Audiovisuel Interview de l'équipe XviD et sortie de la version 1.0.1

Posté par (page perso) . Modéré par Benoît Sibaud.
Tags :
Le lundi 7 juin, une version de corrections de bugs de XviD est sortie, la 1.0.1. Les changements se situent dans xvidcore et le frontend VFW.

Une interview à laquelle l'équipe XviD a bien voulu se soumettre a été réalisée. Elle est en anglais. Les différents sujet abordés sont l'historique du projet, son organisation, les tests Doom9, la violation de licence GPL, les standards, les brevets logiciels, l'interopérabilité, les autres codecs, une brève analyse du monde des codecs vidéo, deux mots sur le futur d'XviD. Lire l'article.

L'équipe XviD nous propose non seulement un codec libre, standard, performant, stable, mais en plus l'équipe est ouverte, disponible et réactive, bref que du bonheur.

Merci XviD ! ---------------------------------------------------------------------------
Q: How is the XviD project born? ...and when?

It's a longer than average story, bear with us.

In January 2001, DivXNetworks created ProjectMayo, a website to facilitate the development of open source MPEG-4 related software projects. It included message boards, mailing lists and CVS servers. The initial projects published on the websites were developed by DivXNetworks staff. Users and developers were encouraged to contribute to the projects by e-mail.

The flagship project, named OpenDivX, was based upon the freely available MoMuSys [1] reference MPEG-4 encoder. As the name suggests, it was to be an "Open" implementation of "DivX", because at the time, DivX was synonymous with the hacked Microsoft MPEG-4v3 binary.

Little improvements were made to the OpenDivX code base. Many people attribute this to the restrictive open source license under which the software was distributed, and the lack of a write-CVS access to the general public. In March 2001, a rewritten encoder library was committed to the CVS (by a DivXNetworks staff). The rewritten library was removed shortly after, with DivXNetworks citing that "We (our bosses) decided that we are not ready to have it in public yet."

The release of the closed-sourced DivX codec in June 2001 was met with some anger by some of "supports" of OpenDivX. As a result, the German student, Michael Militzer decided to continue the OpenDivX spirit elsewhere. In early August 2001 a website and public CVS repository was set-up at, where also an initial source code release of a still nameless project got published. A name for the project was established two months later: XviD, proposed by an anonymous supporter, probably as a joke and probably because it spells DivX backwards, was chosen because it was reasonable, sounded cool and a free ".org" domain name was available.

During the very first months, new contributors [2] joined which helped tremendously making the project grow and further evolve. The initial focus was to learn from, document and replace the original OpenDivX and MoMuSys code. The GNU GPL was chosen as an appropriate distribution license. New features were added and routines optimized. Over the next months, even more new developers and supporters joined (now) XviD [3] and due to many further advances, the project soon gained attention from multimedia/DVD-backup enthusiasts and end-users. Their support has *enabled* the success of XviD!

[1] The IEC/ISO MPEG-4 standard provides the source code of a reference codec for free. It is used in order to test new implementations of the standard. It provides an easy way to test compatibility and compliance with the standard.

[2] The first who dared to join what should later become XviD: Christoph Lampert, Peter Ross, Daniel Smith.

[3] Here is a small list of the most active people: Radoslaw Czyz, Edouard Gomez, Dirk Knop. For a more complete list of contributors, refer to the AUTHORS/ChangeLog files available in the XviD source distribution.

Q: How do you code such standard-compliant, high-performance multiplatform video codec?

In short, enthusiastic developers and users. Often we've work with the FFmpeg project (LGPL), which is a superb MPEG-4 implementation, was often ahead of XviD concerning the decoding part.

Portability is the result of almost three years collaboration between developers from the Win32 world and the Unix world. XviD performance is the consequence of the hard work of a few and talented assembly wizards.

Q: How do you organize as a team?

We don't have a real organizational structure nor hierarchies. Every developer is free to pick tasks that interest him (or her), however we try to balance the boring tasks with some of the more fun things to code. It is important to mention that XviD is a hobby project; no one's obliged to do anything.

Do you accept external contributions?

Yes, if they are under GPL. The powers of the Free Software development ensures that people who find bugs can help remove them, and people who desire new features can implement them, and make XviD better for everybody.

How and when did the user and developer community grow?

