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