Tests de codecs vidéo Doom9.org : XviD vainqueur

Posté par (page perso) . Modéré par Benoît Sibaud.
Tags :
0
31
déc.
2003
Audiovisuel
Doom9.org, un des sites techniques de référence sur la vidéo numérique, a reconduit sa comparaison de codecs vidéos en cette fin d'année 2003 : c'est XviD, le codec libre qui remporte ce test pour la première fois !

Bravo donc à l'équipe XviD qui vient de publier la bêta 3 de XviD 1.0.0, à tester avant d'adopter définitivement !

Pour rappel, XviD est un implémentation libre de MPEG4. Les codecs comparés sont les suivants : 3ivX, DivX 3, DivX 5, ffvfw, Nero Digital, RV9, VP6, XviD.

Les tests ont été effectués sur un AMD Athlon XP 2800+ et portent sur les films The Matrix, Saving Private Ryan et Futurama.

La présentation du test a un peu changé : grâce à du javascript on peut charger une photo d'écran du codec sélectionné, donc comparer pixel à pixel, d'autant plus qu'on peut zoomer (avant, les images étaient les unes au dessous des autres).

Pour finir, un bout de la conclusion :
Finally, XviD is my winner this time. It came in first in both Matrix and SPR test, and second in Futurama. Also, for the first time in a long testing series, there were no glitches and no problems in the encoding setup (I never had to redo a single encoding session).

