That’s to be expected. RGB here refers to typical computer sRGB values which are 0-255 full range. The YUV values in the scope are always reported as limited range. The scope does not report studio range RGB. So we would expect a mismatch.
One scope, two different ranges. That’s confusing.
They should make scales — one readout shows my true weight and the other reads 20 pounds less, and not tell the user which is true. The man who wears two watches indeed.
Austin: did you get my files?
Oh, sorry, I forgot there is another place I can look for them. I see them. I’ll check it out when I’m back near a computer.
The different ranges are definitely confusing and super annoying, but the Shotcut video zoom is also very useful the way it is.
Here’s the complication… In sRGB, the triplet of 255,255,255 represents the sRGB white point which is defined to be CIE D65. In limited range YCbCr, the CIE D65 white point is Y 235.
Even though the numbers are different, they represent the same color being projected off a screen. They are correlated through CIE XYZ color space as equivalent, meaning the same nanometers of light emission.
Using your scale analogy, a person has only one weight (just like the color being analyzed in the video zoom has a specific nanometer wavelength). But weight can be expressed in pounds or kilograms. Different numbers, but equal in meaning. That’s what is happening here. So the Shotcut scope analyzes one color and reports the value using the two most common units of measure, just like the labels on a cereal box show both grams and ounces. (Although some of my boxes are measured in pounds… 
)
I do not use ffplay, as ffplay tend to display wrongly colors or to insert wrongly filters into filtergraph.
I use only mpv.
Chris was referring to the ffmpeg/ffplay -vf waveform with IRE setting when used directly on a full range video (with full range flag), not a rendered RGB video display (that’s ok for both, on these greyscale test videos) - and it’s the same
mpv input.ext --vf=waveform=s=ire:g=green:o=0.25
Austin already answered this above and posted the relevant parts of the code - ffmpeg/ffplay waveform IRE is not clamping the data automatically (like shotcut) whenever a full range flag is present. It’s just replacing the 16-235 graphic with 0-100 IRE
Maybe full range flagged files should automatically be clamped whenever “IRE” is selected, but left alone when “digital” is selected , assuming the input was 709. But that approach can be problematic; The counterpoint is you’re not necessarily working with sRGB or 709 input files or situations with ffmpeg. A user would have to know which situations IRE could be used, or there would have to be other compensations or conversions to sRGB or 709 equivalents to the same whitepoint before using the filter. The other option would be to remove it, or maybe add a warning in the documentation
Small bug report . I’ll post it here since it’s related
Clamp is not applied to 10bit full range flagged files , even though properties display color range as full (inconsistent behaviour compared to 8bit full range flag handling)
8bit full range flagged files are automatically clamped, and the properties are set to “full” upon import
10bit full range flagged files are not clamped, but also have properties automatically set to “full” on import. Videozoom reports expected Y 0,16,235,255 downconverted 8bit values; but IRE waveform shows unclamped that corresponds with preview display
AVC Test video with Y = 0,64,940,1023, yuv420p10 , flagged full attached. Right click, save as
(It also occurs with 10bit HEVC and DNxHR 10bit422 flagged full, let me know if you need those)
First off, I think “clamp” is bad terminology here. Clamp usually implies a truncation whereas you are referring to converting value ranges. I think it is good that its waveform does not automatically convert range to something else. However, perhaps it should adjust the IRE graticules for full range. I wish Shotcut Source would not convert full range to limited but alas that is how it handles it currently.
Small bug report . I’ll post it here since it’s related
Clamp is not applied to 10bit full range flagged files in Shotcut, even though properties display color range as full
Please do not post any more bug reports in this thread. This thread is not concise enough for a bug report, and I am no longer reader everything within it. Luckily, I caught this and looked into it. Unfortunately, it appears swscale does not convert range while also converting bit depth. So, that means MLT will have to be modified to do two passes: once to convert bit depth and second the range.
A scope program should under no circumstances alter the levels of the file under test (FUT). It should measure and report the true levels in the file. This means that the scope does not adapt based on the flagging, IOW the limited/full flag is ignored by the scope.
As far as the graticule (scale) is concerned, 8-bit values are unambiguous. If you want IRE units, 235 is 100 and 16 is 0 when working with BT.709.
I tried changing the color range of the ffplay scope and was unable to, which is as it should be.
Are you referring to the ffplay scope or the Shotcut scope?
I disagree - “Clip” implies truncation; “clamp” implies squishing
eg. When you clip an audio waveform or clip your hair, you cut data off ; when you “clamp” something, like a screw clamp or other clamp tool - you’re squishing it
Yes ideally it shouldn’t change the levels ; but it usually doesn’t matter for the waveform because that’s the end node for that branch. You don’t use that waveform display for anything else. The actual data is in a separate branch
I was going to ask ; because the only convoluted workaround to keep full range without “clamping”, or going through the RGB work around (both add additional quality loss) that I could figure out was to assign “limited” in properties before exporting + color_range=pc in the “other” export tab
I can ctrl+a to select all clips on the timeline, but you can’t change the color range in the properties panel for all clips. Even though all clips are highlighted red in the selection, only the one clicked on will change in the properties panel… so you do it one by one. … ughh but it works. Or is there another smarter/faster way to do that ?
got it
Yes, and that’s what shotcut is doing. For -vf waveform, moving the adjust the IRE graticules that Austin and Dan suggested would be a better idea. Paul/richardpl is one of the original authors of the -vf waveform, you can see what he thinks
That’s true it shouldnt change the levels, but a possible workaround if you needed to satisfy a requirement would be to change the actual levels . A separate node (2 branches, 1 is the “display”, 1 is the real data which is unchanged). But to change the color range - you would have to apply a filter before the input of the scope. ffplay is a bit “finicky” with filters, but you can do this by piping ffmpeg to ffplay
This is the way it’s done in some nodal editors; you have different branches and viewers and scopes that you can plug into different parts of the process.
It shows up on Shotcut IRE waveform; but the issue is the underlying handling of full range flagged 10bit files
I understand your point, and I agree with more general purpose usage of the term. There is a common programming function clamp that does limiting without scaling values, and that is what I tend to think of. In that context when you clamp full range to limited it simply makes values under/over a threshold equal to that threshold. But in digital video color range conversion expands or contracts all of the values.
I see how that can be a problem; clamping = clipping from that perspective . I will no longer use “clamping”. Range expansion /contraction is better phrasing, less ambiguous .
Agreed… for scopes that measure levels in a file.
IRE does not visualize levels in a file.
IRE is an analog unit that measures voltage on an electrical wire. Since limited Y 235 and full Y 255 produce the same voltage on an electrical wire (700 mV reference white point), both those values should be 100 IRE. The values of the digital data are irrelevant. All that matters is the final voltage hitting a wire.
Agreed… for a scope that measures levels in a file.
IRE does not visualize levels in a file.
It measures voltage. Since the sRGB and BT.709 specs happen to put black at 0 mV and white at 700 mV, the 0-100 IRE range is implicitly tied to the black and white reference points. In order to know whether a Y value represents black/gray/white, it has to be interpreted in the context of the range flag. Therefore, the scope must adapt itself based on the range to calculate what final voltage will hit an electrical wire.
IRE is completely different from a digital waveform.
Only in limited range. Full range would be 0 and 255 because full Y 255 is the same white as limited Y 235, therefore it should get the same IRE value.
With IRE, the graticules are usually 0% and 100% because IRE is a percentage, not an absolute value. The only way it would make sense to move a percentage graticule is to represent the black and white points for a format that puts black somewhere other than 0% (like composite video where black is 7.5%). However, even if we were to do that, nothing changes because limited Y 235 and full Y 255 are the same white and land on the same voltage and the same IRE/percent. Since the IRE is the same for both ranges, there’s no other sensible place to move the graticules. They already represent the black and white points for both BT.709 and sRGB without any movement at all. Limited and full are two different ways of specifying the exact same color, therefore they will have exactly the same placement on an IRE scope.
IRE measures only the final result, not the path taken to get there. This makes it intrinsically different than a digital waveform.
For a digital waveform, yes, it can make sense to move the graticules to represent the black and white points depending on the range.
That’s a nice explanation, Austin
What would you suggest in the -vf waveform IRE case ?
a) Range compression based on flag detection (similar to what shotcut is doing)
b) Limited Y 16-235 = 0-100 IRE . Full Y 0-255 = 0-100 IRE . Based on flag detection
c) Limited Y 16-235 = 0-100 IRE . Full Y 0-255 = 0-100 IRE . 2 user switches, IRE limited vs. IRE full
(And it would be up to the user to ensure prerequisites are met in all cases)
Wait a minute, Austin. You’re talking out of both sides of your mouth. After posting that you posted this:
So which is it, percentage or voltage?
Can you produce any documentation that says IRE units are used in 0 - 255 sRGB, i.e. anything other than BT.601 or BT.709?
For ITU-R BT.709 there is no full range video. ITU-R BT.709 table 4.6 only defines a narrow range signal. It does allow overshoots in the range 1-253, but black is defined as 16 and white as 235.
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.709-6-201506-I!!PDF-E.pdf
If you are going to use black at 0 and white at 254, it is not standards compliant and it will require slightly different colour matrices.
Full-range has multiple meanings in different organisations. The EBU in Europe have recently published this discussion on the topic: https://tech.ebu.ch/docs/r/r103.pdf
This has already been covered extensively. Table 4.6 only applies to the broadcast half of the color transformation pipeline. But the YCbCr/RGB color conversion formulas in table 3.5 operate in full range, and these values can be written directly to a computer file and played back successfully in any competent media player. It is not “standards compliant” in terms of broadcast, but it is 100% standards compliant in terms of BT.709 as a color space. BT.709 is both a color space definition and a broadcast standard. This is why ffmpeg has a -colorspace bt709 flag… because BT.709 is a stand-alone color space for color processing. The color space portion can be used without legalizing values for broadcast. Otherwise, there would be no such thing as a full-range YCbCr file that all media players can play. And yet, they can. Everyone is aware of cameras that write full-range YCbCr files and they are correctly interpreted by all major video editors. It works because BT.709 is also a color space that can operate completely independent of broadcast requirements.
Full range is the “real” BT.709 and limited range is just a hack to get full range through the broadcast pipeline (and to provide room for sync signaling of analog televisions). If BT.709 delivery was entirely digital (no need to add buffer for frequency separation or to sync a CRT), then limited range math would have no need to exist and the world would be a less confusing place, just like sRGB.
IRE is a percentage of maximum protocol voltage. This was covered extensively in my first post. For BT.709, the protocol maximum is 700 mV. So if somebody puts a voltmeter on an electrical wire carrying a BT.709 signal and reads 350 mV, then that is 50% of the maximum possible and is called 50 IRE.
IRE is an electrical concept, not a television concept. It can be applied to any electrical signal. It is not specific to BT.709 or any other wire protocol. In that sense, documentation is not necessary because IRE is implicitly a unit of measure for any electrical signal.
However, to your point, IRE is not traditionally used to scope sRGB signals because it is a more consumer-oriented format that doesn’t have the strict boundaries of broadcast. When people want to calibrate sRGB color, they calibrate the screen itself with a colorimeter and don’t worry about the values going over the DVI/HDMI/DisplayPort cable because those values are digital, not analog. Thus, a digital waveform makes more sense for sRGB. So, to compare sRGB and BT.709 on the same IRE scope, we have to pretend sRGB is going over a VGA cable because VGA actually is an analog specification that was purposefully designed to match the 700 mV white point of BT.709. This concept was documented in the sources of my first post.
That is the million dollar question for all of us. 
Paul B. Mahol has already gone clear off the board for Option D, “stay the same as hardware scopes even if hardware shows wrong results because it wasn’t designed for full-range video”. Given the operating environment of ffmpeg, I can totally respect this direction. It would be nice if this disclaimer was included in ffmpeg-all documentation so the unaware user knows what to expect from the IRE values.
This would be my personal preference. When a user pumps a video through the pipeline, the scope results will automatically be correct without any user intervention or knowledge. For full diagnostics ability, it could be useful to have full/limited override flags to the auto detection, as you suggested in Option C. That would be a productive blend.
Since ffmpeg has access to source videos (whereas the Shotcut scope only has access to timeline output), it would be nice to take advantage of the exact input file format for diagnostic purposes, meaning Option A (range compress everything to limited) would make me hesitant. However, it would still be “correct enough” and I wouldn’t lose sleep over it.
For me, I could be 100% content with a simple addendum to the ffmpeg documentation that said “the IRE scope always assumes the max possible voltage is based on limited-range Y values, and will show incorrect IRE for full-range video”.
What kind of double talk is that? BT.709 is a digital standard. Analog televisions have nothing to do with it.
No wonder prosumer digital video is all screwed up. You’re making me cringe, buddy, with some of your inaccurate statements and tortured metaphors. Sorry if this sounds harsh.
I’m out of this discussion of Shotcut’s video scope. You guys rationalize it whatever way you please.
I still waiting on proof/input what hardware scope or ScopeBox does in such case.
I have started to map some of the information from this post to these topics:
Feedback or contributions are welcome.
Some people are uncomfortable with the term “IRE unit”, feeling it is obsolete. Call it “percent” if you are more comfortable with that. Either way it measures the same thing: the percentage of the range between digital 16 and 235 (or 0 and +0.714 volts analog). What it is NOT is a unit of voltage.