[Ffmpeg-devel] FFmpeg API Discrepancies
Michael Niedermayer
michaelni
Wed Jan 10 03:02:26 CET 2007
Hi
On Tue, Jan 09, 2007 at 03:55:58PM -0800, Roman Shaposhnik wrote:
> Hi
>
> On Tue, 2007-01-09 at 12:32 +0100, Michael Niedermayer wrote:
> > > > am i rightly assuming that dv.c is buggy because it doesn't call
> > > > release_buffer() on dvvideo_close()?
> > >
> > > I'm not sure I understand the intricate details of buffer management
> > > well enough but it looks like lots of codecs are that way -- they
> > > do:
> > > if(s->picture.data[0])
> > > avctx->release_buffer(avctx, &s->picture);
> > >
> > > in the context of *_decode_frame() and they don't (are not supposed to?)
> > > care about *_close().
> > >
> > > Am I missing something here ?
> >
> > some codes do release_buffer() during close (all mpeg and h26* codecs IIRC)
> > i dont think its documented anywhere if this is needed or not but looking
> > at the analogy of malloc() and free() id say things which have been allocated
> > should be freed ...
>
> I see your point. I've also noticed that quite a few codecs don't
> even bother to defining AVCodec::close() because they truly don't
> need it. Given that maybe the best way to fix the problem would be
> modifying avcodec_close() so that it calls release_buffer() ?
yes but how?
release_buffer(AVFrame from uhm wait i dont know where the codec stored it)
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Everything should be made as simple as possible, but not simpler.
-- Albert Einstein
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20070110/8f763699/attachment.pgp>
More information about the ffmpeg-devel
mailing list