[Thomson] Vidéo avec son en streaming
Modérateurs : Papy.G, fneck, Carl
Re: [Thomson] Vidéo avec son en streaming
C'est un net progrès, mais il n'y aura pas de miracle par rapport à la version précédente, seulement la satisfaction d'avoir fait le mieux possible avec les contraintes imposées. Finalement, c'était l'objectif, et il va être atteint
Reste encore à modifier le sketch Arduino pour le nouveau player...
Reste encore à modifier le sketch Arduino pour le nouveau player...
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7923
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] Vidéo avec son en streaming
Ah la vache!__sam__ a écrit :Et les résultats? Ben ca encode... suspens...
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [Thomson] Vidéo avec son en streaming
Effectivement, ça change de Kylie Minogue. Le rythme est plus lent et il y a moins de changements de plan
Tu as oublié le son
Tu as oublié le son
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7923
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] Vidéo avec son en streaming
Meuuuh non!
En fait la vache est silencieuse dès l'origine, mais du coup chacun peut faire ses propres bruitages.
Les autres vidéos plus tard.. j'ai pas eu le temps d'envoyer le zip ce matin.
En fait la vache est silencieuse dès l'origine, mais du coup chacun peut faire ses propres bruitages.
Les autres vidéos plus tard.. j'ai pas eu le temps d'envoyer le zip ce matin.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
-
- Messages : 7923
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] Vidéo avec son en streaming
- http://www.cjoint.com/doc/15_10/EJjpteC ... -On-Me.zip
- http://www.cjoint.com/doc/15_10/EJjpuxV ... Pjanoo.zip
- http://www.cjoint.com/doc/15_10/EJjpvY5 ... ffects.zip
- http://www.cjoint.com/doc/15_10/EJjpxa8 ... Faster.zip
- http://www.cjoint.com/doc/15_10/EJjpzcp ... Color-.zip
- http://www.cjoint.com/doc/15_10/EJjpAxI ... Video-.zip
- http://www.cjoint.com/doc/15_10/EJjpEs3 ... 9rique.zip
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [Thomson] Vidéo avec son en streaming
Ce serait chouette si vous réalisiez, de temps en temps, une petite vidéo des travaux en cours :-)
-
- Messages : 7923
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] Vidéo avec son en streaming
Ben, c'est plus grand que je prévoyais. En fait il y avait un bug dans mon algo de compression fictive (guess_zoom) qui me faussait le calcul du zoom. En outre j'accepte que le début descende jusqu'à 8fps, ce qui ajoute 20% de bande passante supplémentaire.__sam__ a écrit :Alors ?
Les couleurs sont magnifiques! C'est quand même formidable d'avoir des videos "photo-réalistes" sur thomson.
Je pense pouvoir adapter le principe d'alternance RAMA/RAMB au niveau du bloc aussi sur MO6 et TO9 (qui n'a pas la possibilité de mapper la vidéo à une uatre adresse que $4000).. et par là même ouvrir la voie sur la modification d'attributs couleurs sur TO7 et MO5 (à suivre), ce qui serait vraiment très bien avec le tramage couleur de http://forum.system-cfg.com/viewtopic.p ... 523#p99523
Mais.. car il y a un mais... lors des changements trop brutaux, on voit apparaitre le motif en peigne des colonnes RAMA/RAMB sur une petite zone (10-12 lignes), mais visible quand même. C'est dommage Je me demande si c'est un effet réel ou un effet fictif lié à l'échantillonnage de l'affichage réalisé par l'émulation. Il faudrait adapter le code arduino pour ca (hum.. ).
Maintenant si l'effet se produit aussi sur machine réelle, il faudra peut-être ne plus basculer RAMA/RAMB au niveau d'un bloc de 512 octets, mais plus souvent: 2 ou plus de fois par bloc. C'est une analyse rigolote de la décomposition de 512 en morceaux réguliers 512=a*(b*c+1) où le 1 représente l'octet son et permet la commutation RAMA/RAMB, "a" ne nombre de morceaux, b la taille d'une trame, et c le nombre de fois. Le player à base de trames de 7 octets est traduit par a=1,b=7,c=73: on a un seul gros morceaux de 73 trames de 7 octets.
Essayons de voir avec a=4 histoire d'avoir plus qu'un seul gros morceau dans le bloc. Il vient b*c = 127... or 127 est premier. Il n'y a donc aucun b ni aucun c qui convienne. La vache, c'est pas facile comme équation ce truc!
Amis de l'arithmétique: bonjour!
Avec a=2, on a b*c=255=3*5*17, donc soit:
- b=3 et c=6*17.. mais un bloc de 3 octet c'est pas beaucoup: 1 octet son, 1 octet déplacement, 1 octet audio. On oublie.
- b=5 c=3*17, mais dans 5 octet on peut faire passer 1 son et 4 video, mais aucun déplacement. Ca ne va pas. On oublie.
- b=15 c=17... 15 octets par blocs, ca nous fait 1 octet son sous les 14 octets vidéos, soir une fréquence audio de 5khz.. C'est trop bas. On oublie!
- les autre combinaisons ont b>=17... c'est pareil la fréquence son est trop faible
a suivre....
Dernière modification par __sam__ le 09 oct. 2015 19:59, modifié 3 fois.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [Thomson] Vidéo avec son en streaming
Je reste sans voix devant un tel exploit. La technique est au point, personne ne pourra faire plus rapide sans modification du matériel. Les seules améliorations possibles sont dans les réglages fins de l'image, mais ça ne changera pas beaucoup le résultat. Le son est tellement bon qu'il n'est pas possible de faire mieux avec 6 bits.
La démo ultime consisterait à remplacer les vidéos existantes par une création originale pour Thomson, réalisée par de vrais artistes (pas des petits programmeurs besogneux comme moi ), et alors le TO8 pourrait rivaliser avec l'Amiga, voire le dépasser
Pour revenir sur terre, __sam__, as-tu modifié le programme Arduino ? Sinon donne-moi le timing et j'essaierai de le faire fonctionner avec la vraie machine.
Pour t'embêter un peu : les pixels carrés vont paraître un peu étroits sur un moniteur Thomson ou un téléviseur 4/3, et un peu larges sur un téléviseur 16/9. C'est ce que j'ai constaté avec les vidéos précédentes. Mais je n'ai pas de solution miracle, à moins de faire plusieurs versions.
La démo ultime consisterait à remplacer les vidéos existantes par une création originale pour Thomson, réalisée par de vrais artistes (pas des petits programmeurs besogneux comme moi ), et alors le TO8 pourrait rivaliser avec l'Amiga, voire le dépasser
Pour revenir sur terre, __sam__, as-tu modifié le programme Arduino ? Sinon donne-moi le timing et j'essaierai de le faire fonctionner avec la vraie machine.
Pour t'embêter un peu : les pixels carrés vont paraître un peu étroits sur un moniteur Thomson ou un téléviseur 4/3, et un peu larges sur un téléviseur 16/9. C'est ce que j'ai constaté avec les vidéos précédentes. Mais je n'ai pas de solution miracle, à moins de faire plusieurs versions.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7923
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] Vidéo avec son en streaming
La modif de l'arduino me fait un peu peur. Je ne l'ai pas encore modifié.
Les timings sont simple car le motif de base asm est: LDA(4)/STA(4)/LDB(4)/ABX(3)/LDA(4)/LDB(4)/STD(5)/LDB(4)/ABX(3)/LDA(4)/LDB(4)/STD(5) donc les accès à l'arduino en prenant comme point de départ la fin du premier STA(4) (acquitement+son) sont à 4, (7,4,9), (7,4,9)
Question bande passante, avoir 20khz sur le son est sans doute trop. On ne percoit pas de différence avec 14khz. Or si on revient à des trames non plus de 7 octets mais de 10, on peut mettre à jours 6 octets vidéos par octet son à 14khz. Le débit video est pas mal augmenté avec ces trames à 10 octets. On a alors le découpage 512=2x(25x10 + 5 + 1). Il y aurait des demi-trames de 5 octets. J'aime pas trop.
Concernant la VIDEO.. dès que ca tourne sur arduino ca devrait pouvoir se faire... mais il ne me reste plus qu'une semaine bien chargée avant d'être loin des thomson (mais proche de l'amiga cassé).
Les timings sont simple car le motif de base asm est: LDA(4)/STA(4)/LDB(4)/ABX(3)/LDA(4)/LDB(4)/STD(5)/LDB(4)/ABX(3)/LDA(4)/LDB(4)/STD(5) donc les accès à l'arduino en prenant comme point de départ la fin du premier STA(4) (acquitement+son) sont à 4, (7,4,9), (7,4,9)
Question bande passante, avoir 20khz sur le son est sans doute trop. On ne percoit pas de différence avec 14khz. Or si on revient à des trames non plus de 7 octets mais de 10, on peut mettre à jours 6 octets vidéos par octet son à 14khz. Le débit video est pas mal augmenté avec ces trames à 10 octets. On a alors le découpage 512=2x(25x10 + 5 + 1). Il y aurait des demi-trames de 5 octets. J'aime pas trop.
Concernant la VIDEO.. dès que ca tourne sur arduino ca devrait pouvoir se faire... mais il ne me reste plus qu'une semaine bien chargée avant d'être loin des thomson (mais proche de l'amiga cassé).
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
-
- Messages : 7923
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] Vidéo avec son en streaming
Pour l'effet "peigne" j'ai une théorie qui si elle s'avère juste est ennuyeuse.
Ce n'est probablement pas un artefact de l'émulateur, mais le résultat des deux flux fonctionnant en parallèle. Si l'un des deux flux prend de l'avance sur l'autre parce que localement ses colonnes se compressent mieux, il va prendre de l'avance sur l'autre et quand chacun des flux aura épuisé son bloc avant l'autre, le peigne commencera à apparaitre. Or le phénomène est cumulatif: le déphasage entre les deux flux va s'accumuler si par malchance le 2eme flux a des colonnes qui continuent à mieux se compresser.
Ce qui nous sauve c'est qu'en fin d'écran il y a une légère attente avant de repartir au début. Si le flux en retard arrive en fin d'écran pendant l'attente, les deux repartent à 0 en même temps. Donc le cumul ne depasse pas le dessin d'une image.
En outre il est peu probable qu'un seul des deux flux prennent de l'avance en permanence. Parfois ce sera l'un qui prendra de l'avance, parfois ce sera l'autre, et en moyenne ca se compense à peu près. Alors oui en moyenne, mais autour de cette moyenne il y a de la dispersion donc il n'est pas illogique de voir apparaitre de temps le temps autour d'une série d'images aux propriétés de compressions caractéristiques un léger déphasage.
(punaise, c'est tellement compliqué comme situation, que je ne suis pas certain d'avoir bien expliqué le problème)
Si cette théorie est exacte, je ne sais pas comment empêcher le déphasage. Ce que j'imagine naïvement est d'introduire du bruit dans l'image pour casser les propriétés de compressions d'un flux par rapport à l'autre. Mais franchement, casser la compression n'est pas glorieux.
S'il y en a qui ont suivis: Quelqu'un aurait-il une idée géniale pour forcer "automatiquement" les flux à se resynchroniser si l'un prend du retard sur l'autre ? (sachant qu'ils ne sont pas vraiment calculés en parallèles, mais séquentiellement, c'est à dire sans possibilité de retour arrière).
Ce n'est probablement pas un artefact de l'émulateur, mais le résultat des deux flux fonctionnant en parallèle. Si l'un des deux flux prend de l'avance sur l'autre parce que localement ses colonnes se compressent mieux, il va prendre de l'avance sur l'autre et quand chacun des flux aura épuisé son bloc avant l'autre, le peigne commencera à apparaitre. Or le phénomène est cumulatif: le déphasage entre les deux flux va s'accumuler si par malchance le 2eme flux a des colonnes qui continuent à mieux se compresser.
Ce qui nous sauve c'est qu'en fin d'écran il y a une légère attente avant de repartir au début. Si le flux en retard arrive en fin d'écran pendant l'attente, les deux repartent à 0 en même temps. Donc le cumul ne depasse pas le dessin d'une image.
En outre il est peu probable qu'un seul des deux flux prennent de l'avance en permanence. Parfois ce sera l'un qui prendra de l'avance, parfois ce sera l'autre, et en moyenne ca se compense à peu près. Alors oui en moyenne, mais autour de cette moyenne il y a de la dispersion donc il n'est pas illogique de voir apparaitre de temps le temps autour d'une série d'images aux propriétés de compressions caractéristiques un léger déphasage.
(punaise, c'est tellement compliqué comme situation, que je ne suis pas certain d'avoir bien expliqué le problème)
Si cette théorie est exacte, je ne sais pas comment empêcher le déphasage. Ce que j'imagine naïvement est d'introduire du bruit dans l'image pour casser les propriétés de compressions d'un flux par rapport à l'autre. Mais franchement, casser la compression n'est pas glorieux.
S'il y en a qui ont suivis: Quelqu'un aurait-il une idée géniale pour forcer "automatiquement" les flux à se resynchroniser si l'un prend du retard sur l'autre ? (sachant qu'ils ne sont pas vraiment calculés en parallèles, mais séquentiellement, c'est à dire sans possibilité de retour arrière).
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [Thomson] Vidéo avec son en streaming
On peut peut-être forcer un retour en début d'écran en même temps pour les deux flux, à intervalles réguliers, par exemple tous les n secteurs de la carte SD. Ce qui veut dire qu'un écran de temps en temps ne serait pas entièrement mis à jour, mais c'est peut-être moins grave que la désynchronisation des flux ?
Pour le sketch Arduino, je viens de faire un essai "au feeling". Il a échoué. Demain je reprendrai plus sérieusement en utilisant l'analyseur logique pour mesurer les délais. Il y a un paramètre que je ne maîtrise pas trop : dans une instruction à 4 cycles, à quel cycle le signal est-il lu et pendant combien de cycles doit-il être maintenu à la bonne valeur ? Et quand le TO8 écrit le signal de synchronisation, à quel cycle de l'instruction se situe le basculement du signal ? Tout se joue à la microseconde, et sur 48 cycles une erreur de 2% suffit à provoquer une catastrophe. Il faut jouer serré...
Pour le sketch Arduino, je viens de faire un essai "au feeling". Il a échoué. Demain je reprendrai plus sérieusement en utilisant l'analyseur logique pour mesurer les délais. Il y a un paramètre que je ne maîtrise pas trop : dans une instruction à 4 cycles, à quel cycle le signal est-il lu et pendant combien de cycles doit-il être maintenu à la bonne valeur ? Et quand le TO8 écrit le signal de synchronisation, à quel cycle de l'instruction se situe le basculement du signal ? Tout se joue à la microseconde, et sur 48 cycles une erreur de 2% suffit à provoquer une catastrophe. Il faut jouer serré...
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7923
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] Vidéo avec son en streaming
J'anticipe un peu l'arrivée de sketch arduino avec ce gros montage éhonté (La TV du TO8 me sert de moniteur PC sur lequel tourne DCMOTO en plein écran ):Fabrice Montupet a écrit :Ce serait chouette si vous réalisiez, de temps en temps, une petite vidéo des travaux en cours
Avec un peu d'attention, on remarque l'effet "peigne".
Pour la synchro je suis en train de revoir l'encodeur. L'idée est de compresser les deux flux simultanément et si l'un prend trop d'avance par rapport à l'autre, on le retarde en introduisant des triplets avec déplacement nul. Du coup le défaut du déplacement nul devient une sacrée qualité. J'aime bien ces revirements de situation.
Dans le datasheet 6809e (pas le programming manual), sur la figure 17 "Cycle by cycle performance" (pages 21 à 25) il y a une machine a état indiquant ce qu'on trouve à chaque cycle sur le bus d'adresse en fonction de l'instruction. Si je suis le diagramme: STA <$CD se décompose en <fetch> (p21), puis <nnnn+1> (récup partie basse), puis <FFFF> (cycle interne), et enfin <ea> (l'addresse d'écriture). Donc fort logiquement la valeur est écrite sur le dernier cycle de l'instruction qui en comporte 4. Le LDA est similaire: l'adresse de lecture est présentée au 4 eme et dernier cycle, et le reg de donnée contient alors la valeur lue.Daniel a écrit :Et quand le TO8 écrit le signal de synchronisation, à quel cycle de l'instruction se situe le basculement du signal ? Tout se joue à la microseconde, et sur 48 cycles une erreur de 2% suffit à provoquer une catastrophe. Il faut jouer serré...
Maintenant si le timing est trop serré, on peut parfaitement mettre un nop entre les deux lecture consécutives au port A.
PS: "Call on me" me fascine depuis que je l'ai vu tourner sur Amstrad avec un OS multitache:
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Re: [Thomson] Vidéo avec son en streaming
Je te remercie pour les vidéos :-)
Félicitations pour le travail accompli, le rendu est vraiment très bon!
Quant au travail réalisé sur SymbOS pour CPC, il est epoustouflant et laisse sans voix.
Félicitations pour le travail accompli, le rendu est vraiment très bon!
Quant au travail réalisé sur SymbOS pour CPC, il est epoustouflant et laisse sans voix.
Re: [Thomson] Vidéo avec son en streaming
C'est normal, il n'y a pas la pause permettant d'initialiser l'Arduino. Il envoie donc le premier échantillon de son trop tôt, avant l'initialisation des ports.Daniel a écrit :Pour le sketch Arduino, je viens de faire un essai "au feeling". Il a échoué.
Je vais maintenant modifier le player (comme je l'avais fait avec SDANIM7) avant de reprendre les essais. Au passage j'ajouterai aussi le choix du fichier dans la carte SD, et le test MO/TO pour faire éventuellement une version MO6.
Daniel
L'obstacle augmente mon ardeur.
L'obstacle augmente mon ardeur.
-
- Messages : 7923
- Inscription : 18 sept. 2010 12:08
- Localisation : Brest et parfois les Flandres
Re: [Thomson] Vidéo avec son en streaming
Ah oui j'ai méchamment simplifié le player :-/
De mon coté j'ai trouvé le moyen de garder les deux flux strictement synchrone. Il faut que je revoie complètement l'encodeur, mais je pense que ca va marcher, et qu'en prime l'encodeur sera plus simple et plus rapide.
De mon coté j'ai trouvé le moyen de garder les deux flux strictement synchrone. Il faut que je revoie complètement l'encodeur, mais je pense que ca va marcher, et qu'en prime l'encodeur sera plus simple et plus rapide.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos