[FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit application when decoding returns AVERROR_EXIT

[Soft Works]

> -----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
> 
> On 10/19/2021 3:59 PM, Soft Works wrote:
> >
> >
> >> -----Original Message-----
> >> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> >> James Almer
> >> Sent: Tuesday, October 19, 2021 4:39 PM
> >> To: ffmpeg-devel at ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit
> >> application when decoding returns AVERROR_EXIT
> >>
> >> On 10/19/2021 2:07 AM, Soft Works wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf
> Of
> >>>> Gyan Doshi
> >>>> Sent: Tuesday, October 19, 2021 6:51 AM
> >>>> To: ffmpeg-devel at ffmpeg.org
> >>>> Subject: Re: [FFmpeg-devel] [PATCH 1/2] fftools/ffmpeg: exit
> >>>> application when decoding returns AVERROR_EXIT
> >>>>
> >>>>
> >>>>
> >>>> On 2021-10-19 10:11 am, Soft Works wrote:
> >>>>
> >>>>> Maybe there's a better way than my patch, but what happens is
> >>>>> a bug IMO, and I wouldn't say that it would be a fix to say
> that
> >>>>> a certain option needs to be set by the user to "fix it".
> >>>>
> >>>> What's ideally required is for user to designate essential and
> >>>> non-essential parts of the task. Then some errors can be
> ignored,
> >> and
> >>>> some are fatal.
> >>>
> >>> Yes, and we know when this will happen - haha.
> >>>
> >>> I guess I'll keep my fix and ffmpeg keeps the bug.
> >>
> >> You could also just call ffmpeg with the -xerror option in this
> >> scenario
> >> where cuda is failing. It should abort the process at the exact
> same
> >> point your patch tries to.
> >
> > I try to contribute patches based on experience when working
> > with ffmpeg for the benefit of other ffmpeg users.
> > Though, I have no need for these to get merged as we're always
> > running ffmppeg builds from a custom fork, besides that it would
> > be nice to keep the differences at a moderate level.
> >
> > -xerror is a widely unknown parameter that nobody is using, so it
> 
> It exists, and is documented in both texigen and the ffmpeg CLI help
> output. People not being familiar with it doesn't mean fixes should
> be
> designed in a way as if it didn't exist.

Yes, but were not talking about a transient error here, where there
would be a choice about whether to continue.

We're talking about an unrecoverable decoder error and currently,
this is causing ffmpeg to get into an ENDLESS LOOP (or at least
almost endless) where ffmpeg will only exit once the HD is full 
from its log output.

And you want to tell that this behavior is correct and that a user
needs to be aware of the -xerror parameter and specify it to 
prevent this from happening?

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?


In our use case of ffmpeg, we are auto-building an extremely wide
range of ffmpeg commands with and without hw accelerations (and 
from these - most of which ffmpeg supports).

Over the years, I have looked at more than a thousand log files
from users.
And I haven't seen a single case like this before, where ffmpeg 
doesn't exit when an error occurs with some hw acceleration and
continues to output millions of times the same 2 lines to the log.

softworkz