ffmpeg Color Range

[poisondeathray]

eg. "Red" is YUV 50,108,211

Red is supposed to be:
51-109-212

So we're one point off.

You're going to have a degree of floating-point error when doing these calculations. It's inevitable and not worth fussing over.

You can do it with 8bit RGB => YUV conversion. That's the whole point of rp219. They give exact YUV values for 10 and 12 bit too

And it's definitely possible when adding youtube compression on top with ffmpeg using 8bit, I just checked.

Not a big deal; but if you can have perfect specs, why not use perfect specs ?

What is 0-255 ? RGB or YUV ?

RGB, which as I said should be limited to 5 - 246.

Verify the direct output of your program and into ffmpeg while still in RGB, write out a BMP and check the RGB levels

Already done. The levels are checked internally, before writing the output file, and the levels are what I expect.

You send RGB 5-246, but the BMP written by ffmpeg is 0-255 ?

Are you sure you're not doing other stuff before ffmpeg step ?

Or maybe there are issues with the internal check ? or some other assumptions need rechecking?



or why don't you just clip in FFmpeg ? lutrgb ?

[chris319]

You can do it with 8bit RGB => YUV conversion. That's the whole point of rp219.

Why don't you write a patch for ffmpeg's x265 encoder that eliminates the floating-point error? It was used to convert the bmp image to mp4.

Get YouTube to use your encoder, too.

[poisondeathray]

You can do it with 8bit RGB => YUV conversion. That's the whole point of rp219.

Why don't you write a patch for ffmpeg's x265 encoder that eliminates the floating-point error? It was used to convert the bmp image to mp4.

Get YouTube to use your encoder, too.

You don't need a patch. It's already accurate

I used ffmpeg libx264, there is no floating point error . I doubt x265 has one either

You just encode the bmp or png normally using 191 bars. 75% for 0-255 RGB. Use limited range 709 conversion. (ie. a "normal" everyday conversion)

something like this

ffmpeg -r 24 -loop 1 -i 191bars.png -vf scale=out_color_matrix=bt709,format=yuv420p -c:v libx264 -crf 16 -t 10 -an test191.mp4

Didn't you verify with the spreadsheet yesterday ? Did you need to use floating point there?

Anyways, youtube didn't kill it either; YUV values match rp219 exactly when you download the video

Accuracy is the supposedly the point of rp219 and color bars in general. If you can get 100% perfect just using ffmpeg normally using 8bit, then why not ?



I already mentioned above - but if you used 180,16,16 , 75% for 16-235, values are slightly off using existing full range 709 conversion routines as-is. You need that levels workaround to get it matching.

[chris319]

if you used 180,16,16 , 75% for 16-235, values are slightly off using existing full range 709 conversion routines as-is. You need that levels workaround to get it matching.

180-16-16 is ancient history; we're way past that and on to 191-0-0. I thought I made that clear in an earlier post.

The actual colors don't make a difference anyway, as long as the color out matches the colors in the original bmp. You could use 64-180-200 but you want to see that color on the output.

[chris319]

I used your code and got the same +/- 3 floating-point errors. Tried it in several players including (MPC-BE). All of the colors are perfect in "test_pattern_709.bmp".

ffmpeg  -y    -r 24 -loop 1 -i "test_pattern_709.bmp" -vf scale=out_color_matrix=bt709,format=yuv420p -c:v libx264 -crf 16 -t 10 -an test191.mp4

[poisondeathray]

if you used 180,16,16 , 75% for 16-235, values are slightly off using existing full range 709 conversion routines as-is. You need that levels workaround to get it matching.

180-16-16 is ancient history now; we're way past that and on to 191-0-0. I thought I made that clear in an earlier post.

Then why are all the colors slightly off? It's unexpected

I thought it might be YT, but I tested yesterday and it survived YT intact.



You can use studio range RGB if you really wanted to, it's just rare to work with and most computer programs and displays aren't setup to deal with it. That levels workaround can work in 8bit too (at least for the rp219 bar values given), and the values end up matching too, The earlier example used normalized non linear 0-1.0 range, but it's not required

