Salut a tous !!
 
Alors je viens de faire un algorithme de compression video mais je dois maintenant m attaquer au programme mais je ne sais pas comment marche l affichage d une video.
 
Je vais d abord prendre des videos au format brut pour ensuite les encoder avec mon codec ensuite je decompresse mais je ne sais pas comment afficher l image sachant que je dois afficher des pixels a certains emplacements. J ai vu que certains lecteurs utilisait directX pour l affichage, j ai des notions en openGL donc je voudrais savoir si c est possible de le faire avec cette lib
 
Merci de votre aide  
a+ !

Certes.

tu as un fait un algo de compression video ? tiens donc, certains chercheurs mettent toute une vie à concevoir un algo, et toi pof comme ca, t'en a crée un

Jvai pas y passer ma vie, jlai fait en 10 minutes en regardant la télé (chacun son niveau). I faut juste que j affiche mes pixels

Etrange, tu concois un algo de compression video en 10 minutes, mais un truc aussi trivial qu'afficher des pixels a un emplacement donne te bloque ?

Sa a rien a voir. Faire un algo et un prog c est pas pareil.
Je peux afficher des pixels mais ce que je demande c est la methode la plus performante histoire de ne pas tout recommencer apres car je ne savais pas qu il y avait plus simple ou plus rapide c tout.
Je ne suis pas bloqué je demande des renseignements

Trois façon d'afficher une image temps réel:

• tu as accès directement à la mémoire vidéo, tu affiche une image, tu attends le rafraîchissement tout en décompressant la suivante, etc...
• tu as accès à la mémoire vidéo tampon, où tu y affiche ton image, au moment du rafraîchissement la carte vidéo bascule sur la zone que tu vient d'écrire, tu recommence sur une autre zone tampon.
• tu gère toi-même la zone tampon, quand tu a affiché une image dedans, tu refile l'adresse de début de la zone à la carte et ça s'affiche.

Il y a des tonnes de librairies qui font ça pour toi, au final tu n'a qu'a utiliser la librairie de ton choix et à écrire dans un tampon mémoire. Et le bus AGP fait des miracles, surtout si tu fait du mixage vidéo temps réel.
 
Le plus dur est de déterminer quel est le format de l'image, car selon le format différents algorithmes sont plus ou moins efficaces. Certaines cartes acceptent du YUV, mais la plupart fonctionnent en RGB. Par exemple, pour du RGB24, le plus courant, tu as:

Je te conseille SDL, une petite lib graphique gratuite et assez simple qui permet de gérer les tampons pour toi, de te donner toutes les infos sur le format d'affichage voire de convertir entre formats (!! c'est lent les conversions). Compatible Windows+Linux.

 
Bah quoi, moi aussi j'en ai inventé hein. Il est juste très destructif

 
evidemment je parlais d'un algo utilisable... c'est sur que si tu considères par exemple que transformer une video en un enchainement d'image de 1x1 pixel c'est un algo de compression, alors ...

Nan  c est un algo qui conserve la dimension de l image sans perte de qualité

Bah tiens. On a petit génie parmis nous qui pond des algos de compression sans perte en 10 min devant sa télé

bah tu fous toutes les images en BMP, dans un ZIP, et hop, une vidéo compressée
 
plus serieusement, y'en a qui avaient eu ca comme projet tutoré en fin d'iut (ou de licence), et c'était un peu l'esprit. Le but, c'est de comprendre le principe, pas de concurrencer l'existant.

ouais, enfin, la gestion des marco-block et des frames i,p,b, ça ne s'invente pas en 10 min devant la téloche non plus, hein

C est pas pareil le zip utilise la redondance des octets.
D ailleurs j ai fait un algo de compression de ce genre mais j ai pas reussi a faire mieux que winrar, j ai fait mieux que huffman en compression et vitesse de compression c est deja pas mal .
Mais faut dire aussi winrar utilise 2 algos

bof, le format GIF est compressé, pourtant il n'a rien d'extraordinaire.
 
On s'est tous amusé avec la compression. Perso, j'avais essayé un algo en temps exponentiel, qui découpait <<idéalement>> les images en plus grands rectangles de même couleur/hue/sat/r/g/b superposables. Ça compresse assez bien, c'est juste très très long.
 
