[MPlayer-dev-eng] [RFC] change lacv's MPEG-4 encoding options defaults

[Robert Swain]

Hello,
On 12/28/05, Guillaume Poirier wrote:
> Hi,
> Rich Felker wrote:
> > On Wed, Dec 28, 2005 at 02:48:45PM +0100, Guillaume Poirier wrote:
>
> > This topic has come up in the past and I've flamed in the past.

And it appears we disagree with you.

> Ok, now I understand why some (re-using your words, lame) MEncoder users
> gave up using lavc (besides all its great quality) and turned to other
> codecs.
>
> It's really sad that when people come with ideas to make the majority of
> people's life easier, it turns into flames.
> That sounds like eletism to me.
>
>
> > Defaults should always be all-off. If users are too lame to RTFM they
> > should not hope to get a good encode.

This kind of attitude alienates and scares off many potential
users/developers. It also doesn't produce a well-rounded product, in
my opinion.

> I'll try to picture what you're saying with an example:
> Let's say I buy a car. In my _real_ world, there's already an engine in
> it that's tune for 'normal' mileage/speed. If I want to get a muscle
> car, I'd work on the engine and tune it a bit. But in most cases, I just
> trust the engineers who build the car that they have tuned it "fairly
> well" and forget about it.
> In your ideal world, someone who buys a car should expect its engine to
> be completely untuned and should go through a big boring book to make it
> usable.
> I don't know about the others, but I prefer when I use an object that it
> behaves in a sane way for most of the things I'm likely to be doing with it.

In terms of the car analogy, I'd want the car that was reasonably well
tuned for most situations rather than having to tune it myself and so
would the average Joe. If the aim is to turn away all but those who
are willing to read lots and pester people on #mplayer or -users then
Rich's method is fine.

Personally I think that having a good speed/quality tradeoff while not
crippling compatibility, and being more userfriendly for the majority
of new users who just want to specify a bitrate, is a better route. It
wouldn't affect the overall functionality of the program for those who
know it well, but it would reduce the required information the average
user has to know/provide to produce quality outputs.

> For what it's worth, other codeds supported by MEncoder (XviD and x264
> at the very least) have defaults which are carefully chosen (by people
> who know what they are talking about) to provide a good speed/quality
> tradeoff, making them a _lot_ more user-friendly.
> Users love that.

The default number of b-frames for x264 is currently 0 while most
people use 2/3 as standard. Fair enough b-frames stored in avi aren't
perfect, but standalones can play the produced files, most if not all
software can play the produced files, so is this a real problem?

When I have some time I will look into 'fixing' the mp4 multiplexer
such that it can handle b-frames and everything correctly, then maybe
the default container for MPEG-4 codecs should be the defined
container.

> So the current situation is definitely not all off for all codecs.
> The excuse that some options can't be turned off is a very bad excuse as
> it can be added if needed.

Indeed.

> Well, since I don't want to interfere with you, I'll just drop the case.

I would be interested to hear what the rest of the developers and
maintainers think rather than dropping this prematurely after
receiving only one contributor's input.

> Guillaume

Rob