[FFmpeg-devel] [PATCH 1/3] avformat/avienc: write chained master index only if std_compliance is normal or below

[Tobias Rapp]

On 13.01.2017 17:42, Michael Niedermayer wrote:
> On Tue, Jan 10, 2017 at 09:26:53AM +0100, Tobias Rapp wrote:
>> On 10.01.2017 00:19, Michael Niedermayer wrote:
>>>  [...]
>>> isnt it better to warn the user and inform him at the end what size
>>> of reserved space would have been needed?
>>>
>>> not saying iam against this, i do see how it is formally correct to
>>> fail hard but it feels painfull to me to fail
>>> muxing at 256gb hard when we can perfectly fine just continue and
>>> the user can just remux the file with bigger reserved master index
>>> to fix it
>>
>> But then adding "-strict strict" just enables a warning message and
>> a non-compliant file is written still? Or do you mean that
>> additionally a warning message could be written in case
>> std_compliance is <= normal?
>>
>> Background story: I'm working on an application that fetches some
>> AVI file byte range from tape storage and restores the file header.
>> The header restoration requires the ODML master index in the header
>> to be complete. Thus I'd like to ensure that all AVI files put into
>> the archive have a compliant/compatible index structure.
>>
>> For such automated processes failing hard is more safe than
>> continuing with a warning message, checking for log messages in the
>> host application and possibly re-running the transcoding with
>> adapted options.
>
> whats your oppinion on an option that selects muxer error behavior ?
> something that can
> fail immedeatly on error or
> warn but continue, return failure after writing the file and trailer
>
> that is a option to make it possible for a muxer to continue even
> if there was an error, maybe even a int max_muxer_error or something
> else?

You mean something like extending the current use of error_recognition 
and AV_EF_EXPLODE to encoders/muxers? In general it might be a good idea 
but I don't see how it helps in the current case.

When all entries of the master index are exhausted and another entry is 
to be added the basic options are:
a) write a chained master index (currently implemented)
b) enlarge the master index (currently not implemented and I won't 
volunteer for doing it)
c) fail

(a) slightly violates the specs but (b+c) doesn't. One could see (c) as 
a placeholder until (b) is done. In that case '-strict 1' would perform 
(b) and '-strict -1' might perform (a) because it is faster.

Version 2 of the patch series now adds a compliance warning with proper 
reserve_index_space value to (a).

Regards,
Tobias