[FFmpeg-trac] #10838(undetermined:new): RTMP protocol, ffmpeg to ffmpeg, always ends with a connection reset (broken pipe)

[FFmpeg]

#10838: RTMP protocol, ffmpeg to ffmpeg, always ends with a connection reset
(broken pipe)
-------------------------------------+-------------------------------------
             Reporter:  Momtchil     |                     Type:  defect
  Momtchev                           |
               Status:  new          |                 Priority:  normal
            Component:               |                  Version:  git-
  undetermined                       |  master
             Keywords:  RTMP         |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
 When using ffmpeg as a server and ffmpeg as a client, RTMP streaming
 always ends with a connection reset.

 The bug is present since at least 4.4.2 in Ubuntu 22.04 to the latest git
 of today.

 The server sends its data, then once it is finished, it immediately closes
 its end. The TCP connection remains in a half-closed state. The client
 continues reading and at the end sends an {{{RTMP_PT_BYTES_READ}}} (called
 an Acknowledgment, type 3, in the offical specs) message which causes the
 remote end to reply with a TCP {{{RST}}} packet. This renders checking for
 errors difficult, as there is no nominal case - the error is always
 expected.

 How to reproduce:
 {{{
 ./ffmpeg -i input.mp4 -f flv -ar 44100 -flvflags no_duration_filesize \
   -listen 1 rtmp://localhost:9099/video

 ./ffmpeg -y -i rtmp://localhost:9099/video output.mp4
 }}}

 I was not able to find anything on the connection teardown in the
 specifications:
 https://rtmp.veriskope.com/docs/spec/#543acknowledgement-3

 But given the wording of the acknowledgment section, I will be inclined to
 say that this is the server's fault - since it has to expect that the
 client will ack its last packet - which means that it should keep its end
 open until this ack is received.
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10838>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker