[FFmpeg-devel] [PATCH] lavf/mxfenc: Bump EDIT_UNITS_PER_BODY

[Tomas Härdin]

mån 2023-02-13 klockan 20:33 +0100 skrev Marton Balint:
> 
> 
> On Mon, 13 Feb 2023, Tomas Härdin wrote:
> 
> > Passes FATE because we don't have any tests that mux files with a
> > whopping 250 frames. Tested with a jpeg2000 Tears of Steel sample.
> 
> Have you checked what BMX does? Because as far as I remember for 
> RDD9 (XDCAM HD) this should not exceed 10 seconds.

I have not checked BMX. Also such constraints should be explicitly
documented and there should be tests for them. An option like -xdcam
might be appropriate. Currently there is no justification at all in the
code for the choice of 250.

> 
> I suggest adding an option for this with -1 default, and unless the
> user 
> overrides it make it 238 in case of MPEG2 essence, and infinite (0) 
> otherwise.

I wouldn't be opposed to having it use a dynamic array. As for MPEG2,
that does stink a bit but perhaps it avoids causing grief for most
users. Here we again come to the problem that we don't know the
workflows in which mxf* are used, and I don't like that we're cargo
culting defaults.

> 
> There is also code which allocates the index entries in 
> EDIT_UNITS_PER_BODY increments, that probably should be replaced with
> av_dynarray2_add...

That (re)allocation happens at most twice for assuming GOP size <
EDIT_UNITS_PER_BODY

The reason I bring this all up is because opening MXF files muxed by
lavf over HTTP is slow as hell. This will be true for any other storage
where seeking incurs a non-trivial cost. HDDs come to mind. Perhaps
that is really an mxfdec problem, but then parsing becomes even hairier
than it already is. We'd have to binary search the file when seeking,
hoping to find the necessary index table segments on-the-fly..

/Tomas