DRAFT OCTV SPECIFICATION

Table of contents

1        Introduction. 1

2        Terms, acronyms and definitions. 2

3        Use cases. 2

3.1       Real-time streaming. 2

3.2       Creation and uploading of rich content 2

3.3       Push distribution of rich content 2

3.4       Pull distribution of rich content 3

4        Requirements. 3

4.1       General requirements. 3

4.2       Functional requirements. 3

4.3       Platform requirements. 3

5        Architecture3

5.1       Architecture for OCTV devices. 3

5.2       Device set up for Core OCTV.. 4

5.2.1        Source5

5.2.2        Sink. 5

5.2.3        Server 5

6        Component and service technologies. 5

6.1       Component technologies. 5

6.2       Service technologies. 5

7        Reference Software (Platform) 6

7.1       Functionality and technologies. 6

7.2       Server technologies. 6

7.3       Client technologies. 6

8        Process to add a new module to the platform.. 7

Annex A - Technology walkthroughs. 7

A.1      Technologies for real-time streaming. 7

A.2      Technologies for content creation and uploa7

A.3      Technologies for push distribution. 7

A.4      Technologies for pull distribution. 8

Annex B - Guidelines for the OCTV project execution. 8

B.1      Definitions. 8

B.2      Membership. 8

B.3      Master plan. 8

B.4      Initial steps. 8

B.5      IPR management 9

Annex C - The OCTV test be9

 

1        Introduction

"Connected TV" is seen by many as the means to provide the much sought-after convergence between traditional broadcast television  and various new forms of video delivery. The largely proprietary implementations of Connected TV are a major impediment to the development of a promising new market of content, products, services and applications. 

This Open Connected TV (OCTV) specification (the Specification) has been designed to provide the means to support interactive rich media streaming services in a plurality of application domains, such as to enrich one-way TV services with support to interoperable multichannel two-way content access and delivery, interactive video service on mobile networks etThus the Specification creates the conditions for the development of a global market for video services by providing a technical specification based on international standards and an industry-grade implementation of an Open Connected TV platform. 

This is the first specification issued by the OCTV Project, an initiative of the Digital Media Project, and is called "Core OCTV Specification" (C-OCTV Specification). It is divided in 6 parts:

1. Terms, acronyms and definitions
2. Use cases
3. Requirements
4. Architecture
5. Component and service technologies
6. Reference software

 This document includes two annexes. The first documents the walkthroughs that have been used to identify the component and service technologies and the second provides administrative background regarding the implementation and exploitation of the OCTV project.

 This Specification is publiHowever, the code corresponding to part 6 Reference software is only available to OCTV members who have developed the portion of the software assigned to them and whose software has been accepted for inclusion in the OCTV Reference Software.

 It should be noted that this document is not intended to be the specification and the software implementation of a complete product or a running service, but is a technology specification and an industry-grade implementation of software components that may be used by implementers in products and services according to the terms of the OCTV software licence.

 

2        Terms, acronyms and definitions

 

 

3        Use cases

3.1       Real-time streaming

Server provides a service to its subscribers whereby a subscriber can stream real-time video to any other subscriber.

In this use case John uses a Source device to send a real-time video to Jane's Sink via Server.

1.     John uses a widget on the Source's screen to
   1. Authenticate with Server
   2.     Activate camera
   3.      Request to stream AV sequence to Jane's Sink
2.     Server requests Jane's Sink to send environment description
3.     Jane's Sink sends environment description to Server
4.     Source streams unprotected real-time AV sequence to Server provided by Camera attached to Source
5.     Server
   1.      Adapts video according to Jane's Sink environment description
   2.     Encrypts adapted video
   3.      Sends to Jane
      1.                                         i.     Encrypted video
      2.                                         ii.     Encrypted keys
6.     Jane has a backgroud application on her Sink that
   1.      Decrypts keys
   2.     Decrypts video
   3.      Decodes video
   4.     Presents video

3.2       Creation and uploading of rich content

Server provides a service to its subscribers whereby a subscriber can upload content for distribution to a plurality of subscribers.

In this use case Mary creates and uploads a rich media video to Server.

1.     Mary uses a widget to
   1.      Activate a camera
   2.     Store AV sequence to her Source
   3. Sequence from her Source
   4.     Compose a scene of which AV sequence is an element on her Source
   5.      Create DI with metadata, template licence eton her Source
   6.      Authenticate with Server
   7. Upload DI to Server

