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) . Évalué à 10.
[^] # Re: Damned !
Posté par boris . Évalué à -2.
[^] # Re: Damned !
Posté par Edouard Gomez (site web personnel) . Évalué à 10.
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 . Évalué à 7.
Une petite question, quel gain en performance peut-on espérer entre la rc4 et la finale?
Richard.
[^] # Re: Damned !
Posté par Olivier Jeannet . Évalué à 3.
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 . Évalué à -1.
[^] # Re: Damned !
Posté par Fabimaru (site web personnel) . Évalué à 4.
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 . Évalué à 1.
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 . Évalué à 6.
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 . Évalué à 1.
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 . Évalué à 6.
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 . Évalué à 2.
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) . Évalué à 1.
urpmi.update -a
sinon pas de nouveau packages...
# Quid des brevets ?
Posté par Christophe Fergeau . Évalué à 6.
[^] # Re: Quid des brevets ?
Posté par thaodalf . Évalué à 3.
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) . Évalué à 6.
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 . Évalué à 6.
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) . Évalué à 8.
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 . Évalué à -2.
# bitsream figé
Posté par Marc Lacoste . Évalué à 4.
D'ou spéculations pour la v2:
- mpeg4 advanced profile (h264)?
- vagueletes?
- theora?
- portage pour MdeskOS?
[^] # Re: bitsream figé
Posté par wismerhill . Évalué à 0.
s/correctionner/corriger/
[^] # Re: bitsream figé
Posté par fmaz fmaz . Évalué à 0.
Ceci dit, tu n'as rien compris. Ce qu'il voulait dire, c'est
s/correctionner/correctationager/
[^] # Re: bitsream figé
Posté par David . Évalué à 2.
# Puisque j'ai un dev sous la main...
Posté par tgl . Évalué à 10.
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.