Select provider of libav* libraries

[Alessandro Ghedini]

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. One was 
> > about the fact that libav doesn't implement some video filters, which 
> > forces mpv to carry its own implementations (still true). Another 
> > about about libav HTTP support (most likely fixed but I'm not sure). 
> > The other were all about subtitles.
> > 
> > It's also true that the list wasn't really esaustive before it was 
> > deleted. For example one time I tried to convert a part of a movie 
> > into a GIF with mpv, before realizing that libav's GIF encoder is 
> > completely broken (I actually tried to backport it from ffmpeg, before 
> > giving up and switching to ffmpeg myself), but this wasn't mentioned 
> > in the wiki.
> 
> 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).

But my point was that they don't list all the problems, so trying to argue
that the problems listed aren't really that relevant is useless because it
doesn't take much to find other ones.

> >> Ok, so exotic subtitle formats is a "particular" reason for mpv authors 
> >> to favor FFmpeg over libav.
> >
> > Where did you get the "exotic" part?
> 
> Sorry that I didn't clarify.  I wanted to avoid the misconception (among 
> those reading along but not themselves using mpv) that _all_ mpv 
> subtitle handling was broken with Libav (it certainly is not), and 
> assumed from my own experience that those missing were less common than 
> the ones supported in both of the libraries.

Ok, that makes sense.

> > 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 bleeding edge 
> possible" then they'd never use our too boring stable release anyway.

You keep saying "bleeding edge", but 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?

> 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. 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).

> > 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). And it's already
clear that libav just doesn't provide enough security coverage, so how can you
justify leaving Debian stable users open to security vulnerabilities and bugs
by keeping libav in stable and not ffmpeg (or by providing security "support"
for libav and not ffmpeg)?

> > 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. And no just having packages using ffmpeg
in experimental is IMO not a solution (it's a PITA for both the maintainers and
the users).

> and I do not (or do and don't give a shit)?

Well, do you? You already made clear several times that your main concern is
this concept of "long-term maintanability" that no one else is apparently
sharing. That by itself implies that you rate what users have asked multiple
times over the years less important. But please, do correct me if I'm wrong,
because your arguments really don't make a whole lot of sense to me and I'm
starting to think that I got wrong everything that you've been saying.

Cheers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/attachments/20150518/7dffca4c/attachment.sig>