[MPlayer-users] Some philosophical thoughts (WAS: When will there be a new release?)

[Attila Kinali]

Salve Vladimir,

On Fri, 17 Oct 2008 21:50:17 +0400
Vladimir Mosgalin <mosgalin at VM10124.spb.edu> wrote:

>  On 2008.10.17 at 18:47:39 +0200, Attila Kinali wrote next:
> 
> > > but a/v sync problems is one big
> > > areas where are I stopped submitting bugs a long time ago, since usually
> > > no solution is offered
> > 
> > Because it's the single most difficult field of problems to fix.
> > A/V sync problems can stem from anything, sound card bugs, sound
> > card driver bugs, video card driver bugs, too slow cpu, broken
> > files in various forms and bugs in MPlayer. And with the information
> 
> Hmm.. I experienced some of the things you're talking about, like sound
> card and driver bugs in the past, but I'm pretty sure nowadays most sync
> problems come from broken files, and some from bugs in mplayer.

Hmm, yes, most common issue are broken files these days,
after that still comes broken sound card drivers
(alsa is quite good in providing broken stuff), then come
misconfiguration of MPlayer that it uses too much cpu, too
slow machines or other processes that eat up i/o or cpu
and after that come real MPlayer bugs.

> > > (even for the simplest question like "if I found
> > > correct -mc/-fps/etc options that keep sync, how do I remux file so that
> > > resulting one can be played in sync without using any special options").
> > 
> > Uhm.. because this question is so simple that by looking into the
> > documentation for a few minutes you could have figured it out yourself?
> 
> Yes, though unfortunately I still don't have answer for this question.

Oh.. ok... that explains a few things.

> > Beside, why don't you as a fellow user answer those questions if you
> > know the answer?
> 
> Having invested quite a time into solving a/v sync problems in varions
> situations with mplayer and mencoder, I always try to help people on
> this when I notice question/have time..

Good to hear.

> > This is normal with all of the projects i know. If you cannot
> > get a developer interested in fixing a bug, you either have to
> > fix it yourself or will never get it fixed at all. Sounds logical,
> > doesn't it?
> 
> Yes. Unfortunately, mplayer's bug reporting works much worse than with
> some other projects. Many reasons for that.. In small projects there are
> people interested in "making project better" and "fixing any bug, as
> long as it's annoying enough", but mplayer is big and complex and no
> one knows everything there in detail enough for fixing obscure bugs;
> forgive me if I'm wrong, but it looks to me that mplayer hasn't got a
> team of lead developers who can take on any bug in any of its modules if
> the person maintaining this module is absent or can't fix the bug. Lack
> of good, popular among users and developers and useful bug tracking
> system (yes, I know that there are some), meaning that even most
> detailed bugreport is lost if the only developer who can fix that
> wasn't reading list for some time. And, of course, interaction with
> broken files, hardware and environment, which is a source of many bugs..

You could easily improve MPlayers bug tracking capabilities, as 
i have done it for a few years. Read the Mails here, check which
issues are real bugs, which are problems from broken files and
which are just PEBCAK. Enter the first classes of issues into
the bugtracker and forward them to the developers.
If you feel advantourus, you could try to track the bug down
to the file or even function it comes from (that's easier
than it sounds, all you need is the ability to read C code).

And from time to time you should remind the developers, that 
this or that bug is still outstanding and should be fixed.

> > To motivate developers, one way is to make sure they get that
> > the problem you have is important (aka many users have it) and
> 
> It's hard. Besides, I think that mplayer loses its users (mainly because
> unlike 5 years ago, now there are other usable media players based on
> ffmpeg, less obscure than mplayer).

Really? The only worth noting are vlc and xine, and both
were our fiercy competitors for way more than 5 years.
Or did others pop up that i didnt notice?

> Well, mplayer is still bleeding age
> of linux players in terms of overall features and performance, and I
> guess there'll be a lot of users as long as it stays this way. However,
> simply because of this niche mplayers' users and developers will meet
> more uncommon and strange bugs and feature requests than users and
> developers of some other media players; there's simply no way around it.

Well if that means that MPlayer will die, so be it.

MPlayer is now about 8 years old (nearly 9 if you count the "non-public"
development too), it has seen quite a fiercy and judging from
experience, i'd say that MPlayer will be still around and actively
maintained in another 8-9 years.

> > that it is really a problem of MPlayer and not in the user setup
> > or a problem of the file. Or for new features, make sure the
> 
> Arhg, "problem of the file" again. Can "the problem is in the file, but
> player XYZ somehow managed to work around it" be considered a problem of
> mplayer? ;)

Only if you consider "patches welcome" a valid answer ;-)


				Attila Kinali

-- 
The true CS students do not need to know how to program.
They learn how to abstract the process of programming to
the point of making programmers obsolete.
		-- Jabber in #holo