H.265 est finalisé

Posté par  . Édité par Davy Defaud, NeoX, baud123, Pierre Jarillon, Bruno Michel, Benoît Sibaud et patrick_g. Modéré par Pierre Jarillon. Licence CC By‑SA.
Étiquettes :
86
27
jan.
2013
Audiovisuel

La norme de codage vidéo H.265/HEVC — High Efficiency Video Coding — vient d’être annoncée comme finalisée par l’ITU, à savoir l’organisme qui gère sa définition. Après douze réunions et trois ans de travaux, le consortium s’est mis d’accord sur la définition de ce nouveau standard vidéo qui viendra remplacer à terme les standards MPEG-2 et H.264/AVC.

Cette dépêche traite des avancées techniques apportées par ce nouveau standard. Les questions portant sur les brevets n’y sont pas traitées.

Sommaire

Généralités sur le décodage vidéo

La compression image JPEG

La compression JPEG peut se représenter sous la forme de cet organigramme :

organigramme JPEG

Au travers des fonctions de transformations de couleurs et de sous-échantillonnage, les pixels sont tout d’abord transformés du plan des 3 couleurs primaires rouge, vert et bleu, vers le plan YUV (luminance, chrominances bleu [Cb] et rouge [Cr]). L’œil humain étant moins sensible à la chrominance, il est fréquent de ne garder qu’un pixel sur quatre pour la chrominance : c’est le sous-échantillonnage 420.

Ainsi, la transformation de couleurs est sans perte, tandis que le sous-échantillonnage produit de la perte d’information.

Les pixels subissent ensuite une DCT : il s’agit d’une transformée de Fourier permettant le passage de pixels issus d’un échantillonnage vers une information de type fréquentielle. Cette transformation se fait sans perte.

L’intérêt de cette transformation est que les éléments de fréquence basse sont ceux qui sont le plus visibles pour l’œil. Ceux de fréquence haute ne font qu’améliorer la qualité de l’image.

La quantification est justement l’étape qui permet de filtrer, plus ou moins selon la qualité désirée, les hautes fréquences par rapport aux basses et d’augmenter le pas de résolution de cette information. Plus ce filtrage est fort, plus la compression est importante, moins la qualité est bonne en sortie. De ce fait, la quantification est une étape avec pertes.

Les données issues de cette étapes sont appelées les résidus. Ces derniers sont ensuite encodés par un algorithme de type Variable Length Coding, permettant d’encoder avec moins de bits les éléments les plus probables.

La compression vidéo MPEG-2/H.264

La compression vidéo ajoute principalement deux étapes à celles de la compression JPEG. Il s’agit de deux mécanismes de prédiction de pixels : la prédiction intra-image et la prédiction inter-image.

La prédiction intra-image

Elle consiste à utiliser les résidus déjà décodés dans l’image comme prédiction. Il s’agit en général des pixels présents en haut ou a gauche du bloc concerné. Les résidus qui sont ensuite décodés sont alors additionnés au résultat de la prédiction intra.

L’intérêt de cette étape réside dans le fait que les résidus à encoder ont alors une grande chance statistique de se trouver autour de 0, rendant les encodages de type Variable Length Coding extrêmement performants.

La prédiction inter-image

Cette prédiction consiste à utiliser les pixels d’une image déjà décodée comme prédiction. On fait donc appel à une image déjà décodée et on lui applique un vecteur de mouvement permettant d’appliquer un déplacement à un groupe de pixels. Ainsi, une séquence avec un plan fixe et une voiture qui se déplace sur une route peut être encodée de manière très performante par ce type de prédiction.

Cependant, cette prédiction oblige le décodeur à avoir décodé l’image de référence. Si toutes les images utilisent la prédiction inter-image, il devient impossible pour l’utilisateur d’entamer un flux vidéo s’il ne l’a pas décodé depuis le début. Pour gérer ce problème, on insère à intervalles réguliers des images dites « key frames » qui garantissent au décodeur que les images suivantes ne feront jamais appel à une image antérieure.

Cet artifice explique que l’utilisateur qui change de chaîne sur sa TV doive attendre un certain laps de temps qu’une key frame lui parvienne.

H.265

Voyons désormais les principales nouveautés introduites dans cette nouvelle version du standard.

Le codage CABAC

Introduit par H.264 et réservé aux profils les plus élevés, le codage arithmétique CABAC est désormais systématique pour remplacer les codages de type Variable Length Coding.

Cet encodage, relativement complexe, n’encode pas les éléments de syntaxe un à un, mais va le faire par paquets d’éléments de syntaxe, en encodant ceux-ci par rapport à leurs valeurs les plus probables.

On considère le gain du CABAC par rapport au VLC de l’ordre de 10 %.

La fin des macro-blocs pour un découpage des pixels adapté à chaque fonction

Jusque là, dans un flux vidéo, les pixels sont découpés en carrés de 16 pixels de large (les macro-blocs), eux-mêmes sous-divisés en blocs de 8 pixels de large. Les algorithmes travaillent ensuite sur cette unité de données.

En H.265, les pixels sont divisés en Coded Tree Unit (CTU) de 16, 32 ou 64 pixels de largeur. Ces dernières sont ensuite partitionnées en coding unit (CU). Une CTU peut être divisées en 4 CU, qui peuvent elles-mêmes se diviser en 4 CU, et ainsi de suite. Cette récursivité s’applique au maximum 3 fois, donnant un passage CTU vers CU de ce type :

split CTB

Les CU peuvent ensuite être découpées en Transform Unit (TU) et en Prediction Unit (PU), pour respectivement les fonctions qui concernent les résidus et les prédictions.

split PU

Ce découpage adaptatif permet aux encodeurs d’appliquer les meilleurs découpages possibles, permettant un meilleur gain et une meilleure qualité d’image. Il rend en revanche la tâche plus compliquée pour les décodeurs matériels qui doivent constamment adapter leur flux de données aux dimensions données par le flux vidéo.

Prédiction intra-image angulaire

H.264 apportait une prédiction intra-angulaire de type 45°. On pouvait donc prédire les résidus en les prenant à gauche, en haut mais aussi en biais. H.265 va plus loin en permettant d’utiliser un plus grand nombre d’angles, comme le montre cette image :

pred intra angulaire

Prédiction inter-image

La prédiction inter-image évolue, notamment sur les vecteurs de mouvement indiquant le déplacement des pixels à effectuer sur l’image de référence. Ceux-ci sont désormais donnés avec une précision au quart de pixel (au lieu d’un demi-pixel en H.264) et peuvent désormais être plus grands (de -8192 à 8192).

Wavefront

H.265 ajoute un mode de décodage qui permet de paralléliser le décodage d’un flux vidéo. Toute la difficulté est que dans un flux vidéo, on se sert généralement des données précédemment décodées pour décoder la donnée courante. Il a donc été créé ce mécanisme de Wavefront. On lance un thread de décodage sur chaque ligne de CTB, la première ligne étant en légère avance de phase par rapport à la deuxième, etc. Cela permet de faire en sorte que les données soient à peu près disponibles lorsqu’un thread fait appel aux résidus de la CTB du dessus.

Wavefront

Sample adaptative offset

Un nouveau filtrage appliqué en sortie de l’image, en plus du filtrage de deblocking, est désormais appliqué afin de réduire le bruit sur l’image.

H.265 a porté un souci constant pour améliorer les filtres d’images. Cela permet de compresser plus les données, tout en retrouvant une qualité d’image acceptable.

Résolution d’image

Bien que le permettant, H.264 n’était pas adapté aux résolutions de type 4k2k. H.265 permet aujourd’hui de passer à des résolutions jusqu’au 8k.

Gain de bande passante

H.265 ayant énormément porté l’effort sur les boucles de filtrage, le consortium a décidé d’appliquer des mesures de gain de bande passante par comparaisons subjectives. Des novices en termes de décodage vidéo ont été confrontés à des flux en H.264 et des flux H.265, et, à qualité visuelle égale, on peut voir un gain de bande passante en moyenne aux alentours de 50 %, avec des pics à 60 % sur certains profils.

