On 7/26/18, Thilo Borgmann <thilo.borgm...@mail.de> wrote: > Hi, > > Am 26.07.18 um 21:26 schrieb Rostislav Pehlivanov: >> As discussed recently, the vf_sr filter and the DNN framework have an >> issue: unreproducable weights and questionable license, as well as >> overall unfitting coding style to the rest of the project. >> >> The vf_sr filter in particular has weights embedded which weight the >> libavfilter binary by a bit and cannot currently be reproduced. >> There's an overall consensus that NN filters should accept external >> weights only, as the nnedi filter currently does. >> >> So, temporarily remove both until the coding style issues have been >> fixed with the framework and the filter has been modified to accept >> external weights. >> >> Also, there's a discussion by the Debian folks as to whether to treat >> pretrained NNs as non-free[0], hence its not just our project that's >> affected by the questionable license of distributing pretrained NN >> weights. > > I personally don't have a good feeling with pre-trained NNs in the codebase, > too. However, I do not care much about what solution we take, but Mina's > GSoC project also depends on the NN code that comes with this and therefore > I'd encourage everyone to make up their mind to find a suitable solution > sometime soonish. > > Maybe for the time-being, we might only accept such code reading in > externally provided NNs and/or the ability to train using FFmpeg itself. (Or > ask one of our kind users with compute power to generate some for us)
IIRC mentioned filter already supports external files. It just have internal one too. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
