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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4