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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
