The Digital Media Project

terrificbeepedΚινητά – Ασύρματες Τεχνολογίες

10 Δεκ 2013 (πριν από 3 χρόνια και 10 μήνες)

138 εμφανίσεις

The Digital Media Project


Date

201
1
/0
7
/
1
6

No.

1
3
1
7
/
OCTV

Source

G
A3
1

Title


Draft
Core OCTV specification




Draft
Core OCTV specification


Contents

1

Introduction

................................
................................
................................
................................
..

2

2

Terms, acronyms and definitions

................................
................................
................................
.

2

3

Use cases

................................
................................
................................
................................
......

3

3.1

Real
-
time streaming

................................
................................
................................
...............

3

3.2

Creation and uploading of rich content

................................
................................
.................

4

3.3

Push distribution of rich content

................................
................................
............................

4

3.4

Pull distribution of rich content

................................
................................
.............................

4

4

Requirements

................................
................................
................................
................................

5

4.1

General requirements

................................
................................
................................
.............

5

4.2

Functional requirements

................................
................................
................................
........

5

4.3

Platform

requirements

................................
................................
................................
...........

5

5

Architecture

................................
................................
................................
................................
..

6

5.1

Architecture for OCTV
devices

................................
................................
.............................

6

5.2

Device set up for Core OCTV

................................
................................
...............................

8

5.2.1

Source

................................
................................
................................
.............................

8

5.2.2

Sink

................................
................................
................................
................................
.

9

5.2.3

Server

................................
................................
................................
.............................

9

6

Component and service technologies

................................
................................
...........................

9

6.1

Component technologies

................................
................................
................................
.......

9

6.2

Service technologies

................................
................................
................................
............

10

7

Refere
nce Software (Platform)

................................
................................
................................
...

10

7.1

F
unctionality and technologies

................................
................................
............................

10

7.2

Server

technologies

................................
................................
................................
..............

10

7.3

Client

technologies

................................
................................
................................
..............

11

8

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

12

Annex

A


Technology walkthro
ughs

................................
................................
...............................

14

A.1

Technologies for real
-
time streaming

................................
................................
..................

14

A.2

Technologies for content creation and upload

................................
................................
.....

14

A.3

Technologies for push distribution

................................
................................
......................

14

A.4

Technologies for pull distribution

................................
................................
.......................

15

Annex

B


Guidelines for the OCTV project execution

................................
................................
....

16

B.1

Definitions

................................
................................
................................
...........................

16

B.2

Membership

................................
................................
................................
.........................

16

B.3

Master plan

................................
................................
................................
..........................

16

B.4

Initial steps

................................
................................
................................
...........................

17

B.5

IPR management
................................
................................
................................
..................

17

Annex

C


The OCTV test bed

................................
................................
................................
..........

18


1

Introduction

“C
onnected 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 deliver
y. 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 design
ed 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 serv
ice on

mobile networks etc. Thus the S
pecification

create
s

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
Conn
ected TV platform
.


This is the first specification issued by the OCTV Project, an initiative of the Digital Media Project,
and
is called “Core OCTV S
pecification”

(C
-
OCTV S
pecification)
. It is divided in
6

parts:

1.

Terms, acronyms and definitions

2.

Use cases


3.

R
equirements

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
identif
y

the component and service technologies and the second provides admin
istrative background
regarding the implementation and exploitation of the OCTV project.


Th
is

S
pecification is public. However, the code
corresponding

to
part
6

Reference software is only
available to OCTV members who have developed the portion of the sof
tware assigned to them and
whose software has been accepted for inclusion in the OCTV Reference Software.


It should be noted that th
is
document

is not
intended to be the specification and the software
implementation of
a complete product or a running serv
ice, 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



Term

Defini
tion

Conditional
access s
ystem

A system that enables a Service Provider to discriminate who can access its
Service based on its own criteria

Client

The
device used to provide or consume content from
a
S
erver by way of a
network

Content

A content ty
pe t
hat can be handled by the S
pecification

Content
description

Technology allowing the description of content from different viewpoints (a.k.a.
Metadata)

Content type

1.

Audio

2.

Video

3.

Images (natural pictures and static 2D graphics)

4.

Text

5.

Their combination ( “sce
ne description”)

Core Open
Connected TV

A restriction of Open Connected TV for the purpose of phase 1 of the
Specification

Media framework

An organised collection of software to handle digital media, such as demuxers
and decoders

Open Connected
TV

Stand
ard t
echnologies to enrich one
-
way TV services with support to
interoperable multichannel two
-
way content access and delivery

Platform

The Client and Server Reference Software implementing th
e

Specification

Server

A

device

provid
ing

Services to
Clients

Service

The organised provisioning of Content to Client
s

Sink

A device acting as a Client to consume content from a Server

Source

A device acting as a Client to provide content to a Server

Specification

This specification

Trick mode

