[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