[MPlayer-dev-eng] 3 pass encoding syntax poll

[D Richard Felker III]

On Wed, Feb 09, 2005 at 10:43:39AM +0100, Danny wrote:
> Loren Merritt ha scritto:
> 
> >On Sat, 5 Feb 2005, Loren Merritt wrote:
> >
> >>When I came up with the current syntax for N-pass encoding with lavc 
> >>or x264 (pass=1 on the first pass, pass=3 on all subsequent), I 
> >>though it was the most logic method: N-pass simply enables both 1st 
> >>pass stats file and 2nd pass ratecontrol, so I used 3 == 1|2.
> >>However, I have seen many confused users, so apparently this isn't so 
> >>intuitive, and nobody reads the section in the manpage describing its 
> >>usage.
> >>So I have decided to change the syntax and/or behavior of multipass 
> >>encoding. But since I was wrong the first time, I will now ask 
> >>opinions before choosing a replacement.
> >>
> >>* Always perform N-pass encoding. (It is, after all, identical to 2-pass
> >> if you run only one Nth pass.)
> >>
> >>Additionally (especially in the last option), I think it would be 
> >>beneficial to use separate statsfiles for each pass, so that 
> >>cancelling an encode doesn't erase the results of previous passes. 
> >>This would require changing the -passlogfile option somehow, since 
> >>there would be multiple files to specify. How best to go about this?
> >
> >
> >OK, unless there are arguments to the contrary, I will now implement:
> >Always use N-pass encoding instead of 2-pass.
> >The statsfilenames will be derived from the value of -passlogfile as:
> >If the filename contains "%i", replace it with the pass number, else 
> >append the pass number.
> >
> >This allows 2-pass encoding with no changes from the current syntax, 
> >and allows N-pass encoding by simply incrementing vpass.
> >
> >
> 
>    What about use a temporary file to store the current log and copy it 
> on the real logfile only at the end of the encoding ?
> 
>    In this way if you stop an encode session you have the (complete) 
> previous log and you can start another encode, maybe with differents 
> parameters.
> 
>    This let you usa as many passes as you want without use a lot of log 
> file.
> 
>     Maybe another solution is to keep the log file in memory (if you 
> have already a log file you know how many frames you encode). 

No, these are all bad! I like to read the log file with tail -f or
less while it's encoding to watch the quantizers and make sure they
look ok. This would be possible with a temp file, but it's a pain and
temp files always lead to annoying misfeatures.

Please, can we just leave this how it is? Encoding is a complicated
process inherently, and if people can't be bothered to learn a little
bit before doing it, they're GUARANTEED to make crappy encodes.

Rich