The 36C3 info-beamer setup
Like in the three years before, I’ve been running the info screens at this years 36C3 / Chaos Communication Congress, a yearly conference organized by the Chaos Computer Club. There have been around 17000 visitors from all over the world and multiple stages with talks on technical and political issues related to security, cryptography, privacy and online freedom of speech.
Photo: CC BY 2.0, Assembly Hall by bin hacken, on Flickr
There were a total of five large halls, some of them with more than one projector. During downtime between talks, the projectors switched over to a Pi3 connected to the AV system in each hall. Additionally another Pi was connected to an HDMI➔Multicast encoder. The video stream was then shown on ~40 screens in the conference center building.
Each Pi was assigned the same scheduled player based setup, showing upcoming talks, a twitter feed and projects submitted by attendees:
Photo: Snapshot taken from this talk.
At https://36c3.info-beamer.org (now defunct) a custom content management system allowed attendees to sign up using their github account and upload their own content, showcasing interesting projects, events or installations. A total of 138 users signed up and the majority of them contributed at least one image or video.
The dashboard for uploading/managing content
The main page showing all uploaded content
Every few minutes, the content management system would sync all content into a 36c3 info-beamer account. It automatically added new pages to a scheduled player based setup. With around 150 submissions, that got quite large. Here’s what an individual page looked like in the info-beamer setup editor:
The code that does all the syncing can be seen here. The
/sync endpoint was called by a cronjob every 5 minutes.
“Proof of play”
During the event, I’ve modified the scheduled player package so it generates an event for each played image/video. These “proof of plays” would then be sent out of the info-beamer process into a simple forwarding service running on the Pi. It would gather events and submit then every few seconds to the content management system as HTTP post requests to the
/proof endpoint. It would store the last 1200 seconds of played images/videos in a local redis. A dedicated page allowed visitors to see the last ten pieces of content on a screen:
Adhoc API keys
So far this is all pretty similar to how the setup in the previous year works. The main difference is how it was all implemented. The page now uses Vue.js for any interactive page instead of server side rendering.
Additionally the content management system no longer stored and forwarded uploaded content. Instead is used adhoc API keys. This is a new mechanism added to info-beamer hosted just recently. It allows you to programmatically create a short-lived API key with custom limited permissions. The content management system used this mechanism to hand out single-use API keys to users when they intend to upload new content. This API key was restricted so it only allowed uploads to a predefined filename and further limited the content to FullHD or less than 10 second videos. This is neat as the user can directly upload content into the 36c3 info-beamer account.
The content management system then used
userdata to add state information (like the moderation status) to each uploaded asset.
Again using adhoc API keys, the content management system has a hidden interface for stage managers. This allowed them to interrupt the current content with predefined slides showing (for example) information about available translations for the next talk:
The complete source code for the content management system is available at https://github.com/info-beamer/36c3-cms. It shouldn’t be treated as production ready code, but more as an example of how a custom external content management system using info-beamer.com as its backend might work.
The collection of all uploaded project images/videos can be downloaded here (ZIP, ~85MB).