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

[Michael Niedermayer]

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


> 
> 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
>

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170117/a57fa939/attachment.sig>