ffmpeg Color Range

[poisondeathray]

It's called "limited" range equation because it takes the limited range of Y 16-235.

So when encoding my color-bar bmp I use range=limited, correct?

Yes, if you start with 191,0,0 ,you use limited range equation . And since limited range equation is default, so you can omit the range argument entirely. You only need to fill in arguments that deviate from defaults. Since bt601 is default, you need to enter bt709 . Since you're going from RGB to YUV, you point in the YUV direction, so you fill in out_color_matrix (not in_color_matrix)

-vf scale=out_color_matrix=bt709,format=yuv420p

[chris319]

ffmpeg defaults to BT.601? I never knew that, but I do specify BT.709 in my scripts.

[poisondeathray]

Yes, 601 is default for many computer programs. It just is. Don't ask.



It might be good practice to include all the arguments

There are some "gotchas" situations where some files might be flagged incorrectly and so forth. Even something simple like a PNG can have a gama tag that changes the results

It certainly won't hurt to enter everything to override everything

[chris319]

Don't get me started on BT.601. In 2020 it has no place being near a computer. It was intended as a bridge between analog and digital video and that's it. When it was written, the IBM PC could display a whopping 16 colors.

[chris319]

OK, I got the full/limited range thing straightened out. The white object in my camcorder footage now clips at 246.

ffmpeg -y  -i "D:\videos\trains\c0015.MP4"    -vf scale=in_range=full:in_color_matrix=bt709,format=rgb24,lutrgb='r=clip(val,6,246)',lutrgb='g=clip(val,6,246)',lutrgb='b=clip(val,6,246)',scale=w=1280:h=720:out_color_matrix=bt709:out_range=full,format=yuv422p  -r 59.94  -vb 50M  -minrate 50M  -maxrate 50M     -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xd59  -non_linear_quant 1  -g 12  -bf 2  -profile:v 0  -level:v 2  -f  mxf  clipped.mxf

bin\ffplay -i clipped.mxf -t 5  -vf scale=in_color_matrix=bt709:in_range=full,format=rgb24

However, I had to re-encode color bars as follows, or else I get 16-180-16. With the code below, with out_range=full, I get 0-191-0.

ffmpeg  -y  -loop 1 -t 10  -i "test_pattern_709.bmp"  -pix_fmt yuv444p  -c:v libx265  -vf scale=w=1280:h=720:out_color_matrix=bt709:out_range=full  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -r 59.94  -an  test_pattern_720.mp4

[poisondeathray]

However, I had to re-encode color bars as follows, or else I get 16-180-16. With the code below, with out_range=full, I get 0-191-0.

ffmpeg  -y  -loop 1 -t 10  -i "test_pattern_709.bmp"  -pix_fmt yuv444p  -c:v libx265  -vf scale=w=1280:h=720:out_color_matrix=bt709:out_range=full  -color_primaries bt709  -color_trc bt709  -colorspace bt709  -r 59.94  -an  test_pattern_720.mp4

Not correct if you start with 191; you should be using limited range equation

You want 16,180,16 for that last RGB check. That's for r103 (75% of RGB 16-235)


Do you recall the spreadsheet?

If you start with RGB 191 bars, such as 0,191,0 for 75% green of 0-255 Computer RGB, you should be using limited range equation if you want rp219 spec bars

If you start with RGB 180 bars, such as 16,180,16 for 75% green of 16-235 Studio range RGB, you should be using full range equation if you want rp219 spec bars

When converting those YUV bars back to RGB, using full range 709 equation, you expect 16,180,16. (75% of limited range RGB, or studio range RGB 16-235)

When converting those YUV bars back to RGB, using limited range 709 equation, you expect 0,191,0. (75% of full range RGB, or computer RGB 0-255)



And in both cases, the YUV values are the same (or should be). The YUV values listed in rp219 . That YUV color picker is helpful in many ways, consider the jump to vapoursynth or avisynth

[_Al_]

I'm pretty sure it's just *100 , and it's linear not some weird log function. It's just decimal range 0-1.0 . 0 is 100% black, 1.0 is 100% white. Stuff in between is intermediate. 50% affected would be 0.5

yes , it gives the same value,
mask is just same three planes (ModifyFrame needs out same as in), so using R plane and reading on screen as 0.025346:

monitor_with_props = core.std.PlaneStats(mask_monitor_no_text,  plane=0, prop = 'PlaneStatsR').text.FrameProps()

or calculate it, for example 748 frame:

print(monitor_with_props.get_frame(748).props['PlaneStatsRAverage']*100)

gives the save value as this in numpy:

white_pixel_total = np.sum(mask == 255)
percent = white_pixel_total/NUM_PIXELS*100

2.53 %

[chris319]

