[FFmpeg-devel] [PATCH] mxfdec: Constrain run-in to 64k
Carl Eugen Hoyos
ceffmpeg at gmail.com
Tue Apr 16 16:29:05 EEST 2019
2019-04-16 14:44 GMT+02:00, Tomas Härdin <tjoppen at 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 <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.
>>
>> 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
More information about the ffmpeg-devel
mailing list