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

[Marton Balint]

On Mon, 24 Apr 2023, Anton Khirnov wrote:

> Quoting Marton Balint (2023-04-24 20:41:55)
>>
>>
>> On Mon, 24 Apr 2023, Anton Khirnov wrote:
>>
>>> Quoting Marton Balint (2023-04-24 11:09:44)
>>>> The real risk is that they unintentionally do that, when the error code is
>>>> coming from some underlying operation for example.
>>>>
>>>> So previsouly a muxer could return any error code to signal error
>>>> condition and reasonably assume that ffmpeg.c will report it back to the
>>>> user as an error.
>>>>
>>>> The change in ffmpeg.c "forces" muxers to check if they ever get
>>>> AVERROR_EOF for some real error condition and map them to
>>>> e.g. AVERROR(EIO). And that is an API change.
>>>
>>> I don't follow, how is fixing bugs in muxers in any way an API change?
>>
>> The API change is that muxers are no longer allowed to return AVERROR_EOF
>> for an error condition.
>
> I still don't follow - what is the API that is being changed?

av_interleaved_write_frame(). Previously any negative return value was an 
error condition. This change assumes that AVERROR_EOF return value is a 
non-error condition.

>
> Besides, I don't think that was ever a valid thing to do anyway.

The error codes a muxer can use is not explicitly documented, so one 
could reasonably assume that any negative error code is valid. And 
ffmpeg.c worked that way for a long time, doc/examples/mux.c still works 
that way.

Regards,
Marton