On Tue, Jan 10, 2017 at 10:41:04AM +0100, Tobias Rapp wrote: > 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.
yes, that was the idea > > >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. simply writing the whole header again may be cleaner than moving parts of it thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth.
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
