On Thu, May 30, 2002 at 06:05:45PM +0200, Matthieu Moy wrote: > Yves Rutschle <[EMAIL PROTECTED]> writes: > > > C'est la base de tous les compresseurs (pkzip, gzip, mpeg etc). > > Pour mpeg, c'est un peu différent. C'est un algorithme avec perde de > qualité, qui est surtout basé sur des transformations analytiques > (transformées de fourrier & cie) que sur la répétition. > > > j'ai une photo en jpeg, je change la couleur des yeux d'une personne > > (change quelques pixels), y'a toute les chances pour que le nouveau > > jpg soit complètement différent.) > > Pas tout à fait vrai non plus : le jpeg commence par découper l'image > en carrés de 8 par 8 (ça se voit d'ailleurs quand on zoome), et les > carrés sont compressés individuellement, donc, il y a au contraire de > fortes chances pour que ton image change peu.
Mpeg et Jpeg marchent de la même façon au niveau de l'image: couper en macro-blocks (8x8 pixels), faire une transformée en cosinus bi-dimentionelle (DCT: Discrete Cosine Transform), prendre les bits des fréquences basses (donc on perd les fréquences hautes: c'est pour ça que Jpeg donne des résultats horribles pour les dessins). De là, Mpeg cherche les macro-blocks dans l'image précédente (et suivante, si on est en Mpeg4 et le bon profil) pour voir si il peut les retrouver au même endroit ou "dans les environ", c'est l'estimation de mouvement. (Pour info, Mpeg2, H261 et H263 sont tous basés sur le même principe.) Enfin, Mpeg et Jpeg passent tout ça dans un "VLE" (Variable Length Encoder) qui est un codage de Huffman avec une table fixe, donc finalement exactement ce que je disais, mais en retirant 2 paragraphes, parce que sinon c'était hors sujet. C'est toujours Hors Sujet, d'ailleurs :-) Donc: si je change des yeux, il y a de bonnes chances que la DCT donne un nombre de bits differents, donc décale l'ensemble du bitstream; ensuite, il y a aussi pas mal de chance que le VLE donne un résultat différent. Au final, ça revient au même: la plupart des compressions sont basées sur des flux de bits (bitstreams), pas sur des octets, donc dès qu'un morceau change de taille, tous les autres octets sont également affectés. Tiens, peut-être qu'une façon d'améliorer rsync serait précisément de considérer le fichier comme une suite de bits au lieu d'une suite d'octet. /Y -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]