Video and Sound Synchronization

We took another stab at a stake conference broadcast from the stake center to two other buildings. The audio and video were never in sync.

At the stake center (we monitored a return feed) the audio drifted a little during each talk. We found that flashing a still picture for a few seconds between speakers (we used a temple) caused the audio and video to synchronize again. They then drifted apart as the next talk continued.

At the other two buildings, the drift was more noticeable. Sometimes the audio was ahead of the video. Other times the video was ahead of the audio. And the audio and video did not sync after the still picture.

We are using Church software on laptops through the Church servers. Everything worked well on Saturday. Alas, our conference broadcast was on Sunday.

What causes the audio and video to be out of sync on the download? Why is the situation different in each receiving building?

Any suggestions on what can we do about it?

Not my area of expertise, but I'm guessing that your ISP or network couldn't keep up with the stream. The static photo (a minimal video bit rate since there is no change) allowed everything to sync back up. Unless the photo somehow disrupted the stream (restarted it), I can't see why the photo would cause things to sync back up.

You might also look to see the CPU load on the encoding machine. Depending on how the process is divided up between the cores, the CPU may seem to have plenty of headroom if you look at the total, but the active cores are maxed out.

russellhltn wrote:You might also look to see the CPU load on the encoding machine.

This would be my guess as well. Did you have any sync problems during testing?

Question: Was the sync problem the same with all buildings? If so, then that suggests a encoding/upload issue. If not, then that suggests a download/local CPU load issue. And the two are not mutually exclusive.

mikerowaved wrote:Did you have any sync problems during testing?

Yes. During testing, the audio was delayed (the opposite of what we normally experience) by about a second every ten minutes. That was where we found that the still picture would sync things again. Perhaps, as Russell said, it was just allowing the audio to catch up.

russellhltn wrote:Was the sync problem the same with all buildings?

No. During the actual broadcast, the video was ahead in one building and the audio was ahead in the other two. And neither of the other two buildings returned to sync with the still picture on Sunday. (They did during test.)

I gather that the audio and video are processed separately. Is that true on both the sending and receiving end?

We will have to figure out how to monitor the individual cores if audio and video are being processed separately. Total CPU was never an issue.

lajackson wrote:I gather that the audio and video are processed separately. Is that true on both the sending and receiving end?

To some extent, yes. And when things come to crunch time, systems have to decide what to do to catch up.

For example, if I'm watching a YouTube video, I tend to hear audio just fine, but the video can freeze and jump to get back in sync.

russellhltn wrote:For example, if I'm watching a YouTube video, I tend to hear audio just fine, but the video can freeze and jump to get back in sync.

That is what we expected and what I normally see. That's why we were surprised that the video got ahead of the audio.

We had this problem this past weekend during testing in one of the two buildings, and 6 months ago during the live session also in just one of the two buildings (different buildings, different computers). The audio was behind. In each case a restart on the receiving end fixed it. Never had a problem in the past with slower computers. I wonder if some background process was running.

I really wish we could just buy computers for the stake that we could set up for our a/v purposes.

craiggsmith wrote:I really wish we could just buy computers for the stake that we could set up for our a/v purposes.

For webcast purposes, your Stake President can direct the use of local unit funds for purchasing such equipment. See Section 8.3.3 here Local Unit Provided Equipment.

We already have very capable equipment. What we don't have is the ability to determine if we are having a problem at the originating site (we think not), at the receiving site (again, we think not), or along the way "somewhere".

There is a black void at the "somewhere" point that we have not yet been able to crack. So we do not know what to do from here. With 2M up and 8M down at every location, you would think we could do a successful web broadcast.

You also would think we would not need to use the lowest speed on the uplink, which caused the sound quality to drop into the sewer.

But for now, we would be happy just to sync the video and the sound. I can stream stuff on my computer at home until the cows come home, and I never have a synchronization issue. I can stream other stuff at the meetinghouse without a synchronization issue, TV, general conference, women's meeting, whatever.

What is so special about the Sunday morning of stake conference?

lajackson wrote:What is so special about the Sunday morning of stake conference?

Is it because half of the USA is doing the same thing and the Church servers can't cope?

Biggles wrote:Is it because half of the USA is doing the same thing and the Church servers can't cope?

You'd think the folks running the servers would notice. I'm wondering if the network/isp they're connected to is saturating. It seems to me that would be more likely to escape notice.

I don't remember for sure, but I seem to remember a mention that the Church servers were only about 65% utilized during a peak Sunday morning several years ago. I suspect that is why they don't think they could be a contributor to the problem.

danpass wrote:

craiggsmith wrote:I really wish we could just buy computers for the stake that we could set up for our a/v purposes.

For webcast purposes, your Stake President can direct the use of local unit funds for purchasing such equipment. See Section 8.3.3 here Local Unit Provided Equipment.

Thanks! Looks like there have been lots of updates; last I heard we weren't aloud to buy computers for any purpose.