The user community began to grow significantly from February 2002 onwards, which was when XviD participated in doom9's codec comparison for the first time and had been found to compete very well with the available commercial MPEG-4 codecs at that time. Nowadays, even "Joe" users know about XviD. It's quite impressive to see how our work became "almost" mainstream, given we've done so little to promote it.

The developer community has grown since project inception, however not at the same rate. Industry have difficulty finding video compression developers (we know, every month somebody receives a letter approaching them for work), let alone finding developers willing to do it in their spare time!

Q: How many beta and release candidate versions before hitting 1.0.0? Why?

For the first 18 months we didn't bother with releases or concern ourselves with version numbers. Some of the developers were kind provided unofficial binaries to the user community. However as time went by, and XviD's popularity grew, the need for official releases arose.

We started with 3 official 0.9 series releases. This branch was focused on providing a stable codec for the MPEG-4 Simple Profile [3].

For almost 18 months, an experimental branch of the CVS was the focus of development, were Advanced Simple Profile features were implemented. Again, some developers provided unofficial binaries to the user community. The branch was eventually considered stable to start the 1.0 beta series (3 beta releases), and followed by four release candidates.

In summary, 10 official releases were made prior to the 1.0 final.

[3] MPEG-4 is divided in profiles which ensure interoperability between same profile support hardware/software.

Q: Did you participate in Doom9 tests that gave XviD the winner? Did the results surprise you? Do you pass such tests internally?

Sure we did participate in doom9's codec tests since we consider his tests very solid and objective, which cannot be said about most other codec tests. However internally we don't carry out such extensive tests regularly - it is too time consuming. We perform such tests only in preparation for doom9's tests (to propose reasonably well working XviD settings), or after a significant modification to the code.

And did doom9's results surprise us? Of course _not_. We're very convinced that XviD is by far the best video codec in the world - you didn't expect any different answer, right? ;-)

Q: What happened with Sigma Designs? How did the GPL violations evolved? Are they resolved?

During the second quarter of 2002, Sigma Designs released an MPEG-4 video codec called the REALmagic MPEG-4 (aka "RMP4"). As we regularly test XviD bitstreams with other MPEG-4 codecs for interoperability, one of the team stumbled across a bug in the RMP4 software. Examination of the RMP4 binary revealed that it was based heavily upon XviD.

We sought legal advice from the Free Software Foundation and contacted Sigma Designs. Sigma Designs privately admitted their fault, and stated the codec would be rewritten from scratch to prevent future license violation. We accepted this resolution. Their "rewritten" version was released in the weeks following. To our dismay, the codec had not been rewritten, but compiled different and assembly instructions mangled to hide the fact REALmagic was heavily based on XviD.

We contacted Sigma Designs and demanded that they stop distribution of RMP4 until the issue could be resolved. Their response was unacceptable, so in protest we halted XviD development and posted evidence clearly showing the GPL violation.

Sigma Designs reacted quickly, releasing the source code to RMP4 and provided a minor apology to the open source community. However, they said that the release of source code was planned all along.

Releasing the source code was unnecessary. Sigma Designs could have:
a) rewritten the product
b) sought the use of an alternative MPEG-4 encoder product
c) terminated the product

Q: Do you strictly implement MPEG-4 standards?

XviD adheres to the MPEG-4 standard. However it's a large standard and we only adhere to a small component of it.

Q: Do you have problems with software patents?

Yes. Almost all "ideas" of MPEG-4 are under patent, it's impossible to create an MPEG-4 codec without using methods on which companies claim rights. Unfortunately, due to the rapidly increasing amount of software patents granted also in Europe, today patents are a real thread to the development of almost all kinds of software (just think of LZW compression case).

That is one of the reasons why XviD is distributed source-only: because an end-user ready program might need a license from MPEG-LA which would cost several millions of dollars for a codec of XviD's popularity, even though we ourselves don't earn anything from XviD.

Q: Are you in contact with DivX Networks developers?

Yes, occasionally. Some XviD developers who were already involved in OpenDivX still have some private contact with some of the DivXNetworks developers. Most of the time it's just an occasional 'how are you?' but seldom also DivX/XviD specific implementation bugs are discussed.

Q: Do they follow the standard?

Yes they follow the standard, minus implementation bugs and the way they store bi-directional frames in the AVI container. Though the first point is forgivable (what software is totally bug free?), but the second point is more critical, and we are now obliged to implement this scheme too in order to be interoperable.

Q: Are they interoperable/compliant?

