Webcast 3.0 is out

A new version of webcast is out. There are quick guides and complete guides links in the portal. Also the new url for the system is webcast.churchofjesuschrist.org.
Be sure and register your teradek before if you are going to use it.

Have fun!!!

Is it still based on Azure for the video streaming, or something else?

rannthal wrote:There are quick guides and complete guides links in the portal. Also the new url for the system is webcast.churchofjesuschrist.org.

Keep this link handy, because the URLs are wrong in both the quick-start and the complete guides.

Portal.ldswebcast.org will be redirected to webcast.churchofjesuschrist.org for several months.
(The original portal url was left in the docs because at the time of doc creation, it was unknown what the new url would be. So it was left that way knowing it would be redirected to the new.)

russellhltn wrote:Is it still based on Azure for the video streaming, or something else?

Yes, it is Azure still.

One of the cool new features of Webcast 3.0 is the ability to configure the Teradek VidiU once and then it will configure automatically for all your events going forward. You will no longer need to configure the Teradek VidiU (e.g. copying/pasting codes into the Teradek) every time you create a new event. You can also change your bitrate using the portal.

Another great feature is the Low Bandwidth Broadcast mode, for areas that have low and/or unstable internet.

Let us know what you think of the new features and give us any feedback you have (webcastpm@chruchofjesuschrist.org).

Thanks,
Sean
Webcast Product Team

Could we start thinking about the receiving end of these broadcasts? Consistency with a player is the absolute most important thing in a successful broadcast that can't be controlled from the Stake Center / Webcast broadcast site.

seanhyte wrote:One of the cool new features of Webcast 3.0 is the ability to configure the Teradek VidiU once and then it will configure automatically for all your events going forward.

I really like this, but have a small concern.

As I understand it, the Teradek will self-configure only if you turn it on during the pre-buffer period. This is okay for a regular webcast with a two-hour pre-buffer period, but a test broadcast only gives 10 minutes. That does not give much time if the Teradek doesn't come up when first started. Ours takes almost 5 minutes to boot up, and does not always come up Ready the first time. If we had to do it again, we would be late for our test broadcast.

Is there any way to trigger the Teradek to accept the auto configuration during the pre-buffer period if it is turned on before the pre-buffer period has started? Obviously, any type of trigger would have to take place during the actual pre-buffer period. Or is the only method to turn it off and take our chances on bringing it up again during the pre-buffer period, or just never turn it on early for a test?

Again, for actual events with a two-hour pre-buffer, this is not an issue. And I guess a test is a test is a test, so it is no big deal then. I was just wondering if there was another way to trigger the auto-configuration than the poor little switch on the side of the box.

Thanks for sharing this news with the forum, Sean! The first thing I noticed was a complete list of my past events (both testing and otherwise). For some reason, I was not able to see that before. The UI looks a lot more refined and easier to navigate than before.

seanhyte wrote:You can also change your bitrate using the portal.

Any chance the 2.1Mb/s ceiling has been increased?

seanhyte wrote:
Another great feature is the Low Bandwidth Broadcast mode, for areas that have low and/or unstable internet.

Wasn't this available on a per-location basis in the previous version? This setting does that for the entire broadcast, right? So even if we have sites that can take a full HD stream, if we set this it will stream at the lower bandwidth option, right?

johnshaw wrote:Could we start thinking about the receiving end of these broadcasts? Consistency with a player is the absolute most important thing in a successful broadcast that can't be controlled from the Stake Center / Webcast broadcast site.

Yes, we have been aware of this, and we are working towards a solution for the receiving end soon.

Mikerowaved wrote: Any chance the 2.1Mb/s ceiling has been increased?

The 2.1Mbps is still the highest, this is to keep the experince more stable for meetinghouse webcast.

seanhyte wrote:The 2.1Mbps is still the highest, this is to keep the experince more stable for meetinghouse webcast.

