XviD 1.0 est enfin sorti !

Posté par Edouard Gomez (site web personnel) le 18 mai 2004 à 19:44. Modéré par Nÿco.

Étiquettes : aucune

mai

2004

L'équipe de développement est heureuse de vous annoncer la disponibilité immédiate d'XviD 1.0.0. Et bien que ce numéro de version ne soit au final que symbolique, il s'agit tout de même d'une étape importante. La "xvid-team" espère que vous apprécierez les efforts placés dans cette version 1.0. Merci à tous les utilisateurs qui ont rapporté des bugs, envoyé des patchs et donc au final contribué à ce que XviD atteigne une qualité suffisante pour être estampillée 1.0.

Nous vous souhaitons d'heureux codages de vidéo et restez attentifs aux améliorations prévues pour les prochaines versions.

Màj : Pour fêter la sortie de XVid 1.0, le site s'est fait pirater. Mais le logiciel est toujours téléchargeable sur le site.

NdM : rappelons que XviD est une implémentation libre - donc ouverte - du codec MPEG4. Ce qui ne gâche rien, c'est que XviD est aussi le meilleur codec MPEG4, c'est le site de référence Doom9 qui le conclut après de nombreux tests.

Guillaume POIRIER précise : XviD est un codec MPEG-4 libre supportant un grand nombre de fonctionnalités avancées de MPEG-4, telles que le GMC, les qpel, et dispose de quelques modes spéciaux pour l'encodage d'anime ou de films.
Cette version a vu bon nombre de nouvelles fonctionnalités s'ajouter, et la vitesse d'encodage s'accélérer, avec des optimisations SIMD pour PPC et pour x86, et une ré-écriture du code pour l'encodage en deux passes.

NdM 2 : merci à Freedom66, mansuetus et Guillaume POIRIER pour avoir également proposé la nouvelle. Changements depuis la RC4 (Hola):
- bug mineur dans l'optimisation de quantification par Trellis ;
- optimisation des modes VHQ> (le code exécutait deux types de recherches, là ou une seule était utile) ;
- meilleur clipping des vecteurs de mouvements ;
- correction de la fonction C de sortie RGB 16bit ;
- correction d'une possible corruption de l'entête VOL dans le cas ou le framerate est de 1 image par seconde ;
- correction de la prédiction du coefficient DC (ce bug a aussi été rapporté/corrigé au/par le projet FFMPEG).

