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
signature.asc
Description: signature
_______________________________________________ pkg-multimedia-maintainers mailing list pkg-multimedia-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-multimedia-maintainers