ffmpeg Color Range

[poisondeathray]

Another question: there's a way to probe the source file in order to get the exact input range ?

But if it's just a quick testing to get feedback, to help debug your commandline, you could use ffplay with -vf waveform . You can check each channel individually or together

[chris319]

It turns green ,and the output Y range is 1-235

I can corroborate this.

It turned RGB 111-111-111 to RGB 96-113-93.

RGB 255-255-255 turned to 239-255-237.

RGB 235-235-235 turned to 219-237-217.

RGB 0-0-0 turned to 0-5-0.

Also, I was getting some odd results testing lutrgb clip so I rewrote my script using colorlevels as follows:

ffmpeg  -y  -i "C0015.mp4"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf scale=in_color_matrix=bt709:in_range=full,format=yuv422p,scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv422p,colorlevels=romax=0.85:gomax=0.85:bomax=0.85:romin=0.076:gomin=0.076:bomin=0.076  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  output.mxf

[chris319]

Another question: there's a way to probe the source file in order to get the exact input range ?

The way I do it is to start with a "test signal" of known values which (I hope) I have attached. I then use an eyedropper program to check colors.

You will need a video player which does not alter your video levels, such as Pot Player with the range 16 - 235 mapped to 16 - 235.

I also have that program which scans an entire video file and reports the max/min levels.

[chris319]

I am AFK at the moment but can elaborate on how to configure Pot Player if you need me to.

As noted elsewhere, most video players raise video at RGB 235-235-235 to RGB 255-255-255. This makes them useless for performing serious video measurement. I could not find a way to defeat this behavior in VLC or MPC-BE. I would be interested in hearing about other video players besides Pot Player that can be so configured.

[_Al_]

So you need to encode a video to find out what resulting values are? Change - encode - check, again, change - encode - check.
That is not very efficient.

You can make a player yourself. Pipe you video (if piping it from ffmpeg as you insist to be hard on yourself) to opencv (for your language, C++, whatever you use).
Use your code to get RGB, limit RGB whatever.
Then pop frame on screen using opencv. Make one key dedicated to return RGB values if pressed for mouse coordinates and print them.
Those are basics for opencv. I will not help you, only with Python, but I'm sure it works with C++ or C, there is no reason why that would not work.

You cannot do a serious work and wait for encode to analyze what you've got.

[chris319]

With and without lutrgb:

Window signal:
Patch #1: RGB 0-0-0
Patch #2: RGB 235-235-235
Patch #3: RGB 255-255-255

SCRIPT #1 (includes lutrgb)

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf format=rgb24,scale=in_color_matrix=bt709:in_range=full,"lutrgb=r='clip(val,36,210)':g='clip(val,36,210)':b='clip(val,36,210)'",scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  clipped.mxf

Output: RGB 0-0-0,255-255-255,255-255-255 (middle patch elevated from 235 to 255; whites not clipped at 210; blacks not clipped at 36)

Am I doing something wrong?

SCRIPT #2 (removed lutrgb)

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf format=rgb24,scale=in_color_matrix=bt709:in_range=full,scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  clipped.mxf

Output: RGB 0-0-0, 235-235-235, 255-255-255 (same as input file)

[poisondeathray]

With and without lutrgb:

Window signal:
Patch #1: RGB 0-0-0
Patch #2: RGB 235-235-235
Patch #3: RGB 255-255-255

SCRIPT #1 (includes lutrgb)

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf format=rgb24,scale=in_color_matrix=bt709:in_range=full,"lutrgb=r='clip(val,36,210)':g='clip(val,36,210)':b='clip(val,36,210)'",scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  clipped.mxf

Output: RGB 0-0-0,255-255-255,255-255-255 (middle patch elevated from 235 to 255; whites not clipped at 210; blacks not clipped at 36)

Am I doing something wrong?

SCRIPT #2 (removed lutrgb)

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf format=rgb24,scale=in_color_matrix=bt709:in_range=full,scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  clipped.mxf

Output: RGB 0-0-0, 235-235-235, 255-255-255 (same as input file)

WindowSignal.mkv is encoded as RGB 0,0,0 , 235,235,235 and 255,255,255 . The border is grey RGB 111,111,11

It will decode as RGBP (RGB planar) , but RGBP<=>RGB24 is lossless

The 2nd one takes RGB input and encodes it full range YUV, but tags it limited range YUV . So you get YUV 0,128,128 , 235,128,128, 255,128,128 . Border becomes 111,128,128 . This is expected because full range equations map Y [0,255] <=> RGB [0,255]

"matrix" only applies when you do RGB<=>YUV conversions.

But in_range and out_range can scale the levels. limited is default. If you don't specify something it selects default. So prior to lutrgb, you actually have a full range to limited range conversion in RGB. RGB 0-255 gets scaled to RGB 16-235 before lutRGB is applied. This is why you get the change in contrast

In the other examples, you were starting with YUV , then controlling the conversion to RGB, by applying full range 709 equations before lutRGB. Here, you are starting in RGB.

in_range=full:out_range=limited

What you probably wanted to do is clip the direct RGB input levels, instead of changing the values before lutRGB . Just delete the arguments before lutrgb. You have direct RGBP input, and I'm assuming you want those clip values to affect the input R,G,B levels

-vf "lutrgb=r='clip(val,36,210)':g='clip(val,36,210)':b='clip(val,36,210)'",scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p

That will give you YUV 36,128,128 , 210,128,128, 210,128,128, and border of 111,128,128 . I'm assuming that's what you wanted

[chris319]

I hope I understood your advice correctly.

This puts the middle patch at 255 instead of 235. The right patch is 255, not 210. The left patch is 0, not 36. The background is 109. All RGB measurements.

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf "lutrgb=r='clip(val,36,210)':g='clip(val,36,210)':b='clip(val,36,210)'",scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  clipped.mxf

[poisondeathray]

I hope I understood your advice correctly.

This puts the middle patch at 255 instead of 235. The right patch is 255, not 210. The left patch is 0, not 36. The background is 109. All RGB measurements.

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf "lutrgb=r='clip(val,36,210)':g='clip(val,36,210)':b='clip(val,36,210)'",scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  clipped.mxf

Is "windowSignal.mkv" the same one posted earlier ?

That will give you a MXF with YUV values of 36,128,128 , 210,128,128, 210,128,128, and border of 111,128,128

Notice the values coincide with your clip values in RGB, because you're using full range equation to convert to YUV.

So when convert that MXF to RGB (for display) using full range equation you should get RGB 36,36,36 , 210,210,210, 210,210,210 , and border of 111,111,111 . Notice again the Y value coincides with the RGB value , since full range equations are used

[chris319]

So when convert that MXF to RGB (for display) using full range equation you should get RGB 36,36,36 , 210,210,210, 210,210,210 , and border of 111,111,111 .

Am I not doing that already? This is from my script:

out_range=full

[poisondeathray]

So when convert that MXF to RGB (for display) using full range equation you should get RGB 36,36,36 , 210,210,210, 210,210,210 , and border of 111,111,111 .

Am I not doing that already? This is from my script:

out_range=full

No,

The MXF is the output file. That's YUV yuv420p according to that commandline (it's usually 422 for broadcast mpeg2, xdcamhd422 spec) . But the MXF is what is submitted. It's YUV not RGB.

When you "see" something on a display , you're not viewing YUV. It's converted to RGB for display purposes. You're not converting the actual file, you're just converting a preview of the video to RGB. On a computer, you normally use the limited range equations. Here you are using the full range equations, because you want studio range RGB.

To do that, you can use one of the methods described a few posts earlier , mpv, ffplay etc...

eg. ffplay

ffplay -i clipped.mxf -vf scale=in_color_matrix=bt709:in_range=full

[chris319]

I don't use ffplay.

