[FFmpeg-devel] [PATCH 2/2] avformat/mpegts: Skip over broken 0x80 headers
michael at niedermayer.cc
Fri Apr 29 15:08:17 CEST 2016
On Fri, Apr 29, 2016 at 08:09:34AM -0400, Ronald S. Bultje wrote:
> 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
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: Digital signature
More information about the ffmpeg-devel