On Thu, Apr 10, 2008 at 12:48:44AM -0400, Michael Conrad wrote: > Hi, I'm working on an application that uses libav for playback. I'd > like to support as many kinds of streams as possible, so I'm looking > to make my code as robust as I can. I've been reviewing Dranger's > tutorial (http://www.dranger.com/ffmpeg/tutorial05.html) and the > source for FFPlay > (http://svn.mplayerhq.hu/ffmpeg/trunk/ffplay.c?view=markup) > and I notice they both use an ugly hack where they capture the > current packet's PTS value in a user-defined get_buffer function. > > According to Dranger: > > However, the frame we get from avcodec_decode_video() gives > us an AVFrame, which doesn't contain a useful PTS value. > (Warning: AVFrame does contain a pts variable, but this > will not always contain what we want when we get a frame.) > > I would really like to know why. It seems to me that having a useful > pts in AVFrame is one of the most important things libavcodec could do > for me. This hack of storing the current packet PTS in a global > variable and grabbing a copy of it as a side-effect of a get_buffer > function seems extremely bug-prone. Case-in-point, I was looking > through the documentation of AVCodecContext and see that there is also > a reget_buffer function that reuses the buffers of an existing AVFrame, > if possible. Does this mean that FFPlay already has a bug in it? > If a codec decided to use reget_buffer instead of get_buffer it would > bypass the PTS-copy, and end up with a new frame with an old PTS value. > > I'm really hoping that this is an old bug that doesn't need a > workaround anymore... > > Any insight is appreciated.
Some codecs have pts stored in their bitstream, this ends up in AVFrame.pts Some containers have pts stored in their bitstream, this ends up in AVPacket.pts in a perfect world these would always be equal, well you can guess it, there are plenty of files where they are not. Libav* provides you with both values, what you do with them is up to you. If you want to reorder pts with frames that can easily be done by passing the pts over AVCodecContext.opaque and get_buffer() And codecs using reget_buffer have dts==pts so there should be no need for any reordering. If you have suggestions and especially patches to improve anything they are welcome. > > > Other questions I'd love to know the answer to, if anyone knows: > > * Can av_decode_video ever allocate two frames during one call? yes, but no codec currently does this for valid streams, just for broken ones IIRC. > (yes, it can only return one, but seems like in complex streams > it might internally allocate two at once, to be returned later) > > * If the AVFrame->pts really isn't usable, could I just use the pts of > the first packet which does *not* result in a completed frame as > the pts of the next completed frame? no [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein
signature.asc
Description: Digital signature
_______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
