Re: Les bons noms pour les bons formats (etait: Re: mencoder…

Top Page

Reply to this message
Author: Geoffroy Carrier
Date:  
To: Olivier Allard-Jacquin
CC: Guilde
Subject: Re: Les bons noms pour les bons formats (etait: Re: mencoder)
Reponse ecrite rapidement, je me suis lache sur les parentheses et les
phrases alambiquees puis vieillies en cuve...

Olivier Allard-Jacquin wrote:
>>>     Le débat a eu lieu depuis plus de 3 ans, sur des sites comme
>>> http://www.doom9.org/ . L'idée est venue de la part des Windowsiens qui
>>> voulaient avoir un moyen de différentier les contenus purement audio
>>> ogg/vorbis des vidéo utilisant le conteneur http://www.xiph.org/ .
>> Non, ca n'est pas la meme chose, et ce n'est pas simplement une question
>> d'extension dans le nom des fichiers.
>     Je n'ai pas dit cela.

Vu qu'un fichier OGM peut ne contenir que du son, ca ne differencie en
rien les deux.
Et c'etait pas pour differencier, c'etait, comme tu le dis plus bas,
pour foutre de la video dans du Ogg en "precisant" quelle convention on
utilise pour le codec (precision toute relative, ya pas de specs ; OK,
c'est pas super complique).

>     Cependant, http://fr.wikipedia.org/wiki/Ogg_Media indique que le
> conteneur ogg de Xiph.org supporte au moins un flux video (theoras),
> donc il est quand même conçu pour le multiplexage (contrairement à ce
> que tu pourrais laisser sous-entendre) :
> <extrait>
> C'est (ndt: le format "ogm" décrit par Tobias) en fait une modification
> (ou "hack", dans le sens légal du terme) du conteneur Ogg, qui ne
> supporte quant à lui que les formats issus du projet éponyme (Theora et
> Vorbis), lesquels sont libres.
> </extrait>

Gnnn ? Je parle explicitement de Theora dans ta citation, donc la je
vois assez mal le sous-entendu... Effectivement, c'est clairement un
multiplexe :)

>     Maintenant, que ce hack soit propre ou non, qu'il ne soit pas maintenu
> par Xiph.org, ce sont d'autres problèmes. Le "format ogm" de Tobias
> marche, et il peut servir à mutiplexer divers combinaisons de flux
> audios (ogg/vorbis, mp3, ...) et vidéos (xvid, divx, etc...). Enfin, les
> fichiers générés sont lisibles sous Linux (mplayer, vlc, ...) et sous
> Windows (vlc ou via oggds)

Tout a fait d'accord. Sauf que c'est pas une excuse. On peut dire la
meme chose des vieilles versions du conteneur Windows Media (wmv, wma),
de l'ASF et du Quicktime Movie.

>> Bonne lecture :
>> http://xiph.org/container/ogm.html
>> (4eme resultat de ma premiere recherche google, "ogm ogg differences" en
>> non-francophone, et le premier resultat visiblement sur un "site officiel")
>     Merci de ce lien, cela doit fait au moins 3 ans que je le connais, et
> il son contenu n'a pas bougé d'un poil depuis ce temps... ;)

Le lien n'etait pas specialement pour toi mais aussi pour des personnes
moins au courant, et je suppose qu'il y en a qui m'ont lu...
Effectivement, ca bouge pas. En meme temps, OGM ne bouge pas :)

>     Soit dit en passant, RIEN dans la page que tu cites n'indique que, je
> te cite "on NE peut PAS mettre du xvid proprement par exemple". Le
> problème, décrit dans cette page, est plus philosophique (philosophie du
> libre) que technique.

