Ligne a retard pour signal vidéo PAL

[invitec7f35b68]

Bonjour,
Ma question concerne la synchronisation de deux signaux PAL. Ayant déjà chercher (énormément) sur internet et n'ayant rien trouvé je m'en remet a vous ! J'ai pour but de synchroniser deux signaux PAL et plusieurs solutions s'offre a moi.

La première est de passer au numérique, mettre tout une série de circuit intégré allant de la RAM au µC afin de numériser le signal puis de le reconvertir en le retardant un peu afin qu'il soit synchro avec un autre signal. Cette solution ne convient malheureusement pas pour disons donc garder un esprit plus vintage !

La deuxième de manière analogique, serait d'appliquer un retard tel un echo a un des deux signaux pour qu'ils soit de fait synchronisés ! Cette solution me parait meilleure pour la simple raison que des tas de gens l'ont fait dans le passer et que ca roulait bien ! Vous savez en ce temps ou le numérique se traduisait par transistor et non par ordinateur. ... (Un peu de nostalgie) lol non bon sérieusement. J'ai découvert certains IC qui permettent de retarder non pas d'une frame mais d'une ligne. Ces IC (de chez Interstil et autre pour ne pas les cités) sont accessible mais les delais ne sont que trop court.

Pouvez vous m'aider, bien a vous

Raph

PS: Ne me dites pas d'acheter un TBC ou Frame synchronizer a 800$ svp. La n'est pas le but. Je préfère le DIY !
-----

[jiherve]

Bonjour,
Il n'existe en effet que des lignes à retard CCD .
Faire recherche avec CCD delay line.
Si les signaux sont mésochrones cela sera plus compliqué.
La seule autre alternative c'est la digitalisation mais cela nécessite aussi des circuits spéciaux et un recodage pour revenir en PAL.
Les deux sont disponibles chez AD ou NXP.

JR

[Tropique]

Pour pouvoir synchroniser deux signaux video arbitraires, il faut pouvoir stocker une quantité d'info allant de 0 à un frame complet.
Disons que ce n'est pas complètement impossible en analogique, ça s'est déjà fait pour les premiers convertisseurs de standard transcontinentaux, à une époque ou il n'existait pas d'autre alternative, mais ça reposait sur des lignes à retard en verre monstrueuses, des polygones dans lesquels on créait des dizaines de réflexions.
C'était incroyablement coûteux et délicat, et il n'y a jamais eu que quelques exemplaires de fabriqués.
Pour de la bidouille DIY, ce n'est pas réaliste, il faut passer au digital. Il y a des blocs de fonction incluant convertisseurs, processeur video et mémoire qu'il suffit de configurer et combiner correctement pour arriver simplement et économiquement au résultat.

[invitec7f35b68]

Merci pour vos réponses rapides, j'ai déjà regarder du coté Digital dont vous me parlez et les ic indépendants ou blocs qui permettent le retard sont relativement couteux et difficiles a trouver. Cela d'après mes sources bien entendu. Pourriez vous me donner des exemples plus concrets ?

En ce qui concerne la longueur du retard elle peut être réduit a une demi frame. Je m'explique : Le retard d'un signal de 75% revient au meme que retarder le deuxième de 25% par rapport au premier. Logique n'est ce pas. Je ne tiens pas a retarder les deux signaux mais bien un seul. C'est même plus logique pour une réelle synchronisation.

Quant au ligne a retard CCD, je viens de regarder et je n'ai pas trouvé, ou alors je n'ai pas compris. Dans ce cas, autant pour moi.

[A voir en vidéo sur Futura]

[Tropique]

Je ne sais pas donner de références précises, mais ce genre de circuits s'emploie dans les petits pupitres d'effets video (Panasonic.... ), les circuits PIP de TV, les processeurs pour VCR VHS multistandard, etc.
Il doit y avoir des circuits Sony notamment (CXxxx).

[invitec7f35b68]

