Message ID | 20230102232133.729217-1-philipl@overt.org |
---|---|
Headers | show |
Series | Interpolation filter using nvidia OFFRUC Library | expand |
On Tue, 3 Jan 2023 at 02:22, Philip Langdale <philipl@overt.org> wrote: > This filter implements frame rate down/upsampling using nvidia's > Optical Flow FRUC (Frame Rate Up Conversion) library. It's neat because > you get realtime interpolation with a decent level of quality. It's > impractical because of licensing. > > I have no actual intention to merge this, as it doesn't even meet our > bar for a nonfree filter, and given the EULA restrictions with the SDK, > anyone who would want to use it can easily cherry-pick it into the > build they have to anyway. But I figured I'd send it to list as a way > of announcing that it exists. > > How nice would it be if nvidia had sane licensing on this stuff? > > I'll keep a branch at: https://github.com/philipl/FFmpeg/tree/fruc-me > > --phil > > Philip Langdale (2): > lavu/hwcontext_cuda: declare support for argb/abgr/rgba/bgra > avfilter/vf_nvoffruc: Add filter for nvidia's Optical Flow FRUC > library > > configure | 7 +- > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/vf_nvoffruc.c | 644 +++++++++++++++++++++++++++++++++++++ > libavutil/hwcontext_cuda.c | 4 + > 5 files changed, 654 insertions(+), 3 deletions(-) > create mode 100644 libavfilter/vf_nvoffruc.c > > -- > 2.37.2 Related, If this were to be implemented in mpv, can libplacebo pick up this feature spec as a filter in ffmpeg? Perhaps that would make such a feature easier to merge down the line, instead of re-implementing it directly in ffmpeg as an additional filter. Adding Niklaas to the thread.
On Tue, 3 Jan 2023 at 03:13, Philip Langdale <philipl@overt.org> wrote: > On Tue, 3 Jan 2023 02:39:19 +0300 > Dennis Mungai <dmngaie@gmail.com> wrote: > > > Related, > > > > If this were to be implemented in mpv, can libplacebo pick up this > > feature spec as a filter in ffmpeg? Perhaps that would make such a > > feature easier to merge down the line, instead of re-implementing it > > directly in ffmpeg as an additional filter. > > > > Adding Niklaas to the thread. > > It doesn't make a difference. The licensing is fundamentally unusable > for an open-source project (and there are engineers at nvidia who know > this and wish they could write filters leveraging all their various > capabilities). The only thing with any nuance is what level of > `nonfree` a project is willing to have sitting in their repo. Most > projects (including mpv and libplacebo) would say "none", because it's > not worth the trouble. ffmpeg has gone back and forth on what exact > critera have to be met to qualify as mergeable vs unmergeable nonfree. > In the past we have accepted filters based around nvidia libraries with > prohibitive licensing - see the libnpp based filters, but I don't think > we have the appetite for that now. If we were to decide that this > filter was ok on that basis, I'd merge it, but honestly, the usability > benefit of it being in master is tiny vs all the other hoops you have > to jump through. > > Anyway - punchline: it is not easier to get this kind of thing merged > into other projects. > > --phil > Got it, thanks for the clarifications.