[Thomson] SDDRIVE Vidéo

Cette catégorie traite de développements récents pour nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!

Modérateurs : Carl, Papy.G, fneck

__sam__
Messages : 4554
Enregistré le : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ » 29 nov. 2018 00:33

Samuel.
A500 Vampire V2+, A1200(030@50mhz/fpu/64mb/cf 8go),
GVP530 (MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.

__sam__
Messages : 4554
Enregistré le : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ » 04 déc. 2018 01:54

Samuel.
A500 Vampire V2+, A1200(030@50mhz/fpu/64mb/cf 8go),
GVP530 (MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.

__sam__
Messages : 4554
Enregistré le : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ » 04 déc. 2018 19:06

(je me demande si le lien caché a été découvert. Plus d'infos plus tard....)
Samuel.
A500 Vampire V2+, A1200(030@50mhz/fpu/64mb/cf 8go),
GVP530 (MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.

Daniel
Messages : 11519
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par Daniel » 05 déc. 2018 09:25

C'est toujours le même constat : dans certaines parties on ne distingue pas grand chose, dans d'autres (en particulier les gros plans) c'est bien meilleur. Il n'y a pas de mystère : avec peu de pixels on ne peut pas afficher des détails très fins. Le son est excellent, la fluidité aussi, sauf dans quelques rares passages où l'écran doit être affiché entièrement à chaque trame.
Daniel
L'obstacle augmente mon ardeur.

__sam__
Messages : 4554
Enregistré le : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ » 05 déc. 2018 10:11

C'est un mode graphique spécial permettant d'afficher 60 couleurs simultanément sur le TO8 et qui passe sur émulateur (bonne nouvelle!). Comment? plus d'infos plus tard. Du coup la colorimétrie est carrément meilleure, au point qu'on peut prétendre à de la qualité photo, bien sûr pas en nombre de pixels (qui est pourtant bien meilleure que le 80x50 de cet été) mais au niveau du delta-E colorimétrique. Le tramage est utilisé mais beaucoup moins souvent, et du coup le flux se compresse mieux. Avec du débit SD bien plus elevé il devrait être possible de doubler la résolution horizontale et commencer à mieux voir certains détails, mais c'est déjà pas mal.
Samuel.
A500 Vampire V2+, A1200(030@50mhz/fpu/64mb/cf 8go),
GVP530 (MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.

Daniel
Messages : 11519
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par Daniel » 05 déc. 2018 12:08

Dans dcmoto, en plus des modes graphiques officiels des TO de dernière génération, j'avais commencé à programmer quelques modes non documentés. Ce n'est ni parfait ni exhaustif, car il faut en permanence comparer les résultats entre la vraie machine et l'émulateur et ça prend beaucoup de temps.

S'il y a d'autres modes intéressants pas encore programmés, il faut me le dire, je les ajouterai. Depuis longtemps je comptais programmer le mode spécial utilisé par un des membres du forum logicielsmoto, mais il n'a pas diffusé ses démonstrations, je manque donc d'éléments pour mettre au point l'émulation.
Daniel
L'obstacle augmente mon ardeur.

__sam__
Messages : 4554
Enregistré le : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ » 04 avr. 2019 14:29

S'il y en a qui sont encore intéréssés par le streaming de vidéo sur thomson, j'alimente un peu ce sujet.

Ces derniers temps, j'ai pas mal travaillé sur ce thème. Déjà j'ai remplacé un certain type de trame par un autre qui est plus simple à décoder, et même plus fréquent statistiquement parlant. Résultat: j'ai gagné 10 cycles sur le player par trame de 3 octets et les vidéos se compressent un peu mieux permettant soit un écran plus grand soit un FPS plus élevé.

Ensuite j'ai constaté qu'étant donné la résolution très faible possible pour la vidéo (on a un écran 80x50 en gros), le tramage aux basses intensités est super visible. C'est un problème classique avec tous les tramages: on allume 1 point sur 16 pour simuler un gris 12%, mais d'une part vu la résolution utilisée on voit plutôt des gros points au milieu de zones noires au lieu de voir un gris "sombre" (des points plus "fins" aideraient bien), et d'autre part, l'intensité non nulle minimal sur thomson est déjà très élevée (on est à un gris 100/255 de PC), donc on voit encore plus ces gros points. Résultat: aux basses intensités les vidéos ne montrent pas bien les détails. On a juste une bouillie super moche de pixels.

Comme indiqué ci-dessus, cette bouillie de gros pixel serait mieux si on pouvait avoir des points plus petits. Or j'ai trouvé une modification du dithering qui permet de diviser par 3 la taille des pixels dans les modes 7 et 9, c'est à dire les modes où l'on gère sur 2 ou 3 lignes différentes les composantes R, V et B. Avec ce tramage modifié, on garde une densité de points allumés plus élévé aux basses intensités tout en respectant la teinte (c'est similaire aux rendu sub-pixel utilisé dans la technologie ClearType), ce qui devrait amméliorer la visibilité des détails aux basses intensités. Voici ce que ca donne sur une rampe de gris:
dcmoto26.png
Mode #7
dcmoto26.png (7.96 Kio) Vu 141 fois
dcmoto23.png
Mode #9
dcmoto23.png (8.43 Kio) Vu 141 fois
Ceux qui ont testés les vidéos chez eux en mode 7 ou 9 ont constatés qu'on voit pas mal un effet de "vague" apparaitre lors des mises à jour de grandes portions d'écran. C'est lié au faible débit de SDDrive: on met à jour au mieux 2 octets en 169µs, ce qui veut dire qu'une mise à jour complète prends 675ms (30 VBL!). J'avais réduit ce phénomène en utilisant un entelacement non progressif des images, ce qui fait qu'on voit plutôt à ces moments là un mélange entre l'ancienne et la nouvelle image suivant les lignes. C'est mieux, mais pas parfait car on voit apparaitre des "franges" de composantes primaires (R,V ou B suivant les lignes) dans les zones à fort contraste entre deux images. C'est logique étant donné le fonctionnement des modes 7 et 9. Dans le mode 9 par exemple: une ligne sur 3 affiche le rouge, une autre ligne sur 3 affiche le vert et la dernière le bleu. Groupé par 3 on voit une vraie couleur, mais suivant l'entrelacement on pourra voir la ligne rouge de la nouvelle image sur le fond noir de l'image précédente: cela crée une frange rouge sur les bords à fort contraste ou pire on peut même voir un fantôme rouge de l'image à venir se superposer à l'image actuelle. Bref c'est super désagréable.

J'ai compris que pour casser ce phénomène il faut briser la régularité des lignes. Une ligne ne doit pas être toute rouge ou tout verte (ou bleue), mais panacher les couleurs. Ainsi lors de l'entrelacement ca n'est pas la composante rouge de l'image à venir qu'on voit, mais un mélange des couleurs de l'image à venir. C'est beaucoup plus discret. Au départ j'organisais la ligne en R/V/B/R/V/B/.. etc. On obtient un motif en diagonal.

Code : Tout sélectionner

   RVBRVBRVB ..B
   VBRVBRVBR .B.
   BRVBRVBVR B..
Malheureusement avec un entrelacement de 3 (une ligne sur 3 est changée à chaque image), on voit apparaitre des effets de moiré pas joli. C'est lié au fait que la periode de l'entrelacement et la periode des couleurs sur la ligne ne sont pas premiers entre eux. J'ai alors modifié ce motif diagonal pour avoir plutôt une sorte de zigzag (voir image "Mode #9" ci-dessus). Et là ca marche carrément mieux. On ne voit plus de moiré, et le mélange d'image se fait plutôt bien à l'écran.

Bref tout ca pour dire que j'ai pas mal bossé et ammélioré le rendu. Voyez par vous même sur les vidéos suivantes qui montre les modes 5 (80x200 16 couls):

7 (80x100 60couls virtuelles):

et 9 (80x66 216couls virtuelles):

Le mode 9 est vraiment très joli. Les dégradés sont super "lisse". Le nombre de couleurs virtuelles élevé compense bien la résolution médiocre (80x66 pixels). C'est impresionnant à voir sur vraie machine.
Samuel.
A500 Vampire V2+, A1200(030@50mhz/fpu/64mb/cf 8go),
GVP530 (MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.

Daniel
Messages : 11519
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par Daniel » 04 avr. 2019 16:07

Oui, c'est encore meilleur sur la vraie machine, à la fois pour le son et la vidéo.

Le son, on en a déjà discuté, c'est du à la fréquence d'échantillonnage en sortie de l'émulateur. Avec les dernières versions de dcmoto on peut la choisir, mais quel que soit le choix ce n'est pas aussi bon qu'un décodage analogique. Comme quoi les techniques modernes ne sont pas meilleures dans tous les domaines.

La video, avec l'émulateur, est moins fluide. L'émulateur affiche 50 écrans complets par seconde, alors que la vraie machine affiche octet par octet au rythme du balayage. Avec la vraie machine et un écran LCD c'est déjà mieux que sur PC. Je pense qu'avec un moniteur Thomson c'est encore mieux (il faut que j'essaye). Les défauts du matériel devraient minimiser la perception des gros pixels grâce au flou et aux bavures de l'écran cathodique.

Conclusion : Utilisez les vraies machines pour profiter pleinement des démonstrations !

Et vous pouvez félicitez __sam__ ! Pour apprécier les progrès, il faut comparer différentes versions de la même vidéo. Mon étalon est celle que je connais le mieux : Spinning a Mountain. Les dernières versions sont incontestablement meilleures que les premières. Tout ça va me donner du courage pour faire une version plus rapide de SDDRIVE (en remplaçant la liaison SPI par une transmission parallèle sur huit bits).
Daniel
L'obstacle augmente mon ardeur.

jasz
Messages : 679
Enregistré le : 05 oct. 2016 20:05
Localisation : Quelque part dans le 31

Re: [Thomson] SDDRIVE Vidéo

Message par jasz » 04 avr. 2019 17:25

C'est vraiment bien sur une vraie machine. Beau travail!

[ps] Je n'ai pas encore testé sous émulateur.

[edit] On peut aussi féliciter le concepteur de la sdDrive :wink:

__sam__
Messages : 4554
Enregistré le : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ » 04 avr. 2019 17:49

Merci Daniel! ([EDIT] et Jasz qui a posté pendant que j'écrivais ce message)

J'ai oublié de préciser que les fichiers SD sont à 13imgs/sec minimum, mais qu'avec l'entrelacement c'est un peu comme si on avait le double #astucec0d3rz ;) J'ai aussi oublié de préciser que j'ai construit des palettes "universelles" spéciales pour chaque mode >= #5 (les modes #3 & #4 sont avec la palette standard TO7/70). Ces palettes sont construites pour approcher aux mieux les couleurs standard malgré le mauvais gamma du Thomson. Étonnamment ce n'est pas une répartition linéaire des intensités qu'il faut prendre, mais un truc exponentiel (voir source pour les détails). Le mode #5 est quant à lui à la fois une palette optimisée combiné à un algo de tramage sous (c) --mais vieux, donc il y a prescription-- dont je me suis inspiré (il est utilisé pour les modes #3, #4, #10 et #11). Les modes #10 et #11 sont nouveaux. Ils concatènent toutes les images de la vidéo dans une très de grosse image et appelle mon algorithme de réduction de couleur pour trouver la meilleure palette Thomson pour l'ensemble des images de la vidéo. Le résultat n'est pas aussi bien que je l'espérais (sauf avec les trucs monochromes), donc je ne le mets pas en avant. C'est juste une curiosité.

Résumé des modes:
  • Mode #0 : 320x200. N&B compatible tout Thomson
  • Mode #1: 320x200. Une couleur par ligne. Compatible tout Thomson.
  • Mode #2: 80x200. Les 16 couleurs de la palette MO5. Compatible toute machine MO.
  • Mode #3: pareil mais pour TO.
  • Mode #4: 80x200. Palette spéciale. Compatible MO6.
  • Mode #5: pareil mais pour TO8/TO9+.
  • Mode #6: 80x100. 60 Couleurs vitruelles. Compatible MO6.
  • Mode #7: pareil mais pour TO8/TO9+.
  • Mode #8: 80x66. 216 Couleurs virtuelles. Compatible MO6.
  • Mode #9: pareil mais pour TO8/TO9+.
  • Mode #10: 80x200. 16 Couleurs déduite des images. Compatible MO6.
  • Mode #11: pareil mais pour TO8/TO9+.
Tout ce travail avait été fait +/- en préparation de la forever-party, mais comme je me suis rendu-compte que PulkoMandy n'avait pas un SDDrive mais un SDMoto, c'était tombé à l'eau et il a fallu se rabattre sur du plus classique et moins epoustouflant (d'où le résultat de cette année). Mais depuis étant un peu coincé chez moi j'ai repris tout ca et obtenu un truc que je trouve vraiment bien pour du matériel que je qualifierai de standard#2018. Tout le monde devrait avoir un SDDrive sur son Thomson! :D. Tu as tous mes encouragements pour une version "SDDrive x8 (bits)" (le futur standard #2020?). Avec ca, d'une part le chargement de n'importe quelle diskette thomson sera quasi instantanée, mais d'autre part le streaming video sera pratiquement à la vitesse maxi du 6809.
Samuel.
A500 Vampire V2+, A1200(030@50mhz/fpu/64mb/cf 8go),
GVP530 (MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.

Daniel
Messages : 11519
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par Daniel » 04 avr. 2019 18:12

C'est mon rêve. Une transmission sur 8 bits rend la carte SD aussi rapide que la RAM pour un accès séquentiel. Avec un Arduino ce serait une prouesse, il faudra peut-être un processeur plus rapide.
Daniel
L'obstacle augmente mon ardeur.

__sam__
Messages : 4554
Enregistré le : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ » 04 avr. 2019 19:03

Je me demande s'il faut une puissance énorme. La lecture en RAM d'un octet isolé ne peut pas se faire à moins de 4 cycles 6809. Il faut donc que l'interface à l'autre bout soit capable de lire et présenter sur un buffer 8bits les octets à la vitesse max de 250Ko/sec. Cela me semble compatible avec les vitesse de lecture de clef USB (mais peut-être pas en mode SPI 1bit, et sans doute avec un beau buffer pour amortir les latences). Même si cela se trouve, un truc simple comme un PIC serait suffisant pour ca.
Samuel.
A500 Vampire V2+, A1200(030@50mhz/fpu/64mb/cf 8go),
GVP530 (MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.

Daniel
Messages : 11519
Enregistré le : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par Daniel » 04 avr. 2019 20:59

PIC ou Arduino, je crois que c'est le même problème : on doit lire la carte SD en mode SPI, car l'autre mode n'est pas accessible sans payer d'énormes redevances à la SD Association. Donc il faut lire huit bits, les mettre dans un buffer et attendre un signal d'horloge pour recommencer, le tout en moins de 4 µs. Avec un Arduino à 16 MHz ça doit être jouable. On arrivait déjà à 116 Ko/s avec SDANIM7 : http://dcmoto.free.fr/bricolage/sdanim7/index.html
Daniel
L'obstacle augmente mon ardeur.

OlivierH
Messages : 47
Enregistré le : 22 janv. 2017 00:42
Localisation : AUCH (Gers)
Contact :

Re: [Thomson] SDDRIVE Vidéo

Message par OlivierH » 16 avr. 2019 13:54

Je suis époustouflé par le travail de Samuel sur l'encodage vidéo ! C'est vraiment top ! :)
Félicitations :)

Félicitation aussi à Daniel pour la partie hardware ^^

A ce propos, je crois avoir compris que SDAnim7 a un débit d'environ 120ko/s contre 20ko/s pour le SDDrive... c'est bien ça ?

Du coup c'est encore plus impressionnant d'arriver à faire ça avec le SDDrive :)

__sam__, est-ce que ton convertisseur vidéo est disponible quelque part ?
J'ai une furieuse envie de me générer une vidéo de Second Reality sur MO5 :D
Il n'y a que 10 sortes de gens. Ceux qui lisent le binaire, et les autres.

__sam__
Messages : 4554
Enregistré le : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: [Thomson] SDDRIVE Vidéo

Message par __sam__ » 16 avr. 2019 18:32

Oui SDVideo est 5 à 6 fois plus lent que SDAnim7. En gros dans SDAnim7, pour lire un octet.. et bien on le lit. Par contre avec SDDrive, il faut le reconstituer bit par bit. Si ARDrive aboutit, alors on pourra avoir des superbes vidéos. Pas forcément sur MO5 qui est limité question graphisme, mais sur sur les machines de 2nd génération (je pense à doubler voir quadrupler la résolution par exemple.)

Mon source est dispo dans le dernier lien du message: viewtopic.php?p=148810#p148810

[EDIT] Arg, je viens de tester sur MO5 (émulé), et il y a un bug. Je corrige ca... stay tuned.

[EDIT2] Corrigé. J'en ai profité pour mettre un nouveau mode (no 12). Honnêtement la démo est plutôt sombre et la palette thomson n'a pas vraiment de couleur qui correspondent. Du coup la démo ne sorte pas terriblement. M'enfin, le mieux pour MO6 est, selon moi le fichier 4_XXXX.sd (qui approxime le mieux les teintes sombres), et le 1_XXXX.sd (ou peut être le 12_XXXX.sd) pour MO5.


Mes nouveaux sources sont téléchargeables >>ici<< (lien temporaire, user=ce qu'on veut, passwd=sdvideo)
Samuel.
A500 Vampire V2+, A1200(030@50mhz/fpu/64mb/cf 8go),
GVP530 (MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.

Répondre