Le H.266 officiellement présenté, des fichiers encore moins gros à qualité constante

Le H.266 officiellement présenté, des fichiers encore moins gros à qualité constante

Le H.266 officiellement présenté, des fichiers encore moins gros à qualité constante

L’institut Fraunhofer pour les télécommunications a annoncé hier soir l’arrivée du VVC (Versatile Video Coding) ou H.266, en relève du H.265. Il a été développé pendant trois ans en partenariat avec Apple, Ericsson, Intel, Huawei, Microsoft, Qualcomm et Sony notamment.

On retrouve les promesses habituelles des évolutions de la technologie : un nouveau bond d’environ 50 % dans la réduction du poids des fichiers, sans « différence perceptible dans la fidélité visuelle ». À taille constante, les vidéos pourront bien sûr être de meilleure qualité.

Fraunhofer donne un exemple. Il faut actuellement 10 Go pour stocker 90 min de vidéo 4K UHD en H.265. En H.266, la même vidéo ne prend plus que 5 Go. Le codec a d’ailleurs été pensé avec les 4K et 8K en cibles.

L’institut annonce également que les logiciels permettant de lire et coder en H.266 seront disponibles pendant l’automne. 

Le nouveau codec aura cependant fort à faire pour s’imposer. Le H.265 n’a été adopté que lentement mais est bien là, tout comme AV1, un standard ouvert, sans royalties et faisant aussi bien. Sans parler du H.264, très présent.

Commentaires (79)


Bah voila, pas besoin de la 5G pour regarder du porno en (U)HD dans les toilettes, suffit du H.266.

E Piellot va être content…



La réduction de 50% en volume est impressionnante, quid des ressources nécessaires pour décoder un tel fichier par rapport à un 4K H.265 sachant qu’au départ il n’y a pas de support matériel non, tout sera en software ?


Quel intérêt d’utiliser ce format quand l’AV1 fait aussi bien mais gratuitement ?&nbsp;<img data-src=" />








SomeDudeOnTheInternet a écrit :



Quel intérêt d’utiliser ce format quand l’AV1 fait aussi bien mais gratuitement ?&nbsp;<img data-src=" />





A voir si h266 consomme moins de ressources. Et AV1 ne proposait que 20 à 25% d’amélioration.

Et puis pour l’aspect gratuit on a sisvel qui poursuit son FUD par rapport à ses brevets.&nbsp;



Le véritable problème va être le non support hardware. Sur des machines vraiment performantes, cela ne devrait pas être trop un souci. Sur des machines un tant soit peu anciennes, oulah … Déjà que tous les matériels actuels n’ont pas de capacité hardware de décodage H265, pour le H266, va falloir attendre, et pas qu’un peu.


Comme toujours, faut renouveler le matos pour une prise en charge matérielle. <img data-src=" />


En même temps comment veux tu la prise en charge matérielle sans changer le matos?


J’en sais rien du tout, ce n’est pas mon métier.

Je trouve ça juste dommage de devoir changer. <img data-src=" />


Au vu du degré de programmation possible sur les puces graphiques actuelles, une maj par driver est envisageable. Par contre je doute que les fabricants de smartphones la propose si elle existe un jour.


Prise en charge matériel signifie que c’est directement supporté par des composants spécifiques dans le silicium.



Pour ça qu’il faut changer.



Prise en charge logiciel par contre te permet de l’utiliser sans changer de matos, s’il est assez puissant








SirGallahad a écrit :



Au vu du degré de programmation possible sur les puces graphiques actuelles, une maj par driver est envisageable. Par contre je doute que les fabricants de smartphones la propose si elle existe un jour.





C’est ça que j’ai un peu de mal à comprendre, on a Vulkan, DirectX 12, j’y connais rien en programmation mais j’imagine qu’il doit forcément avoir un moyen de prendre en charge le H.266 de façon matériel en utilisant une API graphique?



&nbsp;





Leum a écrit :



Prise en charge matériel signifie que c’est directement supporté par des composants spécifiques dans le silicium.



Pour ça qu’il faut changer.



Prise en charge logiciel par contre te permet de l’utiliser sans changer de matos, s’il est assez puissant





Yes, tu as raison, mais bon, j’imagine qu’une solution peut être bricolée pour prendre en charge le nouveau codec quoi, même si on n’a que 50% des perf, ça sera toujours mieux qu’avec le CPU.



Après, il faut que les constructeurs aient envie de le faire. <img data-src=" />



Le H.265 est sorti en 2013, il y a 7 ans. On a donc un gain moyen de 6,4% par an, pas négligeable!


C’est le support logiciel ;)


Yes, mais pour moi, le support logiciel, c’est le CPU. <img data-src=" />

La CG n’est pas utilisée, moi je vois que sur YT, le codec AV1 utilise le CPU.


Il est clair qu’avant de trouver une box multimédia (et pire : une télé) compatible, et à un coût moindre (comme avec des puces Asmedia ou nVidia) on risque d’attendre un peu.&nbsp;<img data-src=" />

Déjà que les puces actuelles ARM (sauf Apple A10+) ne savent pas décoder des flux élevés (&gt; 100Mbits en crête) alors décoder de l’AV1 et pire h266…. Ben ne compressons pas trop vite nos vidéos “archivées” pour gagner de la place&nbsp;<img data-src=" />


Le H265 n’est même pas décodé par la Freebox revolution…. alors pour le H266, faudra attendre de nouveaux matos.








SirGallahad a écrit :



Au vu du degré de programmation possible sur les puces graphiques actuelles, une maj par driver est envisageable. Par contre je doute que les fabricants de smartphones la propose si elle existe un jour.







Non. La décompression logicielle peut être aidée par le matériel mais ça ne vaudra jamais un décodeur matériel pur, câblé pour. Le calcul par gpu ne fait de miracles que dans lez cas prévus pour. La décompression vidéo n’en fait pas partie.









tifounon a écrit :



Bah voila, pas besoin de la 5G pour regarder du porno en (U)HD dans les toilettes, suffit du H.266.

E Piellot va être content…



La réduction de 50% en volume est impressionnante, quid des ressources nécessaires pour décoder un tel fichier par rapport à un 4K H.265 sachant qu’au départ il n’y a pas de support matériel non, tout sera en software ?









Leum a écrit :



Prise en charge matériel signifie que c’est directement supporté par des composants spécifiques dans le silicium.



Pour ça qu’il faut changer.



Prise en charge logiciel par contre te permet de l’utiliser sans changer de matos, s’il est assez puissant





Questions pertinentes que j’aurais aimé voir traitées dans la news (c’est aussi ça le travail journalistique creuser un peu le sujet…<img data-src=" /> Oui je suis taquin aujourd’hui <img data-src=" />)



S’il faut 100% de puissance en plus pour gagner 50% en poids, franchement on n’est pas gagnants.&nbsp;



Je précise que je suis bien entendu pour la réduction du poids des vidéos, mais je regrette que ça ne s’inscrive pas DU TOUT dans une approche globale de réduction des échanges à travers l’internet, mais juste dans une “limitation d’accroissement” du poids des échanges vu les 4k et 8k.



Je rêve d’une approche globale dont l’objectif serait non de faire un pas en avant (réduction de poids) pour 5 pas en arrière (4k, 8k, centralisation toujours plus poussée des flux) mais de faire un pas en avant (réduction de poids) en plus d’autres (étude d’impact préalable à l’autorisation de commercialisation des vidéos 4k grand public, adaptation du droit d’auteur pour que le P2P ou le partage “en local” / par disque devienne la norme).



Guerre des codecs en perspective ?


ce qui m’interroge à chaque fois c’est la limite en résolution d’un codec donné, ça marche comment ? Il n’est pas efficace si on a trop de pixels en même temps ?<img data-src=" />

Hormis pour le fun ( <img data-src=" /> ), qu’est-ce qui n’empêcherait de faire du 4K en MPEG2 par exemple ? (enfin les logiciels et le codec doivent imposer la limite justement).



+1 avec Citan666


J’sais pas, chez moi l’AV1 utilise la partie 3D du GPU d’après le task manager alors que le VP9 utilise la partie Video Decode <img data-src=" />








jb18v a écrit :



ce qui m’interroge à chaque fois c’est la limite en résolution d’un codec donné, ça marche comment ? Il n’est pas efficace si on a trop de pixels en même temps ?<img data-src=" />

Hormis pour le fun ( <img data-src=" /> ), qu’est-ce qui n’empêcherait de faire du 4K en MPEG2 par exemple ? (enfin les logiciels et le codec doivent imposer la limite justement).



+1 avec Citan666





Ce n’est pas une limitation mais un usage prévu pour. Ton codec sera plus efficace pour les cas prévus, ce qui ne veut pas dire qu’il sera inutilisable en dehors : il ne sera juste pas optimisé pour.

en 720p par exemple, rien ne te dit que ton h265 et h266 auront la même qualité pour 50% de la taille d’origine . T’aura peut être besoin de 75% de la taille









DoWnR a écrit :



J’sais pas, chez moi l’AV1 utilise la partie 3D du GPU d’après le task manager alors que le VP9 utilise la partie Video Decode <img data-src=" />





Ton support AV1 est logiciel avec extensions opencl ou cuda, alors que ton vp9 est purement matériel: ton ordi donne la vidéo à la carte graphique qui en chie des images, sans aucune implication cpu.









patos a écrit :



Ce n’est pas une limitation mais un usage prévu pour. Ton codec sera plus efficace pour les cas prévus, ce qui ne veut pas dire qu’il sera inutilisable en dehors : il ne sera juste pas optimisé pour.

en 720p par exemple, rien ne te dit que ton h265 et h266 auront la même qualité pour 50% de la taille d’origine . T’aura peut être besoin de 75% de la taille





<img data-src=" />









mouton_enragé a écrit :



Le H265 n’est même pas décodé par la Freebox revolution…. alors pour le H266, faudra attendre de nouveaux matos.



En même temps la Revo est sortie en 2010, et le h.265 en 2013…



J’ai une 1080 Ti donc tout ce qui est après 2017 c’est mort….








jb18v a écrit :



ce qui m’interroge à chaque fois c’est la limite en résolution d’un codec donné, ça marche comment ? Il n’est pas efficace si on a trop de pixels en même temps ?<img data-src=" />

Hormis pour le fun ( <img data-src=" /> ), qu’est-ce qui n’empêcherait de faire du 4K en MPEG2 par exemple ? (enfin les logiciels et le codec doivent imposer la limite justement).





En principe rien n’interdit de compresser une vidéo quelconque en MPEG-2, c’est juste que ça n’a pas d’intérêt puisqu’à qualité égale ça va prendre beaucoup plus de place qu’en (par exemple) H264, qui est utilisable par tellement de matériel à l’heure actuelle. On a fait des progrès en techniques de compression depuis l’époque où le MPEG-2 a été conçu (et en puissance matérielle, ça va un peu avec).



Pour le support des codecs, intégrer un FPGA aux GPU pourrait être intéressant.


Pour le support des codecs, intégrer un FPGA aux GPU pourrait être intéressant.


Pour le support des codecs, intégrer un FPGA aux GPU pourrait être intéressant.


Quid du temps d’encodage ? Vu le temps complètement abusé requis par le H265, s’il faut encore plus, pratiquement personne ne l’utilisera.


Je partage également ton avis sur les gains d’un côté qui se traduisent par une augmentation de usage et non par une économie.



Traditionnelle analogie bagnolesque :



Pour la voiture électrique, le gain de densité sur les batteries ne va presque pas à la diminution du poids de la voiture mais à l’augmentation de l’autonomie.



Idem, l’amélioration des moteurs thermiques a surtout permis d’augmenter la taille des voitures sans augmenter la consommation.



C’est la même chose avec l’informatique.




un nouveau bond d’environ 50 % dans la réduction du poids des fichiers, sans « différence perceptible dans la fidélité visuelle »



Quelqu’un aurait-il une source expliquant comment on compare la fidélité visuelle ?

Parce qu’en demandant à un aveugle, on peut descendre jusqu’à 100% sans différence perceptible dans la fidélité visuelle ….








tifounon a écrit :



Bah voila, pas besoin de la 5G pour regarder du porno en (U)HD dans les toilettes, suffit du H.266.

E Piellot va être content…



La réduction de 50% en volume est impressionnante, quid des ressources nécessaires pour décoder un tel fichier par rapport à un 4K H.265 sachant qu’au départ il n’y a pas de support matériel non, tout sera en software ?









Citan666 a écrit :



Questions pertinentes que j’aurais aimé voir traitées dans la news (c’est aussi ça le travail journalistique creuser un peu le sujet…<img data-src=" /> Oui je suis taquin aujourd’hui <img data-src=" />)



S’il faut 100% de puissance en plus pour gagner 50% en poids, franchement on n’est pas gagnants.&nbsp;



Je précise que je suis bien entendu pour la réduction du poids des vidéos, mais je regrette que ça ne s’inscrive pas DU TOUT dans une approche globale de réduction des échanges à travers l’internet, mais juste dans une “limitation d’accroissement” du poids des échanges vu les 4k et 8k.



Je rêve d’une approche globale dont l’objectif serait non de faire un pas en avant (réduction de poids) pour 5 pas en arrière (4k, 8k, centralisation toujours plus poussée des flux) mais de faire un pas en avant (réduction de poids) en plus d’autres (étude d’impact préalable à l’autorisation de commercialisation des vidéos 4k grand public, adaptation du droit d’auteur pour que le P2P ou le partage “en local” / par disque devienne la norme).









Bin en fait le banc d’essai est à analyser en premier lieu. Il y a ce que l’on dit et …le reste. Ici c’est une annonce…

&nbsp;

Par exemple : Est-ce un banc d’essai avec les mêmes fichiers ? CAD les mêmes résolutions. En général c’est riche d’enseignement.





Sinon les gains de compression se font aussi par le fait que les résolutions augmentent. On a des pâtés de couleurs plus gros donc plus facile à traiter.

&nbsp;

Une vidéo en 480p est finalement plus difficile a encoder qu’une vidéo en 8k. Il y a plus de détails (ou perturbation).&nbsp; Les cas de “gros patés” sont plus abondant dans une vidéo à grosse résolution.

&nbsp;

C’est un peu comme d’encoder un film versus encoder un dessin animé (avec plein d’aplat) dans les couleurs.



Donc au niveau des ressources c’est pas forcément de la puissance de calcul qu’il faut mais de la bande passante pour transporter la quantité jusqu’au moniteur (et de la RAM… plein).

&nbsp;









XXC a écrit :



Quelqu’un aurait-il une source expliquant comment on compare la fidélité visuelle ?





En coupant la tête d’un poulet et quand il à finis de courir sa position correspond à une note.

&nbsp;





TexMex a écrit :



Bin en fait le banc d’essai est à analyser en premier lieu. Il y a ce que l’on dit et …le reste. Ici c’est une annonce… Par exemple : Est-ce un banc d’essai avec les mêmes fichiers ? CAD les mêmes résolutions. En général c’est riche d’enseignement.





Je vois qu’il y à beaucoup de scepticisme ici ! J’ai l’impression de revivre l’ère du divx…



A une époque le seul moyen d’avoir de la vidéo c’était le mpeg 1. Un film pouvais y tenir en qualité moyenne sur un seul cd et en qualité correcte sur deux cd. Puis le divx est apparu et un film pouvais tenir sur un seul cd avec une qualité proche de l’original.



Beaucoup ont criés au bullshit au début parce que c’était dur d’avoir des démos et qu’a l’époque ça tournais pas sur des machines normales, c’était un peu sacadé. Et puis lors d’un changement de machine, tout fonctionnais correctement.





D’après mes calcul au doigt levé si un film 4k de 90 mn peut tenir sur 5 go cela veut dire qu’un film en 1080p de 90 mn peut donc tenir sur 1.25 go et qu’un épisode de série TV pourra tenir sur un fichier de 625 mo.

&nbsp;



Éric Piolle* ;)








vampire7 a écrit :



Quid du temps d’encodage de compression ? Vu le temps complètement abusé abusif requis par le H265, s’il faut encore plus, pratiquement personne ne l’utilisera.





Je sais qu’on n’est pas supposé corriger les fautes dans les commentaires, mais là c’était trop combo.

Non seulement ce n’est pas un codage (car c’est de la compression avec perte, alors qu’un codage est une transformation réversible), mais c’est encore moins un “encodage” (anglicisme issu de “encoding”), d’ailleurs on parle de codec = codeur/décodeur.

Ça n’a pas de sens d’écrire “abusé” comme ça, je ne comprends toujours pas cette faute que je vois parfois. On écrit soit “faire ceci c’est abuser” (se moquer du monde), soit “faire ceci c’est abusif”.

Merci.









Pseudooo a écrit :



Je partage également ton avis sur les gains d’un côté qui se traduisent par une augmentation de usage et non par une économie.

[..]

Idem, l’amélioration des moteurs thermiques a surtout permis d’augmenter la taille des voitures sans augmenter la consommation.

C’est la même chose avec l’informatique.





En fait pas tout à fait.

En informatique les résolutions augmentent, que ce soit côté écran informatique comme côté vidéo (on est parti sur de 480p ou 576i en gros, en pratique la qualité d’une télévision cathodique était plutôt vers 360p me semble). Les progrès dans la compression (j’ai même connu avant le MPEG-1) font qu’on peut réduire l’encombrement et les bandes passantes (avant même celle du réseau, celle du disque et des circuits graphiques) à résolution et qualité égale.



Concernant les voitures, ce sont les normes de sécurité (crash-test) et le souhait de confort (lié aussi à l’augmentation du niveau de vie) qui ont fait enfler les voitures ; disons que le progrès dans la consommation des moteurs a été en partie “mangé” par l’alourdissement, ça dépend des gammes. On a quand même fait pas mal de progrès sur la consommation des voitures moyennes, je l’ai constaté perso pour les miennes à la pompe (et j’en suis seulement à ma 3e).







XXC a écrit :



Quelqu’un aurait-il une source expliquant comment on compare la fidélité visuelle ?

Parce qu’en demandant à un aveugle, on peut descendre jusqu’à 100% sans différence perceptible dans la fidélité visuelle ….





Il y a des critères quantifiables comme le rapport signal/bruit, et des critères qualitatifs par des jurys, car finalement c’est l’oeil le meilleur juge, sachant que les algorithmes de compression (que ce soit son ou image) avec perte tiennent comptent et tirent profit des caractéristiques de l’oreille et de la vision humaine. Pour l’oreille la compression retire certaines fréquences d’intensité faible et cachées par d’autres, sans qu’on s’en rende compte (ou alors il faut une oreille très exercée). Pour l’oeil le JPEG fait l’impasse sur certains détails fins et code la couleur sur moins de bits que la luminosité (chrominance versus luminance), ce que l’oeil ne voit pas forcément.









TexMex a écrit :



Par exemple : Est-ce un banc d’essai avec les mêmes fichiers ? CAD les mêmes résolutions. En général c’est riche d’enseignement.





Ben évidemment, sinon quel intérêt ??



C’est comme la fameuse image de Lena (la femme au chapeau) qui a longtemps servi dans les tests de compression d’image.







TexMex a écrit :



Sinon les gains de compression se font aussi par le fait que les résolutions augmentent. On a des pâtés de couleurs plus gros donc plus facile à traiter.





Non, ce n’est pas pour ça, sinon ça voudrait dire que la qualité n’augmente pas (à la source). Et je vois très bien la différence de niveau de détail entre un bon fichier HD 1080p et un (bon) fichier SD 480p.

La compression s’améliore sur une image donnée, on trouve des techniques plus performantes (comme quand on est passé du simple “BMP” au JPEG).

 





TexMex a écrit :



Une vidéo en 480p est finalement plus difficile a encoder qu’une vidéo en 8k. Il y a plus de détails (ou perturbation).





Tu rêves…

Et c’est très facile à vérifier.

D’ailleurs on compresse, on ne code pas (et encore moins “encode”). Un codage est une opération réversible.







TexMex a écrit :



C’est un peu comme d’encoder un film versus encoder un dessin animé (avec plein d’aplat) dans les couleurs.





Justement non. Un dessin animé a lui tendance à avoir des aplats, en effet.







skankhunt42 a écrit :



Puis le divx est apparu et un film pouvais tenir sur un seul cd avec une qualité proche de l’original.





Qualité proche, faut le dire vite. En fait ce n’était pas le cas, vu que c’était impossible. Même un film en H264 qui tient sur un CD, c’est juste (en 480p pour rester dans une résolution de l’époque).







skankhunt42 a écrit :



D’après mes calcul au doigt levé si un film 4k de 90 mn peut tenir sur 5 go cela veut dire qu’un film en 1080p de 90 mn peut donc tenir sur 1.25 go et qu’un épisode de série TV pourra tenir sur un fichier de 625 mo.





Ça ne dit rien de la qualité. En pratique un film en 1080p de qualité moyenne (genre issu de la TNT) de 90 min c’est plutôt vers 2,5 à 3 Go, et si on veut de la bonne qualité c’est plutôt le double.



La comparaison divx / mpeg2 tiens toujours, malheureusement.

Pour obtenir leur gains en compression on perd généralement en piqué, et a mes yeux ca reste visible pour toutes les évolutions.

On a de plus en plus de fonds baveux (aplat au lieu de grain du film), mais, chouette, on peu faire passer tenir 2H de 8K sur un CD..









OlivierJ a écrit :



Je sais qu’on n’est pas supposé corriger les fautes dans les commentaires, mais là c’était trop combo.

Non seulement ce n’est pas un codage (car c’est de la compression avec perte, alors qu’un codage est une transformation réversible), mais c’est encore moins un “encodage” (anglicisme issu de “encoding”), d’ailleurs on parle de codec = codeur/décodeur.

Ça n’a pas de sens d’écrire “abusé” comme ça, je ne comprends toujours pas cette faute que je vois parfois. On écrit soit “faire ceci c’est abuser” (se moquer du monde), soit “faire ceci c’est abusif”.

Merci.





“encodage” :

https://fr.wiktionary.org/wiki/encodage

https://www.larousse.fr/dictionnaires/francais/encodage/29215

Quant à “abusé”, c’est une expression désormais reconnue :

http://www.linternaute.fr/expression/langue-francaise/20636/c-est-abuse/



Le français est une langue vivante. Les règles et expressions d’autrefois ont été décidées de manière aussi arbitraire que celles d’aujourd’hui. Le seul mauvais français est celui qui n’est pas compris de la plupart des gens.

Tu prouves toi-même que mon français est correct puisque tu as parfaitement compris ce que je voulais dire. <img data-src=" />









XXC a écrit :



La comparaison divx / mpeg2 tiens toujours, malheureusement. Pour obtenir leur gains en compression on perd généralement en piqué, et a mes yeux ca reste visible pour toutes les évolutions. On a de plus en plus de fonds baveux (aplat au lieu de grain du film), mais, chouette, on peu faire passer tenir 2H de 8K sur un CD..





Ça dépend de plein de facteur…



Pour commencer la compression. Certaines team s’en cognent complètement que le media doit tenir sur un cd donc il est évident que la qualité sera meilleurs si la cible est un bitrate moyen “constant”. D’autre ne ce focalisent la dessus et tu te retrouve avec un truc tout dégueux.



Certaines team vont ripper le film en local “à la mano” alors que d’autre vont le faire sur un serveur avec un outil “one click”. La source va dépendre aussi de la qualité finale d’un film. Tout comme la part du son, un son en mp3 prendra moins de place qu’un multi canal en AC3.



Ensuite tu à aussi à prendre en compte ou le contenu sera visionné. Sur une télévision le piqué est meilleur car il y à des filtres, l’image à aussi tendance à être plus claire. Même entre VLC et windows media player il y à des différence. Je trouve le h24 légèrement plus net et ça prend moins de de ressource sur ma machine.



Tu doit aussi prendre en compte le système de stockage. Perso je garde toujours le dernier épisode d’une série pour pas perdre le film au niveau des noms à la longue ça prend de la place. Ça dépend aussi d’ou tu traine, certains n’auront que de la qualité merdique et d’autre que de la haute qualité.





Maintenant si l’ont regarde du côté du légal je ne peut pas vraiment me prononcer hormis pour youtube. Ça fait le job mais c’est pas la folie furieuse niveau qualité / option. Par exemple mon portable ne peut pas tenir le 60 fps du coup je dois tout regarder en 480p car il y à pas le 720p 30fps de dispo. C’est pas évident de contenter tout le monde hein.









OlivierJ a écrit :



Ça ne dit rien de la qualité. En pratique un film en 1080p de qualité moyenne (genre issu de la TNT) de 90 min c’est plutôt vers 2,5 à 3 Go, et si on veut de la bonne qualité c’est plutôt le double.





En fait ce qu’il faudrait c’est une base de comparaison, car même au niveau des films ça ne veut rien dire suivant les format. Un film en ultra wide pèsera quasiment deux fois moins lourd qu’un film en 16 ème avec la même compression. Du coup à taille équivalente ton fichier ultra wide sera deux fois plus net.



&nbsp;









OlivierJ a écrit :



Ben évidemment, sinon quel intérêt ??







Bien évidement qu’il faut le vérifier SURTOUT. Comme qui dirait ce ne serait pas la première fois qu’on annonce quelque chose et qu’après un test un peu plus sérieux les chiffres du départ ne sont pas retrouvés. Un genre de carte graphique RTX ??? Ou d’étude pas si conforme que cela (ex: The lancet). Se pourrait-il qu’il y ait des effets d’annonce ? Même dans le monde scientifique / technologique? Naaaaaaan, y’a que des gens honnêtes la dedans. C’est bien connu.



Ici on en est aux annonces.



Globalement il faut toujours vérifier 2 fois. C’est comme pour les zombies : Règle #1 Double tap (pan, pan).











OlivierJ a écrit :



Non, ce n’est pas pour ça, sinon ça voudrait dire que la qualité

n’augmente pas (à la source). Et je vois très bien la différence de

niveau de détail entre un bon fichier HD 1080p et un (bon) fichier SD

480p.

La compression s’améliore sur une image donnée, on trouve des

techniques plus performantes (comme quand on est passé du simple “BMP”

au JPEG).

&nbsp;







&nbsp; J’ai jamais dit qu’il n’y avait pas plus de détail à la source. Ce que tu perçois comme un détail n’est pas “vu” de la même manière par la machine/algo. Effectivement le nombre de détail augmente (ca reste subjectif et je pourrai en atomiser plus d’un la dessus mais passons) mais la taille du terrain augmente aussi avec une proportion bien supérieure. Donc au final les “détails” sont moins nombreux en densité (ou plus facilement traitable). Et bien plus facilement dissimulable. Ce qui est souvent le propre de ces algos. Enlever les fréquences qu’on entend pas… ou ne distingue pas… Ça fait moins de boutons sur la gueule des acteurs.



Si on regarde une image sous un angle topologique. Ça ressemble à une carte IGN. Le noir est le niveau de la mer et le blanc, un pic de montagne. Dans un contexte d’appréciation des résolutions qui augmentent. Cette nouvelle image plus large est un peu comme une montagne dont on change la superficie à la base mais pas l’altitude. Parce que si on considère que 256 est l’altitude maximale et que FF,FF,FF est blanc. On ne fera pas plus blanc que blanc. Sauf pour un vendeur de lessive (demandez à Coluche). Bref la pente de la montagne sera moins prononcée, …bien plus lisse. Et ça fait le pain béni des algos. Une orgie en fait. Et c’est ce qui permet d’obtenir de meilleurs résultats.



En compression/encodage il n’y a pas que le fait de l’algorithme mais aussi l’objet du traitement. C’est un tout. Donc si on dit qu’un algorithme est meilleur il faut le mettre au banc d’essai sur tout les types d’objet. Passés et présents. Et dans le cas de la vidéo la résolution est non négligeable.

&nbsp;

&nbsp;









OlivierJ a écrit :



Tu rêves…

Et c’est très facile à vérifier.

D’ailleurs on compresse, on ne code pas (et encore moins “encode”). Un codage est une opération réversible.





Personne n’a tort dans ce contexte. Les deux principes utilisent les mêmes ficelles pour réduire la taille de stockage (qui a dit dictionnaire?). Mais ce n’est pas la même approche. Encoder est une pierre philosophale de l’informatique. Genre ASCII. Ça pose la base.

&nbsp;

&nbsp;La compression(1)(2) dans le sens originel de l’informatique (avant Mpeg / jpg) n’admet pas une perte / distorsion du signal. Ce serait ballot pour un exécutable, hein.



Mais surtout la compression de donnée englobe aussi les techniques pour les médias.

&nbsp;

Quand il y a une perte de qualité (ou transposition) dans le sens ou on ne retrouve jamais le signal original avec une fidélité absolue (mais que cela reste intelligible / approchant); on encode. C’est le plus adapté. D’ailleurs on règle la “qualité” (notamment pour le JPG) et non un ratio de compression lors de l’utilisation de ces solutions logicielles. Parler de compression fut introduit il y a bien longtemps avec la mode du MP3. Ça fait plus vendeur de parler de “compression”. Surtout quand la qualité sonore laisse à désirer. Mais c’est mon oreille entraînée qui se rebiffe.



Citation du TLF :Coder s’emploie au sens premier de code (code secret), alors que encoder est le symétrique de décoder et se réfère aux emplois récents de code.

&nbsp;

Dans les deux cas de compression avec ou sans perte il y bien de l’encodage/décodage. La différence est l’exigence sur la notion de fidélité de restitution. Et c’est pour cela qu’il est bon de les séparer. C’est mieux d’enlever les possibles ambiguïtés.

&nbsp;







OlivierJ a écrit :



Justement non. Un dessin animé a lui tendance à avoir des aplats, en effet.





Heu… c’est bien ce que j’ai dit. Sur une ligne de pixel : 1x Noir,&nbsp; 100x blanc ,1x Noir; c’est plus facile à encoder qu’un mix valeurs en ordre dispersé. Pastis, Ricard ?









skankhunt42 a écrit :



Je vois qu’il y à beaucoup de scepticisme ici ! J’ai l’impression de revivre l’ère du divx…





Non pas septique. Prudent. Par les temps qui courent les faits me donnent plutôt raison. Double tap rules! (voir paragraphe 1).



&nbsp;









vampire7 a écrit :



“encodage” :

https://fr.wiktionary.org/wiki/encodage

https://www.larousse.fr/dictionnaires/francais/encodage/29215





C’est un tolérance et un anglicisme, personne ne disait ça en 1990 par exemple. On tolère trop de choses dans le dictionnaire concernant ce qui vient de l’informatique, et les informaticiens sont mauvais en français.

Le bon terme, en math en particulier (je suis matheux) est “codage” et rien d’autre.

Et en plus en vidéo il ne s’agit PAS d’un codage, mais d’une compression avec perte.

Je rappelle qu’on parle de “message codé” et de “fax codé” (moins maintenant évidemment pour le fax).

Tout autre usage est une faute de français à la base.







vampire7 a écrit :



Quant à “abusé”, c’est une expression désormais reconnue :

http://www.linternaute.fr/expression/langue-francaise/20636/c-est-abuse/





Arf “Linternaute” la référence. C’est juste une recension, c’est une énorme faute de dire “c’est abusé”, ça n’a AUCUN sens.



Le français est une langue vivante mais pas la peine de légitimer ce qui sont juste de fautes liées à des gens qui parlent mal le français (beaucoup d’informaticiens et pas que).









TexMex a écrit :



Bien évidement qu’il faut le vérifier SURTOUT. Comme qui dirait ce ne serait pas la première fois qu’on annonce quelque chose et qu’après un test un peu plus sérieux les chiffres du départ ne sont pas retrouvés. Un genre de carte graphique RTX ???





Mais là c’est un algo que tout le monde pourra tester, pas vraiment la même chose.

Évidemment que du monde vérifiera, comme à chaque fois.







TexMex a écrit :



J’ai jamais dit qu’il n’y avait pas plus de détail à la source. Ce que tu perçois comme un détail n’est pas “vu” de la même manière par la machine/algo. Effectivement le nombre de détail augmente (ca reste subjectif et je pourrai en atomiser plus d’un la dessus mais passons) mais la taille du terrain augmente aussi avec une proportion bien supérieure. Donc au final les “détails” sont moins nombreux en densité (ou plus facilement traitable).





Mais non enfin…

C’est que ta source est de mauvaise qualité si c’est le cas.

Ta théorie ne tient pas la pratique (rien qu’entre la qualité télé SD et la HD).







TexMex a écrit :



En compression il n’y a pas que le fait de l’algorithme mais aussi l’objet du traitement.





?? Une compression EST un traitement.







TexMex a écrit :



Donc si on dit qu’un algorithme est meilleur il faut le mettre au banc d’essai sur tout les types d’objet. Passés et présents. Et dans le cas de la vidéo la résolution est non négligeable.





La résolution n’a aucun rapport.

Et oui évidemment, quand on évalue un algo de compression, on le teste sur différents fichiers, que ce soit pour un algo de compression vidéo ou pour de la compression de données (comme zstd versus lz4 versus lzma).









TexMex a écrit :



Les deux principes utilisent les mêmes ficelles pour réduire la taille de stockage (qui a dit dictionnaire?). Mais ce n’est pas la même approche. Encoder est une pierre philosophale de l’informatique. Genre ASCII. Ça pose la base.





On parle de code ASCII, c’est un codage. On n’encode rien, on code.

 

La compression sans perte est un codage, c’est bijectif (réversible). Un codage n’est pas forcément une compression, évidemment, ça peut être l’inverse.

La compression avec perte (souvent utilisée pour la vidéo, le son et l’image) n’est pas un codage.



NB : j’ai étudié la théorie de l’information et j’ai déjà rappelé la différence ci-dessus, t’es drôle à m’expliquer les choses, je l’ai même enseignée en fac.







TexMex a écrit :



Citation du TLF :Coder s’emploie au sens premier de code (code secret), alors que encoder est le symétrique de décoder





C’est moche, car si on parle de “codec”, c’est bien parce qu’il s’agit de codage/décodage.

Le symétrique de décoder en bon français c’est coder, c’est ainsi qu’on l’apprenait au 20e siècle en tous cas.



Quand il y a de la perte, ça n’a PAS de sens de parler de codage (ou “encodage” pour les anglicismes berk), même si on a gardé le terme “codec” par habitude.







TexMex a écrit :



Dans les deux cas de compression avec ou sans perte il y bien de l’encodage/décodage. La différence est l’exigence sur la notion de fidélité de restitution. Et c’est pour cela qu’il est bon de les séparer. C’est mieux d’enlever les possibles ambiguïtés.





Mais NON…

On doit parler de codage quand c’est sans perte.

On doit parler de compression ou de conversion quand c’est avec perte.



Personne ne dit qu’il a “encodé son image en JPEG”, il dit qu’il l’a “converti en JPEG” ou tout simplement “sauvé en JPEG” <img data-src=" />

Pourquoi on en ferait autrement pour la vidéo ou le son ?







TexMex a écrit :



Heu… c’est bien ce que j’ai dit. Sur une ligne de pixel : 1x Noir,  100x blanc ,1x Noir; c’est plus facile à encoder qu’un mix valeurs en ordre dispersé. Pastis, Ricard ?





Relis ce à quoi je répondais. Le seul truc sur lequel tu as dit juste c’est sur les aplats du dessin animé (ou les dégradés mais justement c’est bien géré par la compression type JPEG ou ondelettes).

Par ailleurs les contours brutaux genre seulement 1 pixel, ça passe mal la compression type JPEG en général.



&nbsp;







OlivierJ a écrit :



Mais là c’est un algo que tout le monde pourra tester, pas vraiment la même chose.

Évidemment que du monde vérifiera, comme à chaque fois.





Bon bin finalement tu vois que ça a de l’intérêt de vérifier !

&nbsp;

&nbsp;





OlivierJ a écrit :



Mais non enfin…

C’est que ta source est de mauvaise qualité si c’est le cas.

Ta théorie ne tient pas la pratique (rien qu’entre la qualité télé SD et la HD).





?? Une compression EST un traitement.





La résolution n’a aucun rapport.



Et oui évidemment, quand on évalue un algo de compression, on le teste

sur différents fichiers, que ce soit pour un algo de compression vidéo

ou pour de la compression de données (comme zstd versus lz4 versus

lzma).





La résolution plus grande; indéniablement changera le nombre et le type de “motifs” présents. Ou pour faire plus précis “changera la statistique de la présence des motifs dénombrables” (dans le sens de reconnaissable, de ceux qui sont “de le delicious” à encoder). Donc SI ça a rapport.&nbsp;



&nbsp;Parce que tout simplement quand ces zones apparaissent il devient pertinent de s’en occuper pour “gagner en place” car cela devient “gagnant”. N’oublions que la compression est aussi une histoire de décision. Enfin quand on a un bulbe rachidien fonctionnel mais c’est une autre histoire. Et aussi du fait de la répétition. Plus d’espace, plus de répétition potentielles.



Déjà regardé de près une photo 200Mpx ou Gpx ? Et pas en JPG bien sur. Rien qu’à l’œil (qui semble être une référence de choix pour toi), cela se voit comme le nez au milieu de la figure. Hors problème d’optique bien entendu.



&nbsp;Il y a du détail sur certaines zones bien évidement. Mais il apparaît également des espaces bien plus facilement traitables. S’en est même surprenant à un point ou se dit qu’il faut revoir / affiner les profils pour mieux “gagner en compression”. Dure la vie d’un codeur (anglicisme dont on pourrait parler des décennies tellement celui-ci est fumant).

&nbsp;

&nbsp;



OlivierJ a écrit :



C’est moche, car si on parle de “codec”, c’est bien parce qu’il s’agit de codage/décodage.

Le symétrique de décoder en bon français c’est coder, c’est ainsi qu’on l’apprenait au 20e siècle en tous cas.



Quand il y a de la perte, ça n’a PAS de sens de parler de codage (ou “encodage” pour les anglicismes berk), même si on a gardé le terme “codec” par habitude.





Seulement voila. Faire cela rend incompréhensible le locuteur. Si on regarde les définitions de codage on s’aperçoit qu’il n’est fait nulle part mention de la taille des données. C’est ballot.



Aller on dérive sur les expressions. “Compression de donnée” désignera bien ce fait. Parce qu’il parle de l’objectif. La plupart des gens dans un souci de vitesse et de confort tronquera à “compression”. Ce n’est pas malsain en soit.

&nbsp;



&nbsp;







OlivierJ a écrit :



C’est moche, car si on parle de “codec”, c’est bien parce qu’il s’agit de codage/décodage.

Le symétrique de décoder en bon français c’est coder, c’est ainsi qu’on l’apprenait au 20e siècle en tous cas.





Quand il y a de la perte, ça n’a PAS de sens de parler de codage (ou

“encodage” pour les anglicismes berk), même si on a gardé le terme

“codec” par habitude.





Mais NON…

On doit parler de codage quand c’est sans perte.

On doit parler de compression ou de conversion quand c’est avec perte.



Personne ne dit qu’il a “encodé son image en JPEG”, il dit qu’il l’a “converti en JPEG” ou tout simplement “sauvé en JPEG” <img data-src=" />

Pourquoi on en ferait autrement pour la vidéo ou le son ?







&nbsp;Déjà fait de la compression vidéo?&nbsp; Dans les disciplines techniques il faut se défaire des ambiguïtés au maximum. Et en informatique il en a des tonnes. Prenons le premier FrameWork (cadre de développement) qui vient et on dégote une refonte de dictionnaire en bonne et due forme.



&nbsp;Et même quand c’est bien fait il y a des difficultés. Le processus et l’habitude à tort ou à raison forgent le langage. Sans compter les interventions de l’académie pour franciser (ou badigeonner suivant les avis) les termes Yankee.



Quiconque a fait de la vidéo dans les année 90 et + et attendu des plombes chaque fichier le sait. Le processus est nettement plus long qu’une simple sauvegarde. Les mots utilisés dans les interfaces de ces logiciels n’y sont pas pour rien non plus. C’est donc naturellement que le mot fut adopté. Ironie du sort. Que l’on considère le terme conforme ou non il produit la différenciation. Il est donc est plus utile finalement.



Utiliser “codage” pour le mode sans perte ne permet pas de se défaire d’un flou grossier. Aucune définition ne stipule le changement de taille. Techniquement tout est codage finalement (on va y venir) seulement cela complique les échanges de l’utiliser ainsi. Surtout dans des forums. C’est source d’ambiguïté. Sans compter que le phénomène vient souvent de l’adaptation depuis l’anglais. Pour rappel un même mot n’a pas le même sens dans les deux langues.



Donc la pédagogie quand on la fait bien est responsable avant tout.





&nbsp;

&nbsp;Afin de contribuer à l’humanité,… du coup j’invente un mot.



&nbsp;Les définitions (coder, encoder, etc ) que l’on trouve dans les dictionnaires officiels et passablement dans pas mal de bouquins qui traitent d’entropie (ou pas), référencent comme synonyme les termes voisins. Et ainsi de suite pour revenir à la première définition. Ce qui en l’état file en cycle.



Du coup c’est un Cyclofilage.

&nbsp;

&nbsp;





OlivierJ a écrit :



La compression avec perte (souvent utilisée pour la vidéo, le son et l’image) n’est pas un codage.



&nbsp;



&nbsp; Imaginons les chaînes 123456789 , aaaaaaaaaaa, 123456788 , aaaaaaaaaaB, 123456787 , aaaaaaaaaaC qui se trouvent en nombre dans un fichier.

&nbsp;

On pourra simplement les “coder” (pour reprendre le terme) dans un objectif de “compression de donnée” (au sens du Larousse) en “1” & “2” . Ainsi on obtient un dictionnaire 1=“123456789”, 2=“aaaaaaaaaaa” et un fichier nettement plus petit. On pourra étendre le dictionnaire si on le choisi et compresser un peu plus.



&nbsp;Imaginons maintenant que l’on reprenne le processus et que l’on change la regle du dictionnaire par

&nbsp;1 équivaut à “123456787” , “123456788” , “123456789” =&gt; écrire “123456788”

&nbsp;2 équivaut à “aaaaaaaaaaa”, “aaaaaaaaaaB”, “aaaaaaaaaaC”. =&gt; écrire “aaaaaaaaaaB”

&nbsp;Refaire la même opération produira le même type de résultat que pour une vidéo ou image.

&nbsp;

D’un point de vue programmatique c’est pourtant identique (trouver, cataloguer), et c’est un codage d’après les dictionnaires. Même si on invite Huffman à la petite fête.





Codage : Action de coder un texte, des données informatiques ; chiffrement, encodage.

Encodage: Action d’encoder ; production d’un message ; codage.



Donc à moins de changer l’ensemble des dictionnaires…. Déjà que je voudrais proposer Cyclofilage….

&nbsp;



&nbsp;









XXC a écrit :



La comparaison divx / mpeg2 tiens toujours, malheureusement.

Pour obtenir leur gains en compression on perd généralement en piqué, et a mes yeux ca reste visible pour toutes les évolutions.

On a de plus en plus de fonds baveux (aplat au lieu de grain du film), mais, chouette, on peu faire passer tenir 2H de 8K sur un CD..



Je t’invite à encoder une source Bluray (&gt;50Go) en HEVC avec x265 CPU uniquement en preset slow, débit 4mbps hors son. Le résultat est pas mal… (si tu réponds dans moins de 24h à ce message, soit tu bluffes soit tu as un threadripper)

&nbsp;

Les encodeurs matériels sont mauvais mais suffisant. Parce que personnellement, passer 20mn à encoder sur ma 2070super me convient plus que 18h sur mon CPU 6 coeurs, donc j’accepte la légère perte de qualité.



Le problème principal qui se pose, c’est la consommation énergétique.



Même en décodage matériel, le H265 est déjà bien plus gourmand que le H264, c’est bien beau de parler de réduction de poids de fichiers et débits de streaming, mais si la consommation d’énergie pour décoder le H266 sera supérieure aux gains côté réseau et stockage, à quoi bon ?



Ça n’est pas un hasard si le H265 peine à s’imposer en streaming et à être adopté partout !



À la limite, ça pourra être intéressant pour les services d’accès à distance (Cloud Gaming comme Shadow, Teamviewers & cie…)








OlivierJ a écrit :



C’est juste une recension, c’est une énorme faute de dire “c’est abusé”, ça n’a AUCUN sens.



Le français est une langue vivante mais pas la peine de légitimer ce qui sont juste de fautes liées à des gens qui parlent mal le français (beaucoup d’informaticiens et pas que).



Désolé de te l’apprendre, mais cette expression est comprise et utilisée par toute personne de moins de 40 ans (dans le langage courant, certes).

On dira que c’est un marqueur du temps qui passe…

https://www.youtube.com/watch?v=kAUahaZTcZg <img data-src=" />









near667 a écrit :



Désolé de te l’apprendre, mais cette expression est comprise et utilisée par toute personne de moins de 40 ans (dans le langage courant, certes).

On dira que c’est un marqueur du temps qui passe…

https://www.youtube.com/watch?v=kAUahaZTcZg <img data-src=" />







<img data-src=" />

Merci d’étayer ton avis linguistique avec un gamin de 12ans fan de JuL.

Ce n’est pas parce que tout un quartier (nord, de Marseille) te comprend que tu parles français.

C’est un dialecte local, juste.

<img data-src=" />



Je me pose aussi cette question. Après j’imagine qu’il faut qu’il soit suffisamment taillé pour les usages futurs.


Il n’y aura peut être pas la chaîne complète mais aujourd’hui le décodage passe par tellement d’étapes qu’on peut espérer que les plus coûteuses soient quand même déjà faisables matériellement.








skankhunt42 a écrit :



En coupant la tête d’un poulet et quand il à finis de courir sa position correspond à une note.

 



[…]





D’après mes calcul au doigt levé si un film 4k de 90 mn peut tenir sur 5 go cela veut dire qu’un film en 1080p de 90 mn peut donc tenir sur 1.25 go et qu’un épisode de série TV pourra tenir sur un fichier de 625 mo.







SouthPark, MargaritaVille hein <img data-src=" />

J’arrive au même calcul, ca prendra moins de place sur les NAS.



Je me demande d’ailleurs si les smartphones vont pas être les premiers à supporter le décodage matériel vu comme ça bouge assez vite.









Salamandar a écrit :



Éric Piolle* ;)







Merci ;)



