Cant use Highest Quality Setting on Meeting Webcast Software

[ksolsen]

We don't throttle the connection. There may be differences in the Internet traffic paths between normal speed tests and the CHQ speed test server.

[russellhltn]

We don't throttle the connection. There may be differences in the Internet traffic paths between normal speed tests and the CHQ speed test server.

I'm sure there's more, but I did find this old thread

Trying right now at work:
Download Speed: 12087 kbps (1510.9 KB/sec transfer rate) (Interesting, I think I only got 7 or so a couple of hours ago.)
Upload Speed: 10196 kbps (1274.5 KB/sec transfer rate)

Speedtest.net (local)
Download: 44.68 Mbps
Upload: 39:06 Mbps

Speedtest.net to Comcast in SLC
Download 36.55 Mbps
Upload: 9.78 Mbps

I'm not sure as anyone is intending to limit, but there are in fact significant limits when it comes to church servers. Anyone trying to max out the quality may well run into problems from server connection limits.

[lajackson]

Oops - typo on my part. 50Mbps, not 50GB. But still...

In another thread it was reported that you can only get about 30Mbps through the 881W firewall.

In any event, as was earlier posted, if your receiving location cannot swallow the fast stream, it will choke with varying results.

[russellhltn]

One important thing to be aware of - you may have massive amounts of upload speed at your stake center / broadcast site, but if the receiving site doesn't have a matching download speed, the receiving site will exhaust its buffer and either freeze the video or you'll get nothing at all.

So you're saying the server can't down convert the stream to dynamically meet the ability of the receiving sites? It's up to the broadcaster to pick a setting that will work for the slowest of sites?

[johnshaw]

I'm not sure as anyone is intending to limit, but there are in fact significant limits when it comes to church servers. Anyone trying to max out the quality may well run into problems from server connection limits.

We have too much evidence that the church firewall is where the bottleneck is, it is not the church servers, neither is it a VPN connection because the streams don't ride the vpn, they access church servers direction across the Internet.

As I recall the threads were even more specifically related to 'streaming' technologies being affected more than others. The church is aware of the issue, indicated from the threads.

[Mikerowaved]

So you're saying the server can't down convert the stream to dynamically meet the ability of the receiving sites? It's up to the broadcaster to pick a setting that will work for the slowest of sites?

That's correct. Some streaming services encode multiple bit rates and can dynamically switch bit rates on-the-fly, depending on conditions. The webcast communicator and meetinghouse webcast software encode ONE bit rate, which is selected prior to the start of the webcast. The church servers simply "fan" that stream out to multiple receive sites, but they don't alter it. In other words, whatever bit rate you select for the upload is what all the receive sites will see and have to deal with.

[heyring]

WE do speedtest before connecting to the salt lake streamers and we get 37 down and 26 up with our business class cable from Cox.

We have done the same test at all three other buildings and have gotten no less than 20mb down in each,

Even with our streamer pushing up its fattest signal, we still get 19 up and 25down,

[russellhltn]

WE do speedtest before connecting to the salt lake streamers and we get 37 down and 26 up with our business class cable from Cox.

Are you using speedtest.lds.org? For the purposes of a broadcast, I think that would be more accurate.

[heyring]

I am going to go and verify what our current numbers are at every building this evening.. But I have checked since our last bandwidth numbers and everything far exceeds the numbers both in the application and that I have seen as requirements on tech.lds.org.

I will post what our numbers are after I go around and get them from all 4 buildings.