[Live-devel] Bad performance with 4 or more clients at proxy server

Frank van Eijkelenburg frank.van.eijkelenburg at technolution.nl
Fri Jun 5 00:06:09 PDT 2015


Hi Ross,

My original report was not to blame your library. But to make sure I was 
not using the library in a wrong way and to see if other people have the 
same experience. I agree that there are many factors which could 
influence the actual capacity of a network.

Best regards,

Frank van Eijkelenburg

On 05-06-15 00:52, Ross Finlayson wrote:
>>    i have the some problem too and i don't think the problem is 
>> caused by vlc.  when I start multiple VLC players and have them 
>> playing the stream of a ip camera source, it is working fine . if i 
>> start and play them for the remote proxyServer, I will get a bad 
>> performance . i try to increase the socket buffer size but could not 
>> fix it. i also use ffplay.exe to test proxyServer, then i find some 
>> information maybe , the players' frame have a serious time delay, and 
>> vlc always discard the delay frames so why we get the bad performance .
>
> Scalability problems like this are almost always caused by the 
> combined bitrate of the multiple-unicast streams (from the proxy 
> server) approaching or exceeding the capacity of your network.  (Note 
> that when you had multiple VLC players playing a stream from an IP 
> camera, that this was probably a *multicast* stream (because few 
> network cameras support unicast streaming to more than one 
> simultaneous client).  The proxy server, on the other hand, streams to 
> each of its clients via unicast; if it has N concurrent clients, then 
> the stream will be multiplied N times (not counting the additional 
> stream that came from the back-end server).)
>
> People tend to greatly overestimate the capacity of their LANs.  They 
> may see a 100 Mbps or 1 Gbps Ethernet interface on the back of their 
> server computers, and assume that that’s the capacity of their LAN. 
>  Usually not even close.  The actual capacity of a network depends on 
> many factors, including OS and network interface buffering, 
> virtualization (if any), network interface issues, the presence of 
> routers (and even worse, firewalls).
>
> In any case, I’m not planning on responding to any more reports like 
> this unless they can also identify a specific problem with our 
> software that might be responsible.
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
>
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20150605/d2d11b0b/attachment.html>


More information about the live-devel mailing list