Re: chromium-browser from experimental has included h.264 by default?, Re: chromium-browser from experimental has included h.264 by default?
On Tue, May 11, 2010 at 17:27:31 (CEST), Giuseppe Iuculano wrote:
> severity 580947 important
> thanks
For the record, after reading your latest mail, I still disagree with
this assessment, but won't play BTW ping pong.
> Il 11/05/2010 10:44, Reinhard Tartler ha scritto:
>> I can only assume that the functionality to link and use the system
>> ffmpeg is severely broken. One more reason to have bug #580947 at
>> severity serious.
>
> I disagree with this interpretation, please explain why this is broken.
sure.
The explanation was already given correctly by Ben:
On Tue, May 11, 2010 at 17:35:20 (CEST), Ben Hutchings wrote:
>> How can you expect this to work? The ABI of the system ffmpeg libraries
>> is not going to match the ABI defined by the bundled headers. You must
>> patch chromium to work with the system ffmpeg headers.
Later, you write:
> chromium doesn't compile with the current version of ffmpeg in unstable
> because it is too outdated,
Have you thought about *why* it doesn't build? The reason surely isn't
because it's old, but because there have been done *changes* that are
incompatible to the last ffmpeg release. Exactly these changes are the
reasons why I claim your approach inherently broken.
> this means I had three choices:
>
> - compile with use_system_ffmpeg=0 and build_ffmpegsumo=0 (this means
> drop ffmpeg support)
right, that's undesireable.
> - compile with use_system_ffmpeg=1 and build_ffmpegsumo=0 --> FTBFS
right, and the cause has been explained to you know at least two times.
> - compile with use_system_ffmpeg=1 and build_ffmpegsumo=1 (this means
> compile and ship ffmpeg-mt)
I guess you meant "use_system_ffmpeg=0 and build_ffmpegsumo=1".
Settings both values to "1" doesn't really make sense to me. If it does
make a difference to "use_system_ffmpeg=1 and build_ffmpegsumo=1",
please elaborate what the difference is.
But right, I think this is the best option you have at this point. BTW,
this is also what the ubuntu package is doing AFAIUI.
> There was another solution, and this is now adopted in the latest
> experimental package, Compile with use_system_ffmpeg=1 and
> build_ffmpegsumo=0, but use the in-sources include path for headers,
> see [1] and [2]. In this way, chromium doesn't FTBFS but use the
> system ffmpeg libs (if they are available).
Which is going to crash on you at runtime and is inherently
broken. Please don't do this, this leads to the symptoms the reporter of
this bug has.
> Unfortunately it searches also libavutil50, this is in not yet in the
> archive, it is in NEW (experimental) or in debian-multimedia repository.
Of course it does, because the internal copy of ffmpeg that chromium is
using has avutil at SONAME 50, whereas debian's ffmpeg is still at
SONAME49. Even if you would install libavutil50 from experimental or
marillat (don't!), have you considered what would happen if both
libavutil49 and libavutil50 get loaded into the same address space?
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Reply to: