[FFmpeg-user] clipping samples to broadcast range in an mpeg2video output

[Andy Furniss]

Dave Rice wrote:
>
>> On Feb 7, 2016, at 4:57 PM, Andy Furniss <adf.lists at gmail.com> wrote:
>>
>> Dave Rice wrote:
>>>
>>>
>>>>> On Feb 7, 2016, at 1:42 PM, Paul B Mahol <onemda at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On 2/5/16, Paul B Mahol <onemda at gmail.com> wrote: On 2/5/16,
>>>>>> Dave Rice <dave at dericed.com> wrote: Hi all, I am having trouble
>>>>>> creating an mpeg2video output that conforms to 16-235 broadcast
>>>>>> range. I'd like to find a way to have an input which is
>>>>>> yuv420p but has luma values out of broadcast range but clip to
>>>>>> broadcast range while encoding to mpeg2.
>>>>>>
>>>>>> To demonstrate the issue, I generate a yuv420p file with
>>>>>> samples in the out of broadcast range via:
>>>>>>
>>>>>> ffmpeg -f lavfi -i
>>>>>> "nullsrc=s=256x256,geq=random(1)/hypot(X-cos(N*0.07)*W/2-W/2\,Y-sin(N*0.09)*H/2-H/2)^2*1000000*sin(N*0.02):128:128"
>>>>>>
>>>>>>
>> -c:v ffv1 -t 10 sample.mkv
>>>>>>
>>>>>> I can then clip the samples using clipval in the lut filter and
>>>>>> see the clipped values in a waveform with:
>>>>>>
>>>>>> ffmpeg -i sample.mkv -vf lut=y=clipval:u=clipval:v=clipval -c:v
>>>>>> ffv1 -f nut - | ffplay - -vf waveform The waveform shows the
>>>>>> values clipped at 16 and 235.
>>>>>>
>>>>>> However I need the output to use mpeg2video. When I change
>>>>>> lossless ffv1 to mpeg2video with:
>>>>>>
>>>>>> ffmpeg -i sample.mkv -vf lut=y=clipval:u=clipval:v=clipval
>>>>>> -c:v mpeg2video -f nut - | ffplay - -vf waveform
>>>>>>
>>>>>> The output shows many sample values above 235. The lossy
>>>>>> mpeg2video encoding seems to place values above 235 while the
>>>>>> lossless ffv1 doesn't. Is there a way to encode in mpeg2video
>>>>>> without having values over 235 in the output?
>>>>>
>>>>> Appears to be mpeg2video bug, can others confirm?
>>>>
>>>> It appears that having out of range values is OK, its player
>>>> responsibility to clip values that are out of range.
>>>
>>> The players involved are broadcast television servers which do not
>>> clip the values. The broadcast specification that I'm trying to
>>> adhere to requires both mpeg2 encoding and clipping out of range
>>> values. Dave Rice
>>
>> Disclaimer - I know nothing about broadcasting!
>>
>> Random observations.
>>
>> I have looked at the yuv values of decoded broadcast mpeg2/h264 and
>> there are plenty of over/under samples produced.
>>
>> Your sample is quite extreme so has more than "real" stuff would.
>
> OK, I made a new test with real world stuff. I uploaded the real-world sample along with a waveform gif and then waveform gifs for the sample encoded to ffv1 and mpeg2video. It is here: https://github.com/dericed/ffmpeg-mpeg2video-clipping/blob/master/README.md <https://github.com/dericed/ffmpeg-mpeg2video-clipping/blob/master/README.md>
>
> The git of the ffv1 encoding shows that out of broadcast range values are clipped (by the lut filter), but with the mpeg2video encoding it introduces many out of broadcast range values.
>
>> If your source is full range then maybe it should be scaled rather than
>> clipped.
>
> The source file is yuv422p10le, not yuvj422p10le. I believe the sample is intended to be interpreted at broadcast range and not full range, though it has values out of broadcast range.

Ok it does seem to be tv range eg. many samples at 16 (after converting 
to 8bit)

>> "The players involved are broadcast television servers"
>>
>> confuses me - are they mpeg encoders needing clipped raw input, in which
>> case the lut does its job, or do they take some high bitrate mpeg2 you
>> are trying to make? If so maybe there will be less over/under from that
>> than this test.
>
> The mpeg decoders (of the broadcast server) need high bitrate mpeg2 with clipped luma values. However when the mpeg2video encoder encodes the clipped output of lut, it adds out of range values back.
> Dave Rice

Yea, I didn't know that happened so much before this post. It's not just 
mpeg2 though, it's the same with libx264.

Higher bitrate helps - testing with your sample mpeg2 -b:v 40M and 80M 
produces a far "tighter" spread. Still over and unders, though.

I don't know how fussy your kit is, but at 80M I think the range may be 
acceptable to UK broadcasters, which according to this give some leeway.

https://drive.google.com/file/d/0BxP5-S1t9VEEaTFsRGFldXZPdEE/view?usp=sharing

2.3.1 Measuring signal levels
Digital video levels are usually measured with a device which displays a 
trace like a traditional
waveform monitor. This gives readings in mV (emulating an analogue 
signal), or as a percentage of the
allowable levels.
The limits of signal levels are defined by reference to a nominal black 
level and a nominal white level.
Black level comprises R, G and B all at zero (or 0% or 0mV) and white 
level is all three components at
100 % or 700mV.
In a picture signal, each component is allowed to range between 0 and 
100% (or 0mV and 700mV).
This equates to digital sample levels 16 and 235 (8-bit systems) or 64 
and 940 (10 bit systems).
2.3.2 Tolerance of out of gamut signals
In practice it is difficult to avoid generating signals slightly outside 
this range, and it is considered
reasonable to allow a small tolerance, which has been defined as follows 
under EBU Rec103:
•
RGB components must be between -5 % and 105% (-35 and 735mV)
and
•
Luminance (Y) must be between -1% and 103% (-7mV and 721mV)
Slight transient overshoots and undershoots may be filtered out before 
measuring, and an error will only
be registered where the out of gamut signals total at least 1% of 
picture area. Many monitoring devices
are designed to detect errors to this specification.