EOS – Swisscom’s Android AOSP TV Middleware - getIT
Daughter and father at the kitchen table
Software Engineering

EOS – Swisscom’s Android AOSP TV Middleware

Swisscom was one of the first telcos in the world using Android for their set-top boxes. The internally developed TV middleware "EOS" powering all Swisscom TV 2.0 set-top boxes is now available as open source software. We publish the complete framework to build a customized IPTV middleware.
Lukas Hohl
Lukas Hohl, Leader for Teams Development
11 December 2018


The Android operating system (OS) was introduced by Google many years ago for touch screen devices – smartphones and tablets. In the Android Open Source Project (AOSP), the source code was available for everyone with a permissive license. Therefore, different companies started using it on “unusual” devices. One example was porting Android to TV set-top boxes (STB).


Beginning of 2012, Swisscom started investigating the possibility of using Android as a platform for their new generation STBs. There was a need to have a TV middleware (MW) natively integrated into the Android framework. Swisscom was licensing one of the very few available 3rd party MW solutions and Swisscom TV 2.0 was launched in 2014 (on the IP1200 STB).


The MW is crucial to have a successful TV product. 3rd party solutions were designed to run on a variety of devices supporting a plethora of standards. This made them inefficient in a much simpler environment such as Swisscom’s IPTV managed network. This led to the development of Swisscom’s own TV MW named “EOS”.


For the introduction of the Swisscom IP1400 (UHD) STB in 2016, EOS was used as a MW; and soon afterwards it was ported back to the older IP1200 (HD) STB.


EOS MW is based on the following design principles:

  • Simplicity – EOS is not a full-fledged TV MW. It has no intention to contain all bells and whistles of a generic commercial TV MW. It is focused on IPTV features only (e.g. it assumes that data is coming from the network).
  • Speed – Operations on IPTV streams should be as fast as possible.
  • Data control – Data control is crucial to have optimal IPTV stream playback. Correct fetching, feeding and flushing of the stream data is a must.
  • Portability – It should be possible to move to any chosen STB SoC without significant effort.
  • Extendibility – It supports functionalities required by Swisscom TV, but it can be easily extended if required.

General architecture

EOS is split in four layers (Figure 1):

  • System – Set of functions for OS porting and some general utilities used in EOS.
  • Streaming – Modules dedicated to the stream feeding, handling and playback.
  • Core – Modules providing core functionalities.
  • API – Native API definition and Java related functionalities and APIs.


The System layer is creating a base environment for the rest of the MW. OS Interface (OSI) and utilities are members of the system layer.


EOS is targeting Android OS, but in general it could be ported to other operating systems. For the sake of simplicity, EOS is using a small subset of OS facilities:

  • Memory management
  • Threads
  • Semaphores
  • Mutexes
  • Time primitives
Each facility has its own module and POSIX implementation (compatible with Android bionic libc). On top of the OS interface, there are various utility functions used through EOS.
Examples of such are:
  • Logging
  • Message queue
  • Message queue
  • Ring buffer


Handling of the stream data is in the stream layer.


EOS recognizes three types of stream handling modules:

  • Sources – Responsible for media recognition and data fetching. Practically these are implementing support for needed IPTV protocols (e.g. RTP, HLS, …).
  • Processors – Are doing data processing (e.g. recording, remuxing, …).
  • Sinks – Responsible for media playback and playback control.
All three types of stream handling modules have two sets of functionalities:
  • Required – Defined set of functions which a module must have (e.g. start, stop, …).
  • Capabilities – Functionalities which might be implemented depending on the nature of the module (e.g. trick-play, track selection, …).
Sources and processors should be (but do not have to be) platform agnostic. Sinks, on the other side, are by their nature bound to the platform. To make the best use of the platform, EOS has one special type of the sink – Cron player. This sink must implement “time-based APIs”. These APIs are designed to maximize playback performance by concentrating on the time related features of the stream.


Management of the streaming, stream metadata and playback control are in the core layer.


EOS can have one or more streaming sessions. Each session is called “chain”. A chain consists of one source, zero or more processors and one sink. The module responsible for chain creation, recycling and destruction is called chain manager.


The chain manager is probing available sources for a given URL. Afterwards, depending on the source output type and supported capabilities, any necessary processor elements are connected and, at the end, the sink is connected.


Each chain has an assigned playback controller as well as a data manager. The playback controller is handling playback related actions (e.g. play, stop, trick-play, …) while the data manager handles stream metadata (e.g. teletext, subtitles, …). The data manager is managing a set of core modules called engines. Engines are platform agnostic stream metadata parsers and aggregators. These are attached to the chain if such metadata is available in the stream.


The API layer consists of two parts:

  • Native API – Simple wrapper around the core layer which exposes EOS functionalities.
  • Java API – Set of Java classes exposing EOS functionalities to the Java application.
Java APIs are set upon the JNI interface which is using native EOS APIs.

Extension points

Primary functions of EOS are dictated by the Swisscom TV requirements. As these are not a finite set of requirements, it was very important to have an architecture which provides means to easily extend supported functionalities.
Obvious extension points are in the streaming layer. If a new streaming protocol should be supported, a new source should be created, or an existing one should be extended. The same reasoning applies for stream processing and processor modules.


In the core layer, two services are extendable: playback control and engines. Playback control can be customized to fit new requirements. For example, if a recording service needs to be included, playback control must be extended to support such a scenario. The default playback controller is prepared, and it can be used for general playback scenarios. New engines may be needed if additional metadata must be parsed. One example of such would be adding “Now/Next” support directly from MPEG TS EIT tables.

Source code

EOS source code is publicly available on https://github.com/swisscom/eos


Two external packages are shipped with EOS source code:

Because of the software license limitations, we could release only basic streaming modules: file source and PC/Linux based Cron player sink. This should provide you with enough information to implement whatever source/protocol you need and to port Cron player to your target platform. Source code is released under permissive BSD 3-Clause License.
We hope that you find EOS useful in your environment.

An article by:

Portrait Image

Lukas Hohl

Leader for Teams Development

More getIT articles

Ready  for  Swisscom 

Find the job or career to suit you. A career where you can make a difference and continue your personal development.


What you do is who we are.