[FFmpeg-devel] [PATCH] avfilter: add vmafmotion filter

Tobias Rapp t.rapp at noa-archive.com
Wed Sep 13 17:09:54 EEST 2017


On 13.09.2017 15:10, Ronald S. Bultje wrote:
> Hi,
> 
> On Wed, Sep 6, 2017 at 4:04 PM, Ashish Pratap Singh <ashk43712 at gmail.com>
> wrote:
> 
>> From: Ashish Singh <ashk43712 at gmail.com>
>>
>> Hi, this patch changes previous one to framesync2.
>> SIMD is a work in progress for this filter.
>>
>> Signed-off-by: Ashish Singh <ashk43712 at gmail.com>
>> ---
>>   Changelog                   |   1 +
>>   doc/filters.texi            |  16 ++
>>   libavfilter/Makefile        |   1 +
>>   libavfilter/allfilters.c    |   1 +
>>   libavfilter/vf_vmafmotion.c | 413 ++++++++++++++++++++++++++++++
>> ++++++++++++++
>>   libavfilter/vmaf_motion.h   |  42 +++++
>>   6 files changed, 474 insertions(+)
>>   create mode 100644 libavfilter/vf_vmafmotion.c
>>   create mode 100644 libavfilter/vmaf_motion.h
> 
> 
> One more general comment on this filter: it appears to me that the motion
> is calculated based on the reference, and we only use the "main" to apply
> the metadata to. Although this makes sense from the "vmaf" filter
> perspective, I'm actually wondering if - from the perspective of the
> "vmafmotion" filter alone, it wouldn't be simpler to just have a single
> filterpad input ("reference") and apply the metadata on it (when used by
> itself). (The "vmaf" filter could still apply metadata on the "main").
> 
> What do people think? Would you prefer the "vmaf" and "vmafmotion" to
> consistently apply the metadata on the "main" video frames, or would you
> prefer that the "vmafmotion" filter more accurately presents which frame is
> used for the motion scoring, which also happens to lead to simpler code /
> filterchains?

So when I understand this correctly the "vmafmotion" filter would work 
similar (in structure) to the "idet" filter, comparing consecutive 
frames on a single filterpad input and attaching metadata to the output 
frames? Yes, that would make using the "vmafmotion" filter more simple 
and flexible, IMHO.

Regards,
Tobias



More information about the ffmpeg-devel mailing list