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

[Andreas Rheinhardt]

Soft Works:
> 
> 
>> -----Original Message-----
>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
>> James Almer
>> Sent: Tuesday, November 22, 2022 2:31 PM
>> To: ffmpeg-devel at ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [PATCH 3/4] avutil/cuda_check: propagate
>> AVERROR_UNRECOVERABLE when needed
>>
>> 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 at 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?
> 
> Thanks James, for picking this up!
> 
> All I can say is that my original patch is deployed to a quite a
> number of systems and there hasn't been any case where this 
> would have had an adverse effect.
> 
> I hadn't reported this to Nvidia because a solution was needed
> and it was an erroneous file, so the best they could 
> have probably done was to return a different error code ;-)
> 

If this was an erroneous file, then wouldn't it be possible for future
packets to be non-erroneous and therefore decodable?
(An alternative fix for this would be for fftools to calculate how many
errors there were in a row and stop trying to decode a stream that
returns too many errors based upon some option (one could also use the
ratio of successful to non-successful decode calls or something like that).)

- Andreas