More stable? I have to jump through hoops just to get Wirecast DOWN to 2.1Mbps when sending a 720p/30 video stream. We have ample bandwidth to support 8k/60 if we had the equipment and need for it (which we don't). The default for 720p/30 using NVENC is 4Mbps plus audio. Forcing it down to 2.1Mb really starts to affect the quality. Please don't take this the wrong way. I'm just trying to make those in the overflow buildings have as good an experience as reasonably possible and it's limitations like this that make me look for other solutions.

Mikerowaved wrote:

seanhyte wrote:The 2.1Mbps is still the highest, this is to keep the experince more stable for meetinghouse webcast.

More stable? I have to jump through hoops just to get Wirecast DOWN to 2.1Mbps when sending a 720p/30 video stream. We have ample bandwidth to support 8k/60 if we had the equipment and need for it (which we don't). The default for 720p/30 using NVENC is 4Mbps plus audio. Forcing it down to 2.1Mb really starts to affect the quality. Please don't take this the wrong way. I'm just trying to make those in the overflow buildings have as good an experience as reasonably possible and it's limitations like this that make me look for other solutions.

Yes, thank you for expressing your wanting the best possible experience for your viewers, me personally as an STS myself and I'm also a home theater enthusiast, I’m very picky wanting the best audio/video possible, so I’m with you in your desire.

The webcast team is evaluating requirements all the time to make sure stakes are successful in webcasting, and when I said “more stable” I was using it to refer to the Church as a whole in its overall success for meetinghouse webcasting. There are many reasons for the limit at this time, but one of the reasons was to reduce the amount of failures stakes were having, not just in Utah but all over the world as a high percentage of failures happened when using the higher bitrates. The Church is extremely interested in making sure meetinghouse webcast is as successful and reliable as possible so the technology can be utilized to further the work. Although webcast failures are rare now, it is always hard to hear when even one event has failed and to know there was a group of people that did not get to hear the message that was intended for them.

2.1 Mbps can reach HD quality if you have the bandwidth, stable internet, and all your equipment including cameras and projectors are HD capable.

Thanks

lajackson wrote:

seanhyte wrote:One of the cool new features of Webcast 3.0 is the ability to configure the Teradek VidiU once and then it will configure automatically for all your events going forward.

I really like this, but have a small concern.

As I understand it, the Teradek will self-configure only if you turn it on during the pre-buffer period. This is okay for a regular webcast with a two-hour pre-buffer period, but a test broadcast only gives 10 minutes. That does not give much time if the Teradek doesn't come up when first started. Ours takes almost 5 minutes to boot up, and does not always come up Ready the first time. If we had to do it again, we would be late for our test broadcast.

Is there any way to trigger the Teradek to accept the auto configuration during the pre-buffer period if it is turned on before the pre-buffer period has started? Obviously, any type of trigger would have to take place during the actual pre-buffer period. Or is the only method to turn it off and take our chances on bringing it up again during the pre-buffer period, or just never turn it on early for a test?

Again, for actual events with a two-hour pre-buffer, this is not an issue. And I guess a test is a test is a test, so it is no big deal then. I was just wondering if there was another way to trigger the auto-configuration than the poor little switch on the side of the box.

You may be getting “auto-configure” confused with the “auto-start” process (which both are all part of the auto-config mode but separate processes).

The Teradek will auto configure anytime it is turned on and boots up. So if you change the bitrate or create a new event in the webcast portal, you need to reboot the Teradek (or power it on from an off state) for the Teradek to get its configuration. It does not need to be in a prebuffer mode for the Teradek to auto config. The Teradek will auto config anytime it boots no matter what state (of course this only works if you previously have setup the auto-config mode as shown in the 3.0 guide).

However, the Teradek will only auto-start broadcasting if it boots up when your event says “begin encoding” in the webcast portal. (“begin encoding” will start in the prebuffer state). If you boot up the Teradek before your event says “being encoding” the Teradek will configure, but not auto start broadcasting. If this happens and you want the Teradek to start encoding, you can either reboot the Teradek again after it says “being encoding”, or push the red “start” button on the front of the Teradek to manually start it. (You can only manually start it from the red button, if you previously rebooted the Teradek to receive its auto-configuration).

seanhyte wrote:The Teradek will auto configure anytime it is turned on and boots up.

That's a very nice feature! I have a few questions...

1. Does the Teradek need to be in the Facility Zone to be found, or can it remain in the Meetinghouse Zone?
2. Using this feature, can the church roll out acceptable firmware updates to the Teradek so we don't accidentally roll it ahead too far?
3. As part of this routine, can the church run a bitrate test from the Teradek to the church's portal to make recommendations (or automatically set) webcasting bitrates?

Mikerowaved wrote:

seanhyte wrote:The Teradek will auto configure anytime it is turned on and boots up.

That's a very nice feature! I have a few questions...

1. Does the Teradek need to be in the Facility Zone to be found, or can it remain in the Meetinghouse Zone?
2. Using this feature, can the church roll out acceptable firmware updates to the Teradek so we don't accidentally roll it ahead too far?
3. As part of this routine, can the church run a bitrate test from the Teradek to the church's portal to make recommendations (or automatically set) webcasting bitrates?

1. Zones do not matter, the Teradek just cares if it has an internet connection or not (of course policy states connections need to go through meetinghouse firewall). Basically (in autoconfig mode), every time the Teradek boots up, it goes out to retrieve any settings that are set in the webcast portal. That is why you need to reboot Teradek if you change bitrate in the portal, or setup a new event in the portal.

2. Not able to update firmware because there is only a limited items the Teradek VidiU can be auto configured, this is a limitation from Teradek.

3. Currently we have added a new test in the portal that will let you test at your broadcast site for the closest cloud region you should use, and have added new articles/worksheets to help you understand the right bitrate and settings you should use, but hope to move towards other tools that will help as well.

johnshaw wrote:Could we start thinking about the receiving end of these broadcasts? Consistency with a player is the absolute most important thing in a successful broadcast that can't be controlled from the Stake Center / Webcast broadcast site.

Here is what I do, I think the church should do something just like it:
viewtopic.php?f=27&t=24539&p=199482#p199482

segbert wrote:
Wasn't this available on a per-location basis in the previous version? This setting does that for the entire broadcast, right? So even if we have sites that can take a full HD stream, if we set this it will stream at the lower bandwidth option, right?

I see what you mean. It used to be per-location but now it seems to be a blanket application. When reviewing Locations, there's no way to check if the site previously set as a Low Bandwidth location is still that way. The whole interface for Location reveiw, editing and adding seems clunky and missing configuration ability that was available before.

egibb wrote:

segbert wrote:
Wasn't this available on a per-location basis in the previous version? This setting does that for the entire broadcast, right? So even if we have sites that can take a full HD stream, if we set this it will stream at the lower bandwidth option, right?

I see what you mean. It used to be per-location but now it seems to be a blanket application. When reviewing Locations, there's no way to check if the site previously set as a Low Bandwidth location is still that way. The whole interface for Location reveiw, editing and adding seems clunky and missing configuration ability that was available before.

The broadcast site will encode and upload at the rate you set. This stream is then transcoded so your receive sites will be able to receive the stream at the rate the location can handle based on its network speed and heath. It worked this way in the previous version, and still works this way now.

The added new feature to 3.0 is the Low Bandwidth Broadcast Mode. In this mode the rate is locked in at a low encode rate and there is no transcoding. This will help sites that have low/unstable internet.
Make sure to read up on the below article -
Webcast Network Health and Encoder Settings https://www.churchofjesuschrist.org/hel ... s?lang=eng

seanhyte wrote:It worked this way in the previous version, and still works this way now.

Because I was told differently, we have been encoding for several years at a low rate so that the poorest receiving units could receive an acceptable broadcast. I was specifically told that if I encoded it a higher rate it would ruin the broadcast for the lower rate receiving units. And we have taken the flak from the more capable locations in stride, telling them that we were following the official guidance from the Church.

So since apparently this was is not true, I would just like to confirm that I can encode at a high rate for the benefit of those units that have excellent internet, and the units that have low-grade Internet will still be able to receive the broadcast at a lower rate with no degradation in quality other than the limits of their Internet speed.

Is this correct?

lajackson wrote:Because I was told differently, we have been encoding for several years at a low rate so that the poorest receiving units could receive an acceptable broadcast.

I believe that was true for a prior version of the server software. My understanding is the current system can down convert on the fly.

russellhltn wrote:I believe that was true for a prior version of the server software. My understanding is the current system can down convert on the fly.

That is what I am trying to find out. I was told originally that the prior version would not down convert, but the post two before yours says it would. I never found that to be true.

I am now being told that the new system will. I am just trying to confirm that is true. My skepticism comes from years of experience asking the same question of the help desk two times and getting three different answers.

For now I will trust that it is true that the system will down convert, but I will run extensive tests before our next conference to see if it actually works.

I am very glad to see these improvements. And I hate being the one to interject what may appear to be negative comments, but the reality is that we've been using multi-bit rate broadcasts for 3 years now. Plus, we've been encoding 1080P at 3.5Mbps which gives a strikingly better remote picture. It's been very easy to tailor a high bandwidth stream and a low bandwidth stream for remote locations as receive bandwidth allows. At risk of being pedantic, we've been using SundayStreams.

I fully understand the need to make it useful for all locations and bandwidth considerations. But, the reality is that the capability to do this has been available for at least 5 years. Limiting the max bandwidth because you don't want to damage the low bandwidth connections does not make any sense to me. This is a server side issue, and modern streaming servers can supply multiple bandwidth connections all at the same reliability. I'm pretty sure the state of the art is AWS with nginx servers. Not sure what Azure allows but it should be similar.

But, I'm very happy the "official" servers are finally catching up to external options.

If I could make one suggestion it would be to stop requiring reservations for streaming events. Most every other service gives you a bandwidth budget and allows connection to the system with your user ID whenever you need. This allows testing and conference webcast with little friction.

randysteck wrote:...but the reality is that we've been using multi-bit rate broadcasts for 3 years now.

Since the church changed to the Azure servers about 4.5 years ago, it has had multi-bitrate download capability. Although the first couple of years were pretty rocky, it's a fairly stable streaming platform today.

Is the Teredek 3.0.8 firmware acceptable to use now?

Never mind. I found the answer to this.

https://www.churchofjesuschrist.org/hel ... e?lang=eng

I'm preparing for a stake conference in a couple of weeks. I was going to do a test event tomorrow, I went into webcast portal tonight to schedule the test, and it appears completely broken. The list of "completed events" was completely wrong, there was a loading spinner that never cleared. When I inspected the underlying api calls in the dev tools they were calls like https://webcast.churchofjesuschrist.org/api/org/0. Upon further inspection I can see the call that's returning incorrect data is https://webcast.churchofjesuschrist.org/api/userProfile. In that JSON response there's an organizations with an id of 0, rather than what I assume should be my stake unit number. Is this happening to anyone else? Or is it working fine for others?

Seems to work OK for me. I didn't try to actually schedule anything. Just pulled up the scheduling form.

It was not working for me for about 20 minutes, but it is coming up now. Whatever was failing appears fixed.

mstauff wrote:It was not working for me for about 20 minutes, but it is coming up now. Whatever was failing appears fixed.

The church has been experiencing a rash of authentication errors. I'm sure they are working on getting it stable again. In the meantime, we'll have to bear with the occasional glitches.