For RGB=>YUV rp219 bars e.g. avisynth

#studio range RGB source (RGB 16-235)
Levels(16,1,235,0,255)
ConvertToYV12(matrix="rec709") #4:2:0

Levels is a clamping , not a clipping . And ffmpeg doesn't have a levels filter. I have no idea why.

[poisondeathray]

I used your code and got the same +/- 3 floating-point errors. Tried it in several players including (MPC-BE). All of the colors are perfect in "test_pattern_709.bmp".

ffmpeg  -y    -r 24 -loop 1 -i "test_pattern_709.bmp" -vf scale=out_color_matrix=bt709,format=yuv420p -c:v libx264 -crf 16 -t 10 -an test191.mp4

We're talking about actual YUV values. ie. The values given in rp219 . Those are the specs you want to match

Not your YUV converted back to RGB values. If you wanted the original RGB values for the roundtrip, then yes you need 10bit YUV . All the original 8bit RGB colors fit in 8bit YUV color model. But you need 10bit to overcome the lossy rounding for the round trip back to RGB

[chris319]

We're talking about actual YUV values. ie. The values given in rp219 . Those are the specs you want to match

Not your YUV converted back to RGB values.

Oh, OK. That's why I was asking for an eyedropper program that reads YUV directly. It would sure make it a lot easier.

Ultimately the YUV is converted to RGB and sent to the graphics card/monitor and that's what the viewer sees. The small amount of fp error after conversion to RGB doesn't bother me. We're off the 180-16-16 now so get over that. I'll let you chase that. I need to get back to the original subject of this thread which involves ffmpeg.

[poisondeathray]

That's why I was asking for an eyedropper program that reads YUV directly. It would sure make it a lot easier.

You were given two choices that actually work; I looked at a few others, but most actually read a RGB converted version then convert back YUV, not the YUV values directly

If you were to pick one I would say vapoursynth and vsedit, because it's cross platform, supports many pixel formats and bit depths. 10bit is getting more and more common now, even for consumer formats.

Ultimately the YUV is converted to RGB and sent to the graphics card/monitor and that's what the viewer sees. The small amount of fp error after conversion to RGB doesn't bother me.

The bars was for color accuracy for submission. You don't want to attach slightly off color bars

And if you did want perfect color accuracy for actual program submission, just use something like prores or dnxhd 10bit variants . If the distribution format was 10bit or had 10bit options (e.g. UHDBD, many broadcaster in europe, netflix etc...) , then use 12bit prores or dnxhd variants. +2 bits is usually enough

I need to get back to the original subject of this thread which involves ffmpeg.

Yes, and unexpected results raises red flags in my mind. If you're getting different YUV values from ffmpeg and color bars, something is wrong

Did you do something differently to make that 1st youtube video ? Can you repeat the process with that commandline above to get correct rp219 YUV values ?

[chris319]

And if you did want perfect color accuracy for actual program submission, just use something like prores or dnxhd 10bit variants . If the distribution format was 10bit or had 10bit options (e.g. UHDBD, many broadcaster in europe, netflix etc...) , then use 12bit prores or dnxhd variants. +2 bits is usually enough

As I've said many times in the past, it all depends on what the client requires. It's not my choice or that of the producer of the video.

I am performing the 5 - 246 limiting in the RGB domain and it works fine. I think the trouble is when I save the RGB data as YUV. The video is not playable when written as RGB24.

This is why legalizing video is such a daunting problem. Some people swear by hardware legalizers and say that's the only way to go.

[poisondeathray]

I am performing the 5 - 246 limiting in the RGB domain and it works fine. I think the trouble is when I save the RGB data as YUV. The video is not playable when written as RGB24.

But you said sending 5-246, and saving it as a BMP was incorrect already. No YUV step. That suggests a problem upstream with RGB.

