[FFmpeg-devel] [RFC]lavf/mxfdec: Assume first track if track number is unknown

Carl Eugen Hoyos cehoyos at ag.or.at
Mon Mar 14 17:32:12 CET 2016


Tomas Härdin <tomas.hardin <at> codemill.se> writes:

> On Sun, 2016-03-13 at 14:25 +0000, Carl Eugen Hoyos wrote:
> > Tomas Härdin <tomas.hardin <at> codemill.se> writes:
> > 
> > > On Thu, 2016-03-10 at 15:06 +0100, Carl Eugen Hoyos wrote:
> > > > 
> > > > Attached patch fixes ticket #5312 here.
> > > > The OP claims that the file plays fine with Mainconcept
> > > > software, afaict the track number of the video track in 
> > > > the mxf header (0x15010800) does not match the track 
> > > > number of the video frames (0x15010500 == 352388352).
> > > Hrm, this sounds suspicious. But I think happens for some 
> > > other files too, and I guess playing something is better 
> > > than nothing.. 
> > > Perhaps we can have it be a bit more stringent with when 
> > > it applies this hack?
> > > Like if there's only a single track
> > The file in question has several tracks, see the console 
> > output in ticket #5312.
> > The demuxer already accepts any track number for 
> > single-track files.
> > I was hoping you could have a look at the sample in 
> > http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket5312/
> > I hope I missed something...
> 
> I took a look at the file, this indeed seems to be the case.

I did miss something and there is a way to read this file 
without any workarounds?

> In other words the file was written by a bad or badly 
> configured encoder,

Or do you mean the video frames do use a track number that 
was not defined in the header?

> which is behavior we shouldn't be encouraging. In other 
> words, the user should fix their workflow.

If available proprietary software does decode the files, I 
fear the only reaction will be "FFmpeg fails to play real 
world files".

Thank you, Carl Eugen


More information about the ffmpeg-devel mailing list