On 4/16/19, Tomas Härdin <tjop...@acc.umu.se> wrote: > 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. The > field is already a huge mess of broken muxers and demuxers. We should > make sure our own yard is in order > > As always, I'm going to point out that we'd be better off using bmxlib
I can not follow your logic. _______________________________________________ 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".
