J'ai vu que Gordian Knot supportait désormais l'encodage avec x264, en plus des DivX et Xvid. Je me suis laissé tenté. L'encodage se déroule bien, mais je ne sais pas avec quoi lire le fichier. ffdshow semble disposer d'un décodeur, mais n'y parviens pas.
 
En outre, je ne sais pas quel container est requis. AVI ? MKA ? MP4 ? Je pencherais pour ce dernier (car Ahead procède ainsi), mais je ne sais pas comment procéder. Et j'imagine que si GK propose des sorties en AVI, OGM ou MKA, les fichiers doivent pouvoir être lus.
 
Les fichiers que j'ai réalisé sont en matroska. J'ai tenté l'avi, sans plus de succès. Si quelqu'un pouvait me dépanner...

Le conteneur "naturel" est mp4 vu que H264 fait partie de la norme MPEG4.
 
Un thread qui pourrait t'interesser.

Merci pour le lien. On y trouve pas mal d'infos, mais les solutions proposées font appel à des outils qui ne me sont pas familiers. Je vais essayer ce soir, à mon retour.
Sinon, quelqu'un sait comment fourrer les fichiers créés avec x264 dans du MP4 ? Ne faut-il pas sortir un flux brut pour que cela fonctionne (et non pas un avi ou autre) ? Si oui, comment faire ?

En tant que membre du consortium MPEG, Ahead n'allait tout de même pas utiliser de l'avi...
 

Je pense que ça doit passer avec MP4UI/MP4Tools. En tout cas cela marchait pour du mpeg-4 asp.
 
Accessoirement si tu as la suite Nero installée, il y a les filtres de décodage qui sont fournis. Cela doit marcher au moins pour le mp4 et l'avi.

Normalement les versions de dev de FFDShow peuvent lire le AVC (H.264). Sinon t'as les versions de dev de VLC (Videolan) aussi.
Enfin si tu remuxes en matroska, ça marche aussi avec le filter de Nero (version de dev de mkvtoolnix)

PS: il te faut le filtre Matroska de Haali aussi pour lire un tel fichier. MPC est hors course...

"... pour le mp4 et l'avi"
Es-tu certain pour l'avi ? Parce que Nero est installé (la suite du moins), et mes avi/avc n'étaient pas pris en compte. Peut-être un autre filtre a-t-il pris le dessus. Je peux vérifier/changer comment ?
 
J'avais essayé un outil de création MP4 (MP4tools je crois), mais il ne prend en entrée ni avi, no ogm ni mka. Et je sais pas comment sortir de l'avc autrement que dans ces containers.

robux4> merci pour les précisions.

Zut, je viens d'essayer et cela ne marche effectivement pas avec l'avi.
Par contre en activant le décodage h264 de ffdshow, cela marche avec l'avi.

Je suis rentré chez moi avec une clé USB chargé d'appli et de topics variés.Compte rendu de mes essais:
 
- H264 dans un container AVI
Ca fonctionne très bien. Cela fonctionnait même d'emblée sur mon système, malgré les infos que j'ai indiqué plus haut. Je m'étais heurté à un échec apparamment lié à une mauvaise version de ffdshow (dédiée à un CPU particulier), qui du coup ne décodait plus rien. Le retour à une ancienne version m'a permi de décoder le fichier .avi sans la moindre difficulté. Mon Duron 800 parvient même à une restitution fluide, du moins des scènes calmes. Après, le film vire au diaporama.
 
J'ai ensuite mis à jour ffdshow dans une compilation généraliste des plus récente, et si le décodage se déroule à nouveau bien, les lenteurs frappent en revanche tout le film, même les scènes les moins animées. Inutilisable...
 
- H264 dans un container MATROSKA
 
Le nom de Matroskaparser me faisait peur, et j'ignorais comment m'en servir. En fait, seul un double click est exigé...    
Dès lors, les encodages réalisés avec x264 sont lisibles une fois placés dans un container matroska. J'étais content, car j'avais trois pistes son à y caser, chose difficile à réaliser je suppose avec l'avi. Un petit détour par virtualdubmod pour le mux, un double click sur le .mkv et le fichier s'ouvre avec MPC... sans possibilité de changer de flux sonore   Bug ? Problème connu ?
 
 
 
Sinon, l'encodage avec x264 m'a agréablement surpris. Grosso modo du niveau d'XviD. Je ne sais pas comment font certains pour établir des différences qualitative entre deux flux de qualité similaire en l'absence d'outils ABX. Personnellement, je n'arrive à aucune certitude. Je ne peux donc que dire que les deux encodages se valent, et que si x264 est un codec embryonnaire, il semble pouvoir tenir tête avec un XviD arrivé semble-t-il à maturité. Etonnant.
 
