[FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers
Carl Eugen Hoyos
cehoyos at ag.or.at
Sat Apr 30 22:57:18 CEST 2016
On Friday 29 April 2016 09:10:08 am Christoph Gisquet wrote:
> 2016-04-27 23:58 GMT+02:00 Carl Eugen Hoyos <cehoyos at ag.or.at>:
> > Mark Thompson <sw <at> jkqxz.net> writes:
> >> Unless someone can show what created this file and that
> >> it might make more, I suggest that the hack workaround
> >> should be removed.
> > Is there a valid file affected by the applied patch?
> > It is very important that FFmpeg also decodes invalid
> > files as long as no valid files are affected.
> The file is invalid in the sense that someone didn't remove an
> encapsulation (*) from another protocol layer (ie did a very bad job),
> not because of a somewhat known implementation bug due to misreading
> some specs (like we have for avi, mpeg-4 part 2, and already hevc,
If somebody agrees with my reasoning above (as said, I was very
surprised that people disagreed), your explanation sounds like an
acceptable reason to keep the patch imo.
> I wonder, for instance, if I stream copy that sequence into another
> container, would the issue remain, and thus require the bugfix to be
> copied yet somewhere else?
I tested the following with todays Zeranoe binaries:
$ ffmpeg -i 01c56b0dc1.ts -an -vcodec copy out.ts
$ ffmpeg -i 01c56b0dc1.ts -an -vcodec copy out.mov
$ ffmpeg -i 01c56b0dc1.ts -an -vcodec copy out.mkv
$ ffmpeg -i 01c56b0dc1.ts -an -vcodec copy out.asf
All four output files play fine with WMP, the first three also with
the new MS media player (which does not support asf afaict).
(I also successfully tested mp4 with one of the players.)
> You even think so:
> > This is of course assuming that the file was not created
> > for the sole purpose to produce such changes in FFmpeg.
> i.e., is there a software/application that needs this, or is it just
> someone that expected dumping the stream to work while
> debugging/implementing something entirely different?
My question was: Is there any indication that somebody was acting on
bad faith, only wanting to get a patch into FFmpeg?
This seems very unlikely for the given file.
> In the end, if that was not that rare, I wonder if that wouldn't be
> the job of a bitstream filter.
> (*) although we probably support some strange things iirc, like
I am quite sure that FFmpeg does not support wav-in-avi (and not
Note that the dts-in-wav support really is problematic but was
More information about the ffmpeg-devel