[MPlayer-dev-eng] [PATCH] x264 fast first pass

[Robert Swain]

----- Original Message ----- 
From: "Jeff Clagg" <snacky at ikaruga.co.uk>
To: <mplayer-dev-eng at mplayerhq.hu>
Sent: Sunday, July 10, 2005 1:26 AM
Subject: Re: [MPlayer-dev-eng] [PATCH] x264 fast first pass

^--- Yes, I do use Outlook Express. :)

> On Sat, Jul 09, 2005 at 06:53:13PM +0100, Robert Swain wrote:
>> Hello all,
>>
>> After a request was made I have written a small patch that adds a fast
>> first pass feature to x264 in mencoder. The VFW version of x264 has been
>> using a conservative fast first pass for a long while and I have tested a
>> second set of reduced complexity settings myself which seem to give good
>> results. As such specifying fastfirstpass=<0-2> in the x264encopts allows
>> for the following settings:
>
> First, I think that for consistency with the options in mplayer's other
> encoding libs (lavc, xvid), it would be a good idea to name the option
> "turbo" instead of "fastfirstpass."

Turbo in XviD should mean something different (a fast qpel technique) and 
_not_ fast first pass. I decided to name it 'fastfirstpass' because that is 
what it is. I dislike the naming 'turbo' as it isn't very descriptive. If 
people, including yourself, continue to insist it be called 'turbo' I will 
alter it.

>> 0 - disabled (same as omission)
>
> Since this is the default, and since firstpass=0 has absolutely no
> effect, I suggest not documenting it at all, and only telling users
> about firstpass=[12].

OK. I've changed it to "fastfirstpass=<1-2>"

>> 1 - reduced settings in the same fashion as the VFW fast first pass 
>> (number
>> of references, subq and reduction of subpartition types; cf the patch or
>> x264 source for further details)
>> 2 - reduced settings ( frame_ref = 1, subq = 1, no sub-partitions, no
>> 8x8dct, and diamond ME search)
>>
>> I also tried to update the documentation but I'm unfamiliar with the
>> notation used for the man pages.
>
> Try "man ./mplayer.1" to test the rendering of your local copy. Your
> patch messes up indentation (more on this below).

OK, thanks. I was wondering how to check it. I usually just read the html 
off the web page.

>> +reduce subq, frame_ref and disable some inter macroblock partition 
>> analysis
>> +modes
>
> Change "frame_ref" to "frameref"

I originally typed it as 'frameref' but changed it to 'frame_ref' to be 
consistent with the option name. I will revert them.

>> +reduce subq and frame_ref to 1, use a diamond ME search, disable all
>> +sub-partition analysis modes and don't use the 8x8 DCT
>
> Again, frame_ref => frameref. And isn't 8x8dct a sub-partition type? So
> no need to mention it specially. (also, contractions like "don't" are
> considered to be against the mplayer man page style rules iirc)

8x8dct is an 8x8 transform that is used adaptively in high profile alongside 
the 4x4 transform used in main profile. i8x8 is the corresponding 
sub-partition type. I will change the "don't" to "do not". I generally 
consider the latter to sound more stern than the former, probably because 
it's more formal.

> Finally, add a line like ".PD 1" at the bottom of your manpage changes;
> the way you have it now, all indentation below your new option is broken.

OK. I see that the indentation is broken below the fast first pass option 
but adding .PD 1 to the end of my section doesn't appear to fix it. As you 
said on IRC, .REss does work. Is this a reasonable way to solve the 
indentation problem?

Please find the updated patch attached. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer.x264.fastfirst.1.diff
Type: application/octet-stream
Size: 4640 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20050710/7ada5bc9/attachment.obj>