> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@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-boun...@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 <jamr...@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-requ...@ffmpeg.org with subject "unsubscribe".
