Le Dynamique Adaptative Streaming Gabriel Melki - INA-EXPERT

• Contexte et définitions

• Les protocoles utilisés

• Le pseudo streaming

• Le streaming adaptatif

• Vers le MPEG DASH

Etat des lieux

Selon Laurent Blanchard (DG de Cisco France)

dans une interview accordée au magazine

Challenge(s): « les vidéos, qui représentent

aujourd’hui entre 30 et 40% des données véhiculées

sur le Net », vont être responsables d’une explosion

du trafic généré dans un futur très proche puisque

« d’ici à 2015, ce sera 90% ».

Les premières solutions proposées

• Evolution de l’internet et du Web..

• D’abord du texte (HTML via HTTP)..– Puis de l’incorporation d’images (mime)

– Puis des images animées (gif animés)

• la vraie vidéo apparait quelques années plus tard..• Naissance du streaming

Téléchargement de fichier ou Téléchargement de flux

Ex: mms://serveur.load.asf

Ex: http://www.load.com

Qu’est ce que le streaming: l’aspect juridique

• Il y a un grand débat quant à savoir si ces techniques doivent être appelées « streaming » ou téléchargement.

• En général les diffuseurs sont autorisés à diffuser des contenus (streaming), mais ils ne sont pas autorisés à rendre disponible le contenu en téléchargement.

• En streaming: seule, la partie demandée est transférée. En ce sens les diffusions adaptatives sont appelées streaming.

• Téléchargement: dés qu’un fichier multimédia est copié sur le client, c’est du téléchargement. Les techniques décrites pourraient être appelées « téléchargement adaptatif ».

• En streaming, il devrait être impossible à un utilisateur de stocker une copie du média. Mais c’est techniquement impossible et il reste toujours possible de stocker une copie.

• Il serait utile dans ce cas, en streaming de préciser combien il est difficile de stocker une copie.

Qu’est ce que le streaming: l’aspect juridique

• En streaming, les médias ne doivent jamais être stockés (en cache) sur le client.

• Pour certains algorithmes d’encodage des parties du fichier doivent être réutilisées et doivent donc être stockées pour un temps limité (ex: GOP long)

• D’un point de vue technique, « Streaming » correspond à une terminologie souvent en désaccord avec le point de vue juridique.

Le retour d’expérience

• Aujourd’hui la diffusion de vidéos est monnaie courante..

• Mais la fluidité n’est pas garantie (longs temps d’attentes, interruptions, blocage partiel ou total).

• Problèmes de compatibilité des navigateurs et des players

Les contraintes de diffusion

• Contexte et définitions

• Les protocoles utilisés

• Le pseudo streaming

• Le streaming adaptatif

• Vers le MPEG DASH

Les protocoles TCP/IP

• Pour communiquer sur internet, le protocole de base c’est IP, en général en association avec TCP (70% des échanges).

• L’objectif, c’est de transmettre les paquets de données à travers le réseau.

• L’avantage de TCP, c’est qu’il garantit que tous les paquets arrivent dans l’ordre et sans dommage, quitte à réinitialiser une transmission complète du fichier

Les problèmes de TCP

Mais cette puissante possibilité de correction d’erreurs de TCP a un côut:– TCP refuse la release d’un paquet défectueux ou bloquant et refuse

de traiter le paquet suivant tant que ce paquet n’est pas passé –même si tous les autres paquets sont sans problème et en attente dans les buffers.

– TCP attendra que le paquet manquant arrive.

– D’autre part, les procédures de transmission TCP sont très longues..

Le streaming dynamique

• Transfert de données audiovisuelles sous forme d’un flux régulier et continu sans téléchargement

Avantages Inconvénients Usages

Lecture Temps réel

Pas de stockage local

Adaptation à la BP du client

Adaptation dynamique de débit

Seeking

Live

Support Multicast (LAN)

Serveur spécifique

Diminution qualité vidéo (Risque de

perte de paquets)

Nombre de connections unicast UDP

Rebuffering et lags lors du switch MBR

Prévoir les débits à l’encodage

Blocage possible NAT et firewall (sauf

tunneling HTTP)

Diffusion de fichiers longs

Diffusion Live

Réseaux managés

Ex.: E-learning, webTV, VOD

locative (DRM, CAS)

Transport Temps réel

