[FFmpeg-devel] [PATCH] avformat/tee: signal EOF if no more output is to be published.
Marton Balint
cus at passwd.hu
Fri Feb 3 10:32:47 EET 2023
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
More information about the ffmpeg-devel
mailing list