[FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: do not write index tables with the same InstanceUID

Marton Balint cus at passwd.hu
Mon Mar 14 21:54:12 EET 2022



On Mon, 14 Mar 2022, Tomas Härdin wrote:

> mån 2022-03-14 klockan 19:49 +0100 skrev Marton Balint:
>> Only index tables repeating previous index tables should use the same
>> InstaceUID. Use the index start position when generating the
>> InstanceUID to fix
>> this.
>> 
>> Signed-off-by: Marton Balint <cus at passwd.hu>
>> ---
>>  libavformat/mxfenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
>> index ba8e7babfb..5b972eadaa 100644
>> --- a/libavformat/mxfenc.c
>> +++ b/libavformat/mxfenc.c
>> @@ -1757,7 +1757,7 @@ static void
>> mxf_write_index_table_segment(AVFormatContext *s)
>>  
>>      // instance id
>>      mxf_write_local_tag(s, 16, 0x3C0A);
>> -    mxf_write_uuid(pb, IndexTableSegment, 0);
>> +    mxf_write_uuid(pb, IndexTableSegment, mxf-
>> >last_indexed_edit_unit);
>
> Two things: yes, it is good that this fixes the same InstanceUID being
> reused. But more importantly, we should not be writing files with over
> 65536 partitions!

last_indexed_edit_unit is frame based not partition based, so it can 
overflow 65536 realtively easily, that is why I submitted patch 1.

>
> This has been bugging me for quite some time. Honestly I don't know why
> the decision was taken initially to write indices every 10 seconds. In
> any use-case where seeks are moderately expensive working with files
> produced by mxfenc is a nightmare. Prime example being HTTP.

The 10 second body partition limit is coming from some specification 
(XDCAM HD?), so this is kind of intentional.

>
> If we do still need to keep writing partitions this way, can we repeat
> the IndexTableSegments in the footer so the entire file doesn't have to
> be scanned?

Yeah, that is what smart tools like bmxtools are doing.

Regards,
Marton


More information about the ffmpeg-devel mailing list