Tech Forum

stake center upstream / downstream bandwidth = 1.72 Mb / 7.0 Mb

remote buildings upstream / downstream = 6 Mb / 12 Mb

We used Telestream Wirecast to encode the stream with three Sony cameras and titles / overlays through the new portal.ldswebcast.org application. Because the Western Region servers were offline, we used the Central Region as recommended by the GSC.

We started broadcasting two hours before our stake conference session with downloaded MoTab videos from previous general conferences in a 4:3 aspect ratio at 800k. The video and sound at the other buildings looked and sounded pristine as it had during our tests. We had given out the event code to the bishops to distribute to home bound members. We noticed that when they started joining the quality received at our remote buildings seriously degraded. 26 home users ended up joining. Our buildings would experience black screens, freezes, and buffering.

We reduced the broadcast stream to 400k to stabilize the presentation but this caused the picture to be pixelated and grainy at the remote buildings. We found that the default minimum receive bit rate defaults at the remote sites were set to 100k, and when we bumped this up to 300k the picture improved immensely and was workable. On the receive browsers there is a button on the lower right to check the statistics where this can be adjusted.

I've got a call into the GSC as to why home users joining the conference would so significantly degrade the receive quality in our remote buildings. Please consider only giving out the audio bridge info to home users and not have them join the videocast until this is addressed.

We did have the wireless AP's shut down in each of the buildings, so as to not compete for bandwidth. GSC is reviewing the logs and alerts from our Completed Event.

After reviewing the broadcast statistics with the GSC the critical piece was that I only reserved up to 10 locations (thinking that only each building would count as one), when in actuality each home user additionally counted as 1 location in this calculation. My suggestion for stake conference broadcasts is to request 30 locations and then strictly control home user access to the stream.

garybsanders wrote: and then strictly control home user access to the stream.

Just to emphasize the Webcast Policies and Guidelines:

Webcasting to locations other than Church buildings should only be done under the direction of the event's presiding authority.

That could get interesting if you have a visiting GA.

garybsanders wrote:After reviewing the broadcast statistics with the GSC the critical piece was that I only reserved up to 10 locations (thinking that only each building would count as one), when in actuality each home user additionally counted as 1 location in this calculation. My suggestion for stake conference broadcasts is to request 30 locations and then strictly control home user access to the stream.

Thanks for the valuable feedback! This situation is sad. Ideally they should be able to determine the number of connection on-the-fly and adjust the server load accordingly so STS's don't HAVE to overestimate the number of connections just to make sure they never run into this problem. [sigh]

Mikerowaved wrote:Ideally they should be able to determine the number of connection on-the-fly and adjust the server load accordingly so STS's don't HAVE to overestimate the number of connections just to make sure they never run into this problem. [sigh]

We don't have to get a precise number. The choice is between 10, 25 and 50. I've been told that in the new system, the server is "in the cloud" (not at the church like it is for the old system). I'm sure this setting is used to determine how big a server is spun up for our event.

With the need to clear this with the presiding authority, leaders should have some idea ahead of time. It's also pretty clear that with a upper limit of 50, we're going to have to save the links for those who really have no other options and not be handing them out to everyone who doesn't want to make the trip.

russellhltn wrote:It's also pretty clear that with a upper limit of 50, we're going to have to save the links for those who really have no other options and not be handing them out to everyone who doesn't want to make the trip.

Yes, it should only be homebound members if deemed appropriate by the presiding authority. Probably about the same list of people who regularly have the sacrament brought to their homes.

It is important to understand how this system is designed.

The solution is a Microsoft Azure Cloud based solution and is designed to be efficient in terms of cost. The Cloud will spin up enough resources to ensure the success of our broadcast based on what we tell it. So, if you reserve 10 streams, the Cloud spins up enough services to give you 10 streams. If you reserve 20, then it spins up 20, etc.. Once the session is over, the resources are spun down, and the Church is billed only for the usage. (this explanation is a bit simplified.. but you get the drift)

This is a way the Church is saving a whole ton of wasted money saving the creation of an internal infrastructure that must be designed to accommodate the largest amount of broadcasts that could ever be done at the same time. Mon-Fri this is WASTED energy, hardware, etc... It is a ton of wasted money... The new design is good but we need to very specific when we start talking about streams.

garybsanders wrote:We used Telestream Wirecast to encode the stream.

How do you use the software to encode? The webpage only lists the Teradek VidiU Encoder as an encoding option.

aclawson wrote:

garybsanders wrote:We used Telestream Wirecast to encode the stream.

How do you use the software to encode? The webpage only lists the Teradek VidiU Encoder as an encoding option.

A software based solution is not officially supported (yet), but that hasn't stopped some from experimenting on their own, as reported in this post:

https://tech.lds.org/forum/viewtopic.ph ... 49#p135749