Re: [xine-devel] Threading libmpeg2

[James Courtier-D. <Ja...@su...>]

Ashendra Singh wrote:
> Hi,
> 
> I was wondering if libmpeg2 was threaded at all in order to take advantage of 
> smp machines for example. From what i've been able to find out it seems that 
> the library itself is unthreaded. This might make a difference in the MC 
> parts of decoding high resolution mpeg2. 
> 
> Any ideas or opinions?

A lot of modern graphics cards support XvMC, so this moves the problem 
of doing the really hard work away from the CPU.

The most CPU intensive part in the decoding process is transferring the 
final image to the graphics card.
XSHM is the slowest, because YUV -> RGB conversion/upscaling has to be 
done first.
XV is faster, because the hardware does the YUV -> RGB conversion/upscaling.
XvMC is the fastest, because the Mpeg2 data is passed to the graphics 
card in compressed form, and very little work is required by the 
software decoder, apart from unpacking the stream.

If you do wish to implement a threaded mpeg2 decoder, I think it would 
be better to exclude the treading code from libmpeg2, and get the app to 
do the threading.
e.g. libmpeg2 takes in the data stream, then outputs each slice(before 
decode). the app then decides what to do with each slice.
In this way, you can separate the unpacking of the stream, which is 
really a single threaded task, from the slice decode, that might be 
handled with multiple threads, so long as all the threads are on a SMP 
based machine. If there is not shared memory between processors, 
threading my actually make things slower.

James