<div dir="ltr">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).<div><br></div><div>So sorry for the thread when Erlang/Beam isn't at fault in the end :)</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 4, 2016 at 2:23 AM, Sergej Jurečko <span dir="ltr"><<a href="mailto:sergej.jurecko@gmail.com" target="_blank">sergej.jurecko@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4 Dec 2016, at 04:42, Matthew Shapiro <<a href="mailto:me@mshapiro.net">me@mshapiro.net</a>> wrote:<br>
><br>
> So I guess VLC is doing something funky on localhost connections that is making prim_inet.send/3 to go into waiting.<br>
<br>
</span>There is only one thing that could be happening, VLC is not reading data from the socket fast enough, causing your side to block.<br>
<br>
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.<br>
<br>
I think your problems have pretty much nothing to do with erlang/elixir.<br>
<br>
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).<br>
<br>
regards,<br>
Sergej</blockquote></div><br></div>