mikrocontroller.net

Forum: Digitale Signalverarbeitung / DSP Videoverschlüsselung


Autor: Josef Krusch (netroman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Ich würde gerne für Videokameras eine digitale Videoverschlüsselung
realisieren.
Deshalb wäre ich für Vorschläge dankbar, wie ich so etwas am besten
angehen könnte. PIC Programmierkenntnisse in Assembler sind
vorhanden...

Vielen Dank im Voraus

                          Josef

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das große Problem wird die Datenrate sein, die du in deinen Chip, der
die Verschlüsselung macht, verarbeiten musst.
Sagen wir mal Video mit 320x240, 60Hz, 16bit (YUV 4:2:2 codiert). Das
macht eine Taktrate von 4,6Mhz, und eine Datenrate von 74Mbit/s. Das
kann ein PIC definitiv nicht verarbeiten. Am besten bei den Controllern
suchen, die für Video ausgelegt sind und entsprechende IOs dafür haben.
Dabei ist auch die Frage: Wie kommt das Video von der Kamera? Gibt die
Kamera das Video digital aus? Oder gibt sies analog aus, zB als PAL
Signal? Dann musst du schauen einen geeigneten Video AD Wandler zu
finden, mit einem Controller der dazu passt.
DSPs die für Video gedacht sind wären sicher eine brauchbare Lösung, du
hast ja selbst im anderen Thread schon den Blackfin erwähnt. Eine andere
Sache wäre die Lösung mit einem FPGA.

Autor: Josef Krusch (netroman-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, Matthias!

Vielen Dank für die Antwort!
Ich halte sowohl einen Blackfin, als auch einen FPGA als eine unter
Umständen eher (kosten-)günstige Lösung. Allerdings habe ich noch nie
einen FPGA programmiert und sehe da einen sehr großen Aufwand dahinter,
etwa dazu extra VHDL oder Verilog zu erlernen.
Beim Blackfin sehe ich wenigstens die Chance, durch meine
PIC-Programmierkenntnisse (Assembler), schneller vorwärts zu kommen.
Auch "C" wäre nicht das größte Problem.

Was die AD-DA Wandler betrifft, so bin ich bei www.ti.com fündig
geworden - ob die Handhabung der Wandler dann so einfach ist, werde ich
dann wohl noch sehen...

Kamera digital/analog? Erst einmal habe ich an analoge Kameras gedacht,
weil billiger und mehr verbreitet. Mit digitalen habe ich mich noch gar
nicht befasst bzw welche Schnittstellen diese bieten - tue ich aber
noch!

Generell stellt sich für mich als Hobby-Entwickler folgendes Problem:
In einer professionellen Entwicklungsabteilung sitzt mindestens ein
Fachmann für die Controller und ein anderer (!) für die FPGAs oder
CPLDs. Für einen einzelnen sehe ich das eher so, dass man da bald an
die Grenzen des machbaren bzw der verfügbaren Zeit stößt :-((

Ergo: Die simple Invertierung des Videobandes wäre einfach zu machen -
ist aber alles Andere als wirklich sicher. "Cut and rotate" oder
ähnliche Verfahren gehen ein klein Wenig über den Conrad-Bausatz hinaus
;-)

Ich glaube, dass ich mir da etwas zu viel vorgenommen habe - aber es
heißt ja, "der Wille zählt für das Werk" gg

Lg Josef

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Machbar ist das schon, auch wenn da schon einiges an Aufwand und viel zu
  Lernen dahinter steckt. Aber das muss ja nicht umbedingt schlecht
sein.
Ein großes Problem ist, dass die geeigneten schnellen Chips auch alle
ein gutes Board und Layout benötigen, das meist gleich >= 4 Layer
bedeutet, und für den Hobby Bereich sehr teuer ist.
Beim Blackfin könntest du eventuell als Entwicklungsplattform auf das
Blackfin BF533 Stamp Kit zurückgreifen, das es bei Farnell für relativ
humane 136Eur gibt.
Auf der zum Blackfin Linux Projekt zugehörigen Seite
(http://blackfin.uclinux.org ) gibts auch Schematics zu Erweiterungen,
wie Video In und Video Out:
http://blackfin.uclinux.org/frs/?group_id=7&releas...

Wenn du mal auf den Bytestream im Controller zugreifen kannst sollte
die Implementierung einer verschlüsselung des Signals nicht mehr ein
allzu großes Problem darstellen.
Wie willst du eigentlich das signal nach der verschlüsselung weiter
übertragen? Wieder als analoges Signal? Oder dann auf irgendeine
digitale Weise?

Autor: Josef Krusch (netroman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Hinweis!
Ich habe zufällig heute gerade das Board bei Farnell gesehen - der
Preis ist indeed eher human. Ich wusste nur nicht, was ich alles mit
diesem Board anfangen könnte.

Die Frage über die weitere Übertragung ist nicht nur berechtigt,
sondern auch gravierend! Am schönsten wäre, das Signal einfach digital
weiterzuleiten. Ich habe zwar Erfahrung mit RF-Modulen auf 433/866 MHz.
Diese dürften aber zB viel zu langsam sein für solche Datenraten - das
ist wahrscheinlich noch milde ausgedrückt.
Vielleicht gibt es da etwas mit wesentlich mehr Bandbreite im 2,4GHz
Bereich. Das bezweifle ich allerdings, da sich das mit den genehmigten
Frequenzen vermutlich nicht ausgeht - HF lässt grüßen :-)

Mir ist klar, dass es nochmals um einiges umständlicher wird, wenn das
Signal nach der Verschlüsselung wieder analogisiert wird. Das birgt
zusätzliche Fehlerquellen, mehr Aufwand, Kosten etc.

Ich habe eben nicht einmal (noch nicht) Erfahrung mit den von Dir
beschriebenen speziellen Videoeingängen von DSPs.

Wenn ich mir die möglichen Sampleraten der ADC/DACs, die auch zu eher
moderaten Preisen erhältlich sind, ansehe, so scheint die Wandlung ja
gar nicht so schwer zu sein - scheint...

Ein Board mit 4 Layern im Eurokarten-Format kostet schon an die
100€ -  ich weiß.

So langsam nähert man sich dann schon der Tatsache, dass es natürlich
schon fertige cut and rotate Lösungen gibt. Die allerdings irgendwo im
1.000-2.000 EUR liegen, soweit ich mich erinnere.

Ein anderer Ansatz wäre uU mit IP-Kameras und automatisch
verschlüsselter Übertragung über ein WLAN.

Ja sogar die Verwendung von ausgedienten D-Boxen über WLAN wäre denkbar
- jedoch nicht zukunftsträchtig, da man die Boxen nicht mehr lange
bekommen wird.

Na, ja - ich habe ja schon geschrieben, dass ich mir da wohl zu viel
vorgenommen habe - leider!

Obwohl ich ja teilweise zu einem regelrechten "2-Layer Künstler"
mutiere ;-) Ich habe kürzlich ein PIC18F8722 Board mit 2 128x8 SRAMs
gebaut mit 2 Layern. Auch das ging - das ist allerdings noch nicht mit
den doppelt so vielen Pins des Blackfin vergleichbar - ächz!

Lg Josef

Autor: Josef Krusch (netroman-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So - jetzt ist mir noch eine simpel klingende Lösung eingefallen:

1) A/D-Wandler mit 8-bit Ausgang
2) weiter auf XC9572XL - schafft ja eher recht hohe Taktraten >100MHz
3) im XC9572XL die Bits ein wenig verändern zB für den Anfang
invertieren als Test
4) vom XC9572XL wieder auf einen D/A-Wandler und ab zum Sender...

