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

List:       kde-kimageshop
Subject:    Re: "Recorder Docker" and Ffmpeg issues.
From:       Timothée_Giet <animtim () gmail ! com>
Date:       2020-09-29 17:34:50
Message-ID: 6acc4c90-8333-82c4-2631-b3bffbcc87a6 () gmail ! com
[Download RAW message or body]

Hi,

Since we already have that system to use an external ffmpeg for the
animation part, it would look logical to me to rely on the same for the
recorder feature. Having two different paths to use ffmpeg for two
different features looks not optimal.

Cheers,
Timoth=C3=A9e


Le 29/09/2020 =C3=A0 15:53, Boudewijn Rempt a =C3=A9crit=C2=A0:
> I'm cc'ing the mailing list, because this really needs to be a public d=
iscussion, 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 n=
eed
>> 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 u=
ses
>> autotools.
>>
>> *(b) *There seems to be some concern over format patents.
>>
>> We can resolve (a) by downloading gpl-friendly binaries, but that does=
n't
>> change potential patent issues.
>> We can resolve (b) by building from source, I think, with `--enable-li=
bvpx`
>> and `--enable-libopus`, but not on Windows because of autotools.
> Hm... On irc, ben cooksley suggested we look at how OpenSUSE patches ff=
mpeg 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 u=
se an
>> external standalone ffmpeg.
> Hm again... I'm not sure about that. Of course, the recorder already st=
ores all frames before writing them out, instead of writing them out in s=
tream.
>
>> (Like Krita currently does for the animation renderer.)
> We could just leave things as is: have it built if ffmpeg is present, b=
ut not bundle libffmpeg ourselves.
>
>> We brought this up on IRC, but it was hard to get a real, definitive a=
nswer
>> 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.
>>


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