I recently recalibrated my scopes to match Pot Player. Why? When properly set up, Pot player does not alter video levels by making 235 into 255. Now the same video played back on my scope program has the same levels as when played back on Pot Player. Previously, I was making level measurements using MPC-BE. This was inaccurate because it was "forcing" 235 to 255.

the MXF is what is submitted. It's YUV not RGB.

The r103 spec is for RGB levels (5 - 246).

[poisondeathray]

I recently recalibrated my scopes to match Pot Player. Why? When properly set up, Pot player does not alter video levels by making 235 into 255. Now the same video played back on my scope program has the same levels as when played back on Pot Player. Previously, I was making level measurements using MPC-BE. This was inaccurate because it was "forcing" 235 to 255.

So are you getting the matching numbers ?

the MXF is what is submitted. It's YUV not RGB.

The r103 spec is for RGB levels (5 - 246).

Yes, and you're submitting YUV, not RGB

We've been over this 100 times. You're going backwards again.

The r103 QC check converts using studio range RGB for the gamut check . If your gamut check is >1% illegal pixels it gets flagged. It's in the r103 specs. They also prefilter before they measure. Also in the document.

The ffplay check (or whatever method you choose) is just simulating what the broadcast QC check is using, when you stipulate full range equations. It's conservative because it's not applying the same prefilter . And it doesn't measure %, so you have no idea if it will pass or not

[chris319]

So are you getting the matching numbers ?

Absolutely!

you're submitting YUV, not RGB

Right.

The r103 QC check converts using studio range RGB for the gamut check .

My scope programs convert YUV to RGB.

Filtering is a recommendation, not a requirement. Video will not be bounced for lack of filtering.

Likewise the 1% of picture area is a recommendation, not a requirement:

the EBU further recommends that
 measuring equipment should indicate an “Out-of-Gamut” occurrence only after the error
exceeds 1% of an integrated area of the active image.

They won't bounce a video if the levels are within the 5 - 246 limits.

I still haven't got lutrgb doing what I want, which is to clip RGB to 5 - 246 without altering video at levels within the clip range of 5 - 246. IOW, the values 0 - 4 should be clipped at 5 and 247 - 255 at 246. Video at, say, 235 should be left there.

[poisondeathray]

Filtering is a recommendation, not a requirement. Video will not be bounced for lack of filtering.

Likewise the 1% of picture area is a recommendation, not a requirement:

the EBU further recommends that
 measuring equipment should indicate an “Out-of-Gamut” occurrence only after the error
exceeds 1% of an integrated area of the active image.

Everything is a "recommendation". Everything falls under "the EBU recommends that," ...

The QCer or client can choose to implement some or all of the recommendations, or set their own limits and rules

It's the QCer that applies a filter before measuring. It reduces the % of illegal pixels, it's basically a low pass filter. There are 2 versions for EBU r103, 2000, 2016. It's just a recommendation like everything else. Some places might not apply it, but it's recommended

The QCer can setup custom limits or setting according to what their requirements are. Maybe 2% is the number at one place, maybe 0.5% at another. But 1% is recommended

They won't bounce a video if the levels are within the 5 - 246 limits.

Depends on what they are actually using - Everything in that table is a recommendation . 5-246 is a recommendation. You can set custom limits in the QC check. Maybe another client wants 10-239.

You can be conservative, but a video that is within those limits can still be rejected for a hundred other reasons e.g. missing slate info, crushed or burned areas (loss of shadow/ highlight details) , audio clipping, wrong mxf container essence, title safe excursion, etc... hundreds more... There are generally 3 categories - mandatory, technical, editorial ; and the EBU check is just a small part of the QC technical portion of the check.

I still haven't got lutrgb doing what I want, which is to clip RGB to 5 - 246 without altering video at levels within the clip range of 5 - 246. IOW, the values 0 - 4 should be clipped at 5 and 247 - 255 at 246. Video at, say, 235 should be left there.

If you clip in RGB to 5-246 that's what you have RGB 5-246. RGB 235 will not be touched , if it started at RGB 235 before lutrgb, it will be RGB 235 directly after lutrgb

