Log in

View Full Version : AVC Intra Class 100 vs AppleProRes LT vs XDCAM-50


FranceBB
6th May 2020, 17:22
Intro:

This whole comparison started because some of my coworkers are obsessed with AppleProRes and wanted to shoot everything in ProRes. ProRes is probably the only not-so-bad thing Apple made in its own existence as a company. The adoption of Apple ProRes has been growing during the years and its use manages to retain a lot of details thanks to the 4:4:4 sampling (with additional possibility of having the alpha channel as well), the 10bit planar bit depth and its very high bitrate. As a matter of fact, it's also one of the most used codecs for cameras that shoot log, however our scenario was different: we had a program recorded in a theater far away from our studio so files had to be recorded by the cameras, sent via Aspera, downloaded by our studio, edited and encoded which was quite a challenge to do with such a huge filesize considering that we had to go on air the very next day.
For the records, we weren't recording anything special, just plain old FULL HD linear BT709 25p, so we didn't need anything particular.
Some of my colleagues proposed AppleProRes LT profile which is essentially with a bitrate as low as 75 Mbit/s, however me (and three other people) argued that having ProRes with such a low bitrate wasn't worth it and it would make more "damages" than anything 'cause not only it's a low bitrate for which such a codec isn't made for, but also because whenever it goes on air the final file has to be encoded live by our encoders in H.264 so the final fine ends up being processed by two different codecs. The point is that everybody knows that going through two different codecs like that is bad and lowers the quality, so I proposed AVC Intra Class 100. The only reason why there's XDCAM-50 in there is that some of our video-servers still like MPEG-2, so they kinda wanted me to add it to the comparison, but I knew it was going to perform poorly...


MPEG-2 and XDCAM-50

MPEG-2 is a codec based on the Discrete Cosine Transform, an excellent transform that works with real numbers (therefore it has a lower computational cost than - for instance - the Fourier Transform since the latter works with imaginary numbers), is continuous in 2π (therefore it has fewer discontinuity points than other transforms like the Fourier one). MPEG-2 will always be remembered as the "first true modern codec" in the sense that it has an implementation that played a role as a "start / beginning" of the modern conception of codecs and led to the development of many other successive codecs, however years passed and it's very old now.

In its implementation, the image is divided into 4x4 and 8x8 blocks and macroblocks and - to each one of them - is assigned a numerical value that goes from 0 to 99 after going through the transform.

