FFDShow with H.264 10bit support

[nevcairiel]

Michael applied a change to ffmpegs swscale now to always use a simple shift for the chroma planes and limited-range luma, and only use the byte-duplication for full-range luma.
Its not a final solution, but it fixes the common use-case for limited range content.

However, this is ffmpeg, not x264, so .. someone get the changed in there as well. :p

I do hope the development of the changes goes into the right direction. The latest talk is about simply changing the 10->8 downscaler to correct for the upscaling error, which sounds terrible.

[JEEB]

Yeah, saw that on the IRC channel when it got in.
<CIA-107> ffmpeg: Michael Niedermayer master * rabe0b8e9f3 ffmpeg/ (9 files in 3 dirs):
<CIA-107> ffmpeg: sws: use shift for chroma sample up convertion
<CIA-107> ffmpeg: sws: use shifts for non full range luma sample upconvertion
<CIA-107> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
<kierank> irock: ^
<irock> oh
<irock> well, it was the right thing to do - but I assumed we were going to discuss this further first

Anyways, the good thing is that now something goes by some specification (BT.709 in this case IIRC), full range content can be discussed further, as well as the 10->8 dithering algorithm + possible other specifications.

Also, in related things, I wish I could understand filters/video/depth.c better >_>

[JEEB]

Posted a test build of x264 with a corrected limited range 8bit -> output bit depth algorithm here (http://forum.doom9.org/showthread.php?p=1522281#post1522281). Would be interested to see results.

[Cman21]

So now the question is which way is correct?

FFDShow-Tryouts | LAV-Video
OR
MPlayer | FFmpegSource2 | MadVR



Actually now that I think about it, what we are likely seeing is once again the x264 8bit to 10bit levels bug which madshi confirmed with a test chart sample I created a few days ago. Which once again means that MadVR, MPlayer, and FFmpegSource2 are decoding the incorrect levels in the encode as-is (which is correct decoding), and reproducing the slight color shift which x264 created.

FFDShow-Tryouts & LAV-Video are either using the same broken swscale conversion as x264 or clipping input levels and is actually partially reversing the problem skewed levels in the encode creates (which is incorrect decoding). Which likely means both FFDShow-Tryouts and LAV-Video will need to keep their eye out for x264 fixing their swscale levels bug, so they can apply the same fix.

What this really comes down to is don't use x264's built-in 8bit to 10bit conversion or your encode won't have proper levels and will decode/render with a color tint until the bug is fixed. Someone should really check if the same thing happens with 16bit x264 input to 10bit.

so does the latest x264 revision2074 on 2011-08-25 have this issue fixed or is it still pending?

[cyberbeing]

Still pending. The patches were pulled from the x264-devel tree since they are still in the process of being re-worked, and won't be included in the upcoming 4:2:2 encoding support push. Which means it will probably be a couple more weeks, or whenever the push after 4:2:2 happens, for this to finally be fixed once and for all.

[sneaker_ger]

You can get builds with an intermediate patch for limited range conversions from JEEB's blog (http://x264.fushizen.eu/).

[Cman21]

OH! thanks for pointing that out to me i didnt notice it the first time >_<

anyway i went and did a quick test encoding and it worked great! here are some comparisons if anyone cares:

http://screenshotcomparison.com/comparison/80048
http://screenshotcomparison.com/comparison/80050

[chapas]

Cman21, those look great! So 10bit solves the color blotches attributed to the encoder being too aggressive?

Can I get a sample of a 10bit file?

Thanks.

[Cman21]

umm sure i can upload a sample, sry for the delay but my C:\ failed on me so i have been a little preoccupied trying to get my computer back to an operable state... just send me a PM and i'll shoot you a link to the samples i used to make that comparison.

also i see that we are now on revision 2085 but on the change log i dont see anything about correcting this shift. but im going to ask anyway as half that stuff went over my head but is it corrected in r2085 or do i still need to use the non official one?

EDIT: Crap... i completely forgot i saved those videos on my desktop which i lost when i lost my C:\ so i cant upload them at the moment. i could always run it again but i dont know when i'll have the time to do so. but i do have more screenshots that i didnt post before cuz i didnt think they where completely relevant at the time so i'll just post those now.

the gradient comparisons show the main strong point in 10bit vs 8bit with the first screenshot is obvious why 10bit is better and the second is more subtle. on the second image on the gradient comparison look around the snow flakes near the top, you should see the 10bit has a much smoother transition between the white and blue. now after looking at quite a few detail oriented screenshots i think it is a wash between which is better, 10bit or 8bit. this is because 10bit's main advantage is in gradients and most detail oriented content has few gradients. but then you must also keep in mind the ~5-10% file size reduction that 10bit has, when encoding with the same settings, which is why 10bit still better.

the only other thing to note on these screenshots is that they where made using the official x264 r2074 which does not contain the correction that i compared in the previous post, which is why you see the shifting on the first gradient comparison. other than that single image i can barley, or not at all, see any shifting of colors.

Gradient Comparisons:
http://screenshotcomparison.com/comparison/80034

Detail Comparisons:
http://screenshotcomparison.com/comparison/80038
http://screenshotcomparison.com/comparison/80039
http://screenshotcomparison.com/comparison/80040
http://screenshotcomparison.com/comparison/80041
http://screenshotcomparison.com/comparison/80042