On Sat, Dec 20, 2014 at 5:17 AM, Clément Bœsch <u...@pkh.me> wrote:
> On Fri, Dec 19, 2014 at 08:04:33PM +0100, Michael Niedermayer wrote: > > On Fri, Dec 19, 2014 at 07:26:52PM +0100, Clément Bœsch wrote: > > > On Fri, Dec 19, 2014 at 06:42:22PM +0100, Michael Niedermayer wrote: > > > > On Fri, Dec 19, 2014 at 04:55:32PM +0100, Clément Bœsch wrote: > > > > > On Fri, Dec 19, 2014 at 04:40:21PM +0100, Michael Niedermayer > wrote: > > > > > [...] > > > > > > then one filter that i remember was requested (longer ago) is > > > > > > nnedi3 but that would need to have its asm removed or ported > which > > > > > > is not trivial i suspect > > > > > > > > > > > > > > > > The problem with nnedi3 is that it requires 13MB of learned data. > > > > > > > > and fate is 900mb, still it seems we have no problem running it > > > > putting these 13MB on rsync would be rather easy > > > > > > > > > > If you want to distribute that binary data with the filter (that is if > you > > > want the filter to work out of the box), it will probably have to end > up > > > in the git; we are not requiring our users to make fate-rsync. > > > > > > Or do you want to add another layer of specific distribution just for > that > > > filter? > > > > i dont think this really differs much from something like drawtext > > the user needs some fonts installed for it to be able to draw text > > same here. > > Except most systems actually have many fonts available... > > > I dont even think we really need to automate it in principle but its > > more user friendly. But as theres no really clean way to do it > > maybe its best to just have the filter print a url from where to > > download the file if its not found and where to put it. > > distro packageers can then also decide if they want a seperate > > package for the file or not or not support the filter at all. > > I think it's just too bad to provide a filter that can't work out of the > box and depend on an external heavy resource. > > > > > I dont think we should just dump it into git and the tarballs > > it would very significantly increase their size > > I obviously agree with this. > > -- > Clément B. > > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > What further changes are required in fspp? _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
