On 10/7/17, Nicolas George <geo...@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 > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel