Re: mulithread rework

Bill Mccormick wrote:
> This is kind of a newbie question, and I readily admit I don't completely 
> understand the details of the encoding process.
> 
> If you want to do the frame encoding in parallel on n processors, 
> wouldn't it be ideal to tessallate the frame into n pieces?   For example 
> if you have 4 processors then split the frame up into 4 quadrants and 
> make each processor responsible for 1 quadrant.
> 
> For inter-coded frames all 4 threads could share read only access to the 
> reference frame(s).   Statically create 1 thread per processor to perform 
> encoding so you don't waste time with thread creation/destruction.    
> Maybe there's a final thread to consolidate the 4 quadrants into a 
> complete frame if necessary.
> 
> I'm sure I'm missing something, what is it?

I will also readily admit that I am clueless with regards to the encoding 
process and it's requirements. However, I wrote a graphics app prototype 
once that processed different regions of the image in multiple threads. One 
thing interested me: When implementing a gaussian blur filter the threads 
needed to access pixels outside of their region to calculate pixels within 
their region. But since this was read only access it was ok. It got 
interesting when processing multiple layers of gaussian blurs. Because then 
these threads would duplicate some work. Ie thread A would calculate a 
region outside it's target region for the first blur, only to be able to 
have all data for the second blur. But thread B might also have calculated 
those very same pixels because it needed them for it's own target region. 
My point is, I allowed this happening and also used more memory so that 
each thread had it's own (full frame) intermediate buffer if it needed to 
store some results. But the effect was that each thread could work quite 
independently from each other. I don't know if anything of this can be 
applied to xvid though, so sorry for wasting your time if that is not the 
case. :-)

Best regards,
-Stephan