3:12 a.m.
Hi,
there are several packages in the distribution which require FFMPEG
(libavformat, libavcodec, etc.), one of them being chromium. The package could
be created in a way that you can easily replace it with a version from
rpmfusion to get to the full encoder/decoder set including H264 etc.
This is working fine with openSUSE and packages from Packman.
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
The Packman version always has a higher release version than the one in the
distribution.
I'm interested in this, as I try to package electron for Fedora. The big
problem is the included ffmpeg. With openSUSE I can just use the system
ffmpeg, with Fedora I have to do some source code voodoo which I really would
like to avoid.
Thanks for considering!
Best regards
Andreas
3:55 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
Hi,
there are several packages in the distribution which require FFMPEG
(libavformat, libavcodec, etc.), one of them being chromium. The package could
be created in a way that you can easily replace it with a version from
rpmfusion to get to the full encoder/decoder set including H264 etc.
This is working fine with openSUSE and packages from Packman.
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
The Packman version always has a higher release version than the one in the
distribution.
I'm interested in this, as I try to package electron for Fedora. The big
problem is the included ffmpeg. With openSUSE I can just use the system
ffmpeg, with Fedora I have to do some source code voodoo which I really would
like to avoid.
Maintaining such package would require keeping watch for any new files
you'd need to include and going through legal review each time you do.
IMO it's much less work to just maintain everything that depends on
FFmpeg in RPM Fusion.
If you're determined, however, you could start with what Chromium does:
https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
Feel free to flag me for package review. I one of the maintainers
of the ffmpeg package in RPM Fusion.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
4:51 a.m.
On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski
wrote:
On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
> Hi,
>
> there are several packages in the distribution which require FFMPEG
> (libavformat, libavcodec, etc.), one of them being chromium. The package
> could
be created in a way that you can easily replace it with a version
> from rpmfusion to get to the full encoder/decoder set including
H264 etc.
>
> This is working fine with openSUSE and packages from Packman.
>
> https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
> https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
>
> The Packman version always has a higher release version than the one in
> the
distribution.
>
> I'm interested in this, as I try to package electron for Fedora. The big
> problem is the included ffmpeg. With openSUSE I can just use the system
> ffmpeg, with Fedora I have to do some source code voodoo which I really
> would
like to avoid.
Maintaining such package would require keeping watch for any new files
you'd need to include and going through legal review each time you do.
Did you take a look how they solved it at SUSE?
You have list for encoder and decoders which are allowed to be built. So if a
new encoder or decoder would be added, it would just not be built. You will
just always end up with the same set of encoders/decoders with every update.
Packman uses the exact same package as openSUSE and all it does it to enable
all encoders and decoders.
All packages requiring ffmpeg can just always be built against the system
version.
It should be less legal work, as you have to check just one package and not
several which might include it as third_party source code.
IMO it's much less work to just maintain everything that depends
on
FFmpeg in RPM Fusion.
If you're determined, however, you could start with what Chromium does:
https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
How is it less work if you need to clean ffmpeg source codes in several
projects which include it instead of just linking the system one? It is more
prone to errors to remove sources and you have to track it instead of just
having a fixed decoder/encoder set you build.
Feel free to flag me for package review. I
Best regards
Andreas
5:01 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On Mon, Nov 8, 2021 at 11:51 AM Andreas Schneider <asn(a)redhat.com> wrote:
On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski
wrote:
> On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
>
> > Hi,
> >
> > there are several packages in the distribution which require FFMPEG
> > (libavformat, libavcodec, etc.), one of them being chromium. The package
> > could
be created in a way that you can easily replace it with a version
> > from rpmfusion to get to the full encoder/decoder set including H264 etc.
> >
> > This is working fine with openSUSE and packages from Packman.
> >
> > https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
> > https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
> >
> > The Packman version always has a higher release version than the one in
> > the
distribution.
> >
> > I'm interested in this, as I try to package electron for Fedora. The big
> > problem is the included ffmpeg. With openSUSE I can just use the system
> > ffmpeg, with Fedora I have to do some source code voodoo which I really
> > would
like to avoid.
>
>
> Maintaining such package would require keeping watch for any new files
> you'd need to include and going through legal review each time you do.
Did you take a look how they solved it at SUSE?
You have list for encoder and decoders which are allowed to be built. So if a
new encoder or decoder would be added, it would just not be built. You will
just always end up with the same set of encoders/decoders with every update.
Packman uses the exact same package as openSUSE and all it does it to enable
all encoders and decoders.
All packages requiring ffmpeg can just always be built against the system
version.
It should be less legal work, as you have to check just one package and not
several which might include it as third_party source code.
> IMO it's much less work to just maintain everything that depends on
> FFmpeg in RPM Fusion.
>
> If you're determined, however, you could start with what Chromium does:
> https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
How is it less work if you need to clean ffmpeg source codes in several
projects which include it instead of just linking the system one? It is more
prone to errors to remove sources and you have to track it instead of just
having a fixed decoder/encoder set you build.
It's not the point that it's easier.
If I understand correctly, any official ffmpeg package distributed by
Fedora would not be allowed to contain even the *source code* for
patent-encumbered or redistribution-limited codecs in its source
package (because those sources are redistributed too). So the only way
to achieve that would be to use "clean" tarballs - and a hardcoded
list of "allowed codecs to build" alone is not enough to satisfy that
requirement.
Fabio
6:27 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On Monday, 08 November 2021 at 12:01, Fabio Valentini wrote:
On Mon, Nov 8, 2021 at 11:51 AM Andreas Schneider
<asn(a)redhat.com> wrote:
>
> On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski
> wrote:
> > On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
> >
> > > Hi,
> > >
> > > there are several packages in the distribution which require FFMPEG
> > > (libavformat, libavcodec, etc.), one of them being chromium. The package
> > > could
> be created in a way that you can easily replace it with a version
> > > from rpmfusion to get to the full encoder/decoder set including H264 etc.
> > >
> > > This is working fine with openSUSE and packages from Packman.
> > >
> > > https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
> > > https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
> > >
> > > The Packman version always has a higher release version than the one in
> > > the
> distribution.
> > >
> > > I'm interested in this, as I try to package electron for Fedora. The
big
> > > problem is the included ffmpeg. With openSUSE I can just use the system
> > > ffmpeg, with Fedora I have to do some source code voodoo which I really
> > > would
> like to avoid.
> >
> >
> > Maintaining such package would require keeping watch for any new files
> > you'd need to include and going through legal review each time you do.
>
> Did you take a look how they solved it at SUSE?
>
> You have list for encoder and decoders which are allowed to be built. So if a
> new encoder or decoder would be added, it would just not be built. You will
> just always end up with the same set of encoders/decoders with every update.
>
> Packman uses the exact same package as openSUSE and all it does it to enable
> all encoders and decoders.
>
> All packages requiring ffmpeg can just always be built against the system
> version.
>
> It should be less legal work, as you have to check just one package and not
> several which might include it as third_party source code.
>
> > IMO it's much less work to just maintain everything that depends on
> > FFmpeg in RPM Fusion.
> >
> > If you're determined, however, you could start with what Chromium does:
> > https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
>
> How is it less work if you need to clean ffmpeg source codes in several
> projects which include it instead of just linking the system one? It is more
> prone to errors to remove sources and you have to track it instead of just
> having a fixed decoder/encoder set you build.
It's not the point that it's easier.
If I understand correctly, any official ffmpeg package distributed by
Fedora would not be allowed to contain even the *source code* for
patent-encumbered or redistribution-limited codecs in its source
package (because those sources are redistributed too). So the only way
to achieve that would be to use "clean" tarballs - and a hardcoded
list of "allowed codecs to build" alone is not enough to satisfy that
requirement.
That's what I meant although I haven't said so explicitly. The chromium
script does what you've described.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
6:37 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On Monday, 08 November 2021 at 11:51, Andreas Schneider wrote:
On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann'
Mierzejewski
wrote:
> On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
>
> > Hi,
> >
> > there are several packages in the distribution which require FFMPEG
> > (libavformat, libavcodec, etc.), one of them being chromium. The package
> > could
be created in a way that you can easily replace it with a version
> > from rpmfusion to get to the full encoder/decoder set including H264 etc.
> >
> > This is working fine with openSUSE and packages from Packman.
> >
> > https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
> > https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
> >
> > The Packman version always has a higher release version than the one in
> > the
distribution.
> >
> > I'm interested in this, as I try to package electron for Fedora. The big
> > problem is the included ffmpeg. With openSUSE I can just use the system
> > ffmpeg, with Fedora I have to do some source code voodoo which I really
> > would
like to avoid.
>
>
> Maintaining such package would require keeping watch for any new files
> you'd need to include and going through legal review each time you do.
Did you take a look how they solved it at SUSE?
Actually, yes. We cannot do the same as we cannot distribute the full
upstream source.
You have list for encoder and decoders which are allowed to be built.
So if a
new encoder or decoder would be added, it would just not be built. You will
just always end up with the same set of encoders/decoders with every update.
Sometimes new dependencies get added to existing decoders/encoders which
would require legal review.
Packman uses the exact same package as openSUSE and all it does it to
enable
all encoders and decoders.
All packages requiring ffmpeg can just always be built against the system
version.
It should be less legal work, as you have to check just one package and not
several which might include it as third_party source code.
Chromium was checked by legal. I'm not aware of any other Fedora
packages bundling a subset of FFmpeg.
> IMO it's much less work to just maintain everything that
depends on
> FFmpeg in RPM Fusion.
>
> If you're determined, however, you could start with what Chromium does:
> https://src.fedoraproject.org/rpms/chromium/blob/rawhide/f/clean_ffmpeg.sh
How is it less work if you need to clean ffmpeg source codes in several
projects which include it instead of just linking the system one? It is more
prone to errors to remove sources and you have to track it instead of just
having a fixed decoder/encoder set you build.
I agree it would be better to have one system package that others would
link against but as with everything, it's not always possible. You're
welcome to try.
Regards,
Dominik
--
Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
7:55 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 11/8/21 13:37, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 08 November 2021 at 11:51, Andreas Schneider wrote:
> On Monday, November 8, 2021 10:55:32 AM CET Dominik 'Rathann' Mierzejewski
> wrote:
>> On Monday, 08 November 2021 at 10:12, Andreas Schneider wrote:
>>
>>> Hi,
>>>
>>> there are several packages in the distribution which require FFMPEG
>>> (libavformat, libavcodec, etc.), one of them being chromium. The package
>>> could
> be created in a way that you can easily replace it with a version
>>> from rpmfusion to get to the full encoder/decoder set including H264 etc.
>>>
>>> This is working fine with openSUSE and packages from Packman.
>>>
>>> https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
>>> https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
>>>
>>> The Packman version always has a higher release version than the one in
>>> the
> distribution.
>>>
>>> I'm interested in this, as I try to package electron for Fedora. The big
>>> problem is the included ffmpeg. With openSUSE I can just use the system
>>> ffmpeg, with Fedora I have to do some source code voodoo which I really
>>> would
> like to avoid.
>>
>>
>> Maintaining such package would require keeping watch for any new files
>> you'd need to include and going through legal review each time you do.
>
> Did you take a look how they solved it at SUSE?
Actually, yes. We cannot do the same as we cannot distribute the full
upstream source.
> You have list for encoder and decoders which are allowed to be built. So if a
> new encoder or decoder would be added, it would just not be built. You will
> just always end up with the same set of encoders/decoders with every update.
Sometimes new dependencies get added to existing decoders/encoders which
would require legal review.
> Packman uses the exact same package as openSUSE and all it does it to enable
> all encoders and decoders.
>
> All packages requiring ffmpeg can just always be built against the system
> version.
>
> It should be less legal work, as you have to check just one package and not
> several which might include it as third_party source code.
Chromium was checked by legal. I'm not aware of any other Fedora
packages bundling a subset of FFmpeg.
Firefox ships bundled ffmpeg with VP8/9 and maybe some other codecs.
--
Martin Stransky
Software Engineer / Red Hat, Inc
8:15 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 08/11/2021 10:12, Andreas Schneider wrote:
I'm interested in this, as I try to package electron for Fedora.
Electron can't be build completely from sources without downloading
pre-built binaries/blobs from npm.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:25 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On Mon, Nov 8, 2021 at 9:16 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 08/11/2021 10:12, Andreas Schneider wrote:
> I'm interested in this, as I try to package electron for Fedora.
Electron can't be build completely from sources without downloading
pre-built binaries/blobs from npm.
This is not true anymore.
--
真実はいつも一つ！/ Always, there's only one truth!
8:33 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 08/11/2021 15:25, Neal Gompa wrote:
This is not true anymore.
Have you tested the build without network access? Because even Flatpaks
download everything from npm.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:35 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On Mon, Nov 8, 2021 at 9:34 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 08/11/2021 15:25, Neal Gompa wrote:
> This is not true anymore.
Have you tested the build without network access? Because even Flatpaks
download everything from npm.
I've done an offline build with some prep work upfront, yes. It's not
automatically a thing, but it is possible.
--
真実はいつも一つ！/ Always, there's only one truth!
8:43 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 08/11/2021 15:35, Neal Gompa wrote:
I've done an offline build with some prep work upfront, yes.
Fully offline with rebuilding all JS dependencies from sources?
All minified JS blobs must be rebuild from sources on Fedora infra
instead of downloading them from npm with direct links.
It's not automatically a thing, but it is possible.
Can you show the SPEC please?
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
8:45 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On Mon, Nov 8, 2021 at 9:44 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
On 08/11/2021 15:35, Neal Gompa wrote:
> I've done an offline build with some prep work upfront, yes.
Fully offline with rebuilding all JS dependencies from sources?
All minified JS blobs must be rebuild from sources on Fedora infra
instead of downloading them from npm with direct links.
> It's not automatically a thing, but it is possible.
Can you show the SPEC please?
I haven't done it in the form of a spec file recently. It hasn't been worth my
time to do that yet with other blockers. I don't have anything I can
share at this time.
--
真実はいつも一つ！/ Always, there's only one truth!
9:47 a.m.
On Monday, November 8, 2021 3:43:37 PM CET Vitaly Zaitsev via devel wrote:
On 08/11/2021 15:35, Neal Gompa wrote:
> I've done an offline build with some prep work upfront, yes.
Fully offline with rebuilding all JS dependencies from sources?
All minified JS blobs must be rebuild from sources on Fedora infra
instead of downloading them from npm with direct links.
> It's not automatically a thing, but it is possible.
Can you show the SPEC please?
I have electron building offline for Fedora, you can find it here:
https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
11:04 a.m.
Andreas Schneider wrote:
I have electron building offline for Fedora, you can find it here:
https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
I see from the presence of electron-13-openh264-format-security.patch that
you are building the bundled OpenH264. This is not going to be allowed on
Fedora: only the openh264 repository provided by Cisco is allowed to
distribute OpenH264 for Fedora due to how the H.264 patent license works.
And as I understand it, you cannot even build against a system OpenH264
(because that repository is not enabled in the build system). The only
packages that support OpenH264 within Fedora are those that can dlopen it at
runtime, which Chromium cannot.
The build of openh264 is also controlled by enable_proprietary_codecs, which
you unconditionally set to true. So your approach is not going to work on
Fedora. In fact, you are not even supposed to include openh264 in the
tarball at all. At least in qt5-qtwebengine, I added an rm -rf line to the
tarball cleanup script that removes it (some time ago, back when upstream
had added the bundled copy), I have not checked whether the chromium package
does that too, but in any case, it should.
This is also another reason why just swapping out ffmpeg will not give you
fully working support for patent-encumbered codecs, whereas the qt5-
qtwebengine-freeworld approach (just rebuilding the whole thing) will. (qt5-
qtwebengine-freeworld in RPM Fusion does include the bundled OpenH264, as
there is nothing preventing shipping non-Cisco builds there, the copyright
license is perfectly fine, it is the patent license that only applies to
builds shipped by Cisco.) FFmpeg does not include a H.264 encoder at all. It
has support for using an external libx264, but Chromium does not support
using that libx264 support, nor using libx264 directly. Instead, Chromium
relies on OpenH264 for encoding (probably because that ensures that the
bitstream will only use features that are also supported by the OpenH264
decoder used by some other browsers, even though Chromium does not use the
decoder from OpenH264, only the encoder). Hence, Chromium uses OpenH264
directly (for encoding), which is a compile-time decision based on
enable_proprietary_codecs and not affected by replacing FFmpeg at all.
Kevin Kofler
12:56 a.m.
On Monday, November 8, 2021 6:04:12 PM CET Kevin Kofler via devel wrote:
Andreas Schneider wrote:
> I have electron building offline for Fedora, you can find it here:
>
> https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
I see from the presence of electron-13-openh264-format-security.patch that
you are building the bundled OpenH264.
Oh, good catch. I've removed it from the source tarball and disabled it.
3:28 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 08/11/2021 16:47, Andreas Schneider wrote:
I have electron building offline for Fedora, you can find it here:
https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
Electron core packaging is a quite trivial task (Arch Linux and Debian
have already done this), but what about Electron applications (VS Code
for example)?
Most of them download tons of bundled JS blobs from npm during the
build. I don't think it will be easy (or even possible) to build
everything from sources.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
9:06 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org> writes:
On 08/11/2021 16:47, Andreas Schneider wrote:
> I have electron building offline for Fedora, you can find it here:
> https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
Electron core packaging is a quite trivial task (Arch Linux and Debian
have already done this), but what about Electron applications (VS Code
for example)?
They have? What's it called? Asking because I don't see it:
rharwood@eesha:~$ aptitude search electron | grep -v electronics
p node-electron-to-chromium - Provides a list of electron-to-chromium version
mappings
rharwood@eesha:~$
Be well,
--Robbie
5:10 p.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
Nov 9, 2021 9:06:58 AM Robbie Harwood <rharwood(a)redhat.com>:
Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org>
writes:
> On 08/11/2021 16:47, Andreas Schneider wrote:
>> I have electron building offline for Fedora, you can find it here:
>> https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
>
> Electron core packaging is a quite trivial task (Arch Linux and Debian
> have already done this), but what about Electron applications (VS Code
> for example)?
They have? What's it called? Asking because I don't see it:
rharwood@eesha:~$ aptitude search electron | grep -v electronics
p node-electron-to-chromium - Provides a list of electron-to-chromium version
mappings
rharwood@eesha:~$
Be well,
--Robbie
Hi Robbie,
It looks like you're right. According to pkgs.org[1], Electron is only packaged in
Archlinux, Tumbleweed, and a couple more obscure distros (or at least obscure to me 😀).
Thanks,
Maxwell
[1]: https://pkgs.org/search/?q=electron
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8
gotmax(a)e.email
2:01 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 09/11/2021 16:06, Robbie Harwood wrote:
They have? What's it called? Asking because I don't see it:
Sorry, my mistake. Only Arch Linux[1] and openSUSE[2].
[1]: https://archlinux.org/packages/community/x86_64/electron/
[2]: https://software.opensuse.org/package/nodejs-electron
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1:01 a.m.
On Tuesday, November 9, 2021 10:28:12 AM CET Vitaly Zaitsev via devel wrote:
On 08/11/2021 16:47, Andreas Schneider wrote:
> I have electron building offline for Fedora, you can find it here:
> https://build.opensuse.org/package/show/network:im:signal/nodejs-electron
Electron core packaging is a quite trivial task (Arch Linux and Debian
have already done this), but what about Electron applications (VS Code
for example)?
As I've done the packaging, I strongly disagree!
Most of them download tons of bundled JS blobs from npm during the
build. I don't think it will be easy (or even possible) to build
everything from sources.
Can you point me to those tons of bundled JS blobs in the source tarball from
the above link please? I don't see them.
Thanks for your help!
Andreas
1:55 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 10/11/2021 08:01, Andreas Schneider wrote:
Can you point me to those tons of bundled JS blobs in the source
tarball from
the above link please? I don't see them.
https://github.com/microsoft/vscode/blob/main/yarn.lock - 11K lines of
external dependencies.
All of them must be compiled from source on Fedora's infra.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
2:44 a.m.
On Wednesday, November 10, 2021 8:55:53 AM CET Vitaly Zaitsev via devel wrote:
On 10/11/2021 08:01, Andreas Schneider wrote:
> Can you point me to those tons of bundled JS blobs in the source tarball
> from
the above link please? I don't see them.
https://github.com/microsoft/vscode/blob/main/yarn.lock - 11K lines of
external dependencies.
I'm sorry, but didn't we talk about electron and you're pointing to vscode?
4:27 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 10/11/2021 09:44, Andreas Schneider wrote:
I'm sorry, but didn't we talk about electron and you're
pointing to vscode?
My previous message was:
Electron core packaging is a quite trivial task (Arch Linux and
Debian have already done this), but what about Electron applications
(VS Code for example)?
By the way, which Electron app do you want to package?
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
9:33 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
Le 10/11/2021 à 11:27, Vitaly Zaitsev via devel a écrit :
On 10/11/2021 09:44, Andreas Schneider wrote:
> Electron core packaging is a quite trivial task (Arch Linux and
> Debian have already done this), but what about Electron applications
> (VS Code for example)?
By the way, which Electron app do you want to package?
Just wanted to add that if
Electron is packaged for Fedora, packaging
the rest of the electron apps would not necessarily happen in the
official repos (due to the enormous work needed). I could very well
imagine a properly maintained Electron in the repos, including the
patches for Wayland & Pipewire, and then some packagers/users building
everything in COPR disregarding some of the Guidelines in instances
where it is too hard to apply them. I could even imagine someone
creating a repo (not in COPR hopefully, due to legal issues) replacing
in proprietary apps like Discord (or Slack which happens to be relevant
to other discussions here) the bundled electron with Fedora's making
things like Desktop sharing (not sure if it requires more changes) and
Wayland working natively, packaged in a convenient RPM, a bit like what
is currently available in the AUR.
10:34 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
Hi Lyes,
Nov 10, 2021 9:34:17 AM Lyes Saadi <fedora(a)lyes.eu>:
Le 10/11/2021 à 11:27, Vitaly Zaitsev via devel a écrit :
> On 10/11/2021 09:44, Andreas Schneider wrote:
>> Electron core packaging is a quite trivial task (Arch Linux and
>> Debian have already done this), but what about Electron applications
>> (VS Code for example)?
> By the way, which Electron app do you want to package?
Just wanted to add that if Electron is packaged for Fedora, packaging the rest of the
electron apps would not necessarily happen in the official repos (due to the enormous work
needed). I could very well imagine a properly maintained Electron in the repos, including
the patches for Wayland & Pipewire, and then some packagers/users building everything
in COPR disregarding some of the Guidelines in instances where it is too hard to apply
them. I could even imagine someone creating a repo (not in COPR hopefully, due to legal
issues) replacing in proprietary apps like Discord (or Slack which happens to be relevant
to other discussions here) the bundled electron with Fedora's making things like
Desktop sharing (not sure if it requires more changes) and Wayland working natively,
packaged in a convenient RPM, a bit like what is currently available in the AUR.
That sounds like an intriguing proposal. Perhaps this would be appropriate for RPM
Fusion?
Thanks,
Maxwell
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8
gotmax(a)e.email
10:48 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 10/11/2021 17:34, Maxwell G (@gotmax23) via devel wrote:
Perhaps this would be appropriate for RPM Fusion?
RPM Fusion doesn't allow network access during the build either.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
10:47 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 10/11/2021 16:33, Lyes Saadi wrote:
I could even imagine someone creating a repo (not in COPR hopefully,
due
to legal issues) replacing in proprietary apps like Discord (or Slack
which happens to be relevant to other discussions here) the bundled
electron with Fedora's making things like Desktop sharing (not sure if
it requires more changes) and Wayland working natively, packaged in a
convenient RPM, a bit like what is currently available in the AUR.
Proprietary apps don't allow patching of their code. Recently discussed
in #flatpak:matrix.org.
I could very well imagine a properly maintained Electron in the
repos, including the patches for Wayland & Pipewire, and then some packagers/users
building everything in COPR disregarding some of the Guidelines in instances where it is
too hard to apply them.
Yes, COPR packages can use npm/etc. to download all the required
dependencies.
Just wanted to add that if Electron is packaged for Fedora, packaging
the rest of the electron apps would not necessarily happen in the official repos (due to
the enormous work needed).
We will have another problem - different Electron apps require different
major versions of Electron engine.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
11 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
Nov 10, 2021 10:47:59 AM Vitaly Zaitsev via devel <devel(a)lists.fedoraproject.org>:
On 10/11/2021 16:33, Lyes Saadi wrote:
[snip]
> Just wanted to add that if Electron is packaged for Fedora,
packaging the rest of the electron apps would not necessarily happen in the official repos
(due to the enormous work needed).
We will have another problem - different Electron apps require different major versions
of Electron engine.
This would obviously be more effort, but Arch resolves this issue by packaging multiple
versions of Electron [1].
Thanks,
Maxwell
[1]: https://archlinux.org/packages/?q=electron
--
Maxwell G (@gotmax23)
Pronouns: He/Him/His
PGP Key Fingerprint: f57c76e5a238fe0a628e2ecef79e4e25e8c661f8
gotmax(a)e.email
11:04 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
Le 10/11/2021 à 17:47, Vitaly Zaitsev via devel a écrit :
On 10/11/2021 16:33, Lyes Saadi wrote:
> I could even imagine someone creating a repo (not in COPR hopefully,
> due to legal issues) replacing in proprietary apps like Discord (or
> Slack which happens to be relevant to other discussions here) the
> bundled electron with Fedora's making things like Desktop sharing
> (not sure if it requires more changes) and Wayland working natively,
> packaged in a convenient RPM, a bit like what is currently available
> in the AUR.
Proprietary apps don't allow patching of their code. Recently
discussed in #flatpak:matrix.org.
That's why I said « not in COPR hopefully » ^_^. Client modification is
prohibited by Discord, but it is not really acting on that unless it
harms them (the AUR repo is an example of that). I wonder what is
Slack's TOS? Maybe with their approval, a COPR could be maintained
without any issue?
(Also, I just want to insist I am not pushing nor advising anyone to do
something breaking Discord's TOS without their approval, I'm just
thinking of examples of external demand for a Discord package in Fedora.)
> Just wanted to add that if Electron is packaged for Fedora,
packaging
> the rest of the electron apps would not necessarily happen in the
> official repos (due to the enormous work needed).
We will have another problem - different Electron apps require
different major versions of Electron engine.
That is true. Though, compat-packages
could be an option for the main
repository anyway.
12:26 p.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
Hi
On Wed, Nov 10, 2021 at 12:05 PM Lyes Saadi wrote:
(Also, I just want to insist I am not pushing nor advising anyone to do
something breaking Discord's TOS without their approval, I'm just
thinking of examples of external demand for a Discord package in Fedora.)
https://fedoraproject.org/wiki/Changes/Filtered_Flathub_Applications is
intended to address that
Rahul
2:30 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 10/11/2021 18:04, Lyes Saadi wrote:
I wonder what is Slack's TOS? Maybe with their approval, a COPR
could be
maintained without any issue?
COPR can't be used for building non-free software:
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-buil...
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:26 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
> I wonder what is Slack's TOS? Maybe with their approval, a
COPR could
> be maintained without any issue?
COPR can't be used for building non-free software:
https://docs.pagure.org/copr.copr/user_documentation.html#what-i-can-buil...
Indeed, forgot about that when writing my e-mail ^^'!
I guess someone volunteering to properly package it in RPM Fusion could
do it (if they got Slack's approval), since Slack seems to be no longer
willing to ship it themselves.
4:22 p.m.
Vitaly Zaitsev via devel wrote:
On 10/11/2021 16:33, Lyes Saadi wrote:
> I could even imagine someone creating a repo (not in COPR hopefully, due
> to legal issues) replacing in proprietary apps like Discord (or Slack
> which happens to be relevant to other discussions here) the bundled
> electron with Fedora's making things like Desktop sharing (not sure if
> it requires more changes) and Wayland working natively, packaged in a
> convenient RPM, a bit like what is currently available in the AUR.
Proprietary apps don't allow patching of their code. Recently discussed
in #flatpak:matrix.org.
You would not actually be patching the proprietary code, but the bundled
Electron. Considering that essential parts of libchromiumcontent (the Blink
code derived from WebKit, itself derived from KHTML) are under the LGPL, the
proprietary applications are actually *required* to allow you to replace the
LGPL library with a modified and/or updated version. If they attempt to sue
you for it, *they* are violating the LGPL license of WebKit. (You will
probably also be able to find some KDE developers whose LGPLed KHTML code
ended up in Blink and who may be more willing to cooperate with you in the
case of a lawsuit than Google or Apple.)
Kevin Kofler
4:08 a.m.
On Wednesday, November 10, 2021 11:27:32 AM CET Vitaly Zaitsev via devel
wrote:
On 10/11/2021 09:44, Andreas Schneider wrote:
> I'm sorry, but didn't we talk about electron and you're pointing to
> vscode?
My previous message was:
> Electron core packaging is a quite trivial task (Arch Linux and
> Debian have already done this), but what about Electron applications
> (VS Code for example)?
By the way, which Electron app do you want to package?
I'm packaging Signal-Desktop completely built from source.
https://build.opensuse.org/package/show/network:im:signal/
4:28 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 11/11/2021 11:08, Andreas Schneider wrote:
I'm packaging Signal-Desktop completely built from source.
https://build.opensuse.org/package/view_file/network:im:signal/signal-des...
Does this script simply download assets from npm using the "yarn
install" command?
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
9:31 a.m.
On Thursday, November 11, 2021 11:28:42 AM CET Vitaly Zaitsev via devel wrote:
On 11/11/2021 11:08, Andreas Schneider wrote:
> I'm packaging Signal-Desktop completely built from source.
https://build.opensuse.org/package/view_file/network:im:signal/signal-deskto
p/prepare_vendor.sh?expand=1
Does this script simply download assets from npm using the "yarn
install" command?
Does it look like it only calls 'yarn install' and does nothing else?
Maybe look through the "echo" commands to see what it does. Are you looking
for the `echo ">>>>>> Cleanup object files"` section?
4:29 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On Thu, 2021-11-11 at 11:08 +0100, Andreas Schneider wrote:
On Wednesday, November 10, 2021 11:27:32 AM CET Vitaly Zaitsev via
devel
wrote:
> On 10/11/2021 09:44, Andreas Schneider wrote:
>
> > I'm sorry, but didn't we talk about electron and you're pointing
> > to
> > vscode?
>
> My previous message was:
>
>
> > Electron core packaging is a quite trivial task (Arch Linux and
> > Debian have already done this), but what about Electron
> > applications
> > (VS Code for example)?
>
> By the way, which Electron app do you want to package?
I'm packaging Signal-Desktop completely built from source.
https://build.opensuse.org/package/show/network:im:signal/
https://build.opensuse.org/project/show/network:im:signal
https://build.opensuse.org/package/view_file/network:im:signal/signal-des...
--
Sérgio M. B.
3:07 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
All of them must be compiled from source on Fedora's infra.
No, they don't.
https://fedoraproject.org/wiki/Changes/NodejsLibrariesBundleByDefault#Det...
Have you tested the build without network access? Because even
Flatpaks download everything from npm.
"Flatpaks" using flatpak-node-generator for downloading modules but doesn't
requires network access during build. Builds also reproducible.
4:34 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 10/11/2021 10:07, Artem Tim wrote:
Yes, bundling is allowed only for sources. You can package all
dependencies in source form into a single vendored tarball.
"Flatpaks" using flatpak-node-generator for downloading
modules but doesn't requires network access during build.
Flathub != Fedora. All Fedora packages must be built from sources
(except firmware).
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:54 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
Yes, bundling is allowed only for sources. You can package all
dependencies in source form into a single vendored tarball.
OP never talked about bundling blobs, only you. Also OP never talked about vscode.
Flathub != Fedora. All Fedora packages must be built from sources
(except firmware).
Indeed, and they are built from sources on Flathub and that exactly the point. We can do
the same for Fedora.
Keep mislead people and twisting things if this helps you with packaging electron apps on
Fedora.
8:39 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On 10/11/2021 11:54, Artem Tim wrote:
Indeed, and they are built from sources on Flathub and that exactly
the point. We can do the same for Fedora.
As far as I know, they just parsing yarn.lock file and downloading
assets. This is not suitable for Fedora.
Keep mislead people and twisting things if this helps you with
packaging electron apps on Fedora.
I think it will be very difficult or even impossible to build Electron
apps completely from sources without using pre-built assets from npm (or
parsing and downloading content from yarn.lock).
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
4:13 a.m.
On Wednesday, November 10, 2021 3:39:42 PM CET Vitaly Zaitsev via devel wrote:
> Keep mislead people and twisting things if this helps you with
packaging
> electron apps on Fedora.
I think it will be very difficult or even impossible to build Electron
apps completely from sources without using pre-built assets from npm (or
parsing and downloading content from yarn.lock).
It is a pain, but doable. I have it working for Signal-Desktop.
10:50 a.m.
Neal Gompa wrote:
On Mon, Nov 8, 2021 at 9:16 AM Vitaly Zaitsev via devel
<devel(a)lists.fedoraproject.org> wrote:
>
> On 08/11/2021 10:12, Andreas Schneider wrote:
> > I'm interested in this, as I try to package electron for Fedora.
>
> Electron can't be build completely from sources without downloading
> pre-built binaries/blobs from npm.
>
This is not true anymore.
As I understand it, it was never true, in the sense that it was always
*possible* to build Electron completely from sources. The issue was that the
upstream build system worked against you there and that you had to jump
through a lot of hoops to use components built from source instead of blobs
downloaded from somewhere. Each of the Electron stages was just downloading
the next lower layer as a blob, which in turn included the next lower layer
as a blob. In particular, each Electron app bundled the Electron blob which
was just downloaded from Electron at build time, and each Electron build
bundled the Chromium fork blob which was also downloaded as a blob during
the build. (I think there were even one or two additional blob layers that I
have forgotten. The minified JavaScript blobs you mention were probably also
already part of it.) I do not know to what extent, if at all, this has been
improved since last I checked.
Kevin Kofler
10:52 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On Mon, Nov 8, 2021 at 11:50 AM Kevin Kofler via devel
<devel(a)lists.fedoraproject.org> wrote:
Neal Gompa wrote:
> On Mon, Nov 8, 2021 at 9:16 AM Vitaly Zaitsev via devel
> <devel(a)lists.fedoraproject.org> wrote:
>>
>> On 08/11/2021 10:12, Andreas Schneider wrote:
>> > I'm interested in this, as I try to package electron for Fedora.
>>
>> Electron can't be build completely from sources without downloading
>> pre-built binaries/blobs from npm.
>>
>
> This is not true anymore.
As I understand it, it was never true, in the sense that it was always
*possible* to build Electron completely from sources. The issue was that the
upstream build system worked against you there and that you had to jump
through a lot of hoops to use components built from source instead of blobs
downloaded from somewhere. Each of the Electron stages was just downloading
the next lower layer as a blob, which in turn included the next lower layer
as a blob. In particular, each Electron app bundled the Electron blob which
was just downloaded from Electron at build time, and each Electron build
bundled the Chromium fork blob which was also downloaded as a blob during
the build. (I think there were even one or two additional blob layers that I
have forgotten. The minified JavaScript blobs you mention were probably also
already part of it.) I do not know to what extent, if at all, this has been
improved since last I checked.
Electron can use vanilla Chromium source trees to build now rather
than a prebuilt libchromiumcontent library.
--
真実はいつも一つ！/ Always, there's only one truth!
10:26 a.m.
Andreas Schneider wrote:
there are several packages in the distribution which require FFMPEG
(libavformat, libavcodec, etc.), one of them being chromium. The package
could be created in a way that you can easily replace it with a version
from rpmfusion to get to the full encoder/decoder set including H264 etc.
And does Chromium fully work with HTML5 video if you do that? In particular,
does it correctly report the list of supported codecs to the website? Last I
checked, Chromium hardcoded the list of supported codecs at compile time
(and there were actually only 2 hardcoded lists in the source code, one of
which was selected at compile time depending on whether the
"proprietary_codecs" flag was set at compile time or not; no attempt
whatsoever was made to query ffmpeg for what codecs it actually supports,
neither at compile time nor at runtime), so the only way to replace the list
was to replace the entire Chromium (which is what qt5-qtwebengine-freeworld
does for qt5-qtwebengine: it replaces the entire QtWebEngine shared
libraries including the entire bundled Chromium).
Kevin Kofler
10:33 a.m.
Kevin Kofler via devel wrote:
And does Chromium fully work with HTML5 video if you do that? In
particular, does it correctly report the list of supported codecs to the
website? Last I checked, Chromium hardcoded the list of supported codecs
at compile time (and there were actually only 2 hardcoded lists in the
source code, one of which was selected at compile time depending on
whether the "proprietary_codecs" flag was set at compile time or not; no
attempt whatsoever was made to query ffmpeg for what codecs it actually
supports, neither at compile time nor at runtime), so the only way to
replace the list was to replace the entire Chromium (which is what
qt5-qtwebengine-freeworld does for qt5-qtwebengine: it replaces the entire
QtWebEngine shared libraries including the entire bundled Chromium).
PS: And, also last I checked, even MP3 (whose patents expired a few years
ago) was still considered a "proprietary codec" by Chromium. (The Fedora
Chromium package, but not the qt5-qtwebengine one, has a patch to enable MP3
support, but I think it does not actually touch the supported codec list, it
only enables the codec in the bundled ffmpeg. And to do so, it also requires
several files related, according to their names, to other patent-encumbered
codecs such as AAC, files that I was not comfortable with shipping in qt5-
qtwebengine when I last looked into the issue, which was before I handed
over qt5-qtwebengine maintenance to Rex Dieter.)
Kevin Kofler
5:39 a.m.
New subject: Package FFMPEG with royalty free codes (AV1, THEORA, VPX, OGG,
OPUS, SPEEX, ...) for Fedora
On Mon, 2021-11-08 at 10:12 +0100, Andreas Schneider wrote:
Hi,
there are several packages in the distribution which require FFMPEG
(libavformat, libavcodec, etc.), one of them being chromium. The
package could
be created in a way that you can easily replace it with a version from
rpmfusion to get to the full encoder/decoder set including H264 etc.
This is working fine with openSUSE and packages from Packman.
https://build.opensuse.org/package/show/multimedia:libs/ffmpeg-4
https://pmbs.links2linux.org/package/show/Essentials/A_tw-ffmpeg
Also Debian have ffmpeg package
you may try :
dget https://deb.debian.org/debian/pool/main/f/ffmpeg/ffmpeg_4.4.1-1.dsc
cd ffmpeg-4.4.1/debian
vi README.Debian
etc
The Packman version always has a higher release version than the one
in
the
distribution.
I'm interested in this, as I try to package electron for Fedora. The
big
problem is the included ffmpeg. With openSUSE I can just use the system
ffmpeg, with Fedora I have to do some source code voodoo which I really
would
like to avoid.
Thanks for considering!
Best regards
Andreas
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
--
Sérgio M. B.
9:07 a.m.
Sérgio Basto wrote:
Also Debian have ffmpeg package
you may try :
dget https://deb.debian.org/debian/pool/main/f/ffmpeg/ffmpeg_4.4.1-1.dsc
cd ffmpeg-4.4.1/debian
vi README.Debian
etc
Debian has much less strict rules for multimedia patents than Fedora. E.g.,
Debian has always held the viewpoint that codec patents are only enforcible
against encoders, not decoders, and was happily shipping MP3 decoders back
when the MP3 patent(s) had not yet expired.
Kevin Kofler
897
days inactive
900
days old
49 comments
14 participants
participants (14)
-
Andreas Schneider -
Artem Tim -
Dominik 'Rathann' Mierzejewski -
Fabio Valentini -
Kevin Kofler -
Lyes Saadi -
Lyes Saadi -
Martin Stransky -
Maxwell G (＠gotmax23) -
Neal Gompa -
Rahul Sundaram -
Robbie Harwood -
Sérgio Basto -
Vitaly Zaitsev