Alors je me suis documenté et renseigné sur les différents ic qui peuvent être solicité pour ma réalisation et je n'en ai pas trouvé énormément. La plupart sont des PIP ce qui n'est pas exactement ce que je cherche. Dans les datasheets des TBC et Frame Synchronizer professionnels la solution la plus répétée est de faire un "classique" A/D -> RAM -> D/A. Quand je dis classique ce n'est pas péjoratif mais c'est une solution bien connue qui modifie considérablement le reste de mon montage. Néanmoins, cette tache n'ayant pas de ic dédié, je pense que c'est la seule façon d'arriver au résultat recherché. Je me suis donc inspiré d'un article publié dans électronique pratique sous le nom de "mosaïque 4 écrans pour vidéo-surveillance". Néanmoins je vais le transposer dans un model qui permet de créer un simple buffer haute qualité (Signal PAL en faite j'dirais donc plutot moyenne qualité ). Et je vous sollicite a nouveau afin d'avoir votre avis concernant la routine a créer, pensez vous qu'elle peut être réalisée sans microcontrolleur ? Je n'arrive pas a me décider. Ca serait logiquement faisable. Néanmoins ...

J'attends vos avis, bien a vous.

Raph

[Tropique]

Les circuits existent, mais leur grande époque était il y a une quinzaine d'années, et ce sont des circuits très spécialisés, qui étaient faits sur mesure par les fabricants pour leurs produits.
Maintenant que le PAL va disparaître, et ce n'est plus du tout d'actualité.
En principe,un microcontroleur n'est pas indispensable: il faut écrire à un rythme dans la mémoire, et la relire à un autre, ce que quelques compteurs, décodeurs et un peu de logique peuvent faire, mais s'il faut écrire dans des registres de configurations de certains circuits, un µC peut s'avérer utile, si pas indispensable.

[jiherve]

Bonsoir,
Pour digitaliser ADV7403,ADV7181C,SAA7118, attention c'est couillu à utiliser malgré leur apparente "simplicité".
Ensuite il faut mémoriser, n'importe quelle mémoire suffisamment rapide fait l'affaire, ZBT, DDRx, il faut cependant piloter l'écriture en mémoire, la meilleure solution est le FPGA; C'est réalisable avec de la logique standard mais c'est une usine à gaz.
Et enfin il faut "rejouer " la vidéo de façon synchrone avec la seconde, là pas moyen d'éviter un FPGA ou un DSP ad hoc pour assurer la resynchronisation et la lecture de la mémoire, dans le principe c'est aussi assez simple mais la mise en œuvre est assez délicate si l'on désire un résultat impeccable.
Le ré-encodage demande à nouveau des circuits spécialisés, chez AD ou NXP aussi.
Le Pal étant entrelacé il faut normalement mémoriser deux trames au minimum pour s'en sortir, ce qui suppose une mémoire triple page.
Le µcontroleur sera habilement utilisé pour configurer et piloter tout ce petit monde.
Tu t'attaques là à un problème complexe.

JR(La vidéo mais c'est très simple!)

[invitec7f35b68]

Paris tenu ! Ce n'est pas ma première application ni mon premier montage en vidéo donc je pense que ca va pouvoir se faire. Je pense décrire toutes les étapes du montage dans ce topic pour qui voudra suivre ou aider. Concernant l'aspect technique du signal vidéo je le connais plus ou moins bien donc ca ne devrait pas poser problème.

1ère étape : Choix des outils et de la procédure.

- Je vais donc d'abord (pour plus de faciliter) convertir mon signal PAL en RGB + Sync. La qualité de la numérisation sera plus grande, je compte donc utiliser un A/D 8bits avec 3 entrées et un selecteur de préférence. (Évitons les circuits supplémentaires) Je pense utiliser le TDA8708 qui dispose de trois entrées.

- En ce qui concerne la mémoire tampon. Le choix me parait moins simple. Je vais utiliser trois mémoires différentes afin de reproduire le schéma suivant :

Ecriture :__| 1 || 2 || 3 || 1 |
Lecture : ___| 3 || 1 || 2 || 3 |

Lors de l'écriture de la mémoire 1 on lit la 3 ainsi l'écriture de la mémoire 2 peut commencer sans que la lecture obstrue.

- La gestion du choix des mémoires a lire et écrire sera faite automatiquement. Le plus simple je pense est de constamment lire les mémoires dans l'ordre et d'écrire sur l'une des trois en fonction de celle qui est lue. N'oublions pas que le montage est multiplier par deux. Et les compteurs de lecture sont incrémentés par la même horloge afin d'assurer la synchronisation des deux canaux vidéo.

- Les mémoires seront donc lues ou écrites grâce a des compteurs incrémentés soit par l'horloge fix dite de synchronisation, soit par le sync horizontale ou vertical du signal RGB. Cette détection sera faite par le biais de la ligne Sync. via un LM1881 ou autre détecteur. A vrai dire quelques transistors devraient aussi faire l'affaire.

- En ce qui concerne le D/A je ne l'ai pas encore trouvé mais ca ne serait tarder.

Je triche un peu étant donné que j'ai déjà mon convertisseur PAL -> RGB et RGB - PAL. Ce dernier étant construit a base d'un schéma de montage velleman.

En ce qui concerne la gestion de tout ce petit monde, un FPGA serait une solution mais pourquoi pas un peu de logique. A méditer...

Idées, conseils ? N'hésitez pas. Je vous tiens au courant de l'avancement.

Raph

[invitec7f35b68]

Petit calcul concernant la RAM.

Une trame est composée de 625 lignes de 320 a 720 points (pixels) ceux ci sont caractérisés par 3 couleurs différentes (Rouge, vert et bleu), il nous faut donc une RAM mémorisant 625 * 720 points * 3.

On peut procéder de deux manières différentes. La première serait d'avoir sur la même RAM une première adresse de 10bits (1024 données) pour la ligne, une autre de 10bits pour les points de cette ligne et enfin 2bits pour le choix de la couleur. Faisons donc un calcul rapide : 22bits d'adresses au total soit 4 194 304 données ! PFou !

La deuxième manière est de "compresser" le tout pour atteindre un unique compteur qui devrait retenir 3 * 625 * 720 données de 8bits soit 1 350 000. C'est déjà plus raisonnable ! Et en diminuant le nombre de pixel a 559 on obtiendrait : 625 * 559 * 3 soit 1 048 125 données a mémoriser !!!! Ce la signifie 20bits d'adresse. Donc 2 de gagnés.

Il ne reste donc plus qu'a trouver un RAM de 8Mbit (1024k * 8). Cypress produit des SRAM du genre je pense. ((CF : http://www.digchip.com/data/115/115-...Y62158DV30.pdf )) Ca serait bon d'après vous ?? J'aurais préféré une RAM a package DIP mais bon ..

[jiherve]

Bonsoir,
Mal barré tout çà : on ne convertit pas un signal PAL composite en RVB avec un simple DAC fut il triple (on se demande bien pourquoi d'ailleurs).
Ceci dit :
Pour la RAM il faut :
288 (ligne utiles par trame)x 720 x 3 octets x 3 pages pour gérer l'asynchronisme donc :1,8 Mo min
Avec une numérisation à 13,5 MHZ (because 720 points) il faut donc une mémoire ayant 15 à 20 ns de temps d'accès, en effet il faudra penser a relire aussi!
Le plus simple est d'utiliser une ZBT il en existe en 1Mx36.
JR

[invitec7f35b68]

Bonjour,

En ce qui concerne la conversion du signal PAL en RVB je n'utilise pas un DAC ... D'ou mon incompréhension concernant votre réponse. J'ai du mal m'exprimer. En gros ca se ferait comme ceci : Conversion PAL-RVB, A/D du RVB, mémorisation, D/A RVB, conversion RVB-PAL.

En ce qui concerne la conversion PAL->RVB et RVB->PAL mon montage est déjà pret et opérationnel. Il fonctionne très bien même. Donc en réalité il me suffit de créer l'étage du milieu.

Par contre je ne comprend pas pourquoi vous ne citez que 288 lignes. Une trame complète en contient le double. Cette trame est en effet divisée en demi trame mais celles ci doivent être numérisées ensemble.

J'ai fais (TRÈS) grossièrement un schéma fonctionnel. Il n'y a pas le détail des RAMs ni des compteurs ou autres... Mais ca permet de donner une vue d'ensemble sur mon idée.

[jiherve]

Bonsoir,
Le DAC c'était une faute de doigt il fallait bien sur lire ADC.
Une image télévision est constitué de 2 trames (mais que l'on peut nommer demi trame), chacune comportant au plus 288 lignes utiles (287,5 en fait) qui ne sont pas forcement cohérentes temporellement le dispositif de génération d'image pouvant lui même être entrelacé, il ne sert donc à rien, hormis pour absorber un asynchronisme de mémoriser 2 trames ou plus; c'est d'ailleurs un des piège du désentrelacement.
Avec quoi convertis tu le signal composite en composantes ?
Recup de circuit de téléviseur ?
Un bon lien :http://www.100fps.com/
JR

[invitec7f35b68]

Bonjour,

Tout d'abord en ce qui concerne la conversion PAL -> RVB (+sync) j'utilise le schéma d'un montage velleman (le K4600 pour être exacte) C'est un processeur RVB fonctionnent a base de différents TDA. Il convertit dans un premier temps le signal S-Vidéo - PAL en RVB puis le traite (gestion des couleurs, saturation, luminosité et contraste) puis le reconverti a base d'un "traditionnel" MC1377 Le schéma est divisé en deux sections bien distinctes ce qui permet de dérouter le signal RVB et de le synchroniser avec un autre avant de le réinjecté vers le MC1377.

J'ai du mal a comprendre votre explication concernant les demi trames. D'après tous les articles que j'ai lu, afin d'opérer une synchronisation cohérente il faut obligatoirement synchroniser les demi trames paires entre elles et de même pour les impaires. Si non on a un retard temporel et on risque d'avoir une image "a cheval" entre deux trames complètes. (Il y a d'ailleurs différents exemple de ce phénomène sur le lien que vous avez posté).

De plus pour la mémorisation il faut 3 RAM différentes afin de numériser et de lire simultanément (Cf: message du haut). Ce qui signifie qu'on mémorise 3 trames complètes. Si on numérise que 3 demies trames, lors de la lecture synchro on risque d'avoir en lecture une demi trame paire sur un canal et une demi trame impaire sur l'autre (par exemple). La synchronisation serait erronée.

Bien à vous,
Raph

PS: Voici un article fort intéressant : http://www.maxim-ic.com/app-notes/index.mvp/id/734

[PIXEL]

une observation toutefois....

de genre de manip ne se fait pas en RVB , mais en Y Dr Db ( dit parfois Y U V) ce qui permet d'économiser grandement la mémoire, car il n'y a pas besoin d'autant de précision pour les infos chrominance.

[invitec7f35b68]

Je me suis renseigné pour numériser de cette façon et de faite économiser la mémoire, seulement il se pose alors différents problèmes et contraintes.

Premièrement, d'après certaines société spécialisé en ic pour traitement vidéo, je pense notamment a Gennum, le traitement Y U V diminue et altère la qualité de la vidéo, sauf dans le cas de compression a matrice comme pour le format JPEG par exemple. (Il faut que je recherche l'article que j'ai lu a cet effet)

Deuxièmement, ce type de mise en mémoire ne permet pas un traitement approfondi. Imaginons que l'on veuille traiter la vidéo par la suite en appliquant différents étages d'effets, ceux ci sont plus faciles a effectuer a partir d'un signale RVB (sans faire appel a des calculs savant par microprocesseurs).

Je vais néanmoins voir de quelle manière votre idée pourrait etre mise en œuvre. Toutes les idées étant bonnes a prendre !

[PIXEL]

si tu part d'un signal PAL ou SECAM , c'est déjà du 4.2.0 numérique.

en gros il "manque" une ligne sur deux de chrominance, cette contrainte est liée aux traitements analogiques déterminés il y a 40 ans basée sur la constatation que la précision angulaire de l'oeuil est plus basse pour les teintes que pour la luminosité.

merci de me rajeunir en me rappelant le bon temps où j'enseignais tout ça !

[invitec7f35b68]

Quel circuit utiliseriez vous pour convertir un signal PAL (oublions SECAM ) en YUV afin de le numériser ? Il est vrai que l'avantage de ce dernier signal (YUV) permettrait plus tard de transformer le schéma non pas avec une interface PAL mais HDMI, construit si mes souvenirs sont bons sur les mêmes calculs de différence de couleurs.

[jiherve]

Bonjour,
Je n'ai jamais écrit, et même écrit plutôt le contraire, qu'il faille associer des trame de parité différentes. L'association de trame identiques ne nécessite cependant que de mémoriser 3 trames(field) (ce que tu nommes demi trame) au plus, par contre il faut une gestion ad hoc des pages car il faudra peut être de temps en temps répéter une trame ou en sauter une suivant le glissement de phase des deux vidéo.
Et comme je l'ai déjà écrit il n'y a pas vraiment de cohérence entre les deux trames(field) d'une image si le capteur(caméra) est lui même entrelacé donc il n'est pas nécessaire de faire un traitement image par image sauf si la source est cohérente(PC par exemple et encore pas toujours).
il n'est pas non plus nécessaire d'avoir 3 mémoires distinctes si la mémoire utilisée offre une bande passante suffisante ce qui est le cas avec des ZBT ou des DDR.
Pour la digitalisation j'ai déjà fournit les références, c'est ce qui se fait de mieux aujourd'hui.
Pour ce que tu veux faire rester en YCrCb ne présente aucun inconvénient si tu disposes d'un encodeur acceptant ce format en entrée, mais il est vrai que s'il faut faire des traitements un peu plus savant qu'une resynchronisation il faudra passer en RVB.
Désolé si je ne suis pas toujours très clair.

JR

[invitec7f35b68]

Merci pour ces plus amples explications. C'est moi qui n'avais de fait pas tout compris. Je pense que je vais en rester a un traitement RGB pour l'instant. En ce qui concerne la mémorisation j'ai regardé les différentes RAM. Il n'existe pas bcp de RAM au package DIP pour contenir autant de trames et images.