Hi, I'm using a windows build of ffmpeg from zeranoe which uses librtmp. There is a long standing problem that I'm trying to fix. There is a case on the ffmpeg bug tracker: https://trac.ffmpeg.org/ticket/1604 And a related thread on the forum: http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=657&sid=276f96e2c4ff9f62a2733007f2e82e1c I've posted on both. The basic problem is that RTMP_SendPacket() writes to the socket in 128 byte chunks, and when the destination server has a long RTT the stream stalls. I've tested with a simple fix - there is code there to buffer the chuncks for HTTP, but if the buffering is enabled for all sends, the whole packet is written to the socket, and the stream works much better. I'd really like to get this or something like it into a patch. I think it may fix this problem. Anybody have any feedback on this? Thanks, Cary
You might try increasing SO_SNDBUF in RTMP_Connect0. The default send buffer in Windows seems to be practically nothing (8192, I believe). Other workarounds do exist for this problem: http://strikerx3.blogspot.com.br/2014/12/tcprelay-is-now-open-source.html http://www.dest-unreach.org/socat/ -NhJm On Fri, Jan 9, 2015 at 7:01 PM, <ctetrick@satx.rr.com> wrote:
Hi, I'm using a windows build of ffmpeg from zeranoe which uses librtmp. There is a long standing problem that I'm trying to fix.
There is a case on the ffmpeg bug tracker: https://trac.ffmpeg.org/ticket/1604
And a related thread on the forum:
http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=657&sid=276f96e2c4ff9f62a2733007f2e82e1c
I've posted on both.
The basic problem is that RTMP_SendPacket() writes to the socket in 128 byte chunks, and when the destination server has a long RTT the stream stalls. I've tested with a simple fix - there is code there to buffer the chuncks for HTTP, but if the buffering is enabled for all sends, the whole packet is written to the socket, and the stream works much better.
I'd really like to get this or something like it into a patch. I think it may fix this problem.
Anybody have any feedback on this?
Thanks, Cary _______________________________________________ rtmpdump mailing list rtmpdump@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/rtmpdump
That ended up being exactly what I did. I can also do this after connecting in ffmpeg in the open function of librtmp.c The issue for me is that using a tcp relay really complicates things for me. I need the option in the ffmpeg.exe file and would rather use an "official" build. But thanks, my original "fix" is unnecessary. ---- NhJm <nhjm449@gmail.com> wrote:
You might try increasing SO_SNDBUF in RTMP_Connect0. The default send buffer in Windows seems to be practically nothing (8192, I believe).
Other workarounds do exist for this problem: http://strikerx3.blogspot.com.br/2014/12/tcprelay-is-now-open-source.html http://www.dest-unreach.org/socat/
-NhJm
On Fri, Jan 9, 2015 at 7:01 PM, <ctetrick@satx.rr.com> wrote:
Hi, I'm using a windows build of ffmpeg from zeranoe which uses librtmp. There is a long standing problem that I'm trying to fix.
There is a case on the ffmpeg bug tracker: https://trac.ffmpeg.org/ticket/1604
And a related thread on the forum:
http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=657&sid=276f96e2c4ff9f62a2733007f2e82e1c
I've posted on both.
The basic problem is that RTMP_SendPacket() writes to the socket in 128 byte chunks, and when the destination server has a long RTT the stream stalls. I've tested with a simple fix - there is code there to buffer the chuncks for HTTP, but if the buffering is enabled for all sends, the whole packet is written to the socket, and the stream works much better.
I'd really like to get this or something like it into a patch. I think it may fix this problem.
Anybody have any feedback on this?
Thanks, Cary _______________________________________________ rtmpdump mailing list rtmpdump@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/rtmpdump
So what's the final patch here? Did it fix things? On 1/21/15, ctetrick@satx.rr.com <ctetrick@satx.rr.com> wrote:
That ended up being exactly what I did. I can also do this after connecting in ffmpeg in the open function of librtmp.c
The issue for me is that using a tcp relay really complicates things for me.
I need the option in the ffmpeg.exe file and would rather use an "official" build.
But thanks, my original "fix" is unnecessary.
---- NhJm <nhjm449@gmail.com> wrote:
You might try increasing SO_SNDBUF in RTMP_Connect0. The default send buffer in Windows seems to be practically nothing (8192, I believe).
Other workarounds do exist for this problem: http://strikerx3.blogspot.com.br/2014/12/tcprelay-is-now-open-source.html http://www.dest-unreach.org/socat/
-NhJm
On Fri, Jan 9, 2015 at 7:01 PM, <ctetrick@satx.rr.com> wrote:
Hi, I'm using a windows build of ffmpeg from zeranoe which uses librtmp. There is a long standing problem that I'm trying to fix.
There is a case on the ffmpeg bug tracker: https://trac.ffmpeg.org/ticket/1604
And a related thread on the forum:
http://ffmpeg.zeranoe.com/forum/viewtopic.php?f=7&t=657&sid=276f96e2c4ff9f62a2733007f2e82e1c
I've posted on both.
The basic problem is that RTMP_SendPacket() writes to the socket in 128 byte chunks, and when the destination server has a long RTT the stream stalls. I've tested with a simple fix - there is code there to buffer the chuncks for HTTP, but if the buffering is enabled for all sends, the whole packet is written to the socket, and the stream works much better.
I'd really like to get this or something like it into a patch. I think it may fix this problem.
Anybody have any feedback on this?
Thanks, Cary _______________________________________________ rtmpdump mailing list rtmpdump@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/rtmpdump
_______________________________________________ rtmpdump mailing list rtmpdump@mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/rtmpdump
participants (3)
-
ctetrick＠satx.rr.com -
NhJm -
Roger Pack