Dave Rice wrote:
On Feb 7, 2016, at 4:57 PM, Andy Furniss <[email protected]> wrote:
Dave Rice wrote:
On Feb 7, 2016, at 1:42 PM, Paul B Mahol <[email protected]>
wrote:
On 2/5/16, Paul B Mahol <[email protected]> wrote: On 2/5/16,
Dave Rice <[email protected]> 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.
_______________________________________________
ffmpeg-user mailing list
[email protected]
http://ffmpeg.org/mailman/listinfo/ffmpeg-user