Puis ma valeur ajoutée à cette traduction de l'annonce... XviD 1.0 c'est quand même:
- un projet vieux de 3ans (enfin en Novembre 2004), dont presque 1an et demi consacré à cette version ;
- un projet mené tant bien que mal par à peu près seulement 6 personnes de coins différents (Allemagne, France, Australie, USA et d'autres) ;
- quelques 242 patchs depuis la version 0.9.2, soit un patchset arch/tla pesant 5.2MB (logs tla compris), soit 93 fichiers modifiés, 525 fichiers ajoutés (logs tla compris), 50 fichiers supprimés, 18 fichiers renommés ;
- des heures et des heures de chauffage de pièce par les CPUs des devs pour les tests, et pas de pause pendant la canicule 2003 ;
- de belles tensions dans l'équipe de dev pour savoir ce qui a le droit de citer dans la version finale comme fonctionnalité ou encore license GPL ou license GPL plus clause d'exclusion géographique à cause des brevets logiciels.

Bah vala, il est temps de lâcher son bébé dans la nature, mon oeuvre ne m'appartient plus :-)

Aller plus loin

XviD.org (11 clics)
Un ami/concurrent libre (3 clics)
DLFP 2003-12-31 : « Tests de codecs vidéo Doom9.org : XviD vainqueur » (20 clics)
Téléchargements (5 clics)
Sources signées par Edouard Gomez (xvid-team) (7 clics)
La clef publique GnuPG (2 clics)

# Damned !

Posté par Vivi (site web personnel) le 18 mai 2004 à 15:44. Évalué à 10.

XVID site cracked. Unfortunately, right after we released the long-awaited XviD 1.0 final, the XviD web server got cracked and many files were deleted. Whoever did this, we actually don't find this funny at all. We're currently working hard to recover from this attack. However it will take us (at least) a couple of days to be back. Meanwhile, we've mirrored the 1.0 final announcement below and you can still download all the XviD 1.0 final source code packages from the files section at the bottom of this page.
We're very sorry for this inconvenience!
- [^] # Re: Damned !
  
  Posté par boris le 18 mai 2004 à 16:25. Évalué à -2.
  
  Là, ca devient carrément une épidémie...
- [^] # Re: Damned !
  
  Posté par Edouard Gomez (site web personnel) le 18 mai 2004 à 16:27. Évalué à 10.
  
  A noter que seul le frontal web a été touché (site web + forum + Mailing lists). Le serveur de fichier (downloads et CVS) n'a pas été compromis.
  
  Il semble qu'un bug noyau ait été exploité (surement grace à un remote exploit annexe pour obtenir un shell), il faut dire que nous utilisions une vieille version de noyau car le controleur RAID ne fonctionne plus avec des versions récentes... comme quoi ca arrive pas qu'aux autres.
  
  Sinon pour les plus novices d'entre vous, je tiens a preciser qu'XviD est principalement un projet de *codeur* MPEG4, et que le decodeur n'est pas le plus performant. Donc, si vous ne pensez pas coder des videos, ne vous embetez pas à installer XviD pour lire les "XviD" (qui ne sont que du MPEG4). FFMPEG, qui est deja inclus dans vos lecteurs preferés mplayer/xine, peut lire le MPEG4 et bien plus encore.
  - [^] # Re: Damned !
    
    Posté par Richard Van Den Boom le 18 mai 2004 à 17:17. Évalué à 7.
    
    Juste pour dire que je suis récemment passé à XVid pour encoder des DVD avec dvd::rip en visant un fichier de 1GB (comme ca 4 films par DVD+RW) et que la qualité obtenue avec xvid est réellement remarquable une fois toutes les optimisations mises en place. En fait, elle est pratiquement impossible à distinguer de l'original.
    Une petite question, quel gain en performance peut-on espérer entre la rc4 et la finale?
    
    Richard.
    - [^] # Re: Damned !
      
      Posté par Olivier Jeannet le 19 mai 2004 à 02:53. Évalué à 3.
      
      pour encoder des DVD
      
      Rhalala, c'est pour chipoter, mais Edouard a eu le bon goût d'utiliser les termes "codeur" et "codage" (ça fait plaisir), et toi tu nous remets un affreux "encoder".
      
      J'en profite pour rappeler que si l'usage de "encoder" et "encodage" (beurk) est toléré, l'usage le plus correct est bien "coder" et "codage", comme dans "message codé", "fax codé", "codage préfixe", "brin codant d'ADN", etc...
      - [^] # Re: Damned !
        
        Posté par Richard Van Den Boom le 19 mai 2004 à 07:34. Évalué à -1.
        
        Pardon, pardon, je ne le ferai plus.
  - [^] # Re: Damned !
    
    Posté par Fabimaru (site web personnel) le 19 mai 2004 à 09:40. Évalué à 4.
    
    il faut dire que nous utilisions une vieille version de noyau car le controleur RAID ne fonctionne plus avec des versions récentes...
    Je vais m'attraper quelques [-]. Quand un matériel n'est plus supporté sur un OS proprio, on lit par ici "oh voilà l'intérêt des pilotes ouverts". Ben le logiciel libre ne s'en sort pas mieux sur le coup. "debug et envoie un patch" comme on lit ici, ah ah.
    
    PS: ma carte PCTV marche encore avec Linux, et pas de driver sous Windows 2000. C'était juste pour dire que certains déclarent que quoiqu'il en soit, le logiciel ouvert sera toujours plus sécurisé que le logiciel proprio, que le matériel sera supporté plus longtemps, tout ceci étant parole d'évangile et sera _toujours_ vrai. Et ça m'énerve les gens qui n'ouvrent pas les yeux pour défendre un (bon) idéal.
    - [^] # Re: Damned !
      
      Posté par arnaudus le 19 mai 2004 à 10:22. Évalué à 1.
      
      il faut dire que nous utilisions une vieille version de noyau car le controleur RAID ne fonctionne plus avec des versions récentes...
      
      Le noyau 2.6 a quand même énormément régressé au niveau du support matériel. A l'heure où je vous parle, je suis en train de griller mon processeur parce que la gestion de l'énergie ne fonctionne plus sur mon portable, alors que ça tournait magnifiquement avec le 2.4.
      
      Pour ceux qui s'y connaissent, ce type de mésaventure est-il d'origine politique ou technique?
      - [^] # Re: Damned !
        
        Posté par schyzomarijks le 19 mai 2004 à 10:25. Évalué à 6.
        
        >technique
        
        Je crois que Linus a décider de n'intégrer dans le 2.6 que les pilotes avec un mainteneur officiel, de fait, beaucoup de pilotes n'ont pas encore été intégrer au noyau (et beaucoup ne le seront pas)
  - [^] # Re: Damned !
    
    Posté par M le 19 mai 2004 à 19:55. Évalué à 1.
    
    Il semble qu'un bug noyau ait été exploité (surement grace à un remote exploit annexe pour obtenir un shell), il faut dire que nous utilisions une vieille version de noyau car le controleur RAID ne fonctionne plus avec des versions récentes... comme quoi ca arrive pas qu'aux autres.
    
    Et le noyeau de debian stable il marche pas ?
    C'est pourtant une ancienne version 2.4.18(a peu pres) qui est patche contre les trous de securité.
# pour télécharger les fichiers binaires

Posté par ecyrbe le 18 mai 2004 à 16:04. Évalué à 6.

une adresse utile...ou vous trouverez les fichiers déjà compilés...malheureusement seulement pour windows...

http://roeder.goe.net/~koepi/(...)

sinon c'est pas compliqué...a vos gcc, près ? compilez...
- [^] # Re: pour télécharger les fichiers binaires
  
  Posté par sirrus le 18 mai 2004 à 18:12. Évalué à 2.
  
  Les paquets PLF sont prêts également...
  
  Donc c'est encore moins compliqué... à vos console, près ? # urpmi --auto-select !
  - [^] # Re: pour télécharger les fichiers binaires
    
    Posté par Raphaël G. (site web personnel) le 11 juin 2004 à 23:32. Évalué à 1.
    
    Avant quand même ne pas oublier un chtit
    urpmi.update -a
    sinon pas de nouveau packages...
# Quid des brevets ?

Posté par Christophe Fergeau le 18 mai 2004 à 16:57. Évalué à 6.

La news dit que l'implémentation du codec est libre, mais quelle est la position du projet vis à vis des brevets qui encombrent vraisemblablement l'implémentation d'un codec mpeg4. Est-ce que le projet viole de façon certaine des brevets, ou bien est-ce qu'il y a des brevets potentiellement violés, mais de façon discutable, ou bien est-ce que le projet n'en sait rien ?
- [^] # Re: Quid des brevets ?
  
  Posté par thaodalf le 18 mai 2004 à 17:02. Évalué à 3.
  
  je crois me souvenir que le projet xvid est tolerer par mpeg car ils le considere comme un projet d'education.
  je pense pas que tu est le droit d'en faire un autre codec et de le vendre.
  - [^] # Re: Quid des brevets ?
    
    Posté par un_brice (site web personnel) le 18 mai 2004 à 17:48. Évalué à 6.
    
    Je crois que l'affaire c'est que s'opposer à la diffusion d'un code source poserait des problèmes vis à vis de la liberté d'expression. Ça n'as jamais été testé, mais les détenteurs des brevets n'ont pas envie de se prendre la tête avec ça et préfèrent faire comme s'ils n'avaient rien vu.
    C'est pour ça que le projet Xvid ne produit pas de binaires, mais seulement du source.
    - [^] # Re: Quid des brevets ?
      
      Posté par Beretta_Vexee le 18 mai 2004 à 18:22. Évalué à 6.
      
      Même chose pour les encodeurs AAC libre, disont que les sources de ces projets beneficie d'un flou juridique aventageux, du moment que cela reste des sources apres a charge a d'autre (
      Koepi, rareware, etc etc ... ) de distribuer des binaires a leurs risques et perils.
      Mais bon pour rappel le MPEG consortium ne s'emmerde plus a recolter des royalties en dessous de 5000 exemplaire a 2$ la licence pour du MPEG4 on peut dire qu'en dessous de 10000$ il s'en tape. Vue que le manque a gagnier dut par XviD FAAC et autre son probablement minime ....
# Symbolique le numéro de version ?

Posté par ploum (site web personnel, Mastodon) le 18 mai 2004 à 17:11. Évalué à 8.

Pour les geeks et habitués de l'open source oui, très certainement.

Mais j'ai été étonné du nombre de personnes dans le milieu de la vidéo qui ne voulait pas utiliser Xvid car pas encore en version 1.0 !
Mes livres CC By-SA : https://ploum.net/livres.html
- [^] # Re: Symbolique le numéro de version ?
  
  Posté par sirrus le 18 mai 2004 à 17:59. Évalué à -2.
  
  Ben c'est surement idiot mais j'en fais partie d'autant plus que j'ai eu une ou deux deux bugs donc pour des test, ça allait mais pour le codage courant, c'était plutôt ffmpeg. Mais bien sur, maintenant, ce sera XviD. :-)
# bitsream figé

Posté par Marc Lacoste le 18 mai 2004 à 18:15. Évalué à 4.

A priori (corrigez moi (non, pas ça, c'est douloureux!) si je me trompe), je crois que le bitstream de XviD est figé par les versions 1.0, que les versions 1.x seraient là pour augmenter les perfs en encodage et correctionner les cafards sans modifier le flux produit. Les modifs du bitstream apparaitraient pour Xvid 2.

D'ou spéculations pour la v2:
- mpeg4 advanced profile (h264)?
- vagueletes?
- theora?
- portage pour MdeskOS?
- [^] # Re: bitsream figé
  
  Posté par wismerhill le 19 mai 2004 à 08:45. Évalué à 0.
  
  Argh, je peux pas la laisser passer celle-là
  s/correctionner/corriger/
  - [^] # Re: bitsream figé
    
    Posté par fmaz fmaz le 19 mai 2004 à 09:45. Évalué à 0.
    
    qu'il est bon de rire parfois!
    
    Ceci dit, tu n'as rien compris. Ce qu'il voulait dire, c'est
    s/correctionner/correctationager/
- [^] # Re: bitsream figé
  
  Posté par David le 19 mai 2004 à 13:21. Évalué à 2.
  
  Le support du H264AV me semble optimiste. Il y a quelque temps, un hacker avait voulu se baser sur le code de Xvid pour coder rapidement un codec H264AV. Je crois bien qu'il a rapidement déchanté.
# Puisque j'ai un dev sous la main...

Posté par tgl le 18 mai 2004 à 19:55. Évalué à 10.

...petite suggestion à garder dans un coin pour l'avenir :

Si dans une prochaine version vous changez encore l'API comme par exemple ça a été fait entre les versions 0.9.x et les 1.0, serait-il possible de changer en même temps le nom ou le path du header (genre "xvid-X.Y.h" ou encore "xvid-X.Y/xvid.h"). Comme c'est fait par exemple pour gtk1.2/2.0.

Parceque le simple "xvid.h" utilisé actuellement pose problème, au moins pour les distributions source : il est parfaitement possible de faire cohabiter les librairies des version 0.9.2 et 1.0 par exemple, permettant ainsi d'exécuter les programmes utilisant encore l'ancienne API, mais il n'est pas (sans très vilain hack) possible de faire cohabiter leurs headers respectifs, et donc de permettre d'installer depuis les sources à la fois des programmes utilisant l'ancienne API et d'autres utilisant la nouvelle.

Voilà, en espérant que c'était clair, mes 0,02.

Suivre le flux des commentaires

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