3.3       Push distribution of rich content

Server provides a service to its subscribers whereby a subscriber can upload content for distribution to a plurality of subscribers. In this use case Mary sends a non-real-time video to a group of friends.

1.     Mary requests Server to distribute video to Mary's group of friends
2.     Server requests the Sinks of Mary's group of friends to send their environment descriptions
3.     Server
   1.      Adapts video independently for each member of Mary's group of friends
   2.     Sends the scene to Mary's group of friends via parallel unicast sessions
4.     Each member of Mary's group of friends has a backgroud application on their Sinks that
   1.      Decodes scene
   2.     Presents scene
5.    Each member of Mary's group of friends interacts with scene

3.4       Pull distribution of rich content

Server provides content on demand service to its subscribers.

In this use case Mario watches Mary's rich media video as content on demand.

1. Mario uses a widget to
   1. Authenticate with Server
   2. Search for content on Server
2. Server displays choices
3. Mario selects Mary's scene as content of interest
4. Server
   1. Checks that selection is compatible with rights declared by Mary
   2. Requests environment description of Mario's Sink
5. Mario's Sink sends environment description
6. Server
   1. Adapts video to make it suitable to a Mario's Sink's characteristics
   2. Streams scene
7. Mario
   1. Watches video
   2. Interacts with scene

4        Requirements

The Core OCTV specification shall satisfy the set of requirements given below.

4.1       General requirements

1. C-OCTV functionalities impacting interoperability of implementations shall be based on international standards unless the required standards
   1. Do not exist
   2. Are demonstrably inferior to other openly available solutions

4.2       Functional requirements

C-OCTV shall

1. Support the following types of Content
   1. Audio
   2. Video
   3. Images (natural pictures and static 2D graphics)
   4. Text
   5. Their combination ("scene description")
2. Specify at least one default format for each Content type
3. Support Content description
4. Support Client search for Content in a Server
5. Support real-time streaming of Content
6. Support delivery of Content with a Conditional Access System
7. Specify a default Conditional Access System
8. Support trick modes playing of Content
9. Support interactivity with Content
10. Specify a widget based UI framework
11. Be open to support application download to Clients
12. Support protocols for remote service requests

4.3       Platform requirements

The Platform shall

1. Be based on the MPEG-M architecture and APIs
2. Be written in
   1. Client: C or C++
   2. Server: Java
3. Be functional for
   1. Client: Android, Linux
   2. Server: Linux (Java-based)
4. Support major open source media frameworks
5. Support major open source rendering environments
6. Support User management
7. Support Content management
8. Support Content storage
9. Support Data Persistence and Processing System not bound to a specific DBMS
10. Support data representation according to possible client requests (e.g. HTML/CSS or LASeR)
11. Support Web Services management (REST API or SOAP Web Services)
12. Provide a general security layer for relevant server and client components

5        Architecture

5.1       Architecture for OCTV devices

Fig. 1 provides a general architecture of an OCTV Device based on MPEG-M part In this architecture Applications running on an OCTV Device call the Engines in the Middleware via an Application-Middleware API.

 

 

Fig. 1 - Generic OCTV Device architecture

 

The following possibilities exist for an App

1. It calls a PE which in its turn calls a TE
2. It calls a PE which in its turn calls a plurality of TEs
3. It calls a combination of PEs which call a single TE
4. It calls a PE
5. It calls a TE

 

In case the call is performed via the the Orchestrator Engine.

 

Fig. 2 shows the notion of Aggregation of Elementary Services and Orchestration of Technology Emgines.

 

 

Fig. 2 - Aggregation of Services and Orchestration of Technologies

 

Fig. 3 shows how an application running in an OCTV Device communicates with a remote OCTV Device via MPEG-M service protocols.

 

Fig. 3 - Communication between two OCTV Devices

 

When the OCTV Device at the right hand side (a "client") communicates with the Device at left hand side (a "server") the following happens:

