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

[Nicolas George]

Le quintidi 15 vendémiaire, an CCXXVI, Ronald S. Bultje a écrit :
> 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.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20171007/5a3e3f3a/attachment.sig>