• Objectif: utiliser d’autres protocoles pour le transport des flux audiovisuels. Besoin de protocoles « légers »

• Les protocoles RTP/RTCP complètent l’offre « tout ou rien » du niveau 4. Ils fournissent des mécanismes TCP-Friendly absent dans UDP

Protocole RTP RTCP

Fournit L’identification de charge utile

(PAYLOAD)

La numérotation des paquets

L’horodatage

Rend compte de la qualité de

distribution

L’identification des participants

Contrôle la fréquence d’émission

des paquets RTP

Un contrôle min. des échanges

Ne fournit pas La réservation de ressources

Ne garantit pas la QoS

Streaming RTSP

• Real Time Streaming Protocol– RFC 2326

– Port réservé: TCP 554 (UDP possible)

– Live et VOD

• Rôles:– Signalisation: mise en place des ressources serveur, détection automatique de

la bande passante du client, versions de players, statistiques,… etc

– Interactivité: Fonctions de type VCR

• Transport des données audiovisuelles– UDP + RTP/RTCP

– TCP

– HTTP

Débits vidéo et Bande passante

• En streaming, la bande passante du client doit être supérieure au débit vidéo

• Régulation du débit en fonction des CR RTCP– Diminution / augmentation du volume d’informations à transmettre

Compensation de la gigue (coté client)

• Utilisation de buffer de gigue pour amortir les variations de délai

• Ajustement dynamique du délai de présentation par détection des pics de trafic

Streaming Dynamique RTMP (Adobe)

• Real Time Messaging Protocol– TCP 1935

– Mode Tunnel: RTMPT

– Mode sécurisé: RTMPE

– Couche Transport: TCP (donc pas de Multicast)

• Live et VOD pour applications Adobe Flash

• L’adaptation s’effectue dans les extrémités (serveur et client)– Détection initiale de la bande passante et du terminal (RTMP)

– Optimisation à postériori de la qualité vidéo pour chaque terminal• Détecter un changement de bande passante

• Détecter une modification de la résolution d’affichage

MMS (Microsoft)

• mms://serveur_video/ma_video.wmv

• Windows Media Server

• Recherche automatique de la couche transport idéale

• MSBD (Media Stream Broadcast Distribution) pour la liaison encodeur/serveur

MMS Applications streaming et transport

TCP UDP

IP Réseaux

Transport

HTTP

• Contexte et définitions

• Les protocoles utilisés

• Le pseudo streaming

• Le streaming adaptatif

• Vers le MPEG DASH

HTTP downloading

• Très répandu, HTTP permet de délivrer de la vidéo sur le WEB .

• Il est autorisé par la plupart des firewalls, même en cas d’accès à Internet via un proxy.

• Le moyen le plus simple pour délivrer de la vidéo sur HTTP est nommé: « http downloading » (téléchargement).

• Le fichier multimédia sera alors, traité et transmis vers internet via le protocole TCP.

• Une fois téléchargé, il peut être lu par un player en « stand alone » ou avec un plugin du navigateur HTTP.

• cette technique garantit une lecture à qualité optimale, mais les utilisateurs devront attendre que le fichier soit totalement téléchargé avant de le lire.

HTTP:Progressive Downloading

• La solution consiste à déplacer les informations nécessaires au démarrage de la lecture vers le début du fichier.

• Ainsi, le client pourra démarrer la lecture du fichier alors que celui-ci est toujours en téléchargement.

Le pseudo streaming

• On va intégrer au serveur un outil capable d’analyser la structure du fichier multimédia de manière à l’indexer dans le temps.• Les clients peuvent alors demander le téléchargement d’un intervalle de temps spécifique, sans avoir à télécharger tout le fichier.

HTTP Pseudo streaming

• Transfert par téléchargement du fichier AV– La lecture s’effectue progressivement pendant le téléchargement

– Transport classique HTTP/TCP

– Serveur web (Apache, IIS + Media Pack, Lighthttpd…)

Avantages Inconvénients Usages

Pas d’infrastructure spécifique

Pas de perte de paquets

Qualité

« friendly » firewall

Accessibilité pour les fichiers longs

Pas de Live

Pas de seeking en natif sur les paquets non

téléchargés (sauf mécanismes ad-hoc)

Pas de détection BP utilisateur

Pas d’adaptation dynamique de débit

Pas de multicast

Nombre de connections unicast TCP

