document - Site de formation CM 84

Broadcast et Media Synchronisés :
QT4, RealG2, MS WMT4, une bataille décisive...
Yannick Chalony
La sortie de QT4 , prerelease alias b21, pose le champ de bataille complet dans la lutte autour
d'un format de type Broadcast et de 'Media Synchronisés' via les reseaux dont tout
particulierement Internet , bien sur. Il s'agit , outre Apple avec QT4 , de RealNetworks , de MS
MediaPlayer , et d'un outsider le MPEG-4 .
Nous verrons en quoi Quicktime constitue une architecture globale et tres puissante , mais
totalement propriétaire, tandis que RealNetworks s'appuie pour partie sur sa technique
proprietaire "G2" mais aussi sur le langage standardisé SMIL du W3 Consortium ; que ensuite
MS recourt tout comme Apple éssentiellement à des solutions propriétaires (HTML+TIME) ;
et que enfin le MPEG-4 , standard ISO ambitieux , pourrait à ce titre, recevoir un large accueil
face à ces 3 solutions .
rappelons brievement l'interet des medias synchronisés : il s'agit d'assurer le synchronisme de
pistes media , de formats tres divers, notamment compressés selon des codecs optimisés pour
chaque format media rentrant dans la présentation multimedia; avec au final un gain substantiel
en terme de bande passante internet.
Ce vaste comparatif à 3 (+1) fera l'objet de la seconde partie de l'article; la premiere étant
consacrée à QT4 , non dans sa vaste totalité , mais déjà à noter en quoi il differe et progresse
depuis QT3 , s'agissant donc d'atteindre à ce format Broadcast en ligne.
Part 1 : Quicktime 4.0 , quoi de neuf ?
QT4 apporte enfin un format de video "LIVE" et "Video On Demand" à Quicktime ; quand
meme 2 ans apres RealNetworks ce qui constitue un lourd retard en terme de positionnement
marché à rattraper . A cette fin, Apple propose d'emblée son soft serveur streaming en Open
Source façon Linux , là ou RealNetworks et MS ont des couts de licenses non négligeables ; une
maniere de sensibiliser le portefeuille...sera ce suffisant pour autant ? à defaut de pouvoir
répondre , nous examinerons techniquement , en seconde partie , le 'streaming' version Apple;
ainsi que ses deux concurrents.
Quicktime Player (ex MoviePlayer) progresse agréablement dans son aspect cosmétique. Nous ne
commenterons pas cela , mais plutot déjà les apports les plus marquants à QT4 en terme de
formats media et fonctionnalités.
Texte © Yannick Chalony
1
Ainsi QT4 lit désormais un fichier Flash , mais n'exporte toutefois pas (encore..) à ce standard ;
lors du WWDC 99 , Apple a montré la possibilité d'utiliser l'interface d'interactivité (Alpha)
d'une animation Flash (une simple piste du movie désormais) pour controler d'autres pistes
media du movie ...smart ! au passage , sale coup pour Electrifier (et LiveStage) passé , ici meme,
en revue en fevrier . Apple a simplement pris acte de la position dominante du format Flash en
matiere de graphique vectoriel sur internet . Ce qu'avait anticipé RealNetworks presque un an
avant Apple..; Ensuite QT4 a eu le bon gout mais tardif d'inclure l'audio Mpeg1 Layer 3 (.mp3)
, ce qui raisonnablement aurait pu aussi etre fait depuis un an ... ; là encore le dynamisme de
RealNetworks contraste avec l'acquisition recente de Xing Technology , heraut du .mp3 en
version VBR (variable bit rate) , format mp3 "évolué" que ne reconnait pas QT4 ! rappelons qu'il
s'agit toutefois d'une version prerelease b21
Tout cela est quand meme positif; reste à voir , en détail, en quoi progressent les deux codecs
(audio et video) sur lesquels reposent tous les espoirs actuels de QT4 pour son OPE sur le
'streaming' sur internet : Sorenson version 2.0 pour la video et QDesign 2.0 pour l'audio.
De fait la disponibilité , ou non, de codecs audio et video capables de data rate tres bas , tout en
conservant une qualité suffisante, reste tres certainement l'aspect LE plus critique de chacune des
trois solutions en lice (Apple , Real, MS) ; voyons cela pour QT4 .
QDesign 2.0 : ce codec audio fonctionne exceptionnellement bien s'agissant de distribuer de la
musique dans les bit rate les plus bas , par ex. entre 8 et 32kbps (1 a 4 Ko/s) ; il n'y a tout
simplement rien pour l'égaler avec la possible exception du codec Sound VQ dont Yamaha
propose player et encodeur gratuits. On devrait du reste retrouver ce type de codec Sound VQ
dans la version finale de Mpeg-4; mais il ne figure pas dans Quicktime . Pas trop grave des lors
que QDesign fait merveille pour délivrer un contenu musical stereo quasi FM des 24 ou 32kbps !
performance inaccessible aux codecs audio de Real G2 , ni au format MS Audio 4.0 (peut etre un
dérivé de .mp3 ou Sound VQ ?) ; il leur faut un bit rate sensiblement plus élevé pour exprimer
leurs qualités .
Ainsi , ni le .mp3 , ni RealAudio G2 , ni MS Audio 4.0 ne se revelent capables de soutenir la
comparaison avec QDesign sur tout flux musical --stereo entre 20 et 40kbps ; soit le debit réaliste
actuel du net pour un format radio ; toutefois le layer3 se rattrape totalement des lors que la
bande passante augmente , ce qui en a fait LE standard de 'distribution' en qualité quasi CD sur
le net , à defaut d'etre un possible format de 'diffusion' , dans l'etat actuel des débits reseaux.
Dans ce contexte les fonctionnalités Live et On Demand de QT4 devraient logiquement booster
QDesign en diffusion (radio notamment) ; pour autant QDesign n'est pas exempt de défauts ,
parfois assez génants, nous les verrons plus loin.
S'agissant de la parole et tout particulierement des bit rate vraiment tres bas (5 a 8kbps) pourtant
parfaitement aptes à constituer la piste audio d'un flux video LIVE , genre un présentateur de
news , QDesign propose QDCM vers 6kbps avec une qualité peu ou prou similaire au codec
'voix' RealAudio G2 en 6,5kbps; c'est à dire tres intelligible au minimum ; dans ce registre parlé ,
MS propose dans MediaPlayer les remarquables codecs MS Audio 4 ou ACELP (Sitpro Lab) en
remplacement de VoxWare ;
anecdotiquement , ce dernier, était pourtant spectaculaire à descendre vers 350 octets/sec avec
certes un son quelque peu synthetique mais tout à fait intelligible ! de plus un astucieux player
Voxware autorise la lecture accelerée de ce format audio dictaphone (plus d'une heure sur une
disquette !!)
Apres une longue attente , Quicktime dispose enfin de quelque codec audio bas débit, ce qui a
(trop) longtemps fait séverement défaut sans raison bien légitime , vu qu'ils existaient ici ou là ;
bref avec QT4 c'est presque QDesign ou rien , meme sur la voix, vu que PureVoice de
Qualcomm ne fait désormais pas beaucoup mieux.
Texte © Yannick Chalony
2
Sorenson 2.0 : cet excellent codec video pour faire du CD-Rom est venu , tardivement en 98 ,
combler un vide cruel dans Quicktime apres que Apple ait bien légerement laissé partir , début
97, l'exceptionnel codec ClearVideo (fractales) chez ...RealNetworks ;
Iterated Systems , le créateur du codec, avait pourtant sorti deux versions Mac/PC en 96 de
ClearVideo . On ne comprendra toujours pas le manque d'opportunisme de Apple en regard de
ce codec exceptionnellement performant en tres bas débit ...; surtout lorsque l'on voit ce qu'a su
en faire RealNetworks et la part de marché conquise grace à la qualité quasi unique de ce produit.
De fait , de 97 à 99 , RealNetworks a fait cavalier seul ; ce n'est donc que tout recemment , avec
Sorenson 2.0 pour Apple et avec Mpeg4 -V3 pour MS , que RealVideo rencontre finalement
quelque concurrence à ses 85% , bien établis, de part de marché.
Apparu en 98 avec QT3, Sorenson 1.0 avait montré de tres réelles qualités pour faire du CDRom, bref enfin remplacer Cinepak. Mais Sorenson ne fonctionnait que imparfaitement avec
comme principaux defauts une médiocre gestion du mouvement et de l'espace couleur ,
particulierement en situation de forte compression ; donc sur internet pour commencer ; ainsi là
ou ClearVideo / RealVideo pouvait encore fonctionner 'correctement' entre 20 à 40kbps ,
Sorenson en était quasi incapable avec donc principalement les deux types d'artefacts mentionnés
(mouvement et couleur).
les outils pour combattre ces defauts sont fournis avec la version pro du codec , Sorenson
Developer , ainsi que l'utilitaire de compression Media Cleaner 3.0 ; mais il s'agit pour l'éssentiel
de recourir au VBR (variable bit rate) ce qui consiste à autoriser le débit à fluctuer avec désormais
des pics de data rate (typiquement entre ><2 et ><5 voire plus..) permettant un maintien de la
qualité lorsque le compresseur se voit trop sollicité par le mouvement dans l'image , le point
faible de Sorenson .
Ce procédé fonctionne de maniere satisfaisante en usage CD-Rom vu les débits possibles avec les
lecteurs CD actuels . Il fonctionnait aussi , à peu pres, sur internet avec le précédent systeme de
diffusion pseudo-streaming de Quicktime ; c'est à dire en fait un téléchargement pur et simple du
fichier avec une lecture immédiate possible de ce qui a déjà été chargé (le Fast Start) ; dans ces
conditions , 'hors temps réel', les variations de debit dues au VBR ne sont pas critiques;
par contre désormais avec le vrai streaming de QT4 (LIVE au moins) il y a une quasi obligation
de controler étroitement le débit, et alors un VBR laxiste n'est plus possible meme sous la
'protection' d'un buffer limité à quelques secondes !! Sorenson est rattrapé par ses defauts , ce que
l'on constate dans les flux LIVE QT4 actuels (voir en deuxieme partie).
En aparté , on peut rappeler comment tres simplement faire fonctionner Sorenson 1 et 2 en
VBR sans acheter la version pro Developer du codec ($500) et donc alors aussi obligatoirement
MediaCleanerPro 3 ($400) ;
Il suffit ,depuis Premiere ou autre , de faire fonctionner Sorenson simplement en mode "qualité" ,
c'est à dire via le reglage de 0 à 100 du curseur de qualité du codec , ceci donc SANS selectionner
la case data rate ; des lors le codec ne cherche pas à respecter un data rate mais applique
simplement un facteur de compression constant à l'image , ce qui produit un data rate variable
selon la complexité des images ; apres quelques tatonnements on sait assez rapidement trouvers
ses marques autour du rapport recherché entre qualité image / débit moyen et cretes ; certes
Sorenson pro et MCP3 disposent de quelques optimisations supplémentaires , mais en pratique
cette solution peut parfaitement se suffire tant en qualité que 'quantité', s'agissant des débits CDRom les plus courants; et c'est gratuit !
Avec Sorenson 2.0, l'éditeur apporte son lot d'améliorations au codec , à commencer par un
temps d'encodage divisé par 2 ; si les fonctionnalités de la version gratuite demeurent indentiques
à la version 1.0, le kit Developer Pro apporte quelques nouveautés interessantes en vue de
diminuer les artefacts liés au mouvement dans l'image (LE défaut Sorenson) ; on notera ainsi les
Texte © Yannick Chalony
3
nouveaux outils Block Refresh Frequency , Minimum Quality, entre autres . Désormais , meme
avec un bit rate assez contraint, Sorenson reduit sensiblement ces désagréables artefacts de
mouvement ; on peut considérer que , en CD-Rom , Sorenson 2 est arrivé à maturité meme si
finalement il n'apporte rien de plus (plutot moins) que du Mpeg1 ; en fait Sorenson trouve un
positionnement multimedia idéal avec une tres réelle et surprenante qualité pour des 'petits'
débits (CD-Rom) entre 20 et 80 Ko/s par ex. ; au delà et surtout pour de la video full screen , full
motion , le Mpeg1 reste intouchable des 150Ko/s donc.
pour revenir sur la gestion des artefacts de mouvement de Sorenson 2.0 , si l'on voit qu'en CD
c'est plutot résolu , il n'en va pas de meme avec les contraintes d'internet toujours trop séveres en
terme de bit rate pour Sorenson ; là le VBR ne peut s'exprimer librement, au moins sur des flux
LIVE, et on voit toujours beaucoup d'artefacts liés au mouvement dans les sites de demo LIVE
de QT4 (voir *les pubs* sur Bloomberg TV par ex.) .
Comment analyser techniquement les 'difficultés' de Sorenson ? pas vraiment facile , vu que
aucune info n'est disponible ; tout au plus savons nous que Sorenson utilise le Vector
Quantization , tout comme Cinepak et Indeo 3 ; hors Cinepak ne présente pourtant pas le meme
degré d'artefacts liés au mouvement , ni aussi la meme tres importante charge CPU en lecture ;
ainsi Sorenson est plus exigeant en puissance machine que du Mpeg1 !!
Si Sorenson , Cinepak, Indeo3 ont en commun l'usage du Vector Quantization (VQ) , on note
d'emblée que la qualité d'image de Sorenson est nettement superieure , ce qui doit bien signifier
que des choix qualitatifs différents ont déjà été opérés ; ainsi là ou Cinepak chercherait fort
logiquement à ramener à zero le maximum de coefficients , peut etre Sorenson ne fait il pas ce
'forcing' pour conserver le maximum de qualité , ce qui revient en VQ à construire une base de
blocs plus riche ; tout ceci expliquerait du reste tres bien le temps d'encodage tres lent des algos
de Sorenson et la forte charge CPU en lecture ;
rappelons le principe du Vector Quantization sensiblement different des systemes à base DCT :
le VQ utilise le frame differencing dans lequel la partie encodée de chaque frame est la
soustraction opérée par rapport à la frame précédente ; seuls les pixels qui ont changé sont
encodés selon un systeme de grille 4><4 et un espace couleur dit YUV-9 sous-samplé sur 9 bits ;
en comparaison le JPEG utilise un espace couleur YUV 4:2:2 sur 16 bits pour une compression
sur base DCT.
bref dans cet espace YUV-9 , le Vector Quantization analyse des blocs de 4><4 pour constituer
une base de blocs 'génériques' , contre laquelle chaque bloc sera comparé, la compression
constituant ici à déterminer si le data rate permet de créer un nouveau bloc en fonction du
contenu spécifique de chaque image ou bien si l'on doit piocher le bloc 'générique' le plus
approchant dans une base plus ou moins limitée donc ; on conçoit que dans un espace d'analyse
déjà pas mal sous-samplé une réduction de la classe de blocs (tres forte compression) produise
finalement de severes aberrations à commencer par la couleur ; ce qui se verifie aussi avec
Sorenson ;
on notera toutefois , dans ce contexte un peu similaire aux Look Up Tables de la couleur indexée
(attention, sans etre limité à 256 codes de blocs pour autant) que les algorithmes d'analyse de
Sorenson doivent etre tres sensiblement meilleurs que Cinepak , tout particulierement si l'on
admet que Sorenson fonctionne , à qualité égale, avec un data rate 2 voire 3 fois moindre que
Cinepak !
On pourrait conclure que meme si Sorenson survole la catégorie VQ , probablement l'analyse
type DCT sur bloc 8><8 (Jpeg , etc..) associée à la compensation et estimation de mouvement
(Mpeg,etc..) restent elles toujours des techniques plus efficaces à ce jour . L'observation
comparative de tout ceci n'est pas simple du fait que Sorenson et Cinepak utilisent aussi des blocs
'tempo' ecran 8><8 pour afficher , ce qui complique pas mal l'observation de la technique VQ .
Texte © Yannick Chalony
4
En pratique , dans QT4, Sorenson se rapproche désormais la "qualité" d'image de Real G2 dans
les tres bas bit rate, sans pour autant l'égaler ; à commencer donc par la pietre gestion du
mouvement dans ces compressions extremes , mais aussi en notant que les sites de demo de QT
Live délivrent un flux 40kbps qui ne fait déjà certainement pas 2 fois mieux que Real G2 en
20kbps , spécialement dans la gestion du mouvement ; ou meme que MS Mediaplayer en 28kbps
; hors un modem 56k aura beaucoup de mal à suivre les moindres fluctuations du reseau sur un
flux déjà aussi élevé que 40kbps ; nous verrons tout cela aussi en seconde partie.
Pour conclure ce long passage sur Sorenson et lui delivrer quand meme quelque satisfecit, il
convient de rappeler que , hors cette zone délicate entre 20 et 40kbps, Sorenson devient
franchement excellent ; pour preuve les demos de trailers de films Hollywoodiens à paraitre aux
USA (toujours sur le site Apple) compressés vers 128kbps pour la partie image et qui sont
franchement TRES bons ; à notre avis supérieurs alors à Real G2 ; pour comparaison , voir Red
Thin Line , par ex., qui est disponible quasiment au meme bit rate dans ces deux standards (chez
Real.com pour le Real G2) ; pour autant Sorenson devra désormais aussi affronter MS Mpeg4V3 , tres performant aussi , sur tout bit rate qui plus est ...
Ensuite Sorenson incorpore un excellent algo d'affichage en 200% , de type interpolation
bicubique , tel celui dispo dans Photoshop. On regrettera que Apple n'ait du reste rien prévu de
similaire dans Quicktime Player ou le Plug pour Netscape /IE.
bref en LAN , T1, xDSL, Cable Modem , Sorenson fera certainement merveille ; mais avec un
parc de modems d'acces internet encore à 70% en 28,8 ou 33,6k , Sorenson reste bien à la peine ;
surtout que dans ce contexte , Apple ne dispose pas non plus de la solution serveur la plus souple
(tel le SureStream de Real G2).
pour clore ce rapide (..) survol des nouveautés de QT4 , on remarque que le Mpeg2 version
software n'est pas dispo alors que jamais les Mac G3 B/W n'ont été aussi puissants y compris en
affichage...; tout cela rappelle les retards et autres rendez vous manqués de QT ; pour mémoire
avec l'OpenGL de SGI (92) "au profit" de QD3D quelques 3 ans plus tard ; incidemment en ce
mois de mai...99 , Apple integre finalement OpenGL ; no comment; on comprend aussi assez
mal que QT4 ne lise pas désormais le VRML 2, pourtant 'enfant naturel' de 3DMF .
De meme la gestion du Mpeg dans Quicktime n'a jamais été idéale , euphemisme...; avec une
absence constante de décodeur dans QT For Windows , rien n'a permis d'exploiter par ex des 96
l'interessant Mpeg en version m.75 et/ou .m15 , c'est à dire une variante (officielle) du standard
Mpeg en 7,5fps et 15fps ; le principe est simple , il consiste à resampler le movie source en 7,5fps
puis à l'encoder en 30fps, frame rate officiel Mpeg ; l'adjonction du suffixe .m75 indiquant
finalement au player qu'il faut bien réajuster la lecture en 7,5fps ; sur un movie 160><120 on
garde une qualité image correcte jusque 5 à 7 Ko/s , ce qui , mi 96, etait une performance
vraiment excellente sur internet ; au demeurant si .m75 et .m15 relevent du standard Mpeg , une
fois encapsulés dans QT ce dernier peut en faire un peu ce qu'il veut ; à condition d'avoir une
version QT For Windows pour exploiter cela ! tel l'adjonction à l'époque d'une piste audio en
GSM 8kbps ! là encore il aura fallu attendre 1998 et QT3 pour avoir enfin un codec audio bas
debit présent aussi dans QT For Win !!! tout cela fut bien tardif ...
bah, foin des grincements , avec QT4 , Apple consolide un puissant format multimedia capable
de fonctionner en multicouches (à la différence de Real G2 et MS mediaPlayer) avec une liste
impressionnante de formats media supportés ; on ne peut que reconnaitre l'élégance , l'excellence,
et l'avance technologique de QT4 en tant qu'architecture multimedia , capable d'apporter une
solution pertinente dans chaque creneau du multimedia ; des lors pourquoi ne s'imposerait il pas ,
sur internet , dans la diffusion de 'media synchronisés' ce qu'il sait faire tres souplement , mais
finalement aussi en tant que format Broadcast ?
Ce qui nous amene à cette seconde partie consacrée à l'analyse comparative des solutions en
Texte © Yannick Chalony
5
concurrence tant pour les Media Synchronisés , que le Broadcast ; donc l'analyse détaillée des
architectures media , de la qualité des composants (codecs), mais aussi de l'etat actuel de
performances des solutions serveurs disponibles; bref ce que l'on peut voir ou faire , ici et
maintenant
Part 2 : Les Streaming Multimedia :
Le 'streaming multimedia' est la combinaison de divers media en flux selon une synchronisation ;
c'est principalement cet aspect de relation au temps , et donc de la synchronisation des divers
éléments distribués , qui a longtemps manqué à HTML . Le tout compliqué par la difficulté de
s'assurer d'une reception en temps réel de categories média les plus divers (audio, video, images,
texte) ;
en caricaturant quelque peu , on pourrait penser que les protagonistes de cette bataille des
streaming media sont partiellement en train de réinventer la roue (html) , mais désormais
controlée par de nouveaux 'paquets' de technologie propriétaire ; pas vraiment un progres alors ...
? ; de fait le Web nous délivre depuis longtemps un riche contenu multimedia ; mais manquaient
quand meme trois choses : l'echelle du temps , la synchronisation , et l'adaptation de la taille des
media au 'tuyau' du client.
Voyons comment les solutions proposées abordent le probleme :
1) Les diverses solutions : Apple, Real , et Microsoft .
avec QT4, Apple , propose un traitement totalement propriétaire, avec déjà l'avantage de ne pas
nécessiter un nouveau langage , additionnel au HTML . Pour oser une comparaison, il y a de
longue date diverses propositions en vue de créer un langage traitant spécifiquement du format
vectoriel sur internet (le VML par ex) , et puis il y a eu ...Flash ; tres bien adapté à ses buts, ce
format propriétaire s'est rapidement imposé comme un format incontournable ; QT4 offre , au
meme titre, une technologie tres performante et opérationnelle en tant que format de streaming
multimedia ; la démarche de Apple a le mérite d'etre limpide : tel Flash ou flop !
Ce qui contraste avec la bataille de chiffonniers (pardon pour eux) entre RealSystems et
Microsoft autour de langages 'standard' mutuellement contestés ; en fait c'est surtout MS qui
accable la technologie RealG2 de communiqués à la limite de la désinformation pure et simple.
En effet , RealSystems a pris une bonne longueur d'avance en jouant la carte de SMIL ,
désormais au stade de langage officiellement 'Recommandé' par le W3C (world wide web
consortium) . Real dispose depuis quelques temps d'une technique et d'outils opérationnels , déjà
sur le marché ; avec une méthode simple : le HTML au browser , le SMIL à un player ...et Real
entre les deux !
evidemment ce grossier affront à Big Browser contrarie la belle vision du 'tout browser' de MS ,
qui se bat désormais aupres du W3C pour imposer HTML+TIME (parfumé XML) en
...remplacement de SMIL ! Nous regarderons de pres ces langages 'cousins' dont bien sur la
mouture MS , présentée poutant comme une extension de SMIL, oublie de lui etre compatible
...; MS nous rejoue l'épisode Javascript , au choix.
Ce tableau, rapidement planté, va etre détaillé en examinant les techniques et fonctionnalités
,opérationnelles ou non de chacun ; puis par un comparatif qualitatif des resultats actuels
constatables ; enfin la derniere partie sera consacrée aux techniques de streaming en présence , à
leur degré de parenté , et aux systemes serveurs.
Texte © Yannick Chalony
6
Apple Quicktime 4.0:
là tout est relativement simple , unifié, operationnel . Quicktime est ,par conception,
multicouches à la difference de la base RMFF/AVI de MS ou Real, lesquels ne font
qu'encapsuler une diversité de formats media dans un format conteneur de streaming ; sans
procurer un systeme multicouches pour autant ;
Ainsi dans QT4 on peut superposer , mélanger, les formats graphiques et video (audio, etc..) les
plus divers ; tel incruster de la video Mpeg dans l'alpha channel d'un graphique compressé PNG ,
par ex, et bien sur superposer diverses opérations de découpe, transparence de ce type ; gérer
l'ordre des layers tout comme dans Adobe PS ou AE ; grace à des outils de compositing tels
Electrifier ou LiveStage , tout ou presque est possible à l'instar de ces deux softs prestigieux .
Essayez donc cela avec RealMedia ou Windows Media Technology ....
Bien sur, la présence d'une timeline gere l'instant et la durée des media ; Quicktime en accepte
une diversité impressionante , environ 70 rien qu'entre image et son ! pour le reste, c'est tout
format ou preque dont on peut avoir besoin dans le cadre d'une composition multimedia (texte ,
vectoriel, 3D, MIDI, etc..) ; enfin QT4 possede une large variété de filtres et effets divers (140
effets de transition SMPTE par ex) ;
A cela QT4 ajoute des facultés de liens avec la page HTML , pour y afficher des encarts
synchronisés de texte , déclencher l'affichage d'URL , par ex ; Au final , il ne resterait plus qu'à
ajouter , un jour, à cela la faculté d'afficher les pistes media dans plusieurs fenetres , si il y a
quelque interet à le faire .
Rappelons les deux outils majeurs pour faire de la composition de streaming media avec
Quicktime : Electrifier passé en revue ici en fevrier 99 ; et LiveStage à découvrir dans toute
bonne presse Mac.
Parmi les rares limites de QT4 , notons que dans le cadre d'une composition (un movie en fait)
on ne peut soumettre divers flux , accessibles dynamiquement mais separement , pour chaque
piste media qui pourrait justifier sélectivement d'adaptation dynamique en ligne. Certes QT4
prevoit l'envoi du movie le plus adapté aux conditions (Alternate Movie) de la connexion mais
pas de chaque piste media séparement . La complexité des compositiions réalisables sous QT4 ne
permettrait pas sérieusement cela , au demeurant.
SMIL et HTML+TIME , dont les possibilités réalistes de composition sont nettement moins
sophistiquées que QT4 , permettent , sur le papier , l'envoi dynamique ou préférentiel de divers
flux media ; ce qui reste peu etre plus une potentialité qu'autre chose au vu des inconvénients de
buffering , resynchronisation , en definitif perte momentanée d'une piste media ; ce qui peut etre
parfois pire qu'une attente globale ; l'idée restant néanmoins bonne sur le principe et
probablement bien adaptée à des compositions plutot simples .
RealSystems G2 et Windows Media Technology : SMIL versus HTML+TIME .
Apres QT4 , voyons Real ; avec SMIL , RealSystems conserve le leadership conquis grace à
RealVideo et l'étend aux streaming media . SMIL est un langage W3C permettant la
synchronisation de multiples formats media avec des éffets coté client tel , actuellement, fondu
entre images, ou bien du texte déplacé ou zoomé ; bref pas de quoi impressionner la palette
d'effets de QT4 ! Tout comme ce dernier, SMIL prévoit un minimum de liens avec la page
HTML (ouverture d'URL , texte ,..) ; Au passage , HTML+TIME ne fait qu'inverser ce
principe en unifiant le tout (html et multimedia) dans LE browser.
Finalement , hors cette divergence majeure ..d'interets , les langages sont plutot proches ;
Texte © Yannick Chalony
7
rentrons un peu dans le détail de SMIL; tout comme HTML, SMIL est un langage utilisant des
tags . Il gere le positionnement des media dans une fenetre d'affichage et leur timing (la
proposition MS étant précisement d'étendre cette fonction temporelle à toute la fenetre HTML,
d'unifier l'affichage) ; avec SMIL on crée des "Regions" (dans une fenetre flottante ouverte par le
player SMIL , pas dans le cadre de la page HTML donc) dans l'esprit des cellules d'un tableau en
HTML ; on en controle le nombre , la taille , la place . Lorsque le layout est composé , on crée la
timeline selon deux modes , le 'SEQentiel' lorsque les fichiers se suivent simplement , et le
'PARallele' lorsque plusieurs fichiers vont jouer simultanement .
SMIL est compatible avec CSS-2, ce qui permet , par ex., d'avoir des Regions qui se recouvrent ,
ou se repositionnenent tels des 'Objects' en DHTML; on utilise des index (ID) .
rapide aperçu des tags de layout:
<layout>
<root-layout> fenetre principale
<region id = videoregion> region de la video
Chaque type de media (que le player doit supporter et/ou disposer des bons codecs ; pas de tel
souci avec QT4) possede son Tag générique; ainsi 'video, audio, img, animation, text,textstream,
etc..'
Lorsque le layout est fait , on crée la timeline ; en SEQ ou PAR donc ; il s'agit classiquement de
fixer le point d'entrée et la durée d'un media ; avec des possibilités d'offset pour commencer à un
temps précis d'un movie , par ex, et de n'en lire qu'une partie.
<par>
<img src="toto.jpg" begin="0s" dur="10s" />
<img src="tintin.rm" begin="6s" dur="50s"/>
<img src="blabla.ra" begin="2s" dur="10s"/>
<img src="blabla2.ra" clip-begin="20s" clip-end="10s"/>
</par>
SMIL permet de délivrer differentes versions de fichiers media , selon par ex. la langue préférée
ou le choix de la bande passante. Tous ces envois préférentiels se font en relation avec des criteres
présélectionnés dans un menu préférences , dans le cas du player RealG2.
D'une maniere générale, le tag <switch> va indiquer au lecteur client qu'il a un choix à opérer ;
par ex. l'adaptation à la bande passante :
<switch>
<par system-bitrate="48000">
<!--numeris ou plus -->
<img src="toto.jpg" begin="0s" dur="10s"/>
<video src="tintin.rm" begin="5s" end="50s"/>
</par>
Texte © Yannick Chalony
8
<par system-bitrate="20000">
<!-- modems 28k-->
<img src="toto.jpg" begin="0s" dur="10s"/>
<video src="tintin.rm" begin="5s" end="50s"/>
</par>
</switch>
dans SMIL , on retrouve des fonctions HTML classiques , telle l'image map , ce qui permet de
créer des zones cliquables dans les Regions ; bien sur des liens hyperlink classiques peuvent aussi
etre utilisés . L'emploi coordonné des offset de temps et des zones cliquables autorise les
fantaisies multimedia les plus diverses.
SMIL est un langage utilisable avec un simple éditeur de texte ou un éditeur SMIL tel TAG de
Digital Renaissance , ou V-Active de Veon; RealSystems dispose aussi d'outils 'maison' pour
créer des SMIL.
le fait que SMIL existe et fonctionne plutot bien ,depuis plus de 6 mois maintenant, suscite
quelque irritation du coté de Redmond qui propose donc HTML+TIME pour contrer le
leadership de RealSystems ; cela , sans bien sur se soucier que SMIL soit un standard de fait
("Recommandé") par le W3C . De fait tant l'esprit que la syntaxe de HTML+TIME sont
similaires à SMIL , mais MS ne semble pas néanmoins vouloir assurer une compatibilité ...un
(mauvais) classique ; MS a un retard d'environ un an car il lui faudra déjà disposer d'une version
finale du client , compatible HTML+TIME , c'est à dire IE5.0 dont l'implémentation actuelle
de ce langage est décrite par MS, soi meme, comme encore 'expérimentale' ; il faudra aussi
disposer d'outils systeme (WMT 4.0) et de composition (Windows Media Tools) totalement
opérationnels . On parle de l'été 99 , ce qui est proche finalement.
L'interet premier de HTML+TIME est d'étendre le mode synchronisé à la page HTML , par
exemple synchroniser une présentation multimedia avec le déroulement du contenu de la page
HTML ; ce qui revient à repenser le layout ; sur le fond , la proposition est de toute façon
interessante seulement si elle doit deboucher sur un standard ouvert (ce qui reste un voeu pieu
des lors que MS est le promoteur du langage et cherche aussi à imposer son browser à cette
occasion !!) . Le premier exemple qui vient à l'esprit et celui d'un tutorial qui pourra etre réparti
entre le flux multimedia (les aspects graphiques) et une partie HTML dynamique pour par ex.
des explications ou commentaires .
voyons un ex. ,le plus simple, de tags de timing dans le contenu HTML; (d'autres syntaxes plus
riches sont possibles pour gerer le timing avec HTML+TIME.)
<p t:begin="1"> paragraphe de texte qui apparait apres 1 seconde
</p>
<p t:begin="5"> paragraphe de texte qui apparait apres 5 secondes
</p>
<p t:begin="10"> paragraphe de texte qui apparait apres 10 secondes
</p>
Texte © Yannick Chalony
9
on le voit, rien de bien nouveau sous le soleil depuis le DHTML...sauf que désormais seul IE5.0
(beta) sait interpreter la totalité de ce nouveau langage ; de fait le HTML+TIME n'a reçu aucun
imprimatur du W3C , autre que la reconnaissance d'une 'Soumission' (..) , ce qui est le tout
premier niveau de la procedure, celui de la communication d'une Note ; à ce stade
HTML+TIME reste donc encore totalement propriétaire à la différence de SMIL.
L'offensive MS est vaste, autour de IE5.0 qui doit introniser , par defaut, ce langage
HTML+TIME avec en ligne de mire le SMIL et le DHTML . Autant dire que les versions 5.0
de Communicator et IE parleront de moins en moins la meme langue , ce qui est une stratégie
constante MS .
un aperçu dela syntaxe HTML+TIME
Behaviors: time
Elements :ANIMATION, AUDIO, IMG, MEDIA, PAR, SEQ, VIDEO
Attributes/Properties :accelerate, autoReverse, begin, beginAfter, beginEvent, beginWith,
clipBegin, clipEnd, clockSource, currTime, decelerate, dur, end, endEvent, endHold,
eventRestart, img,localTime, onOffBehavior, player, playerObject, progressBehavior, repeat,
repeatDur,
src,
syncBehavior,
syncTolerance,
timeAction,
timeline,
timelineBehavior,timeStartRule, type
Methods:beginElement, endElement, pause, resume
Events :onbegin, onend, onmediacomplete, onmedialoadfailed, onmediaslip, onpause, onrepeat,
onresume, onresync, onreverse, onscriptcommand
l'écriture de media synchronisés semble bien devoir etre tres similaire ,sur le fond, à ce que nous
avons vu pour SMIL. toutefois à ce jour , il ne semble pas exister 'en place publique' d'exemples
HTML+TIME déjà par manque d'outil client ; tout ceci reste , à ce jour, encore du domaine des
developpeurs possedant les outils beta nécéssaires (WMT4.0, WMT, IE5.0)
Certes la panoplie Windows Media Tools dispose de certains outils pour , des maintenant ,
réaliser quelques présentations simples de streaming media ; par ex. Media Author , développé
conjointement avec l'éditeur de TAG , permet des compositions de streaming plutot basiques ;
tel la synchronisation d'un flux audio avec l'envoi d'images ; on pensera là encore au présentateur
et son slideshow ; rien de trop sophistiqué non plus ...; avec Media Presenter et Media Publisher
, autres outils , on perçoit bien la stratégie MS d'amener son logiciel PowerPoint dans les
streaming media .
Bref , l'état actuel , encore en devenir, des technologies et des outils de streaming media ne
facilite pas une appréciation comparative des possibilités de chacune des ces 3 architectures ni de
leurs résultats concrets ; ainsi meme si nous connaissons bien les remarquables possibilités de
composition multimedia avec QT4 , nous n'en avons néanmoins pas encore vu dans un format
streaming ; mais là on ne voit pas quelle surprise particuliere il pourrait y avoir , hors de banals
rebuffering , en consultation 'linéaire' ; par contre on aimerait verifier comment se passera un
streaming multimedia en consultation "à la demande" avec donc des acces random en divers
points du movie ; cette interrogation est légitime lorsque l'on voit qu'une composition
multimedia dans QT4 peut rapidement avoir plusieurs dizaines de pistes ; des lors comment se
passeront les acces 'random' en streaming , bref de la consultation VOD donc (ce qui n'est plus
un téléchargement linéaire du fichier)
par contre , à la différence de QT4 ou toutes les pistes media sont multiplexées , parfaitement
synchronisées, SMIL peut , dans son principe , réserver plus de surprises , une référence horloge
n'étant pas multiplexée avec les media mais simplement confiée aux bons soins du lecteur client
Texte © Yannick Chalony
10
qui reçoit des pistes media sans liens temporels établis ; la (re)constitution de ces liens temporels
reposant sur le bon déroulement de la syntaxe prévue pour le rendu .
Néanmoins les demos SMIL que nous avons vues, notamment en provenance du site Real,
fonctionnaient plutot bien , meme avec les impondérables du net ; ainsi les insuffisances de bande
passante étaient gérées correctement ce qui ne veut pas dire fluidement ; avec meme un petit
doute que la technique SureStream (voir plus loin) n'etait pas opérationnelle , avec apparament
des attentes classiques de rebuffering plutot que des changements dynamiques de flux media ,
pour les pistes " à la traine" ; à (re)verifier.
D'autres demos , telles celles du site TAG..plantaient assez régulierement ; elles appellent le
Plug-in plutot que le Player , ce qui plante tres régulierement sur le Mac
bref , meme si SMIL n'apporte pas cette perfection formelle d'une composition réalisée sous
QT4, ça n'en reste pas moins une interessante technologie , qui marche, et satisfait tres bien à
l'éssentiel d'une présentation multimedia en streaming, qui n'a pas forcement besoin d'un
esthetisme poussé mais plutot d'éfficacité . SMIL apporte aussi des fonctions qui échappent à
QT4 , tels des réglages tres sélectifs de préférences (language par ex., flux dynamiques) ; bref tout
ce que le tag <switch> va permettre à SMIL.
La bataille s'annonce difficile avec pour QT4 probablement un handicap de simple crédibilité du
marché (ce qui est peut etre le plus désarmant) face donc aux 85% de part de marché de
RealSystems et face à "l'ogre de Redmond" qui veut désormais tout simplement "tuer"
RealSystems (cf : le site Microsoft s'exprimant sur RealSystems) ; et il dispose désormais d'une
stratégie et d'outils pour cela...
A défaut de pouvoir , à ce jour, bien cerner les mérites de ces diverses architectures , on peut
néanmoins faire une point comparatif sur la qualité des 'briques' de chacun ; en gros la qualité des
codecs , avant de passer au chapitre suivant consacrée aux serveurs et architectures streaming.
2) qualité des codecs audio /video dans QT4, RealG2, MS Video 4.0:
voilà peut etre enfin un passage qui interessera (le plus bien sur ..) le lecteur ! qu'est ce qui
fonctionne le mieux ? quelques heures de tests ont été faites sur internet et en local , sur Mac et
PC ; ce sont les versions player Mac qui ont été testées sur Internet via un acces Numeris sur un
G3/300 ; tests ensuite vérifiés ou completés en local sur un P2/233.
Premierement l'aspect radio ; tres peu de sites diffusent , à ce jour, en live au triple standard
RealAudio, MS Audio, et QT4 ; www.hardradio.com , radio de hardrock , le fait ; l'occasion
donc de comparer des flux --stereo , en tres bas débits (20 à 32kbps) ; ce qui est actuellement le
cas de figure le plus réaliste , donc le plus interessant à vérifier ; à savoir, existe t-il aujourd'hui
une technologie capable de diffuser --en stéreo , avec une qualité acceptable , en direction d'acces
modems 33,6 ou 56k (70% des acces sont entre 28,8 et 33,6); on peut répondre par l'affirmative ,
surtout apres constatation que hardradio diffusait aussi en simple unicast HTTP (au moins tel
que constaté sur un flux RealAudio) , sans trop de 'dommages' au flux ! bref comment monter ,
de nos jours, une radio sans passer par la case CSA ....
Hardradio donc : QT4 y est utilisé en 20kbps sous codec QDesign , qui démontre d'emblée un
son 'différent' , plus clair , stereo plus large, aigus étendus ; comme évoqué précedemment, à ces
bit rate ultra bas , on ne peut chapper aux artefacts sur un contenu musical, et avec QDesign c'est
éssentiellement une 'enveloppe' sonore à type de 'flanger', ce qui va du reste plutot bien avec du
hard rock ! QDesign peut se débarasser presque totalement de cet artefact des 32kbps (stereo) par
ex. , pour un flux de qualité déjà 'supérieure', ciblé vers les modems 56k ; ensuite sur Hardradio,
RealAudio G2 y est aussi exploité en 20kbps , ce qui laissait mal augurer des
résultats...finalement acceptables s'agissant donc de hardrock ,avec meme une stereo que l'on
attendait pas non plus de RealAudio en si bas débit ; reste MS Audio 4.0 proposé en 25 et
Texte © Yannick Chalony
11
34kbps ; d'emblée la stereo de MS Audio4.0 se retrecit , il est clair que c'est du 'joint-stereo'
plutot tres ..sérré ; en 25kbps la qualité du son est aussi la moins bonne du lot ; par contre en
34kbps , le son devient bon , différent mais concurrentiel de QDesign (ici en 20kbps seulement ,
rappelons le quand meme) .
D'autres stations de radios ont été éssayées , confirmant que RealAudio a quelque souci à se faire
face à MS Audio notamment ; et aussi face à QDesign , encore trop peu présent sur le net ; ainsi
nous avons comparé sur NPR (national Public Radio) du broadcast en-- mono : QDesign en
16kbps , MS Audio mono en mp3 en 18kbps (flux non standard?) et enfin RealAudio 5.0 en
16kbps ; les conditions de broadcast en 16kbps mono sont moins 'hard' que précedemment ; le
choix se portait ici entre le son 'plus rond' de MS Audio et à nouveau la 'clarté' de QDesign ;
sans grande préférence finalement ici ; Ce son 'rond' est une constante de MS Audio , plutot
agréable sur de la voix .
en matiere de radio sur internet , QDesign devrait supérieurement fonctionner des lors que on
lui attribuera au moins 32kbps, en stereo ; mais visiblement les diffuseurs tiennent le plus grand
compte du parc modems actuel et n'attribuent pas les 10 ou 12kbps supplementaires qui
permettent à QDesign d'atteindre une tres remarquable qualité ; audiblement supérieure ; pour
autant MS Audio 4.0 n'est pas loin derriere , des 32kbps aussi...: les deux atteignant finalement a
peu pres ce que délivre un radio K7 FM stereo moyen ; quel progres en 4 ans !
(disclaimer : malheureusement le cout extravagant des communications locales en France laisse
l'initiative de tout ceci aux maitres du monde ; ou en sont les belles déclarations de nos politiques
hexagonaux sur 'la nécéssité impérieuse d'un forfait , global, modéré pour l'utilisation d'internet '
:-(; à l'heure meme ou toute l'activité informatique et particulierement l'internet booste
incroyablement l'activité US)
A des bit rate supérieurs , ceux de la 'distribution' sur internet (128kbps) et non de la diffusion
temps réel , RealSystems dispose désormais du .mp3 en VBR (bit rate variable) ; tandis que
MSAudio propose un format (en suffixe .wma) peut etre technologiquement similaire au .mp3
ou alors au Sound VQ ; sans oublier QDesign , parfaitement au meme niveau de qualité à ces bit
rate . Actuellement le layer 3 (.mp3) est quand meme le standard de fait en distribution.
Fort logiquement , on peut penser que l'on retrouvera aussi en diffusion ces solutions lorsque les
tuyaux de l'internaute auront grossi (cable modem, xDSL, satellite) .
Notons aussi que , actuellement, la version de MS Media Player , pour MacOS, est tres
notablement moins complete que celle sous Win95/98/NT; à commencer par l'absence de ces
nouveux codecs audio 'hauts debits' (.wma) ; ensuite pour ce qui est de la partie video de
MediaPlayer / MacOS, le codec MS Video Mpeg4-V3 est aussi absent (seulement V1 et V2) ;
des lors selon le choix de l'auteur de l'option Multiple Bit Rate dans Windows Media Encoder ,
la compatibilité avec le Mac n'est meme pas acquise...
Apres la radio, la Video en ligne sur le net ; là encore peu de sites diffusent au triple standard
RealG2 , QT4, MS4 ; de fait la prise de marché de QT4 Streaming semble bien lente ...; et alors
, à defaut de convaincre les gros acteurs du broadcast sur le net (CNN, ABC, ZDTV,..)
d'adopter aussi QT4 Streaming , Apple met en ligne un ou deux depuis ses propres serveurs
Apple.com (tel Bloomberg TV qui diffuse déjà en RealG2 et MS4 depuis son propre site); ce qui
autorise heureusement la comparaison des trois solutions techniques .
Le site Bloomberg diffuse en RealG2 SureStream , en restant compatible avec RealVideo5.0, et
propose ainsi classiquement deux flux modems (28,8K et 56K) . Bloomberg utilise aussi deux flux
sous MS WMT 4.0 , là encore pour conserver une compatibilté maximum avec un parc éxistant
sous NetShow 3.0; (MS4.0 autorisant normalement ,comme RealG2 SureStream , du Multiple
Bit Rate via un seul fichier)
Texte © Yannick Chalony
12
Bloomberg diffuse 24/24h de l'info HiTech et boursiere ; c'est donc une succession à l'antenne
de journalistes présentateurs ('talking head' video) , de reportages, et de pubs ; ce qui fait 3 types
de video bien distincts, pour voir apparaitre, ou non , des défauts...
Précisons déjà , que vu les difficultés que rencontre le codec Sorenson dans les tres bas débits,
Apple diffuse Bloomberg TV via un seul flux de 40kbps , ce qui est plus élevé que les flux de
RealG2 et MS4; éffectivement sur Bloomberg (et ailleurs du reste) un flux référencé 28,8 délivre
classiquement 20kbps, un flux référencé 56k delivre 34 kbps ; et ce donc tant pour RealG2 que
MS 4.0 ; les chiffres sont parfois trompeurs...;
cette limite à 34kbps correspond statistiquement à la réalité 'fluctuante' d'une connexion via un
modem 56k; on peut donc considérer que Apple 'ruse' avec un flux de 40 ou 42kbps 'hors norme',
ce qu'ils peuvent tenter et plus ou moins réussir du fait qu'ils distribuent eux memes , depuis des
serveurs et tuyaux tres performants (chez Apple donc) ce flux de demo Bloomberg en QT4
Streaming ; c'est certes malin , mais ce mode de 'demo sécurisée' en 40kbps+ ne correspond pas
exactement à la réalité quotidienne du net , de ses sites, tuyaux et serveurs , où 34kbps semble
plus conforme à un acces modem 56K .
Sur les images de plateau (journalistes plutot statiques) la qualité d'image RealVideoG2 se
détache assez visiblement avec une image étonnament précise ainsi qu'un tres bon espace couleur
; Sorenson de QT4 s'en sort plutot bien sur la précision d'image avec quand meme un espace
couleur visiblement 'different' mais aussi déjà certains artefacts liés aux (petits..) mouvements
dans l'image , tel les mouvements de bras , de mains , de tete des journalistes ; MS 4 Video
fonctionne bien aussi , avec déjà repérables certaines caractéristiques du codec Mpeg-4 V3 (voir
plus loin) ; l'image est un peu 'blurée' ce qui n'est pas du reste rédhibitoire ; il semble que MS4
ait privilégié une tres bonne fluidité des images avec donc peu d'artefacts sur les mouvements de
bras , de mains, et surtout un étonnant synchronisme avec la voix (lipsync des levres) ; bref 3
qualités indéniables de MS 4 Video --meme en flux 20kbps !! curieusement , le flux superieur
sous 34kbps ne progresse pas qualitativement dans le meme rapport...
S'agissant du lipsync , la demo Sorenson QT4 sur Bloomberg ou HBO est aussi parfois
décevante (desync flagrant) , là ou le lipsync de RealG2 est plutot proche de MS4 Video.
L'espace couleur MS4 Video est là encore légerement moins bon que sous RealG2 ;
particulierement avec le MediaPlayer pour MacOS qui semble avoir des presets d'affichage bien
discutables (couleur désaturée , et image trop claire) et ne pas non plus disposer des filtres de
'post-traitement' image et son tels que présents dans la version Win; laquelle dispose aussi de
classiques réglages personnalisés (niveau et saturation couleur, luminosité) ; des possibilités peu
ou prou similaires avec RealPlayerPlus G2 ($29), mais pourtant absentes de QT Player...
Ensuite lorsque Bloomberg diffuse des reportages , ceux ci sollicitent essentiellement la qualité de
la gestion du mouvement dans l'image avec donc l'apparition , ou non, de phénomenes de 'blocs'
(blockniness) ; à cet exercice , RealG2 et MS4 Video s'en sortent normalement sans trop de
problemes , par contre Sorenson QT4 montre déjà bien des défauts à savoir gérer le mouvement
dans l'image lorsque le bit rate ne peut raisonnablement fluctuer dans de grandes proportions (le
cas du Live donc)
Ensuite arrivent les publicités ; et là Sorenson s'éffondre completement , à en devenir le plus
souvent quasiment irregardable, là ou RealG2 et MS 4 Video arrivent à préserver la qualité de ces
images , par nature , souvent fortement animées . Dans cet exercice, RealG2 semble délivrer peut
etre moins d'images (d'inter-frames) en cas de fort mouvement que MS4 Video, mais elles
semblent conserver une netteté que ne privilégie pas toujours MS4 video ; de meme la qualité de
l'espace couleur de RealG2 , sur certaines pubs, reste absolument étonnante s'agissant quand
meme d'images tres fortement compressées !
la piste audio de ces video 'vignette' repose , pour les 3 solutions, sur l'usage de flux entre 5 et
Texte © Yannick Chalony
13
8kbps pas significativement différents ; MS4 étant peut etre légerement plus agréable à l'oreille ,
et le plus diversifié en terme de codecs et flux.
Il semble que Apple ait conscience de la faiblesse actuelle de Sorenson dans les tres bas débits ,
ou plus précisement avec les forts taux de compression, et éssaye d'échapper à cette réalité en
communiquant sur "le futur" de Mr tout le monde, celui des réseaux hauts debits, (cable modem,
xDSL, satellite) ou Sorenson sera tres à son aise ; en évoquant à cette occasion la qualité (tres
réelle) que sait atteindre Sorenson dans les demo movies de trailers Hollywoodiens proposés sur
le site Apple (Star Wars, Red Thin Line, Mummy2,..) ; certes la qualité est désormais au rendez
vous , vraiment excellente meme , y compris la bonne gestion du mouvement ; pour autant si l'on
analyse ces movie trailers de demo QT4 on trouve environ 150kbps de bit rate pour la seule
partie video ; ce qui élimine déjà un acces ISDN 128k et meme une T1 aux USA ...
Toutefois, éffectivement , les choses bougent là bas beaucoup plus vite que dans notre
Hexagone...et la vitalité des divers acteurs des secteurs telecoms et reseaux , permet à certains
augures de prédire que ,dans 3 ans, peut etre 30% des acces a internet seront --là bas , de type
'haut débit' .
Et pourtant , il se pourrait que Sorenson reste finalement un codec pas idéalement adapté à de la
'transmisssion' ; du fait que le maintien de sa meilleure qualité reste trop lié à d'importantes
variations de bit rate (certes le VBR modéré est désormais utilisé ailleurs en transmission,
notamment en Mpeg2) ; ce qui nous amene à premierement analyser les chiffres de Sorenson en
terme de --taux de compression sur ces trailers de demo; sur le site Apple ; ce sont des movies au
format 240><136 (ou 140) et 8fps (soit 1/3 du frame rate nominal du cinema , 24fps , ce qui
indique déjà l'excellence de la source : un telecinéma reporté vers Beta Numerique ou équivalent;
bref pas une source en simple DV...) .
Pour ne pas dépayser le lecteur , on gardera le principe de calcul d'une compression sur la base
d'un espace YUV 4:2:2 16bits ; et là Sorenson compresserait à raison de :
240><136><16bits><8fps , le tout divisé par 150kbps ; soit environ 28/1 ce qui reste tres modéré ;
mais encore faut il se rappeler que Sorenson n'est pas dans un YUV-16bits mais un YUV-9bits ;
des lors la compression peut etre légitimement estimée presque de moitié moindre encore !
dans ces taux modérés, tout codec récent est bon ou presque ! nous avons ainsi voulu verifier ce
que donnait le fait de transcoder , à data rate égal , l'un de ces trailers sous Sorenson
(inévitablement déjà bien artéfacté en l'état) donc vers ClearVideo 1.2 (tres peu décelable) , puis
en MS Mpeg4-V3 (tres légerement décelable) ; on peut estimer que sur la source d'origine en
Beta Numerique , ClearVideo eut été largement aussi bon que Sorenson , ainsi que MS Mpeg4V3 ; sans oublier Indeo 5.0 , performant aussi mais quand meme en retrait de Sorenson (codec
désormais disponible pour le Mac depuis le 19 mai)
Bref Sorenson est excellent jusqu'à un point de rupture lorsque le bit rate vient à manquer ; il
reste , à ce jour, toujours assez loin des prouesses de RealG2 lorsque il s'agit de délivrer de la
video Live en 34kbps (soit environ 26kbps pour la piste video) ; prenons simplement la calculette
: RealG2 exploite un espace couleur YUV-16bits ; le frame rate 'nominal' est classiquement
7,5fps soit 1/4 de ntsc ; (c'est celui là qui compte pour notre calcul , et non le fait que la réalité de
la connexion soit plutot vers un 5fps effectif, selon le drop frame)
format QCIF = 176><144><16bits><7,5fps ,divisé par 26kbps ; soit...116/1 !! performance
inaccessible à l'etat actuel de developpement de Sorenson et peut etre à son principe meme (le
Vector Quantization) ; à noter quand meme le coté abstrait de ce ratio élevé tant qu'il n'est pas
pondéré par le facteur de redondance entre images ; toutefois 7,5fps indique une redondance déjà
faible , rendant 116/1 certainement bien difficile à réaliser.
Ce qui , à contrario, autorise à émettre quelques doutes sur les performances de Sorenson des lors
Texte © Yannick Chalony
14
que Apple ne l'utilise déjà pas , et de beaucoup, à des taux aussi élevés sur ses demos Live en
40kbps+ (Bloomberg) ; soit déjà un minimum de 32 ou 34kbps attribué à la piste video ; ce qui ,
dans le cas de Bloomberg , recemment redescendu de QCIF 176><144 à 160><120, correspond à
:
160><120><16bits><7,5fps, divisé par 34kbps = 67/1 , soit un taux de compression nettement
moindre que RealG2 / 26kbps (en ayant gardé en plus 16 bits au lieu de 9 comme base espace
YUV, pour faciliter la comparaison.)
De meme on peut aussi faire valoir que , pour les trailers Hollywoodiens, Sorenson bénéficie
d'une 'redondance' entre images de (cinéma) 24/8fps , alors que les flux live RealG2 exploitent
une redondance ,inferieure, classiquement un format video (ntsc) 30/7,5fps ; bref une pertinence
entre images de 1/3 dans le premier cas contre 1/4 dans le second ; ce qui désavantage
normalement la gestion du mouvement .
Voyons ensuite de plus pres les variations de bit rate produites par le VBR de Sorenson : si l'on
analyse le flux du movie Red Thin Line on trouve un data rate moyen de l'ordre de 17Ko/s
(environ 140kbps) ; mais il s'agit là du calcul moyen sur la durée totale du movie , ce qui
n'informe en rien sur les périodes de haut bit rate , notamment leurs durées réelles; car peu
importe qu'une periode statique donc de bas bit rate viendra(it) retablir une moyenne abstraite ,
des lors que la durée d'une periode de pic sera(it) superieure à l'overhead client/serveur, qui sur
un flux Live (et non Video On Demand) ne depasse pas classiquement 5 à 10 secondes ; hors
dans Red Thin Line nous observons (MovieAnalyser) des durées de haut bit rate (25 a 40Ko/s)
approchant parfois 5 secondes ou plus , ce qui pourra compromettre un tel movie en flux Live.
Pour revenir sur les choix de diffusion proposés par les broadcasters du net , certains anticipent
nettement le futur US proche (?) ; tel CNN qui ne propose plus que 2 flux : 20 et ...80kbps !! ; on
peut raisonnablemement penser que CNN a les pieds sur terre s'agissant d'internet ; et que donc
notre bon Operateur hexagonal telecom devrait s'activer quelque peu au lieu de presser le citron
doux; surtout que autre ironie , l'ADSL aux US s'opere principalement sous la houlette Alcatel !
nul n'est prophete , etc...
Quelques mots sur MS Mpeg4-V3, qui semble toucher les dividendes de sa participation au
comité Mpeg4 , avec notamment l'héritage des plus récents travaux en matiere de motion
compensation et motion estimation, ce qui explique tres probablement la qualité de la gestion du
mouvement et la fluidité supérieure des images . Là ou Sorenson reste conforme à un modele
frame differencing tel Cinepak ...
Enfin nous analyserons , en fin d'article, dans la partie consacrée à la technologie serveur Apple ,
le tres interessant comparatif possible entre la qualité des images du show Steve Jobs à la
WWDC 99 ; celles ci étant disponibles en QT4 / Sorenson chez Apple et en RealG2 chez
ZDTV ;
Toutes ces observations qualitatives 'en ligne' ont été ensuite (re)vérifiées en local, lors de la
compression de divers movies avec les outils d'encodage disponibles pour chaque solution (avec
Real G2 en Mac/PC et Windows Media Encoder seulement sur PC)
Un mot technique final sur ces trois codecs : Sorenson a été longuement décrit en premiere partie
; pour RealVideo (c'est a dire anciennement ClearVideo de Iterated) on peut se reporter sur le
Pfeifferreport à un précédent article consacré au Mpeg4 , qui aborde Iterated et les fractales.
Reste l'interrogation sur le "Mpeg4-V3" de MS ; certains y voient un H263 amélioré selon les
travaux Mpeg4 donc ; on peut tout aussi bien noter que l'image , apres fort agrandissement,
évoque du wavelet au vu de zones de 'flou' et des artefacts de contour des formes; rappelons que
MS a acquis en 97 tant Vxtreme que VDOlive , tous deux consacrés au wavelet ; en rappelant
aussi que désormais Indeo 5.0 est aussi en wavelet ; pour se faire leur propre idée sur Mpeg4-V3 ,
les plus férus se reporteront aux images depuis NBC Business (MSBNC).
Texte © Yannick Chalony
15
3) Les technologies de Streaming en présence:
Abordons maintenant le point à faire sur les technologies streaming utilisées de chacun
(composants, protocoles, serveurs,..) ; celles qui nous permettent aujourd'hui de voir/entendre de
la video 'vignette' et de la radio quasi FM via un simple modem 56k, ce qui reste une
performance technique tres remarquable ; à nouveau les memes 3 protagonistes...
Real G2 SureStream :
la préséance ira cette fois à RealNetworks apparu bon premier des 1995 avec Realaudio ; ce tout
premier codec concocté par une équipe proche du Dolby AC3 semble etre , à l'époque , un
simple ADPCM amélioré (un procédé de compression reposant sur l'encodage de la seule
différence avec l'échantillon précédent ; une sorte de frame differencing pour de l'audio) ; les
performances étaient inédites (enfin du Live!) mais pas encore spectaculaires quant à la qualité;
par contre RealAudio se distinguait par un tres astucieux systeme de 'packeting' sur un protocole
UDP , plus rapide ('expeditif') que TCP .
RealAudio divisait chaque tranche d'environ 3 secondes en 144 échantillons de 20 millisecondes ;
lesquels sont ensuite réassemblés en 12 paquets comprenant 12 echantillons; l'astuce consiste là à
mettre dans le paquet n&deg;1 tous les echantillons d'ordre 1 donc séparés de 240 millisecondes ;
soit linéairement les echantillons 1,13,25, etc..; puis dans le paquet n&deg;2 tous les echantillons
d'ordre 2 soit les n&deg; 2,14,26, etc..; ainsi de suite ; des lors la perte du paquet N ne signifie
plus la perte de 240 millisecondes ce qui s'entend nettement mais plus subtilement de 20
millisecondes tous les 1/4 de seconde durant donc 3 secondes ; ce que en plus un algo de
correction peut rattraper.
Par la suite en 97, Real a recupéré l'exceptionnel codec Iterated ClearVideo (fractales) capables
de performances toujours inégalées dans les tres bas bit rate; RealSystems en a poursuivi le
developpement, tant en qualité qu'en rapidité d'encodage (le probleme initial) , au point que ,
avec Real G2 , notre G3/300 encode un movie QCIF 176><144 et 7,5fps en temps réel sans
probleme; au moins sur un format source yuv . Pour comparaison , et de memoire , Sorenson 2.0
etait au minimum 5 fois plus lent, pour aussi une qualité d'image moindre ; et MS Mpeg4-V3
facilement temps réel comme RealG2
En 98, avec G2 et SureStream , RealSystems incorpore une nouvelle technologie issue de Intel
(Intel Streaming Web Video Technology) ; peut etre les retombées des travaux Intel autour des
solutions de visiophonie ProShare , adaptées à des conditions reseaux souvent tres aléatoires .
SureStream consiste à multiplexer , dans un seul fichier, plusieurs versions , de bit rate différent,
d'un meme movie . Ensuite un mécanisme client/serveur sophistiqué détecte les changements de
bande passante selon un protocole de 'regles' (ASM = Adaptive Stream Management) ; allouant
des propriétés telles que 'prioritaires' ou 'flux moyen' à des groupes de packets; ainsi en cas de
rebuffering le RealServer sait déterminer une priorité entre les packets ; en mode avancé , chaque
'regle' ASM possede une expression pour s'adapter à une condition ; par ex. si l'analyse du client
détermine une bande passante entre 5 et 15kbps et un packet loss (pertes de paquets) de moins
de 2% , alors le client souscrit à la condition .
Par suite , le changement dynamique de stream s'opere selon la bande passante constatée ou le
packet loss ; le probleme devenant de savoir établir une balance raisonnable dans les changements
dynamiques : un systeme trop 'sensible' provoquera trop de changements ce qui occasionne à
chaque fois une latence de renegociation / rebuffering , un systeme pas assez sensible acceptera
Texte © Yannick Chalony
16
trop de packets perdus .
Par comparaison , dans RealVideo 5.0, il y avait une négociation initiale de bande passante mais
pas de changement dynamique ensuite . De meme l'adaptation aux conditions en ligne , en cas de
packet loss , consistait à abandonner les inter-frames au profit des seules key frames voire
seulement préserver l'audio , plutot que de changer de catégorie de flux .
un mot sur la fonction UpSampling de G2 qui consiste à créer des frames interpolées pour
améliorer la lecture de movies en tres bas frame rate ; il faudrait pouvoir disposer de demos pour
en juger; à ce stade cela reste un acronyme de plus.
Par contre , s'agissant de Real G2 SureStream , nous avons pu constater en récuperant ou créant
des fichiers 'multi-flux' G2 que lorsque on les joue en local depuis le disque , avec pourtant un
player G2 bien sur, c'est toujours le flux le plus bas qui est délivré ! la meme chose se produit
aussi , mais en ligne , lorsque l'on accede à un fichier G2 via un RealPlayer 5.0 (déjà si conçu
backward compatible ..).
pour clore avec l'audio RealG2 , meme s'il progresse sensiblement par rapport a Real5.0 , on
constate désormais que , dans les tres bas bit rate --stereo entre 20 et 40kbps , des solutions
récentes telles QDesign , MS Audio 4.0 , Sound VQ , sont désormais meilleures à bit rate égal ;
reste quand meme le tres efficace protocole serveur RealAudio, tres solide dans l'adversité
d'internet ;
Il va falloir attendre le parti que va savoir tirer RealSystems de l'acquisition de Xing tech qui
possede un encodeur audio .mp3 de type VBR , probablement apte à resserer les écarts ; et
surtout .mp3 est déjà un standard de distribution ; il lui reste à devenir un standard de diffusion ,
notamment contre l'offensive MS Audio 4.0
Windows Media Technology :
la technologie streaming Windows Media propose des concepts et solutions tres similaires à Real
SureStream G2 ; on retrouve ainsi peu ou prou un descriptif de fonctionnalités identiques ; seuls
les acronymes sembleraient devoir changer .
s'agissant donc des apparences , SureStream devient Intelligent Streaming , certes avec 5 flux
multiplexés là ou Real G2 en prévoit 6 ...; l'ASM (Adaptive Streaming Management) de Real
G2 devient Intelligent Transmission ; bref tout semble quasi identique ! hors que l'Intelligent
Transmission ne semble pas fonctionner , tel que prévu sur le papier, malgré de nombreux éssais
pour le provoquer ; ainsi là ou RealG2 SureStream alterne (trop..) régulierement entre 15, 20 , 34
et 60kbps sur notre acces Numeris , nous n'avons rien obtenu de tel avec l'ASM de Windows
media , où lors de baisses du reseau , MediaPlayer se contentait d'attendre et passé un laps de
temps d'inactivité de simplement ..planter la connexion ; nous n'avons jamais constaté de
renégociation(s) dynamique(s) entre divers flux ;
ce constat ayant été fait sur plusieurs sites, cela leve l'hypothese d'un serveur isolé éventuellement
encore avec des media au format Netshow 3.0 , c'est à dire sans le Multi-Bit Rate Streams de
Windows Media 4.0 ; lequel consiste , tout comme RealG2, à créer directement , en production,
un seul fichier multiplexant divers bit rate possibles , ce qui autorise normalement de passer
dynamiquement et souplement d'un flux à l'autre , tel que nous l'avons décrit pour RealG2 ; un
tel systeme est quand meme sensiblement différent du principe de 'n' fichiers de bit rate
différents , dont l'un d'entre eux est envoyé préférentiellement selon un paramétrage préalable du
player ; et en cas de difficulté , on descend au flux inférieur , avec d'éventuelles tentatives de
revenir 'plus tard' au flux présélectionné ;
Texte © Yannick Chalony
17
hors force est de constater que si éffectivement Windows Media dispose bien d'un encodeur de
type Multi Bit-Rate Stream , il n'est pas pour autant évident que ensuite cela corresponde
(actuellement au moins) exactement à la meme chose que RealG2 SureStream ; en clair il nous a
nettement semblé que la technologie Windows Media , et notamment donc le fichier multi-rate
créé n'était actuellement pas utilisé dynamiquement , alors que RealG2 SureStream assure tres
visiblement un monitoring constant de la connexion et use bien de tous les flux disponibles ; il en
use meme peut etre trop 'souplement' .
Ceci étant nos connexions vers les serveurs ASF Windows se sont déroulées généralement tres
bien , avec d'étonnantes périodes de stabilité , de facilement 20 minutes d'affilée , meme en
34kbps ; de ce point de vue , en comparaison , les connexions vers un serveur Real ont souvent
été plus tourmentées, moins stables , avec de nombreux changements de flux ;
Pour revenir aux similarités de l'Intelligent Transmission avec RealG2 SureStream , il s'agit pour
la partie 'statique' de l'adaptation (celle ne concernant donc pas le changement de flux) d'abord
de la baisse de l'envoi des inter-frames video sans toucher au flux audio, jusqu'à ne transmettre
que les keys frames , voire geler momentanement la video ; bien sur le player dispose aussi de
protocoles de corrections aptes à récupérer la qualité d'un flux auquel manque quelques packets .
Tout ceci nous amene à conclure pour Windows Media Technology avec le coeur du systeme :
ASF pour Active Streaming Format ; qui est selon MS un standard ouvert (.) pour gérer la
structure des fichiers , les protocoles de transmission, et le canevas de composition de media en
streaming . A ce titre, ASF se veut un format extensible de conteneur plutot qu'un standard
régissant les divers formats dans le conteneur ; ainsi ASF est 'ignorant' des formats media (Mpeg,
etc..) , des protocoles de transmission (HTTP, RTP,..) , du format de composition (DHTML,
Mpeg4, ..)
Quelques caracteristiques de ASF : ce n'est donc pas un format de 'montage' en tant que tel mais
de 'présentation' des media ; des Objets media peuvent etre definis et partager une timeline pour
etre synchronisés ; s'agissant de la transmission, ASF peut s'adapter tres souplement ; ainsi un
flux ASF peut etre repacketisé vers un reseau RTP, chaque header de data ASF étant converti en
un flux de packets correspondant au reseau RTP ; ASF n'est pas non plus un format de
composition , ce qui le rend ainsi tres libre face aux nombreux types media liés à chaque format
de composition (DHTML, Mpeg4, SMIL, ..) ;
C'est avec ce tres beau faux-nez que ASF avait brigué début 98 l'aval du comité Mpeg4 ; too bad
(.) ; se proposant meme à l'époque à tout 'encapsuler' dans ASF : RTTP, Mpeg4, MBone
Sessions ...
QT4 Streaming :
le premier atout de Quicktime et qui se maintient avec QT4 , meme pour le streaming, est d'etre
accessible à toute appli compatible QT ; c'est à dire beaucoup ! l'interet de QT Player étant de
désormais pouvoir ouvrir des URL directement et bien sur d'offrir des fonctions avancées , ce que
ne possede pas une simple appli QT .
L'autre caractéristique de QT4 Streaming est l'extreme rapidité d'intervenir "à la volée" dans un
flux de Video On Demand , avec des temps de Negociation, Buffering , tres sensiblement plus
courts que via RealG2 , qui en est désormais franchement pénible de lenteur ; c'est un point
TRES agréable de QT4 Streaming ; MS WMT4.0 étant entre les deux .
Classiquement QT Streaming adresse les trois cas de figure du 'broadcast' sur internet : l'unicast
dans lequel le serveur assure un lien personnel avec chaque client , ce qui consomme le max. de
bande passante internet...; ensuite le multicast , et là le serveur principal envoit le flux vers une
Texte © Yannick Chalony
18
arborescence d'adresses de groupes relais sans pour autant verifier si il y a 'quelqu'un à l'ecoute' ;
mais déjà il n'y plus l'envoi d'un flux pour chaque client depuis le serveur principal ; grosse
économie de bande passante etde ressources serveur ; enfin le reflected multicast fait la meme
chose mais en s'abstenant lorsqu'il n'y a personne 'à l'ecoute' à l'adresse relais ; ce schéma de
fonctionnement s'appuie souvent sur des (infra)structures spécialisées existantes tel MBone
(Multicast Backbone) veritables diffuseurs temps réel à l'echelle planétaire ; enfin de taille
modeste quand meme ; à notre connaissance l'état de l'art actuel étant au max de 100 000 flux
simultanés ; mais c'est certes un business en pleine explosion que la mise en place de 'myriade
satellitaires' va conduire à maturité .
avec QT4 streaming , le fait marquant ce sont les Hint Tracks qui assurent éssentiellement
l'analyse et la conversion du contenu en packets pour serveur RTP ; ce sont des infos statiques
(protocoles) ou dynamiques (taille packets) ; au final le fichier client créé ne contient que des
infos serveurs mais plus de data ; si on le relance , il réappelle le serveur pour jouer le movie.
Chaque Hint Track créée est spécifique à des types media , un protocole d'acheminement , à des
tailles de packets; le serveur utilise les infos Hint tracks pour créer un jeu de flux RTP , sans avoir
à connaitre du format des data ; on le voit , tout cela est tres similaire à l'ASF de MS décrit
précédemment.
Hormis le protocole RTP (un acheminement 'just in time ' en somme), QT4 délivre aussi sous
HTTP (via le serveur Web donc) qui ne s'occupe pas de timing d'acheminement ; mais là , le
streaming ne semble plus etre possible à la différence de RealVideo , qui permet ainsi à bon
nombre de petits sites , ou sites perso, de mettre de la video streaming sans se soucier si l'ISP
hébergeur (fournisseur d'acces) dispose d'un soft serveur spécialisé ; si cela se verifie c'est , à notre
sens , un point (temporairement) négatif pour QT4 Streaming ; car ne reste pour ces
broadcasters occasionnels que l'ancien systeme de pseudo streaming de QT (le Fast Start) .
Enfin à la différence de SureStream et autre MultiRate plus Intelligent Transmision , qui
assurent une 'dégradation intelligente' du signal transmis en cas de difficulté réseau , QT4 ne
dispose de rien de ce niveau , à ce jour ; Ainsi en visionnant la video de Steve Jobs au WWDC
sur ZDTV , le flux SureStream RealG2 variait tres souvent entre 20/34/60kbps ce qui atteste
bien du monitoring réel de la connexion et d'un multi bit rate éffectif , pas seulement sur le
papier comme Windows Media, ou dans les limbes comme QT4...
Avec QT4 on retrouve le systeme déjà présent depuis QT3 des 'alternate movies' , qui consiste
pour le serveur à envoyer un movie de flux data déterminé selon des reglages dans le TdB
Quicktime ; déjà cela nécéssite ,en production, de créer plusieurs versions d'un meme movie sans
offrir les possiblités dynamiques liées au multiplexage de plusieurs flux en un seul fichier ; bref ça
fait désormais quelque peu dépassé par rapport au fichier Multi Bit Rate unique et variable
dynamiquement de RealG2 et MS WMT 4.0 (avec les réserves évoquées concernant ce dernier) ;
certes QT4 nous annonce un monitoring de la connexion pour éventuellement renégocier l'envoi
d'un autre flux (autre fichier donc) , ce qui est précisement un systeme lourd et abandonné par
RealG2 et MS ! de plus nous n'avons jamais pu constater la réalité de cette fonction de
monitoring ....; ce qui nous amene à commenter les videos de la WWDC 99 :
Apres avoir éssuyé quelques platres (perte d'un site Reflector) lors de la transmission LIVE de
Steve Jobs à la WWDC99 , le site Apple propose désormais l'intégralité de la conference en
VOD apres avoir curieusement laissé ce soin ,pendant une semaine, à ZDTV ; peut etre le temps
d'optimiser la compression des divers flux proposés ; nous n'en avons éssayé que 3 : "double
ISDN " soit 80kbps moyen effectif , "modem 56k" soit 40kbps moyen ; enfin "modem 33,6" soit
28kbps moyen effectif.
le choix du flux se fait selon le principe des Alternate Movie de QT ; technologie quelque peu
rigide et obsolete , qui consiste à parametrer --préalablement , le TdB Quicktime Settings pour
UN flux et...un seul ; de fait si l'on arretait la transmission du movie (movie fermé) , que l'on
Texte © Yannick Chalony
19
changait de flux dans le TdB Quicktime Settings, que l'on relançait le serveur pour donc une
rediffusion totale et non pas pour reprendre dans le cours du movie ...ça plantait quand meme ;
de meme à aucun moment il n'y a eu de changement dynamique d'un flux a un autre quand bien
meme la connexion était manifestement désadaptée ; ainsi notre acces Numeris 64k ne suffisait
maifestement pas à 'suivre' le flux 80kbps , et pourtant malgré le packets loss évident , le serveur
n'a rien fait ; pire il privilégiait le flux video en arretant l'audio ; pas tres smart tout cela...; ceci
étant la qualité des images 240><180 du flux 80kbps est remarquable , exceptés à nouveau les
artefacts liés au mouvement dans l'image , bete noire de Sorenson (cf: le pano sur le gagnant du
tirage, parfaitement irregardable) ; à voir donc absolument meme si vous allez rater quelques
images ; car au moins le frame droping (abandon de frames) fonctionne.
Nous avons ensuite regardé le flux 40kbps , du 160><120, qui marchait plutot tres correctement ;
mais 40kbps reste bien élévé pour un modem56k ; par contre via Numeris 64k, pas de probleme
particulier ; en regardant le frame rate dans le Get Info de la piste streaming , nous constations
un frame rate quand meme plutot irrégulier , entre 1fps et 7fps , fluctuations que l'oeuil
confirmait du reste ; ceci sans explication particuliere des lors que l'onglet Bit Rate indiquait un
flux variable (VBR) entre 25/30 et 43/45kbps , donc totalement dans les possibilités de notre
connexion Numeris 64k.
Enfin nous avons regardé le flux 28kbps (modem 33,6) ce qui est là encore bien limite pour un
modem 33,6 ; là aussi 160><120; certes le VBR de Sorenson fait que le flux oscille entre 20 et
35kbps , tel que l'on peut le verifier comme précedemment , mais il ya fort à parier qu'un modem
33,6 va rater des frames; mais là Sorenson n'a plus trop d'autre alternative que de miser sur le
maximum maximorum d'un modem 33,6 (environ 28kbps effectif) ; de fait , là encore, pour des
raisons peu explicables , vu notre acces Numeris loin d'etre saturé comme l'indiquait le tableau de
controle du POD Sagem, le frame rate etait pourtant tres irregulier ; ce qui reste plus un mystere
que le constat de la baisse assez nette de la qualité des images , avec aussi des artefacts liés au
mouvement ;
Nous avons alors voulu comparer avec les memes images mais en RealG2 depuis ZDTV; RealG2
nous a envoyé un flux SureStream nominal de 34kbps et franchement : "il n'y a pas photo" ;
image de meilleure qualité , et fluidité bien meilleure ; ce qui confirme le bien severe drop frame
constaté sous Sorenson ; par contre tres probablement ZDTV n'assure pas une meme qualité de
tuyau que Apple , dont Steve Jobs , soi meme, a mentionné le recours à des 'huge pipes' pour la
promotion des demo QT4 streaming ; bref comme (trop) souvent avec des transmissions RealG2
, on constate des "net congestion, rebuffering" quelque peu agaçants par leur fréquence.
Au final , on peut légitimement s'interroger sur le succes de la formule actuelle des solutions et
outils de QT streaming (ce qui n'est apres tout qu'un aspect de Quicktime) hors la sphere des
aficionados de Apple ....(votre serviteur !) ; toutefois cela devrait vite évoluer , Apple ne fait que
combler un loooong retard sur les streaming media; mais un échec serait lourd de conséquences
pour Quicktime dans sa totalité .
Conclusion:
"à suivre" bien sur ; au jour le jour, comme tout sur internet ; en espérant que Sorenson fera tres
bientot fonctionner son codec aussi bien à 25kbps qu'à 25Ko/s ; à défaut un boulevard va s'ouvrir
devant MS WMT 4.0 , technologie performante , déjà en route pour rattraper sous peu la
domination de RealSystems ; souvenons nous de Netscape versus IE ...
et puis il y a Mpeg-4 (voir article Nov98) qui pourrait tres bien seduire les futurs gros
Broadcasters du net que l'on voit finalement mal s'en remettre à des technologies propriétaires .
Yannick Chalony 19/05/99 e-mail [email protected]
Texte © Yannick Chalony
20