Prototype planning report for set-top box and playout

Prototype planning report for
set-top box and playout
Deliverable D3.3
GLOBAL ITV ID: GLOBALITV-D3.3-PrototypePlanning
Version: 3
Deliverable number: D3.3
Authors: Michael Schäfer (TARA), Manuel Melic (TARA)
Contributors: Gustavo Calixto (USP), Gabriel Trevisan (UNICAMP),
Jackelyn Roxana Tume Ruiz (UNICAMP)
Internal reviewers: Christian Keimel (IRT)
Work Package: WP3
Task: T3.3
Nature: R – Report
Dissemination: PU – Public
Status: Living
Delivery date: 16.01.2015
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
Version and controls:
Version
Date
Reason for change
Editor
0
2014-10-28
Initial version
Manuel Melic (TARA)
1
2014-11-30
Ginga-NCL software aspects high Calixto (USP)
level specification
2
2014-12-20
Contribution of playout part
Gabriel Trevisan (UNICAMP),
Jackelyn Roxana Tume Ruiz
(UNICAMP)
3
2015-01-16
Final version
Michael Schäfer (TARA),
Manuel Melic (TARA)
Acknowledgement: The research leading to these results has received funding from the European Union's Seventh Framework Programme (FP7/2007-2013, call FP7-ICT-2013-10.2) under grant agreement
n° 614087 and from the Brazilian Conselho Nacional de Desenvolvimento Científico e Tecnológico
(CNPq) under grant CHAMADA MCTI/CNPq Nº 13/2012 and project number 490088/2013-9.
Disclaimer: This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of its content.
This document contains material, which is the copyright of certain GLOBAL ITV consortium parties, and
may not be reproduced or copied without permission. All GLOBAL ITV consortium parties have agreed to
full publication of this document. The commercial use of any information contained in this document may
require a license from the proprietor of that information.
Neither the GLOBAL ITV consortium as a whole, nor a certain party of the GLOBAL ITV consortium
warrant that the information contained in this document is capable of use, nor that use of the information
is free from risk, and does not accept any liability for loss or damage suffered by any person using this
information.
page i
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
Executive Summar y
This deliverable describes the GLOBAL ITV Set-Top Box prototype, based on the architectural concepts
as defined in D3.2 Initial high level architecture and first specifications [1]. Furthermore, the playout system used in the GLOBAL ITV project will be described within this document. The GLOBAL ITV Set-Top
Box prototype will implement the interoperable approach supporting Ginga and HbbTV as defined in the
high level architecture. The required hardware and software components will be described in detail. Furthermore the concept for the playout system will be outlined.
page ii
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
Table of Contents
1 Introduction....................................................................................................................................... 1
2 System Overview and High-Level Architecture ............................................................................ 2
3 Set-top box prototype ...................................................................................................................... 4
Hardware .................................................................................................................................... 4
High-Level Software Architecture ............................................................................................... 7
Detailed Software Architecture ................................................................................................... 7
Testing and Validation .............................................................................................................. 12
4 Playout system ............................................................................................................................... 14
Broadcast .................................................................................................................................. 14
Broadband ................................................................................................................................ 14
Unit tests ................................................................................................................................... 15
Field tests ................................................................................................................................. 15
Required Material ..................................................................................................................... 16
Glossary ............................................................................................................................................... 17
References ........................................................................................................................................... 19
List of Figures ...................................................................................................................................... 20
page iii
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
1 Introduction
In the first part of this document, a brief overview of the high level architecture for the GLOBAL ITV system
will be given. The architecture to be implemented in the prototype set-top-box (STB) will be defined.
The section giving the overview will be followed by the section providing a description of the hardware
which is used for the GLOBAL ITV prototype STB. This includes a description of input methods and connectors. In the following part, the software architecture is described in a high level way as well as in detail.
This will cover the software components to realize the basic TV functionality, and both the HbbTV and the
Ginga specific components. Furthermore, the required extensions for interoperability between both iTV
stacks will be highlighted.
The last section of this document outlines the playout system which is used in the GLOBAL ITV project.
page 1
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
2 System Over view and High-Level Architecture
The document “Initial high level architecture and first specifications” [1] describes the overall architecture
of the GLOBAL ITV system. The GLOBAL ITV STB prototype will be implemented according to that high
level architecture with additional iTV stacks as shown in Figure 1.
Figure 1: GLOBAL ITV high-level architecture with additional iTV stacks [1]
As described in Section 2.1 of [1], the iTV Player provides the capabilities to process legacy iTV systems.
Additionally, the architecture allows integrating native iTV stacks. To achieve this, four evolutionary steps
are defined in the specification of the high level architecture. The second evolutionary step focuses on
the interoperability aspects of native iTV systems. The architecture for this step is shown in Figure 2.
Figure 2: Architecture of the interoperable approach [1]
page 2
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
Due to time constrains in the GLOBAL ITV project, the architecture of the STB prototype will be based
on the interoperable step. This allows the project partners to evaluate their concepts and outcomes on
existing iTV systems which are already deployed in the market, i.e. Ginga-NCL and HbbTV 1.0.
page 3
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
3 Set-top box prototype
Hardware
The hardware of the GLOBAL ITV STB prototype is provided by Kathrein TechnoTrend, a German manufacturer of DVB and IPTV receivers. Based on their IPTV receiver IP8300 which comes without any
tuner, the STB was manually equipped by an ISDB-Tb tuner. This hand-crafted modification allows the
reception of digital television in Brazil.
3.1.1
Chipset Capabilities
The GLOBAL ITV STB prototype is based on the Broadcom BCM7584 System-on-a-Chip (SoC). This
powerful chip allows the GLOBAL ITV partners to develop and test a wide range of scenarios in the
context of interactive TV systems. Additionally, the chip comes with support for media playback via the
Internet, USB recording and 3D hardware acceleration. The powerful dual core CPU with 2000 DMIPS
supports the MIPS instruction set and comes with 512 MB of RAM and 128 MB of NAND flash.
Figure 3: Broadcom BCM7584 SoC and Memory
In Figure 3, the BCM7584 SoC is placed below the cooling element in the middle of the board. On the left
side of the chip, the memory is placed.
page 4
Version of
2015-01-16
3.1.2
D3.3 Prototype planning report for set-top box and playout
Tuner for ISDB-Tb
Since the IP8300 receiver is an IPTV device, there is no tuner preinstalled on the STB. To support reception of digital terrestrial television in Brazil, the STB was extended by an ISDB-Tb tuner. This hand-crafted
extension was applied to 8 devices to fulfil the requirements of the GLOBAL ITV project partners.
Figure 4: Tuner for ISDB-Tb Broadcast
Figure 4 shows the manually installed ISDB-Tb tuner on the right side of the board. The electronic components are placed on the downside of the small additional board. The tuner is connected to the main
board using thin copper wires.
3.1.3
Housing of the STB
The GLOBAL ITV STB prototype comes with a plain and elegant black case. All connectors, except of the
post installed tuner connectors, are placed on the backside of the STB. Due to the manually installed
tuner, the antenna connectors are placed on the right side of the prototype STB. This required a small
modification to the device housing.
Figure 5: Housing of the Prototype STB
In Figure 5, the housing of the prototype STB is shown. As visible on the right side of the STB, the case
was modified to expose the tuner connectors.
page 5
Version of
2015-01-16
3.1.4
D3.3 Prototype planning report for set-top box and playout
Connectors for external Devices
To support state of the art input and output methods, the STB prototype comes with various connectors
for external devices. The output of video and audio is available using HDMI and analogue connectors.
Additionally, for digital audio output, an optical SPDIF connector is available. Recording and playback of
broadcast content is supported by attaching storage devices to the USB port of the STB. Furthermore,
this USB port can also be used to play media files of different formats from hard disks or flash drives.
With respect to the concept of interactive TV systems, the STB comes with an Ethernet port to enable
access to the Internet. This allows downloading of application data and media files on demand. Furthermore, this link can be used as a back channel to the ITV system of the broadcaster. To receive broadcast
content, the manually installed tuner comes with two connectors for the terrestrial antenna signal.
Figure 6: Connectors on the back side of the STB
Figure 6 shows the back side of the STB prototype providing connectors for various output and input
devices. In this picture, the ISDB-Tb tuner connectors are placed on the left side of the STB.
3.1.5
Input Methods and Devices
The STB is equipped with four buttons on the front side of the case. These buttons are commonly used
for software updates. Additionally, an infrared remote control is available as the standard input device.
This device comes with a typical layout for TV sets and Set-Top Boxes including the colour buttons which
are widely used in ITV systems.
Figure 7: Remote Control of the STB
In Figure 7, the remote control of the STB prototype is shown. The colour keys and navigation keys, which
are important for iTV systems, are placed together in the middle part of the remote control.
page 6
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
High-Level Software Architecture
The software architecture of the STB prototype is based on three groups of functional components.
Figure 8: High level software architecture of the STB prototype
In Figure 8, the first group of components is shown in orange colour. This group is built by the operating
system, the drivers for platform specific hardware extensions, a high level API for accessing the hardware,
and the graphics system. As operating system, the STB prototype uses Linux with Busybox as extension
for common system tools. Since these tools are well known in the UNIX environment, this allows developing and debugging in a very convenient way. To access the platform specific hardware extensions like
the tuner, and video decoders, a Broadcom specific kernel module is used. On top of this kernel module,
the Broadcom reference software tree NEXUS is used to get a high level interface to the hardware capabilities. This includes for example the playback of video streams delivered via HTTP. For hardware accelerated graphics output, platform adapted versions of DirectFB and OpenGL are available.
The second group of components is shown in green and contains the Inaris DVB/IPTV Middleware which
is able to deal with DVB, as well as ISDB-Tb signals. Inaris provides all state of the art STB features like
PVR and EPG. One extension for Inaris is the Inaris HbbTV Solution which supports the reception of
DSM-CC Object Carousels. In context of the GLOBAL ITV system architecture as described in section 2,
some of these components will be considered as Common iTV Components. In this architecture, the
application lifecycle will be common for all iTV systems such as HbbTV and Ginga-NCL.
The third group of components, shown in blue colour, are the runtime environments of the iTV applications
as well as the native TV application. For Ginga-NCL applications, the Ginga-NCL Middleware is integrated
on the graphics system and specific parts of the TV Middleware. To run HbbTV applications, the Opera
web browser including the Inaris HbbTV extension is used. Since both iTV systems share the same resources like Media Player, only one iTV application is allowed to run at one time. Additionally to the iTV
application, the native TV application is present all the time. This application allows performing of channel
changes, display EPG data, and scheduling of recordings.
Detailed Software Architecture
3.3.1
TVolution and Inaris Overview
The reference TV application TVolution, provided by TARA Systems, is the native TV application on the
STB prototype. TVolution comes with the required features to scan and manage services, display EPG
information, and integrate hybrid platforms like HbbTV. Furthermore, TVolution connects the different
components of the Inaris Middleware together and provides the main processing loop. As a consequence,
TVolution also controls the startup and shutdown of the whole software stack.
The most comprehensive part of this software stack is the Inaris DVB/IPTV Middleware. This component
based middleware solution provides all DVB und IPTV relevant functionality. The hardware abstraction
layer (HAL) of Inaris allows interfacing with platform specific features using a unified interface. Further-
page 7
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
more, there are components that provide a window management system as well as an interprocess communication facility, which allows splitting TVolution into different processes. This helps to improve the
system stability and allows separating components to reduce complexity for integration work.
3.3.2
Multi-Process-Environment and Window Management
For the GLOBAL ITV STB prototype, TVolution is split into three processes as they are: TVolution main
process, HbbTV Browser process, and the Ginga-NCL Middleware process.
Figure 9: Process Modell and Window Management
In Figure 9, the processes including the composition of the graphical output is shown. For the communication between the process hosting the Ginga-NCL Middleware and the process hosting the main TV
application as well as the TV Middleware, an IPC communication channel is required. This is realized
using InarisIpc, which provides a message passing mechanism between processes.
Alongside the communication between the main process and the Ginga-NCL process, there is a need to
compose the graphics output of multiple processes. As shown in Figure 9, there are three processes with
graphics output: The TVolution main process with the native GUI, the HbbTV browser process with the
rendered content of the web browser, and the Ginga-NCL process with the rendered Ginga-NCL application. The final composition of the graphics output is realized using the InarisWindowManager. This window
management facility allows to access surfaces for rendering from different processes and composes them
according to the given layering. For the STB prototype, the output of the Ginga-NCL process is placed
behind the output of the HbbTV process. However, since there is no support to run applications on both
iTV systems at the same time, this means that both are in the same layer. On the top of the window layer,
the main TV application is placed.
3.3.3
IPC capable iTV Layer
For each Middleware component which is accessible from another process, there is an IPC server component running in the main process. Requests are sent from an IPC client component that runs in the
client process and implements the same functions as defines in the server process. This makes it fully
transparent whether an application accesses some functionality using a normal function call in the same
process or performing the call via IPC.
page 8
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
Figure 10: iTV Layer and IPC Communication
As shown in Figure 10, the Ginga-NCL process interfaces the main process for three different reasons:
 The Ginga-NCL application requires access to the Media Player as provided by the TV Middleware. This interface provides typical player functions to control the playback of the Media Player.