Uncompressed RGB24 (or BGR24) in a container (e.g. AVI) is playable by MPCHC, MPV, etc.. Raw RGB24 can be playable with ffplay or vsedit, but you need to enter the parameters such as -pix_fmt , -r, -s . Raw RGB has no header info, so you have to fill that in that info so the player knows what to do with the raw sampels

This is why legalizing video is such a daunting problem. Some people swear by hardware legalizers and say that's the only way to go.

Honestly it's futile what you are trying here, because of subsampling. It's not the RGB => YUV conversion. RGB24 => YUV444P8 can be fine. Anything you fix is has a high chance of generating at least some illegal values as soon you subsample. It completely depends on pixel relationships to each other, because that's how subsampling works. The question is whether or not you have <1% of the pixel flagged as illegal, or >1%, and what to do about it. Min/Max clipping in prior RGB step approach will miss potentially millions of potential new illegal values generated in the middle of the range.

Hardware legalizers can make it legal, but brute force ugly. You can get artifacts such as ugly splotches because they are "dumb". They don't have fancy routines or human eye to guide them for ideal fix .

[chris319]

But you said sending 5-246, and saving it as a BMP was incorrect already.

No I didn't. The bmp is perfect, 100%.

Uncompressed RGB24 (or BGR24) in a container (e.g. AVI) is playable

No, and I've tried it on several players. Can't have a situation where it succeeds on player X and fails on player Y.

[poisondeathray]

Uncompressed RGB24 (or BGR24) in a container (e.g. AVI) is playable

No, and I've tried it on several players. Can't have a situation where it succeeds on player X and fails on player Y.

Yes uncompressed RGB24 AVI is playable in the ones I mentioned (MPCHC, MPV, a few others). But not all players

But you said sending 5-246, and saving it as a BMP was incorrect already.

No I didn't. The bmp is perfect, 100%.

I asked
"What is 0-255 ? RGB or YUV ? "

You said
"RGB, which as I said should be limited to 5 - 246."

How can RGB be 0-255, but your BMP is 5-246 ?

So you miscommunicated a few steps or I misunderstood a few things you did in between. What you really meant is you output RGB 5-246 from your program sent to ffmpeg (double checked that bmp is ok), converted to YUV somehow and then again to RGB somehow, and got RGB 0-255



I'm saying your RGB => YUV can be your "unity" when you work with the full range conversion (this is what RGB clipping for r103 means, it's done on studio range RGB 16-235, not computer range RGB) .

If you send RGB 5-246, you can have Y 5-246 with a full range conversion to YUV. That's what you're supposed to be doing . The broadcast checker uses the same studio range conversion for the RGB portion of the check so they get RGB 5-246. (And the pripr YUV to RGB conversion before your program should have used the full range conversion, otherwise your contrast will be wrong)

Perfect.



Not quite. This only works for YUV444. The problem is subsampling (and upsampling)




A group of 100% legal pixels can generate illegal values because of subsampling . You will get some pixels that show up as min/max of 0 or 255 (that are actually negative or >255)

Put a RGB 16,16,16 group of pixels beside a RGB 16,235,16 group of pixels. Black and green. Just 2 colors. When you convert to YUV444 it's still Y 16-235, because you're using studio range conversion. When the broadcast checker checks RGB range, you still get RGB 16-235 because it's using studio range too. It's easy to verify this. Perfect so far

BUT when you subsample,

1) you will get zeros in some channels during the RGB check stage because of subsampling and subsequent chroma upsampling in this example .

2) you can generate new YUV values in the middle of the range, that map to negative RGB values , or RGB >255 for 8bit (out of gamut, not in the RGB cube). Min/max clipping won't catch those.

Some chroma sampling algorithms can produce more or less illegal pixels, but all are prone. It's almost impossible not to generate at least some illegal pixels on typical content

When you only assess min/max individual pixels, you will miss combinations of pixels that when alone are legal, but in combination can generate illegal values

