ARRI Forum

Posted: **Sun Feb 28, 2016 1:21 am**

I've always thought that ProRes 444 from both Alexa and Alexa Mini is recorded as RGB 12-bit. That's what it says in the manual. But FFmpeg identifies it as yuv444p10le. Resolve identifies it as 16-bit. Can anyone shed light on this subject? Also, I would assume the camera does not write an alpha channel, is that true?

Posted: **Tue Mar 01, 2016 6:14 pm**

Hello again Llama Films,

ProRes 4444 and ProRes 4444XQ are 12 bit codecs and we do write 12 bit in all ALEXA cameras.
Furthermore also yes to the alpha channel it is not being used in ARRI cameras.

By the way, ARRIRAW is 12 bit, too.

Kind regards,
Jan

Posted: **Tue Mar 01, 2016 7:46 pm**

Jan, how is it that ffmpeg identifies the footage as 10 bit YUV, and yet it still displays properly? Trying to play 12 bit video using 10 bit code should result in something very distorted. And can you suggest any other software that can be used to verify the video bit depth?

Posted: **Fri Apr 08, 2016 2:49 pm**

you can try mediainfo
https://itunes.apple.com/app/mediainfo/id510620098

Posted: **Thu Apr 19, 2018 9:39 pm**

I'd like to resurrect this old topic, because this questions is still bugging me. Mediainfo does not show bit depth for ProRes files. If ffmpeg decodes a 12-bit file as 10-bit, then the image should look wrong. But actually the image looks fine in ffmpeg. How is this possible?

One more question: Mediainfo (and ffmpeg) identify ProRes files from Alexa as YUV 4:4:4. Is this true, or are they actually RGB 4:4:4?

Posted: **Fri Apr 20, 2018 9:12 am**

Dear Elliott,

some information from our R&D hackers...
All ProRes codecs are is based on YCC, not RGB. ProRes 4444/4444 XQ is sometimes regarded to being RGB because it can be converted to RGB loss free (quantization left aside). Neither RGB nor YCC is being is being saved, only DTC coefficients.
In our cameras we calculate the DTC coefficients with 16 bit accurancy.

I don't know how Media Info gathers its information, when using ProRes files from different sources I don't see any bitdepth information. Be it a file from ALEXA SXT or Premiere Media Encoder.
Did you use files from Mini?

Media Info Screenshots: ProRes 4444 render from Premiere vs. ALEXA SXT ProRes 4444
> no bitdeph shown.

MediaInfo_ALEXASXT.png

MediaInfo_Premiererender.png

Cheers,
Jan

Posted: **Sat Apr 21, 2018 12:43 am**

Thanks for the info from your R&D hackers. I'm really not familiar with DTC, but I tried googling, is that the same as DCT coefficient? It's fascinating to me that YUV and RGB can be used interchangeably. I thought 50% gray in 10-bit RGB would be 512,512,512. But in 12-bit RGB that code value would represent 12.5% dark gray. And in 10-bit YUV it would be bright green. But you're saying you don't encode the values in either mode, rather just the coefficients.

I would love to learn more about how this is possible.

I did check clips from the Mini too, they are the same way. I spoke with the developer of MediaInfo, who said that he doesn't know how to definitively read the bit depth from ProRes files, so therefore he does not display a number that may be wrong.

But ffmpeg definitely shows it as 10 bit.

Code: Select all

Stream #0:0(eng): Video: prores (ap4h / 0x68347061), yuv444p10le(bt709, progressive), 1920x1080, 277199 kb/s, SAR 1:1 DAR 16:9, 23.98 fps, 23.98 tbr, 23976 tbn, 23976 tbc (default)
    Metadata:
      creation_time   : 2012-10-23T22:30:46.000000Z
      handler_name    : Apple Alias Data Handler
      encoder         : Apple ProRes 4444

Posted: **Mon Apr 23, 2018 4:57 pm**

Dear Elliott,

I guess it is not a 1:1 swap of data but rather a lossless translation. Some magic might be involved, too.

As ffmpeg newbie... you're saying this 10 in that string: yuv444p10le
says it is 10bit?

Posted: **Mon Apr 23, 2018 5:36 pm**

Haha yes, the magic part is what I'm trying to understand.

Yes, that's right about ffmpeg, and the le means little endian. You can get a list of all supported pixel formats by running "ffmpeg -pix_fmts". yuv444p12le is also supported.

I'm open to the idea that ffmpeg is wrong here, but I can't believe that without strong evidence.

Posted: **Wed Apr 25, 2018 11:59 am**

When rendering ProRes 4444 in Premiere ffprobe gives me 10bit with alpha:

Code: Select all

pix_fmt=yuva444p10le

Resolve kicks the alpha, but still leaves us with

Code: Select all

pix_fmt=yuv444p10le

for ProRes 4444 and ProRes 4444 XQ.

and ARRIRAW Converter gives me

Code: Select all

pix_fmt=yuv444p10le

for ProRes 4444 and ProRes 4444 XQ

So is it 10 bit everywhere?

By the way, for Compressor-rendered files I end up with

Code: Select all

pix_fmt=yuv422p10le

for ProRes 4444 and 4444XQ

Posted: **Sat Apr 28, 2018 4:15 am**

Alright I've put together a test showing that 12-bit does indeed exist, and that ffmpeg is incorrectly decoding it as 10-bit.
If anyone else comes across this thread, the proof is here: https://trac.ffmpeg.org/ticket/7163#comment:2

I'm still interested to know how to properly read the bit depth metadata from a Quicktime file, but maybe that info is secret...

ARRI Forum

Is ProRes 444 really 12-bit?

Is ProRes 444 really 12-bit?

Re: Is ProRes 444 really 12-bit?

Re: Is ProRes 444 really 12-bit?

Re: Is ProRes 444 really 12-bit?

Re: Is ProRes 444 really 12-bit?

Re: Is ProRes 444 really 12-bit?

Re: Is ProRes 444 really 12-bit?

Re: Is ProRes 444 really 12-bit?

Re: Is ProRes 444 really 12-bit?

Re: Is ProRes 444 really 12-bit?

Re: Is ProRes 444 really 12-bit?