[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:
> Hi,
> 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,
> etc).

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 
requested often.

Carl Eugen

More information about the ffmpeg-devel mailing list