[FFmpeg-soc] [soc] Add choice of threading algorithm to AVCodecContext.
michaelni at gmx.at
Tue Jun 17 23:07:21 CEST 2008
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
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
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
Size: 189 bytes
Desc: Digital signature
More information about the FFmpeg-soc