High 4:4:4 Predictive@L4 vs. High@L4 4:2:0, for archival purposes

[abolibibelot]

I would like to make good quality lossy compressions of lossless intermediate files used for a now completed movie, for reference / archival purposes, before removing the lossless files. Those files were exported as Lagarith / AVI after various pre-processing treatments in Avisynth followed by a YUV to RGB conversion (as I discovered that the Magix NLE software imported lossless AVI files with the wrong colorspace conversion matrix), and for some of them yet another step of stabilization with Deshaker (which requires RGB input).
If I compress those files as-is, with this script :

ffmpeg -i "[Lagarith source].avi" -c:v libx264 -preset slower -crf 20 "[output].mp4"

the resulting files according to MediaInfo are in “High 4:4:4 Predictive@L4” profile and “4:4:4” chroma subsampling.
If I run the compression from an Avisynth script with a RGB to YV12 conversion, the profile of the resulting files is reported as “High@L4” and the chroma subsampling is 4:2:0 which is more standard / typical for a lossy MP4 file. But in this particular case, would it make sense to do a direct conversion ? Does the 4:4:4 conversion more reliably reproduce the original content than the 4:2:0 counterpart, even though the source files (M2TS) were 4:2:0 to begin with ? Also, strangely, the size of the 4:4:4 MP4 files seems to be consistently inferior to that of the 4:2:0 MP4 encoded with the exact same settings. (Below MediaInfo report for two compressions of the same lossless export from the NLE of an earlier version of the complete movie ; the 4:4:4 one has a size of 1.98GB, the 4:2:0 one has a size of 2.08GB.) Is it to be expected, and why ?

– direct compression :

Général
Nom complet                              : F:\20151224 (export 20171231 sans traitement) [x264 crf=20 slower] {compression directe, sous-échantillonnage 4;4;4, pourtant taille inférieure}.mp4
Format                                   : MPEG-4
Profil du format                         : Base Media
Identifiant du codec                     : isom (isom/iso2/avc1/mp41)
Taille du fichier                        : 1,99 Gio
Durée                                    : 1 h 23 min
Débit global moyen                       : 3 424 kb/s
Application utilisée                     : Lavf58.19.102

Vidéo
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Profil du format                         : High 4:4:4 Predictive@L4
Paramètres du format                     : CABAC / 8 Ref Frames
Paramètres du format, CABAC              : Oui
Paramètres du format, RefFrames          : 8 images
Identifiant du codec                     : avc1
Identifiant du codec/Info                : Advanced Video Coding
Durée                                    : 1 h 23 min
Débit                                    : 3 229 kb/s
Largeur                                  : 1 280 pixels
Hauteur                                  : 720 pixels
Format à l'écran                         : 16/9
Type d'images/s                          : Constant
Images par seconde                       : 29,970 (30000/1001) Im/s
Sous-échantillonnage de la chrominance   : 4:4:4
Profondeur des couleurs                  : 8 bits
Type de balayage                         : Progressif
Bits/(Pixel*Image)                       : 0.117
Taille du flux                           : 1,87 Gio (94%)
Bibliothèque utilisée                    : x264 core 157 r2935 545de2f
Paramètres d'encodage                    : cabac=1 / ref=8 / deblock=1:0:0 / analyse=0x1:0x131 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=4 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Codec configuration box                  : avcC

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Identifiant du codec                     : mp4a-40-2
Durée                                    : 1 h 23 min
Type de débit                            : Constant
Débit                                    : 186 kb/s
Canaux                                   : 2 canaux
Channel layout                           : L R
Echantillonnage                          : 48,0 kHz
Images par seconde                       : 46,875 Im/s (1024 SPF)
Mode de compression                      : Avec perte
Taille du flux                           : 110 Mio (5%)
Default                                  : Oui
AlternateGroup/String                    : 1

– compression from Avisynth script with YV12 conversion

Général
Nom complet                              : F:\20151224 (export 20171231 sans traitement) [x264 crf=20 slower] {script Avisynth conversion YV12 Rec709}.mp4
Format                                   : MPEG-4
Profil du format                         : Base Media
Identifiant du codec                     : isom (isom/iso2/avc1/mp41)
Taille du fichier                        : 2,08 Gio
Durée                                    : 1 h 23 min
Débit global moyen                       : 3 595 kb/s
Application utilisée                     : Lavf58.19.102

