Streaming Video+Son sur vieilleries

[6502man]

[Daniel]

Cette idée de "streamer" le code à exécuter est assez géniale. Les problèmes d'alignement du code et d'interruptions rencontrés sur 8088 ne concernent pas les Thomson, de ce côté-là c'est nettement plus simple.

Tous les détails donnés sur l'optimisation sont aussi applicables à ma méthode des "deltas", qui pourrait être bien améliorée. J'applique les modifications en parcourant la mémoire vidéo en séquence, alors que "8088 Domination" saute d'un point à un autre. Je suis incapable de dire quelle méthode est la plus rapide. La réponse dépend probablement des cas de figure rencontrés, il faudrait faire des essais pour choisir...

L'intérêt de ces productions est de stimuler l'esprit de compétition. Maintenant le challenge est de faire mieux sur MO5, mais la barre est placée très haut. Dans un premier temps je vais surtout essayer d'avancer sur l'aspect matériel, dès mon retour de vacances. Si Fool-DupleX travaille aussi de son côté, un nouveau périphérique Thomson sera peut-être disponible pour Noël... Ca n'empêche pas de réfléchir en parallèle sur une future démo qui gagnera dans toutes les compétitions

[Carl]

Daniel, bravo pour cette nouvelle démo !

Carl

[Daniel]

En réalité, c'est une vieille démo de 2013 que je viens tout juste de ressortir de mes archives

[Carl]

si je filme cette démo et que je la post sur youtube, je vais me prendre un rappel pour droit d'auteur, signe de la qualité audio de la démo (déjà vécu avec la démo de Stan Getz)

[Daniel]

Remarque, sur youtube il y a la vidéo originale ayant servi à faire la démo
https://www.youtube.com/watch?v=Hw_ZYn6mTpY

[Carl]

Carl

[__sam__]

Arf, la video "Bad Apple" a été portée sur C64 et tout tient sur une seule face de D7 (170ko?). Chacune des 2200 images fait environ 70octets qui sont streamés à 12fps depuis le disk!
==> http://www.pouet.net/prod.php?which=63649


Je suis bluffé!

sam (et aussi jaloux )

[Carl]

[Fool-DupleX]

Cette version m'impressionne beaucoup plus, surtout depuis un lecteur de disquette.

