LE site de test des CODECS Pro

ça y est, ça marche, nikel le dernier test.

Quelqu'un pourrait il fournir les tests sur des digisuites si c'est possible car ça m'interesse.
merci

 

superbe comparo!


j'ai une petite question, au niveau des codecs DV, lesquels sont utilisable avec une carte OCH toute bete (enfait les ports FW de ma carte mere abit nf7-S)

et heu j'ai pas trop vu ou on choisisait le codec DV de capture dans scenalyser live 2.1

 

nop à part Avid Xpress DV qui utilise son codec ....

=> dès lors que tu passses par le port DV, le codec utilisé sera le Microsoft Avi

++

SteF

 

hum curieux, en tout cas si je ne dis pas de bétises, avec mon ancienne Dazzel DV Now lite, c'était pas les codec DV Microsoft mais bien ceux à la sauce dazzel

 

@+ YvesP

 

Ah ça c'est marrant parce que je n'ai pas le même résultat avec le codec Avid DV25. Voici ce que j'ai :

Avid DV25 PAL 4:2:0 codec :


Apple QuickTime DV PAL 4:2:0 codec :



Je n'ai pas le resize que STEF a remarqué lors de son export sous After. Problème de configuration ? J'ai fait mes exports directement à partir de QuickTime Pro mais je le fais régulièrement à partir d'After et je n'ai jamais eu le problème.

Par contre ces tests me dérangent parce que deux paramètres ne sont pas pris en compte.

1) Une image DV a un espace alloué fixe dans le flux DV. Ce qui signifie que si l'image compressée prend moins de place, le codec va remplir le reste de zéro pour que le débit reste constant. Un bon codec doit donc prendre le maximum de place pour conserver le maximum de détails de l'image... Mais ne doit jamais dépasser l'espace alloué pour chaque image. Bien sûr, si le codec n'a pas de contrainte de temps (pas de rendu ou d'enregistrement en temps réel), c'est beaucoup plus facile.
Dans mes deux exemples, j'ai compressé les deux fichiers MOV (exportés de la même manière) en fichier .RAR. L'image compressée avec le codec Apple DV est passée de 141Ko à 102Ko, et celle compressée avec Avid DV de 141Ko à 93Ko. Ce qui signifie que le codec d'Avid est moins optimisé. Bon, là, je chipote, en pratique tout ceci n'a que peu d'importance, mais j'aime bien voir si les ch'tits programment bossent bien en interne.

2) Le DV travaille avec les normes de luminosité vidéo. Chaque pixel peut prendre les valeurs de luminosité de 0 à 255, mais le noir est défini à 16 et le blanc à 235 (j'espère que tout le monde voit de quoi je parle, hein). Il me semble bien que la grande majorité des codecs DV prennent en entrée des valeurs RGB (0-255) puis les ramènent au 601 (16-235), compressent, puis à la décompression reprennent les valeur 601 (16-235) et les étendent en RGB (0-255). Tout ça pour ne pas choquer le monteur du dimanche moyen qui ne comprendrait pas pourquoi son noir devient tout-à coup gris... D'où l'effet de bande qu'on observe dans presque tous les codecs DV bas de gamme (celui de Microsoft en est un excellent exemple). Je ne sais pas comment fonctionne le codec d'Apple. Par contre, pour celui d'Avid, je le sais puisque dans les options de compression j'avais le choix entre lui dire de considérer l'image comme étant en RGB et la convertir (option "RGB"), ou bien la prendre telle quelle (option "601"). Comme à la décompression le codec ne fait pas l'opération inverse, j'ai opté pour qu'il compresse sans modifier l'image ("601") pour pouvoir comparer les deux images à la sortie. Mais en pratique, cette manipulation est totalement fausse puisqu'en vidéo on travaille toujours en 601. Alors, comment réagissent les autres codecs DV ? Est-ce que ces problèmes d'espace colorimétrique sont pris en compte dans tous ces tests ou est-ce que tout le monde a fait comme moi, sans savoir si d'autres manipulations (autre que la simple compression) entrent en jeu ?
Note : en compressant l'image correctement avec le codec d'Avid, il n'y a pas d'effet de bande de toute façon, l'image est comparable.