Wenn meine Rechnung aufginge, wäre eventuell ein 2-Layer Board
ausreichend, da ich nicht so hohe Taktraten fahren muss wie in einem
Blackfin.

Ich werde mal ein bisschen herumprobieren.

Sollte ich grundlegend falsch liegen, wäre ich natürlich für
entsprechende Hinweise dankbar ;-)

Gruß Josef

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gescambled haste das Videosignal jetzt ja, aber wie willst Du das jetzt
wieder sichtbar machen? (Ich gehe mal davon aus das das gewünscht ist
...)
Da bräuchtest Du beim Empfänger ein Analogsignal das bei der
AD-Wandlung wieder zu einem identischen Bitmuster führt, sonst
funktioniert die Bitweise Verschlüsselung nicht. Und dann ist da noch
das Problem mit den Synchronimpulsen.

Autor: Josef Krusch (netroman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@tom:
Natürlich gehe ich davon aus, dass das so veränderte Bild nach der
Übertragung per Funk wieder auf umgekehrte Weise wieder entschlüsselt
werden kann. Genauer gesagt mit der selben bzw einer gleichartigen
Platine, wo der CPLD die Bits wieder zurechtrückt. So bräuchte ich
wenigstens nur einen Platinenentwurf.

Sollte ich da allerdings irgendwo gravierende Denkfehler eingebaut
haben, wird es schwer ;-)