Ceci dit, je trouve la qualité des deux encodages absolument médiocre. Pourtant, le débit est de 1100 kbps (le film dure moins de 70 minutes en 16/9). Beaucoup de macroblocs, d'arrière-plans hésitants... Les scènes détaillées sont paradoxalement les mieux rendues ; celle qui intègre un plan 'brouillard' vire au damier.    
 
 
Merci en tout cas pour les réponses

 
Oui, c'est un problème d'utilisateur
 
Quand tu lis un fichier Matroska avec le filtre de Haali, il y a une icone qui apparait dans le tray icon (à coté de l'heure). Et là tu peux choisir ce que tu veux. Comme ça ça fonctionne pareil avec tous les players.
 
PS: toi qui est à fond dans la musique, tu peux lire les fichiers dans foobar aussi

J'avais noté l'icône, en bas à droite, mais je n'ai pas trouvé de mention des différentes pistes sonores. J'ai sans doute mal regardé. Merci

Quand je lis les mkv/h264 avec MPC, y a rien dans le menu audio mais en allant voir dans un des dernier filtre (qui porte le nom du chemin ou se trouve le fichier mais je pense que c'est le filtre matroska), y a une petite fleche qui te permet de changer de piste audio ou de sous titres.
Par contre en effet, avec d'autres player rien.
 
J'avais pas fait attention a cette icone non plus. Mais je sens que ça va etre bien utile

Pour moi y a encore un problème avec h264 de nero et le mkv.
Je sais pas si c'est due au splitter mkv ou à ffdshow
 
ffdshow decode parfaitement les fichier mp4 créés par Nero mais le même fichier dans un mkv pose comporte quelques saccades.
 
Ideologiquement j'aurais quand même préféré utilisé le conteneur mp4 pour une "éventuelle" compatibilité avec les futurtes platines de salon mais les outils de multiplexage en mp4 sont soit pas assez abouti soit un peu trop complexes.
 
Avec graphedit, y a moyen de se debrouiller un peu avec le muxer de Nero mais le problème reste les sous titres au format vobsub. Y a un topic qui traine sur doomç ou un gars a reussi a se servir de graphedit pour muxer des sous titres au format vobsub dans un mp4 mais chez moi(chez tout le monde je crois...) ça n'a pas marché
 
Pour teminer avec x264, y a également uneversion vfw avec une gui utilisable dans virtualdub(c'est peut etre même ça que gordian knot utilise?) faite par syskin qui travaille sur xvid. J'avais testé une version ou la 2eme passe ne marchiat pas mais c'est une affaire a suivre.
http://forum.doom9.org/showthread. [...] adid=87719

 
Gabriel m'a fourni des encodages "comparatifs" , faits avec apparemment l'outil interne Ateme , en ligne de commandes, qui offre plus de parametres que Recode (lesquels du reste?   ) , bref ça fait quand meme bien souffrir XviD , au moins dans des débits "intermédiaires" : disons un full res' (720*576) vers 2Mbits fait tres mal à XviD ;  
 
on y voit bien , ici, la cible d'utilisation (d'optimisation?) de AVC..
 
ça n'enleve rien à XviD ; simplement que mpeg4ASP va se faire, quasi inéluctablement,  distancer par AVC ; simple question de ressources internes nouvelles, plus puissantes, pour developper des codecs (dans le cadre architectural H264/AVC donc)
 
ceci étant , la petite confrontation AVC/XvID , faite avec Gabriel, faisait abstraction d'un parametre d'importance : la période RC ( rate control) ; ça n'avait pour but que de tester ce que le codec a dans les tripes ,sur 30 sec ,  sans le 'parachute' du RC  ; en cela , ça reste peut etre quand meme encore un peu 'abstrait' dans le contexte du rip par ex ;  
 
enfin il importe de by-passer tout filtre PP dans les players , sous peine de void le moindre interet au comparatif....ou de n'y voir peu de différences , tant les filtres de lissage font du mal aux encodages ! un classique hélas  
 
>> et que si x264 est un codec embryonnaire,
 
plus vraiment ...
 
et H264/AVC c'est une architecture complete qui va voir se developper des codecs toujours meilleurs , là ou mpeg4ASP semble en fin de course quant à ses possibilités de developpement
 
reste que tout comme mp3 , le switch va prendre sacrement de temps (amha), tout simplement parceque ça reste bon !
 

J'avais téléchargé les deux fichiers que tu avais mis en ligne
 
Sinon, dans la même veine, toi qui t'intéresse pas mal à l'HE-AAC, j'ai mis en ligne un sample dans lequel un encodage HE-AAC à 96 kbps semble être à la traîne par rapport à un balan encodage en MP3 (commande lame un peu modifiée) :
 
ftp://ftp2.foobar2000.net/foobar/krenek.zip
 
 
Tu en penses quoi ?

le h264 AVC de Nero a encore peaucoup de bugs... j'ai encodé pas mal de choses en AVC avec les parametres a fond (mici le 3400+) et si le résultat est bon sr mon PC, il l'est nettement moins quand je matte ça sur la TV... il y a un gros bug de "clignotement" des macroblocks , ce qui est très désagréable...

 
ben, rapido, et meme si là les 621 Altec ne sont pas des outils exceptionnels , bien sur, je dirais que nan la version AAC > MP3 , quand meme sans trop de difficulté(s) ; pas besoin d'y revenir plus de 2 fois disons  
 
et au moins sur deux plans : meilleure dynamique et meilleure conservation de la clarté , le mp3 sonnant un peu 'arrondi' sur les angles , voire par suite spectralement modifié (probablement par éffet de masque)
 
ensuite en regardant rapido aussi, via FooBar, je vois donc
 
mp3 = Lame 3.97 VBR
AAC = Nero 2.9.9.999
 
edit : pourquoi resampler 44.1 dans Lame , puisque le source est 44.1 ?

Met un casque, et utilise un soft de type ABX si ce n'est pas déjà fait

lame à 96 kbps rééchantillonne par défaut à 32000 hertz. Il faut donc  demander à l'encodeur de maintenir la fréquence d'origine. A 32 Khz, la comparaison avec l'HE-AAC peut être faussée par ce seul fait.

 
l'outil de test le plus redoutable pour tester reste un tft/lcd 'économique' disons;   j'ai , par ex, un LG 1915s qui est tout simplement une horreur pour regarder un encodage , et meme un movie tout court du reste  
 
c'est 'pas cher' mais c'est bien dégueu    
 
mais , en revanche, quel outil "de test" ! ça pardonne rien (halos , ringings, blockiness, ect..)
 
bref si ça sort 'bien' sur une telle horreur , alors ça sera nickel , magnifique, sur un ecran CRT  
 
le pb que tu évoques, de sortie tv , ne concerne tres probablement pas/plus le codec...; sauf si tu parles ici d'un encodage entrelacé(?) (pas encore fait , donc je peux pas te dire)

 
tres franchement , là les différences sont telles (chez moi au moins) qu'il n'y a pas besoin d'un ABX , ni meme d'un outil d'écoute beaucoup plus précis ; surtout que comme il y a le fichier référence, ça aide beaucoup à dire ,au moins, ce qui s'en rapproche le plus  
 
(again dans mon cas )
 
 
dans ce genre de cas de figure, de 'désaccord' , parfois il ne s'agit simplement que de l'usage de Dll decodage de versions différentes ; c'est peut etre le cas (?)

D'autres peut-être pourront donner leur avis sur les échantillons que j'ai mis en ligne (420 ko à télécharger, encodages inside) ?
 
Merci en tout cas pour ton avis. Cela tend à montrer que les encodages perceptuels ne fonctionnent pas uniformément d'un auditeur à l'autre.
 
P.S. Tu reproches quel défaut à l'encodage MP3 ? N'entends-tu pas une très forte granulosité/ringing sur l'encodage HE-AAC (décodé avec quoi d'ailleurs ?)

 
en fait , j'ai été manger, j'ai donc 'oublié' les premieres impressions et j'ai remis dans FooBar , le cycle Wav, mp4,mp3 , en boucle ; de sorte que chaqque sample encodé est précédé ou suivi de l'original ; comme c'est court ce genre de méthode est fiable
 
et donc il ressort , apres digestion (!) , que effectivement le petit surplus de dynamique de mp4 (aac) ici est 'suspect' effectivement
 
donc mp3 fait encore de la résistance à 96kbps et c'est tant mieux    
 
par contre , je suis réticent , de longue date, à analyser par type de sample (et les artefacts potentiels susceptibles de subvenir) parceque on en arrive à trop morceler l'approche ; nécéssairement plus globale
 
à ce titre , j'en ressortirais alors ( 'pondéré' , en somme ) , sans réelle préférence , meme si différences il y a ; trop petites pour etre significatives de certitudes  ; mais cela , par contre, je le mets au crédit de l'outsider (mp3)

 
L'échantillon posté fait figure d'exception. Poche locale de résistance d'une guerre largement perdue. A 96 kbps, l'HE-AAC est presque toujours supérieur à un encodage MP3.
En fait, il faudrait davantage comparer les encodages réalisés à même débit entre le profil LC et le profil HE (sans et avec SBR), pour bien mesurer la pertinence du SBR et ses effets négatifs. Parmi eux, je peux par exemple citer :  
- difficultés sur certains signaux tonaux aigus (problème peut-être lié à un manque de maturité du codec)
- pre-echo exagéré (difficulté structurelle semble-t-il)
 
Tout cela pour dire que l'HE-AAC ne me parait pas très intéressant passé un certain débit (64 kbps en stéréo), et que même là, la qualité reste vraiment médiocre (quoique parfaitement acceptable sur de petites enceintes).

Le problème vient peut-être en effet d'un problème d'entrelacement. En effet, pour afficher sur une télé il faut, hélas, ré-entrelacer le contenu.
 
Concernant la gestion de l'entrelacement, la suite Nero ne gère pas encore l'encodage de contenus entrelacés en H264. L'encodeur lui-même le gère parfaitement, mais pas le front-end (ici Nero).

J'allais poster sur HA, mais vu que t'en parles ici, je vais le faire là. (pas mal le HS d'ailleurs... )
 
Sur ce sample, je perçois nettement le ringing sur le flux aac. Ma préférence à ce niveau serait plus pour le flux mp3.  
 

C'est se que je compte faire puisque un dév m'avait demandé de comparer l'AAC/HE-AAC de Real @128kbps...D'ou ma requête, Guru, pour se que je t'avais demandé dernièrement. Malheureusement, j'ai peu de temps en ce moment.
 
Cependant, vite fait un test LC-AAC vs HE-AAC @128 kbps avec ton sample :

C'est fou.... On distingue allègrement les artefacts (ringing surtout) sur l'HE-AAC. Le LC s'en sort le mieux ici, incontestablement. C'est pas pour rien que les dév de chez Nero ont tuné le SBR pour les bas-débits à mon avis...
 
Si certains voudrez tester du he-aac @128kbps...le sample à télécharger [fait avec BeSweet version 1.5b29 + bsn.dll + aacenc.dll v2.9.999 de Nero, puisque l'on peut contrôler entièrement les lignes de commandes sous cette CLI. ]

koabaia> non non, ce n'est pas entrelacé et ce n'est pas due a la sortie... sur doom9, bcp se plaignent de ce bug tres genant...

Merci beaucoup kurtnoise pour la mise en ligne de ce fichier (et pour ton retour sur la qualité des encodages - cela me rassure de voir que je ne suis pas seul à percevoir des défauts grossiers à l'HE-AAC là dessus). Je voulais dernièrement te demander de me réaliser un encodage forcé à 128 kbps en HE-AAC, ayant pas mal de peine à y parvenir moi-même Pensées croisées...
 
Pour ceux que cela intéresse, une petite comparaison fréquentielle entre l'original et la version encodée. Elle permet de particulièrement bien voir que le SBR relève plus de la production de hautes fréquence que de leur reproduction. Bien entendu, c'est une simple illustration, pas une quelconque preuve qualitative
 
ftp://ftp2.foobar2000.net/foobar/heaac128.gif
 
A conserver dans un coin, pour l'opposer à ceux qui voient dans l'encodage lossy un simple procédé de cutoff, coupant les plus hautes fréquences mais maintenant indemne le signal en deça de la coupure.

 
c'est je dirais un vieux sujet du domaine subjectif de l'écoute ;
 
cela fait > 25/30 ans que l'on s'est aperçu (enfin que des appareils sont alors sortis ; cf les premiers Aphex) que un 'apport' judicieux d'harmoniques 2 notamment , était interpreté "favorablement" au plan de l'écoute ;  
 
j'ai vu débarquer fin 70's l'Aphex A ( uniquement à la location par minute à l'époque !) , qui a fait les beaux jours de myriades de titres...; puis ensuite les versions 'sédentaires' abordables B, C, etc...; enfin la concurrence donc
 
je serais donc méfiant sur ce distingo , ou 'illustration' péjorative
 
particulierement dans ce domaine aussi particulier de la réduction extreme de bit rate , des lors que le 'procécé' a montré satisfaction , par lui meme  
 

Oui   Mais enfin, de là à parler "d'apport" notamment "judicieux" dans le cas présent, y a quand même de la marge. Dès 12 Khz, tout est bousillé. Ni plus ni moins. Et pourtant, on est à 128 kbps, ce qui de nos jours est tout sauf un 'petit' débit et ne correspond pas à une réduction "extrême".
 
Le SBR a plein d'avantages, que je ne conteste pas. Mais apparemment, les hautes fréquences qu'il permet de restituer sont d'une correspondance douteuse par rapport à l'original. D'un point de vue subjectif et auditif, ce décalage ne semble pas vraiment être gênant sur certains types de signaux (je reste bluffé par la qualité d'un encodage de Metallica à 32 kbps en parametric stereo) ; mais sur d'autres, comme ce violon qui est défini par de jolies harmoniques, on voit et entend les limites du système.

 
j'ai pas suivi le fil précis sur le sample 'visé' (?) , mais piqué cela SBR 'au vol' , quant au principe lui meme
 
hors cela, il y a aussi le fait que le 'principe de départ' disons (apport de H2 donc dans le cas évoqué) s'appliquait 'naturellement  et directement' ,disons, dans le domaine analogique ;  
 
la transposition , et la reprise en tant que procédé a posteriori , dans le domaine des techniques de compression est à prendre avec beaucoup plus de recul , bien sur  
 
pour le reste , [le domaine de perception subjectif] , il reflete finalement la grande diversité humaine ; certains seront sensibles à des écarts dynamiques , d'autres à des écarts fréquenciels, d'autres à de la disto d'intermodulation, etc..etc..
 
et leur singularité peut tres bien ne pas s'appliquer à tel ou tel sample ; ou plutot leur degré d'alaxité ( tolérance) ;  
 
pour mémoire , je ne supportais pas ( et j'ai revendu ledit casque du reste) le manque de dynamique et ce que je percevais comme un déséquilibre ( manque) dans le médium du casque Philips HP890 SBC ; d'autres ne ressentait pas tant de gene , ou leur degré de tolérance englobait *ce type* de phénomeme
 
toutes notions qui n'apparaissent pas dans les mesures linéaires classiques ; là encore c'est vers la fin des années 70 que sont apparues des analyses plus fines ( TDS / time delay spectometry par ex) qui ont definitivement relégué le bon vieux banc B&K 'linéaire' au rang d'outil rudimentaire (utile pour autant)
 
toute la difficulté ajoutée du champ des techniques de compression est (amha), que les 'artefacts' sont encore moins susceptibles de faire l'objet de définition rigoureuse, et encore-encore moins de corrélation avec des mesures physiques directement afférentes (explicatives)  
 
c'est pas pour cela qu'il faut nier toute validité à des travaux  d'évaluation ; loin de là

 
Tout à fait. Mes intentions étaient autres : prouver, si cela est vraiment nécessaire, que l'apport fréquentiel du SBR relève d'une construction fictive. Certains ne perçoivent pas le décalage ainsi (dé)montré, mais d'autres y sont sensibles. Par ce seul fait, il devient impossible d'affirmer avec pertinence que le SBR, du moins en l'état actuel, puisse prétendre à la transparence dans le domaine du codage fréquentiel.
 
 
Tu me diras peut-être qu'on le savait, que c'est une évidence et que je ne fais que démontrer que l'eau est mouillée, etc... Je répondrais juste que certains l'ignorent, et voient dans l'HE un outil majestueux pour s'indigner qu'il ne soit pas disponible à plus haut débit. Pour leur répondre, cet échantillon peut servir d'exemple ou d'illustration

oui, oui , ça releve plus de 'béquilles' ( pardon aux anciens du forum ) qu'autre chose ; maintenant il faut raison garder , quand on descend aussi bas que 32kbps stereo, ou meme 64k, il ya fort peu de chances que l'on puisse jamais atteindre à la 'transparence' , à fortiori via des outils de "restauration"
 
HS : tiens , puisque je te sais (comme moi) , amateur de zik classique , à quel format, quel débit, consentira(i)s tu d'acheter en ligne via X ou Y  ?  je n'ai aucune autre réponse satisfaisante que un format FLAC, Monkey,  ou assimilé ; ça fait pas avancer le schmilblik
 
bien sur c'est un peu LA question piege en regard des diverses évaluations et comparos , arrivant à la conclusion que X est estimé quasi transparent , à tel bit rate  ; est ce que le rationnel ( la constatation) l'emporte , ici, pour autant....
 
ou bien quelles que soient les perfs du systeme, le 'principe de précaution' va de toute façon prévaloir !

 
La petite flèche c'est VSfilter. C'est un peu pourri d'avoir le filtre de sous-titre qui va bidouiller les pistes de son, je trouve. L'icone du filtre d'Haali est blanc avec un petit logo matroska. Et là normalement t'as tout ce qu'il faut.

 
Cela dépend du format utilisé, voire du type d'enregistrement. Pour du clavecin par exemple, 192 kbps auront du mal à me satisfaire pleinement.
Franchement, je n'en sais rien. Je préfère m'abstenir de tout achat de formats compressés avec pertes et présentant des restrictions en terme de transferts.

c'est bien tout le coté paradoxal
 
on lit parfois  sur tel ou tel codec , @tel ou tel bit rate, des appréciations du type "on est au niveau de la transparence "  (ceci accrédité par des stats de type ABX , par ex) , mais néanmoins il persiste un reflexe ultime , quasi contradictoire , qui rejette 'tout format compressé'
 
(et je me range dans ce bataillon 'réactionnaire' de toute façon ! bref, c'est une remarque d'ordre général disons)  
 
 
 

C'est parce qu'on n'est jamais "au niveau de la transparence" avec une compression avec pertes.
Tout ce que l'on peut atteindre, c'est que la différence avec l'original ne soit en général pas significative. Cela veut dire que pour la majeure partie des auditeurs et sur la majorité des échantillons cela semble transparent.
Le problème est que l'on peut tout-à-coup tomber sur un échantillon non transparent, voir franchement non transparent. (ce qui n'affectera pas le critère de transparence du codec de manière significative)
 
Je comprends tout à fait les personnes qui sont réticentes du fait de ce point.
 
C'est en tout cas beaucoup plus compréhensible que ceux qui rejettent en bloc les codecs avec perte sous le simple prétexte qu'il y a des pertes, sans même avoir fait de sérieux tests d'écoute.

 
 
1) bien sur , mais dans le cadre d'une écoute "continuum" ( un progamme dans sa durée) le passage 'non transparent' devient quantité négligeable, voire n'attire meme pas l'attention ;  
 
regarde un DVD Mpeg2 @6Mbits , frame par frame , et ma foi, les défauts sont là ; mais non significatifs dans le cadre d'une visualisation 'continuum'
 
2) tout comme un parasite Hertzien en réception télé ou radio  
 
