Liens connexes

Dépêche modérée par

: XviD 1.0 est enfin sorti !

Posté par Edouard Gomez (page perso, ). Modéré le 18 mai 2004.
0
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.

> Lire la suite (24 commentaires, moyenne: 4,7).   [dépêche : 1550 caractères]

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 :-)

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

Damned !

Posté par Vivi (page perso, ) le 18/05/2004 à 13:44. (lien). Évalué à 17.

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!

pour télécharger les fichiers binaires

Posté par Bench () le 18/05/2004 à 14:04. (lien). É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...

Quid des brevets ?

Posté par Christophe Fergeau () le 18/05/2004 à 14:57. (lien). É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 ?

Symbolique le numéro de version ?

Posté par ploum (page perso, ) le 18/05/2004 à 15:11. (lien). É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 !

bitsream figé

Posté par Marc Lacoste (page perso, ) le 18/05/2004 à 16:15. (lien). É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?

Puisque j'ai un dev sous la main...

Posté par tgl () le 18/05/2004 à 17:55. (lien). Évalué à 14.

...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€.

Revenir en haut de page