Re: Re: About chromium packaging

[Jeremy Newton]

See the review request:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=4363

Note that I'm leaning towards just making a chromium-freeworld instead of
this package. Please see the request and leave your feedback there.

On Mon, Nov 28, 2016 at 6:24 PM, Jeremy Newton  wrote:

> I want to do this, but I've been swamped at work recently. If someone
> beats me to it, feel free.
>
> I believe it's as simple as enabling "freeworld" and exclude all the other
> files (as they would be duplicated from Fedora). I'll look into it tonight,
> and if I get a working solution, i'll make a review request.
>
> In the event that some one beats me, please cc me on the request and I
> will review it.
>
> On Thu, Nov 24, 2016 at 2:05 PM, Jeremy Nouhaud 
> wrote:
>
>> Well I'm not skilled enough but I'm surprised that nobody in RPMFusion
>> is interested since it looks to be relatively simple.
>>
>> > 2016-11-12 13:44 GMT+01:00 Jeremy Nouhaud :
>> > Hello,
>> >
>> > According to Tom 'spot' Callaway it's possible to build a
>> > chromium-libs-media-freeworld package to make available proprietary
>> > codecs
>> > to chromium. It will be great if that can be add to RPMFusion !
>> Feel free to maintain the work in RPM Fusion.Thx-- -Nicolas (kwizart)
>>
>
>

Re: Re: About chromium packaging

[Jeremy Newton]

I want to do this, but I've been swamped at work recently. If someone beats
me to it, feel free.

I believe it's as simple as enabling "freeworld" and exclude all the other
files (as they would be duplicated from Fedora). I'll look into it tonight,
and if I get a working solution, i'll make a review request.

In the event that some one beats me, please cc me on the request and I will
review it.

On Thu, Nov 24, 2016 at 2:05 PM, Jeremy Nouhaud 
wrote:

> Well I'm not skilled enough but I'm surprised that nobody in RPMFusion
> is interested since it looks to be relatively simple.
>
> > 2016-11-12 13:44 GMT+01:00 Jeremy Nouhaud :
> > Hello,
> >
> > According to Tom 'spot' Callaway it's possible to build a
> > chromium-libs-media-freeworld package to make available proprietary
> > codecs
> > to chromium. It will be great if that can be add to RPMFusion !
> Feel free to maintain the work in RPM Fusion.Thx-- -Nicolas (kwizart)
>

Re: Re: About chromium packaging

[Jeremy Nouhaud]

Well I'm not skilled enough but I'm surprised that nobody in RPMFusion
is interested since it looks to be relatively simple.

> 2016-11-12 13:44 GMT+01:00 Jeremy Nouhaud :
> Hello,
>
> According to Tom 'spot' Callaway it's possible to build a
> chromium-libs-media-freeworld package to make available proprietary
> codecs
> to chromium. It will be great if that can be add to RPMFusion !
Feel free to maintain the work in RPM Fusion.Thx-- -Nicolas (kwizart)

Re: Re: About chromium packaging

[Nicolas Chauvet]

2016-11-12 13:44 GMT+01:00 Jeremy Nouhaud :
> Hello,
>
> According to Tom 'spot' Callaway it's possible to build a
> chromium-libs-media-freeworld package to make available proprietary codecs
> to chromium. It will be great if that can be add to RPMFusion !
Feel free to maintain the work in RPM Fusion.

Thx

-- 
-

Nicolas (kwizart)

Re: Re: About chromium packaging

[Jeremy Nouhaud]

Hello,

According to Tom 'spot' Callaway it's possible to build a chromium-
libs-media-freeworld package to make available proprietary codecs to
chromium. It will be great if that can be add to RPMFusion !

https://www.reddit.com/r/Fedora/comments/5buozn/how_to_enable_mse_h264_
in_chromium/

https://www.reddit.com/r/Fedora/comments/5buozn/how_to_enable_mse_h264_
in_chromium/d9x3lap/

Thanks !

Re: Re: About chromium packaging

[Jeremy Nouhaud]

Hello,

Any progress on the codec handling of Chromium ?

Thanks !

Re: About chromium packaging

[Kevin Kofler]

Neal Gompa wrote:
> You really only need to recompile libmedia.so, which is where the
> codec whitelist exists. Both this and the libffmpeg.so library are
> provided by the chromium-libs-media package. I'm not sure if it would
> work with the system ffmpeg library without a patch, so you may need
> to recompile specifically the libmedia.so and libffmpeg.so components
> from the Chromium sources into a new chromium-libs-media-freeworld
> package.