Aller plus loin

  • # Consommation CPU

    Posté par  . Évalué à 10.

    Et au niveau de la consommation du processeur, ça donne quoi ?

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Consommation CPU

      Posté par  . Évalué à 4.

      ils ne sont pas encore commercialisés, attend un peu.

      • [^] # Re: Consommation CPU

        Posté par  . Évalué à 3.

        D'après les commentaires plus bas, l'encodeur/décodeur existe déjà, pas besoin d'attendre.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Consommation CPU

          Posté par  . Évalué à 2.

          Le compresseur de référence est prêt, bien sur, mais pas forcément le plus optimisé. Mais il faut s'attendre à une demande en CPU nettement supérieur que le H.264.

  • # Images?

    Posté par  (site web personnel) . Évalué à 2.

    Y a que chez moi que les images ne s'affichent pas?

    Firefox, dernière version, sur Mac OS, style CSS par défaut.

    • [^] # Re: Images?

      Posté par  (site web personnel) . Évalué à 2.

      OK j'ai trouvé, il charge pas les images non https. C'est un sacré problème quand même non?

      • [^] # Re: Images?

        Posté par  . Évalué à 8.

        Va falloir le répéter combien de fois ?
        va voir la FAQ.

        Mais je suis d'accord que comme ca ne marche pas out of the box c'est un problème.

        • [^] # Re: Images?

          Posté par  (site web personnel) . Évalué à 10.

          va voir la FAQ.

          Avec un lien : http://linuxfr.org/aide#aide-imgcertificatssl

          Mais je suis d'accord que comme ca ne marche pas out of the box c'est un problème.

          Si quelqu'un a une idée sur comment résoudre ce problème, qu'il ou elle n'hésite pas à la proposer sur http://linuxfr.org/suivi/proposer-une-page-d-aide-a-la-configuration-https.

          • [^] # Re: Images?

            Posté par  . Évalué à 6.

            Si quelqu'un a une idée sur comment résoudre ce problème, qu'il ou elle n'hésite pas à la proposer

            Payer pour les audits de CA-Cert ?

          • [^] # Re: Images?

            Posté par  (site web personnel) . Évalué à 8.

            Utiliser un certificat gratuit de chez StartSSL ?

            • [^] # Re: Images?

              Posté par  . Évalué à 9.

              C’est plus pratique mais c’est beaucoup moins en accord avec les valeurs des admin.

              Si je dis pas de bêtise, CA-Cert a été choisi parce qu’il s’agit d’une association à but non lucratif avec un fonctionnement démocratique.

              • [^] # Re: Images?

                Posté par  (site web personnel) . Évalué à 10.

                • [^] # Re: Images?

                  Posté par  . Évalué à 8.

                  choisir une solution non fonctionnelle parce qu'elle est pus libre, c'est ça l'intégrisme.

                  • [^] # Re: Images?

                    Posté par  (Mastodon) . Évalué à 10.

                    La vraie question, c'est pourquoi Mozilla n'inclut pas les certificats CACert dans son navigateur alors qu'elle inclut des certificats complètement moisis ?

                    • [^] # Re: Images?

                      Posté par  . Évalué à 5.

                      • [^] # Re: Images?

                        Posté par  . Évalué à 2.

                        Apparemment CACert n'a pas non plus réussi à être accepté par Fedora (superficiellement pour une histoire de licence, mais à voir la discussion imbuvable on peut dire que CACert a du mal à faire passer un message clair).

                        • [^] # Re: Images?

                          Posté par  (site web personnel) . Évalué à 5.

                          C'est con, on ne peut pas modifier un certificat SSL. Ce n'est donc pas libre !!

                          Plus sérieusement, Pour que CAcert puisse être accepté dans les distrib, il lui suffit juste de régénérer une nouvelle arborescence de certificats selon un processus documenté et auditable dans des conditions initiales draconiennes. Rien d'insurmontables, mais qui ne doit pas être fait à la légère.

                          Il est vrai que les certificats actuels "Root CA" et "CAcert Inc." manque un peu d'uniformité dans leur nom d'organisation. Mais il est regrettable que Mozilla en fasse un point bloquant alors qu'ils sont moins regardant pour accepter les certificats moisis de sociétés moins scrupuleuses. Beaucoup y voient une affaire de gros sous…

                          • [^] # Re: Images?

                            Posté par  . Évalué à 6.

                            Ce n'est donc pas libre !!

                            Ah bon, tu ne peux pas recompiler Firefox?

                            Beaucoup y voient une affaire de gros sous…

                            Soupir J'avoue ne pas comprendre ces soupçons constants sur Mozilla. Je ne comprends pas qu'ils fassent autant l'objet de critique malgré tout ce qu'ils font. Ils ont leur ligne directrice, franchement ouverte, et ils gardent la maîtrise sur leur projet de bout en bout puisqu'ils considèrent a raison que ça fait partie intégrante de leur responsabilité. Certes ca détonne un peu dans le monde du libre. Pour autant que je sache, tout le monde est libre de recompiler le code.

                            J’espère que qui aime bien châtie bien ?

                            • [^] # Re: Images?

                              Posté par  . Évalué à 4.

                              Tu sais, on peut aimer quelqu'un pour ce qu'il fait de bien tout en critiquant ce qu'il fait de mal. Tout n'est pas tout blanc ou tout noir.

                    • [^] # Re: Images?

                      Posté par  (site web personnel) . Évalué à 8.

                      Parce que CACert ne cherche pas à se faire inclure tant qu'ils ne sont pas en mesure de passer un audit qui répond aux critères de Mozilla.

                      http://wiki.cacert.org/InclusionStatus
                      (voir aussi le commentaire 158 dans le bug cité plus haut : https://bugzilla.mozilla.org/show_bug.cgi?id=215243#c158 )

                      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                      • [^] # Re: Images?

                        Posté par  (Mastodon) . Évalué à 2.

                        Un commentaire écrit en 2007 est bien sûr entièrement valide en 2013, c'est certain…

                        Faudrait arrêter un peu de prendre les gens pour des cons. Il y a eu pas mal d'affaires montrant que les certificats inclus ne sont pas aussi sûr qu'ils le disent, malgré les audits. En plus, le bug dit que CACert a arrêté de demander, sauf que le lien que tu donnes dit exactement le contraire et dit même que c'est le "primary focus and largest challenge".

                        • [^] # Re: Images?

                          Posté par  (site web personnel) . Évalué à 5.

                          Un commentaire écrit en 2007 est bien sûr entièrement valide en 2013, c'est certain…

                          Quand le wiki du projet qui a été mis à jour il y a moins de deux semaines dit la même chose, oui.

                          Le lien dit clairement que ça passe pas encore l'audit. Donc, non, ils essaient toujours pas de se faire inclure dans Firefox pour le moment. Ils essaient de passer l'audit d'abord (en vue de pouvoir introduire une demande à Mozilla entre autres, certes).

                          Après, s'il y a des CA dans Firefox qui sont moisies, parce que leur processus d'audit ou celui de Mozilla est pourri, c'est une autre histoire.

                          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

                          • [^] # Re: Images?

                            Posté par  (Mastodon) . Évalué à -1.

                            Donc, non, ils essaient toujours pas de se faire inclure dans Firefox pour le moment.

                            C'est marrant, c'est pas ce que j'ai lu dans le lien que tu as donné. Je cite :

                            CAcert's primary focus and largest challenge at present is to meet the fair but firm policy of Mozilla with a view to inclusion in their products, including the popular Firefox browser.

                            Que je traduirais par :

                            Le principal objectif et le plus grand challenge de CAcert pour le moment est de se conformer à la politique juste mais ferme de Mozilla pour être inclus dans leurs produits, y compris le navigateur Firefox.

                            • [^] # Re: Images?

                              Posté par  (site web personnel) . Évalué à 9.

                              CAcert a bien pour objectif de se faire inclure dans Firefox, mais c'est un objectif en plusieurs étapes. La première étape consiste à passer l'audit interne et seulement après ils feront la demande à Mozilla pour être inclus. En 2007, ils considéraient qu'ils ne répondaient pas au niveau d'exigence de Mozilla et ont retiré leur demande. Donc, non, ils n'essayent pas de se faire inclure dans Firefox pour le moment, même si l'objectif principal sur le long-terme.

                  • [^] # Re: Images?

                    Posté par  . Évalué à 5.

                    Je sais pas dans quel monde tu vis mais, dans le miens, SSL/TLS fonctionne très bien sans financer des sociétés privés ou quoi que ce soit dans ce genre.

                    D’ailleurs, la solution choisi ici fonctionne parfaitement, il suffi de faire confiance à CACert. Tandis que la solution fourni par ma banque, par exemple, ne fonctionne pas puisque je ne pas faire confiance à VeriSign.

                    • [^] # Re: Images?

                      Posté par  . Évalué à 7.

                      Moui. Sauf que Mozilla fournit pour ta banque une chaîne qui aboutit à un certificat "builtin". C'est (très) discutable, mais ça rend l'accès à cette dernière simple.

                      Pour tout ce qui est CAcert, tu peux "au mieux" ajouter la racine. Or, pour les logiciels Mozilla, ce n'est pas exactement la même chose qu'une racine builtin (i.e. ajoutée à la compilation) : tu ne peux notamment pas installer automatiquement des extensions signées par un descendant d'une racine "user-added".

                      Alors oui, il y aurait sûrement des choses à faire pour que CAcert soit accepté. Mais prétendre qu'en l'état ça "fonctionne très bien" est un mensonge pur et simple. Même en ajoutant manuellement la racine (ce qui n'est pas à la portée de toutes les Michus, mais qui est effectivement nécessaire à une vraie "confiance"), on n'a pas un comportement identique à celui d'une CA inclue d'office.

                      • [^] # Re: Images?

                        Posté par  . Évalué à 2.

                        Quand tu ajoute la racine il te demande pour quels usages tu la destine. Tu peut le mettre pour les extensions si je ne m'abuse.

                        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

          • [^] # Re: Images?

            Posté par  . Évalué à 10.

            Il me semble qu'il suffit de pointer sur https://img.linuxfr.org, accepter normalement le certificat et c'est bon. C'est plus simple que de l'importer à la main dans le navigateur.

            • [^] # Re: Images?

              Posté par  (site web personnel) . Évalué à 2.

            • [^] # Re: Images?

              Posté par  (site web personnel) . Évalué à 3. Dernière modification le 27 janvier 2013 à 20:58.

              Et un certificat wildcard ne serait pas une solution pour permettre aux lecteurs d'intégrer le certificat des sous-domaines en même temps que le domaine ?

              ce commentaire est sous licence cc by 4 et précédentes

              • [^] # Re: Images?

                Posté par  (site web personnel) . Évalué à 2.

                Il me semble que c'est ce que l'on a déjà en place, mais qu'il faut quand même l'accepter pour chaque domaine.

                • [^] # Re: Images?

                  Posté par  (site web personnel) . Évalué à 3.

                  C'est bizarre, lorsque j'affiche le certificat je lis CN=linuxfr.org au lieu de CN=*.linuxfr.org.
                  Aussi, je lis CN=linuxfr.org pour https://img.linuxfr.org. Et pourtant Epiphany et Firefox avec le certificat racine CaCert ne ralent pas pour ce dernier point. Il y a quelque chose que j'ai raté ?

                  ce commentaire est sous licence cc by 4 et précédentes

                  • [^] # Re: Images?

                    Posté par  (site web personnel) . Évalué à 2.

                    Hum, je ne suis pas un spécialiste des certificats, c'est plutôt oumph qui s'occupe de ça. *.linuxfr.org apparaît dans le champ Subject Alt Name, ça doit compter quand même, non ?

                    • [^] # Re: Images?

                      Posté par  (site web personnel, Mastodon) . Évalué à 5.

                      Pour avoir déjà bidouillé avec les certificats wildcards, il faut ajouter à la fois *.domain.tld et domain.tld dans le alt name du certificat pour que ça passe.
                      Dans le certificat actuel, il y a ceci dans le alt names:

                      Nom DNS: linuxfr.org
                      Nom DNS: linuxfr.org
                      Nom DNS: dev.linuxfr.org
                      Nom DNS: prod.linuxfr.org
                      Nom DNS: alpha.linuxfr.org
                      Nom DNS: *.linuxfr.org

                      Je ne comprends pas l'intérêt de mettre deux fois "linuxfr.org", ni de spécifier un ou deux sous-domaines pour finir par "*.linuxfr.org". Peut-être que ça parait juste et redondant, mais il est possible que le navigateur ne gère pas ça correctement…

          • [^] # Re: Images?

            Posté par  . Évalué à 3.

            C'est quoi l'interet du sous-domaine ?

          • [^] # Re: Images?

            Posté par  . Évalué à 0.

            Servir les images en http?

            Linuxfr, le portail francais du logiciel libre et du neo nazisme.

            • [^] # Re: Images?

              Posté par  . Évalué à 7.

              Ça fait aussi des warning et bientôt Firefox n'affichera plus les ressources http dans une page https.

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

            • [^] # Re: Images?

              Posté par  (site web personnel) . Évalué à 7.

              On sert les images en http pour les utilisateurs qui viennent en http sur LinuxFr. Par contre, pour ceux qui viennent en https, on préfère les servir en https pour éviter que les navigateurs affichent une erreur de sécurité.

      • [^] # Re: Images?

        Posté par  . Évalué à -8.

        Habawé, t'as raison, macos est un sacré problème.
        Donne pas le baton pour te faire battre..

        • [^] # Re: Images?

          Posté par  (site web personnel) . Évalué à 4.

          Habawé, sur linux t'as pas eu le problème? Qu'est ce que Mac OS a à voir là dedans?
          Tu possède pas une voiture, j'espère, parce quec'est pas libre un voiture, hein?
          Intégriste…

          • [^] # Re: Images?

            Posté par  . Évalué à -4.

            Non mais avec une voiture on emprunte pas les pistes cyclabes.

            abaoué abaoué

            • [^] # Re: Images?

              Posté par  . Évalué à 2.

              Message reçu. Tu n'aimes pas MacOS.

              Le fait est que le problème dont on parle n'a rien à voir avec un OS quelconque. Il s'agit d'un problème de gestion des certificats dans les navigateurs, navigateurs dont tu remarqueras que ce sont les mêmes d'un OS à l'autre : Firefox, Chrome, Opéra, IE.

              • [^] # Re: Images?

                Posté par  . Évalué à 1.

                J'utilise un OS digne de ce nom et c'est lui qui inclue les certificats racines « par défaut » pas le ou les navigateurs installé dessus.

                • [^] # Re: Images?

                  Posté par  (site web personnel) . Évalué à -1.

                  Pas tous… Ubuntu n'inclus pas CA-CERT. J'ai dû faire la manip sur mes 2 PC linux à la maison.
                  Quel débat stérile, "OS digne de ce nom", c'est pas parce que tu utilises ArchLinux que tu es supérieur aux autres.
                  T'est peut-être intelligent, mais ça n'empêche pas d'être con.

                  • [^] # Re: Images?

                    Posté par  (Mastodon) . Évalué à 4.

                    Toi tu n'as pas compris la remarque. Il oppose le fait d'installer les certificats au niveau global pour tous les navigateurs quelque part dans un /usr/share/ plutôt que de l'installer dans chacun des navigateurs.

                    • [^] # Re: Images?

                      Posté par  (site web personnel) . Évalué à 2.

                      Probable, en 2ème relecture. Me suis emporté, mais les commentaires intégristes du dessus m'ont un peu énervé… Désolé.

                  • [^] # Re: Images?

                    Posté par  . Évalué à 1.

                    Ubuntu n'inclus pas CA-CERT

                    $ dpkg -S /usr/share/ca-certificates/cacert.org/cacert.org.crt
                    ca-certificates: /usr/share/ca-certificates/cacert.org/cacert.org.crt
                    
                    

                    c'est pas parce que tu utilises ArchLinux que tu es supérieur aux autres.

                    Ça fait un bon moment que j’ai quitté Arch.

                    T'est peut-être intelligent, mais ça n'empêche pas d'être con.

                    What The Fuck ?!

    • [^] # mac os ?

      Posté par  . Évalué à -6.

      Bon, la prochaine fois que j'ai eu une question sur windows 8, on sait jamais, si un jour j'y revenais, je n'hésite pas alors.

  • # 50% de bande passante en mois

    Posté par  (site web personnel) . Évalué à 7.

    Pas mal: 50% de bande passante en mois, ça veux dire des film/serie occupant 50% moins de place. Et que si ça arrive sur youtube, c'est 50% de bande passante en mois pour tout le monde (youtube, FAI, client)…
    Encore faut t'il avoir un encodeur qui fait bien sont travail.

    Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

  • # Resolution d'image

    Posté par  . Évalué à 4.

    Bien que le permettant, H264 n'était pas adapté aux résolutions de type 4k2k. H265 permet aujourd'hui de passer à des résolutions jusqu'au 8K.

    Tu peux nous en dire plus ? En quoi h264 n'est pas adapté ? c'est pourtant le codec principalement utilisé sur les blueray :o

    • [^] # Re: Resolution d'image

      Posté par  . Évalué à 8.

      bluray c'est du 1920x1080
      4k2k, c'est plutot du 3840×2160
      La taille d'au dessus donc

      • [^] # Re: Resolution d'image

        Posté par  . Évalué à 1.

        4k2k, c'est plutot du 3840×2160

        Ah ok j'avais compris, 4k2k = Résolution 4k et 2k .

    • [^] # Re: Resolution d'image

      Posté par  . Évalué à 6.

      Les codecs vidéos définissent des profils. H264 en avait principalement 3: baseline, main, et high. Aucun de ces profils ne permettaient d'aller au dela du 1080p. Tu peux donc très bien aller au 4k2k mais tu n'auras aucun profil qui correspondra. En pratique, ca fera que tu ne seras compatible avec aucun décodeur.

      Sinon, h264 en lui même n'est pas super adapté: par exemple les pixels sont divisés en macroblocks de 16 pixels de large, pour du 4k2k c'est trop petit comme unité. Il en va de même pour les motions vectors, taillés trop petits pour des image de cette taille.

      • [^] # Re: Resolution d'image

        Posté par  (site web personnel) . Évalué à 3.

        C'est l'association des profiles et des niveaux qui permettent de déterminer la résolution maximum. H.264 peut très bien faire du 4K. Exemple en Profil High et Level 5.1 : 4,096×2,048 @30.0 fps.

        Voir https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels

      • [^] # Re: Resolution d'image

        Posté par  (site web personnel) . Évalué à 9.

        H264 en avait principalement 3: baseline, main, et high. Aucun de ces profils ne permettaient d'aller au dela du 1080p. Tu peux donc très bien aller au 4k2k mais tu n'auras aucun profil qui correspondra.

        N'importe quoi.
        Renseigne-toi sur ce qu'on appelle "Level".
        Pour info, le Level 5.2 permet d'aller par exemple à 4K à 50 fps.
        Et absolument rien n'interdit de balancer un update (juste 1 page en plus dans la spec). quand le besoin s'en fera sentir pour un Level 6.
        Le profile ne dit absolument rien sur la résolution, mais sur des capacités supportées ou pas (CABAC, 4:4:4, 12-bit…), et c'est un gros bug de mélanger profile et level dans le discours.

        Sinon, h264 en lui même n'est pas super adapté: par exemple les pixels sont divisés en macroblocks de 16 pixels de large, pour du 4k2k c'est trop petit comme unité. Il en va de même pour les motions vectors, taillés trop petits pour des image de cette taille.

        Ah la bataille des 16 pixels… Rien de neuf, on disait ça déjà lors du passage de 480p (DVD) au 1080p (Blu-ray)… Ca ne l'empèche pas de pouvoir compresser pas trop mal du 8K. Et certes, il y a un peu d'optimisation à faire pour les hautes résolution, et c'est pour ça qu'on sort H.265, mais ça n'enlève pas le fait qu'H.264 est quand même adapté au 8K si besoin (pour le moment, les 8K que j'ai vu passé est en JPEG-2000, certes, mais parce que les mecs s'en foutent un peu de l'optimisation pour le moment).

        Bref, faudrait pas enterrer trop tôt H.264, et surtout il faut arrêter le FUD qu'H.264 n'est pas adapté au 4K et/ou des trucs genre "tu n'auras aucun profil qui correspondra".

        • [^] # Re: Resolution d'image

          Posté par  (site web personnel) . Évalué à 2.

          Et que vaux H265 par rapport à DCI ? Après tout, beaucoup de monde vient de s'apercevoir qu'il y a peu (pas ?) de problèmes de brevet sur le JPEG2000 dans le cadre de l'usage du DCI.

          "La première sécurité est la liberté"

          • [^] # Re: Resolution d'image

            Posté par  (site web personnel) . Évalué à 5.

            Pas suivi : DCI, c'est du JPEG 2000, donc que de l'Intra. Même MPEG-1 avec des P-Frame ferai mieux.
            Après, à savoir si H.265 fait mieux que H.264 ou JPEG-2000 en "Intra only", grande question que je ne me suis jamais posé et que je n'ai jamais vu comparée car JPEG-2000, à part les félés du format ciné, il n'y a personne pour l'utiliser (qui d'autres que les cinés peuvent se permettre d'imposer de l' "intra-only" hyper consommateur d'espace pour la diffusion?) et donc pas foule pour imaginer faire une comparaison.

            Après tout, beaucoup de monde vient de s'apercevoir qu'il y a peu (pas ?) de problèmes de brevet sur le JPEG2000 dans le cadre de l'usage du DCI.

            Oui, mais bon, le prix de la licence H.264 c'est peanuts par rapport aux prix du stockage DCI!

            • [^] # Re: Resolution d'image

              Posté par  (site web personnel) . Évalué à 3.

              J'avais l'impression quand dans le domaine haute qualité, le DCI était ce qui produisait le moins de truc désagréable à l'oeil.

              Par exemple, est-ce que des flux à 15mbits/s 1080p, ne serait pas meilleur en DCI qu'en H264 ?

              "La première sécurité est la liberté"

              • [^] # Re: Resolution d'image

                Posté par  (site web personnel) . Évalué à 6.

                Je n'ai pas fait de tests, mais bon, mon préjugé est que je vois mal comment une série d'image intra peuvent concurrencer une fonctionnalité qui réduit de 90% le poids d'une image (les P et B-frames).

                Même en "haut" (entre guillement, 15 Mbps c'est faible ;-) ) débit.

                A confirmer, ça reste un préjugé de ma part et je ne m'engagerai pas sur ma vie dessus :), juste que je vois mal comment ça en serait autrement.

                (mais de ton côté, imaginerais-tu plutôt du JPEG 2000 contre AVC-Intra plutôt que tout H.264?, la JPEG 2000 a meilleure réputation à ma connaissance)

                • [^] # Re: Resolution d'image

                  Posté par  (site web personnel) . Évalué à 2.

                  Il me semble que Prae disait que DCI avait été choisi car il n'y avait jamais de défaut gênant.

                  "La première sécurité est la liberté"

                  • [^] # Re: Resolution d'image

                    Posté par  (site web personnel) . Évalué à 3.

                    Il me semble qu'il parlait de AVC-Intra contre JPEG 2000, et la oui, ben AVC-Intra, c'est du AVC (H264) donc avec ses défauts, et si tu enlèves la partie intéressante (les B et P frames) d'H264, forcément…

                    PS : DCI, c'est une norme qui a dit quel format utiliser, ce n'est pas un format. DCI n'a pas été choisi, DCI a choisi! (MXF et JPEG 2000 en l’occurrence)

    • [^] # Re: Resolution d'image

      Posté par  (site web personnel) . Évalué à 3.

      Le Blu-ray est en 1920x1080p (2k), H264 est clairement adadpté au 1080p. Le 4K aussi, mais c'est très gourmand pour l'encodage et décodage… ! H265 devrait améliorer les performance.

      • [^] # Re: Resolution d'image

        Posté par  (site web personnel) . Évalué à 0.

        Encore faut-il que le 4K remporte un succès plus important que la 3D. Vu le gain apporté, ce n'est pas sûr.
        Certes, en théorie, on a 2 fois plus de pixels (en largeur).

        Cependant, une bonne distance pour regarder la télé donne une ouverture d'entre 20 (un peu loin) et 40° (un peu près).
        L'œil humain a un pouvoir de résolution d'environ (1/60)°. Autrement dit, il n'est pas capable de distinguer plus de 1 200 pixels en largeur sur une télé vue avec un angle de 20°, et plus de 2 400 sur une télé vue avec un angle de 40°.

        Du coup, si on regarde une télé avec un angle de 32°, on ne verra pas de différence entre la Full-HD (1 920 pixels de large) et la 4K (3 840 pixels).

        Par contre, on aurait vu la différence avec une Full-HD en 16/9 et une Full-HD en 4/3 (l'œil ayant plutôt une vision en 4/3)…

  • # Le profil Main 10

    Posté par  (site web personnel) . Évalué à 10.

    Une autre amélioration du H.265 est la capacité de stockage des pixels en 10 bits au lieu du classique 8 bits via le profil Main 10, permettant d'avoir une meilleure profondeur des couleurs (jusqu'à 1024 niveaux contre 256) et limiter le color banding. En H.264 c'est aussi possible, mais c'est peu (voir pas) du tout supporter pas les décodeurs hardware. Par contre en software aucun souci.

    De plus cela améliore la compression (on pourrait penser le contraire !), car il faut moins de débit en 10 bits. (http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)

    • [^] # Re: Le profil Main 10

      Posté par  . Évalué à 4.

      De plus cela améliore la compression (on pourrait penser le contraire !), car il faut moins de débit en 10 bits.

      N'y aurait pas une explication plus technique ?

      Sinon vu que nos cpu travaille aussi avec des octets (8 bits), je pense que le 10 bits est plus couteux.

      • [^] # Re: Le profil Main 10

        Posté par  . Évalué à 3. Dernière modification le 27 janvier 2013 à 16:21.

        Les processeurs 8bits pour décoder de la vidéo, ça ne cours pas les rues, surtout dans les PC/smartphones/tablettes/… on est plutôt avec 32 ou 64 bits dans ce cas.

        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

        • [^] # Re: Le profil Main 10

          Posté par  . Évalué à 7.

          Les processeurs 8bits pour décoder de la vidéo, ça ne cours pas les rues, surtout dans les PC/smartphones/tablettes/… on est plutôt avec 32 ou 64 bits dans ce cas.

          Ben les instruction SIMD travaille sur des données 8 bits en parallèle et leur registre font plutôt 128 bits.

          Du coup je comprend pas trop pourquoi ce commentaire est autant plussé.

      • [^] # Re: Le profil Main 10

        Posté par  . Évalué à 2.

        Plus technique que le pdf, ou un résumé de celui-ci?

        Pour l'aspect gradients, on peut l'expliquer comme ceci: l'encodeur peut décrire d'un coup une grande surface, alors qu'avec des coordonnées moins précises la même description aurait été mal arrondie et aurait créé des bandes de couleurs qui collent moins bien au gradient original (à bande passante égale c'est moche, à qualité égale il faut faire plein de gradients sur des surfaces plus petites).

        Pour l'aspect source 10bit, il s'agit de ne pas enchaîner deux types de compression à perte: la quantification suivie de la compression vidéo.

    • [^] # Re: Le profil Main 10

      Posté par  . Évalué à 1.

      L'H.264 gère le 10 bit (Hi10P).

      • [^] # Re: Le profil Main 10

        Posté par  (site web personnel) . Évalué à 2.

        En H.264 c'est aussi possible, mais c'est peu (voir pas) du tout supporter pas les décodeurs hardware. Par contre en software aucun souci.

        Oui, et c'est très bien supporté côté software (Mplayer2 notamment). Par contre comme je l'ai dit, en hardware ce n'est pas du tout supporté (à ma connaissance), lire une vidéo ne serait-ce qu'en 720p en 10 bits est impossible sur smartphone/tablette/box/mediaplayer/… car le décodeur matériel ne le supporte pas. En général on obtient une bouillis de pixels vert.

        Avec l'arrivé du H.265 on peut imaginer que les décodeurs HW gèreront enfin le 10 bits !

        • [^] # Re: Le profil Main 10

          Posté par  (site web personnel) . Évalué à 1.

          Par contre comme je l'ai dit, en hardware ce n'est pas du tout supporté (à ma connaissance), lire une vidéo ne serait-ce qu'en 720p en 10 bits est impossible sur smartphone/tablette/box/mediaplayer/…

          Ce même matos ne supporte pas H.265, donc?

          Avec l'arrivé du H.265 on peut imaginer que les décodeurs HW gèreront enfin le 10 bits !

          Pas plus : ça reste optionnel.
          Tu imagines sérieusement un décodeur HW décoder du H.265 en 10-bit avant de savoir décoder du H.264 10 bits?

          Bref : tu verras rien, faut arrêter le fantasme. H.265 n'apporte rien de ce côté, c'est identique (optionnel dans les deux cas).
          Ca veut rien dire "Une autre amélioration du H.265 est la capacité de stockage des pixels en 10 bits"

          PS : c'est fou ce qu'on peu lire comme FUD et/ou fantasmes sur H.265 dans les commentaires! H.265 apporte plein de choses, mais certainement pas le 10-bit (c'est pareil qu'H.264).

          • [^] # Re: Le profil Main 10

            Posté par  . Évalué à 1.

            Clairement, le 10 bits fait partie des requêtes fréquentes pour h265. Il y a de vraies chances de le voir émerger sur les décodeurs matériels.

            Tu imagines sérieusement un décodeur HW décoder du H.265 en 10-bit avant de savoir décoder du H.264 10 bits?

            Oui. Personne ne va s'amuser a bosser sur un ancien standard. h264 est utilisé, il n'est plus vraiment question de le voir évoluer.

            • [^] # Re: Le profil Main 10

              Posté par  (site web personnel) . Évalué à 3.

              Clairement, le 10 bits fait partie des requêtes fréquentes pour h265.

              Venant des mêmes qui avaient demandé 4:2:2 ou Spatial dans MPEG-2 Video?
              Pourquoi donc ne pas commencer avec H.264 "pour voir", vu que ça coûte bien moins cher et que ça permettait de se faire la main… Un peu trop facile de jeter comme ça "plus besoin de le voir évoluer", H.264 est encore la pour un bon moment (avant qu'on fasse du HW H.265 pas cher et économe en énergie…)

              On verra bien, une chose est sûre : le futur proche nous départagera :)

              • [^] # Re: Le profil Main 10

                Posté par  . Évalué à 4.

                Pourquoi donc ne pas commencer avec H.264 "pour voir", vu que ça coûte bien moins cher et que ça permettait de se faire la main…

                Parce que justement, passer un bloc hardware sur 10 bits, ca coûte cher. C'est du temps de développement, et cela nécessite de se remettre a travailler sur des blocs hardware qui sont plutôt destinés a l'écurie, développés avec d'anciennes technos qui ne sont pas forcément optimales en terme de développement.

                Bref, vraiment pas l'idéal. Il est plus facile d'aller de l'avant et de profiter du passage vers h265 pour se reposer ce genre de questions.

          • [^] # Re: Le profil Main 10

            Posté par  (site web personnel) . Évalué à 0.

            Pas plus : ça reste optionnel.
            Tu imagines sérieusement un décodeur HW décoder du H.265 en 10-bit avant de savoir décoder du H.264 10 bits?
            Bref : tu verras rien, faut arrêter le fantasme. H.265 n'apporte rien de ce côté, c'est identique (optionnel dans les deux cas).

            J'avais en tête que le H.265 en 10 bits, serait plus « standardisé », accessible au grand public et pas réservé aux pros (nouveau format BD par ex.). Je sais plus où j'ai lu ça, peut-être encore un FUD comme tu le dit si bien…

            En résumé, mon hypothèse est la suivante : Si il y a de plus en plus d'encodage en 10 bits (H.264 comme H.264), alors on pourrait imaginer/espérait des décodeurs HW qui gèrent le 10 bits :) (L'adoption de masse tout ça).

            Ca veut rien dire "Une autre amélioration du H.265 est la capacité de stockage des pixels en 10 bits"

            À ton écoute pour reformuler cette phrase ;)

            • [^] # Re: Le profil Main 10

              Posté par  (site web personnel) . Évalué à 2.

              J'avais en tête que le H.265 en 10 bits, serait plus « standardisé », accessible au grand public et pas réservé aux pros (nouveau format BD par ex.). Je sais plus où j'ai lu ça, peut-être encore un FUD comme tu le dit si bien…

              Je veux bien des sources.
              Parce que le 10-bit (tout comme le Chrom 4:2:2), je ne l'ai pas trop vu sorti des caméras pro et après en interne (à mon grand regret!), et je ne vois pas pourquoi ça en serait autrement avec H.265 "comme ça". Certes, ils ont balancé un profile 10 dès le départ (alors qu'ils s'en foutent de 4:2:2, ça fait mal à la qualité des couleurs…), mais perso je parie que les premiers décodeurs HW ne le supporteront pas… Et seront comme H.264.
              Bref : des sources sur ce soudain intérêt de la part de "tout le monde" sur le 10-bit (et qu'on m'explique pourquoi la 4:2:2 passe à la trappe aussi)

              Ca veut rien dire "Une autre amélioration du H.265 est la capacité de stockage des pixels en 10 bits"

              À ton écoute pour reformuler cette phrase ;)

              "Une autre amélioration du H.265 est une amélioration de la compression des pixels en 10 bits"?
              Parce que la phrase d'avant, elle sous-entend que H.264 ne supporte pas le 10-bit, alors qu'il supporte le 10-bit et même le 12-bit (le fait que le HW ne le supporte pas ne change rien à la capacité de H.264!)

              • [^] # Re: Le profil Main 10

                Posté par  (site web personnel) . Évalué à 4.

                Refaire un bloc hardware h264 en 10 bits peut vouloir dire tout refaire, pour seulement supporter le 10 bits. Cela représente presque autant de boulot que de faire un H265 tout neuf, mais en plus du 10 bits, tu as un standard tout neuf.

                "La première sécurité est la liberté"

              • [^] # Re: Le profil Main 10

                Posté par  . Évalué à 2.

                Si, sur les caméra High End, surtout en AVC-Intra (H.264 avec uniquement des trames Intra) 100 Mbps 10 bits. Mais ça n'a d'intéret que pour les pro. Pour le grand public (ie quelqu'un qui ne veut pas dépenser 100000€ euros dans une caméra et 2000000€ en stockage), les fichiers H.265 seront toujours en 422/8 bits/IBP-Frames.

        • [^] # Re: Le profil Main 10

          Posté par  . Évalué à 4.

          Je doute de l'intéret pour le grand publique. Le décodage HW en 10 bits est déjà disponible pour les matériel professionnel, car ca permet de retravailler l'image plus précisement. Pour le consommateur, il l'affichera en 8 bits sur sa télé ou son PC quoi qu'il arrive, donc le surcout d'implémenter le decodage hardware 10b en H.265 comme en H.264 ne se justifie pas.

          • [^] # Re: Le profil Main 10

            Posté par  . Évalué à 1.

            et pourquoi sa télé serait limité à 8 bits ? Que ce soit pour des vrais raisons, ou pour des raisons marketings hein.

            • [^] # Re: Le profil Main 10

              Posté par  (site web personnel) . Évalué à 4. Dernière modification le 30 janvier 2013 à 22:42.

              Parce que l'oeil humain n'est pas vraiment capable de voir plus (déjà qu'il a du mal avec 8 bit, mais bon 7 bits on ne sait pas vraiment faire en informatique et 6 bits ça commence à trop se voir), et que du coup l'utilisateur final il ne verra rien de mieux alors qu'il a payé 4x plus cher sa TV 10-bit, et que donc il en a rien à foutre.

              Le 10-bit pour l'utilisateur final, c'est de la branlette pour se faire plaisir tout seul, au même titre que que le 24-bit et/ou le 192 kHz pour l'audio : tout ça est utile pendant la phase d’acquisition et de traitement afin de ne pas perdre en précision lors des traitement (tu perds un bit de précision à chaque traitement, c'est même à se demander pourquoi on ne capture et stocke pas plutôt en 12-bit, AVC le permet déjà, mais bon 10-bit est déjà pas mal. Bon, si t'es un bourrin tu stockes en 16-bit ou 32-bit flottants mais la attention à l'espace disque :) ) donc pour les pros c'est très très utile si tu veux une bonne image après x traitements, mais très peu utile pour l’utilisateur final.

              Les LCD ont déjà du mal avec le 8 bits (ils ont la réputation d'être plutôt 6-bit pour les bas de gamme, 7-bit pour le milieu de gamme) et les gens ne voient pas la différence…

              Moralité : capturez et stockez en 10-bit (voire 12-bit pour vos super photos, les APN en faisant parfois, j'ai pas encore vu de caméra 12-bit mais ça doit bien exister quelque part), mais arrêtez de fantasmer sur votre acuité visuelle, plus que 8-bit ça sert pour les traitements intermédiaires, pas pour votre oeil (et donc pas la peine de transmettre la vidéo finale en 10-bit). Les images flashy, c'est x.v.Color qui est ton ami.

              On peut adapter le discours à l'audio 24-bit et/ou le 192 kHz, a FLAC contre les méchant codecs lossy qui casserait tout c'est horrible même en utilisant un bon encodeur, ou les cables HDMI qui doivent être plaqués or sinon tu perds des bits (si si, on m'a déjà sorti ça…), ainsi que des câble d'enceinte à 1 000 € le mètre (ne rigolez pas, j'en ai déjà vu et transporté), tu auras toujours des gens pour te dire que c'est super-méga-génial et qu'il voient une putain de de différence de la mort qui tue (et la majorité de ces gens se planteront royalement à un test en "aveugle", seuls quelques exceptions sont assez douées pour voir la différence, pas assez nombreuses pour construire des TV qui font plus de 8 bit tant que le marketing n'arrivera pas à vendre la chose comme "le nec plus ultra" du moment).

              • [^] # Re: Le profil Main 10

                Posté par  . Évalué à 3.

                Relis mieux mon commentaire (particulièrement la partie "marketing") avant de vouloir absolument me faire la leçon.
                Ca éviteras de répondre à coté.

                Mais si tu veux absolument rentrer dans ce débat :
                La qualité, l'oeil (et surtout le cerveau) a ceci de génial qu'il est capable de s'adapter.
                Regarde la qualité de la vidéo sur youtube, tout le monde s'en accomode alors que certaines sont "blocky".
                Par contre regarde les effets spéciaux fait il y a une quinzaine d'année : tout le monde les remarques maintenant (alors que c'était ultra réaliste on voit pas la différence quand c'est sorti).

                pour avoir fait de la photo, tu dis que l'on ne voit pas la différence avec 8 bits, mais je ne suis pas d'accord.
                Exemple très simple :
                tu prend une photo (même en 10 bits)
                -> avant plan une petite grotte
                -> plan du milieu une forêt (au dessus de la grotte)
                -> arrière plan un ciel bleu avec quelques nuages.

                Montre moi une photo avec un capteur 10 bit qui arrivera à voir, comme l'oeil, l'intérieur de la caverne, le vert des arbres, et le bleu du ciel.

                Même chose pour prendre l'intérieur d'un appart aussi éclairé que tu le vois, sans cramer l'extérieur ensoleillé.

                L'oeil à une dynamique exceptionnelle (13 à 14 f-stop en mode "tous les jours").
                Ce n'est pas juste pour se toucher que le HDR est sorti.

                • [^] # Re: Le profil Main 10

                  Posté par  (site web personnel) . Évalué à 2.

                  Mouais, toujours la même chose : les gens croient qu'ils ont des oreilles et des yeux plus que parfaits.
                  Rien de nouveau, la polémique sur les yeux n'étant pas nouvelle.

                  Chope-toi tout une chaîne de production et affiche en 10-bit, fait un test en aveugle, prend-toi la honte de ne pas avoir vu de différence, et on en reparle… Et le HDR sert surtout à trafiquer l'image ensuite car ton oeil ne verrait pas les parties sombres sinon (elle sont jolies les photos, mais mon oeil ne verrait pas ça dans la vraie vie : tu crois sérieusement que je verrai tous les détails entre les nuages et les néons qui m'en foutent plein la gueule ou plutôt du noir pour les nuages?). Je n'ai jamais dit que le HDR ou le 10-bit (voir 12-bit) était inutile (j'ai même dit le contraire), je dis juste que sur sa télé (ta question) c'est inutile (pour le consommateur final, sans retouche).

                  Donc pour te répondre :

                  Relis mieux mon commentaire (particulièrement la partie "marketing") avant de vouloir absolument me faire la leçon.

                  C'est rigolo, parce que je te parle sans marketing, et toi tu me balances du marketing à fond.
                  Tu veux parler marketing ou pas? Faudrait se décider.

                  Regarde la qualité de la vidéo sur youtube, tout le monde s'en accomode alors que certaines sont "blocky"

                  On peut parler sérieusement? S’accommoder ne veut pas dire ne pas voir la différence. La question est : vois-tu la différence entre 8 et 10 bit? Désolé, mais j'en doute.
                  Et il faut croire que même les marketeux en doutent, ils partent sur du 4k plutôt que sur du 10-bit pour le consommateur final, alors que toute la chaîne vers l'utilisateur final le permet (AVC a du 10-bit, HDMI a du 10-bit… Reste à vendre des TV 10-bit, mais pas foule croit pouvoir vendre ça…)


                  Après, le futur nous servira d'arbitre, reste à attendre quelques années.

                  • [^] # Re: Le profil Main 10

                    Posté par  . Évalué à 2.

                    Rien de nouveau, la polémique sur les yeux n'étant pas nouvelle.

                    Je te parle de dynamique, tu me parles de résolution angulaire …

                    Et le HDR sert surtout à trafiquer l'image ensuite car ton oeil ne verrait pas les parties sombres sinon

                    T'a jamais fait de photo toi.

                    Si, mon oeil voit des détails dans les nuages, et la forêt, et si je prend une photo, soit je prend la forêt bien, soit je prend les nuages bien.

                    D'ailleurs pour résoudre ce problème, avant le HDR, on utilisait (et on utilise toujours) des filtres dégradés de gris.

                    C'est rigolo, parce que je te parle sans marketing, et toi tu me balances du marketing à fond.

                    Ce qui est rigolo c'est que dans mon tout premier commentaire j'ai dis que ça pouvait être marketing. Et que c'est toi qui a décidé de répondre à coté de la plaque.

                    La question est : vois-tu la différence entre 8 et 10 bit? Désolé, mais j'en doute.

                    Sur la plage dynamique de mes photos ? oui.

                    Et il faut croire que même les marketeux en doutent, ils partent sur du 4k plutôt que sur du 10-bit pour le consommateur final, alors que toute la chaîne vers l'utilisateur final le permet (AVC a du 10-bit, HDMI a du 10-bit… Reste à vendre des TV 10-bit, mais pas foule croit pouvoir vendre ça…)

                    pour le end-user peut être, pour le pro c'est moins sûr :
                    http://h20331.www2.hp.com/Hpsub/cache/596803-0-0-225-121.html

              • [^] # Re: Le profil Main 10

                Posté par  (site web personnel) . Évalué à 0.

                Sauf qu'il y a vraiment une différence entre une vidéo encodé en 10 bits et en 8 bits, même si la source est de base en 8 bits ! En plus du gain de bitrate… cela permet vraiment de diminuer le color banding et de conserver plus de détails dans les scènes sombres, même si il y a conversion 10 bits --> 8 bits.

                Un exemple de comparaison, parmi tant d'autres…

    • [^] # Re: Le profil Main 10

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 28 janvier 2013 à 19:41.

      De plus cela améliore la compression (on pourrait penser le contraire !), car il faut moins de débit en 10 bits. (http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)

      Pourquoi alors ne pas faire du 12-bit avec la même "logique", puis du 16-bit puis du 32-bit? C'est un peu léger comme explication. Je ne dis pas que c'est faux (je ne sais pas), je dis juste que j'attend une explication du pourquoi 10.

      • [^] # Re: Le profil Main 10

        Posté par  . Évalué à 2.

        On m'a raconté (oui ma source est très certainement foireuse) que l'encodage CABAC des résidus serait plus performant. Ca fait un peu magie dit comme ca, pour le coup j'aimerais bien un truc un peu sérieux qui confirme/infirme la chose.

        • [^] # Re: Le profil Main 10

          Posté par  . Évalué à 4.

          Je m'auto réponds. Il y a un papier sur le dépot du comité qui traite de ce sujet.

          http://phenix.int-evry.fr/jct/doc_end_user/documents/12_Geneva/wg11/JCTVC-L0189-v2.zip

          Manifestement, le gain est amélioré en 10 bits.

          • [^] # Re: Le profil Main 10

            Posté par  . Évalué à 1.

            l'encodage CABAC des résidus serait plus performant

            On parle niveau perf ou qualité d'image ? Niveau perf, j'ai jamais analysé d'encodeur, mais au niveau du décodeur CABAC est toujours beaucoup plus lent que CAVLC. Sinon se sont deux méthodes de compressions sans perte qui manipulent des données numériques. Si tu encodes 00101101110, tu décoderas 00101101110.

            Manifestement, le gain est amélioré en 10 bits.

            Heu on à pas lu le même document alors : "However, an analysis of this property for HEVC using HM software model (HM-range-extensions) yields inconclusive results, as discussed in this contribution."

            • [^] # Re: Le profil Main 10

              Posté par  . Évalué à 3.

              On parle niveau perf ou qualité d'image ?

              On parle compression de données.

              Heu on à pas lu le même document alors : "However, an analysis of this property for HEVC using HM software model (HM-range-extensions) yields inconclusive results, as discussed in this contribution."

              Oui, mais ce que tend a montrer le document, toutes réserves émises, est que:

              All configurations above show BD-rate losses with the increase of internal bit depth contrary to the
              expected behaviour. The performances for Chroma components also largely follow a similar pattern.

              C'est bien le résultat qui semble contradictoire: on passe en 10 bits pour les résidus, cela devrait coûter plus cher en bande passante car plus d'info a encoder, et au final, ca coûte moins.

      • [^] # Re: Le profil Main 10

        Posté par  . Évalué à 4.

        Parce que les rendements sont exponentiellement décroissants ? (facteur 2 pour 1 bit ajouté) Ça explique pas « 10 », mais ça explique pourquoi il y a une limite supérieure.

      • [^] # Re: Le profil Main 10

        Posté par  . Évalué à 0.

        Je ne dis pas que c'est faux

        Tu peux. Le pdf n'indique rien de concret et les explications sont foireuses.

        Il est normal qu'encoder une source 10 bits sur 8 bits provoque une pénalité point de vu performance (et encore, je ne pense vraiment pas que ça soit significatif, cf chroma subsampling), autant pour le reste… Et la palme de la mauvaise foi : la source 10 bits encodée en 8 bits est magiquement re-étirée en 10 bits lors du décodage : absolument aucun intérêt à par massacrer volontairement les performances, et encore moins en sachant que nos écrans affichent 8 bits par canal, et non pas 10 (et encore, si ils sont de bonne qualité).

        • [^] # Re: Le profil Main 10

          Posté par  . Évalué à 3.

          Tu peux. Le pdf n'indique rien de concret et les explications sont foireuses.

          Ca confirme bien ce que je soupçonne : ce pdf est du marketing de la part d'ateme pour vendre leur encodeur.
          On supporte le 10 bits, c'est super génial, acheté chez nous vous aurez de la super qualité même sur vos sources 8 bits.

        • [^] # Re: Le profil Main 10

          Posté par  . Évalué à 1.

          Le pdf ne parle que de performance en compression, pas en temps de calcul.

  • # Pinaillage

    Posté par  (site web personnel) . Évalué à 4.

    Introduit par H264 et réservé aux profils les plus élevés, le codage arithmétique CABAC est désormais systématique pour remplacer les codages de type Variable Length Coding.

    On considère le gain du CABAC par rapport au VLC de l'ordre de 10%.

    Le codage CABAC est aussi un codage de type VLC. La nouveauté, c'est que les normes précédentes utilisaient un codage de Huffman, ou un codage arithmétique simple comme code VLC.

    L'intérêt du codage CABAC c'est qu'il dépend du contexte, c'est à dire qu'il ajuste automatiquement ses paramètres en fonction du contenu de l'image alors que le code de Huffman ou le codage arithmétique simple utilisent des paramètres constants (voire fixés une fois pour toute par la norme).

    • [^] # Re: Pinaillage

      Posté par  . Évalué à 4.

      H.264 utilise CA-BAC et CA-VLC, les deux sont "Context Adaptive".
      CAVLC est un codage entropique basé sur le codage "Huffman" (les symboles sont de tailles variables) alors que CABAC est un codage entropique arithmétique et binaire (les symboles sont des bits).

      • [^] # Re: Pinaillage

        Posté par  (site web personnel) . Évalué à 8.

        Oui, mais cela n'empêche pas que les deux sont des codes de type VLC. Cf. par exemple ce cours de théorie de l'information : le chapitre 5 est intitulé « Variable-length coding » et la section 5.3 est « Arithmetic Codes » (j'avais commencé par citer Wikipedia mais vu que cette page considère LZ comme un code VLC, j'ai trouvé que ça ne faisait pas très crédible…)

        Ce qui définit un code de type VLC, c'est que chaque symboles source est représenté par un nombre de bits différent après compression. Dans le cas du code de Huffman, ce nombre de bits est entier et la séquence qui représente un symbole donné est toujours la même. Dans le cas du code arithmétique, ce nombre de bits est fractionnaire et la séquence qui représente un symbole donné varie en fonction des symboles voisins. Dans les deux cas, chaque symbole source correspond à un nombre de bits variable après compression.

        Par opposition, un codage de type LZ77 n'est pas un code VLC puisque les symboles codés ont tous la même taille indépendamment des symboles source.

        PS: Je sais que les normes MPEG (et JPEG) utilisent le terme « VLC » pour désigner un code de Huffman. Ceci est principalement dû à des raisons historiques puisqu'à l'origine Huffman était le seul code VLC utilisé. Quand H264/JPEG2000 ont introduit le codage arithmétique, ils ont préféré garder l'appellation « VLC » pour la méthode historique afin de rester cohérent avec les normes existantes.

        • [^] # Re: Pinaillage

          Posté par  . Évalué à 2.

          J'avoue que je n'étais pas au courant de cette subtilité. J'ai effectivement du être mis en erreur par l'appellation" VLC" telle qu'elle est utilisée dans les standards.

        • [^] # Re: Pinaillage

          Posté par  . Évalué à 2.

          Le codage arithmétique peut être qualifié de "variable length coding" à raison, mais je ne suis pas sur que l'on puisse en dire autant de CABAC. C'est un type particulier de codage arithmétique, qui ne code que deux symboles : 0 et 1 (donc de taille fixe). La correspondance (ou la "binarisation") avec les symboles de tailles variables (les "bins" de cabac) est faite en dehors du décodeur.

  • # précision sous-pixel

    Posté par  . Évalué à 6.

    La prédiction inter-image évolue, notamment sur les Motion Vector indiquant le déplacement des pixels à effectuer sur l'image de référence. Ceux-ci sont désormais donnés en précision de quart de pixel (au lieu de demi-pixel en h264) et peuvent désormais être plus grand (-8192..8192).

    Il me semble que le quart de pixel était inclus dans H.264/AVC; il n'était pas disponible en MPEG-2, et optionnel (pas présent dans le premier profil simple mais à partir du profil Advanced Simple Profile) en "MPEG-4 part 2" (base de divx /xvid).

    En revanche, l'efficacité du quart de pixel est légèrement améliorée dans H.265/HEVC, je crois, grâce à un filtre d'interpolation plus adapté qu'en H.264/AVC.

    • [^] # Re: précision sous-pixel

      Posté par  . Évalué à 2.

      C'est tout à fait ça.

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

      • [^] # Et l'entrelacement ?

        Posté par  . Évalué à 2.

        En revanche, si les rumeurs que j'ai entendues pendant la phase de normalisation sont restées, il y a un changement significatif : la disparition des modes spécifiques pour les vidéos entrelacées ! Enfin la fin de ce mode issu des débuts de la télévision analogique et cathodique, et qui est désuet pour nos écran LCD ou autre (qui ne peuvent d'ailleurs pas le rendre correctement, introduisant moultes artefacts).

        Y aurai-t-il quelqu'un qui puisse confirmer ?

        • [^] # Re: Et l'entrelacement ?

          Posté par  (site web personnel) . Évalué à 4.

          Dans tes rêves.
          "pic_struct indicates whether a picture should be displayed as a frame or as one or more fields"
          "progressive_source_idc equal to 1 indicates that the scan type of the associated picture should be interpreted as progressive. progressive_source_idc equal to 0 indicates that the scan type of the associated picture should be interpreted as interlaced"

          Ah les vieilleries horribles que sont l'entrelacement et les frame rate non ronds… Toujours pas tués, et pas près de l'être.

        • [^] # Re: Et l'entrelacement ?

          Posté par  . Évalué à 4.

          Tu confonds avec le VP8

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # Et pour les brevets ?

    Posté par  . Évalué à 3.

    Ce n'est pas traité dans la dépêche, mais on a droit en commentaire je suppose.

    C'est pareil/mieux/pire que le H264 ?

    • [^] # Re: Et pour les brevets ?

      Posté par  . Évalué à 4.

      Même combat. Ils ne vont quand meme pas lâcher leur vache à lait sous prétexte que 2 libristes crient. Si le H.265 devient un standard de l'industrie comme le H.264 (ie si Microsoft, Apple, Google, et les fondeurs de processeur) se jettent dessus, les chances pour que ce codec (qui a déjà couté très cher en mise au point) soit libéré sont nulles. En tout cas, les détenteurs (MPEG-LA) n'en ont aucun intéret et continueront de faire payer la license aux constructeurs.

      • [^] # Re: Et pour les brevets ?

        Posté par  . Évalué à 2.

        les spécifs du h.264 sont librement disponible.
        Par contre, il y a des brevets logiciels dessus.

        • [^] # Re: Et pour les brevets ?

          Posté par  (site web personnel) . Évalué à 0.

          les spécifs du h.264 sont librement disponible.

          Euh non : 200 €

          • [^] # Re: Et pour les brevets ?

            Posté par  (site web personnel) . Évalué à 5.

            Note: The electronic version of this International Standard can be downloaded from the ISO/IEC Information Technology Task Force (ITTF) web site

            C'est gratuit.

            Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/

            • [^] # Re: Et pour les brevets ?

              Posté par  . Évalué à 2.

              Et celle d'h265 est donné en lien de la dépêche. Tu as plusieurs versions, il suffit de prendre la dernière en date.

              • [^] # Re: Et pour les brevets ?

                Posté par  (site web personnel) . Évalué à 1.

                Et celle d'h265 est donné en lien de la dépêche.

                Quel lien?
                Je dois être un peu idiot, mais j'ai suivi "H.265 specifications", je tombe sur http://phenix.int-evry.fr/jct/ , et sans avoir un compte, ben on ne peut pas télécharger grand chose (j'ai pu télécharger des compte-rendu de réunion), et les comptes sont restreints (il faut montrer pâtes blanches?).

                • [^] # Re: Et pour les brevets ?

                  Posté par  . Évalué à 4.

                  Tu vas dans all meetings, puis sur geneva, le premier de la liste, et la tu as tous les documents de travail du comité. Avec un control +f spécification, tu devrais rapidement trouver le document en question.

                  • [^] # Re: Et pour les brevets ?

                    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 29 janvier 2013 à 08:16.

                    argh, oui, je suis un peu idiot :(.
                    Mais par exemple, j'ai "AHG9: General HEVC high-level syntax cleanups" (L0043v3), mais ayant des marques de révision, et toujours pas la page de garde disant que c'est la version finale (et elle en change des choses dans le bitstream, faut pas se planter si on lope la dernière version qui rechange des choses!)

                    Je sais, je suis idiot, mais c'est pas terrible comme affichage pour ceux qui s’intéressent à la spécification telle que validée pour être la définitive.

                    • [^] # Re: Et pour les brevets ?

                      Posté par  . Évalué à 3. Dernière modification le 29 janvier 2013 à 09:16.

                      La version finale est pas encore publiée. La finalisation a été annoncée a la fin du dernier comité, je pense qu'il faut encore 1 ou 2 semaines que les derniers bugs soient remontés et corrigés. C'est ce qui c'est passé a chaque comité, la période post-comité servant à finaliser les décisions prises pendant le comité.

                      En tous cas, les specs qui sont sur ce site sont les dernières en date.

                      • [^] # Re: Et pour les brevets ?

                        Posté par  (site web personnel) . Évalué à 5.

                        Oui, mais les specs H264 étaient payantes quand finalisées.
                        Ici, je m’intéresse au prix de la chose (c'était la discussion).
                        La version finale sera-t-elle gratuite?

                        que les derniers bugs soient remontés et corrigés.

                        Voila, c'est bien le problème : la spec n'est pas encore sortie en fait (elle n'est pas figée), malgré la super-annonce de vendredi dernier. Attendons donc la sortie officielle pour voir la vraie spec + son vrai prix… Tu as pris un peu d'avance pour sortir le dépèche, et l'intitulé du lien dans la dépêche est faux : il point vers un draft, pas vers la spec (chez mes clients, ça change tout, un draft est un draft = n'a aucune valeur, une spec est une spec = c'est l'arbitre)

                        • [^] # Re: Et pour les brevets ?

                          Posté par  . Évalué à 2.

                          C'est bien pour ca que j'ai entamé la dépêche par "annoncée comme finalisée par l'ITU" parce que pour le coup, j'ai trouvé cette annonce un poil précipitée. C'est d'ailleurs ce que je passe mon temps à expliquer dans mon taf: la vraie finale toute propre et sans ambiguité arrivera dans quelques semaines.

                          Après pour le lien, vu que les versions finales des précédents comités ont été publiés sur ce site, je pensais qu'il ne ferait pas différemment pour le dernier comité mais effectivement, autant il faudra raquer.

                          • [^] # Re: Et pour les brevets ?

                            Posté par  . Évalué à 1.

                            Sur le site de l'ISO les documents sont toujours payants. Si le document de l'ISO à une correspondance chez l'ITU, alors on peut avoir la version "n-1" gratuitement en effet, mais du coups pour le H.265 même la version "n" n'est pas sortie, alors il va falloir patienter…

            • [^] # Re: Et pour les brevets ?

              Posté par  (site web personnel) . Évalué à 6.

              Argh, je m'y ferai jamais à leur bidouilles (la dernières fois que j'ai eu besoin des specs, j'ai dû payer et plus fait attention que la page a changé, maintenant c'est payant mais avec un lien pour le gratuit, pfff…)

  • # Round 2 : fight !

    Posté par  (site web personnel) . Évalué à 4. Dernière modification le 28 janvier 2013 à 14:23.

    Le libre a perdu le premier round concernant la bataille entre H264 et WebM.

    Concernant les futurs formats vidéos libres et sans brevets, avec pour objectif de concurrencer h265, il y a :

    • VP9 : le successeur de VP8 (utilisé dans WebM)

    One of the goals for VP9 is to reduce the bit rate by 50% compared to VP8 while having the same video quality

    VP8 est à peu près au niveau de H264, VP9 devrait être au niveau de H265.
    Un décodeur VP9 a été inclus en décembre dans Chromium.

    • Daala de la fondation Xiph (ogg vorbis, ogg theora, flac), développé en coopération avec Mozilla.

    The goal of the project is to provide a free to implement, use and distribute digital media format and reference implementation with technical performance superior to h.265.

    La bataille des formats vidéos devrait être mouvementée.

    • [^] # Re: Round 2 : fight !

      Posté par  (site web personnel) . Évalué à 5.

      VP8 est à peu près au niveau de H264,

      Tu en as d'autres des bonnes blagues comme ça?

      La bataille des formats vidéos devrait être mouvementée.

      C'est ce qu'on a dit quand Theora est sorti. Puis rien.
      C'est ce qu'on a dit quand Dirac est sorti. Puis rien.
      C'est ce qu'on a dit quand VP8 est sorti. Puis rien.
      Un truc de changé dans la façon de faire qui laisserai supposer un minimum de chance que le résultat change?

      • [^] # Re: Round 2 : fight !

        Posté par  . Évalué à 2.

        VP8 est à peu près au niveau de H264,
        Tu en as d'autres des bonnes blagues comme ça?

        Le VP8 est définitivement le second meilleur codec après le H264, donc si on ne peut pas dire que les deux sont à peu près du même niveau on dit quoi ?

        VP8 est souvent donné comme comparable au H264 profile "main", ce qui est pas très loin de la réalité. Un décodeur ainsi qu'un encodeur pas trop moches sont fournit sous licence BSD. L'intérieur du format est "simple" comparé à la monstruosité qu'est le H.264 si on veut l’implémenter complètement. La complexité d'un décodeur VP8 est ridicule comparé à un décodeur H.264, ce qui en fait une excellente alternative pour bien des usages, comme par exemple le web. Quand on voit comment l'encodeur H264 de youtube massacre la qualité des vidéos, l’intérêt d'utiliser ce format bardé de fonctionnalités et de brevets devient toute relative par rapport à l'usage du VP8…

        • [^] # Re: Round 2 : fight !

          Posté par  (site web personnel) . Évalué à 2.

          Le VP8 est définitivement le second meilleur codec après le H264, donc si on ne peut pas dire que les deux sont à peu près du même niveau on dit quoi ?

          Si pour toi un produit A est 1000x inférieur à un produit B, c'est être "du même niveau" juste parce qu'aucun produit C ou D arrive à faire mieux que le produit A, nous n'avons définitivement pas la même définition de "à peu près du même niveau"
          On dit qu'il est second (ce qui reste à prouver) et assez mauvais par rapport au premier. Le fait qu'il soit second ne veut clairement pas dire qu'il est du même niveau, ou alors on ne parle pas le même français.

          Quand on voit comment l'encodeur H264 de youtube massacre la qualité des vidéos,

          Superbe référence… Qui mène à quoi? Pas à une démonstration de supériorité d'un foramt sur l'autre en tous cas.

          Tiens, ça me rappelle les "super" démos comparatives Theora contre H264 de l'époque où on essayait de faire croire que Theora avait le même niveau que H264 et qui configuraient Theora avec des keyframes de 300 contre Youtube (pour comparer un format, prendre un compresseur mauvais qu'on ne maîtrise pas, bravo!) qui a des keyframe de 30… Ou comment "comparer" en faussant la comparaison pour faire gagner son poulain!
          (on peut aussi parler du "avant" la libéralisation, ou l’ancêtre de VP8 nous promettait de la HDTV a 100 bits/seconde… On2 faisait fort dans le marketing!)

          VP8 est dans les oubliettes au même titre que Theora, c'est un fait, et tout le monde a les yeux rivés que H265 et rien d'autre, c'est un autre fait. Que VP9 nous fasse un démo de ce qu'ils sont capables…

          • [^] # Re: Round 2 : fight !

            Posté par  . Évalué à 4.

            Si pour toi un produit A est 1000x inférieur à un produit B

            Ok ça commence bien…

            On dit qu'il est second (ce qui reste à prouver)

            Pas vraiment. Quel est ton second choix alors ?

            Superbe référence… Qui mène à quoi? Pas à une démonstration de supériorité d'un foramt sur l'autre en tous cas.

            Qui mène à deux choses:
            - Le VP8 à sa place pour certain usage, quand on souhaite privilégier la simplicité de l'implémentation par rapport à une palanquée de fonctionnalité qu'on n'utilisera pas de toute manière. Sans même parler de la possibilité de décoder légalement du VP8 dans son navigateur…
            - A quoi bon mettre en avant le fait que le H.264 est visuellement meilleur si c'est pour ne pas en profiter ? J'ai voulu dire que Youtube n'en rien à carrer de la qualité de la vidéo (cf leur encodeur infâme) car c'est la vitesse d'encodage qui est préférée. Logique quand on doit encoder des heures de vidéos chaque seconde (haha).

            Ton raisonnement m'horrifie. H.264 est meilleur, brûlons tous ceux qui essayent de faire mieux ? Belle leçon de technologie.

            • [^] # Re: Round 2 : fight !

              Posté par  (site web personnel) . Évalué à 2.

              Ok ça commence bien…

              C'est bien toi qui traduit "second" par "du même niveau", je n'y peux rien. Je ne fais que démontrer par l'absurde l'absurdité d'une telle affirmation.

              Pas vraiment. Quel est ton second choix alors ?

              MPEG-4 Visual (poussé à bout par l'encodeur Xvid?)
              Mais en fait je m'en fout : je m'interesse au premier choix en fait, le second est comme le dernier : à ne pas utiliser.

              Le VP8 à sa place pour certain usage, quand on souhaite privilégier la simplicité de l'implémentation par rapport à une palanquée de fonctionnalité qu'on n'utilisera pas de toute manière.

              Pour ça, tu as une magnifique invention : les profiles. Je t'invite à te renseigner, exemple :
              http://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles
              "Constrained Baseline Profile (CBP)
              Primarily for low-cost applications, this profile is most typically used in videoconferencing and mobile applications. It corresponds to the subset of features that are in common between the Baseline, Main, and High Profiles."

              Forcément, en faisant comme VP8, c'est plus simple :).

              Sans même parler de la possibilité de décoder légalement du VP8 dans son navigateur…

              99.999% des gens lisent légalement du H264 dans leur navigateur… Surtout que la licence pour les navigateur est à 0$ pour le moment.

              brûlons tous ceux qui essayent de faire mieux ? Belle leçon de technologie.

              Non, tu veux ne pas voir la réalité : VP8 n'a rien pour lui. La licence H264 est déjà la car H264 existe depuis longtemps. Aucun avantage pour VP8. Techniquement, c'est inférieur, même en "pas cher" (cf les profiles). Encore rien.
              Je dis juste que c'est à mourir de rire de mettre en avant un truc qui n'a rien pour lui dans la réalité.

              Amène moi un seul argument en faveur de VP8 dans la réalité… Et donc avec une licence H264 payée, et donc avec un gain de licence qui ne se fait pas annulé par une conso de bande passante, et j'en passe.

              Le truc rigolo : pas foule n'utilise VP8, mais on ne se pose pas de questions?


              J'aimerai un format libre de chez libre, mais voila, il faut revenir sur terre : je ne vais pas payer plus cher (en bande passante) pour le masochisme. Le jour où les libristes sortiront un format performant (pour l'époque), il sera utilisé. Aujourd’hui, VP8 ne répond pas du tout à ça, même Google et Mozilla l'admettent (Google avait annoncé le drop d'H264 de Chrome, et rien. Mozilla refusait H264, et a changé d'avis).

              • [^] # Re: Round 2 : fight !

                Posté par  . Évalué à 2.

                Pour avoir implémenté les deux, le VP8 est fonctionnellement équivalent à un H.264 "main profile", tout en étant bien moins complexe en offrant une qualité d'image comparable. Et pour le reste franchement, "no comment".

              • [^] # Re: Round 2 : fight !

                Posté par  (site web personnel) . Évalué à 6.

                je ne vais pas payer plus cher (en bande passante) pour le masochisme

                Pas besoin d'être masochiste pour utiliser des formats libres. Aimer la liberté est suffisant.

              • [^] # Re: Round 2 : fight !

                Posté par  . Évalué à 8.

                Amène moi un seul argument en faveur de VP8 dans la réalité…

                Et bien vraiment très concrètement, grâce à VP8 je peux voir des vidéos de chatons sur Youtube et Koreus sans avoir Flash installé dans Firefox.

                Rien que pour ça, VP8 poutre H264. Et de très loin !!! Surtout que la qualité de la vidéo est la même.

              • [^] # Re: Round 2 : fight !

                Posté par  . Évalué à 1.

                Mais en fait je m'en fout : je m'interesse au premier choix en fait, le second est comme le dernier : à ne pas utiliser.

                Je trouve bizarre cette discussion. De mon point de vu de néophyte, il y a 2 axes pour comparer des formats/encodeurs : la qualité (le fait d'avoir une retranscription la plus proche possible de l'originale) et l'espace disque. Il y en a probablement d'autres comme la performance en lecture ou en écriture. Je ne vois pas comment un format pourrait être meilleur que tous dans chaque domaine (puisque c'est ce qui ressort du « le second c'est de la merde »).

                De plus il y a un paquet de format d'image, le jpeg le plus utilisé sort beaucoup d'artefacts dès qu'il est un peu compressé, png est super pour des images avec de grandes surfaces d'une même couleur, tiff/bmp ne compressent pas pour ainsi dire, etc Je vois pas comment sans avoir de format d'image qui se démarque réellement des autres, on peut créer un format de vidéo qui déchire tout les autres.

                Bref tu aurais pas oublié de te rasé ce matin dans ta caverne ?

                Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                • [^] # Re: Round 2 : fight !

                  Posté par  (site web personnel) . Évalué à 4. Dernière modification le 28 janvier 2013 à 23:13.

                  De mon point de vu de néophyte, il y a 2 axes pour comparer des formats/encodeurs : la qualité (le fait d'avoir une retranscription la plus proche possible de l'originale) et l'espace disque.

                  Ben non : c'est un seul axe la, que tu donnes.
                  La qualité dépend de l'espace disque.

                  Je ne vois pas comment un format pourrait être meilleur que tous dans chaque domaine (puisque c'est ce qui ressort du « le second c'est de la merde »).

                  Un autre peut être mieux dans un autre domaine.
                  Mais : dans quel domaine VP8 est meilleur?

                  Bref tu aurais pas oublié de te rasé ce matin dans ta caverne ?

                  Non, je regarde juste la réalité : VP8 arrive trop tard, a 10 ans de retard (et donc la licence gratuite ne marche pas, il faut se taper l'autre dans tous les cas, à cause de l'historique). J'attend toujours un vrai argument dans la vraie vie (celui de Firefox est à mourir de rire : c'est un choix de Mozilla, pas du format. D'ailleurs, ils changent d'avis, et cet "argument" va tomber, sans coût supplémentaire pour Mozilla, comme quoi c'était du FUD).

                  Juste posez vous une question : tout le monde ou presque s'en fout de VP8, pourquoi? Tout le monde regarde H265 et ne connait même pas VP9, pourquoi?

                  • [^] # Re: Round 2 : fight !

                    Posté par  . Évalué à 2.

                    J'attend toujours un vrai argument dans la vraie vie (celui de Firefox est à mourir de rire : c'est un choix de Mozilla, pas du format. D'ailleurs, ils changent d'avis, et cet "argument" va tomber, sans coût supplémentaire pour Mozilla, comme quoi c'était du FUD).

                    Oui c'est un choix de Mozilla, que j'approuve. Mais ils ont fait ce choix à cause d'une particularité du format H264 ! Donc peu importe que ce soit un choix de Mozilla ou non, le fait est que COMPTE TENU que H264 est bardé de brevets, je ne peux pas voir de vidéo de chatons sur Youtube. Donc H264 = poubelle.

                    Désolé mais pour moi c'est très concret. Tu ne parles que de technique, mais pour moi ce n'est pas la priorité.

                    Et puis le fait que effectivement Firefox va pouvoir lire du H264, à ma connaissance c'est via l'OS. Or moi sur Linux je ne suis pas sûr d'avoir de lib pour lire H264 (?) donc je ne pourrais peut-être toujours pas lire de H264 sur Youtube.

                    En attendant avec VP8, pas de problèmes.

                    • [^] # Re: Round 2 : fight !

                      Posté par  (site web personnel) . Évalué à 6.

                      Or moi sur Linux je ne suis pas sûr d'avoir de lib pour lire H264 (?) donc je ne pourrais peut-être toujours pas lire de H264 sur Youtube.

                      http://fr.wikipedia.org/wiki/X264
                      Le problème de H264 c'est le fait qu'il est lardé de brevets logiciels. Il n'y a pas de problème de licence puisque x264 est libre.

                  • [^] # Re: Round 2 : fight !

                    Posté par  . Évalué à 4.

                    Comprends bien que je me fou de VP8. Mon commentaire n'en tenais pas trace.

                    La qualité dépend de l'espace disque.

                    Oui et tout les algo ont la même courbe ? Mais ensuite il y en a d'autres, la possibilité (ou la facilité) de faire du streaming par exemple, la performance lors de la compression ou de la décompression (logiciel ou hardware) et probablement un tas que le néophyte que je suis en la matière n'imagine même pas.

                    Un autre peut être mieux dans un autre domaine.

                    Oui mais de quel domaine tu parle ? Tu dis que H26{4,5} sont les meilleurs sans donner de domaine particulier et surtout en disant que tout le reste (que ce soit VP8 ou MPEG-4 Visual) c'est du pipi de chat.

                    Juste posez vous une question : tout le monde ou presque s'en fout de VP8, pourquoi? Tout le monde regarde H265 et ne connait même pas VP9, pourquoi?

                    Il y a tellement peu de monde qui utilise autre chose (VP8 ou autre relire la première ligne) que mediainfo est inutile, n'est ce pas ?

                    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

                    • [^] # Re: Round 2 : fight !

                      Posté par  (site web personnel) . Évalué à 2.

                      Comprends bien que je me fou de VP8. Mon commentaire n'en tenais pas trace.

                      Tu cherches un concurrent qui serait meilleur sur un point particulier. remplace "VP8" par "Tartampion", mon commentaire reste valide.

                      Oui et tout les algo ont la même courbe ?

                      Non. Mais j'attends une démo qu'un autre est meilleur à un endroit donné. Vraiment meilleur, hein, pas une broutille dans 0.1 des cas d'utilisation qui ferait que son coût est énorme par rapport à son gain.

                      Mais ensuite il y en a d'autres, la possibilité (ou la facilité) de faire du streaming par exemple, la performance lors de la compression ou de la décompression (logiciel ou hardware) et probablement un tas que le néophyte que je suis en la matière n'imagine même pas.

                      Yep. Et le miracle d'H264 est qu'il a réussi tout ça…

                      Oui mais de quel domaine tu parle ?

                      Justement, c'est ma question!!!
                      Résumons : je dis que je ne vois aucun problème à avoir un autre format qui soit meilleur qu'H264, mais j'attends un nom de domaine. Tu me demandes à moi, mais demandes aux adorateurs de VP8 plutôt! Aujourd'hui, H264 est le meilleur partout (non, le fait de ne pas avoir de brevet dans VP8 n'est pas un avantage, car les gens, exceptés quelques libristes intégristes, payent déjà leur licence H264 et donc le coût reste, c'est la vraie vie qui prend en compte la date d'arrivée d'un format).

                      Il y a tellement peu de monde qui utilise autre chose (VP8 ou autre relire la première ligne) que mediainfo est inutile, n'est ce pas ?

                      Le poids de l'histoire surtout.
                      Si tu veux un listing : MPEG-2 Video est toujours la (et je fais toujorus des évolutions dessus), plus personne n'utilise MPEG-4 Visual, et H.264 est le domaine maître. Reste VC-3 (DNxHD) pour le stockage intermédiaire (faible compression contre faible complexité), et JPEG 2000 (le ciné qui peut se permettre le hors de prix). MediaInfo a surtout des évolution sur les conteneurs (la, c'est la guerre en cours, toujours).
                      Les faits, rien que les faits : H264 a la suprématie dans les formats vidéos.

                      • [^] # Re: Round 2 : fight !

                        Posté par  . Évalué à 10.

                        Je suis d'accord avec toi sur le fait qu'h264 est nettement plus performant que VP8. En même temps, la vidéo est tellement rempli de brevets qu'il me semble quasiment impossible d'innover dans ce domaine sans tomber un brevet.

                        Par contre, la "faille" dans ton raisonnement, c'est ca:

                        les gens, exceptés quelques libristes intégristes,

                        C'est la dessus où tu te goures. VP8 a sa place en tant que codec vidéo car il est sans brevet. Evidemment, si l'industriel a à payer un surcout de bande passante, il étudiera le compromis bande passante a payer vs licence. Par contre, s'il ne paie pas la bande passante, ca ne peut être qu'a son avantage.

                        Tu cherches un domaine ou c'est interessant ? La visiophonie. Le flux passe directement de l'utilisateur a l'utilisateur. Pas de surcout pour l'industriel, la licence est en cadeau. Et la, ô miracle: skype utilise VP8, xmpp envisage de l'utiliser.

                        J'ai l'impression qu'il te semble irrationnel de chercher a économiser le prix d'une licence alors que c'est tout a fait normal.

                        Pour moi, on assiste aujourd'hui à une fissure dans les codecs vidéos: d'un coté les formats web: peu optimisé mais libre d'accès, et de l'autre, les format broadcasters qui cherchent à optimiser la compression et la scalabilité des flux.

                        • [^] # Re: Round 2 : fight !

                          Posté par  (site web personnel) . Évalué à 3.

                          Je suis d'accord avec toi sur le fait qu'h264 est nettement plus performant que VP8.

                          C'est surtout la que je veux en venir ;-).

                          En même temps, la vidéo est tellement rempli de brevets qu'il me semble quasiment impossible d'innover dans ce domaine sans tomber un brevet.

                          Je n'ai pas dit le contraire. C'est la grosse merde, et je ne dirai jamais le contraire (a qualité équivalente, je préfère largement, sans hésitations, un format libre!!! Mais je ne suis pas maso au point de me couper un bras pour utiliser un format libre pour le principe)

                          Tu cherches un domaine ou c'est intéressant ? La visiophonie. Le flux passe directement de l'utilisateur a l'utilisateur. Pas de surcout pour l'industriel, la licence est en cadeau.

                          Et donc la, on aurait trouvé une utilité! Ce qui me fait réagir est qu'on dise une connerie du style "VP8 est du même niveau qu'H264". Non, il ne l'est pas, pourquoi vouloir faire croire le contraire?

                          Après, ok, il est intéressant pour un besoin précis, donc parlons de son intérêt à l'endroit où il est intéressant, et arrêtons de fantasmer sur du broadcast/youtube/que sais-je en VP8 ou des délires genre "je peux pas lire du H264" (si, tu peux).

                          Bref, argumentons avec des vrais arguments. Je ne suis pas juriste, j'ai du mal à suivre le document sur les royalties, mais si celui-ci empêche Skype d'encoder légalement en utilisant ce qui est dispo (donc pas un "bouh je veux pas utiliser H264 pour le principe" à la mode Mozilla qui retourne ensuite sa veste, mais un vrai empêchement qui ne change pas suivant ce qu'on a envie de faire, hein), yep VP8 a alors toute sa place et utilisons-le la où il a sa place.

                          Si VP8 répond a un besoin, pourquoi mentir sur ses capacités plutôt que de parler de ses véritables qualités dans la vraie vie avec un exemple d’intérêt du prix de la licence en plus par rapport au coût du bitrate plus élevé pour la même qualité? C'est le seul message que je veux faire passer. (bon, du coût, je constate que l’intérêt de VP8 est de faire transiter le coût du fournisseur de logiciel vers le FAI à cause du débit en plus, sympa… VP8 sert donc si je suis vos arguments à faire peser le coût sure un tiers, mais autant être honnête et l'accepter, les gens aime le "gratuit" et il faut vivre avec)

                          PS : par contre, ça serait pas mal de faire une vraie spécification (car le pavé "tenez le code source et démerdez-vous (et surtout, si une personne s'amuse à faire une spec et qu'il se trompe, c'est le logiciel buggué qu'on a pas trop regardé qui fait foi)" à la mode VP8 ou Opus, c'est pas super vendeur). Car la, les H.26x ou AAC sont un pur bonheur comparé à "ça".

                        • [^] # Re: Round 2 : fight !

                          Posté par  (site web personnel) . Évalué à 3.

                          J'ai l'impression qu'il te semble irrationnel de chercher a économiser le prix d'une licence alors que c'est tout a fait normal.

                          Non, pas du tout : ça me semble irrationnel de payer plus cher pour un truc, juste pour le principe (oui, pour moi, le libre est un outil parmi d'autres pour développer ce qu'il y a de meilleur, pas une religion), et tous les exemples qu'on me donne sont généralement avec un coût total prohibitif pour une entité (pour Google aussi, sinon ils auraient depuis des lustres passé tous les user-agent Chrome en VP8 par défaut sur youtube, si il ne le font pas, c'est pour quelle raison?), est-ce si illogique de dire que seuls les intégristes peuvent s'amuser à payer (et pas trop, car leur budget est limité, donc ça ne va pas loin) plus cher une même prestation?

                          Et justement, contrairement aux autres, tu donnes un exemple précis où le coût pour une entité en devient inférieur (même si le coût total de tout le monde en devient plus cher, ce n'est pas le problème de l'entité qui code), et la, ça prend tout son sens. C'est en donnant de bons exemples de la vraie vie et pas de la théorie religieuse qu'on peut convaincre plus facilement un interlocuteur.

        • [^] # Re: Round 2 : fight !

          Posté par  . Évalué à 5. Dernière modification le 28 janvier 2013 à 23:50.

          Quand on voit comment l'encodeur H264 de youtube massacre la qualité des vidéos, l’intérêt d'utiliser ce format bardé de fonctionnalités et de brevets devient toute relative par rapport à l'usage du VP8

          Techniquement, le VP8 est pire que le H.264 pour la qualité de l'image. C'est juste youtube qui utilise mal son encodeur H.264…

          Quant aux brevets, le VP8 est tellement proche du H.264 sur de nombreux points (c'est copié/collé en grande partie en fait) que la MPEG-LA avait décidé de mener son enquête… (c'est arrivé pour le VC-1 : au début il était 'royalty free" puis quand il a été découvert qu'il était très proche du MPEG-4 ASP, les détenteurs de brevets et le MPEG-LA ont exigé des royalties, et les ont obtenues !)

          http://www.guardian.co.uk/technology/blog/2011/mar/04/justice-department-antitrust-mpeg-la-vp8
          http://arstechnica.com/business/2011/07/mpeg-la-12-companies-own-patents-essential-to-googles-vp8-codec/

          "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

          • [^] # Re: Round 2 : fight !

            Posté par  (site web personnel) . Évalué à 5. Dernière modification le 29 janvier 2013 à 10:38.

            C'est juste youtube qui utilise mal son encodeur H.264…

            En fait, c'est surtout que Youtube a des contraintes (support par le HW de certaines features, profiles, levels, et surtout débit le plus faible possible tout en ayant un max de keyframes) qui sont "oubliées" quand les gens essayent de comparer avec leur compression à eux (qui zappent littéralement les contraintes pour mettre tout au max, sans essayer la même chose avec H264…)

            Ceux qui ont essayé de compresser en VP8 avec les mêmes contraintes de débit pleurent sur la qualité, et se promettent de ne plus jamais toucher à la chose.

            c'est arrivé pour le VC-1

            Chut ;-)

        • [^] # Re: Round 2 : fight !

          Posté par  . Évalué à 3.

          Quand on voit comment l'encodeur H264 de youtube massacre la qualité des vidéos,

          Ben, il faut sortir un peu le dimanche…;-) Youtube réencode toutes les vidéos avant de les mettre en ligne. Donc, oui, baisse de qualité au final.

          Et pour info, Youtube utilise l'x264 pour réencoder les flux au format AVC…Pas vraiment une merde quand même.

    • [^] # Re: Round 2 : fight !

      Posté par  . Évalué à 3.

      Le constructeurs travaillent tous sur des codeurs/décodeurs matériels pour HEVC, les premières versions ont été présentées au CES le mois dernier. Tout le mode se fout plus ou moins de VP9, et encore plus de DAALA, à mon avis la guerre est déjà perdu. En fait elle n'a même jamais eu lieu…

    • [^] # Re: Round 2 : fight !

      Posté par  . Évalué à 6.

      VP8 est à peu près au niveau de H264

      Du H.264 Baseline, oui. Sinon, il est très très très très très (très) loin derrière. Et il ne risque pas de rattraper son concurrent, vu que c'est une limitation du standard VP8…

      Overall, VP8 appears to be significantly weaker than H.264 compression-wise. The primary weaknesses mentioned above are the lack of proper adaptive quantization, lack of B-frames, lack of an 8×8 transform, and non-adaptive loop filter. With this in mind, I expect VP8 to be more comparable to VC-1 or H.264 Baseline Profile than with H.264. Of course, this is still significantly better than Theora, and in my tests it beats Dirac quite handily as well.

      http://x264dev.multimedia.cx/archives/377

      "Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)

  • # En route pour la joie...

    Posté par  . Évalué à 1.

    A rajouter dans la dépêche…une branche expérimentale de libav permet déjà le décodage des flux HEVC. Le travail a débuté via le GsoC de l'été dernier.

    Développé par un froggy en plus…yeah.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.