Cela étant dit, il y a encore beaucoup de progrès à faire sur Thomson côté disquette. PrehisTO a fait des miracles en termes de capacité (e.g. 920 Ko au lieu de 640 Ko sur une disquette 3"1/2, sans compression) et a notablement optimisé les routines, mais que je sache, personne n'a encore essayé de synchroniser finement la lecture avec autre chose (animation) en profitant des temps d'attente. On ne peut pas faire n'importe quoi, mais y'a des possibilités.

Rajouter le son en plus me semble proche de l'impossible par contre. Mais en réalité, si on pouvait se débarasser du moniteur, ca ouvrirait des portes formidables. Notre OS-9/MO5 par exemple remplace completement la ROM originale et on voit une nette difference. Le débat est toujours le même : qu'est-ce qui est tricher et qu'est-ce qui ne l'est pas ? J'aurais tendance a dire que des que la machine originale est modifiee, il y a triche. Que dire alors d'un peripherique moderne adossé a la machine comme l'înterface SD de Daniel ?

[__sam__]

Pour faire du son: il n'y a qu'à organiser les données sur disk pour que le déplacement de la tête de lecture fasse de la musique:


Bon là l'exploit n'est pas au niveau de transfert floppy->C64, mais dans la compression. 70 octets par images. C'est vraiment peu ce qui explique les divers artefacts qu'on voit, mais le résultat est bluffant.

De ce que j'ai compris de la technique les 2200 images sont divisées par paquet de 128 (environ 10secs par paquet). Sur ce paquet un algo d'optimisation (qui contient un algo génétique) trouve un ensemble de 256 blocs 16x16 optimaux pour reconstruire chacune des 128 images de la séquence (c'est vraiment là le coeur de l'optimisation à mon avis). Pour faire une image 320x200 soit 20x12 blocs 16x16 il faut décrire 240 tels blocs, ce qui fait que l'encodage "brut" d'une image ne coute que 240octets (chacun contenant le numéro de blocs dans l'ensemble des 256 trouvés). Si la dessus on encode que seuls les blocs qui ont changés et qu'on compresse le tout avec un algo lz, on arrive à encoder les 128 images dans 10ko, soit environ 70-80 octets par image à l'arrivée.

Je suis vraiment surpris que seulement 256 blocs élémentaires suffisent pour décrire 128 images. Le fait que la vidéo soit uniforme doit beaucoup aider. L'algo de recherche des 256 blocs optimaux m'intrigue. Je ne vois pas trop comment ce genre d'algo pourrait se coder autrement que par programmation génétique (et même encore: c'est quoi un croisement de population sur des blocs de 16x16 ?). En plus est-ce que la programmation génétique donne le meilleur ensemble de blocs ou est-ce qu'une recherche par force brut ne donnerait pas un meilleur résultat.

Je me demande si le principe des algos de réduction de couleurs ne pourrait pas être utilisé pour réaliser la sélection des meilleurs 256 blocs car après tout quand on réduit une image de millions de couleurs à une palette de 16 on a fait aussi une sorte de compression. C'est juste la dimension de l'espace de recherche qui est différent: 3 dimensions pour une composante couleur et 16x16=256 dimensions pour un bloc 16x16. Petite différence: les 256 dims ne sont pas continues: c'est 0 ou 1. C'est gênant, mais si on prends la transformée de Fourier de ces blocs on doit pouvoir à la fois réduire la dimension de l'espace de recherche tout en introduisant de la continuité.... hum.... à réfléchir.

Bref... BadApple64 est démo expérimentale intéressante qui stimule beaucoup mes cellules grises. Ca fait du bien!

[Fool-DupleX]

Sur ce paquet un algo d'optimisation (qui contient un algo génétique) trouve un ensemble de 256 blocs 16x16 optimaux pour reconstruire chacune des 128 images de la séquence ...

Pour être tout à fait franc, c'est a peu près l'idée qui m'est passée par l'esprit quand j'ai vu les premières secondes de la video. Il était évident qu'il y a un ensemble de motifs prédéfinis. Comment déterminer l'ensemble optimal ? Mon idée consistait a découper toutes les frames de la video originale en carrés, établir la liste exhaustive de tous les motifs, puis faire un calcul de similitude et une répartition par cluster, les 256 motifs se trouvant le plus près des barycentres des clusters étant ceux recherchés.

Cette technique fonctionne admirablement pour du noir et blanc et il fallait y penser.

heu pour le son par disquette j'ai des doutes quand même ... faisable en theorie, mais en pratique ...

[__sam__]

Mon idée consistait a découper toutes les frames de la video originale en carrés, établir la liste exhaustive de tous les motifs, puis faire un calcul de similitude et une répartition par cluster, les 256 motifs se trouvant le plus près des barycentres des clusters étant ceux recherchés.

Oui c'est du k-mean (k=256). J'avais utilisé ca à une époque pour faire de la réduction de couleurs. Par contre je crois que ca rame pour les grosses valeurs de "k" car il faut comparer chacun des 240*128 = 17920 échantillon à chacun des 256 clusters et leur faire changer de cluster s'ils sont plus proche d'un autre que celui actuel. Il y a sans doute des algos optimisés pour réduire les calculs et les comparaisons.

Etablir la liste de tous les blocs 16x16 dans les 128 image est jouable. Mais comment établir une notion de "barycentre" qui ait du sens sur des blocs 16x16 ? Tu sommes tous les pixels de même coordonnées x/y et si c'est majoritaire tu définis le pixel du barycentre à 1 et 0 sinon ? Je ne sais pas si ce barycentre a les bonnes propriétés pour être un bon représentant de son cluster. Autre question, est-ce que la distance de Hamming (==nombre de pixels non identiques entre 2 blocs) est une bonne distance pour ce barycentre ?

Il faudrait essayer pour voir surtout que j'ai réussi à faire la musique pour thomson.

[Fool-DupleX]

Hey mais dis donc ca sonne vachement bien, en plus avec l'affichage ! Mais il doit pas rester grand chose pour l'animation, si ?

J'étais parti en premiere approximation sur une distance de Hamming mais je sais par experience que ce n'est pas la meilleure metrique de similitude pour les images, car il y a des "collisions" (on peut construire un cas avec 3 images a b c ou a est similaire à b, b est similaire à c, mais a et c sont totalement dissimilaires). C'etait juste une simple idée pour me convaincre que ce n'est pas si difficile c'est peut-être tout faux !

Il y a sans doute des algos optimisés pour réduire les calculs et les comparaisons.

Il y a surtout des GPUs de tueur de nos jours ... un peu de Cuda et on en parle plus ...

[__sam__]

Hey mais dis donc ca sonne vachement bien, en plus avec l'affichage ! Mais il doit pas rester grand chose pour l'animation, si ?

Non il ne reste plus rien: l'anim mange le reste du cpu de libre. Elle tourne plein pot à plusieurs FPS en faisant du filtrage temps reel sur la courbe pour la rendre plus lisse sinon on voit des créneaux tout moches. Mais comme il n'y a pas de drum, ca mériterait que je fasse un nouveau player asynchrone plus léger et donc plus rapide. Au fait tu as vu comme le binaire n'est pas très grand ? Et il n'est pas EXOmizerisé. En fait l'encodage utilisé regroupe les bouts de musique identiques dans une bibliothèque récursive de motifs musicaux récurrents, factorisant ainsi efficacement les redondances (le morceau est réduit de 50% grâce à ca). Oui oui le player réalise bien une décompression lzw-like à la volée de la musique. C'est très efficace: le Bollero de Ravel passe de 8ko à 569 octets grâce à ca (http://pastebin.com/adGnXtA4).

J'étais parti en premiere approximation sur une distance de Hamming mais je sais par experience que ce n'est pas la meilleure metrique de similitude pour les images, car il y a des "collisions" (on peut construire un cas avec 3 images a b c ou a est similaire à b, b est similaire à c, mais a et c sont totalement dissimilaires).

C'est l'inégalité triangulaire qui n'est pas bien respectée. Apparemment le k-mean sur des données binaire est un truc assez connu. Mais la distance n'est pas celle de Hamming/manathan, mais la distance de Jacquard qui mesure la similarité entre des données binaires. http://fr.wikipedia.org/wiki/Indice_et_ ... s_binaires

Visiblement les staticiens sont super habitués à faire des clusters sur des données booléennes. Il y a toute une littérature là dessus. Cependant je crois qu'ils utilisent une notion de k-median plutot que k-mean.. mais j'avoue que j'ai du mal à comprendre la notion de médiane quand on a du 0/1. C'est peut être le barycentre "majoritaire" dont je parlais au début.

C'etait juste une simple idée pour me convaincre que ce n'est pas si difficile c'est peut-être tout faux !

Je te dirais bien que ca se tente quand même... C'est le genre de trucs fou dans lequel je me suis embarqué en me disant qu'après tout le dither devrait pouvoir s'accommoder des contraintes 8x1 qui ne sont juste qu'une source d'erreur supplémentaire. A l'arrivée on arrive à avoir des images très fines et très colorées, même sur un vieux TO7 et sa pauvre palette de 7couls.

Il y a surtout des GPUs de tueur de nos jours ... un peu de Cuda et on en parle plus ...

Je sais qu'il y a des gens qui font de l'optim en vue de compression avec le GPU pou faire de la recherche "force brute" des meilleurs graines d'un générateur aléatoire. Ainsi certains on pu encoder Mona Lisa en 256 octets sur atari 800XL: http://www.pouet.net/prod.php?which=62917