[rtmpdump] librtmp performance and high latency

NhJm nhjm449 at gmail.com
Mon Jan 12 18:05:00 CET 2015


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 at 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 at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/rtmpdump
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.mplayerhq.hu/pipermail/rtmpdump/attachments/20150112/726dedc0/attachment.html>


More information about the rtmpdump mailing list