Hi, On Fri, Apr 29, 2016 at 9:08 AM, Michael Niedermayer <mich...@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 <ceho...@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. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