Vidéo
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Profil du format                         : High@L4
Paramètres du format                     : CABAC / 8 Ref Frames
Paramètres du format, CABAC              : Oui
Paramètres du format, RefFrames          : 8 images
Identifiant du codec                     : avc1
Identifiant du codec/Info                : Advanced Video Coding
Durée                                    : 1 h 23 min
Débit                                    : 3 400 kb/s
Largeur                                  : 1 280 pixels
Hauteur                                  : 720 pixels
Format à l'écran                         : 16/9
Type d'images/s                          : Constant
Images par seconde                       : 29,970 (30000/1001) Im/s
Espace de couleurs                       : YUV
Sous-échantillonnage de la chrominance   : 4:2:0
Profondeur des couleurs                  : 8 bits
Type de balayage                         : Progressif
Bits/(Pixel*Image)                       : 0.123
Taille du flux                           : 1,97 Gio (95%)
Bibliothèque utilisée                    : x264 core 157 r2935 545de2f
Paramètres d'encodage                    : cabac=1 / ref=8 / deblock=1:0:0 / analyse=0x3:0x133 / me=umh / subme=9 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=2 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=20.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00
Codec configuration box                  : avcC

Audio
ID                                       : 2
Format                                   : AAC LC
Format/Info                              : Advanced Audio Codec Low Complexity
Identifiant du codec                     : mp4a-40-2
Durée                                    : 1 h 23 min
Type de débit                            : Constant
Débit                                    : 186 kb/s
Canaux                                   : 2 canaux
Channel layout                           : L R
Echantillonnage                          : 48,0 kHz
Images par seconde                       : 46,875 Im/s (1024 SPF)
Mode de compression                      : Avec perte
Taille du flux                           : 110 Mio (5%)
Default                                  : Oui
AlternateGroup/String                    : 1

[babygdav]

You have several things going on.
1. YU12 vs RGB
https://en.wikipedia.org/wiki/YUV#Y%E2%80%B2UV420p_(and_Y%E2%80%B2V12_or_YV12)_to_RGB888_conversion
YU12 is a 12-bit per pixel format
RGB is 8-bit per pixel

Without thinking too much, 12 bits > 8 bits, so naturally, more information is stored in YU12 format than RGB.
Specifically, "the range of colors and brightnesses (known as the color gamut) of RGB (whether it be BT.601 or Rec.709) is far smaller than the range of colors and brightnesses allowed by Y′UV."

Part of what you are noticing comes from this difference in image quality.

For the encode, it says YUV 8-bit. It's probably converting 12-bits down to 8-bits for output - but I'm not an expert on ffmpeg internals.

2. CRF
https://trac.ffmpeg.org/wiki/Encode/H.264
You're not using CRF 0 = lossless, but instead, a lossy number of 20.
ffmpeg says "Consider 17 or 18 to be visually lossless or nearly so; it should look the same or nearly the same as the input but it isn't technically lossless."

So you are using a CRF that isn't visually lossless despite being in lossy encode mode.

3. Input format
If you're inputting RGB lossless video into ffmpeg, you'll need to adjust settings.
https://trac.ffmpeg.org/wiki/Encode/H.264 "Why doesn't my lossless output look lossless?
If your input files are RGB, it's the RGB to YUV color space conversion. Use -c:v libx264rgb instead."

https://ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb
"The libx264rgb encoder is the same as libx264, except it accepts packed RGB pixel formats as input instead of YUV."

This suggests that if you feed the encoder RGB video and don't set settings correctly, it'll do an unnecessary YUV conversion internally.

4. BITS allocated.
In both, you only have 8-bits allocated to describe either 4:4:4 rgb or 4:2:0 yuv.
4:2:0 has far less color information to encode than 4:4:4, so it needs fewer bits to encode nicely.
if you force 4:4:4 (crf) to use the similar amount of bits to encode much more color info, it can't do a good job.

https://www.headendinfo.com/chroma-subsampling-video-compression/
4:2:0 is about 1/2 the color info of 4:4:4, so to get the same visual quality in an encode, the 4:4:4 needs about twice the bits (twice the file size) to properly do it.

Both your files are about the same size (crf), so that's a BIG reason. Change the CRF for the 4:4:4 to give it about double the file size.

[sneaker]

3. Input format
If you're inputting RGB lossless video into ffmpeg, you'll need to adjust settings.
https://trac.ffmpeg.org/wiki/Encode/H.264 "Why doesn't my lossless output look lossless?
If your input files are RGB, it's the RGB to YUV color space conversion. Use -c:v libx264rgb instead."

https://ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb
"The libx264rgb encoder is the same as libx264, except it accepts packed RGB pixel formats as input instead of YUV."

This suggests that if you feed the encoder RGB video and don't set settings correctly, it'll do an unnecessary YUV conversion internally.

IIRC x264 encodes YUV more efficiently than RGB so it can still make sense to convert RGB->YUV before feeding it to x264.

4. BITS allocated.
In both, you only have 8-bits allocated to describe either 4:4:4 rgb or 4:2:0 yuv.
4:2:0 has far less color information to encode than 4:4:4, so it needs fewer bits to encode nicely.
if you force 4:4:4 (crf) to use the similar amount of bits to encode much more color info, it can't do a good job.

