[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