A part une optimisation des lecteurs/codec et l’utilisaiton combinée du couple GPU/CPU, je vois pas encore comment.



Wait and see


L’encodage ce n’est rien car si on parle de diffusion, on encode une fois pour diffuser potentiellement des milliers/millions de fois.

Tu penses bien que Netflix dont les coûts viennent en grande partie du transfert de donnée va prendre le temps d’encoder les vidéos correctement.


En petits caractères on lit H.266/WC.








TexMex a écrit :



Bon bin finalement tu vois que ça a de l’intérêt de vérifier !





Ce n’était pas la question initiale.







TexMex a écrit :



Déjà regardé de près une photo 200Mpx ou Gpx ? Et pas en JPG bien sur. Rien qu’à l’œil (qui semble être une référence de choix pour toi), cela se voit comme le nez au milieu de la figure. Hors problème d’optique bien entendu.





Pas compris.

Les photos de 200 MP ou plus qu’on peut voir sont des “collages” de photos prises avec des capteurs de taille plus normale. Il y a autant de détails en zoomant (c’est d’ailleurs ça qui est amusant avec ce genre de “photo” où on peut beaucoup zoomer).







TexMex a écrit :



Il y a du détail sur certaines zones bien évidement. Mais il apparaît également des espaces bien plus facilement traitables. S’en est même surprenant à un point ou se dit qu’il faut revoir / affiner les profils pour mieux “gagner en compression”.





