New Standard Webcasting solution

[russellhltn]

Well, this could get intersting. Our current "new" webcasting solution uses Microsoft Silverlight for the receiving system. But Microsoft has depreciated Silverlight in favor of HTML5.

[rolandc]

We need a few people to setup receive only tests and see if the public 5 digit code is working. not the dedicated links for the wards.

2 days worth of troubles now.

[johnshaw]

I can help out

[rolandc]

Thanks John, whatever the problem was. its fixed and working now.

And everyone please notice that the download streams have been upped to 900k, with the four core cpus. and it looks great. Thanks Broadcast team!

[Hagothsen]

Got my first taste of the new system today, and was less than impressed, to put it mildly. We had conducted quite a few tests beforehand, and even had the full setup running at the Saturday evening adult session. To this point, I can't say that I was happy with the 500k or lower bitrates. So, I decided to bring in my photo and video editing rig, Sunday morning.

Two hours before the session started, we started the broadcast. With the stud computer, I could easily get the 2150k stream, with a CPU load < 5% (I was also running Open Broadcaster, to use it as a video mixer to the projector). Things looked good. BUT, 45 mins before the session, things started to go downhill (deja view all over again). There was an operator error of some such at the head end. It took 42 mins for the signal to come back strong. As the choir sang the intro music, things were going well to the opening prayer, then boom, screen frozen in middle of the prayer (should I say amen to what I did hear?). I was set to min 2150, max 2150. After a couple more drops and freezes, I set it to min 100, max 2150. Throughout the 2 hour session, we froze (albeit briefly) 8 more times. I wasn't running the stats window, but I doubt we ever saw faster rates than 300, MAYBE 500, and at that, only briefly. For the most part, the new system looked as humble as the old one, with perhaps a tad better connectivity.

The broadcast site has a measured 8000k+ upload capacity. The broadcast site was using a Vidiu to the new portal. The receiving site has a measured 3000k download. I not only disabled wireless, I removed the patch cables to the firewall, and directed the podium's connection directly into the modem. My receiving computer is an order of magnitude greater than what is required. And for all these improvements, it looked like we were uploading at 768k from an old meetinghouse communicator, to a site with barely 1000k down. Everything new, made old again.

I'm going to put into place a procedure wherein we ask the presiding authority to allow us to use an outside CDN provider. With every turn, I get "we used to travel 1.5 hours each way, to listen on a telephone connection, in the past". I hope we (as a church) haven't spent a lot on this new system. Nevertheless, it is what it is, and it's way above my spiritual pay grade to do anything about it.

[rannthal]

Mr. Hagothsen,
Maybe you should look at your stats on what happened and what your receive bitrate is before you start complaining.

Your first problem is that you set your min to 2150 and max to 2150. This means that if the download bitrate ever dropped below 2150 that you would freeze. This is what happened, you couldn't sustain that. Once you lowered it, things went better.

If you look at your stats you can tell why each time your site buffered....it is because your bandwidth dropped at the encoding site.

Your stats also show that the receive rate dropped, you couldn't sustain the 2M. You can't play what you don't have.

You need to look at your internet. Even though you determined that you get high speeds, doesn't mean that you get it all the time. There are peak and valleys that happen all the time that we are not aware about. A speedtest only tests how long it took a single file to be transferred from one location to another.
Another issue could be the silverlight player itself. Sometimes with erratic bandwidth the player decides for itself to jump down to a lower bandwidth and stay there. No idea why. To try and rectify this we are developing a new player using HTML5 technology. The player currently is in beta and could be used.

In order to fix this mess is there needs to have a test run for a long period of time, several times. From that it can be determined what the average bandwidth sustainability is and set the encoder to do so.

"Everything new, made old again." Nice.....was there a portal to schedule event from? Was there any stats available to use to determine what is going on with your broadcast? Was there an adaptive stream to view from? Could the stream be sustained above 300k? Could you choose what format you were able to watch the stream in and not be stuck at 4:3? Were users at home able to watch the stream? Was the stream available on mobile devices so that you could watch conference from anywhere in the world? Were you stuck using Windows media player? Could you choose where the closest media server was to encode to instead of everyone being sent to the data center in Provo, Utah?
"Everything new, made old again." Perhaps you would like to have audio only???

By the way, if you were using the old system, you would have been down and never come back up.

[Aczlan]

We did a webcast this weekend and (from what I have heard back) it went very well.
We used the VidiU with the Startech S-Video to HDMI adapter.
We had a couple of issues:
At one location, on Sat the Silverlight player locked at 100kbps for the video stream (got a call from someone in Salt lake on that one ), and on Sunday, the silverlight plugin locked up and refused to re-start. We switched them to the HTML5 player and heard no further complaints.
At another location, they plugged in a HDMI to VGA adapter (to connect to the VGA input on the projector) and that switched the audio to use the HDMI.
I showed them how to switch the default audio device and all went well from there.

Aaron Z