Sinon, il est aussi amusant de jouer avec les formats déjà compressés pour voir si on peut faire mieux. En utilisant BZIP, sur des formats déjà compressés avec perte via FFT (genre avi ou mp3), on peut recompresser de 1 à 2% en plus en réorganisant les données. Il s'agit de calculer la meilleure dérivée du fichier d'entrée pour avoir le maximum de valeurs identiques consécutives. Ex: 1, 2, 5, 6: meilleure dérivée: 1, format de sortie: 1(derivée), 1(première valeure), +1(à ajouter au précédant), 5-2, +1, résultat: 3*(1) à re-compresser via BZIP. Ça fonctionne uniquement sur les fichiers compressés avec une FFT, sinon sur du texte brut ça alourdi de 10%. Un autre fait interessant finalement dans cette expérience est que la méthode permet presque à coup sûr de savoir si un fichier de type inconnu utilise une compression avec FFT.

Ah, oui, sinon, je te signale qu'avant d'afficher la vidéo, il faut que tu arrives à lire une vidéo brute pour avoir quelque chose à encoder.
 
Ca, tu sais faire ?

Je comprend pas ce que tu veux dire par lire une video brute.
Tu veux dire si je sais a quoi correspondent les octets d une video brute ?

non je pense qu'il veut parler d'une vidéo où l'ont voit des brutes.

In adess we trust

va louer la cassette de "Le bon , la brute et le truand"

 
UHARC http://www.klaimsoft.com/winuha/
 
Ca met une grosse race a winrar  

Pour les algos de compression sans perte, la question n'est pas de savoir quel est celui qui compresse le mieux, c'est impossible de surpasser huffman. Il s'agit plutôt de trouver le meilleur compromis entre temps d'analyse et compression.

Bien sur que si on peut surpasser huffman, je l ai fais. J ai obtenu un meilleur ratio et une plus grande vitesse de compression (pas d arbre a construire).

 
la méthode idéale pour un cas particulier n'a que peu d'intérêt... il vaut mieux un bon algo générique qu'un excellent pour une tache !
la compression cest pas j'ai un algo je le test avec un truc et je compare...
il faut faire différents test, reflechir sur les cas limites où la méthode n'est pas optimale etc etc...
donc coder un algo qui fout la piller à huffman, ouais je peux le faire mais ca marchera que pour un truc donné... et ca sera la pire merde pour 99.99 des applications.
 
et pour info, apres un huffman on fait souvent un rle, histoire de tasser tout ça

 
@pluche

Nan sa marchai tout le temps, c est ma methode generale qui etait plus performante quelques calculs suffisent a savoir kel taille va prendre le fichier une fois compressé mais je n ai pu que comparer avec winrar qui combine huffman et LZ77 j ai pas pu tester que avec huffman je connais pas de prog qui compresse que avec cet algo

 

Tu peux pas envisager des dicos avec des mots superieurs a 2 chars avec huffman, ca prend trop de place.
 
LZW est bien meilleur car les elements de son dico peuvent etre tres long alors qu'il n'est pas stocke.
 
 
En revanche, il est vrai que UHARC est tres gourmand, mais le resultat est violent  

 
t'es marrant toi... T'as aucune idée de quoi tu parles
 
à lire...
 
http://fr.wikipedia.org/wiki/Entropie_de_Shannon
http://fr.wikipedia.org/wiki/Codage_de_Huffman

Je connais deja

Montre nous ton algo alors

si vraiment tu avais crée un algo de compression vidéo, tu n'aurais aucun problème à concevoir un logiciel pour l'utiliser CQFD

il est sur papier j ai la flemme de tout scanner

 
Et quel est le rapport entre les connaissances pour faire un algo et celles pour faire un prog ? aucun
Si pour toi faire un algo et un prog c est la meme chose ben va prendre des cours

tu te ridiculise avec un tel topic ici...

"j'ai une super idée pour algo de compression vidéo révolutionnaire. Mais il n'y a pas la place dans la marge pour en faire la démonstration"

J ai juste poser une question pour faire mon prog jvoi pas ce que sa a de ridicule mais je ne comprend pas ou est ton probleme par contre

 
Fermat n'était pas une quiche non plus

je doute qu'il aie eu une solution complète, vu le temps qu'il a fallu par la suite
 
edit ;
 
http://forums.futura-sciences.com/ [...] ermat.html

Pour une chaîne de N bits il y a N^N (N exposant N) possibilités de réarrangements (oui, c'est la limite mathématique, et non pas le calcul exact), et par conséquent il faudrait explorer toutes ces possibilitées pour trouver le meilleur ratio de compression. Ce n'est pas du tout, mais alors pas du tout, un arbre. (vous connaissez le problème du voyageur de commerce?)
 
Problème: soit X le numéro de l'arrangement, X variant de 0 à N^N, combien de bit sont necessaires pour coder X?
 
WaHaHa

log2 n^2
 
je crois que le problème du voyageur de commerce (np complet) n'a rien à voir avec la compression vidéo qui travaille différement (voir le discrete cosine transform par exemple)