[FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers

Ronald S. Bultje rsbultje at gmail.com
Sat Apr 30 14:30:41 CEST 2016


On Fri, Apr 29, 2016 at 9:08 AM, Michael Niedermayer <michael at niedermayer.cc
> wrote:

> On Fri, Apr 29, 2016 at 08:09:34AM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Fri, Apr 29, 2016 at 7:52 AM, Carl Eugen Hoyos <cehoyos at ag.or.at>
> wrote:
> >
> > > I was under the impression that the only reason that demuxers and
> decoders
> > > are written like that is that we all want FFmpeg to support invalid
> streams
> > > as long as this doesn't affect valid streams.
> >
> >
> > It's too broad. I want to know the origin so we know the scope of this
> > problem. All we know is that somehow, one file came into existence and
> this
> > patch fixes this one file. I have doubts that multiple of these files
> > exist. If so, then what exactly do we gain from this "enhancement"? Our
> > codebase is full of this crap, and it becomes harder and harder to do
> > actual work because of these hacks.
> i dont know about this specific commit but more generally the case of
> "RTP encapsulations remaining in the data stream" was more widespread,
> for example longer ago there where users trying to play H263 streams
> encapsulated in RTP
> i do not know if these as a sideeffect of other changes can be
> played now or if that just stoped being an issue due to h263 being
> less common or something else ...
> >
> > At least the baby monitor (supposedly) is a class of files. This patch
> > doesn't fix one class, it fixes just one. And we have no idea where that
> > one came from.
> > You don't even seem mildly concerned that under your current
> > assumed "rule", anyone can generate any slightly-broken file to
> auto-amend
> > any decoder or demuxer in ffmpeg with any change whatsoever without
> concern
> > for code validity, code cleanliness or anything else.
> Has this ever happened ?
> Also what about the work needed to verify the widespreadness and
> origin of a type of file.
> A task that could be very difficult

You're asking questions that make the main issue stick around longer: can
we please revert this patch? I don't think there's wide support for it. If
we find out more about the origins of the file, we can revisit this issue.


More information about the ffmpeg-devel mailing list