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

[James Almer]

On 11/22/2022 11:33 AM, Soft Works wrote:
> 
> 
>> -----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 ;-)
> 
> softworkz

Can you be more specific about what kind of erroneous file it was? Are 
we talking about a completely broken stream where no packet was valid 
and even the software decoder would fail, or something that had one 
invalid packet that somehow chocked the nvdec to the point not even an 
IDR picture triggering a refresh would fix it?

If this is the former, then what you encountered was not the decoder 
entering an unrecoverable state, but just properly rejecting bad input, 
and then this patch would probably not be correct.