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

Paul B Mahol onemda at gmail.com
Sat Oct 7 12:16:39 EEST 2017


On 10/7/17, Nicolas George <george at nsup.org> wrote:
> Le quintidi 15 vendemiaire, an CCXXVI, Ronald S. Bultje a ecrit :
>> The same mechanism is present in ssim/psnr filters.
>
> This is true. But how do you think it came to happen?
>
> It happened because somebody wanted some feature for their use and
> implemented it (so far, very good), and since it involved an unusual
> situation (a filter outputting non-audio-video data), they had to
> improvise and chose a quick-and-dirty solution.
>
> And it got in. It got in because the feature was useful. It got in
> because it was only one filter. It got in because maybe it was an
> internship thing. And most importantly, it got in because being the
> killjoy who always rejects quick-and-dirty solutions becomes tiring.
>
> Then somebody else implemented something with a slightly similar need,
> and they used the same quick-and-dirty solution. And since there was
> precedent, it got in even more easily.
>
> And that brings us now, we have many filters that interact with the
> outside using various quick-and-dirty solutions, with all the bad
> consequences for the project.
>
> Michael raises a concern about security, and he is right. Not because
> that feature is in itself a security concern, it is not, not really. But
> it is still communication with the outside: when building a sandbox to
> secure a service, you have to think about all communication channels,
> secure all of them. Maybe the sandboxing mechanism you use can secure
> most of them at the same time; key word: "maybe": you have to check.
> Every channel means more work, more potential attack surface.
>
> But the concerns are not all about security. By writing the information
> into a file, you make it unusable from within libavfilter, from within
> the same filter graph. Ideally, all statistics gathered by any filter
> could be used by another filter downgraph: boxblur on detected faces,
> strengthen postprocessing depending on PSNR, etc. We cannot do that at
> this time, but we want it. Unfortunately, if everybody always goes for
> the quick-and-dirty solution, we will never have it.

There is metadata for each frame added and it can be used right now.

>
> It is not unexpected that a beginner in the project would reuse a
> solution. But experienced and competent developers could be expected to
> have the big picture in mind, to stop and think ahead.
>
> Regards,
>
> --
>   Nicolas George
>


More information about the ffmpeg-devel mailing list