ffmpeg Color Range

[poisondeathray]

vapoursynth also has "limiter" that works for both YUV , RGB. I think avisynth's limiter is YUV only. But I think he had problems getting either of them working



You can clip with ffmpeg too. eg. -vf lutyuv, lutrgb. Make sure you explicitly control the input and outputs for each step. For example, you can't just input a normal YUV video and use lutrgb . Otherwise you will get a limited range 601 conversion to RGB before the filter.

Walk through it step by step, keeping in mind what pixel format you're currently in at that point, and you can test the direct output of each step to verify if you wanted to . E.g. output a .rgb (or maybe a .bmp) if testing 8bit RGB, output .yuv if testing YUV

You can use -vf scale with in_color_matrix, out_color_matrix, in_range, out_range . An east way to remember it is the argument you need to fill "points" in the YUV direction. So if you were converting YUV to RGB you would need the "in" commands. RGB to YUV would need the "out" commands . For your purpose, full range is what you want for the to/from RGB step

[jagabo]

I had forgotten about the Limiter() filter in AviSynth.

Keep in mind that most YUV combinations within their respective min/max ranges are still illegal. For example, the YUV triad 200,200,200 is way outside the RGB cube. The easiest way I know of to eliminate those colors is to convert to RGB then back to YUV. Of course, you lose a little accuracy and will end up with some chroma blurring when chroma is subsampled.

[poisondeathray]

Keep in mind that most YUV combinations within their respective min/max ranges are still illegal. For example, the YUV triad 200,200,200 is way outside the RGB cube. The easiest way I know of to eliminate those colors is to convert to RGB then back to YUV. Of course, you lose a little accuracy and will end up with some chroma blurring when chroma is subsampled.

Exactly ; Converting to RGB "culls" those YUV values that "map" to out of gamut negative RGB values. And clipping to [5,246] makes it 100% perfect.... If you stay in RGB.

But some out of gamut combinations come back when you convert to back to YUV and subsample. New values are generated from the math, no matter what algorithm is used. Clipping min/max won't get those values, they can appear in the middle of the range.

However, if I omit the romin, etc., the colors are accurate by actual test.

I meant from a YUV source, apply the filter with no clipping. This necessitates a RGB conversion, since the filter is a RGB filter
-vf colorlevels=romin=0:gomin=0:bomin=0:romax=1:gomax= 1:bomax=1

Then it depends on what your input video is:

A) If your input video has the matrix flag in the metadata, ffmpeg will use the flag to guide the conversion to RGB. So if you got no change, your video must be flagged 709.

B) If your input video is unflagged it will use default 601, and your colors will shift

This can be good and bad. There are many cases where videos are unflagged (e.g. many intermediate formats, uncompressed video, raw video pipes in/out of ffmpeg, many random videos) , or cases where input videos are flagged incorrectly

The colors I use for testing are in the RGB range of 16 - 180 so they shouldn't clip.

RGB color bars are less useful here, because your input is YUV.

It's a bit tricky to get correct YUV bars (as per rp219) when using 16-180 (75% RGB for 16-235) , instead of 191 (75% RGB for 0-255) , because none of the equations use strict studio RGB in ffmpeg . The range is correct, but the colors are a bit off . For example if you use full range 709, you get YUV 51,109,210 for "red" . But it should be 51,109,212 as per rp219. Green becomes YUV 133,65,54, but should be 133,63,52 as per rp219. For every bar, the Y level is correct, but every color is slightly off in the either the U,V channel or both U,V

But if you use 191 (75% RGB for 0-255), you get perfect match for all YUV colors with rp219 when using limited range 709 equation.

_Al_ knows this, but people noticed this slight color shifting with sony vegas. This is because Vegas uses true studio RGB function. There is a way to correct this for colors in vapoursynth/avisynth, using RGB float and levels. It might be possible in ffmpeg, IIRC jagabo wrote a levels function


In normalized 0-1 range, the input low 0.062, input high 0.92 . Those are actually the values given for vegas studio RGB to computer RGB filter, and it works. This is for gamma encoded RGB (not linearized RGB). Output is YUV444, but you can change it (if you do, for the vapoursynth version you might want to change "point" to bicubic or other resizer)

So this is RGB 75% for RGB[16-235] to YUV color bars as per rp219 , to adjust for the slight color errors (Or you could just use 191, RGB[0-255] to generate the perfect YUV as per rp219)

avisynth

#Load your RGB 75% of 16-235 source
ConvertToPlanarRGB()
ConvertBits(32)
Levels(0.063,1,0.92,0,1)
ConvertBits(8)
ConvertToYV24(matrix="rec709")

