Google vient d'annoncer les 150 projets retenus pour le Summer of Code 2010:
http://socghop.appspot.com/gsoc/program/accepted_orgs/google(...)
Voila la liste des nouvelles organisations:
http://dev.gentoo.org/~dberkholz/gsoc/new_orgs.txt
et des absentes cette année (à noter des petits projets comme Fedora, PHP ou Subversion)
http://dev.gentoo.org/~dberkholz/gsoc/gone_orgs.txt
Journal Google Summer of Code 2010
19
mar.
2010
# absence révélatrice: Xiph.org
Posté par GeneralZod . Évalué à 10.
Google fait ce qu'il veut de son pognon, mais si c'est le cas, je trouve ça très mesquin vis à vis d'une fondation à but non-lucratif qui cherche à faire avancer les formats multimédias ouverts (mieux encore: libres !).
Ah, j'oubliais ! C'est bel et bien Google qui a refusé la candidature de Xiph.org en tant que mentor, pas la peine de chercher d'autres explications farfelues (genre, ils ont pas candidaté, pas de projets, etc ...)
[^] # Re: absence révélatrice: Xiph.org
Posté par El Titi . Évalué à 4.
Ah, j'oubliais ! C'est bel et bien Google qui a refusé la candidature de Xiph.org en tant que mentor, pas la peine de chercher d'autres explications farfelues (genre, ils ont pas candidaté, pas de projets, etc ...)
J'ai oui dire que Google aurait mis la main sur une boîte qui disposerait d'un codec performant, voire même que quelque assocs libres les encourageaient à le libérer.
Mais j'en conviens, ce ne sont que des supputations farfelues.
[^] # Re: absence révélatrice: Xiph.org
Posté par GeneralZod . Évalué à 4.
> J'ai oui dire que Google aurait mis la main sur une boîte qui disposerait d'un codec performant, voire même que quelque assocs libres les encourageaient à le libérer.
Si tu parles d'On2, la dernière fois qu'ils ont libéré un codec, c'était sous l'égide de Xiph.org ...
Pour le moment, ce qui est certain c'est que Google soutient activement H264 et a refusé Xiph.org comme mentor pour les SoC.
Pour On2, on ne sait pas si ils vont effectivement libéré les codecs ou bien les laisser pourrir dans un tiroir. Ils peuvent très bien avoir racheté la boite pour son portefeuille de brevets ou les compétences internes pour améliorer l'implémentation de H264 par exemple.
D'ordinaire, Google est moins frileux avec la concurrence.
[^] # Re: absence révélatrice: Xiph.org
Posté par Zenitram (site web personnel) . Évalué à 1.
D'ailleurs, je peux lire autant du Theora que du x264 avec Chrome. Ce n'est pas Google qui empêche les autres sites de passer à Theora, un Chrome sachant lire ces vidéos.
Faut arrêter le délire!
- Google met H.264 dans son lecteur car ça lui coûte moins cher que d'encoder tout Youtube en Theora (à cause de la bande passante monstrueuse demandée par Theora par rapport à H.264 pour une qualité donnée). Sans compter les sites webs qui diffusent en H.264 déjà.
- Le seul test "Get the facts" qui met Theora en avant est biaisé (Distance entre les Keyframes énorme, inexploitable pour du streaming où on veut faire des "seek", et ce paramètre change énormément la qualité d'une vidéo).
- Theora n'a jamais montré qu'il pouvait potentiellement arriver à des taux de compression pouvant rivaliser avec H.264.
Google n'est pas contre Theora. Il est contre dépenser plus d'argent pour rien, c'est tout. Qu'on prouve que Theora a une once de chance d'être performant, et ça changera la donne.
Mais dire que Google ne fait rien pour Theora est faux, il le distribue au niveau du client web, il n'empêche personne de dépenser du fric en bande passante pour diffuser une vidéo en Theora.
refusé Xiph.org comme mentor pour les SoC.
Qu'est-ce qui dit que Google a rejeté Xiph parce qu'ils sont "concurrent" (ah ah ah... Google achète une licence H.264, Google ne voit pas Theora comme concurrent! Imagination...)? Ne serait-ce pas parce que les projets imaginés ne sont pas sexy (j'ai regardé la page avec les 2 projets qui étaient proposé, à part montrer que le format OGG, le container, est pas du tout mûr, il n'y a pas grand chose de sexy dedans).
Bref, beaucoup de procès d'intention.
[^] # Re: absence révélatrice: Xiph.org
Posté par GeneralZod . Évalué à 4.
Rien à foutre de Chrome, en revanche Chrome/Chromium utilise FFMpeg pour la lecture des vidéos, FFMpeg qui ne peut pas être librement redistribué partout dans le monde.
Google a refusé la proposition des développeurs GStreamer d'intégrer GStreamer (ne serait qu'optionnellement) dans Chromium. Google préfére que les utilisateurs de distributions libres n'aient pas de vidéo du tout si on ne leur impose pas H264.
> Google met H.264 dans son lecteur car ça lui coûte moins cher que d'encoder tout Youtube en Theora (à cause de la bande passante monstrueuse demandée par Theora par rapport à H.264 pour une qualité donnée).
1. Pour 99% des vidéos sur le web, on ne verra quasiment pas la différence en terme de qualité entre Theora et H264 et sans surcoût en BP. L'argument du coût de la BP ne tient pas debout.
2. Quant au streaming de contenu HD sur lequel H264 se distingue, la plupart des diffuseurs s'orientent vers du p2p justement à cause du coût délirant de la bande passante. C'est ce que fait déjà Veoh. Rien à voir avec la balise video d'HTML5.
3. le coût de la licence h264 est tellement hallucinant que réencoder toutes les vidéos sur youtube reviendrait beaucoup moins cher. Certes, le MPEG a annoncé une trêve temporaire (pour forcer le passage dans HTML5) mais tu crois que les diffuseurs vont arrêter subitement de payer la taxe en question ?
> Theora n'a jamais montré qu'il pouvait potentiellement arriver à des taux de compression pouvant rivaliser avec H.264.
Theora a démontré qu'il pouvait se substituer à H264 dans le cadre de HTML5 et qu'il avait un gros potentiel d'amélioration.
> Ne serait-ce pas parce que les projets imaginés ne sont pas sexy
Pourtant ils ont été acceptés les années précédentes, et subitement pouf ! L'argument des projets pas sexy est risible, parce qu'aucun projet n'a été présenté à Google.
Seule la première étape vient de se terminer, étape où les projets open-source ne font que candidater pour mentorer des étudiants, seul le projet lui-même et la motivation des mentors sont évalués. La seconde étape consistera à recruter les étudiants, puis à peaufiner les projets pour les présenter à Google.
Forcément, si Xiph n'a pas passé la première étape, ils vont pas se casser le cul à travailler les propositions. Ce que t'as vu, c'est quelques suggestions pour les étudiants, vu que les projets finaux doivent être élaborés avec les étudiants depuis hier seulement.
> Bref, beaucoup de procès d'intention.
Je ne fais que ramasser les miettes de pain qu'ils ont laissés tombé.
[^] # Re: absence révélatrice: Xiph.org
Posté par defmonkey . Évalué à 3.
Ben je suis désolé mais informatiquement parlant je les comprends: prendre Gstreamer, c'est aussi prendre toute la glib et tout un tas de trucs dont chromium (et donc chrome) n'a pas besoin. Quand on fait 1 logiciel en langage object (ici le C++), se trainer la Glib et ce truc de GObject, ben ça fait mal ...
Et puis moi j'aime bien ffmpeg ;)
[^] # Re: absence révélatrice: Xiph.org
Posté par GeneralZod . Évalué à 7.
Chromium dépends déjà de Gtk+ et de la Glib sur GNU/Linux ... De plus, la proposition consistait à fournir une option de compilation pour pouvoir utiliser alternativement GStreamer, pas de remplacer FFMpeg. Google pouvait très bien continuer à utiliser FFMpeg et laisser les autres s'amuser avec GStreamer sans problème. Google a fermé le ticket sans discuter.
WebKit offre plusieurs backends (CoreGraphics, Cairo, Gtk+, Qt, Wx, EFL, etc ...), ça ne t'oblige pas à les utiliser tous en même temps ...
> se trainer la Glib et ce truc de GObject, ben ça fait mal
La GLib, c'est une petite lib de rien du tout, c'est même une dépendance de Qt depuis quelques temps. Au passage, la GLib ne dépends pas de GObject (en fait, c'est l'inverse).
> Et puis moi j'aime bien ffmpeg ;)
FFMpeg est un super projet, mais le code n'est pas redistribuable partout dans le monde. De par son architecture modulaire, GStreamer permet de fournir un set de codecs de base librement redistribuable et d'obtenir légalement les autres (soit une implémentation libre, soit les codecs fluendo). Actuellement, sans FFMpeg, pas de balise video sous Chromium.
[^] # Re: absence révélatrice: Xiph.org
Posté par BohwaZ (site web personnel, Mastodon) . Évalué à 3.
« Je vois bien à quels excès peut conduire une démocratie d'opinion débridée, je le vis tous les jours. » (Nicolas Sarkozy)
[^] # Re: absence révélatrice: Xiph.org
Posté par Zenitram (site web personnel) . Évalué à -1.
Si tu es capable d'accepter la qualité Theora à un débit donné, tu es capable d'accepter du H.264 à un débit moindre, donc gain de bande passante, donc gain en argent.
L'argument du coût de la BP ne tient pas debout.
Mais l'intérêt d'un codec video, c'est : la bande passante, la bande passante, et la bande passante. Que ce soit avec Flash, HTML5 ou le P2P.
Sinon, pas besoin de Theora, on reste en RGB brut, c'est suffisant.
Tant que les libristes n'auront pas compris ce qui fait que les diffuseurs choisissent H.264 et pas un autre, c'est le prix de la bande passante (le prix de la licence H.264 n'est rien du tout comparé au prix de la bande passante), il ne risquent pas de réussir à promouvoir un autre format.
[^] # Re: absence révélatrice: Xiph.org
Posté par ribwund . Évalué à 3.
> Bref, beaucoup de procès d'intention.
Je ne fais que ramasser les miettes de pain qu'ils ont laissés tombé.
Plutot que de supputer, vous avez demandé à Leslie ? En général ils donnent du feedback sur les raisons, si vous demandez.
Mais bon j'imagine que c'est comme pour le choix des projets, y'a X slots (150), les gens votent selon plein de critères, et le top 150 passe. Ça veut pas dire que les autres sont mauvais...
[^] # Re: absence révélatrice: Xiph.org
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 3.
Il a surtout été vérifié que la compression utilisée par YouTube est inférieure, à qualité égale, à celle produite par le codec Theora actuel.
[^] # Re: absence révélatrice: Xiph.org
Posté par feth . Évalué à 4.
[^] # Re: absence révélatrice: Xiph.org
Posté par Zenitram (site web personnel) . Évalué à 1.
- Youtube n'utilise pas les dernière techno d'encodage H.264, l'image Youtube est moche par rapport à une vidéo de même débit encodé avec x264 (un des meilleurs encodeurs H.264)
- L'encodage Theora pour comparer a été fait avec des Keyframes toutes les 10 secondes. En gros, c'est ingérable ce genre de truc pour du web, ou la personne va vouloir se balader dans le flux vidéo. Bizarre qu'un mec voulant faire une comparaison de codec "oublie" ce genre de détail qui est la base de la compression vidéo (le choix du nombre de Keyframes est le facteur n°1 de facilité de compression)
- La conclusion du mec était que sa version de Theora était meilleure que la version H.264 de Youtube, ce qui n'avait pas l'air faux.
- Mais vu qu'on sait mieux faire en terme d'encodage H.264, ça couterai moins cher de changer d'encodage H.264 pour exploser la gueule au test plutôt que de changer de format complètement, et en plus si on revenait à des Keyframes toutes les 0.5 secondes (plus classique), on n'ose pas trop imaginer le résultat Theora.
Maintenant, je vous laisse continuer à adorer Theora le magnifique que pas foule n'aime depuis sa sortie (ça fait un moment, et depuis pas beaucoup d'évolution, alors que H.264 continue sa lancée dans en:Scalable_Video_Coding et en:Multiview_Video_Coding, l'un étant spécialement prévu pour le web en s'adaptant au débit du client en temps réel, l'autre en permettant d'avoir des vidéos en 3D qui ne vont pas tarder à arriver sur le web non plus, les écrans s'y mettant actuellement. Ne vous dites pas que c'est irréaliste, je travaille actuellement pour de faire de l'analyse sur ce genre de flux destiné au web... Et Theora, ben il n'a rien du tout à proposer en face, et comme personne n'a envie de se taper 2 codecs en paralele, ben ils choisissent le plus polyvalent et le plus performant.).
Demandez-vous juste pourquoi Theora n'a pas encore percé alors que la vidéo est le moteur de pas mal d'industries à l'heure actuelle...
PS : notez que les logiciels libres qui ont percé n'ont pas percé parce qu'ils étaient libres, mais parce qu'ils répondaient à un besoin que le proprio ne proposait pas (Linux, Firefox...) ou qu'ils étaient moins cher (Ooo...).
[^] # Re: absence révélatrice: Xiph.org
Posté par franckd . Évalué à 5.
Qu' H.264 est une longueur d'avance je veux bien le croire, mais le coté politique n'est certainement pas absent, là tu peux effectivement dire que je fait un procès d'intention:
je suis presque certain qu'à qualité égale c'est quand même le H.264 qui aurait été choisi par Apple, Microsoft et Google (si Youtube=Google sa neutralité est un peu bidon). Ce format à l'énorme avantage de fixer un « ticket d'entrée » permettant aux gros de rester tranquillement entre eux (ou de suspendre une épée de Damoclès au dessus de potentiels concurrents au porte-feuille moins bien fourni.)
Le coté killing feature genre 3D ,ce n'est pas vraiment pour demain, et ne sera pas vraiment un avantage concurrentiel, (puisque tous les acteurs majeurs sont sur le coup) sinon vis à vis de ces bricolo du libre...
[^] # Re: absence révélatrice: Xiph.org
Posté par flagos . Évalué à 7.
Par contre, ce que tu oublies de mentionner systematiquement dans ton argumentaire (bien rode maintenant) c'est que Theora est a la rue non pas a cause des competences des mecs de Xiph.org mais parce que H264 tue la concurrence a coups de brevets et cela fausse totalement la concurrence !
Le probleme qui nous interesse avec H264 n'est pas celui de la performance mais celui de la liberte de pouvoir specifier une norme video sans retomber sur un nieme brevet video a la con.
Alors oui je suis d'accord avec toi, choisir Theora c'est pas la solution ideale pour des questions de performance, mais choisir H264 c'est un choix encore plus mauvais puisqu'il nous enferme dans ces histoires de brevets...
Enfin esperons que google fasse quelque chose d'interessant de son VP8...
[^] # Re: absence révélatrice: Xiph.org
Posté par TImaniac (site web personnel) . Évalué à 0.
Bah oui : H264 ca existe depuis longtemps, les encodeurs hardwares existent, et la plupart des cartes graphiques modernes sont capable de décoder ce flux, déchargeant largement le CPU.
Pour que Theora s'impose, il faudrait qu'il offre une réelle amélioration du rapport qualité/débit pour que les acteurs en place investisse dans du hardware dédié. Actuellement, le prix de la licence étant dérisoire, à qualité égal et au vu du matériel disponible sur le marché, il est totalement illusoire de voir de gros acteurs migrer vers Theora à court terme.
Celà dit oui, brevets c'est mal toussa, mais ce critère, 90% des utilisateurs de H264 s'en tapent le coquillard (évidemment le ratio est inverse ici ;)). Dommage, c'est le seul atout de Theora à l'heure actuelle...
[^] # Re: absence révélatrice: Xiph.org
Posté par zebra3 . Évalué à 2.
Par contre le temps encodage est pareil.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: absence révélatrice: Xiph.org
Posté par 태 (site web personnel) . Évalué à 2.
[^] # Re: absence révélatrice: Xiph.org
Posté par briaeros007 . Évalué à 2.
Pour avoir travailler dans la qualité vidéo a destination de streaming, je peux t'assurer que les paramètres d'encodage utilusé par youtube sont loin d'être excellent pour une optimisation de la qualité par rapport à la bp.
Ils ont d'autres contraintes (utilisation d'encodeur hard qui ne gèrent pas forcément tout, temps limité par vidéo, compatibilité des lecteurs, etc..).
Si tu ne me crois pas , je t'invite à faire le test :
Tu prend une vidéo "original" et tu la met sur youtube (et encore tu auras une meilleur qualité que les premiers enco de youtube).
Tu récupère cette vidéo, et tu notes le bitrate moyen.
Ensuite tu la convertis avec x264, en activant toutes les options de qualité, et en faisant un enco 2 passes, et en utilisant le bitrate moyen de la vidéo youtube.
Tu convertis avec theora, idem.
Tu teste le VQM (ou le psnr si tu n'arrive pas à tester le VQM) entre l'original et les trois encos.
Et tu nous indique laquelle sera la plus mauvaise.
[^] # Re: absence révélatrice: Xiph.org
Posté par Zenitram (site web personnel) . Évalué à 2.
Euh... Je te crois, vu que c'est aussi ce que j'ai dit.
On regarde la bande passante nécessaire à chaque codec avec toutes les contraintes liées à la diffusion.
Dans un commentaire plus bas, c'est même ce qui me fait descendre le test fait qui dit que Theora est meilleur (le testeur ayant oublié les contraintes du streaming, forcement ça biaise tout)
Ensuite tu la convertis avec x264, en activant toutes les options de qualité, et en faisant un enco 2 passes, et en utilisant le bitrate moyen de la vidéo youtube.
Bizarrement, ceux qui disent que Theora est meilleur (un encodage qu'ils ont bien soigné avec la qualité maximum) oublient de parler de ce genre d'encodage de H.264 :-D.
Et tu nous indique laquelle sera la plus mauvaise.
En fait, on n'a pas dû se comprendre : on est 100% d'accord sur ce point.
[^] # Re: absence révélatrice: Xiph.org
Posté par briaeros007 . Évalué à 1.
(mais dans ce cas l'argument de "theora moins bon que h264 pour le streaming" , même si dans l'absolue est vrai, ne tient pas vu que youtube utilise "mal" le h264).
[^] # Re: absence révélatrice: Xiph.org
Posté par Zenitram (site web personnel) . Évalué à 3.
A comparer avec utilise "mal" le Theora, est-ce que Theora sera meilleur? J'en doute, car il y aura aussi des contraintes qui feront que ceux qui testent en qualité maxi de Theora ne se mettent pas dans les conditions du streaming.
D'ailleurs, en parlant de streaming, le truc rigolo est que OGG, le conteneur, n'est pas adapté au streaming : il ne contient pas dans le header la position des keyframes. Donc le "seek" est fait à l'arrache, ce qui est assez éliminatoire pour un codec vidéo pour le web.
[^] # Re: absence révélatrice: Xiph.org
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 1.
Du vrai streaming, ça peut imposer un débit constant, par exemple. Ça ne concerne pas YouTube qui est un site de téléchargement de vidéos et non de streaming. Alors je ne vois pas.
[^] # Re: absence révélatrice: Xiph.org
Posté par Zenitram (site web personnel) . É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.
[^] # Re: absence révélatrice: Xiph.org
Posté par Anonyme . Évalué à 0.
[^] # Re: absence révélatrice: Xiph.org
Posté par briaeros007 . É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).
[^] # Re: absence révélatrice: Xiph.org
Posté par Zenitram (site web personnel) . Évalué à 2.
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.
Presque ;-). Novembre 2007.
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).
Yep. C'est pas la solution miracle, il faut faire avec les contraintes aussi, je suis d'accord.
Ca c'est la théorie. Maintenant la grande question, tu le fait comment dans un flux TS ?
Le TS (satellite donc) contient toujours toutes les couches (forcement, c'est du CBR le TS un satellite ayant toujours la même bande passante), par contre le décodeur décode les couche qu'il peut décoder en échange. Mais la on n'est plus sur le web.
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 ),
D'où le travail encore à faire dessus.
Qui sait que mpeg2 a des extensions de scalabilité ?
Oui, t'inquiète (pour les petits noms : profile SNR Sclable et Spatially Scalable). Pas utilisé effectivement, si c'est ce à quoi tu penses comme argument.
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.
Le hic est que les technologies de demain se basent sur les codecs (et leurs capacités) d'aujourd'hui. Pour choisir un codec, il faut comparer les capacité qui seraient utilisées dans le futur, et non les utilisations actuelles.
Tu parlais du MPEG-2, il est sorti à une époque ou la scalabilité n'avait pas trouvé d'utilité (pas de web), le web amène ce besoin (tu peux effectivement dire que c'et subjectif) du fait de son hétérogénéité, certains ne vont pas l'utiliser, d'autres vont l'utiliser, mais AVC garde une chose importante : il peut. Donc celui qui ne va pas utiliser SVC va utiliser AVC, et celui qui va utiliser SVC va aussi utiliser AVC. Un format de base unique. Et ça les boites aiment.
Je peux me tromper sur l'utilité du SVC, il ne sera peut-être pas utilisé trop, mais une chose reste sûre : AVC propose tout ce que plein de boites demandent, c'est une base forte, et ça Theora ne rivalise pas, car il va sur un marché de niche (le libre) sans aucun autre avantage que le fait d'être libre, ce qui est peu (je ne connais pas un seul format ou logiciel sorti des connaissances geek juste parce qu'il était libre : il y a toujours un "plus" avec)
[^] # Re: absence révélatrice: Xiph.org
Posté par briaeros007 . Évalué à 2.
J'avais plus ou moins commencé une thèse sur justement la métrique vidéo susmentionné, dans le cas d'une transmission de flux video SVC sur IP.
Et je participais, dans ce cadre là, à un projet inter entreprise pour justement mettre en place cette solution de façon globale pour une architecture "adsl" (du réseau de coeur au pan en passant par l'adsl).
ensuite j'ai pas mal perdu, dès qu'on est plus dans le bain...
Le TS (satellite donc)
De base satellite, certains fai l'utilise encore pour transmettre leurs flux aux dslam par exemple.
Et c'est le dslam qui effectue le décodage de flux et la transmission "finale".
Ce qui dans le cadre de la convergence peut poser problème (l'exemple "classique" :
le père regarde un match de foot sur son écran hd, tandis que le fils le regarde dans sa chambre (puni) sur son smartphone par le wifi.
l'équipement qui doit faire le filtrage des couches est la STB ici).
Je peux me tromper sur l'utilité du SVC, il ne sera peut-être pas utilisé trop, mais une chose reste sûre : AVC propose tout ce que plein de boites demandent, c'est une base forte, et ça Theora ne rivalise pas, car il va sur un marché de niche (le libre) sans aucun autre avantage que le fait d'être libre, ce qui est peu (je ne connais pas un seul format ou logiciel sorti des connaissances geek juste parce qu'il était libre : il y a toujours un "plus" avec)
Sans vouloir revendiquer que si le format est libre il aura la prédominance, je me suis rendu compte que quand on est le nez dans quelque chose, on a tendance a surestimé son importance (et c'est bien normal après tout).
Personnellement Je ne vois pas le SVC être vraiment utilisé avant au bas mot 5 ans.
Ne pas oublier que l'on utilise encore le mpeg2 dans certains transmission TV over IP ou TNT.
(je sais, on va me dire que la décision du MPEG2 sur la TNT est une décision politique, et ils auront raison , mais bon).
[^] # Re: absence révélatrice: Xiph.org
Posté par yellowiscool . Évalué à 3.
Envoyé depuis mon lapin.
[^] # Re: absence révélatrice: Xiph.org
Posté par Jean B . Évalué à 6.
[^] # Re: absence révélatrice: Xiph.org
Posté par El Titi . Évalué à 0.
Parce que si c'est bien ce à quoi je pense: un contrat est un contrat.
C'est du donnant donnant.
Et je suppose que Google ne joue pas les philanthropes.
[^] # Re: absence révélatrice: Xiph.org
Posté par BAud (site web personnel) . Évalué à 8.
[^] # Re: absence révélatrice: Xiph.org
Posté par zebra3 . Évalué à 6.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: absence révélatrice: Xiph.org
Posté par windu.2b . Évalué à 10.
[^] # Re: absence révélatrice: Xiph.org
Posté par zebra3 . Évalué à -2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: absence révélatrice: Xiph.org
Posté par Jean-Philippe Garcia Ballester (site web personnel) . Évalué à 6.
[^] # Re: absence révélatrice: Xiph.org
Posté par Antoine . Évalué à 2.
[^] # Re: absence révélatrice: Xiph.org
Posté par dguihal . Évalué à 5.
[^] # Re: absence révélatrice: Xiph.org
Posté par albert . Évalué à -1.
celui ci appartient à Apple
il est à noté aussi que microsoft vient de choisir le h264
le ogg theora est sans doute bien fini...
triste...
[^] # Re: absence révélatrice: Xiph.org
Posté par Prosper . Évalué à 1.
Pas vraiment , non http://www.videolan.org/developers/x264.html
[^] # Re: absence révélatrice: Xiph.org
Posté par FluffyHamster . Évalué à 2.
Cela m'étonnerai beaucoup que microsoft ai choisit h264 sachant qu'ils poussent leur codec vc1 (globalement équivalent au h264, moins bien quand même) depuis un petit bout de temps déjà. Ils ont par exemple réussi à le faire accepter dans les bluerays, en plus du h262 et h264.
Ogg Theora n'a que sa liberté pour lui. Et c'est pour ça qu'il faut tout de même l'utiliser.
Il est moins bon, et il n'a pas tant de marge de progression que ça... Enfin pas jusqu'à poutrer h264 non...
Et puis d'ailleurs tout les trucs cool sont déjà brevetés !! Rendez vous bien compte de ça.
[^] # Re: absence révélatrice: Xiph.org
Posté par TImaniac (site web personnel) . Évalué à 4.
C'est assez logique au vu de la politique actuelle de Microsoft vis-à-vis du format H264 : intégré par défaut dans Windows, dans Silverlight, il n'y a rien de surprenant qu'il soit supporté dans IE9.
[^] # Re: absence révélatrice: Xiph.org
Posté par Bruno Michel (site web personnel) . Évalué à 3.
Certes, mais le Google Summer of Code est une opération de communication, et le premier des objectifs cités sur http://socghop.appspot.com/document/show/gsoc_program/google(...) est « Create and release open source code for the benefit of all ».
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.