Mais traiter les zones avec peu de variations est la base des algo depuis le JPEG (et même avant).







TexMex a écrit :



Seulement voila. Faire cela rend incompréhensible le locuteur. Si on regarde les définitions de codage on s’aperçoit qu’il n’est fait nulle part mention de la taille des données. C’est ballot.





Et pourquoi faudrait-il le mentionner ? Je pense que tu n’as pas compris le sens de base de codage.







TexMex a écrit :



Déjà fait de la compression vidéo?  Dans les disciplines techniques il faut se défaire des ambiguïtés au maximum. Et en informatique il en a des tonnes.





Vu mes commentaires, il est évident que j’en ai fait (et que je sais comment ça fonctionne pour certains algos).



Il n’y a aucune ambiguïté quand on nomme les choses correctement, ce que je me tue à expliquer. Je me demande si tu fais exprès. Je ne vais pas répéter mes commentaires précédents.







TexMex a écrit :



Utiliser “codage” pour le mode sans perte ne permet pas de se défaire d’un flou grossier.





Non, surtout qu’en général on utilise le terme “codage” sur des fichiers audio/vidéo pour parler de compression (du coup c’est pas un codage).







TexMex a écrit :



Techniquement tout est codage finalement (on va y venir)





NON.



Le codage Huffman est bien un codage, par exemple. La compression JPEG n’est PAS un codage.