I think I've got it all together now.

[chris319]

Interesting:

https://www.cube-tec.com/en/solutions/video/mxf-legalizer

[chris319]

How about this?

D:\Programs\ffmpeg\BroadcastVideo\ffmpeg -y  -i "Test_pattern_720.mkv"    -vf scale=in_range=full:in_color_matrix=bt709,format=yuv420p,lutrgb='r=clip(val,22,227)',lutrgb='g=clip(val,22,227)',lutrgb='b=clip(val,22,227)',scale=out_color_matrix=bt709:out_range=full,format=yuv422p,tinterlace=4    -flags +ilme+ildct  -r 29.97  -vb 50M  -minrate 50M  -maxrate 50M  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xdv2  -non_linear_quant 1  -g 12  -bf 2  -profile:v 0  -level:v 2  -f  mxf  clipped.mxf

The final output is 1080i.

[poisondeathray]

How about this?

D:\Programs\ffmpeg\BroadcastVideo\ffmpeg -y  -i "Test_pattern_720.mkv"    -vf scale=in_range=full:in_color_matrix=bt709,format=yuv420p,lutrgb='r=clip(val,22,227)',lutrgb='g=clip(val,22,227)',lutrgb='b=clip(val,22,227)',scale=out_color_matrix=bt709:out_range=full,format=yuv422p,tinterlace=4    -flags +ilme+ildct  -r 29.97  -vb 50M  -minrate 50M  -maxrate 50M  -dc 10  -intra_vlc 1  -lmin "1*QP2LAMBDA"  -qmin 1  -qmax 12  -vtag xdv2  -non_linear_quant 1  -g 12  -bf 2  -profile:v 0  -level:v 2  -f  mxf  clipped.mxf

The final output is 1080i.

It depends on what "Test_pattern_720.mkv" is ;

-If it's 1280x720p59.94, and the height is "720" as the name suggests, you'd need to scale to 1920x1080 for 1080i

-clip values are probably too severe if the input clip was correct range Y=16, Y=235 for black and white reference levels. Because the output clip would be Y=22, Y=227 for white and black , since you're using full range equations in and out. If you include some of the other signal patterns from rp219, you should be able to detect this

[poisondeathray]

"xdv2" is for regular XDCAMHD , the 4:2:0 1440x1080 35Mb/s variant. "xd5b" is for "1080i60" XDCAMHD422 50Mb/s .
https://www.videolan.org/developers/vlc/doc/doxygen/html/fourcc__list_8h_source.html

