Colorspace loss when converting from FRAPS to XviD?

[Foxhack]

I've been doing some game footage captures with Fraps (1280x720) and the videos are rather large, somewhere around 750 to 900 MB per minute. I figure, I can probably recompress them to XVid using its 720p profile at maximum quality to have it in a format I can back up and edit later on. I know, it's not lossless, but it's not that big of a deal.

Anyway, I used Virtualdub and while the compression looks fine, the colors look very washed out on the video now - too bright, even. I'm not sure what's causing this, but some sites seem to suggest it's a colorspace issue.

Is there a way to fix this with an encoder setting, or am I out of luck?

[jagabo]

You probably just need to adjust your graphics card's video proc amp settings. Ie, there's nothing wrong with the Xvid file you made. The problem is how video is being displayed by your graphics card.

Try playing the video in this post:

https://forum.videohelp.com/threads/326496-file-in-Virtualdub-has-strange-colors-when-o...=1#post2022085

Does it look the same as the first picture?

[Foxhack]

That video looks the same as that picture on both Videolan and Media Player Classic Home Cinema using FFDShow Tryouts.

So I'm not sure what's going on. If you need more information, please ask, I'll do my best to answer as much as I can.

Thank you for your help.

[jagabo]

Can you post a few frames of the fraps source and the Xvid file you made from it?

Some general info:

Xvid uses YUV 4:2:0 chroma subsampling internally so colors from and RGB 4:4:4 source will get a little blurred. Very small objects (one or two pixels) may lose their color or saturation depending on the surrounding pixels. But large areas shouldn't change colors.

Note that VLC uses its own internal Xvid decoder. MPCHC may use its own decoder or the system installed DirectShow decoder depending on how it's set. So different players and editors can be use different decoders -- and hence may look different. MPCHC will show you which filters are in use while playing a video: right click on the player while playing a video and hover over Filters. You can select any of the filters in the list to see what internal settings are in use. Some filters let you change settings from there too.

Check the Xvid decoder's brightness setting. Also Check FFDShow's brightness settings.

[Foxhack]

Well, here you go. 100 frames (roughly 3 seconds) of footage.

Fraps: http://dl.dropbox.com/u/12145986/Temp/Alone%20Test-Fraps.avi (100-ish MB)
XviD: http://dl.dropbox.com/u/12145986/Temp/Alone%20Test-XviD.avi (31-ish MB)

I tried changing the decoder that ffdshow used, and there was a difference between libavcodec and XviD - XviD's colors were a lot more muted than libavcodec.

Even in VideoLan, the XviD version is slightly brighter than the original FRAPS version. So there's probably something still going on that I'm not quite understanding.

Thanks again for your help.

[jagabo]

Your Xvid file definitely has less contrast than the fraps file. But when I encode the fraps file, my xvid video looks like the original. Did you apply some filters? Maybe a pc.601 to rec.601 matrix adjustment? I was able to duplicate your result by doing that.

[Foxhack]

I was messing around with Avisynth before I made this post, and I had a line in the script: "ConvertToYV12(interlaced=false, matrix="PC.709")"

But, I just now took the original source video, ran it through Virtualdub (without an Avisynth script), selected the first 300 frames, cropped the rest, used the XviD 720p profile at 1 quality, and got the exact same result as the second video.

I also noticed that when I load the source video on VLC, it's dark - but when I load that into Virtualdub and MPCHC, the image is brighter than it should be.

I didn't mention this earlier, but I'm using ffdshow tryouts rev3814 as my DirectShow display filter, and Koepi's XviD 1.3.2 build.

I wonder if my computer's just cursed.

[jagabo]

Note there are two video subsystems in Windows: DirectShow and VFW. Media players use DirectShow, VirtualDub uses VFW. There are separate codecs for each. And if you're using 64 bit Windows you have 32 bit and 64 bit versions of each, four video systems, all of which are separate and cannot access each others' codecs. In addition, programs can use their own private codecs. So you need to figure out which decoder is being used when you open your source in VirtualDub and why it looks different than playing the video in VLC and MPCHC.

Computer RGB video normally uses the full range of 0 to 255 to represent graphics. RGB=0 is full black, RGB=255 is full white. But video usually use a limited range of YUV values where Y=16 is full black and Y=235 is full white. So most programs perform a contrast stretch from Y=16-235 to RGB=0-255 when converting YUV to RGB, and conversely a contrast squash from RGB=0-255 to Y=16-235 when converting RGB to YUV. Therein lies your problem. When you open the fraps file (encoded in YUV) in VirtualDub (which does its filtering in RGB) the normal contrast stretch is not being performed.

