[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