| Auteur | Message |
|---|---|
|
Administrateur
 |
Ces deux codecs ne sont pas les plus efficaces, et au contraire, à la louche au minimum trois fois moins efficaces concernant la taille des vidéos encodées, que ne le sont les codecs les plus courants. Ils sont cependant beaucoup plus économe en consommation CPU, et sont aussi nettement plus simples.
L’intérêt de ces deux codecs est dans leur simplicité, ce qui est utile pour des applications autonomes sans dépendances externes ou avec la spécification desquelles il est possible d’avoir la main entièrement. Il en existe deux, l’un avec perte et l’autre sans perte. Leurs spécifications complètes restent assez courtes. Spécifications de Cinepak, un codec simple avec perte : cinepak.txt (multimedia.cx) Spécifications de HuffYUV, un codec simple sans perte : huffyuv.txt (multimedia.cx) Ces deux codecs sont en pratique lisibles par tous les lecteurs multimédias, même les plus simples, qu’ils soient sous forme logiciels ou sous forme matériels. Ce sont de véritables codecs reconnus, et non‑pas des codecs expérimentaux produit d’un hobby; sinon ils seraient sans intérêts et je n’en aurais pas fait un sujet. |
|
|
|
Administrateur
|
Hibou a écrit : Ces deux codecs ne sont pas les plus efficaces, et au contraire, à la louche au minimum trois fois moins efficaces concernant la taille des vidéos encodées, que ne le sont les codecs les plus courants. Plus de précision sur cette appréciation vague, avec une citation (traduction plus bas). From Cinepak to H.265: a brief history of video compression (arstechnica.com). Décembre 2009. L’article a écrit : The carousel of progress keeps on turning, and today's compression algorithms are much more effective than older ones. The Cinepak codec that powered early versions of both QuickTime and Windows Media video formats aimed no higher than getting 320x240 video resolution out of a standard CD-ROM drive, which means cramming 2.2Mbps plus audio and overhead into a 1.2Mbps traffic stream. Call it 50 percent compression on a good day. Traduction a écrit :
La roue du progrès continue de tourner, et les algorithmes de compressions, sont de nos jours, beaucoup plus efficaces que les anciens. Le codec Cinepak, sur lequel reposaient alors les formats vidéos des premières versions de QuickTime et Windows Media, se destinait à des résolutions vidéo ne dépassant pas les 320x240 à partir d’un lecteur CD‑ROM standard, ce qui signifiait faire passer 2.2 Mbps plus l’audio et les extra‑données, dans un flux à 1.2 Mbps. Disons, une compression à 50% les bons jours. |
|
|
|
|
Administrateur
|
Il existe une variante de HuffYUV, nommée Lagarith.
Mais deux choses… Il utilise un encodage arithmétique, qui est mathématiquement meilleur que l’encodage de Huffman (l’encodage de Huffman, est en fait un encodage arithmétique non‑optimal), mais qui est aussi parfois sujet à des brevets. La plupart des encodage arithmétique ne sont plus sous brevets de nos jours, mais peut‑être certains le sont encore, et la question de tomber sous le coup d’un brevet est toujours inquiétante. Ce n’est cependant pas son plus gros défaut, qui est plutôt : il n’est pas spécifié. Lagarith ne semble exister que sous forme logicielle, et et je ne lui ai trouvé aucune spécification (excepté de vagues explications selon lesquelles il est dérivé de HuffYUV). Il est possible de consulter les sources, mais des sources ne sont pas des spécifications (les implémentations doivent être dérivées des spécification, et faire le contraire, c’est la négation, l’antithèse de l’ingénierie logicielle). Pour ces deux raisons, et surtout la seconde (la question des brevets étant peut‑être plus une crainte qu’un réalité ici), il est sûrement préférable de ne retenir que HuffYUV et d’oublier Lagarith. |
|
|
|
|
Administrateur
|
Voir aussi : Introduction technique aux flux audios et vidéos.
|
|
|
|
