[x264-devel] Re: parallising the encoder

Tuukka Toivonen tuukkat at ee.oulu.fi
Wed Apr 6 19:17:44 CEST 2005


On Wed, 6 Apr 2005, Loren Merritt wrote:

> You probably don't want to parallelize MBs. The extra predictions are no 
> problem (just encode each line 2 MBs behind the previous), but it would mean 
> you have to save residual coefficients and such, and delay bitstream writing.

Hmm... i think i don't follow you. So, suppose one would have two threads 
and frames with, say, 22x18 MBs. Which MBs would be encoded by which 
thread?

> And delayed bitstream writing could hurt RD, whenever that gets finished. And

I implemented delayed bitstream writing into x264 a while ago, though for 
other purposes =)

> with different MBs taking much different amounts of time, I would imagine 
> syncing the lines would reduce the benefits of parallelizing.

Hmm... do you mean that the parallelization would be at MB line level then?

> With slices you sacrifice about 1% bitrate for much simpler code.

I consider 1% quite much.

> The 3rd possibility is to parallelize at the frame level. But that's back to 
> complex code, since it requires duplicating large parts of the encoder context 
> and keeping track of multiple DPBs and stuff.

Well, the simplest way is at frame level, divide the sequence in half at 
the middle of its length and encode both halves completely independently... 
very easy (just launch two encoders) fast (both encoders completely 
independent) and good quality (just needs one extra intra slice in the 
middle).

Obviously won't be practical for real-time encoding, but I still hope 
ffmpeg/x264 would have it :)

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



More information about the x264-devel mailing list