The big question is what % of the active image area is flagged, and what to do about those. Are you over the 1% limit ? Also distribution is important. Large clusters of illegal pixels can be produce very ugly results when you just clip them. But you can usually get away with single stray pixel clipping, here and there

Most software broadcast legalizers do the RGB check and indicate % of "bad" pixels and what areas (shown as a colored overlay or zebras) to see groupings of pixels and their relationships. Usually there are fast/automatic correction modes when you're in a hurry, and you can choose to either reduce saturation or increase/decrease levels, but they can produce very ugly results just like a hardware legalizer. You're supposed to use software legalizer in combination with human eye and manual intervention, but it takes time to do properly.

[chris319]

What is the reverse of this code, i.e. how to convert from YUV to RGB? I'm having trouble getting it to work out.

Kr = 0.2126
Kg = 0.7152
Kb = 0.0722

y = 16 + r*(Kr*219/255) + g*(Kg*219/255) + b*(Kb*219/255)
u = 128 - r*(Kr*112/255)/(1.0-Kb) - g*(Kg*112/255)/(1.0-Kb) + b*(112/255)
v = 128 + 112/255*r - Kg*112/255*g/(1-Kr) - Kb*112/255*b/(1-Kr)

[poisondeathray]

It looks to be the same as this

http://avisynth.nl/index.php/Color_conversions

standard range
yuv [16,235] <-> rgb [0,255]

y - 16 = (Kr*219/255)*r + (Kg*219/255)*g + (Kb*219/255)*b 
v - 128 = 112/255*r - Kg*112/255*g/(1-Kr) - Kb*112/255*b/(1-Kr) 
u - 128 = - Kr*112/255*r/(1-Kb) - Kg*112/255*g/(1-Kb) + 112/255*b 

r = (255/219)*y + (255/112)*v*(1-Kr) - (255*16/219 + 255*128/112*(1-Kr)) 
g = (255/219)*y - (255/112)*u*(1-Kb)*Kb/Kg - (255/112)*v*(1-Kr)*Kr/Kg
    - (255*16/219 - 255/112*128*(1-Kb)*Kb/Kg - 255/112*128*(1-Kr)*Kr/Kg) 
b = (255/219)*y + (255/112)*u*(1-Kb) - (255*16/219 + 255*128/112*(1-Kb))

And for full range
yuv [0,255] <-> rgb [0,255]

y = Kr*r + Kg*g + Kb*b 

v - 128 = 0.5*(r-y)/(1-Kr) = 0.5 * r - 0.5 * g * Kg/(1-Kr) - 0.5 * b * Kb/(1-Kr) 

u - 128 = 0.5*(b-y)/(1-Kb) = - 0.5 * r * Kr/(1-Kb) - 0.5 * g * Kg/(1-Kb) + 0.5 * b 


r = y + 2*(v-128)*(1-Kr) 

g = y - 2*(u-128)*(1-Kb)*Kb/Kg - 2*(v-128)*(1-Kr)*Kr/Kg 

b = y + 2*(u-128)*(1-Kb)

[chris319]

It seems to work now.

I added this code when opening the output pipe:

-vf scale=in_range=full:out_range=tv

Pixel format is yuv420p. It is playable and the RGB levels are confined to 5 - 246.

[poisondeathray]

It seems to work now.

I added this code when opening the output pipe:

-vf scale=in_range=full:out_range=tv

Pixel format is yuv420p. It is playable and the RGB levels are confined to 5 - 246.

Won't that mess up the contrast? That basically clamps levels. You would expect wrong black and white level, washed out, low constrast

Or maybe you're else doing something differently in other steps or conversions ?

A good way to check it is to run black and white test video through it. Y=16, Y=235. If the output YUV video does not have Y=16, Y=235, then the contrast is off. Maybe slightly off is acceptable. The 5-15, 236-246 are just for small excursions. The actual black , white level should be Y=16, Y=235

You can check your yuv420p output video with ffplay -i input.ext -vf waveform=g=green

[chris319]

