From kde-kimageshop Wed Sep 30 20:26:35 2020 From: Dmitry Kazakov Date: Wed, 30 Sep 2020 20:26:35 +0000 To: kde-kimageshop Subject: Re: "Recorder Docker" and Ffmpeg issues. Message-Id: X-MARC-Message: https://marc.info/?l=kde-kimageshop&m=160149761614288 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--000000000000e5c22005b08db767" --000000000000e5c22005b08db767 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > *(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 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 shi= p > it with Krita, and make a separate plugin for openh264. This way we'll ke= ep > 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 "=E2=80=9CCommercial=E2=80=9D product= s 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 wrote= : > >> On Tuesday, 29 September 2020 19:34:50 CEST Timoth=C3=A9e 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 th= e >> > 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 vide= o >> format and use that both for animations and recordings. >> >> -- >> https://www.krita.org >> >> >> > > -- > Dmitry Kazakov > --=20 Dmitry Kazakov --000000000000e5c22005b08db767 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> *(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.
<= /div>

If we resolve the patent issues by stripping away = problematic codecs, then we can build ffmpeg separately and store that on <= a href=3D"http://files.kde.org">files.kde.org. And during the build pro= cess just download blobs and package.


On Wed, Sep 3= 0, 2020 at 11:22 PM Dmitry Kazakov <dimula73@gmail.com> wrote:
Hi, all!

From the research I did it seems like we can bundle the following codecs w= ithout any patent concerns:

1) VP8, VP9, AV1 --- o= wned by Google
2) GIF ---patents expired (?)
3) Theora<= /div>
4) Cisco's implementation openh264 (https://www.openh264.org/). Though we ha= ve to use a binary blob distributed by Cisco and we cannot package it. It s= hould be installed on runtime when installing Krita on the user's syste= m 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 l= icensing information [1]. They have a weird claim that they don't licen= se "=E2=80=9CCommercial=E2=80=9D products primarily used to create or = distribute Commercial HEVC Content or provide cloud-based services". B= ut I don't know what it means and whether it is applicable to Krita.


On Wed, Sep 30, 2020 at 10:59 AM Boudewijn= Rempt <boud@valdy= as.org> wrote:
On Tuesday, 29 September 2020 19:34:50 CEST Timoth=C3=A9e 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 th= e
> 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 f= ormat and use that both for animations and recordings.

--
http= s://www.krita.org




--
Dmitry Kaz= akov


--
Dmitry Kazakov
--000000000000e5c22005b08db767--