[FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet
tomas.hardin at codemill.se
Sun Oct 4 14:07:54 CEST 2015
On Mon, 2015-09-28 at 15:11 +0200, Tobias Rapp wrote:
> On 19.09.2015 22:49, Tomas Härdin wrote:
> > On Wed, 2015-09-16 at 14:33 +0200, Tobias Rapp wrote:
> >> Hi,
> >> attached patch fixes ticket #4759 but I guess it is a bit too hasty to
> >> always abort transcoding if a single frame cannot be written. I guess it
> >> would be better to check for some "exit_on_error" like flag set but
> >> couldn't find out how to achieve that.
> >> Any comments would be appreciated.
> >> Regards,
> >> Tobias
> >> From 7d6f8de2a411817c970a19d8766e69b6eb604132 Mon Sep 17 00:00:00 2001
> >> From: Tobias Rapp <t.rapp at noa-audio.com>
> >> Date: Mon, 14 Sep 2015 12:06:22 +0200
> >> Subject: [PATCH] avformat/mxfenc: stop encoding if unfilled video packet
> >> occurs
> >> Fixes ticket #4759.
> >> ---
> >> libavformat/mxfenc.c | 14 +++++++++-----
> >> 1 file changed, 9 insertions(+), 5 deletions(-)
> > Is this really better than not writing anything?
> > /Tomas
> (Sorry for the long delay in answering, I was caught by a flu last week.)
> I want to transcode thousands of files and want to get some indication
> from ffmpeg if the transcoding has been successful (all frames have been
> transcoded) or not. Currently I am using the process exit code to verify
> There are two different user stories when using ffmpeg:
> a) "process the input data and exit with error as early as possible in
> case of errors/problems"
> b) "process the input data and avoid exit with error as long as possible
> in case of error/problems"
> If I understand correctly I can basically switch between (a) and (b)
> mode by passing the "-xerror" option to ffmpeg or not. So my plan is to
> transcode all my files with "-xerror" and assume that >99% of the files
> will pass. The small amount of failing ones can then be analyzed for
> problems manually and possibly have a re-run without "-xerror".
> Unfortunately the "-xerror" option affects only ffmpeg but not the
> libraries, so I cannot use it do decide if "mxf_write_packet" should
> return with an error when the video packet size doesn't match the CBR
For me the most important thing is that anything dealing with MXF should
never write invalid files. I'm not sure whether the current code is
broken per se, but it does look suspicious. Perhaps someone else has a
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the ffmpeg-devel