Broadcasting stake conference - question 1

We are interested in setting up the simulcast of stake conference to other buildings in the stake. As soon as the current project (getting the clerk machines hooked up to the FHC connections) is completed we'll be taking on the big issue.

First and most important question: how much bandwidth is needed at each end. For starters let's assume one building broadcasting to one building. Add in enough overhead to allow three clerk machines to be doing simultaneous transmits.

Will 1Mb SDSL do the trick or should it be 1.5? For the receiving building will a 1.5/734 ADSL connection do the trick?

I'm puzzled by your overhead requirements. Why would any clerk machines be doing transmits during stake conference?

Convenience of a commonly understood resource use more than anything - just in CASE there is network use (setting MLS to download a large patch, the future probability that these machines will grab windows updates or virus definition updates) I want to make sure there is enough padding to ensure smooth transmission. Or perhaps they set something running just before conference... not really worried about what they're doing, I just want to make sure the video runs smoothly.

aclawson wrote:Convenience of a commonly understood resource use more than anything - just in CASE there is network use (setting MLS to download a large patch, the future probability that these machines will grab windows updates or virus definition updates) I want to make sure there is enough padding to ensure smooth transmission. Or perhaps they set something running just before conference... not really worried about what they're doing, I just want to make sure the video runs smoothly.

When we do our building to building simulcasts, I physically take the Cisco firewall offline, which eliminates any possibility of bandwidth contention from computers in the building, since all connections that could have a computer connected to them, hang off of the firewall. The DSL modem has an integrated router, so I'm able to connect both Slingboxes to it. So far, we haven't actually tried dual feeds using both Slingboxes concurrently. I'll be testing that soon because the Stake Pres. wants to transmit to two buildings in September. Our DSL is 1.5/734 and the 734 upstream bandwidth has given us a high quality feed. The Slingbox adjusts video quality based on available bandwidth. I'll report back here on how the dual feed test goes.

danpass wrote:When we do our building to building simulcasts, I physically take the Cisco firewall offline, which eliminates any possibility of bandwidth contention from computers in the building, since all connections that could have a computer connected to them, hang off of the firewall. The DSL modem has an integrated router, so I'm able to connect both Slingboxes to it. So far, we haven't actually tried dual feeds using both Slingboxes concurrently. I'll be testing that soon because the Stake Pres. wants to transmit to two buildings in September. Our DSL is 1.5/734 and the 734 upstream bandwidth has given us a high quality feed. The Slingbox adjusts video quality based on available bandwidth. I'll report back here on how the dual feed test goes.

If you have difficulties with sending from one building to two others, it might be worth trying sending from building A to building B, then relaying from building B to building C. There may be situations in which relaying might work better than the 1->2 configuration.

danpass wrote:When we do our building to building simulcasts, I physically take the Cisco firewall offline...

Isn't this a fundamental violation of the Church's network security policies?

denleyan wrote:Isn't this a fundamental violation of the Church's network security policies?

I think he means he shuts down all internet bound traffic, not disable the firewall as to allow any traffic. If on the odd chance an MLS PC needs to do a send/receive during this period, it will have to revert to dial-up.

denleyan wrote:Isn't this a fundamental violation of the Church's network security policies?

I suppose from a technical standpoint it is - but if a slingbox is only thing connected to the DSL/Cable modem, would issues would that create? (I've never used a Slingbox, so I don't know.)

On the receiving end this could be an issue since it exposes the receiving machine (I assume is a PC) to the attacks from the Internet.

denleyan wrote:

danpass wrote:When we do our building to building simulcasts, I physically take the Cisco firewall offline, which eliminates any possibility of bandwidth contention from computers in the building, since all connections that could have a computer connected to them, hang off of the firewall.

Isn't this a fundamental violation of the Church's network security policies?

To clarify, the way that I take the firewall offline is that I disconnect its WAN/Internet connection. All ports in the building that have or could have a computer connected, are connected via patch panel and a network switch to the LAN side of the firewall. The Slingbox connections do not go through the firewall in order to ensure that the firewall does not interfere with our broadcasts.

The initial policy statement we received from HQ indicated that no devices should be allowed to bypass the firewall. I communicated with Troy Sheffield regarding our (stake president approved) configuration and he said that what we are doing is acceptable.

danpass wrote:So far, we haven't actually tried dual feeds using both Slingboxes concurrently. I'll be testing that soon because the Stake Pres. wants to transmit to two buildings in September. Our DSL is 1.5/734 and the 734 upstream bandwidth has given us a high quality feed. The Slingbox adjusts video quality based on available bandwidth. I'll report back here on how the dual feed test goes.

We performed this test earlier this week. As promised, here is my report:

In addition to the information about our configuration that I posted previously, I should mention that I did not make any attempt to allocate bandwidth between the two SlingBoxes through router configuration. I would have pursued this had the need manifested itself.

At the beginning of our test the person helping me at one of the two broadcast destinations was using a MacBook with the Mac version of the Sling player software. He kept having problems with the player dropping it's connection to the SlingBox. He speculated that the Mac version of the player application was probably buggy.

After switching over to a Windows PC and running the Windows player, he had no further connection problems. The player app at both broadcast destinations had default options set as follows:

Video - Buffer settings: automatic - Optimizations: Enable SlingStream optimizer and Enable fast start - Home Network Video Quality: Full Resolution
Encoding - Medium Action

I was worried that whichever SlingBox was connected to first would get and keep a bigger slice of the bandwidth. But as it turned out, within about 15 seconds of when the 2nd SlingBox was connected to, they evened out to where they both were using about the same.

The bottom line is that while there was some loss in video quality with 2 concurrent streams versus a single stream, the audio quality was fine. The video was definitly not broadcast quality but good enough for our purposes. The members who will be viewing these broadcasts are very grateful that we will be saving them from long drives to and from some of our stake meetings

Is your DSL still 1.5/734? Any options to get better upload bandwidth? Given what you are doing, it might be cost justifiable to upgrade the service.

How was the sound? One of the things that really irks me is the sound of a organ over some of the audio compressions systems. The results are anything but uplifting.

RussellHltn wrote:Is your DSL still 1.5/734? Any options to get better upload bandwidth? Given what you are doing, it might be cost justifiable to upgrade the service.

How was the sound? One of the things that really irks me is the sound of a organ over some of the audio compressions systems. The results are anything but uplifting.

Unfortunately, that speed is the maximum available for where our stake center is located. The building is in a Comcast service area, but there is no cable service into the building. So our only option is DSL which we are getting through Qwest. When we first explored our broadband options, I tried Sprint's EVDO service. The maximum speeds I was able to get were about 20% of what we get with DSL.

The sound was very good. The SlingBoxes seem to prioritize the audio over the video. So if they are having trouble keeping up, the video will degrade before the audio.

danpass wrote:The building is in a Comcast service area, but there is no cable service into the building.

Not as nice and neat as DSL, but it sounds like cable can be done. I know some of the FHCs in my area are on cable. I'd be really surprised if any of them had cable service into the building before they signed up.

For a solution using Windows Media Encoder, see http://tech.lds.org/forum/showthread.php?p=20457