A video published on the front page of the newspaper Aftonbladet reached over 146,000 simultaneous visitors less than a minute after it was shot in Ukraine during the Euro 2012 soccer championship. This was made possible by the Swedish company Shootitlive, which is using the latest in web technology to make it possible for news organizations to provide real-time video and photo coverage from events around the world. Today we’re talking to one of its developers, Emil Stenqvist, about what Shootitlive does and how it does it.
The emergence of live media coverage from anywhere
There’s no denying that video, photos, and other types of digital media is extremely popular on the web today. On YouTube alone, over 4 billion hours of video are watched each month, and Facebook currently stores 200 billion photos. The cutting edge in online publishing is to be able to broadcast real-time video and photos from anywhere in the world, which is, of course, of special interest to news organizations.
That’s where Shootitlive comes in.
With Shootitlive, photographers equipped with cameras that transmit photos and video wirelessly can publish images and video clips on the web in a matter of seconds. Real-time media feeds can be embedded anywhere on the web, and served up to users in a variety of situations. These feeds enable newspapers, photographers, and others to cover live events by removing all the technical hassle involved in sending, storing and distributing the media. Shootitlive’s customers include Aftonbladet, VG.no, Italehti.fi and some 40 other big nordic newspapers.
Scaling and performance
Clearly, scaling and performance are at the top of the agenda at Shootitlive. “Serving content on multiple news sites is the equivalent of being Slashdotted and HackerNewsed at the same time, and results in a very discontinuous load pattern with lots of spikes,” according to Emil. Despite these challenges in terms of traffic, by using cloud technologies, a team of less than 10 people at Shootitlive can handle close to 150k simultaneous users. That is pretty cool when you think about it.
But scaling when demand requires it is just one side of the coin. The other is that the technology has to be up and running in a reliable manner. Being a self-hosting service oriented company, Shootitlive’s uptime is their clients’ uptime. In other words, a failure on Shootitlive’s part can, potentially, break many contracts that it has with customers. For example, news sites fail to render, photographers can’t provide media from the events they’re contracted for, etc.
To make sure that its infrastructure is up and running as it should, Shootitlive uses Pingdom’s website monitoring service. Emil says, “Being a third party that can immediately notify us if we’re having problems, Pingdom has been great for us. The Twitter notifications are awesome.” Shootitlive also uses Pingdom’s Public Reports feature. You can see their public uptime record here and here.
On the backend
What goes on behind the scenes at Shooitlive? Emil explains,“We use Amazon EC2 for elastic scaling, SQS for distributed job queuing, S3 for static content, CloudFront for reducing latency. And The Shootitlive Player is an HTML5 plus JavaScript app that loads media from their servers in the form of JSON playlists.”
“Our backend is written in Python running on Debian servers on Amazon EC2. Had we done this again we’d probably have looked into the range of great services that have popped up – for example zencoder.com or encoding.com. But when we introduced video support in early 2009 they couldn’t provide the short time encoding that we require. Therefore, we’ve built our own encoding services using ImageMagick and FFMPEG.”
Shootitlive has endorsed the principle of KISS – not the rock band but rather the principle of Keep It Simple Stupid. Emil says, “to keep things simple on our end, content is statically stored in Amazon S3 in the form of media files and JSON playlists. Server costs also play an important role here, of course. No one in their right mind would have the same content dynamically generated over and over.”
This strategy is a time-tested way of decoupling the two tasks of serving and generating. In practice, servers could go down, or a horrible bug could be introduced in the code, and yet visitors wouldn’t notice anything apart from the fact that no new content shows up.
On the frontend
For most users, what they see of Shootitlive is its player embedded on a website somewhere. The player is written in JavaScript and HTML5 and aims to provide a seamless experience for the visitor who simply want to see pictures and movies related to an article.
“Since we can potentially break the whole page on which the player is embedded, we have put much work into making this tag safe and non-interfering,” says Erik. “This involves making it load asynchronously, wrapping all third party libraries to avoid JavaScript namespace clashing, catching JavaScript errors, and much more.”
If this is something you’re interested in, the team at Shootitlive has an ongoing blog series detailing the development of its player and on creating embeddable JavaScript widgets in general.
What lies ahead for real-time video
For Shootitlive, things are happening fast. Developments to the service, continuously tweaking performance and functionality, as well as signing up new customers continue at a fast pace. One area in particular where it is considering expansion is to offer an API.
We’re hoping to come back to Shootitlive at a later date to follow up on how things are developing. At Pingdom, we’re obviously very interested in this kind of scenario, understanding better how a company deals with issues of scaling and performance. We are constantly trying to improve our offering of digital monitoring experience.