vapoursynth

import vapoursynth as vs
core = vs.get_core()
clip = #sourcefilter #RGB  75% of 16-235 source
clip2 = core.resize.Point(clip, format=vs.RGBS) 
clip2 = core.std.Levels(clip2, min_in=0.063, max_in=0.92, gamma=1, min_out=0, max_out=1, planes=[0,1,2]) 
clip2 = core.resize.Point(clip2, format=vs.YUV444P8, matrix_s="709")

clip2.set_output()

(The vapoursynth bars plugin _Al_ mentioned above generates exact match as the rp219 document for 8,10,12 bit. I didn't verify the HDR and 2020 variants in Bt2111 but I suspect they are perfect too.)

[chris319]

It's a bit tricky to get correct YUV bars (as per rp219) when using 16-180 (75% RGB for 16-235) , instead of 191 (75% RGB for 0-255) , because none of the equations use strict studio RGB in ffmpeg . The range is correct, but the colors are a bit off . For example if you use full range 709, you get YUV 51,109,210 for "red" . But it should be 51,109,212 as per rp219. Green becomes YUV 133,65,54, but should be 133,63,52 as per rp219. For every bar, the Y level is correct, but every color is slightly off in the either the U,V channel or both U,V

But if you use 191 (75% RGB for 0-255), you get perfect match for all YUV colors with rp219 when using limited range 709 equation.

Before we go any further, please post the equations you are using to get from RGB to YUV and from YUV to RGB in BT.709. Yes, red should be 51-109-212 per RP 219, Fig. 3-2.

What I need is an eyedropper/color picker tool which reads in BT.709 YUV. Know of one? I have one which reads RGB.

[poisondeathray]

Before we go any further, please post the equations you are using to get from RGB to YUV and from YUV to RGB in BT.709. Yes, red should be 51-109-212 per RP 219, Fig. 3-2.

For what scenario? Did you want full range for clipping, or limited range for general use? For ffmpeg it's just using those in_color_matrix, out_color_matrix, in_range, out_range .

If it's for bars, I already explained above, if you want perfect match, use 191,0,0 for 75% red 0-255 RGB (computer range RGB). Then ffmpeg can do RGB=>YUV and get YUV 51,109,212 (and all the other colors match too) . ie. It's just the regular conversion (limited range, 709) for computers.

But if you start with RGB 180,16,16 for 75% red in 16-235 RGB (studio range RGB), you need to use full range, 709 conversion, plus that levels workaround, otherwise slight color mismatch.

That's RGB to YUV.


YUV to RGB is just the regular conversion for computers to get back the original 75% 0-255 RGB

For the YUV to RGB back to 180,16,16 75% 16-235 case, you need another levels adjustment Levels(0,1,1,0.06,0.92), to emulate the actual studio RGB conversion (something like vegas would do)

eg. for avisynth; (not sure how to do for ffmpeg, because it doesn't have a levels filter, although IIRC, jagabo wrote one up somewhere for ffmpeg)

#YUV source
ConvertBits(32)
ConvertToPlanarRGB(matrix="rec709")
Levels(0,1,1,0.06,0.92)
ConvertBits(8)

Recall for the bars, in both cases the YUV values should be the same (the exact numbers given in rp219). This discussion is just clarifying using 2 different RGB scales intended for different systems (studio level RGB vs. computer RGB)

What I need is an eyedropper/color picker tool which reads in BT.709 YUV. Know of one? I have one which reads RGB.

It doesn't matter if it's 601,709,2020 etc... You want to read the raw YUV values

"BT. 709 YUV" implies a conversion is going on somewhere, for example a RGB color picker that converted YUV to RGB using 709.

Anyways -

avisynth , avspmod for 8bit values . It can read YUV or RGB directly

vapoursynth, vsedit. This is more versatile because it can read 8bit, 10bit, 12bit, 16bit, negative RGB (RGB float), negative YUV (YUV float) etc....

[chris319]

Here is the equation to convert Red to Y in 709:

180*0.2126+16*0.7152+16*0.0722 = 51

It uses 709 coefficients. 51 is the correct answer per RP 219.

Now let's rework the equation using 255 * 0.75, or 191:

191*0.2126+0*0.7152+0*0.0722 = 41

41 is not compliant with RP219. See Fig. 3-2 of the spec. I know I've gone through this exercise before, either with you or someone else.

Now let's see the equation you're using to convert Red to U and Red to V and we'll see if we get 109 and 212 per the spec. No vapoursynth or avisynth code or palaver. A simple equation as above that I can plug into Excel.

[poisondeathray]

The equation you're using is for studio range RGB . If you use 191 you need to use the computer RGB to YUV equation, so you're using the wrong equation for that scenario. I'm pretty sure this was demonstrated in another thread


I'm not using equations, just demonstrating actual usage, actual video. And the values match RP219 exactly. Real measurements on real video. You don't have to use avisynth or vapoursynth, there are various raw yuv parser utilities, some free, some commercial

You can look up actual the equations used for excel. It's open source.

[chris319]

The equation you're using is for studio range RGB .

BT.709 is all studio range. I'm not interested in full/computer/0 - 255 range, period. BT.709 makes no provision for "computer range".

I'm asking for the equation that makes 191-0-0 equal to 109/212 in PB and PR per RP 219 and you keep dodging the question. Using 191 makes Y levels that do not comply with RP 219 as I've proven in the past. Using 180 and 16 is RP 219 as I've demonstrated in the past.

[jagabo]

Full range RGB (0 to 255) to limited range (Y = 16 to 235, U/V = 16 to 240): rec.709:

y = 16.0 + r*(0.2126*219/255) + g*(0.7152*219/255) + b*(0.0722*219/255);

for RGB 191,0,0

y = 16.0 + 191*(0.2126*219/255) + 0*(0.7152*219/255) + 0*(0.0722*219/255);
y = 16.0 + 34.874
y = 50.874 rounds up to 51

[chris319]

I already demonstrated how to calculate Y. Nobody seems to know U and V (or PB and PR).

[poisondeathray]

The equation you're using is for studio range RGB .

BT.709 is all studio range. I'm not interested in full/computer/0 - 255 range, period. BT.709 makes no provision for "computer range".

Again, you're not delivering in RGB, you're delivering YUV.

Usually you're using computer RGB on a computer, unless you're setup for studio RGB on a computer. Do you have 2 displays?

Again, you get the correct results, 100% perfect in YUV as per rp219 if you use 191,0,0 and the proper equation (all the rp219 colors, not just red). You can look up the equation if you want to, I don't know it offhand. I'm more interest in actual video results than spreadsheets

I'm asking for the equation that makes 191-0-0 equal to 109/212 in PB and PR per RP 219 and you keep dodging the question. Using 191 makes Y levels that do not comply with RP 219 as I've proven in the past. Using 180 and 16 is RP 219 as I've demonstrated in the past.

You've proven that when you use the wrong equation you get the wrong results for 191,0,0 .

I don't know the equation, you look it up in the code. I know the commands and usage to get the results for actual video. I'm pretty sure jagabo made a little chart and posted the equation in your other thread


RGB 191,0,0 EXACTLY matches RP219 giving 51,109,212, when you use the proper conversion . 100% definitively proven, not theoretical math. Actual video. Actual usage . You can even do this one in ffmpeg right now.

Yours probably works too, in excel, at least on "paper." Does it work for real? So where is the video ? Where is the physical evidence and proof ?

For RGB 180,16,16 - The problem is nobody coded the proper equations in ffmpeg. That full range 709 equation gets the levels correct, but the colors are slightly off. It's a close approximation - I posted the workaround to get the exact YUV values when using RGB 180,16,16. That uses existing conversion code. A cleaner way would be to use the correct equation in the first place. Submit a patch if you want

[chris319]

After all this we're no closer to a solution to my original problem.

[poisondeathray]

After all this we're no closer to a solution to my original problem.

Which original problem? I already posted the answer for "unity"


I already mentioned this, but again, the "full range conversion" is just a name used for a conversion . It's independent of the actual data levels.

It's called "full range conversion" because the "full range" of Y is mapped to RGB . It's 1:1 . Y 0-255 <=> RGB 0-255. If you had Y 16-235 <=> RGB 16-235 . That's your "unity" that you requested at the beginning of the thread. Nothing is forced. If your C program spit out RGB 35,35,35, you would get YUV 35,128,128

Where "limited range conversion" takes Y 16-235 <=> RGB 0-255 . Limited because the "limited" Y range of 16-235 is used in the conversion. <16, >235 are clipped

The problem I see is the ffmpeg full range 709 conversion indeed keeps the correct Y range, but the U,V values are off by 1 or 2 compared to the studio RGB conversion . The range is correct, but it's not the exact studio RGB function and the colors are slightly off.... But you're going to 8bit RGB and back to 8bit YUV, lossy compression - so you're going to get rounding errors anyways +/- a few. Subsampling on top of that. Subsampling can generate wildly off pixel values like -40. It's way worse



It might be that ffmpeg is doing some other conversions inbetween or in the background that you're not aware of

Or am I misreading the original problem?

[chris319]

It might be that ffmpeg is doing some other conversions inbetween or in the background that you're not aware of

I think that's what's going on.

[jagabo]

I already demonstrated how to calculate Y.

You posted the equation for limited range RGB to limited range rec.709. Then you asked how 191,0,0 can lead to the correct limited range rec.709 Y value of 51. I gave the full range RGB to limited range rec.709 equation -- which does exactly that.

Nobody seems to know U and V (or PB and PR).

Full range RGB to limited range rec.709:

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 might be that ffmpeg is doing some other conversions inbetween or in the background that you're not aware of

I think that's what's going on.

going to need some more info than that...


some examples, maybe simple ones like colors, gradients

what you expected, vs. what you actually got

command lines used

[chris319]

I coded up jagabo's YUV equations for red in Excel using R-G-B 191-0-0:

= 128 - 191*(0.2126*112/255)/(1-0.0722) - 0*(0.7152*112/255)/(1-0.0722) + 0*(112/255)

The result is 109 which is the correct PB value for the red bar, per RP 219.

= 128 + 112/255*191 - 0.7152*112/255*0/(1-0.2126) - 0.0722*112/255*0/(1-0.2126)

The result is 212 which is the correct PR value for the red bar, per RP 219.

Nice work, jagabo, thanks! You guys are right and I'm proven wrong

[chris319]

Back on topic.

What is the output here? Does it step through all of the frames in the input video and output a playable video file? What about audio (though I can deal with that separately)?

import vapoursynth as vs
from vapoursynth import core
import numpy as np

source_path=r'G:/test_file.mp4'
clip = core.lsmas.LibavSMASHSource(source_path)

#trimming for testing
#clip = clip[3000:3200]

MIN = 5
MAX = 246

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

def restrict_rgb_frame(n,f):
    #this converts vapoursynth rgb frame to numpy array 
    np_image = np.dstack([np.array(f.get_read_array(i), copy=False) for i in range(3)])

    #this restricts values in numpy array image
    clipped_np_image = np.clip(np_image, a_min = MIN, a_max = MAX)

    #this changes numpy array type back to vapoursynth VideoFrame type
    vs_frame = f.copy()
    [np.copyto(np.asarray(vs_frame.get_write_array(i)), clipped_np_image[:, :, i]) for i in range(3)]

    return vs_frame


clipped_rgb = core.std.ModifyFrame(rgb_clip, rgb_clip, restrict_rgb_frame)
clipped_yuv = core.resize.Point(clipped_rgb, matrix_s='709', format = vs.YUV420P8)

clip.set_output(0)
clipped_rgb.set_output(1)
clipped_yuv.set_output(2)  #to actually encode for studio

[_Al_]

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

[poisondeathray]

The output is whatever you send it to. You can pipe it to ffmpeg for example, using vspipe. Or to x264, or to x265, or whatever application. It's either rawvideo pipe or y4m pipe

ffmpeg binaries can be compiled with native vapoursynth support (compiled with vapoursynth demuxer) , so you can open .vpy directly with ffmpeg . Common public distributions tend not to have it. But they tend to have avisynth support compiled natively, because it's so common (for windows that is).

Not very many players have native vapoursynth support (more have avisynth support) . Potplayer, mpchc have native vpy support. Vdub2 also has native vpy support (not really a "player")

To preview scripts you can use vsedit . You can play scripts too with it. Also has the color picker and many more functions

Audio support is currently being worked on in vapoursynth (immature, WIP). Audio is supported in avisynth (mature)

For vapoursynth audio you could use two inputs (video stream .vpy, audio stream native) into ffmpeg using -map



The problem with that script is it's converting to RGB using the standard method, "computer RGB". RGB for r103 requires using the full range conversion. Y 16-235 <=> RGB 16-235. And the conversion essentially is the same as ffmpeg using full range 709 (U,V channel will be slightly off compared to what ITU uses , or sony vegas uses, for real studio RGB; but since you're using the same method both ways YUV=>RGB=>YUV, the difference sort of cancels out, and the magnitude is tiny compared to subsampling issues) . The reference black and white level are 16,16,16 and 235,235,235 in studio level RGB. I'm not talking about excursions, but the reference black and white. Not 0,0,0 and 255,255,255 (that latter is for computer range RGB conversion).

add range_in_s = "full" to the RGB conversion
add range_s = "full" to the YUV conversion

[_Al_]

and this is another line that limits values in Vapoursynth, as pdr reminded of:

clipped_rgb = core.std.Limiter(rgb_clip, MIN, MAX, planes=[0, 1, 2])

Also not sure about that last line that brings YUV420P8 from RGB, maybe Bilinear would work better than Point, not really sure there,
but with that poisondeathray's correction so far:

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, range_in_s = "full")
clipped_rgb = core.std.Limiter(rgb_clip, MIN, MAX, planes=[0, 1, 2])
clipped_yuv = core.resize.Point(clipped_rgb, matrix_s='709', format = vs.YUV420P8, range_s = "full")

