[FFmpeg-devel] [PATCH 3/6] libavformat: Add a function for freeing an AVFormatContext

[Reinhard Tartler]

On Thu, Feb 03, 2011 at 16:07:42 (CET), Martin Storsj? wrote:

> On Thu, 3 Feb 2011, Reinhard Tartler wrote:
>
>> On Thu, Feb 03, 2011 at 13:10:14 (CET), Martin Storsj? wrote:
>> 
>> > This function is useful for freeing data structures allocated by
>> > muxers, which currently have to be freed manually by the caller.
>> > ---
>> >  libavformat/avformat.h |    6 ++++++
>> >  libavformat/utils.c    |   11 ++++++++---
>> >  2 files changed, 14 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> > index f9f9be5..1cbe274 100644
>> > --- a/libavformat/avformat.h
>> > +++ b/libavformat/avformat.h
>> > @@ -1230,6 +1230,12 @@ void av_close_input_stream(AVFormatContext *s);
>> >  void av_close_input_file(AVFormatContext *s);
>> >  
>> >  /**
>> > + * Free an AVFormatContext and all its streams.
>> > + * @param s context to free
>> > + */
>> > +void av_free_context(AVFormatContext *s);
>> > +
>> > +/**
>> >   * Add a new stream to a media file.
>> >   *
>> >   * Can only be called in the read_header() function. If the flag
>> > diff --git a/libavformat/utils.c b/libavformat/utils.c
>> > index 4f51c26..2d0dea5 100644
>> > --- a/libavformat/utils.c
>> > +++ b/libavformat/utils.c
>> > @@ -2541,12 +2541,17 @@ int av_read_pause(AVFormatContext *s)
>> >  
>> >  void av_close_input_stream(AVFormatContext *s)
>> >  {
>> > -    int i;
>> > -    AVStream *st;
>> > -
>> >      flush_packet_queue(s);
>> >      if (s->iformat->read_close)
>> >          s->iformat->read_close(s);
>> > +    av_free_context(s);
>> > +}
>> > +
>> > +void av_free_context(AVFormatContext *s)
>> > +{
>> > +    int i;
>> > +    AVStream *st;
>> > +
>> >      for(i=0;i<s->nb_streams;i++) {
>> >          /* free all data in a stream component */
>> >          st = s->streams[i];
>> 
>> Patch misses doc/APIchanges update and minor bump.
>
> Ah, yes. I'll add these in the next round of this patch.
>
> Should I add the APIchanges in a separate commit, with a placeholder XXX 
> for the git hash that the applyer hopefully changes to the hash of the 
> preceding commit? Or what's the best procedure for sending full patchsets 
> doing this, without sending APIchanges as a separate patch afterwards, 
> once the actual change has been committed?

I don't think there are rules for this (yet?), but I would 'just' update
this particular patch and repost it as a followup to this thread.

This can be done by first committing the change you want to add and then
use 'git rebase -i $base' with $base being the last common revision with
the master branch, and them squash (combine) the last commit with the
one you are merging. Then use 'git format-patch $base' to generate new
patchsets.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4