[x264-devel] Re: x264 benchmarking

[Loren Merritt]

On Sun, 8 Oct 2006, Christian Bienia wrote:

> Hi,
>
> I'm about to run a few benchmarks to analyze the performance of x264's
> parallel encoder. I have two questions, I'd appreciate if somebody could
> help me here:
>
> 1. How exactly is x264 parallelized? From my source code review, I
> understand that for each slice, no more than X264_SLICE_MAX threads are
> started (I assume a slice corresponds to a frame):

For each frame, no more than X264_SLICE_MAX threads are started. Each 
thread gets one slice.

>    h->param.i_threads = x264_clip3( h->param.i_threads, 1,
> X264_SLICE_MAX );
>    h->param.i_threads = X264_MIN( h->param.i_threads,
> (h->param.i_height + 15) >> (4 + h->param.b_interlaced) );
>
> Furthermore, the height of the slice (param.i_height) is an upper bound
> on the amount of parallelism each slice contains. x264 cannot encode
> multiple frames simultaneously if the amount of CPUs exceeds the upper
> bound. Could somebody confirm that?

Yes. And if you even approach that bound (by raising X264_SLICE_MAX), then 
the bottleneck will be the parts of the codec that aren't in a slice and 
thus get no parallelism at all.

> 2. How does x264 detect the number of frames in a YUV video? I have a
> case where x264 detects twice as many frames in the benchmark input I
> created than are actually available. I used ffmpeg to merge multiple PNG
> files to a YUV420P video, and now I'm wondering why the number of frames
> doubled.

number of frames = filesize / frame size.
If the number is wrong, then either your file isn't yuv420, or you told 
x264 the wrong frame size.

--Loren Merritt

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