[FFmpeg-user] New options -preset and -tune for x264 encoding

[Baptiste Coudurier]

On 04/19/2011 03:51 PM, sean darcy wrote:
> Hi,
> 
> On 04/19/2011 06:09 PM, Baptiste Coudurier wrote:
>> Hi Sean,
>>
>> On 04/19/2011 03:05 PM, sean darcy wrote:
>>> On 04/19/2011 03:27 PM, Baptiste Coudurier wrote:
>>>> Hi,
>>>>
>>>> On 04/19/2011 08:56 AM, sean darcy wrote:
>>>>> On 04/16/2011 08:10 PM, Baptiste Coudurier wrote:
>>>>>> Hi everyone,
>>>>>>
>>>>>> Latest git has now added 2 new options for libx264 encoding:
>>>>>> -preset<preset>
>>>>>> -tune<tune>
>>>>>>
>>>>>> These options are directly mapped to internal tune and presets within
>>>>>> libx264. The old presets files have been removed, please use the new
>>>>>> options.
>>>>>>
>>>>>> Best regards.
>>>>>>
>>>>> How do these new presets work with 2 passes?
>>>>>
>>>>> For instance, I have a script that used:
>>>>>
>>>>> -pass 1 -vpre slow_firstpass
>>>>>
>>>>> -pass 2 -vpre slow
>>>>>
>>>>> I've changed it to:
>>>>>
>>>>> -pass 1 -preset slow
>>>>>
>>>>> -pass 2 -preset slow
>>>>>
>>>>> I used to get 100 fps on the 1st pass, now about 70. Is this to be
>>>>> expected? Or do I need to do something else on the 1st pass?
>>>>>
>>>>> Here's the full script:
>>>>>
>>>>> ffmpeg -i $INPUT -an -pass 1  -vcodec libx264 -level 30 -preset
>>>>> slow     \
>>>>>          -bufsize 10000000 -maxrate 10000000 -b 1200k -threads 0 -f
>>>>> mp4 -y
>>>>> /dev/null
>>>>> ffmpeg -i $INPUT -an -pass 2  -vcodec libx264 -level 30 -preset slow
>>>>> -timestamp now \
>>>>>          -bufsize 10000000 -maxrate 10000000 -b 1200k -threads 0
>>>>> $1.m4v
>>>>
>>>> fastfirstpass should be enabled by default.
>>>> Can you please double check that the parameters printed are the same ?
>>>>
>>>
>>> I've changed the script a little: slow ->  slower, and added -tune film.
>>> But on pass 1 there's no fastfirstpass.
>>
>> I don't understand what you mean. fastfirstpass is activated by default
>> like x264, if you want to disable it use: -fastfirstpass 0.
>>
> 
> 
> I misunderstood you. I thought you meant check ffmpeg parameters v. x264
> parameters. I now understand you meant to check if the parameters for
> ffmpeg were the same with -vpre and -preset. And the answer is yes -
> they were the same: I was using the identical script.

You have to compare this line:
[libx264 @ 0x10340b0] 264 - core 115 r1937+22 337ca0a - H.264/MPEG-4 AVC
codec - Copyleft 2003-2011 - http://www.videolan.org/x264.html -
options: cabac=1 ref=8 deblock=1:-1:-1 analyse=0x3:0x133 me=umh subme=9
psy=1 psy_rd=1.00:0.15 mixed_ref=1 me_range=16 chroma_me=1 trellis=2
8x8dct=1 cqm=0 deadzone=21,11 fast_pskip=1 chroma_qp_offset=-3 threads=9
sliced_threads=0 nr=0 decimate=1 interlaced=0 bluray_compat=0
constrained_intra=0 bframes=3 b_pyramid=2 b_adapt=2 b_bias=0 direct=3
weightb=1 open_gop=0 weightp=2 keyint=250 keyint_min=25 scenecut=40
intra_refresh=0 rc_lookahead=60 rc=abr mbtree=1 bitrate=1200 ratetol=1.0
qcomp=0.60 qpmin=0 qpmax=69 qpstep=4 vbv_maxrate=10000 vbv_bufsize=10000
nal_hrd=none ip_ratio=1.40 aq=1:1.00

between the 2 to make sure they match.

> I'm still puzzled by the new behavior. I'm not sure fastfirstpass is
> enabled, or maybe something else is slowing the first pass.  With ffmpeg
> and the old presets, as I remember it, pass 1 was 80-100 fps. pass 2 was
> 30-40 fps. So pass 1 was about twice as fast as pass 2.
> 
> With the new settings (bearing in mind I've gone from slow -> slower)
> pass 1 is 2 fps _slower_ than pass 2!

Can you please recheck with latest git ?

> frame=91961 fps= 37 q=-1.0 Lsize=       0kB time=3068.37 bitrate=
> 0.0kbits/s    /s
> 
> Pass 2:
> 
> frame=91961 fps= 39 q=-1.0 Lsize=  450992kB time=3068.37
> bitrate=1204.1kbits/s
> 
>>> BTW, notice "-level 30" on ffmpeg command line becomes Level 3.1 in
> x264.
>>
>> -level has not effect when -preset is used.
>>
> 
> I'm trying to encode so that it can be played on android/iphone. Some
> models require 3.0 (others are ok with 3.1). I assume some of this will
> be fixed with -profile, but even within a profile, the levels can be
> important. But I guess this is an x264 issue, not ffmpeg.

Of course it is important.
-level should now work, enjoy.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org