Static linking against ffmpeg for Chromium builds

[Raymond Wooninck]

Hi,

A colleague at openSUSE pointed me out to the following commit ( https://
chromium.googlesource.com/chromium/src/+/
fd11b3c3aa6730ae1f024811b61913cd63f9d39a)

With this commit, Chromium will be changed to statically link against ffmpeg.
It hasn't reached the latest dev build yet, but I am expecting it with the
next update of the dev channel.

For openSUSE this might mean the end of the chromium builds as that this would
mean we can only deliver a crippled chromium and no longer an easy way to get
full ffmpeg support by just building the libffmpegsumo in a different place
(in our case packman OBS). Unfortunately packman OBS does not have the
resources to build Chromium completely which means that openSUSE has to drop
the Chromium builds.

I am not sure how happy that other Chromium packagers are with this move
(especially since that it is only there to resolve Windows bugs).

It would have been great if this could be a selectable feature or that it was
just activated for Windows builds.

Regards

Raymond
Chromium packager for openSUSE

[Chad Miller]

We've been pretty worried about it in Ubuntu land too. 

--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/7320845.i3p4ceMzAa%40hqvmt44011.eur.

[Miro Hrončok]

Fedora would have a problem as well.

Dne 15.6.2015 12:16 napsal uživatel "Raymond Wooninck" <titti...@gmail.com>:

[Michael Moss]

+chcunningham

On Mon, Jun 15, 2015 at 5:33 AM, Miro Hrončok <mi...@hroncok.cz> wrote:

Fedora would have a problem as well.

Dne 15.6.2015 12:16 napsal uživatel "Raymond Wooninck" <titti...@gmail.com>:

Hi,

A colleague at openSUSE pointed me out to the following commit ( https://
chromium.googlesource.com/chromium/src/+/
fd11b3c3aa6730ae1f024811b61913cd63f9d39a)

With this commit, Chromium will be changed to statically link against ffmpeg.
It hasn't reached the latest dev build yet, but I am expecting it with the
next update of the dev channel.

For openSUSE this might mean the end of the chromium builds as that this would
mean we can only deliver a crippled chromium and no longer an easy way to get
full ffmpeg support by just building the libffmpegsumo in a different place

Can you elaborate on this, since I'd guess chcunningham isn't familiar with Linux distro issues?

 

(in our case packman OBS).  Unfortunately packman OBS does not have the
resources to build Chromium completely which means that openSUSE has to drop
the Chromium builds.

I am not sure how happy that other Chromium packagers are with this move
(especially since that it is only there to resolve Windows bugs).

It would have been great if this could be a selectable feature or that it was
just activated for Windows builds.

Regards

Raymond
Chromium packager for openSUSE

--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/7320845.i3p4ceMzAa%40hqvmt44011.eur.

--
You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/CAG7fsRQKzHXUgSr1eU%3D3LtQyg448Qdfv7GVX_g0mQbNQBB_5YA%40mail.gmail.com.

[Raymond Wooninck]

On Monday 15 June 2015 09:01:44 'Michael Moss' via chromium-packagers wrote:
> >> For openSUSE this might mean the end of the chromium builds as that this
> >> would
> >> mean we can only deliver a crippled chromium and no longer an easy way to
> >> get
> >> full ffmpeg support by just building the libffmpegsumo in a different
> >> place
>
> Can you elaborate on this, since I'd guess chcunningham isn't familiar with
> Linux distro issues?
>

Sure. :)

For a number of distro's (e.g. openSUSE, Fedora) it is impossible to ship
ffmpeg due to the legal issues around some of the codecs inside (e.g. mp3). As
that I am packaging for openSUSE, I can only indicate the situation there. In
the beginning of Chromium it was possible to build Chromium with ffmpeg
support, but a lot of people complained that they couldn't play video's etc.
Also at a certain moment ffmpeg needed to be build due to the dependencies in
Chromium itself (ffmpegsumo) We as the openSUSE community then had a
discussion with the legal department of SUSE to see what was possible in order
to keep Chromium as one of the browsers that were officially delivered as part
of the distro. We got the ok from the legal department, that we could host the
source for ffmpeg on the openSUSE Build Service and that we could build ffmpeg
support based on the opensource codecs. This was easily done as that mp3
support would require certain buildrequirements which couldn't be satisfied
anyway. This is the current situation for openSUSE where we deliver Chromium
with a limit ffmpegsumo that can only play opensource codecs (e.g. ogg,
vorbis). We are also utilizing the Packman Build Service (community driven
buildservice for openSUSE, where packages can be build that cannot be build by
SUSE/openSUSE due to possible legal implications) to build just the ffmpeg
source inside the chromium tree with all build requirements satisfied. This
delivers the single libffmpegsumo which contains all the codecs that Chromium
supports. Users can now easily install the ffmpegsumo from the Packman Build
Service which would overwrite the limit version, giving the user the full
Chromium.

