High 10 profile in x264: first impressions

[D3C0D3R]

Attachments may take a long time to get approved and we can't see them before that happens.
i didnt know ))
i opened all files via
DirectShowSource(src,pixel_type="RGB24",audio=false)
EDIT: upload here http://www.mediafire.com/file/jxdznmixnom/x264_bit_depth_tests.rar

What's interesting about the SSIM of the not properly decoded video being lower than the one decoded correctly?
this is only case where 10 bit SSIM>9 bit SSIM>8 bit SSIM

[nm]

i didnt know ))
i opened all files via
DirectShowSource(src,pixel_type="RGB24",audio=false)
Ok, so you don't control the colorspace conversion but let either the decoder or some DirectShow format convertion function do it. That's why you get different results with 8-bit ffdshow and DivX output. Use YV12 output when decoding and convert to RGB24 with AviSynth or some common separate tool.

I'm not sure how to make a valid comparison between 8-bit and 9/10-bit encodes though.

this is only case where 10 bit SSIM>9 bit SSIM>8 bit SSIM

But it doesn't make sense to compare those results when the decoded video is broken differently in each case.

[foxyshadis]

A few test sequences decoded with DivX showed better behavior in fades when I was looking extremely closely for artifacts. Not sure if that's the weightp effect mentioned earlier? I won't post metrics since I wasn't encoding for them though.

The major advantage of 10-bit output: You can represent the entire 8-bit RGB gamut, even with clamped TV levels, which is impossible in 8-bit YUV. You no longer need a dithered RGB conversion just to get a full range of bright and dark colors. Even with 8-bit input, all of the roundoffs that x264 makes would make 10-bit look better. I look forward to that.

Of course, RGB still can't handle the full range of 8-bit YUV color, but that's a different problem.

[Manao]

You can represent the entire 8-bit RGB gamut, even with clamped TV levels, which is impossible in 8-bit YUVHuh ? You'll get a more precise YUV -> RGB conversion, and that's all. I don't see how 10 bits would improve coverage of the whole RGB gamut

[benwaggoner]

Huh ? You'll get a more precise YUV -> RGB conversion, and that's all. I don't see how 10 bits would improve coverage of the whole RGB gamut
...mulling over just this question today, I did the math, so I might as well share it :).

Typically (at least with some decoders) on playback the Y'=16-235 nominal luma range in an 8-bit encode is exapnded to the 0-255 displayed range of RGB. Since there are 36 more values in 0-255 compared to 16-235, a straight conversion would necessarily skips about 7% of possible RGB values. E.g. we might be able to get output at RGB=19 and RGB=21, but have no Y' value in 8-bit that will wind up as RGB=20 after range expansion. That bigger transition can double the appearance of banding, particularly in CGI content. Dithering can fix this, but at the obvious cost of added noise.

When we have a 64-940 (sic?) range, we have a 3-4 different Y' values that will go into each 8-bit RGB value, so less banding.

Depending on how a 8-bit to 10-bit conversion is done, it could potentially smooth out any gradients in the source a bit, and thus resulting in an output with less banding than the source...

None of this will matter with a decoder that maps Y'=16 to RGB=16, but then you've got very ugly washed-out blacks, particularly on LCD displays.

[madshi]

@ben, when talking about HTPC playback, decoders usually output untouched NV12 or YV12 (for 8bit content). It's usually the duty of the video renderer to convert that to RGB. Good video renderers (e.g. madVR) will internally work in a much higher bitdepth and then at the end of the processing chain automatically dither down to the output bitdepth. So banding should not be an issue in any case, unless it's in the source.

[benwaggoner]

@ben, when talking about HTPC playback, decoders usually output untouched NV12 or YV12 (for 8bit content). It's usually the duty of the video renderer to convert that to RGB. Good video renderers (e.g. madVR) will internally work in a much higher bitdepth and then at the end of the processing chain automatically dither down to the output bitdepth. So banding should not be an issue in any case, unless it's in the source.

Of course. I was imprecisely using "decoder" to encompass the entire chain from bitstream to screen. Since Silverlight is one big .dll, I get sloppy about discriminating between the precise internal components sometimes :).

[aegisofrime]

So... there still isn't a free 10-bit decoder out now? You would think that writing a decoder would be easier than writing an encoder (intuitively, at least)

[madshi]

Of course. I was imprecisely using "decoder" to encompass the entire chain from bitstream to screen. Since Silverlight is one big .dll, I get sloppy about discriminating between the precise internal components sometimes :).
:)

So... there still isn't a free 10-bit decoder out now? You would think that writing a decoder would be easier than writing an encoder (intuitively, at least)
A 10bit decoder patch was posted to the ffmpeg/libav mailing list, but it's still in the review phase since it ever so slightly slows down 8bit decoding.

[mandarinka]

According to http://ffmpeg.org/ (and the videolan git repo history), ffmpeg already has the decoding support merged. It hasn't been speed-optimised, but one should be able to for example compile an MPlayer build capable of 9/10bit decoding.

[kieranrk]

According to http://ffmpeg.org/ (and the videolan git repo history), ffmpeg already has the decoding support merged. It hasn't been speed-optimised, but one should be able to for example compile an MPlayer build capable of 9/10bit decoding.

The problem is that the 10-bit decoder doesn't pass some of the conformance tests which is why it's not in libav yet.

[mandarinka]

Yes, but I think I've seen it mentioned somewhere that the failing streams are produced by some hardware boxes - thus I think I can safely say that those don't matter. We are all in this thread because we want to play/test streams encoded by x264 :)

And yeah, it's not in libav yet (the fork of ffmpeg). ffmpeg will no doubt get any future fixes anyway, when/if they come.

[D3C0D3R]

According to http://ffmpeg.org/ (and the videolan git repo history), ffmpeg already has the decoding support merged. It hasn't been speed-optimised, but one should be able to for example compile an MPlayer build capable of 9/10bit decoding.

We have some steps in this direction. At least it works :cool: