jeudi 10 avril

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Astuces :: Suivi :: RDF

Articles précédents : Logiciel

Liens connexes

Schrödinger (755 hits)
Dirac (497 hits)
Dirac à la BBC (253 hits)
LinuxFR.org : La BBC libère ses travaux sur le codec vidéo Dirac (404 hits)
liboil (227 hits)

Dépêche modérée par

mouns

Dépêche éditée par

Nyco

Logiciel : Schrödinger 1.0 : le codec Dirac est prêt

Posté par Nÿco (Jabber id, page perso, ). Modéré le 07 mars 2008.

En janvier 2003, la BBC (British Broadcasting Corporation), la radio et télévision publique britanique, célèbre pour ses programmes de qualité, a commencé des travaux sur un codec vidéo nommé Dirac, puis diffusé le tout sous licence libre sur SourceForge en mars 2004.

Le codec Dirac est basé sur les ondelettes (wavelets en anglais), sans brevet, permet des résolutions allant de 176x144 (QCIF) à 1920x1080 (HDTV), en progressif ou entrelacé, une compression double et une meilleure qualité (presque sans perte) par rapport au MPEG2.

Le samedi 23 février 2008, c'est la version 1.0 des bibliothèques Schrödinger qui ont été publiées, implémentation de Dirac basée sur les spécifications finalisées les 21 (DiracPro 1.0) et 24 (2.1) janvier 2008.

Les bibliothèques Schrödinger sont des composants de codage et décodage (dépendants de la bibliothèque libre liboil), développés en C par David Schleef, BBC Research and Development et Fluendo, comportant des optimisations en assembleur, un plugin GStreamer, un mapping pour conteneur au format Ogg à l'aide de la fondation Xiph et une proposition de mapping pour conteneur MPEG-TS.

Schrödinger est publié sous quadruple licence : MPL 1.1, LGPLv2, GPLv2 et MIT. La standardisation complète de Dirac par SMPTE (Society of Motion Picture and Television Engineers) est prévue pour cette année, en tant que VC-2. Les codecs audio conseillés pour accompagner un flux Dirac sont le Vorbis et le FLAC.

Erwin Schrödinger et Paul Dirac sont deux physiciens qui ont obtenu un prix Nobel conjoint en 1933.

Schrödinger (755 hits)
Dirac (497 hits)
Dirac à la BBC (253 hits)
LinuxFR.org : La BBC libère ses travaux sur le codec vidéo Dirac (404 hits)
liboil (227 hits)

> Lire la dépêche (65 commentaires, moyenne: 4).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

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

[+] Question bête (comme d'hab' quoi)

Posté par Tux_Beginner (page perso, ) le 07/03/2008 à 20:02. (lien). Évalué à -3.

Ca nous fait un nouveau codec audio libre ?
Il faut le comparer ogg / flac ou a speex (voix) ?

--
~[Chez Wam]~

[^]Re: Question bête (comme d'hab' quoi)

Posté par Sébastien ANDRE () le 07/03/2008 à 20:09. (lien). Évalué à 4.
Attention le codec DIRAC n'est un nouveau codex audio, mais un codec VIDEO.

Par contre, je suis curieux de savoir pourquoi ils ont développé un nouveau codec et non utilisé ce qui existe comme Divx ou Xvid.
Mais à première vue, ils cherchaient quelque chose sans aucun brevet possible.

Il faut maintenant voir ce que donne ce codec sur la qualité des vidéos compressées.
- [^]Re: Question bête (comme d'hab' quoi)
  
  Posté par Tux_Beginner (page perso, ) le 07/03/2008 à 20:16. (lien). Évalué à 2.
  Attention le codec DIRAC n'est un nouveau codex audio, mais un codec VIDEO.
  
  Oups >.<
  J'ai lu trop vite, mes excuses.
  
  --
  ~[Chez Wam]~
