yuvj: waveform monitor vs. graph display

[bavc]

yuvj: waveform monitor vs. graph display

[dericed]

At first appearance, I suspect that the ffmpeg histogram filter, which produced the image, is plotting yuvj420p and yuv420p at different ranges. If I try: ffplay /Users/davidrice/Desktop/70D_lumarange.mov -vf "format=yuv422p,histogram=mode=waveform:waveform_mode=column:waveform_mirror=1,crop=iw:256:0:0,drawbox=y=(256-16):w=iw:h=16:[email protected]:t=16,drawbox=w=iw:h=(256-235):[email protected]:t=16" then I do get a waveform that matches the graph data.

[silicontrip]

That video is jpeg range, not mpeg range.

Something is scaling it

TAG:lavfi.values.YMIN=16
TAG:lavfi.values.YMAX=235

Mark

On 22 Sep 2014, at 12:18 pm, Dave Rice [email protected] wrote:

At first appearance, I suspect that the ffmpeg histogram filter, which produced the image, is plotting yuvj420p and yuv420p at different ranges. If I try: ffplay /Users/davidrice/Desktop/70D_lumarange.mov -vf "format=yuv422p,histogram=mode=waveform:waveform_mode=column:waveform_mirror=1,crop=iw:256:0:0,drawbox=y=(256-16):w=iw:h=16:[email protected]:t=16,drawbox=w=iw:h=(256-235):[email protected]:t=16" then I do get a waveform that matches the graph data.

—
Reply to this email directly or view it on GitHub.

[mhusinsky]

this thread might be related:
http://ffmpeg.org/pipermail/ffmpeg-user/2014-February/thread.html#19728

also this bug report:
https://trac.ffmpeg.org/ticket/225

[dericed]

There's only a few yuvj pixel formats, so I'm tempted to fix this via the noformat filter, such as:
ffplay 70D_lumarange.mov -vf "noformat=yuvj420p|yuvj422p|yuvj444p|yuvj440p|yuvj411p,histogram=mode=waveform:waveform_mode=column:waveform_mirror=1,crop=iw:256:0:0,drawbox=y=(256-16):w=iw:h=16:[email protected]:t=16,drawbox=w=iw:h=(256-235):[email protected]:t=16"

[mhusinsky]

but doesn't this introduce luma-compression from JPEG to MPEG range? have a look at the horizontal lines that appear now:

[dericed]

argh good point

[dericed]

I've been looking at this for a while and trying to deduce is the graph is incorrect or the waveform presentation is incorrect. Obviously the graph shows a maximum Y value of 235 while the waveform implies a maximum of 255. When I place the file into other software waveforms, such as FCP7's, I the video peak at 100 IRE (ie 235), which corresponds to the graph but not the waveform. I suspect (and would love help proving or disproving this) that the encoded h264 uses a range of (mostly) 16-235 (as shown by the graph and FCP7) but that ffmpeg stretches the video to a range of 0-255 somewhere between decoding and plotting in the histogram filter, then in the example where I added the noformat part it's getting scaled twice.
If interested the filterchain used for the waveform display of qctools is found here: https://github.com/bavc/qctools/blob/master/Source/GUI/BigDisplay.cpp#L197.

[dericed]

Paul's patch on ffmpeg-devel appears to resolve the issue. It adds the corresponding YUVJ formats as inputs which prevents the YUVJ->YUV conversion before the signalstats analysis. With the patch YMAX now equals 255 which matches the waveform display. Once pulled into ffmpeg we'll include this in the next QCTools release in early October.

[JeromeMartinez]

Fixed in FFmpeg/FFmpeg@bfdf0f0 , now I need to use this patch in the next QCTools release.

[JeromeMartinez]

Confirmed to be OK now, example with 70D_lumarange.mov: