Plus sérieusement, si une version 6 sort, je propose de la doter de capacités supportant l'idée suivante :
(1) Passer en h264 et à 3 mégas bits/seconde les flux TV "standards".
(2) Passer la bufferisation h264 à 10 secondes (soit 15 secondes de temps max entre la sélection d'une chaine et l'affichage de la première image haute résolution ... cf. le raisonnement plus loin). Le son restant bufférisé au minimum (100 millisecondes ?).
Le problème d'une bufférisation accrue est double (sans parler de la mémoire nécessaire) :
- la taille du buffer joue sur la durée moyenne entre le moment ou on zappe et celui de l'affichage de la première image (arrivée d'une Key frame complète). Pendant ce temps, on ne voit rien (mais on pourrait entendre quelque chose).
- on pourrait être tenté d'afficher autre chose (un flux moins bufférisé, de moins bonne qualité) pendant la constitution du buffer en gardant à l'esprit que, pour un stream infini, on ne peut pas s'en sortir sans freezes (à long terme) si on a moins de bande passante que le débit soutenu nécessaire au stream. Comme il est exclu de compter sur une "pointe de bande passante" pendant les premières seconde d'affichage d'une chaine, il faut donc trouver une autre solution ...
(3) Le point (2) forcerait donc le FAI à envoyer un flux image très basse résolution (genre demi QVGA : 240 * 160) des chaines en parallèle avec le flux SD à 3 mégas. Par exemple un flux à disons ... 384 kbps. Ce flux secondaire, reçu uniquement pendant la durée de buffering du flux normal, serait compacté en bufferisation minimale (moins d'une demi seconde). Il permettrait d'avoir "quasi instantanément" une image en cas de zapping. En outre, on pourrait s'en servir pour faire du PIP sur une seconde chaine ... ou pour regarder la TV sur un téléphone portable (dans la zone de couverture des antennes des particuliers !).
Une bufférisation plus longue permet d'améliorer le compactage (faut pas sombrer dans la désynchronisation Son/Image à la I-Concert HD nonplus). Reste à voir si les gens accepteraient d'avoir une image "relativement pourrie" pendant 12 à 15 secondes après un zapping ... avec la contrepartie d'avoir ensuite un flux de qualité maximum pour le débit requis. Peut-être avec une interface visuelle à la Google earth ? ("zoom image" progressif en cas de zapping : on fige l'image et on commence par afficher la nouveau flux au centre (ou à partir du rectangle concerné de la mosaïque), et la vidéo prend petit à petit tout l'écran ?
Le problème générique est (entre autre) de time coder plusieurs flux et de permettre à la freebox (et à vlc ?) de faire "sa pizza" en choisissant les flux son et image de son choix (de façon changeante) : son stereo, son 5.1, video demi QVGA, video SD full, video HD, etc ... (ça marcherait pour les chaines HD aussi)
Lors d'un zapping, la freebox recevrait instantanément le son (stéréo à 128 kbps ou 5.1), le flux dégueulasse (384 kbps) et le début du buffer du flux clean (transmission à vitesse réduite soit à 2.5 mbps en SD, au lieu de 2.9 ... et 4.5 mbps en HD au lieu de 4.9).
Le son et le flux dégueux sont décodés et envoyés vers la TV.
Evidemment, vu que le buffer clean est envoyé moins vite que le débit nominal du stream (qui serait d'un peu moins que 2,9 mbps en SD), ça mettra sans doute un peu plus de 10 seconde pour balancer 10 secondes de buffer. En même temps, il ne faut pas rater le rendez-vous avec le T0 du flux clean affichable. C'est pour ça que le NRA doit disposer de plus de 10 secondes de buffer (et savoir se mettre quelques secondes derrière l'oreille en envoyant un buffer calé "un peu plus dans le futur" que 10 secondes ... disons au minimum 12 à 15 secondes secondes).
Après (10 + X) secondes à ce régime, la freebox (qui n'a pas cessé d'afficher le flux dégueux) dispose d'un buffer complet de 10 secondes d'image. A ce moment là, elle bascule sur le flux clean et se met à recevoir le flux clean sur la totalité de la bande passante video nominale (2,9 mbps).
Pour l'usage en PIP du flux dégradé, on ferait moins de cas de la bande passante maximale utilisée : si t'as le débit pour faire du PIP, on te donne du flux dégueux pour PIP, sinon, t'en reçois pas.
Tout compte fait, ce post (génial quoique hors sujet) laisse poindre une technique générale de vidéo progressive multi-flux.
On commence par envoyer le flux le moins gourmand et/ou le plus réactif et ensuite on passe à un flux plus gourmand (en buffer ou en bande passante) en utilisant une estimation de la bande passante libre (laquelle peut évoluer) et les paramètres relatifs de buffering pour déterminer où dans le futur il faut caler le début d'affichage (T0) du flux relai (évidemment, on ne passe pas à la vitesse supérieure si le rendez-vous est calculé pour dans 15 minutes ...). On peut refaire la pirouette plusieurs fois ... on peut également le faire pour le son ... et ainsi envoyer le meilleur mix en fonction des flux dispos et de l'état de la ligne. En cas de famine (buffer vide), on redescend vers le flux le moins gourmand et on diminue l'estimation de bande passante maxi utilisable.