[MPlayer-users] When will there be a new release?

[Attila Kinali]

Moin,

On Wed, 15 Oct 2008 14:01:46 +0400
Vladimir Mosgalin <mosgalin at VM10124.spb.edu> wrote:

>  On 2008.10.15 at 08:55:13 +0200, Attila Kinali wrote next:
> 
> > > Well certainly mplayer has a lot of problems with some mpeg ts streams,
> > > but mind you, a lot of players (at least under windows) have even more
> > > problems with them.. With mplayer, the worst you have to do is some
> > > fiddling with -mc and -fps options, in some other players it's
> > > unsolvable.
> > 
> > Have you send a bugreport?
> > Nico is usualy quite fast in fixing such issues.
> 
> I don't want to hurt your feelings,

Don't worry, you cannot hurt my feelings by critizing MPlayer or me.

> 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
usualy given, it is impossible to even guess what is going on. It would
be a little bit different if users would actualy follow the guidlines
in bugreports.html and submit a _full_ bugreport with where
_no_output_has_been_truncated_. But i gave up on teaching
users that we need their help to figure out what their problem
is, as nobody seemed to care and thought we are god like beings
who can read your mind and just know what kind of system you have
and what commands you typed.

> (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?
Beside, why don't you as a fellow user answer those questions if you
know the answer?

If a developer has to answer those simple questions, it's a total
waste of his time. And it really takes a lot of time to read -users
and answer even just the good bugreports.

> I have tons video files with all kinds of sync glitches, including some
> very strange ones (like mkv that loses sync depending on -correct-pts and
> -mc options, avi with sync problems solvable only with -demuxer lavf,
> desync in ogm files and so on). And "regular" sync glitches in avi and mpeg
> ts are very common, I don't even care when/if they'll ever get fixed,
> all I want is a way to convert such files so they won't be needing any
> options. I struggled with mencoder for some time, but (almost) never was
> able to create video which doesn't exhibit same problems.

I guess you hit the usual problem: user cannot convince a developer
that the problem is in the code and not in the user setup. And with
as many PEBCAK problems we have on this list, this doesn't surprise me.

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

> which works
> only for some of them; ffmpeg is better in this aspect. Users simply
> get used to this and stop submitting bugs and feature requests; for
> example, as much as I want to get proper multicore processing for h264
> decoding and video filters in mplayer, I won't bug developers about
> this, since I understand that simple words without any code won't help
> this issue at all. Same applies to other areas (e.g. high resolution
> audio, which hardly even works in mplayer and some other things).

Well, MPlayer developers are busy with a lot of things beside
MPlayer, and very few have time to develop for something they
can't even use. Same with all other projects i know.
So, if you want a certain feature, either figure out a way
to motivate developers to do it for you, or do it yourself.

To motivate developers, one way is to make sure they get that
the problem you have is important (aka many users have it) and
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
developer can use it, by e.g. donating some hardware (i've
done that my self a few times).

As i said already a few times, MPlayer is an OSS project,
it lives by the motivation of the developers to invest
their free time. It is not a product that wants to please
customers to buy it. 

			Attila Kinali

-- 
If you want to walk fast, walk alone.
If you want to walk far, walk together.
		-- African proverb