[FFmpeg-devel] h264 multithreading, chapter 2
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
> - 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).
More information about the ffmpeg-devel