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

[Paul B Mahol]

On 10/7/17, Ronald S. Bultje <rsbultje at gmail.com> wrote:
> Hi,
>
> On Sat, Oct 7, 2017 at 6:25 AM, Michael Niedermayer <michael at niedermayer.cc>
> wrote:
>
>> On Sat, Oct 07, 2017 at 12:12:15PM +0200, Michael Niedermayer wrote:
>> > > >>>>> On Fri, Oct 06, 2017 at 10:03:16AM -0400, Ronald S. Bultje
>> > > >>>>> wrote:
>> > > >>>>>> I'm open to any alternative method you suggest.
>>
>  [..]
>
>> > About a solution, I didnt write alot about solutions as iam really fine
>> > with any solution. There are many possible solutions ...
>> > The libavfilter/af_astats.c filter i mentioned outputs statistics
>> > via metadata
>>
> [..]
>
>> > There are other possibilities. Also Hendriks suggestion about
>> > turning metadata via some other application option into a file sounds
>> > pretty good to me
>>
>
> psnr/ssim/vmafmotion indeed use per-frame metadata, but that unfortunately
> doesn't address the use case of using ffmpeg to quickly dump some per-frame
> stats to a file (or stdout) for quick comparison/verification (e.g. compare
> against Netflix' vmaf code reference scores) since we don't print frame
> metadata anywhere.
>
> If someone does what Hendrik suggests (turning metadata into a file or into
> a log) then indeed there is no problem.

There is (a)metadata filter.

>
>
>> > or av_log as 2 alternatives to direct file write.
>>
>
> av_log would be simpler, yes.
>
> yet another solution (if people dislike all suggestions so far) would
>> be adding a flag to filters which are safe to use with untrusted
>> parameters. Or a flag to options which are unsafe so they are blocked
>> from being set from an untrusted input string
>>
>
> I actually considered this myself, but didn't want to propose it because I
> personally thought it was a little hacky... I'm not against it, though.
>
> Of these, I probably like the first one best (having some way of writing
> per-frame metadata generically to stdout or to a file, without explicit
> options), but it may also be the most complex one. Any takers to implement
> this?
>
> Ronald
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>