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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
