1. Le Dynamique Adaptative Streaming
Gabriel Melki - INA-EXPERT

2. • Contexte et définitions
• Les protocoles utilisés
• Le pseudo streaming
• Le streaming adaptatif
• Vers le MPEG DASH

3. 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% ».

4. 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

5. Téléchargement de fichier ou
Téléchargement de flux
Ex: http://www.load.com
Ex: mms://serveur.load.asf

6. 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.

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

8. 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

9. Les contraintes de diffusion

10. • Contexte et définitions
• Les protocoles utilisés
• Le pseudo streaming
• Le streaming adaptatif
• Vers le MPEG DASH

11. 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

12. 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..

13. 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 Serveur spécifique Diffusion de fichiers longs
Pas de stockage local Diminution qualité vidéo (Risque de Diffusion Live
Adaptation à la BP du client perte de paquets) Réseaux managés
Adaptation dynamique de débit Nombre de connections unicast UDP Ex.: E-learning, webTV, VOD
Seeking Rebuffering et lags lors du switch MBR locative (DRM, CAS)
Live Prévoir les débits à l’encodage
Support Multicast (LAN) Blocage possible NAT et firewall (sauf
tunneling HTTP)

14. 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 Rend compte de la qualité de
(PAYLOAD) distribution
La numérotation des paquets L’identification des participants
L’horodatage 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

15. 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

16. 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

17. 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

18. 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

19. 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
HTTP
TCP UDP Transport
IP Réseaux

20. • Contexte et définitions
• Les protocoles utilisés
• Le pseudo streaming
• Le streaming adaptatif
• Vers le MPEG DASH

21. 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.

22. 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.

23. 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 Accessibilité pour les fichiers longs Diffusion de fichiers courts
Pas de perte de paquets Pas de Live (max. 6 à 10 minutes)
Qualité Pas de seeking en natif sur les paquets non Ex.: Clips, BA en FOD
« friendly » firewall 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ète
Pas de statistiques (modification player)

24. 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)

25. • Contexte et définitions
• Les protocoles utilisés
• Le pseudo streaming
• Le streaming adaptatif
• Vers le MPEG DASH

26. Principe du streaming adaptatif
• Bien qu’utilisable avec d’autres protocoles, c’est en général en
HTTP que nous retrouverons cette technologie. Ce qui permet
de passer la plupart des firewalls.
• Fichiers contigus pour le stockage (multi-fichiers ou MBR)
• Fragmentation en objets plus petits (chunks) pour la
distribution (en fonction du GOP par ex.)
• Une application cliente adaptive
• Signalisation par fichiers spécifiques
– Ex. *.ism et *.ismc chez Microsoft

27. 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 Peu d’encodeur compatible pour VoD et Live
Préservation de la BP réseau l’instant (Mai 2010)
Adaptation Bande Passante utilisateur Pas d’implémentation standard
Adaptation dynamique de débit Pas de statistiques (modification
Démarrage rapide player)
Aucun buffering et déconnection
Seeking
Bonne montée en charge
Parc de terminaux hétérogène

28. 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.

29. 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.

30. 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

31. 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

32. 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.

33. 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
34

35. Format de fichier MP4 fragmenté
Metadata describes file contents Index information provides random
access to individual fragments
Individual Media Fragments (of equal duration and starting and
ending on GOP boundaries)
35

36. Les composants du « Smooth Streaming »
• Expression encodeur 2 sp 1 version Pro
• Serveur IIS 7 + Smooth Streaming
• Client Silverlight (en HTTP uniquement)

37. 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
38

39. 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
40

41. Les technologies de l’ Adaptive Streaming
Microsoft Adobe Apple
Smooth Streaming Flash Dynamic Streaming HTTP Live Streaming
Streaming Protocol HTTP HTTP & RTMP HTTP
Silverlight, Xbox 360, other
Supported iOS, devices running
Smooth Streaming-compatible Flash Player 10, AIR
Platforms QuickTime X
players and iOS
MPEG 4 – Part 12
MPEG 4 – Part 12
Media Container (Fragmented MP4 - HTTP MPEG-2 TS
(Fragmented MP4)
Only), FLV
Currently supports VC-1
Supported Video H.264 Baseline, Main, and Currently Supports H.264
Advanced Profile & H.264
Codecs High; VP6 Baseline Level 3.0
Baseline, Main, and High
Supported Audio Currently Supports MP3,
Currently supports WMA & AAC AAC, MP3
Codecs HE-AAC, AAC-LC
Default Fragment
2 seconds n/a 10 seconds
Length
Contiguous single file for each Contiguous single file for each
File Type on Server Segmented Multi-file
bitrate or single multi bit-rate file bitrate
41

42. • Contexte et définitions
• Les protocoles utilisés
• Le pseudo streaming
• Le streaming adaptatif
• Vers le MPEG DASH

43. 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

44. Dynamic Adaptative Streaming over HTTP

46. Principe du DASH

47. Media Presentation Description
Content Segmentation for HTTP Adaptive Streaming

49. Merci de votre attention