Au fait, les techniques de compression qui utilisent des dictionnaires, comme LZW, ce sont des codages justement.







patos a écrit :



Je t’invite à encoder compresser/convertir une source Bluray (&gt;50Go) en HEVC avec x265 CPU uniquement en preset slow, débit 4mbps hors son. [..]

Les encodeurs matériels sont mauvais mais suffisant. Parce que personnellement, passer 20mn à encoder compresser sur ma 2070super me convient plus que 18h sur mon CPU 6 coeurs, donc j’accepte la légère perte de qualité.





<img data-src=" />



J’ai toujours maudit les gens qui préfèrent gagner un peu de temps (enfin, celui de l’ordi) en compressant en mauvaise qualité, plutôt que de compresser en bonne qualité une fois pour toute une fichier qui peut être relu un certain nombre de fois, surtout si on le distribue.

Si la conversion prend la nuit, et bien tant pis, ça n’a aucune importance.









bingo.crepuscule a écrit :



Le problème principal qui se pose, c’est la consommation énergétique.

Même en décodage matériel, le H265 est déjà bien plus gourmand que le H264





En général le décodage est conçu pour être peu gourmand, surtout en matériel, et surtout par rapport à la compression.



Tu as des chiffres sur la différence de consommation dont tu parles ?







bingo.crepuscule a écrit :



