On 10.01.2017 00:15, Michael Niedermayer wrote:
On Mon, Jan 09, 2017 at 09:56:51AM +0100, Tobias Rapp wrote:
Allows the user to reserve space for the ODML master index. A sufficient
sized master index in the AVI header avoids storing follow-up master
indexes within the 'movi' data later.
Signed-off-by: Tobias Rapp <t.r...@noa-archive.com>
---
libavformat/avi.h | 1 -
libavformat/avienc.c | 36 +++++++++++++++++++++++++++++-------
libavformat/version.h | 2 +-
3 files changed, 30 insertions(+), 9 deletions(-)
iam not against this but as the only way to write strictly spec
compiant files >= 256g, i think this is not very user friendly
FFmpeg should work out of the box not requireing the user to tune
options
I took the "reserve_index_space" option of matroskaenc.c as an
inspiration. But I see that for Matroska it is "just" a matter of
optimization while for AVI it means compliance + optimization.
Here are some random ideas:
Enlarge the default index depending on expected bitrate, a high res
rawvideo input should by default get a bigger reserved index space
Yes, this would be a low-hanging fruit.
Use the input file duration (aka pass it to the muxer) and use it as
a guess on duration, enlarge the space accordingly
You mean guessing and setting the AVStream->duration field in ffmpeg.c
as a hint to the AVI muxer? Will take a look on how this could be done.
Or, do the hard but correct and just enlarge it
As in when you hit some SIZE1 like lets say 1GB leave 1mb space
(which at this filesize is a insignificant 0.1%)
and when writing the trailer and the file exceeded 256G go back and
move the first 1gb forward to make space for a larger master index.
(this at that point just moves 0.5% of the file)
You can also use the 1mb space for holding a 2nd master index prior
to writing the trailer. Either way the file should ideally be partially
indexed while it is being written so a 2nd process could read and mostly
seek in it
Moving the first 1GB forward also means updating each entry within the
legacy "idx1" index structure plus the base offset of each ODML standard
stream index. Further as the ODML master index of each stream has to be
enlarged also parts of the file header need to be moved.
In my opinion this would be a complex and fragile process. It seems more
safe to either warn the user to re-mux with adapted options (if he/she
cares for strict compliance) or fail, as discussed in the other thread
of this patch series.
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
