[MEncoder-users] Re: Re: Tutorial?

[Ilya Zakharevich]

[A complimentary Cc of this posting was NOT [per weedlist] sent to
Jeff Clagg 
<mencoder-users at mplayerhq.hu>], who wrote in article <20061006191523.GA5606 at ikaruga.co.uk>:
> >   1) xvidencopts (do not know whether discussing them belongs here, or
> >      better be delegated to something XVID specific)
> > 
> >      1a) 2pass processing: absolutely nothing is said about WHICH
> > 	 options are ignored with pass=1, and which with pass=1:turbo;
> > 	 thus one does not know which one could be changed between
> > 	 pass1 and pass2;
> 
> It's true the man page doesn't go into details about how xvid's 2pass
> works, but for normal usage, you don't need to know.

Well, *I* need to know this.  I can't convince you that I'm a typical
user, but in my experience, if I stumble somewhere, then all my
friends will stumble at the same place; so, at least, I'm not *alone* ;-).

> 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.

> 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.

> 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.

> >      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.

> >      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?

> There is no -vf pullback.

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):

  Average fps is about 6, length of video is about 6900sec.  Near the
  start of encoding Trem is about 55min.  %done goes to zero about
  480sec into the video; estimate of size at this time is about 83mb
  (actual size about 1300MB).

> The -692% thing is pretty interesting, I suspect you're encoding a
> growing file or something. If so, mplayer is not psychic...

The file is on DVD-Video.

> >   3) I got an AVI file which plays in Mplayer, but DivX will play it
> >      only up to 1h25m out of 1h52m (total size about 1.3GiB).  There
> >      are some vague hints scattered in documentation at shortcomings
> >      of AVI format, and that sometimes only Mplayer will be able to
> >      read the bastardized AVI file.  Do I get any feedback on this
> >      from mencoder?

> Maybe there should be some mention of -noodml or something.

Good, since this would fix at least one of the problems I see:  I redid

  -oac copy -ovc copy -noodml

and the file now plays in DivX fine.  It still does not play in Media
Player (I got the latest Gordian knot installed, and latest XviD
installed on top of this)...

> ODML files are not particularly bastardized and mplayer cannot
> directly fix divx player's shortcomings. Workaround: don't use
> players that can't handle large avi's, or, make a smaller file.

Please do not joke that bad.  It is mencoder which had chosen to
generate a file which is not playable almost anywhere just "because it
is 1GB in length or more".  Why this number, BTW?  I think the default
should be at least much closer to 2GB, and best user-settable.

> >   4) I must join the OP that there is no discussion of overall
> >      architecture of the process of Video Conversion.

> 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?

Maybe it contains this information somewhere; but how would I find it?

> And surely you don't argue that the man page should include something
> like this.

Surely I did, did not I?

> It's long enough already.

There is more to readability than length.

Hope this helps,
Ilya