Better/faster: improving our video workflows for Android Makers 2019

After each Android Makers event we ask to the participants the things they liked and the ones to improve for the next year. In the audience survey of 2018, the videos of the talks were on top of that list.

This article will explain what we did to improve the quality and the release time of the Android Makers 2019 videos.

Last year review

For us, the most important part in a video of a talk is the slides and the audio because this is where the content is. This is why, in Android Makers 2018 we tried to focus the camera on the screen rather than the speaker or the stage. This strategy was not as good as expected and this is why:

• filming a screen is not ideal as it can produce a flickering and annoying auto-exposure changes. Another problem is that the speaker was sometimes out of the filmed area.
• the publishing time was not good enough: we publicly released the 70 videos of the 2018 edition more than a month after the event. This delay was due to the fact that we had to cut and re-encode every raw video. Indeed, when a video is recorded by the camera, the output video is split into multiple raw files. To have an exploitable video, we need to merge these files into one and then trim the video from the start to the end of the talk. The person in charge of producing the video and one person of the team did that “manually” for each video (more than 70 videos). After this step, we needed to add an introduction image that should fade into the video. After having the resulting video, we needed to upload it on Youtube and put the correct title, description, and thumbnail. Since we did not want to do that manually on every videos, we implemented a python script that runs an ffmpeg command to get the resulting video and to upload this video to Youtube with the correct metadata.

Here is one of the worst example of the video quality of Android Makers 2018, sorry Britt!

For these reasons, improving the Android Makers video process was one of our top priority for the 2019 edition.

What we tried

Months before the event, we brainstormed about what we could do to improve the content of the videos and to make them available quicker.

In order to improve the video quality, we wanted to have a video containing two parts: one big for the slides, the other, smaller, for the speaker.

The first solution we came up with was to launch a screen-record on the laptop of the speaker and to create a video containing the two parts in post production (i.e. after the talk is finished). Our friend (and member of the PAUG) Edouard Marquez was using that solution for his Flutter meetups.

This process is quite long since we have to adjust the timing of the two sources. This was way too long to do it on more than 60 videos, so we considered to synchronise the two streams thanks to the audio (this tools has been slightly tested: https://github.com/bbc/audio-offset-finder).

This solution was a bit too complicated, required to operate on the laptop of the speaker and had a lot of work to do after the conference.

What we did

To speed up the release process of the formerly described solution, we wanted to edit the video while it was recording. The main idea is to merge the camera stream and the slides stream (output from the speaker laptop) in a laptop that will produce the video.

We met Philippe Sentenac who is used to produce videos of this type. He has been kind enough to share his setup and help us record the September meetup (here is the video of one of the talk). In the meantime, Edouard Marquez started investigating a similar setup for the Flutter meetup and guided us through the hardware selection. Thanks to these experiences, we had a good grasp on the work to do to quickly produce quality videos. So a big thanks to Edouard and Philippe!

We decided to explore this solution and see how it would scale for Android Makers.

At Android Makers, rooms are very big so we can’t have a laptop connected to the speakers laptop while it is also connected to the camera. Luckily, in big rooms of the Android Makers venue, the control room is able to give us the stream that is projected on the screen. This way, slides and camera can be close enough to both connect them to one laptop that can record a video that merges these two streams.

For the smaller size rooms (10 meters long max), we should have a long enough cable from the speaker laptop to the recording laptop that is placed near the camera. As HDMI cables are limited in length, we opted for SDI cables that can accommodate longer distances.

Once the setup for each room has been defined, we could make our shopping list.

The equipment list

Let’s recap the technical setup of the Android Makers rooms:

• Two rooms with a control room that can provide a copy of the stream that is displayed on the screen, a camera and an audio stream that is plugged into the camera (i.e. the sound is merged to the video of the speaker by the camera)
• Two smaller rooms with a camera filming the speaker and getting the audio, and a laptop far away (10 meters) providing the stream of the slides.

Also note that the video producer will provide two camera that have an SDI output for the big rooms and two camera with a mini-hdmi output. The computers in charge of recording the video will be provided by organizers of the Paris Android User Group.

Here is the equipment we need:

For each big room, we need two videos converters (one for the camera, the other for the slides stream). For each small room, we need one hdmi splitter (input: hdmi from the speaker laptop, output: one hdmi to the screen/projector and another to the laptop that does the record) and two video converters (one for the camera, the other for the slides stream).

Here is our shopping list for one big room:

• 1 AverMedia ExtremeCap SDI (SDI -> USB-C)
• 1 BlackMagic UltraStudio Mini Recorder (HDMI/SDI -> Thunderbolt 2)
• 1 Decimator MD-LX (SDI/HDMI -> SDI + HDMI)
• 3 hdmi cables
• 1 long SDI cable
• 1 small SDI cable

As you can see, this whole list cost quite a lot for the 4 rooms. The budget of the video part in Android Makers has increased this year, but this should be considered as an investment. Moreover, the cost of the video production will be decreased since we will lower the post-production work.

On the software part, we will use OBS to do the record.

Here is a schema of the setup for a small room:

We received the whole equipment one week before the event. We made two meetings to install the software, test the hardware, and understand how the overall setup works.

After these meetings, we shared with the team the OBS scenes to use on the D-Day. This json file describes the scenes that we can use and the output.

We decided to have 3 scenes.

• The main one shows the slides and the speaker at the same time. This scene has a white background that contains the Android Makers logo. On the top left is the speaker stream. This part is a cropped rectangle of the camera stream. And in the center are the slides.
• A scene that only shows the slides, full screen.
• A scene that only shows the speaker, full screen.

This OBS setup is available on our Github.

The D-Day

On the D-Day, we had one staff member dedicated to each room. This person was in charge of setting up the hardware, testing mics and audio gain, changing batteries when empty, changing the scene if needed… and of course, pressing the start/stop button !

Publishing the videos

After the event, we got back home with 66 videos. To release them, we re-used the scripts that we made last year, but with some modifications (and a Kotlin script implementation, yay). All these scripts are open-sourced: https://github.com/paug/video-tools.

The first modification we did was to improve the ffmpeg command to adapt to new need we had this year. Hence we added a way to:

• trim the start and the end of the video
• only use one audio channel and output it on both channels. This is because we kept two different audio sources on the camera on some rooms: one was the speakers mics, the other was the camera mic (as a fallback if the microphone of the speakers did not work). So we had to remove afterward the audio channel that was not useful.

Second modification was due to the YouTube API quotas limitation. The YouTube Data API v3 now requires to be verified by Google to use the auth/youtube scope. As we did not have time to do it, we used the “unverified” free tier that only allows smaller quotas. With this reduced quota, we could not use the script to upload all videos anymore. This is why we uploaded manually the videos once they were generated. We slightly modified the script so it can be used to only update the metadata of a video and upload the thumbnail.

With this process, a video gets generated in around 13 minutes and uploaded in 10. This is how we could publish all the 66 Android Makers videos for 2019 in 13 days.

Android Makers 2020 and beyond!

We improved the overall video quality a lot this year! And we want to improve it even more next year.

• The speaker part of the video is not as sharp as we can expect. Moreover, the speaker is sometimes underexposed or overexposed and it changes according to the speaker slides. This is because the cameras were recording the whole stage and we were cropping this stream to only show the area where the speaker is. This choice makes the speaker part a rectangle of 200x400 in a 1920x1080 stream. The exposure problem is also due to the fact that we were filming the whole stage: the auto-exposure of the camera is computed on the speaker but also (and mainly) on her/his slides. We made the choice to film the whole stage because we wanted to have a fallback if the recording laptop would crash. Since it was our first time, we really wanted to assure our back. Since our solution seems to work, we can choose to drop this backup solution and zoom on the area where the speaker can be. This way, we could have a 1920x960 resolution and the auto-exposure would be computed only on the speaker.
• Some videos are laggy. We had one recording computer per room, and each computer was different. We had a high spec MacBook Pro and some old MacBooks. It seems that the oldest MacBook could not handle the two 1080p input streams too long. For next year, we will try to either improve the input/output config in OBS or, if this does not fix the problem, come with computers with better specs.
• The 13 days release were good, but we can still improve. We lost some time this year to get all the settings to correctly generate the video (the audio channel to keep, the start/stop time and some metadata such as the tags). Next year, we could prepare a proper file that can gather the data we need and fill it directly during the event.

Overall, improving the videos was a lot of work… and a lot of fun! We never imagined we could learn so much about SDI/XLR/MIC/MKV and other weird acronyms, but we’re glad we did and we’re quite happy with the results. You can see for yourself on our Youtube page.

Don’t hesitate to let us know what you think. Stay tuned for more improvements next year!!!

Thanks a lot to all the Android Makers team (especially Martin and Eyal) for their help on this article, and to Antoine for his review. ❤️