In September the Mirror reached us to help them with an online contest named the Gauntlet Challenge. The Gauntlet Challenge was part of a Mirror campaign that aims to position the Mirror as “the intelligent tabloid”.
In response to this ongoing campaign, the Mirror has received some “mean tweets” from the public, people that disagree that it is a smart tabloid. This Gauntlet Challenge was a direct response to those tweets.
The challenge consisted in answering questions about news that appeared in the previous week’s Mirror. The audience could play live against the Editor-in-chief Lloyd Embley, by answering the questions in turns. It was their chance to prove that they were smarter than the Mirror.
We had the mission of developing the online platform where the challenge would take place. This platform would handle the game between Lloyd Embley and each contender, while streaming it live to a larger audience.
The main requirements were:
- Allow each contender to participante in a video chat with Mirror’s editor.
- Streaming the chat to a potential large audience.
- The possibility of viewing and participating via both desktop or mobile.
- Have controllers for the assistant that was supporting the challenge session, as the score, and accept and skip the participants in the queue.
- Build it, test it, and deploy it to live in under 4 weeks.
We had two major challenges to figure out before starting building the application: 1 - Which technologies we could use so that users could participate and watch the live stream on both desktop and mobile. 2 - How to ensure we would be able to stream the event to all viewers. As it was quite difficult to estimate the audience size, we required a solution that could scale easily.
They are naturally interdependent - to choose the right infrastructure we had to take into account the technologies we were going to use for conference and streaming; at the same time, we had to be sure to choose a technology that could scale.
Note: Conference mode is when two (or more) people are having a conversation in real-time between each other - in this case, the two players. Streaming mode is when you are assisting to a video - in this case the live streaming of the two players playing.
During our research, we found various scalable solutions out there that we could use for both conference and streaming. But they all used… Flash.
Flash isn’t dead in the streaming business. Far from it. And we couldn’t use it because users had to participate and watch the stream on mobile devices, where Flash isn’t supported.
We knew the existence of the new and sweet WebRTC, and have actually used it in previous projects. But WebRTC technology is not meant for streaming. In the best case scenario, WebRTC would allow for around 150 to join, which was a hard limit that would not allow us to scale this to larger audiences.
We reached out for several streaming companies and field experts, but no simple and clear solution appeared. All options seemed to require a compromise on our initial requirements.
With time passing by we started implementing not one but two solutions. This allowed us to minimize risk and ensure a working product would be ready on the big day; even if with some level of compromise.
As we already had the conference component working with WebRTC, the ideal solution would be to find a third-party service that we could use to leverage our solution and stream the event at scale - this would require converting from WebRTC to other video protocol.
There are several services to stream common video protocols, but none offered the ability to convert from WebRTC. We had a plan to make this conversion ourselves, and then use a 3rd party to serve the streaming, now encoded as video. But it wasn’t trivial.
The second plan was about finding a way to build the entire infrastructure ourselves. The most obvious one was to implement a way to scale WebRTC to thousands of people. To get this working, we would have to hack around present WebRTC limits. Again, we had a vision of how this should work, but there was some risk.
The team was reinforced and split in two, each part focused on each plan, which were developed in parallel. All of this while maintaining a close communication with the Mirror about our progress and challenges.
After a lot of work on both plans, and various direct contacts with various streaming service providers, we heard about a beta product from Tokbox. It was still in closed beta, but could take care of this important part of the app - the product used WebRTC for the conference mode, and then streamed using the HLS protocol. After some conversations with the Tokbox team, we decided to work with them.
Excellent. This one is solved. What’s next?
Next we had to integrate the Tokbox streaming product into the conference system and the rest of the app’s features, such as: the queue mechanism, the score controllers, implement the frontend we designed, install the right streaming player, install the server monitorisation tools, etc.
Once again, all of this had to be built taking into account that it was a real-time app, with various people communicating with each other through desktop and mobile, and where all were subject to video delays and connection issues.
After some very hard-working days, we had the app ready to launch on what it was a successful close call of our own challenge.
The challenge took place at 8 pm of 28th of October, after an advertisement on the X-Factor show from that day. A few thousand people have watched the challenge, with dozen participating.
The assistant had a page with the score and queue controllers. The assistant could also see the list of people in the queue, and see their Twitter/Facebook profiles in case it would like to send them messages.
Not everything was perfect. There were some hiccups, and surely some things that we need to improve the next time. But in the end, it was a successful experience, where we were able to sort out a complex channel in due time, and help the Mirror prove their point.
P.S. A big “Thank you” to Melih Onvural and his team from Tokbox, for the excellent work and communication in making their beta product available on time for this live session.