On 13.10.2015 08:42, Tomas Härdin wrote:
On Mon, 2015-10-05 at 14:25 +0200, Tobias Rapp wrote:
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?
Possibly. Feels like it'd be tricky to write tests for. But I do see a
point in having a mode where lavf is not allowed to do anything strange,
as it often tends to want to do. But this really touches on some rather
nasty bits of how lavf is (not) structured, and I think it might be
easier if you just keep some local hack for your workflow rather than
try to bring some sanity to the situation..
I agree that it would cause too much impact to add some "lavf mode
switch" that covers the different use-cases. Will work-around it by some
log message pattern matching in my application.
Thanks for taking the time to discuss the issue. I think I have a better
view on the situation now.
Regards,
Tobias
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel