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

[Michael Niedermayer]

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


[...]
-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20160429/957bb646/attachment.sig>