https://www.headendinfo.com/chroma-subsampling-video-compression/
4:2:0 is about 1/2 the color info of 4:4:4, so to get the same visual quality in an encode, the 4:4:4 needs about twice the bits (twice the file size) to properly do it.

This is actually not true. Converting 4:4:4->4:2:0 is a very dumb/simple form of compression. x264 can achieve a nicer result encoding 4:4:4 since H.264 has much more advanced tools than "only-keep-every-4th-chroma-pixel-compression". (Why exactly the file size with same CRF is a bit lower is a different question. Be careful not to regard CRF as an absolute and perfect measure for visual quality.)

[babygdav]

https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Hardware-Based-Tra...aspx?pageNum=2
http://www.x264.nl/x264/10bit_03-422_10_bit_pristine_video_quality.pdf

Also, keep in mind you are encoding to 8-BIT video, instead of 10-bits or better.

10-bit FFMPEG binaries can output 10-bit H.264 to give you even better quality - see examples above.
10-bit x.265/Intel Quicksync/Nvidia NVENC H.265 encodes can instantly give you much better encodes at the same bitrate versus H.264, so for a lossy archival format, you may wish to encode to H.265 given the benefits of the native 10-bit support for the format as well as the more modern, better codec.

...

https://www.avid.com/products/avid-high-resolution-workflows

Keep in mind for the LONG term, the one codec that is nearly UNIVERSAL across all broadcast and major motion picture companies is Avid's DNxHD/DNxHR format given that almost all broadcast TV stations and all major Hollywood motion picture companies use Avid Media Composer etc for editing.
It's been around forever, was designed exactly as a high-quality proxy for the RAW video files, and will never really vanish given how entrenched Avid is in this industry.
0 tweaking is needed on your part - simply open the original video in Avid, export to DNxHD/HR to get excellent lossy conversions.
https://www.avid.com/products/avid-high-resolution-workflows

Or ffmpeg
http://macilatthefront.blogspot.com/2018/12/tutorial-using-ffmpeg-for-dnxhddnxhr.html?m=1

For example -
ffmpeg -i "inputvideo.mp4" -c:v dnxhd -profile:v dnxhr_444 -pix_fmt rgb24 -c:a pcm_s16le "outputvideo.mxf"
....

"Those files were exported as Lagarith / AVI after various pre-processing treatments in Avisynth followed by a YUV to RGB conversion"
This step prior to the final lossy file conversion immediately introduces a lossy step - color space conversion.
Thus, your final video will have at least 2 lossy conversion steps.
The stabilization may add another.

Really should be kept in RAW/original format in the video editing software all the way through editing, effects, stabilization, before output to final lossy format - this keeps the conversion steps to 1 because most modern video editing software won't touch the original until final output.

Avid Media Composer First and Blackmagic DaVinci are two free, top video editing programs to look into for future projects to avoid all this independent conversion and processing.

[abolibibelot]

@babygdav

YU12 vs RGB

I said YV12, so what follows must be moot. Or I'm still completely confused on that matter. Or you're confused. Or both. (Anyway, the world is a ball of confusion today.)

You're not using CRF 0 = lossless, but instead, a lossy number of 20.
ffmpeg says "Consider 17 or 18 to be visually lossless or nearly so; it should look the same or nearly the same as the input but it isn't technically lossless."
So you are using a CRF that isn't visually lossless despite being in lossy encode mode.

Well, as I understand it, it's a matter of degree, not a stark distinction between a given value producing "visually lossless or nearly so" and the next one producing a noticeable quality loss. Many people wouldn't see any difference between a -crf 28 and the original (hence the popularity of LOFY movie encodes). The -crf 20 setting is often recommended here as a good quality / size compromise. If I wanted lossless, I would just keep the Lagarith files (or convert them to FFV1 which is supposedly the most efficient), but considering that there's 200 to 300GB of those files, and that, if I ever want to re-work on this movie at some point I'll have to re-render them anyway, there's little point in hoarding it all. But it could still be useful to have a reference for the intensive frame interpolation and color/levels correction I had to make. (Of course I'll keep the original scripts, but as I noticed recently there can be surprises when doing using the same very simple script on the same computer with a different version of Avisynth, so there could be other discrepancies if using a much more complex script on a different computer running on a different operating system with different drivers or whatever...)

If you're inputting RGB lossless video into ffmpeg, you'll need to adjust settings.
https://trac.ffmpeg.org/wiki/Encode/H.264 "Why doesn't my lossless output look lossless?
If your input files are RGB, it's the RGB to YUV color space conversion. Use -c:v libx264rgb instead."
https://ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb
"The libx264rgb encoder is the same as libx264, except it accepts packed RGB pixel formats as input instead of YUV."
This suggests that if you feed the encoder RGB video and don't set settings correctly, it'll do an unnecessary YUV conversion internally.

