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

[Vladimir Mosgalin]

Hi Attila Kinali!

 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.

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

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

> > Unfortunately, mplayer and ffmpeg have a lot of problem areas where bug
> > submitting isn't worth it. Well, IMHO mplayer has major problems with bug
> > processing anyway - most bugs don't get solved unless some developer is
> > interested into fixing it right after bug report appears,
> 
> 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..

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

> 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? ;)

-- 

Vladimir