The problem with that little trick is it introduces color shifts.

[chris319]

Dont use that script, I'm sorry, I use numpy a lot, it gets a pay off sometimes together with opencv. But Vapoursynth has its own filter exactly to do that. Use that second script:

import vapoursynth as vs
from vapoursynth import core

clip = core.lsmas.LibavSMASHSource(r"G:/my_file.mp4")

MIN = 5
MAX = 246

rgb_clip = core.resize.Point(clip, matrix_in_s = '709', format = vs.RGB24)

def restrict(x):
   return max(min(x, MAX), MIN)

clipped_rgb = core.std.Lut(clip=rgb_clip, planes=[0, 1, 2], function=restrict)
clipped_yuv = core.resize.Point(clipped_rgb, matrix_s='709', format = vs.YUV420P8)

clipped_yuv.set_output(0)

save that script with some name , example as: C:\my_scrit.vpy
I recommend to use vapoursynth editor.
Then you proceed to command prompt in windows and apply those three command lines:

"vspipe.exe"  --y4m  "C:\my_scrit.vpy"  -  | "x264.exe"  --demuxer y4m  --crf 18 --vbv-bufsize 30000 --vbv-maxrate 28000 --colorprim bt709 --transfer bt709 --colormatrix bt709 --output "C:\my_output.264" -
"ffmpeg.exe"  -i "G:\my_file.mp4"  -vn -f wav -  | "neroAacEnc.exe"  -ignorelength -lc -cbr 256000 -if - -of "C:\my_audio.m4a"
"mp4box.exe" -add "C:\my_output.264:fps=29.970" -add "C:\my_audio.m4a" -new "C:\my_output.mp4"

that is just an example how you can get what you want, you might as well use ffmpeg only to get your mp4, I just use that sequence

do not forget fix your correct fps when muxing, include whole paths for filepaths,
or do whatever you want if you use ffmpeg and not x264

Vapoursynth does not pass audio in official version, right now they final touch it and test to include it in a incoming release version I guess. That would include perhaps two vspipe lines , for audio and video and then some for muxing or just use piping with ffmpeg

Sorry, x264.exe is not recognized.

[chris319]

This is working pretty well so far:

D:\Programs\ffmpeg\BroadcastVideo\ffmpeg -y  -i "test_pattern_720.MP4"  -c:v mpeg2video  -pix_fmt rgb24  -vb 50M  -minrate 50M  -maxrate 50M  -vf lutrgb='r=clip(val,6,245)',lutrgb='g=clip(val,6,245)',lutrgb='b=clip(val,6,245)',scale=out_color_matrix=bt709:out_range=limited  -color_primaries bt709  -color_trc bt709  -colorspace bt709 -an  -f vob  clipped.mpg

Here is the dilemma with R 103 and RP 219 bars: if the RGB range is 5 - 246 and the bar colors are 191-0-0, you can see that the 0's will be clipped and you'll have 191-5-5. This is a predictable artifact and probably tolerable. What do you think, PDR?

There must be no data at 0 or 255 as these are sync levels in ATSC.

[_Al_]

Sorry, x264.exe is not recognized.

You need to put down the whole path in cmd line and of course you need to have x264 downloaded in your PC in first place if using x264 encoder and not ffmpeg. ffmpeg alone is using some x264 library. Btw I hate ffmpeg, the whole thread in here basically is telling why. Defaults , defaults, defaults and you need to know exactly what to use in ffmpeg to override it or not allow it. If I can avoid it, I do that. There is a bunch of sources where to get x264.exe, for example: http://download.videolan.org/x264/binaries/win64/
Same for Nero encoder, mp4box . Those are tools that are dedicated for a particular job and they are doing it well.

[poisondeathray]

This is working pretty well so far:

