[FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit application when decoding returns AVERROR_EXIT
Soft Works
softworkz at hotmail.com
Wed Oct 20 03:53:01 EEST 2021
> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> James Almer
> Sent: Tuesday, October 19, 2021 10:51 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit
> application when decoding returns AVERROR_EXIT
> You didn't ask for alternatives until now, only submitted this patch
> and
> argued in favor of it.
No that's not true, I already said
"Maybe there's a better way than my patch, .."
> explicitly ensures it's *not* a decode error before deciding to abort
> or
> not, because decoders can fail at decoding a packet but easily
> recover
> after receiving new ones.
Yes, that's why I'm returning an error code for this case that
clearly indicates that it is an unrecoverable error.
> > I am open to suggestions to fix the issue in a different way.
>
> If the issue is that a CUDA module like cuviddec gets stuck in an
> unrecoverable state with decode/receive_frame calls, regardless of
> what
> packet or how many you pass to it, then an option could be to somehow
> prevent said module to get stuck like that, by for example adding
> some
> sort of retry count to ffmpeg CLI, with infinite as default
Why does an unrecoverable error need retries?
> Why do you think it's a bug? ffmpeg, by design, is explicitly not
> stopping on decoding errors.
This is not a decoding error, it's a decoder error and surely not
the intended kind of case where ffmpeg should continue.
> Do you need ffmpeg to output a log at all?
How should I be able to diagnose and discover such bugs without
outputting a log?
Kind regards,
softworkz
More information about the ffmpeg-devel
mailing list