tis 2019-04-16 klockan 15:29 +0200 skrev Carl Eugen Hoyos: > > 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?
Eh, that doesn't really accomplish much. I guess I'll have to look at this from the positive side: more people writing broken muxers means more consulting hours for the rest of us! /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".
