[FFmpeg-devel] [PATCH v2] fftools/ffmpeg_mux: fix reporting muxer EOF as error

[Anton Khirnov]

Quoting Marton Balint (2023-04-23 20:15:13)
> 
> 
> On Sun, 23 Apr 2023, Anton Khirnov wrote:
> 
> > Quoting Marton Balint (2023-04-23 12:05:51)
> >>
> >>
> >> On Sun, 23 Apr 2023, Anton Khirnov wrote:
> >>
> >>> Quoting Marton Balint (2023-04-23 11:42:48)
> >>>> On Sun, 23 Apr 2023, Anton Khirnov wrote:
> >>>>> Quoting Marton Balint (2023-04-23 11:12:38)
> >>>>>> This seems like yet another clash of AVERROR_EOF error codes coming from
> >>>>>> different places with different semantics. For
> >>>>>> av_interleaved_write_frame(), AVERROR_EOF is an error condition, so
> >>>>>> file encoding should fail,
> >>>>>
> >>>>> Why should it fail? I'd think a muxer returning EOF is the way to signal
> >>>>> non-error muxer-side termination.
> >>>>
> >>>> That would be an API change. AVERROR_EOF is not special in any way from
> >>>> other error codes for av_interleaved_write_frame. A muxer cannot signal
> >>>> non-error muxer side termination with existing API.
> >>>
> >>> All error codes (should) have a specific meaning. I cannot think of a
> >>> good reason for a muxer to return AVERROR_EOF to signal an error.
> >>> Can you?
> >>
> >> Previously, we expeced users to treat any negative error code as error for
> >> av_interleaved_write_frame().
> >
> > I don't think we expect the users to do anything in particular in
> > responce to av_interleaved_write_frame() return codes. The doxy says
> > that it returns a negative error code on error, but the caller can
> > freely decide what to do with that information - this includes ignoring
> > it.
> 
> I don't understand. A good program propagates back error conditions to the 
> user, and not hides them silently.

I do not think blanket claims such as this are a good idea. What is or
is not considered "an error condition" depends on the context.

As I said before - I don't see why a muxer should ever return
AVERROR_EOF to signal a legitimate muxing error.

-- 
Anton Khirnov