Hallo! Ich bin gerade dabei mal die Möglichkeiten auszuloten die sich bieten um ein CVBS PAL (vielleicht auch NTSC) mit einem zweiten Overlay zu verbinden. Wer noch die Genlocks aus Amiga/Atari Zeiten kennt... :) Hintergrund: Bei FPV-Flugmodellen im Modellbau (Quadrocopter, Flugzeuge, etc..) wird dem primären Videosignal (Aus latenz- und Kostengründen meist analog) gerne ein OSD-Overlay zugemischt auf dem wichtige Informationen wie Kompass, Horizont, Batteriestand, GPS, Warnungen angezeigt sind. Dazu wird gerne ein Maxim OSD-Chip MAX7456 oder ein clone dessen eingesetzt. Er ist billig, leicht zu bekommen und hat sich mangels Alternativen durchgesetzt. Leider bringt der IC etliche Nachteile mit sich wie etwa 1-bit Farbe :) und 255 feste Charakter die sich im eeprom speichern lassen.. Da hab ich mir gedacht ich mache mich mal auf die Suche nach einer kostengünstigen Alternative mit der mal zumindest Farbdarstellung geht. Leider konnte ich keinen dedizierten OSD-Chip finden, der noch in Produktion ist und Farbdarstellung bietet. Jetzt hab ich mal ne grundsätzliche Frage zum Thema Video-Overlay: Angenommen ich habe mein Primärsignal, also das Bild aus der Videokamera und mein Sekundärsignal, also das synthetisch erzeugte Overlaybild. Das Overlay hat wohl am besten einen schwarzen Hintergrund. Würde es ausreichen das synthetische Signal einfach horizontal und vertikal synchron zum Primärbild auszugeben und einfach hinzuzumischen? Soweit ich mich erinnere war es eine Besonderheit der guten, alten Amiga-Computer dass es möglich war das komplette System mittels Genlock auf das Primärsignal zu synchronisieren (CPU und Chipsettakt abhängig vom Videosignal) und so Text und Grafik ganz easy ins Primärsignal einzublenden. Soweit ich gesehen habe gibt es dedizierte, günstige Chips die Videotimings bestimmen und als Takt ausgeben.. wenn ich nun einen AVR oder STM32 dazu zwingen könnte ein Bild auszugeben (es gibt etliche beispiele dazu im netz.. sogar in Farbe) und es so zu synchronisieren hätte ich quasi mein Problem gelöst.. Ich hab mir auch schon überlegt einen Video-Dekoder Chip wie den TVP5150 herzunehmen, das Signal dann als digitales RGB an einen kleinen FPGA oder einen großen Microcontroller mit genügend RAM weiterzugeben, das Overlay hinzuzumischen (in diesem Fall dann sogar mit Alphakanal!) und wieder (eventuell umgekehrt mittels Encoder-IC wie dem TVP6000) als CVBS-Signal ausyugeben.. das wäre so quasi der Königsweg, allerdings auch recht komplex. (Die kosten würden sich auch noch in Grenzen halten.. ca 30€) Habt Ihr eine Idee hierzu? Viele Grüße!!
Um in ein FBAS Signal ein farbiges Overlay zu mischen, musst du erst aus dem FBAS ein RGB-AS Signal machen, dann das Overlay dazu mischen und dann wieder in ein FBAS kodieren. Eine andere Möglichkeit wäre, den Burst des FBAS auszuwerten und sich einen lokalen Farbhilfsträger phasenrichtig zu erzeugen und damit das Overlay zu erzeugen und dann dazu zu mischen.
Georg G. schrieb: > Um in ein FBAS Signal ein farbiges Overlay zu mischen, musst du > erst aus > dem FBAS ein RGB-AS Signal machen, dann das Overlay dazu mischen und > dann wieder in ein FBAS kodieren. Das wäre dann in etwa die analoge Variante zu meiner Idee mit dem Video A/D Wandler, dann Microcontroller mit Framebuffer und danach wieder daraus ein analoges Signal erzeugen... Ich habe bloß Bedenken dass neben der Komplexität auch noch eine mega-Latenz dazu kommt... von daher hört sich deine Idee eigentlich ganz gut an. Kannst du da ein wenig ins Detail gehen wie du so etwas grob realisieren Würdest? > > Eine andere Möglichkeit wäre, den Burst des FBAS auszuwerten und sich > einen lokalen Farbhilfsträger phasenrichtig zu erzeugen und damit das > Overlay zu erzeugen und dann dazu zu mischen. Ja, einfach so dazumischen wird wohl nur bei weißem Overlay auf schwarzem Grund gehen. Wenn mann da etwas farbiges drüberlegt kommt wahrscheinlich alles mögliche dabei raus... Das Problem bei 8-Bit Mikrokontrollern ist dass es zwar ausreicht ein sw-Signal zu erzeugen, aber für die Phasenverschiebung reicht die Bandbreite ohne Overclocking nicht aus, und dann auch nur für 45° 90° usw.. also in groben Schritten. Da müsste schon etwas in der STM32-Klasse her. Aber mal so in den Raum gestellt: Es kann doch nicht sein dass es für so etwas keine dedizierte ICs gibt außer dem blöden maxim... in den späten 90ern hatte doch so ziemlich jeder Fernseher, Videorekorder usw.. ein OSD! Und dass in Farbe und Bunt! Wie haben die das gemacht? Sind die Chips alle EOL? Gruß! Ach ja: Wie wird eigentlich Videotext erzeugt? Ist ja auch mit Overlay...
Moin, Sicher kann man das analog machen, aber das ist schon arg Horrorshow vom Aufwand her. Wenn du z.B. schon irgendwoher den H-Sync hast, dann brauchst du erstmal noch 2 Monoflops mit den richtigen Zeiten, um an den Burst zu kommen. Dann eine Phasenvergleichstufe, die den Burst mit deinem lokalen Farbhilfstraegeroszillator vergleicht und in einer Regelspannung umsetzt, um den Oszillator zu ziehen. Dann brauchst du noch die entsprechenden Synchrondemodulatoren, um an U und V zu kommen; dann noch ein PAL-Flipflop; die ollen Verzoegerungsleitungen fuer Chroma und Luminanzsignal... Wenn du die SMD Chips verarbeiten kannst, wird das mit der von dir skizzierten Loesung schon hinhauen. Mit dem Speicher, dem ein kleines FPGA mitbringt, kann auch nicht allzuviel Delay entstehen. Also sicher << 1 Halbbild. Gruss WK
PhiMX schrieb: > Ach ja: Wie wird eigentlich Videotext erzeugt? Ist ja auch mit > Overlay... Der wird auf RGB Ebene dazu gemischt. > Das wäre dann in etwa die analoge Variante zu meiner Idee mit dem Video > A/D Wandler, dann Microcontroller mit Framebuffer und danach wieder > daraus ein analoges Signal erzeugen... Du solltest dir den Aufbau eines FBAS Signals näher ansehen. Was du hier beschreibst, ist bei einem SW-Signal möglich, für Farbe ist der Aufwand drastisch höher. Wie wäre denn der Ansatz, einen normalen Framegrabber zu verwenden (USB, unter 20.-) und dazu einen Raspberry für die Datenverarbeitung.
Georg G. schrieb: > Der wird auf RGB Ebene dazu gemischt. Vor allem ist dadurch die Qualität des Overlays deutlich besser, als sie sein könnte, wenn es als PAL/NTSC-Signal erzeugt würde. Das liegt in erster Linie an der in der RGB-Stufe nicht mehr begrenzten Videobandbreite und daher höheren darstellbaren Pixelzahl, und andererseits auch im Farbcodierungsverfahren selbst. Insbesondere bei rotem Text auf dunklem Untergrund kann man die Defizite von PAL recht gut sehen (sehr unsaubere Ränder), die aber treten bei Videotext und OSD-Anwendungen nicht auf.
Der SCART-Anschluss hat genau zu dem Zweck einen digitalen Eingang, um RGB-Signale in ein Videosinnal einzustanzen. Pin 16 müsste das sein https://de.wikipedia.org/wiki/SCART#Steckerbelegung
Georg G. schrieb: > PhiMX schrieb: >> Ach ja: Wie wird eigentlich Videotext erzeugt? Ist ja auch mit >> Overlay... > > Der wird auf RGB Ebene dazu gemischt. Dann kann ich auch den Microcontroller/FPGA-Ansatz hernehmen, s.u. >> Das wäre dann in etwa die analoge Variante zu meiner Idee mit dem Video >> A/D Wandler, dann Microcontroller mit Framebuffer und danach wieder >> daraus ein analoges Signal erzeugen... > > Du solltest dir den Aufbau eines FBAS Signals näher ansehen. Was du hier > beschreibst, ist bei einem SW-Signal möglich, für Farbe ist der Aufwand > drastisch höher. > PAL FBAS ist bekannt, ich dachte das ist die Grundvoraussetzung für so ein Projekt :) Vielleicht hab ich mich zu "plump" ausgedrückt, ich hab mir das so gedacht: Es gibt sog. Video-Decoder, das hab ich mit Video A/D gemeint, ich hab da gerade den Ti TVP5150 im Auge, der macht aus einem PAL/NTSC FBAS einen digitalen YUV 4:2:2 Datenstrom, also in Farbe. Den Datenstrom wollte ich dann an einen kleinen FPGA weiterleiten (Sowas in der ice40-Klasse, also weiniger als 10k Logikblöcke) der mir zumindest mal YUV in RGB wandelt und danach mein Overlaybild hinzurechnet. Dann muss ich den RGB Datenstrom wieder in FBAS wandeln (Da muss dann wieder ein Video-Encoder her). Das RGB-Overlaybild wollte ich in nem µC erzeugen, STM32 oder ähnlich. Das gute ist, der Video-Encoder gibt ein Genlock-Clock aus, mit dem man H-Sync und Phase für die Farbe synchronisieren kann. Also insgesamt 4 ICs, allesamt recht günstig (Decoder und Encoder je 1-5€,FPGA 10€ und 8€ für den STM32). Leider ist das ein recht komplexes Projekt, bei dem ich bestimmt schnell an meine Grenzen komme, aber es gibt relativ viel Dokumentation, und ich will ja auch was lernen.... > Wie wäre denn der Ansatz, einen normalen Framegrabber zu verwenden (USB, > unter 20.-) und dazu einen Raspberry für die Datenverarbeitung. Das wäre wirklich das einfachste, es gibt da nur 1-2 Probleme: 1. Die Latenz. Ich hab mir schon gedacht das da bestimmt ein Lag auftritt, da der Datenstrom ja durch die arme kleine USB 2.0-Schnittstelle gestopft werden muss. Ohne Komprimierung geht das nicht und die verursacht auf jeden Fall Latenz. Nun habe ich gerade keinen Framegrabber da um diese Theorie zu überprüfen aber ich habe das hier: https://www.youtube.com/watch?v=DFI_bFxahDA Bis ich da sehe dass ein Baum auf mich zukommt, haben sich die Eichhörnchen längst ein Nest aus meinem Kopter gebaut :) Zum zweiten noch Größe und Gewicht.. ist bei nem Pi zero nicht so wild, aber ich wollte nur noch erwähnen dass sich der ganze OSD-Kram wegen der Echtzeitdaten vom Flugcontroller traditionell IM Fluggerät befindet. Ich weiß, traditionell ist dafür auch nur ein IC nötig aber wer mehr will muss halt Kompromisse eingehen... Aber deswegen wende ich mich ja an euch. Nicht das der Eindruck entsteht oben skizzierter Plan sei mein Masterplan, aber es ist halt das einzige was mir einfällt um ein zeitgemäßes OSD zu implementieren (sofern man von analog-Video überhaupt noch von zeitgemäß sprechen kann). Vielleicht hat jemand eine einfachere Idee.
Moin, PhiMX schrieb: > ...ich hab mir das so > gedacht:... Jepp. Das koennt' schon so gehen. Ich wuerd' nur die Rechnerei YUV->RGB->YUV weglassen und das OSD-Bild auch gleich in YUV berechnen. Das spart einen Haufen Multiplizierer und vor allem Filterei; weil ja die Abtastrate von Y doppelt so hoch ist, wie von U und V. Von YUV wieder nach PAL ist auch im FPGA eher wieder machbar, dann braucht's nur noch 'nen "dummen" DAC. Gruss WK
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.