[MEncoder-users] Re: Re: Tutorial?

[Jeff Clagg]

On Fri, Oct 06, 2006 at 10:55:40PM +0000, Ilya Zakharevich wrote:

> > In a nutshell, when you specify pass=1, xvid ignores any option
> > setting either bitrate or quantizer. But, so what?
> 
> So that I can change my mind, and specify different bitrate on pass=2
> command line.

Huh? I'm not even sure what you're trying to say here. I suspect your
statement is based on a misunderstanding.

> > As for exactly what turbo changes, it makes the pass faster, and that's
> > all most users want to know.
> 
> Please do not vouch for "most users".  Thanks.

It's true, whether you agree or not. Unless you presume to vouch for
most users, yourself.

> > I'm sure Guillaume Poirier could tell you
> > EXACTLY what effects turbo has, and I also suspect that upon seeing the
> > answer, you'd realize why few people care.
> 
> Let be assured: people care.  They just are not brave enough to ask.

Bravery's got nothing to do with it. Flooding users with trivial details
takes second priority to giving them the information they're actually
looking for.

> > >      1b) bitrate: it is not clear whether it sets VIDEO BITRATE and
> > > 	 VIDEO SIZE, or overall bitrate and overall size;
> 
> > I think it's clear.
> 
> I do not.  So, should we split the loot 50/50?  ;-)
> > How is it unclear?
> 
> Could you please explain WHICH of two answers is "clear", and how one
> can deduce it looking in documentation.  I do not know even after
> running half a dozen of tests.

As the docs say, positive number sets target bitrate, negative number
sets target output file size (which is the same as setting bitrate, only
you make the computer do slightly more arithmetic for you). I probably
shouldn't have to say this, but if you have pass=1 in your xvidencopts,
you will not observe any difference.

> > >      1c) interlacing option: I found no clue what should be the
> > > 	 relationship of this to, e.g., -vf pullback;
> 
> > I'm guessing you don't know why the option is used in the first place.
> 
> Quite probable.  If you know, care to explain how one can deduce it
> from the docs?

You have to know what you want, before you can put things into action. I
again suggest reading the long mplayer html guide I linked to.

> 
> Rechecking my logs...  Sorry, I meant pullup (of course!).
> 
> > > Pos:3299.2s  79108f (-692%)  7.33fps Trem:   0min   0mb  A-V:0.009 [3684:159]
> 
> > Trem=time remaining. 218mb=current estimate of output filesize. 3684:159
> > is cumulative average output video:audio bitrate.
> 
> Trem is not time remaining, likewise for 218mb.  It has nothing to do
> with actual time.  E.g., here is (the only case when in my experince
> mencoder finished without segfaulting):

mplayer is not psychic. trem is an estimate. Filesize estimate does not
take unforseen contingencies into account.

> > How about http://www.mplayerhq.hu/DOCS/HTML/en/index.html . It addresses
> > most of the stuff you mention.
> 
> You mean a document whose TOC takes 20 screen pages?  Are you serious?

This is a funny comment for you to make, after arguing that the docs
should teach newbies everything they need to know about video
processing, and that the docs should also contain trivial details about
xvid's 2pass and turbo implementations.

> > And surely you don't argue that the man page should include something
> > like this.
> 
> Surely I did, did not I?

Apparently so. And then you complained that it is way too long.

Which is it?