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

[Tomas Härdin]

On Sun, 2011-12-18 at 17:01 +0100, Reimar Döffinger wrote:
> On Sun, Dec 18, 2011 at 04:47:54PM +0100, Tomas Härdin wrote:
> > On Sun, 2011-12-18 at 14:12 +0100, Reimar Döffinger wrote:
> > > On Sun, Dec 18, 2011 at 01:39:25PM +0100, Tomas Härdin wrote:
> > > > On Fri, 2011-12-16 at 21:01 +0100, Reimar Döffinger wrote:
> > > > > This is useful if either the index is just broken or as a
> > > > > temporary workaround if the new index parsing code doesn't
> > > > > handle some case yet.
> > > > 
> > > > Actually, the new code absoletes this hack. The reason is simple: except
> > > > for OPAtom it works mostly like the old code.
> > > 
> > > It's not a hack, it is supporting a feature.
> > > And I don't think the new code will obsolete it, if the index contains
> > > complete nonsense the new code will still try to use it for seeking
> > 
> > Do you have a sample that demonstrates this problem? If so, then what
> > software wrote it? The first attempt at a solution would be to file a
> > bug report with the authors, not encourage the use of such shitty
> > writers.
> 
> It will not encourage it, because the user still has to explicitly
> enable it.

Ah, I see.

> And I do not have a sample file, but I strongly object about this (in
> some parts) new philosophy of "let's only support 100% valid files an
> leave users helpless if ever something goes wrong".

It's more a case of "please provide a sample so we can perhaps make the
demuxer detect/handle such files".
For instance, if we know that some company produces strange files that
don't follow the spec we might be able to inspect the Identification set
and toggle some logic based on that.

> What is the big problem that makes the idea of making it easy for
> users to work around such issue such a horror that even a one-line
> patch is not acceptable?

Added complexity. But I'll concede that in this case it isn't very
complex at all.
> 
> > It could just be that its a partial file, with only part of the
> index
> > missing.
> > Or some transmission error damaging mostly the index.
> I can see that for MXF it is not going to be very convincing case,
> but for AVI one of the biggest issues was actually with torrents:
> They can easily end up with an index that looks almost ok, except
> that somewhere in the middle there is a block of 0s instead of a
> proper index.

I can see that being at least a plausible use case, if unlikely (your
typical MXF user has enough bandwidth to re-download).

Anyway: The patch no longer applies. A suitable replacement could
possibly be to check that flag in mxf_read_seek().

/Tomas