On Sat, Jun 21, 2008 at 12:39:49AM -0400, Michael Conrad wrote: > On Fri, 20 Jun 2008 20:11:01 -0400, Tom Conerly <[EMAIL PROTECTED]> > wrote: > > I have two AVFrame structs which I am switching between so that > > I can work on one frame while decoding the next frame. When I > > call avcodec_decode_video the struct holding the previous frame's > > data is changed (not the struct being passed to the function). > > I've run into the same. I'm pretty sure its by design. It might help to > think of the objects you get from libav more like views, and less like > allocated objects. (though they still need to be freed, to let the lib > know that you are done looking at them) Anyway, don't expect frames or > packets to be preserved accross calls to the next function that returns > one. I think they do this to give codec and muxer implementors more > freedom to optimize things, but yes, its annoying for people who are > trying to parallelize. In order to have more than one packet available at > a time, you have to call av_dup_packet,
> and in order to have more than one > decoded frame available at a time you need to call av_picture_copy. (See > respective documentation and/or source for how to use them) For decoders that support CODEC_CAP_DR1 its possible to override AVCodecContext.get/release_buffer() and make the codec render frames where you want them, thus avoiding the copy. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates
signature.asc
Description: Digital signature
_______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
