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.
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
