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 :
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 :
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.
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 :
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.
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
- H.265 sur Wikipédia (1476 clics)
- H.265 specification (428 clics)
# Consommation CPU
Posté par claudex . É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 Anonyme . Évalué à 4.
ils ne sont pas encore commercialisés, attend un peu.
[^] # Re: Consommation CPU
Posté par claudex . É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 Stibb . É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 Gui13 (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 Gui13 (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 Xaapyks . É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 Bruno Michel (site web personnel) . Évalué à 10.
Avec un lien : http://linuxfr.org/aide#aide-imgcertificatssl
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 Anonyme . Évalué à 6.
Payer pour les audits de CA-Cert ?
[^] # Re: Images?
Posté par MrLapinot (site web personnel) . Évalué à 8.
Utiliser un certificat gratuit de chez StartSSL ?
[^] # Re: Images?
Posté par Anonyme . É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 Bruno Michel (site web personnel) . Évalué à 10.
Je confirme. Cf http://linuxfr.org/aide#aide-autrecertificatssl notamment.
[^] # Re: Images?
Posté par coïn . Évalué à 8.
choisir une solution non fonctionnelle parce qu'elle est pus libre, c'est ça l'intégrisme.
[^] # Re: Images?
Posté par rewind (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 djano . Évalué à 5.
https://bugzilla.mozilla.org/show_bug.cgi?id=215243
[^] # Re: Images?
Posté par Tobu . É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 Christophe Merlet (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 djano . Évalué à 6.
Ah bon, tu ne peux pas recompiler Firefox?
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 Anonyme . É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 Krunch (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 rewind (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 Krunch (site web personnel) . Évalué à 5.
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 rewind (Mastodon) . Évalué à -1.
C'est marrant, c'est pas ce que j'ai lu dans le lien que tu as donné. Je cite :
Que je traduirais par :
[^] # Re: Images?
Posté par Bruno Michel (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 Anonyme . É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 Larry Cow . É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 barmic . É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 Larry Cow . Évalué à 2.
Ce n'est pas la même chose. Cf. https://bugzilla.mozilla.org/show_bug.cgi?id=688383
[^] # Re: Images?
Posté par Marotte ⛧ . É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 BAud (site web personnel) . Évalué à 2.
ajouté comme méthode sur http://linuxfr.org/suivi/proposer-une-page-d-aide-a-la-configuration-https#comment-1426816
merci.
[^] # Re: Images?
Posté par Thomas Debesse (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 Bruno Michel (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 Thomas Debesse (site web personnel) . Évalué à 3.
C'est bizarre, lorsque j'affiche le certificat je lis
CN=linuxfr.orgau lieu deCN=*.linuxfr.org.Aussi, je lis
CN=linuxfr.orgpourhttps://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 Bruno Michel (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.orgapparaît dans le champ Subject Alt Name, ça doit compter quand même, non ?[^] # Re: Images?
Posté par Cyrille Pontvieux (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:
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 ribwund . Évalué à 3.
C'est quoi l'interet du sous-domaine ?
[^] # Re: Images?
Posté par Bruno Michel (site web personnel) . Évalué à 7.
Une sombre histoire de sécurité, à cause des SVG qui peuvent embarquer du JS.
[^] # Re: Images?
Posté par groumly . Évalué à 0.
Servir les images en http?
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
[^] # Re: Images?
Posté par claudex . É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 Bruno Michel (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 haleth . Évalué à -8.
Habawé, t'as raison, macos est un sacré problème.
Donne pas le baton pour te faire battre..
[^] # Re: Images?
Posté par Gui13 (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 pseudovalide . Évalué à -4.
Non mais avec une voiture on emprunte pas les pistes cyclabes.
abaoué abaoué
[^] # Re: Images?
Posté par Marotte ⛧ . É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 Anonyme . É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 Gui13 (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 Psychofox (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 Gui13 (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 Anonyme . Évalué à 1.
Ça fait un bon moment que j’ai quitté Arch.
What The Fuck ?!
[^] # mac os ?
Posté par pseudovalide . É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 alpha_one_x86 (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/
[^] # Re: 50% de bande passante en mois
Posté par claudex . Évalué à 10.
Et un décodeur, et que YouTube paye la licence.
« 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: 50% de bande passante en mois
Posté par alpha_one_x86 (site web personnel) . Évalué à 6.
A quand un format libre équivalent?
Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/
[^] # Re: 50% de bande passante en mois
Posté par gnuzer (site web personnel) . Évalué à 10.
Je ne sais pas, mais à en croire des posts sur le forums de phoronix, VP9 et Daala avancent bien : http://phoronix.com/forums/showthread.php?77123-ITU-Approves-H-265-HEVC-Video-Codec&p=308848#post308848
On lit des choses encourageantes sur les forums de doom9 (voir les liens sur le forum de phoronix).
[^] # Re: 50% de bande passante en mois
Posté par benpro (site web personnel) . Évalué à 2.
Ah tiens, bonne info ! Je ne pensais pas qu'ils étaient déjà en train de travailler sur le successeur de VP8. VP8 est vraiment pas mal, mais a encore beaucoup de retard comparé au H.264. (Je ne sais pas si cela vient des encodeurs – j'utilise vpxenc – ou du codec lui même de part ses spécificités).
[^] # Re: 50% de bande passante en mois
Posté par Stibb . Évalué à 3.
oui une génération de retard par rapport au H.264, malheureusement.
[^] # Re: 50% de bande passante en mois
Posté par fredix . Évalué à 4.
Apparemment il y a un DEC/ENC sous licence BSD : http://hevc.hhi.fraunhofer.de/ https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk/
[^] # Re: 50% de bande passante en mois
Posté par portninwak_ . Évalué à 5.
Oui, l'encodeur/décodeur de référence (utilisé lors du processus de définition et de normalisation) est sous licence BSD, mais l'utilisation des technos H.265 est soumise à royalties. Comme ce fut le cas pour H.264.
[^] # Re: 50% de bande passante en mois
Posté par fredix . Évalué à 2.
Donc si ffmpeg intègre ce code ils vont se faire taper ?
[^] # Re: 50% de bande passante en mois
Posté par Renault (site web personnel) . Évalué à 6.
Pas forcément.
Cela n'est valable que dans les pays reconnaissant les brevets logiciels. Les projets de ce type s'ils sont situés en Europe ils ne seront pas menacés (comme pour le MP3 ou le H264 que VLC et d'autres projets libres savent lire et ne sont pas inquiétés en Europe).
[^] # Re: 50% de bande passante en mois
Posté par ribwund . Évalué à 2.
Et surtout il me semblait que les questions de brevet/royalties visaient principalement les produits finaux, pas les bibliothèques.
[^] # Re: 50% de bande passante en mois
Posté par haleth . Évalué à 3.
ffmpeg intègre pas vraiment de code lié au 264 / mp3
Il utilise des libs (respectivement libx264 & libmp3lame)
[^] # Re: 50% de bande passante en mois
Posté par ✅ ffx . Évalué à 9.
ça fait combien en semaines ?
[^] # Re: 50% de bande passante en mois
Posté par Moonz . Évalué à 6.
4 fois moins, donc à peu près 12%
# Resolution d'image
Posté par Prosper . Évalué à 4.
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 haleth . É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 Prosper . Évalué à 1.
Ah ok j'avais compris, 4k2k = Résolution 4k et 2k .
[^] # Re: Resolution d'image
Posté par flagos . É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 benpro (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 Zenitram (site web personnel) . Évalué à 9.
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.
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 Nicolas Boulay (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 Zenitram (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.
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 Nicolas Boulay (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 Zenitram (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 Nicolas Boulay (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 Zenitram (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 benpro (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 flan (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)…
[^] # Re: Resolution d'image
Posté par neil . Évalué à 6.
Sauf que tes yeux ne sont pas paralysés et que des dizaines d’aires corticales traitent le signal dans le temps après les photorécepteurs. Donc même si ton acuité théorique/bateau/naïvement mesurée est d’1/60 degrés, l’hyper-acuitée engendrée par le cerveau sera nettement supérieure. Genre 5 à 10 fois supérieure pour une simple perception d’alignement.
# Le profil Main 10
Posté par benpro (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 M . Évalué à 4.
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 claudex . É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 M . Évalué à 7.
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 Tobu . É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 M . Évalué à 2.
Un truc qui explique en détail et pas un truc de marketeux.
D'ailleurs je suis pas le seul a me poser la question :
https://linuxfr.org/news/h-265-est-finalise#comment-1426763
[^] # Re: Le profil Main 10
Posté par Stibb . Évalué à 1.
L'H.264 gère le 10 bit (Hi10P).
[^] # Re: Le profil Main 10
Posté par benpro (site web personnel) . Évalué à 2.
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 Zenitram (site web personnel) . Évalué à 1.
Ce même matos ne supporte pas H.265, donc?
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 flagos . É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.
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 Zenitram (site web personnel) . Évalué à 3.
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 flagos . Évalué à 4.
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 benpro (site web personnel) . Évalué à 0.
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).
À ton écoute pour reformuler cette phrase ;)
[^] # Re: Le profil Main 10
Posté par Zenitram (site web personnel) . Évalué à 2.
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)
"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 Nicolas Boulay (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 Stibb . É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 Stibb . É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 briaeros007 . É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 Zenitram (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 briaeros007 . É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 Zenitram (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 :
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.
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 briaeros007 . Évalué à 2.
Je te parle de dynamique, tu me parles de résolution angulaire …
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.
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.
Sur la plage dynamique de mes photos ? oui.
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 benpro (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 Zenitram (site web personnel) . Évalué à 4. Dernière modification le 28 janvier 2013 à 19:41.
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 flagos . É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 flagos . É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 FluffyHamster . Évalué à 1.
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.
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 flagos . Évalué à 3.
On parle compression de données.
Oui, mais ce que tend a montrer le document, toutes réserves émises, est que:
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 Moonz . É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 FluffyHamster . Évalué à 0.
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 M . Évalué à 3.
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 Tobu . Évalué à 1.
Le pdf ne parle que de performance en compression, pas en temps de calcul.
# Pinaillage
Posté par jeberger (site web personnel) . Évalué à 4.
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 FluffyHamster . É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 jeberger (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 flagos . É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 FluffyHamster . É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 iTanguy . Évalué à 6.
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 xcomcmdr . É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 iTanguy . É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 Zenitram (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 xcomcmdr . É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 Wawet76 (site web personnel) . É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 Stibb . É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 briaeros007 . É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 Zenitram (site web personnel) . Évalué à 0.
Euh non : 200 €
[^] # Re: Et pour les brevets ?
Posté par Zarmakuizz (site web personnel) . Évalué à 5.
C'est gratuit.
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
[^] # Re: Et pour les brevets ?
Posté par flagos . É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 Zenitram (site web personnel) . Évalué à 1.
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 flagos . É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 Zenitram (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 flagos . É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 Zenitram (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?
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 flagos . É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 FluffyHamster . É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 Zenitram (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 misaflo (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 :
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.
La bataille des formats vidéos devrait être mouvementée.
[^] # Re: Round 2 : fight !
Posté par Zenitram (site web personnel) . Évalué à 5.
Tu en as d'autres des bonnes blagues comme ça?
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 FluffyHamster . É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 ?
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 Zenitram (site web personnel) . Évalué à 2.
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.
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 FluffyHamster . Évalué à 4.
Ok ça commence bien…
Pas vraiment. Quel est ton second choix alors ?
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 Zenitram (site web personnel) . Évalué à 2.
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.
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.
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 :).
99.999% des gens lisent légalement du H264 dans leur navigateur… Surtout que la licence pour les navigateur est à 0$ pour le moment.
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 FluffyHamster . É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 gnuzer (site web personnel) . Évalué à 6.
Pas besoin d'être masochiste pour utiliser des formats libres. Aimer la liberté est suffisant.
[^] # Re: Round 2 : fight !
Posté par WhiteCat . Évalué à 8.
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 barmic . Évalué à 1.
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 Zenitram (site web personnel) . Évalué à 4. Dernière modification le 28 janvier 2013 à 23:13.
Ben non : c'est un seul axe la, que tu donnes.
La qualité dépend de l'espace disque.
Un autre peut être mieux dans un autre domaine.
Mais : dans quel domaine VP8 est meilleur?
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 WhiteCat . Évalué à 2.
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 patrick_g (site web personnel) . Évalué à 6.
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 barmic . Évalué à 4.
Comprends bien que je me fou de VP8. Mon commentaire n'en tenais pas trace.
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.
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.
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 Zenitram (site web personnel) . Évalué à 2.
Tu cherches un concurrent qui serait meilleur sur un point particulier. remplace "VP8" par "Tartampion", mon commentaire reste valide.
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.
Yep. Et le miracle d'H264 est qu'il a réussi tout ça…
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).
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 flagos . É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:
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 Zenitram (site web personnel) . Évalué à 3.
C'est surtout la que je veux en venir ;-).
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)
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 Zenitram (site web personnel) . Évalué à 3.
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 xcomcmdr . Évalué à 5. Dernière modification le 28 janvier 2013 à 23:50.
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 Zenitram (site web personnel) . Évalué à 5. Dernière modification le 29 janvier 2013 à 10:38.
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.
Chut ;-)
[^] # Re: Round 2 : fight !
Posté par Kurtnoise . Évalué à 3.
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 LeMagicien Garcimore . É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 xcomcmdr . Évalué à 6.
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…
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 Kurtnoise . É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.