[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-kimageshop
Subject:    Re: "Recorder Docker" and Ffmpeg issues.
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2020-09-29 13:53:34
Message-ID: 5737376.lOV4Wx5bFT () selday
[Download RAW message or body]

I'm cc'ing the mailing list, because this really needs to be a public discussion, not \
something just between us :-)

On Monday, 28 September 2020 21:04:45 CEST you wrote:
> Hey Boud,
> 
> Eoin and I aren't sure how to proceed with the recorder docker so we need
> your advice.
> The author wrote the plugin to be used with ffmpeg's libav shared
> libraries, but:
> 
> *(a)* We can't easily automate building ffmpeg on Windows because it uses
> autotools.
> 
> *(b) *There seems to be some concern over format patents.
> 
> We can resolve (a) by downloading gpl-friendly binaries, but that doesn't
> change potential patent issues.
> We can resolve (b) by building from source, I think, with `--enable-libvpx`
> and `--enable-libopus`, but not on Windows because of autotools.

Hm... On irc, ben cooksley suggested we look at how OpenSUSE patches ffmpeg to come \
to a patent-unencumbered binary. That's probably a good idea, since they have a legal \
team that has looked into it.

> The only other option that I can think of is to revert, reopen the MR,
> and have the author (or Eoin or I or whoever) change their design to use an
> external standalone ffmpeg.

Hm again... I'm not sure about that. Of course, the recorder already stores all \
frames before writing them out, instead of writing them out in stream.

> (Like Krita currently does for the animation renderer.)

We could just leave things as is: have it built if ffmpeg is present, but not bundle \
libffmpeg ourselves.

> 
> We brought this up on IRC, but it was hard to get a real, definitive answer
> either way.
> It's probably not a huge deal, really. But I'm no patent lawyer, so we need
> some help coming up with a direction.
> 

-- 
https://www.krita.org


[prev in list] [next in list] [prev in thread] [next in thread]