Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Thu, 1 Sep 2016 00:01:16 -0400
Mike Gilbert  wrote:

> On Wed, Aug 31, 2016 at 11:09 PM, Mike Gilbert 
> wrote:
> > On Wed, Aug 31, 2016 at 12:52 PM, Alexis Ballier
> >  wrote:  
> >> On Sun, 28 Aug 2016 19:28:48 +0200
> >> "Paweł Hajdan, Jr."  wrote:
> >>  
> >>> D. Patch chromium not to require newer ffmpeg  
> >>
> >>
> >> You can use the attached patch. Quick test on youtube showed it
> >> works.  
> >
> > Nice! Testing this now.  
> 
> The code you have disabled seems to be comparing color space id values
> as defined in src/ui/gfx/color_space.h to the equivalent values in the
> ffmpeg API. I would assume this is because some chromium code uses
> them interchangeably.
> 
> What happens if we pass one of those ids to an ffmpeg function that
> doesn't understand it? I'm afraid this might break in some subtle way.

Me too. Except that looking at the code I realized those values are
only read from ffmpeg, never written to, so this case cannot happen I
think.

Worse: ffmpeg usually parses it from the bitstream and passes it
straight from it since the numerical values are made to match e.g. the
ones from the hevc spec, so it should actually be transparent.

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Mike Gilbert]

On Wed, Aug 31, 2016 at 11:09 PM, Mike Gilbert  wrote:
> On Wed, Aug 31, 2016 at 12:52 PM, Alexis Ballier  wrote:
>> On Sun, 28 Aug 2016 19:28:48 +0200
>> "Paweł Hajdan, Jr."  wrote:
>>
>>> D. Patch chromium not to require newer ffmpeg
>>
>>
>> You can use the attached patch. Quick test on youtube showed it works.
>
> Nice! Testing this now.

The code you have disabled seems to be comparing color space id values
as defined in src/ui/gfx/color_space.h to the equivalent values in the
ffmpeg API. I would assume this is because some chromium code uses
them interchangeably.

What happens if we pass one of those ids to an ffmpeg function that
doesn't understand it? I'm afraid this might break in some subtle way.

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Mike Gilbert]

On Wed, Aug 31, 2016 at 12:52 PM, Alexis Ballier  wrote:
> On Sun, 28 Aug 2016 19:28:48 +0200
> "Paweł Hajdan, Jr."  wrote:
>
>> D. Patch chromium not to require newer ffmpeg
>
>
> You can use the attached patch. Quick test on youtube showed it works.

Nice! Testing this now.

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Rich Freeman]

On Wed, Aug 31, 2016 at 1:03 PM, Alexis Ballier  wrote:
> On Wed, 31 Aug 2016 08:28:14 -0400
> Rich Freeman  wrote:
>> Sure, but we're talking about a major version here, and a web browser
>> where future security updates need to be deployed quickly.  You don't
>> want to be stuck figuring out what other ffmpeg API calls were touched
>> in the new version while there is some exploit floating around.
>>
>> It seems like bundling is the simpler solution here, unless the
>> necessary patches are trivial.  If they're in fact trivial somebody
>> can probably just post one and save a lot of speculation.  :)
>
> It depends on the complexity of the patch indeed. We're talking about 3
> enum values that were added in ffmpeg-3 here.
>

If that is indeed all this is, then it does seem like a no-brainer...

-- 
Rich

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Wed, 31 Aug 2016 08:28:14 -0400
Rich Freeman  wrote:
> Sure, but we're talking about a major version here, and a web browser
> where future security updates need to be deployed quickly.  You don't
> want to be stuck figuring out what other ffmpeg API calls were touched
> in the new version while there is some exploit floating around.
> 
> It seems like bundling is the simpler solution here, unless the
> necessary patches are trivial.  If they're in fact trivial somebody
> can probably just post one and save a lot of speculation.  :)

It depends on the complexity of the patch indeed. We're talking about 3
enum values that were added in ffmpeg-3 here.

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Sun, 28 Aug 2016 19:28:48 +0200
"Paweł Hajdan, Jr."  wrote:

> D. Patch chromium not to require newer ffmpeg


You can use the attached patch. Quick test on youtube showed it works.
Index: chromium-54.0.2837.0/media/ffmpeg/ffmpeg_common.cc
===
--- chromium-54.0.2837.0.orig/media/ffmpeg/ffmpeg_common.cc
+++ chromium-54.0.2837.0/media/ffmpeg/ffmpeg_common.cc
@@ -786,7 +786,9 @@ TEST_PRIMARY(SMPTE170M);
 TEST_PRIMARY(SMPTE240M);
 TEST_PRIMARY(FILM);
 TEST_PRIMARY(BT2020);