Ça n’est pas un hasard si le H265 peine à s’imposer en streaming et à être adopté partout !





C’est comme les codecs précédents, il faut que la base installée soit suffisante (ou que les ordinateurs aient atteint une puissance CPU suffisante). Le H264 a mis du temps aussi.









near667 a écrit :



Désolé de te l’apprendre, mais cette expression est comprise et utilisée par toute personne de moins de 40 ans (dans le langage courant, certes).





Évidemment puisque ça se prononce pareil, c’est juste une grosse faute de français.

Ça me tue que ça ne saute pas aux yeux.







barlav a écrit :



<img data-src=" />

Merci d’étayer ton avis linguistique avec un gamin de 12ans fan de JuL.

Ce n’est pas parce que tout un quartier (nord, de Marseille) te comprend que tu parles français.





Tout à fait.









ErGo_404 a écrit :



L’encodage La compression ce n’est rien car si on parle de diffusion, on encode convertit une fois pour diffuser potentiellement des milliers/millions de fois.

Tu penses bien que Netflix dont les coûts viennent en grande partie du transfert de donnée va prendre le temps d’encoder de compresser les vidéos correctement.





<img data-src=" />



(oui il a tout intérêt à ce que la conversion soit à la fois de bonne qualité et sans prendre trop de place)



