[FFmpeg-devel] h264 multithreading, chapter 2

Thorsten Jordan tjordan
Wed Sep 26 09:37:27 CEST 2007

Mathieu Monnier schrieb:
>> The attach patch gives ~20-30% speedup on single sliced CABAC content.
> That's actually better than I would have thought.
>> But rather before I spend any more time on it I'd like to know
>> if people think it is worth finishing.
> Well, as already discussed previously :
>   - slice based parallelism depends on the video, so will not be always 
> possible. Furthermore, it scales as much as the encoder was scaled, so 
> though it's an easy solution, it's not a pretty one
well but i can tell that it works pretty well, at least for all german
HDTV broadcasts i have tested. And it gives a nearly 1:1 balancing over
the cores, that is really hard to beat by other methods, except
frame-parallel decoding.

>   - cabac / reconstruction parallelism : relatively good speed up, 
> though it will depends on the bitrate of the video ( low bitrate -> bad 
> scaling, very high bitrates -> bad scaling too ), and no scaling over 2 
> CPUs. There again, not necessarily pretty, but effective. More effective 
> imho than slice based, and sufficient for decoding anything up to 
> 1080i30 40 Mbit/sec on a C2D, I would say.
i have doubts here, with deblocking the decoding is really cpu-demanding
with these resolutions. If you shave off 20-30% "only", it wouldn't be
enough. One core would be maxed out, the other at 30%. Not good...

>   - frame based, which I think should be the "best" method : a priori 
> very scalable ( if x264's threading efficiency is achieved ), no 
> constraint on the video except for vertical downward motion vectors, 
> but, alas, not tested, so scalability is hypothetical.
Has the tiny disadvantage that decoding is delayed up to N-1 frames when
N frames are decoded in parallel, but that shouldn't be a problem. Can
use free cpu time of any core better than slice-parallel decoding (with
N = 2 * #cores or so).

Greetings, Thorsten

More information about the ffmpeg-devel mailing list