Select provider of libav* libraries

Mon May 18 14:05:11 UTC 2015

Quoting Dmitry Smirnov (2015-05-17 03:28:28)
> I also found an interesting comparison where "mpv" upstream shares
> their assessment of the problem:
>   
https://web.archive.org/web/20150115005029/https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav

Quoting Alessandro Ghedini (2015-05-18 14:26:41)
> On Sun, May 17, 2015 at 10:53:37PM +0200, Jonas Smedegaard wrote:
>> Quoting Alessandro Ghedini (2015-05-17 21:58:15)
>>> The issues mentioned in the page were hardly wide ranging.
[...]
>>> It's also true that the list wasn't really esaustive before it was 
>>> deleted.

>> Oh.  Do I understand you correctly that neither wiki page nor 
>> README.md file is really relevant,
>
> How would they not be relevant? They recommend users to use ffmpeg and 
> list examples of problems they may encounter if they decide to use mpv 
> with libav (problems that are regularly reported as mpv bugs).

Because a) it is not a comparison (as Dmitry introduced it) but a 
non-exhaustive list now shrunk to a single concrete item (subtitle 
coverage) that you find wrong to focus on and instead bring a different 
example of your own, and because b) it is not an assesment of *our* 
problem but a different problem that can be solved by running a script 
that recompiles against uptodate FFmpeg statically linked against mpv.

>>> I've run into libav's lack of external vobsub files support several 
>>> times already. I've also seen broken PGS subtitles decoding in the 
>>> wild, even though I'm not really an avid watcher of BluRays.
>>
>>> Several people also expressly asked me to provide mpv packages built 
>>> against ffmpeg. I suppose they had their own reasons.
>>
>> ...and you do build against ffmpeg.  Targeted experimental.  No doubt 
>> those wanting it would prefer it being easier accessible than that, 
>> but if their reason was "just to be sure to have the most [REDACTED] 
>> possible" then they'd never use our too boring stable release anyway.
>
> You keep saying "[REDACTED]", but

Sorry for my use of strong language.  I distinguish between boring and 
exciting, and concretely above translated that into a likely real-world 
phrase.  I can see how I picked a term with negative connotations.  
Please try imagine the word "cool" in its stead.

> is proper support for features that are documented as being supported 
> but are in practice buggy or unusable considered bleeding edge? What 
> about users of Debian stable that run into libav bugs? Should they use 
> experimental too?

I get the feeling that you think I prefer that mpv linked against FFmpeg 
should stay in experimental.  I don't: Please read my later response to 
IOhannes where I try clarify how I see multiple options, only one of 
them being the current practice of mpv.  Or maybe I misunderstood - if 
so then please try rephrase your questions.

>> We don't know their reasons, so can only speculate and that 
>> speculation can go in any direction, not only towards "ffmpeg is the 
>> better choice for Debian."
>
> That goes both ways.

Yes.  As I wrote: can go in any direction.

> You can't assume people want to use ffmpeg just because "it's 
> bleeding-edge" either (your earlier proposal to have packages built 
> with ffmpeg in experimental, or that ffmpeg shouldn't receive security 
> support sort of implies that).

My main reason for considering FFmeg less boring, more exciting, than 
Libav is its larger codebase and larger featureset:

Quoting Jonas Smedegaard (2015-05-15 11:13:31)
> Quoting Reinhard Tartler (2015-05-15 09:23:13)
>> Also, given that Libav supports significantly less codecs and formats 
>> (and in some cases specific variants or features of codecs), many 
>> security issues simply don't apply.
>
> I find above important, not only for security but for long-term 
> maintenance in general.

I consider FFmpeg not boring enough for shipping with stable Debian, 
compared to Libav.

Maybe _neither_ Libav nor FFmpeg are boring enough for stable Debian, 
security team has send a clear message that they do not have enough 
resources to handle security-related bugs for both, which can be 
addressed by either picking one to have security support or pick none.

>>> It might be true that there is no major issue that makes libav 
>>> unusable for everyone,
>>
>> I never said that.
>>
>> My main concern is long-term maintainability.
>
> (The following is sort of off-topic in respect to the point you were 
> making, sorry about that, but I'd like to understand your POV).
>
> What does "long-term maintainability" even mean for you? What are the 
> factors that make something long-term maintanable and something else 
> not in your opinion and why is libav better in that regard?
>
> As far as Debian stable is concerned the only relevant metric is 
> security support, simply because pretty much any other change will 
> just be rejected by the release team (unless it's for some really 
> serious bug).

Stable updates are generally security updates.  But iceweasel and 
Postgres got major upgrades in several Wheezy point releases.

A concern for Release team is also complexity of bugfixes - e.g. if a 
bugfix requires 2 or 200 binNMUs that needs verification they didn't 
subtly break.  Or if a bug in some network-related crypto handling are 
entangled with 2 or 15 subtitle parsers: Although the parsers themselves 
are not security-flawed, the bugfix may break them accidentally.

A more complex ABI means more ways things can break for 
reverse-dependencies - no matter if the change is a security-related 
bugfix or some other change (e.g. a bug revealed by mere recompilation 
triggered by a bugfix in _another_ library).

> And it's already clear that libav just doesn't provide enough security 
> coverage,

Clear how?  Not by the wiki page nor README.md texts discussed here.

>>> but there are a lot of somewhat minor issues that make libav 
>>> unusable for many different use-cases (e.g. see Fabian's earlier 
>>> email). Which is kinda sad IMO, considering that the needs of our 
>>> users is supposed to be one of Debian's main priorities.
>>
>> "supposed to be"? - are you somehow implying that you know the needs 
>> of our users
>
> I'm implying that users have been asking for what they need (ffmpeg) 
> for a long time, and Debian isn't providing it.

Why bother discussing, if what our users are craving for is not 
stability nor any concrete features, but simply the brand "ffmpeg"?

I want us to discuss boring vs. exciting, not strong vs. weak.

 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20150518/e11eb55b/attachment.sig>