Webcast testing glitches

I have been testing the (new to us) webcast portal and VidiU encoder, in preparation for our upcoming stake conference.

We have the following equipment configuration:

SD cameras producing 4:3 aspect ratio video.
HDMI output (480i) from a Black Magic Design ATEM video mixer connected to the HDMI input of the VidiU.
Meetinghouse audio connected to the analog audio input of the VidiU.
VidiU loaded with currently recommended 2.4.7 firmware.
Stake Center where all initial broadcast and receive testing has taken place has 60/12 Mbps cable Internet service.
VidiU broadcast settings are configured as advised in the lds.org help page, with Medium quality, Adaptive Bitrate disabled, Frame-rate full and Audio Quality mobile.

I have been scheduling events of type Test (full), using either the US West or US West 2 region and the 4:3 broadcast profile.

Issue 1:
On the receiving computers, the video stream has occasionally stalled. I'm in the process of troubleshooting this issue. Most of the time, it resumes on its own. When it resumes, I see a message indicating that due to a slow network connection, only audio is available. When the audio resumes, it does not resume where it left off, but rather jumps ahead to a more current position in the buffer. Is it normal to lose segments of the stream when playback resumes after stalling?

Issue 2:
Even though we are producing 4:3 video and using the 4:3 profile setting on the portal, the player nearly always automatically stretches the video horizontally. This happens whether or not I check the Limit to SD box for the receiving site when scheduling the event. There have been a few times where the player randomly switches between a true 4:3 and the stretched wide display, while the stream is playing. Each time it switched, there was a split-second audio dropout. Is there a way to control the aspect ratio used by the player?

First of all, I'm envious of your ATEM setup. Those are nice to work with.

So are you both webcasting and receiving in the same building? You should have enough BW to do that, I was just curious. You mention "the receiving computers", how many are there? What program are they using to play the video? (e.g. Windows Media Player, VLC, etc.)

Mikerowaved wrote:So are you both webcasting and receiving in the same building? You should have enough BW to do that, I was just curious. You mention "the receiving computers", how many are there? What program are they using to play the video? (e.g. Windows Media Player, VLC, etc.)

The initial phase of testing has only included webcasting and receiving in the same building. We are about to expand testing to receive at remote locations.

At most, I have had 3 concurrent receiving devices. 2 computers with wired network connections and an Android phone on the WiFi. For each device, I logged into the portal and entered the event code. The video played in the browser, which was Chrome in each case.

So, you didn't turn off the WiFi? Even if you were the only one in the building, there could be neighbors.

russellhltn wrote:So, you didn't turn off the WiFi? Even if you were the only one in the building, there could be neighbors.

TM showed DHCP allocation only for the expected number of devices and Fing confirmed which devices were on the network. It was at a time when I was the only person in the building.

