From: Michael R. <mr...@us...> - 2004-07-09 15:48:51
|
Hi, > This would mean i would have to divide up the slices within decode.c and > spawn threads there so that they could share a common xine frame to draw > to, or is this achievable at a higher level in the decode chain? Well, the threads you launch have to get a memory chunk from somewhere, where they write the decoded slices to. What difference does it make, from the single thread's POV, if these chunks are inside a xine frame? > I think i've managed to get libmpeg2 to selectively decode the slices i'm > interested in but am unable to get xine the display even the incomplete > frames because of incomplete timecode info. picture->current_frame and > picture->backward_frame_reference_frame are the same with > picture->forward_reference_frame=0. I'm using an almost unmodified version > of parse_chunk and it expects to recieve complete frames, do i maybe have > to rearrange the entire structure of decode.c or is there any easier way to > do this that i'm not thinking of? I am not sure how the timecode can be a problem here. The whole parsing of the headers has to be done in one single thread of course. I would simply look for the loop in libmpeg2 that iterates over the slices of one image (line 1634 in slice.c, maybe?) and try to parallelize this in an OpenMP-like way. If you have an OpenMP-capable compiler (the free icc for Linux for example), you can even do that with actual OpenMP. Michael -- panic("kmem_cache_init(): Offsets are wrong - I've been messed with!"); 2.2.16 /usr/src/linux/mm/slab.c |