Le 30 décembre dernier est sortit la tant attendue version 1.1.0 d'XviD (http://www.xvid.org/)
XviD est un codec vidéo en GPL implémentant toute (ou presque) la norme MPEG-4 ASP. Ce codec tient depuis plusieurs années de suite le haut du pavé des codecs ASP, et c'est ma fois assez mérité.
XviD est en effet encore une fois tout à fait bien placé dans le comparatif effectué par Doom9: http://www.doom9.org/index.html?/codecs-final-105-1.htm
Cette version apporte des améliorations au niveau qualité, et plus de plateformes logicielles supportées de façon optimisée.
Au menu des réjouissances pour les versions à venir, le mode multithreadé: http://forum.doom9.org/showthread.php?t=104257&highlight(...) mais probablement plus de considérables améliorations.
NOTE: Pour supporter toutes les nouveautés d'XviD, si vous utilisez MEncoder, il faut utiliser la version CVS de MPlayer/MEncoder.
Le changelog:
This release is the long awaited 1.1.0. It is mostly API compatible with the previous stable release as we dropped support for reduced resolution coding. If your application didn't use that feature then the upgrade is totally compatible.
Changes since 1.0.3:
* xvidcore:
o Improved Low bitrate quality.
o Improved VBV support
o Rate-Distortion mode decision for bvops
o New postprocessing functions, brightness and deringing
o New PowerPC port by Christoph Naegeli
o Brand new amd64 Linux 64bit port by Andre Werthmann
o Various decoder and encoder speedups
o A few bugs squashed
* VFW frontend
o Mingw/CygWin support
o Various small improvements
o A few bugs squashed
* DShow frontend
o Mingw/CygWin support
o Support for brightness control
o Various small improvements
o A few bugs squashed
Changes since 1.1.0-beta2:
* xvidcore
o Field interlaced decoding
o IEEE-1180 compliant SSE2 iDCT (disabled for safety)
o Fixed misaligned reads on RISC platforms such as ARM
o Completed GCC 4.0 support
o Export only public API on GNU/Linux and Solaris
o Work on the example apps. Support for AVS input in xvid_encraw
* VFW frontend
o Small updates
* DShow frontend
o Additional fourcc support
Journal XviD 1.1.0-final dans les bacs
5
jan.
2006
# Pour rendre visite...
Posté par Me Nut (site web personnel) . Évalué à 3.
# meuh
Posté par gc (site web personnel) . Évalué à 2.
dans mencoder, bitrate= et fixed_quant= semblent utiliser un bitrate fixe, et je ne vois rien d'autre dans le domaine ?
j'ai une deuxième question : j'aimerais "recompresser" des vidéos issues d'appareil photo numérique, en automatique - car les vidéos sont souvent de 5 à 10 fois plus grandes que nécessaire. existe-t-il des options ou un trick permettant de sélectionner un bitrate dans l'espoir de ne pas en gâcher si inutile (en effet en général la qualité est mauvaise) mais pas non plus réduire la qualité de la vidéo ? au besoin ça peut se faire en deux passes si jamais.
et enfin, j'avais essayé l'option "cartoon" pour encoder une vidéo issue d'une capture d'écran d'une appli gtk[1] mais ça n'avait pas amélioré, à ma surprise.
merci :)
[1] http://zarb.org/~gc/html/booh/video-demo.html
[^] # Re: meuh
Posté par Guillaume POIRIER . Évalué à 6.
Plus précisément, le codec utilise un tampon qui se rempli/vide en fonction de la complexité de la vidéo à traiter. Je ne sais pas de tête quelle est la durée du tampon, mais c'est de l'ordre de quelques secondes. Ça veut dire que sur la première passe de vidéo, ton débit vidéo va être respecté à chaque fois sur un intervalle de temps définit.
Le mieux, c'est de faire un encodage en 2 passes: la première regarde la complexité de la source, et la deuxième utilise ces stats pour décider comment adapter le débit vidéo sur l'ensemble de l'encodage.
Concrètement, ça veux dire que tu fais une première passe avec:
pass=1:bitrate=xx
et une 2e passe avec
pass=2:bitrate=xx
Pour ce qui est de la sélection de bitrate automatique, ça ne marche pas exactement comme tu le voudrais. Le plus simple pour toi et d'encoder à quantizer constant, fixed_quant=2 ou fixed_quant=3
Tu peux baisser encore le quantizer si tu veux faire baisser la qualité de ta vidéo.
Pour ce qui est de l'option cartoon, il ne faut pas attendre des miracles: c'est juste une heuristique qui est sencé mieux marcher, mais si tu encodes à faible débit, ça ne peut pas faire de miracles.
[^] # Re: meuh
Posté par Matthieu Weber . Évalué à 1.
[^] # Re: meuh
Posté par Guillaume POIRIER . Évalué à 2.
Par contre, les normes VCD, XVCD et DVD placent des contraintes assez chiantes pour garantir un bon décodage par les platines hardware. Ils ne requièrent pas de débit constant si je me rappelle bien mais par contre, ne permettent pas une grosse variation du débit (sans doute une question de tampons de données).
[^] # codage, en bon français
Posté par Olivier Jeannet . Évalué à 3.
# Par la présente...
Posté par Edouard Gomez (site web personnel) . Évalué à 6.
sysKin, l'autre développeur actif à l'époque où j'étais encore mainteneur, semble reprendre gout au hacking d'XviD, et je pense que les possesseurs d'architecures bicore AMD64 seront les grands bénéficiaires de ses efforts de développement:
- Multithreading et amélioration de la qualité par ajout de nouveaux algos autrefois peu accessibles car trop gourmands pour les configs utilisateurs.
Seul bémol, il possède un bicore 4200+ tournant sous windows 32bit, ce qui me fait craindre, que les adorateurs du full 64bit ne pourront peut etre pas profiter de tout sans faire appel a la compat 32bit. Enfin, moindre mal car xvid ne depend que de la libc, et donc je suis quasi sûr qu'aucune chroot ne sera pas nécessaire.
Enfin, voilà bonne chance à sysKin, XviD le mérite bien.
[^] # Re: Par la présente...
Posté par patrick_g (site web personnel) . Évalué à 5.
Mais...heu...c'est un CPU 64 bits ça non ?
Qu'est-ce qui l'empêche d'installer une distrib 64 bits à la place ou à coté de son Windows ? Ou alors il est Redmondophile fanatique ?
[^] # Re: Par la présente...
Posté par David . Évalué à 4.
Autrement dit, est-ce que le mode 64bit permet un gain en performance pour les application desktop/multimedia?
D'autre part, est-ce que FFMpeg est compatible 64bit?
Le but est de savoir si ca vaut la peine d'installer Debian Etch 64bit, ou s'il vaut mieux rester en 32bit? Attention : je veux pas m'embeter avec un mélange 64bit et 32bit chrooté!
[^] # Re: Par la présente...
Posté par Guillaume POIRIER . Évalué à 3.
Quand les optimisations ont été portées, j'ai fait un bench: http://list.xvid.org/pipermail/xvid-devel/2005-January/00481(...)
Par exemple, sur ma machine je suis passé de 44fps à 51fps en 64 bits. C'est ridicule du tout, non?
Les différences de perfs en 64 bits sont surtout sensibles sur des bouts de codes de calcul intensif, et où on manipule suffisamment de données pour bénéfi
cier des 8 registres suplémentaire.
En général, les applis sur AMD64 sont plus rapides, à quelques exceptions près.
Oui, depuis 1 an et demi ^_^! (cf le même lien pour avoir une idée des perfs).
Ma machine est tourne exclusivement en 32bits depuis un an. L'unique raison pour laquelle je garde un chroot 32bits c'est pour pouvoir lire de vidéos WMV3
et quelques codecs pervers de ce genre (puisqu'on passe par les codecs binaires de MS).
Toutes les autres applis digne de ce nom sont portées depuis fort longtemps.
[^] # Re: Par la présente...
Posté par reno . Évalué à 1.
--> C'est *pas* ridicule du tout, non?
Au départ je croyais que tu trouvais l'accélération ridicule, bon je suis un peu fatigué..
Sinon l'accélération conforte les benchs que j'avais vu jusqu'à présent: 20% de mieux.
>Ma machine est tourne exclusivement en 32bits depuis un an.
Tu veux dire 64 bit, non? Autrement je ne comprends pas la phrase.
[^] # Re: Par la présente...
Posté par Edouard Gomez (site web personnel) . Évalué à 4.
Non, juste une question d'habitude...
lui son dada c'est le codage vidéo, il ne souhaite pas migrer car il aime bien son environnnement windows. Je ne vois aucun mal à ce qu'il continue à travailler sous windows sans pour autant le qualifier de "redmondophile fanatique".
[^] # Re: Par la présente...
Posté par patrick_g (site web personnel) . Évalué à 2.
le simple fait de tester un code dans des environnements différents doit aider à mettre en évidence certains problèmes.
mais bon...il fait comme il veut et je le remercie chaudement pour son boulot.
[^] # Re: Par la présente...
Posté par JP Martin . Évalué à 1.
En tout cas, merci à tous les développeurs du libre pour votre don de temps et de savoir !
Bonne année 2006 à tous
JP Martin
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.