[MPlayer-dev-eng] Re: [PATCH] synch to new x264 revision

Guillaume POIRIER guillaume.poirier at ifsic.univ-rennes1.fr
Mon Sep 27 11:47:52 CEST 2004


Hi,
Le sam 25/09/2004 à 00:49, Edouard Gomez a écrit :
> Dans gmane.comp.video.mplayer.devel, vous avez écrit :
> >> All codecs are by default fast, even if their maintainers dislike it.
> >> For example, I know that XviD devs would prefer some "basic" quality
> >> optimization on per default.
> >
> > I haven't seen that rule written in stone anywhere, I doubt patches
> > for it would be rejected.
> 
> They've been rejected, so now we end up with mencoder users having to
> tune xvid module options to catch up with the quality provided by
> default values on the win32 frontend or even the transcode module.

Are the defaults the one provided by xvid4conf?


> Same goes for lot of little things i had to discard from the xvid4
> module before he got accepted by mplayers' commiters, where most
> refusing reasons were just "we have that behavior with xvid 0.9, so xvid
> 1.0 should behave the same". To me that was clearly saying something
> like: "guy you worked well on xvid 1.0, but let's face it, our users
> will have no benefit from all the new stuff because we choose to stall
> default behavior" *sigh*.

Well, I hope people won't hate me here for saying that, but since I _DO_
care to have a good XviD support in mencoder, I really plan to weight as
much as possible to improve collaboration with the XviD team.
Let's bury that unfortunate past and move on!
And, if necessary, I can work on the front-end (but I'd prefer not to)
If few MPlayer developers use XviD, and don't care much for what happens
on that field, I'd really like if Edouard Gomez could to see his work
included "right away", after a quick review.
I really think we should trust Edouard's judgment on XviD defaults, as I
don't really see any reason why he'd write something that would do any
harm to MEncoder. Plus, he's more than likely to offer the best
front-end you can imagine, given his expertise on XviD internals.


> I just decided to continue improving the module separately so i'm not
> bounded by mplayer commit rules. If someonee wants to merge changes
> into mplayer, then he can do so. That's the beauty of GPL.

That a bummer to have 2 separate front-ends. It the one you provide on
your website the one you're talking about?
As you know, I sent a patch to this ML some days ago, but haven't had
much feedback since then.
That's probably because it's okay, I guess...

Regards,
Guillaume




More information about the MPlayer-dev-eng mailing list