[x264-devel] Re: parallising the encoder

[Loren Merritt]

On Wed, 6 Apr 2005, Michael S. Kazmier wrote:

>> Thread 0 encodes row 0 (mb 0-21).
>> When thead 0 finishes mb 1, start thread 1 encoding row 1 (mb 22-43),
>> making sure that it stays >= 2 mbs behind all the way.
>> When thread 0 finishes row 0, start it on row 2 (mb 44-65).
>> When thread 1 finished row 1 or thread 0 finishes mb 45 (whichever is
>> later), thread 1 starts row 3.
>
> From a software development scalability view, I believe this approach would
> produce the most linear scalability for additional threads.  You would want
> a single "control" thread handle the scheduling of each worker thread that
> is not encoding any of the stream itself.
>
> This architecture would also allow for portability of x264 to other
> platforms a bit easier.  For example, in most multi-DSP based encoders you
> have a host processor or and FPGA with a MIPS core - this would run the
> master control thread and linux, and then you have multiple DSPs, each of
> which could be encoding a line of the video.  This would scale very nicely -
> assuming you have a shared memory architecture where each processor / dsp
> could access the info from previous macroblocks.

For porting to DSP, yes. For scaling to lots of threads, no.
The approach of dividing the whole video in half temporally would work 
for even hundreds of threads, and they don't have to all be on the same 
computer.
No need for extra keyframes if you have a little overlap or run a 
scenecut detector in advance. Also, I originally thought it hurt 
ratecontrol, but you can do overflow compensation just like normal as 
long as the encoders can communicate at least once every few frames.
The only problem is that it needs significant application support. I don't 
forsee it in ffmpeg, only x264cli and elder.

--Loren Merritt

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