Kurze Frage - Systemdesign Line-Shuffling-Video-Scrambler

[TU Student 1. (student0)]

Eine kurze Frage an die erfahrenen Entwickler hier - ist dieses 
System-Design plausibel?

Entwickeln will ich einen Video-Scrambler, ähnlich dem historischen 
analogen NAGRA-Verfahren (Premiere analog) - Line Shuffling.  Die 
Videozeilen werden dabei nach einem gewissen Muster vertauscht - wobei 
hier natürlich ein Halbbild-Speicher notwendig ist.  Das ist nicht 
sicher, aber hält wahrscheinlich gut genug Gelegenheits-Voyeure auf 
"bekannten" Bändern wie 5.8GHz (vor allem FPV) ab.

Meine Design-Idee:
Der Takt wird aus der H-Sync-Frequenz, die von einem Sync-Separator 
gewonnen wird durch eine PLL vervielfacht und ist der ADC-Pixeltakt. 
Der ADC (TLC5510) digitalisiert direkt das Composite-Signal einer Zeile 
ohne Demodulation.  Ein Dual-Port-FIFO-Speicher (AL422) wird mit den 
ADC-Daten gefüllt.   Ein Mikrocontroller, mit praktischerweise gleichem 
Pixeltakt als Takt (keine Vorraussetzung beim DP-FIFO) oder einem 
anderen Vielfachen der PAL-Horizontalfrequenz, liest den FIFO aus und 
beschreibt abwechselnd (Double-Buffering) 2 SRAMs, wobei die 
RAM-Adressen nun nach einem Muster vertauscht werden.  Das jeweils 
gerade nicht mit Video-Daten befüllte SRAM wird von einem anderen 
Mikrocontroller ausgelesen und per DAC analogisiert. In der letzten 
Zeile werden als Key-Indexes oder andere Steuerdaten als  Blöcke 
übertragen, damit der Empfänger sich synchronisieren kann, falls z.b. 
ein Videobild verloren geht.   Vermutlich kann man auch den zweiten 
Mikrocontroller und das zweite SRAM weglassen, wenn man mit der 
doppelten Taktfrequenz arbeitet und das ganze "multiplexed" - erstmal 
würde ich es aber so machen.

Resultat ist ein zeilenvertauschtes Videobild, wobei die Vertauschung im 
Empfänger nach demselben Schema rückgängig gemacht wird.

Optional könnte die PLL auch  weggelassen werden, da es auch ausreichen 
könnte,  wenn ein schneller Mikrocontroller in Software auf den 
Zeilenanfang "triggert", wenn der Trigger immer an der gleichen Stelle 
ist -  da ja bei analogem Video der Pixeltakt innerhalb einer Zeile 
beliebig sein kann.  Pixel-Jitter kann man ab einer bestimmten Frequenz 
(f_CPU >> f_Pixel) vernachlässigen, weiss ich aus der Entwicklung von 
OSDs, die auch formal "asynchron" liefen (Takt nicht aus V/H-Sync 
abgeleitet) und sich in nur "softwarebasiert" auf H/V-Sync 
synchronisierten.

Ist dieses Systemdesign plausibel oder habe ich an etwas nicht gedacht?

[Dergute W. (derguteweka)]

Moin,

Ein Microcontroller koennt' etwas ins Schnaufen kommen, bei den Schreib- 
und Leseorgien auf's RAM. Aber mit einem FPGA sollte das schon machbar 
sein. Ist halt insgesamt schon ein Aufriss - vielleicht waere ein 
Videokabel ziehen einfacher und haette die gleiche Abhoersicherheit...

Gruss
WK

[Martin S. (strubi)]

Moin,

für Pixelfrequenzen bis ca. 33 MHz klappt das, was du willst, auf einem 
alten BF533 EZKIT. Habe mal nen PAL->NTSC-Wandler damit gemacht.
Für das Scrambeln würdest du dann verkette DMA-Descriptoren aufsetzen 
und jeweils im VBlank neu aufsetzen. D.h. es läuft auf cleveres Fahren 
gleichzeitiger DMA-Transfers raus.
Ansonsten würde ich dir bei höheren Bildfrequenzen eher zu einem FPGA 
raten, da musst du allerdings beim RAM genau hinschauen, SDRAM ist noch 
einfach, DDR2 schon kniffliger, und DDR3 ist eine richtige Bitch.
Wenn Scrambeln von einigen wenigen Zeilen ausreicht, geht es auch auf 
grösseren FPGAs locker im internen RAM.