Reprise du message précédent :
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...
 
 

 
Gabest peu pas modifier MPC pour integrer le filtre d'Haali ?

On sait plus trop ou il est gabest. Installe le séparement le filtre d'Haali. Y a maintenant une option qui permet de desactiver le splitter Matroska de MPC.
 
Bonne nouvelle également, ffdshow arrive a lire correctement le h264 de Nero sans saccades avec la version du 01/02/2004. Les saccades n'étaient présentes que si le h264 était à l'intérieur du mkv.

 
Pas si sûr. L'exception attire plus l'attention que le continu.
Regarde un film de qualité médiocre (VHS, TV...) : passé quelques minutes, tu cesses d'être gêné, et tu oublies la médiocrité technique au profit du message. Mais à l'inverse, si tu as l'occasion de voir un film dans d'excellente qualité (cinoche), et qu'un incident bref survient (grosse poussière, décrochage de la pellicule), chacun sera interpellé.
 
Il m'arrive souvent la même chose avec mes écoutes sur baladeur. La qualité me satisfait généralement, mais vient toujours un évenement désagréable me rappelant qu'il s'agit d'en encodage avec pertes.

OK; alors quels seraient , à tes gouts , à ton oreille plutot, les codecs et leurs settings susceptibles de te 'perdre' statistiquement via un test AB , dans une écoute continuum d'un sample de zik classique d'une durée significative
 
'perdre' veut dire ici que tu ne sais bien sur pas quel est le sample d'origine ; et donc seule ta préférence déterminera la décision quant au stade ou un codec, et son setting, attendrait un niveau statistique ou , soit :
 
A) tu es à 50% ou plus dans l'incapacité de dire quid des samples originels,  
B) ta préférence atteint un niveau statistique égal à 50% pour les samples compressés

J'en sais rien.
Le MP3 risque de se trahir sur les attaques (pré-écho) même à débit élevé.
Vorbis attirera mon attention sur le bruit de fond additionnel et la grossiereté de certains timbres (jusqu'à 200 kbps environ).
Le MPC sera sans doute OK avec --standard.
L'AAC a moins de défauts génériques.
Je connais mal le WMA.
 
Voilà pour les défauts perceptibles sans comparaison. Reste à déterminer un panel représentatif, pour donner sens aux 50%...
Difficile de répondre.
Je pense que le mpc est hors-jeu (trop de problèmes sous -q5), car débit minimal requis trop élevé. Pour le reste, je ne sais vraiment pas.

 
merci    
 
mais note que je te demandais , ce qui serait susceptible d'échapper à ta vigilance, et non... l'inverse    
 
je crois percevoir que , selon codec(s), et vers des débits de l'ordre de  >300k , tu sembles envisager une ou des possibilités  
 
c'est pas si mal, en ce que ça correspond déjà à moitié moins de bit rate que du Monkey ou assimilé
 

Ce serait un comparatif d'encodeurs, pas de codecs.
Si on veut une comparaison pertinente pour un utilisateur, il faut se placer dans les conditions qu'il aura, en essayant d'obtenir le résultat optimal.
Aux débits de ce shoot-out, le postprocessing apporte un réel gain, et sera utilisé par les utilisateurs. Comparer une sortie qu'il ne verront pas (sans post-processing) n'a pas beaucoup d'interet dans le contexte de ce test.

A 300 kbps, quasiment tout est transparent, y compris en condition extreme de test (extrait de 2-3 secondes réécouté de façon acharnée).
 
EDIT: tout m'est transparent...

Allez, un petit sample de castagnettes avec Blade en 320kbps...

 
c'était mon sentiment    
 
j'ai ciblé un peu haut pour pouvoir entamer ...une descente éventuelle ;  et c'est bien là , ou ça devient (plus) interessant ; qqchose pour toi vers 256k...voire meme 192k , par ex ? VBR/ABR peu importe

 
si ce n'était que LE contre exemple, tout va encore bien , nan ?

Même à 130 kbps, beaucoup d'encodages (50% ? plus ? moins ?) passent sans problème à l'écoute avec un format moderne (voire lame -V 5).
Je pense que le challenger le plus redoutable serait l'AAC vers 160 kbps (je précise cependant que je m'avance sans véritablement tester) :  
 
