Il y a désormais plus de deux ans que le groupe de travail codec de l'IETF avait commencé un effort inédit de spécification d'un codec audio libre. Ce nouveau RFC, le 6716, est le couronnement de cet effort : Opus, le codec standard et libre est désormais officiel.
Journal Le codec audio libre Opus désormais normalisé
11
sept.
2012
# basse latence ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 7.
Est-ce que c'est le codec basse latence développé par la fondation à l'origine de Vorbis ?
"La première sécurité est la liberté"
[^] # Re: basse latence ?
Posté par liberforce (site web personnel) . Évalué à 5.
Il semble que oui. D'après Wikipédia c'est Xiph.org et Skype qui en sont à l'origine:
Opus_Interactive_Audio_Codec
[^] # Re: basse latence ?
Posté par Thomas Debesse (site web personnel) . Évalué à 4.
Ah bien ! J'utilise déjà CELT pour le boulot, j'avais repéré Opus mais je n'avais pas trop compris le lien entre CELT et Opus, si c'était une alternative qui réinvente la roue sur le même créneau, ou pas. Puisque Opus est normalisé, je suppose qu'il faut comprendre que CELT restera toujours un codec expérimental et qu'Opus peut être considéré comme la normalisation de CELT, et qu'à l'avenir on pourra remplacer facilement CELT par Opus, comme si on passait à une nouvelle évolution de CELT ?
J'ai choisi CELT parce qu'il était simplement disponible dans les dépôts, on peut supposer qu'il sera peu à peu remplacé par Opus ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: basse latence ?
Posté par liberforce (site web personnel) . Évalué à 6. Dernière modification le 11 septembre 2012 à 13:40.
A priori Opus a pour vocation d'être plus flexible que CELT, mais je n'ai pas vu dans l'article sur la cohabitation ou l'obsolescence de CELT.
[^] # Re: basse latence ?
Posté par Adrien . Évalué à 5.
Le site web de CELT l'indique : http://celt-codec.org/
[^] # Re: basse latence ?
Posté par vrm (site web personnel) . Évalué à 2.
pour faire court Opus c'est silk (codec skype) pour le bas débit (voip) et CELT pour la musique (haut débit)
[^] # Re: basse latence ?
Posté par liberforce (site web personnel) . Évalué à 4.
Pour info, il y a eu une conf sur Opus lors de la GStreamer Conference 2012: voici les slides et la vidéo.
# Opus n'est pas un format de fichiers, comme MP3.
Posté par cosmocat . Évalué à 5.
Si j'en crois le liens du journal "Opus n'est pas un format de fichiers, comme MP3".
C'est à dire que le flux audio ne peut pas être stocké dans un fichier au format opus?
Donc si on veut streamer un flux, il faut transcoder?
Et on ne peut pas bénéficier des avancées de ce codec pour avoir une meilleure qualité ou des fichiers plus petits?
Il ne concurrence pas Ogg Vorvis?
Cette petite phrase m'intrigue beaucoup…
Ou alors il voulait dire qu'Opus doit être stocké dans un conteneur (Ogg ou matroska). Je ne sais.
Si y'en a qui en savent plus…
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
C'est un codec de streaming, donc temps réel, pour faire de l'audio ou de la vidéo-conférence. L'objectif est d'avoir une bonne qualité audio pour de la conf orale avec un débit des plus faibles. Dans le temps, on avait le G711…
C'est pas à mon sens un codec pour compresser de la musique, le résultat ne sera pas au rendez-vous.
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par cosmocat . Évalué à 7.
C'est pas à mon sens un codec pour compresser de la musique, le résultat ne sera pas au rendez-vous
Pourtant Opus truste le haut du pavé :
http://opus-codec.org/comparison/
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Exact… J'étais resté sur un post que j'avais lu il y a une quinzaine ou c'était surtout la comparaison avec speex qui prenait le dessus.
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
le haut du pavé en dessous de 128kbs, il faudrait avoir le graphique jusqu'à 300.
"La première sécurité est la liberté"
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par vrm (site web personnel) . Évalué à 2.
ben non vu que c'est un test d'écoute et que la courbe va arrêter de progresser.
tu peux toujours chercher a comparer avec ton oscillo :)
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Tout le monde est capable de faire la différence entre un mp3 128k et un mp3 160 ou 256Kbs, donc je pense que l'on peut pousser un peu plus loin l'expérience. Il suffit d'avoir un système audio de test suffisamment haut de gamme.
"La première sécurité est la liberté"
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Zenitram (site web personnel) . Évalué à 9.
Non (même avec un bon système audio), surtout avec un bon encodeur (Lame etc).
Je ne veux pas dire que ce n'est pas important d'aller plus haut, mais non, ce n'est pas tout le monde qui peut entendre la différence, loin de la. Il faut former l'oreille, et ne pas écouter "n'importe quoi" (parce que souvent, c'est la source elle-même qui est déjà merdique :) ).
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par vrm (site web personnel) . Évalué à 1.
franchement ca m'étonne fortement. je suis plutôt d'accord avec zenitram.
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par arnaudus . Évalué à 4. Dernière modification le 12 septembre 2012 à 11:02.
Ah ah, le mythe du mec qui arrive à voir ou entendre des différences imperceptibles, et qui en plus n'arrive pas à supporter les encodages avec pertes. À ranger du côté de l'oreille musicale absolue…
Si 1% des gens sont capables de percevoir des différences sur 1% du matériel, on se retrouve dans un cas hyper-minoritaire qui ne peut être considéré que comme "spécialisé" ou "professionnel". Aucun intérêt pour le grand public.
Il faut aussi réaliser à quel point les limites de la technologie conditionnent notre perception de la "perfection". Si on est habitués à une qualité faible, on s'en contente, et on n'a pas de problème de confort (c'est par exemple le cas au cinéma, malgré une fréquence de rafraichissement de l'écran assez faible). Il y a de toutes manières des cas qui sont insolubles, et les crétins qui prétendent être gênés par la dissonnance des accords dans la musique moderne (gamme à tempérament égal) ne peuvent que souffrir toute leur vie, tant pis pour eux.
Enfin, d'après mon expérience personnelle, il est vrai qu'une fraction de la population a des capacités de perception hors du commun, mais que ceux qui se plaignent des défauts de telle ou telle technologie n'en font jamais partie.
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Alex . Évalué à 1.
moi je perçois des différences, surtout lié à l'utilisation de matériel bas de gamme, et je suis loin d'avoir les oreilles de superman
exemple purement perso: j'écoute des podcasts dans ma caisse (de la voix). En dessous de 128, ça grésille assez régulièrement, au dessus, non
A l'inverse, et là je suis d'accord avec toi, sur mon casque ou sur une chaine hifi, je ne perçois pas vraiment de différences.
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 12 septembre 2012 à 11:32.
Engueule les mecs qui encodent, car du grésillement à 128 Kbps, ce n'est pas la faute du format, quel qu'il soit… Trop facile d'accuser le débit sans preuve autre que "j'ai pris deux trucs différents, je ne sais pas ce qui a changé, mais c'est sûr c'est la faute du débit".
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Alex . Évalué à 2.
ce que je disais, c'est que c'est lié en partie au matos
j'ai fait des essais persos (c'est pour ça que j'affirme ça, j'ai pas de podcasts à plus de 128), de ma voix encodé avec le kioslave de kde (lame ?) en 96/128/256/320, le problème n'apparait que dans les 2 premiers cas
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Alex . Évalué à 2.
et pour être plus précis, ce problème ne se produit que dans ma caisse et en dessous des 128, au casque via mon téléphone cela ne se produit pas
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
On voit bien que les HF sont coupés assez vite. Un adulte normal entend bien jusqu'à 18khz, les enfants au delà. Donc avec une coupure à 15khz, selon le morceau, tout le monde peut entendre la différence.
Il suffit d'écouter quelques choses ayant de aigüe pour l'entendre (voix, violons, musique électronique "cristalline").
Je suis aussi d'accord que le problème des 128kbs est de ne pas être encodé par Lame, ce qui peux faire une sacré différence.
"La première sécurité est la liberté"
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par liberforce (site web personnel) . Évalué à 7.
C'est en effet pour du streaming, le but à atteindre étant la faible latence. Mais il est possible de transmettre de la musique de cette manière, le codec ayant été étudié pour s'adapter à la bande passante nécessaire. La partie d'Opus inspirée du codec Silk gère la voix, la partie inspirée de CELT gère la musique.
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par mickabouille . Évalué à 10.
Il est prévu que ça se retrouve dans du ogg à la place du vorbis, voir
http://wiki.xiph.org/OggOpus
pour l'original, remplacé par
http://tools.ietf.org/html/draft-terriberry-oggopus-01
C'est un des usages prévus.
C'est une des possibilités.
Opus utilise 2 codecs différents (plus un mode hybride) précisément pour couvrir le spectre le plus large possible, de la voip à la hi-fi.
Le seul usage explicitement exclus est le lossless.
(Cela dit, je n'y connais rien, je ne fais que rapporter ce que je lis :p)
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Zenitram (site web personnel) . Évalué à 5.
En fait la phrase ne veut absolument rien dire (surtout : il se trompe, si il les les commentaires…)
MP3 = MPEG Audio Layer 3. C'est une format audio, comme Opus, point. Ce n'est pas un "format de fichier". C'est même utilisé en transmission satellite avec des "live", si si!
Ce n'est pas parce qu'un dump de MPEG Audio est synchronisable que ça en fait un "format de fichier". Ca en fait juste un format audio synchronisable sans couche de synchronisation (par exemple, AAC n'est pas synchronisable non plus, exactement comme Opus, il lui faut ADIF, ADTS ou LATM pour la synchro, ou ont peut jouer avec du Out of Band contenant les données d'init si on sait faire du out of band. bref, Opus n'a rien inventé, c'est un format audio comme les autres).
Ca n'enlève pas le pourquoi Opus est prévu : de la bande passante faible, du temps réel, et être sans brevets. Sur la papier, c'est super-méga-extra-ordinaire, ça fait tout mieux que les autres, attendons de voir… Car le dernier qui a dit ça c'est révélé être assez mauvais (d'ailleurs, la façon de présenter la spec est exactement pareil, par code source, même façon de faire même résultat? Oui, je parle de WebM qui se voulait surpuissant et finalement s'est révélé très très bof et la sauce n'a pas pris)
Ou utiliser le framing optionnel (Appendix B). Ceci-dit, ce n'est pas unique à Opus, c'est juste de la config (AAC, ou H264 ont la même possibilité de se passer de couche de synchro, rien de nouveau, ça dépend si tu as besoin de synchro ou pas)
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par Moonz . Évalué à 4.
Je ne me souviens pas que qui que ce soit ait jamais prétendu que WebM soit plus performant (du point de vue qualité/débit) que H.264, encore moins avec des vrais tests derrière. Là on a quand même les tests d’écoute d’HA qui donnent des résultats vraiment enthousiasmants.
[^] # Re: Opus n'est pas un format de fichiers, comme MP3.
Posté par gnuzer (site web personnel) . Évalué à 2.
VP8 (parce que c'est comme ça que le codec vidéo s'appelle : WebM ce n'est pas le codec, c'est le conteneur qui embarque du VP8 et du vorbis, et qui est effectivement merdique) se situerait entre H264 baseline et H264 main profile en terme de rapport qualité/compression. Bien qu'il demeure en-dessous de H264 high profile, il s'agit sans nul doute du codec video libre et ouvert qui possède le meilleur rapport qualité/compression.
# Une bonne nouvelle n'arrive jamais seule
Posté par rakoo (site web personnel) . Évalué à 2.
Aaaah. Ce codec annonce de grande choses sympathiques pour la diffusion temps-réel, et, top cool, quelques entreprises ont pensé à nous :
Bien, donc si on veut implémenter dans notre coin, il va nous falloir demander l'avis de ces dépositaires pour diffuser. Super.
[^] # Re: Une bonne nouvelle n'arrive jamais seule
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 4.
D'abord, la plupart des ces brevets sont illégaux en Europe. Donc, il suffit de ne pas voyager ou vendre aux USA ou en Chine (l'autre pays du brevet futile) pour être tranquille.
Ensuite, même aux USA, rien ne dit que ces brevets tiennent le coup devant un tribunal. Il suffit donc d'embaucher plusieurs avocats et de faire annuler ces brevets. Fastoche.
Sérieusement, l'IETF publie les revendications de brevet, elle n'évalue pas leur mérite.
[^] # Are you sure ?
Posté par Kurtnoise . Évalué à 1.
http://www.opus-codec.org/license/
[^] # Re: Are you sure ?
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 2.
La licence choisie par les développeurs d'Opus n'a aucune importance. Les brevets sont détenus par des tiers (comme Microsoft) et ceux-ci n'ont aucune raison de se sentir liés par une licence qu'ils n'ont pas écrite.
[^] # Apparemment, t'as pas tout lu...
Posté par Kurtnoise . Évalué à 0.
Une partie des développeurs appartient à la fondation Xiph qui elle même détient des brevets de ce codec…donc, si, il y a un lien.
[^] # Re: Une bonne nouvelle n'arrive jamais seule
Posté par goom . Évalué à 1.
Etonnant de mettre la Chine parmi les défenseurs des brevets. J'avais plutôt dans l'idée que la Chine était connue pour être un pays laxiste en matière de PI.
[^] # Re: Une bonne nouvelle n'arrive jamais seule
Posté par Larry Cow . Évalué à 7.
Seulement avec la PI des autres : avec la leur ils sont beaucoup plus stricts, à ce qu'on dit.
[^] # Re: Une bonne nouvelle n'arrive jamais seule
Posté par Stéphane Bortzmeyer (site web personnel, Mastodon) . Évalué à 3.
Tous les pays sont dans ce cas. La plupart des entreprises états-uniennes ne cherchent même pas dans la base des brevets chinois pour voir s'ils n'en enfreignent pas un.
[^] # Re: Une bonne nouvelle n'arrive jamais seule
Posté par claudex . Évalué à 3.
Sauf que c'est de moins en moins le cas avec la part de marché croissante de la Chine.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Une bonne nouvelle n'arrive jamais seule
Posté par Misc (site web personnel) . Évalué à 4.
De ce qu'on m'a expliqué, le souci est que même dans ton bon droit, ça coute vachement cher d'aller au tribunal juste pour montrer que tu n'as rien fait.
[^] # Re: Une bonne nouvelle n'arrive jamais seule
Posté par zebra3 . Évalué à 2.
Mais si tu gagnes le procès, c'est au plaignant de payer tes frais, me semble-t-il ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Une bonne nouvelle n'arrive jamais seule
Posté par Buf (Mastodon) . Évalué à 6.
En général, oui. Le problème, c'est qu'il faut quand même avancer l'argent, et avoir les moyens d'attendre la fin du procès avant de récupérer sa mise.
Pour une petite entreprise ou un privé, même à 100% dans son bon droit, ça reste un risque potentiellement important.
[^] # Re: Une bonne nouvelle n'arrive jamais seule
Posté par Zenitram (site web personnel) . Évalué à 6.
Dans la vraie vie, le plaignant fait ensuite souvent faillite, et tu peux toujours rêver pour te faire rembourser (des sous qu'il faut déjà que tu avances, et ce n'est pas petit), donc au final :
- Petite boite qui t'attaque, elle fera faillite ensuite car si elle t'attaque c'est qu'elle n'a plus rien à vendre.
- Grosse boite qui t'attaque, le fric à avancer pour te défendre va te faire très mal, et le remboursement est très partiel.
Bienvenue dans la vraie vie :(.
[^] # Re: Une bonne nouvelle n'arrive jamais seule
Posté par Adrien . Évalué à 2.
Il me semble que c'est le juge qui décide si le perdant paye sa tournée… du coup tu peux très bien de lancer dans une coûteuse bataille juridique, gagner, mais avoir tout de même des frais à payer.
# écriture de spec
Posté par Nicolas Boulay (site web personnel) . Évalué à 7. Dernière modification le 11 septembre 2012 à 14:49.
L'idée de ce choix « le code est la norme » était que l'alternative (faire une spécification en langue naturelle, complète et sans ambiguité), serait bien plus de travail et, dans le cas particulier d'un codec audio, serait peut-être même irréaliste.
C'est intéressant comme manière de faire. Dans le domaine aéronautique, le principe est de raffiner les spec de manière successive avec la traçabilité, qu'il faut, entre les couches de HLR.
L'avantage du code est d'être formalisé et vérifié par un compilateur, le désavantage est de n'être pas très lisible.
Dans le domaine ferroviaire, il me semble qu'il double le développement. Le code est développer 2 fois par 2 équipes et les résultats doivent converger.
Est-ce qu'il ne serait pas sain de réécrire le codec dans un langage de haut niveau pour vérifier qu'il n'y a pas trop de variable magique fausse ? Par contre, il faudrait partir au moins d'une pseudo spec, pour éviter de partir des bugs du 1er code :)
"La première sécurité est la liberté"
# Détente...
Posté par Mathieu . Évalué à -6.
J'ai tout de suite pensé à ça :)
# Ce qui me surprend...
Posté par Zenitram (site web personnel) . Évalué à 9.
… Est que ça ne vous fasse pas bondir que la spec soit du code source? En base64 dans la RFC, c'est fort.
Ca s'annonce mal, car l'expérience des gens qui font des specs vidéo et audio depuis longtemps fait qu'on a plusieurs encodeurs et decodeurs créés avant de sortir la spec, afin de confronter la réalité à la théorie, afin de confronter les points de vues. Ici, un code source sert de référence, et si il y a un bit qui est laissé "random" à cause d'un bug de l'encodeur, on est mal! Un code source n'est jamais une spec!
"eh c'est trop chiant de faire une spec HTML, et si on balançait le code source?" sera la prochaine étape. Qui sera choisi? (Gecko ou Webkit? Mystère…).
[^] # Re: Ce qui me surprend...
Posté par gnuzer (site web personnel) . Évalué à 2.
C'était aussi le cas pour VP8 y'a pas si longtemps (RFC 6386).
[^] # Re: Ce qui me surprend...
Posté par reno . Évalué à 2.
Moi, ça me fait tiquer très fortement, enfin ce serait du code façon "literate programming" je n'aurais pas de problème, mais là l'article parle de valeur magiques dans le code, du code censé servir de spec, beurk!!!
# MPEG2 Transport Stream
Posté par superna (site web personnel) . Évalué à 1.
Salut,
Est-ce que l'IETF va normaliser l'encapsulation dans du MPEG2 TS (DVB ou ATSC qu'importe) et lui attribuer un stream_id et un descripteur ?
Car un codec audio qui s'ajuste selon la bande passante disponible et qui se débrouille bien en bas débit ET qui est résistant à la perte de packet ET en plus que le décodeur est déjà en Fixed Point ET qu'il ne dépends par d'un conteneur comme vorbis, perso ça m'intéresse dans la TV numérique ;-)
[^] # Re: MPEG2 Transport Stream
Posté par Kurtnoise . Évalué à 0.
Seul l'avenir nous le dira…mais l'attribution d'un identifiant + descripteur n'est pas suffisant. Exemple : Dirac.
PS: le vorbis n'est pas un conteneur. Simplement un format audio.
[^] # Re: MPEG2 Transport Stream
Posté par superna (site web personnel) . Évalué à 1.
jamais dit le contraire ;-)
mais vorbis dans les faits (dans le code de libvorbis) dépends fortement de Ogg…
[^] # Re: MPEG2 Transport Stream
Posté par mickabouille . Évalué à 4.
Tellement qu'on ne peut pas le mettre dans du mkv pour faire un fichier webm.
[^] # Re: MPEG2 Transport Stream
Posté par Zenitram (site web personnel) . Évalué à 3. Dernière modification le 12 septembre 2012 à 11:35.
Pas besoin de stream_id enregistré (AC-3 n'en a toujours pas! Dès que tu sors de MPEG, dur d'avoir un stream_id officiel), suffit de fournir un descripteur privé. Mais bon, je n'ai rien vu passer encore à ce sujet (faut pas trop en demander :) ), donc ça va être le bordel avec tout le monde qui va faire sa bidouille faute de code fourni par les mecs qui font Opus, grrr…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.