[FFmpeg-devel] [PATCH] mxfdec: Constrain run-in to 64k
Paul B Mahol
onemda at gmail.com
Tue Apr 16 16:16:33 EEST 2019
On 4/16/19, Tomas Härdin <tjoppen at 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 <tjoppen at 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
>> > > > > > > > <tjoppen at 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.
>> > 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.
More information about the ffmpeg-devel