Replacing libmedia.so is unfortunately not enough. The 
USE_PROPRIETARY_CODECS compile-time flag is checked all over the place, even 
in the application layer. See e.g.:
https://chromium.googlesource.com/chromium/src.git/+/master/chrome/common/chrome_content_client.cc#135

(QtWebEngine's equivalent has the same at:
http://code.qt.io/cgit/qt/qtwebengine.git/tree/src/core/content_client_qt.cpp#n253
by the way.)

You'll probably find more if you search all .cc files for the string. So 
either you patch all these usages in the Fedora Chromium package to look up 
the flag from libmedia at runtime, or there is no way around recompiling the 
whole Chromium.

Kevin Kofler

Re: About chromium packaging

[Nicolas Chauvet]

2016-08-09 23:35 GMT+02:00 Neal Gompa :
> On Sun, Aug 7, 2016 at 5:56 PM, Kevin Kofler  wrote:
>> Hans de Goede wrote:
>>>  I don't understand why you keep repeating this. I'm sure we can
>>> come-up with a patch to make the codec-lists a runtime configurable
>>> thing, this is not rocket science.
>>
>> If you want to have a try at fixing this, look, e.g., at the member variable
>> media::MimeUtil::allow_proprietary_codecs_, i.e., the way it is initialized
>> (to a compile-time hardcoded value) and the way it is used (in several
>> places).
>>
>> The right way would really be to remove the boolean variable (which only
>> allows a binary all-or-nothing approach to patent-encumbered codecs)
>> entirely and query for each individual codec at runtime. But then, you will
>> likely be querying FFmpeg directly, whereas for Samsung's GStreamer backend
>> (which is also affected by this issue, see
>> https://github.com/Samsung/ChromiumGStreamerBackend/issues/16 ), one would
>> have to query GStreamer directly instead. You would also likely be touching
>> several code places related to codec support.
>>
>> A less invasive approach would simply try to initialize
>> media::MimeUtil::allow_proprietary_codecs_ to a runtime-detected value.


So, I'm asking the question again, is there any volunteer to maintain
an existing plugin for chromium ?

Thx



-- 
-

Nicolas (kwizart)

Re: About chromium packaging

[Neal Gompa]

On Sun, Aug 7, 2016 at 5:56 PM, Kevin Kofler  wrote:
> Hans de Goede wrote:
>>  I don't understand why you keep repeating this. I'm sure we can
>> come-up with a patch to make the codec-lists a runtime configurable
>> thing, this is not rocket science.
>
> If you want to have a try at fixing this, look, e.g., at the member variable
> media::MimeUtil::allow_proprietary_codecs_, i.e., the way it is initialized
> (to a compile-time hardcoded value) and the way it is used (in several
> places).
>
> The right way would really be to remove the boolean variable (which only
> allows a binary all-or-nothing approach to patent-encumbered codecs)
> entirely and query for each individual codec at runtime. But then, you will
> likely be querying FFmpeg directly, whereas for Samsung's GStreamer backend
> (which is also affected by this issue, see
> https://github.com/Samsung/ChromiumGStreamerBackend/issues/16 ), one would
> have to query GStreamer directly instead. You would also likely be touching
> several code places related to codec support.
>
> A less invasive approach would simply try to initialize
> media::MimeUtil::allow_proprietary_codecs_ to a runtime-detected value.
>
> Kevin Kofler

You really only need to recompile libmedia.so, which is where the
codec whitelist exists. Both this and the libffmpeg.so library are
provided by the chromium-libs-media package. I'm not sure if it would
work with the system ffmpeg library without a patch, so you may need
to recompile specifically the libmedia.so and libffmpeg.so components
from the Chromium sources into a new chromium-libs-media-freeworld
package.

-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: About chromium packaging

[Kevin Kofler]

Hans de Goede wrote:
>  I don't understand why you keep repeating this. I'm sure we can
> come-up with a patch to make the codec-lists a runtime configurable
> thing, this is not rocket science.

If you want to have a try at fixing this, look, e.g., at the member variable 
media::MimeUtil::allow_proprietary_codecs_, i.e., the way it is initialized 
(to a compile-time hardcoded value) and the way it is used (in several 
places).

The right way would really be to remove the boolean variable (which only 
allows a binary all-or-nothing approach to patent-encumbered codecs) 
entirely and query for each individual codec at runtime. But then, you will 
likely be querying FFmpeg directly, whereas for Samsung's GStreamer backend 
(which is also affected by this issue, see 
https://github.com/Samsung/ChromiumGStreamerBackend/issues/16 ), one would 
have to query GStreamer directly instead. You would also likely be touching 
several code places related to codec support.

A less invasive approach would simply try to initialize 
media::MimeUtil::allow_proprietary_codecs_ to a runtime-detected value.

Kevin Kofler

Re: About chromium packaging

[Hans de Goede]

Hi,

On 07-08-16 14:03, Kevin Kofler wrote:

Nicolas Chauvet wrote:

libffmpeg.so is not provided anymore in the approved fedora build.
So I think there is nothing much to replace, but instead to provide
the shared library as a complement.


If it's not build as a shared library, then it's statically linked and
cannot be replaced at all (without recompiling the entire Chromium). And
anyway, you are also going to run into issue 3 (the hardcoded codec lists)
if you don't recompile the whole Chromium.


 I don't understand why you keep repeating this. I'm sure we can
come-up with a patch to make the codec-lists a runtime configurable
thing, this is not rocket science.

Regards,

Hans

Re: Re: About chromium packaging

[Kevin Kofler]

Nicolas Chauvet wrote:
> libffmpeg.so is not provided anymore in the approved fedora build.
> So I think there is nothing much to replace, but instead to provide
> the shared library as a complement.

If it's not build as a shared library, then it's statically linked and 
cannot be replaced at all (without recompiling the entire Chromium). And 
anyway, you are also going to run into issue 3 (the hardcoded codec lists) 
if you don't recompile the whole Chromium.

Kevin Kofler

Re: Re: About chromium packaging

[Nicolas Chauvet]

2016-08-07 1:18 GMT+02:00 Kevin Kofler :
> Jeremy Nouhaud wrote:
>> According to this comment from Spot it is possible to make, I quote,
>> "an rpmfusion addon package to replace the ffmpegsumo.so".
>
> And that comment is incorrect (or at least poorly formulated and
> incomplete):
> 1. There is no "ffmpegsumo.so" in his package (nor in any other current
>Chromium package). That file name was dropped in Chromium 45. Now, FFmpeg
>is either static, or shared as libffmpeg.so (in a private library
>directory). spot's package uses the latter (shared libffmpeg.so).
libffmpeg.so is not provided anymore in the approved fedora build.
So I think there is nothing much to replace, but instead to provide
the shared library as a complement.

I might have something to share to acheive that, so please ask on
#rpmfusion IRC about this, as I don't plan to do much packaging work
until the infra is finished.

Thx


Nicolas (kwizart)

Re: Re: About chromium packaging

[Jeremy Nouhaud]

I don't know why he say that if it's not really possible. Maybe you can
talk with him to have some clarifications ?

Re: Re: About chromium packaging

[Jeremy Nouhaud]

According to this comment from Spot it is possible to make, I quote,
"an rpmfusion addon package to replace the ffmpegsumo.so".

https://bodhi.fedoraproject.org/updates/chromium-52.0.2743.82-2.fc24#co
mment-464045

Re: About chromium packaging

[Kevin Kofler]

Nicolas Chauvet wrote:
> Okay, good news, so we may have the chromium-ffmpeg under review.

It might not be enough to replace the chromium-ffmpeg, you may need a 
complete chromium-freeworld rebuild with the enable_proprietary_codecs flag 
on. There is code in Chromium itself which hardcodes the list of available 
codecs (which is provided, e.g., to websites querying for supported codecs) 
depending on that compile-time flag. The GStreamer backend in Samsung's fork 
currently has the same issue, which pretty much defeats the point of using 
GStreamer. See also 
https://github.com/Samsung/ChromiumGStreamerBackend/issues/16

If things like Pepper plugins and Widevine DRM support are not compiled in 
(as was mentioned elsewhere in this thread), that would be another possible 
reason for rebuilding the entire package. (For what it's worth, QtWebEngine 
actually enables support for both of them, there just aren't any blobs 
shipped – if you want Pepper Flash or the Widevine DRM blob (which is also 
shipped as a Pepper plugin), you need to get them from Chrome or elsewhere, 
downloading Chrome being probably the only legal way to get them.) That 
said, if you're going to install the proprietary Chrome anyway to get those 
proprietary blobs, why would you even bother with the Chromium package? (It 
makes more sense for QtWebEngine, which integrates the Chromium/Blink engine 
into native Qt applications.)

> (unless this chromium use gstreamer ?)

It doesn't. Spot's package is a package of upstream Chromium without 
Samsung's changes.

Kevin Kofler

Re: About chromium packaging

[Nicolas Chauvet]

2016-07-19 14:43 GMT+02:00 Andrea Musuruane :
>
>
> On Tue, Jul 19, 2016 at 2:38 PM, Nicolas Chauvet  wrote:
>>
>> Hello,
>>
>> I've just saw that chromium was banned to RPM Fusion whislist
>> http://rpmfusion.org/Wishlist
>>
>> I haven't see any message from the developers mailing list where this
>> has been discussed.
>> To be, the only valid reason why a software can be banned from the
>> repo is that it cannot be redistributed.
>
>
> Well, we don't also accept software that can go to Fedora proper. And if I'm
> not mistaken Chromium can go directly to Fedora. There even a review request
> open:
> https://bugzilla.redhat.com/show_bug.cgi?id=1270322

Okay, good news, so we may have the chromium-ffmpeg under review.
(unless this chromium use gstreamer ?)



-- 
-

Nicolas (kwizart)

Re: About chromium packaging

[Sérgio Basto]

On Ter, 2016-07-19 at 14:42 +0200, Antonio Trande wrote:
> chromium is under review on Fedora:
> https://bugzilla.redhat.com/show_bug.cgi?id=chromium

from https://github.com/UnitedRPMs/packages/issues/13#issuecomment-233225170

Chromium was approved in Fedora Official repositories!!
https://bugzilla.redhat.com/show_bug.cgi?id=1270322

@kuboosoft no ffmpeg, no HTML5 multimedia, no way.

The rpm of Spot has disabled the capability for pepper and widevine...
then? maybe a chromium-freeworld :)


> On 07/19/2016 02:38 PM, Nicolas Chauvet wrote:
> > 
> > Hello,
> > 
> > I've just saw that chromium was banned to RPM Fusion whislist
> > http://rpmfusion.org/Wishlist
> > 
> > I haven't see any message from the developers mailing list where
> > this
> > has been discussed.
> > To be, the only valid reason why a software can be banned from the
> > repo is that it cannot be redistributed.
> > 
> > 
-- 
Sérgio M. B.

Re: About chromium packaging

[Andrea Musuruane]

On Tue, Jul 19, 2016 at 2:38 PM, Nicolas Chauvet  wrote:

> Hello,
>
> I've just saw that chromium was banned to RPM Fusion whislist
> http://rpmfusion.org/Wishlist
>
> I haven't see any message from the developers mailing list where this
> has been discussed.
> To be, the only valid reason why a software can be banned from the
> repo is that it cannot be redistributed.
>

Well, we don't also accept software that can go to Fedora proper. And if
I'm not mistaken Chromium can go directly to Fedora. There even a review
request open:
https://bugzilla.redhat.com/show_bug.cgi?id=1270322

Bye,

Andrea

Re: About chromium packaging

[Antonio Trande]

chromium is under review on Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=chromium

On 07/19/2016 02:38 PM, Nicolas Chauvet wrote:
> Hello,
> 
> I've just saw that chromium was banned to RPM Fusion whislist
> http://rpmfusion.org/Wishlist
> 
> I haven't see any message from the developers mailing list where this
> has been discussed.
> To be, the only valid reason why a software can be banned from the
> repo is that it cannot be redistributed.
> 
> 

-- 
---
Antonio Trande
mailto: sagitter 'at' fedoraproject 'dot' org
http://fedoraos.wordpress.com/
https://fedoraproject.org/wiki/User:Sagitter
GPG Key: 0x6CE6D08A
Check on https://keys.fedoraproject.org/



signature.asc
Description: OpenPGP digital signature

About chromium packaging

[Nicolas Chauvet]

Hello,

I've just saw that chromium was banned to RPM Fusion whislist
http://rpmfusion.org/Wishlist

I haven't see any message from the developers mailing list where this
has been discussed.
To be, the only valid reason why a software can be banned from the
repo is that it cannot be redistributed.


-- 
-

Nicolas (kwizart)