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

[Soft Works <softworkz@hotmail.com>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> Andreas Rheinhardt
> Sent: Tuesday, November 22, 2022 3:48 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 3/4] avutil/cuda_check: propagate
> AVERROR_UNRECOVERABLE when needed
> 
> Soft Works:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of
> >> James Almer
> >> Sent: Tuesday, November 22, 2022 2:31 PM
> >> To: ffmpeg-devel@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@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).)

That error isn't a normal decode error. Those exist as well and it 
can recover from these.
But from all experiments I did, my conclusion was that this 
is an error of final death. AFAIR.

Thanks,
softworkz





_______________________________________________
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".