[FFmpeg-trac] #10565(undetermined:new): Error submitting a packet to the muxer: Broken pipe, Error muxing a packet

[FFmpeg]

#10565: Error submitting a packet to the muxer: Broken pipe, Error muxing a packet
-------------------------------------+-------------------------------------
             Reporter:  Rob          |                    Owner:  (none)
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:  Error        |               Blocked By:
  submitting a packet to the muxer:  |
  Broken pipe, Error muxing a        |
  packet                             |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by Rob):

 Hi Steven,

 I have follow up question for you and since you originally replied it
 appears that you have a great understanding of this (much better than I
 do).

 I am experiencing another issue related to this and I am hoping you can
 shed some light on it.

 Both nginx RTMP and SRS developers put in workarounds on the server to now
 blow up when this condition is hit:

 (from the developer)

 "FFmpeg sends a buggy AMF0 structure when -map option is used: the AMF
 type is 0x00, it means it is a number and the following 8 bytes are used
 to represent a number, but there are only 3 bytes left."

 However, it seems like after this condition is hit ffmpeg stops sending
 some information that the server determines if the client is still alive.

 Both nginx RTMP and SRS have a "drop idle publisher" option:

 drop_idle_publisher 5s;

 We set this so publishers that legitimately stop will be dropped.

 However, in the case of FFMPEG is it still sending RTMP data but the
 server thinks it's dead and will drop it. This is what the nginx rtmp
 developer said:

 "Debug logs in nginx's error.log showed that FFmpeg indeed didn't send any
 messages in 5s after malformed AMF was sent."

 Do you have any insight as to why the "map" function stops sending the
 data that the server needs to determine that the client is still
 connected.

 Even though the server developers put in workarounds for the bug in
 ffmpeg, it seems that there is an underlying issue that happens after that
 bug condition is met.

 Thanks for your time.

 -Rob
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/10565#comment:12>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker