[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).
Radek
More information about the XviD-devel
mailing list