Feed x264 with 16bit avs

[FranceBB]

Great!
I tested the build, it works just fine as I've encoded an XAVC Intra Class 10bit planar feeding it with a 16bit 4:2:2 planar, but... here's the thing: my AppleProRes masterfile was 10bit planar 4:2:2, but after indexing it I had to go all the way up to 16 planar 4:2:2 and feed x264 which then used the Sierra 2-4A Error Diffusion Dithering to go back to 10bit planar, which is... well... alright, but I couldn't feed x264 with 10bit 4:2:2 planar directly as it was saying that it's not supported.

Maybe in the future it would be worth adding support for 10bit planar as well to avoid useless dithering if sources are 10bit planar in the first place.

This is just me thinking out loud, though.

Thanks for the build, Jean Philippe. ;)

[benwaggoner]

Great!
I tested the build, it works just fine as I've encoded an XAVC Intra Class 10bit planar feeding it with a 16bit 4:2:2 planar, but... here's the thing: my AppleProRes masterfile was 10bit planar 4:2:2, but after indexing it I had to go all the way up to 16 planar 4:2:2 and feed x264 which then used the Sierra 2-4A Error Diffusion Dithering to go back to 10bit planar, which is... well... alright, but I couldn't feed x264 with 10bit 4:2:2 planar directly as it was saying that it's not supported.

Maybe in the future it would be worth adding support for 10bit planar as well to avoid useless dithering if sources are 10bit planar in the first place.

This is just me thinking out loud, though.

You could use ffmpeg to do 10-bit 4:2:2 passthrough to see if there's a meaningful difference in the results between that and the 16-bit passthrough. Or dump the two outputs to .y4m and compare a diff of them.

In general, using error diffusion doesn't seem to be needed in doing 10-to-16-to-10. The intermediate 16 has enough precision that a straight truncated conversion will return the same values as long as you're not doing any filtering (including scaling).

[tormento]

Can we please make a point about direct HBD support in current x264 builds?

AFAIK JPSDR has implemented it, plus a Sierra dithering to output to lower bitplanes, but without OpenCL, DJATOM supports it but without dither.

The perfect build would be with dithering and OpenCL. Please :)

[jpsdr]

In the dawn of time, during my first attempts to build x264, the build failed with an OpenCL related error. Adding --disable-opencl allowed the build to success, and as i'm not interested in OpenCL, i didn't want to spend time to search why the build failed and how fix this.
Out of curiosity, just now, i tested to make a build removing --disable-opencl, to see if by any chances, things changed since.
And the build worked. So, unless bad unexpected surprise, there is a big chance that the next release will have OpenCL, or at least, not build with --disable-opencl.

[FranceBB]

So, unless bad unexpected surprise, there is a big chance that the next release will have OpenCL, or at least, not build with --disable-opencl.

Great news. :)

[DJATOM]

OpenCL stuff in x264 is 8 bit only. Why do we need it nowadays, when CPUs yields much better performance? I have tested with rtx2070 and it's even slower than plain CPU encode :D

[FranceBB]

Maybe for some scenarios, but in my case I've seen some improvement on a Quadro P4000 on my server. The reason is that such a server is almost always busy encoding Apple ProRes or whatever to XDCAM MPEG-2 or doing some linear transformation from AVC Intra Class log to BT709 whatever in the meantime, so if I can free up the CPU it's always a good thing. As a matter of fact I did in the past and I've seen some improvements for low bitrate (2.5 Mbit/s to 5 Mbit/s) FULL HD 8bit x264 preset medium High 4:2:0 --ref 4 encode from masterfiles that are supposed to go to the web (like Twitter, Facebook, Instagram etc).

I know that this is a bit different from the everyday folk usage, but professionally speaking you always wanna make the best out of your server and I can't of course use NVEnc for those kind of files so if one of the encoders like x264 can offload something to the GPU, why not...

[jpsdr]

The reason i'm not interested in OpenCL, is that i have a very old blur memory of reading that it produced result less good than with pure CPU for of course the exact same encode.

[FranceBB]

The reason i'm not interested in OpenCL, is that i have a very old blur memory of reading that it produced result less good than with pure CPU for of course the exact same encode.

That's correct. Any kind of parallelization produces a slightly worse quality for the very same encode at the same bitrate, however if we compare it with something like Intel VA-API encoder or the NVIDIA NVEnc proprietary encoder, x264 still yields a significant advantage in terms of quality, so... some people think it's kinda worth it.

But again, it's a matter of taste.
For what is worth, thank you for integrating my patch for XAVC and also for allowing 16bit planar, those two things alone made my day. ;)

What would make it perfect would be VideoLAN integrating it in the official repository, but... I don't think that's ever gonna happen... :(