XviD est maintenant une mecanique bien rodée. Les algorithmes de Motion Estimation sont stabilisés depuis pas mal de temps maintenant et on ne peut plus trop espérer les améliorer. La suite sera donc surement principalement orienté sur deux axes:
- Reduire la complexité des algos, afin de gagner des cycles et par consequent, pour un meme temps de codage, permettre l'utilisation d'options plus gourmande. On optimise en vitesse pour que l'utilisateur a machine constante puisse activer plus d'options pour la qualité -> gain de qualité a temps de codage constant.
- Ameliorer les algos de ME. Tache plus difficle mais pas insurmontable pour les courageux. sysKin avait beaoucoup travaillé sur les algos dit "rate distortion optimized (RDO)" dans XviD 1.x pour le choix des blocs (vhq1) et pour l'evaluation des vecteurs de mouvements candidats (vhq>1). Ces fonctions RDO d'evaluation utilisent toutes des contantes magiques qui permettent d'etablir une relation entre R (le nombre de bit codés) et D (distortion entre l'image originale et l'image codée, grandeur assimilable a l'energie de l'erreur de codage), et F(type de bloc) qui donne une cst par rapport au type de bloc qui represente le nombre de bit employes de facon constante dans la grammaire du bitstream du bloc codé:
R = F(type bloc) + Lambda*D
XviD utilise un lambda constant, pour gagner en qualité, il est envisageable de passer à un lambda optimum pour le bloc codé... en gros rendre le Lambda un poil adaptif a la source.... J'ai pas d'url a proposer pour obtenir les publications sur le sujet, dsl.
>astuces
Pas d'astuces désolé, optimiser tant en qualité qu'en vitesse, c'est toujours un travail assez fastidieux et minutieux.
>Trucs a faire
Ouais, plein ! d'abord le code d'XviD est pas si bien designé. Donc un travail plus ou moins facile consisterait a nettoyer les APIs internes tout en ayant une correspondance 1:1 avec le resultat des vieilles versions. Une autre tache moins excitante, completer la doc dispo sur mon site.... bref XviD est un projet plutot en maintenance, les codeurs fous passeront surement leur chemin, les autres, trouveront toujours quelque chose a nettoyer, redisigner etc...
Autre truc a faire, continuer a tester, remonter les bugs de facon precise (avec une lib compilée pour debug et un coup de gdb et le contexte de pile etc etc)... bref ce que tout logiciel libre demande à ses power users.
>Trucs a ne pas faire
Appeler les fonctions inutilement: toujours n'appeler une fonction que si c'est necessaire, meme si cela impose de garder en memoire l'etat de tes objets (au sens conceptuel, pas OOP) pour savoir le travail qu'il reste encore a effectuer dessus.
La consommation inutile de memoire reduit aussi beaucoup les perfs de facon indirecte. Reduire les besoins memoire permet souvent d'etre moins gourmand en bande passante... moins d'acces memoire, c'est moins de temps perdu dans les cache miss et le rapatriement sur les bus memoires qui representent de vrais goulot d'etranglement comparativement aux 3GHz de nos CPU...
Mettre des tests dans les boucles critiques, preferer une boucle critique par cas a traiter.
... je pourrais en parler des heures... mais tout a une fin :-)
[^] # Re: Conclusions
Posté par Edouard Gomez . En réponse au journal XviD 1.1.0-beta2 is out ! Et moi aussi.... Évalué à 7.
>pistes
XviD est maintenant une mecanique bien rodée. Les algorithmes de Motion Estimation sont stabilisés depuis pas mal de temps maintenant et on ne peut plus trop espérer les améliorer. La suite sera donc surement principalement orienté sur deux axes:
- Reduire la complexité des algos, afin de gagner des cycles et par consequent, pour un meme temps de codage, permettre l'utilisation d'options plus gourmande. On optimise en vitesse pour que l'utilisateur a machine constante puisse activer plus d'options pour la qualité -> gain de qualité a temps de codage constant.
- Ameliorer les algos de ME. Tache plus difficle mais pas insurmontable pour les courageux. sysKin avait beaoucoup travaillé sur les algos dit "rate distortion optimized (RDO)" dans XviD 1.x pour le choix des blocs (vhq1) et pour l'evaluation des vecteurs de mouvements candidats (vhq>1). Ces fonctions RDO d'evaluation utilisent toutes des contantes magiques qui permettent d'etablir une relation entre R (le nombre de bit codés) et D (distortion entre l'image originale et l'image codée, grandeur assimilable a l'energie de l'erreur de codage), et F(type de bloc) qui donne une cst par rapport au type de bloc qui represente le nombre de bit employes de facon constante dans la grammaire du bitstream du bloc codé:
R = F(type bloc) + Lambda*D
XviD utilise un lambda constant, pour gagner en qualité, il est envisageable de passer à un lambda optimum pour le bloc codé... en gros rendre le Lambda un poil adaptif a la source.... J'ai pas d'url a proposer pour obtenir les publications sur le sujet, dsl.
>astuces
Pas d'astuces désolé, optimiser tant en qualité qu'en vitesse, c'est toujours un travail assez fastidieux et minutieux.
>Trucs a faire
Ouais, plein ! d'abord le code d'XviD est pas si bien designé. Donc un travail plus ou moins facile consisterait a nettoyer les APIs internes tout en ayant une correspondance 1:1 avec le resultat des vieilles versions. Une autre tache moins excitante, completer la doc dispo sur mon site.... bref XviD est un projet plutot en maintenance, les codeurs fous passeront surement leur chemin, les autres, trouveront toujours quelque chose a nettoyer, redisigner etc...
Autre truc a faire, continuer a tester, remonter les bugs de facon precise (avec une lib compilée pour debug et un coup de gdb et le contexte de pile etc etc)... bref ce que tout logiciel libre demande à ses power users.
>Trucs a ne pas faire
Appeler les fonctions inutilement: toujours n'appeler une fonction que si c'est necessaire, meme si cela impose de garder en memoire l'etat de tes objets (au sens conceptuel, pas OOP) pour savoir le travail qu'il reste encore a effectuer dessus.
La consommation inutile de memoire reduit aussi beaucoup les perfs de facon indirecte. Reduire les besoins memoire permet souvent d'etre moins gourmand en bande passante... moins d'acces memoire, c'est moins de temps perdu dans les cache miss et le rapatriement sur les bus memoires qui representent de vrais goulot d'etranglement comparativement aux 3GHz de nos CPU...
Mettre des tests dans les boucles critiques, preferer une boucle critique par cas a traiter.
... je pourrais en parler des heures... mais tout a une fin :-)