Video Levels in Quicktime

[GaneshRavi1125]

I am confused about something and hope someone can help. I work alot with 10 bit Uncompressed QT files that are sourced from analog videotapes. When I open them in applications and view the waveform displays I routinely see levels that exceed what I understand to be the theoretical limit for Y in a 10 bit file, i.e. 1023 or 100 IRE or 255, depending on the application. What am I actually seeing? Do meters in digital video applications show the levels of the stored video or not? How does that correlate with 1023 being the limit for 10 bit files? Thank you.

[poisondeathray]

I am confused about something and hope someone can help. I work alot with 10 bit Uncompressed QT files that are sourced from analog videotapes. When I open them in applications and view the waveform displays I routinely see levels that exceed what I understand to be the theoretical limit for Y in a 10 bit file, i.e. 1023 or 100 IRE or 255, depending on the application. What am I actually seeing? Do meters in digital video applications show the levels of the stored video or not? How does that correlate with 1023 being the limit for 10 bit files? Thank you.

It depends on the application, and what settings you are using.

If you've digitized the analog signal, technically IRE is irrelevant, because it refers to an analog signal. But many programs keep "IRE" and mV units notation for nostalgic editors and engineers. IRE 0-100 just means black to white

In 10bit video (standard range) levels , Y 64-940 is black to white. (or in RGB 0-1023). For a standard range project 0-100IRE represents Y 64-940 (or Y 16-235 in 8bit code values). So if you had values above 100 IRE in a modern NLE, that represents code values >940 (or values >235 in 8bit).

But if you're working in full range project, full range assets, 0-100IRE represents Y 0-1023. ie. The IRE definition changes depending on your settings. If you're using a NLE, all assets when conformed to the timeline are converted to the whatever timeline colorspace and settings are set to, and 0-100 IRE just means black to white for those settings

[GaneshRavi1125]

Thanks for your response. So, is it accurate to say that Uncompressed QT files will store video that is in the range 236-254 (8 bit) and 941-1023 (10 bit) with no alteration to the signal and that applications will display the waveform for it but as soon as you want to do something with it including playing, editing, transcoding, etc., there is the potential that video that exceeds 235 or 940 might be clamped unless measures are taken to prevent it?

[poisondeathray]

So, is it accurate to say that Uncompressed QT files will store video that is in the range 236-254 (8 bit) and 941-1023 (10 bit) with no alteration to the signal and that applications will display the waveform for it but as soon as you want to do something with it including playing, editing, transcoding, etc., there is the potential that video that exceeds 235 or 940 might be clamped unless measures are taken to prevent it?

Yes it's possible to store code values 236-255, 941-1023 with uncompressed QT, such as v210 (10bit 4:2:2 uncompressed in MOV) . But often capture hardware or software place limitations. eg. Code values 0 and 255 for 8bit and 0, 1023 for 10bit are often "reserved" values depending on the hardware or software. Some software or hardware scopes perform additional processing or scaling. So it depends on what you are using, exactly, and what settings you are using. If you want to examine unprocessed signal waveform for a digital file, (ie. actual digital values) ffmpeg -vf waveform can display it for 8,10,12 bit video . Avisynth histogram can to (it's actually a waveform)

When you "view" something on a display, it gets converted to RGB. You're viewing a RGB representation of the underlying YCbCr values . Y values >940 are "whiter than white" if you use a standard range conversion matrix (normal), so they become the same "shade" of white, or clipped at RGB 255,255,255 (or RGB 1023,1023,1023 on a 10bit display) . If you are using full range, then Y 0-1023 gets "mapped" to RGB 0-1023, and nothing is clipped in terms of max signal value, but the contrast will appear to be different if it was a standard range video to begin with (reference black level at 64, reference white at 940) .

[GaneshRavi1125]

Thank you for clarifying that even displaying a v210 file with white >940 might result in all white values over 940 having the same intensity or shade of white because of clamping and / or screwed up contrast because the file's native YCbCr isn't what is shown but the RGB derived from it via some conversion. Do most modern video applications provide the means for a knowledgable operator to avoid those kinds of negative consequences when transcoding or editing 8 or 10 bit Uncompressed QT files with "out of range" luma or color values? Does FFMPEG?

[poisondeathray]

Thank you for clarifying that even displaying a v210 file with white >940 might result in all white values over 940 having the same intensity or shade of white because of clamping and / or screwed up contrast because the file's native YCbCr isn't what is shown but the RGB derived from it via some conversion. Do most modern video applications provide the means for a knowledgable operator to avoid those kinds of negative consequences when transcoding or editing 8 or 10 bit Uncompressed QT files with "out of range" luma or color values? Does FFMPEG?

It's a complicated answer. In short, it depends (on the program, the scenario, what operations are being performed)

If v210 is treated as YCbCr, then generally nothing is clipped . e.g. Premiere Pro has a YCbCr timeline, and v210 gets treated as YCbCr. The preview might appear the "same" shade of white for values over 940, but you can adjust and recover those "overbrights". ie. the preview is a temporary RGB preview, but the underlying data is the original YCbCr format

But some programs clip because timeline works in RGB (format is actually converted), and a limited range conversion is performed, so there is clipping at that step

But some work in float , so even though timeline is RGB, the data is recoverable (e.g. Resolve) . v210 is actually a "special" pixel format in resolve, it gets passthrough treatment



For FFmpeg there can be partial clipping - but it depends on what specific operations are being performed, and which formats are being used.

eg. ffmpeg v210 encoding ranges actually from 4-1019, not 0-1023 . Some formats like ffmpeg prores encoding are 4-1019 too. But ffmpeg DNxHR perserves 0-1023 code values .

For 10bit broadcast hardware equipment 4-1019 is correct (certain values are reserved for SDI sync). But digitally, for computers, 0-1023 code values is correct.



Often there are a lot of "gotchas" or operations done in the background in various programs that sometimes lead to undersireable or unexpected results. You should always test and verify your workflow

[GaneshRavi1125]

If v210 is treated as YCbCr, then generally nothing is clipped . e.g. Premiere Pro has a YCbCr timeline, and v210 gets treated as YCbCr. The preview might appear the "same" shade of white for values over 940, but you can adjust and recover those "overbrights". ie. the preview is a temporary RGB preview, but the underlying data is the original YCbCr format

Since you mention YCbCr I have another question. I would assume that because 4:2:2 Y'CbCr chroma subsampling is designed to reduce the bandwidth required for the chroma channels by half compared to Y that the digital ranges for the Cb and Cr channels would be 1-128 or some such but they are 16-240 which (the way I understand it) is more than Y. What am I not getting?

[poisondeathray]

Since you mention YCbCr I have another question. I would assume that because 4:2:2 Y'CbCr chroma subsampling is designed to reduce the bandwidth required for the chroma channels by half compared to Y that the digital ranges for the Cb and Cr channels would be 1-128 or some such but they are 16-240 which (the way I understand it) is more than Y. What am I not getting?

The code values are not "subsampled". Chroma subsampling can be thought as the "resolution" or "pixel samples" of the Cb, Cr planes. eg. A 1920x1080 4:2:2 video would have 1920x1080 Y , but 960x1080 Cb and Cr (horizontally half sampled).

The code value range for standard range is 16-240 for CbCr in 8bit (not 16-235 like Y'), and 64-960 (not 64-940 like Y') . "Full range" is still 0-255 and 0-1023 for 8 and 10bit respectively for Y,Cb and Cr

[Cornucopia]

And the difference in coding levels has more to do with the difference in expected overshoot & undershoot in chroma vs luma.

Scott