Sign In

Post #1269000

Author
TomArrow
Parent topic
Star Wars 4K77 - Regraded - No DNR
Link to post in topic
https://originaltrilogy.com/post/id/1269000/action/topic#1269000
Date created
11-Feb-2019, 4:01 PM
Last modified
11-Feb-2019, 4:07 PM
Edited by
TomArrow
Reason for edit
None provided

Just a few notes about the (hypothetical) sharing of lossless masters, if it’s of interest to anybody:

  • crf 0 is the wrong way to do lossless x264 afaik, the correct way is -qp 0 (as crf is conceived to achieve variable bitrate with varying qp (quantization parameter) across blocks/frames. QP explicitly sets it to 0 globally.

  • x264 only encodes YUV values. A conversion from RGB will automatically lead to rounding loss and thus not be 100% lossless anymore (but still good enough practically). ProRes also works in YUV.

  • x264 by default encodes in 4:2:0. Compare to RGB, which naturally is 4:4:4. So you automatically lose half the color information. The solution is to encode in the 4:4:4 mode of x264, which has to be explicitly stated.

  • Normal x264 only has 8 bits, whereas ProRes has 10 bits (or even more with a proper Apple ProRes encoder). For sharing a master for proper color correction work, a higher bit depth would be highly beneficial. This can be achieved with the 10-bit version of x264.

  • Lagarith as well as normal lossless AVIs only support 8 bits as well, therefore are not useful for sharing lossless masters, especially not if further color work is to be done.

  • Lagarith has 3 modes afaik: RGB, RGBA and YV12. YV12 is a 4:2:0 mode and tends to produce significantly smaller files than RGB. RGBA includes alpha channel, should be irrelevant for most cases. RGB is default. The mode can be changed in the codec settings (for example in VirtualDub when selecting Lagarith).

  • x264 is a DCT-based codec, so everything always gets converted into the frequency domain on a per-block basis, which of course can introduce rounding errors in theory, especially at 8 bit. It’s possible they have ways to avoid this, but it’s something to keep in mind. Same applies to ProRes by the way, also DCT-based; but ProRes is not meant to be lossless to begin with, so that’s okay.

  • ProRes, unless you use the 4:4:4 mode, also is 4:2:2 and thus not ideal for anything that will require further color work imo.

  • Currently the only way (known to me) to have a truly lossless master with high bit depth is an RGB 16-bit TIFF/PNG/(some other formats) sequence or some exotic AVI codecs that support higher bit depths, but aren’t widely supported or maintained.

Of course it’s still possible that x264 it’s not 100% lossless, because it was never really made for it and who knows what it does to the signal behind the scenes, but some people have evidently achieved losslessness in x264, see here: https://stackoverflow.com/questions/6701805/h264-lossless-coding

Either way, it’s certainly good enough, if you use the 10-bit version, in addition to qp 0 and 4:4:4 color setting. But at that point the bitrates will quite likely even exceed those of ProRes (as I believe ProRes in High profile has the equivalent of qp=4 if I’m not mistaken, at least that’s what ffmpeg shows), and come at the cost of being several times more inefficient than ProRes when it comes to editing. Most editing software doesn’t even support importing x264 10 bit, so you would have to convert it back to ProRes or the likes anyway in order to edit it.

With that said, I think that if you drop the strict “lossless” requirement, we could share very high quality masters (comparable to ProRes) suitable for color grading & VFX if we just set the qp to values above 0. Again, with 10 bit x264 in 4:4:4 mode. As a starting value, I would probably try qp 4, but maybe it’s possible to go even higher. To test the quality of the result, you’ll need to do 16 bit screenshots (as PNG/TIFF don’t support 10bit), for example using AviSynth+ & VirtualDub, and then I typically load that stuff into Photoshop and play with the Levels to blow up dark areas to see if any artifacts become noticeable.

I think this way there could be a notable size improvement over ProRes, which would help with transferring. The recipient could convert back to ProRes then for his own work.