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

[Marton Balint]

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.

>
>> This is what is documented. ffmpeg.c followed this approach. Don't you
>> see the slightest problem if we suddenly change this?
>
> Seems to me you're mixing ffmpeg CLI and lavf behavior. My claim is
> entirely from the point of view of the CLI, and is this: if the muxer
> returns AVERROR_EOF, then it should be treated as normal termination.

I disagree. If ffmpeg.c ignores a specific muxer error code for whatever 
reason, that is a bug. At least it should fail if -xerror is given.

> This is similar to how other components behave - e.g. a (bitstream)
> filter can at any time decide to return EOF to its downstream,
> terminating a stream even though more input is available.

And for bitstream filters it is properly documented, and callers were 
always expected to act accordingly.

Regards,
Marton