[FFmpeg-devel] [PATCH 2/2] avfilter/vf_histogram: improve waveform mode
cus at passwd.hu
Sat Sep 28 17:50:48 CEST 2013
On Sat, 28 Sep 2013, Paul B Mahol wrote:
> On 9/28/13, Marton Balint <cus at passwd.hu> wrote:
>> On Sat, 28 Sep 2013, Paul B Mahol wrote:
>>> On 9/27/13, Marton Balint <cus at passwd.hu> wrote:
>>>> - faster
>>> How? Are there results and way to reproduce such findings?
>> Sure, here is one benchmark I just made:
>> time ./ffmpeg -i fate-suite/bink/hol2br.bik -vf \
>> format=yuv444p,histogram=mode=waveform -f null -
>> real 0m0.129s
>> user 0m0.109s
>> sys 0m0.019s
>> real 0m0.110s
>> user 0m0.093s
>> sys 0m0.016s
> Hmm, if there are changes that make filter faster with same input/output format
> than it belongs again to separate patch.
Fine, I will split it.
>>>> - handles more pixel formats
>>> Well that it is not nice for output, as subsampled pixel format output
>>> look worse.
>> I tried to keep the original design of the filter by keeping the input and
>> the output pixel format the same.
>> Forcing the the output format to an unsubsampled format can be done, but
>> if the source is subsampled, you may not have the resolution to do that
>> without upscaling.
> This sentence does not make any sense.
> Filter can take YUV411 from input and return YUV444 at output. And no scaling
> of any kind is required.
I meant the following case:
- you got a YUV411 video (512x512) with chroma planes of 128x512.
- with column filter mode you will have a 128x256 waveform.
- but you will have to upscale it to 512x256 for a yuv444 filter output.
So, a yuv444 output also has it's scaling requirements. What do you
>> I think the speed benefit of not forcing a colorspace conversion (a
>> software upscaling) and producing sensible output at the same time is
>> great. The filter can actually now work realtime for me on my HD videos.
> Just because you use yuv420p instead of yuv444p?
>> If anybody prefers the waveform of an upscaled chroma plain in full
>> resolution, he can still do that by forcing the input format of the filter
>> to yuv444p.
> That adds extra processing which is not needed at all.
I meant that the user can force the input formats to the list of the
currently supported unsubsampled formats, this way the filter will work
exactly as before - operating always in full resolution, and with an auto
inserted scaler (extra processing) for subsampled inputs.
>> Look, if it were up to me, I'd only draw the waveform of a single plane
>> but always IN AV_PIX_FMT_GRAY8 format with the proper resolution for the
>> plane. But this would obviously mess up the current design of the
>> histogram filter, so I had two chices. Make the best of the histogram
>> filter, or create a separate waveform filter (which probably will never be
>> accepted into ffmpeg because we already have a waveform filter).
> There are already overlay and parade display mode, and adding other modes
> would not be hard.
> If you want to have waveform of only say U plane, use histogram in combination
> with extractplanes filter.
>>>> - added parameter to mirror the waveform (high values are shown on top
>>>> column mode)
>>> I do not like when bunch of unrelated changes are put into single patch.
>>> What is point of this mirror thing? Isn't there already filter(s) that do
>> Mirror mode ensures that high luminance/chrominance values are shown on
>> the top of the waveform in column mode, which is I think how most consumer
>> scopes work.
> Good, but than do that in separate patch.
>> In parade mode you have to mirror the waveform of each plane individually,
>> not the whole frame, so a simple flip filter won't work.
>> I can split the patch to two parts, if you prefer, but I thought since it
>> adds minimal extra complexity and touches new code anyway, it is not
> Patch that changes existing code should change a little as possible, and
> that is for easy reviewing and/or accepting patches.
More information about the ffmpeg-devel