[FFmpeg-devel] [PATCH] support for ordered chapters/segment linking in Matroska
Michael Niedermayer
michaelni
Fri Nov 28 17:10:52 CET 2008
On Fri, Nov 28, 2008 at 04:08:08PM +0100, Anton Khirnov wrote:
> On Thu, Nov 27, 2008 at 11:49 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
> > On Fri, Nov 21, 2008 at 11:13:30PM +0100, Anton Khirnov wrote:
> >> On Fri, Nov 21, 2008 at 9:03 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
> >> >
> >> > [...]
> >> >> +#define AV_LINK_FILENAME 0x0001 ///< exact paths to external streams are known
> >> >> +#define AV_LINK_SAMEDIR 0x0002 ///< search for linked files in the same directory
> >> >> +
> >> >> +typedef struct AVLinkContext {
> >> >> + int search_flags; /**< Where should we look for external streams. */
> >> >
> >> > is the reader supposed to guess what values this field has or if it
> >> > maybe takes AV_LINK flags?
> >> >
> >>
> >> fixed =p
> >>
> >> >
> >> > [...]
> >> >> diff --git a/libavformat/avio.h b/libavformat/avio.h
> >> >> index 687333e..261fb32 100644
> >> >> --- a/libavformat/avio.h
> >> >> +++ b/libavformat/avio.h
> >> >> @@ -135,6 +135,9 @@ typedef struct URLProtocol {
> >> >> int (*url_read_pause)(URLContext *h, int pause);
> >> >> int64_t (*url_read_seek)(URLContext *h,
> >> >> int stream_index, int64_t timestamp, int flags);
> >> >> + int (*url_opendir)(URLContext **h, const char *path, int flags);
> >> >> + int (*url_readdir)( URLContext *h, char *filename, int max_size);
> >> >> + void (*url_closedir)(URLContext *h);
> >> >> } URLProtocol;
> >> >
> >> > This stuff belongs in a seperate patch
> >> >
> >>
> >> done
> >>
> >> Anton
> >
> >> diff --git a/libavformat/avio.h b/libavformat/avio.h
> >> index 687333e..261fb32 100644
> >> --- a/libavformat/avio.h
> >> +++ b/libavformat/avio.h
> >> @@ -135,6 +135,9 @@ typedef struct URLProtocol {
> >> int (*url_read_pause)(URLContext *h, int pause);
> >> int64_t (*url_read_seek)(URLContext *h,
> >> int stream_index, int64_t timestamp, int flags);
> >> + int (*url_opendir)(URLContext **h, const char *path, int flags);
> >> + int (*url_readdir)( URLContext *h, char *filename, int max_size);
> >> + void (*url_closedir)(URLContext *h);
> >> } URLProtocol;
> >
> > i was wondering if this is needed, i mean
> > url_open/url_read could be used too given a special flag during open to
> > indicate opening a directory.
> > But maybe this is undesireable, and your patch is better, i dont know
> > except this i think the directory patch is fine
> >
>
> I'd say that since we treat directories differently from normal files,
> we should also use different functions.
we treat them differently because the underlaying functions we (have to) use
treat them differently
> Besides i don't see an
> immediate way to determine if url_read is called for directory or
> file.
the "int flags"
like
#define AV_OPEN_DIR 0x1234
url_open(..., AV_OPEN_DIR);
>
> >
> >> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> >> index acdcec4..e85b49d 100644
> >> --- a/libavformat/avformat.h
> >> +++ b/libavformat/avformat.h
> >> @@ -22,8 +22,8 @@
> >> #define AVFORMAT_AVFORMAT_H
> >>
> >> #define LIBAVFORMAT_VERSION_MAJOR 52
> >> -#define LIBAVFORMAT_VERSION_MINOR 23
> >> -#define LIBAVFORMAT_VERSION_MICRO 1
> >> +#define LIBAVFORMAT_VERSION_MINOR 24
> >> +#define LIBAVFORMAT_VERSION_MICRO 0
> >>
> >> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> >> LIBAVFORMAT_VERSION_MINOR, \
> >> @@ -464,6 +464,29 @@ typedef struct AVChapter {
> >>
> >> #define MAX_STREAMS 20
> >>
> >> +#define AV_LINK_FILENAME 0x0001 ///< exact paths to external streams are known
> >> +#define AV_LINK_SAMEDIR 0x0002 ///< search for linked files in the same directory
> >> +
> >> +typedef struct AVLinkContext {
> >> + int search_flags; /**< Where should we look for external streams. See AV_LINK_* */
> >> + char **filenames; /**< Paths to external streams, if known. */
> >> + unsigned int nb_filenames;
> >> + char *extensions; /**< Extensions we are interested in, comma-separated. */
> >> + struct AVFormatContext **external_ctx; /** Handles of external streams. */
> >> + unsigned int nb_external_ctx;
> >> + /**
> >> + * Check if this stream is needed.
> >> + * First parameter is the main context, second is
> >> + * external stream.
> >> + */
> >> + int (*check_external_stream)(struct AVFormatContext *, struct AVFormatContext *);
> >> + /**
> >> + * Prepare the main context for using external
> >> + * streams.
> >> + */
> >> + int (*setup_context)(struct AVFormatContext *);
> >> +} AVLinkContext;
> >> +
> >> /**
> >> * Format I/O context.
> >> * New fields can be added to the end with minor version bumps.
> >
> > Why this complexity?
> >
> > I mean what is the problem with a demuxer calling a function that then
> > creates more AVFormatContext/... for the external streams and adds them
> > to some list in the main one?
> >
>
> I'm not sure what do you mean, some pingpong between demuxer and
> utils.c is unavoidable because the demuxer doesn's always know the
> filenames it'll need and utils.c can't do checking by itself.
i cant follow your logic.
* there is a way to decide which file to open or the file could not
be opened.
* above way can be implemented in a function be that in the demuxer or
utils.c
* this function can be called to find the file, next it can be opened
the contexts and streams be created ...
at no point does a AVLinkContext with callbacks become needed thus my
question again, what is this good for?
If matroska uses some silly system to guess which file to open, its a
matter of matroska calling a
give_me_a_list_of_file_names()
url_open(the_name_i_picked)
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.
-------------- 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/20081128/fa9371ae/attachment.pgp>
More information about the ffmpeg-devel
mailing list