clipped_yuv.set_output(0)

[chris319]

FWIW, here is a new test pattern clip with the correct colors:

https://www.youtube.com/watch?v=eBSVzLZD6Js

[_Al_]

I dont think it is useful much , going thru youtube,
if you used vapoursyth editor, you get real YUV values for an output.
Then there is one more step, encoding, so hopefully values do not change much, but that should be ok.
look at vapoursynth editor , you go over with mouse and it gives you YUV values:

[poisondeathray]

FWIW, here is a new test pattern clip with the correct colors:

https://www.youtube.com/watch?v=eBSVzLZD6Js

FYI, some Y,U,V values are slightly off when you download the video. Even Y is off for red
eg. "Red" is YUV 50,108,211

For 8bit RGB => 8bit YUV , you should be able to get perfect YUV values matching rp219. Even with youtube compression.

[_Al_]

if I use this:

rgb_clip = core.resize.Point(clip, matrix_in_s = '709', format = vs.RGB24, range_in_s = "full")
clipped_rgb = core.std.Limiter(rgb_clip, MIN, MAX, planes=[0, 1, 2])
clipped_yuv = core.resize.Point(clipped_rgb, matrix_s='709', format = vs.YUV420P8, range_s = "full")

I get green as YUV420P8 y:137 u:54 v:41
if I use this:

