On Sun, 23 Apr 2023, Anton Khirnov wrote:
Quoting Marton Balint (2023-04-23 11:12:38)
On Sat, 22 Apr 2023, Anton Khirnov wrote:
Quoting Zhao Zhili (2023-04-22 14:56:34)
From: Zhao Zhili <zhiliz...@tencent.com>
Fix #10327.
Signed-off-by: Zhao Zhili <zhiliz...@tencent.com>
---
fftools/ffmpeg_mux.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index a2e8873ad2..0e1a5d7dc5 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -214,9 +214,15 @@ static void *muxer_thread(void *arg)
ost = of->streams[stream_idx];
ret = sync_queue_process(mux, ost, ret < 0 ? NULL : pkt, &stream_eof);
av_packet_unref(pkt);
- if (ret == AVERROR_EOF && stream_eof)
- tq_receive_finish(mux->tq, stream_idx);
- else if (ret < 0) {
+ if (ret == AVERROR_EOF) {
+ if (stream_eof) {
+ tq_receive_finish(mux->tq, stream_idx);
+ } else {
+ av_log(mux, AV_LOG_VERBOSE, "Muxer %s\n", av_err2str(ret));
That seems unnecesarily convoluted, given that we _know_ the error to be
EOF here. Also, please make it "Muxer returned EOF" to make it clear
what exactly is the source of EOF.
Otherwise ok, feel free to push with this change.
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.
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".
