[XviD-devel] [FRONTEND UPDATE] mplayer modules.

[Edouard Gomez]

Guillaume POIRIER (guigui-nospam at laposte.net) wrote:
> I saw that "4mv" was removed (which I somewhat figured out as mencoder
> refused to transcode a stream if that 0.9.x option was there)... Is that
> just a omission, or is this option actually out with XviD-1.0.x?
> ... or maybe it is always active?

mencoder support of xvidcore 0.9.0 is clearly to geeky
oriented, moreover all the terminology between transcode,
mencoder and win32 worlds was different.

When i prepared xvid 1.0 transition for mencoder and
transcode, i tried to stick to win32 options because of two
reasons:
 - even if they're still a bit power user oriented, at least
   that doesn't go so far as 4mv (what user may ever know what
   this option really does ?!). This was a first step toward
   user friendlynes
 - that way linux app users could still use the guides
   published by the numerous win32 user base.

So what happenned then... transcode did accept all the
terminology change, after all, that was a major change, so
users were to learn new option (for their own good).

mplayers' maintainers refused the changes, because, according
to their opinions, there is no point in changing codec
options. I refused stating that this was a major rewrite of
the module, not a simple -- common let's port this to xvid
1.0. So in the end, my module has been accepted minus lot of
options renamed to their old equivalent.

Why all this history (no rant involved) ?

That explains why, today, you have a ve_xvid4.c module sharing
lot of options names with the old ve_xvid.c though their
behavior differs slightly. Same remark concerning the codec's
default, some maintainers complained that xvid 1.0 was too
slow and they wanted it to be as fast as xvidcore 0.9.x...
they didn't find any better solution than returning to 0.9.x
codec default values... that is disabling almost all new
features in xvid 1.0 except bframes.

So now i understand your position, you want to ddoucment all
this, but you're left with a mess.

To answer your very specific question:
4mv was depreciated, and all is taken care by the me_quality
option, me_quality>4, 4mv is activated.

If at anytime you need precise information about what option
does what, refer to the dispatch_settings() function. It
embends the entire logic hidden behind the options.

> I also saw that the option that allowed manually raise the quantizers
> for credits (at least with a 0.9.x build) was out too... Is it also not
> supported by XviD-1.0.x too ?
> I personally find this kind of option quite convenient.

There is no strict equivalent, but a better solution in xvid
1.x. That's called zones.

What kept me from offering a user interface to this feature on
GNU/linux apps, is that it's not easy at all expressing a zone
as flat text. Its parsing can become PITA quite fast.

What's a zone:
 - a zone is an open frame range (range of type [start..[) for
   which you can set a specific quantizer and disable/enable some
   features.

Why is it so difficult to describe a zone with mencoder.
 - Let's suppose you want to do that through cmd line options,
   then old config system (the one that was operational when i
   started writing the module) didn't allowed that because it
   supported only certain type of data: float, string, integr,
   flag and so on. mplayer switched to a better config system,
   allowing function hooking for parameters, that can help.
   But transcode still uses the fixed model, so it's very
   tricky, and i don't want to have two completely different
   zone description "language"

So... the time going, i just forgot about this feature.

> Please consider not this mail as a user request, but as someone who
> wants to bless mencoder users with the best XviD support I can afford.

All feedback is good, even if sometimes it's negative.

> Also, if you want a user to test some new XviD features with mencoder,
> I'm your man! ;-)

Cheers

-- 
Edouard Gomez