Alright, now that's interesting. So what I got when compressing directly is 4:4:4 YUV, produced by an automatic conversion by ffmpeg. And so, in this particular case, to stay as close as possible to the original files, libx264rgb would be preferred, I suppose.

4. BITS allocated.
In both, you only have 8-bits allocated to describe either 4:4:4 rgb or 4:2:0 yuv.
4:2:0 has far less color information to encode than 4:4:4, so it needs fewer bits to encode nicely.
if you force 4:4:4 (crf) to use the similar amount of bits to encode much more color info, it can't do a good job.
https://www.headendinfo.com/chroma-subsampling-video-compression/
4:2:0 is about 1/2 the color info of 4:4:4, so to get the same visual quality in an encode, the 4:4:4 needs about twice the bits (twice the file size) to properly do it.
Both your files are about the same size (crf), so that's a BIG reason. Change the CRF for the 4:4:4 to give it about double the file size.

That's interesting too, but in this case the 4:4:4 files are significantly smaller. Why would it be, if the bitrate is more constrained according to the above explanation ?

@sneaker

IIRC x264 encodes YUV more efficiently than RGB so it can still make sense to convert RGB->YUV before feeding it to x264.

Alright, so it should be done with Avisynth, or can ffmpeg do it reliably with an extra command switch ? Or is indeed preferred in this specific case to use libx264rgb ?

This is actually not true. Converting 4:4:4->4:2:0 is a very dumb/simple form of compression. x264 can achieve a nicer result encoding 4:4:4 since H.264 has much more advanced tools than "only-keep-every-4th-chroma-pixel-compression".

So in this case, for approximately the same bitrate, you would say that it's better to keep the input as RGB ?

(Why exactly the file size with same CRF is a bit lower is a different question. Be careful not to regard CRF as an absolute and perfect measure for visual quality.)

And how would you answer to that different question ? It may not be absolute and perfect, but it's supposedly tuned to be approximately consistent.

@babygdav

Also, keep in mind you are encoding to 8-BIT video, instead of 10-bits or better.
10-bit FFMPEG binaries can output 10-bit H.264 to give you even better quality - see examples above.
10-bit x.265/Intel Quicksync/Nvidia NVENC H.265 encodes can instantly give you much better encodes at the same bitrate versus H.264, so for a lossy archival format, you may wish to encode to H.265 given the benefits of the native 10-bit support for the format as well as the more modern, better codec.

So, would it make sense to encode 8-bit video into 10-bit H.264 ?
I haven't tested x265 yet. With a machine based on an Intel i7 6700K CPU and 16GB or RAM, encoding with x264 (or ffmpeg / libx264) in 1280x720 is done at about 1x or 29FPS. From what I could gather x265 would be much slower with similar settings, like 3-5FPS. Is the incremental improvement worth the compounded trouble ?

Keep in mind for the LONG term, the one codec that is nearly UNIVERSAL across all broadcast and major motion picture companies is Avid's DNxHD/DNxHR format given that almost all broadcast TV stations and all major Hollywood motion picture companies use Avid Media Composer etc for editing.
It's been around forever, was designed exactly as a high-quality proxy for the RAW video files, and will never really vanish given how entrenched Avid is in this industry.
0 tweaking is needed on your part - simply open the original video in Avid, export to DNxHD/HR to get excellent lossy conversions. [...] Or ffmpeg

What is the typical compression ratio between an efficient lossless codec like Lagarith and DNxHD ?

"Those files were exported as Lagarith / AVI after various pre-processing treatments in Avisynth followed by a YUV to RGB conversion"
This step prior to the final lossy file conversion immediately introduces a lossy step - color space conversion.
Thus, your final video will have at least 2 lossy conversion steps.
The stabilization may add another.
Really should be kept in RAW/original format in the video editing software all the way through editing, effects, stabilization, before output to final lossy format - this keeps the conversion steps to 1 because most modern video editing software won't touch the original until final output.