A set of functional
ity that allows users to play Content from a Server as if it
were from a
VCR
, e.g.

pause, fast forward, fast rewind, slow forward, slow
rewind, jump to previous/future frame etc.

User
management

A server component to

define

and manage who and

how
can use
a Service

Content
management

A server component
support
ing

the collection, managing, and publishing of
Content


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 subscr
iber.

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

a.

Authenticate with Server

b.

Activate camera

c.

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

a.

Adapts video

according to Jane’s Sink environment description

b.

E
ncrypts adapted video

c.

Sends to Jane

i.

Encrypted video

ii.

Encrypted keys

6.

Jane has a backgroud application on her Sink that

a.

Decrypts keys

b.

Decrypts video

c.

Decodes video

d.

Presents video

3.2

Creation and uploading of rich content

Server provides a service to its subscribe
rs 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

a.

Activate a camera

b.

Store AV sequence to her Source

c.

Edit AV sequence

from

her Source

d.

Compose a scene of which AV sequence is an element

on her Source

e.

Create DI with metadata, template licence etc.

on her Source

f.

Authenticate with Server

g.

Upload DI to Server

3.3

Push distribution of rich content

Server provides a service to its subscr
ibers 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 S
inks of Mary’s group of friends to send their environment descriptions

3.

Server

a.

Adapts video independently for each member

of Mary’s group of friends

b.

Sends the scene to Mary’s group of friends

via parallel unicast sessions

4.

Each member

of Mary’s group of frie
nds has a backgroud application on their Sinks that

a.

Decodes scene

b.

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
M
ario watches
Mary’s rich media video as
content on demand
.

1.

Mario uses a widget to

a.

Authenticate with Server

b.

Search for content on Server

2.

Server displays choices

3.

Mario selects Mary’s scene as content of interest

4.

Server

a.

Checks that selection is compatible wi
th rights declared by Mary

b.

Requests environment description of Mario’s Sink

5.

Mario’s Sink sends environment description

6.

Server

a.

Adapts video to make it suitable to a Mario’s Sink’s characteristics

b.

Streams scene

7.

Mario

a.

Watches video

b.

Interacts with scene


4

Requi
rements

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

a.

Do not

exist

b.

Are demonstrably inferior to other openly available solutions

4.2

Functional requirements

C
-
OCTV shall

1.

Support the following types of Content

a.

Audio

b.

Video

c.

Images (natural pictures and static 2D graphics)

d.

Text

e.

Their combination ( “scene description”)

2.

Spec
ify 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 Conditiona
l 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
Platfor
m shall

1.

Be based on the MPEG
-
M architecture and APIs

2.

Be written in

a.

Client: C or C++

b.

Server: Java

3.

Be functional for

a.

Client: Android, Linux

b.

Server: Linux (Java
-
based)

4.

Support major open source media frameworks

5.

Support major open source rendering environmen
ts

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 1. I
n 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 cal
ls 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 2. 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 communicate
s
with
a r
emote OCTV
Device via MPEG
-
M service protoco
ls.



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 clien
t Protocol Engine
invok
es

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 th
e

Create Licence
case the Protocol
Engine processes the Create Licence Protocol and the Technology Engine (REL Engine) creates
the requested licence.

5.2

Device set up for Core OCTV

The S
pecification provide
s

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 archi
tecture


Please note that

1.

In the following

Content


means any audiovisual sequence or a scene, i.e. 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 c
omputer 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
Si
nks

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

a.

Description

b.

Licences

6.

Compose a scene of which audio
-
visual sequences captured in real time or stored are elements

7.

Up
load 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 possibl
y pro
tected with a Conditional access s
ystem

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 ch
aracteristics

7.

Streams content to a Sink possibl
y protected with a Conditional access s
ystem


6

Component
and service
technologies

6.1

Component technologies

The following technologies are proposed to satisfy the given functionality


Functionality

Technology

Vid
eo coding

AVC profile?

Audio coding

AAC

profile?

Still pictures

JPEG baseline

2D graphic image

PNG

Text

Unicode

Font

OFF

Composition

LASeR Mini profile

Metadata

MPEG
-
7 Simple Profile/TVA (which subset?)

Digital item

DID

Content identification

DI
I

File format

ISO Base Media FF (which
subset

of it?)


MP4 FF


DI FF?

Licence

REL DAC profile

Conditional access system

MSAF

Streaming

MPEG
-
2 TS, RTSP

Presentation

Qt

Widget

MPEG
-
U part 1


6.2

Service technologies

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


Elementary Service

Purpose

Adapt Content


Authenticate User


Create Content


Create Licence


Deliver Content


Describe Content


Identify Content


Identify User


Package Content


Process Content


Search Co
ntent


Store Content


Verify Licence




7

Reference Software (
Platform
)

7.1

F
unctionality and technologies

The following functionality and technologies are
used


Device

Functionality

Technology

Server

Environment

JEE + Spring


User management