When using an AviSynth script to open a video file AviSource() will use VFW codecs, DirectShowSource() will use DirectShow codecs. When opening an AVI video directly with VirtualDub you will will be using VFW codecs, unless you force the program to use DirectShow by selecting "DirectShow Input Driver" via the pulldown at the bottom of the File Open dialog.

You need to figure out which decoder is being used to open the file in VirtualDub. In addition, depending on whether you use the DirectX option in VirtualDub, the graphics card may be converting YUV to RGB for display -- and the graphics card may perform some additional processing of the picture. I would start by disabling DirectX output in VirtualDub to eliminate that as a source of your problem. Options -> Preferences -> Display (left pane) -> Use DirectX... (right pane), un-tick the option and restart VirtualDub.

Now open your Fraps file in VirtualDub. Select File -> Information. In the Decompressor section it may tell you which decoder is being used. I see "ffdshow Video Codec (FPS1)". If it's not obvious which decoder is being used it's harder to figure out. You have to go through your VFW decoders and set an obvious option like vertical flip, or an obvious color change, then open the video in VirtualDub and see if there's any difference. Once you've figured out which decoder is being used you can go through its options and see why it's not performing the usual contrast stretch when converting YUV to RGB.

For example, ffdshow (Start -> All Programs -> ffdshow -> VFW Configurateion) has lots of filtering options that can effect brightness, contrast, and colors: Levels, Offset & Flip, AviSynth, etc. Also, at the bottom of the filter list is "RGB conversion". The "input levels" should be set to "Standard...", and "Output Levels" should be set to "Computer monitor...":

[Foxhack]

Thanks for the explanation.

After reading that, I looked at my video card settings (ATI Radeon HD 4850 running Catalyst 11.8 on Windows 7 Home Premium) and disabled all sorts of color preprocessing that was enabled by default for some reason.

Then I started messing around with Virtualdub's settings and I didn't see anything change regardless of what I changed in the various FFDShow display properties. So I turned to MPC HC, and I managed to fix it by switching the DirectShow video renderer to "Overlay Mixer". This made the Fraps video be as dark as it should be. I tested the other options and some were broken, but it looks like VMR-9 (windowed) worked the best.

And now I went back to VirtualDub. No matter what I messed with in FFDShow, I couldn't get the video display to change. The brightness was still pretty high. I disabled DirectX rendering, made sure both VFW and Video Decoder Configuration had messed up settings, and nothing changed.

I'm completely stumped. I have absolutely no idea what to do now.

[jagabo]

No matter what I messed with in FFDShow, I couldn't get the video display to change. The brightness was still pretty high. I disabled DirectX rendering, made sure both VFW and Video Decoder Configuration had messed up settings, and nothing changed.

In all likelihood ffdshow isn't being used in VirtualDub. To be sure, enable an obvious filter like Flip under Offset * Flip. Then open a video in VirtualDub. If it isn't upside down ffdshow isn't being used.

[Foxhack]

I already did that (apologies if it wasn't made clear in my post.)

If it's not using FFDshow then what the heck is it using?

[jagabo]

Maybe Frap's own decoder?

By the way, this is what I see in VirtualDub and all my players (half size):


And this is what you get when the levels aren't adjusted correctly:

[Foxhack]

... Well. This is... embarrassing.

I just played the game again to get some more test captures and see if I could pinpoint the cause of the problem. It turns out the problem is VideoLan and libavcodec in FFDShow tryouts not handling FPS1 codec videos properly!

I went to the level featured in the videos and played it - and noticed the scene was much brighter than I remembered. So I turned on Fraps, took a screenshot, and ran a test capture. The image came out just as bright as the image I thought was "incorrect". In fact the test video starts off with the proper contrast settings, but then it goes dark after a second.

I looked around and found this thread from last July where one guy has this same issue on a Mac, and they seem to think it's a colorspace issue.

It seem that fraps likes to output full range YCbCr instead of a Lumma that ranges from 16-235.

So Virtualdub sees the video fine since it's using the Fraps codec the program installs instead of the libavcodec / VLC version. Well, I don't understand it, but whatever, I'm just happy I'm not as crazy as I thought.

Thank you so much for your help, jagabo.

[jagabo]

So the brighter of the two images I posted is right?

[Foxhack]

Yes! I don't know why it's doing that, but the brighter version is the right one.

[jagabo]

So yes, that means Fraps is is using Y values from 0-255 rather than 16-235. They should fix their RGB to YUV conversion matrix. Maybe they're doing that to retain a little more precision? But few other programs will handle it correctly. Mabye you should use RGB mode instead.

[Foxhack]

I blame the lack of public documentation on the codec for this weird issue. Both VideoLan and ffmpeg may not have complete support for all features, including the weird color balance thing I mentioned.

I'll go and file bug reports on both projects to let them know about this issue. My videos should be able to help.