- 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.
Oui mais non :P
1°) les flux annexes ne sont pas forcément des augmentations en qualité mais aussi temporelles (plus de frames intermédiaires. Le h.264 "classique" supporte déjà cela, avec les frames B hierarchiques), et/ou spatiales (résolution plus grande).
2°) 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.
A noter, lorsque il y a une trop grande différence entre la "base layer" et la couche comportant l'ensemble des augmentations de qualité, alors tu as une perte en qualité globale.
3°) Je n'ai encore rien vu chez Theora qui permette de faire ça, bien que mpeg2 comportait déjà une base de scalabilité, l'annexe G de h264 qui traite de la scalabilité (SVC) n'est sorti en final qu'en septembre 2008 si ma mémoire est bonne.
Ok theora ne permet pas de le faire, mais est ce déjà utilisé ? Qui veut l'utiliser (je peux te citer au moins un nom de la télphonie/fai qui a dis "svc on l'utilisera pas" au niveau de ses équipes de recherches) (je peux aussi te citer des industrielles qui disent "ouais c'est génial" mais qui trainent des pieds quand il s'agit de bosser dessus). ?
4°) un flux svc, a qualité et résolution égale, demande ~10% de cpu en plus (dixit les industriels qui bossaient sur un projet comportant du SVC).
5°) , 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
Ca c'est la théorie. Maintenant la grande question, tu le fait comment dans un flux TS ?
Comment tu fais si ta base layer est corrompue ?
L'utilisation de SVC demande une architecture à séparation des flux et à remontée de métrique (ok si on dis RTP/RTCP, mais il faut demander des rapports RTCP plus complets, des rapports RTCP sur du multicast pour l'abonnement/désabonnement, et enfin de l'aggrégation de rapport RTCP pour que l'on se désabonne du flux au bon endroit, et ni trop haut, ni trop bas) , et une protection des flux suivant leur priorité (et ensuite quel est la priorité de deux flux additionnels : celui qui augmente le nombre de trames ? la résolution ? la qualité ? Utilisations des codes "raptor" pour la base layer ? http://en.wikipedia.org/wiki/Raptor_FEC_Technology )
Une vidéo de 10 fps, même en 1920x1080p ca ne sera pas agréable. une vidéo de 60 fps en 320x480 idem) -> réussir à faire une métrique vidéo objective des flux individuels*, à partir de métriques réseaux (tiens tiens tiens ca me rappelle qqch ça XD ), sur des flux aussi différents que du QCIF ou du 1080p, c'est aussi un des gros défis du SVC (et si tu en as une ca m'interesse.)
*ah ben oui, de façon statistiques (sur un ensemble de flux), la littérature en a déjà (au moins un).
6°) il n'y a (en tout cas il y a 1.5 ans, le moment ou j'ai arrêté de travaillé sur le SVC), pour le SVC, aucun décodeur optimisé au même niveau que le h264 de ffmpeg ou coreavc ou ...
Bref, le SVC est certes intéressant, mais vu la pénétration de cette technologie, pour l'instant je ne l'utiliserais pas pour comparer.
Qui sait que mpeg2 a des extensions de scalabilité ?
Enfin
7°) d'autres alternatives sont utilisées pour juste augmenter "la résolution spatiales" (bof bof) ET assurer une bonne "redondance" des informations, c'est le MDC (Multiple Description Coding) . A noter, le MDC dans sa forme la plus simple peut être adapté à n'importe quel codec (version un peu plus avancée de l'entrelacée).
[^] # Re: absence révélatrice: Xiph.org
Posté par briaeros007 . En réponse au journal Google Summer of Code 2010. Évalué à 2.
Oui mais non :P
1°) les flux annexes ne sont pas forcément des augmentations en qualité mais aussi temporelles (plus de frames intermédiaires. Le h.264 "classique" supporte déjà cela, avec les frames B hierarchiques), et/ou spatiales (résolution plus grande).
2°) 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.
A noter, lorsque il y a une trop grande différence entre la "base layer" et la couche comportant l'ensemble des augmentations de qualité, alors tu as une perte en qualité globale.
3°) Je n'ai encore rien vu chez Theora qui permette de faire ça, bien que mpeg2 comportait déjà une base de scalabilité, l'annexe G de h264 qui traite de la scalabilité (SVC) n'est sorti en final qu'en septembre 2008 si ma mémoire est bonne.
Ok theora ne permet pas de le faire, mais est ce déjà utilisé ? Qui veut l'utiliser (je peux te citer au moins un nom de la télphonie/fai qui a dis "svc on l'utilisera pas" au niveau de ses équipes de recherches) (je peux aussi te citer des industrielles qui disent "ouais c'est génial" mais qui trainent des pieds quand il s'agit de bosser dessus). ?
4°) un flux svc, a qualité et résolution égale, demande ~10% de cpu en plus (dixit les industriels qui bossaient sur un projet comportant du SVC).
5°) , 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
Ca c'est la théorie. Maintenant la grande question, tu le fait comment dans un flux TS ?
Comment tu fais si ta base layer est corrompue ?
L'utilisation de SVC demande une architecture à séparation des flux et à remontée de métrique (ok si on dis RTP/RTCP, mais il faut demander des rapports RTCP plus complets, des rapports RTCP sur du multicast pour l'abonnement/désabonnement, et enfin de l'aggrégation de rapport RTCP pour que l'on se désabonne du flux au bon endroit, et ni trop haut, ni trop bas) , et une protection des flux suivant leur priorité (et ensuite quel est la priorité de deux flux additionnels : celui qui augmente le nombre de trames ? la résolution ? la qualité ? Utilisations des codes "raptor" pour la base layer ? http://en.wikipedia.org/wiki/Raptor_FEC_Technology )
Une vidéo de 10 fps, même en 1920x1080p ca ne sera pas agréable. une vidéo de 60 fps en 320x480 idem) -> réussir à faire une métrique vidéo objective des flux individuels*, à partir de métriques réseaux (tiens tiens tiens ca me rappelle qqch ça XD ), sur des flux aussi différents que du QCIF ou du 1080p, c'est aussi un des gros défis du SVC (et si tu en as une ca m'interesse.)
*ah ben oui, de façon statistiques (sur un ensemble de flux), la littérature en a déjà (au moins un).
6°) il n'y a (en tout cas il y a 1.5 ans, le moment ou j'ai arrêté de travaillé sur le SVC), pour le SVC, aucun décodeur optimisé au même niveau que le h264 de ffmpeg ou coreavc ou ...
Bref, le SVC est certes intéressant, mais vu la pénétration de cette technologie, pour l'instant je ne l'utiliserais pas pour comparer.
Qui sait que mpeg2 a des extensions de scalabilité ?
Enfin
7°) d'autres alternatives sont utilisées pour juste augmenter "la résolution spatiales" (bof bof) ET assurer une bonne "redondance" des informations, c'est le MDC (Multiple Description Coding) . A noter, le MDC dans sa forme la plus simple peut être adapté à n'importe quel codec (version un peu plus avancée de l'entrelacée).