Converting to Broadcast Levels

[chris319]

These scripts convert to broadcast legal levels (8 bit) in the range 16 - 235:

720p:

ffmpeg -y  -hide_banner  -i "C0015.mp4" -vf  scale=width=1280:height=720:flags='lanczos',"lutrgb=r='clip(val,16,235)':g='clip(val,16,235)':b='clip(val,16,235)'"  -codec:v libx264  -crf 0   -pix_fmt:v yuv422p  -color_range "tv"  -color_primaries bt709  -color_trc bt709 -colorspace bt709  -movflags +write_colr  -r 59.94  -c:a copy  limited_264.mov

1080i:

ffmpeg -y -hide_banner -i "C0015.mp4" -vf  tinterlace=mode='interleave_top',setparams=field_mode='tff',scale=width=1920:height=1080:flags='lanczos',"lutrgb=r='clip(val,16,235)':g='clip(val,16,235)':b='clip(val,16,235)'",setparams=range="tv"  -codec:v libx264  -crf 0  -pix_fmt:v yuv422p  -color_range "tv"  -color_primaries bt709  -color_trc bt709 -colorspace bt709  -flags +ilme+ildct  -movflags +write_colr  -r 29.97  -c:a pcm_s16be  -ar:a 48000  limited.mov

To review:
ABC, ESPN and Fox expect 720p

CBS, NBC, CNN and PBS expect 1080i

The scripts have undergone many iterations and much testing and seem to pass muster.

[pandy]

IMHO Y, Cb, Cr values should be level limited - IMHO there is no need to limit RGB levels...It is probably better to use proper RGB > YCbCr formula to provide broadcast levels.

[chris319]

I understand what you're saying. Some submission specs call for R G B to be limited to 16 - 235, so argue with the spec authors. Bottom line is whether it will pass QC.

[Sharc]

Interesting, thanks.
Here a quick test for legalizing "all_yuv", interleaved for comparison.
All become legal, but it seems that the legal YUV->RGB colors within the "ALL_YUV" picture get somewhat affected by the legalization as well. Is this intended, or do I miss something?

Edit: Hmmm.... I guess it is by desing because the slope of the luma ramp changes slightly due to the legalization of the out-of-gamut brights and darks .....

[chris319]

Here a quick test for legalizing "all_yuv", interleaved for comparison.
All become legal, but it seems that the legal YUV->RGB colors within the "ALL_YUV" picture get somewhat affected by the legalization as well. Is this intended, or do I miss something?

Edit: Hmmm.... I guess it is by desing because the slope of the luma ramp changes slightly due to the legalization of the out-of-gamut brights and darks .....

I'm afraid I don't understand the problem. Could you describe it a little more clearly?

If all R G B values are 16 - 235 then it's doing what it's supposed to do.

[Sharc]

If all R G B values are 16 - 235 then it's doing what it's supposed to do.

I don't know where this rule comes from. RGB is not a broadcast format. The 16....235 TV range applies for the luma. The EBU is even little more tolerant if I remember correctly. RGB should not clip at 1 or 254 upon conversion. Your limited range RGB seems unnecessary strict.
You may have different infomation/requirements though.

Edit: ok 16-235 RGB is defined as nominal range in EBU 103. The limit is 5...246 (EBU 103).

[pandy]

I don't know where this rule comes from. RGB is not a broadcast format. The 16....235 TV range applies for the luma. The EBU is even little more tolerant if I remember correctly. RGB should not clip at 1 or 254 upon conversion. Your limited range RGB seems unnecessary strict.
You may have different infomation/requirements though.

Edit: ok 16-235 RGB is defined as nominal range in EBU 103. The limit is 5...246 (EBU 103).

YCbCr shall be within 1..254 range - this is due fact that words with value 0 and 255 are used to signal SAV and EAV flags in RAW video transport (such as SDI/SMPTE 259M) but RGB is not transported over SDI...

There is at least one justification to clip RGB between 16 and 235 - this is covered by https://scdn.rohde-schwarz.com/ur/pws/dl_downloads/dl_application/application_notes/7b...8/7BM18_0E.pdf .

[chris319]

It's easy enough to change the values in my scripts if different clip levels are desired. Depends on who's doing the QC.

[Sharc]

For info here the EBU 103 document which I had in mind. It specifies limits on RGB on SDI Interface which are allowed and no correction (clipping or legalizing) is needed. Table 1 and Figure 1 "preferred min./max."

[pandy]

SDI transport YCbCr 4:2:2.

Btw Avisynth offer Limiter() to clip signal level in desired range.

[chris319]

I've seen R 103. Again, it's easy to change the clip levels in my scripts.

[Sharc]

SDI transport YCbCr 4:2:2.

Btw Avisynth offer Limiter() to clip signal level in desired range.

