3.2.4.2 Le flux de données

Les données arrivent au client en paquets, chaque paquet contenant un certain nombre de trames (en anglais: frames) à décompresser et visualiser. Dans certains cas, pour décompresser une trame on a besoin de plusieurs paquets voisins (ceci est une caractéristique des formats de compression MPEG, avec des trames P, I, B15). Pour cela, et pour compenser des fluctuations dans le débit du réseau, un lecteur utilise une mémoire tampon (en anglais : buffer) pour recevoir en avance les données. La taille de ce buffer est mesurée en temps de visualisation des ces données (généralement, la taille du buffer est de moins de 5 secondes de contenu).

Le lecteur commence à jouer l'objet uniquement lorsque le buffer est rempli. Si le serveur fonctionne en mode push, le client va attendre un certain temps avant que l'objet ne soit joué. Le même phénomène se reproduit pour chaque opération Seek (le buffer est vidé et re-rempli). Pour qu'un client soit satisfait de son service VoD, le temps de réponse a ses commandes (play, seek) doit être le plus petit possible ([nwosu96]). En conséquence, pour garantir une bonne satisfaction du client, le serveur doit augmenter le trafic lorsque ces événements surviennent. Idéalement, le débit des données reçues côté client pour un flux multimédia encodé à débit constant va avoir un profil comme celui de la Figure 32.

message URL fig32.gif
Figure 32 Le débit sur réseau d'un flux multimédia encodé à débit constant.

Les opérations VCR (seek, jump) nécessitent un nouveau remplissage du buffer. Ce transfert se fait le plus vite possible afin d'offrir une bonne réactivité à ces commendes et engendre donc une fluctuation importante dans le débit.

Notes
15.

frames P, I, B : types de cadres utilisés dans le format de compression MPEG