[FFmpeg-devel] [RFC] missing close/free functions for avformat?

Michael Niedermayer michaelni
Tue Dec 18 22:30:03 CET 2007


On Mon, Dec 17, 2007 at 08:28:12PM +0100, Reimar D?ffinger wrote:
> Hello,
> On Mon, Dec 17, 2007 at 01:09:14PM +0100, Michael Niedermayer wrote:
> > On Sun, Dec 16, 2007 at 11:09:48AM +0100, Reimar D?ffinger wrote:
> > > On Sun, Dec 16, 2007 at 02:44:09AM +0100, Michael Niedermayer wrote:
> > > > On Sat, Dec 15, 2007 at 08:32:53PM +0100, Reimar D?ffinger wrote:
> > > [...]
> > > > > It's untested, but does something like this look good?
> > > > 
> > > > if you test it and are sure its correct and theres no way to make
> > > > av_close_input_file() work with _stream as well ...
> > > 
> > > Of course there are ways, e.g. a autoalloced_byteio flag (ok, preferably
> > > a better name) in the AVFormatContext that indicates if we should do
> > > url_fclose on the byteiocontext or not.
> > > That would mean we could get rid of the (very minor) "must_open_file"
> > > code duplication between open and close functions.
> > > But then IMO the naming is inconsistent, and calling it
> > > av_free_format_context would be better (keeping the av_close_input_file
> > > as deprecated for compatibility).
> > > I find that name appropriate because such a function frees the
> > > AVFormatContext and everything that avformat allocated "behind the back"
> > > of the user, and the only alternative that would give a consistent
> > 
> > ok
> 
> This is what I had in mind, say if you think it makes sense.

somehow it feels wrong
what about putting a close function ptr in ByteIOContext instead of calling 
url_fclose() with the hidden assumtation that opaque is a URLContext?

and independant of that i was thinking if all these function ptrs in
ByteIOContext should not maybe be split out into a ByteIOProtocol simiar
to URLContext/URLProtocol

though the whole feels somehow bloated and redundant, i wonder if we could
merge ByteIO* and URL* ...
or maybe have a pointer in ByteIOContext pointing to URLProtocol instead of
these many wraper functions and pointers in ByteIOContext ...

more random ideas and less constructive comments, i know ...

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20071218/f5b63e73/attachment.pgp>



More information about the ffmpeg-devel mailing list