- [^]Re: Question bête (comme d'hab' quoi)
  
  Posté par verdesroches (page perso, ) le 07/03/2008 à 21:36. (lien). Évalué à 7.
  En fait, ce codec exploite la techno d'encodage en ondelettes, qui était notamment utilisé dans... JPEG-2000, format de fichier photo qui promettais une qualité d'image inégalée tout en conservant une taille de fichier convenable. Ce format est finalisé depuis de nombreuses années, mais n'as jamais réussit à s'imposer, et seuls quelques logiciels très rares le gèrent (a ma connaissance, il y a xNview, qui est capable de le lire et de l'écrire, mais du coté proprio, et même Photoshop ne peut le gérer que via un plugin si mes souvenirs sont bons, comme quoi, ce format à tout fait, sauf ce que nous avait dit le Join Picture Expert Group, qui prétendais que ce format était l'avenir et qu'il allais se démocratiser rapidement).
  
  Pourtant, cette technologie d'encodage par ondelette est vraiment très puissante. Si ce format Dirac se démocratise un tant soit peux, alors je pense que je l'utiliserais volontiers.
  - [^]Re: Question bête (comme d'hab' quoi)
    
    Posté par Matthieu C () le 07/03/2008 à 21:56. (lien). Évalué à 10.
    Pour JPEG-2000, les brevets pesant dessus n'ont pas aidé...
  - [^]Re: Question bête (comme d'hab' quoi)
    
    Posté par christian sahastume () le 08/03/2008 à 14:39. (lien). Évalué à 10.
    Bonjour,
    
    Je vous lis beaucoup mais n'intervient que très rarement (la peur de dire des bêtises peut-être :)
    
    Je rebondis sur ce fil qui traite du format de compression par ondelettes pour vous rappeler qu'il existe djvulibre, un format équivalent fourni dans toutes les distributions si je ne m'abuse.
    
    Avec le paquet djvulibre, vous trouverez un binaire qui se nomme c44 et donne des résultats surprenants. Faites le test suivant:
    
    - Prenez un fichier raw issu de votre APN,
    - Enregistrez-le au format PPM via Ufraw (exemple ici: Photo1.ppm -> 110Mo)
    
    Maintenant faisont un test comparatif:
    - convert Photo1.ppm Photo1.jpg -> donne un jpeg de 4.8 Mo
    - c44 Photo1.ppm -> donne un fichier djvu de 480 ko (visible avec djview ou un plugin disponible pour votre naviagteur internet, donc c'est un format idéal pour la diffusion sur le web).
    
    Je ne vois pas de différences flagrantes entre les deux images affichées, mais le poids (10 fois moindre) du format djvu est évoquateur.....
    
    Certes, je ne possède aucune compétence technique pour juger de la qualité des images obtenues, je voulais simplement mettre en lumière ce format qui me paraît trop confidentiel alors qu'il mériterait d'être plus diffusé (avis personnel bien sur :)
    
    Désolé d'avoir détourné le sujet principal.....
    - [^]Re: Question bête (comme d'hab' quoi)
      
      Posté par seginus () le 08/03/2008 à 22:58. (lien). Évalué à 5.
      Tu es pardonné (mais que cela ne se reproduise pas !)
      
      J'ai déjà vu se format qui m'avait l'air en effet prometteur
      De mémoire (je n'ai pas refait de recherche), c'est un peu aussi un concurent du pdf (plusieurs pages dans un même fichier) qui est très intéressant et surtout utilisé pour la numérisation de document manuscrit dans lequel il apporte un très grand gain de compression pour une très bonne qualité.
      
      Quand au pourquoi de sa non-adoption, cela reste pour moi sans réponse.
      - [^]Re: Question bête (comme d'hab' quoi)
        
        Posté par seginus () le 08/03/2008 à 23:05. (lien). Évalué à 6.
        Je rajoute un lien vers un document d'exemple trouvé sur wikisource :
        
        http://upload.wikimedia.org/wikipedia/commons/b/b5/True_stor(...)
        
        Ceci est un livre scanné :
        — Nombre de pages : 426,
        — Taille du fichier : 1.3 Mo
        
        Je pense qu'il manque à être connu, surtout pour l'archivage de documents scanné.
        merci de m'avoir fait connaître la commance c44, je vais pouvoir faire une bonne compression par lot !
        
        [^]Re: Question bête (comme d'hab' quoi)
        
        Posté par Grégoire G (Jabber id, page perso, ) le 09/03/2008 à 17:04. (lien). Évalué à 3.
        J'ai juste ajouté le plugin djvu avec aptitude.
        
        Je n'ai même pas relancé mon navigateur... c'était déjà pris en compte.
        
        Ce format (djvu) est tout simplement génial.
        
        J'espère qu'il y a un plugin pour le PHP.
    - [^]Re: Question bête (comme d'hab' quoi)
      
      Posté par Yusei (page perso, ) le 09/03/2008 à 12:15. (lien). Évalué à 2.
      En quoi le fait que ce soit affichable avec un plugin rend-il ce format "idéal pour la diffusion sur le web" ?
      - [^]Re: Question bête (comme d'hab' quoi)
        
        Posté par christian sahastume () le 09/03/2008 à 13:54. (lien). Évalué à 6.
        Je ne trempe dans le milieu de l'info, et je vais peut-être dire une ânerie...
        
        Si une image jpeg pèse 4Mo et que la même image en djvu ne fait que 400ko, je me dis que pour la même utilsation de bande passante (ou quantité de donnée diffusée dans les tuyaux), je peux afficher 10 fois plus d'image sur mon écran.
        
        En effet, pour l'instant le djvu n'est accessible que par le biais d'un plugin. Mais je m'autorise à penser que ce format pourrait-être directement pris en compte par le navigateur, on verrait alors fleurir quantité de média (galleries d'images par ex) diffusé dans ce format.
        A noter que ce gain de compression peut aussi s'appliquer au rempalcement du PDF. (c'est le rôle du binaire djvudigital fourni avec le paquet djvulibre + recompilation des sources de Ghostscript>
        
        Je sais que les débits de connexion et et la taille des disques augmentent sans cesse, mais il suffit d'imaginer toutes les images et les PDF du Web passer en djvu pour extrapoler le gain de place et l'économie de transfert de données pour la même service rendu aujourd'hui.
        
        Ce n'est qu'une idée cependant.....
        
        [^]Re: Question bête (comme d'hab' quoi)
        
        Posté par Yusei (page perso, ) le 09/03/2008 à 16:02. (lien). Évalué à 4.
        Ce qui m'avait surpris était l'implication "visible par un plugin, donc bien pour le web". Tant que le format n'est pas géré nativement par les navigateurs les plus répandus, il ne faut pas espérer l'utiliser dans des pages web. Il n'y a qu'à regarder le taux d'adoption du SVG.
        
        Mais si tu voulais dire "ça compresse bien, donc ça serait bien pour le web", là je suis évidemment d'accord.
        
        [^]Re: Question bête (comme d'hab' quoi)
        
        Posté par gpe () le 09/03/2008 à 17:19. (lien). Évalué à 8.
        Tant que le format n'est pas géré nativement par les navigateurs les plus répandus, il ne faut pas espérer l'utiliser dans des pages web. Il n'y a qu'à regarder le taux d'adoption du SVG.
        
        Il n'y a qu'à regarder le taux d'adoption du Flash ...
        
        [^]Re: Question bête (comme d'hab' quoi)
        
        Posté par Yusei (page perso, ) le 09/03/2008 à 18:48. (lien). Évalué à 1.
        La dernière fois que j'ai installé un IE, Flash était livré avec donc, même si techniquement c'est un plugin, ça reste supporté de base, sans démarche particulière de l'utilisateur.
        
        Après, on peut se demander pourquoi ce plugin là en particulier s'est imposé au point d'être fourni d'office, mais c'est parce qu'il comblait un manque à l'époque.
        
        [+] [^]Re: Question bête (comme d'hab' quoi)
        
        Posté par gpe () le 10/03/2008 à 00:36. (lien). Évalué à -5.
        Si ta vision du navigateur Web se limite à IE ...
        
        [^]Re: Question bête (comme d'hab' quoi)
        
        Posté par regdub () le 10/03/2008 à 10:07. (lien). Évalué à 4.
        "convert" utilise une qualité de 100 par défaut, mais pour du web on peut prendre 85 ou moins.
        
        Sur une de mes photos d'environ 1 Mpx, la version jpeg qualité 85 fait 436 Ko contre 254 Ko pour la version djvu, mais la version djvu contient moins de détails que la version jpeg.
        
        Les options de c44 pour augmenter la qualité sont un peu techniques et il y a des chances qu'en augmentant la qualité, la différence de taille soit bouffée en grande partie.
    - [^]Re: Question bête (comme d'hab' quoi)
      
      Posté par Zenitram (page perso, ) le 09/03/2008 à 20:04. (lien). Évalué à 8.
      alors qu'il mériterait d'être plus diffusé
      
      ...Faudrait qu'il le veuille aussi.
      Je vais sans doute faire hurler les pro-GPL, mais quand on veut qu'un format s'impose, soit on a la force commerciale de Adobe, soit... On propose une implémentation utilisable telle quelle par les softs proprio.
      Et la GPL n'y aide pas.
      Djvulibre est sous GPL, donc un soft proprio qui veut l'implémenter doit se taper tout le boulot d'implémentation. Vu le ROI sur le sujet, ben... Il ne fait pas, et le format reste confidentiel. Et un format sans support des "gros" outils d'imagerie (désolé : qui sont non GPL!!!), c'est pas gagné...
      
      De même, la licence du plugin Djvu pour Firefox que j'ai téléchargé me semble tout sauf libre. Il sera à jamais (sauf changement de licence) impossible de l'intégrer à Firefox ou Khtml ou autre projet libre.
      
      Pour la licence du format, je ne vois pas dans le fichier de spécification http://www.djvu.org/docs/DjVu3Spec.djvu un mot sur la licence du document, ou sur la protection contre les brevets (désolé, mais les brevets existent, il faut donc y faire attention). C'est un peu léger.
      
      Ce format me semble plutôt être un outil pour qu'une boite se fasse du fric (c'est pas un reproche, juste un constat), plutôt qu'un format destiné à une large diffusion. Juste un concurrent d'Adobe, mais sans la puissance d'Adobe. Le libre n'a pas grand chose à y gagner de plus que de jouer avec le format PDF, largement répandu et ISO si je ne me trompe pas. Le terrain du format d'archivage est déjà bien pris par PDF, avec une très bonne réputation, pour qu'un format concurrent s'impose il lui faudra bien plus que son 10x moins de poids, malheureusement.
      Corrigez-moi si je me trompe.
      - [^]Re: Question bête (comme d'hab' quoi)
        
        Posté par Jean Boussier (Jabber id, ) le 09/03/2008 à 23:57. (lien). Évalué à 4.
        >De même, la licence du plugin Djvu pour Firefox que j'ai téléchargé me semble tout sauf libre.
        
        Pas si on en croit RMS:
        $ aptitude search djvu | grep plugin i djvulibre-plugin - Browser plugin for the DjVu image format $ vrms | cowsay ___________________________________________ / Non-free packages installed \ | | | ia32-sun-java6-bin Sun Java(TM) Runtime | | Environment (JRE) 6 (32-bit) | | sun-java6-bin Sun Java(TM) Runtime | | Environment (JRE) 6 (architecture | | sun-java6-jre Sun Java(TM) Runtime | | Environment (JRE) 6 (architecture | | | | 3 non-free packages, 0.2% of 1431 | \ installed packages. / --------------------------------------------------------------- \ ^__^ \ (oo)\_______ (__)\ )\/\ ||----w | || ||
        
        [^]Re: Question bête (comme d'hab' quoi)
        
        Posté par Zenitram (page perso, ) le 10/03/2008 à 08:35. (lien). Évalué à 2.
        Tiré du plugin Firefox/Windows (désolé, je suis encore sous ce méchant OS, je suis conscient qu'il n'est pas libre ;-) ) :
        1. (...) Si vous effectuez des copies du Logiciel, Vos copies doivent inclure l'intégralité des fichiers afférents à ce Logiciel sous leur forme originale, y compris et sans limitation, le programme d'installation. Si vous diffusez le Logiciel, vous devez également conserver l'ensemble des fichiers sous leur forme originale et diffuser le Logiciel dans son intégralité tel qu'il peut être obtenu sur le site Web de LizardTech. Dans le cas d'une copie autorisée du logiciel sur un support matériel, (...)
        2. (...) Vous acceptez également de ne pas traduire, décompiler, désassembler, modifier, procéder à une ingénierie inverse ou tenter de toute autre façon de découvrir le code source d'une partie ou de la totalité du Logiciel.
        Ca ne me parait pas très libre... Je passe les autres numéros.
        
        Peut-etre que la version Linux est libre, mais si on veut un format répandu, il faut aussi penser à l'OS répandu sur 95% des gens... Ce n'est pas parce que l'OS est fermé qu'il faut un plugin fermé, surtout que Firefox est multi-Os, donc le code doit être libre sur toutes les plate-formes pour espérer un jour être inclus par défaut. Et pas que GPL, comme je l'ai argumenté précédemment.
        
        [^]Re: Question bête (comme d'hab' quoi)
        
        Posté par j0akim () le 10/03/2008 à 13:02. (lien). Évalué à 3.
        Bon, on s'en fiche tant que la version libre existe et qu'elle permet de décoder les fichiers dans les mêmes conditions que la version commerciale ? Je pense que oui. Quelqu'un portera bien le plugin sous winshit un jour.
        Le djvu c'est une spécification, comme ils ont sorti la spécification dirac, après chacun peut implémenter son codec de compression ou de décompression.
        
        Pour le format microchiotte jpeg-xr, le comité a été très attentif à ce qu'il ne puisse pas y avoir d'entourloupe ou de brevet à royalties pour éviter les soucis du jpeg. (royalty-free commitment de microsoft :/ : http://www.jpeg.org/newsrel19.html
        
        Sinon le format djvu est déjà pas mal utilisé pour les scans de bouquins qui sont en ligne, en effet dans le cas du noir et blanc les résultats sont bien supérieurs aux pdf.
        
        Aussi, on évite avec cet algo le souci classique du jpeg qui fait des carrés et des trames bizarres parfois, ceci à cause de son principe basé sur la transformée de fourier. Sans s'étendre sur les détails, un algo ondelettes aura plus tendance à flouter l'image sans la dégrader comme le jpeg.
        
        J'ai testé le djvu avec la suite libre, ca marche impec sauf dans certaines conditions ou la compression prend un temps qui tend vers l'infini pour une série de pages couleur. Je n'en avais pas parlé aux développeurs mais il faudrait que je le fasse.

Très puissant

Posté par farib () le 07/03/2008 à 20:16. (lien). Évalué à 10.

Une vidéo encodée en Schrödinger contient toutes les vidéos existantes (et à venir) de l'univers. Cette propriété se perd au moment ou on regarde la vidéo ou elle ne contient plus alors ce que l'on vient de voir.

[^]Re: Très puissant

Posté par plic () le 07/03/2008 à 20:31. (lien). Évalué à 10.
Une vidéo encodée en Schrödinger contient toutes les vidéos existantes

Vidéos de chat exclusivement !

--
«La faculté de citer est un substitut commode à l'intelligence» — Sommerset Maugham
- [^]Re: Très puissant
  
  Posté par Tux_Beginner (page perso, ) le 07/03/2008 à 20:33. (lien). Évalué à 4.
  Vidéos de chat exclusivement !
  Il n'y a pas de chat dans ces vidéos !!
  
  --
  ~[Chez Wam]~
  - [^]Re: Très puissant
    
    Posté par baud123 (Jabber id, page perso, ) le 07/03/2008 à 22:25. (lien). Évalué à 3.
    Bientôt la vidéo dans jabber alors ?
  - [^]Re: Très puissant
    
    Posté par Francois Revol (page perso, ) le 09/03/2008 à 11:37. (lien). Évalué à 2.
    Justement si, enfin non, enfin y en a un mais on ne sais pas s'il est toujours vivant ou pas, quand sa mort est déclanchée par la présence de code propriétaire sur l'OS de la personne qui regarde la vidéo :))

[^]Re: Très puissant

Posté par Guillaume Gimenez (page perso, ) le 07/03/2008 à 21:12. (lien). Évalué à 8.
T'es sur que la théorie est bonne ? car j'ai téléchargé bowling for columbine encodé en dirac. Et là ! surprise ! mon chat n'est ni mort ni vif, bien au contraire et la décohérence n'a pas donné le bon film mais "gang bang au bowling" façon RDA pré-89... pfff
- [^]Re: Très puissant
  
  Posté par Thomas Douillard () le 08/03/2008 à 10:41. (lien). Évalué à 2.
  Regarde, tu n'as pas de chat.

Tiens les ondelettes... encore....

Posté par Nicolas BOUTHORS (page perso, ) le 07/03/2008 à 20:36. (lien). Évalué à 3.

Quand on a commencé à parler des ondelettes pour « remplacer JPEG » c'était la révolution, ca allait tout péter et révolutionner le monde. Et puis non finalement... Non.

C'est génial comme principe, mais combien cela coûte-t-il de fabriquer un "ipod Schrïdinger" ou un "Archos Schrïdinger" ? Si c'est 3 centimes de plus parcequ'il faut une nouvelle puce ou une batterie plus grosse, alors ca va finir comme d'habitude : une superbe techno jamais implémentée par l'industrie.

Enfin bon. j'espère me tromper hein.

--
NBI -- Solutions & Développement -- http://nbi.fr

[^]Re: Tiens les ondelettes... encore....

Posté par Jeff_ () le 07/03/2008 à 22:20. (lien). Évalué à 7.
oui et non : comme on l'a dit plus haut, jpeg-2000 était sous le coup de divers brevetsen faisant un format kipuképalibre n'incitant gère les dev de tous poils à l'intégrer.

Ici, le format est ouvert, le codec aussi : aucun coût, donc pas vraiment de contraintes pour l'injecter dans les "balladeurs" existants ou futurs... mais c'est comme d'hab : si personne ne réclame ce format, ne fait de buzz autour... le jour où les balladeurs etc... l'incorporerons ne risque pas d'arriver... en même temps, j'ai du mal à concevoir le fait de voir un film sur un ipod... m'enfin a priori ya des amateurs...

--
"L'informatique, c'est comme le sexe : c'est mieux quand c'est gratuit" [Linus]

[^]Re: Tiens les ondelettes... encore....

Posté par helkyn () le 07/03/2008 à 22:29. (lien). Évalué à 10.
Les ondelettes n'ont jamais eu pour objectifs de remplacer JPEG. C'est un algorithme différent du DCT utilisé par défaut dans l'actuel.

Le gros souci de JPEG, c'est... JPEG. Au départ, la norme (la 10918 j'entends) a eu des écueils, qui ont été constaté bien trop tard:
- aucune notion de lossless
- la DCT s'est révélée être désastreuse dans certaines applications, au niveau qualité d'image (restitution).

JPEG 2000 a capoté pour des raisons d'implémentation: les constructeurs ne se sont pas mis d'accord dessus, et des palliatifs pour le lossless sont arrivés très rapidement (le PNG et le DNG, suivant les objectifs).

Les artefacts de la DCT n'étant pas flagrants sur des photos (mais plus sur des diagrammes), personne n'a éprouvé la nécessité d'évoluer.

Maintenant, ca change: le JPEG-XR de Microsoft, c'est bien JPEG 2000 mais réchauffé. C'est la même chose, le marketing en plus. On s'attaque à Adobe et son DNG.

[^]Re: Tiens les ondelettes... encore....

Posté par Manuel Vonthron (Jabber id, page perso, ) le 07/03/2008 à 23:28. (lien). Évalué à 4.
Mais il s'agit là d'un format libre, et contrairement au JPEG-2000, les développeurs pourront bosser dessus et rendre ce format pérene parce qu'ayant des applications concrètes.

Il est vrai que engouement pour le Ogg Vorbis chez les industriels n'est pas transcendant, mais si les développeurs libres arrivent à tirer quelque chose du Dirac, que des institutions telles que la BBC le soutiennent et qu'il à tant de qualités qu'on veut bien le dire, alors pourquoi les industriels ne s'y mettraient pas ? Ils se sont bien mis au DivX qui avait pourtant la réputation (et l'a toujours un peu à mon avis) de ne servir qu'au piratage de vidéos.
- [^]Re: Tiens les ondelettes... encore....
  
  Posté par helkyn () le 08/03/2008 à 01:04. (lien). Évalué à 0.
  Mais il s'agit là d'un format libre, et contrairement au JPEG-2000, les développeurs pourront bosser dessus et rendre ce format pérene parce qu'ayant des applications concrètes.
  
  1 - On entend tout et son contraire avec format libre.
  
  Si c'est par "format libre de droit", JPEG 2000 l'est, dans sa première part (celle dont tout le monde a besoin pour en écrire un lecteur libre). Les autres parts, elle concerne les extensions, et des procédés industriels pour l'implémenter dans des appareils. Il est tout à fait normal que ces parties là soient protégés par de la propriété industrielle, on est plus dans le logiciel pur et dur ici.
  
  Si par "format libre" on entend "j'en fait ce que je veux", c'est du nawak de libriste. C'est un effort de normalisation entre industriels, avec un man power derrière. Cela a un cout. Aucune norme n'est gratuite. A la limite le document peut être en libre accès, ca ne veut pas dire qu'il ne coute rien.
  
  2 - Le JPEG 2000 a des applications concretes. Me concernant, je le vois passer en permanence pour de l'archivage de photos sur négatifs numérisées pour archivage.
- [^]Re: Tiens les ondelettes... encore....
  
  Posté par Jean Boussier (Jabber id, ) le 08/03/2008 à 09:58. (lien). Évalué à 3.
  >Ils se sont bien mis au DivX qui avait pourtant la réputation (et l'a toujours un peu à mon avis) de ne servir qu'au piratage de vidéos.
  
  Justement les industriels et FAI ont énormément profité du piratage, souvenez vous des pubs oranges qui disait "accédez a toutes la musique que vous voulez" à une époque ou les offres légales même payante n'existaient pas.
  
  Quand les gens vient marqué DivX sur leur lecteur DVD ils se disent : "je pourrait regarder des films pour pas cher"

Qualité ?

Posté par seginus () le 07/03/2008 à 22:36. (lien). Évalué à 5.

Qu'en est-t-il de la qualité ?
De quel codec se veut-il le concurrent ?

Actuellement, le seul format considéré libre semblait être le theora, mais, à moins que ce ne soit du à de mauvais réglages, il ne me semblait pas concurrencer le divx / xvid en thermes de qualités et vitesse d'encodage.
J'ai découvert plus récemment le h264, j'ai trouvé que la qualité avec encore bien augmenté à compression égale (je ne sais pas ce que rend se format côté liberté).

Mais ce codec, qu'en est-t-il ?

PS : il y a peut-être des incohérence de ce que j'ai dit, même si je ne pense pas trop, mais si il y a un domaine qui est bien tordu, c'est la vidéo. Entre les conteneurs / codecs / familles de codecs etc… ça devient dur de s'y retrouver.

[^]Re: Qualité ?

Posté par Frédéric COIFFIER () le 07/03/2008 à 23:00. (lien). Évalué à 4.
Effectivement, il serait intéressant d'avoir un test comparatif par rapport à d'autres codecs en terme de qualité, taux de compression, vitesse de compression/décompression...
C'est peut-être le codec qui pourra enfin remplacer Xvid (celui-ci étant libre mais couvert par des brevets) !
- [^]Re: Qualité ?
  
  Posté par Jacques L. () le 07/03/2008 à 23:51. (lien). Évalué à 2.
  XviD est en bonne voie pour être remplacé par x264, implémentation libre du format H.264, qui est également couvert de brevets.
- [^]Re: Qualité ?
  
  Posté par Kévin FERRARE (page perso, ) le 08/03/2008 à 02:19. (lien). Évalué à 3.
  Dirac a pour l'instant pas l'air très véloce si on en croit wikipedia
  http://en.wikipedia.org/wiki/Dirac_(codec)
  
  "17fps sur un proc à 3Ghz pour une vidéo en 720x576"
  J'espère que ca s'optimise
  - [^]Re: Qualité ?
    
    Posté par Matthieu C () le 08/03/2008 à 09:59. (lien). Évalué à 5.
    Ben essayes la bibliothèque Schrödinger qui est censé être plus optimisée.
    
    Mais bon ça n'empêche pas que ce type de codec (dirac ou snow) sont très gourmand. C'est utile pour de l'archivage sans perdre trop de qualité, pour du realtime ca devient plus chaud.
    - [^]Re: Qualité ?
      
      Posté par Richard Van Den Boom () le 09/03/2008 à 09:22. (lien). Évalué à 7.
      Exactement.
      Ce codec a été développé par la BBC, donc l'objectif n'est pas forcément de créer un enième codec HD de visualisation (h264 fait cela très bien), mais un codec pro pour archiver ou monter ses vidéos.
      En montage vidéo, on ne travaille pratiquement jamais avec des codecs destructeurs comme le MPEG2, 4 ou le h264, à cause des artefacts qui apparaissent à partir de plusieurs générations (essayer de faire en montage avec des fichiers MPEG2 et d'exporter le tout en MPEG2, vous verrez ce que je veux dire).
      Il existe des codecs spécifiques genre HDCAM-SR ou DVCPro-HD, mais ils sont souvent très volumineux et sont spécifiques de certains constructeurs. Une TV peut avoir intérêt à demander un format unique, plus léger et offrant toutes les garanties nécessaires de qualité pour le montage et remontage.
      Travaillant entre autres dans le cinéma d'animation, je vais aller regarder ce codec de près.
      - [^]Re: Qualité ?
        
        Posté par sioben () le 11/03/2008 à 09:29. (lien). Évalué à 1.
        Espérons que ce format devienne un équivalent video de l'OpenEXR, et surtout qu'il soit correctement implémenté pour être interchangeable entre chaque logiciel professionnel!
        
        Ce serait pas mal de pouvoir choisir Dirac à l'export d'un projet FinalCutPro sous Mac (si Schrödinger nous sort une extension QuickTime) pour l'envoyer ensuite sur AfterEffects sous Windows ou Piranha ou Cinelerra sous Linux ...
        
        Dirac pourrait avantageusement remplacer le DVCam, le DVCPRO-HD, ... pour archiver en bien meilleure qualité. Et ce format semble accessible aux petits studios (pas besoin de remplacer tout le réseau):
        We can use SD infrastructure to route HD signals by compressing 1.5 GBit/s HDSDI links into 270 MBit/s SDI or SDTI. Likewise, compressing HDSDI signals to be carried on Gigabit Ethernet (at circa 600 MBit/s) would also allow HD working on cheap network infrastructure. DiracPRO introduces minimal artefacts at these levels of compression.
        
        La BBC innove à nouveau dans le domaine du broadcast. Félicitations à eux & à l'équipe Fluendo!
      - [^]Re: Qualité ?
        
        Posté par reno () le 11/03/2008 à 09:58. (lien). Évalué à 2.
        >créer un enième codec HD de visualisation (h264 fait cela très bien)
        
        Sauf que h264 a des patentes, pas Dirac, ce qui fait une grosse différence pour les distributions!
        
        Donc j'espère que Dirac est aussi utilisable pour faire de la simple visualisation, ce qui permettrait à terme peut-être d'avoir enfin des distributions Linux 'multimédia-ready' enfin si par la on entend pour du Ogg Vorbis ou du Dirac..
        :-)
    - [^]Re: Qualité ?
      
      Posté par Matthieu C () le 09/03/2008 à 16:17. (lien). Évalué à 6.
      et pour des chiffres regardes http://sourceforge.net/forum/forum.php?thread_id=1830216&(...)
      
      Times for decoding a 1440x1080 Dirac stream (with inter) of 3880 frames:
      
      - CPU only implementation: 2671126.326 ms = about 1.5fps
      - GPU accelerated implementation: 188548.063 ms = about 21fps
      
      These timings were done by gstreamer on this machine:
      CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 5200+
      GPU: Geforce 8800GTX
      - [^]Re: Qualité ?
        
        Posté par reno () le 11/03/2008 à 10:04. (lien). Évalué à 2.
        Ca fait mal: même pas du décodage 'temps réel' (25fps) avec le top des GPUs et je ne parle même pas du rendu purement sur le CPU..
        
        Je croise les doigts pour qu'il reste plein d'optimisations à faire.
        
        Enfin peu de film utilise une résolution aussi élevée (même si la full HD est encore supérieure..).
        
        [^]Re: Qualité ?
        
        Posté par PasChauve PasOunet () le 12/03/2008 à 13:05. (lien). Évalué à 3.
        Enfin peu de film utilise une résolution aussi élevée (même si la full HD est encore supérieure..).
        
        Y a plein de cameras qui filment en 1440x1080 , c est juste la version anamorphique du 1920x1080

[^]Re: Qualité ?

Posté par Stéphane (page perso, ) le 08/03/2008 à 12:10. (lien). Évalué à 3.
Voici un site qui propose des comparaisons de codeurs H.264 (et pas codecs vu qu'ils décodent tout avec le décodeur de référence H.264) : http://compression.ru/video/codec_comparison/index_en.html

Attention cependant, ils utilisent des métriques de qualité objectives (PSNR et SSIM) dont les performances sont très discutables.... et faire des tests subjectifs n'est pas à la portée de tout le monde.
L'autre problème est qu'ils testent énormément de choses. Il y a du multi-contenu, du multi-format (du QCIF à la TVHD), du multi-framerate et donc du multi-codeurs. Pas facile de s'y retrouver et d'avoir des échantillons représentatifs. La dernière campagne de comparaison de décembre 2007 (http://compression.ru/video/codec_comparison/mpeg-4_avc_h264(...) ) portait sur les codecs suivant :
# XviD (MPEG-4 ASP codec)
# MainConcept H.264
# Intel H.264
# x264
# AMD H.264
# Artemis H.264

Évidemment, il n'inclut pas Dirac dans son panel de codecs, peut-être qu'ils élargiront à l'avenir. Pour résumer les résultats (basé sur du PSNR et du SSIM, donc à prendre avec des pincettes) : MainConcept et x264 semblent meilleurs pour les trois configurations (vidéoconférence bas débit, basse taille d'image ; films (qualité DVD) ; TVHD (haut débit, 1920*1080) mais pour ces deux derniers les résultats sont discutables dans la mesure où la source a déjà subit un codage MPEG-2).
- [^]Re: Qualité ?
  
  Posté par GPL (Jabber id, ) le 08/03/2008 à 12:58. (lien). Évalué à 2.
  D'ailleurs pour avoir une source vidéo la plus "dirac" possible, je crois qu'il y a des plans de design libre d'une électronique spécialisée dans la compression en "dirac pro" afin que des caméras puissent directement compresser en "dirac pro" le flux non compressé.
  
  En attendant... :) est-ce qu'il existe des torrents de vidéos HD non compressées? J'imagine qu'ils ne doivent pas être tous petits petits. Avoir différents type de séquences (beaucoup de details avec mouvement rapide/lent, sombre, éclairé, gros objects etc... etc...) on pourrait voir ce que donne, un plus pertinement (je sais que c'est très subjectif), les codecs en rapport compression/qualité (cas d'un flux HD).
  - [^]Re: Qualité ?
    
    Posté par Stéphane (page perso, ) le 09/03/2008 à 19:31. (lien). Évalué à 2.
    y'en a très peu, c'est d'ailleurs un gros problème pour nous (chercheurs en qualité vidéo en HD)
    pour donner une idée, on utilise 24 séquences de 10 secondes, elles font à peu près 1Go chacune (et le codage H.264 avec le codeur de référence dure environ 2 jours sur un bi-Xeon :-) )
    j'avais un lien où on pouvait en télécharger une poignées mais il est HS, donc je n'ai rien à proposer....

Assembleur quand tu nous tiens!

Posté par ADN733r () le 07/03/2008 à 23:37. (lien). Évalué à 4.

Il faut croire que la mention "optimisations en assembleurs" donne des frissons à certains : ça fait toujours bon genre ces petites phrases...

Des examples?

Posté par Zenitram (page perso, ) le 08/03/2008 à 10:05. (lien). Évalué à 2.

Ou peut-on trouver des exemples de fichiers Dirac dans un conteneur OGG, ou dans un conteneur MPEG-TS?

Merci

Posté par beagf (page perso, ) le 08/03/2008 à 12:11. (lien). Évalué à 7.

The BBC is releasing the source to the reference implementation of Dirac under the free software and open source Mozilla Public License, the GNU GPL 2 and the GNU LGPL. This may accelerate its adoption and lower entry costs into the emerging industry of Internet television.

While the BBC own some patents on Dirac, they have irrevocably granted a royalty-free licence for their Dirac-related patents to everyone. In addition, the BBC have checked (by extensive patent search) that Dirac does not infringe any third party patents, enabling the public to use Dirac for any imaginable purpose.

Quand je lit ça sur le site de wikipedia je dit un grand merci a la BBC. Ils jouent le jeu jusqu'au bout, le projetest vraiment libre et ils font tout leur possible pou être sur qu'il n'ya pas debrevets dessus. Bravo !

[^]Re: Merci

Posté par Jerome Alet (page perso, ) le 08/03/2008 à 13:45. (lien). Évalué à 10.
> Quand je lit ça sur le site de wikipedia je dit un grand merci a la BBC.
> Ils jouent le jeu jusqu'au bout, le projetest vraiment libre et ils font
> tout leur possible pou être sur qu'il n'ya pas debrevets dessus. Bravo !

Putain, le jour où France Télévision(s) fait un truc de ce genre, on pourra déboucher le Champagne...
- [+] [^]Re: Merci
  
  Posté par eastwind (Jabber id, ) le 08/03/2008 à 18:26. (lien). Évalué à -1.
  Faut que TF1 mettent du temps de cerveaux disponible :)
  - [+] [^]Re: Merci
    
    Posté par cyril guilloud () le 08/03/2008 à 22:19. (lien). Évalué à -1.
    Les petits ruisseaux font les grandes rivieres.
    Imaginez que TF1 rendent tous les temps de cerveau confisqués... (meme des cerveaux regardant le 13h de TF1) . Ca laisse songeur.
- [^]Re: Merci
  
  Posté par alice_liddell () le 11/03/2008 à 11:09. (lien). Évalué à 1.
  Vivement Derrick en HD.

Le Web vidéo...

Posté par GPL (Jabber id, ) le 08/03/2008 à 12:26. (lien). Évalué à 10.

... maintenant il faut que firefox 3 ne fasse pas de bourde et présente par défaut le support de ogg/mkv(containeurs) theora/dirac(video) vorbis/flac(audio).

Bon... pour rester réaliste, il faudrait que la plomberie "video" de firefox 3 soit pluggable sur un framework multimedia pour nous lire tout ça... ffmpeg? gstreamer?

Il faut que binaires firefox 3 puissent découvrir les codecs installés sur la machine où justement il est installé, et si il ne trouve rien qu'il soit équipé par défaut du support de ces codecs pour le DOM et la balise vidéo. Ensuite il faut mettre en avant le fait qu'avec firefox les webmasters sont "sûrs" d'avoir au moins ces codecs.

[^]Re: Le Web vidéo...

Posté par Didier Raboud (Jabber id, page perso, ) le 09/03/2008 à 21:57. (lien). Évalué à 3.
Bon... pour rester réaliste, il faudrait que la plomberie "video" de firefox 3 soit pluggable sur un framework multimedia pour nous lire tout ça... ffmpeg? gstreamer?

Ou même qu'il soit pluggable sur un gestionnaire de framework multimédia... Phonon ?

[^]Re: Le Web vidéo...

Posté par GPL (Jabber id, ) le 11/03/2008 à 11:51. (lien). Évalué à 0.
TRÈS TRÈS mauvaise nouvelle: il n'y aura pas de support de l'élément <vidéo> ainsi que de lecteur vidéo DOM dans firefox 3.

CPU/GPU nécessaire?

Posté par José JORGE (Jabber id, page perso, ) le 08/03/2008 à 20:24. (lien). Évalué à 5.

Voici donc un nouveau format, encore plus gourmand que le x264 si j'ai bien suivi. Quelqu'un a évalué la puissance nécessaire à son visionnage à des résolutions standard, genre 768x576?

Mon P3-450 ne peut pas décoder du x264 à ce format, et XVMC n'étant pas adapté à autre chose que du MPEG1/2, il nous faut donc espérer que le projet nouveau va pondre une belle implémentation d'accélération GPU du décodage MPEG4 et/ou DIRAC, afin que le libre continue d'être là où l'on peut utiliser le mieux les anciennes machines.

Tiens, rien que pour ça, ça vaut le coup ce pilote nouveau.

[^]Re: CPU/GPU nécessaire?

Posté par Matthieu C () le 08/03/2008 à 21:18. (lien). Évalué à 5.
Faut-il encore que ton gpu supporte le dirac (ou soit programmable pour le faire). Et ton P3-450 doit avoir une vielle carte graphique ?

Et puis Schrödinger a déja du code "cuda" pour tourner sur les gpu nvidia (avec le pilote proprio je suppose).

[^]Re: CPU/GPU nécessaire?

Posté par GPL (Jabber id, ) le 09/03/2008 à 00:46. (lien). Évalué à 4.
Vu et la nouvelle pile graphique pour Linux se penche sur le sujet:
http://www.freedesktop.org/wiki/Software/vaapi
- [^]Re: CPU/GPU nécessaire?
  
  Posté par j0akim () le 10/03/2008 à 13:16. (lien). Évalué à 4.
  Oui, les GPUs sont des architectures massivement parallèles, qui peuvent être utilisées pour des traitements d'unités à décompresser en parallèle, c'est super efficace pour cela. Ca fonctionne alors comme un dsp mais avec plein d'unités en parallèles et qui peuvent, en plus changer d'affectation (décodage, post-traitement...). On en est qu'au début, c'est très dur d'utiliser cela mais ca va augmenter en puissance, par exemple pour une petite initiation :
  
  http://www.daimi.au.dk/~mosegard/GPGPU_E04
  http://www.cis.upenn.edu/~suvenkat/700/#lectures
  http://www.gpgpu.org/s2004/
  http://courses.ece.uiuc.edu/ece498/al1/Syllabus.html
  http://gamma.cs.unc.edu/GPGP/
  http://www.seas.upenn.edu/~cis665/index-2007.htm
  http://courses.ece.uiuc.edu/ece498/al1/
  
  Je suis bien sûr sur qu'en france on fait pareil mais il est moins facile de trouver de la biblio en francais sur ce sujet.

[^]Re: CPU/GPU nécessaire?

Posté par j0akim () le 10/03/2008 à 13:07. (lien). Évalué à 3.
De toute facon tous les codecs récents nécessitent des machines brutalement puissantes, le flux de données est plus important à cause de la haute résolution.

En compression il y a toujours un tradeoff ratio de compression / temps de compression / temps de décompression / qualité (dans le cas d'une compression destructive).

Si tu es en flux brut ton vieux pc ne pourra pas assurer le flot de données, si tu est en flux ultra compressé non plus il n'aura pas la puissance de calcul nécessaire pour décoder.

Donc les vieux pc c'est poubelle pour dirac/mp4.

Il y a des articles comparant les différents codecs mais ils sont proprio :/ notamment dans les ieee transactions, si ca intéresse quelqu'un qui a accès à cette base et pourrait m'en faire aussi profiter :)

http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/11153/(...)

Sinon j'ai trouvé une page en francais mais les liens sont morts :/
- [^]Re: CPU/GPU nécessaire?
  
  Posté par José JORGE (Jabber id, page perso, ) le 11/03/2008 à 14:39. (lien). Évalué à 3.
  Non, les codecs peuvent aussi être utilisés dans des résolutions basses. C'est pourquoi je parlais de la résolution d'un DVD. Ma machine gère très bien cette résolution en MPEG2 (70%CPU), moins bien en MPEG4 de base (Xvid 95% CPU et plus dans les mouvements de caméra) et pas du tout en MPEG4/AVC (x264 160% CPU). Par contre en Theora j'ai que 75% CPU.
  - [^]Re: CPU/GPU nécessaire?
    
    Posté par j0akim () le 12/03/2008 à 10:35. (lien). Évalué à 3.
    C'est exactement ce que je dis, tu nous parle du tradeoff en question, j'abordai juste le problème de manière générique.
    J'ai pas donné d'exemple, mais un flux hdtv en dirac ou en h264 ne passera pas sur une petite machine. Le dvd il est à résolution faible en mp2 et de toute façon c'est pas du tout récent, donc les flux restent à la portée des vieux pc. Les xvid pareil, c'est vieux et les divx passent très bien sur de vieilles machines, pas de souci, ca a été fait pour ca et à l'époque on n'avait pas la puissance pour h264. Theora, pas souvent testé mais les ogg disséminés sur le web ont souvent une réso faible. Dans ton cas on voit bien que le h264 mise sur la qualité, le mp2 et theora, moins, dans la limite que ces algos sont +- optimisés en assembleur ou autre, et qu'il est possible d'agir sur la phase compression en étant plus ou moins agressif, et la phase décompression avec la décompression en elle-même et le post-traitement.
    - [^]Re: CPU/GPU nécessaire?
      
      Posté par José JORGE (Jabber id, page perso, ) le 14/03/2008 à 15:21. (lien). Évalué à 3.
      Tu confonds machine courante en France, avec machine courante dans le monde. Si on suit ce raisonnement, un aura jamais un standard vidéo potable.
      
      Allez, puisque tu trouves qu'il n'y a pas de gros Theora, un gros Ogg/Theora alors : http://jjorge.free.fr/mathilde/video/mirabelle_et_le_papillo(...)
      
      (Oui c'est de l'auto-pub, mais c'est libre ;-P)

Revenir en haut de page

Articles précédents : Logiciel

Liens connexes

Dépêche modérée par

Dépêche éditée par

Logiciel : Schrödinger 1.0 : le codec Dirac est prêt

[+] Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[+] [^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

[^]Re: Question bête (comme d'hab' quoi)

Très puissant

[^]Re: Très puissant

[^]Re: Très puissant

[^]Re: Très puissant

[^]Re: Très puissant

[^]Re: Très puissant

[^]Re: Très puissant

Tiens les ondelettes... encore....

[^]Re: Tiens les ondelettes... encore....

[^]Re: Tiens les ondelettes... encore....

[^]Re: Tiens les ondelettes... encore....

[^]Re: Tiens les ondelettes... encore....

[^]Re: Tiens les ondelettes... encore....

Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

[^]Re: Qualité ?

Assembleur quand tu nous tiens!

Des examples?

Merci

[^]Re: Merci

[+] [^]Re: Merci

[+] [^]Re: Merci

[^]Re: Merci

Le Web vidéo...

[^]Re: Le Web vidéo...

[^]Re: Le Web vidéo...

CPU/GPU nécessaire?

[^]Re: CPU/GPU nécessaire?

[^]Re: CPU/GPU nécessaire?

[^]Re: CPU/GPU nécessaire?

[^]Re: CPU/GPU nécessaire?

[^]Re: CPU/GPU nécessaire?

[^]Re: CPU/GPU nécessaire?

[^]Re: CPU/GPU nécessaire?