mbox series

[FFmpeg-devel,0/2] Interpolation filter using nvidia OFFRUC Library

Message ID 20230102232133.729217-1-philipl@overt.org
Headers show
Series Interpolation filter using nvidia OFFRUC Library | expand

Message

Philip Langdale Jan. 2, 2023, 11:21 p.m. UTC
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

Comments

Dennis Mungai Jan. 2, 2023, 11:39 p.m. UTC | #1
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.
Dennis Mungai Jan. 3, 2023, 12:15 a.m. UTC | #2
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.