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