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
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.
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
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&release_id=284 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?
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
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
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.
@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.
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.
@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
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.
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
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
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
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...
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
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
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?
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).
@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.
@Heinz Das wären ca 77,34MByte/s wo deine Schaltung verarbeiten müste wenn ich mich nicht verrechnet habe.
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.