> -----Original Message----- > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of > Timo Rothenpieler > Sent: Tuesday, November 22, 2022 4:16 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 3/4] avutil/cuda_check: propagate > AVERROR_UNRECOVERABLE when needed > > > > On 22/11/2022 14:31, James Almer wrote: > > 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? > > It's more that that very much depends on the context the function is > used in. > In the context of an active de/encoding loop, every non-success > return > would be unrecoverable. Or even during init. > > While in other places a failure just breaks a single frame and if it > somehow recovery, it can continue on. Though that's usually the > exception.
Can you give an example for this in ffmpeg where CUDA returns an error and ffmpeg continues? At the time when I had submitted the patch, I had replied this to James after he had argued that the behavior would be correct as is and a user who would want ffmpeg to exit in such case, must specify the -xerror parameter. softworkz: > When there's an error in a filter => ffmpeg exits > When there's an error in an encoder => ffmpeg exits > When there's an error initializing a decoder or an encoder > => ffmpeg exits > > So why shouldn't ffmpeg exit when there's an unrecoverable error > in a decoder? AFAIR, in case of filtering and encoding, any "normal" CUDA error is already sufficient to cause ffmpeg to exit. > In any case, this function does not seem the right place to map an > arbitrary return code to such a result. That depends on whether you consider CUDA_ERROR_UNKNOWN as generally unrecoverable. When you do - like I did - then it's the right place IMO. If you doubt it, then yes - it wouldn't be the right place. Best regards, 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".
