[erlang-questions] Troubling gen_tcp.send/3 performance

[Matthew Shapiro]

Yeah I think I can safely say this is something to do with how VLC is
functioning.  Even remotely I'm getting stuck in send, though not as bad,
and looking at what's going on in the difference between VLC and Ffmpeg I
believe my timestamps are being unexpected and both are reacting weirdly
too it, with VLC trying to slow the feed down for whatever reason and that
may be causing it to be slow to do a TCP read.  Shot in the dark but at
least I know now that it's not an BEAM issue (and my time on this hasn't
been to waste).

So sorry for the thread when Erlang/Beam isn't at fault in the end :)

On Sun, Dec 4, 2016 at 2:23 AM, Sergej Jurečko <sergej.jurecko@REDACTED>
wrote:

> On 4 Dec 2016, at 04:42, Matthew Shapiro <me@REDACTED> wrote:
> >
> > So I guess VLC is doing something funky on localhost connections that is
> making prim_inet.send/3 to go into waiting.
>
> There is only one thing that could be happening, VLC is not reading data
> from the socket fast enough, causing your side to block.
>
> Unless there is a bug in windows (or any possible virtualization if it is
> being used), which is possible as we've encountered it once and it resulted
> in similar behavior.
>
> I think your problems have pretty much nothing to do with erlang/elixir.
>
> This is a bit off topic, but why RTMP? Pretty much everything is or has
> moved to HLS/DASH. HLS especially will work on practically every client
> (all major browsers, all relevant mobiles).
>
> regards,
> Sergej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20161204/b573495c/attachment.htm>