But after lutrgb clipping, when you convert to YUV and subsample, you will get some 0's and 255's on most types of content. This is normal and expected. You're doing operations AFTER you clip in RGB. You're changing the values. This was all explained earlier. The % is what is important, and tells you if you need to take farther action.

If you submitted RGB and it was a format they were willing to accept - everything would be easy for this portion. No need to worry about % pixels

[_Al_]

I still haven't got lutrgb doing what I want, which is to clip RGB to 5 - 246 without altering video at levels within the clip range of 5 - 246. IOW, the values 0 - 4 should be clipped at 5 and 247 - 255 at 246. Video at, say, 235 should be left there.

So after months of explanations, programs, workflows that give you visual feedback and simple graphics to see on your own what's happening that it can't be and it is also video specific, that it is how RGB to YUV works and still hearing that from you is quite uneasy.

If you set 0-4 to 5 and 246 to 255 to 246 then only those values are adjusted, not others. When you convert video back to YUV and then again to RGB to view it, you end up with some % of illegal values again. That 103 specs even talk about that specifically. Conversion of YUV to RGB are not simply mapped, for example green RGB value is:
G = weird_constant1 * Y - weird_constant2 * U - weird_constant3 * V - weird_constant4
and that possibly introduces illegal R, G or B again,
you are looking for a ghost, you can reduce it, but that will cost you changing different levels or blurring especially if you do it for the whole video , not per scene evaluation

[chris319]

How is it that I get incorrect colors when lutrgb is in the script and perfect colors when it is not?

See post #246 in this 9-page thread to refresh your memory:

https://forum.videohelp.com/threads/395939-ffmpeg-Color-Range/page9#post2578594

The script below contains lutrgb and gives erroneous results as I described in detail in post #246:

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf format=rgb24,scale=in_color_matrix=bt709:in_range=full,"lutrgb=r='clip(val,36,210)':g='clip(val,36,210)':b='clip(val,36,210)'",scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  clipped.mxf

This script gives perfect results. Exact same script with lutrgb eliminated. Aside from the absence of lutrgb, what difference do you see between the two scripts? How do you account for the fact that one gives perfect colors and the other doesn't, the only difference being the presence or absence of lutrgb?

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf format=rgb24,scale=in_color_matrix=bt709:in_range=full,scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  clipped.mxf

[poisondeathray]

How is it that I get incorrect colors when lutrgb is in the script and perfect colors when it is not?

See post #246 in this 9-page thread to refresh your memory:

https://forum.videohelp.com/threads/395939-ffmpeg-Color-Range/page9#post2578594

The script below contains lutrgb and gives erroneous results as I described in detail in post #246:

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf format=rgb24,scale=in_color_matrix=bt709:in_range=full,"lutrgb=r='clip(val,36,210)':g='clip(val,36,210)':b='clip(val,36,210)'",scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  clipped.mxf

This script gives perfect results. Exact same script with lutrgb eliminated. Aside from the absence of lutrgb, what difference do you see between the two scripts? How do you account for the fact that one gives perfect colors and the other doesn't, the only difference being the presence or absence of lutrgb?

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf format=rgb24,scale=in_color_matrix=bt709:in_range=full,scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  clipped.mxf

The difference is lutrgb and the clip values


You're starting with RGB 0,0,0 , 235,235,235 and 255,255,255 (The border is grey RGB 111,111,111) .

When you apply lutRGB and clip RGB 36-210 , all values below 36 and above 210 are cut off. That's what clipping does. If a value is within 36-210, it remains untouched.

