[FFmpeg-devel] [PATCH] pkt_pts reordering

Michael Niedermayer michaelni
Mon Jan 10 16:39:28 CET 2011


On Mon, Jan 10, 2011 at 04:21:31PM +0100, Michael Niedermayer wrote:
> On Mon, Jan 10, 2011 at 09:30:10AM -0500, Ronald S. Bultje wrote:
> > Hi,
> > 
> > On Mon, Jan 10, 2011 at 9:26 AM, Vladimir Pantelic <vladoman at gmail.com> wrote:
> > > Luca Barbato wrote:
> > >> On 01/10/2011 03:04 PM, Michael Niedermayer wrote:
> > >>> ?whats the use case for non timestamp opaque?
> > >>
> > >> I could think about some use case that would work better with a void
> > >> pointer instead of a 64bit int but I might be wrong.
> > >
> > > yes, a void* value would be better indeed now
> > >
> > > The use case is to allow the user to carry frame private data from
> > > a pkt to decoded frame
> > 
> > That could be an AVPacket * also, in which case we no longer need pkt_pts/dts.
> 
> no, we still would need pkt_dts the 2 timestamps are reoredered differently
> and a AVPacket * has a few extra issues like it has to be a copy of the struct
> as the original struct can be freed long before the AVFrame is freed also the
> bitstream pointed to from the AVPacket can be freed or changed long before the
> AVFrame is freed.

So we could maybe replace pkt_pts by a pointer to a copy of the AVPacket
what wed gain by this would be access to the AVPacket flags and file pos
from the AVFrame. We would not gain access to the bitstream from the AVFrame
as this could be freed or reused already even immedeatly after decode() returns

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20110110/63ef6a7a/attachment.pgp>



More information about the ffmpeg-devel mailing list