Re: [FFmpeg-devel] [PATCH 3/4] avutil/cuda_check: propagate AVERROR_UNRECOVERABLE when needed

[Timo Rothenpieler <timo@rothenpieler.org>]

On 22.11.2022 17:02, Soft Works wrote:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
>> Timo Rothenpieler
>> Sent: Tuesday, November 22, 2022 4:16 PM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 3/4] avutil/cuda_check: propagate
>> AVERROR_UNRECOVERABLE when needed
>>
>>
>>
>> On 22/11/2022 14:31, James Almer wrote:
>>> On 11/22/2022 10:21 AM, Timo Rothenpieler wrote:
>>>> On 22/11/2022 14:07, James Almer wrote:
>>>>> Based on a patch by Soft Works.
>>>>>
>>>>> Signed-off-by: James Almer <jamrial@gmail.com>
>>>>> ---
>>>>>    libavutil/cuda_check.h | 4 ++++
>>>>>    1 file changed, 4 insertions(+)
>>>>>
>>>>> diff --git a/libavutil/cuda_check.h b/libavutil/cuda_check.h
>>>>> index f5a9234eaf..33aaf9c098 100644
>>>>> --- a/libavutil/cuda_check.h
>>>>> +++ b/libavutil/cuda_check.h
>>>>> @@ -49,6 +49,10 @@ static inline int ff_cuda_check(void *avctx,
>>>>>            av_log(avctx, AV_LOG_ERROR, " -> %s: %s", err_name,
>>>>> err_string);
>>>>>        av_log(avctx, AV_LOG_ERROR, "\n");
>>>>> +    // Not recoverable
>>>>> +    if (err == CUDA_ERROR_UNKNOWN)
>>>>> +        return AVERROR_UNRECOVERABLE;
>>>>
>>>> Why does specifically CUDA_ERROR_UNKNOWN get mapped to
>> unrecoverable?
>>>
>>> It's the code that Soft Works found out was returned repeatedly no
>>> matter how many packets you fed to the encoder, which meant it was
>> stuck
>>> in an unrecoverable state. See
>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2021-October/287153.html
>>>
>>> If you know of cases where this error could be returned in valid
>>> recoverable scenarios that are not already handled in some other
>> way,
>>> what do you suggest could be done?
>>
>> It's more that that very much depends on the context the function is
>> used in.
>> In the context of an active de/encoding loop, every non-success
>> return
>> would be unrecoverable. Or even during init.
>>
>> While in other places a failure just breaks a single frame and if it
>> somehow recovery, it can continue on. Though that's usually the
>> exception.
> 
> Can you give an example for this in ffmpeg where CUDA returns an
> error and ffmpeg continues?

Almost all the filters will continue when one filtering step fails.

> At the time when I had submitted the patch, I had replied this to James
> after he had argued that the behavior would be correct as is and
> a user who would want ffmpeg to exit in such case, must specify
> the -xerror parameter.
> 
> 
> softworkz:
>> When there's an error in a filter => ffmpeg exits
>> When there's an error in an encoder => ffmpeg exits
>> When there's an error initializing a decoder or an encoder
>> => ffmpeg exits
>>
>> So why shouldn't ffmpeg exit when there's an unrecoverable error
>> in a decoder?
> 
> 
> AFAIR, in case of filtering and encoding, any "normal" CUDA
> error is already sufficient to cause ffmpeg to exit.
> 
> 
>> In any case, this function does not seem the right place to map an
>> arbitrary return code to such a result.
> 
> That depends on whether you consider CUDA_ERROR_UNKNOWN as
> generally unrecoverable. When you do - like I did - then
> it's the right place IMO.
> 
> If you doubt it, then yes - it wouldn't be the right place.

Why is the function not unconditionally returning an unrecoverable error 
then?
Like, 90% of current error returns, independent of CUDA, in 
filters/codecs can be considered UNRECOVERABLE then. Which does make 
sense that you want them to about.
But you in turn give up the informational character of error codes.

Makes me think this should be some kind of additional flag instead.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".