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
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
