Sharing our experience with Virtual Sacrament Meeting Broadcasts

[sbradshaw]

There's at least one unit using a simple "member equipment" approach! As I've stated elsewhere, while I appreciate techies (at least to me you guys are all techies) who understand the ins-and-outs of audio/visual stuff, we have a sufficient implementation which works for us: using Zoom on a cellphone which is placed in a small tripod on the podium. The virtual attendees say that the picture and sound comes through fine for them. We use Zoom settings to simulate a streaming (non-interactive) sacrament meeting broadcast. Our particular Stake hasn't been involved in implementing any solution for us, they've really farmed it out to each local unit to figure out. As our leaders and members are familiar now with Zoom, it's good enough for us.

Zoom does a good job at filtering out background noise, which probably compensates for not connecting directly to the sound system. Our ward also has a simple setup – a laptop computer between the first and second rows in the chapel, sitting on a music stand, with the screen tilted so the built-in camera points to the speaker. Feedback from members has been positive!

[quintonrhq]

A few notes from using the OBS software for a sacrament broadcast. Basic setup: 2 PTZ cameras from the stake, ATEM mini pro, laptop, small firewall to create a subnet inside the church network for better camera control. Cable service is 6mbps up. The highest resolution allowed is 1280x720 using the church webcast system.
OBS settings:
Output advance audio track 1, encoder Nvidia Nvenc (laptop specific - experiment here to reduce the CPU load), enforce streaming service encoder settings, rescale output 1280x720.
Rate control CBR, bitrate 2100kbps, keyframe interval 2, preset quality, profile high, max b frames 2.
Video output scale 1280x720 FPS 30
Audio 44.1kbps mono mic/aux audio microphone Blackmagic , aux audio 2 disabled, desktop audio 2 disabled, aux3, 4 disabled.
It is really important to disable everything except the audio from the church feed otherwise you may have a sound injection from the laptop downstream from the monitor. Doing a test OBS run to disk is well worth doing.
No sync offset but hey with everyone wearing masks who can tell?
The ATEM mini will do the job and it has a really good audio processing section to gate out the hiss etc.
Very pleased with the OBS package, and free as well. Not for the Zoom crowd.

[rich_jones_1999]

I put this system together, and it has been working great for weeks now in our meetings.
Thank you for putting up the post on how you did it.

I do have a question, if you have the time to respond.
Last week, towards the end of the meeting, the streaming started kinda freezing/stuttering.
It would kind of stall, then put out some more frames, then stall again. (This is watching the FFMPEG running on the PI over an ssh link on a laptop behind me in the chapel)

My question is...
Do I need to be doing some kind of file system maintenance with this?
Should I be running fstrim or some other utility on occasion?

I had the know-how to get it running, with the information you provided, but I am not a Linux expert by any stretch of the imagination.

Any advice would be much appreciated.
Thank you!

[rmrichesjr]

I put this system together, and it has been working great for weeks now in our meetings.
...

Just in case I'm not the only one not entirely clear, are you referring to the system described at the very beginning of this topic/thread? Or, are you referring to one of the variations that might have been discussed between then and now?

Regarding the stuttering toward the end of the meeting, is it possible that the Pi's CPU or GPU might be overheating? If there is any question about that, opening any case the Pi might be in and blowing some cool air on it may help. I haven't monitored a Pi's temperatures myself, but I understand there are ways to do that. On other Linux systems, "lm-sensors" is the package for checking/monitoring temperatures. I'm not sure whether the Pi might have a variation on the theme.

There are lots of ways to check on what might be slowing down a Linux system. Here are a few of my favorites:

• "top" to see what processes are using how much CPU time and a few other things
  "vmstat 3" to watch storage/disk traffic
  "free -h" to check on memory usage

If "top" shows some rogue process consuming a lot of CPU time, that might be the culprit. If "vmstat 3" or "free -h" show any swapping/paging traffic, you're out of memory.

[mrbitsch]

...
My question is...
Do I need to be doing some kind of file system maintenance with this?
Should I be running fstrim or some other utility on occasion?
...

You're welcome, I've got another update I'm getting ready to push here to help deal with some of the YouTube API changes that recently went into effect that have taken out some of the automation I've been able to enjoy with it.

As far as the stuttering issue, and file system maintenance. If you're running Rasbian or another Pi oriented distro on it, I don't think file system maintenance should be needed. I've easily got a dozen Pi's running around the house and the office, and I've never encountered a need for that. (anecdotal information at best as that may be) The scripts as written shouldn't be writing many files to the filesystem.

