Università degli Studi di SalernoFacoltà di Ingegneria

Corso di Laurea in Ingegneria Informati ca

Media Delivery Platform

Daniele Cafaro 0622700020Gianfranco Cerrato 0622700029

Reti di Calcolatori: Protocolli e SistemiProf. Massimo De Santo

Tutor: Ing. Paolo Napoletano

HELIX PLATFORM

I PROTOCOLLI

Client

3rd PartyRTSP/RTP

Server

3rd PartyRTSP/RTP

Client

RDT (Real Data Transport)

RTP

RTSP

RTP

RTSP

OBBIETTIVO

Server

Player

Encoder

Studio ed analisi dell’architettura RealNetworks per il Live & On-demand Streaming

OUTLINE

Architettura• Helix Producer• Helix Server• Real Player• Funzionalità avanzate

Deployment• Configurazione generale• Casi d’uso

HELIX PRODUCERConsente di creare stream multimediali con formati adatti alla distribuzione sulla rete.

• Cattura dalla sorgente audio/video

• Editing e Pre-filtering

• Codifica e FEC

• Delivery

CODECIl file di output è codificato in un formato proprietario della RealNetworks: RealAudio e RealVideo.

C A R AT T E R I S T I C H E

Audio Type: Voice, music

Audio codec: RealAudio

Channel: Mono, stereo, stereo-surround, multi-channel

Video Codec: RealVideo

Codec Versions: 8, 9, 10

Multi-rate: SureStream

File Type: RealMedia (.ra, .rm, .rmvb, .rpm)

Real Video

Audio Track: RealAudioBandwidth: Qualsiasi

Type: CBR - VBR

Real Audio

Type:

Voice Codec

High-Response Codec

Mono Music Codec

Stereo Music Codec

Stereo-Surround Codec

5.1 Multichannel Audio Codec

Sample Rate: 8000 - 44100

Bandwidth: 5 – 320 Kbps

• Stesso file con più bit-rate• Afferisce ai formati CBR

incremento dimensioni del fie collo di bottiglia per live streaming

Adattamento dinamico alle condizioni della rete (es. congestione)

SURESTREAMTecnologia multi-rate usata da RealNetworks:

HELIX SERVER

• Fisici: per accedere al file system• Virtuali: per richiedere determinati servizi

La sintassi per l’utilizzo dei mount point è la seguente:protocol://address:port/mount_points/path/file

http://helixserver.example.com/ramgen/movie/video.rm

rtsp://helixserver.example.com/movie/video.rm

Il server permette di distribuire lo stream grazie ai mount point:

FisicoVirtualemetafile .ram

UnicastInvia uno stream separato per

ogni receiver o media player

MulticastInvia lo stesso stream a tutti i receiver o media player, con

eventuale canale di controllo unicast

UNICAST VS MULTICAST

Adattamento del flusso ad hoc per ogni client

Uso “inefficiente” della rete

Uso efficiente della rete

Richiede particolari configurazioni di rete

In reti molto ampie è possibile combinare queste due tecniche

Configurazione di default per Helix Server

Riservare un certo numero di indirizzi IP multicast:1 per ogni bit-rate

SPLITTINGLo splitting abilita un componente a distribuire lo stream

multimediale verso altri componenti.

Encoder-to-Server: per distribuire uno stream multimediale da un encoder verso un Helix Server.

Server-to-Server: per distribuire uno stream verso un altro Helix Server.

C O M P O N E N T I P R I N C I PA L I

Transmitter:è il dispositivo su cui ha origine lo stream multimediale. Invia il flusso verso un receiver o direttamente verso i media player. Possibili transmitters sono: Helix Producer, SLTA, Helix Server…

Receiver: è l’Helix Server che riceve uno stream da un transmitter e lo distribuisce verso i media player.

PULL VS PUSHPush

Esiste una connessione persistente tra transmitter e receiver

Il server è subito pronto a soddisfare i player

