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


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.

Attachment: signature.asc
Description: Digital signature

ffmpeg-devel mailing list

Reply via email to