Furthermore it contains function to set the video window of the used Media Player which allows
embedding the video into iTV applications.
 The second reason for communication between the main process and the Ginga-NCL process is
the control of the application lifecycle. Since the AIT reception is completely handled in the main
process and no sections are passed to the Ginga-NCL Middleware, there is a need to control the
currently running application from the main process. This is done by offering events to start applications with a specific URL. Furthermore there is the possibility to terminate a running application. Finally, there is the demand to send key events to the Ginga-NCL middleware. Key events
are always feed to the native TV application TVolution. Depending on the current focus, the key
event may be sent to the Ginga-NCL application.
 The third part of the iTV Layer is responsible to allow the Ginga-NCL process to start other applications using a given URL.
The iTV Layer is realized as InarisItv software component.
3.3.4
ISDB-Tb extensions of the Inaris Middleware
The Inaris Middleware supports DVB transmissions via Satellite, Cable, Terrestrial, and IP channels. For
the GLOBAL ITV prototype, the driver for the ISDB-Tb tuner is added to the platform dependent software
stack. This is the basic step to receive broadcast transmissions based on the ISDB-Tb standard. Within
the transmitted transport streams, DVB and ISDB-Tb overlap in many parts on their signalling. Thus, only
a few extensions are required to support ISDB-Tb broadcasts. These extensions include updating of the
used frequency list for channel scans as well as supporting additional audio types.
3.3.5
GLOBAL ITV specific extensions of Inaris HbbTV
The prototype STB comes with the pre integrated Inaris HbbTV Solution which supports the basic profile
of HbbTV 1.0. The Inaris HbbTV Solution comes with the InarisApplicationManager component to process
and handle the application related service information as signalled in the transport stream. Furthermore,
the DSM-CC implementation InarisDsmccReceiver supports reception of object carousels. Both components are considered as common iTV components of Inaris as shown in Figure 8. The rendering of the
HbbTV application is realized by ab CE-HTML capable web browser. For the STB prototype, the Opera
web browser is used.
page 9
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
To realize a proper key handling, the web browser is integrated at a proper position in the focus path of
the main TV application. Received keys are first sent to any open menu or dialog of the main TV application. The second possible layer to handle a key is the web browser for HbbTV, and the third possible layer
is the root of the main TV application. If a key reaches the root, the default action will be performed such
as open the channel list when pressing the OK button. If the key is requested by the HbbTV application,
the key is sent to the browser and will not reach the root of the TV application.
At this layer, also the key handling for the Ginga-NCL application will be performed. The decision of which
key should be handled is made in a similar way as it is done for HbbTV: The application, either the HbbTV
application of the Ginga-NCL application, sets a mask which indicates which keys should be sent to the
iTV system. Setting the key mask and sending the keys to the HbbTV application is part of the integration
of the Inaris HbbTV Solution into the Inaris Middleware and TVolution main TV application. For GingaNCL applications, these features are realized by the iTV layer.
3.3.6
GLOBAL ITV specific extensions of Ginga-NCL Application Player
Ginga-NCL software stack has the objective to play available applications developed in NCL/Lua language. From a Brazilian Digital Terrestrial Television standard point of view, a Ginga full implementation
covers Ginga-NCL player, Ginga-J player and its application manager (features for application handling,
application signalling, application lifecycle and window managing). Despite the fact Inaris TV Middleware
provides similar and compatible features compared to Ginga Application Manager (GEM compatibility),
InarisTV middleware can provide the necessary functionality to Ginga-NCL software stack instead of
Ginga Application Manager. In summary, Inaris TV Middleware will provide for Ginga-NCL software stack
the necessary interfaces to launch and manage applications, such as interfaces for objects rendering,
user inputs controlling and HbbTV interoperability.
A detailed interface between Ginga-NCL software stack and common iTV components of Inaris is shown
in Figure 11. Presentation Machine loads Ginga-NCL applications, perform NCL parsing analysis and
address the necessary objects to be created by demonstrator. In additional, Presentation Machine performs Lua scripts as media objects as well as HbbTV applications (one of GLOBAL ITV demonstrator
achievements). LSI-TEC’s Ginga-NCL software stack contains an interface module called Platform Abstraction Layer (PAL). PAL is an intermediary group of functions which allows Ginga-NCL to be interfaced
with a widely range of devices, mainly STBs. The Ginga-NCL implementation process consists to adjust
the right Inaris TV middleware functions to be invoked by PAL and set up compilation environment for
GLOBAL ITV demonstrator target hardware.
Figure 11: Ginga-NCL Platform Abstraction Layer
PAL has a module organization as follows: dynamic player, input manager, media manager, screen manager and zapper manager. Dynamic player provides functions for controlling media playing, rendering
page 10
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
controlling and z-order media adjustments. Input manager offers I/O communication interfaces for devices
such as STB remote controller events. Media manager contains call to invoke media codecs. Screen
manager interfaces objects rendering, layers and window management. Zapper manager allows calling
functions to control TV channel zapping from a Ginga-NCL context.
The expected behaviour is Ginga-NCL Presentation Machine, PAL and Inaris TV Middleware software
stacks working to achieve the goal to play NCL/Lua applications. Figure 12 presents a sequence diagram
with an example of Ginga-NCL application call stack, from Ginga-NCL application player to Inaris TV
middleware. When a Ginga-NCL application is loaded, a method to parse the NCL file is called. Presentation Machine, by the way, invokes the necessary PAL functions to reflect application resources requirements. Next, PAL invokes Inaris TV Middleware to perform NCL/Lua application in the STB.
Figure 12: Ginga-NCL call stack example
3.3.7
Application Signalling
The signalling of HbbTV and Ginga-NCL applications is done within the Application Information Table
(AIT). However, signalling inside the AIT differs between the DVB standard used for HbbTV and the ISDBTb standard used for Ginga-NCL. To decide which interpretation of the data should be used, the application type has to be signalled properly inside of the PMT. Using the application type, it is possible to signal
an AIT sub table for HbbTV on one PID, and another AIT sub table for Ginga-NCL on another PID, both
referenced from the same service. This is required for the dual stack capable STB prototype as defined
in [1].
To process the signalling for two application types at the same time, the AIT parsing functionality in the
Inaris DVB/IPTV Middleware has to be extended to handle multiple sub tables. For handling of the descriptors contained in the Ginga-NCL based AIT sub table, the Application Manager component of the
Inaris HbbTV Solution is extended.
3.3.8
Application Lifecycle Management
To signal HbbTV and Ginga-NCL applications for one service at the same time results in a common list
of applications. This list is created and managed by the Application Manager component. Based on the
rules for common signalling as defined in [1], the Application Manager is able to select an application to
run on one of the two ITV systems.
page 11
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
Figure 13: Application lifecycle and interoperability
To enable interoperability between the ITV systems, the Application Manager provides an Interface to
schedule application start requests for applications running in the same or in the other iTV system. For
this, the applications identification as defined in [1] is implemented by the Application Manager. The possible interaction between the two iTV systems and the common Application Manager is shown in Figure
11.
3.3.9
Application delivery using DSM-CC
The HbbTV as well as the Ginga-NCL standard require delivering application content using DSM-CC
Object Carousels. In the STB prototype, the reception of that content is realized by the Inaris DSM-CC
Receiver as it is part of the Inaris HbbTV Solution. The Inaris DSM-CC Receiver comes with a carousel
caching functionality which allows downloading the whole application immediately after service change.
Thus, application start of DSM-CC applications can be done very quickly.
For the web browser running HbbTV applications, the content of the object carousel is made available
using a localhost HTTP server on the STB prototype. This allows exposing the object carousel also to
other processes on the same machine. However, to provide the Ginga-NCL Middleware access to the
object carousel, another mechanism will be implemented on the prototype STB: The carousel content will
be made available through a user space file system (FUSE) as available by the Linux kernel. This allows
the Ginga-NCL Middleware to access object carousels using standard file system operations as it is already implemented in the Ginga-NCL Middleware.
Testing and Validation
For testing and validation of the GLOBAL ITV STB prototype, different phases are used.
3.4.1
Unit Testing
To test the core functionality of the Inaris TV Middleware, a huge set of automated unit tests are used to
validate most of the middleware components. This also applies to the Application Manager and DSM-CC
Receiver which are commonly used in the GLOBAL ITV system. To test the extensions made for GingaNCL and ISDB-Tb the corresponding unit tests are extended.
3.4.2
Official HbbTV Test Suite
To validate the functionality of the Inaris HbbTV Solution and integration of HbbTV on the Inaris DVB/IPTV
Middleware, the official HbbTV Test Suite is used. This collection of tests is designed to act as a black
box test for the STB. Tests are executed in a specific test environment using a synthetic test stream. The
HbbTV Test Suite is executed half-automated where a review of test artefacts have to be done after the
test run has been completed.
3.4.3
Ginga-NCL Application Player Tests
LSI-TEC’s Ginga-NCL application player will be submitted to a black box test to validate all features according to functional requirements established for GLOBAL ITV demonstrator [2]. The black box test for
Ginga-NCL application player consists in a group of stub applications that tests isolated features. In additional, for integrated tests, it expected collaboration from WP4 outcomes. A first test step expects to
page 12
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
execute application stubs to validate Ginga-NCL player implementation using local file systems. In a second step, considering integrated tests, Ginga-NCL will be tested using MPEG2 transport streams (performed by playout) and applications available to be obtained by TCP/IP STB stack and via DSM-CC.
3.4.4
GLOBAL ITV Playout System
For test scenarios and demonstration purposes, the GLOBAL ITV Playout Systems as described in section 4 is used.
3.4.5
GLOBAL ITV Reference Applications
To test the interoperability between HbbTV and Ginga-NCL on the GLOBAL ITV STB prototype, the reference applications as created in working package 4 are used.
page 13
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
4 Playout system
The methodology applied in the playout of the project is based on DVB­T and ISDB­T standards.
Wherever possible, open source code will be used, running Linux (Debian distribution).
Broadcast
For transport stream generation, OpenCaster software is used. For that purpose, AV content is
multiplexed with Ginga or HbbTV apps creating the output TS. The validation of this procedure is
conducted by means of TS software analyser, e.g. DVB analyser, DVB inspector, DVB snoop, among
other, or even by over­the­air transmission by means of modulator cards. For Ginga, we are using a
commercial TV set.
During the process of TS generation, a set of parameters must be passed to the generator. This can
be done by scripts, identifying some important table values, such as application types, identification
and control codes, the program specific information, the application information table that allows all PID
of the system, application signalling descriptor, transport protocol descriptors, service information,
among others.
The Figure 14 shows general workflow for TS generation. The audio, video and application files are
sent to a TS generator software. This software will output a number of different TS files, which will be
later multiplexed and transmitted over­the­air.
Figure 14: TS Generation workflow
Broadband
In broadcast network, playout system is expected to be similar to the one depicted in Figure 15. Both
the TV and the 2nd screen devices should be connected to the same local area network and this local
network should have Internet access. The broadband content will be distributed to the TV and to the
2nd screen device, accordingly to an inter­device synchronization procedure that uses this local network
connection.
Figure 15: Broadband and broadcast communications
page 14
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
Unit tests
In the first step, unit tests in the RT­DSP Laboratory will be conducted. In sequel, integration of SW
and HW modules will also be tested in our lab. The project can be divided in the following units:





