Bonjour,
je suis à la recherche d'une librarie qui permette de décoder des images jpeg de façon rapide (ie: en utilisant les extensions processeur MMX/SSE)
La libjpeg n'est écrite qu'en C...
Alors si vous en connaissez une faite le savoir  
 

Et tu voudrais une lib écrite en quoi d'autre qu'en C ?

assembleur je suppose.

Magick++ en C++ je crois

Il a dit plus rapide que le C

AFAIK, pas mal d'implémentations de librairie de manipulation graphique utilisent l'assembleur pour optimiser des portions de code.

Voui, je sais, mais quand même pour faire une lib en "pur assembleur"

quand j'ai écrit "La libjpeg n'est écrite qu'en C... " ça voulait dire 100% de C d'où aucune optimisation.
En fait c'est la fonction idct qui est consommatrice de ressource dans la décompression jpeg et c'est celle là qui doit être optimisée.
Les codecs mpeg1/2/3/4 par exemple possèdent pour la plupart une version optimisée de cette fonction, la librairie libjpeg non

Harko et ses disciples pourraient nous faire ca en quelques minutes je penses

Ben reste plus qu'à faire une zentille demande à l'équipe qui dev la libjpeg

S'il sont pas morts
 
"IJG is an informal group that writes and distributes a widely used free library for JPEG image compression.
 
The latest release is version 6b of 27-Mar-1998. This is a stable and solid foundation for many application's JPEG support. "

 
Il me semblait pourtant qu'elle continuait à évoluer régulièrement ...

regardes éventuellement du coté de la libgd

Si elle est stable et qu'elle ne contient pas de bug
http://www.ijg.org/

pour l'avoir utilisé, l'assembleur n'est pas forcément plus rapide que le C, cela dépend comment c'est rédigé-algorithmé.
sinon oui effectivement.

l'assembleur niveau portabilité c'est zéro donc pas utilisé en priorité sauf pour des trucs comme libatlas.
sinon les options de compilation peuvent changer quelque chose si les bonnes sont utilisées.
eventuellement utiliser le compilateur intel.

toi tu ne connais pas menuetOS

 
Oui m'enfin le compilateur fait lui aussi des optimisations.
 
Et je doute très sincèrement que un dev assm d'aujourd'hui sont autant capable de pondre un code optimisé pour une archi donné qu'un compilo spécialement fait pour. S'il y a des optimisations à faire, c'est certainement dans le code C alors (boucle en -- , parallèlisation de la mort sur les multi core actuels), que de se taper ca en pur assembleur.  
 
Faut être maso

Mais pour accéder aux instructions MMX et tout le tralala, on doit toujours passer par l'asm, non ?

Encore heureux que le compilateur les gère (-msse, -mmmx), parce que vu la gueule des instructions pour des opérations "pas simples" (flottants par exemple), on s'en sortirait plus.

unix s'est basé sur un choix de langage "haut niveau" pour la prog du système (les débuts du C), alors que tout le reste était avant codé pour une archi particulière en assembleur. On laisse le soin au compilo de faire les optimisations, comme au garbage collector d'une JVM ou CLR de gérer les références en mémoire.

Faire de l'assembleur aujourd'hui, à part pour se prendre pour un l33t ou faire du debug, ca ne sert vraiment plus à grand chose, surtout si c'est pour jouer la compet avec un compilo et des flags agressifs. Plutot se concentrer sur le multi core et les optimisations qui vont avec, qui sont tout aussi peu triviales mais pas soluble par un compilateur.

Pourtant une grande majorité de codecs utilisant la DCT (jpeg mpeg1,2,3,4 entre autres) utilisent une version écrite en assembleur de cette fonction. La compensation de mouvement est également écrite en assembleur dans la plupart des implémentation mpeg, il suffit de regarder le code source de libavcodec pour s'en convaincre.
Bien sur  on parle d'algorithmes qui prennent moins de 50 lignes de code en C mais qui représentent une trés larges majorité du temps d'encodage/décodage.
Sinon à part le compilateur d'Intel, les compilateurs actuels sortent du code mmx/sse médiocre par relativement à celui écrit à la main (il faut se mettre en tête que l'on parle d'algorithmes courts et ultra classiques donc les expert on eu le temps de pondre du code pour cela).

C'est pas de gestion dont on parle mais plutôt du fait que le compilateur soit capable de reconnaître une situation où il peut remplacer du code par une instruction MMX/SSE/Bidule adaptée. GCC fait un peu d'auto-vectorisation mais c'est pas pour autant qu'il saura faire mieux qu'un développeur qui a un besoin très spécifique...
 
http://gcc.gnu.org/projects/tree-s [...] ation.html

Y'a un monde entre faire du code as pour des algorithmes courts et s'amuser à optimiser une lib en as. Avec quelques insomnies, crise de folie et litres de café au passage.

De facto, "un développeur qui a un besoin très spécifique" ne verra pas son .o optimisé comme il se doit, du fait du besoin très spécifique. Ce qui reste une minorité, surtout avec les contreparties que ca implique: portabilité qui disparaît, relecture pénible, arcane difficilement maitrisable. On s'éloigne de la philosophie d'origine.

Même la FFTW, qui est une lib incontournable pour quiconque fait du TS/TI dans sa vie de dev, essaie autant que possible d'éviter les bouts de code assembleur, et les gardes dans des cores spécifiques. Donc avant de se jeter dedans à corps perdu, vaut mieux réfléchir.

 
Ha ben ça, c'est sûr... L'assembleur n'est à utiliser qu'en dernier ressort. C'est bien pour cela que je parlais de besoins spécifiques. Dans le code des codecs vidéo, il y en a souvent parce que des instructions adéquates pour les CPU modernes utilisées dans des boucles peuvent vraiment améliorer les performances.
 
Il y a aussi moyen d'utiliser des bibliothèques qui incorporent de l'assembleur (avec différents codes en fonctions des plateformes) pour éviter d'avoir à se le palucher soi-même ; je pense à liboil en particulier.

Bon... je viens de regarder du coté de la libjpeg6: c'est immonde cette librairie. Elle suit la philosophie du "pourquoi faire simple quand on peut faire compliqué", et je ne parle même pas des gestionnaires d'erreur avec "setjmp" ou du buffering prise de tête(en gros il faut 100 lignes de code pour décompresser une image JPEG en ram vers la ram).

Bon quelle chance, avant de se lancer sur de l'assembleur tel un Harko en furie, un bon petit patch, du nettoyage de lib, tout le monde sera content

Mon but premier n'était pas de faire de l'assembleur, même si je sais coder en assembleur je n'ai pas de temps à perdre pour celà en ce moment, je voulais juste savoir si il existait une lib optimisée. N'empêche que ça m'étonne que la libjpeg soit aussi compliquée. De la même manière cela m'étonne que pour accéder à un périphérique v4l2 (périphérique d'acquisition video) on doivent encore dialoguer avec le drivers à coup de "ioctl" sans aucune librairie de plus haut niveau. Je pense que le monde linux à réellement besoin d'une librairie haut niveau qui permette d'accéder facilement à différents types de périphériques multimedia facilement de façon unifiée (j'ai l'impression que tout le monde fait ça dans sont coin KDE d'un côté Gnome d'un l'autre ....)
Le projet est ambitieux, mais l'idée est facile alors pourquoi personne ne s'est jamais lancé dans un tel projet ?

Parce qu'il y a assez peu d'intérêt? Elle est solide, et n'a pas eu de rapport sévère de bugs ces derniers temps (j'en ai pas vu passer sur mes listes sécu du moins), quand on compare à la libpng ou libsvg, moins "matures", c'est autre chose.
 
Pour v4l je savais pas, ca fait en plus de cela des appels ioctl pour fonctionner? Amha, ca sent le périph derrière vraiment foireux . Pour avoir une API stable, il faudrait avoir des périphs assez facile à suivre, et pour des chips d'acquisition je doute que ca soit aussi critique que d'autres, genre imprimantes. Moins d'investissement, donc forcément, ca devient craignos niveau code ("on se fait pas chier" ).

laissez donc faire son taff au compilo

intéressant ce projet, le dev semble être en suspens par contre, à moins que ca soit terminé.

j'ai deja vu ça quelquepart  

directX  \o/

ben ça part d'une bonne intention directX
le seul pb, c'est la pourritude des sdk et de l'API fournies  

Ah ouais, mais windows et tout c'était une bonne intention aussi hein

SDL+OpenGL+OpenAL c'est pareil que DX.
Après y'a gstreamer, phonon etc...