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 it might be a good idea
but I don't see how it helps in the current case.
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
(a) slightly violates the specs but (b+c) doesn't. One could see (c) as
a placeholder until (b) is done. In that case '-strict 1' would perform
(b) and '-strict -1' might perform (a) because it is faster.
Version 2 of the patch series now adds a compliance warning with proper
reserve_index_space value to (a).
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
