[FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet
nichot20 at yahoo.com
Mon Oct 5 09:10:37 CEST 2015
-----BEGIN PGP SIGNED MESSAGE-----
On 04/10/15 13:07, Tomas Härdin wrote:
> 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:
>>>> attached patch fixes ticket #4759 but I guess it is a bit too hasty
>>>> always abort transcoding if a single frame cannot be written. I gue
>>>> 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.
>>>> From 7d6f8de2a411817c970a19d8766e69b6eb604132 Mon Sep 17 00:00:00
>>>> 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 p
>>>> Fixes ticket #4759.
>>>> libavformat/mxfenc.c | 14 +++++++++-----
>>>> 1 file changed, 9 insertions(+), 5 deletions(-)
>>> Is this really better than not writing anything?
>> (Sorry for the long delay in answering, I was caught by a flu last we
>> I want to transcode thousands of files and want to get some indicatio
>> from ffmpeg if the transcoding has been successful (all frames have b
>> transcoded) or not. Currently I am using the process exit code to ver
>> There are two different user stories when using ffmpeg:
>> a) "process the input data and exit with error as early as possible i
>> case of errors/problems"
>> b) "process the input data and avoid exit with error as long as possi
>> 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
>> transcode all my files with "-xerror" and assume that >99% of the fil
>> 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 shou
> never write invalid files.
+1 for sure.
> 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)?
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
-----END PGP SIGNATURE-----
More information about the ffmpeg-devel