Journal XviD 1.1.0-beta2 is out ! Et moi aussi...

Posté par Edouard Gomez (site web personnel) le 05 avril 2005 à 02:05.

Étiquettes : aucune

avr.

2005

Houpla boum, une nouvelle release d'XviD.

Pour ceux qui ne connaissent pas, il s'agit d'un codec MPEG4 libre (GPL) qui donne d'excellents résultats pour des taux de compression importants (<1.5MBit/s)

Cette nouvelle version apporte un certain gain en qualité pour les vidéos à petit débit, et corrige certains bugs de la dernière beta. Le ChangeLog est disponible sur http://www.xvid.org/(...) ainsi que les sources.

Cette release est aussi la dernière que je prépare au nom de la "XviD team", car après plus de 3 années de loyaux services, je ne ressens plus aucun plaisir à travailler sur ce projet qui demande beaucoup d'investissement personnel en temps pour le suivi et son amélioration.

Voilà j'espère que les linuxfriens qui utilisent xvid et lisent ce journal ont apprécié mon travail. Je souhaite bonne chance au reste des developpeurs XviD pour les prochaines releases.

# Merci ...

Posté par Sasuke le 05 avril 2005 à 06:42. Évalué à 9.

... beaucoup pour ton travail :) ca fait partie des "killer app" sous linux que j'adore (j'ai dit killer app ? oui bon ca va). Bonne continuation.
- [^] # Re: Merci ...
  
  Posté par Frédéric COIFFIER le 05 avril 2005 à 09:28. Évalué à 3.
  
  Merci beaucoup !
  Je n'utilise que ça pour compresser mes videos ! Même si ça fait planter Windows Media Player (Vive vlc !)
# Merci

Posté par zeb le 05 avril 2005 à 08:41. Évalué à 4.

Merci beaucoup, xvid est un fantastique codec.
As-tu de nouveaux projets ? En particulier dans les codecs video ? Apparemment le futur est maintenant dans le h264 et ses derives, la compression par ondelettes (il y a aussi le codec de la BBC). Il y a notamment une implementation libre de h264 (appelee x264) qui est tres prometteuse, d'apres ce que j'ai essaye.
- [^] # Re: Merci
  
  Posté par Edouard Gomez (site web personnel) le 05 avril 2005 à 13:45. Évalué à 6.
  
  >As-tu de nouveaux projets ? En particulier dans les codecs video ?
  
  Non, rien de particulier en vue. Je n'ai plus trop de temps libre ces derniers temps...
  
  Je redeviens donc avec plaisir un simple utilisateur de logiciels libres, meme s'il m'arrive encore parfois, d'aller fouiner dans le code des applis pour changer quelques trucs afin de les adapter a mes besoins.
# Merci et bravo !

Posté par Olivier (site web personnel) le 05 avril 2005 à 09:59. Évalué à 3.

Bravo pour votre boulot à tous, XviD est un codec de grande qualité dans technique que philosophique (libre). Son intégration à Linux via transcode et mplayer est vraiment bonne, ce qui permet d'avoir une chaine d'encodage vidéo de très grande qualité sous Linux.

Merci à toi pour ton implicatoin dans ce projet, et longue vie à XviD !
# Conclusions

Posté par tuan kuranes (site web personnel) le 05 avril 2005 à 13:22. Évalué à 2.

Merci pour ton boulot !

On a suivi avec interet ton travail d'optimisation...