Copie du media en local (temporaire)

Signalisation asymétrique

Téléchargement inutile si lecture incomplètePas de statistiques (modification player)

Diffusion de fichiers courts

(max. 6 à 10 minutes)

Ex.: Clips, BA en FOD

Seeking en pseudo streaming

• Lecture d’une partie non téléchargée d’un fichier FLV ou MP4– Nécessite HTTP 1.1

– Les métadonnées du fichier doivent contenir une liste de seekpoints.

– Le player recherche le point le plus proche de la demande utilisateur et construit sa requête:

• http://www.monsite.fr/mavideo.flv?start=219476905

• http://www.monsite.fr/mavideo.mp4?startime=30.4

– Un module coté serveur permet de renvoyer la vidéo à l’offset correspondant (Keyframe)

• Contexte et définitions

• Les protocoles utilisés

• Le pseudo streaming

• Le streaming adaptatif

• Vers le MPEG DASH

Principe du streaming adaptatif

• Bien qu’utilisable avec d’autres protocoles, c’est en général enHTTP que nous retrouverons cette technologie. Ce qui permetde passer la plupart des firewalls.

• Fichiers contigus pour le stockage (multi-fichiers ou MBR)

• Fragmentation en objets plus petits (chunks) pour ladistribution (en fonction du GOP par ex.)

• Une application cliente adaptive

• Signalisation par fichiers spécifiques– Ex. *.ism et *.ismc chez Microsoft

HTTP dynamique streaming

• Téléchargement Adaptatif– Fragmentation des fichiers en segments de 2 à 4 sec.

– Compatible avec les caches HTTP existants

– Encodages multi-fichiers, MBR ou scalable

– Player intelligent (surveillance de la bande passante, CPU, batterie)

Avantages Inconvénients Usages

Utilisation des caches HTTP existants

Préservation de la BP réseau

Adaptation Bande Passante utilisateur

Adaptation dynamique de débit

Démarrage rapide

Aucun buffering et déconnection

Seeking

Bonne montée en charge

Parc de terminaux hétérogène

Peu d’encodeur compatible pour

l’instant (Mai 2010)

Pas d’implémentation standard

Pas de statistiques (modification

player)

VoD et Live

L’adaptative streaming: coté serveur• Coté serveur, le streaming adaptatif, c’est:

– Fournir aux clients une table d’adresses (URL).

– Chaque adresse (URL) pointe vers un intervalle de temps précis (colonne), d’une qualité spécifique (lignes), d’un même contenu.

– Tous ces renseignements sont mis en œuvre dans le client.

– Le serveur peut être n’importe quel serveur HTTP compatible.

L’adaptative streaming: coté client• Après avoir téléchargé la table d’URL:

– Le client analyse son propre système et ses connexions pour sélectionner l’URL appropriée de la prochaine séquence.

– Auparavant, il doit démarrer la lecture du 1er intervalle de temps avec le niveau de qualité le plus bas, afin d’obtenir le meilleur temps d’accès.

– Durant ce 1er téléchargement, la bande passante disponible va être estimée (ex: 1er bloc de 325 ko téléchargé en 1.3 sec, la BP sera estimée à 2 Mb/sec).

– Le client passe alors à la qualité disponible la plus élevée pour son cas.

L’adaptative streaming: le switching

• Pour arriver à un switching fluide entre les différentes séquences, il y a certaines exigences.– Chaque séquence (chunk) doit être totalement autonome.

– Les algorithmes d’encodage utilisant la compression inter trames, réutilisent des morceaux d’images précédentes pour construire l’image actuelle, en transmettant seulement les différences. Le client aura donc besoin d’accéder à l’image de référence précédente. Ainsi, chaque séquence doit commencer par une image I (début d’un GOP) et se terminer par la dernière image d’un GOP.

– La longueur du GOP doit donc être équilibrée. Plus long est le GOP, plus la compression sera élevée et plus lent sera le switching

• C’est pareil pour l’audio- Encodage par échantillonnage (AAC= 2048 ech/bloc)- la coupure doit se produire sur un multiple entier de cette taille de bloc

L’adaptation

• L’adaptation définit seulement le format du fichier sur le réseau

• Par exemple, Microsoft, pour sa mise en œuvre utilise un seul fichier préparé pour la durée complète. Un module serveur définit la densité d’octets correcte pour chaque séquence (chunk) en fonction des demandes clients. Les protocoles utilisés s’assurent que tous les chunks soient individuellement décodable