1. A client Application calls a local Protocol Engine
2. The client Protocol Engine invokes a server Service (e.g. an Elementary Service such as Create Licence (or an Aggregated Service)
3. The corresponding server Application calls a specific Engine or, in the general case, the Orchestrator Engine
4. The Orchestrator Engine sets up a chain of Engines: in the Create Licence case the Protocol Engine processes the Create Licence Protocol and the Technology Engine (REL Engine) creates the requested licenc

5.2       Device set up for Core OCTV

The Specification provides the technologies necessary to support the use cases in chapter 3 satisfying the requirements in chapter 4 so as to enable interoperability of independent implementations of "Source", "Server" and "Sink" depicted in Fig. 3.

 

Fig. 4 - Building blocks of the Core OCTV architecture

 

Please note that

1. In the following "Content" means any audiovisual sequence or a scene, i.a composition of media
2. Two out of three of these devices (e.g. Source and Sink) may coalesce into a single device.

5.2.1       Source

The Source is a device (e.g. a computer equipped with appropriate peripherals, a camera with processing capability and WiFi) by means of which a user can

1. Capture and/or supply (e.g. via file or stream) an audio-visual sequence
2. Stream it to the Server for storage or for distribution to Sinks
3. Store it to a storage device (local or in the cloud)
4. Edit the audio-visual sequence
5. Upload the audio-visual sequence to the Server with
   1. Description
   2. Licences
6.  Compose a scene of which audio-visual sequences captured in real time or stored are elements
7.  Upload the scene to the Server

5.2.2       Sink

The Sink is a device (e.g. a computer equipped with appropriate peripherals) by means of which a user can

1. Search for content on the Server
2. Select content on the Server
3. Receive streamed content from the Server possibly protected with a Conditional access system
4. Interact with content on the Server via scene composition functionality and rich UI interface

5.2.3       Server

The Server is a device that

1. Lets a Source stream content for uploading or streaming to a Sink
2. Lets a Source upload a content
3. Lets a Sink receive content via streaming or download
4. Provides responses to content search by Sinks
5. Checks that a selection of a content for streaming is compatible with rights declared by Source
6. Adapts content to make it suitable to a Sink's characteristics
7. Streams content to a Sink possibly protected with a Conditional access system 

6        Component and service technologies

6.1       Component technologies

The following technologies are proposed to satisfy the given functionality

 

 

6.2       Service technologies

The relevant technologies from the MPEG-M part 4 standard are given below

 

 

 

7        Reference Software (Platform)

7.1       Functionality and technologies

The following functionality and technologies are used

 

 

7.2       Server technologies

Fig. 2 depicts the combination of the component technologies above to implement the Core OCTV Server

 

 

Fig. 5 - Architecture of Core OCTV Server

 

7.3       Client technologies

Fig. 6 provides a general architecture of a C-OCTV client.

 

 

Fig. 6 - Architecture of Core OCTV Client

 

8        Process to add a new module to the platform

OCTV adopts a test bed, whose initial configuration is described in Annex C, with the following features

1. The testbed is composed of a client and a server
2. Each of the client and server supports a significant subset of OCTV functionalities implemented as C++ Engines (client) and Java Engines (server)
3. The Engines are available in object cod

 

A proposal to test an OCTV module for acceptance may fall into one of three categories

1. It implements a functionality that is already present in the testbed
2. It implements a functionality that is not present in the testbed
3. It implements a functionality that is partly present in the testbed

 

In case the functionality is already present in the testbed

1. The existing module(s) is(are) replaced by the new one(s) and
2. The new set up is tested against the old one
3. If the test is successful the new module(s) replace(s) the old module(s) in the testbed

 

In case the functionality is not yet present in the testbed

1. The new module(s) is(are) added to the set up
2. New applications designed to test the new set up are developed
3. The new set up is tested
4. If the test is successful the new module(s) is(are) added to the testbed

 

In case the functionality that is partly present in the testbed a mix of the two preceding cases.

1. The existing module(s) is(are) replaced by the new one(s) and
2. The new module(s) is(are) added to the set up
3. New applications designed to test the new set up are developed
4. The new set up is tested
5. If the test is successful the new module(s) is(are) added to the testbed

 

In case the proposed engine(s) pass the above tests, they become part of the OCTV platform and the proponent becomes an OCTV member as defined in Annex B

 

Annex A - Technology walkthroughs

 

A.1Technologies for real-time streaming

The following protocols and technologies are needed to satisfy the given functionality

 

 

A.2Technologies for content creation and upload

The following protocols and technologies are needed to satisfy the given functionality

 

A.3Technologies for push distribution

The following protocols and technologies are needed to satisfy the given functionality

 

A.4Technologies for pull distribution

The following protocols and technologies are needed to satisfy the given functionality

 

 

 

 

Annex B - Guidelines for the OCTV project execution

The development and use of the OCTV Platform shall be based on the following guidelines

B.1    Definitions

OCTV manager	An officer with the task to Oversee execution of the master plan Verify the suitability of contributed modules Integrate all modules in the platform
OCTV master plan	A plan of OCTV work initially agreed by DMP members and invited technical experts and subsequently defined by OCTV members
OCTV member	A DMP member whose assigned portion of OCTV work has been delivered within the agreed time frame and accepted by the OCTV manager
OCTV platform	The Platform target of the OCTV project
OCTV scope	The MPEG Multimedia Service Platform Technologies standard, MPEG-M, and portions of other publicly available specifications as agreed by the OCTV members
OCTV software	The ensemble of software modules constituting the OCTV platform
OCTV specification	The technical specification based on which the OCTV platform is developed
OCTV work	Any activity carried out to plan, develop and manage the OCTV platform

B.2    Membership

• The OCTV membership begins the moment the assigned portion of OCTV work is accepted as part of OCTV software
• To become OCTV member again, a member who has discontinued DMP membership must develop a new assigned portion of OCTV work
• DMP members who are not OCTV member
  • Have visibility of the OCTV work, but not of the OCTV software
  • Can comment on (e.g. propose new activities in) the OCTV work

B.3    Master plan

• The OCTV mater plan shall include
  • Specification
  • Architecture
  • Programming language
  • List of software modules
  • Conformance testing plans
  • List of current OCTV members
• The selection of programming languages and OSs will be based on the following
  • One programming language to be selected for the initial phase of OCTV software
  • One OS for server and one/two OSs
  • Multiple language and OSs may be decided for the later phases
• The number of modules for the same function will be managed as follows
  • Get a full implementation of the modules required for the initial implementation
  • Improve existing implementations of modules
  • Allow different implementations of existing modules

B.4    Initial steps

• The initial OCTV architecture and its subdivision in modules shall be created by the DMP members and invited external experts with an advisory role
• The initial OCTV architecture and its subdivision in modules shall be made public
• The DMP members will agree on
  • Work plan including
    • Software modules
    • Module integration
  • Assignment of module development
  • Time line of software module development
  • Project management policy
  • OCTV manager
  • Environment
    • OS/platform
    • Software language
    • Project design tools
    • Repository

B.5    IPR management

• DMP members who wish to get a licence of the OCTV software shall become OCTV members
• OCTV members shall assign their software modules to DMP for free
• DMP shall license the OCTV software modules assigned to it exclusively to OCTV members who have accomplished their share of the OCTV software development
• DMP shall license the OCTV software for free according to a licence TBD, whose preliminary elements are
  • OCTV software modules may be used for commercial purposes
  • OCTV software modules may be modified
  • No further licensing of OCTV software modules other than for end user licensing
  • An OCTV member can transfer its rights to one and only one third party but will lose the right to use the OCTV software unless a new module is developed and the code is assigned to DMP
  • The task of obtaining Licences of patents relevant to the use of OCTV software modules, if any, shall be left to OCTV members who want to use the modules
• DMP licenses current OCTV members all past and current OCTV software releases
• OCTV members discontinuing their OCTV membership will retain the previously obtained licences but will not be eligible for licenses of subsequent OCTV releases
• Upon decision of the DMP General Assembly DMP may help OCTV members negotiate licensing terms for patents relevant to the use of OCTV software modules 

Annex C - The OCTV test bed

The OCTV test bed has the following features 

1. It has client-server configuration
2. The client is implemented in C++
3. The server is implemented in Java
4. The client supports the following subset of OCTV functionalities
   1. The player is a stand alone application
   2. The middleware is populated with the following engines
      1. Media Framework Technology Engine
      2. LASeR Parser Technology Engine
      3. Rendering Technology Engine
      4. Orchestrator
5. The server supports the follwing subset of OCTV functionalities
   1. LASeR creator TE
   2. Request Content PE
   3. Orchestrator
6. The engines are available as object code 

The overall architecture of the set up is given by Fig. 7

Fig. 7 - End-to-end architecture of the proposed OCTV testbed

 

The architecture of the player is depicted by Fig. 8

 

 

Fig. 8 - LASeR player architecture

 

The Media Framework and LASeR Parser Engines implement the architecture depicted in Fig. 9

Fig. 9 - Internal architecture of Media Framework and LASeR Parser Engine

 

 

 

 

.