IPTV: The Magic of Moving Pictures and Sound

Hello Everybody, I’m Dave, the Lead Software Developer here at Atlas Networks. To help provide some context for this article it’s helpful to have a little background about what I do day to day. I am primarily a Full Stack JavaScript Developer, dealing with both front end (user interface) and back end (server side) code. Our IPTV (Internet TV) Set Top Boxes (STB’s) run Linux, and display their information via a WebKit browser implementation. For my first article, I want to provide some insight into how we develop our IPTV platform.

The Software Components of the IPTV

The Software: IPTV is basically magic. On the surface it’s pretty simple; the user sits down, turns on their TV, and then proceeds to watch their favorite shows and movies. Behind the scenes, though, it’s a bit of a different story. The Atlas Networks IPTV ecosystem is comprised of the following pieces of software:

• iptvNEXT: The main server portions responsible for processing schedule and program data.
• Diver and DiverCORE: These are our DVR systems responsible for recording and playout of recorded shows.
• IPTVControlServer: Handles real time communication such as telemetry, remote commands for updating box payloads and software.
• ReCast: Handles webcam streaming and transcoding.
• Hubris: Our in house STB framework. This is what runs on the box itself.
• Cerberus: Backend control UI for sending out updates, resetting boxes, and troubleshooting via live telemetry.

The operation of the STB itself (Hubris) on the current build is comprised of 15 functional modules, 3 core modules, 1 bootstrap module (this actually loads the code to execute), 2 stylesheets, and 2 view templates. All of this spans over 9,000 lines of code, all written in our in-house framework. To provide a great user experience, everything from button presses to video events to server communication must work together in perfect concert. Low level control of the STB, such as video playout, volume control, and power management, are accessed via an API provided by the manufacturer of the box. This comprises fewer than 100 lines of the code.

I am a fanatic about optimization, because optimized software runs faster and provides a better user experience. To provide an idea of the extent to which this system has been tweaked and refactored, there are currently over 141 thousand lines of code in our Legacy repository alone, which does not include current development or production builds.

The Capabilities of the IPTV Platform

On the server side of things, iptvNEXT and Diver do most of the heavy lifting. Diver handles user requests for DVR recordings: processing, saving, and serving them on demand to users. There is a cluster of servers dedicated to just this task. In the past 60 days, these systems have handled over half a petabyte of data. iptvNEXT is where the real magic happens with that data. One of its main responsibilities is to take the 2.5GB of TV program metadata, and 55MB of TV Guide scheduling data that represent each day’s programming, and compress it down to roughly 11MB for display on your TV Guide. This data includes description, times, and other metadata for every show airing for the next two weeks.

The way that most IPTV systems work is that they only load the data being displayed on the screen. Our approach of storing all of the day’s data on the box was a lot more work to implement, but it results in an incredible speed-up. Storing this data on the box also allows us to speed up searching by several orders of magnitude, by parsing through all of this data and filtering it down for a response in only a few milliseconds.

The Build Process

I also want to talk about our software release process. Every IPTV release starts out life as a clone of the current production software. Development builds incorporate some extra tools, which help debug processes and keep track of certain performance telemetry – this lets us validate that the code we’re writing is fast and efficient. There are usually at least two different kinds of builds in progress; one is considered a, “Clean” build, in which everything is functioning predictably. We have a small but dedicated group of alpha testing users, who run the software under active development, and report bugs or other feedback. The primary goals of the clean development build are validation and addressing user reported items. The second version is considered, “Experimental.” There are a few very brave users who run this branch, and to my team and I, they are absolute heroes. This version usually contains minor to major redesigns (what we call “refactors”) of certain pieces of code, and focuses on performance and stability optimizations, as well as any new feature modules being built.

As we write code, it travels cyclically through a process of testing, bug fixes, validation, and user acceptance trials. We run software tests on the code to ensure there aren’t any outstanding issues, and then provide it a validation period for our test users to try out. During development, all of the functional logic is broken down from the language we write in, TypeScript, into more traditional JavaScript. At release time, some additional tooling packages are added, and the application is packaged up for release. Depending on the scope of the changes, releases can take anywhere from a week to a month or more.

That, in a nutshell, is some of the work that goes into the software running on your Atlas Networks IPTV service.