Tech Forum

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.