Page 1 sur 1

le xvid est mort?

Posté : mer. 20 janv., 2010 21:40
par dimdes
Que pensez-vous de ceci?
Trouver sur le site d'un soft que j'utilise pour réencoder sur mac ( et oui.. je suis passé sur mac)



Focus on what we do best

As we've had on our roadmap for quite awhile now, one of our goals for version 0.9.4 was to refocus on HandBrake's key strengths and to remove dead weight. As part of this process, several containers and a codec have been removed from HandBrake.

AVI: AVI is a rough beast. It is obsolete. It does not support modern container features like chapters, muxed-in subtitles, variable framerate video, or out of order frame display. Furthermore, HandBrake's AVI muxer is vanilla AVI 1.0 that doesn't even support large files. The code has not been actively maintained since 2005. Keeping it in the library while implementing new features means a very convoluted data pipeline, full of conditionals that make the code more difficult to read and maintain, and make output harder to predict. As such, it is now gone. It is not coming back, and good riddance.

OGG/OGM: HandBrake's OGM muxer is just as out of date. It hasn't been actively maintained in years either, and it too lacks support for HandBrake's best features. It requires conditionals to work around missing functionality too...only this one gets tested so infrequently the conditionals were never even put in the code, so it just fails when you try to do anything advanced. This one is not coming back either. And yes, we're aware of HTML 5. For patent-free muxing, HandBrake still has Matroska, which is a much better container anyway.

XviD: HandBrake, these days, is almost entirely about H.264 video, aka MPEG-4 Part 10. This makes it rather...superfluous to include two different encoders for an older codec, MPEG-4 Part 2. When choosing between FFmpeg's and XviD's, it came down to a matter of necessity. We need to include libavcodec (FFmpeg) for a bunch of other parts of its API, like decoding. Meanwhile, XviD's build system causes grief (it's the most common support query we get about compiling, after x264's requirement of yasm). Since we mainly use MPEG-4 Part 2 for testing/debugging, and recommend only H.264 for high quality encodes, Xvid's undisputed quality edge over FFmpeg's encoder is inconsequential, while FFmpeg's speed edge over XviD is important to us.

Posté : mer. 20 janv., 2010 21:53
par Underground78
Bah en fait ici le XviD est supprimé mais il reste toujours FFmpeg comme encodeur MPEG4 ASP ...

Après c'est clair qu'il y a de moins en moins de gens qui encodent en XviD. Avant on pouvait toujours parler de la compatibilité avec les divers lecteurs mais aujourd'hui c'est plus très vrai ... Le XviD se meurt je pense qu'on peut pas le dire autrement ...

Posté : mer. 20 janv., 2010 22:04
par pepsilite
le xvid se meurt ... mouais, mais l'enterrement ne sera pas pour tout de suite quand même... on trouve 100x plus de xvid que de x264 sur la toile.

Posté : mer. 20 janv., 2010 23:03
par Subbat
pepsilite a écrit :le xvid se meurt ... mouais, mais l'enterrement ne sera pas pour tout de suite quand même... on trouve 100x plus de xvid que de x264 sur la toile.
+1
Il suffit de voir les 1ères demandes de chaque nouveau membres (moi le 1er il y a 1 an), il me semble bien qu'elles traitent la plupart du temps de xvid...

Posté : mer. 20 janv., 2010 23:15
par pepsilite
pepsilite a écrit : ... on trouve 100x plus de xvid que de x264 sur la toile.
Ce que je déplore d'ailleurs, vivement le "tout-x264".