[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