I did think it through and tried to preserve the original quality (which wasn't great to begin with) as much as possible. From what I could gather, most non-linear editors import everything as RGB anyway (as they work in RGB internally), what I realized is that for lossless YUV files the one I'm using imported them with the wrong color conversion matrix, so the workaround was to do the conversion in Avisynth, with the proper setting. I did the stabilization in between, in VirtualDub2, normally this was a lossless RGB => RGB processing (at first I did the stabilization within the NLE, it was mostly good, with the advantage that it could be adjusted on-the-fly, but in some parts it got confused by large and highly contrasted moving objects AKA people with dark clothes, and it randomly left thin black borders which I couldn't get rid of ; the Mercalli plugin didn't have that bug but I found its treatment less consistent than that of the native Magix stabilizer module ; I also tried DepanStabilize which would have worked in YUV but the result was clearly inferior). Then the complete movie was rendered as Lagarith RGB, and I did further processing in Avisynth, after a RGB to YUV conversion, which, unless I'm mistaken, was only the second colorspace conversion, and the last one before the final encode. I don't see how it could have been done with fewer colorspace conversion steps, or how any advanced editing can be done with fewer colorspace conversion steps for that matter (unless using an editor which can work in YUV internally but I don't know of any). And it's certainly better than doing all the intermediate rendering in lossy format, isn't it ? Also, there's probably no equivalent in full-fledged video editors to mvtools based interpolation functions which were badly needed here to improve the original footage (unless perhaps in some high-end specialized restoration suites with three zeros on their price tag).

Avid Media Composer First and Blackmagic DaVinci are two free, top video editing programs to look into for future projects to avoid all this independent conversion and processing.

I tried DaVinci Resolve at some point, as it was recommended for color correction processing, but didn't go very far — it seems to have a hell of a learning curve, so it seemed way overkill to go that route and start all over again, while the preliminary results were not that great compared with what I could achieve with HDRAGC and a few other Avisynth filters (tried to RTFM but the FM was more than 1000 pages long IIRC which was a PITA so I was kinda SOL). But I'll think about it next time I need to do some serious work starting from scratch.

[babygdav]

YU12 my typo.
Meant YUV12 = YV12 = YUV....
https://en.m.wikipedia.org/wiki/YUV

..

https://software.intel.com/en-us/articles/evolution-of-hardware-hevc-encode-on-tenth-g...ore-processors
10th gen Intel CPU Quicksync hardware h.264/h.265 encoding is now on par with software encoders and far faster (easily 100-300+ fps 2K h.265 encodes).

...

4:4:4 etc means color info per pixel.

With a Fixed bitrate encode, the encoder will assign the necessary bits to the color info, taking it away from the image info (think details - the encode will use less bits, picture looks softer and less detailed).

At a Fixed bitrate:
Increase color info, detail suffers.
Decrease color info, detail improves.

...

Davinci, Premiere, etc - to learn quickly and easily, videos.
E.g. https://www.lynda.com/DaVinci-Resolve-tutorials/DaVinci-Resolve-Guru-Color-Correcting-.../499489-2.html

But, what's done is done.

...

Dnxhd - about 5:1. 1TB of raw video takes up 200GB~ in DNxHD (using one of the higher quality settings).

Type. ..... Compression Ratio
DNxHR 444 DNxHR 4:4:4 12 RGB / 4:4:4 4.5:1
DNxHR HQX DNxHR High Quality (12 bit) 12 4:2:2 5.5:1
DNxHR HQ DNxHR High Quality (8 bit) 8 4:2:2 4.5:1

...

10-bit encodes.
https://av.community/guides/10-bit-h264/
Yes, color encoding and editing benefits greatly later on.

...

http://www.compression.ru/video/codec_comparison/pdf/lossless_codecs_test_en.pdf
Lagarith 2-3x compression vs 5~ for dnxhd 444

But, http://www.digitalfaq.com/forum/video-workflows/8202-warning-lagarith.html
http://mod16.org/hurfdurf/?p=142

Like the numerous codecs tested by compression.ru, none are industry standards, no real support, so any video read/encode problems you encounter are not going to be resolved since it's a community effort deriving from huffyuv.

On the other hand, DNxHD is a broadcast smtpe standard, so it's extremely well supported, bug free, depended upon for years by the broadcast industry and Hollywood.

10, 30, 50+ years from now, it's easy to predict which codec will be around and supported, and which will not (e.g.. Pray you can even install a Lagarith codec on Windows 2050 to open your encodes).

...

Top end video editing software used for broadcast/commercial work all do it in yuv internally.

Avid, edius, davinci, Premiere, etc...

They will maintain full 4:4:4 etc yuv per original all the way through editing until final output. They will do on the fly encoding to rgb for the monitor, but won't change the yuv original in doing this.

...

Yuv / rgb conversions always results in image quality degradation.
https://discoverybiz.net/enu0/faq/faq_YUVbyBreeze_test_00.html

4:4:4 color space is critical to maintaining the best image quality, else, expect bad image quality after a few conversions. Even then, don't expect miracles with yuv / rgb conversions - you'll always degrade the image.

[abolibibelot]

YU12 my typo.
Meant YUV12 = YV12 = YUV....
https://en.m.wikipedia.org/wiki/YUV

So it's still 8-bit, right ?

10th gen Intel CPU Quicksync hardware h.264/h.265 encoding is now on par with software encoders and far faster (easily 100-300+ fps 2K h.265 encodes).

But what about what I have ? (Which must be considered as 6th or 7th generation, not sure.)

4:4:4 etc means color info per pixel.
With a Fixed bitrate encode, the encoder will assign the necessary bits to the color info, taking it away from the image info (think details - the encode will use less bits, picture looks softer and less detailed). At a Fixed bitrate:
Increase color info, detail suffers.
Decrease color info, detail improves.

But in this case, since the source was 4:2:0 to begin with, is there really that much more color information in an intermediate RGB export ?

Dnxhd - about 5:1. 1TB of raw video takes up 200GB~ in DNxHD (using one of the higher quality settings).

Alright, so that's very large for a non-lossless compression.

10-bit encodes.
https://av.community/guides/10-bit-h264/
Yes, color encoding and editing benefits greatly later on.

Would you say that it is akin to editing 16-bit audio in 32-bit float ?
By the way, totally unrelated, I discovered recently that the APE codec, which I use to archive WAV files (more efficient than FLAC, 100% bit-perfect lossless, preserves timestamps), was totally inefficient with 32-bit float input : a 746MB WAV file (created to test ffmpeg's internal Dynamic Audio Normalizer filter suggested on this thread which I found while trying to fix an audio issue for that same movie) was compressed as a 755MB APE file, hence larger than the source ! While 7-Zip compressed it to 620MB (LZMA2 "Max" & 64MB dictionary) and WinRAR to 598MB (RAR5 "Good" 128MB dictionary). That's quite puzzling.

http://www.compression.ru/video/codec_comparison/pdf/lossless_codecs_test_en.pdf
Lagarith 2-3x compression vs 5~ for dnxhd 444

But then again Lagarith is 100% lossless...

Like the numerous codecs tested by compression.ru, none are industry standards, no real support, so any video read/encode problems you encounter are not going to be resolved since it's a community effort deriving from huffyuv. On the other hand, DNxHD is a broadcast smtpe standard, so it's extremely well supported, bug free, depended upon for years by the broadcast industry and Hollywood.

So is there at least one lossless codec that is widely supported and fully compliant with industry standards ?

10, 30, 50+ years from now, it's easy to predict which codec will be around and supported, and which will not (e.g.. Pray you can even install a Lagarith codec on Windows 2050 to open your encodes).

Well, it's quite optimistic to think that 30-50+ years from now we'll 1) still be alive 2) still have the luxury to care about video codecs intricacies !
When kids are already jumping out of windows out of sheer hopelessness for the future of humanity...

Top end video editing software used for broadcast/commercial work all do it in yuv internally.
Avid, edius, davinci, Premiere, etc...
They will maintain full 4:4:4 etc yuv per original all the way through editing until final output. They will do on the fly encoding to rgb for the monitor, but won't change the yuv original in doing this.

Alright then... I'll think about it when I have a top-end wallet.

Yuv / rgb conversions always results in image quality degradation.
https://discoverybiz.net/enu0/faq/faq_YUVbyBreeze_test_00.html

That much I do know by now.

4:4:4 color space is critical to maintaining the best image quality, else, expect bad image quality after a few conversions. Even then, don't expect miracles with yuv / rgb conversions - you'll always degrade the image.

It's critical even with 4:2:0 source footage ?

[babygdav]

Rgb uncompressed is 8 bits per color, r, g, and b for a total of 24-bits per pixel.

Yuv is a different way of representing colors, so more complex:
https://en.m.wikipedia.org/wiki/YUV
Yuv 444 is 8 bits per y, u, v

But yv12 is yuv 420
YUV444 3 bytes per pixel (12 bytes per 4 pixels)
YUV422 4 bytes per 2 pixels (8 bytes per 4 pixels)
YUV411 6 bytes per 4 pixels
YUV420 6 bytes per 4 pixels, reordered

...

6/7th gen Quicksync is still very good, but not as good as the 10th gen for h.264.
https://en.m.wikipedia.org/wiki/Intel_Quick_Sync_Video
No h.265 Quicksync encoding though.

...

https://en.m.wikipedia.org/wiki/YUV
Yuv to rgb conversion requires mathematical conversions that result in floating point values. Rounding off in 10 bit rgb is more accurate than in 8 bit, similar to why audio editors are using 24, 32 bit consoles even though the end output is 8 bit aac/mp3.

....

Lossless codec.
It's complicated, but getting better.
https://www.premiumbeat.com/blog/history-raw-video-footage
History had a bunch in use.

https://www.archives.gov/preservation/products/products/mpd-p1.html
Hollywood and the National Archives standardized on the DPX file format, an industry standard for lossless video.

https://wolfcrow.com/what-is-aces-academy-color-encoding-system/
Very recently, to handle hdr, 8k, and complex color and effects work, a new Academy of Arts standard was created.

...

Realistically, raw from a camera comes in many different formats - Alexa, red, Canon, etc etc.

Most movie companies keep the original for archiving.
They usually ingest into the video editor and have everything converted into 1 standard (can vary depending on the company). DNxHD (broadcast, tv - faster), openexr under aces workflow (motion pictures https://blog.frame.io/2019/09/09/aces/).

Then edit from there until final output.
Archiving includes all the files used in the edit + original camera raw masters.

If you discard the camera raw masters, the dnxhd/openexr files are generally sufficient and equivalent to the originals to recreate the final render and for reediting.

....

But this is talking about 100+TB movie projects where money for hard drives of that size isn't any issue...

For home users, the very minor compression of any consumer lossless codec vs dnxhd is nearly insignificant and undetectable, so the better compression, editability, and long term compatibility is worth it.

That said, if you're not going to be around 2050, no point worrying too much about the codec - as long as you have 1 Windows 10 pc working, you can convert from what you use now to any other more modern format before the codec support disappears. (I'd still convert to dnxhd, but really up to you.)

...

4:4:4 color space of the video files is important even with 4:2:0 sources if you're converting from yuv to rgb, again because of the math used inn the yuv to rgb conversion, round off errors, and such.

If you were keeping everything in the original yuv source and adding all edits, stabilization, effects in 1 video editing program, no need to worry because it'll only apply everything at once during the final render. But pushing video through many programs, always best to use 4:4:4.

In any case, if you use anything less, it'll still be upsampled to 444 internally by most top video editing programs.

...

Avid Media Composer First and Blackmagic Davinci are 100% free for home use.
https://www.avid.com/media-composer
https://www.blackmagicdesign.com/products/davinciresolve

[abolibibelot]

So I made a compression of a similar file as the one mentioned in the first post (this time it's the most recent export of the completed movie) with libx264rgb, all else being equal, and the size of the resulting file is about three times as high as that of the YUV compressions : 6.36GB (RGB) vs. 2.13GB (YUV 4:4:4) vs. 2.06GB (YUV 4:2:0). While the encoding time was about twice as high : 0.448-0.547x for a total of 3h02m32s (RGB), 0.678-0.821x for a total of 2h00m44s (YUV 4:4:4), 0.923-1.11x for a total of 1h28m50s (YUV 4:2:0).
Is this to be expected ? According to what you wrote, shouldn't there be as much information in RGB and in YUV 4:4:4 ? And why would it be so much slower to encode ?

That said, if you're not going to be around 2050, no point worrying too much about the codec - as long as you have 1 Windows 10 pc working, you can convert from what you use now to any other more modern format before the codec support disappears. (I'd still convert to dnxhd, but really up to you.)

I don't even have one Windows 10 PC working now — still using 7 here... (And I know that some respectable individuals on this forum are still sticking with XP, stubbornly bent on sticking with it for the decades to come ! )
I don't know if I am going to be around come 2050, but certainly if I am going to be this I is going to be very different in any way, shape or form from what it currently is — and it is currently barely being at all. What is going to be relevant to that hypothetical 50-years-from-now-I is another question. I couldn't even ascertain that the movie in question is relevant to anyone now (except one aunt who got very emotional watching it on January 1st, but that aunt doesn't even have a computer or anything that can play the damn thing), even for myself (even if some parts could have moved me somewhat originally, the very fact of working for so long on a movie with supposedly personal connections inevitably ends up destroying any remnants of emotion attached to it, or the people involved), except for the fact that it had to be completed.

6/7th gen Quicksync is still very good, but not as good as the 10th gen for h.264.
https://en.m.wikipedia.org/wiki/Intel_Quick_Sync_Video
No h.265 Quicksync encoding though.

So, to benefit from this I would have to replace both the CPU and the MB ?

But this is talking about 100+TB movie projects where money for hard drives of that size isn't any issue...

Impressive... do you know what kind of storage device is being used for those humongous projects ?

[babygdav]

Rgb bigger than yuv
Without knowing exactly what's the conversion process and command into each format, who knows why one is much bigger. Could be as simple as yuv using standard 8-bit per yuv = 24-bits total vs rgb using 24bits per rgb, instantly tripling the size.

...

All major motion pictures made by Hollywood making over $500 million are all edited on Avid.

Avid not only does broadcast tv, but major films, too, so it needs a solution for all that footage.

https://www.avid.com/products/avid-nexis

Whether you call it a NAS or SAN, a bunch of hard drives in a box that is smart enough to make backups and prevent data loss on its own.

For home users, they'd use raid drives, nas (syno lo ogy, qnap, etc), Windows storage spaces (https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/overview), etc.

Not rocket science, but everyone runs to Avid in Hollywood because it just works.

...

If you wanted to benefit from far faster h.265 encodes,
Either replace cpu and mb with a recent Intel combo to access Quicksync,

Or install a new gpu card like a Nvidia 1050 ti or better that does faster encodes through the gpu. (Cheap - $100+)

...

The slower encodes suggest two things - cpu and drive are bottlenecks.

[abolibibelot]

Rgb bigger than yuv
Without knowing exactly what's the conversion process and command into each format, who knows why one is much bigger. Could be as simple as yuv using standard 8-bit per yuv = 24-bits total vs rgb using 24bits per rgb, instantly tripling the size.

Again, with the same Lagarith/AVI file as input, one encode was made directly with libx264 (resulting in the "4:4:4" chroma subsampling), another was made from an Avisynth script with a single RGB to YV12 conversion (slightly larger file size than the former but significantly faster processing), then a third was made directly with libx264rgb (file size x3 and procesing time x2).

4:4:4 = ffmpeg -i "F:\input Lagarith.avi" -i "F:\input qaac.m4a" -map 0:0 -map 1:0 -c:v libx264 -crf 20 -preset slower -c:a copy "R:\output.mp4"
YV12 = ffmpeg -i "F:\input RGB to YV12.avs" -i "F:\input qaac.m4a" -map 0:0 -map 1:0 -c:v libx264 -crf 20 -preset slower -c:a copy "R:\output.mp4"
RGB = ffmpeg -i "F:\input Lagarith.avi" -i "F:\input qaac.m4a" -map 0:0 -map 1:0 -c:v libx264rgb -crf 20 -preset slower -c:a copy "R:\output.mp4"

I don't get why "24 bits per R, G, B" is triple of "24 bits per Y, U, V" (I may be completely confused on the matter). Or why a compression with a 4:4:4 conversion (made internally by ffmpeg) is smaller than a compression with a 4:2:0 conversion (made by Avisynth) whereas a compression with no conversion is much bigger than both. Logically the 4:4:4 compression should be in-between in size.

The slower encodes suggest two things - cpu and drive are bottlenecks.

Drive speed being the bottleneck is unlikely, the input file is quite large (~120GB) but the same for the three encodes, while the data throughput for H.264 encoding is very small compared with the performance of a current HDD (the input AVI file is on a 8TB HDD, the output MP4 files were written to a 4TB HDD connected in USB 3).

Or install a new gpu card like a Nvidia 1050 ti or better that does faster encodes through the gpu. (Cheap - $100+)

I currently don't even have a discreet graphic card so that would probably be the most efficient upgrade route. But is the NVidia hardware encoding just as efficient as the QuickSync encoding, in terms of quality / size / processing time ? And isn't it a bit overkill to purchase a graphic card aimed for fancy video games and advanced 3D applications, just to benefit from an ancilliary feature for video compression ? Or is it precisely because they're aimed for games, and the global sales are so huge, that they can be designed with such a tremendous processing power at a relatively low cost ?

[babygdav]

If you're using a basic 1050, 1080p h.264 encodes are easily 250+fps on medium quality encode settings.
Higher cards go faster.

https://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Hardware-Based-Tra...tors_selection

You'll have to test, but if you're not concerned about absolute smallest file size and simply set a quality target, qs and nvidia gets you nice encodes far faster.

...

Hardware encoding acceleration has been around forever.
Since Quicksync landed in Intel cpu's 8 generations ago, nvidia since at least the 960 series from 2015.
Nothing new.
People use them for many things besides games - ai, image recognition, bitcoin mining, etc - because the gpu cards are good at doing lots of repetitive calculations quick.

It's all about time vs money.
1 h.264 encode a hour? Or 4+?
You want to wait, you can even program a scientific calculator to do encodes that take a year.

...
It's possible to max out a hard drive using gpu encoding.
Let's say a 50GB bluray using gpu encodes 4x faster than real time, 30 minutes. That's 28~MB/second transfer rate.

You can easily saturate a modern, basic hard drive that has a max transfer rate of 100-150MB/sec with a few simultaneous h.264 encodes (top 2080 cards can easily push more than a dozen).

....

No idea about the time differences.
Would just chalk it up to the different encoders.

As for file size, crf is the factor - it's letting the computer pick a bitrate by magic.

The way to test encoder performance would be to lock the bitrate based on the chroma encoding.
4:4:4 yuv or rgb use a full 24-bits per pixel.
So let's say you assign a fixed video bitrate of 10,000 kbps for those encodes.

4:2:0 needs only 1/2 the bits per pixel, so let's say you set the video bitrate to 5,000 kbps.

Encode and time.

[gdgsdg123]

There's plenty of misinformation in the discussion... regardless, I'll update this post and clear things up when the time seems opportune.

[abolibibelot]

There's plenty of misinformation in the discussion... regardless, I'll update this post and clear things up when the time seems opportune.

And... when will the time seem opportune would you say ? So that I can prepare myself for that day and be ready to get enlightened in some way.

[gdgsdg123]

And... when will the time seem opportune would you say ? So that I can prepare myself for that day and be ready to get enlightened in some way.

It will be incremental. May take a relatively long time before fully finished...