On 05.10.2015 09:10, tim nicholson wrote:
On 04/10/15 13:07, Tomas Härdin wrote:
On Mon, 2015-09-28 at 15:11 +0200, Tobias Rapp wrote:
[...]
For me the most important thing is that anything dealing with MXF should
never write invalid files.
+1 for sure.
To overstate your point: So it would be OK to skip most input frames and
replace them with black frames as long as the output file is valid MXF?
I think there are different requirements for determining what makes an
"error" depending on the use-case. If I try to recover video frames from
an broken hard disk, for example, I probably won't mind some lost
frames. If I try to encode a video file from a presumably healthy input
file I likely care about lost frames.
I'm not sure whether the current code is
broken per se, but it does look suspicious. Perhaps someone else has a
better idea?
Truncate/pad mis sized frames to allow muxing to continue, and issue a
warning (as at present)?
It is currently quite difficult to ensure that all frames have been
transcoded if there is only a warning in the log message because AFAIK
the only generic way to separate a info log message from a warning is to
parse terminal color code sequences. The other solution would be to
maintain a RegEx black-list of log output messages in the parent process.
Wouldn't it be helpful to introduce some flag option like "-flags
+xerror" on avformat level to toggle between "recover as much as
possible" mode and "encode all or fail" mode?
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
