[XviD-devel] multithreaded pvop-ME

Radek Czyz radoslaw at syskin.cjb.net
Wed Dec 21 07:52:18 CET 2005

Pascal Massimino wrote:
> 	That is, we should use:
> 	while( mb_pos==top_mb_pos ) { /* do nothing and wait for the other thread to advance 'top_mb_pos' */ }

I tried that and it was very slow. My reasoning is that if current 
thread has nothing to do, then surely there exists another thread that 
does. It didn't exactly work for me yet (3 threads were slower than 2) 
but I plan to add third thread, which is doing the MC and bitstream 
encoding, and which can always jump in and fill any gaps on any ME threads.

Also note that your solution encourages processing only one MB at a time 
and then resynchronize again. If one thread is so much ahead of the 
other, it's probably best for this thread to purposefully delay itself 
and grab larger MB chunk next time.

I plan to experiment with Sleep() more and try this: if a thread grabbed 
very few macroblocks at one time (say below 3), process the MBs but then 
Sleep() before you even try to resynchronize again.

More complex solution involves using one thread for more than one line 
of macroblocks at a time, to reduce number of stalls (same logic as 
using more threads than CPUs, but without involving real OS threads).

Thanks for your comments everyone, my experience with multithreading is 
basically nil so I'm grateful :)

Oh, guess what: there's a demand for multithreaded b-frame ME that 
produces completely identical bitstream. I would have to use the same 
logic as pvop-ME. I'll definitely try this because this method has its 
interesting advantages. I'll see if it's faster or not (guess what, it 
might be).


More information about the XviD-devel mailing list