[Live-devel] scaling live555 rtsp proxy to hundreds of viewers.

[Pete Pulliam]

I have an implementation of an rtsp proxy server based on the
live555ProxyServer that ships with the live555 source.  When connecting
only a couple of viewers to a single proxied stream, things look great.
I'm hoping to get a few hundred viewers per stream though.  What I'm seeing
is that there is a large drop off in quality and kbps as I add more
viewers.  I see this drop off both with the custom proxy I've written and
the stock proxy that ships with the source.

While this is happening, the CPU and memory are only lightly used, and the
NIC is not that busy.

I'm trying to use this to shield a transcoder that provides an RTSP origin
(as well as several other formats).  When I run the same test directly
against the origin I don't see a drop off in quality like this for viewers
less than 50 (and haven't tested that for more than 50 viewers).  Hitting
the origin directly looks great.

Is there perhaps something I should have tuned in the proxy, or could tune
with the Linux box this is running on that is causing this drop off?
Advice wanted to improve the scaling of single stream => many viewer.

The kbps drop off looks like:
# ​
of clients
​ , ​
bitrate (kbps)
2 977.688820
3 976.666311
4 936.494160
5 940.096328
6 944.486316
7 955.723431
8 945.044076
9 944.803396
10 930.465372
11 925.247045
12 931.066158
13 713.205068
14 486.331708
15 492.473134
16 485.362249
17 483.711453
18 490.636454
19 485.919289
20 487.862608
21 489.587224

Pete

-- 
The information in this message may be confidential.  It is intended solely 
for
the addressee(s).  If you are not the intended recipient, any disclosure,
copying or distribution of the message, or any action or omission taken by 
you
in reliance on it, is prohibited and may be unlawful.  Please immediately
contact the sender if you have received this message in error.

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