PullNon esiste alcuna connessione

persistente tra transmitter e receiver

In configurazioni avanzate queste due tecniche possono coesistere

Uso efficiente della rete

Uso “inefficiente” della rete Introduce una maggiore “latenza” per la prima richiesta

Molto semplice da realizzare

Richiede una esplicita configurazione del

transmitter e del receiver lato Server

SURESTREAM AWAREIl SureStream-Aware Splitting permette di distribuire

soltanto la specifica codifica dello stream richiesta dal client.Non sarà mai trasmessa al receiver una codifica

non richiesta esplicitamente.

E’ uno spreco di risorse utili!E’ una soluzione più efficiente!

REDUNDANCYEsistono configurazioni con ridondanza sugli encoder, sui server e sugli stream:

• Maggiore affidabilità del servizio• Maggiore qualità• Uso efficiente della rete (Content Caching e Media Proxy)

Due modalità di funzionamento:

1. Fault tolerant2. Load balancing

Media Proxy: Aumenta la qualità dello streaming avvicinando sempre di più i contenuti al player

Content Caching: Aumenta la qualità dello streaming avvicinando sempre di più i contenuti al player

REDUNDANCY

I Subscriber mantengono una cache dei contenuti inseriti sui PublisherIl Proxy funge da intermediario

tra i Player ed il Server

REDUNDANCYEncoder Redundancy: gli encoder trasmettono lo stesso

live stream e formano una coda in base all’arrivo delle connessioni

Identificativo dell’encoderStesso contenuto multimediale

REDUNDANCYConfigurazione Avanzata: combinazione di encoder redundancy, multiple servers e broadcast redundancy

Broadcast Redundancy: il receiver riceve un duplicato dello stream (flusso unicast e multicast)

LATENZALa latenza è un parametro importante da controllare

specialmente quando si utilizza lo splitting

• Latenza end-to-end (max 10 sec.)• Latenza di startup bassa

Helix Server permette di variare i parametri sulla latenza con il latency mode

LATENCY MODE RECEIVER BUFFERING

0 – normal latency 1 second

1 – reduced latency 0.05 second

2 – minimal latency none

Intervallo di tempo che intercorre da quando si verifical’evento live a quando viene riprodotto sul media player

Intervallo di tempo che intercorre da quando l’utente clicca sull’URL associato al file multimediale a quando il

media player avvia la riproduzione del contenuto

REALPLAYERIl lettore multimediale riceve in carico lo stream e lo

decodifica per riprodurne il contenuto

Il Media Playback Pane consente di visualizzare le clip

scaricate o in streamingIl Realted Info Pane fornisce

all’utente informazioni aggiuntive sulla presentazione

Il Media Browser Pane permette all’utente di

navigare sul WEB

PLAYLISTLa playlist comprende una sequenza di clips che il media player

riceve come singolo stream

La playlist è asscoiata ad un file XML:

<smil xmlns="http://www.w3.org/2001/SMIL20/Language">

<head><meta name="title" content="Coming Attractions"/><meta name="chapter-skip" content="1"/>

</head><body>

<seq id="chapter_1"><video id=“vid1" src=“video1.rm">

<param name="src-dur" value="31.3"/>

</video><video id=“vid2" src="/media/video2.rm">

<param name="src-dur" value="185.4"/>

</video>…………

La playlist può essere trasmessa in 3 possibili sessioni:

• Externally controlled

• Internally controlled

• Non controlled

In una sessione externally controlled l’utente player può muoversi tra le differenti parti che costituiscono la playlist usando delle direttive HTTP

(in genere cliccando su dei link). Il controllo della playlist quindi è

esterno al canale RTSP.Nota: A ciascuna sessione RTSP è

associato un ID utilizzato nelle direttive HTTP.

In una sessione internally controlled l’utente può spostarsi all’interno della

playlist mediante dei comandi RTSP impartiti all’Helix Server.

In questo caso, il controllo della playlist è interno allo stream del contenuto