Yes. The problem is how to set these limits to prevent out-of-gamut RGBs for a particular source, or how to process/tweak (aka "legalize") those YCbCr triplets which would produce invalid (out-of-gamut) RGB upon conversion.

[Sharc]

It's easy enough to change the values in my scripts if different clip levels are desired. Depends on who's doing the QC.

Yes. The purpose of the test in post#4 was just to see how your 720p conversion commandline treats the "all_yuv" source picture (representing axes (cutting planes) of the YCbCr cube) which includes many YCbCr tristimuli which would produce invalid (=out-of-gamut -> clipped) RGBs upon conversion when using a standard conversion matrix (like 601 or 709).

The RGB block within the YCbCr cube. The picture applies for the 601 matrix, for example. The black -> white bar in my picture (of post#4) is represented by the dotted line in the figure below (Cb=Cr=128, Y=var=0....255). Similar (perpendicular) for the other two bars.

[chris319]

Are you satisfied with the results obtained with these scripts?

[Sharc]

Are you satisfied with the results obtained with these scripts?

The conversion eliminated (or tweaked, remapped) the critical YCbCr. So far good. Slight perceptional changes are to be expected due to the legalization. Not sure however if some clipping in your legalization process would also remove some of the picture details in real world pictures which require legalization. Maybe you can tell from your testing, or someone who knows more may chime in.

P.S. I am not aiming at broadcast compliance/QC. But legalization can sometimes be relevant for videos (e.g. tape captures) which are "off the kilter".

[chris319]

Not sure however if some clipping in your legalization process would also remove some of the picture details in real world pictures which require legalization.

At those levels I don't think the clipping would be enough to be visible to the eye and objectionable.

[Sharc]

Here another (maybe pathological) legalization experiment using your (modified) commandline.

The left picture walks through all 16+ milllion Y,Cb,Cr triplets of the YUV cube when playing the file. The picture coordinates are Cb vs Cr and the Y is given by the frame number and is also visualized by the waveform monitor on top. So a vast number of the Y,Cb,Cr result in out-of-gamut (clipped) RGB upon YUV->RGB conversion using the 601 matrix.
The picture to the right is after applying your modified legalization commandline. The picture doesn't contain any bad Y,Cb,Cr which would result in clipped RGBs, so the "legalization" is effective but one gets the small bar on the right for Y>235.
Take it for what it is


Modified commandline:

ffmpeg -y  -hide_banner  -i "allyuv.avi" -vf  scale=width=256:height=256:flags='lanczos',"lutrgb=r='clip(val,0,255)':g='clip(val,0,255)':b='clip(val,0,255)'"  -codec:v utvideo  -pix_fmt:v yuv444p  -color_range "tv"  -color_primaries bt470bg  -colorspace bt470bg  -movflags +write_colr -c:a copy  "llegalized.avi"

[_Al_]

That was discussed before, chris319 now found ffmpeg line, which perhaps works, perhaps he looks for conformations if it is ok. I think clipping rgb depends hugely on source where broadcasted material should be perhaps ok for this. But home user stuff could spit out far more drastic changes.

To visually analyze a volume of all changes by rgb clipping, if visible etc., I was doing it with vapoursynth,
Some pictures for comparisons here:
https://forum.videohelp.com/threads/395939-ffmpeg-Color-Range/page6
And using plot graphs to analyze all frames for a video, script and plotted images:
https://forum.videohelp.com/threads/395939-ffmpeg-Color-Range/page7#post2577691
https://forum.videohelp.com/threads/395939-ffmpeg-Color-Range/page7#post2577692

[Sharc]

That was discussed before, chris319 now found ffmpeg line, which perhaps works, perhaps he looks for conformations if it is ok.

Yes, I remember the former discussions.
His ffmpeg commandline seems to work eliminating / legalizing bad YCbCr.
Top right picture of the attached video shows the bad YCbCr in Cyan (same as your red marks in your links)
The bottom row is the same after application of the ffmpeg commandline. No Cyans on the bottom right means that all RGB are now valid. (The small bar on the legalized variant for Y>235 remains for some reason ....)

[chris319]

BT.601 is as good as obsolete. Please stick to BT.709.

VLC is unable to play your test2.avi file.

[chris319]

The idea is to take footage shot with a camcorder which outputs 0 - 255 and make it 16 - 235 or 5 - 246 if you prefer.

After spinning my wheels here and being gaslit by one particular member, I worked with a guy on reddit/ffmpeg to get the code posted here. It was his idea to use ffmpeg's clip function. I put the project aside for a couple of years and am now coming back to it.

[Sharc]

BT.601 is as good as obsolete. Please stick to BT.709.

VLC is unable to play your test2.avi file.

601/470bg colorspace is alive as ever and is standard for legacy SD video. But I am not going to argue. I just avoid unnecessary conversions.

test2.avi and test3.avi: The codec/format is lossless UTVideo 4:4:4. Ffplay, VirtualDub2, MPC-HC play it. Don't know why VLC does not recognize the fourCC code ULY4.

[Sharc]

The idea is to take footage shot with a camcorder which outputs 0 - 255 and make it 16 - 235 or 5 - 246 if you prefer.

A camcorder outputting RGB? Usually camcorders output YUV with Y (luma) in the range ~16....~235, or sometimes ~32.... ~240 for DV. How this gets converted to RGB depends on the decoding matrix. I don't know your camcorder though, so no argument here.
Your source in post#1 was a file C0015.mp4. As we have not seen it I did use my own synthetic test sources for experimenting with your commandline. No rating, just playing with your suggested commandline out of interest to see what is does here.

[Sharc]

So finally here a screenshot of a real case from an interlaced 720x576i25 analog PAL tape capture.

Top left: Original with "bad" YCbCr
Top right: Bad pixels highlighted in Cyan
Bottom left: same as Top left but legalized
Bottom right: No Cyan, means no bad pixels any more

The legalizing ffmpeg commandline:

ffmpeg -i"source.avi" -vf  scale=interl=1,setfield=tff,"lutrgb=r='clip(val,1,254)':g='clip(val,1,254)':b='clip(val,1,254)'",setparams=range="tv"  -codec:v ffvhuff  -pix_fmt:v yuv422p  -color_range "tv"  -color_primaries bt470bg  -colorspace bt470bg  -flags +ilme+ildct  -movflags +write_colr  -c:a copy  "legalized.avi"

[Attachment 90828 - Click to enlarge]

[chris319]

My camcorder outputs YUV with Y in the range 0 - 255.

[Sharc]

My camcorder outputs YUV with Y in the range 0 - 255.

Ok. But is it really necessary to take the legalizing route, or would a simple

ColorYUV(levels="PC->TV")

do the job adequately?

[jagabo]

My camcorder outputs YUV with Y in the range 0 - 255.

Ok. But is it really necessary to take the legalizing route, or would a simple

ColorYUV(levels="PC->TV")

do the job adequately?

If you look at the RGB cube inside the rec.601 YUV cube you'll see that even within the valid Y (16-235) and UV (16-240) range most of the YUV combinations are outside the RGB cube.


[Attachment 90830 - Click to enlarge]

For example, at Y=235 the only legal value for U and V is 128. If they were 129 they would be illegal, even though 129 is within the 16-240 range. The "valid" ranges refer to the 8 corners of the RGB cube.

[Sharc]

Yes. That's what I demonstrated with the synthetic "all_yuv" examples.
And for the real case in post#24 the top left picture has YCbCr well within their "legal" range Y(16.....235) and Cb,Cr(16....240) - see picture below - but many of the RGB are invalid and highlighted in the top right picture of post#24 (for a non-expanding matrix; using the standard Rec.601 limited->full expanding matrix it would be even worse). The legalization commandline fixed it (bottom row in post#24).

Edit:
And yes, this example would not have been properly fixed with a simple ColorYUV(levels"PC->TV") or similar. Still invalid RGB, see 2nd screenshot.

[Sharc]

The idea is to take footage shot with a camcorder which outputs 0 - 255 and make it 16 - 235 .....

OK. So here a test pattern with Y(0.....255), interleaved with the output of your commandline '720p' of post#1. The actual colors depend on the decoding matrix (limited or full) of the renderer/player of course, but in any case one gets a "flat" picture with valid RGB but with loss of details in the darks and brights due to the clipping. Best seen with the yellow and green brights. Unless I am mistaken ...

[_Al_]

but in any case one gets a "flat" picture with valid RGB but with loss of details in the darks and brights due to the clipping.

If levels are ok or so, then fixing RGB legal values, if needed, perhaps does not do much a visible damage. Or if image is not too much saturated (more illegal RGB values).
BECAUSE mostly ONE value (R or G or B) is fixed from RGB pixel. Whereas if pixel is overblown all RGB values are cut off, hence visibly striking difference, greyed out footage.

To be honest, for all these years, I never understood, how op cannot notice that, if all values go way above 235 then cutting all RGB values off makes it visible.
Maybe there is no overblown whites in his footage.

Rule #1 to shoot a footage was to not have overblown whites if footage is suppose to be broadcasted (camcorders would not record below 16) and have encountered yelling something about having it all within 0-100 IRE (16-235 values) . So lighting must be used in special cases, or just simply not shoot something, where in old days camcorder viewfinder showed zebra patterns going all over a frame. Or sure, no problem, but using grey filters, or grey filter and lighting as well

Talking about camcorder footage, if not shooting outside, or shooting a special content only, might not give overblown footage because light dynamics are narrow. In old times, one would start, I have a camcorder, I'm a videographer and shooting weddings, etc., etc. and it was more clear. Maybe Chris319 does not have overblown whites at all. He described using broadcast station footage and later camcorder footage as well. Obviously, those are a different beasts. There is no one treat fixes them all.