Università degli Studi di Salerno Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica...
-
Upload
carlita-poletti -
Category
Documents
-
view
217 -
download
0
Transcript of Università degli Studi di Salerno Facoltà di Ingegneria Corso di Laurea in Ingegneria Informatica...
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!