multimediale e la playlist deve essere composta da stream che presentano

una durata definita

In una playlist con sessione non-controlled il media player tratta l’intera sessione come un unico live stream e non sono disponibili in alcun modo i

comandi per il controllo della risproduzione

SLTA

Il Simulated Live Transfer Agent (SLTA) consente lo streaming di contenuti multimediali preregistrati o di archivi broadcast come

eventi live. Usando SLTA, per esempio, è possibile simulare la programmazione radio o TV.

SLTA è un tool a linea di comandoSupporta tutte le modalità di broadcasting

SLTA ≈

ASML’Adaptive Stream Management (ASM) sono delle regole che descrivono lo streaming ed aiutano l’Helix Server a prendere

delle decisioni su come trasmettere i pacchetti sulla rete.

Insieme di regole costituite da una o più proprietà, ed opzionalmente da

una espressione:

#16000 <= $Bandwidth,AverageBandwidth=4000,

Priority=7; }ASM Rule

Il client riceve l’ASM Rule Book dal server e si sottoscrive ad una o più

ASM Rule in base alle proprie capacità di banda

Nota:Il tutto funge se si utilizzano file

multimediali multi-rate (es. SureStream)

Il server invierà al cliente soltanto i pacchetti associati alle

ASM Rule sottoscritte

RATE CONTROLE’ possibile adattare il tasso trasmissivo in funzione

dello stato del buffer del player

Si minimizza il rebuffering della clip, aumentando la qualità di fruizione dei contenuti

ASM o

Rate Control !?!?

E’ possibile usare il rate control lato server se: E’ disponibile la clip multirate Sono disponibili info sul buffer Il player invia riscontri periodici al server

23

1

RATE CONTROL

Slowdown Mode Exit indica il valore di uscita

dalla modalità di slowdown durante un

upshiftPreroll è la quantità di

dati che bisogna bufferizzare prima della

riproduzione

Il Server mantiene il modello del buffer del player e setta dei parametri di soglia. Se questi parametri

vengono violati, si adottano politiche di rientro

Una volta raggiunto Max Advance il server diminuisce la velocità

con cui vengono trasmessi i dati al client

Buffer Limit è il limite massimo della

dimensione fisica del buffer

Una volta raggiunto Upshift Depth il server passa ad un flusso dati con bit-rate maggiore

Target Time è un tempo espresso in millisecondi

che il media player preferisce avere a sua disposizione nel buffer

prima che la sua riproduzione termini

Downshift Depth è la soglia minima affinchè si passi ad un tasso di

codifica più basso; in questo modo si minimizza la

probabilità che il client effettui un rebuffering.

DEPLOYMENTPer testare le funzionalità dell’architettura RealNetworks

è stata creata una rete giocattolo ad hoc composta da: 1 Helix Server e 2 Client (Producer/Player)

CARATTERISTICHE:HP Proliant DL360Windows Server 2003 EE SP2Intel Xeon 3.60 GHz2.00 GB di RAM160 GB Ethernet 10/100 MbpsHelix Server Mobile v.13Wireshark v.1.4.2

CARATTERISTICHE:Dell Studio 15Windows Vista Ultimate 64 bitIntel Core 2 Duo P8600 2.40 GHz4.00 GB di RAM320 GB HD 5200 RPMEthernet 10/100 MbpsRealPlayer v.14.0.1Helix Producer Standard 13.1

CARATTERISTICHE:Dell XPS M1530Windows 7 Professional 32 bitIntel Core 2 Duo T9300 2.50 GHz4.00 GB di RAM320 GB HD 7200 RPMEthernet 10/100 MbpsRealPlayer v.14.0.1Helix Producer Standard 13.1

Helix mette a disposizione un

administration tool per la gestione

ed il monitoraggio del server di streaming

ADMINISTRATION TOOL

Admin PortIl tool è molto utile ma soffre di alcuni BUG!

