[XviD-devel] Multithreaded Motion Search - looking for benchmarker

Pascal Massimino skal at planet-d.net
Mon Aug 1 22:35:38 CEST 2005


	Hello Bryan,

On Wed, 2005-07-27 at 22:42, Bryan Mayland wrote:
> While I was lying in bed the other night thinking about how much time it 
> takes to encode my 720x480 MPEG2 television recordings in 2-pass XViD, I 
> considered a processor upgrade.  

	hey, hope it was just bad dream ;)

> The algorithm creates a second thread to help with the ME, although 
> there is no reason this could not be increased further.  An array 
> [mb_width x mb_height] of "completed blocks" is initialized to 0, and an 
> array of "available blocks" is initialized to point to the block at 
> (0,0). Once the thread has completed the search, the block is flagged as 
> completed and then the algorithm checks to see if the block to the right 
> can be searched (which is true if block2's top right neighbor is 
> complete), and if the block to the bottom left can be searched (which is 
> true if block3's left neighbor is complete).  These blocks are added to 
> the "available" list.  If there are blocks on the list, the thread takes 
> one and starts again. 

	This seems to me like a very good idea. Something
	equivalent is possible on the decoder side, too.

	Did you consider using a cascading condition/signal
	instead of using the array? Every row signals it is
	finished doing its current MB to the one underneath, 
	which is possibly blocked at its condition (but
	fortunately not waiting for long).

	I would warmly recommend using the pthread API for that.
	There are a lot of equivalent to it under Win32.
	I could quickly crank up one if you want...

	very nice!
-Skal

(ps: @Tom Jacobs: unfortunately your attachment didn't make
it to the ML. Do you have a replacement URL??)






More information about the XviD-devel mailing list