Implémentations courantes

• 3 grands acteurs: Microsoft, Apple et Adobe.

• Microsoft Smooth Streaming + client Silverlight.

• Apple HTTP Adaptative Streaming (HAS).

• Adobe HTTP Dynamic Streaming (lect Flash vers 10.1)

• Autres acteurs:

• 3GPP en liaison avec l’OIPF, ils ont défini le DASH, (avec fichier XML).

• MPEG travaille sur la normalisation du Mpeg DASH avec la collaboration du 3GPP et de Microsoft.

Implémentation Microsoft

• Utilise un fichier XML (*.ism) afin de communiquer le tableau des URL au client et permettant d’identifier quels codecs, quels débits et quelles résolutions seront utilisés pour chaque fragment.

• Chaque chunk contient de l’audio et de la vidéo dans un conteneur MP4 fragmenté.

• Audio et vidéo sont ainsi demandés séparément et le client peut accéder par système commuté vers différentes qualités.

• Le player silverlight ne supporte que les formats H264 et VC-1 en vidéo, ainsi que AAC et WMA en audio

34

Microsoft Smooth Streaming Architecture

35

Format de fichier MP4 fragmenté

Metadata describes file contents

Individual Media Fragments (of equal duration and starting and

ending on GOP boundaries)

Index information provides random

access to individual fragments

Les composants du « Smooth Streaming »

• Expression encodeur 2 sp 1 version Pro

• Serveur IIS 7 + Smooth Streaming

• Client Silverlight (en HTTP uniquement)

Implémentation Apple

• La table des URL est fournie à partir d’un fichier texte appelé « playlist ».

• Le niveau supérieur de la playlist contient la liste des qualités disponibles avec pour chacune d’elles une sous-playlist.

• La sous-playlist énumère les URL de chaque chunk.

• Ces chunks contiennent à la fois audio et vidéo dans un format Mpeg-2 TS.

• La spec permet n’importe quel codec vidéo ou audio, mais actuellement uniquement H264, AAC et MP3.

38

Apple Live Streaming Basic Architecture

Implémentation Adobe

• Adobe utilise aussi un fichier XML afin de communiquer au client le tableau des URL (*.f4m).

• Il a sa variante MP4 (F4F)

• Les métadatas sont aussi fragmentées

• Le flash player (client) ne supporte que H264, VP6, AAC et MP3

40

Adobe Flash Dynamic Streaming Architecture

41

Les technologies de l’ Adaptive Streaming

Microsoft

Smooth Streaming

Adobe

Flash Dynamic Streaming

Apple

HTTP Live Streaming

Streaming Protocol HTTP HTTP & RTMP HTTP

Supported

Platforms

Silverlight, Xbox 360, other

Smooth Streaming-compatible

players and iOS

Flash Player 10, AIRiOS, devices running

QuickTime X

Media ContainerMPEG 4 – Part 12

(Fragmented MP4)

MPEG 4 – Part 12

(Fragmented MP4 - HTTP

Only), FLV

MPEG-2 TS

Supported Video

Codecs

Currently supports VC-1

Advanced Profile & H.264

Baseline, Main, and High

H.264 Baseline, Main, and

High; VP6

Currently Supports H.264

Baseline Level 3.0

Supported Audio

CodecsCurrently supports WMA & AAC AAC, MP3

Currently Supports MP3,

HE-AAC, AAC-LC

Default Fragment

Length2 seconds n/a 10 seconds

File Type on ServerContiguous single file for each

bitrate or single multi bit-rate file

Contiguous single file for each

bitrateSegmented Multi-file

• Contexte et définitions

• Les protocoles utilisés

• Le pseudo streaming

• Le streaming adaptatif

• Vers le MPEG DASH

Vers un streaming unifié

Outre les différences, dans les implémentations actuelles, il y a aussi des similitudes:– Tous les acteurs supportent H264 et AAC

– Le conteneur peut être MP4, F4V, Mpeg-2 TS

– On peut imaginer un format de stockage disque unique

– On peut aussi imaginer une évolution future vers le VBR

Dynamic Adaptative Streaming over HTTP

Principe du DASH

Media Presentation Description

Content Segmentation for HTTP Adaptive Streaming

Merci de votre attention