[FFmpeg-devel] [PATCH 2/3] avformat/avienc: add reserve_index_space option

Tobias Rapp t.rapp at noa-archive.com
Tue Jan 10 11:41:04 EET 2017


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.rapp at 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



More information about the ffmpeg-devel mailing list