Gruß Josef

P.S: Die Synchronimpulse werden doch eh von den D/A u A/D Wandlern
berücksichtigt, oder? zB ADV7183BBSTZ und als Gegenstück ADV7191KSTZ -
jeweils von Analog Devices.

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollen die Signale digital oder Analog übertragen werden ?
Wenn man die Bits verschiebt, das ganze analog überträgt und wieder
digitalisiert und dann wieder die Bits zurückschiebt, kommt was anderes
raus, als das eigentlich Signal.

Autor: Josef Krusch (netroman-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Benedikt:

Ich habe(hatte) das vor, was Du gerade beschrieben hast.
Leider weiß ich keinen kostengünstigen Weg, die Signale digital per
Funk zu übertragen - oder gibt es da vertretbare Lösungen?

Zumindest war ich der Meinung, dass am Ende wieder das raus kommt, was
man vorher hineingeschickt hat.

Da ich aber mit Video noch nichts gemacht habe, fehlt es mir da leider
an Erfahrung...

Kannst Du mich ein wenig aufklären, warum dann am Ende was anderes
herauskommt?

Gruß Josef

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sagen wir mal du vertauschst Bit 0 und Bit 7
Jetzt wird plötzlich aus einer kleinen eine große Spannungsänderung und
umgekehrt.
Bei der Funkübertragung gehen Informationen verloren, und komme
Rauschen hinzu. Daher wackelt jetzt auf einmal D0, was ja am Ende
wieder D7 ist.

Also ganz so einfach lässt sich das Signal nicht verschlüsseln.

Besser ist es, das Bildsignal ganz zu lassen, aber nur einzelne Zeilen
zu vertauschen. Dazu braucht man aber einer etwas größeren CPLD und
einen SRAM in den die Daten Zeilenweise geschrieben werden, und dann
z.B. mit umgekehrter Adressierung (also A0 statt A7, A1 statt A6 usw.)
ausgelesen und gesendet werden.

Für sowas ist ein CPLD optimal, da es nur einfache logische Operationen
sind, und man alles auf die Sync Signale synchronisieren kann.

Autor: Josef Krusch (netroman-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tip - ich hatte auch schon dahin gehende Befürchtungen,
dass die analoge Übertragung da Störungen verursachen kann/wird.

Was ich benötigen würde, wären fundierte Unterlagen, aus denen
hervorgeht, was genau mir die von den D/A-A/D Wandlern
ausgegebenen/eingelesenen Signale "H-Sync" und "V-Sync" genau
anzeigen. Wann also weiß ich, dass eine Zeile komplett ist und wann
eine Seite fertig ist?

Ich fand ja nicht einmal nähere Unterlagen für die von mir erwähnten
Wandler (ADV7183BBSTZ und ADV7191KSTZ). Das Datasheet hat zwar eine
Anschaltung der Chips dabei - den Umgang mit den erwähnten
Sync-Signalen setzt man jedoch leider voraus ("no, na, ned").

Als CPLD stehen mir wie gesagt XC9572XL mit 44 und glaublich 100 Pins
zur Verfügung. Ich fürchte jedoch, dass ich unter Umständen eher auf
FPGAs zurückgreifen müsste wegen der S-RAMs, oder?

Ich habe schon S-RAMs versuchsweise angesteuert - mit einem PIC18F8722.
Der hat aber schon ein eigenes Interface dafür. Ein CPLD würde da wohl
eher "gnadenlos" ohne Rücksicht auf Timings drauflos schreiben.

Auch 2 Stk der Spartan (alte Version I) hätte ich - aber keinerlei
VHDL/Verilog Kenntnisse.

Ich "liebäugle" schon lange auf ein Stamp-Board der Blackfin BF533 -
aber mir kommt vor, dass es eventuell besser wäre, in ein EVAL-Board
für Spartan III zu investieren. Mein Gefühl (Wissen ist es eben nicht
;-) ) sagt mir, dass der Spartan leichter zum erlernen ist, als ein
Blackfin mit all seinen Tücken.
Aber gerade über den Spartan III habe ich bis jetzt noch nicht wirklich
viel Lesestoff gefunden, oder Schaltungsbeispiele.

Gruß Josef

Autor: Josef Krusch (netroman-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So - jetzt habe ich endlich Infos zum Videosignal bzw zur
Synchronisation gefunden:
http://www.azubi.vision-tools.com/Videosignale.htm

Außerdem habe ich mich jetzt durchgerungen, mit das Spartan3-Kit zu
bestellen. Mal sehen, was daraus wird...

Jetzt wird es wohl langsam Zeit, das Thema nach "Programmierbare
Logik" zu verlegen :-)

Ich finde einfach die Kosten für die Verwendung von Blackfin für den
Hobbybereich zu hoch (Entwicklungs-Software, Multilayer-Boards etc).

Gruß Josef

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wenn Du nur verhindern willst, daß jeder die Übertragung mitsehen kann,
schau Dir die alten analogen Verschlüsselungen von Premiere, Teleclub,
RTL??? an.
Zeilen nach wiederkehrendem Muster invertieren, Sync-Impuls
invertieren, Sync als Sinus-Impuls mit einigen kHz übertragen und das
wahlweise kombiniert.
Macht wenig Aufwand (LM1881, NE592, CD4051 usw.).

Die Steuerung des Coders/Encoders kann ein kleiner Atmel erledigen,
beim Teleclub-Decoder hat schließlich auch mein C64 zum decodieren
gereicht...

Gruß aus Berlin
Michael

Autor: Josef Krusch (netroman-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, Michael!

Sehr interessante Hinweise - offensichtlich bist Du gut vertraut mit
diesen alten, aber für den "Hausgebrauch" völlig ausreichenden
Methoden der Verschlüsselung!

Ich habe mir die Datenblätter der Bausteine, die Du erwähnt hast, schon
kurz angesehen!

Derzeit bin ich allerdings schon mittendrin im Layout für eine
"simple" digitale Lösung, dass ich schon rein aus Interesse erst mal
daran weiterbasteln werde. Wenn das allerdings nichts wird, greife ich
vermutlich auf die erwähnten Methoden zurück.

Jedenfalls vielen Dank für die hilfreichen Hinweise!

Gruß Josef

P.S: Auch Nagra II wurde geknackt - was soll's also, irgendwelche
komplizierten Algos zu entwickeln...

Autor: Michael U. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

sicher ist das relativ problemlos zu knacken, wenn man es will und die
Moglichkeit hat, sich z.B. mit einem Speicheroszi eine Weile die
Signale aufzunehmen. Normale Videorecorder und vermutlich auch digitale
sind als Zwischenspeicher aber kaum zu gebrauchen.
Das hängt also von Deiner Einschötzung der nötigen Sicherheit ab.

Zum Prinzip: mit dem 1881 (oder Nachfolgern) H- und V-Sync separieren,
die muß ein kleiner Prozessor bekommen und mitzählen.
Das Videosignal durch den NE592 schicken, bekommt man an den Ausgängen
mit 0 und 180Grad Phase raus. Diese Ausgänge auf den Analogschalter,
den vom Prozessor ansteuern. Sync wird dahinter mit einem Transistor
wieder eingetastet.
Der Trick liegt jetzt darin, in jedem Halbbild (V-Sync) bestimmte
Zeilen in der Polarität umzuschalten. Das System nach einer bestimmten
Anzahl Halbbilder wechseln usw.
Am anderen Ende passiert das dann umgekehrt.
Damit der Kram die Tabellen syncron abarbeiten kann, in einer der
ersten Zeilen nach dem Halbbildwechsel einen Startcode mitschicken.
Der kann z.B. vom Prozessor in Zeile 16 (als Beispiel) geschrieben
werden, bei 16 benutzten Tabellen wären das dann nur 4Bit.
Die lassen sich auch recht einfach wieder auswerten.
50 Halbbilder/s und z.B. eine Tabelle für 300 Halbbilder würde alle 6s
einen Sync bedeuten. Es würde also nach den zuschalten max. 6s dauern,
bis der Decoder syncron ist.

Naja, falls das interessant werden sollte, suche ich mal, was ich dazu
noch habe.

Gruß aus Berlin
Michael

Autor: Josef Krusch (netroman-)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Nochmals danke für die interessanten Ausführungen! Wenn man einmal
dahinter gekommen ist, weiß man, wie einfach so etwas gehen könnte.

Heute habe ich übrigens mein Spartan3-Kit von Segor bekommen (sind mir
sympatischer als eine vielzitierte Konkurrenz) - bin schon gespannt.

Zur Zeit bin ich allerdings eh noch etwas mit dem Layout meiner
"Digital-Lösung" beschäftigt, denn es kommen vor: 1xTVP5150AM1,
1xADV7191, 1xXC9572XL und ein PIC18LF452 für die I²C-Kommunikation mit
den Wandlern (Setup) und eventuell noch ein SRAM.
Das ist eine Menge "Holz" - bin schon am überlegen, ob ich die
Platine dann nicht fertigen lasse wegen der gleichmässigen Verzinnung,
die beim löten der sehr feinen PINs hilfreich wäre, sowie der
Lötstoplack... Aber wehe das Layout war fehlerhaft, dann ist die Kohle
umsonst gewesen - wenn ich selber ätze, ist mir das noch eher egal,
weil wesentlich billiger.

Gruß Josef

Autor: Heinz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie viel Rechenpower würde ich benötigen, um ein S/W CCIR Videosignal
(352*288*256 Graustufen) zu diitalisieren und zwischenzuspeichern?
Würde das ein ARM mit externem ADC schaffen?

Autor: alpha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit einem PIC wirst du zwar nicht weit kommen, aber da du schon mit dem
Spartan3 experimentierst, wird unsere Lösung in Frage kommen.

Dieser FPGA ist in der Lage, das Videosignal MPEG-ähnlich zu
komprimieren, zu verschlüsseln und mit Fehlerkorrekturcodes erweitert
über eine Funkstrecke (TV-Qualität) zu übertragen. Damit bist du gegen
Rauschen und Störsignale weitgehend abgesichert. Habe irgendwo noch die
Projektdateien (20 Videochannel mit 2x Virtex4, sollte aber übertragbar
sein).

Autor: Netroman_ (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@alpha:

Das klingt zwar sehr kompliziert, dennoch höchst interessant! Würdest
Du tatsächlich die Dateien zur Verfügung stellen?

Gruß Josef

P.S: Meine simple Lösung funktioniert inzwischen wie es aussieht.

Autor: Marco S. (masterof)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Heinz

Das wären ca 77,34MByte/s wo deine Schaltung verarbeiten müste wenn ich
mich nicht verrechnet habe.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo muss sie die Verarbeiten?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.