Broadcast range filter display inaccuracy on yuv422p input

[bavc]

Broadcast range filter display inaccuracy on yuv422p input

[epiil]

[dericed]

ffprobe -f lavfi -i color,geq=lum_expr=15,signalstats=stat=brng -show_entries frame_tags=lavfi.signalstats.BRNG -of flat
yields
frames.frame.0.tags.lavfi_signalstats_BRNG="1"
because lum_expr=15 sets y to 15 which makes the whole frame outside of broadcast range.

ffprobe -f lavfi -i color,geq=lum_expr=16,signalstats=stat=brng -show_entries frame_tags=lavfi.signalstats.BRNG -of flat
yields
frames.frame.0.tags.lavfi_signalstats_BRNG="0"
because now y is 16 so the whole frame is in broadcast range.

Similarly
ffprobe -f lavfi -i color,geq=lum_expr=235,signalstats=stat=brng -show_entries frame_tags=lavfi.signalstats.BRNG -of flat
gives
frames.frame.0.tags.lavfi_signalstats_BRNG="0"
and
ffprobe -f lavfi -i color,geq=lum_expr=236,signalstats=stat=brng -show_entries frame_tags=lavfi.signalstats.BRNG -of flat
gives
frames.frame.0.tags.lavfi_signalstats_BRNG="1".
Right?

[dericed]

@epiil could you share a few frames of your sample?

[epiil]

[epiil]

These are signal-generated NTSC bars, confirmed on a calibrated Tek WFM to be within broadcast range. The "Value Highlight" filter puts the black chip and adjacent blanking (on the left) at Code 16. If this is the case, then BRNG is set to report on 0-16, which is incorrect. I don't understand what "because lum_expr=15 sets y to 15 which makes the whole frame outside of broadcast range" means. Can you elaborate?

[dericed]

Is the attachment intended to be a full range yuvj444p jpeg? It contains many luma values outside of broadcast range (see: https://gist.github.com/dericed/85c1e4cab4d8a9c57ad5, occurrence in column 1 and hex value of the luma sample in column 2).
I see that Value Highlight is one value off in its highlight so a min of 15 will highlight pixels where y=14. I'll start another ticket for this.

By "because lum_expr=15 sets y to 15 which makes the whole frame outside of broadcast range" I'm demonstrating the brng test by generating a frame where all y values are equal to 15 (out of broadcast range) so "brng" equals the maximum value of 1, whereas if I generate a sample with all y values at 16 then brng equals 0 as none of the frame is outside of broadcast range.

[epiil]

The attached TIFF might have made an incorrect pixel format conversion, but nonetheless QCTools is reporting the following:

You can see which portion of the image is reporting as Code 16, and how said value is reflected in BRNG.

[epiil]

Here's the technical metadata of the video:

General
Complete name : /Volumes/AFA SHUTTLE 3/NTSC Bars.mov
Format : MPEG-4
Format profile : QuickTime
Codec ID : qt
File size : 30.8 MiB
Duration : 3s 570ms
Overall bit rate : 72.3 Mbps
Encoded date : UTC 2014-09-13 18:45:28
Tagged date : UTC 2014-09-13 18:45:32
Writing library : Apple QuickTime
com.apple.proapps.logNote : Untitled 01
com.apple.proapps.reel : 001
com.apple.proapps.scene : Scene 01
com.apple.proapps.shot : 01
com.apple.proapps.angle : 01

Video
ID : 1
Format : ProRes
Format version : Version 0
Format profile : High
Codec ID : apch
Duration : 3s 570ms
Bit rate mode : Constant
Bit rate : 70.7 Mbps
Width : 720 pixels
Height : 486 pixels
Display aspect ratio : 4:3
Frame rate mode : Constant
Frame rate : 29.970 fps
Standard : NTSC
Color space : YUV
Chroma subsampling : 4:2:2
Scan type : Interlaced
Scan order : Top Field First
Stored scan order : Bottom Field First
Bits/(Pixel*Frame) : 6.742
Stream size : 30.1 MiB (98%)
Writing library : Apple
Language : English
Encoded date : UTC 2014-09-13 18:45:28
Tagged date : UTC 2014-09-13 18:45:32
Color primaries : BT.601 NTSC
Transfer characteristics : BT.709
Matrix coefficients : BT.601

Audio
ID : 2
Format : PCM
Format settings, Endianness : Little
Format settings, Sign : Signed
Codec ID : sowt
Duration : 3s 570ms
Bit rate mode : Constant
Bit rate : 1 536 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Stream size : 669 KiB (2%)
Language : English
Encoded date : UTC 2014-09-13 18:45:28
Tagged date : UTC 2014-09-13 18:45:32

Other
ID : 3
Type : Time code
Format : QuickTime TC
Duration : 3s 570ms
Time code of first frame : 00:00:00:00
Time code settings : Striped
Title : time
Language : English

[dericed]

@epiil sample?

[dericed]

I've been unable to reproduce this. With test files that have Y=16 it is not returned as illegal. The associated test here https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/vf_signalstats.c#L158 only qualifies Y samples if the value is lesser than 16 or greater than 235. If you have a sample that reports Y=16 as illegal in the BRNG filter please re-open with a sample.

[dericed]

Found that when the output of signalstats=out=brng:c=FFFF00 is scaled by qctools default scaler the result becomes corrupted and inaccurate (the gridded yellow effect noted above). Formatting the input to remove chroma subsampling via yuv444p fixes the issue. See:
ffplay -v debug "/Users/drice/Desktop/digisigbarsPR.mov" -vf 'signalstats=out=brng:c=FFFF00,format=yuv444p,scale=720:486' vs ffplay -v debug "/Users/drice/Desktop/digisigbarsPR.mov" -vf 'signalstats=out=brng:c=FFFF00,scale=720:486'

[dericed]

Fixed in 86fd301

[epiil]

Thanks Dave!