<   News

Tech Talk - Middleware Architecture

Following our announcement last month at IBC, we got a lot of inquiries about technical details on the software architecture of the TV set-top box middleware source code that will be available through this website in Q1 2014. So, by popular demand from technical managers, architects and developers interested in Frog by Wyplay, here is an overview of what is "under the hood". The "client" part of the Frog offering consists in a layered software stack that involves components developed by Wyplay (blue bits in the diagram below) and third-party components (in grey) either open source or proprietary.

Frog by Wyplay’s TV Middleware Architecture

Members of the Frog community will access the source code of Wyplay’s components through private repositories on github. For integration, platform configuration and build, we offer as part of Frog the "genbox", a Wyplay-developed software packaging and build environment based on Gentoo. We will provide more details on this environment in a future blog post. Let’s now look into the different layers in the architecture from bottom to top:

At the lowest level, Wyplay’s TV software stack relies on the Linux operating system kernel, tuned and optimised for the CPU architectures we support (SH4, MIPS and ARM). The drivers (and bits of the kernel) may come either from the chipset vendor (through their SDKs, e.g. Broadcom’s Nexus or ST’s SDK2) or the device vendor for which Wyplay’s solution is ported on. As part of Frog, Wyplay will supply reference hardware and reference implementations for those. We are able to deliver pre-built binaries that will be bundled with the "genbox". If you want to port the Frog middleware on new hardware, you will have to get in touch with the software team of the device vendor to get their drivers.

Wyplay’s TV middleware relies on a number of open source projects (e.g. glib, dbus, ffmpeg, etc. - see diagram above), some of which have been modified / tuned by Wyplay. The list is long, so we won’t go into details in this overview. The source code for those is pulled in by the genbox from mirrors hosted by Wyplay of each project’s public repositories. As a developer or integrator, it may be necessary during a TV software integration project to tune the code in those components, or you may even want to replace some (e.g. swapping ffmpeg with gstreamer for instance, even though you would then fork from our recommended architecture)

The heart of our TV software stack is the "middleware" layer. It is a modular collection of independent software components that implement the features necessary for TV services (e.g. DVB / Cable / IPTV / OTT zapper, EPG, PVR & Timeshift, and more - see more details on supported TV features on Wyplay’s WyTV pages). The choice of software components that will go into your end product is done with the genbox tool. All middleware components are written in C or C++ and communicate -between themselves and with the layers above- through the D-BUS Inter Process Communications framework (or direct call if they are in the same process). In addition, all middleware processes are executed with dedicated isolation for security. Some components have to be adapted to the specificities of each TV or STB system integration project, for example :

  • hardware-dependent components (denoted in the diagram above by grey cricles with a blue triangle: clock, power management, networking, Audio/Video I/O ...) have to be customised depending on hardware features (e.g. Set-Top-Box specific inputs-outputs)
  • the DVB stack and others (denoted in dark blue rectangles above) have to be customised depending on the feature requirements of your project (e.g. operator headend)

As part of a porting / customisation / integration project, you may also want to integrate 3rd party software libraries or create your own middleware components for feature extensions. One important example of such 3rd-party components as part of projects for Pay TV operators is Conditional Access System (CAS) and Digital Rights Management (DRM). Frog provides documented integration interfaces for those security components.

The topmost layer in our software architecture is for applications frameworks and user interface. The Frog reference implementation provides an application framework based on web technologies that relies -through a web server- on the D-BUS IPC interfaces exposed by the middleware layer. You could also add other application frameworks as part of your projects.

In the Frog reference implementation software architecture, an embedded web server (implemented in python using open source projects like Bottle and uWSGI) provides an HTTP stack that exposes all middleware functionality through RESTful APIs that provide a higher level of abstraction than the DBUS interface. These RESTful APIs are exposed to the user interface on the device and possibly to companion mobile devices. Additional modules can be added at this layer for e.g. swipe&pairing of companion devices or implementing "business logic" between the UI and the middleware.

Finally, the user interface screens are rendered by a local web browser (built on QtWebkit with squirrelfish JIT and optimised by Wyplay for performance). The user interface is implemented as a web application using HTML5 technologies (Javascript, CSS3, HTML) and leverages hardware acceleration capabilities of the chipset. The user interface serves as a basis for tests and customisation as part of a project.

< Previous
Next >