[FFmpeg-devel] [RFC] avformat/mxfenc: stop encoding if unfilled video packet

[tim nicholson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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:
>>>> 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 gue
ss 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 p
acket
>>>>   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 we
ek.)
>>
>> I want to transcode thousands of files and want to get some indicatio
n
>> from ffmpeg if the transcoding has been successful (all frames have b
een
>> transcoded) or not. Currently I am using the process exit code to ver
ify
>> that.
>>
>> There are two different user stories when using ffmpeg:
>> a) "process the input data and exit with error as early as possible i
n
>> case of errors/problems"
>> b) "process the input data and avoid exit with error as long as possi
ble
>> 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 fil
es
>> 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

>> constraints.
> 
> For me the most important thing is that anything dealing with MXF shou
ld
> 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)?


> /Tomas
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 


- -- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJWEiJtAAoJEAwL/ESLC/yDGQAIAJmqWRatBPd/2SXuzyFGWqB2
sg/FBpbzRqFGxr8dOfqfSkwLWu+EUL66UZKu5liVKkeksiUgx4sPtj6DFGFX7ozV
g2DbJxvsFG18ES9C8OHc3qRDsgF4Z+F4GuScWMPrVcyvimSdHeajVkS8slrZlg2Y
tMGQSin5jLwzv1pGIhCOdQLEndrr+PzwajPI837UBW2e7znWDb1uNHBy1yiPzcf+
0pyZluyhkqW6IBzgO34Dc39DfQdGrtDWlzyUacT7nQz/4W5q2KAAhUhBTNtqTabK
KCtSUfpqWgu6P2xxNvi87F9acqYprS80RC/ovrdgsXiXTNGSbYVscY748xg8mgA=
=Clgr
-----END PGP SIGNATURE-----