+#if LIBAVUTIL_VERSION_INT > AV_VERSION_INT(55,5,0)
 TEST_PRIMARY(SMPTEST428_1);
+#endif
 
 TEST_TRANSFER(RESERVED0);
 TEST_TRANSFER(BT709);
@@ -804,8 +806,10 @@ TEST_TRANSFER(BT1361_ECG);
 TEST_TRANSFER(IEC61966_2_1);
 TEST_TRANSFER(BT2020_10);
 TEST_TRANSFER(BT2020_12);
+#if LIBAVUTIL_VERSION_INT > AV_VERSION_INT(55,5,0)
 TEST_TRANSFER(SMPTEST2084);
 TEST_TRANSFER(SMPTEST428_1);
+#endif
 
 TEST_COLORSPACE(RGB);
 TEST_COLORSPACE(BT709);

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Rich Freeman]

On Wed, Aug 31, 2016 at 8:06 AM, Alexis Ballier  wrote:
>
> For years we've been patching packages to work with >= our latest stable
> version of ffmpeg/libav and unbundle it. Even mplayer. Chromium shouldnt
> be any exception.
>
> Patching consumer packages that way has some advantages:
> - Maintainers do not need to wait for ffmpeg to be stabilized.

Sure, but we're talking about a major version here, and a web browser
where future security updates need to be deployed quickly.  You don't
want to be stuck figuring out what other ffmpeg API calls were touched
in the new version while there is some exploit floating around.

It seems like bundling is the simpler solution here, unless the
necessary patches are trivial.  If they're in fact trivial somebody
can probably just post one and save a lot of speculation.  :)

Ultimately though I think it is up to the chromium team to decide
whether they would rather bundle or patch.  Then perhaps the rest of
us get to decide whether we want chromium in the tree or not.  They're
volunteers, after all, we can't force them to create patches.  I
suspect for quite a few Gentoo would probably go before Chromium does.

-- 
Rich

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Wed, 31 Aug 2016 23:36:21 +1200
Kent Fredric  wrote:

> On Wed, 31 Aug 2016 09:43:08 +0200
> Alexis Ballier  wrote:
> 
> > nobody is talking about a premature unmask and even less about
> > firefox :)  
> 
> Right. My bad on the FF :)  ( ffmpeg having FF in it is clearly
> perturbing my brain )
> 
> But my point really is that *chromium* has end users desiring
> latest-and-greatest for valid security reasons.
> 
> And the strategy of allowing temporary USE masking means the
> life-cycles of stabilization between Chromium and ffmpeg don't need
> to be tied together.
> 
> That way we're not motivated to push stabilization of ffmpeg into end
> users systems in order to satisfy the security cycles of Chromium, so
> we can get Chromium stable and secure without necessitating we do the
> same with ffmpeg.
> 
> And as stabilizing/unmasking ffmpeg relies mostly on the ability for
> its reverse dependencies not to be broken, this essentially means
> without the USE mask option, our stabliziation/unmasking workflow for
> Chromium is now dependent on everything that uses ffmpeg.
> 
> And I'd just rather we not create such a tight, inflexible dependency
> that motivates us to propagate breakage when there's a clear path
> that doesn't propagate breakage.


For years we've been patching packages to work with >= our latest stable
version of ffmpeg/libav and unbundle it. Even mplayer. Chromium shouldnt
be any exception.

Patching consumer packages that way has some advantages:
- Maintainers do not need to wait for ffmpeg to be stabilized.
- ffmpeg does not need to be stabilized in lockstep with a few dozen
  packages that work with this only version.

x 2 if you replace 'stabilized' by 'unmasked' in the above.


Most often it is rather trivial to do; sometimes really annoying (hey
gst)...

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Kent Fredric]

On Wed, 31 Aug 2016 09:43:08 +0200
Alexis Ballier  wrote:

> nobody is talking about a premature unmask and even less about
> firefox :)

Right. My bad on the FF :)  ( ffmpeg having FF in it is clearly perturbing my 
brain )

But my point really is that *chromium* has end users desiring 
latest-and-greatest
for valid security reasons.

And the strategy of allowing temporary USE masking means the life-cycles of 
stabilization
between Chromium and ffmpeg don't need to be tied together.