The closer the value is to 0, the more it is considered important for human vision, the closer it is to 99 the less it is considered important for human vision. The samples are divided into luma and chroma and according to the sampling type (yv12, yv16, yv24) a different behavior is chosen. (Although I'm using the term "behaviour" loosely here).

This codec was very widespread back when channels were in SD, and it should have been completely replaced with the arrival of HD and FULL HD resolutions as it's not optimized for those resolutions, however, due to the reluctance of various broadcasters to switch to H.264 and due to the much higher computational cost not well supported by the hardware of the time, MPEG-2 managed to survive in some parts of the world despite the advent of HD and FULL HD.


In our test we will use the XDCAM-50 standard, which is MPEG-2 at 50 Mbit/s constant bitrate yv16, 8bit BT709 in FULL HD.



Advantages of MPEG2:

- Low computational cost



Disadvantages of MPEG2:

- Obsolete codec not optimized for resolutions above SD

- Bit depth limitations (max 8bit)

- It only supports linear color curves with BT601 and BT709 matrices

- Each encoder implementation is either single-core single-thread or very poorly optimized to scale on modern CPUs.



MPEG-4 Part 10 H.264

After the development of MPEG2 and after the development of Dvix/Xvid, H.264 was made; it's a very good codec, quite performing in terms of scalability of resources, that was based on the previous models but added many more compression tools and improved things like motion compensation (vector displacement calculations) and, in addition to the Discrete Cosine Transform, the Hadamard Transform was introduced, a very light transform that had the task of dealing with what the Discrete Cosine Transform couldn't handle efficiently enough.



Advantages of H.264


- Supports 8bit and 10bit bit depth

- It supports linear and logarithmic color curves (Linear BT601, Linear BT709, BT2020nc HLG, BT2100 PQ, Slog1-2-3, Clog1-2-3, Log-C, F-Log, V-Log).



Disadvantages of H.264

- It does not support 12bit and higher

- It's getting old and it's not optimized for resolutions higher than FULL HD.

- The division into blocks and macroblocks is limited to 4x4 and 8x8

- It scales fine on multi-core and multi-thread CPUs but it's not very good on Dual Socket configurations with many cores and threads



Note on H.265 HEVC:
The only reason why I didn't include H.265 is that, although it's a very good codec, now mature, based on DCT and other transforms, with 4x4, 8x8, 16x16, 32x32 and 64x64 blocks and macroblocks, optimized for 4K resolutions which supports up to 12bit planar, it's not supported by AVID Media Composer and AVID Interplay Access to be checked-into an AVID Workspace, therefore I couldn't include it...




AppleProRes

Unlike MPEG codecs, it is a codec designed exclusively as a mezzanine file in the sense that the benefits of its compression tools are seen only at very high bitrates and it's not suitable for final users delivery.



Advantages:

- Codec designed for broadcast

- It supports linear and logarithmic curves just like H.264



Disadvantages:


- Closed source proprietary technology with few implementations

- It does scale on multi-core and multi-thread CPUs but it's far from being optimal on non-apple OS which is what most people use since they don't wanna pay for overpriced crap branded Apple

- Free non-apple encoders only support a maximum bit depth of 10bit, just like H. 264


Type of Test

The Test is based on a series of .tiff lossless images recorded by several 4K cameras, downscaled with Lanczos to FULL HD and appended together to make the reel, which is then encoded in UTVideo 4:2:2 planar 10bit linear BT709 and used as source for this comparison. This clip will then be encoded using the three codecs examined: MPEG-2, H.264 and AppleProRes.

Due to the AVID limitation in consolidating these codecs into its system, encoding settings have been chosen in order to make them compatible with the AVID platform, in particular: XDCAM50 for MPEG-2, AVC-Intra 100 for H.264 and LT Profile for Apple ProRes.


Source:

Codec: UTVideo
Bitrate: 1750 Mbit/s
Width: 1920
Height: 1080
Display Aspect Ratio: 16:9
Frame rate mode: Constant
Frame rate: 25fps
Scan Type: Progressive
Color Space: YUV
Chroma Sampling: 4:2:2 planar
Bit Depth: 10bit
Color Range: Limited
Color Primaries: BT709
Matrix Coefficients: BT709

XDCAM Encoding:

Codec: MPEG-2
Bitrate: 50 Mbit/s
Width: 1920
height: 1080
Display Aspect Ratio: 16:9
Frame rate mode: Constant
Frame rate: 25fps
Scan Type: Interlaced TFF
Chroma Sampling: 4:2:2 planar yv16
Bit Depth: 8bit
Color Range: Limited
Color Primaries: BT709
Matrix Coefficients: BT709

AVC-Intra 100 Encoding:

Codec: MPEG-4 Part 10 H.264
Bitrate: 100 Mbit/s
Width: 1920
height: 1080
Display Aspect Ratio: 16:9
Frame rate mode: Constant
Frame rate: 25fps
Scan Type: MBAFF
Chroma Sampling: 4:2:2 planar
Bit Depth: 10bit
Color Range: Limited
Color Primaries: BT709
Matrix Coefficients: BT709

AppleProRes LT Encoding:

Codec: AppleProRes
Bitrate: 85 Mbit/s
Width: 1920
height: 1080
Display Aspect Ratio: 16:9
Frame rate mode: Constant
Frame rate: 25fps
Scan Type: Interlaced TFF
Chroma Sampling: 4:2:2 planar
Bit Depth: 10bit
Color Range: Limited
Color Primaries: BT709
Matrix Coefficients: BT709



Objective metric: SSIM

https://i.imgur.com/tpUyxEo.png

SSIM objective metric test resulted in the following values:


H.264 AVC Intra Class 100

Total value: 358627.09

Average value: 19.33



Apple ProRes profile LT

Total value: 341903.78

Average value: 18.43



MPEG-2 XDCAM50

Total value: 313139.78

Average value: 16.88


Although there are some scenes in which AppleProRes LT profile has actually performed better than H.264, in general, a bitrate of 85 Mbit/s is really too low for its compression tools and this penalized ProRes in favor of H.264 which had the best overall result. As for MPEG-2, it showed all its difficulties in a series of scenes that included many elements like raindrops in which the individual 8x8 and 4x4 blocks and macroblocks of the droplets required a way higher bitrate and coding tools that take precautions when they detect these elements which obviously do not exist in MPEG-2 encoders. Another thing that penalized MPEG-2 a lot was the fact that it was 8bit only while both H.264 and AppleProRes were 10bit planar and avoided banding, especially in dark scenes with gradients and strong lights, and in the fading shades of the sky...


Objective metric: PSNR

https://i.imgur.com/bmUcV8J.png

PSNR objective metric test resulted in the following values:


H.264 AVC Intra Class 100

Total value: 724718.01

Average value: 39.06



Apple ProRes profile LT

Total value: 722724.27

Average value: 38.95



MPEG-2 XDCAM50


Total value: 714906

Average value: 38.53


PSNR was been much more permissive on some types of artifact; for instance it penalized more the fact of having macroblock correlation problems typical of MPEG codecs such as H.264 compared to grain retention, giving more points to AppleProRes than SSIM, however, overall, H.264 turns out to be once again the best on most scenes. One thing that can be noticed, among other things, is that although AppleProRes is only slightly lower than H.264, it is - in some particular situations - even lower than MPEG-2 due to the nature of the codec which is used at a way too low bitrate (85 mbit/s).

In any case, once again, H.264 turns out to be the winner, with AppleProRes immediately behind it and MPEG-2 at the bottom.


Final thoughts

H.264 is the clear winner of this challenge: it's a rather mature codec, supported everywhere in many broadcasting platform (like ours) and for which encoders like x264 have years of development behind them so that they're truly stable and safe.

It can also be used at 10bit in order to avoid banding and, as shown by the objective metrics, it represents the solution with the highest quality compatible with AVID Interplay Access among those analyzed.

mp3dom
6th May 2020, 18:25
15% less bitrate on the Prores LT can made this comparison unfair, plus, I think you need to take into the account the fact that all the certified Apple encoders (both on cameras and softwares) give the same results in terms of video quality while AVC quality depends by the encoder implementation. For example, I'm not sure the output from x264 is the same as the ones coming from a MainConcept encoder or Panasonic cameras, which may result in a different PSNR score and quality. You can't also expect that all the post-services are going to use ffmpeg or x264 directly (well, it's probably the opposite).

Also, I don't get the clue of this comparison... if you want to compare the quality at the same bitrate, you should try to match all of them (obviously here MPEG-2 is the less advanced codec, plus half the bitrate of AVC... it's clearly the worst even without a PSNR comparison). But if the reason of this is to compare the quality based on the "standard" actually in use, well... then you should compare AVC-100 with ProRes HQ, because ProRes LT is not for mastering purposes (LT most of the times is used as an alternative to ProRes Proxy for editing and pre-editing purposes). Never seen someone delivering ProRes LT as a final master.

TEB
6th May 2020, 20:06
My take on this is that Prores is an EDITING format, mezzanine..
H264, is better suited as a storage format in the higher bitrate tiers..

We use Prores 422HQ as the mezz edit format and H264@Hi10P@CRF10 as the storage format giving us anything from 1,5 to 5 times compression vs Prores with VMAF scores in the 99-99.9 ranges.

FranceBB
6th May 2020, 20:49
Also, I don't get the clue of this comparison... if you want to compare the quality at the same bitrate, you should try to match all of them

I would if I wasn't hog-tied to the AVID Interplay Storage which doesn't allow arbitrary import of codecs... :(


if the reason of this is to compare the quality based on the "standard" actually in use, well... then you should compare AVC-100 with ProRes HQ, because ProRes LT is not for mastering purposes (LT most of the times is used as an alternative to ProRes Proxy for editing and pre-editing purposes). Never seen someone delivering ProRes LT as a final master.

Got it, makes sense. I just checked and ProRes HQ is 220 Mbps; I'm not sure why my colleagues proposed the LT version though. I guess they thought that HQ was going to be too large to move around via aspera for such a fast-peace production (it's actually a talk show shot at a theatre that I think you're familiar with (https://videoplatform.sky.it/still/2020/04/01/1585735897250_video-epcc-2020-promo_videostill_1.jpg); if it was done in one of our studios like we did for the former seasons with each and every camera connected via SDI it would have been a totally different story...).

My take on this is that Prores is an EDITING format, mezzanine..
H264, is better suited as a storage format in the higher bitrate tiers..

We use Prores 422HQ as the mezz edit format and H264@Hi10P@CRF10 as the storage format giving us anything from 1,5 to 5 times compression vs Prores with VMAF scores in the 99-99.9 ranges.

Got it! :)

mp3dom
6th May 2020, 20:50
ProRes is used a lot for almost everything since, going from LT to XQ/Raw, you're covering almost all areas with a single codec. It's used for editing, mezzanine, master storage and the top-tier profile even for color grading

Blue_MiSfit
6th May 2020, 20:56
Erm... I was under the impression that ProRes is DCT based? https://www.provideocoalition.com/prores_a_closer_look/

Also, you might want to try just ProRes 422 (non HQ, LT, or Proxy). That might be a good fit.

FranceBB
6th May 2020, 21:52
you might want to try just ProRes 422 (non HQ, LT, or Proxy). That might be a good fit.

Oh, got it. I'll try that one as well!

Blue_MiSfit
7th May 2020, 03:20
For additional context, we use ProRes 422 HQ and XQ for almost everything internally. HQ has been deemed "good enough" for SDR mastering, but only XQ has received the golden approval for HDR.

I continue to be impressed by how good a well-configured JPEG2000 encode (from Transkoder for example) fares against ProRes, particularly when coding UHD HDR where it delivers excellent quality for HDR mezzanines at around the same data rates that would be required for ProRes 422 HQ to do HD SDR (~200 Mbps). You wouldn't use this as your archival to be sure, but for delivery for the purpose of encoding HDR10 HEVC it's quite good!

Cary Knoop
7th May 2020, 06:52
No surprise with the findings.
But ProRes encodes in parralel just fine.

kolak
11th May 2020, 23:59
There is nothing that crazy special or great in ProRes as codec/math behind. DNxHR efficiency is about the same.
What is great about ProRes is the same as some hate so badly- closed source and fact that Apple does care at least a bit about implementations. This is the reason why tons of a mezzanine masters are stored as ProRes.
There are also unused features like 1/2, 1/4 resolution decoding. This is not as efficient as in case of eg. Cineform (where even data read from the disk is proportionally reduced), but still saves a lot of CPU.
You can also re-encde just small area in original ProRes frame (like a dropout fix) keeping same bitrate for the whole frame. This is not part of Apple SDK though.

One note (which I see you met). If you are doing codec shootout make sure source was never compressed (unless lossless, probably best some film scan). This is good test footage used for DCI: https://www.dcimovies.com/2014_StEM_Access/
but it's not free. It's well shot and prepared footage with scenes of a different nature. Apple and GrassValley white papers uses it for PSNR measurements.
For example: you may get great quality source out of eg. Arri Alexa, but it was shot as ProRes. This will make whole comparison unfair (2nd generation of ProRes will give you very good/not objective PSNR values).

kolak
12th May 2020, 00:07
I continue to be impressed by how good a well-configured JPEG2000 encode (from Transkoder for example) fares against ProRes, particularly when coding UHD HDR where it delivers excellent quality for HDR mezzanines at around the same data rates that would be required for ProRes 422 HQ to do HD SDR (~200 Mbps). You wouldn't use this as your archival to be sure, but for delivery for the purpose of encoding HDR10 HEVC it's quite good!


Maybe because ProRes is not really a crazy efficient codec. It's just good enough. JPEG2000 is still a huge pain when it comes to encoding/decoding speed. I rather take Cineform lower efficiency, but few times better speed.

kolak
12th May 2020, 09:45
Objective metric: PSNR

https://i.imgur.com/bmUcV8J.png




When you show such a graph use correct scale. All <eg. 25 is meaningless and makes graphs less readable and waste space.

Blue_MiSfit
12th May 2020, 18:12
True^. Also, metrics are best used for evaluating short clips.

FranceBB
17th May 2020, 16:55
When you show such a graph use correct scale. All <eg. 25 is meaningless and makes graphs less readable and waste space.

Copy that. Will do next time.


One note (which I see you met). If you are doing codec shootout make sure source was never compressed (unless lossless, probably best some film scan).

Yes, thanks God we're a broadcaster but also a studio, so we have many .tiff and .dnf lossless footages in our MAM (Media Asset Management) of former productions that already aired. It just takes a hell lot of time as some of them are stored in LTO-6 in our local datacenter as we can't keep everything on RAID-6 hard drives. Anyway, the process of copying a file from LTO-6 to hard drives is totally automated so it's just a matter of time, in fact I wanted to use them to make the comparison. By the way, when they bring us .dng / .tiff is always a pain in the butt to encode 'cause you never know whether reading the metadata file in programs like AVID or Davinci is gonna work or not and if it doesn't... well... it's up to us to deal with tons of images and separate PCM audio tracks. (And believe me, I've seen many corrupted metadata files, especially when cameraman copy the whole structure from their storage to another HDD - or more than one - that is then delivered to us. Oh and when they use the "virtual cut" function to split across two or more HDDs is almost definitely NOT going to work. I have a sort of "Odi et amo" (hate and love) relationship with .dng / .tiff (as Catullus would say).



JPEG2000 is still a huge pain when it comes to encoding/decoding speed.

JPEG2000? It took a hell lot of time when we made a 4K DCP with OpenDCP on a 28c/56th Xeon last year. (T_T)