Re: apt-proxy/rsync/proxy
On Thu, May 30, 2002 at 06:05:45PM +0200, Matthieu Moy wrote:
> Yves Rutschle <y.rutschle@indigovision.com> 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 debian-user-french-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: