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