ANN Animator en GPL - Page 1

Je n'avais pas tenu ma langue, mais c'est désormais officiel, les sources d'Animator, notre media player made in Removers, sont désormais disponible sur SourceForge.


Pour rappel, Animator est une chouette moteur pour jouer des vidéos en full-screen. A l'origine, en 1997, il s'agissait de poser les bases d'un nouvelle architecture pour faire péter des records de performances brutes en vitesse de playback... enfin, sur Falcon 030 de base du moins. Pour la petite histoire, ils avaient fini par tomber ! Pour le Cinépak en 1998, puis pour l'Indéo 3.2 en 1999 (entièrement désassemblé puis réécrit de zéro, aujourd'hui je comprends à peine mon propre code ). Bref, Animator était et reste un chouette projet, prometteur... sauf qu'il y a déjà Aniplayer qui est vachement bien et plein d'autres projets qui mériteraient aussi que je m'y investisse


Le fait que ce soit en GPL, ça ouvre maintenant la voie à plein de choses super cool :
[ul]
[li]un véritable effort commun dans le domaine de la vidéo, partagé entre Didier, moi et Guillaume (il serait temps!!)
[li]des variantes du moteur pour des intégration faciles dans des démos
[li]une adaptation sur Jaguar (dans la revovers' lib ?? )
[li]des espoirs d'améliorations. Le système de synchronisation demande qu'à évoluer (j'ai des idées qui se sont précisées en préparant la release GPL, mais ça se bouscule vite, tant le domaine est vaste), la gestion des QT aussi avec l'intégration d'un algo de gunzip...
[/ul]
Enfin bref, c'est cool de se dire que je partage ça, et qu'à l'avenir on pourrait s'y mettre à plusieurs !


Au fait, je poste ça dans le forum de développement parce que pour l'instant, ce n'est pas une release binaire. Certes les sources s'assemblent ok, elles apportent quelques nouvelles fonctionnalités, et j'y ai pas laissé beaucoup de bugs connus, mais pour moi la priorité était d'abord de partager le projet.

Les bonnes volontés sont donc les bienvenues, et j'assure les service après-vente pour permettre à tous les curieux de se plonger dans le code !

Super !!!

C'est une tuerie ce prog, surtout sur Falcon de base !

Longue vie au projet ^^

Et ça gère le MPEG aussi ?


Sinon, quand je clique sur All Files sur Sourceforge, pour le moment ça a l'air vide... c'est normal ?

je pense que pour le moment tout est dans le dépot Subversion...

oui, le svn marche nickel

pour récupérer les sources:

svn co https://removers.svn.sourceforge.net/svnroot/removers/animator/trunk animator

super stabylo pour cette release

Y'a même des commentaires en français sans fautes, c'est beau !

Et la décompression GSM 68K/DSP, c'est
(vous étiez des fous quand même... j'ai jamais vu aucun son ou vidéo utiliser ce format )

Zerosquare (./7) :
Y'a même des commentaires en français sans fautes, c'est beau !

Et la décompression GSM 68K/DSP, c'est
(vous étiez des fous quand même... j'ai jamais vu aucun son ou vidéo utiliser ce format )

tu rigoles, j'ai le générique de Goldorak qui utilise le GSM pour l'audio... et l'indeo 4.x pour la vidéo
on a au moins le son comme ça

Bravo pour cette initiative !

bonne nouvelle, ça donnera peut etre une seconde vie a la chose

oui espérons

ça serait chouette en effet

bon, pour ce qui est d'un portage Jag, comme me l'a très justement fait remarqué une fois Zero, pas sur que ça soit très pertinent...

Disons que sans média de stockage de masse pour les vidéos, j'ai un peu de mal à voir l'intérêt.

Avec la JagCF (ou à la rigueur le JagCD pour les maso ) pourquoi pas. Mais sans remettre en question le boulot énorme que vous avez dû faire pour Animator, les codecs vidéos commencent à dater sérieusement, je sais pas si le résultat serait meilleur que le Cinepak qu'on a déjà. Pour ce qui est du son, le GSM a un bon taux de compression, mais niveau qualité c'est pas franchement utilisable ; l'ADPCM pourrait par contre resservir

Pour ma part, je suis en train de voir si on peut faire tourner une version simplifiée et modifiée du MJPEG sur la JagCF. Même si Animator ne gère pas ce format, il y a peut-être dedans des concepts/algos intéressants à reprendre pour la lecture de la vidéo, non ?

oui, les codecs video datent sérieusement, mais ce sont surement les seuls qui sont jouables pour une Jag (le MJPEG sur Jaguar, j'aurais tendance à ne pas y croire par exemple: bien trop couteux)

l'avantage de ce cinepak là, c'est qu'il y a les sources, et qu'on peut produire les vidéos avec des outils "standards" sur PC (genre virtualdub)

pour les codecs sonores, effectivement, il y en a peut-être quelques-uns qui peuvent servir (évidemment le GSM n'en fait pas partie , vu comme ça bouffe)

ce qui peut être intéressant, c'est le système de synchro, c'est le point critique d'un player video à mon avis, mais je crains que le code soit très Falcon-dépendant
mais je crois que stabylo a d'ailleurs des idées pour en faire un nouveau plus "puissant"

Oui, c'est ce à quoi je pensais aussi. J'avais déjà réfléchi un peu à la question, et créé un convertisseur de vidéo et du code côté Jaguar, qui exploitent le fait que sur Jag l'audio et la vidéo dérivent de la même base de temps (ce qui n'est pas le cas sur PC par exemple). Si vous avez des idées, c'est toujours bon à prendre

SebRmv (./14) :
ce sont surement les seuls qui sont jouables pour une Jag

Exactement. Je me suis justement aperçu cette semaine qu'on retrouve dans Animator exactement les mêmes codecs qui étaient présents dans le dernier Quicktime 4.0 pour Mac 68k.

C'est finalement pas un hasard. Les codecs ultérieurs (Indéo 4 et 5, Sorenson et cie) ne passaient pas sur 68k, ils avaient été compilés que pour PPC.

SebRmv (./14) :
(le MJPEG sur Jaguar, j'aurais tendance à ne pas y croire par exemple: bien trop couteux)

Pour compléter, il me semble que le MJPEG c'est en gros une image JPEG par frame. Le DSP de la JagCF serait essentiel pour arriver à la prouesse de restituer ce type de flux à une vitesse correcte.

Il faut voir aussi que la raison d'être du MJPEG, c'est de pouvoir facilement monter les vidéos avec un accès image par image. Si j'ai bien compris il n'y a pas de codage différentiel entre 2 images successives. Donc ça bouffe beaucoup de bande passante pour une fonctionnalité pas forcément utile sur la Jag.

Pour la Jag, je dirais que c'est rejouer des vidéos qui compte. La bande passante perdue à cause de l'absence de codage différentiel, ça pourrait virer au beau gâchis. Moralité, autant faire du MPEG, tout simplement. Quitte à se limiter aux I-frames et P-frames lors de la compression, pour éviter les B-frames (double codage différentiel avec l'image précédente ET la suivante) parce qu'elles sont un peu lourdes à décoder.

SebRmv (./14) :
l'avantage de ce cinepak là, c'est qu'il y a les sources, et qu'on peut produire les vidéos avec des outils "standards" sur PC (genre virtualdub)

Je ne peux pas dire mieux

SebRmv (./14) :
pour les codecs sonores, effectivement, il y en a peut-être quelques-uns qui peuvent servir (évidemment le GSM n'en fait pas partie , vu comme ça bouffe)

Toutafé, trop coûteux mon fils A oublier !

SebRmv (./14) :
ce qui peut être intéressant, c'est le système de synchro, c'est le point critique d'un player video à mon avis, mais je crains que le code soit très Falcon-dépendant
mais je crois que stabylo a d'ailleurs des idées pour en faire un nouveau plus "puissant"

Oui, j'ai quelques améliorations à apporter à cette partie.

De manière générale, le système actuel est basé sur 3 pseudo-threads. Du plus prioritaire au moins prioritaire : (1) le décodage du son, (2) le chargement depuis le disque, (3) le décodage de la vidéo.

Le (1) est basé sur l'interruption de fin de son, avec toujours un bloc de son pré-décodé d'avance. A la fin d'un bloc de son, on lance la lecture du suivant et on décompresse celui qui vient après.

Le (2) est en interruption VBL. Il suit l'avancement du (1) et du (3) et s'assure de leur fournir les données avant qu'ils en aient besoin. Dans la stratégie actuelle, il s'assure aussi de lire les données séquentiellement : la tête de lecture du disque de revient JAMAIS en arrière.

Le (3) est le fil d'exécution normal en IPL 3. Il décode les images dans l'ordre, et vérifie si le son n'a pas passé un jalon de key-frame. Le cas échéant, il saute à la key-frame en question.

Simple !

Ce que je compte ajouter (4) c'est l'utilisation du timer système 200 Hz (enfin.. seulement 1 sur 2 pour être compatible avec le 100 Hz d'aranym ) pour ajouter une ligne temporelle constituée de points de synchro pour éviter de se synchroniser uniquement sur le son. Le (3) se synchronisera alors sur ce (4), au lieu de stopper toute synchro quand le (1) est au chômage technique, c'est-à-dire quand il n'y a pas (ou plus) de son.


Donc oui, le (1) s'appuie sur une capacité du hardware STe/TT/Falcon. Le (2) et le (3) on peut le faire sur n'importe quel hardware.

Donc pour reproduire le système (imparfait) actuel sur Jag, est-il possible d'avoir une interruption de fin de son ?

Et pour le (4) à venir, on devrait pouvoir trouver un timer 100 Hz équivalent sur la Jag, non ?

ah bah voilà, parfait, le mieux était qu'effectivement stabylo nous parle du comment ça marche (c'est en tout cas bien plus sérieux que dans Aviplayer par exemple )

pour le (1), je ne me rappelle plus trop si le DSP peut déclencher une interruption du GPU ou du CPU
si oui, alors on devrait pouvoir émuler ce comportement
si non, bah, euh, ça risque d'être plus tendu
(pour rappel, le son sur Jag, c'est tout à la mano... pour te faire une idée, ça ressemble à comment on rejoue des samples sur STF)

(2), (3) et (4) aucun problème en effet

Je suis en partie d'accord avec ce que dit Stabylo en ce qui concerne le MJPEG, mais il ne faut pas mettre la charrue avant les bœufs ! Avant de penser à décompresser du MPEG (même sans les trames B), il faudrait déjà arriver à décompresser du "simple" MJPEG.

Alors certes c'est du gâchis de ne pas faire de compression sur plusieurs images, mais je pense que ça demande moins de puissance de calul pour le décodage, et ça a l'avantage d'avoir un débit constant (ce qui n'est pas vraiment possible avec le MJPEG : il y a des cas où on est obligé de rajouter des trames I parce que la prédiction est insuffisante, par exemple lors d'un changement de scène). De plus la qualité est constante aussi, les blocs ne deviennent pas subitement visibles quand il y a beaucoup de mouvements, truc que je déteste par dessus tout

Pour ce qui est de la synchro, c'est grosso modo ce que j'utilise aussi. Par contre, je ne vois vraiment pas l'intérêt du (4) : vu que l'horloge audio est la plus critique et la plus précise, ça complique les choses d'en ajouter une autre et ça n'apporte rien de plus (en plus c'est complètement redondant sur Jaguar, vu qu'il n'existe qu'une seule horloge physique dans le système). Pour le cas où tu as de la vidéo muette, on peut substituer un timer fixe, ou plus simple encore, tricher en jouant des échantillons audio vides