On Fri, 3 Feb 2023, Gyan Doshi wrote:
On 2023-02-03 04:17 am, Marton Balint wrote:
On Thu, 2 Feb 2023, Gyan Doshi wrote:
Prior to 2d924b3a630, ffmpeg.c would exit if any packet write failed.
tee's
write_packet seemingly relied on that to enforce its abort failure
policy.
From 2d924b3a630, ffmpeg only closes that OutputStream and keeps on
sending packets of other streams.
Hmm, are you sure? I glanced at the code and it seems to me that any
failure of av_interleaved_write_frame() will cause the muxing thread to
exit. So I don't quite see how other streams can receive packets.
Steps to reproduce:
1) ffmpeg -readrate 1 -stream_loop -1 -i INPUT -map 0:v -map 0:a -c copy -f
tee "[f=flv:onfail=abort]rtmp://url/playpath|[f=null:onfail=ignore]stub"
2) Kill the rtmp endpoint at the server side. The tee muxer logs that it's
aborting, however, ffmpeg keeps running. Contrast with 5.1 or earlier, which
exit.
av_iwf returns EOF which just results in a call to tq_receive_finish() for
that ost without breaking muxer_thread's loop.
Any av_interleaved_write_frame() negative return value is an error, ffmpeg
should abort. It seems that there is a clash of error codes in
sync_queue_process which returns AVERROR_EOF to signal sq_send EOF return,
but that clashes with the AVERROR_EOF of av_interleaved_write_frame(), so
the error condition is lost.
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".
