[FFmpeg-devel] [PATCH] mxfdec: Constrain run-in to 64k

[Tomas Härdin]

tis 2019-04-16 klockan 15:29 +0200 skrev Carl Eugen Hoyos:
> > 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?

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