Creation d un algorithme de compression video

Creation d un algorithme de compression video - C - Programmation

Marsh Posté le 14-08-2006 à 14:15:51    

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+ !

Reply

Marsh Posté le 14-08-2006 à 14:15:51   

Reply

Marsh Posté le 14-08-2006 à 14:18:01    

Certes.

Reply

Marsh Posté le 14-08-2006 à 22:26:29    

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 [:cupralf]


---------------
Hobby eien /人◕ ‿‿ ◕人\
Reply

Marsh Posté le 14-08-2006 à 22:46:37    

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

Reply

Marsh Posté le 14-08-2006 à 23:15:01    

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 ?

Reply

Marsh Posté le 14-08-2006 à 23:19:13    

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

Reply

Marsh Posté le 15-08-2006 à 03:20:12    

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:

Code :
  1. typedef struct { unsigned char r,g,b; } RGB;
  2. RGB* tampon=(RGB*)malloc(taille_x*taille_y*sizeof(RGB));
  3. // afficher un pixel blanc à la position (10,11)
  4. RGB blanc; blanc.r=blanc.g=blanc.b=0xff;
  5. tampon[11*taille_x+10]=blanc;


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.

Reply

Marsh Posté le 15-08-2006 à 03:21:02    

Tamahome a écrit :

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 [:cupralf]


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


---------------
Bitcoin, Magical Thinking, and Political Ideology
Reply

Marsh Posté le 15-08-2006 à 10:43:10    

farib a écrit :

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


 
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 ...


---------------
Hobby eien /人◕ ‿‿ ◕人\
Reply

Marsh Posté le 15-08-2006 à 13:14:08    

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

Reply

Marsh Posté le 15-08-2006 à 13:14:08   

Reply

Marsh Posté le 15-08-2006 à 13:32:31    

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

Reply

Marsh Posté le 15-08-2006 à 13:47:42    

bah tu fous toutes les images en BMP, dans un ZIP, et hop, une vidéo compressée [:dawa]
 
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.


Message édité par lorill le 15-08-2006 à 13:47:53
Reply

Marsh Posté le 15-08-2006 à 13:51:41    

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 :o

Reply

Marsh Posté le 15-08-2006 à 13:51:48    

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

Reply

Marsh Posté le 15-08-2006 à 14:02:27    

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.

Reply

Marsh Posté le 15-08-2006 à 14:25:47    

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 ? [:pingouino]


---------------
Bitcoin, Magical Thinking, and Political Ideology
Reply

Marsh Posté le 15-08-2006 à 14:29:47    

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 ?

Reply

Marsh Posté le 15-08-2006 à 14:54:17    

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


---------------
Hobby eien /人◕ ‿‿ ◕人\
Reply

Marsh Posté le 15-08-2006 à 15:01:00    

In adess we trust [:atari]

Reply

Marsh Posté le 15-08-2006 à 16:51:44    

adess00 a écrit :

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 ?


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

Reply

Marsh Posté le 16-08-2006 à 12:35:20    

adess00 a écrit :

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


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

Reply

Marsh Posté le 16-08-2006 à 13:11:46    

SBAM a écrit :

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


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.

Reply

Marsh Posté le 16-08-2006 à 13:16:15    

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).

Reply

Marsh Posté le 16-08-2006 à 16:43:50    

adess00 a écrit :

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


---------------
Fight with the best, die with the rest ...
Reply

Marsh Posté le 16-08-2006 à 17:07:33    

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

Reply

Marsh Posté le 16-08-2006 à 17:17:50    

gizmo a écrit :

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.


 
http://forum-images.hardware.fr/icones/message/icon10.gif
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  [:huit]

Reply

Marsh Posté le 16-08-2006 à 19:04:23    

adess00 a écrit :

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).


 
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

Reply

Marsh Posté le 16-08-2006 à 19:16:21    

Je connais deja

Reply

Marsh Posté le 16-08-2006 à 19:33:51    

Montre nous ton algo alors :lol:

Reply

Marsh Posté le 16-08-2006 à 19:44:56    

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

Reply

Marsh Posté le 16-08-2006 à 19:45:14    

il est sur papier j ai la flemme de tout scanner

Reply

Marsh Posté le 16-08-2006 à 19:47:28    

jagstang a écrit :

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


 
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

Reply

Marsh Posté le 16-08-2006 à 19:51:36    

tu te ridiculise avec un tel topic ici...

Reply

Marsh Posté le 16-08-2006 à 19:53:21    

"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"

Reply

Marsh Posté le 16-08-2006 à 19:59:10    

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

Reply

Marsh Posté le 17-08-2006 à 00:42:26    

jagstang a écrit :

"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"


 
Fermat n'était pas une quiche non plus ;)

Reply

Marsh Posté le 17-08-2006 à 00:44:13    

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


Message édité par jagstang le 17-08-2006 à 00:49:55
Reply

Marsh Posté le 17-08-2006 à 23:54:16    

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 :p

Reply

Marsh Posté le 17-08-2006 à 23:56:51    

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)

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed