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

[Tobias Rapp]

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