D:\Programs\ffmpeg\BroadcastVideo\ffmpeg -y  -i "test_pattern_720.MP4"  -c:v mpeg2video  -pix_fmt rgb24  -vb 50M  -minrate 50M  -maxrate 50M  -vf lutrgb='r=clip(val,6,245)',lutrgb='g=clip(val,6,245)',lutrgb='b=clip(val,6,245)',scale=out_color_matrix=bt709:out_range=limited  -color_primaries bt709  -color_trc bt709  -colorspace bt709 -an  -f vob  clipped.mpg

Here is the dilemma with R 103 and RP 219 bars: if the RGB range is 5 - 246 and the bar colors are 191-0-0, you can see that the 0's will be clipped and you'll have 191-5-5. This is a predictable artifact and probably tolerable. What do you think, PDR?

There must be no data at 0 or 255 as these are sync levels in ATSC.

I suspect you're using the wrong conversion to RGB prior to the clipping. You shouldn't have any "zeros" when you convert to RGB with standard colorbars . The only way you have that is when you use the standard conversion Y 16-235 => RGB 0,0,0 - 255,255,255. ie. the wrong equation for this situation. The only way you have zeros, is if you started with zeros. Because the proper equation is your "unity" Y 16-235 => RGB 16-235 (or Y 0-255 => RGB 0-255)

It also depends on what your input video is, and how it's flagged. How your input video is flagged can affect the input conversion for ffmpeg to rgb24, unless you explicitly override it.

When you use -pix_fmt rgb24 , it will normally use limited range 601 for unflagged video to convert to RGB . This means not only colors wrong, the levels will be wrong for r103 . Y 16-235 get mapped to RGB 0,0,0-255,255,255. The clipping will be at the wrong values, leading to the wrong contrast. The black and level in RGB will be 0 and 255. Definitely wrong for r103. Ok for computer.

Generating a test chart from 75% computer RGB (191 etc...) should use limited range (normal conversion) . Generating from 75% in studio range (180,16,16, etc..) should use full range equations + adjustment (if using current ffmpeg code). That's already established. That's only for the test chart generation. Recall that in both cases the YUV values were the same (or should be) . That's irrelevant now, you can file that away. Let's not discuss that anymore it's a different concluded topic

But a normal input video should use full range for the RGB clipping. That is what r103 means. Black and white reference points should be at 16, 235 for r103. Both RGB and YUV. That's your unity equation, or the full range equation

What you should be doing is full range conversion to RGB, clipping 5-246, full range out to YUV. So black is always at 16, white is always at 235. Both Y and RGB. You still have >5, <246, but those are just excursions. The actual black level is 16, actual white level is 235, so the contrast looks normal. r103 is using studio range RGB. That means prior when you convert to your RGB clipping stage, 75% red is now at RGB 180,16,16 , NOT RGB 191,0,0

The final check to RGB is ALSO done at studio range RGB (16-235). That's what the broadcast RGB checker does too. I suspect you're using standard conversion. When you're dealing with r103, everything is 16-235. (Again, the test chart generation itself is excluded, because the YUV values are the same eitherway, and you're not submitting RGB)

[jagabo]

I think R103 is referring to limited range when it discusses RGB limits. Ie, converting limited range YUV to limited range RGB should keep RGB values between 5 and 246. This is really the only interpretation that makes sense. With a conversion to limited range RGB you can see how far off your RGB values are. With conversion to full range RGB all the out of gamut pixels would be pegged at 0 or 255 so you couldn't tell if they were out of gamut or not.

[chris319]

I think R103 is referring to limited range when it discusses RGB limits. Ie, converting limited range YUV to limited range RGB should keep RGB values between 5 and 246. This is really the only interpretation that makes sense. With a conversion to limited range RGB you can see how far off your RGB values are. With conversion to full range RGB all the out of gamut pixels would be pegged at 0 or 255 so you couldn't tell if they were out of gamut or not.

How would you rewrite my code to satisfy all the requirements you have laid out?

I'm getting the results I want with this so I don't understand why it needs to change.

Using full range, ffmpeg seems to force the whites to 255.

[poisondeathray]