Peux tu nous livrer quelques conclusions sur les
pistes/ astuces / trucs a faire / trucs a ne pas faire ?
- [^] # Re: Conclusions
  
  Posté par Edouard Gomez (site web personnel) le 05 avril 2005 à 14:11. Évalué à 7.
  
  >Peux tu nous livrer quelques conclusions sur les
  
  >pistes
  
  XviD est maintenant une mecanique bien rodée. Les algorithmes de Motion Estimation sont stabilisés depuis pas mal de temps maintenant et on ne peut plus trop espérer les améliorer. La suite sera donc surement principalement orienté sur deux axes:
  - Reduire la complexité des algos, afin de gagner des cycles et par consequent, pour un meme temps de codage, permettre l'utilisation d'options plus gourmande. On optimise en vitesse pour que l'utilisateur a machine constante puisse activer plus d'options pour la qualité -> gain de qualité a temps de codage constant.
  - Ameliorer les algos de ME. Tache plus difficle mais pas insurmontable pour les courageux. sysKin avait beaoucoup travaillé sur les algos dit "rate distortion optimized (RDO)" dans XviD 1.x pour le choix des blocs (vhq1) et pour l'evaluation des vecteurs de mouvements candidats (vhq>1). Ces fonctions RDO d'evaluation utilisent toutes des contantes magiques qui permettent d'etablir une relation entre R (le nombre de bit codés) et D (distortion entre l'image originale et l'image codée, grandeur assimilable a l'energie de l'erreur de codage), et F(type de bloc) qui donne une cst par rapport au type de bloc qui represente le nombre de bit employes de facon constante dans la grammaire du bitstream du bloc codé:
  R = F(type bloc) + Lambda*D
  XviD utilise un lambda constant, pour gagner en qualité, il est envisageable de passer à un lambda optimum pour le bloc codé... en gros rendre le Lambda un poil adaptif a la source.... J'ai pas d'url a proposer pour obtenir les publications sur le sujet, dsl.
  
  >astuces
  
  Pas d'astuces désolé, optimiser tant en qualité qu'en vitesse, c'est toujours un travail assez fastidieux et minutieux.
  
  >Trucs a faire
  
  Ouais, plein ! d'abord le code d'XviD est pas si bien designé. Donc un travail plus ou moins facile consisterait a nettoyer les APIs internes tout en ayant une correspondance 1:1 avec le resultat des vieilles versions. Une autre tache moins excitante, completer la doc dispo sur mon site.... bref XviD est un projet plutot en maintenance, les codeurs fous passeront surement leur chemin, les autres, trouveront toujours quelque chose a nettoyer, redisigner etc...
  
  Autre truc a faire, continuer a tester, remonter les bugs de facon precise (avec une lib compilée pour debug et un coup de gdb et le contexte de pile etc etc)... bref ce que tout logiciel libre demande à ses power users.
  
  >Trucs a ne pas faire
  
  Appeler les fonctions inutilement: toujours n'appeler une fonction que si c'est necessaire, meme si cela impose de garder en memoire l'etat de tes objets (au sens conceptuel, pas OOP) pour savoir le travail qu'il reste encore a effectuer dessus.
  
  La consommation inutile de memoire reduit aussi beaucoup les perfs de facon indirecte. Reduire les besoins memoire permet souvent d'etre moins gourmand en bande passante... moins d'acces memoire, c'est moins de temps perdu dans les cache miss et le rapatriement sur les bus memoires qui representent de vrais goulot d'etranglement comparativement aux 3GHz de nos CPU...
  
  Mettre des tests dans les boucles critiques, preferer une boucle critique par cas a traiter.
  
  ... je pourrais en parler des heures... mais tout a une fin :-)
  - [^] # Re: Conclusions
    
    Posté par cho7 (site web personnel) le 05 avril 2005 à 17:17. Évalué à 1.
    
    Ameliorer les algos de ME. Tache plus difficle mais pas insurmontable pour les courageux. sysKin avait beaoucoup travaillé sur les algos dit "rate distortion optimized (RDO)" dans XviD 1.x pour le choix des blocs (vhq1) et pour l'evaluation des vecteurs de mouvements candidats (vhq>1). Ces fonctions RDO d'evaluation utilisent toutes des contantes magiques qui permettent d'etablir une relation entre R (le nombre de bit codés) et D (distortion entre l'image originale et l'image codée, grandeur assimilable a l'energie de l'erreur de codage), et F(type de bloc) qui donne une cst par rapport au type de bloc qui represente le nombre de bit employes de facon constante dans la grammaire du bitstream du bloc codé:
    R = F(type bloc) + Lambda*D
    XviD utilise un lambda constant, pour gagner en qualité, il est envisageable de passer à un lambda optimum pour le bloc codé... en gros rendre le Lambda un poil adaptif a la source.... J'ai pas d'url a proposer pour obtenir les publications sur le sujet, dsl.
    
    Excellent, je n'ai RIEN compris :-D (ah, on m'dit dans l'oreille que c'est normal, et il parrait aussi que je suis une quiche)
