"Recorder Docker" and Ffmpeg issues.

[Dmitry Kazakov]

 > *(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.

If we resolve the patent issues by stripping away problematic codecs, then
we can build ffmpeg separately and store that on files.kde.org. And during
the build process just download blobs and package.


On Wed, Sep 30, 2020 at 11:22 PM Dmitry Kazakov <dimula73 at gmail.com> wrote:

> Hi, all!
>
> From the research I did it seems like we can bundle the following codecs
> without any patent concerns:
>
> 1) VP8, VP9, AV1 --- owned by Google
> 2) GIF ---patents expired (?)
> 3) Theora
> 4) Cisco's implementation openh264 (https://www.openh264.org/). Though we
> have to use a binary blob distributed by Cisco and we cannot package it. It
> should be installed on runtime when installing Krita on the user's system
> and it should be possible to enable/disable it (according to the license).
> That is how Firefox uses h264.
>
> Basically, we can build our own ffmpeg for the first three codecs and ship
> it with Krita, and make a separate plugin for openh264. This way we'll keep
> most of the current code. We'll need only a special case for h264.
>
>
> PS:
> About HEVC. There seems to be an organization that gives licenses for
> HEVC. But they have rather weird licensing information [1]. They have a
> weird claim that they don't license "“Commercial” products primarily used
> to create or distribute Commercial HEVC Content or provide cloud-based
> services". But I don't know what it means and whether it is applicable to
> Krita.
>
> [1] - https://accessadvance.com/pdfnew/HEVC_Advance_Program_Overview.pdf
>
>
>
> On Wed, Sep 30, 2020 at 10:59 AM Boudewijn Rempt <boud at valdyas.org> wrote:
>
>> On Tuesday, 29 September 2020 19:34:50 CEST Timothée Giet wrote:
>> > 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.
>>
>> Yes... But ideally we wouldn't use an external ffmpeg for anything. We
>> need a library that allows us to easily write frames and audio to a video
>> format and use that both for animations and recordings.
>>
>> --
>> https://www.krita.org
>>
>>
>>
>
> --
> Dmitry Kazakov
>


-- 
Dmitry Kazakov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20200930/30762192/attachment.htm>