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

[Michael Niedermayer]

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:
> >> ping?
> >
> >
> >
> >> Index: libavformat/avformat.h
> >> ===================================================================
> >> --- libavformat/avformat.h    (revision 14918)
> >> +++ libavformat/avformat.h    (working copy)
> >> @@ -22,7 +22,7 @@
> >>  #define FFMPEG_AVFORMAT_H
> >>
> >>  #define LIBAVFORMAT_VERSION_MAJOR 52
> >> -#define LIBAVFORMAT_VERSION_MINOR 20
> >> +#define LIBAVFORMAT_VERSION_MINOR 21
> >>  #define LIBAVFORMAT_VERSION_MICRO  0
> >>
> >>  #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> >
> >> @@ -176,6 +176,8 @@
> >>      enum CodecID video_codec_id;
> >>      enum CodecID audio_codec_id;
> >>  #endif
> >> +    /**< Will automatically load linked segments for matroska files.*/
> >> +    int matroska_load_linked_segments;
> >>  } AVFormatParameters;
> >
> > AVFormatParameters is deprecated and i do not want to have more stuff added
> > to it
> >
> It's not marked as deprecated (or i'm missing something). Then what
> would be the correct place for this?

matroska_* should be in matroska*.c :)

a 
AVFMT_FLAG_IGN_EXTERNS
similar to
AVFMT_FLAG_IGNIDX
would probably be ok if that makes sense, als it could be used for mov.


> >
> >>
> >>  //! demuxer will use url_fopen, no opened file should be provided by the caller
> >> @@ -424,12 +426,15 @@
> >>
> >>  #define AVFMTCTX_NOHEADER      0x0001 /**< signal that no header is present
> >>                                           (streams are added dynamically) */
> >> +#define AVFMTCTX_VIRTUAL       0x0010 /** this context is an abstraction over
> >> +                                          several other contexts */
> >>
> >
> > I think this needs some explanation of
> > what it means
> > when its used
> > why it is needed
> >
> > besides 0x0010 is not the next available flag
> >
> i imagine it will work like this:
> demuxer autoloads some external streams -> creates a AVFormatContext
> marked with this flag, that can be used to access all these streams in
> the way they are meant to be played -> add the virtual context and all
> the real contexts to external_ctx array in the main AVFormatContext ->
> the client app a) select the virtual context and uses it instead of
> the main one b) chooses to access these external streams directly c)
> ignores it
> ->

Iam not against providing access to the external AVFormatContext if there
is some use in doing so.
But the rest looks a little unclean to me ...
I mean either a container contains
A. a single sequential timeline that should be sequentially played (possibly
   with redundant streams in different languages, commentary... ; chapters, ...)
B. several alternatives the user can choose from one way or another

If A then the main AVFormatContext should represent this single sequential
timeline no matter if its in a single file or not.
If B then we need some API that is generic enough to handle it, a single
additional virtual AVFormatContext probably isnt



> >>  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


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

There will always be a question for which you do not know the correct awnser.
-------------- 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/20080824/bf1ae7fa/attachment.pgp>