Yes, though only at specific profiles. MPEG-4 profiles define specific feature sets to be supported so every capable decoder of a certain profile is interoperable with another decoder supporting the same profile. XviD and DivX both support the Simple Profile and Advanced Simple Profile.

DivXNetworks are also trying to push its own set of profiles, to ensure interoperability with hardware MPEG-4 players, as the MPEG-4 profiles are inadequate. Whilst we are in favor of new profiles, it would have been better to involve other MPEG-4 vendors, to ensure that new profiles are representative of what users need.

Q: Are there problems with proprietary MPEG-4 implementations? Are they interoperable/compliant?

Most modern proprietary MPEG-4 implementations are hardware based. We get reports from users that XviD works on a number of hardware devices. In general these devices are MPEG-4 interoperable, but enforce restrictions on the video dimensions, bit rates, or MPEG-4 features.

We are also facing another problem. Some hardware manufacturers do advertise their product as XviD compatible. Such statements are false, as we have no certification program. It is difficult for us to educate the average "Joe" user that these companies are abusing of their technical ignorance.

Q: What are the differences between Ogg Theora, Ogg Tarkin, VP3, Dirac and Matroska? Are they concurrent?

Let's first put aside Matroska as it's an A/V container format.

The others differ in the math theories they use to compress the video data. Theora (Free version of VP3) does use the usual block approach, however tries to be free of software patents. Dirac uses wavelets. Tarkin, afaik, is just a mailing list.

They aren't really concurrent at this time because they're simply not ready for mainstream. With time we'll see which one dominates the others :-)

Q: What is video-codecs-universe like now? (free and open source versus proprietary, as well as software versus hardware)

The video codec world is one of the most competitive domains. Today, we see three "ready" technologies competing:
- Windows Media Video from the well known Microsoft Corporation
- RealVideo from RealNetworks
- MPEG-4 industry standard
- H.264 (MPEG-4 Part 10) industry standard

The two first, are proprietary, and the companies backing the formats are known to be highly competitive. Microsoft has an advantage, given its operating system monopoly.

The last two are more Open Source friendly as the specifications are public. There are many MPEG-4 implementations (this list is by far incomplete):
- XviD (Free Software)
- FFmpeg (Free Software)
- DivX (proprietary)
- NeroDigital (proprietary)
- 3ivX (proprietary)
- Quicktime MPEG-4 (proprietary)
- MPEGable MPEG-4 (proprietary)

Whilst a new standard, there are some H.264 implementations underway:
- X.264 (Free Software)
- FFmpeg (Free Software)

Unfortunately the codec-world is not only about making the best codec. It is about persuading those with influence to adopt your codec. The reader could search the web about the war that is raging to establish the High Definition DVD codec.

Q: What are your plans for the future?

We try not to lay plans, it leads to expectation.

For better hardware interoperability, improved bit rate control (VBV) is planned for the next major version 1.1. User interfaces changes for Win32 are also on the horizon.

Internally, there are still lots of work to do, such as improving decoder speed and implementing some remaining Advanced Simple Profile features. As always, we're trying to increase performance/visual-quality, and start tweaking HDTV performance.

"The future of XviD is defined by those who use it."

Q: What questions didn't we ask? Answer them!

Q2: What do people use XviD for?
A2: We assume its primarily for backing up DVDs, videos or broadcasts, but we've heard of some interesting applications, inluding:
- survielance
- medicine
- education: e.g. developing online tutorials.
- research: e.g. experimenting with the MPEG-4 standard.

Q1: How late will you go to bed in order to complete this interview?
A1: Just too late... we're going to have a hard day tomorrow at work :-)

> Thanx for the interview, for the codec, and much more !

No, thanks to you who proposed us this interview.

And thanks to all who contribute to Free Software and Open Source, without your work, our work could not have been possible either.

