[FFmpeg-devel] [PATCH] Generic part of frame multithreading

[Michael Niedermayer]

On Wed, Aug 20, 2008 at 11:07:16AM -0400, Alexander Strange wrote:
> 
> On Aug 19, 2008, at 10:55 PM, Alexander Strange wrote:
> 
> > This patch adds the new API and generic implementation for frame  
> > multithreading. It doesn't cause any behavior changes, since it's  
> > just more functions with no users yet.
> >
> > Some issues:
> > - Some clients can't handle the extra decoder delay right, so I  
> > attached another patch that disables it by default. I don't know  
> > whether it's a good idea since we won't know when it's safe to to  
> > make it default again.
> 
> Specifically, it adds one more frame delay for every new thread.  

Frames should be made available as soon as they are available.
it improves cache usage and should handle frames that need more
time to decode than others better.
Iam not sure if this is or is not the case from your comment here ...


> mplayer counts frame delay using avctx->has_b_frames, which works for  
> h264 and doesn't work with this. ffplay counts delay by adding pts to  
> frames in get_buffer, which works with this but might not work with  
> h264, because of the frame num gap code. I thought about making avctx- 
>  >delay accurate for decoding too, which should solve all this.

mplayer is violating lavc API ...
IIRC ive rejected the use of has_b_frames back then when uoti suggested it
from your mail i assume that this design was commited anyway.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin
-------------- 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-devel/attachments/20080820/6fd9906e/attachment.pgp>