Questions regarding online documentation

Last night we tested our webcast for this weekend's Stake Conference. This will be the 2nd time we've used the Vidiu solution. Our test was a whale of a fail, triggering me to pretty much spend 3 hrs afterward tearing apart the system bit by bit to isolate and check each component.

In doing so, I went back to the original online documentation (https://www.lds.org/help/support/vidiu- ... e?lang=eng) to make sure I had followed it to the letter. This led me to a few questions...

1. Why does it require us to stay on an old firmware? I downgraded the Vidiu to 2.2.0, even though 2.6.0 is available. Since the Vidiu constantly nags you to upgrade, I just don't think it's feasible that this thing stay on an old load all the time. Are we not testing and qualifying all latest versions of Vidiu firmware, or just trusting that they will be improving as they go?

2. Conflicting info in this doc and in posts here and an email I got about using Mono Left only. The docs need to be updated to say to use the Stereo input, if that's what's not going to be a problem. (BTW, this seems like a very strange, basic problem to have. Can't imagine how it got introduced.)

3. Why is it recommended to set audio to Mobile/48kbps?? I suppose that's OK for spoken word, but no choir or organ sounds decent at that bit rate. Is there some other advantage or reason to not increase that?

Just in case you're wondering -- as a summary of where I landed after my failed stake-wide test -- I think I've got two issues to resolve before Sunday:
1. Meetinghouse bandwidth has some kind of gremlin. I had the video bitrate set to "High" for last conference with plenty of overhead - no issues. I had to reduce to "Medium" to get any kind of steady stream out this time, and I still heard a lot of audio speed-up and slow-down on the receiving end (receiving over LTE). I've got an email in to FM to see if we can get on a better upstream bandwidth plan as an emergency measure. It sure hurts my heart to have a beautiful 720p stream getting garbled down to a 700kbps or 300kpbs stream.
2. My EMTech AVHD-1 device has an AWFUL hum coming out of all its audio out ports. I thought maybe it was just miswired on the port going out to the webcast device, but it's something inside the EmTech, I think, because the signal going in seems to be clean from the building audio. My next step on this will probably be to circumvent this device and take the building audio directly into a mixer for better control (and splitting to my backup solution) anyway. But I've lost a lot of faith in that EmTech device. Church should look at improvements there.

First off, thanks for posting your troubles and problems. This is helpful where all of us can learn and share to find solutions.

sammythesm wrote:Last night we tested our webcast for this weekend's Stake Conference. This will be the 2nd time we've used the Vidiu solution. Our test was a whale of a fail, triggering me to pretty much spend 3 hrs afterward tearing apart the system bit by bit to isolate and check each component.

In doing so, I went back to the original online documentation (https://www.lds.org/help/support/vidiu- ... e?lang=eng) to make sure I had followed it to the letter. This led me to a few questions...

1. Why does it require us to stay on an old firmware? I downgraded the Vidiu to 2.2.0, even though 2.6.0 is available. Since the Vidiu constantly nags you to upgrade, I just don't think it's feasible that this thing stay on an old load all the time. Are we not testing and qualifying all latest versions of Vidiu firmware, or just trusting that they will be improving as they go?

Please upgrade the Vidiu to the latest version. I believe currently its 2.4.6.
I've asked the doc people to change that to say to upgrade to the latest version. I'm frustrated why they haven't yet. If there are problems with a version, I'll be one of the first to know about it and post something on here and on the portal.

sammythesm wrote:2. Conflicting info in this doc and in posts here and an email I got about using Mono Left only. The docs need to be updated to say to use the Stereo input, if that's what's not going to be a problem. (BTW, this seems like a very strange, basic problem to have. Can't imagine how it got introduced.)

This Mono bug was introduced with going to a more cloud based system. I haven't seen this email saying to use Mono Left only, so I can't comment on that. For now, please use Stereo input. (I've harped on fixing this bug till I'm blue in the face and told to pipe down. I hope its fixed in the near future.)

sammythesm wrote:3. Why is it recommended to set audio to Mobile/48kbps?? I suppose that's OK for spoken word, but no choir or organ sounds decent at that bit rate. Is there some other advantage or reason to not increase that?

The reason it is recommended to set the audio to Mobile is to save bandwidth. We are finding that with the system being used world wide, in some places they have limited bandwidth, the most they can get is 300k. For stake conferences where it is mostly spoken work, the low setting comes off just as well as the other settings. In doing so, there is more bandwidth for the video. If you have plenty of bandwidth space, then please set the audio to what you see fit.

sammythesm wrote:Just in case you're wondering -- as a summary of where I landed after my failed stake-wide test -- I think I've got two issues to resolve before Sunday:
1. Meetinghouse bandwidth has some kind of gremlin. I had the video bitrate set to "High" for last conference with plenty of overhead - no issues. I had to reduce to "Medium" to get any kind of steady stream out this time, and I still heard a lot of audio speed-up and slow-down on the receiving end (receiving over LTE). I've got an email in to FM to see if we can get on a better upstream bandwidth plan as an emergency measure. It sure hurts my heart to have a beautiful 720p stream getting garbled down to a 700kbps or 300kpbs stream.

The Internet bandwidth can be frustrating. About a year ago we had upped our Internet and had a successful previous conference back in April. Last November, things were going well. We hadn't had an error or problem or anything. During the last 20 minutes of the conference, at one of our receive sites we suddenly got blasted by 82 errors coming from the Internet. No explanation as of why. Those errors lasted for about 15 minutes and then cleared up. But by that time conference was nearly over, so that receive site missed the last 20 minutes of conference. There hasn't been an error in the building since. Why did those errors occurred and at that time? No one has an answer.

sammythesm wrote:2. My EMTech AVHD-1 device has an AWFUL hum coming out of all its audio out ports. I thought maybe it was just miswired on the port going out to the webcast device, but it's something inside the EmTech, I think, because the signal going in seems to be clean from the building audio. My next step on this will probably be to circumvent this device and take the building audio directly into a mixer for better control (and splitting to my backup solution) anyway. But I've lost a lot of faith in that EmTech device. Church should look at improvements there.

You are doing the right thing to circumvent the EMTech device to see if that is the problem. The way to check to listen to what the VidiU is receiving is to plug in head phones found on the jack on the left side of the device. If what you hear is clean, then its not anything before the VidiU. If what you hear is bad, then its something going on before the audio gets the the VidiU.
If what you hear is clean, but at the receive sites the audio is bad, then there is something going on with the encoding process (Mono bug) or possibly at the receive site(s).

I would get a hold of your FM group to have them check out the EMTech device as quickly as they can.

I hope my answers to your questions help. Was the audio problems and the bandwidth issues your only problems you had with your testing or was there other things also?

Thanks for such a speedy reply, and for the go aheads on firmware and audio quality changes.

To clarify what I meant on the Mono Left issue -- the online Vidiu setup says explicitly to set the Vidiu to Mono Left only mode. So that should be updated if stereo is the only supported/working option. I got the tip to use the Stereo mode via this forum and (I think) an email alert that came out.

To respond to your final question on whether these were my only issues...

The symptoms experienced during the test were odd -- intermittent audio, then garbles/pitch variations in the audio, then intermittent video, then audio-only stream, then no audio at all on the audio-only stream, then cutaway to MoTab singing (which, BTW, is a KILLER new feature since I used this last -- really will help maintain a spirit in the meeting if there are any tech issues on the sending side). It wasn't clear it was one thing during the test -- which made it more frustrating to try to play whack a mole while everyone was bombarding me with TXT messages.

Only after the fact did I realize (as I was piecing the system together again bit by bit) that most of the symptoms were really just a factor of bandwidth at my (sending) site. So I'm *pretty* sure I isolated it down to two problems: the EMTech audio hum and the sending site bandwidth.

Tonight's re-test will prove out my theories to see if I can sustain a broadcast for as long as I need to in Conference-like Internet conditions. Fingers crossed. I'm just glad I have good backup solutions available to me (strong LTE signal and a WebEx account).

Just to ask the obvious question - did you shut off internet access to everything else during your test? That is, did you disable WiFi and make sure no one was using any of the wired jacks for non-test activities?

I'd also suggest rebooting your modem during your pre-test setup. I've seen cases where the modem seems OK, but the bandwidth suffers. But power cycling will fix it.

I did shut off the wifi during the test. The router/firewall, I restarted later. Never actually reset our uverse modem. I could do that tonight to see what it does. Thanks!

@rannthal

One more little thing -- in the "Nearest Region" drop down, could those be listed as cities instead of regions?
I'm in Texas, and I have no idea whether I should use Central US, South Central, or North Central... Using city names for the data centers would give a much better feel for where my latency should be measured against.

I'll pass the region/city suggestion on to our project manager. I like it and push for it.

A little bit more about the MoTab choir video that may help. The MoTab choir is always playing on the media server. The MoTab video comes up when the receive site loses the encoding broadcast, like if the broadcast site is having problems. If this happens then you can safely take that the receive site is still working fine, is connected to the media server and is doing what it is supposed to do.

If the receive site does not get the MoTab choir then there is something going on with the receive site.


It sounds like you are correct with your theories to your problems. If the broadcast site has problems, nothing works. I know I've had to lower my encoding bandwidth down to 500k in some cases just to get a steady stream. It doesn't look like clear HD quality, but at least its steady and not lagging or pausing or buffering.