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"
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel