First new webcast results

As a test for tomorrow's stake conference we broadcast the evening session tonight. For the most part everything went smoothly, except about 2/3 of the way through the receiving site had a couple buffering events in succession. No apparent reason, CPU load was never very high and network bandwidth was not an issue.

It seems buffering means it would simply stop displaying the stream while it buffers a little more of it, and therefore not actually miss anything and not be a big concern. But it did lose some of the webcast. So I guess I'm going to have to run the old webcast in parallel as a backup. The catch is that in order to switch quickly they would have to be receiving both simultaneously, which to me presents too much risk to the primary webcast. So not sure if there's really any benefit.

craiggsmith wrote:It seems buffering means it would simply stop displaying the stream while it buffers a little more of it, and therefore not actually miss anything and not be a big concern.

Except it really disrupts the spirit of the meeting each time it happens. Let us know how your Sunday session goes.

Certainly true. Fortunately today things went pretty well; here's my report:

I started the webcast during the buffer period around 8:15. I didn't have a chance to check it until 8:45, at which point I noticed that it was just a black screen. The stats showed that the server was receiving the stream, but that no clients were connected. I tried with two computers at two different locations, and used both the receive links as well as the meeting code. I called support and they saw the same thing. I checked my broadcast settings and restarted the stream any way to be sure. We finally gave up and I terminated the meeting and created a new one. The new one was fine without any other changes.

The only issue we had during the broadcast was one site had a minute where bandwidth dropped to 100 and video quality was poor. This was a different site and different computer than the one that had the buffer events last night. It was our most robust computer (quad core i7 with lots of RAM) and fastest internet connection (20 Mbps cable) so no idea why. CPU only averaged 10% with max less than 20%. Maybe an internet connection glitch? The playback bit rate averaged 716; never seemed to try going higher.

The other site had the slowest computer and slowest internet (12 Mbps DSL); it averaged 22% cpu and a bit rate of 900, with no drops.

My computer (dual core i5) averaged 15% cpu also with a bit rate of 900. There was one brief drop to 716. I had a few other things running (like the stats).

The sending bit rate averaged 774 (Vidiu set to medium). All computers were PCs with Firefox 41. There were no buffer events or disconnects, and audio was always fine, so all in all things went pretty well and I'm a little more confident. But I wonder about the auto adjusting bit rate a little; I wonder if it's a little too hypersensitive. We never had any issues on the receiving end with the old system.

I'm not sure the quality was any better than the old system, and in some ways it seemed worse, perhaps due to the upscaling. I had the converter set on 720p. I never tried 1080. The Vidiu said it was receiving 720p at 50 Hz which I thought odd. With both this system and the old one color is really lacking; this may have been a little better but not significantly. I'd really like to get a better camera. I'd also like to get better lighting, but not holding my breath on that one.

Different stake here. We tested Friday and everything worked just fine. Sunday morning we could not get the broadcast to work at all. Our STS got on the phone with headquarters and they said they had to change some settings on the servers there to get the broadcast to work. Once it got going, the broadcast worked well. We used VidiU but I do not have the technical details.

I am glad we started early Sunday, or we would have missed streaming the conference to multiple locations. I cannot imagine why SL would need to do anything to get it going, unless there was a configuration change of some sort that didn't work.

That is always my biggest concern every six months for stake conference. There is too much that is totally out of our control. And a successful test does not seem to be related to a successful broadcast at all, at least in my experience over the last five years or so.

craiggsmith wrote:I started the webcast during the buffer period around 8:15. I didn't have a chance to check it until 8:45, at which point I noticed that it was just a black screen. The stats showed that the server was receiving the stream, but that no clients were connected. I tried with two computers at two different locations, and used both the receive links as well as the meeting code.

We had the happen during tests. That's one reason why we switched to using YouTube.

Hmmm, interesting. I thought they were using an off-the-shelf system, just leasing time on commercial servers. I'd think it would be well sorted out and they wouldn't need to change anything. I had done some testing with Livestream and was going to use that if they didn't come out with this service, but figured I should use the standard.

I had my first large webcast, and guess what... some sites were very good, and some others...

I considered using youtube to broadcast before, but isn't that a risk for meetinghouses network? I mean, apparently some meetinghouses can reach youtube, some others can't.

Is anybody else used youtube before? any experiences you would like to share?

cordeirol wrote:apparently some meetinghouses can reach youtube, some others can't.

When did you check? YouTube is normally blocked for meethinghouses. However, near General Conference, it's opened up and allowed. I'm guessing it's about a 4 week window. It used to be that FHCs were allowed to go to YouTube, but I've been told they're using the same filtering as the meetinghouse.

Bottom line, if you go YouTube, you'll need to plan by bypassing the firewall (which technically, is against policy).

cordeirol wrote:Is anybody else used youtube before? any experiences you would like to share?

I posted my experience with YouTube over 3 years ago here: https://tech.lds.org/forum/viewtopic.ph ... 85#p128585

The only difference is I've switched to a licensed version of Wirecast, rather than the free YouTube for Wirecast product (now called Wirecast Play), to allow for more than 1 camera, video titling, shot editing, etc.

The nice thing about Wirecast is it's completely free to install and try without any feature restrictions or time limits. The catch is, any stream produced will have the video and audio watermarked until a license is obtained. Try it on a Mac or PC with a simple webcam and see if it's up to the task of uploading a 720p (or higher) stream. BTW, YouTube requires no setup time, can optionally save streams (test or otherwise) up to 8 hours in length, and is free to use.

If you're ambitious, there are also open source alternatives to Wirecast. Open Broadcaster Software or OBS is probably the most well known. IMO, not as polished or capable as Wirecast, it's still a viable alternative for some.

Finally, there are instructions on the Teradek website on how to setup the VidiU box to stream directly to YouTube. Might be a nice backup plan if you're having issues using the portal system.

Those of you thinking about use YouTube, let me throw some logic at you.
In order to get YouTube to work, you have to bypass the firewall. Ever wonder what would happen if you tried to bypass the firewall and use the portal system? It works great....hmm, I wonder why? Its because the firewall/network has been bypassed.

We are finding in meeting houses there are several hardware problems. Either the network isn't setup properly, a bad port on a switch that causes the system to run slow, a rogue Meraki that is throttling the system, and various other in-house hardware/network related issues.

I would suggest that if you are having slow or even disconnecting issues, call your FM and have them come out and take a look at your network system.

rannthal wrote:I would suggest that if you are having slow or even disconnecting issues, call your FM and have them come out and take a look at your network system.

I'm not sure they'd be able to do anything. The capability varies by group, but as a rule, I don't think they have any real network people.

If they don't have any network people, they should be able to find someone to check the system.

For our Stake Conference late last year, we used the Portal with pretty poor results. One building dropped out in the middle of the Stake President's talk and didn't recover until the closing Hymn. All the buildings had some trouble and/or dropouts. For our Stake Conference last month, we streamed to YouTube directly from the Teradek with excellent results. If it's a problem with the building network or the Meraki firewall, then it's a pretty widespread issue, at least within our Stake. I'll see if I can get the Portal to give results anywhere near what we've achieved with YouTube, but I'm not optimistic quite yet. I understand that the Portal has undergone a lot of upgrades and bug fixes recently, so hopefully that will help.

At risk of incurring the wrath of rannthal yet again, I feel I must restate what has become obvious to many of us.

We're fully with the statement by Microwaved and the use of broadcast software. The options are Wirecast, OBS, and vMix. We chose vMix but would also be perfectly happy with OBS. The setup is very simple and is made even easier through the use of IP cameras.

We're also with Microwaved on the alternate distribution using Youtube or (in our case) SundayStreams. We bypass the firewall, but did that even before switching from the portal system. Even bypassing the firewall did not eliminate portal issues. The fact that the portal requires a laptop on the receive end is a definite weak link.

PCs are not the right tools to receive video streams that need to remain stable for literally hours at a time. There are a myriad reasons for this and I think most everyone recognizes it. Problems that we tend to blame on the portal system are often issues of stream integrity between the laptop and portal distribution. (Yes, there are better solutions than Azure, but that's up to others to decide.)

We use Rokus on the receive end with SundayStreams as the distribution. We stream directly from vMix or OBS. What we've found is that we now have NO distribution issues, 1080P on the receive sites, excellent audio, and literally 10 minutes on the receive site to set up equipment.

This is not a slam on the work done by the technology group. After some long conversations with their management I've concluded that they are mostly prohibited from advancing for various reasons, mostly since they are not able to act on the recommendations of their technical staff. That is unfortunate but I'm sure will change in the course of time. In the meantime we're enjoying non-eventful webcasts with tons less stress as we've figured out how to simplify everything.

You're funny. There are 2 problems which everyone is going to have to address according to their own conscious.

1.

randysteck wrote:We bypass the firewall, but did that even before switching from the portal system.

This goes against handbook recommendations. But I guess you have the choice to do what you like.

2. This forum is for solutions and recommendations for those who use the webcast system. It doesn't help anyone to bash on the system. It only causes confusion and contention. You if you have something to say that helps using the webcast system or a question about using it, please state it here....otherwise take it elsewhere.

randysteck wrote: In the meantime we're enjoying non-eventful webcasts with tons less stress as we've figured out how to simplify everything.

Congratz. I'm glad you have found something that works for your stake. I would like to let you know also that most of the world has also using the webcast system. It is in the best state that it has ever been.

I was going to sit this one out, but it just keeps bugging me. The absurdity of thinking that a completely unique system outside the standard the church provides is better in any way just irks me to the nth degree. The completely custom system you have is unsupportable, doesn't sustain calling turnover and/or growth in your stake/wards splitting etc... it just reaks of superiority, but to each his own. A wise STS would counsel against doing something like this unless some kind of unique circumstance exists. I'd much rather put together a system that if I got hit by a bus today someone else could easily step in, from scratch, and be successful, your system isn't sustainable large-scale and blows up the support model from CHQ (ICS/FM). If every chose to do what you have done there is no economy of scale, there is no way to plan for the future. There isn't a forecast to provide a budget each year and growth predictions and usage scenario bucket lists.

But there is one thing I'd love just like you. I'd love to just have a streaming device at each location. The benefits are legion.