Aller plus loin

  • # Re: Tests de codecs vidéo Doom9.org : XviD vainqueur

    Posté par (page perso) . Évalué à 5.

    Un lien pour l'équivalent francophone de doom9 :

    http://atlas2.tgv.net/~media-video/forum2/(...)

    mieux connu sous le nom "unite-video.com"
  • # Re: Tests de codecs vidéo Doom9.org : XviD vainqueur

    Posté par . Évalué à 2.

    J'ai une question qui me démange. ffvfw correspond-il réellement au ffmpeg qu'on a sous Linux?

    Personnellement, je ne veux pas troller mais je ne vois pas trop de différences entre le XviD 1.0 beta 2 et ffmpeg et parfois ffmpeg a toujours l'avantage. Maintenant, je n'ai pas essayé tous les diférents plans possibles, il y a surement des scènes où XviD prend l'avantage... ou alors il n'a pas d'intérêt.
  • # Re: Tests de codecs vidéo Doom9.org : XviD vainqueur

    Posté par . Évalué à 4.

    C'est très fort le code pour zoomer sur les images, c'est sous quelle licence ? ;)
  • # remarque sans rapport direct

    Posté par . Évalué à 6.

    Dans le comparatif, il est indiqué le nombre d'octets que contient un Mo. Cela est bienvenu car pas toujours précisé (surtout sur les disques durs). Néammoins, il faut regretter (quoique cela peut se discuter...) que le consortium de standardisation électronique international a avalisé depuis près de 2 ans les nouvelles unités en informatique à savoir que 1 Ko vaut 1000 octets et non plus 1024. De même pour les multiples.
    N'ayant pas plus d'intérêt que d'être à titre informatif, je ne m'éternise pas.

    Bon réveillon !
    • [^] # Re: remarque sans rapport direct

      Posté par . Évalué à 1.

      le consortium de standardisation électronique international a avalisé depuis près de 2 ans les nouvelles unités en informatique à savoir que 1 Ko vaut 1000 octets et non plus 1024.

      L'information est pertinente, même si un peut hors sujet.

      Personnelement je ne le savais pas
      • [^] # Re: remarque sans rapport direct

        Posté par (page perso) . Évalué à 3.

        Concernant ces unités, tout est expliqué ici : http://physics.nist.gov/cuu/Units/binary.html(...)
        • [^] # Re: remarque sans rapport direct

          Posté par . Évalué à 1.

          et il y a vraiment des gens qui utilisent ca ? o_O
          • [^] # Re: remarque sans rapport direct

            Posté par . Évalué à 1.

            j'ai jamais entendu cela


            la rigueur recule pour se plier à l'usage erroné.. encore une fois.
            • [^] # Re: remarque sans rapport direct

              Posté par . Évalué à 1.

              Le problème, c'est qu'à l'origine, on a utilisé les préfixes décimaux pour les multiples binaires, car 2^10 est quasiment égal à 1000.
              Et ça ne posait de problème à personne, jusqu'à ce que ces connards de commerciaux s'en mêlent : les fabricants de disques durs (Quantum en premier, et les autres ont suivi) ont décidé que le Go contenait 1 millard d'octets (ça implique évidemment qu'il faille faire les corrections pour le Mo et le ko), afin d'augmenter artificiellement la taille prétendue de leurs disques durs.

              Sauf que l'usage n'est toujours pas répandu. Seuls les disques durs utilisent cette notation décimale. Quand on parle de RAM, de carte mémoire, de capacité de cache, etc, c'est toujours l'ancienne notation (préfixes décimaux au lieu des préfixes binaires) qui sont utilisés. Voire, il me semble même (à vérifier sous environnement Win32) que tous les logiciels de comptage d'espace disque fournissent toujours par défaut la taille restante/occupée en _vrais_ Go/Mo (multiple de puissances de 2).

              Il y a clairement eu manipulation de l'organisme de standardisation, à mon avis.
              • [^] # Re: remarque sans rapport direct

                Posté par . Évalué à 2.

                extrait du man du:

                -h, --human-readable
                Afficher les tailles de manière facile à lire par un humain, en
                ajoutant un suffixe correspondant à l'unité (K, M, G).

                -H, --si
                Comme -h, mais en utilisant des unités du Système International
                (avec des puissances de 1000 plutôt que 1024, ainsi M vaut
                1000000 et non 1048576). (Nouveauté dans fileutils-4.0).


                et c'est +- pareil pour ls par ex, donc tu choisis...
                sous Windows, c'est toujours le 1024 qui est utilisé
                • [^] # Re: remarque sans rapport direct

                  Posté par . Évalué à 1.

                  Ah oui, c'est vrai, j'avais oublié. Mais je dois bien avouer que j'utilise seulement -h. Et sur les interfaces graphiques, c'est quel paramètre qui est utilisé par défaut ?
                • [^] # Re: remarque sans rapport direct

                  Posté par (page perso) . Évalué à 1.

                  [commentaire inutile mais nécessaire pour avoir un score qui permette de plusser]

                  Merci pour l'info, j'avais pas vu l'apparition du "-H"
                  Hop, je modifie mon "alias df='df -h'" en "alias df='df -H'" et j'aurais l'impression d'avoir gagné de la place ;-)
        • [^] # Re: remarque sans rapport direct

          Posté par (page perso) . Évalué à 1.

          Seigneur... Mais alors qui croire ? Qui utilise quoi ? Comment savoir qu'un livre, un commerçant, un fabricant utilise tel ou tel standard, l'ancien ou le nouveau ? Ca commence à devenir pénible de plus savoir comment se comprendre, parfois...
    • [^] # Re: remarque sans rapport direct

      Posté par . Évalué à 1.

      Alors voila, y a eu le passage de l'ancien au nouveau franc.
      Ensuite le franc vers l'Euro (et la encore beaucoup ont du mal)
      Maintenant on va faire l'ancien et le nouveau kilo (ben on est mal barré)
    • [^] # Re: remarque sans rapport direct

      Posté par . Évalué à 1.

      Sauf que ce consortuim n'a pas vraiment d'autorité pour faire ca, ils ont sorti ca de leur chapeau mais ca n'a que la valeur qu'on veut bien lui donner.
  • # Re: Tests de codecs vidéo Doom9.org : XviD vainqueur

    Posté par . Évalué à 3.

    Allez un autre liens vers ce sujet: http://linuxfr.org/~GomGom/8060.html(...)

    Enfin bon, ce genre de nouvelle fait toujours plaisirs (Et oui le libre sait produire des produits des très bonnes qualités).
  • # Re: Tests de codecs vidéo Doom9.org : XviD vainqueur

    Posté par . Évalué à 1.

    De plus, XviD tire partie des instructions SSE et c'est pour ça qu'il est très rapide.
  • # Et le WM9 ?

    Posté par . Évalué à 1.

    Ce test est tres bien, mais le wm9 commence à se rependre, et j'aurais bien aimer connaitre les perf du Xvid face au produit de m$, parceque meme si le wm9 est une daube de m$, je ne vois pas pourquoi il est exclu du test .

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.