[MPlayer-dev-eng] [PATCH] fix seeking in demux_lavf

Michael Niedermayer michaelni at gmx.at
Tue Aug 12 05:17:36 CEST 2008


On Mon, Aug 11, 2008 at 01:48:24AM +0200, Aurelien Jacobs wrote:
> Reimar Doeffinger wrote:
> 
> > On Wed, Aug 06, 2008 at 11:44:28PM +0200, Aurelien Jacobs wrote:
> > > So here is a better patch that just reset stream cache to it's
> > > previous state after a stream_seek() failure, thus making
> > > mp_seek meet url_fseek() expectation.
> > 
> > It might be even better to even improve stream_seek to match the expectations
> > instead,
> 
> I've thought about this too. But this would be quite hard to do such
> a major change to stream_seek, testing all the possible corner case,
> without breaking anything.
> So I think it's not worth.
> 
> > but this patch is good enough for me (though I do not maintain
> > demux_lavf).
> 
> Michael ? I will commit this in a few days if I see no complaint.

you can commit it as soon as you cast your vote to anyone you like to
become mplayer leader.

Its not as if i would want some kind of monarchy, its just that half of
the new mails here where about a bunch of monkeys fighting about a piece of a
7 year old banana while they had plenty of fresh ones.
Why exactly did diego fight so fiercely to remove 1 harmless line from
a file maintained by ivan? Have we run out of dirty code that needs to
be cleaned up And that can be cleaned up easily in a non provocative way?
Must be so ...
And the other side, is this line that is apparently needed for xf86 4.1.0
that important. Or more correctly is xf86 4.1.0 important? Is anyone still
using it? Isnt it full of secholes? Does vo_xvmc.c compile under it? does
it work?
Ahh and then the irronic "the only way to win is not to play" quote how
fitting in such a flameWAR ;)
If we had a leader, he could have made a clear decission and shortened
this discussion, not that i think it didnt had some entertainment value ;)
Its even rather irrelevant what decission would have been taken as neither
way really seems to have any practically relevant disadvantages. Neither the
removal nor keeping this line would affect more than VERY few users.

Besides this irrelevant line of code, about which iam not concerned at all
there is the issue with maintainers being ignored that is something iam
rather concerned about.
Because in the absence of maintainers having authority (as happened here),
in the absense of a leader and in the absence of democratic authority (there
was no vote and no clear consensus). The only thing left is the faith of
the one commiting. And a project with more than 2 or 3 developers can likely
not work based on such foundation. Especially when the developers follow
very different religions, like "never drop a feature" vs. "remove as many
hacks as possible"

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080812/ebbbeece/attachment.pgp>


More information about the MPlayer-dev-eng mailing list