H.264 is an intermediate codec (with evidence!)

Ready your pitchforks, I’m going to be controversial:
Can H.264 be used as an intermediate or even master archival codec?
(TL:DR Yes.)

Uli and Marc have repeatedly stated that H.264 is not an intermediate codec and that generational loss gives cartoonishly bad results even after only 10 generations. (ref: viewtopic.php?f=21&t=192146&sid=52b4e1a802f383efb1d5217acff07391#p1006541 and viewtopic.php?f=21&t=192146&sid=52b4e1a802f383efb1d5217acff07391#p1006556 )

In order to make my case I need to explain two very important things: CRF and QP.
The long version of the explanation is at https://slhck.info/video/2017/02/24/crf-guide.html
It’s also helpful to understand how JPEG is compressed, as the quantization matrix compression is roughly identical between H.264 and JPEG: https://en.wikipedia.org/wiki/JPEG#JPEG_codec_example
The short version is that CRF sets how much a file is compressed as a visual factor
QP sets how much a file is compressed as a mathematical factor.

Statement: H.264 is awful
Statement: H.264 deteriorates after 10 generations:
Statement: H.264 looks like an overstylized art project.
Statement: H.264 looked like a video effect filter from the eighties.

Counter statement: H.264 is lossless, both visually and mathematically.

So, who is correct?
In order to answer that, we need to read the H.264 specification:

“This Recommendation | International Standard was developed in response to the growing need for higher compression of moving pictures for various applications such as videoconferencing, digital storage media, television broadcasting, internet streaming, and communication. It is also designed to enable the use of the coded video representation in a flexible manner for a wide variety of network environments. The use of this Recommendation | International Standard allows motion video to be manipulated as a form of computer data and to be stored on various storage media, transmitted and received over existing and future networks and distributed on existing and future broadcasting channels.“

“The coded representation specified in the syntax is designed to enable a high compression capability for a desired image quality. With the exception of the transform bypass mode of operation for lossless coding in the High 4:4:4 Intra, CAVLC 4:4:4 Intra, and High 4:4:4 Predictive profiles, and the I_PCM mode of operation in all profiles, the algorithm is typically not lossless, as the exact source sample values are typically not preserved through the encoding and decoding processes.”

So, yes, H.264 can be lossless.
As proof of that, here is a video showing not 10 but 60 generations of CRF encoded video:
Yes, that is 2160p at 300%. At 3 seconds and 1 frame in, at 59.94 fps.

(source video is at https://drive.google.com/drive/folders/ ... sp=sharing along with two exports of the 2160p timeline at generation 0 and 60)

(for those playing along at home:
At https://media.xiph.org/video/av2/ download sparks_aom_5764-6024
ffmpeg -i libx264_gen0_CRF_0_faster.mov -c:v libx264 -crf 0 -preset faster libx264_gen1_CRF_0_faster.mov

Here is the short mediainfo of the generation 0 and generation 60 files:
Generation 0: Video: MPEG4 Video (H264) 4096x2160 59.94fps 1909057kbps [V: h264 high 10 L5.2, yuv420p10le, 4096x2160, 1909057 kb/s]
Generation 60: Video: MPEG4 Video (H264) 4096x2160 59.94fps 1804717kbps [V: h264 high 10 L5.2, yuv420p10le, 4096x2160, 1804717 kb/s]

Writing library : x264 core 164 r3172 c1c9931
Encoding settings : cabac=1 / ref=2 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=4 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=0 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=24 / lookahead_threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=1 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=20 / rc=crf / mbtree=1 / crf=0.0 / qcomp=0.60 / qpmin=0 / qpmax=81 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00 )

After 60 generations the file lost 5% of the bitrate which is a lot when you consider that CRF 0 should be lossless.

To see how much the file changed, I’m going to do SSIM, PSNR, MSAD, CORR and VMAF comparisons between the Gen 0 and Gen 60 CRF 0 files:
SSIM: Y:0.993719 (22.019606) U:0.992436 (21.212376) V:0.991997 (20.967383) All:0.993218 (21.686425)
PSNR y:46.574179 u:48.013342 v:47.574161 average:46.942391 min:42.924770 max:54.994300
MSAD: Y:0.002768 U:0.002454 V:0.002614 average:0.002612 min:0.001163 max:0.004453
CORR: Y:0.999781 U:0.996666 V:0.996602 average:0.997683 min:0.995516 max:0.999591
VMAF:
0.6.1: 99.9775
0.6.1-4K: 99.9906

To sum those numbers up: 99.3%, 99.995%, 99.95% and 99.97 or 99.99% similar after 60 generations

Doing the same with QP 0:
Generation 0: Video: MPEG4 Video (H264) 4096x2160 59.94fps 3952660kbps [V: h264 high 4:4:4 predictive L6.0, yuv420p10le, 4096x2160, 3952660 kb/s]
Generation 25: Video: MPEG4 Video (H264) 4096x2160 59.94fps 3952660kbps [V: h264 high 4:4:4 predictive L6.0, yuv420p10le, 4096x2160, 3952660 kb/s]
Note that I didn’t do 60 generations here, only 25.
But at a loss of 0 byte I did not see the need to continue.

So that’s the longer version from a technical standpoint:
Yes, H.264 can be used as an intermediate and master archival codec IF used properly as designed.
The above is made with x264, which gained lossless encoding 15 years ago (ref https://code.videolan.org/videolan/x264 ... a2f884a859).


With Davinci Resolve:
Sadly Davinci does not support 10 bit H.264 exports, so lossless is impossible directly from the standard Deliver settings.
However with Voukoder it is possible to use x264, which makes all the above settings possible, but only in the Studio version.

What's the Lossless file size compared to the best quality options from ProRes, DNx and Cineform?

What's the resource usage for playback of each?

What's the subjective scrubbing performance of each?

What's the Lossless file size compared to the best quality options from ProRes, DNx and Cineform?

Filesize is irrelevant in this comparison, bitrate is the important factor:
For comparison: H.264 CRF 0
Video: MPEG4 Video (H264) 4096x2160 59.94fps 1909057kbps [V: h264 high 10 L5.2, yuv420p10le, 4096x2160, 1909057 kb/s]

From Resolve:
Cineform 10 bit YUV:
Video: CFHD 4096x2160 59.94fps 2543194kbps [V: cfhd, yuv422p10le, 4096x2160, 2543194 kb/s]
Cineform 16 bit RGB:
Video: CFHD 4096x2160 59.94fps 119252kbps [V: cfhd, gbrp12le, 4096x2160, 4414219 kb/s]
DNxHR 444-10 bit:
Video: AVDH 4096x2160 59.94fps 3725927kbps [V: dnxhd dnxhr 444, yuv444p10le, 4096x2160, 3725927 kb/s]
DNxHR 444-12 bit:
Video: AVDH 4096x2160 59.94fps 3725927kbps [V: dnxhd dnxhr 444, yuv444p12le, 4096x2160, 3725927 kb/s]
DNxHR HQX 10 bit:
Video: AVDH 4096x2160 59.94fps 1863945kbps [V: dnxhd dnxhr hqx, yuv422p10le, 4096x2160, 1863945 kb/s]
DNxHR HQX 12 bit:
Video: AVDH 4096x2160 59.94fps 1863945kbps [V: dnxhd dnxhr hqx, yuv422p12le, 4096x2160, 1863945 kb/s]
(As previously stated, Resolve on windows does not support ProRes)

Making the visually lossless, generationally stable H.264 flavor less than cineform, less than DNxHR 444 and about the same as DNxHR HQX.

What's the resource usage for playback of each?

No hardware decoder can decode H.264 4:4:4, making it CPU only decode. So, high.
But for archival masters that has minimal impact.

What's the subjective scrubbing performance of each?

Minimal impact in the real world, as the goal was archival masters.

Ready your pitchforks, I’m going to be controversial:

Wouldn't that functionally be the same as pushing GIF video as an archival master? For some people it is. In life, one could do just about anything if one really wanted to.

Wouldn't that functionally be the same as pushing GIF video as an archival master? For some people it is. In life, one could do just about anything if one really wanted to.

Not really as gif doesn't support the baseline useful quality to begin with. h264 and h265 do, by spec.

It is basically the same situation as if going around telling everyone who cares to listen that prores proxy is crapshoot for compositing and archival. Sure it is, but, well, there is more to prores than its shittiest version.

What about 12-bit or 16-bit sources? x264 doesn't support these sampling.

What about 12-bit or 16-bit sources? x264 doesn't support these sampling.

It's not sampling (that's 4:2:0, 4:2:2, 4:4:4) but precision.
Because if you're limited to 10 bit (as in cineform or DNxHR), then it's a level playing field.

DNxHR can do 12 bit.

DNxHR can do 12 bit.

And? Not relevant to the discussion.

I am telling that H.264 10 bit CRF 0 and H.264 10 bit QP 0 is lossless, the other information was a courtesy, and very tangent to the main argument here.

DNxHR can do 12 bit.

And? Not relevant to the discussion.

You said "Because if you're limited to 10 bit (as in cineform or DNxHR)" which is wrong.

Several high-end sources (Arri, RED, Blackmagic) are 12 or 16 bit. So that limitation is a hudge weakness. As I explained in another thread, JPEG2000/IMF is so far the best option for lossless options.

DNxHR can do 12 bit.

And? Not relevant to the discussion.

You said "Because if you're limited to 10 bit (as in cineform or DNxHR)" which is wrong.

Several high-end sources (Arri, RED, Blackmagic) are 12 or 16 bit. So that limitation is a hudge weakness. As I explained in another thread, JPEG2000/IMF is so far the best option for lossless options.

It's not wrong. Factually DNxHR 444 is a 10 bit flavour. That the DNxHR specification also includes 12 bit flavours are not relevant to the current discussion about using H.264 as a generational lossless master archive.

Please stop bringing irrelevant information into the current thread. Thank you in advance.

Please stop bringing irrelevant information into the current thread.

Ok so nobody here shoot with Arri / RED / Blackmagic / Other codec above 10-bit

Several high-end sources (Arri, RED, Blackmagic) are 12 or 16 bit. So that limitation is a hudge weakness. As I explained in another thread, JPEG2000/IMF is so far the best option for lossless options.

None of them can produce 16bit worth of log data. 16bit linear is roughly packageable into 12bit log and 12-14 bit linear to 10bit log encoding. Is there even one single benefit of jpeg2000 compared to lets say exr?

Several high-end sources (Arri, RED, Blackmagic) are 12 or 16 bit. So that limitation is a hudge weakness. As I explained in another thread, JPEG2000/IMF is so far the best option for lossless options.

None of them can produce 16bit worth of log data. 16bit linear is roughly packageable into 12bit log and 12-14 bit linear to 10bit log encoding. Is there even one single benefit of jpeg2000 compared to lets say exr?

viewtopic.php?f=21&t=192146&start=50#p1006904

DNxHR can do 12 bit.

h.264 supports up to 14 bits with chroma sub sampling up to 4:4:4.

if you want 16 bit and 4:4:4 support you go with h.265.

DNxHR can do 12 bit.

h.264 supports up to 14 bits with chroma sub sampling up to 4:4:4.

I was talking about x264 encoder. I don't know any software that supports H.264 / 12 or 14 bit / lossless. But it might exist somewhere.

As proof of that, here is a video showing not 10 but 60 generations of CRF encoded video...

I'm assuming that the "60 generations" being bandied about here is the same video imported and re-rendered 60 times. Gen1 -> Gen2, then Gen2 -> Gen3, then Gen3 .... -> Gen 60.

I'm going to be a bit of a gadfly here and ask a question from my admittedly unknowledgeable perspective. Is that a valid test? Nobody ever needs 60 generations of the same video, what we're actually dealing with is taking source video and applying edits to it which may involve timing changes (i.e., the I-frames may not be in the same places in the source vs. rendered video), picture changes, etc.

In other words, rather than:

Source -> decode -> RAM -> encode -> Result

in real-world use you have:

Source -> decode -> RAM -> make a bunch of changes -> encode -> Result

I can appreciate how the decoded source might have very little loss when reencoded because you're essentially just running the decoding algorithm on the same data in reverse. But after changes have been made? It's not obvious to me that this would be true. And it seems to me that this would be the more important scenario for a typical workflow.

Now if we're limiting the discussion to "archival masters" then obviously we're not trying to make changes, so my comments wouldn't apply.

Filesize is irrelevant in this comparison

Well, if H.264 Lossless is gonna be 3x the size of DNx...maybe folks should know?

There is no inherent 'magic' in H.264 or H.265 (not even the black kind).
Yes, either of these can do I-frame only, higher bit depth, bit rates, chroma sampling.
But in the end, will the files be smaller than the established intermediate codecs for identical IQ?

For me, file size is not irrelevant, but that is only my personal option, of course.

Why does the 'academy' suggest EXR, BTW? (rhetorical question)

There is no inherent 'magic' in H.264 or H.265 (not even the black kind).
Yes, either of these can do I-frame only, higher bit depth, bit rates, chroma sampling.
But in the end, will the files be smaller than the established intermediate codecs for identical IQ?

For me, file size is not irrelevant, but that is only my personal option, of course.

Why does the 'academy' suggest EXR, BTW? (rhetorical question)

For multilayers support maybe? But to me, EXR are necessary only for exchanges between VFX departments and others postproduction services.

Cineform had 10bit tic flavour and 12 rgb flavour.
Anyway why use a h264 or h265 like intermediate codec which ask tons of hardware resource against DI codec if you state that size is not relevant?

Actually exist from many years h266, less space more quality, if you want. But usually when you do master you choose a good ratio between quality, space and usability in future.

Cineform, hr, ProRes give you the unique way to decode files, only one single sdk to use

h264 and more NEVER give you unique way to rebuild original data’sz I remember in past many troubles either adobe decoding of h264 from gh2/gh4/5dmk3 be cause a wrong deblocking setup that causes raining effects (every video with some setup show you vertical raining effects, if you read from different now you see different decoding).

What is your goal? You hate DI workflow and your search a different way?
We are full of different great codec but…
A good intermediate codec should give you
- compatibility like first characteristics and many good codec of past don’t give you it.
And today where you cannot more install under windows and under Mac codec, but software should support directly codec, many chooses are gone.


Inviato dal mio iPhone utilizzando Tapatalk

CF0 results in file size very large, and of course its can sustain many generation with out much quality loss. But, to intent to be use it as a intermediate codec is would be a bad choice. You will never get the same quality super smooth play back as Prores or DNxHR. Don't believe me? try this. Drop your high bitrate h.264 into the TL and play it from the beginning and then try to click the play head at different spot on the video event, see what happen, and you can never scrub the TL smooth. In the last 3 yrs, I have archived many high birate h.264 video. Here is an EX. 1hrs 17 min video, file size: 29.7GB @54.6 Mb/s I have no complain with visual generation quality loss. I now prefer ProRes LT as my archive and as an intermediate codec. Its give me 3:1 ratio file size and super smooth play back. Just a note, I got a pretty strong computer, I can edit 8K drone h264 Autel drone footage without any problem. I edit all my footage natively and export to ProResLT master for archive.

as a intermediate codec is would be a bad choice.

That's good to know, but here I think Mads was looking more at using it as a Master for conversion to delivery formats or archiving more than for continued editing.

But in that Master role, I do think File Size is the second most important factor, aside from Quality.

And I do think Bit Depth is a relevant factor for Quality.

My main question is - why? I suppose it's an interesting enough academic question, but what would be the real-world advantage to doing this? If I'm not saving any file size to speak of, and the quality isn't any better, why would I want to use h264 over ProRes?

Just because I can do something doesn't mean that I should. I can mow my lawn with a weedeater and it will work, but it's still the wrong tool for the job.

Exactly why I believe File Size is relevant, Alan.

My main question is - why? I suppose it's an interesting enough academic question, but what would be the real-world advantage to doing this? If I'm not saving any file size to speak of, and the quality isn't any better, why would I want to use h264 over ProRes?

Just because I can do something doesn't mean that I should. I can mow my lawn with a weedeater and it will work, but it's still the wrong tool for the job.

There is an advantage of H.264 being compatible across OS and applications without needing additional plugins/software. However, one can argue that DNxHR/HD comes very close to that. Not quite for ProRes, especially in the writing department.