[FFmpeg-devel] [PATCH] Generic part of frame multithreading
Thu Aug 21 01:21:45 CEST 2008
On Wed, Aug 20, 2008 at 10:45:04PM +0100, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> > On Wed, Aug 20, 2008 at 10:23:31PM +0300, Uoti Urpala wrote:
> >> On Wed, 2008-08-20 at 21:00 +0200, Michael Niedermayer wrote:
> >> > > 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
> >> You remember things backwards. The preliminary version of -correct-pts
> >> used buffer callbacks to count the number of buffered frames, and it was
> >> you who suggested using has_b_frames instead.
> > I do remember rejecting the even more broken
> > "callbacks to count the number of buffered frames" and i suspect i told you
> > back then that the timestamps should be given to the decoder to reorder them.
> How does one "give the timestamps to the decoder" using lavc? After
> all these years, I still haven't figured it out.
This is trivial, its just:
avcodec_decode_video(avctx, frame, &got_picture, pkt->data, pkt->size);
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel