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

[Tobias Rapp]

On 17.01.2017 19:10, Michael Niedermayer wrote:
> On Tue, Jan 17, 2017 at 02:44:28PM +0100, Tobias Rapp wrote:
>> 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
>
> no, the semantic meaning is different
> recogniing errors in the input material and recognizing errors in the
> muxer "implementation" in relation to the used input or other are not
> the same thing.
> They may have different values, different defaults, and would have
> different explanation in the docs
>
>> it might be a good idea but I don't see how it helps in the current
>> case.
>
> well, it gives the user the option
> d) write a working file with chained master index and fail at trailer
> writing time to indicate that its not spec compliant but loose no
> data. The use case is anything that has non recoverable input,
> anything that cannot be re-run with a larger reserved space

I agree this would be better e.g. when recording live data coming from 
an input device. Would the indication be done by some special return 
code "AV_PROBLEM_BUT_CONTINUE" on API level? Or maybe a separate error 
reporting field/buffer within the AVFormatContext struct? Trying to 
understand how it would integrate into the host application 
(ffmpeg/other) ...

Anyway, will send version 3 of the patch series with this patch excluded.

> [...]

Regards,
Tobias