Samsung / ChromiumGStreamerBackend

Use GStreamer to play media streams in chromium. We implemented a Media Process which is own by the Browser Process and creates players on-demand. Any Video tag will be backed by a GStreamer pipeline that lives in the Media Process.
BSD 3-Clause "New" or "Revised" License
156 stars 55 forks source link

RFE: Support building without FFmpeg #3

Open kkofler opened 9 years ago

kkofler commented 9 years ago

It should be possible to compile Chromium entirely without the FFmpeg backend (only with GStreamer), not only either with both (runtime-selectable) or only with FFmpeg. This is especially important for us in Fedora because FFmpeg is not allowed in Fedora.

aobzhirov commented 9 years ago

Hi, good point. FFmpeg backend is integral part of Chromium and it will be challenging to disable it compile time, but we should definitely consider it. May be it could be done as a part of the refactoring once we introduce media process in upstream Chromium.

kkofler commented 9 years ago

I suppose the first step would be to set media_use_ffmpeg=0 and comment out the runtime backend selection, and see what breaks, right?

kkofler commented 9 years ago

(But that would still try to build a lot of code that isn't actually going to be used, wouldn't it? As far as I can see, your backend plugs in at a much higher level than where the MEDIA_DISABLE_FFMPEG defines are.)

aobzhirov commented 9 years ago

Yes, you are right. If you use MEDIA_DISABLE_FFMPEG it will disable ffmpeg decoder (FFmpegVideoDecoder) for the renderer and it shouldn't compile FFmpeg license code. But it can still use default media player (WebMediaPlayerImpl) with other supported decoders like gpu accelerated (GpuVideoDecoder). And as you said we plug in few levels up and provide our own implementation of blink::WebMediaPlayer that why I was talking about possible future refactoring which would split WebMediaPlayerImpl code into render and media process parts similar to ours. But it looks like you can already disable ffmpeg and use our backend.

CapOM commented 9 years ago

Simply add: media_use_ffmpeg=0 media_use_libvpx=0 media_use_libwebm=0 to the GYP_DEFINES when executing the gyp configuration command. (I need to mention it in our README.md)

Btw why FFmpeg is not allowed on Fedora ?

mariospr commented 9 years ago

Btw why FFmpeg is not allowed on Fedora ?

FFmpeg contains certain algorithms (decoders, encoders) that can be patent encumbered which can't be packaged in Fedora either due to the licensing guidelines: https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Patented_Software (yet you can get them installed via other repositories, such as RPMFusion)

Additionally, another good reason to push for being able to build chromium without the internal FFmpeg it bundles is that Fedora has a strict policy when it comes to bundled libraries which makes it really hard to package Chromium, and not just because of FFmpeg, but also for the rest of libraries it bundles: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries

kkofler commented 9 years ago

Btw why FFmpeg is not allowed on Fedora ?

Because it is a patent minefield. In principle, the patent-encumbered stuff can be ripped out, but in practice, shipping that would be a disservice to our users because its monolithic structure does not allow plugging in additional codecs from third-party repositories, you have to recompile the whole library. Sadly, neither FFmpeg upstream nor Libav upstream are in any way interested in making codecs pluggable. There were even proof of concept patches for codec plugins that got submitted, they all got rejected because they don't like the idea as a principle.

There are Chromium packages in Copr repositories (our version of PPAs) for Fedora, but those ship a bundled FFmpeg with almost all codecs ripped out. Bundled libraries are also not allowed in Fedora in most cases, which is why those packages are only in Copr repositories, and they also suffer from the "can't add more codecs" problem I described above.

CapOM commented 9 years ago

Thx for the detailed explanations. Make perfectly sense. I also like the argument about "Bundled libraries are also not allowed in Fedora in most cases"

Then for chromium it is not only ffmpeg you should disable but at least also libvpx and libwebm.

Theoretically it should be enough to add "media_use_ffmpeg=0 media_use_libvpx=0 media_use_libwebm=0" to the GYP_DEFINES build command.

I tried but I got a few build failures which I fixed: https://github.com/Samsung/ChromiumGStreamerBackend/commit/94e7010a1da9fd163cecd8bc7d7d14a208c15914 It is even a candidate patch for upstream chromium.

So now you should be able to completely disable ffmpeg.

(A side note about HW decoders in chromium, they are not available on desktop linux, only on some Embedded configurations, iOS, Android and ChromeOS. With our on-going zero-copy work our GStreamer backend will be able to use HW decoders that come from gstreamer plugins packages, like gstvaapidecode, gstomxvideodecoder and gstv4l2videodecoder, and having zero-copy working)

JulienIsorce commented 9 years ago

Worth to mention that the patch mentioned in previous comment in under review here: https://codereview.chromium.org/1415793003