Now in the new situation, this is no longer possible as that Chromium will
statically link against ffmpeg. This means that the libffmpegsumo is gone and
that we now have the choice either to build Chromium with limited ffmpeg
support as a browser delivered with openSUSE or to drop the build completly
from openSUSE Build Service and trying to build Chromium fully on Packman.
However the Packman Build Service does not have the resources to support a
buildhost that can actually build Chromium. In the end this would lead to the
situation where openSUSE will drop Chromium as a supported webbrowser and will
just have FireFox as the main browser.

What I know is that on Fedora the situation is worse as that they have no
green light from the Red Hat legal department to put even the ffmpeg source on
the official Build Service and this would even further reduce the chance to
ever have an official supported Chromium build there.

Given the current reaction from Fedora, Ubuntu and openSUSE, it would be great
if we can keep the possibility to keep libffmpegsumo and that Chromium is
dynamically linked against it. The best would be of course if Chromium can
use the ffmpeg system libraries during runtime instead of using its own copy
:)

I do not know the situation for Ubuntu/Debian, etc but I am sure that they
will add their specitics to this email.

Regards

Raymond

[Chad Miller]

Ubuntu and Debian's problem is not in our builders, but for our users. Some users' jurisdictions don't allow them to use some software, and it's impossible to accommodate them all, so we try for two levels: full featured, and unencumbered.

We want to support users in export-restricted countries, or those with terrible patent regimes, onerous licensing authorities, or with other local political troubles. We can't do that if there is no such thing as unencumbered code set.

When I say all this, I am using legal advice that's ten years old. It's possible things have changed somehow since then. I saw a hint in comments in the bug reports or change logs suggesting Google thinks so. But, I don't know about that.

For how, I really want gyp-time setting of whether patented code is included.

- chad, Ubuntu maintainer

[chcunn...@google.com]

Sorry I'm late to the party. I think we solve this without undoing static linking.

While the initial motivation for static linking was fixing windows crashes, we'd like to keep in place on all platforms because it helps us shave off a few hundred KB in overall binary size thanks to dead-code elimintaion. Also, keeping things unified across operating systems reduces developer headaches.

Raymond, IIUC you wish to split out ffmpeg into its shared lib because you replace that lib downstream via pacman. I can easily add a gyp flag that will cause ffmpeg.so (previously ffmpegsumo.so) to re-appear. I've prototyped the change here: https://chromium-review.googlesource.com/#/c/280602/1/ffmpeg.gyp

To use you would simply append "-D ffmpeg_component=shared_library" to the gyp_chromium command. I'll make a similar change to GN if I get good feedback on the GYP prototype.

Chad, I'm not sure I follow how static linking breaks Ubuntu. I hear you about patents etc. We have a gyp flag that may be useful: -D proprietary_codecs=0 will cause chrome to be build without including h264 and similar in ffmpeg. I can't promise it will remove all of your patent concerns, but its a good start. This flag worked before static linking and works after it. You guys could patch in similar flags if you'd like to go further and remove more patented code.

[chcunn...@google.com]

Miro, can you give more details on Fedora's concerns? Does the gyp workaround I mentioned to Raymond help?

[Miro Hrončok]

Chris, I'm sorry byt I don't have time to examine it properly right
now, do whatever Raymond likes and I'll be happy.

Miro Hrončok

Telefon: +420777974800

2015-06-19 4:22 GMT+02:00 <chcunn...@google.com>:
> Miro, can you give more details on Fedora's concerns? Does the gyp workaround I mentioned to Raymond help?
>

> --
> You received this message because you are subscribed to the Google Groups "chromium-packagers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to chromium-packag...@chromium.org.

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-packagers/7436bd39-03b2-4448-89b4-624c0ef9d83b%40chromium.org.

[Raymond Wooninck]

On Thursday 18 June 2015 19:20:42 chcunn...@google.com wrote:

> Raymond, IIUC you wish to split out ffmpeg into its shared lib because you
> replace that lib downstream via pacman. I can easily add a gyp flag that
> will cause ffmpeg.so (previously ffmpegsumo.so) to re-appear. I've
> prototyped the change here:
> https://chromium-review.googlesource.com/#/c/280602/1/ffmpeg.gyp
>
> To use you would simply append "-D ffmpeg_component=shared_library" to the
> gyp_chromium command. I'll make a similar change to GN if I get good
> feedback on the GYP prototype.
>

Hi Chris,