Faudrait que je me retape la RFC de Ogg, mais en gros (un peu peur de
dire des conneries, mais je fatigue ; si quelqu'un veut bien verifier[1]) :
Dans le bos (l'espace ou l'on specifie le codec du flux, et les
parametres necessaires au codec pour savoir comment le manipuler, genre
la profondeur des couleurs ou la taille d'echantillonage), on doit, a
l'implementation de l'encapsulage d'un codec dans le Ogg, determiner une
maniere d'identifier le codec sans la moindre ambiguite par rapport aux
codecs deja implementes (En gros, demerdez-vous entre vous, les premiers
arrives sont les premiers servis, et faites vos recherches quand vous
debarquez ; pas genial si vous utilisez Ogg pour un format de flux que
vous ne publiez pas, en cas de collision avec un nouveau format de flux
que vous voulez gerer dans votre bibliotheque/appli, vous devez changer
vos specs, docs, etc. internes... Yavait qu'a publier, sauf si c'est
militaire mais CHUUUT ! La ou ca devient marrant, c'est quand vous devez
utiliser dans une meme appli deux formats de flux developpes chacun en
secret et que vous devez vous debrouiller pour imposer a l'une des deux
equipes le changement).

Xiph fournit le moyen d'identifier le Vorbis, le Theora, et y fait
explicitement reference dans la RFC (a verifier mais j'en suis a peu
pres sur).

Conclusion : l'encapsulage du XVid dans le Ogg n'ayant pas (a ma
connaissance) ete normalise, c'est (a ma connaissance) crade.

>     D'ailleurs, rien n'empêche de créer une vidéo contenant :
>     - une piste vidéo en theroa (libre au sens que Xiph l'entend)
>     - une piste audio en ogg/vorbis (libre au sens que Xiph l'entend)
>     - dans le conteneur ogm de Tobias (libre, puisqu'à priori non soumit à
> des brevets).
>     Le contenu final ne devant pas choquer Xiph

Ooouh la la, libre puisqu'a priori non soumis a des brevets... On va
passer sur cette formulation hasardeuse :)

Le contenu final ne choquera pas Xiph, surtout que dans ce cas, c'est
tout autant de l'OGM que du Ogg (Je considere les fichiers OGM comme un
sur-ensemble des fichiers Ogg, demontrez-moi le contraire... Ah oui, la
charge de la preuve incombe a celui qui avance, zut).

>     Ce qui ennuies Xiph dans cette affaire, c'est que le ogm de Tobias
> permet de lier un flux MPEG4 (DivX, Xvid, etc, soumit à des brevets),
> avec du ogg/vorbis qui lui est libre de brevets. C'est l'unique problème.

C'est surtout que le mec qui a fait OGM s'est demerde pour qu'on puisse
utiliser n'importe quel format de flux disposant d'un plugin DirectShow
dans "leur" format, sans reellement normaliser : il utilise le FOURCC,
boulet qu'on se traine en video grace a Apple, repris par Microsoft, et
gere par... personne.
Ca se verifie notamment dans les sources de oggdsf[2].

Et une des seules references aujourd'hui pour les FOURCC, c'est...
Microsoft[3]. Mouarf.

Ceci etant dit, pour m'etre tape du code manipulant du Ogg, c'est un
"joli" format pour gerer des flux (sauf qu'il delegue la temporisation,
il se contente de restituer les flux sequentiellement, i.e. sans mettre
dans le desordre les segments ; un truc marrant du coup, c'est que quand
on fait du "grouping", c'est-a-dire qu'on multiplexe plusieurs flux
"simultanes", on peut faire prendre de l'avance a un flux sur un
autre... Pour une video avec du son par exemple, la librairie Ogg te
laisse te demerder pour maintenir ce qui se passe en meme temps a peu
pres au meme endroit dans le fichier). C'est tres logiquement valable
pour OGM, puisque ca "marche pareil".

Refs foireuses :
[1] http://xiph.org/ogg/doc/rfc3533.txt
[2] OGMDecodeInputPin::handleVideoHeaderPacket(OggPacket* inHeaderPack)
http://svn.xiph.org/trunk/oggdsf/src/lib/codecs/ogm/filters/dsfOGMDecoder/OGMDecodeInputPin.cpp
Depechez-vous, c'est du SVN, ca change ! Enfin leeentement...
[3]
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/registeredfourcccodesandwaveformats.asp

--
Geoffroy Carrier
http://sitlib.org/