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 /Tomas _______________________________________________ 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".