Thanks for this feedback. I think that adding this gyp flag, would help
everybody and not just openSUSE. In believe that also Ubuntu is having a
certain methodology, where they would build the ffmpeg in two versions (full
and limited) and then based on the users location either one of them is being
made available. Static linking would mean for them that they have to rebuild
chromium twice, but with the shared library only the ffmpeg part has to be
rebuild in order to get a full version.

At the moment the new dev build available has your commit and I am playing
with it to see what is possible or not. I have been building the DEV build
with shared_libraries and I am wondering if this would allow me already to
replace just the ffmpeg.so file. However I know that shared_libraries are not
really the preference to build from a google perspective, but this would
indeed be resolved by your new flag.

I will patch the dev tarball with your prototype, to see if this works :)

Thanks

Regards

Raymond

[Raymond Wooninck]

On Thursday 18 June 2015 19:20:42 chcunn...@google.com wrote:

> Raymond, IIUC you wish to split out ffmpeg into its shared lib because you
> replace that lib downstream via pacman. I can easily add a gyp flag that
> will cause ffmpeg.so (previously ffmpegsumo.so) to re-appear. I've
> prototyped the change here:
> https://chromium-review.googlesource.com/#/c/280602/1/ffmpeg.gyp
>
> To use you would simply append "-D ffmpeg_component=shared_library" to the
> gyp_chromium command. I'll make a similar change to GN if I get good
> feedback on the GYP prototype.

Hi Chris,

I build Chromium-dev with shared libraries (without your patch atm) and I
build locally the full blown libffmpeg.so. If I install the package build on
openSUSE OBS, then indeed certain audio/video codecs are not supported (which
is inline with the expections).

After the above test, I copied the locally build libffmpeg.so (build from just
within the third_party/ffmpeg directory) and started chromium again. Executing
the same tests shows that now also the encumbered codecs are being supported.,
Which indicates that the old procedure still works.

With your patch it would be easy to build just libffmpeg.so as a shared
library and have this one replaced by the full version. Please let me know if
you need anything else from my side to get your patch in.,

Thanks.

Regards

Raymond

[chcunn...@google.com]

Thanks for confirming Raymond. I'll send this patch off for review today :)

[chcunn...@google.com]

On Monday, June 22, 2015 at 12:48:41 PM UTC-7, chcunn...@google.com wrote:
> Thanks for confirming Raymond. I'll send this patch off for review today :)

The changes to ffmpeg GYP/GN have landed here: https://codereview.chromium.org/1198653005/

For GYP, set ffmpeg_component = shared_library (defaults to static_library)
For GN, set is_component_ffmpeg = true

[Raphael Kubo Da Costa]

Are there any plans to roll ffmpeg in M44 as well? As far as I can see the roll was only done in master, so even though M45 does include the ffmpeg_component change, M44 still does not and only allows ffmpeg to be built statically. 

[Chris Cunningham]

Hi Raphael, 

I had not planned cherry-pick to include the ffmpeg_component into M44 and we've missed the cutoff date for the stable M44 release. Its possible that we could still cherry-pick the change into the 44-branch, but we'd like to only do this if it's really critical. How are you using the official branch milestones to package for linux distros? Would it be possible for you to cherry pick the change locally?

Best,

Chris

[Raphael Kubo da Costa]

Chris Cunningham <chcunn...@google.com> writes:

> Hi Raphael,
>
> I had not planned cherry-pick to include the ffmpeg_component into M44 and
> we've missed the cutoff date for the stable M44 release. Its possible that
> we could still cherry-pick the change into the 44-branch, but we'd like to
> only do this if it's really critical. How are you using the official branch
> milestones to package for linux distros? Would it be possible for you to
> cherry pick the change locally?

Hey Chris,

I can take care of manually rolling ffmpeg forward to address my own use
case (Crosswalk).

However, it also means all Linux distributions which choose to continue
building ffmpeg as a shared library will need to apply the patch you
landed in ffmpeg on top of the source code they get from the Chromium
tarballs for the whole period where M44 remains in the stable channel.

Rolling ffmpeg for M44 would just avoid a lot of duplicated efforts
(plus my own approach of rolling ffmpeg forward might break if a new
merge-m44 branch gets created in the ffmpeg repository and it does not
contain that commit).

[chcunn...@google.com]

Arg, my last reply went only to Raphael.

Good news: the gyp/gn changes have just been cherrypicked into the 44 branch!

[Raphael Kubo da Costa]

<chcunn...@google.com> writes:

> Arg, my last reply went only to Raphael.
>
> Good news: the gyp/gn changes have just been cherrypicked into the 44 branch!

Thanks a lot for working on this :-)