2019-04-16 14:44 GMT+02:00, Tomas Härdin <tjop...@acc.umu.se>: > tis 2019-04-16 klockan 00:41 +0200 skrev Carl Eugen Hoyos: >> > 2019-04-16 0:00 GMT+02:00, Tomas Härdin <tjop...@acc.umu.se>: >> > mån 2019-04-15 klockan 12:40 +0200 skrev Carl Eugen Hoyos: >> > > > > > > > 2019-04-15 10:30 GMT+02:00, Tomas Härdin >> > > > > > > > <tjop...@acc.umu.se>: >> > > > This isn't likely to be a huge problem, but it allows us to reason >> > > > more >> > > > about run-in. It also exposes my gripe about klv_read_packet() using >> > > > mxf_read_sync() >> > > >> > > Does this patch have an effect on one of our samples? >> > >> > It passes FATE if that's what you mean. >> >> No. >> >> > The intent is rather to pre-emptively stop the ability for new >> > broken muxers to pop up, which would end up straying >> > from the spec because mxfdec.c is being too forgiving >> >> As such, and if I don't misunderstand, this sounds to me >> like an explanation why this patch should not be pushed. > > If you want to encourage spec violating behavior in professional > muxers, sure. But for anyone who has to work with MXF, the ability to > tell the other engineer "no, go fix your damn muxer" is important.
Apart from: This is - fortunately - not what we do for all other formats (we wouldn't be here for a very long time if we did): Why don't you print a warning? > The field is already a huge mess of broken muxers and > demuxers. We should make sure our own yard is in order This can only be true for muxers (and encoders), never for demuxers (and decoders). Carl Eugen _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
