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

[Michael Niedermayer]

On Wed, Jan 18, 2017 at 10:18:36AM +0100, Tobias Rapp wrote:
> 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) ...

what i was thinking about would  when enabled not return an error
before the end, but a AV_PROBLEM_BUT_CONTINUE would be an option too

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- 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/20170119/ee1a7d0c/attachment.sig>