# Merci, et bon vent (enfin, pas trop loin quand même)

Posté par Guillaume POIRIER le 05 avril 2005 à 13:47. Évalué à 3.

Merci Edouard pour tout le travail que tu as pu faire au long de ces 3 années. Mon Dieu comme le temps passe vite.
Je te souhaite bon vent et bonne chance pour la suite, et j'espère que tu restera quand même pas trop loin du projet pour continuer de partager ton savoir.
J'espère de mon côté pouvoir continuer "d'améliorer" la symbiose avec MEncoder... y a-t-il une personne qui compte prendre la relève dans l'équipe?

Une grand Merci!

Guillaume
# XviD vs DivX

Posté par Thomas J. (site web personnel) le 12 avril 2005 à 11:15. Évalué à 1.

Tout d'abords un grand merci à toi pour ta contribution à ce fameux codec vidéo libre !!
J'aimerais connaître ta position (ou tes craintes) sur le devenir d'XviD face au nouveau DivX 6 qui sortira très prochainement.
Crois-tu que ce que va proposer DivX Labs avec son nouveau codec (meilleur taux de compression, intégration dans un seul fichier de plusieurs pistes audio, de sous-titres, de menus interactifs...) ne sera que de la poudre aux yeux ou crois-tu qu'il y a un réel danger pour le codec XviD ?
- [^] # Re: XviD vs DivX
  
  Posté par Edouard Gomez (site web personnel) le 14 avril 2005 à 17:50. Évalué à 2.
  
  >J'aimerais connaître ta position (ou tes craintes) sur le devenir d'XviD face au nouveau DivX 6 qui sortira très prochainement.
  
  DivX6 sera comme ses predecesseurs, de la poudre aux yeux en terme de gain de qualité reelle. DivX n'a pas sorti un seul codec innovant depuis DivX5.0. Depuis DivX5, ils multiplient les features qui ne donnent au final que de bien maigres gains pour de si longue seance de codage (mode insane == 1.7x plus lent que xvid avec toute option a fond, pour une qualite moindre dans bien des cas): le npass, le mode insane, les bvops implementes de facon partielle, le GMC a un seul warp point (donc inutile car incapable de simuler les mouvements de caméra autre que la translation) etc etc.
  
  Donc DivX6, je retiens que ce sera surtout un nouveau container... sur PC l'adoption d'un container reste facile, il suffit d'avoir un demultiplexer adequat (splitter sous DShow, ou module quivabien pour nos utilitaires unix). Leur format aura du succes uniquement si l'industrie de players hardware suit. Si elle ne suit pas, ce format restera cantonné au PC et autre player plus évolué qu'une platine de salon, et ne touchera donc pas Mr tout le monde.
  
  Ma crainte pour xvid, c'est que les developpeurs qui restent sur le projet sont de tres loin, les moins actifs de ces deux dernieres années. Le projet est donc fortement compromis dans son évolution. D'autant plus que les codecs h264 arrivent, alors il attirera de moins en moins de personnes, car pourquoi s'embeter a coder sur des vieilles normes, quand on a des trucs bien plus sexys avec lesquels on peut s'amuser aujourd'hui (ie: x264)? :-)

Suivre le flux des commentaires

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