[FFmpeg-soc] [soc] Add choice of threading algorithm to AVCodecContext.

[Michael Niedermayer]

On Tue, Jun 17, 2008 at 02:04:43PM -0400, Alexander Strange wrote:
> 
> On Jun 17, 2008, at 12:18 PM, Reimar Döffinger wrote:
> 
> > On Mon, Jun 16, 2008 at 07:57:05PM -0400, Alexander Strange wrote:
> >>
> >> Use it to simplify USE_* macros.
> >> FF_THREAD_AUTO needs to be handled better - even if a codec can  
> >> handle frame-threads, we still don't want to use them if there are  
> >> enough slices available.
> >
> > I also do not really like that this design does not allow to use both.
> > E.g. when 16 core CPUs become common just one type may not be good
> > enough ;-)
> > Or to say it differently: I think the problem is not just with
> > FF_THREAD_AUTO but in the design in general.
> >
> > Greetings,
> > Reimar Döffinger
> 
> You can't run out of threads for multiframes, but eventually I guess  

no?
Each MB needs to have its references available, So assuming a large GOP size
There is a limit on how many frames can be decoded in parallel.
Also a single motion vector going from the top of a frame to the bottom
will reduce frame level multithreaded decoding to single thread decoding.

mixing slices and frames though as much as i would like it might be
tricky ...

just an example
frame 1   frame 2
 _____     _____
|     |   |     |
|_____|   |_____|
|     |   |x    |
|_____|   |_____|

x here is the 1st block of frame 2 slice 2  lets assume its motion vector
points a little up then it will require slice 1 of frame 1 to be fully
decoded. (and even if it doesnt point up, MC interpolation and the loop filter
will extend its area of needed availability)

so slices * frames does not seem achievable, slice + frames maybe

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20080617/5215ed7c/attachment.pgp>