That way we're not motivated to push stabilization of ffmpeg into end users 
systems
in order to satisfy the security cycles of Chromium, so we can get Chromium 
stable
and secure without necessitating we do the same with ffmpeg.

And as stabilizing/unmasking ffmpeg relies mostly on the ability for its reverse
dependencies not to be broken, this essentially means without the USE mask 
option,
our stabliziation/unmasking workflow for Chromium is now dependent on everything
that uses ffmpeg.

And I'd just rather we not create such a tight, inflexible dependency that 
motivates
us to propagate breakage when there's a clear path that doesn't propagate 
breakage.


pgpG3HvChusMn.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Wed, 31 Aug 2016 03:11:07 +1200
Kent Fredric  wrote:

> On Tue, 30 Aug 2016 09:37:51 +0200
> Alexis Ballier  wrote:
> 
> > Most are fixed, but for me this implies that the space for breaking
> > users setup is much wider with bundled ffmpeg...  
> 
> But that fallout is limited to firefox.
> 
> As opposed to "roll out ffmpeg 3 prematurely" which will break *more*
> than just firefox.

nobody is talking about a premature unmask and even less about
firefox :)

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Kent Fredric]

On Tue, 30 Aug 2016 09:37:51 +0200
Alexis Ballier  wrote:

> Most are fixed, but for me this implies that the space for breaking
> users setup is much wider with bundled ffmpeg...

But that fallout is limited to firefox.

As opposed to "roll out ffmpeg 3 prematurely" which will break *more* than just
firefox.


pgpj4pDhW_kso.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Tue, 30 Aug 2016 16:33:04 +1200
Kent Fredric  wrote:

> On Sun, 28 Aug 2016 19:28:48 +0200
> "Paweł Hajdan, Jr."  wrote:
> 
> > C. Mask chromium's system-ffmpeg flag when the dependency on
> > ffmpeg-3.0.1 can't be satisfied  
> 
> I'd pick this option, mostly because this is the path that introduces
> the least amount of space for breaking users setups.


You seem to forget the burden and the bugs this introduces by itself. A
quick glance at bugzie gave me:

https://bugs.gentoo.org/show_bug.cgi?id=562600
https://bugs.gentoo.org/show_bug.cgi?id=513048
https://bugs.gentoo.org/show_bug.cgi?id=507080
https://bugs.gentoo.org/show_bug.cgi?id=506268
https://bugs.gentoo.org/show_bug.cgi?id=493670
https://bugs.gentoo.org/show_bug.cgi?id=491850
https://bugs.gentoo.org/show_bug.cgi?id=491582
https://bugs.gentoo.org/show_bug.cgi?id=491466


Most are fixed, but for me this implies that the space for breaking
users setup is much wider with bundled ffmpeg...

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Jason Zaman]

On Sun, Aug 28, 2016 at 11:15:40PM -0400, Mike Gilbert wrote:
> On Sun, Aug 28, 2016 at 3:57 PM, Kristian Fiskerstrand  
> wrote:
> > On 08/28/2016 07:28 PM, Paweł Hajdan, Jr. wrote:
> >> B. Backport just the changes needed for chromium to older ffmpeg
> >
> > Any chance of it being included upstream or would it be a downstream
> > carry for a long time?
> 
> I haven't looked at any code, but given that it's a major version bump
> of a library, the changes probably involve API-breaks. Backporting
> them upstream or downstream is probably not a simple matter, and
> probably a bad idea.

Please don't backport or patch. That sounds like a potential disaster
waiting to happen. The tracker bug for ffmpeg 3.0 has been open for
quite a while and is taking time. Backporting just parts of it has the
potential to break both stable and unstable and the time would be better
used working on stabilizing 3.0.

> >> C. Mask chromium's system-ffmpeg flag when the dependency on
> >> ffmpeg-3.0.1 can't be satisfied
> >
> > Would this result in using bundled libraries instead?
> 
> Yes, masking the system-ffmpeg USE flag would cause the bundled ffmpeg
> code to be used.
> 
> The Chromium project applies security fixes quite regularly, so don't
> get too worried over it.

Masking it is fine. Its suboptimal but it has much less breakage-
potential. If 3.0 is not stable in time then just mask it.

Also, is this ffmpeg or libav? or are they the same for 3.x?

-- Jason

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Kent Fredric]

On Sun, 28 Aug 2016 19:28:48 +0200
"Paweł Hajdan, Jr."  wrote:

> C. Mask chromium's system-ffmpeg flag when the dependency on
> ffmpeg-3.0.1 can't be satisfied

I'd pick this option, mostly because this is the path that introduces
the least amount of space for breaking users setups.