J’ajoute que le morse est un codage aussi (on parle de code Morse).

Il y a une forme de compression qui se rapproche de ce qui est exploité par Huffman, les lettres les plus courantes en anglais sont codées sur peu de signes (le “e” est juste un point, le “t” est un seul trait, le “a” et le “i” sont sur 2 signes, etc.), ce qui permet au passage de transmettre un message plus rapidement qu’un codage de type ASCII (même sur 5 ou 6 bits).


Le temps qui passe fait mal aux oreilles… et a surtout une compression / encodage / autotunage / vocodage / accent / vocabulaire / cyclotrucage très étrange <img data-src=" /><img data-src=" />


Si ce n’était que les encodeurs HW qui étaient mauvais, les décodeurs aussi.

Et c’est bien la le but de ma question originale : comment on évalue la qualité d’un système de codage si chacun fait comme il veut lors de implémentation.

Pour en revenir a l’ancêtre divx, a chaque nouvelle version, ils se vantaient d’être plus rapide … en changeant le processeur de test pour un plus puissant.



Eh non, je ne ferais pas d’encodage, il y a bien longtemps que j’ai arrêter de jouer a ca <img data-src=" />








OlivierJ a écrit :



J’ai toujours maudit les gens qui préfèrent gagner un peu de temps (enfin, celui de l’ordi) en compressant en mauvaise qualité, plutôt que de compresser en bonne qualité une fois pour toute une fichier qui peut être relu un certain nombre de fois, surtout si on le distribue.

Si la conversion prend la nuit, et bien tant pis, ça n’a aucune importance.





Oui enfin mettre deux semaines à reencoder 15 films ça me soûle, surtout en été (100% cpu ça chauffe).

c’est le principe d’une qualité suffisamment bonne ;) et franchement je trouve l’encodeur nvenc des rtx très bien, bien meilleur qu’avant.









OlivierJ a écrit :



Il n’y a aucune ambiguïté quand on nomme les choses correctement, ce que je me tue à expliquer. Je me demande si tu fais exprès. Je ne vais pas répéter mes commentaires précédents.







Bin tu devrais regarder les dictionnaires plus souvent. Même ceux appliqués au domaine ne corroborent pas des déclarations.



EOT.

&nbsp;









Pseudooo a écrit :



Le temps qui passe fait mal aux oreilles… et a surtout une compression / encodage / autotunage / vocodage / accent / vocabulaire / cyclotrucage très étrange <img data-src=" /><img data-src=" />





<img data-src=" />







XXC a écrit :



Si ce n’était que les encodeurs compresseurs HW qui étaient mauvais, les décodeurs aussi.

Et c’est bien la le but de ma question originale : comment on évalue la qualité d’un système de codage compression si chacun fait comme il veut lors de implémentation.

Pour en revenir a l’ancêtre divx, a chaque nouvelle version, ils se vantaient d’être plus rapide … en changeant le processeur de test pour un plus puissant.



Eh non, je ne ferais pas d’encodage de compression, il y a bien longtemps que j’ai arrêter de jouer a ca <img data-src=" />





Merci de votre attention.







patos a écrit :



Oui enfin mettre deux semaines à reencoder reconvertir 15 films ça me soûle, surtout en été (100% cpu ça chauffe).





<img data-src=" />

Et pourquoi recompresser (ou reconvertir) un film ?

Et pour des films qu’on conserve des années, oui ça vaut toujours la peine de faire les choses bien. Les MP3 mal compressés d’antan (juste parce que le gugusse est pas capable de laisser tourner son PC), berk (pour prendre cet exemple).







patos a écrit :



c’est le principe d’une qualité suffisamment bonne ;) et franchement je trouve l’encodeur le convertisseur nvenc des rtx très bien, bien meilleur qu’avant.





Pitiééééé…

Rhaaaa… <img data-src=" />



Je regarde des dictionnaires qui sont sérieux. Et surtout j’ai une mémoire des usages, et je refuse le laisser-aller sous prétexte que des geeks s’expriment mal dans des forums (suis geek aussi). La démocratisation de l’informatique a trop laissé se répandre des anglicismes inutiles et des mésusages.








OlivierJ a écrit :



Évidemment puisque ça se prononce pareil, c’est juste une grosse faute de français.

Ça me tue que ça ne saute pas aux yeux.





En fait ce que tu ne comprend pas, c’est que “abusé” est utilisé ici comme un adjectif (attribut du sujet), comme dans l’expression “c’est exagéré”, certes familière à l’origine, mais aujourd’hui largement rentrée dans le langage courant, comme sur notre chaine d’information nationale&nbsp;<img data-src=" />.

