Doctsf (Modèles & Marques)
AnnoncesLe codeur SECAM (ou plutôt PAL/SECAM/NTSC, même si le NTSC n’était pas utilisé dans le Mediasat) était un SAA7182 Philips.
Le codage et le filtrage étaient faits en numérique, la qualité était bien meilleure que celle d’un codeur analogique grand public.
La documentation technique de ce SAA7182 :
J’avais pu en trouver à 2 euros sur ebay il y a 5 ans, c’est en effet une puce qui offre de bonnes prestations d’après la documentation.
Une puce qui prend en entrée un signal vidéo numérique YUV (Y pour la luminance, Cb et Cr pour la chrominance, les 3 infos étant codées chacune sur 8 bits), et en sortie on obtient au choix un signal vidéo composite, un signal S-Vidéo et du RVB (ou les 3 simultanément).
Il a été monté sur tous les décodeurs Canalsat et TPS de première génération car à cette époque leur cahier des charges imposait la possibilité de sortir en RGB et en SECAM (pour l’enregistrement).
Sa fonction a ensuite été intégrée dans le décodeur MPEG-2.
Avec le MEDIASAT de Canal Sat c’était uniquement du SECAM identification ligne, le CEEFAX pour les chaînes étrangères était réinséré en VBI.
Cette puce permettait aussi de générer des signaux anti-copie, mais il n’a jamais été utilisé avec ce premier décodeur, on pouvait enregistrer les programmes VOD du service Kiosque.
La sortie SECAM posait problème avec les programmes en VM avec le sous-titrage optionnel incrusté: on avait des saignées rouges.
Dans le courrier des lecteurs d’un vieux magazine TELE CABLE SATELLITE HEBDO pour résoudre le problème, le rédacteur avait préconisé à juste titre de passer le décodeur en PAL.
Les possesseurs de TV et magnétoscopes multistandards avait tout intérêt à travailler en PAL, ce que j’ai fait dès le premier jour.
Quasiment toute ma vidéothèque est d’ailleurs en PAL ou S-VHS
Pour le TV on avait tout intérêt à utiliser la sortie RGB si le TV avait une péritel complète sur laquelle contraste et saturation agissaient (pas les toutes premières péritel).
La vidéo composite et la S-vidéo étaient destinées au magnétoscope et à l’époque (1996 pour le démarrage de Canal en numérique) le parc de VHS seulement SECAM était encore majoritaire.
Je pense qu’on le sait. 
Penses-tu qu’il serait possible pour un amateur de piloter cette puce SAA7182 avec un microcontrôleur « STM32F4 nucleo », dans le but de créer un codeur PAL/SECAM/NTSC ?
Ce microcontrôleur a un CPU ARM 32 bits qui tourne à 180 Mhz, une mémoire de 256 Ko, un espace de stockage flash de 512 Ko à 1 Mo :
https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus/stm32-high-performance-mcus/stm32f4-series.html
La difficulté c’est peut-être d’acheminer de la vidéo numérique YUV vers le STM32 à un débit constant de 25 images par seconde, on passe par quel bus de données du STM32 ? Le bus SPI ? Sera-t-il suffisamment rapide ?
Il faut donc envoyer 25 images par seconde de vidéo non compressée YUV : 720 x 576 x 25 = 10 368 000 pixels par seconde, on multiplie par 3 (les infos YUV), ça fait environ 30 Mo de données à transmettre depuis le PC vers le contrôleur STM32, le bus USB2.0 peut monter en théorie jusqu’à 60 Mo/sec mais en pratique c’est plus bas, le bus USB3.0 sera beaucoup plus à l’aise (jusqu’à 625 Mo/sec).
Edit : peut-être moins de 30 Mo/sec, si on échantillonne la chroma en 4.2.2, la documentation du SAA7182 parle du format vidéo numérique à la norme CCIR 656 :
4:2:2
The two chroma components are sampled at half the horizontal sample rate of luma: the horizontal chroma resolution is halved. This reduces the bandwidth of an uncompressed video signal by one-third, which means for 8 bit per component without alpha (24 bit per pixel) only 16 bits are enough, as in NV16.
ITU-R BT.656 - Wikipedia
C’était exactement le même sur la version cable DVB-C de Numéricable, voir même sur le SAGEM cable, utilisé par NOOS, avant d’ être bouffé par Numéricable.
Effectivement un encodeur SECAM avec, uniquement l’ identification LIGNE ( rien sur le VBI, pour la réinsertion TXT ), pour le SAGEM, c’était accolé avec la norme L avec un PLL
Mais la meilleure qualité pour le scope, c’est le mode S- Vidéo( PAL séparé ), et le mode PAL, pour la vidéo composite, pour le SAGEM, c’était lié avec la norme G ou I au choix, avec un PLL.
Les technicos commerciaux étaient incompétents dans ce domaine, ils ne juraient que par le SECAM ! 
Pour les TV uniquement norme L( entre 1968 et 1979 ), sans péritel, il fallait ajuster le RLC s’ il y avait un TCA 640, à coté.
Le SAGEM avait un modulateur PLL UHF 21 à 69, pour les TV qui n’ avaient pas de Péritel ou d’ entrée vidéocomposite. avec norme L ou G ou I au choix( TV multistandard sans Vidéo, ou TV uniquement B/G, ou uniquement I ! )
En fait au niveau « hardware » les décodeurs câbles et les décodeurs TPS étaient identiques à la partie RF / démodulation près:
-tête VHF/UHF pour le câble avec démodulation DVB-C (QAM 64),
-tête BIS pour le satellite avec démodulation DVB-S (QPSK)
Le contrôle d’accès était identique (Viaccess).
je maitrise pas bien la question, et je pense que ça meriterait un sujet à part.
mais le saa7182 (que je ne connaissait pas, je viens d’en acheter pour l’occasion :D) prend un flux mpeg 2 en entrée. donc il n’est absolument pas question de faire du 30 Mo/s, le débit sera celui du flux mpeg.
le terme YUV est tendencieux ici. en réalité, il est question de Y’CbCr
donc d’apres la doc, il faut envoyer le flux mpeg sur les entrées MP0 à MP7.
Tu es sûr de ça ?
Accepter en entrée du MPEG2 signifierait que la puce SAA7182 contiendrait un décodeur MPEG2, pour être capable de reconstituer les images du signal d’origine,
la documentation du SAA7182 indique qu’il prend du MPEG2 déjà « décodé », donc un flux YUV avec la chroma échantillonnée en 4.2.2,
à mon avis sur ces décodeurs satellite il devait y avoir 2 puces sur la carte électronique :
- une puce « décodeur MPEG2 », chargée de décoder le MPEG2 extrait du signal DVB-S par le démodulateur
- une puce « codeur PAL/SECAM/NTSC » (le SAA7182), dont l’entrée est reliée à la sortie de la puce « décodeur MPEG2 »
Accepts MPEG decoded data on 8-bit wide input port.
Input data format Cb, Y, Cr etc. or Y and Cb, Cr on 16 lines (“CCIR 656”)
The circuit accepts CCIR compatible YUV data with 720 active pixels per line in 4:2:2
multiplexed formats,
for example MPEG decoded data. It includes a sync/clock
generator and on-chip Digital-to-Analog Converters (DACs).
Si le microcontrôleur STM32 a assez de puissance on pourrait transmettre une vidéo compressée (mpeg2 ou un codec plus facile à décoder comme le MJPEG) et lui demander de faire le décodage vers du YUV, cela aurait l’avantage de réduire la quantité de données à transmettre depuis le PC via l’USB2.0, il faudrait ensuite que le STM32 envoie ce signal décodée aux pins d’entrées du SAA7182 dans les temps pour respecter la cadence de 25 images par seconde.
du tout. et effectivement, je dois avoir tres mal compris.
c’est juste l’hisoire des 30 Mo/s qui me semblait assez improbable pour l’époque.
mais apres tout, sur un « bus » dédié avec un nombre de voies suffisant et des tampons c’était sûrement tenable.
A l’entrée du SAA7182, c’est un flux numérique décompressé au format 4:2:2 qu’on applique (format dit ITU-R656, ex CCIR 656).
C’est à dire un flux Y échantillonné à 13,5 MHz sur 8 bits soit 108 Mb/s et deux flux U et V échantillonnés chacun à 6,75 MHz sur 8 bits, soit encore 108 Mb/s pour les deux, donc 216 Mb/s pour l’ensemble (ou 27 MO/s si on préfère).
Et c’est du « temps réel », pas question d’envoyer ces données par salves, il n’y a pas de bufferisation dans le SAA7182.
Effectivement dans les premiers décodeurs satellite il y avait même deux chips en amont du SAA7182: un chip démultiplexeur du « transport stream » qui sélectionnait les paquets correspondant au programme TV regardé au moyen de leurs PID et un décodeur MPEG proprement dit qui décompressait les flux audio et vidéo (le tout assorti d’une RAM de taille suffisante et contrôlé par un microprocesseur 16 bits).
Le décodeur MPEG était suivi d’un DAC audio pour récupérer l’audio analogique et d’un encodeur vidéo pour récupérer la vidéo analogique.
Comme la chroma est échantillonnée en 4.2.2 alors ça devrait réduire les données à transmettre d’un tiers, on a alors plus qu’à transmettre des données à un rythme de 18 Mo/seconde au SAA7182.
Le STM32 NUCLEO-F411RE (STM32F411RET6) a une fréquence d’horloge qui peut monter jusqu’à 100 Mhz, à voir si c’est suffisant pour envoyer en temps réel les bits YUV 4.2.2 au SAA7182.
Non, car ce qui fait que c’est du 4:2:2 c’est que la fréquence d’échantillonnage des chromas est la moitié de celle de la luminance, et c’est pris en compte dans le calcul de 27 MO/s.
Pour atteindre 18 MO/s il faudrait faire du 4:1:1 (échantillonnage chroma à 3,375 MHz) ou du 4:2:0 (chaque chroma une ligne sur 2 comme en SECAM ou en D2MAC), ce qui réduit la bande passante chroma par deux (dans le sens horizontal dans un cas et vertical dans l’autre).
Mais le SAA7182 n’accepte que du 4:2:2 en entrée (c’est ce qui est restitué par le décodage MPEG-2 même si le codage MPEG-2 était en 4:2:0 au départ).
Pour mémoire 4:2:2 signifie 4 échantillons de Y pour 2 de U et 2 de V.
4:1:1 signifie 4 échantillons de Y pour 1 de U et 1 de V
4:2:0 signifie 4 échantillons de Y pour 2 de U et 0 de V sur une ligne (et l’inverse à la ligne suivante).
Je ne suis pas sûr de ton calcul pour arriver à 27 Mo/sec mais je pense que tu as raison.
Multiplier la fréquence d’échantillonnage par le nombre de bits par échantillon, ce n’est quand même pas si compliqué !
Mais je ne comprends pas ce que tu voudrais faire avec ton STM32 ?
Générer des images fixes ?
Ce que je voudrais faire c’est ce scénario :
- Un PC qui envoie des données YUV 4.2.2 (provenant d’un fichier vidéo) vers un STM32 via le port USB
- le STM32 va ensuite (en temps réel) envoyer ces données au SAA7182
- le but étant étant de pouvoir générer un signal analogique PAL/SECAM/NTSC depuis un PC
Le PC sera équipé d’un programme qui décode un fichier vidéo (peu importe son codec) en vue d’obtenir du YUV 4.2.2, il enverra des bits YUV 4.2.2 vers le STM32, qui grâce à un programme enverra à son tour ces bits YUV 4.2.2 vers les broches du SAA7182, et en sortie du SAA7182 on connectera le nécessaire pour que le signal alimente l’entrée vidéo composite d’un TV (ou d’un magnétoscope, pour revenir sur le sujet du topic, évaluer la qualité du SECAM VCR avec un signal de qualité, pour créer des enregistrements de test)
C’est un peu comme le logiciel hackTV et le périphérique hackRF (ou l’adaptateur USB3 vers VGA) qui produit un signal PAL/SECAM/NTSC, sauf qu’ici on utilise pas la méthode SDR, mais le STM32 combiné à cette puce SAA7182.
Mais j’ai des doutes sur la possibilité de maintenir un flux de bits constant en temps réel entre le PC et le port USB du STM32, je ne sais pas si le port USB du STM32 est conçu pour fonctionner à la vitesse de l’USB2.0, il est possible qu’il soit juste un port USB fonctionnant à vitesse réduite, pour émuler un port série de communication (comme celui du Arduino).
Il n’y a pas que le débit qui compte, je pense que l’USB (contrairement au bus IEEE1394 « firewire ») n’est pas conçu pour des liaisons isochrones nécessaires pour transmettre un flux video.
Des pistes pour contourner le problème :
-
Doter le STM32 d’un lecteur SD-Card rapide qu’on relie à ses pins, cette mémoire contiendra quelques minutes de vidéo YUV 4.2.2,
le STM32 ira régulièrement prélever quelques échantillons YUV, à un rythme qui lui permet de respecter les contraintes de temps réel imposées par le SAA7182. -
Autre manière de contourner le problème : se contenter de diffuser des images fixes (le STM32 enverra au SAA7182 de manière infinie la même trame), ça ferait alors du couple STM32-SAA7182 un générateur de mires PAL/SECAM/NTSC de grande qualité, avec une banque d’images de mires, que le STM32 peut générer à volée via son programme, les mires électroniques type PM5544 pouvant être synthétisées par du code.
si le but c’est juste de pouvoir sortir des mires, je pense que ça pousse trop loin la complexité.
aujourd’hui y’a quand même des boîtiers hdmi > scart qui bossent tres bien en pal, et en intercalant un bon transcodeur pal > secam ça fera aussi bien.
mais apres y’a aussi le côté défi, et ça ne se discute pas 
perso si j’en avais les moyens dans l’immédiat, je verrais bien une carte pci express…