[x264-devel] Re: Scalability

[Loren Merritt]

On Wed, 28 Feb 2007, Alex Izvorski wrote:

> On Tue, 2007-02-27 at 15:10 -0500, Christian Bienia wrote:
>>
>> I encoded a short video with 512 frames in HDTV resolution (1920 x 1080
>> pixels). For the command line I used most switches which increase
>> encoding time, the exact command line was:
>>
>> x264 -B 1000 --qp 20 --partitions b8x8,i4x4 --bframes 3 --ref 5 --direct

You can't specify bitrate and qp at the same time. Whichever comes later
overrides the former.

>> auto --b-pyramid --b-rdo --weightb --bime --mixed-refs --no-fast-pskip
>> --me umh --subme 7 --analyse b8x8,i4x4 --threads ${NTHREADS} -o
>> output.264 input_1920x1080_512.y4m
>
> Thank you for some very interesting results.  Could you do a run with:
>
> x264 --bitrate=8000 --ref=1 --keyint=30 --scenecut=-1 --bframes=1
> --no-b-adapt --threads ${NTHREADS} -o output.264 input_1920x1080_512.y4m
>
> and with threads up to 256 or 512?  I suspect that will scale much
> better.  Thanks ;)

OK, I remembered a limiting factor: The motion estimation prepass
(for b-adapt, scenecut, and ratecontrol) is singlethreaded. It runs
concurrently with all the other threads, but only 1 thread is allocated to
the prepass.
If you disable those features (--qp 20 --no-b-adapt --scenecut -1) or if
you run a 2nd pass (which doesn't do the prepass again), it should scale
better.

I would guess that Alex's command would scale worse than the original, 
since Alex left in --bitrate (so a prepass is still needed), but increased 
the speed of all the other options (so the prepass takes a larger 
fraction of the total cpu-time).

--Loren Merritt

-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html