Generation of an audio and video TS: Test by use of a very wide range of video players
Inclusion of a Ginga application into the audio and video TS: Test by modulate and broadcast
of the TS using a modulation card to ISDB­T TV set
Inclusion of a HbbTV app into the audio and video TS: Test by emulators and TS analysers
Inclusion of both Ginga and HbbTV applications into the audio and video TS: Test by use of
GLOBAL ITV STB prototype
Second screen synchronization: Transmitting of an HbbTV application involving a second
screen and checking sync procedures.
Field tests
The proof­of­concept test procedures also includes field tests involving real system deployment for
hybrid DTV experiencing.
The suggested test scenarios are depicted in Figure 16 and Figure 17 depicts playout tests at lab level,
by use of lower lever power transmitter. For a real world DTV transmitter, the proposed scenario is
depicted in Figure 4, where the playout output is by ASI to broadcaster multiplexer.
Figure 16: Lab­level systemic Test
Figure 17: Broadcaster level tests
The area inside the dashed line represents the broadcaster premises.
page 15
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
Required Material
The required materials for the implementation of the playout system are, but not only:


PCIe modulator card to the DVB­T and ISDB­T standards;
ISDB­T and DVB­T receivers (set­top-boxes, USB pen receivers, or any other possibility)
page 16
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
Glossar y
CA
Consortium Agreement
CoA
Coordination Agreement
DoW
Description of Work, Annex-1 of Project Proposal
EC
European Commission
IPR
Intellectual Property Rights
NDA
Non-disclosure agreement
PO
Project Officer
QA
Quality Assurance
R&D
Research and Development
STB
Set-Top Box
URL
Uniform Resource Locator
WP
Work Package
Partner Acronyms
Acronym
Name
IRT
Institut fuer Rundfunktechnik GmbH, DE
A-CING
Aqua-Consult Ingenieros, S.L., ES
FHG
Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. , DE
TARA
TARA Systems GmbH
TDF
TDF, FR
RETEVISION
Retevisión – AbertisTelecom,ES
SYMELAR
Symelar Innovación SLU, ES
EBU
European Broadcasting Union, CH
BAND TV
Rede Bandeirantes de Televisão, BR
HXD
HXD Interactive Television, BR
LSI-TEC
Associação do Laboratório de Sistemas Integráveis Tecnológico, BR
UCB
Universidade Católica de Brasília, BR
UFABC
Universidade Federal do ABC, BR
UFPA
Universidade Federal do Pará, BR
UNESP
Universidade Estadual Paulista “Júlio de Mesquita Filho” , BR
UNICAMP
Universidade Estadual de Campinas, BR
page 17
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
USP
Universidade de São Paulo, BR
W3C
World Wide Web Consortium at GEIE ERCIM, FR
page 18
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
References
[1] C. Keimel, „D3.2 Initial high level architecture and first specifications,“ GLOBAL ITV, 2014.
[2] T. Cid, „D2.2 Functional and Interoperability requirements,“ GLOBAL ITV, 2014.
[3] ETSI, „TS 102 809 V1.1.1; Digital Video Broadcasting (DVB); Signalling and carriage of interactive
applications and services in Hybrid broadcast/broadband environments,“ 2010.
page 19
Version of
2015-01-16
D3.3 Prototype planning report for set-top box and playout
List of Figures
Figure 1: GLOBAL ITV high-level architecture with additional iTV stacks [1] ............................................ 2
Figure 2: Architecture of the interoperable approach [1] ........................................................................... 2
Figure 3: Broadcom BCM7584 SoC and Memory ..................................................................................... 4
Figure 4: Tuner for ISDB-Tb Broadcast ...................................................................................................... 5
Figure 5: Housing of the Prototype STB .................................................................................................... 5
Figure 6: Connectors on the back side of the STB .................................................................................... 6
Figure 7: Remote Control of the STB......................................................................................................... 6
Figure 8: High level software architecture of the STB prototype ............................................................... 7
Figure 9: Process Modell and Window Management ................................................................................ 8
Figure 10: ITV Layer and IPC Communication .......................................................................................... 9
Figure 11: Ginga-NCL Platform Abstraction Layer .................................................................................. 10
Figure 12: Ginga-NCL call stack example ............................................................................................... 11
Figure 13: Application lifecycle and interoperability ................................................................................. 12
Figure 14: TS Generation workflow ......................................................................................................... 14
Figure 15: Broadband and broadcast communications ........................................................................... 14
Figure 16: Lab­level systemic Test .......................................................................................................... 15
Figure 17: Broadcaster level tests ........................................................................................................... 15
page 20