CASI D’USOI test effettuati sulla piattaforma di streaming

hanno coperto i seguenti aspetti:

• Push e Pull Delivery• Live e on-demand: unicast o multicast broadcasting• Encoder Redundancy• Playlist• Streaming Multirate• Embedded player in una pagina web• Rate Control

PULL DELIVERY & UNICASTObbiettivo: Verificare il pull delivery da Helix Producer

di un live video con distribuzione unicast dello stream verso i diversi player

Pull Request

UDP

5

6

HTTP [GET]

SYN

SYN, ACK

ACK

HTTP [200 OK] (RAM file)

SYN, ACK

ACK

} 1

} 2

} 3

RTSP 4

RDT 7

SYN

HTTP: Richiesta del metafile2

UDP: Delivery dello stream pull.rm6 L’utente clicca sul seguente link:

http://192.168.111.58:81/ramgen/broadcast/split/192.168.111.128:3031/pull.rm

TCP: 3-way-handshake1

Sessione RTSP4

Pull request con autenticazione5

TCP: 3-way-handshake3

RDT: streaming e scambio informazioni di controllo7

PULL DELIVERY & UNICAST

WEB EMBEDDEDObbiettivo: Verificare l’incapsulamento dello streaming

multimediale all’interno di una pagina web

<html>

<head>

<title>Prova Embedded</title>

</head>

<body>

<EMBED SRC="rtsp://192.168.111.58:557/broadcast/live.rpm" CONSOLE=_master WIDTH=545 HEIGHT=438 NOJAVA=true CONTROLS="ImageWindow,All" >

</body>

<html>

Il tag HTML <EMBED></EMBED> permette di inserire lo stream all’interno della pagina

La proprietà CONTROLS consente di sceglierei controlli da visualizzare (es.: Play, Pause,…)

L’estensione del file multimediale deve essere .rpm altrimenti il browser non riconosce il plug-in da attivare

(La macchina client deve aver installato il plug-in RealPlayer)

SURESTREAMObbiettivo: Verificare la distribuzione di stream

ai diversi client con bit-rate differentiCon l’ausilio di Helix Producer è stato creato un file audio

SureStream a 3 bit-rate:

Caratteristiche PLAYER A:Normal Bandwidth: 28.8 KbpsMaximum Bandwidth: 56 Kbps

Caratteristiche PLAYER B:Normal Bandwidth: 10 Mbps or over

Maximum Bandwidth: 10 Mbps or over

1 Dettaglio ASM Rule Book

3 Il player B si sottoscrive alle regole associate al flusso a 96 Kbps

SURESTREAMI player dopo aver instaurato la connessione con il Server

contrattano il bit-rate da usare tenendo conto delle proprie capacità di banda:

1 Il Server invia il rule book ai client

2 Il player A si sottoscrive alle regole associate al flusso a 12 Kbps

SURESTREAMIl risultato ottenuto è:

A CONFRONTOFEATURESCache / Proxy Server

Encoder Redundancy

Broadcast Redundancy

Security Manager

Audio/Video Recovery

Adaptive Control Rate

Fast Start

Failover

Advertising (video, audio, HTML)

Media Library

DRM

= Full support or availability = Partial support or availability = Not support or availability

A CONFRONTOCLIENT - FORMATiPhone

Flash

iPad

Silverlight

Windows Media

Quick Time

3GPP

Android, BlackBerry, Symbian

mp3

mp4

RTSP/RTP Client

= Full support or availability = Partial support or availability = Not support or availability

SYSTEMWindows

MAC

Linux

Solaris

= Full support or availability = Partial support or availability = Not support or availability

A CONFRONTOPROTOCOLRTSP

RTP

MMS

RDT

PNA

IPv6

CONCLUSIONI

Vantaggi Svantaggi

Multipiattaforma

Integrazione

Flessibilità

Qualità

Natura Proprietaria

Complessità

Costo

GRAZIE PER L’ATTENZIONE!