[FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit application when decoding returns AVERROR_EXIT

[James Almer]

On 10/19/2021 3:59 PM, Soft Works wrote:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
>> James Almer
>> Sent: Tuesday, October 19, 2021 4:39 PM
>> To: ffmpeg-devel at ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit
>> application when decoding returns AVERROR_EXIT
>>
>> On 10/19/2021 2:07 AM, Soft Works wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
>>>> Gyan Doshi
>>>> Sent: Tuesday, October 19, 2021 6:51 AM
>>>> To: ffmpeg-devel at ffmpeg.org
>>>> Subject: Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit
>>>> application when decoding returns AVERROR_EXIT
>>>>
>>>>
>>>>
>>>> On 2021-10-19 10:11 am, Soft Works wrote:
>>>>
>>>>> Maybe there's a better way than my patch, but what happens is
>>>>> a bug IMO, and I wouldn't say that it would be a fix to say that
>>>>> a certain option needs to be set by the user to "fix it".
>>>>
>>>> What's ideally required is for user to designate essential and
>>>> non-essential parts of the task. Then some errors can be ignored,
>> and
>>>> some are fatal.
>>>
>>> Yes, and we know when this will happen - haha.
>>>
>>> I guess I'll keep my fix and ffmpeg keeps the bug.
>>
>> You could also just call ffmpeg with the -xerror option in this
>> scenario
>> where cuda is failing. It should abort the process at the exact same
>> point your patch tries to.
> 
> I try to contribute patches based on experience when working
> with ffmpeg for the benefit of other ffmpeg users.
> Though, I have no need for these to get merged as we're always
> running ffmppeg builds from a custom fork, besides that it would
> be nice to keep the differences at a moderate level.
> 
> -xerror is a widely unknown parameter that nobody is using, so it

It exists, and is documented in both texigen and the ffmpeg CLI help 
output. People not being familiar with it doesn't mean fixes should be 
designed in a way as if it didn't exist.

> doesn't help for dealing with this situation. Also it's not
> a fix for a bug to say that it doesn't occur when a certain parameter
> is specified.
> 
> This is not the first situation where my fixes for obvious and
> clear bugs are talked away with great effort, but with zero
> effort and zero interest to find a solution for the actual
> problems they are meant to address.

You didn't ask for alternatives until now, only submitted this patch and 
argued in favor of it. Gyan explained to you why letting a module 
overide a user settable option like xerror is not ok.

If you look at the code where you added the check for AVERROR_EXIT, it 
explicitly ensures it's *not* a decode error before deciding to abort or 
not, because decoders can fail at decoding a packet but easily recover 
after receiving new ones.
The exit_on_error option was added among other reason to override this 
behavior, so i again recommend you to use it.

> 
> I am open to suggestions to fix the issue in a different way.

If the issue is that a CUDA module like cuviddec gets stuck in an 
unrecoverable state with decode/receive_frame calls, regardless of what 
packet or how many you pass to it, then an option could be to somehow 
prevent said module to get stuck like that, by for example adding some 
sort of retry count to ffmpeg CLI, with infinite as default value to 
maintain the current behavior, and make it user configurable. But then 
you could also just use the existing xerror option if you're fine with 
aborting as soon as a single packet fails to decode.

> Otherwise - if you prefer to keep things as they are, we
> get just the result I described above:
> 
> It's fixed for me, but the bugs remain unfixed in ffmpeg.

Why do you think it's a bug? ffmpeg, by design, is explicitly not 
stopping on decoding errors. Your issue is that it prints way too many 
error log lines and you apparently never stop sending it new packets, so 
ffmpeg will keep passing them to cuviddec and it will keep barfing them.
Do you need ffmpeg to output a log at all? You could disable logging 
with -loglevel, or add a way for to ffmpeg not print >= error level log 
messages, if there isn't one already.

> 
> @Paul: I don't see why this would be bad communication, it's just
> a simple factual assessment.
> 
> Kind regards,
> softworkz
> 
> 
> 
> 
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request at ffmpeg.org with subject "unsubscribe".
>