rgb_clip = core.resize.Point(clip, matrix_in_s = '709', format = vs.RGB24)
clipped_rgb = core.std.Limiter(rgb_clip, MIN, MAX, planes=[0, 1, 2])
clipped_yuv = core.resize.Point(clipped_rgb, matrix_s='709', format = vs.YUV420P8

I get green as YUV420P8 y:134 u:63 v:52


the whole script for green as y:134 u:63 v:52, (and red y:51 u:109 v:212):

import vapoursynth as vs
from vapoursynth import core
c = core.colorbars.ColorBars(format=vs.YUV444P10)
c = core.std.SetFrameProp(clip=c, prop="_FieldBased", intval=0) 
c = core.std.Convolution(c,mode="h",matrix=[1,2,4,2,1])
c = core.resize.Point(clip=c, matrix_in_s ='709', format=vs.YUV420P8)
c = c * (30 * 30000 // 1001)
clip = core.std.AssumeFPS(clip=c, fpsnum=30000, fpsden=1001)
MIN = 5
MAX = 245

rgb_clip = core.resize.Point(clip, matrix_in_s = '709', format = vs.RGB24)
clipped_rgb = core.std.Limiter(rgb_clip, MIN, MAX, planes=[0, 1, 2])
clipped_yuv = core.resize.Point(clipped_rgb, matrix_s='709', format = vs.YUV420P8)
clipped_yuv.set_output()

[chris319]

I am reluctant to use ffmpeg for this until we get to the bottom of any video-level issues.

Again, my C program reads video frames into an array, then writes the frames out to a file using ffmpeg. The video data passes through a LUT which confines the RGB levels to 5 - 246. Everything seems to work fine until the frames are written out with ffmpeg; then I'm getting levels in the 0 - 255 range.

[poisondeathray]

I am reluctant to use ffmpeg for this until we get to the bottom of any video-level issues.

Again, my C program reads video frames into an array, then writes the frames out to a file using ffmpeg. The video data passes through a LUT which confines the RGB levels to 5 - 246. Everything seems to work fine until the frames are written out with ffmpeg; then I'm getting levels in the 0 - 255 range.

What is 0-255 ? RGB or YUV ?

If YUV, it could be subsampling

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

[chris319]

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.

[chris319]

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.

[chris319]

I get green as YUV420P8 y:137 u:54 v:41

I get green as YUV420P8 y:134 u:63 v:52
the whole script for green as y:134 u:63 v:52

Green is supposed to be YUV:
133-63-52

That first result is too far off.