(It probably doesn't matter for .MXF variant. But the MOV wrapped one can have problems on some Mac software with the wrong fourcc)

Technically, it should be at least 2 mono 24bit 48khz tracks for actual XDCAMHD422 specs, but some places accept 16bit, check the spec list . But the audio portion of the check will usually fail with the wrong tracks for strict XDCAMHD422

I think the "NTSC" variants should use -g 15 , "PAL" variants -g 12 . Checking valid XDCAMHD422 samples , that appears to be the case. That's what ffmbc uses too

https://forum.videohelp.com/threads/395939-ffmpeg-Color-Range/page4#post2574086

 opt_default("g", norm == NTSC ? "15" : "12");

[chris319]

If it's 1280x720p59.94, and the height is "720" as the name suggests, you'd need to scale to 1920x1080 for 1080i

Good catch. The test pattern file is 720p but the camcorder output is 1080p, so all I need to do is add interlace to the camcorder video. No need to change the resolution.

The clip levels are where I want them.

I've perused several delivery specs and most of them want MXF OP-1A, so that's my target. I've learned that now PBS, the U.S. non-commercial broadcast network, accepts ProRes HQ, but I don't think that's universal.

It would be easy to make it 24-bit audio but I haven't seen that requirement in any delivery spec. The camcorder puts out 16 bits.

Will make it GOP 15 and xd5b.

Are you familiar with ffmbc? Does it have LUTRGB and tinterlace? I'm not expecting 100% compatibility with ffmpeg.

[poisondeathray]

Also the 1st "format" before lutrgb should be rgb24, not yuv420p

Are you familiar with ffmbc? Does it have LUTRGB and tinterlace? I'm not expecting 100% compatibility with ffmpeg.

I used to use it quite frequently a long time ago. But it's a largely abandoned fork . There was a big fuss over open source streams getting rejected back then because of either the encoding was non compliant, or mxf wrapper was non compliant. ffmbc was the only one that passed. It had an almost mythical status for submissions then. It might be that modern ffmpeg commonly distributed build introduced many of the ffmbc changes or code, not sure. It even was read and accepted by Sony decks - this is the "gold standard", the strictest test for the XDCAMHD422 format. If it is accepted by that, the format itself will pass anywhere. (Sony is the author of the spec)

I don't think it has lutrgb, or anything introduced in the last 4-5 years. And the tinterlace might be slightly different than the modern ffmpeg tinterlace version. But you should be able to compile anything for it, for your own custom ffmbc . I remember trying to pipe ffmpeg to ffmbc, as a workaround, but that didn't work too well either. I don't recall what the problem was.

[chris319]

Also the 1st "format" before lutrgb should be rgb24, not yuv420p

Why? The input video from the camcorder is 420p, so shouldn't it match?

One of the guys on the Shotcut forum has access to a Telestream QC thing, and I might have him check a finished video when we get this sorted out (not yet).

We're still aiming for MXF OP1A?

[poisondeathray]

Also the 1st "format" before lutrgb should be rgb24, not yuv420p

Why? The input video from the camcorder is 420p, so shouldn't it match?

No, that's controlling the YUV=>RGB conversion before lutrgb. That's the purpose of -vf scale and format filters there. If not, you get limited range Rec601 autoconversion to RGB, because lutrgb is an RGB filter. Just like the scale and format after lutrgb control the RGB=>YUV conversion coming out of lutrgb . Think of it as a linear filter chain.

One of the guys on the Shotcut forum has access to a Telestream QC thing, and I might have him check a finished video when we get this sorted out (not yet).

We're still aiming for MXF OP1A?

That would be good to know so you can give feedback to shotcut and their settings/presets

But keep in mind, different stations/clients might use different QC methods

[chris319]

that's controlling the YUV=>RGB conversion before lutrgb

OK, makes sense.

you can give feedback to shotcut and their settings/presets

He doesn't take suggestions well. He often doesn't listen to people who know what they're talking about and becomes prickly and argumentative. On the other hand, I was a squeaky wheel about Shotcut's color rendition and he did a nice job of fixing it.

I want to wait until we're really ready before asking for the use of the Telestream.

[poisondeathray]

Another way to look at it is -vf format is what you are converting it "to" ; ie. the destination format at that point in the filter chain. It precedes lutrgb here, so it's converting before lutrgb is applied. So whatever the source is, it converts it to format=whatever . You precede it with "scale", because "scale" specifies the sws flags and controls how you convert from A to B. For example, if you needed interlaced scaling conversion, you'd have to enter that flag. In this case you wanted a full range , 709 conversion, so those were entered. You're still progressive at that point in the chain, so you don't need interlaced YUV=>RGB flag.

Similarly, exiting lutrgb, you convert with the scaling (full range 709 equation conversion again), to the destination format of yuv422p . Since that's the last "format", that's actually the encoded format (provided the encoding settings are compatible, or some other "auto" inserts might occur).

you can give feedback to shotcut and their settings/presets

He doesn't take suggestions well. He often doesn't listen to people who know what they're talking about and becomes prickly and argumentative. On the other hand, I was a squeaky wheel about Shotcut's color rendition and he did a nice job of fixing it.

Use more evidence. Build a better case.

Some things are hard to argue against, like objective facts. If the output color is wrong or inaccurate, you can't argue against that. He has to fix it

Other things are subjective, like I don't like the color of the GUI, or I want so and so preset included - those are more difficult to convince unless you build a better case for it

For example, if you want to improve the xdcamhd422 settings, those ffmbc xdcamhd422 settings are taken directly from the specs, and it has a proven track record of working on strict hardware. If you get that QC report back and it flags a bunch of things look into it more closely and try to figure out why . Compare the settings used, and the MXF muxer. Those are the issues in the past. OTH, it might not be a strict check for compliance, so a "pass" might not mean anything

In the end, all you can do is provide feedback, its up to the dev if they want to implement it or not . You've done your part of the job

[chris319]

Now?

D:\Programs\ffmpeg\BroadcastVideo\ffmpeg -y  -i "Test_pattern_720.mkv"    -vf scale=in_range=full:in_color_matrix=bt709,format=rgb24,lutrgb='r=clip(val,22,227)',lutrgb='g=clip(val,22,227)',lutrgb='b=clip(val,22,227)',scale=out_color_matrix=bt709:out_range=full,format=yuv422p,tinterlace=4    -flags +ilme+ildct  -r 29.97  -vb 50M  -minrate 50M  -maxrate 50M  -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  -f  mxf  clipped.mxf

[poisondeathray]

Now?

D:\Programs\ffmpeg\BroadcastVideo\ffmpeg -y  -i "Test_pattern_720.mkv"    -vf scale=in_range=full:in_color_matrix=bt709,format=rgb24,lutrgb='r=clip(val,22,227)',lutrgb='g=clip(val,22,227)',lutrgb='b=clip(val,22,227)',scale=out_color_matrix=bt709:out_range=full,format=yuv422p,tinterlace=4    -flags +ilme+ildct  -r 29.97  -vb 50M  -minrate 50M  -maxrate 50M  -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  -f  mxf  clipped.mxf

Looks ok except for the clip values and levels. But you said you're ok with that

(And no audio)

[chris319]

The script runs much more slowly with audio added, so I leave it off for testing.

It does not explicitly specify a video codec. We're OK with that?

[chris319]

Here are the results of our file being run through Telestream and Omneon:

The script does not explicitly specify a video codec. We're OK with that?

Ok ran the file, passed.
There were a few warnings but none apply in this case:

Not correct frame rate: ignore as we use 25fps and your clip was 29.97
Audio not within Spec: again, ignore as it’s expecting EBU R128 (-23dBLUFS), yours was -16.
Stereo pair delta: Indicated that the audio content varied by more than 10dB at times, ignore.
There were no “outlier” pixels, colour is broadcast BT709 and it’s TFF, good.
It also contains MXF and SMPTE TC which is set to 00:00:00:00, not a problem in this case, but some
broadcasters insist on a 1 hour TC offset.

I then converted your clip to 25fps, made no other changes and loaded it onto our Omneon playout server.
Played but the “pan” shot of the train was a bit choppy.
Did you perhaps interlace this footage from progressive.
It’s also a tad soft, but it played and was accepted through the chain in our small 6 camera studio.
Pic below, you can see your clip in the preview monitor.
Hope it helps.

[Cornucopia]

Since you are converting to MXF, you are relying on ffmpeg to default to one of the codecs that are allowable for video "essence" streams in MXF. You could specify, but that might make things more difficult, but if you don't specify, you could end up giving it something it doesn't know how to properly process.
My guess is you are ending up sending it AVC-Intra material.
Hopefully not (emulated) XDCAM stuff, see:

FFmpeg, an open source project added support for muxing and demuxing of MXF and MXF D-10 in FFmpeg 0.5, released in March 2009.[4][5]
Note that up to 2019, FFmpeg implements only the base MXF standard but does not provide vendor specific profiles, e.g. one cannot produce a MXF File that is compatible to Sony XDCAM devices due to missing header metadata entries (for further information see ffmpeg trac ticket 5097)

, from Wikipedia - MXF.

Scott

[chris319]

Thanks for that, Scott. I could add -c:v mpeg2video to the script.

Most clients want MXF-OP1A so that's my target and I'm glad my file passed.

A smart client will require a test file to make sure everything plays back OK, at least for first-timers. PBS requires this.

Here is a link to the file that was checked in Telestream/Omneon.

http://www.chrisnology.info/videos/clipped.mxf

I'm still refining the RGB levels in my ffmpeg script. I've written a companion program which reports the max and min RGB levels and had to change the YUV-to-RGB conversion code which pdr helped me with.

[chris319]

This looks interesting and it is free.

https://www.myriadbits.com/index.php/mxf-inspect-2/

[chris319]

I'm about to give up on ffmpeg altogether. It keeps screwing with the video levels I try to set. I've tried every damn thing. So screw it.

I asked how to submit a feature request asking for ffmpeg to write a video file without messing with the levels. Carl Eugen Hoyos seems to have no clue what a "feature request" is and he just stonewalled me.

ffmpeg may be free to acquire a copy of the program but it is hugely expensive in terms of time. I've pissed away countless hours trying to get it to do what I want.

Looking into opencv.

[poisondeathray]

Again, ffmpeg does what you tell it to

Maybe something is wrong with what you told it to do, your assumptions, or your measuring methodology

[chris319]

I'm giving it 255 and I keep getting 235.

[poisondeathray]

I'm giving it 255 and I keep getting 235.

Didn't we go through all this dance already ?





255 what? RGB, YUV ?

235 what? RGB, YUV ?

How are you converting each step? What are you doing each step ?

How are you measuring at the end?



If you go back to the very 1st reply , it's all there

[chris319]

Despite extensive testing, I had my full- and limited-range YUV-to-RGB code reversed. It doesn't help that the white bar on RP 219 bars is 235 because that's exactly what I was getting while the underlying problem was being masked. I had to make a special test signal called a window signal, simply a box at 255-255-255 next to a box at 0-0-0 against a gray background. Now I could see if the whites were coming up to 255, which the SMPTE bars weren't revealing. Using a window signal is a good example of ancient technology helping to solve a modern problem.

I'm still having trouble getting the lutrgb values right. On actual picture content, ringing artifacts seem to bother the lutrgb functions. I hate to apply unsharp and low-pass filter it because the picture is a tiny bit soft to begin with.

To find the bug, sometimes you have to look in the mirror.