[MPlayer-dev-eng] [PATCH] multi-threaded lavc

[Michael Niedermayer]

Hi

On Tuesday 31 August 2004 22:33, D Richard Felker III wrote:
> On Sun, Aug 01, 2004 at 11:44:13AM +0200, Michael Niedermayer wrote:
> > Hi
> >
> > On Sunday 01 August 2004 11:26, Reimar Döffinger wrote:
> > > Hi,
> > >
> > > >>>The results are not bitwise identical to a single-threaded encode,
> > > >>> but
> > > >>
> > > >>this is because the motion estimation normally uses the motion vector
> > > >> of the MB above the current one, but thats not possible if the top
> > > >> one happens to be handled by a different thread
> > > >
> > > > So, theoreticaly the motion estimation is a little bit worse if
> > > > multithreading is used ? I think this should be mentioned in the
> > >
> > > I understood it that usually it takes the vector of the MB above as a
> > > starting point, thus speeding up the search. So I thought it should
> > > only be slower a bit. Is this right? or maybe a mixture of both is
> > > right ;-)
> >
> > its a little slower & a little worse, but the difference is probably
> > tiny, didnt test though
>
> michael, imo it should be possible to make a mode where the threaded
> motion est behaves just like the non-threaded. just delay subsequent
> rows so that when row N is on mb M, row N+1 is on mb M-1. it won't be
> as fast but it might be worth it. the synchronization could be done
> without thread-level locking. if it's not obvious how, i can explain.
1 row != 1 thread, and IIRC the optimal number of threads was close to the 
number of cpus, in which case there will be several rows per thread, waiting 
in such a case for the mb above is problematic speedwise

[...]
-- 
Michael
level[i]= get_vlc(); i+=get_vlc();		(violates patent EP0266049)
median(mv[y-1][x], mv[y][x-1], mv[y+1][x+1]);	(violates patent #5,905,535)
buf[i]= qp - buf[i-1];				(violates patent #?)
for more examples, see http://mplayerhq.hu/~michael/patent.html
stop it, see http://petition.eurolinux.org & http://petition.ffii.org/eubsa/en