I wanted to scan some files for their bitdepth, however in some files that field doesn't show up.
I had this issues especially in DNxHR and DNxHD streams, but also with Prores.
Best,
Lucas
Last edit: Lucas Pfaff 2015-10-05
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
DNxHD: I have no file with missing bit depth
DNxHR: I have no file so I can not test. Sample files would be appreciated.
ProRes: this is a proprietary format, and I did not find a way to detect it. Sample files with 10-bit for sure and sample files with 12-bit for sure would be appreciated.
Last edit: Jerome Martinez 2015-10-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As it happens, Arri is extremely good about having sample footage available for workflow testing on their FTP site. Sample ProRes 4444 XQ files (which are supposed to be 12-bit) can be downloaded from Arri's FTP server. Details on the footage and the FTP site are available at: http://www.arri.com/EN/camera/alexa/learn/alexa_sample_footage/
Although, for some reason the 4444 XQ files read as 16-bit in DaVinci Resolve.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Unfortunately the issue is about the word "supposed".
Dificult to reverse engineer something when we are not sure of the properties of the files we get. Wikipedia page does not do explicit reference to XQ being only 12-bit.
Arri description does not either.
I tried to check:
ALEXA XT\02a_ProRes_16-9_1920x1080\24fps\J001C007_140110_R6MS.mov
ALEXA XT\02b_ProRes_16-9_1920x1080 - ProRes XQ\P001C015_140612_R33F.mov
Additionnaly, "Log C" stuff makes me crazy:
- ProRes frame says RGB (I guess, this is from previous reverse engineering, and it is "reserved" if I rely on colr/nclc atom description by Apple)
- QuickTime colr/nclc atom says BT.709 (why?)
- "Log C" is only in Arri specific metadata
I wonder how I should display such pieces of information.
(for saving the link: ALEXA Log C Curve)
With respect to format, RGB and Rec.709 sound normal. As for LogC, I would suggest denotation of LogC under "Tone Curve" (i.e. as one would denote Sony's S-Log curves, and those of other manufacturers) as that best describes what's going on.
Cursory look at Amira clip A001C002_140702_R3VJ (under HD/2K @ 23.976) suggests src_pix_fmt is also undefined - meaning that the answer may not simply be determined by the header. (Since the header is, according to your link, unable to describe non-floating point 4:4:4 files with greater than 8-bit precision.)
Checking some files (422, 444, 444XQ...), the ProRes frame header looks like identical except 1 bit (the one used for saying the chroma subsampling).
So either:
- the modified bit says also the bitdepth (422 = 10-bit, 444 = 12-bit?)
- the frame size implies some characteristics
- characteristics depend of the container (how?)
- Something else?
Thanks. I compared some files, and same issue: frame header is same. Looks like the LogC info depends of the container (I guess that it will b a pain to save such metadata if there is a move to another container e.g. MXF, with a lost of colour information, fun...)
Cursory look at Amira clip A001C002_140702_R3VJ (under HD/2K @ 23.976) suggests src_pix_fmt is also undefined - meaning that the answer may not simply be determined by the header.
Right, looks like it is only a tip, not for decoding.
As for LogC, I would suggest denotation of LogC under "Tone Curve" (i.e. as one would denote Sony's S-Log curves, and those of other manufacturers)
S-Log is in "CaptureGammaEquation" for Sony (EBU Tech 3349).
So if it is the same piece of info (looks like it is, the ARRI name is "ColorGammaSxS") and no big need of "tone Curve" field name, I think I'll prefer to keep "CaptureGammaEquation" as the "standard" (MediaInfo definition) name, and put it beside Color primaries / Transfer characteristics / Matrix coefficients (another line in MediaInfo!) (for Sony, it is currently only in the Acquisition Metadata track, I guess I'll move the item in the video part of MediaInfo)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Tell me please about your reverse engineering? I'm try understand how worked confirm in Cinema Tools. In the Hex editor you can see that program adds a lot of information to the headers. How to understand the structure of headers and edit their file corruption. Of course all in prores.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry, I totally missed your answer. Please contact me at info@mediaarea.net with access to a place with files if you don't want make them public or I'll provide a private FTP server access so you can upload files.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
White paper: I learnt to not trust marketing material ;-). Additionaly there is the sentence "Apple
ProRes 4444 XQ and Apple ProRes 4444 support image sources up to 12 bits" --> "up to" is the issue, I can not be sure a 4444 XQ file is 12-bit. In the Arri files, I now it is 4444 XQ (description of files), I don't know if it is 10-bit or 12-bit (nothing in the description). I am looking for material 12-bit for sure (and the same content in 10-bit for sure, so I can compare).
TN2162: unfortunately not enough (no description of ProRes bitstream; matrix values, which are expected to be the one in the ProRes stream, say "Reserved" for the value 0 used in the stream, so I don't know what it is). Or did I miss something you want to show me?
Last edit: Jerome Martinez 2016-01-03
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't help you with the 12-bit files, but FCP 7 does have an export mode that is explicitly prores 8-bit. I've uploaded the same colour bars from the same sequence.
The 8-bit one is listed in FCP 7 as "Apple ProRes 422 8-bit 1440x1080 50i 48hz"
The other profile is just the Apple ProRes 422 PAL 48khz option.
Link: https://github.com/kieranjol/24to25/blob/master/prores_8and10bit.zip
Also attached.
I can't see any difference in the ProRes frame header (same for both 8-bit and 10-bit), so I guess I could peek the bit depth only if I decode the slices. Will be longer :(.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I can't see any difference in the ProRes frame header
You won't, there isn't any. ProRes 4444 is always 12-bit, other flavours are always 10-bit. ProRes has a piece of metadata called 'src_pix_fmt', but that just records the type of frame buffer passed to the ProRes encoder. The encoder will transform bit depth and color subsampling before compressing the frame, so 'src_pix_fmt' has no bearing on the format of the compressed frame itself, which is determined by the profile.
Sure, you can create a 422 HQ file from 8-bit or 12-bit sources, but the encoded samples will be padded or truncated respectively to 10-bit and the bitstream format will be the same (except for the src_pix_fmt field).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I read "up to" in the white paper, please provide a source confirming that this is always 12-bit. Before I remove the bitdepth information from MediaInfo output, I got many complains when I was relying on the CodecID only for saying if it is 8- or 10-bit (before 12-bit was there), I don't want to start again this mistake.
Does that also means that the frame is not decodable if the CodecID is wrong? I changed the Codec ID of ap4h to apch (so maximum 10-bit) and it is still playable by VLC, so I guess the bitdepth is somewhere in the frame bitstream, not only from the Codec ID.
If someone is motivated for looking at VLC (or FFmpeg) code... On my side, this is not my priority, I just don't accept to put any bitdepth without being sure it is the right result, I prefer to display no info rather than sometimes wrong info, and I see I can not rely on the Codec ID, so I want to knwo where I can see such info in the bitstream.
Sure, you can create a 422 HQ file from 8-bit or 12-bit sources, but the encoded samples will be padded or truncated respectively to 10-bit and the bitstream format will be the same (except for the src_pix_fmt field).
There is no src_pix_fmt for 12-bit, it uses to be unknown in that case.
this is another issue (for this one, I plan to do as I do for MXF, I'll display 2 fields: "Bit depth" and "Stored bit depth", when I can know the stored bit depth for sure).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Jerome,
We're receiving files from our suppliers that aren't reporting a video bit depth in MediaInfo. It happens pretty rarely, but we have a few samples. The files are all DnX HD MOVs. The missing bit depth info causes us to automatically reject these files from our supply chain. I'm happy to provide you with a sample file if that's helpful in resolving this issue.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There is no ETA on free support. If you are interested in a accelerating development of a specific item (when it is doable, see below), please contact info@mediarea.net for a quote.
Checking again SMPTE docs, I see RDD 36 "ProRes specs" is available now (behind a paywall). Unfortunately it does not provide more help :(.
Quickly looking at the spec, I see nothing about bit depth in the bitstream.
Some sentences from the spec:
"the pixel component samples can have bit depths of 12 or even more bits per sample"
"Using v to denote a (fixed-point or floating-point) reconstructed color component value and s to denote the corresponding (unsigned integer) pixel component sample, this is s = clamp(round(2^b * (v + 256) ÷ 512)), where b is the number of bits per component sample and clamp(n) restricts its argument to the appropriate range (...) The clamping bounds nmin and nmax may be set respectively to 0 and 2^b − 1 to produce pixel component samples that utilize all available quantization levels or to the smallest and largest permissible video quantization levels for b-bit samples"
the more I deal with this ProRes stuff, the more I come to the conclusion that bit depth is not stored in the bitstream and the decoder must choose the output bit depth, and the encoder decides about the bit depth of the numbers it stores in the bitstream without putting any hint in the bitstream.
Note: looks like FFmpeg has similar thoughts, as everything is decoded to 10-bit (files tagged 8, 10, or 12, same output format)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
How is it possible that bit depth is not stored in the bitstream? If the decoder uses the wrong one, then the image will look wrong. Is there truly no way to see what bit depth was used to encode a file?
I know that by now you've see all of Arri's sample footage. I just want to add that in my conversation with Arri here, they confirmed they do write 12 bits.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If I write 25% gray in 12-bits, that would be RGB value 1024,1024,1024. If a playback software decodes this file as 10-bit, then this would appear as 100% white (assuming linear gamma). I'm not understanding how this could possibly look correct if the decoder does not know the bit depth used by the encoder.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there,
I wanted to scan some files for their bitdepth, however in some files that field doesn't show up.
I had this issues especially in DNxHR and DNxHD streams, but also with Prores.
Best,
Lucas
Last edit: Lucas Pfaff 2015-10-05
DNxHD: I have no file with missing bit depth
DNxHR: I have no file so I can not test. Sample files would be appreciated.
ProRes: this is a proprietary format, and I did not find a way to detect it. Sample files with 10-bit for sure and sample files with 12-bit for sure would be appreciated.
Last edit: Jerome Martinez 2015-10-19
As it happens, Arri is extremely good about having sample footage available for workflow testing on their FTP site. Sample ProRes 4444 XQ files (which are supposed to be 12-bit) can be downloaded from Arri's FTP server. Details on the footage and the FTP site are available at: http://www.arri.com/EN/camera/alexa/learn/alexa_sample_footage/
Although, for some reason the 4444 XQ files read as 16-bit in DaVinci Resolve.
Unfortunately the issue is about the word "supposed".
Dificult to reverse engineer something when we are not sure of the properties of the files we get.
Wikipedia page does not do explicit reference to XQ being only 12-bit.
Arri description does not either.
I tried to check:
ALEXA XT\02a_ProRes_16-9_1920x1080\24fps\J001C007_140110_R6MS.mov
ALEXA XT\02b_ProRes_16-9_1920x1080 - ProRes XQ\P001C015_140612_R33F.mov
They have both the ProRes frame header:
Hex dump: 07 80 04 38 C0 00 00 00 00 00 00 03
Trace (reverse engineering and multimedia.cx help):
0026C010 frameWidth: 1920 (0x0780)
0026C012 frameHeight: 1080 (0x0438)
0026C01A chrominance factor: 3 (0x03)(2 bits) - 4:4:4 -
0026C018 reserved: 0 (0x00)(2 bits) -
0026C016 frame type: 0 (0x00)(2 bits) - Progressive - -
0026C014 reserved: 0 (0x00)(2 bits) -
0026C015 reserved: 0 (0x00)
0026C016 primaries: 0 (0x00) - Reserved
0026C017 transf_func: 0 (0x00) - Reserved
0026C018 colorMatrix: 0 (0x00) - Reserved (RGB?)
0026C01D src_pix_fmt: 0 (0x00)(4 bits) - unknown
0026C019 alpha_info: 0 (0x00)(4 bits) - no alpha
0026C01A reserved: 0 (0x00)
0026C01D reserved: 0 (0x00)(6 bits) -
0026C01C custom luma quant matrix present: Yes
0026C01B custom chroma quant matrix present: Yes
Additionnaly, "Log C" stuff makes me crazy:
- ProRes frame says RGB (I guess, this is from previous reverse engineering, and it is "reserved" if I rely on colr/nclc atom description by Apple)
- QuickTime colr/nclc atom says BT.709 (why?)
- "Log C" is only in Arri specific metadata
I wonder how I should display such pieces of information.
(for saving the link: ALEXA Log C Curve)
For reference, an "old" ProRes 422 HQ frame header looks like:
Hex dump: 07 80 04 38 82 00 02 02 01 10 00 03
Trace:
00048736 frameWidth: 1920 (0x0780)
00048738 frameHeight: 1080 (0x0438)
00048740 chrominance factor: 2 (0x02)(2 bits) - 4:2:2 -
0004873E reserved: 0 (0x00)(2 bits) -
0004873C frame type: 0 (0x00)(2 bits) - Progressive - -
0004873A reserved: 2 (0x02)(2 bits) -
0004873B reserved: 0 (0x00)
0004873C primaries: 2 (0x02) - Unknown
0004873D transf_func: 2 (0x02) - Unknown
0004873E colorMatrix: 1 (0x01) - BT.709
00048743 src_pix_fmt: 1 (0x01)(4 bits) - 2vuy (8-bit 4:2:2)
0004873F alpha_info: 0 (0x00)(4 bits) - no alpha
00048740 reserved: 0 (0x00)
00048743 reserved: 0 (0x00)(6 bits) -
00048742 custom luma quant matrix present: Yes
00048741 custom chroma quant matrix present: Yes
I would be curious to have access to real ProRes specifications! :(
Take it with a grain of salt, but Arri explicitly says their ProRes 4444 / XQ files are 12-bit here: https://www.arri.com/camera/alexa/workflow/working_with_proresdnxhd/recording/media_and_codecs/
With respect to format, RGB and Rec.709 sound normal. As for LogC, I would suggest denotation of LogC under "Tone Curve" (i.e. as one would denote Sony's S-Log curves, and those of other manufacturers) as that best describes what's going on.
If it helps any, Arri also makes available test footage from their Amira camera in ProRes 4444 that is not in LogC:
https://www.arri.com/camera/amira/learn/amira_sample_footage/
Cursory look at Amira clip A001C002_140702_R3VJ (under HD/2K @ 23.976) suggests src_pix_fmt is also undefined - meaning that the answer may not simply be determined by the header. (Since the header is, according to your link, unable to describe non-floating point 4:4:4 files with greater than 8-bit precision.)
Without a spec, you may want to keep an eye on the status of this:
https://kws.smpte.org/kws/public/projects/project/details?project_id=278
Checking some files (422, 444, 444XQ...), the ProRes frame header looks like identical except 1 bit (the one used for saying the chroma subsampling).
So either:
- the modified bit says also the bitdepth (422 = 10-bit, 444 = 12-bit?)
- the frame size implies some characteristics
- characteristics depend of the container (how?)
- Something else?
So nothing I can use for the moment :(.
Thanks. I compared some files, and same issue: frame header is same. Looks like the LogC info depends of the container (I guess that it will b a pain to save such metadata if there is a move to another container e.g. MXF, with a lost of colour information, fun...)
Right, looks like it is only a tip, not for decoding.
I guess we need to wait for the release of this document, in order to understand better how to get bit depth information (and more)...
S-Log is in "CaptureGammaEquation" for Sony (EBU Tech 3349).
So if it is the same piece of info (looks like it is, the ARRI name is "ColorGammaSxS") and no big need of "tone Curve" field name, I think I'll prefer to keep "CaptureGammaEquation" as the "standard" (MediaInfo definition) name, and put it beside Color primaries / Transfer characteristics / Matrix coefficients (another line in MediaInfo!) (for Sony, it is currently only in the Acquisition Metadata track, I guess I'll move the item in the video part of MediaInfo)
Tell me please about your reverse engineering? I'm try understand how worked confirm in Cinema Tools. In the Hex editor you can see that program adds a lot of information to the headers. How to understand the structure of headers and edit their file corruption. Of course all in prores.
Your question is too much generic.
Up to date results of our ProRes reverse engineering is in MediaInfo ProRes source code.
If you want a more dedicated support, please contact us for quote for dedicated support.
Hi there Jerome,
where I can send you the footage through? I'd happily arrange all those samples for you :)
Sorry, I totally missed your answer. Please contact me at info@mediaarea.net with access to a place with files if you don't want make them public or I'll provide a private FTP server access so you can upload files.
I missed yours too :) I send you an eMail on the first of February in case it got into spam!
I presume, you already know:
https://www.apple.com/final-cut-pro/docs/Apple_ProRes_White_Paper.pdf
and
https://developer.apple.com/library/mac/technotes/tn2162/_index.html
White paper: I learnt to not trust marketing material ;-). Additionaly there is the sentence "Apple
ProRes 4444 XQ and Apple ProRes 4444 support image sources up to 12 bits" --> "up to" is the issue, I can not be sure a 4444 XQ file is 12-bit. In the Arri files, I now it is 4444 XQ (description of files), I don't know if it is 10-bit or 12-bit (nothing in the description). I am looking for material 12-bit for sure (and the same content in 10-bit for sure, so I can compare).
TN2162: unfortunately not enough (no description of ProRes bitstream; matrix values, which are expected to be the one in the ProRes stream, say "Reserved" for the value 0 used in the stream, so I don't know what it is). Or did I miss something you want to show me?
Last edit: Jerome Martinez 2016-01-03
Hello Jerome,
I can't help you with the 12-bit files, but FCP 7 does have an export mode that is explicitly prores 8-bit. I've uploaded the same colour bars from the same sequence.
The 8-bit one is listed in FCP 7 as "Apple ProRes 422 8-bit 1440x1080 50i 48hz"
The other profile is just the Apple ProRes 422 PAL 48khz option.
Link: https://github.com/kieranjol/24to25/blob/master/prores_8and10bit.zip
Also attached.
Last edit: Kieran O'Leary 2016-01-18
I can't see any difference in the ProRes frame header (same for both 8-bit and 10-bit), so I guess I could peek the bit depth only if I decode the slices. Will be longer :(.
You won't, there isn't any. ProRes 4444 is always 12-bit, other flavours are always 10-bit. ProRes has a piece of metadata called 'src_pix_fmt', but that just records the type of frame buffer passed to the ProRes encoder. The encoder will transform bit depth and color subsampling before compressing the frame, so 'src_pix_fmt' has no bearing on the format of the compressed frame itself, which is determined by the profile.
Sure, you can create a 422 HQ file from 8-bit or 12-bit sources, but the encoded samples will be padded or truncated respectively to 10-bit and the bitstream format will be the same (except for the src_pix_fmt field).
I read "up to" in the white paper, please provide a source confirming that this is always 12-bit. Before I remove the bitdepth information from MediaInfo output, I got many complains when I was relying on the CodecID only for saying if it is 8- or 10-bit (before 12-bit was there), I don't want to start again this mistake.
Does that also means that the frame is not decodable if the CodecID is wrong? I changed the Codec ID of ap4h to apch (so maximum 10-bit) and it is still playable by VLC, so I guess the bitdepth is somewhere in the frame bitstream, not only from the Codec ID.
If someone is motivated for looking at VLC (or FFmpeg) code... On my side, this is not my priority, I just don't accept to put any bitdepth without being sure it is the right result, I prefer to display no info rather than sometimes wrong info, and I see I can not rely on the Codec ID, so I want to knwo where I can see such info in the bitstream.
There is no src_pix_fmt for 12-bit, it uses to be unknown in that case.
this is another issue (for this one, I plan to do as I do for MXF, I'll display 2 fields: "Bit depth" and "Stored bit depth", when I can know the stored bit depth for sure).
Jerome,
We're receiving files from our suppliers that aren't reporting a video bit depth in MediaInfo. It happens pretty rarely, but we have a few samples. The files are all DnX HD MOVs. The missing bit depth info causes us to automatically reject these files from our supply chain. I'm happy to provide you with a sample file if that's helpful in resolving this issue.
Right, I need files, please provide them (contact info@mediaarea.net if you can't publicly provide the file).
Hope you can add feature for prores bit depth soon.
Here's a 10bit 4:2:2 prores video: https://www.sendspace.com/file/fqwlow
There is no ETA on free support. If you are interested in a accelerating development of a specific item (when it is doable, see below), please contact info@mediarea.net for a quote.
Not a lot of change since this answer.
Checking again SMPTE docs, I see RDD 36 "ProRes specs" is available now (behind a paywall). Unfortunately it does not provide more help :(.
Quickly looking at the spec, I see nothing about bit depth in the bitstream.
Some sentences from the spec:
"the pixel component samples can have bit depths of 12 or even more bits per sample"
"Using v to denote a (fixed-point or floating-point) reconstructed color component value and s to denote the corresponding (unsigned integer) pixel component sample, this is s = clamp(round(2^b * (v + 256) ÷ 512)), where b is the number of bits per component sample and clamp(n) restricts its argument to the appropriate range (...) The clamping bounds nmin and nmax may be set respectively to 0 and 2^b − 1 to produce pixel component samples that utilize all available quantization levels or to the smallest and largest permissible video quantization levels for b-bit samples"
the more I deal with this ProRes stuff, the more I come to the conclusion that bit depth is not stored in the bitstream and the decoder must choose the output bit depth, and the encoder decides about the bit depth of the numbers it stores in the bitstream without putting any hint in the bitstream.
Note: looks like FFmpeg has similar thoughts, as everything is decoded to 10-bit (files tagged 8, 10, or 12, same output format)
How is it possible that bit depth is not stored in the bitstream? If the decoder uses the wrong one, then the image will look wrong. Is there truly no way to see what bit depth was used to encode a file?
I know that by now you've see all of Arri's sample footage. I just want to add that in my conversation with Arri here, they confirmed they do write 12 bits.
You have some prejudices about bitstream, it is possible.
Not necessarely.
This is what I know, and would be happy to be wrong if you can indicate the opposite.
Writing 12 bits is one thing, indicating it so decoder can know is another one. This is not only about ProRes.
If I write 25% gray in 12-bits, that would be RGB value 1024,1024,1024. If a playback software decodes this file as 10-bit, then this would appear as 100% white (assuming linear gamma). I'm not understanding how this could possibly look correct if the decoder does not know the bit depth used by the encoder.