More blogs in Arm Community blogs
Tags
Actions
Related blog posts
Related forum threads

Next evolution of the Set-Top Box: Move to the Cloud

Karthik Ranjan
4 minute read time.
The dawn of cable-TV systems started over 30 years ago, marked by the need for an electronic tuning device to receive TV channels available on frequencies not able to be tuned in by standard television sets.These “cable converter boxes,” as they were called back then, were large rectangular boxes which sat on top of, you guessed it, the TV Set. I still recall the old 3 foot high Zenith TV set, nicely recessed in a wooden enclosure with black box sitting on top on which we would receive cable TV in the early 1980s. These gradually evolved into analogue descrambling devices for Pay-TV systems which eventually became digital then grew, smaller and smaller and resulted in what we have today which are very small form factor “pucks” or HDMI “sticks” to decode TV.
As content moves to OTT this functionality has migrated into the Television itself with Smart TVs having Netflix, Roku, Apps and even being able to view Operator premium content through standards like Vidipath (formally known as DLNA CVP2), majority of which have been written for and have extensive support on the ARM® Architecture today.The majority of these STBs and TVs however have historically revolved around the need for reasonably complex software/client middleware to run on the device to allow the user to navigate the content to which they want to see.
For linear content we are all familiar with the Electronic Program Guide (EPG). This piece of software has seen many evolutions from native clients, JAVA, Android, and HTML variants just to name a few running inside the STB. This client software is still required but one major shift is happening in industry and that is this software is on the verge now of migrating completely out of the client and into the cloud. Through the advent of high-bandwith, low latency networks made possible by the roll out fiber and the latest DOCSIS standards, wireline operators are able to leverage these capabilities to offer cloud virtualization of key applications in the home, one of ripe, low-hanging fruit applications is virtualization of the Set-Top Box.

The driving principle behind virtualization of STB is that the majority of the compute (application execution & graphics rendering) moves into the cloud and client requires minimal compute with solid video decoding capability. All application execution is then converted to a standard video stream (e.g. H.264 or HEVC at the relevant resolution 1080p or UHD) and sent to the client where it is decoded.  Any “remote clicks” are received by the client and sent back to the server where they are processed within the application – the application itself is only delivered to a client as a running video stream. There are several benefits to this kind of architecture:
  • Greatly simplifies the STB, the components required for app streaming has the potential to drastically reduce CPE complexity and cost
  • The EPG can be changed at will, even having different versions for different customers.
  • Unlimited number of additional apps can be made available to customers. These apps can be anything from simple weather widgets to the most powerful interactive 3D games.
  • The server app environment is componentize and secure, allows for 3rd parties to also stream apps.
  • Ability to run apps from multiple different operating systems on the same client hardware
ARM has partnered with Netzyn who is leading Software provider for Virtual STB to demonstrate this on 2 different ARM based server hardware platforms:

1.  Applied Micro X-Gene

Based on ARMv8 Architecture, the AppliedMicro X-Gene® processor was designed with scale-out cloud applications in mind, balancing CPU performance; robust memory capacity and bandwidth; and high-speed I/O.  The X-Gene processor’s core design and power efficiency in a high density scale-out server platform is ideally suited for a variety of NFV applications and fits very well into NFV definition of Standard Server.

2. Samsung Exynos based Microserver

Based on ARMv7 Architecture, this product is based on a high volume mobile phone SoC used in popular phones like Samsung Galaxy Note 3 utilizing an octacore big.LITTLE configuration with 4x Cortex-A15 & 4x Cortex-A7. However what makes this solution unique is that it also contains a GPU, in particular the ARM Mali-T628 MP6 along with hardware video accelerators. These type of SoCs are especially well suited to vSTB applications because applications such as 2D/3D games can take full advantage of the GPU. The advantages of having this capability in the SoC enable better performance and density on applications such as 2D/3D Gaming which are made possible by vSTB.
The client leverages the Cubox-i2eX, based on a Freescale i.MX6, Dual-core Cortex-A9 controlled using an Roku IR remote control and gaming enabled through an X-Box 360 USB controller.  The applications shown using this vSTB architecture include XBMC, Angry Birds, CNBC, YouTube, Frogger, and TL Racing. 

Both demonstrations can be seen firsthand at the ARM booth (#48) at NFV World Congress in San Jose, May 6-8, 2015.
Anonymous
Parents

  • App streaming as used here does mean running the app on the server,  taking the frame buffer output, H.264 encoding it and sending the "app stream" to the client where it is decoded. User events (keys, touch, game controller) flow back from the client to the server.    As far as latency, in an key driven app (i.e. a STB remote control), the app seems local when latency is <125ms and for a 3D game app, latency should be <75ms.  In the Netzyn implementation, basically the only contributor to latency is the network and both of these latency requirements are easily met for this type of used case with servers in just one or two data centers.   Also the H.264 frames are only sent when there are changes, so average bandwidth for a STB Guide app is generally <100Kbs, but will have instantaneous peaks of a few Mbits.

    Steve

    Netzyn, Inc

Comment

  • App streaming as used here does mean running the app on the server,  taking the frame buffer output, H.264 encoding it and sending the "app stream" to the client where it is decoded. User events (keys, touch, game controller) flow back from the client to the server.    As far as latency, in an key driven app (i.e. a STB remote control), the app seems local when latency is <125ms and for a 3D game app, latency should be <75ms.  In the Netzyn implementation, basically the only contributor to latency is the network and both of these latency requirements are easily met for this type of used case with servers in just one or two data centers.   Also the H.264 frames are only sent when there are changes, so average bandwidth for a STB Guide app is generally <100Kbs, but will have instantaneous peaks of a few Mbits.

    Steve

    Netzyn, Inc

Children
No Data
Internet of Things (IoT) blog