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 <c...@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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