Ce n’est donc pas une faute de conjugaison, mais un usage nouveau de l’adjectif auquel la littérature francophone ne nous a pas habitué.

Après si c’est dans cette phrase : “c’est abusé que d’insister autant sur un détail sans lien avec le sujet” c’est effectivement une vulgaire faute de grammaire …









OlivierJ a écrit :



<img data-src=" />

Et pourquoi recompresser (ou reconvertir) un film ?

Et pour des films qu’on conserve des années, oui ça vaut toujours la peine de faire les choses bien. Les MP3 mal compressés d’antan (juste parce que le gugusse est pas capable de laisser tourner son PC), berk (pour prendre cet exemple).





Pitiééééé…

Rhaaaa… <img data-src=" />





Pour économiser de la place ? Les TOs ne sont pas infinis (même si j’ai 48to bruts ^^; )



Et m’en fout ;)



J’ai volontairement utilisé les mots qui me venaient naturellement et que tout le monde comprend, j’ai vu la discussion enflammée sur le sujet dans les commentaires et je m’en fous.


Mais fais-tu partie de ceux qui diffusent ? Recompresser pour un usage local à la limite c’est ton problème, au mieux ça te ferait gagner de la place ça retarderait l’achat d’un nouveau disque dur mais c’est tout. Par contre recompresser avant diffusion en ligne, ça fait gagner en temps de transfert, en stockage sur d’éventuels serveurs et donc en énergie/matériel.








near667 a écrit :



En fait ce que tu ne comprend pas, c’est que “abusé” est utilisé ici comme un adjectif (attribut du sujet), comme dans l’expression “c’est exagéré” [..]

Ce n’est donc pas une faute de conjugaison, mais un usage nouveau de l’adjectif auquel la littérature francophone ne nous a pas habitué.





Effectivement, “c’est exagéré” c’est un peu limite mais ça se conçoit mieux. Et j’avais compris et justement c’est ça le problème :-) .







near667 a écrit :



certes familière à l’origine, mais aujourd’hui largement rentrée dans le langage courant, comme sur notre chaine d’information nationale<img data-src=" />.





Arf







near667 a écrit :



Après si c’est dans cette phrase : “c’est abusé que d’insister autant sur un détail sans lien avec le sujet” c’est effectivement une vulgaire faute de grammaire …





Ah merci :-) .

Oui une faute puisque quelque chose ne peut pas être “abusé”. On dire “j’ai été abusé” pour dire qu’on a été trompé, mais c’est un autre sens.

Cette faute est relativement récente, je dirais ça ne fait que quelques années que je lis ça.







patos a écrit :



Pour économiser de la place ? Les TOs ne sont pas infinis (même si j’ai 48to bruts ^^; )





Dans la mesure où l’espace de stockage ne cesse de grossir (la taille des disques à prix constant), pourquoi recompresser des fichiers, c’est juste une perte de temps (et probablement une légère perte de qualité). C’est comme convertir des fichiers MP3 192 kb/s en AAC 128 kb/s : en plus du fait qu’il y aura probablement un peu de perte, ces fichiers prennent de nos jours une place négligeable sur nos disques.









ErGo_404 a écrit :



Mais fais-tu partie de ceux qui diffusent ? Recompresser pour un usage local à la limite c’est ton problème, au mieux ça te ferait gagner de la place ça retarderait l’achat d’un nouveau disque dur mais c’est tout. Par contre recompresser avant diffusion en ligne, ça fait gagner en temps de transfert, en stockage sur d’éventuels serveurs et donc en énergie/matériel.





Je n’ai pas compris ta 2e phrase. Dans quel cas ça a un intérêt de recompresser un fichier ?

Tout comme les disques qui augmentent en taille, les bandes passantes aussi.



“Dictionnaire qui sont sérieux”…Ha ?! et lesquels ?



Aller au pif : le dictionnaire de l’académie française. Après tout il est officiel. C’est le plus légitime. Non? Cocoricooooo!



Alors regardons de plus près :







  • &nbsp;&nbsp;&nbsp; Encoder… oui! il existe

  • &nbsp;&nbsp;&nbsp; Coder… la aussi cela existe et l’article mentionne encoder en référence.

  • &nbsp;&nbsp;&nbsp; Crypter.. oui mais il est mieux de prendre Chiffrer

  • &nbsp;&nbsp;&nbsp; “Compresser”… ha ! Problème mein général (oups). Cela n’existe pas. Comprimer ou Compacter à la rigueur.





    &nbsp;C’est quand même se foutre de la gueule du monde de parler de vocabulaire et de défense de la langue française face aux attaques anglo-saxonnes quand dans le même temps l’usage de termes non admis est plus que flagrant et abusif!&nbsp; Au point que cela parait pathologique avec un soupçon de compulsivité mal placée.

    &nbsp;

    Et s’il te prends l’envie de donner une leçons aux “Immortels”, appelles moi. Je préparerai deux tonnes de pop-corn (ha mince un mot anglais…sic). C’est quand même dingue de se fourvoyer comme cela.



    &nbsp;


La réduction de ton impact environnemental, tout simplement.

Des fichiers plus petits = moins de charge réseau pour le transfert et moins de besoins matériels (et énergétiques) pour le stockage.

Si on parle de diffusion à grande échelle l’effet est évidemment démultiplié.

Evidemment c’est sous réserve que le décodage ne prenne pas plus de ressources que ce que tu gagnes en transfert, mais ce n’est pas gagné car ça consomme beaucoup de transférer des grosses quantités de données.








TexMex a écrit :



“Dictionnaire qui sont sérieux”…Ha ?! et lesquels ?





Ceux que j’ai lu pendant toute ma scolarité et après, par exemple.







TexMex a écrit :



Encoder… oui! il existe





Il est forcément mentionné, mais n’est pas le plus correct. C’est ce que je me tue à dire. J’ai pas 20 ans hein.







TexMex a écrit :



Crypter.. oui mais il est mieux de prendre Chiffrer





<img data-src=" />

C’est pas “qu’il est mieux”, c’est qu’ici on rappelle très régulièrement que “crypter” ne veut rien dire en français (et encore moins “encrypter”), on dit “chiffrer” dans le milieu ; décrypter existe et signifie qu’on essaie de déchiffrer mais sans la clé (ou l’algo de chiffrement).







TexMex a écrit :



“Compresser”… ha ! Problème mein général (oups). Cela n’existe pas. Comprimer ou Compacter à la rigueur.





<img data-src=" />

OK c’est une blague là.



Non ce n’est pas une blague le dictionnaire est en ligne. Cela prend deux seconde à vérifier.



&nbsphttps://www.dictionnaire-academie.fr/

&nbsp;

fin.

&nbsp;








ErGo_404 a écrit :



Mais fais-tu partie de ceux qui diffusent ? Recompresser pour un usage local à la limite c’est ton problème, au mieux ça te ferait gagner de la place ça retarderait l’achat d’un nouveau disque dur mais c’est tout. Par contre recompresser avant diffusion en ligne, ça fait gagner en temps de transfert, en stockage sur d’éventuels serveurs et donc en énergie/matériel.



Oui j’ai un usage distant mais avec mes 1100mbps d’upload possible, je n’ai pas trop de soucis là-dessus.

C’est un réel choix de ne pas accepter cette course à l’échalote en disant “j’ai de la place, j’en abuse”.

Puis j’avoue apprécier avoir une qualité quasi constante à travers mes films, et ne pas subir les paramètres des autres…



&nbsp;





OlivierJ a écrit :



Dans la mesure où l’espace de stockage ne cesse de grossir (la taille des disques à prix constant), pourquoi recompresser des fichiers, c’est juste une perte de temps (et probablement une légère perte de qualité). C’est comme convertir des fichiers MP3 192 kb/s en AAC 128 kb/s : en plus du fait qu’il y aura probablement un peu de perte, ces fichiers prennent de nos jours une place négligeable sur nos disques.



Tu trouves? Je trouve que les films prennent plus en poids que les disques sont abordables. Puis les prises SATA sont limitées au bout d’un moment.

Perso, je prends du 50Go que je compresse en 3Go. Mon AAC 128Kbps, je le fais depuis un FLAC, pas depuis un MP3…



Fermer