-- The "XviD Team"
  • # Lecteur xvid de salon

    Posté par . Évalué à  6 .

    Vivement un lecteur xvid de salon avec un firmware libre...

    Si quelqu'un a des infos sur un éventuel lecteur de ce type, je suis preneur !

    • [^] # Re: Lecteur xvid de salon

      Posté par . Évalué à  -2 .

      • [^] # Re: Lecteur xvid de salon

        Posté par (page perso) . Évalué à  10 .

        A part le fait que le Kiss n'utilise pas un firmware totalement libre (ucLinux + Busybox + des modules noyau binaires), ce qui fait que tu te fait allègrement moinsser, le CPU du Kiss ne fait pas tourner XVid, il se contente d'envoyer les données à un décodeur matériel, ce qui permet d'avoir une puce qui fait tout le décodage avec une très faible consomation électrique.

        Parce que faire tourner un algo comme xvid sur un processeur non spécialisé, ça serait quand même beaucoup plus consomateur de ressources.

        Le Kiss en fonctionnement consomme une vingtaine de watts. Un mini PC aurait vite fait de consommer 5 à 10 fois plus.
        • [^] # Re: Lecteur xvid de salon

          Posté par (page perso) . Évalué à  1 .

          Oula... ou ne compare pas un matériel spécialisé à un matériel générique malheureux ! ;-) Même si tu as une carte spécialisée dans ta bécane... Et puis y'a des platines Kiss avec et sans disque dur, et ça doit pas consommer autant àmha.
          • [^] # Re: Lecteur xvid de salon

            Posté par (page perso) . Évalué à  6 .

            J'ai un lecteur de salon compatible mpeg 4. Les Xvid passent dessus sans probleme. C'est un truc que j'ai acheté 99 ? au supermarché.

            En fait tout codec mpeg4 doit pouvoir les lire.
            • [^] # Re: Lecteur xvid de salon

              Posté par (page perso) . Évalué à  1 .

              Ben du fait que c'est un standard, c'est plutôt normal... mais bon, vu les éditeurs proprio qui veulent tirer la couverture, on va certainement voir des implémentations qui s'écartent un peu des standards, comme c'est déjà le cas pour DivX (lire l'interview), mais je pense aussi et surtout à un géant éditeur américain qui a déjà fait le coup sur les standards du web...

              Encore une fois, les standards sont la voie pour l'interopérabilité.
              • [^] # Re: Lecteur xvid de salon

                Posté par (page perso) . Évalué à  9 .

                Bof tu sais c'est le p2p qui fait le marché, je crois.
                Or en terme de compression / qualité Xvid et de loin le meilleur. De plus le succes d'un logiciel comme virtualdub devrait beaucoup aider.
            • [^] # Re: Lecteur xvid de salon

              Posté par (page perso) . Évalué à  1 .

              Je ne connais pas très bien ce domaine et du coup je ne comprend pas pourquoi il me faut dans ce cas un là un codec divx, un codex xvid etc ?
              • [^] # Re: Lecteur xvid de salon

                Posté par . Évalué à  7 .

                Normalement il ne te faut pas tout plein de codec pour lire les trucs encodés en mpeg4.

                D'ailleur, les gens d'XviD conseillent souvent d'utiliser FFmpeg pour la lecture il me semble. (en disant que le truc sur lequel ils se concentrent, c'est la compression des vidéos)
              • [^] # Re: Lecteur xvid de salon

                Posté par . Évalué à  2 .

                non c est seulement pour l'encodage ( oui oje< je sais on dit pas encodage c est moche ) il me semble meme que pour le decodage xvid conseille de passer par ffmpeg ou le player divx .
                • [^] # Re: Lecteur xvid de salon

                  Posté par (page perso) . Évalué à  5 .

                  Ah non, je peux dire qu'on conseille FFmpeg pour la lecture. Pour le codage, XviD c'est mieux(tm) et on conseillera jamais un autre codeur :-) Non mais, sinon pourquoi on bosserait du coup si c'était pour conseiller à la fois le codeur et le décodeur FFmpeg ? ;-)
                • [^] # Re: Lecteur xvid de salon

                  Posté par . Évalué à  1 .

                  ( oui oje< je sais on dit pas encodage c est moche )

                  Merci mon houpla< je vois que j'ai laissé des traces :-)
                  (Je ne moule plus trop en ce moment, alors je laisse ce commentaire)
  • # XviD pour Windows

    Posté par (page perso) . Évalué à  6 .

    A noter que les binaires pour Windows sont téléchargeables sur
  • # cette page ne rend pas correctement dans konqueror

    Posté par . Évalué à  5 .

  • # OverTime

    Posté par . Évalué à  -2 .

    " Ce lundi 7 mai "

    Le second effet IPOT.
  • # la premiere depeche sur Xvid

    Posté par (page perso) . Évalué à  3 .

    la premiere depeche sur Xvid sur DLFP en 2001:
    Xvid un codec MPEG4 sous GPL

Suivre le flux des commentaires

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