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.
Aller plus loin
- Schrödinger (52 clics)
- Dirac (43 clics)
- Dirac à la BBC (13 clics)
- LinuxFR.org : La BBC libère ses travaux sur le codec vidéo Dirac (44 clics)
- liboil (16 clics)
# Question bête (comme d'hab' quoi)
Posté par Tux_Beginner . Évalué à -3.
Il faut le comparer ogg / flac ou a speex (voix) ?
[^] # Re: Question bête (comme d'hab' quoi)
Posté par Sébastien ANDRE . Évalué à 4.
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 . Évalué à 2.
Oups >.<
J'ai lu trop vite, mes excuses.
[^] # Re: Question bête (comme d'hab' quoi)
Posté par verdesroches (site web personnel) . Évalué à 7.
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 M . Évalué à 10.
[^] # Re: Question bête (comme d'hab' quoi)
Posté par latheix . Évalué à 10.
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 . Évalué à 5.
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 . Évalué à 6.
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 GG (site web personnel) . Évalué à 3.
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.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Question bête (comme d'hab' quoi)
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: Question bête (comme d'hab' quoi)
Posté par latheix . Évalué à 6.
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 (Mastodon) . Évalué à 4.
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 . Évalué à 8.
Il n'y a qu'à regarder le taux d'adoption du Flash ...
[^] # Re: Question bête (comme d'hab' quoi)
Posté par Yusei (Mastodon) . Évalué à 1.
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 . Évalué à -5.
[^] # Re: Question bête (comme d'hab' quoi)
Posté par regdub . Évalué à 4.
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 (site web personnel) . Évalué à 8.
...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 B . Évalué à 4.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 3.
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 . Évalué à 10.
[^] # Re: Très puissant
Posté par plic . Évalué à 10.
Vidéos de chat exclusivement !
La faculté de citer est un substitut commode à l'intelligence -- Somerset Maugham
[^] # Re: Très puissant
Posté par Tux_Beginner . Évalué à 4.
Il n'y a pas de chat dans ces vidéos !!
[^] # Re: Très puissant
Posté par BAud (site web personnel) . Évalué à 3.
[^] # Re: Très puissant
Posté par Francois Revol (site web personnel) . Évalué à 2.
[^] # Re: Très puissant
Posté par Guillaume Gimenez (site web personnel) . Évalué à 8.
[^] # Re: Très puissant
Posté par Thomas Douillard . Évalué à 2.
# Tiens les ondelettes... encore....
Posté par Nicolas BOUTHORS . Évalué à 3.
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.
[^] # Re: Tiens les ondelettes... encore....
Posté par jeffcom . Évalué à 7.
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...
[^] # Re: Tiens les ondelettes... encore....
Posté par helkyn . Évalué à 10.
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 (site web personnel) . Évalué à 4.
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 . Évalué à 0.
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 B . Évalué à 3.
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 . Évalué à 5.
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 . Évalué à 4.
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. . Évalué à 2.
[^] # Re: Qualité ?
Posté par timid . Évalué à 3.
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 M . Évalué à 5.
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 . Évalué à 7.
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 bEN . Évalué à 1.
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 . Évalué à 2.
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 M . Évalué à 6.
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 . Évalué à 2.
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 Prosper . Évalué à 3.
Y a plein de cameras qui filment en 1440x1080 , c est juste la version anamorphique du 1920x1080
[^] # Re: Qualité ?
Posté par Stéphane Péchard (site web personnel) . Évalué à 3.
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 . Évalué à 2.
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 Péchard (site web personnel) . Évalué à 2.
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 Florian . Évalué à 4.
# Des examples?
Posté par Zenitram (site web personnel) . Évalué à 2.
# Merci
Posté par beagf (site web personnel) . Évalué à 7.
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 (site web personnel) . Évalué à 10.
> 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☯ . Évalué à -1.
[^] # Re: Merci
Posté par cyril guilloud . Évalué à -1.
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 . Évalué à 1.
# Le Web vidéo...
Posté par GPL . Évalué à 10.
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 (site web personnel) . Évalué à 3.
Ou même qu'il soit pluggable sur un gestionnaire de framework multimédia... Phonon ?
[^] # Re: Le Web vidéo...
Posté par GPL . Évalué à 0.
# CPU/GPU nécessaire?
Posté par ʭ ☯ . Évalué à 5.
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.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: CPU/GPU nécessaire?
Posté par M . Évalué à 5.
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 . Évalué à 4.
http://www.freedesktop.org/wiki/Software/vaapi
[^] # Re: CPU/GPU nécessaire?
Posté par j0akim . Évalué à 4.
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 . Évalué à 3.
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 ʭ ☯ . Évalué à 3.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: CPU/GPU nécessaire?
Posté par j0akim . Évalué à 3.
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 ʭ ☯ . Évalué à 3.
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)
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.