Every time we have done a webcast of stake conference over the last 2 years we always have a few times throughout the conference where there are hiccups with the stream, they almost always self resolve (while I'm looking into potential issues I get messages saying "ok, it's working now", and it's rare that I've changed anything). And in most cases the stream reconnects wherever it happens to be (receiving sites miss some of the audio). It's rare that it resumes from where it drops.

In regards to issue 2, we saw that same behavior tonight during our adult session of conference. The stream would randomly switch from 4:3 to 16:9. We actually had 2 different machines playing side by side to compare and one was doing it and one was not. We were originally seeing the issue in IE & Safari (due to the current warning in the portal re: Chrome & FF). I switched one machine over to FF or Chrome and it was just displaying at 16:9, while the other machine running in IE was switching aspect ratio's. We had other users viewing the broadcast reporting the 4:3/16:9 issue as well.

This sounds like the same issue I'm having. I broadcast in 4:3 as well, and after running a test with my remote locations this evening and getting some complaints of "choppiness" I thought I'd go take a look for myself. Below is a link to a video I shot of the strange behavior. We've been running this setup since we changed to rtmp streaming with great success, and as recent as April. Now it wants to shift back and forth between aspect ratios, and on one computer it did this a couple of times and then gave me the spinning blue icon and froze.

Take a look, is this what you are seeing?

https://www.youtube.com/watch?v=gikeYBdzNSg

Thanks,

Jack

Looks to me like it keeps switching between two streams of different aspect ratios running at slightly different times. I wonder if it's due to trying to find a stream with a bitrate it likes.

jhawkins75 wrote:This sounds like the same issue I'm having. I broadcast in 4:3 as well, and after running a test with my remote locations this evening and getting some complaints of "choppiness" I thought I'd go take a look for myself. Below is a link to a video I shot of the strange behavior. We've been running this setup since we changed to rtmp streaming with great success, and as recent as April. Now it wants to shift back and forth between aspect ratios, and on one computer it did this a couple of times and then gave me the spinning blue icon and froze.

Take a look, is this what you are seeing?

https://www.youtube.com/watch?v=gikeYBdzNSg

Thanks,

Jack

Yes, this looks like what I saw. It only happened once in my testing and only switched aspect ratio 2 or 3 times.

Later, I discovered a "Widescreen" setting in the VidiU Video/Audio settings which was set to "Auto". I changed it to "No", since we are doing 4:3. If your's is set to Auto, try changing it. Unfortunately, even with Widescreen set to No, we are still seeing the video stretched wide. The stretching occurs regardless of whether Widescreen is set to Auto, Yes or No.

Actually, I should test this again. We got a new VidiU, because the front panel display died on our original device and I loaded the newest firmware on it. We used the new one a couple of weeks ago for a stake general priesthood meeting webcast and the video was stretched as we've become accustomed to. But I didn't check or modify the Widescreen setting. I'll test and report back.

The stretching occurs regardless of whether Widescreen is set to Auto, Yes or No.

Interesting. One thing that jumps out to me is that I broadcast at 640x480 and when I start my stream the status says that it is a 640x480 stream and then eventually it switches to 1920x1080. Does that mean that the streaming server is upscaling and reencoding my SD stream to widescreen HD?

This is an issue with the current player and the aspect ratio pending on the bitrate that is being played. We are trying to correct this issue with the new player that is scheduled to be released soon.

rannthal wrote:This is an issue with the current player and the aspect ratio pending on the bitrate that is being played. We are trying to correct this issue with the new player that is scheduled to be released soon.

Oh great, do you keep a change log somewhere that I can refer to?
The problem I have is I only think about streaming events for church for a few weeks every 6 months, so when there's an issue all I can say is it worked last time.
This last time I got frustrated and decided to set up my own nginx rtmp server with multiple HLS streams running through a videojs player. It worked beautifully, but I missed the nice stream monitoring tools you provide for us, so hopefully come spring it all goes smoothly.

We are going to put on up on the mhtech.lds.org site. I don't know if it is currently up there today. If it is not, it should be there soon.

In the mean time, I try to post changes and things here on the forum that are important.

The first 3-4 broadcasts I did were miserable. I could not get it to work without glitches, both big and small. Finally I bypassed the filter/router in each building and plugged directly into the cable modem, and ever since I have had zero issues. I even upped the video and audio quality. I’d recommend everyone do this if the building’s wiring permits. We have Ethernet wired from where the Teradek device connects to video as well as where we have the receiving laptop(s).

adamhaining wrote:The first 3-4 broadcasts I did were miserable. I could not get it to work without glitches, both big and small. Finally I bypassed the filter/router in each building and plugged directly into the cable modem, and ever since I have had zero issues. I even upped the video and audio quality. I’d recommend everyone do this if the building’s wiring permits. We have Ethernet wired from where the Teradek device connects to video as well as where we have the receiving laptop(s).

I agree that hard-wiring everything is far better than relying on WiFi.

Just curious, which cable company is your internet provider and what kind of upload speed are they giving you? You might want to run some speed tests both through the firewall and without it, because the firewall shouldn't have much impact on the results. If it does, it might be defective or need to be reconfigured. I've never had to bypass the firewall, unless I was uploading to YouTube Live. Is it possible that when you plugged directly into the cable modem you shut out other users, such as everyone's WiFi devices, that might have been hogging resources on your LAN?

I'd be leery about connecting devices directly to the internet and not behind at least a router. They could easily be compromised during the broadcast.

You might check and make sure your modern is acting only as a modem and not adding another router between the firewall and the internet.

For all kinds of testing glitches you can start afresh by reset the setting of router. This will enable and ensure that firewall and system are fullly working.

adamhaining wrote:The first 3-4 broadcasts I did were miserable. I could not get it to work without glitches, both big and small. Finally I bypassed the filter/router in each building and plugged directly into the cable modem, and ever since I have had zero issues. I even upped the video and audio quality. I’d recommend everyone do this if the building’s wiring permits. We have Ethernet wired from where the Teradek device connects to video as well as where we have the receiving laptop(s).

We also had huge problems going through the church firewall. Fortunately the cable modems and DSL modems in the buildings also provide NAT and firewall protection, so even "directly connected" is safe and protected.

Ironically, when we tested this past week, even with the latest versions of everything, we still had to bypass the firewall on the transmit side in order to get the all-in-one beta receivers to work on the receive side. We've relied on YouTube and not had a single problem with any broadcasts, but in an effort to support the department that makes the webcast service, we plan to simulcast to both YouTube and the Church system for our conference in 10 days. The upload bandwidth at the Stake Center appears to handle two streams at 2.5 Mbps OK (based on our testing thus far).