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:
EOS is split in four layers (Figure 1):
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:
Handling of the stream data is in the stream layer.
EOS recognizes three types of stream handling modules:
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:
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.
EOS source code is publicly available on https://github.com/swisscom/eos
Two external packages are shipped with EOS source code:
Leader for Teams Development
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.