So directly after lutRGB, you would expect RGB 36,36,36 (because 0 is clipped to 36) , 210,210,210 (because 235 is clipped to 210) , and 210,210,210 (because 255 is clipped to 210) . (The border is still RGB 111,111,111 , because it's within 36-210)

A full range conversion to YUV would give you YUV 36,128,128 , 210,128,128 , and 210,128,128 (border YUV 111,128,128) . That's your MXF.



If you convert back to RGB using full range equations for the preview (using ffplay, or potplayer or whaetver method) , to emulate the studio RGB range conversion, you would expect RGB 36,36,36 , 210,210,210, and 210,210,210 (the border is still RGB 111,111,111)

And if you break down each of the steps, check, that's what you get

[chris319]

If you convert back to RGB using full range equations for the preview (using ffplay, or potplayer or whaetver method) , to emulate the studio RGB range conversion, you would expect RGB 36,36,36 , 210,210,210, and 210,210,210 (the border is still RGB 111,111,111)

Those are not the results I'm getting! As I have already said in post #246:

Output: RGB 0-0-0,255-255-255,255-255-255 (middle patch elevated from 235 to 255; whites not clipped at 210; blacks not clipped at 36)

As you said, I'm expecting 36-36-36, 210-210-210, 210-210-210.

Instead I'm getting RGB 0-0-0, 255-255-255, 255-255-255.

Once again, for emphasis:

middle patch elevated from 235 to 255; whites not clipped at 210; blacks not clipped at 36

[poisondeathray]

If you convert back to RGB using full range equations for the preview (using ffplay, or potplayer or whaetver method) , to emulate the studio RGB range conversion, you would expect RGB 36,36,36 , 210,210,210, and 210,210,210 (the border is still RGB 111,111,111)

Those are not the results I'm getting! As I have already said in post #246:

Output: RGB 0-0-0,255-255-255,255-255-255 (middle patch elevated from 235 to 255; whites not clipped at 210; blacks not clipped at 36)

In a later post #254, I asked if you were getting matching numbers, you said "absolutely"

So are you getting the matching numbers ?

Absolutely!

So which is it ?


This is the same commandline, I just edited so no audio, and 1 frame. "clipped1.mxf" attached (in a .zip file because forum doesn't like .mxf apparently)

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf format=rgb24,scale=in_color_matrix=bt709:in_range=full,"lutrgb=r='clip(val,36,210)':g='clip(val,36,210)':b='clip(val,36,210)'",scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -an  -frames:v 1 -f  mxf  clipped1.mxf

clipped1.mxf has YUV 36,128,128 , 210,128,128 , and 210,128,128 (border YUV 111,128,128) if you check with a YUV picker or waveform monitor . As expected

Converting to RGB using full range equation for the preview (with whatever method)

eg. ffplay

ffplay -i clipped1.mxf -vf scale=in_color_matrix=bt709:in_range=full

you get RGB 36,36,36 , 210,210,210, and 210,210,210 (the border is still RGB 111,111,111)

You can check with multiple methods, they confirm the same thing. Maybe your player reset or you have some other filter enabled ?

So where is the problem ? Your player configuration ?

[chris319]

It works! I get 35 and 212 for the black and white; close enough. Background is 111.

Yours has an added in_range=full which mine didn't have.

Thanks much for doing that!

[poisondeathray]

It works! I get 35 and 212 for the black and white; close enough. Background is 111.

Yours has an added in_range=full which mine didn't have.

Thanks much for doing that!

You have it too. I copy / pasted

It doesn't do anything anyways. You started in RGB and filtering in RGB. You can omit everything after -vf and before lutrgb and get the same thing. This produces the same thing

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf "lutrgb=r='clip(val,36,210)':g='clip(val,36,210)':b='clip(val,36,210)'",scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -an  -frames:v 1 -f  mxf  clipped1_1.mxf

Greyscale values should be +/- 0 for this . ie. Perfect. Because Y = R,G,B . 0-255 gets mapped to 0-255.

Consider using a different checking method, like ffplay , mpv or anything in the list in the eariler post which are verified to be accurate

[chris319]

All measurements RGB

Clip levels in script: 36, 210

Pot Player: 35, 212, background: 112 (original 111)

mpv player: 23, 226, background: 111 (original 111)

ffplay: same as mpv player.

Pot Player seems to be "less inaccurate" than mpv or ffplay.

[poisondeathray]

All measurements RGB

Clip levels in script: 36, 210

Pot Player: 35, 212, background: 112 (original 111)

mpv player: 23, 226, background: 111 (original 111)

Pot Player seems to be "less inaccurate" than mpv.

ffplay: same as mpv player.

Probably you didn't follow the instructions

Converting to RGB using full range equation for the preview (with whatever method)

eg. ffplay

ffplay -i clipped1.mxf -vf scale=in_color_matrix=bt709:in_range=full

you get RGB 36,36,36 , 210,210,210, and 210,210,210 (the border is still RGB 111,111,111)

https://forum.videohelp.com/threads/395939-ffmpeg-Color-Range/page7#post2577731

1) You can use mpv or one of it's derivatives. Accurate player, including 10bit formats. There are many mpv projects and forks and it's highly customizable

mpv input.ext --video-output-levels=limited

In this case you want the output levels as "limited", because it's applying a studio range RGB conversion (RGB 16-235, white to black ; instead of computer RGB, or 0-255 white to black). It's also called limited range RGB in some places

If you're going to be using this scenario frequently, you can make a batch file , maybe save to a handy location like desktop, where you can drop a video onto it to play (save a text file, rename the .txt extension to .bat)

mpv %1 --video-output-levels=limited

you get RGB 36,36,36 , 210,210,210, and 210,210,210 (the border is still RGB 111,111,111)

[chris319]

If Pot Player isn't giving me accurate levels then I'll have to avoid using it for level measurement.

[chris319]

Pot Player is less accurate than ffplay, mpv and my scope program, which are all spot on.

[forart.it]

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf "lutrgb=r='clip(val,36,210)':g='clip(val,36,210)':b='clip(val,36,210)'",scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -an  -frames:v 1 -f  mxf  clipped1_1.mxf

Greyscale values should be +/- 0 for this . ie. Perfect. Because Y = R,G,B . 0-255 gets mapped to 0-255.

Consider using a different checking method, like ffplay , mpv or anything in the list in the eariler post which are verified to be accurate

...so, is this the DEFINITIVE command line to "legalize" raw shootings ?

[poisondeathray]

ffmpeg  -y  -i "windowSignal.mkv"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf "lutrgb=r='clip(val,36,210)':g='clip(val,36,210)':b='clip(val,36,210)'",scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv420p  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -an  -frames:v 1 -f  mxf  clipped1_1.mxf

Greyscale values should be +/- 0 for this . ie. Perfect. Because Y = R,G,B . 0-255 gets mapped to 0-255.

Consider using a different checking method, like ffplay , mpv or anything in the list in the eariler post which are verified to be accurate

...so, is this the DEFINITIVE command line to "legalize" raw shootings ?

No . It's a specific case where he wanted extreme clipping .


https://forum.videohelp.com/threads/395939-ffmpeg-Color-Range/page6#post2577306


You wanted something like Levels(0, 16, 255, 16, 235, coring=false) in avisynth . This is wrong BTW, the gamma should be 1 . You probably meant Levels(0, 1, 255, 16, 235, coring=false). This is fine if your clip starts as Y 0-255

But this is not a good way to "auto" do things. If you started with a normal range clip y=16-235, you will mess the levels and contrast . You will end up with Y 30-218 . There is no logic applied, such as clamp only if values are above a certain level. It applies the same clamp everywhere, by the same amount.

You posted a sample clip of someone on the drums and the black level is ~ 24-28 . So the clip is not 16-255. It's closer to about 25-255. So if you applied Levels(0, 1, 255, 16, 235, coring=false) , you will push the white level correctly to 235, but the black level to about Y=40 , since you started with ~25 (ie. you will get ~ 40-235) and it will look washed out . "Legal", but will get rejected for the wrong black level

[chris319]

I have rethought the application of r103.

It seems that once chroma subsampling has been applied (4:2:0 or 4:2:2), as the deliverables are required to have, it becomes impossible to accurately measure the levels of the individual R, G and B channels.

It's true that Y = R*Kr + G*Kg + B*Kb (this equation is taken from BT.709), so as long as Y <= 246 and >= 5, the RGB values should also be in this range before subsampling, so my interpretation of r103 is that Y <= 246 and >= 5. 16 - 235 is within this range. I've decided to forget about the RGB levels once subsampling has been applied. Trying to squeeze R,G and B into the 5 - 246 range after subsampling robs the picture of contrast and just looks ugly. So now my thinking is that if Y is in the range 5 - 246 then it's legal. You may want to check with your broadcaster first by submitting a sample. Some broadcasters go no further than to require Y in the range 16 - 235.

A lot depends on how the video is played back. It makes a difference regarding Y levels to use ffplay in full range as pdr has suggested:

ffplay -i clipped1.mxf -t 10  -vf scale=in_color_matrix=bt709:in_range=full

So here is the code I would now use to make an OP-1a file. Note that no clipping is performed. This is for progressive scan only:

ffmpeg  -y  -i "C0015.mp4"  -c:v mpeg2video  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M  -q:v 0  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5b  -non_linear_quant 1  -g 15  -bf 2  -profile:v 0  -level:v 2  -vf scale=in_color_matrix=bt709,format=yuv422p,scale=w=1280:h=720:out_color_matrix=bt709  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -ar 48000 -c:a pcm_s16le  -ac 2  -f  mxf  clipped1.mxf

My camcorder outputs 1080p so I added scale=w=1280:h=720.

[poisondeathray]

I have rethought the application of r103.

It seems that once chroma subsampling has been applied (4:2:0 or 4:2:2), as the deliverables are required to have, it becomes impossible to accurately measure the levels of the individual R, G and B channels.

Of course it's possible, this is what all the broadcast checkers and legalization plugins do. It's just not possible with ffmpeg (or at least not very easily). Min/max values alone are next to useless in this scenario; you need a % readout of illegal pixels. You're simulating what the broadcast checker does before you submit it. _Al_ vapoursynth script can do it for free

It's true that Y = R*Kr + G*Kg + B*Kb (this equation is taken from BT.709), so as long as Y <= 246 and >= 5, the RGB values should also be in this range before subsampling, so my interpretation of r103 is that Y <= 246 and >= 5. 16 - 235 is within this range. I've decided to forget about the RGB levels once subsampling has been applied. Trying to squeeze R,G and B into the 5 - 246 range after subsampling robs the picture of contrast and just looks ugly. So now my thinking is that if Y is in the range 5 - 246 then it's legal. You may want to check with your broadcaster first by submitting a sample. Some broadcasters go no further than to require Y in the range 16 - 235.

No, because there are potentially millions of illegal gamut values that lie in the middle of the range. I already mentioned this many times eg.
https://forum.videohelp.com/threads/395939-ffmpeg-Color-Range/page8#post2577774

Straight out of your camera, even if it's Y16-235, CbCr 16-240. Illegal YUV combinations that result in RGB 0 or 255. By definition, those are not r103 compliant. You need to know what % is affected.

Either clipping or clamping Y16-235, CbCr 16-240 does not catch those. Converting to RGB then mild clipping is a crude way of eliminating those values. Yes, some come back because of converting back to YUV and subsampling, but you reduce that % significantly . If you had stayed YUV all the way through your % will be higher

A lot depends on how the video is played back. It makes a difference regarding Y levels to use ffplay in full range as pdr has suggested:

ffplay -i clipped1.mxf -t 10  -vf scale=in_color_matrix=bt709:in_range=full

This is what r103 uses, studio range RGB . You're simulating the broadcast checker. The only variable here is what chroma upsampling method is used for the RGB conversion (by default ffplay will use bicubic) . Different algorithms will result in slightly higher or low % of illegal values. The QCer usually applies a pre check filter, so their actual readout is lower than this