I think R103 is referring to limited range when it discusses RGB limits. Ie, converting limited range YUV to limited range RGB should keep RGB values between 5 and 246. This is really the only interpretation that makes sense. With a conversion to limited range RGB you can see how far off your RGB values are. With conversion to full range RGB all the out of gamut pixels would be pegged at 0 or 255 so you couldn't tell if they were out of gamut or not.

Exactly!

Jagabo is referring to the range of values . I used the name for the equations . It's the same thing

limited range RGB is "studio range RGB" or RGB 16-235

You convert YUV to limited range RGB by using the full range equations. Ie. 709 full range.

The problem is ffmpeg doesn't use the exact one that ITU or the one outlined there, it's slightly off a bit. The levels workaround makes it work

[poisondeathray]

I'm getting the results I want with this so I don't understand why it needs to change.

Using full range, ffmpeg seems to force the whites to 255.

It doesn't need to change, use whatever works for you

But I suspect your black and white level are off

[chris319]

What you say is true in theory, but the fly in the ointment is that ffmpeg forces levels to 255 in "full range", even when you tell it not to. That is the crux of this whole thread. So you have to use "limited range" instead. If things worked the way they should, and ffmpeg didn't have a mind of its own, it would be different.

You should really sit down and write some ffmpeg code and try this stuff out for yourself and you'll see what I mean.

[chris319]

The next tricks is to output an XDCam file. Hey, it's what the client wants. Hopefully this is close.

D:\Programs\ffmpeg\BroadcastVideo\ffmpeg -y  -i "D:\videos\trains\c0015.MP4"  -c:v mpeg2video  -pix_fmt rgb24  -s 1280x720  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M     -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd5c  -non_linear_quant 1  -vf lutrgb='r=clip(val,6,246)',lutrgb='g=clip(val,6,246)',lutrgb='b=clip(val,6,246)',scale=out_color_matrix=bt709:out_range=limited  -color_primaries bt709  -color_trc bt709  -colorspace bt709 -acodec pcm_s16le  -pix_fmt yuv422p  -profile:v 0 -level:v 2  -f  mxf  clipped.mxf

[jagabo]

Here's what I'm referring to: Take a limited range rec.709 YUV value like 128,190,190. All three values are easily within their respective min/max limits. But is it a legal color? Converting to full range RGB gives 242,84,255. All three values legal for full range RGB. But any YUV color converted to full range RGB will result in a legal RGB value -- it's not possible to represent illegal values below 0 or above 255 with unsigned 8 bit bytes (all such values will always be clamped to 0 or 255). But converting to limited range RGB results in 226,87,244. 244 is outside the valid range of 16-235. So we know the YUV color was illegal. But it's still within the R103 "overshoot" range of 5-246.

[poisondeathray]

What you say is true in theory, but the fly in the ointment is that ffmpeg forces levels to 255 in "full range", even when you tell it not to. That is the crux of this whole thread. So you have to use "limited range" instead. If things worked the way they should, and ffmpeg didn't have a mind of its own, it would be different.

You should really sit down and write some ffmpeg code and try this stuff out for yourself and you'll see what I mean.

What do you mean by full range? YUV values or RGB values? What part? And how are you determining this?

It works fine here. I just double checked everything I posted earlier. It doesn't "force" anything. FFmpeg does what you tell it to.

If I take Y 16-235, do full range 709 conversion , I get RGB 16-235. Do full range 709 conversion again and you get Y 16-235. That's your "unity", that's studio Range RGB, and r103 . I don't see a problem with that . If you had Y 0-255 to start with , you'd get RGB 0-255 too as expected. But your job is to limit Y to 16-235 (hopefully not by clipping)



Did you do what I suggested about adding more of the rp219 signals ? If I run your command on bars that include Y=16, 235 , you end up with Y=21, 226. So it is clamping the range . 75% Blue becomes YUV 33,209,120 instead of 28,212,120 . No doubt the min/max is "ok", but it's changing the contrast and colors . Too aggressive clamping and black/white level are off