Spring securit
y


Content management
and
storage

Code to be developed ad hoc


Data Persistence and Processing System

Hibernate and DBMS (e.g. Postgres)


D
ata representation
(Sink

requests
)

XML/HTML/CSS/LASeR


Web Services management

REST API


G
eneral security layer

Spring security




Source/Sink

Environment

Linux/C++


Streaming

GStreamer


Media Framework

GStreamer


Rendering

Qt


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 Anne
x

C,
with the following
features

1.

The testbed is composed of a client and a server

2.

E
ach of the client and server supports a significant subset of OCTV functionalities

implemented
as C++
Engines

(client) and Java Engines (server)

3.

The Eng
ines are available in object code.


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 testbe
d

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 su
ccessful 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 mo
dule(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 B1
.


Annex

A



Technology walkthroughs


A.1

Technologies for real
-
time streaming

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


De
vice

Functionality

Protocol

Technology

Source

Authenticate with Server

Identify U
ser




Authenticate U
ser



Encode camera output


Media framework


Deliver to End User

Deliver Content


Server

Deliver to End user

Package C
ontent



Adapt Content

Ada
pt Content

Media framework


Encrypt content

Process C
ontent

IPMP components


Encrypt keys

Process Content

IPMP components


Stream content

Deliver Content

RTSP


Deliver to End User

Deliver Content


Sink

Stream receiver

Deliver Content

RTSP


Decrypt

keys

Process Content

IPMP components


Decrypt content

Process Content

IPMP components


Decode content

Process Content

Media framework


A.2

Technologies for content creation and upload

The following protocols and technologies are needed to satisfy the gi
ven functionality


Device

Functionality

Protocol

Technology

Source

Encode camera output


Media framework


Edit AV sequence


Media framework


Compose a scene


LASeR Mini Profile


Create DI

Create Content

DIDL



Describe Content

MPEG
-
7 SMP/TVA



Create

Licence

REL



Identify Content



Authenticate with Server

Identify User




Authenticate User



Upload DI

Store Content


A.3

Technologies for push distribution

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


Device

Functionality

Protocol

Technology

Source

Request to distribute video

Deliver Content


Server

Adapts video for each destination

Adapt Content

Media framework



Deliver Content

RTSP

Sink

Stream receiver

Deliver Content

RTSP


Decode content

Process Conte
nt

Media framework

A.4

Technologies for pull distribution

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


Device

Functionality

Protocol

Technology

Sink

Authenticate with Server

Identify User




Authenticate User



Se
arch for content

Search Content


Server

D
isplays choices



Sink

S
elect
s

content of interest




Checks compatibility with rights

Verify Licence

REL

Server

Deliver to End user

Package C
ontent



Adapt Content

Adapt Content

Media framework


Stream co
ntent

Deliver Content

RTSP

Sink

Stream receiver

Deliver Content

RTSP


Decode content

Process Content

Media framework




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

1.

Oversee execution of the master plan

2.

Verify the suitability of contributed modules

3.

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
spec
ification

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 acc
epted as
part of OCTV software



T
o 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

o

Have visibility of the OCTV work, but not of the OCTV software

o

Ca
n comment on (e.g. propose new
activities in
) the OCTV work

B.3

Master plan



The OCTV
mater
plan shall include

o

Specification

o

Architecture

o

Programming language

o

List of software modules

o

Conformance testing plans

o

List of current OCTV members



The selection of progr
amming languages
and OSs
will be
based on
the following

o

One programming language to be selected for the initial phase of OCTV software

o

One OS for server and one/two OSs

o

Multiple language
and OSs
may be decided for the later phases



The number of modules fo
r the same function will be managed as follows

o

Get a full implementation of the modules required for the initial implementation

o

Improve existing implementations of modules

o

Allow different implementations of existing modules

B.4

Initial steps



The initial OCTV a
rchitecture 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

o

Work plan inc
luding



Software modules



Module integration

o

Assignment of module development

o

Time line of software module development

o

Project management policy

o

OCTV
manager

o

Environment



OS/platform



Software language



Project design tools



Repository

B.5

IPR management



DMP

member
s 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 s
hare of the OCTV software development



DMP shall license the OCTV software for free according to a licence TBD, whose preliminary
elements are

o

OCTV software modules may be used for commercial purposes

o

OCTV software modules may be modified

o

No f
urther licens
ing of OCTV software modules other than
for
end user licensing

o

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

o

The tas
k 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 thei
r 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 o
f 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 foll
o
wing subset of OCTV functionalit
ies

a.

The player is a stand alone application

b.

The middleware is populated with the following engines

i.

Media Framework Technology Engine

ii.

LASeR Parser

Technology Engine

iii.

Rendering Technology Engine

iv.

Orchestrator

5.

The server supports the follwing subset of OCTV fun
ctionalities

a.

LASeR creator TE

b.

Request Content PE

c.

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 play
er 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