We've established there's a lot of problem with having system-wide
ffmpeg 3.0, so running towards that seems foolish.

Patching chromimum to not need 3.0 seems also slightly dodgy.

Though I would be ok with a compromise between C and D, where
system-ffmpeg implied the patch, but otherwise left chromium building
with its bundled ffmpeg.


Then the decision about masking USE="system-ffmpeg" depends on how
stable we expect the patch to be.

Keeping in mind that both case C and D will leave us open to a future
chromium being built with ffmpeg3, and we'll need to make sure that
transition is also smooth.

but for the sake of simplicity, I would just hardmask the useflag until
we know it will work, and then unmask it.


pgpaRAWMriNwG.pgp
Description: OpenPGP digital signature

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Jason A. Donenfeld]

Work on making 3.1.x stable.

In the mean time, mask system-ffmpeg.

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Alexis Ballier]

On Sun, 28 Aug 2016 19:28:48 +0200
"Paweł Hajdan, Jr."  wrote:

> See  for context.
> 
> chromium-54 is currently hard masked; it'd soon enter ~arch, and then
> stable in ~6 weeks. ffmpeg-3.0.1 is currently hard masked.
> 
> These are the options I see for how to proceed. Feel free to share
> further alternatives.
> 
> A. Prepare to unmask and eventually stabilize ffmpeg-3.0.1

Don't use 3.0. Go for 3.1.x.

Except that, it's ideal, but revdeps need to be fixed somehow first.
Help is actually deeply needed to push forward this agenda.

Good news is that Toralf already ran the tinderbox on both ~arch and
stable. Bad news is that there are a lot of failures. Some are not
simple to fix.


> B. Backport just the changes needed for chromium to older ffmpeg

I doubt that is sanely possible.


> C. Mask chromium's system-ffmpeg flag when the dependency on
> ffmpeg-3.0.1 can't be satisfied

It's a bad idea I think.


> D. Patch chromium not to require newer ffmpeg

Maybe the simplest temporary solution, it is equivalent to B. except we
don't change every other consumer of the lib.

In the end, I think if A. can't be sanely achieved, D. is the only
option.


Any clue on what chromium requires from 3.x+ ?

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Mike Gilbert]

On Sun, Aug 28, 2016 at 3:57 PM, Kristian Fiskerstrand  wrote:
> On 08/28/2016 07:28 PM, Paweł Hajdan, Jr. wrote:
>> B. Backport just the changes needed for chromium to older ffmpeg
>
> Any chance of it being included upstream or would it be a downstream
> carry for a long time?

I haven't looked at any code, but given that it's a major version bump
of a library, the changes probably involve API-breaks. Backporting
them upstream or downstream is probably not a simple matter, and
probably a bad idea.

>>
>> C. Mask chromium's system-ffmpeg flag when the dependency on
>> ffmpeg-3.0.1 can't be satisfied
>
> Would this result in using bundled libraries instead?

Yes, masking the system-ffmpeg USE flag would cause the bundled ffmpeg
code to be used.

The Chromium project applies security fixes quite regularly, so don't
get too worried over it.

Re: [gentoo-dev] chromium-54 needs ffmpeg-3.0.1

[Kristian Fiskerstrand]

On 08/28/2016 07:28 PM, Paweł Hajdan, Jr. wrote:
> See  for context.
> 
> chromium-54 is currently hard masked; it'd soon enter ~arch, and then
> stable in ~6 weeks. ffmpeg-3.0.1 is currently hard masked.
> 
> These are the options I see for how to proceed. Feel free to share
> further alternatives.
> 
> A. Prepare to unmask and eventually stabilize ffmpeg-3.0.1

https://bugs.gentoo.org/show_bug.cgi?id=ffmpeg-3

> 
> B. Backport just the changes needed for chromium to older ffmpeg

Any chance of it being included upstream or would it be a downstream
carry for a long time?

> 
> C. Mask chromium's system-ffmpeg flag when the dependency on
> ffmpeg-3.0.1 can't be satisfied

Would this result in using bundled libraries instead?

> 
> D. Patch chromium not to require newer ffmpeg
> 
> Please share your thoughts about pros, cons, and viability of each option.
> 
> I'd certainly be willing to help with testing and making progress on
> these, and I could possibly use a fast machine as a tinderbox for this.
> 
> That also means help is welcome.
> 
> Paweł
> 


-- 
Kristian Fiskerstrand
OpenPGP certificate reachable at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3



signature.asc
Description: OpenPGP digital signature