<div dir="ltr">
> *(b) *There seems to be some concern over format patents.<br>
> <br>
> We can resolve (a) by downloading gpl-friendly binaries, but that doesn't<br>
> change potential patent issues.<br>
> We can resolve (b) by building from source, I think, with `--enable-libvpx`<br><div>
> and `--enable-libopus`, but not on Windows because of autotools. <br></div><div><br></div><div>If we resolve the patent issues by stripping away problematic codecs, then we can build ffmpeg separately and store that on <a href="http://files.kde.org">files.kde.org</a>. And during the build process just download blobs and package.<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 30, 2020 at 11:22 PM Dmitry Kazakov <<a href="mailto:dimula73@gmail.com">dimula73@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>Hi, all!</div><div><br></div><div>From the research I did it seems like we can bundle the following codecs without any patent concerns:</div><div><br></div><div>1) VP8, VP9, AV1 --- owned by Google</div><div>2) GIF ---patents expired (?)</div><div>3) Theora</div><div>4) Cisco's implementation openh264 (<a href="https://www.openh264.org/" target="_blank">https://www.openh264.org/</a>). 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.<br></div><div><br></div><div>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.</div><div><br></div><div><br></div><div>PS:<br></div><div>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.<br></div><div></div><div></div><div><br></div><div>[1] - <a href="https://accessadvance.com/pdfnew/HEVC_Advance_Program_Overview.pdf" target="_blank">https://accessadvance.com/pdfnew/HEVC_Advance_Program_Overview.pdf</a></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 30, 2020 at 10:59 AM Boudewijn Rempt <<a href="mailto:boud@valdyas.org" target="_blank">boud@valdyas.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tuesday, 29 September 2020 19:34:50 CEST Timothée Giet wrote:<br>
> Hi,<br>
> <br>
> Since we already have that system to use an external ffmpeg for the<br>
> animation part, it would look logical to me to rely on the same for the<br>
> recorder feature. Having two different paths to use ffmpeg for two<br>
> different features looks not optimal.<br>
<br>
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.<br>
<br>
-- <br>
<a href="https://www.krita.org" rel="noreferrer" target="_blank">https://www.krita.org</a><br>
<br>
<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr">Dmitry Kazakov</div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature">Dmitry Kazakov</div>