[FFmpeg-devel] [PATCH] mxfdec: support AVFMT_FLAG_IGNIDX.

Tomas Härdin tomas.hardin at codemill.se
Wed Jan 11 10:05:18 CET 2012


On Tue, 2012-01-10 at 20:24 +0100, Reimar Döffinger wrote:
> On Tue, Jan 10, 2012 at 03:28:43PM +0100, Tomas Härdin wrote:
> > On Thu, 2012-01-05 at 22:18 +0100, Reimar Döffinger wrote:
> > > This allow users to work around regressions introduced by index support
> > > and helps with debugging.
> > > 
> > > Signed-off-by: Reimar Döffinger <Reimar.Doeffinger at gmx.de>
> > > ---
> > >  libavformat/mxfdec.c |    3 +++
> > >  1 files changed, 3 insertions(+), 0 deletions(-)
> > > 
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index 66af2e4..1498ebb 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -1529,6 +1529,9 @@ static int mxf_parse_handle_essence(MXFContext *mxf)
> > >          /* remember where we were so we don't end up seeking further back than this */
> > >          mxf->last_forward_tell = avio_tell(pb);
> > >  
> > > +        if (mxf->fc->flags & AVFMT_FLAG_IGNIDX)
> > > +            return 0;
> > > +
> > 
> > Uhm, this doesn't make sense. Shouldn't this flag be checked in code
> > related to index parsing or seeking, like mxf_read_index_table_segment()
> > or somewhere in mxf_parse_structural_metadata()?
> 
> Depends. I possibly/probably made a bad assumption in assuming that the
> index will always be at the end and anything really important in the
> beginning.

Every partition can contain an arbitrary number of index table segments
between its metadata and body (note that all partitions can have
metadata). This means the tables may be in either or all of these
places: The HeaderPartition, any BodyPartitions, the FooterPartition (if
present).
There's also no way to know how the file is structured in advance,
including where the complete metadata or index tables are located.

> Under that assumption it would make sense because it fulfills the
> purpose and in addition allows using the flag as a way
> to make the demuxer avoid a seek that is not really essential
> (e.g. when playing over high-latency network file system) and also
> to allow testing how the demuxer would behave with non-seekable input.

ffprobe - < foo.mxf

Regarding high latency links, maybe there should be a flag to force a
URL to be opened non-seekable? That or the user should remux their files
to be more suitable for HTTP (like qt-faststart).

/Tomas



More information about the ffmpeg-devel mailing list