Digitale Videoübertragung in FullHD 1080i & 1080p
- Themenstarter mueckchen
- Beginndatum
- Status
Ihr müsst nach SDI Funkstrecke suchen. Allerdings nicht wirklich billig. Sind meist 433Mhz Sender.
Die Funkstrecken arbeiten auf 250m absolut störungsfrei auch durch dünne Wände oder in Messehallen
mit unmengen Metal und anderen Hindernissen. Allerdings up to 2k Eur und mehr... ohne Antennen, Kabel und etc
die Kosten nochmal das gleiche.
Die Funkstrecken arbeiten auf 250m absolut störungsfrei auch durch dünne Wände oder in Messehallen
mit unmengen Metal und anderen Hindernissen. Allerdings up to 2k Eur und mehr... ohne Antennen, Kabel und etc
die Kosten nochmal das gleiche.
Ahh, jetzt schnall ich das langsam:
SDI=Serial Data Interface
http://de.wikipedia.org/wiki/HD-SDI
Also, bei meiner ersten Suche habe ich nur Modems gefunden, die per OFDM im 5GHz Band arbeiten mit 4-5 parallel arbeitenden Kanälen.
Ich kann mir irgendwie nicht recht vorstellen, dass SD oder HD Video über 433MHz laufen kann, wegen der Bandbreite. Oder doch etwa?
SDI=Serial Data Interface
http://de.wikipedia.org/wiki/HD-SDI
Also, bei meiner ersten Suche habe ich nur Modems gefunden, die per OFDM im 5GHz Band arbeiten mit 4-5 parallel arbeitenden Kanälen.
Ich kann mir irgendwie nicht recht vorstellen, dass SD oder HD Video über 433MHz laufen kann, wegen der Bandbreite. Oder doch etwa?
SDI gibts glaub schon länger als Digitalfunk. HD btw imax/35mm wird ja in Filmbranche während der produktion schon seit sicher 20 Jahren eingesetzt. Es gab damals ultrateure HD Röhren Master Monitore für Filmproduktionen von Sony.
Ein paar hundert Meter ist doch erstmal ok -) Das Gewicht und der Stromhunger ist eher ein Problem.
Ein paar hundert Meter ist doch erstmal ok -) Das Gewicht und der Stromhunger ist eher ein Problem.
Ich habe mal einen neuen Thread zu unserer 3G/LTE Lösung erstellt: Sky Drone FPV
Interessanter Thread hier. Ich kann mir nicht vorstellen dass es so schwer ist ein digitales Signal vernünftig zu übertragen... Eine Analoge Übertragung ist doch quasi komplett unkomprimiert, und müsste so doch extrem viel Bandbreite ziehen?
Wie viel Bandbreite hat man bei 5,8 Gz oder anderen Frequenzen zur Verfügung?
Wenn man Einzelbilder übertragen würde und diese mit normalem JPG komprimierte, hätte ein Einzelbild bei starker Komprimierung und einer Auflösung von 1280x720 30 KB. Rechnet man das für 25 Frames die Sekunde kommt man auf 750 Kilobyte pro Sekunde. Man hätte eine Latenz von 40ms plus die Zeit die für die Komprimierung benötigt wird, was aber heutzutage wo jedes aktuelle Smartphone einen Quadcore Prozessor hat ziemlich schnell gehen dürfte bei normaler JPG Kompression.
750 KB/s ! Ich kann mir nicht vorstellen dass eine Analoge Übertragung weniger Bandbreite benötigt. Was meint ihr dazu?
Wie viel Bandbreite hat man bei 5,8 Gz oder anderen Frequenzen zur Verfügung?
Wenn man Einzelbilder übertragen würde und diese mit normalem JPG komprimierte, hätte ein Einzelbild bei starker Komprimierung und einer Auflösung von 1280x720 30 KB. Rechnet man das für 25 Frames die Sekunde kommt man auf 750 Kilobyte pro Sekunde. Man hätte eine Latenz von 40ms plus die Zeit die für die Komprimierung benötigt wird, was aber heutzutage wo jedes aktuelle Smartphone einen Quadcore Prozessor hat ziemlich schnell gehen dürfte bei normaler JPG Kompression.
750 KB/s ! Ich kann mir nicht vorstellen dass eine Analoge Übertragung weniger Bandbreite benötigt. Was meint ihr dazu?
Ich glaube, es ist umgekehrt: analoge Übertragung = kleinste Bandbreite. FBAS Signale haben so ca. 4-5MHz Bandbreite, genauer habe ich es nicht im Kopf. Durch die FM am Sender wackelst du also je nach der zu übertragenden Frequenz um den Träger herum. Enorm simpel, störanfällig aber preiswert.
Wenn es so einfach wäre wie du es beschrieben hast, dann wäre schon längst jemand mit einem Produkt am Markt und wir würden alle schon digital fliegen. Tun wir aber leider nicht.
Noch ein Beispiel: digitales Video in SD (BT.656) hat schon ca. 205 MB/s Datenrate. Wir reden noch gar nicht über HD, übrigens. Die musst du erst einmal runterkomprimieren für deinen digitalen Link. Das kostet Zeit und bringt dir Latenz.
Ich glaube auch, dass solche Operationen nur im FPGA schnell genug laufen. Dazu hatte ich mal einen Kontakt zu einem Prof. an einem Fraunhofer-Institut aufgebaut. Die machen Videokompression auf FPGA, aber es ist aussichtslos, die Cores zu lizensieren. Leider unbezahlbar und im OpenSource Bereich kommen die Jungs nicht in die Puschen.
Denn wenn sie es täten, würden sie ein Geschäft daraus machen. Macht aber leider (noch) keiner. Vielleicht kannst du dich einmal daran festbeißen...
Wenn es so einfach wäre wie du es beschrieben hast, dann wäre schon längst jemand mit einem Produkt am Markt und wir würden alle schon digital fliegen. Tun wir aber leider nicht.
Noch ein Beispiel: digitales Video in SD (BT.656) hat schon ca. 205 MB/s Datenrate. Wir reden noch gar nicht über HD, übrigens. Die musst du erst einmal runterkomprimieren für deinen digitalen Link. Das kostet Zeit und bringt dir Latenz.
Ich glaube auch, dass solche Operationen nur im FPGA schnell genug laufen. Dazu hatte ich mal einen Kontakt zu einem Prof. an einem Fraunhofer-Institut aufgebaut. Die machen Videokompression auf FPGA, aber es ist aussichtslos, die Cores zu lizensieren. Leider unbezahlbar und im OpenSource Bereich kommen die Jungs nicht in die Puschen.
Denn wenn sie es täten, würden sie ein Geschäft daraus machen. Macht aber leider (noch) keiner. Vielleicht kannst du dich einmal daran festbeißen...
Mit Bandbreite meinte ich eigentlich die "Umgangssprachliche Bedeutung", also Geschwindigkeit in Byte pro Sekunde 
Also die Datenrate.
Digitales Video in SD mit 205 MB/s? Das wäre bei 25 FPS 8,2MB pro Einzelbild. Also unkomprimiert.
Wie gesagt, wenn man JPG benutzen würde hätte ein Einzelbild nicht mehr 8,2MB sondern 25KB!
Und die Komprimierung nach JPG ist nicht besonders rechenintensiv, das dürfte man mit relativ geringer Latenz hinbekommen. Ich habe eben mal einen kleinen Test in Java gemacht, ein PNG Bild zu stark komprimiertem JPG umzuwandeln dauert mit der Standard Java Library bei mir 70ms. Das ist aber Java und die Umwandlung ist bestimmt nicht auf Schnelligkeit optimiert. Mit richtig gutem C++ Code sollte man da eigentlich auf Latenzen unter 10ms oder sogar 1ms kommen.
Also die Datenrate.Digitales Video in SD mit 205 MB/s? Das wäre bei 25 FPS 8,2MB pro Einzelbild. Also unkomprimiert.
Wie gesagt, wenn man JPG benutzen würde hätte ein Einzelbild nicht mehr 8,2MB sondern 25KB!
Und die Komprimierung nach JPG ist nicht besonders rechenintensiv, das dürfte man mit relativ geringer Latenz hinbekommen. Ich habe eben mal einen kleinen Test in Java gemacht, ein PNG Bild zu stark komprimiertem JPG umzuwandeln dauert mit der Standard Java Library bei mir 70ms. Das ist aber Java und die Umwandlung ist bestimmt nicht auf Schnelligkeit optimiert. Mit richtig gutem C++ Code sollte man da eigentlich auf Latenzen unter 10ms oder sogar 1ms kommen.
Analoge Signale haben keine Bandbreite in Byte/s, da sie, wie der Name schon sagt, analog übertragen werden. Also nicht diskretisiert, gesampled und in bit/bytes gepresst - sondern der Signalverlauf wird (moduliert) übertragen - das Signal/Rausch-Verhältnis sorgt dann für Verluste.
Dass 750kByte/Sekunde ja 6MBit/s Bruttodatenrate sind, hast Du auf dem Schirm? Das kriegt WLAN zwar hin, aber nicht unbedingt mit Dopplereffekt und auf große Distanzen... Müsste man mal testen.
Das Kompressionsverfahren was Du Dir da "ausgedacht" hast gibt es schon ne ganze Weile, ist mehr oder weniger standarisiert als M-JPEG bekannt (und wird zunehmend ersetzt/stirbt). Es wurde gerne in IP-Überwachungskameras verwendet, früher auch in Digicams. Wie Du schon schreibst, schnell zu komprimieren, keine großartige Latenz, aber "damals" reichten die Datenraten einfach nicht um da mehr als 320x240 zu übertragen. Das ist zwar inzwischen anders, aber moderne Kompressionsverfahren holen halt noch mal Faktor 10 raus (auf Kosten von Rechenzeit und damit auch indirekt Latenz, wenn man keinen FPGA nimmt). Bei allen digitalen Verfahren ist aber noch die Latenz des Protokollstacks, der Funkschnittstelle, und im Falle von GSM/UMTS etc., des Netzes dazuzurechnen, das summiert sich schnell.
Dass 750kByte/Sekunde ja 6MBit/s Bruttodatenrate sind, hast Du auf dem Schirm? Das kriegt WLAN zwar hin, aber nicht unbedingt mit Dopplereffekt und auf große Distanzen... Müsste man mal testen.
Das Kompressionsverfahren was Du Dir da "ausgedacht" hast gibt es schon ne ganze Weile, ist mehr oder weniger standarisiert als M-JPEG bekannt (und wird zunehmend ersetzt/stirbt). Es wurde gerne in IP-Überwachungskameras verwendet, früher auch in Digicams. Wie Du schon schreibst, schnell zu komprimieren, keine großartige Latenz, aber "damals" reichten die Datenraten einfach nicht um da mehr als 320x240 zu übertragen. Das ist zwar inzwischen anders, aber moderne Kompressionsverfahren holen halt noch mal Faktor 10 raus (auf Kosten von Rechenzeit und damit auch indirekt Latenz, wenn man keinen FPGA nimmt). Bei allen digitalen Verfahren ist aber noch die Latenz des Protokollstacks, der Funkschnittstelle, und im Falle von GSM/UMTS etc., des Netzes dazuzurechnen, das summiert sich schnell.
Aber das Video muss doch quasi Pixel für Pixel (unkomprimiert) übertragen werden, oder? Also muss die Anzahl der Signale die pro Sekunde gefunkt werden müssen auf jeden Fall höher sein als bei digitaler Übertragung. Und das heißt dass digitale Übertragung auch einfach möglich wäre.
Den Faktor 10 erreichst du aber nur wenn du mehrere Frames gleichzeitig komprimierst, sodass eine viel zu hohe Latenz entsteht. Für Einzelbilder alleine ist JPG schon eine der besten Komprimierungen, da erreicht man mit keiner anderen Einzelbild Komprimierung, egal mit wie viel Zeitaufwand Faktor 2.
Ich habe mal ein wenig herumgegoogelt was aktuelle ARM (Handy-) Prozessoren so an Leistung haben im Vergleich zu normalen x86 CPUs. Und das kann sich wirklich sehen lassen:
Ein Nvidia Tegra 4 (der aktuellste Smartphone Prozessor von Nvidia) hat 2/3 der Pro Kern Leistung eines AMD Phenom II X6, das ist mein Prozessor. Die Latenz die durch das Komprimieren entsteht würde also auch auf extrem stromsparenden ARM Prozessoren nicht deutlich höher sein als auf normalen Desktop PCs.
Ich glaube, hier liegt ein Denkfehler vor. Analoges Video besteht nicht aus vielen Signalen, sondern nur aus einem. Helligkeiten werden als Spannungen zwischen 0 und 1V abgebildet, die Farbinformation kommt phasenmoduliert obendrauf. Zusammen kann dieses HF-Signal einfach auf einem Träger moduliert werden per FM und das war's dann auch schon. Diese Technik ist bald 50 Jahre alt.
Ich möchte dich aber ermutigen, dich an der Sache festzubeißen, wenn du eine clevere Idee hast. Die Videotechnik ist enorm komplex geworden, und findige Ansätze für unseren Anwendungsbereich sind immer gefragt.
Ich möchte dich aber ermutigen, dich an der Sache festzubeißen, wenn du eine clevere Idee hast. Die Videotechnik ist enorm komplex geworden, und findige Ansätze für unseren Anwendungsbereich sind immer gefragt.
Nein, es gibt bei analogem Bild keine "Pixel" - die Zeile, also deren Helligkeitswerte, vereinfacht gesagt, werden als Signalkurve direkt übergeben, man spart sich hier sowohl die vertikale Unterteilung als auch die Diskretisierung der Werte (wofür man dann Bits brächte). Kommt es da zu Störungen, zeigen halt ein paar Pixel auf deinem Monitor (spätestens am VGA-Eingang sitzt der letzte D/A-Wandler halt andere Helligkeitswerte - oder z.B. Schattenwurf nach rechts ist auch beliebtes Störbild. Irgendwo muss ja der Unterschied zu digital liegen Ich hoffe es war verständlich.
Nein, Kompression über mehrere Frames bedingt nicht unbedingt mehr Latenz, denn der Trick liegt ja da drin dass Informationen die im Vor-Frame "gleich" oder "ähnlich" waren nicht noch mal übertragen werden müssen. Der Empfänger kann das erste Keyframe dekodieren und anzeigen bevor die Information des nächsten da ist - usw. Es ist halt nur mehr Aufwand (CPU, RAM, I/O).
Oder sogar noch geringer, da aktuelle ARM-SoCs gerne mal eine h264-Hardwarekompression eingebaut haben (siehe Raspberry Pi)
Ich hoffe es war verständlich.Nein, Kompression über mehrere Frames bedingt nicht unbedingt mehr Latenz, denn der Trick liegt ja da drin dass Informationen die im Vor-Frame "gleich" oder "ähnlich" waren nicht noch mal übertragen werden müssen. Der Empfänger kann das erste Keyframe dekodieren und anzeigen bevor die Information des nächsten da ist - usw. Es ist halt nur mehr Aufwand (CPU, RAM, I/O).
Oder sogar noch geringer, da aktuelle ARM-SoCs gerne mal eine h264-Hardwarekompression eingebaut haben (siehe Raspberry Pi)
- Status
