[FFmpeg-devel] [PATCH] support for ordered chapters/segment linking in Matroska

Aurelien Jacobs aurel
Sun Aug 24 18:15:58 CEST 2008

Michael Niedermayer wrote:

> On Sun, Aug 24, 2008 at 07:44:31AM +0200, Anton Khirnov wrote:
> > On Sat, Aug 23, 2008 at 9:01 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > > On Sat, Aug 23, 2008 at 05:50:23PM +0200, Anton Khirnov wrote:
> > >> 
> > >>  typedef struct AVChapter {
> > >>      int id;                 ///< Unique id to identify the chapter
> > >>      AVRational time_base;   ///< Timebase in which the start/end timestamps are specified
> > >>      int64_t start, end;     ///< chapter start/end time in time_base units
> > >>      char *title;            ///< chapter title
> > >> +    void *priv_data;        ///< demuxer-specific data
> > >>  } AVChapter;
> > >>
> > >>  #define MAX_STREAMS 20
> > >
> > > Thats a seperate change as well that has little to do with the rest.
> > >
> > ok, i'll separate it. if you're asking why do we need  private data
> > for chapters, it's because segment linking in matroska is done through
> > chapters.
> if the matroska maintainer agrees that priv_data in AVChapter is usefull then
> iam ok with it

No I don't. The matroska demuxer already has it's own private chapter struct
and chapter list. Any chapter related private data can be stored here.

There are many more things I don't like in this patch. One of them being that
the demuxer try to parse a directory and open files itself. I think the
demuxer should only deal with ByteIOContext that the generic framework (utils.c)
passes to it. That's up to the generic framework to find and open files
(or network streams of whatever...). That could also be useful for other

I will try to have a deeper look at it in the next few days, but a potential
idea would be:

1) the demuxer set AVFormatContext.flags |= AVFMT_FLAG_LINKED
2) utils.c check this flag and search for potential linked files,
   open them with av_open_input_file() and then pass the resulting
   context to the demuxer of step 1, by the mean of a new
   AVInputFormat.check_linked() function.
3) the check_linked() function of the demuxer verify if this new
   context is the linked one we are searching for, and return the
   result of this check
4) utils.c can then build a composite AVFormatContext containing
   all the context linked to the original file
5) utils.c can abstract this composite context as if it was a real
   context, reading or seeking in the appropriate segment

Well, that's just a rough idea. I don't know if this could fit
demuxers other than matroska. And I need to give it a deeper look
to check if it's feasible.


More information about the ffmpeg-devel mailing list