Converting Fraps footage with x264, output file's colors become brighter?

[Gfer]

I have some 720p footage taken with Fraps that I'm trying to compress with x264 using MeGUI. The problem is, the output file's colors do not look anything like the original video nor the preview in MeGUI. The original file and the preview in MeGUI look identical. They are too bright. How can I fix this? I've tried using the 4 different matrices with ConvertToYV12, the colors look a little better, but not how I would like them to be. Here are some comparative screenshots.

Original, uncompressed:
http://imgur.com/wdP5a.jpg

Compressed with x264:
http://imgur.com/gQa7u.jpg

Will I have to correct this in a editing program?

Encoded with these settings: program --preset slow --pass 2 --bitrate 6000 --stats ".stats" --deblock 0:-2 --bframes 0 --ref 3 --output "output" "input".

[LoRd_MuldeR]

-> FAQ: How to correct luminance levels (http://forum.doom9.org/showthread.php?t=143689)

[Gfer]

Interesting, by default, MPC-HC sets the range to 0-255, but if I switch it to 16-255 the video looks like it should.

[poisondeathray]

What source filter / decoder are you using for the avs script?

AVISource() using the fraps decoder will be RGB (0-255), if you use converttoyv12() it will default to rec601 (Y' 16-235)

FFVideoSource() will decode using full range YUV (Y' 0-255)

Also , The method in which you take screenshots will affect the appearance (ie. which matrix did you use to convert YUV data to RGB for the screenshot)

See
http://forum.doom9.org/showthread.php?t=157941

[Gfer]

I'm using AVISource(). I didn't do anything to the fraps video. So how do I use FFVideoSource()? What about audio? I don't have a lot of experience encoding. I used whatever matrix is the default for MPC-HC.

[Dark Shikari]

x264 by default encodes as TV range.

You must either convert to TV range in your script, or use --fullrange. We have a patch under development to make x264 automatically do --fullrange, but this will not work for Avisynth scripts (it's impossible to judge reliably from an Avisynth script whether the output is fullrange or not).

[Gfer]

How would I go about converting to TV range in my script? I'll try encoding the video with --fullrange on meanwhile.

Edit: --fullrange on didn't do anything, it still doesn't look right.

[LoRd_MuldeR]

How would I go about converting to TV range in my script?

http://avisynth.org/mediawiki/Convert#Options

[poisondeathray]

I read your first post incorrectly. If the original and megui preview correlate, then it is likely a playback problem . Read Lord Mulder's post again. (or are you saying they correlate, but are both wrong?)

If you're using overlay mixer in mpchc, then you can calibrate your graphics card overlay settings (this is different than desktop graphics card settings . )

Some players disregard whatever you flag in x264 (the flag doesn't change the actual video data anyway, it's just a suggestion to the player to display as full range or limited range)

[Gfer]

Already tried ConvertToYV12(matrix="Rec601") and ConvertToYV12(matrix="Rec709"). Still not working. All I want to do is to compress the fraps footage with x264 into a .mp4 file that can be uploaded to Youtube or viewed in MPC-HC without altering any settings in MPC-HC.

The original and preview correlate. They represent exactly how I want the video.

[poisondeathray]

The original and preview correlate. They represent exactly how I want the video.


If your script for that used ConvertToYV12() (converttoyv12 defaults to rec601) and the original and preview look exactly how you want, then it's likely a playback configuration issue. (ie. you have MPCHC setup incorrectly. )

x264 doesn't change levels when fed YV12 input . i.e. input=output

And youtube always displays as Rec709 (even SD content) - ie. YUV=>RGB conversion for display uses Rec709 matrix, so you will never get it looking 100% identical on youtube.

[Gfer]

Is there no way to make the video play correctly out of the box in MPC-HC?

[LoRd_MuldeR]

Then, how do I set up MPC-HC correctly? Is there no way to make the video play correctly out of the box?

Depending on whether the individual player/renderer assumes TV-Levels or PC-Levels by default, the configuration that produces correct display "out-of-the-box" is different :rolleyes:

If, for example, you use choose Haali's Renderer or MadVR as your renderer in MPC-HC, you can simply switch the Luminance Levels in the renderer options...

http://img29.imageshack.us/img29/3261/lumilevels.th.jpg (http://img29.imageshack.us/img29/3261/lumilevels.jpg)

[poisondeathray]

If you're taking screenshots in MPCHC, that means you have the renderer set to VRM9 renderless or VRM7 renderless - this changes how the file looks

As Lord Mulder suggests, change the renderer to overlay mixer, or haali, or mad vr and it will look less "washed out"

There is no perfect "out of the box" settings, because your graphics card settings can alter how it looks if you use certain renderers

When you make changes, make sure you exit the player and restart before checking again

[Gfer]

Haali's renderer and MadVR are greyed out in my settings. Are they plugins? I took the screenshots with the EVR presets renderer. The video looks like it should in overlay mixer. It's sort of annoying though, when a video plays, Windows Aero is turned off. It's turned on again when I close MPC-HC. Should I try a ffdshow + MPC combo? Seems like it's easier to configure.

I've kept MPC-HC mostly because it plays DXVA very well for me. Does ffdshow have support for that?

[LoRd_MuldeR]

Haali's renderer and MadVR are greyed out in my settings. Are they plugins? I took the screenshots with the EVR presets renderer. The video looks like it should in overlay mixer. It's sort of annoying though, when a video plays, Windows Aero is turned off. It's turned on again when I close MPC-HC. Should I try a ffdshow + MPC combo? Seems like it's easier to configure.

Both, Haali's Renderer and MadVR are implemented as DirectShow filters. You need to install/register them separately.

Then you should be able to use them in any DirectShow-based player, at least if the player exposes an option to choose a "custom" renderer (MPC-HC does).

The "overlay renderer" naturally causes Aero Glass to be temporarily disabled, as overlays can't work with desktop composition enabled...

See also:
http://forum.doom9.org/showpost.php?p=1271414&postcount=1


I've kept MPC-HC mostly because it plays DXVA very well for me. Does ffdshow have support for that?

Yes. But neither Haali's Render nor MadVR currently supports DXVA. So you'll have to use EVR for DVXA decoding to work, I guess.

Nontehelss any half-way decent machine should be able to decode 1080p H.264 with pure software decoding...

[Gfer]

Any modern half-way decent machine, yeah. I utilise DXVA on a old Intel Pentium 4 processor. Plays 1080p just fine. I'd rather spend $20 on a new graphics card and be able to play HD videos rather than buying a new motherboard + cpu. Anyway, I tried both Haali's Renderer and MadVR. The video plays just as expected. Problem solved, I guess. Just worried about if I share the .mp4 with other people and the colors are off. Minecraft and other colorful games are so vivid and creates a drastic change in color.

[Dark Shikari]

Already tried ConvertToYV12(matrix="Rec601") and ConvertToYV12(matrix="Rec709"). Still not working. All I want to do is to compress the fraps footage with x264 into a .mp4 file that can be uploaded to Youtube or viewed in MPC-HC without altering any settings in MPC-HC.

The original and preview correlate. They represent exactly how I want the video.That doesn't work. FRAPS decodes as PC-range YV12. Those commands exist to convert RGB to TV-range YV12. But your video is already YV12, so those commands do nothing.

[Gfer]

How would I convert it to TV-range? I did .Info() on the fraps video, it's color space was RGB32.

[poisondeathray]

How would I convert it to TV-range? I did .Info() on the fraps video, it's color space was RGB32.


If you're using the fraps decoder with AVISource, it will be RGB

RGB is 0,0,0 - 255,255,255 (ie. 0,0,0 is black, 255,255,255 is white)

When you convert to Y'CbCr (e.g. ConvertToYV12() ), that converts RGB [0-255] to Y' 16-235, CbCr 16-240 which is "TV range". Y' 16 is black, Y'235 is white

(i.e. when you don't specify a matrix for converttoyv12() it uses rec601, which is TV range)

[Dark Shikari]

If you're using the fraps decoder with AVISource, it will be RGBSince when? FRAPS is a YV12 format.

[Blue_MiSfit]

To shrink PC range (0-255) to TV range, you can use ColorYUV(levels="pc->tv"), or better yet SmoothLevels(preset="pc2tv")

Derek

[cyberbeing]

Since when? FRAPS is a YV12 format.

Since November 21st, 2009 I guess? In FRAPS 3.0.3 they added a Lossless RGB capture mode.

By default FRAPS still captures in their proprietary lossy YV12 compression, but by checking a box in setting, you can get proprietary lossless RGB compression instead, at the expense of slower capture speed and increased file size.

[sneaker_ger]

Also note that when using their decoder with AviSource() it seems to always decode to RGB32, even it's not RGB.

[Gfer]

I'm really confused now. What should I do to ensure the best compatibility? Convert to TV-range(Rec709)?

Edit: It seems like it was an issue with DXVA and my ATI drivers, using ffdshow or disabling dynamic contrast when using the internal DXVA filter in MPC-HC makes the video look a little better.

Edit: I'm pretty sure DXVA is messing up the colors. Looks just fine when using ffdshow for h264. Is there any fix for this? Disabling dynamic contrast makes it look a little better, but not quite as good as the original/preview. Both MPC-HC's internal DXVA filter and ffdshow's DXVA filter produces the same results. I could upload the video if anyone wants to see what I'm seeing.

[Blue_MiSfit]

1) Verify that without any conversion, you're getting RGB out of AVISource

2) If so, use ConvertToYV12(matrix="rec709"), and things should be totally fine

3) If not (you're getting some kind of YUV format), use histogram() to determine if the video is full or limited range

4) If it's limited range, encode as-is. If it's full range, either scale it with ColorYUV/SmoothLevels, or set --fullrange in x264.

Derek

[Gfer]

Encoded a version like that this time. When played with DXVA on, either ffdshow's or MPC-HC's internal filter, the colors become slightly brighter. When using ffdshow's h264 decoder everything looks fine. Even when using shaders in MPC-HC or setting a different output range in my graphic's driver, it still doesn't look like it should. Where do I go from here?

[Snowknight26]

Sounds like your GPU drivers are doing some post-processing.

You must either convert to TV range in your script, or use --fullrange.

Most decoders ignore the fullrange flag, sadly. Even ffplay does, and ironically seems to do the PC -> TV conversion twice.

[Gfer]

Well, I have a ATI Radeon HD5850 GPU. There's Intelligent Saturation, Skin tone correction, dynamic range (which is 0-255) and dynamic contrast. Turning off these options and keeping the dynamic range at 0-255 made the video look like it should. Thanks for the help.

[Blue_MiSfit]

Indeed.

I prefer to turn this dynamic contrast /skin tone correction stuff off anyway - you shout set things up correctly without them.

My feeling on features like these is that they could potentially cause issues if you feed them unexpected input. I'm not basing that on anything but gut instinct, though :devil:!

Derek

[Snowknight26]

Now if only there was a way to keep the source input levels without Avisynth (such as when feeding x264 the input directly) and without --fullrange on..

[nm]

Now if only there was a way to keep the source input levels without Avisynth (such as when feeding x264 the input directly) and without --fullrange on..

Like this:

We have a patch under development to make x264 automatically do --fullrange, but this will not work for Avisynth scripts (it's impossible to judge reliably from an Avisynth script whether the output is fullrange or not).

[Schrade]

Just to let you know, you want your video a bit brighter if you're going to upload it to YouTube. They seem to like to crush the blacks.

My current work process for FRAPS videos is using direct264 to encode the files and ffdshow to set the levels to 16-235. Direct264 reads the file in and it uses ffdshow to decode it on my system.

When encoding the videos using normal x264 and the --fullrange option, the videos playback locally perfectly fine but if you upload them to YouTube, YouTube will crush the blacks and make the videos really dark.

[Dark Shikari]

You should convert to TV range before uploading to Youtube.

[userix]

I have Fraps 3.2.9 and am using Handbrake to transcode my lossless RGB Fraps video captures. I am getting the "washed out" look with my transcoded videos. What arguments exactly do I have to set in my Handbrake CLI box to get it to convert with the right colorspace, luma, chroma, etc? I'm new to all this YUV, RGB, bt601, bt709 stuff.

How/where do I find and use this convertToYYV12 function? Thanks for the help!

[mzso]

x264 by default encodes as TV range.

You must either convert to TV range in your script, or use --fullrange. We have a patch under development to make x264 automatically do --fullrange, but this will not work for Avisynth scripts (it's impossible to judge reliably from an Avisynth script whether the output is fullrange or not).

Ok. So at present, do I have to use --fullrange with ffmpeg?

How to verify the range with certainty? (The renderer might be good enough to guess/determine the range of the video)

[mzso]

There is another thread over there:

http://forum.doom9.org/showthread.php?t=155772

;)

That seems like an avisynth topic which I don't use. Which part is of interest to me?

[vivan]

Ok. So at present, do I have to use --fullrange with ffmpeg?

How to verify the range with certainty? (The renderer might be good enough to guess/determine the range of the video)It's now --input-range PC (http://mewiki.project357.com/wiki/X264_Settings#input-range) in x264, probably the same in ffmpeg...

To verify it - open it in properly configured player, e.g. MPC-HC with LAV filters and madVR. madVR should show that range is full in OSD, and colors&brightness of the image should match source.

[mzso]

It's now --input-range PC (http://mewiki.project357.com/wiki/X264_Settings#input-range) in x264, probably the same in ffmpeg...

To verify it - open it in properly configured player, e.g. MPC-HC with LAV filters and madVR. madVR should show that range is full in OSD, and colors&brightness of the image should match source.
I tried "-color_range 2"
Depending on decoder, I get full range (best guess), but with artifacts:

http://abload.de/img/fraps-ffmpeg-113qyg.png

Otherwise limite range, and blurry. Same results without it.

Now, I'm going try to figure out how to pass --input-range PC to ffmpeg.

[mzso]

You asked this:





And the other thread has the answer to it, see:





;)

By the way, the latest HandBrake version (0.9.9 was just released), converts FRAPS YV12 footage ("Force lossless RGB capture (may be slower)" checkbox disabled) better than anything else i'm aware of.

There is a thread about it:

http://forum.doom9.org/showthread.php?t=165680

With the "Force lossless RGB capture (may be slower)" checkbox enabled, HandBrake messes up the colors. But with that checkbox disabled (YV12), HandBrake is quite perfect at converting FRAPS YV12 to x264.

I really would like to know why HandBrake is so good at converting FRAPS YV12.

I still don't know how to convert FRAPS YV12 with AviSynth as good as HandBrake does.

But If I disable lossless "Force lossless RGB capture (may be slower)" I get a lossy video right?

[mzso]

Now, I'm going try to figure out how to pass --input-range PC to ffmpeg.
But apparently I can't. Tried using "-x264opts " but it didn't work.
Didn't find anything else, besides -color_range in the ffmpeg help.

[mzso]

No, AFAIK both is lossless, but not 100% sure.

AFAIK the only difference is:

"Force lossless RGB capture (may be slower)" disabled = YCbCr 4:2:0

and:

"Force lossless RGB capture (may be slower)" enabled = RGB (which is 4:4:4)

So, yeah, YCbCr 4:2:0 is not really "lossless", because you loose chroma resolution (4:2:0 vs. 4:4:4 (http://forum.doom9.org/showthread.php?t=167428)). But you are very likely to loose that anyway when you are encoding with x264.

You can encode in YCbCr 4:4:4 and RGB with x264 to keep the chroma resolution, see:

http://forum.doom9.org/showthread.php?t=165415

But the resulting video probably (and unfortunately) will not play back on anything else than PC software.

Well I prefer actual lossless and no subsampling. Since I don't use anything else for playback than a computer the last is a non issue for me. Only if I knew how to get ffmpeg/libx264 to keep the range untouched...

[mzso]

Then you explicitly have to tell x264 to encode without subsampling.

x264 defaults to --output-csp i420 (4:2:0 chroma subsampling).

So, if you want to encode without subsampling then you need to use either --output-csp i444 or --output-csp rgb, otherwise it will encode with 4:2:0 chroma subsampling AFAIK.

See:

http://mewiki.project357.com/wiki/X264_Settings#output-csp

ffmpeg doesn't accept "-x264opts output-csp=rgb" or "-x264opts output-csp=i444" it seems. Not sure about the syntax, so far it seemed this syntax is right because it accepted "-x264opts fullrange=on", only it produced the same result.

I get: "Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height"

[poisondeathray]

If you want to encode i444 with ffmpeg , use -pix_fmt yuv444p . I don't think libx264 in ffmpeg can use RGB24 or BGR24 (RGB fraps is detected by current ffmpeg builds as bgr24)

BUT the problems you're going to have is the RGB=>YUV conversion will use Rec601 (it will not be subsampled chroma, but colors will be off because of wrong matrix - should be 709)

ffmpeg does have a colormatrix filter, but the quality is noticably lower than doing it in avisynth
-vf colormatrix=bt601:bt709

(In avisynth you can use ConvertToYV24(matrix="Rec709")

Another option might be to do the colorspace conversions in vapoursynth pipe to ffmpeg

[osgZach]

With the "Force lossless RGB capture (may be slower)" checkbox enabled, HandBrake messes up the colors. But with that checkbox disabled (YV12), HandBrake is quite perfect at converting FRAPS YV12 to x264.

I really would like to know why HandBrake is so good at converting FRAPS YV12.

I still don't know how to convert FRAPS YV12 with AviSynth as good as HandBrake does.

Because when you convert from RGB to YV12 you lose color information. If you record in YV12, most tools won't need to convert because its already YV12. If you judge a YV12 video file produced by fraps, compared to a YV12 H264 you naturally would not see much of a difference, except in the case of the Color Matrix changing for w/e reason.

So, if Handbrake isn't changing the color levels (PC<->TV etc) then that is why it works so well for you.

Its why I loathe Youtube and other streaming services that do not support 4:2:2 or 4:4:4 Color sampling.

When I do game captures I compare the actual game on-screen (PNG/BMP screenshots, etc) to the video file produced during capturing. YV12 always looks horrible to me. Something somewhere, even with tweaking always ends up looking either washed out or oversaturated - i.e it probably takes more effort than I am willing to learn how to precisely convert colors from RGB - > YV12.

So I just gave up on capturing game footage.

[mzso]

If you want to encode i444 with ffmpeg , use -pix_fmt yuv444p . I don't think libx264 in ffmpeg can use RGB24 or BGR24 (RGB fraps is detected by current ffmpeg builds as bgr24)

BUT the problems you're going to have is the RGB=>YUV conversion will use Rec601 (it will not be subsampled chroma, but colors will be off because of wrong matrix - should be 709)

ffmpeg does have a colormatrix filter, but the quality is noticably lower than doing it in avisynth
-vf colormatrix=bt601:bt709

(In avisynth you can use ConvertToYV24(matrix="Rec709")

Another option might be to do the colorspace conversions in vapoursynth pipe to ffmpeg

Well, it still doesn't seem to be right... When I change to PC levels it's still light.

Here's the exact command line:
ffmpeg -i "infile1.avi|infile2.avi" -pixel_format rgb24 -acodec copy -scodec copy -vcodec libx264 -g 30 -pix_fmt yuv444p -vf colormatrix=bt601:bt709 -preset slower -crf 20 -x264opts fullrange=on "teszt.mkv"

Here's the output (interrupted after a few seconds): https://docs.google.com/file/d/0ByfdfPvnoDuzb2k0QTdBVGRqR1U/edit?usp=sharing

[osgZach]

Looks fine to me? Plenty of dark and shadowy in that.

Is your monitor calibrated?

[poisondeathray]

Can you post a few frames of the fraps source file (vdub, video => direct stream copy ) or I suppose you can cut it with ffmpeg -vcodec copy -an with -ss (start time) and -t (duration)

There are major, major quality issues with ffmpeg's colormatrix filter - it looks like doesn't work in full chroma resolution. Even when working with YV12 (4:2:0) material , quality is noticably lower than avisynth's colormatrix (I don't know why, it was ported from avisynth)

[osgZach]

To further that. Why not try running it through x264 instead of ffmpeg. I didn't want to say anything earlier, as I assumed it was just preference. But if there are quality issues with ffmpeg in this situation, then yeah try another encoder.

[mzso]

Can you post a few frames of the fraps source file (vdub, video => direct stream copy ) or I suppose you can cut it with ffmpeg -vcodec copy -an with -ss (start time) and -t (duration)

There are major, major quality issues with ffmpeg's colormatrix filter - it looks like doesn't work in full chroma resolution. Even when working with YV12 (4:2:0) material , quality is noticably lower than avisynth's colormatrix (I don't know why, it was ported from avisynth)

Here's 1 sec. https://docs.google.com/file/d/0ByfdfPvnoDuzeUoxQjNOa1hwLTA/edit?usp=sharing

It's still 33MB...