[MPlayer-dev-eng] deterministic builds

[D Richard Felker III]

On Wed, Dec 24, 2003 at 05:28:38AM +0000, Adam Rice wrote:
> Quoting D Richard Felker III (dalias at aerifal.cx):
> > No, we've made it very clear. There are two problems:
> > 
> > 1. MPlayer (G1)'s architecture does not like DVD menus. This probably
> >    won't change.
> > 2. The software (libdvdnav) does not provide a sufficiently general
> >    api to support the way MPlayer wants to handle input streams.
> 
> Sorry, I didn't mean to troll. I wasn't criticising mplayer, just making a
> joke. I have several DVDs with pictures than can only be accessed through the
> menus, and back when Ogle came out this was a big issue for me. Now our house
> has more DVD players than people, and I find my preferred player is mplayer
> simply because I can skip all the crap.

I expect there's another way to access the pics and you just didn't
find it.... :)

> > Yes. Right now I'm the one holding things up, because the new video
> > layer isn't complete and it's key to everything else...
> 
> Forgive my skepticism, but I've seen a lot of free software projects that have
> tried to do a G2 and died in the attempt. The version that everyone is using

G2 is incremental replacement. Before you dwell on your skepticism,
you should try it and see that it already works:

The demuxer layer has been replaced with something much better.

The filter chain has been replaced once (incrementally), but so far
the changes are insufficient for the sort of flexibility and
functionality we want, so I'm rewriting it again from scratch.

The video output system has been massively overhauled, elminating tons
of buggy overcomplicated code and code duplication. It still needs
various improvements, but the rest of the changes should be
incremental.

Everything related to audio still needs rewrite, but the old code is
usable for the time being.

By replacing components one at a time, we avoid the pitfall you
describe. Unfortunately video is a very _big_ component of a movie
player, so it's taking a while to perfect that one... :)

> stops being mantained, the next generation version develops behind closed
> doors at a mercurial pace with nothing to show for it but a couple of
> snapshots, and ultimately either someone comes along and forks the original,
> or its userbase is poached by a completely new project.

Forgive my arrogance (actually it's not about myself, but the other
MPlayer core devs)......I really don't see there being any chance that
anyone but the MPlayer developers will make a program that rivals
MPlayer G1 in the next five years. No one else knows or cares about
performance, A/V sync intricacies in the presence of broken file
formats, customizability, support for non-xv/x11 video devices, etc.

MPlayer G1 is _slightly_ unmaintained. But that's because there really
isn't much further for it to go. We add new filters, new codecs,
bugfixes, better docs, etc...but the really cool stuff (pvr
functionality, encoding with 100% perfect a/v sync, nut container
format, smart-framecopy starting at any frame (not just keyframes),
ability to function as a library, 50/60fps deinterlacing ala tvtime,
runtime indexbuilding, perfect inverse-telecine, dvd menus, direct
rendering with next-gen codecs, insane performance, runtime stream
selection, ......) really requires the overhaul that G2 entails.

> > Typing "make -n install" should always output a _very_ small number of
> > user-readable commands so the user can evaluate what will happen
> > before doing it!
> 
> In an ideal world, yes. I love it when I type "make install" and it does
> exactly two install commands. It's quick and transparent. But with modern
> projects that install dozens of libraries and hundreds of icons, it becomes
> increasingly unrealistic to expect that.

Such a project inherently sucks... It's not modern to do such horrible
things. It's the sign of stupid windows developers coming to *nix and
treating it like it's windows...

> >                                       it pollutes the CVS repository
> > with thousands of lines of patches, because autoconf _hard-codes_ line
> > numbers into the script for error reporting/logging!
> 
> Ooh, I hate that. If I wanted hard-coded line numbers I'd program in BASIC!

ROTFL! :)

Rich