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

D Richard Felker III dalias at aerifal.cx
Tue Aug 31 22:33:53 CEST 2004


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.

rich




More information about the MPlayer-dev-eng mailing list