3) si le principe de précaution ,  la réticence , est quasi 'viscerale' , alors l'augmentation des tuyaux n'augure d'aucun avenir commercial pour tous ces codecs (?) , sur certains segments de distribution ; il faut donc cesser de les tester avec Monteverdi et en rester au rap !
 
pour Monteverdi, quel sera l'interet de tlc un format audio compressé des lors que l'adsl2 s'installe déjà avec des débits entre 8 et 20Mbits disons , selon distance  (je suis déjà à 7Mbits ATM en adls1 à 3,5km ; ie 640Ko/sec dld !!) ; 20 minutes pour un CD normal 74' ; et donc bientot 15, 12,..10 minutes ...

pour revenir sur le topik ( H264 / AVC) , j'avais pas lu le codec shootout de Doom9 ; plutot bien fait , et avec une méthodologie clairement expliquée ; mais quel dommage de TOUT gacher à la derniere minute !!!
 
j'ai regardé les samples avant de lire, et j'étais persuadé qu'il y avait un lézard TRES visible , au niveau du playback ; le voila
 
>> I've used the default playback filter for every codec, using automatic postprocessing strength selection where this was possible. In XviD I turned on both deblocking and deringing, in HDX4 I turned on chroma and luma deblocking. I used a special Ateme DS filter for the NeroDigital playback (since the Nero filter only decodes Main Profile content - beta testers might also know an earlier version of this filter). I disabled the film effect where applicable. A note on this: HDX4's optimize for film mode actually filters out film grain during encoding, stores a parametric representation of the grain and applies it again during decoding. Thus, we have grain in HDX4 content. In future comparisons, I expect to see more of this as this method has been added to the AVC High Profile.
 
comment gacher toute la rigueur d'un boulot    
 
les codecs doivent *d'abord* se comparer , brut de béton, hors de tout deblocking , deringing ,etc..., puisque ce que l'on veut précisement voir c'est le niveau brut des artefacts ! et non le résultat apres un traitement  PP , qui constitue une variable (individuelle) rajoutée qui fout tout par terre...