[MEncoder-users] Re: Tutorial?

[Jeff Clagg]

On Fri, Oct 06, 2006 at 09:38:08AM +0000, Ilya Zakharevich wrote:

The short answer is that a lot of your (seemingly random) questions are
not about mplayer per se, they're about video processing. MPlayer
doesn't hold your hand when it comes to this. Do you expect Photoshop to
make you a good artist?

>   0) It is unreadable; but this is not easy to fix, so let's delay this ;-)

What exactly is unreadable about it? That it's so long?

>   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. In a nutshell, when
you specify pass=1, xvid ignores any option setting either bitrate or
quantizer. But, so what? You usually do not use the output video
generated by the first pass.

As for exactly what turbo changes, it makes the pass faster, and that's
all most users want to know. 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.

>      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. How is it unclear?

>      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.
There is no -vf pullback.

>   2) What mencode is outputing on TTY is not documented.
> 
>      2a) E.g., I see something like:
> 
> Opening video decoder: [mpegpes] MPEG 1/2 Video passthrough
> VDec: vo config request - 720 x 480 (preferred colorspace: Mpeg PES)
> Could not find matching colorspace - retrying with -vf scale...
> Opening video filter: [scale]
> The selected video_out device is incompatible with this codec.
> Try adding the scale filter, e.g. -vf spp,scale instead of -vf spp.
> VDecoder init failed :(
> 
> 	 How should I know whether it is an error, or just a normal
> 	 process of enumeration of possible input options?  Especially
> 	 confusing if I HAVE -vf scale specified...

This last paragraph is a legitimate complaint. MPlayer is way, way too
verbose, and new users cannot distinguish warnings from errors from
pointless messages. It's annoying.

The GOOD thing about this verbosity is that it sometimes improves the
quality of bugreports.

>      2b) E.g., I see something like:
> 
> Pos:3299.0s  79104f (692%)  7.33fps Trem:-153min 218mb  A-V:0.003 [3684:159]
> Pos:3299.1s  79105f (692%)  7.33fps Trem:-153min 218mb  A-V:0.003 [3684:159]
> Pos:3299.1s  79106f (-692%)  7.33fps Trem:   0min   0mb  A-V:0.005 [3684:159]
> Pos:3299.2s  79107f (-692%)  7.33fps Trem:   0min   0mb  A-V:0.006 [3684:159]
> Pos:3299.2s  79108f (-692%)  7.33fps Trem:   0min   0mb  A-V:0.009 [3684:159]
>          Nothing is documented.  OK, I can guess what the 1st, 2nd and
>          4th fields mean.  I can kinda guess the semantic of A-V
>          (although the details of what is done to establish
>          video-audio sync are not discussed anywhere).  But what is
>          that 692%?  And Trem?  And 218mb? And [3684:159]?

Trem=time remaining. 218mb=current estimate of output filesize. 3684:159
is cumulative average output video:audio bitrate.

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

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

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

And surely you don't argue that the man page should include something
like this. It's long enough already.