The Gig of Ham

One geek's contributions to the series of tubes

Jul 1, 2018 - 7 minute read - Comments - DevOps Days Austin Video OBS

DevOps Days Austin 2018 Audio and Video Postmortem

Now that Ernest posted his thoughts on DevOps Days 2018, I figured it was time to post mine. I’m happy to report that the video recording and audio for DevOps Days Austin 2018 was better than last year. By no means perfect, but better. Let’s dive into the details. For those who don’t care and just want to see the videos, they are posted on YouTube in the DevOps Austin Channel.

Improvements from last year

This year, the two biggest changes/improvements for the year were new systems for running OBS (and Linux powered at that), Behringer Feedback Destroyer modules on all stages, and new cardioid microphone headsets. The feedback destroyers combined with the new headsets worked better than we hoped. We still had some issues with audio quality on all three stages (getting to that) but it was better.

We also decided to not stream this year. This has positive and negative effects. The largest negative effect has been the wait for me to get all the videos edited and posted on-line. The biggest, most vocal feedback from last year was “One talk per video”. That takes time, and I’ve been busy/sick for the last couple of weeks.

We also changed the configuration of the space used at the venue this year, opting for all three stages to be in the “Touchdown Club” and not using the “Centennial Room” at all. This made navigation easier, setup easier, and teardown easier. We also moved all the presentations (sans a couple keynotes and half the ignites) to the first day meaning the wing stages were packed at the end of the first day making move out much easier.

The Wing Stages: Still room for improvement

The biggest thing that was not better than last year was entirely my fault: the audio on the wing stages. It was plain not good, and that’s do a miscommunication between myself and the facility organizer. The wireless mic systems we use are very range sensitive at the UT Stadium, I think a lot of this is because UT uses the same systems and they don’t turn theirs off. The RF environment is the textbook definition of hostile. The end effect is that the range between the mics and their receivers is very short. We mitigate this on the main stage by placing the receivers next to the podium which works great for the presenters, and not so great for Q&A. It’s a compromise.

The problem with the wings was that I normally have the AV stuff up front off to the side, but that wasn’t possible for a myriad of reasons this year. I didn’t recognize this until a couple days before, didn’t think it through, and just ordered longer speaker cables. Those were necessary, but so was needing to move the receivers up front. The #1 item on the shopping list for next year is the equipment (called a snake) to give us that.

The audio on the recordings from the wing stages wasn’t great either. Lots of pops, buzzing, etc. Discussion with the other orgs and volunteers has lead us to the conclusion that we’ve just outgrown the all-in-one PA systems we use for the wings. That’s also why one mic on the wings had the feedback destroyer, while the rest constantly caused feedback. Budget permitting, we’re going to upgrade the wings PA system to be the same components as the main stage to eliminate all of those issues.

The combination of the reception problems with the wireless mics and the connectivity problems for audio to the recording system meant that several talks had worthless audio from the wings and they won’t be uploaded. Sorry about that.

Main stage video: better, not great

The biggest issues on the main stage were:

1) Me not pushing the record button early enough (lost the first few seconds of a couple talks) 2) The speaker being nearly invisible on the camera.

The first problem is an easy fix, don’t depend on me to do it! Seriously, I plan to take a less active role in running the AV for the conference next year and let the volunteers do the bulk of the work so I can float around and not miss important recording events.

The second problem is more complicated. Lighting on the main stage is a hard problem, and we forgot a couple of key issues with it. The lights are controlled by rows, and if we are not careful when placing the screens then the screens wind up under lights and you can’t see them. The solution to this has been to turn off the front lights, but this makes it hard to see the presenters. This is also an easy fix, make sure the screen positions are good and we cover the problem lights.

The other issue with lighting the main stage is geometry. The cameras we use are not the best, I fully admit that. But the podium on the stage is not centered, so the large TV screens are in frame behind them (you can see this in the video) and everyone defaults to while background slides. This causes the camera to crank down the iris in order to see the TV clearly, which we don’t care about. My plan to fix this next year is to dump the stand alone podium, because we need the table, and put a standing podium on the desk itself. This should have the presenter between the TVs and the problem will be lessened, especially if we fix the lights over the project.

Wish list: better main stage camera

We had a lot of wandering presenters this year. Not a complaint! Being the guy who wore a headset mic so I could “gesticulate wildly” during my ignite talk, and we host the “Ghallager of DevOps”, so I totally understand! Manning a live camera is hard, so maybe we’ll do that. We’re going to need a better camera either way. We could also do the cool thing and get a really fancy camera, have it be static, and have OpenCV track the presenter and digitally pan when appropriate. I have testing to do for this. We’ll see how it goes.

Lack of training

Last year when I ran AV, I worked at a company that had a large lab space. I was able to bring all the equipment into the office, and we ran several training sessions on the weekend to get everyone familiar with how to setup, operate, and break down the equipment. I don’t work there anymore, so that wasn’t an option this year. Lacking that training was a huge mistake. I need to come up with a solution for that by next year. I’m also spending the off season writing rudioid microphone headsets. The feedback destroyers combined with the new headsets worked better than we hoped. We still had some issues with audio quality on all three stages (getting to that) bn books for setup, tear down, operation, and post-production so I can spread the load next year with those who wish to help.

Why did the videos take so long?

A lot of reasons. I was on a plane the day after DevOps Days Austin to go to the RedHat Summit for work. Was there for a week, and planned on working on videos when I got back. Unfortunately, I got food poisoning and/or a stomach flu on the way home (my doctor was rather confused by my set of symptoms), and that had me out for most of the next week. Then life got in the way, and then I needed to find a way to edit the videos. I’m squarely in the “Anything but Adobe Products” camp, especially since we are volunteer run and asking folks to pay for licenses is the worst. I talked to friends who do more YouTube production than I do, and they recommended Black Magic Davinci, but that didn’t like that I recorded everything in a MKV container. So, I wound up using OpenShot. Which is fine, but has no hardware acceleration for rendering. So rendering took a while. One of the videos had a sync glitch with the slides, and I owe Pete Cheslock the time to fix that video and replace it. But, in the interest of time I just edited as fast as I could and then uploaded them all. My new job involves a fair amount of travel, so scheduling can be tight, and OpenShot is new to me so I’m learning the UI for things like insets and transitions. It will be better next year.

As always, feedback is welcome in the comments below, via twitter, in person, or any other method!

comments powered by Disqus