• contrairement au mp3 il ne souffre que très peu de préécho
• contrairement à vorbis il n'a pas de problèmes liés à la stéréo, au bruit de fond, etc...
• contrairement au mpc, je peux le paramétrer pour 160 kbps (sans causer du moins de rupture qualitative, comme c'est le cas avec mppenc entre -q4.99 et -q5.00).
 
Évidemment, l'aac à 160 kbps ne sera ss doute pas absolument transparent, mais je pense qu'une majorité d'échantillons me seront transparent, du moins ne susciteront pas de gêne à l'écoute directe.
 
Je précise qu'il s'agit d'une hypothèse - je fais peut-être erreur.

 
là, gros désaccord Gabriel !
 
1) ce ne serait pas un comparatif "d'encodeurs" !? mais toujours bien de codecs
 
2) alors ne jugeons pas/plus des samples audio 'pieges', au casque , en écoute en boucle , dans le noir , 50m sous terre ; mais alors sur une *écoute moyenne* ? heu...c'est peu acceptable , en tant que méthode, non ?  
 
3) lorsque l'on cherche à comparer le niveau d'artefacts *propre* à chaque codec video , ce n'est pas en les masquant par un PP que l'on va y arriver ; au mieux le blur va niveler les différences, au pire il va ...dégrader le signal "utile" ! y compris au débit de ce test ;  
 
 
tout comme un filtre passe-bas en audio ...
 
enfin je regarde perso 99/100 sans PP ; bah tout comme un DVD en somme

 
tu valides ton hypothese bientot ?  
 
voire en montant un plus haut si nécéssaire

 
 tiens parlons en de la partie encodeurs dans ce "test"...
 
comment sélectionner , au visionnage, une frame à comparer ? pas simple...
 
c'est totalement passé sous silence ( volontairement?, par oubli? par manque de rigueur ? ) mais peut on comparer une P frame de rang X avec une B frame de rang x !!??

 
Je n'ai guère trop le temps de faire des tests... Donc j'en reste à l'hypothèse

 
je verse ce doc , copyrighté Kobaia , de la part du post-processing dans RV9 par ex ; qui comme tu le sais est un PP automatqiue , non débrayable....  
 
http://nozilla.free.fr/RV9_postprocessing.jpg
 
comment masquer la misere...ou encore que compare t'on ici ? le codec ou son PP !!

Un petit Kraftwerk peut-être?

C'est cela oui.... et tu crois peut-être que les players DVD modernes n'utilisent pas de post-processing?
 
Désolé, mais le post-processing vidéo peut apporter un gain subjectif significatif. Dans ce cas, il serait dommage de s'en priver.
Il fait partie des outils d'un codec, bien qu'il puisse aussi intervenir après le codec. Si il fait partie du codec, pourquoi s'acharner à le supprimer?
 

En supprimant volontairement des outils du codec? C'est comme dire "je ne veux pas du joint-stereo, moi. Je veux de la vraie stéréo en dual channel, moi"
 

Rien à voir avec le choix des samples. C'est comme si tu refusait d'utiliser le dithering lors de la restitution. Si il t'est offert, ce serait dommage de ne pas l'utiliser.
 

Je note le ton assez catégorique. Devant une telle certitude, il ne sert visiblement pas d'essayer une quelconque explication. Un autre jour peut-être?

"Codec" ne veut pas dire "Codeur/Decodeur" ?
 

Tu cites les conditions d'écoute, avec les vidéos, baisse la lumière, c'est tout.
 

Les blocs d'une Pframe se basent sur l'Iframe (ou Pframe) précédente alors que ceux des Bframes peuvent se baser sur la précédente et la suivante. Ainsi le bloc sera flouter (si il se base sur avant et apres). Les Bframes seront plus petites et moins précise. Du fait qu'elles ne sont pas utilisées comme référence pour d'autre frames (contrairement aux I et Pframes), le codec se permet d'utiliser un plus fort quantizer (plus grande approximation). (Il me semble que c'est ca, mais ca m'a toujours paru compliquer, je doit sans doute me tromper).
Donc comparer une Pframe et une Bframe revient à comparer une twingo à une Ferrari niveau prix alors qu'il faudrait comparer 2 modeles de categorie equivalente (Pframe codec A avec Pframe codec B et non Pframe codec A et Bframe codec B)
 
Sinon, je ne sais pas comment se positionner sur une frame précise pour le rv10
 
[H.S.]
Le XviD, pour un bitrate moyen, me semble qu'il y a trop d'artefacts (blocs, ringing...) comparé aux codecs plus récents qui ont un PP plus "puissant". Le probleme du XviD est la limitation de l'ASP ou d'un PP laissé de coté par les développeurs ? Avec la version 1.1, le deblocking sur la chroma (ou la Luminance ? dsl, j'y connais pas grand chose) est trop exagéré
[/H.S.]
 
P.S. : Comment désactives-tu le PP du RV10 ?

 
Gabriel, c'est un peu facile comme artifice...
 
tu sais tres bien que , passé un certain niveau de qualité d'encodage, le post processing dégrade le niveau de détail(s) que le codec (désolé de scinder encore les outils) arrive pourtant à encoder ...
 
via des lissages , assez visibles lorsqu'il est possible de désactiver ledit PP ;  
 
à un certain niveau , c'est meme parfois pratiquement plus que le PP qui va faire (introduire !) la différence ; certains sont notoirement 'violents' et désavantagent les codecs qu'ils sont censés servir...
 
citons RV déjà (et WM)
 
et tu ne réponds pas non plus sur le point de prendre une image un peu au hasard, dans un comparo entre une demi douzaine de codecs ; rien n'est précisé sur la nature et le rang de la frame pour chaque codec certes c'est pas simple ; perso, j'aurais fait K+1 , enfin ...si ça donne P et non une nouvelle K    ; mais là rien n'est dit  
 
la part propre du PP , dans tout comparo , avait déjà fait l'objet d'un débat chaud mais courtois , il y 30 mois (?) , avec l'excellent Suesser, et le non moins bon Homie-Fr
 
j'ai gardé un petit dossier, un peu par hasard,  sur CE point tres précis , pratiquement le seul qui arrivait à faire (introduire ..)une différence entre RV9 et DivX5.02 sur des encodages de Matrix1 , à des niveaux de compression déjà bien élevés ( 640*272 @650k) , dont on aurait pu penser que le niveau de dégats serait déjà 'suffisant' pour établir une hiérarchie ; et ben nan ! il fallait en venir 'à la part' du PP...
 
http://nozilla.free.fr/snaps_RV9_Div5  (archive .rar 1Mo)
 
en clair , en désactivant le PP dans DivX le niveau de détail conservé lui permettait de prendre l'avantage sur RV9 ;  alors que en activant le moindre déblocking , niveau 1 sur luma , bernic : les deux étaient affligés des memes lissages (blur des détails conservés ) ;  
 
bref , à ton avis, convient-il, ici, d'activer le PP de DivX  ( et donc peu ou prou obtenir le meme type de rendu 'lissé' que RV9 ici) ou bien convient-il de le ...désactiver et récuperer tousles détails que le PP fait passer à la trappe ?  
 
cqfd ?!
 
ou alors est ce ton niveau de certitude , et ta remarque parfaitement 'catégorique, qui ne saurait accepter un fait ?
 
(je ne parle meme pas d'évidence par courtoisie , respect , et amitié forumale  )
 
short answer = d'abord comparer les codecs , à un bon niveau de transparence , là ou le PP n'est pas encore "utile" ;
 
edit... petite perfidie : probablement le fait que le codec Ateme/Nero integre un PP plutot fin et subtil , te convient-il tres bien dans ce genre de comparo ; il t'est évidemment difficile d'etre 100% objectif , je crois avoir lu cela qq part  
 
edit2 : ooops , j'oubliais , que quand meme dans un récent petit comparo privé, il en était ressorti les limites ( la visibilité) du PP du codec AVC Ateme , en 'simple' comparaison avec XviD sans PP ; 720*576 @3MBits et+  ; du reste je reste perplexe sur ce PP , tel que dispo dans Nero Showtime , dans les prefs' 'qualité video' ; entre "off" et "auto" ou meme "max" , ben ,tres, tres peu de différence   s'agissait il, ici, d'un cas particulier (l'indice Q global du clip était-il suffisament élevé pour que le PP s'auto-limite en somme !?)  
 
toujours est-il que si la position "off" correspond au by-pass total du PP, alors c'était alors bel et bien le seul codec qui blurait le grain important sur le film source !? là il va falloir choisir

 
Il me semble que le test de Doom9 ne se base pas sur une frame (qui peut-etre une I, P, B selon le codec) : il a encodé les 2 films et l'épisode, puis a choisi divers séquences révélateurs pour chacun. Les screenshots ne servent que d'illustrations.

 
j'en suis resté à "we are the robots"    
 
mais bon je ne demande qu'à parfaire ma culture musicale ; plus précisement , puisque tu sembles disposer de samples Kraftwerk qui mettraient à mal tout codec meme à 300kbits ; OK voyons cela..
 
en phase deux, je serais interessé de (voir) verifier, valider , l'hypothese de Guru, que AAC @160 à 200k pourrait atteindre à un niveau de transparence suffisament haut pour constituer , alors, un format de distribution 'acceptable' , meme pour les plus exigeants
 
ce qui semble le brillant futur de AVC ( bon format de dsitribution )
 
@Castor-troy : j'en suis resté à l'éxegese des screens , conforté dans "mes certitudes" que je connaissais 90% de la réponse globale
 
la bonne surprise *récente* , est le niveau actuel de AVC ; la version Ateme est remarquable    ; ce n'était pas encore la situation il y a moins d'un an ; ( pas Ateme en particulier je veux dire ; nan , H264/AVC en général)
 

Tentons une explication...

Non, cela je ne le sais pas. Je peux bien sûr constater que certaines implémentations de déblocking ne sont pas vraiment optimales, mais cela ne permet pas d'affirmer que le post-processing dégrade systématiquement la qualité.
 
* Le post processing n'est pas uniquement le déblocking
* Un étage de post-processing peut très bien choisir le niveau de filtrage suivant les blocks, au lieu d'appliquer le même filtrage de façon uniforme. (parallèle: le mode mid/side stereo)
* ce n'est pas parce que des implémentations de post-processing ne sont pas optimales qu'il faut pour autant supprimer systématiquement cet outil.
 

Ca, c'est le problème des développeurs.
 

Si, c'est dit. Ce n'est nullement un test d'images fixes, mais de séquences. Les images ne sont là que dans un but illustratif. Il n'est donc pas question de prendre des images au hasard, ce sont des séquences qui sont comparées.
En audio c'est pareil: on ne compare pas le résultat de l'encodage d'une seule frame.
 

La partie déblocking du codec Ateme, n'est pas vraiment subtile. Elle est conforme à la norme H.264, c'est tout. Les autres codecs peuvent aussi faire un déblocking adaptatif si ils le veulent.
 

Tout codec non, mais les mp3/wma/atrac3 oui. Le sample qui a servi au test 32kbps est fort interessant:
http://www.rjamorim.com/test/32kbps/results.html

 
 
tentons une réponse...  
 
je n'ai jamais dit que "systématiquement" le PP faisait baisser la qualité ; loin de là ; j'ai simplement dit que *passé un  niveau de qualité d'encodage* , là oui il peut se montrer négatif ; pas dans son principe , mais bien sur dans son implémentation , au cas par cas
 
d'ou il me parait judicieux de déjà comparer les codecs à ce niveau là ; et ça ne veut pas dire, pour autant , des bit rate extravagants ; le petit exemple RV9 vs DivX5 , en situation rip 1CD @650k est bien l'exemple meme que l'aspect négatif , surajouté, relevant du seul PP , peut commencer dans des conditions de taux de compression déjà mastoc
 
>>Un étage de post-processing peut très bien choisir le niveau de filtrage suivant les blocks, au lieu d'appliquer le même filtrage de façon uniforme.  
 
c'est ce que j'avais relevé , de visu, dans mon post plus haut , avant que tu ne confirmes (?) cela pour l'AVC Ateme conforme H264 (deblocking adaptif) ;
 
 tu n'as néanmoins pas répondu sur ce 'seuillage' qui pourrait exister ,tel que je note le peu ou pas de différence entre 'off' et 'full' ( Showtime) dans l'encodage version 3Mbits que tu m'a fourni    ; c'est cela que je qualifiais de subtil , dans la mesure ou le PP de XviD est lui toujours parfaitement visible entre 'off' et 'on', sur ce sample.
 
je note donc que meme en haut débit ( intermédiaire disons)  le PP  peut encore ne rien apporter , voire se reveler négatif  
 
par suite, il ne parait pas illogique du tout de confronter les codecs qui peuvent l'etre , hors de tout PP  (c'est quand meme pas dur de by-passer cela dans un player !) ; d'autant plus lorsque parfois les differences peuvent se situer là  (qualité du PP)  
 
de fait, on ne parle pas de ratio >200 ici ; bien sur que là, le PP est obligatoire ; vu qu'il s'agit de cacher la misere ...
 
l'époque des rippers fanatiques est quelque peu passée ( ils vont simplement télécharger , les fainéants ! ) mais quand meme demande aux vétérans si ils ne désactivaient pas le PP lorsque l'encodage était bon

 
c'est pas cette direction (32k) que je mettais en débat ...
 
 mais , essayer de voir si un consensus pouvait exister sur tel codec, à tel bit rate, en tant qu'encodage "transparent"  
 
Guru a esquissé une proposition, ce qui est déjà une forme de courage dans ce petit milieu tres polémique

Moi non plus, c'est juste pour indiquer le sample...

Et bien je n'en sais rien. Je ne sais pas ce que fait le filtre Ahead en termes de post-processing.
Cependant, je doute fort qu'il s'amuse à faire du déblocking en post-processing avec du H.264, vu qu'il y a déjà un étage de déblocking dans le décodage.
 

Comme tous les outils des codecs audio/vidéo avec perte. Mal utilisés, ils peuvent dégrader la qualité. Pourtant on ne s'amuse pas à les désactiver pour autant...

 
bon ben c'est rassurant , j'avions donc 'vu' juste , je n'ai pas besoin de passer chez Afflelou !
 
et donc , le grain du film passe quand meme encore visiblement à la trappe , via l'étage déblocking du décodeur , meme @3Mbits ; je devrais dire surtout @3Mbits , là ou justement l'encodeur s'evertue à ...l'encoder ! situation ironique
 
edit : et donc , par suite, il convient bien de verifier dans un comparo   AVC versus Mpeg4ASP (XviD disons) que le fait de désactiver le PP , dans  ce dernier, ne correspond pas à une ...amélioration ; et non aligner un ensemble de codecs sur leur plus petit commun dénominateur ( PP auto ON) , au seul motif que l'un deux , au moins, possede un étage de PP auto interne décodage , non by-passable

Ouai mais la qualité est legerement moins bonne qu'avec le decodeur de Nero

note pour plus tard : lire ce topic

Le réglage "deblock" ([-6;+6]), c'est le réglage de la puissance du inloop. Vous avez essayez de mettre la valeur "-6" ?
 
(Pas de brimade humiliante svp si je dis une connerie )

 
Tu n'avais pas fixé un seuil de 50% ? Je doute que les plus exigents acceptent ne serait-ce qu'un seul de leur achat soit dégradé (alors, 50%...). Or, actuellement, même à 300 kbps, de tels fichiers existent, et suffisent à jeter le discrédit sur les encodeurs avec pertes pour quiconque refuse d'être ennuyé ne serait-ce qu'une seule fois.

 
nan c'est pas ce que je voulais dire ...
 
ici , l'erreur statistique 50% , par un meme testeur, correspond(rait) à son incapacité à établir sa faculté à discerner les samples A des samples B , dans une serie suffisante et signifiante
 
et si ce fait se verifie sur une serie de testeurs (et pas de recoupage signifiant sur un meme sample notamment) , ben on rentre dans l'erreur statistique , 'nécéssaire et suffisante'
 

 
finalement je préfere verser "au dossier" des pieces ;  une photo vaut 1000 mots , parait-il...  
 
et donc il s'agit , à la base , de l'encodage comparatif de mpeg4ASP ( XviD ici) et AVC version Atem-Nero d'un doc source assez retors du faible non pas de ses subtilités , mais simplement qu'il empeche ,par sa faible durée 30sec et son montage tres nerveux , le codec de s'en sortir via la gestion Rate Control ( jouer avec son VBR en gros) ;  
 
diverses comparaisons avaient été faites à divers bit rate et sans tourner autour du pot, AVC s'est montré toujours supérieur , ou pour rester plus gentil XviD n'a jamais été en mesure de produire un doc globalement superieur ; meme s'il s'est fait jour qu'il pouvait encore faire de la vaillante résistance (ce qui au passage demanderait de verifier si ,en situation de rip, longue durée,  ses tres fines possibilités de jouer du RC ne lui offrirait pas une derniere petite chance !? )  
 
et donc malgré sa globale meilleure prestation , il est quand meme apparu que vers les plus hauts débits , le PP integré , et automatique, de AVC pouvait générer ses propres artefacts !!  il ne fait peu de doute (amha) que c'est là qu'il faut chercher l'explication, plutot que renverser l'approche vers une moindre précision de l'encodeur  , ou meme du décodeur, dans la mesure ou globalement AVC produisait précisement ce surplus de précision qui le mettait devant XviD.  
 
je ne suis pas un grand fan des screens , mais bon là le fait est assez précis , ponctuel , matérialisé , et pointe tres directement du doigt UN type d'artefact ( le blur lié à du PP ), sans vouloir chercher à en déduire autre chose que cela  
 
ici l'encodage AVC ayant été fait par Gabriel, il ne peut m'etre opposé quelque 'subterfuge' que ce soit    ; il a respecté parfaitement le target bit rate (3Mbits) , ce qui n'a pas été le cas avec l'encodage DivX ou ( par hasard) j'étais resté sur des réglages récents plutot bons mais qui convenaient mieux , quant au strict respect du file size , à un rip longue durée ( le joker du RC !) , et donc ici des Bfs voulues tres proches des P et donc en q 1.25 et delta 1.5 participent à l'oversize ; entre autre ; bref ici XviD a produit 3500k de bit rate , sur donc une séquence courte de 30sec  (le générique d'une série US diffusée sur TF1) ; tres certainement le fait de ramener à parité n'aurait changé pas trop  grand chose , qualitativement, avec XviD donc ; et de toute façon n'aurait évidemment en rien changé quoi que ce soit à l'artefact PP constaté sur la version AVC !
 
le doc source étant du Mpeg2 4:2:2 P@ML 25Mbits , j'ai été obligé de passer par un 'master' intermédiaire RGB24 ; je crois que Gabriel aussi (?) , et probablement doit on mettre le léger écart de gamma sur ce fait (peut etre pas la meme dll (?) ; Main Concept en ce qui me concerne); outre le fait que le PP genere aussi , assez souvent, ce genre d'éffet indésirable ( éclaircir les zones 'blurées').
 
bref voilà les images , (3,5Mo chaque) , capturées telles que en 'plein écran', enfin 1280*1024 dans mon cas :
 
http://nozilla.free.fr/AVC_3000k
 
http://nozilla.free.fr/XVID_3500k
 
edit : lien vers l'image source RGB24  
 
http://nozilla.free.fr/RGB_128010241280_1024
 
 
à nouveau , il n'est pas question de dire , ou me faire dire, quoi que ce soit d'autre ! l'AVC de Ateme-Nero m'a quand meme bien bluffé , tout praticulierement vers des débits de l'ordre de 2 / 2.5Mbits ;  
 
il s'est juste trouvé que , ici à 3Mbits, de betes artefacts de PP sont venus assombrir le tableau ; peut etre tout simplement parceque le PP ne sert plus à rien ! et j'en veux pour preuve le screen XviD qui montre bien ici qu'il qu'il n'y a pas/plus  besoin de PP ...  
 
ou alors peut etre ,fausse route , et ici l'option Motion Search @6 de Mpeg4ASP se montre t-il plus capable d'encoder le bruit contenu dans l'image ( heu..ce qui faisait bien sur totalement partie du test    ) ; mais j'y crois pas trop vu l'armada des outils encodeurs sophistiqués de AVC

AVC a l'air de blurer pas mal
on perd tout le grain

kabaia > +1, perso l'AVC Atema+HE-AAC m'a bluffé, j'ai tres longtemps utilisé le XviD et là je prefere le codec Nero, d'une part par sa simplicité, de l'autre par les resultat obtenu. Sans resize d'une source DVD, sur un crop, en 2Mbps l'image est presque parfaite (on divise par 3-4 la taille du DVD quand meme...).
 
dje33 > Utilise ffdshow sans pp et admire la qualité de l'AVC... D'ailleurs le PP de ffdshow bug litérallement sur les H264 en mode mplayer, faut utiliser le mode Nic... Remarque là, pour comparé versus XviD c'est peut etre le meilleure filtre de decompression. Mais le filtre d'Ateme reste meilleur, c'est encore plus bluffant avec

 
Mei ,le PP de AVC/H264  est integré au décodeur lui meme ; qu'il soit 'débrayable' néanmoins , oui probablement (?) , mais faut poser la question à Gabriel, qui y a déjà ...répondu :
 
>> "Comme tous les outils des codecs audio/vidéo avec perte. Mal utilisés, ils peuvent dégrader la qualité. Pourtant on ne s'amuse pas à les désactiver pour autant..."  
 
donc dans ffdshow , "sans pp" , tu ne fais que ne pas ré-ajouter un second PP (?) ; c'est donc normal que ce n'en soit que ....meilleur

Si, justement: L'encodage est en D1 (720x576) et tes captures sont en 1280x1024.
Second point, il s'agit d'UNE image, qui ne permet pas de juger de la qualité d'une séquence encodée face à la source.
Un oeuil averti nottera d'ailleurs sur ce screenshot d'Xvid un motif régulier par endroit sur ce qui est présenté comme du "grain" sur cette capture.
En fait ce sont des artéfacts de compression (ringing). Par endroits je peux même compter combien de coefficients DCT ont été encodés.
L'illusion fonctionne cependant assez bien sur une image fixe.
Petit exercice: observe la même image de la source. Tu constateras vraiscemblablement que les "grains" ne sont pas à la même place que sur Xvid.
 

précision: c'est le loop filter qui est interne. Ce n'est pas grave, mais il ne s'agit pas vraiment de post-processing. D'ailleurs il est controlé par l'encodeur.

heu là, Gabriel, tu la joues ...'artifice de procédure' ; c'est jamais bon signe quant à la recherche de la vérité  
 
mais bon si tu souhaites que je refasse la manip en 720*576, no problem ; les artefacts seront toujours là !!  de taille inférieure certes en 720*576 , mais par ailleurs soyons serieux : QUI regarde un doc source Mpeg2 en 720*576 , et non **en PLEIN ECRAN ** ; là , c'est toi qui "essaye" un "subterfuge" ; quelque peu désolant , vu le crédit qui est le tien  
 
ton point sur sur la difficulté réelle d'encoder du grain  est plus interessant ; maintenant dire , que XviD n'y a ici que 'substitué' en somme des patterns d'artefacts est , à nouveau 'surprenant'  
 
je croirais lire Amir répondant à Monty !! ( je ne suis pas Monty , hélas quant au savoir , je veux dire ; je te laisse juger de l'autre asepct de la proprosition..)  
 
je veux bien , ceci étant, mettre l'image source correspondant ; mais si ça part déjà sur ces bases , je réutiliserais alors ta propre formule :
 
>>Je note le ton assez catégorique. Devant une telle certitude, il ne sert visiblement pas d'essayer une quelconque explication. Un autre jour peut-être?
 
tu as par contre ,bien sur raison, sur l'aspect partiel d'isoler des images  ; je l'ai clairement mis en avant ; mais dans la mesure ou il ne s'agit, dans mon esprit, pas d'une discussion sur les merites respectifs de AVC vs XviD , mais d'isoler UN point particulier , qui me semble un point faible de AVC , version Ateme-Nero(?) , dans certaines circonstances ;
   
ceci étant, je crois avoir été assez clair sur mon appréciation TRES favorable ; meme si ça ne relegue (pas encore) mpeg4ASP aux orties
 
>L'illusion fonctionne cependant assez bien sur une image fixe.
 
"illusion" !! de quoi parles tu     pas du tout; cela "m'a -d'abord- sauté aux yeux" en visionnage normal (25fps)  
 
short answer :je ne suis ni juge , ni partie, j'ai au moins cet avantage ...