Comparatifs cartes graphiques Q3 2008
|
Comparatifs cartes graphiques Q1 2008
|
Comparatifs SLI et Crossfire Q1 2008
|
- 1 – Introduction
- 2 – Le H.264 : rappel
- 3 – Le H.264 : rappel (suite)
- 4 – Le H.264 par nVidia, le test
- 5 – Performances
- 6 – Bilan
Introduction
Nous sommes actuellement à moins d’un mois de l’arrivée des premiers films sur HD DVD, et deux mois des premiers Blu-ray (du moins chez Ricainland, puisque aucune autre date n’a été annoncée). Même sans parler de ces supports, il faut également rappeler l’arrivée désormais effective des premières chaînes payantes de la TNT (en définition standard toutefois, le passage à la HD pour Canal+ devant se faire dès le mois prochain), qui utilisent le même format, et ce bien que la réception de ces chaînes sur un PCHC s’annonce encore un peu compliquée du fait de la nécessité de disposer du bon lecteur de carte d’abonnement. En outre, les premières cartes graphiques intégrant une sortie HDMI certifiée HDCP arrivent enfin (X1600) ! Nous avons donc voulu faire un nouveau point sur la capacité des cartes graphiques actuelles à prendre en charge la décompression H.264. 
Petit rappel des faits : jusqu’à présent, seul ATI avait fait la démonstration de la prise en charge de ce format, avant de la rendre véritablement disponible il y a un peu plus de 3 mois. Seul problème : entre la présentation initiale en septembre et la réalisation effective en décembre, certaines choses ont changées. Non seulement cette prise en charge se limite aux puces de dernière génération (X1x00), comme cela était annoncé, mais en plus même au sein de celles-ci des différences importantes subsistent. Seules les X1800/1900 prennent en charge le H.264 en 1080p : les X1600 sont limitées au 720p, et les X1300 aux résolutions standards.
nVidia venant enfin d’activer la décompression H.264 via ses drivers 84.21, le constructeur tire-t’il partie des faiblesses de son concurrent ?
- Page suivante Le H.264 : rappel
- 1 / 2
- Suivante
-
coreavc et une grande évolution aussi il permet de diviser par deux les resource processeur et c'est gratuit ^^ (je suis a 30/40% sur un 3000+ mais c'est pas du 1080p) il sera aussi optimisez pour les dual core et même le gpu dans ca version pro.
(sinon le H.264 de apple et une version batarde, n'integrant pas la moitié des specifications de l'h264)
De toute façon le Blue Ray permet d'aller jusqu'à 48 Mbps alors ce sera chaud à décoder si on a déjà du mal à 6 Mbps...
Ce sera peut-être ça leur meilleure protection DRM 
| a écrit : le debit n'a rien avoir. |
Bien sûr que si ! Ce n'est pas le seul facteur mais il est très important, crucial même...
Un plus haut débit signifie une moindre compression ...
Moins de compression, moins de boulot pour décompresser 
Khaele > Ou est le problème ?
jeremiah > Oui j'aurais bien aimé pouvoir conserver celle de test pour cet article mais ca n'a pas été possible 
| Djlauby a écrit : Khaele > Ou est le problème ? |
Un test qui aurait ete sympa aussi, ce serait de changer le nom de la carte x1600xt en flash avec un bios modifie (je sais pas si c'est possible avec une ati) pour voir si la decompression en 1080p est activee ou non.
1) Hmm, je note que les graphiques d'utilisation cpu 1 et 2 se contredisent méchamment, surtout le 2 avec une 1600 devant la 1800, et la 1900 loin derrière, c'est complètement idiot. Ca montre juste que le test à foiré
2) - de compression -> plus de débit -> plus de données à traiter -> plus de cpu requis. Peu compressé ou beaucoup compressé, ce sont les même algorythmes qui tournent dans ce cas ci.
3) Qualité d'image, qui dit que ce sont les memes algorithmes pour ATI et Nvidia. Faut pas faire l'hypothèse de meme qualité d'image !
4) Graphique comparaison mpeg2/h264 montre juste que c'est beaucoup plus long pour le h264. La barre max cpu today ne signifie rien, il "suffit" d'optimiser le décodeur ou de faire travailler plusieurs cores, et la justification décodage par GPU tombe. Mais ca ne les arrrange pas !
arghz > La différence de hiérarchie entre les deux trailers n'a rien de surprenante, en réalité il n'y a qu'une seule chose qui compte c'est : "Est-ce que la lecture de cette vidéo sur cette carte est fluide ou non ?". Ici on précise le taux CPU pour une analyse plus fine, mais les résultats montrent qu'à partir du moment ou la lecture n'est pas entièrement fluide, le taux d'occupation CPU ne signifie pas grand chose. Ce serait plus le nombres de frames non affichées qui serait révélateur. Mais dans tous les cas, ca n'est pas bon.
Pour info les tests ont été réalisés trois fois pour chaque vidéo et chaque carte évidemment, donc il n'y aucun problème en ce qui concerne la fiabilité.
Enfin en ce qui concerne la qualité d'image, je n'ai pas mis qu'elle était équivalente par hasard, les comparaisons que j'ai pu faire que ce soit sur des screenshots ou, plus importants, sur les vidéos au complet, ne m'on laissées voir aucune différence.
avec ma 6800gt light (asus v9999GT, agp) et simple athlon xp 2500+@3200+ je suis autour des 70% d'occupation cpu sur une video 1080p avec wmp10...
une vidéo H.264 en 1080p ? Chez moi sur une vidéo H.264 provenant du site d'appele en 1080p sur mon xp 3200+ et ma GeForce 6600GT jsuis à 100% de CPU et ca rame méchamment ! Meme en utilisant VLC
Faudrait vraiment qu'ils optimisent leurs codecs et leurs logiciels de lecture sinon beaucoup comme moi seront dans la merde pour lire un BluRay ou un HD-DVD
ben celles qu'on peut choper là:
http://www.microsoft.com/windows/w [...] wcase.aspx
The_Magic_of_Flight_1080
euh... c'est bien du h.264? j'ai un doute là...
sinon, on peut en choper où?
Florian > Quel est la différence entre les 2 trailers en dehors du débit? Surtout que la carte la plus performante (1900) devient la plus lente et la moins performante (1600) la plus rapide ! Le graphe obtenu est incohérent non?
Au pire on devrait avoir la meme rapidité
ok pour la qualité d'image :-)
CockHot M@ ster > Non ca c'est du WMV9 HD
arghz > Il s'agit de 2 trailers différents (issus de 2 films différents quoi). Je n'ai pas vraiment d'explication pour les écarts relevés sur les cartes qui ne permettent pas la lecture du seconde trailer, mais à partir du moment ou certaines images sont sautées, le CPU est en retard et son taux d'occupation joue au yoyo. Sachant qu'on ne peut capturer plus d'une fois par seconde le taux d'occupation CPU, alors qu'il varie beaucoup plus rapidement que cela, ca dépend en fait du moment ou il capture le taux d'occupation CPU...
Finalement, on aura quand même besoin d'une machine de ouf, mais ca sera pas pour l'usage interne de Vista...
j'ai un GROS doute sur les lecteurs de salon, si deja un PC au top a du mal...
Non, il y a déjà pas mal de puces spécialisées dans le décodage H.264 sur les rails. La raison en est simple : une puce spécialisée sera toujours beaucoup plus efficace qu'un processeur généraliste, comme à chaque fois. Ca me rappelle d'ailleurs l'arrivée du DVD...
Le retour des cartes de décodages, ca rappelle le DXR2 de Creative
Ou la première hollywood... que des souvenirs...j'ai encore la carte.
Salut à tous, je m'inscris juste pour rectifier une énorme connerie que je viens de lire ...
Quote: ultrabill
"Un plus haut débit signifie une moindre compression ...
Moins de compression, moins de boulot pour décompresser "
N'importe quoi ... c'est tout l'inverse, plus haut débit=plus de détail, plus de détail=plus de calcul ...
Adieu à tous, je suis pas un lecteur habituel du forum ...
| impact95100 a écrit : Un plus haut débit signifie une moindre compression ... |
En théorie pure ca ne devrait pas changer vu qu'il y'a le même nombre de macroblocks à encoder/décoder mais dans la pratique c'est une autre histoire comme souvent...
Essayes au moins avant de lancer ce genre d'affirmations péremptoire, compresse en mpeg-4 une video de même résolution en 1 mbps et en 10 mbps et compares la charge cpu au décodage tu verras bien le résultat, j'ai quelques xvid à 12 mbps même pas en résolution HD et bien ça rame à mort à la décompression...
@bennj:
VLC c'est normal que ça rame même avec une 6600 GT car il n'utilise aucune accélération matérielle à part la conversion yuv/rgb.
> rhododendron
Tu as le meme nombre de macroblock, mais tu as beaucoup plus de data à lire/écrire, et donc à traiter -> plus long
Ce sont des sciences exactes, la théorie et la pratique doivent converger, sinon la théorie est fausse ;-) (la théorie est toujours vrai dans une certaine relativité, c'est a dire dans les hypothèses qu'on l'a écrite)
Vous savez lire ?? Je parle de décompression, pas du traitement des données qui découlent de cette décompression ...
| impact95100 a écrit : Vous savez lire ?? Je parle de décompression, pas du traitement des données qui découlent de cette décompression ... |
Tu t'enfonces...
Comme si on pouvait dissocier les deux, quand tu décompresses il y'a toujours une dépendance par rapport aux éléments spécifiques de l'architecture d'un ordinateur surtout la vitesse d'accès à la ram donc décompresser un flux à plus haut débit prendra toujours plus de temps... (et puis t'as qu'à essayer toi même plutôt que de parler dans le vide...)
rhododendron > des données compressées à mort mettrons un temps fou à être décompressées ... avec un faible taux de compression, c'est moins "compliqué", donc moins couteux en temps processeur, pour décompressé.
Ensuite, ce dont je ne parle pas du tout depuis le début, une plus faible compression engendre bien entendu un plus gros débit que le processeur doit pouvoir traiter
| impact95100 a écrit : rhododendron > des données compressées à mort mettrons un temps fou à être décompressées ... avec un faible taux de compression, c'est moins "compliqué", donc moins couteux en temps processeur, pour décompressé. |
Sauf que c'est faux tout le monde peux le constater facilement... Les videos à faible débit prennent touojurs moins de temps cpu à résolution égale (et pour la même vidéo evidemment) Ce que tu dis n'a aucun sens, d'un côté tu dis que à plus bas débit la décompression est plus compliquée et donc prend plus de temps et que à haut débit il y'a effectivement plus de données à traiter et donc ça prend plus de temps aussi, tu serais pas un peu bizarre dans ta tête ??
"des données compressées à mort mettrons un temps fou à être décompressées"
Ca c'est vrai pour de la compression lossless!
Dans le cadre de la "compression" video, c'est de la compression lossy donc c'est pas vrai!
Juste pour dire que je viens de tester le couple MPC + CoreAVC, et bien, maintenant, le H.264 720p de chez Apple, c'est du plus que fluide chez moi.
Et j'ai qu'une X850 couplée avec un 3500+... (le 1080p n'a aucun intérêt pour moi, étant donné que mon écran est en 1280x1024 )
![[:xam]](http://img.infos-du-net.com/forum/images/perso/xam.gif "[:xam]")
- 1 / 2
- Suivante
-
Moi je suis réellement effaré par la consommation CPU de la HD. Avec un X1600 Pro (qui n'est certes pas une référence) et un X2 4600+, ca laggue par moment sur les trailers Apple !
.
Les graphiques de Florian ne m'étonnent pas du tout
En revanche, on voit bien sur ce graphe http://img.presence-pc.com/dossiers/avivo/cpuutil.jpg que la puissance d'un CPU seul est insuffisante. Existe-t-il des décompresseurs H.264 optimisés pour les Dual Core (par exemple, faire calculer la Motion compensation par le second coeur) ?