[Ffmpeg-devel] FFmpeg API Discrepancies

[Michael Niedermayer]

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>