En vrac, ce qui me vient en tête :
- Keyframes pas trop espacées. La performance du format doit se mesurer à Keyframes égales.
- un header qui contient la position des keyframes (OGG? pas dans la définition initiale, je crois qu'ils ont ajouté cet index dernièrement)
- une complexité faible (on vire tout ce qui n'est pas supporté par les lecteurs habituels. Les vidéos actuellement diffusées sont basées sur H.264 version 2003, pas sur les dernières versions, donc à une époque ou Theora n'existait pas encore... Et on vire tout ce qui est consommateur de CPU genre CABAC ou CAVLC)
- Pour demain : Scalabilité, afin de ne pas stocker le fichier 10 fois (qu'est-ce que la scalabilité? Le flux est encodé en basse résolution, et il y a plusieurs flux annexes qui augmentent au fur et à mesure la qualité le tout dans le même fichier, le logiciel qui envoie le flux supprime alors les flux annexes trop gros en temps réel, suivant les modifications de débit du client. Je n'ai encore rien vu chez Theora qui permette de faire ça). An niveau gestion de contenu, on parle actuellement beaucoup de scalabilité, pour répondre au besoin de diffusion allant du petit smartphone en 640*360 au PC en 1920*1080 dans le même fichier.
- Optionelement pour après-demain (aujourd'hui dans tout cinéma qui ne veut pas perdre de clientèle, après-demain sur le web quand vous voudrez visionner une bande-annonce de film) : un évolutivité vers la 3D. Aujourd'hui, les fabriquants choisissent leur format de prédilection pour diffuser sur le web de la 3D, demain le choix sera fait et il sera difficile de changer, trop cher de tout redévelopper. Ne pas oublier qu'il y des années entre la définition du format et sa diffusion généralisé (il y a 1 an, pas un film au cinéma en 3D, aujourd'hui on en voit beaucoup, vous croyez que le choix technologique a été fait hier? C'est la même chose pour le web... Apple, Google, ou Microsoft regardent à long terme le potentiel d'évolution d'un format avant de choisir)
Sans compter qu'il ne faut pas oublier ces aspects :
- Polyvalent. Le même format doit pouvoir être utilisé pour de la diffusion temps réel, du stockage etc... Afin de ne pas développer une autre chaine de compression (ça coûte) avec la convergence des médias.
- Besoin de logiciels d'analyse (si vous me trouvez des analyseurs Theora...) pour débugger les flux qui viennent de différents fabriquant et dont un ne marche pas par exemple.
- Important pour la diffusion du format : un support matériel si possible, décodage et encodage (la, c'est mort pour Theora, je ne connais aucun matériel proposant du décodage Theora en hard, alors que tous les smartphones et beaucoup de PC de bureau ont le décodage H.264 en hard), important pour ne pas tuer les batterie de tout ce qui est mobile.
- Et toujours : le taux de compression à un débit donné et une complexité donnée.
Ne te méprend pas : j'aimerai bien me débarrasser de ces brevets, et je choisirai volontiers un format libre à conseiller si ce format remplissait le cahier des charges nécessaire à un format de diffusion polyvalent sur le web (et son futur) et ailleurs (convergence des médias). Avec Theora, on a juste un container (contre 3 officiels + plein de non officiels pour l'AVC, suivant le besoin), un profile de complexité (contre 12 pour AVC, avec un 13ème qui est en discussion dans les réunions MPEG) qui est loin de remplir le cahier des charges de ceux qui décident, malheureusement. Et aujourd'hui, personne n'est motivé pour mettre un Euro dans Theora (ce que je comprend, vu le résultat de l'aventure Vorbis).
Donc au final, je trouve que c'est un peu trop facile de critiquer Google de ne pas filer de sous à Xiph : peut-être que Google estime qu'il est inutile de mettre de l'argent dans un truc qui va être bientôt oublié, c'est tout, et ça n'a rien à voir avec le "méchant" Google qu'on veut monter en épingle en ce moment dès qu'il ne fait pas ce que la "communauté" (et ça dépend vraiment laquelle, vu la communauté du libre derrière H.264...) souhaite.
[^] # Re: absence révélatrice: Xiph.org
Posté par Zenitram (site web personnel) . En réponse au journal Google Summer of Code 2010. Évalué à 5.
En vrac, ce qui me vient en tête :
- Keyframes pas trop espacées. La performance du format doit se mesurer à Keyframes égales.
- un header qui contient la position des keyframes (OGG? pas dans la définition initiale, je crois qu'ils ont ajouté cet index dernièrement)
- une complexité faible (on vire tout ce qui n'est pas supporté par les lecteurs habituels. Les vidéos actuellement diffusées sont basées sur H.264 version 2003, pas sur les dernières versions, donc à une époque ou Theora n'existait pas encore... Et on vire tout ce qui est consommateur de CPU genre CABAC ou CAVLC)
- Pour demain : Scalabilité, afin de ne pas stocker le fichier 10 fois (qu'est-ce que la scalabilité? Le flux est encodé en basse résolution, et il y a plusieurs flux annexes qui augmentent au fur et à mesure la qualité le tout dans le même fichier, le logiciel qui envoie le flux supprime alors les flux annexes trop gros en temps réel, suivant les modifications de débit du client. Je n'ai encore rien vu chez Theora qui permette de faire ça). An niveau gestion de contenu, on parle actuellement beaucoup de scalabilité, pour répondre au besoin de diffusion allant du petit smartphone en 640*360 au PC en 1920*1080 dans le même fichier.
- Optionelement pour après-demain (aujourd'hui dans tout cinéma qui ne veut pas perdre de clientèle, après-demain sur le web quand vous voudrez visionner une bande-annonce de film) : un évolutivité vers la 3D. Aujourd'hui, les fabriquants choisissent leur format de prédilection pour diffuser sur le web de la 3D, demain le choix sera fait et il sera difficile de changer, trop cher de tout redévelopper. Ne pas oublier qu'il y des années entre la définition du format et sa diffusion généralisé (il y a 1 an, pas un film au cinéma en 3D, aujourd'hui on en voit beaucoup, vous croyez que le choix technologique a été fait hier? C'est la même chose pour le web... Apple, Google, ou Microsoft regardent à long terme le potentiel d'évolution d'un format avant de choisir)
Sans compter qu'il ne faut pas oublier ces aspects :
- Polyvalent. Le même format doit pouvoir être utilisé pour de la diffusion temps réel, du stockage etc... Afin de ne pas développer une autre chaine de compression (ça coûte) avec la convergence des médias.
- Besoin de logiciels d'analyse (si vous me trouvez des analyseurs Theora...) pour débugger les flux qui viennent de différents fabriquant et dont un ne marche pas par exemple.
- Important pour la diffusion du format : un support matériel si possible, décodage et encodage (la, c'est mort pour Theora, je ne connais aucun matériel proposant du décodage Theora en hard, alors que tous les smartphones et beaucoup de PC de bureau ont le décodage H.264 en hard), important pour ne pas tuer les batterie de tout ce qui est mobile.
- Et toujours : le taux de compression à un débit donné et une complexité donnée.
Ne te méprend pas : j'aimerai bien me débarrasser de ces brevets, et je choisirai volontiers un format libre à conseiller si ce format remplissait le cahier des charges nécessaire à un format de diffusion polyvalent sur le web (et son futur) et ailleurs (convergence des médias). Avec Theora, on a juste un container (contre 3 officiels + plein de non officiels pour l'AVC, suivant le besoin), un profile de complexité (contre 12 pour AVC, avec un 13ème qui est en discussion dans les réunions MPEG) qui est loin de remplir le cahier des charges de ceux qui décident, malheureusement. Et aujourd'hui, personne n'est motivé pour mettre un Euro dans Theora (ce que je comprend, vu le résultat de l'aventure Vorbis).
Donc au final, je trouve que c'est un peu trop facile de critiquer Google de ne pas filer de sous à Xiph : peut-être que Google estime qu'il est inutile de mettre de l'argent dans un truc qui va être bientôt oublié, c'est tout, et ça n'a rien à voir avec le "méchant" Google qu'on veut monter en épingle en ce moment dès qu'il ne fait pas ce que la "communauté" (et ça dépend vraiment laquelle, vu la communauté du libre derrière H.264...) souhaite.