Are you running this on a RPi4 or one of the older models? I'm not certain how well this would run on the older pis (it should be okay I'm streaming from my 3D printer on a Pi3 while also running Octoprint, but I haven't tested this specific setup on anything other than a RPi4). If you're monitoring the stream I'd take a look at htop and see what the CPU utilization is looking like, usually the stuttering means you're not able to transcode the stream fast enough which on the RPi I've so far only found 2 causes for, 1) you're not using the h264 stream from the camera (you would notice that from the get-go most likely though) or 2) you're maxing out all the cores and there's not enough processing power left. For number 2 I've only had that happen when the RPi starts throttling the CPU because it's overheating (which is likely something you'd see later in the broadcast)

If you want to check the temp on your RPi just issue the following command '/opt/vc/bin/vcgencmd measure_temp' and you'll get the CPU die's current temp out in C. The RPi is going to start soft throttling the CPU when that gets over 60C, and by the time you hit 80C isn't going to be throttling it pretty hard.

I did quite a bit of testing with the broadcasts and cases before I deployed these, hoping I could find a fanless case to use for this, but in my testing it wasn't possible to do an hour long broadcast without having a fan on the system, so if you're using a fanless case, that's probably where I would start.

[angadimo]

Thanks for writing. here is the URL for the Box folder: [redacted]
[Moderator note: Due to exposing RTMP credentials for upcoming webcasts, you'll need to send a Private Message to dbaresrc to receive the link.]

Carlton

Carlton, would you please share with me your documentation?

Thanks,
Michael.

[lewish]

Thanks for writing. here is the URL for the Box folder: [redacted]
[Moderator note: Due to exposing RTMP credentials for upcoming webcasts, you'll need to send a Private Message to dbaresrc to receive the link.]

Here's what you'll see in there:

There are 3 .txt files with web conference linking codes, one for each of our buildings. The Zoom meetings for QR and Stapleton are scheduled through the year (love the "repeat this meeting" option) and integrate into the HBE functionality. The church events (HBE and Stk Ctr) are scheduled two months at a time. I've submitted an RFE (request for enhancement) to the webcast group to add a repeating option to the scheduling process.

Hi dbaresrc,

I'm replying to an old post, and as a new user can't send you a PM. Could you send the link to me?

TIA!

[dbaresrc]

Thanks for writing. here is the URL for the Box folder: [redacted]
[Moderator note: Due to exposing RTMP credentials for upcoming webcasts, you'll need to send a Private Message to dbaresrc to receive the link.]

Here's what you'll see in there:

There are 3 .txt files with web conference linking codes, one for each of our buildings. The Zoom meetings for QR and Stapleton are scheduled through the year (love the "repeat this meeting" option) and integrate into the HBE functionality. The church events (HBE and Stk Ctr) are scheduled two months at a time. I've submitted an RFE (request for enhancement) to the webcast group to add a repeating option to the scheduling process.

Hi dbaresrc,

I'm replying to an old post, and as a new user can't send you a PM. Could you send the link to me?

TIA!

Sent you a PM.

[BEWilson]

Is there agreement between us the users and church headquarters as to how best to support virtual sacrament meetings?

How about somebody in the "know" setting up a zoom meeting where we can hear some instruction and ask questions. Record it so it can be played by later.

Kenyon Hart
STS Tyhee, Idaho Stake

I fully support this idea! I would love the hear more options using current stake hardware for zoom to be used. Not only does it offer a higher bandwidth encoding but can also be pushed to youtube live where viewers can get a better picture and sound than what comes from the lower encoded church broadcast system. Please teach me more!

Bryan Wilson
STS Stevensville, Montana Stake

[mrbitsch]

FWIW when we've done the Zoom -> YouTube Live for Stake Conference, the quality was awful and the audio sync was bad as well. The video quality on Zoom just by itself has always been worse for us than YouTube Live, and going from Zoom to YouTube seems to lose a bit as well. We've continued to use YouTube Live for all of our broadcasts, and Zoom for classes and other meetings like Presidency, Ward Council, Ward Youth Council, etc.

The wards in our stake are still using the setup I described at the beginning of this post, I've updated the scripts several times, and at this point everything runs pretty much hands off (at the risk of jinking it, I don't think I've had to touch anything in 4 months). With the updates to the church handbook section 27.9 we had asked the FM group if it was possible to install ethenet and audio connections at the back of the chapel so the camera wasn't right in front of the pulpit, and they said "no, we've been instructed this is only temporary and we should not install any new drops that aren't absolutely necessary", their claim was that 27.9 was only talking about stake conferences. Which is a very different read from what I got out of it, but hey, it's the FM group. They also forwarded this document that hopefully I'm attaching to this post, it's the first I'd ever seen of anything official from the church on how to setup for the broadcasts.

For our stake we're planning on keeping with the RaspberryPi/YouTube automated system for now, it works, it's hands free, and we've had several comments from surrounding stakes and visiting Seventies on the quality that I see no reason to mess with it. The Zoom webcast does seem to work well, but again we found the quality wasn't as good at the YouTube Live (also we've found it's a lot easier for people to be able to get a YouTube video up on their TV than Zoom) I'm not sure at this point if you can automate the Zoom webcasts like you can with the YouTube Live ones, but that's another factor for us.

One of the things that we like about he camera in front of the pulpit is that you get a nice closeup view of the speaker, but you still get a wide enough shot of the stand that you can see the organist/pianist. When you move the camera back to the back of the chapel you have to trade of either getting a wide enough shot to still see the organist/pianist but you've got a long shot on the speaker, or you zoom in on the speaker and can't see anything else on the stand. Not a problem if you have somebody running the camera, but I'm wondering if anybody has found a lens setup that allows for a closer shot on the speaker, while still getting most of the stand, with the camera at the back of the chapel. I'm guessing it's an optical impossibility, but then I've seen some cool tricks with tilt-shift lenses and other things that I would have thought were impossible.

Mike Bitsch STS Hillsboro, Oregon Stake