Re: [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 |Owner:  (none)
  Momtchev   |
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
 |  undetermined
  Version:  git-master   |   Resolution:
 Keywords:  RTMP |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
Comment (by Momtchil Momtchev):

 Fix available: https://ffmpeg.org/pipermail/ffmpeg-
 devel/2024-February/320623.html
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

Re: [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 |Owner:  (none)
  Momtchev   |
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
 |  undetermined
  Version:  git-master   |   Resolution:
 Keywords:  RTMP |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
Comment (by Momtchil Momtchev):

 Just tested VLC which behaves the same way as the ffmpeg client - it sends
 one last ack after receiving everything that is rejected by the ffmpeg
 server. However VLC does not report an error to the user, it simply hides
 it.
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

Re: [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 |Owner:  (none)
  Momtchev   |
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
 |  undetermined
  Version:  git-master   |   Resolution:
 Keywords:  RTMP |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
Comment (by Momtchil Momtchev):

 I found the reason and it is a design problem:
 https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/HEAD:/fftools/ffmpeg_mux.c#l407

 In the main loop of {{{muxer_thread()}}}, after {{{sch_mux_receive()}}}
 has reported that the input stream is finished, the loop exits, ending the
 pipeline. This is simply how the pipeline works, fixing it here would
 require a major redesign.

 A proper solution would be to implement ACK handling in the RTMP protocol
 and do not return from {{{rtmp_write()}}} until the remote has actually
 acknowledged - taking into account the window. It should buffer the
 window, handle retransmits and block when the remote is lagging.

 An easy fix would be to simply delay the closing in {{{avio_closep()}}} /
 {{{rtmp_close()}}} with a timeout. I wonder if this would have any
 consequences?
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

Re: [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 |Owner:  (none)
  Momtchev   |
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
 |  undetermined
  Version:  git-master   |   Resolution:
 Keywords:  RTMP |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
Comment (by Momtchil Momtchev):

 The parsing of the received acks happens in a muxer thread, while the
 closing of the connection is triggered by {{{of_write_trailer}}} ->
 {{{avio_closep}}} in the main thread. Can you please advise on the thread
 model, I am willing to fix this. Should I delay the closing of the
 connection in {{{avio_closep}}}? This is something that most other
 protocols are likely already doing?
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".

Re: [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 |Owner:  (none)
  Momtchev   |
 Type:  defect   |   Status:  new
 Priority:  normal   |Component:
 |  undetermined
  Version:  git-master   |   Resolution:
 Keywords:  RTMP |   Blocked By:
 Blocking:   |  Reproduced by developer:  0
Analyzed by developer:  0|
-+-
Comment (by Momtchil Momtchev):

 In fact, by going through the code, I have the feeling that at the moment
 the server simply does not care at all about acknowledgments received from
 the client - it parses them but doesn't do anything else.
-- 
Ticket URL: 
FFmpeg 
FFmpeg issue tracker___
FFmpeg-trac mailing list
FFmpeg-trac@avcodec.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-trac

To unsubscribe, visit link above, or email
ffmpeg-trac-requ...@ffmpeg.org with subject "unsubscribe".