High 4:2:2 Profile (Hi422P)

[Seraphic-]

Has there been any developments in the area of implementation and supporting High 4:2:2 Profile (Hi422P) encoding?

[cacepi]

Has there been any developments in the area of implementation and supporting High 4:2:2 Profile (Hi422P) encoding?
High 10 would probably have to be implemented first, as full High 4:2:2 support naturally implies 10-bit capability. If I understand correctly, 10-bit isn't forthcoming any time soon, as AVIsynth doesn't support 10-bit video and x264 has no internal colorspace conversion (not that it needs it).

[Manao]

AVIsynth doesn't support 10-bit video and x264 has no internal colorspace conversion (not that it needs it). Avisynth 2.6 (which is somewhat working) supports 16bits YUV colorspace, and 8 -> 10 bits colorspace conversion are easy anyway (you just have to multiply by 4).

Seraphic- : are you talking about x264 ? or about any h264 encoders ?

[akupenguin]

8 -> 10 bits colorspace conversion are easy anyway (you just have to multiply by 4).
You mean multiply by 1023/255 = 4.012, assuming fullrange. Though the color change from doing it wrong is pretty small.

[Seraphic-]

Seraphic- : are you talking about x264 ? or about any h264 encoders ?

I am sure there are some rather expensive encoders that support high profile encoding. But yeah, I was talking about x264.

[benwaggoner]

Avisynth 2.6 (which is somewhat working) supports 16bits YUV colorspace, and 8 -> 10 bits colorspace conversion are easy anyway (you just have to multiply by 4).
But if you're just padding the LSBs with 0s, there woudln't be any point in using 10-bit.

OF course, if there was a 10-bit decoder that could plug into a high color display pipeline, you could do some neat stuff in reducing banding by dithering in the LSBs even with 8-bit sources...

It'd be really nice for low lumas where LCDs break perceptual uniformity.

[Dark Shikari]

But if you're just padding the LSBs with 0s, there woudln't be any point in using 10-bit.Sure there would. One of the primary inefficiencies in H.264 is the rounding in motion compensation and biprediction, which is mostly mitigated when using 10-bit.

[benwaggoner]

Sure there would. One of the primary inefficiencies in H.264 is the rounding in motion compensation and biprediction, which is mostly mitigated when using 10-bit.
We need an emoticon for "deeply ruminating."

Yeah, I can see how that could net out as an improvement even with the theoretical overhead of the extra bits. I'd been mainly thinking of it as a way around low-luma blocking/banding problems.

Any rough guess as to the potential efficiency gain?

Windows 7 introduces 10-bit and 16-bit per channel color modes. Maybe in a few years we could have end-to-end 10-bit authoring and display, and stop having to worry about dithering and banding so much. Low luma problems would presumably be better if the in-loop deblocking filter was able to do something between adjoining blocks that today would be Y'=16 and Y'=17.

...so many more cool things to pay attention to than I have attention to pay...

[Dark Shikari]

We need an emoticon for "deeply ruminating."

Yeah, I can see how that could net out as an improvement even with the theoretical overhead of the extra bits. I'd been mainly thinking of it as a way around low-luma blocking/banding problems.

Any rough guess as to the potential efficiency gain?

The biggest (and easiest-to-fix) problem with the H.264 spec is accumulating rounding errors in qpel/bipred, resulting in B-frames having an average of ~0.4 higher luma than P-frames, and furthermore an enormous number of redundant "-1" DC coefficients in inter blocks.

Combine this with rounding errors from iDCT and I would expect at least a 3-5% efficiency gain from 10-bit, probably more.

[Manao]

You mean multiply by 1023/255 = 4.012, assuming fullrange. Though the color change from doing it wrong is pretty small. There are no reason to want both 0 -> 0 and 255 -> 1023. Imho, pixel values are not discrete values, but intervals : 0 actually represents [0:1[ and 255 represents [255:256[. With such a scheme, 255 ought to be mapped on [1020:1024[, and any number in that interval will do.