Digitale Videoübertragung in FullHD 1080i & 1080p
- Themenstarter mueckchen
- Beginndatum
- Status
Wie waere es hiermit: http://www.minicaster.com/mobile-h-264-live-pocket-encoder/ ?
Leider steht in den Specs keine Latenz. Kommt wahrscheinlich auch auf die Latenz auf der Empfaenger-/Decoderseite an.
Und hier nochmal der Link zu dem im Video mit dem ferngesteuerten Auto von "The M" verwendeten Video-Encoder: http://www.teradek.com/thenewcube.html
Es scheint von dieser Sorte (1k - xk Euro) mehrere mobile und drahtlose HD-Videoencoder zu geben. Hat da jemand vielleicht Kontakt zu Leuten die sowas beruflich einsetzen und ihre Erfahrungen teilen wuerden?
Was ist denn die Latenzschranke die fuer FPV nicht ueberschritten werden duerfte?
Leider steht in den Specs keine Latenz. Kommt wahrscheinlich auch auf die Latenz auf der Empfaenger-/Decoderseite an.
Und hier nochmal der Link zu dem im Video mit dem ferngesteuerten Auto von "The M" verwendeten Video-Encoder: http://www.teradek.com/thenewcube.html
Es scheint von dieser Sorte (1k - xk Euro) mehrere mobile und drahtlose HD-Videoencoder zu geben. Hat da jemand vielleicht Kontakt zu Leuten die sowas beruflich einsetzen und ihre Erfahrungen teilen wuerden?
Was ist denn die Latenzschranke die fuer FPV nicht ueberschritten werden duerfte?
Zuletzt bearbeitet:
Glaub mir, mit ner halben Sekunde Verzögerung hättest du nicht viel Spaß! Das Problem bei solch hohen Latenzen ist, dass wenn du z.B. siehst, dass dein Flugzeug nach links fliegt, dann lenkst du nach rechts. Es passiert aber zunächst nichts. Erst wenn du siehst, dass es wieder geradeaus fliegt lässt du den Knüppel los, die tatsächliche Fluglage ist dann jedoch schon nach rechts gekippt. Deine Steuerbefehle schaukeln sich dann quasi auf, bis du abstürzt.
Ich würde sagen über 100ms sollte die Latenz nicht liegen, eher so im Bereich von unter 50ms, wie Rangarid schon sagte.
@Jonek: Alle digitalen Videofunkübertragungen die auf Transcodierung basieren haben sehr hohe Latenzen. Die HD Auflösung macht die Situation noch schlechter, da sind zum Teil Verzögerungen von mehreren Sekunden im Spiel.
Das ist ja der Grund, weshalb WHDI so interessant ist, weil es eben nicht Transcodiert. Verzögerungen sind hier unter 1ms, per Spezifikation!
Ich würde sagen über 100ms sollte die Latenz nicht liegen, eher so im Bereich von unter 50ms, wie Rangarid schon sagte.
@Jonek: Alle digitalen Videofunkübertragungen die auf Transcodierung basieren haben sehr hohe Latenzen. Die HD Auflösung macht die Situation noch schlechter, da sind zum Teil Verzögerungen von mehreren Sekunden im Spiel.
Das ist ja der Grund, weshalb WHDI so interessant ist, weil es eben nicht Transcodiert. Verzögerungen sind hier unter 1ms, per Spezifikation!
Hier das hab ich grade im Katalog gesehen: http://www.conrad.de/ce/de/product/873879/
Es ist zwar nirgens geschrieben, das muss aber WHDI sein.
Es ist zwar nirgens geschrieben, das muss aber WHDI sein.
Die technische Diskussion rund um WHDI (keine Umkodierung) bzw. low-latency Videoübertragung per WIFI (mit Umkodierung) finde ich weiterhin überaus spannend!
Diese Diskussion hier hatte für mich einen hohen informationsgehalt: http://fpvlab.com/forums/showthread.php?6629-Low-latency-3D-HD-Wireless-Transmitter-for-FPV
Hat hier schon mal jemand mit HD-Video über WIFI in einem mobilen Szenario ernsthaft experimentiert?
Schöne Grüße,
Jonek.
Diese Diskussion hier hatte für mich einen hohen informationsgehalt: http://fpvlab.com/forums/showthread.php?6629-Low-latency-3D-HD-Wireless-Transmitter-for-FPV
Hat hier schon mal jemand mit HD-Video über WIFI in einem mobilen Szenario ernsthaft experimentiert?
Schöne Grüße,
Jonek.
Sunshadow8: Bei zunehmender Entfernung gibt es bei digitaler Übertragung im Allgemeinen mehr Übertragungsfehler. Einzelne Datenpakete kommen dabei entweder ganz oder gar nicht an. Moderne digitale Videocodecs für das Streaming können die Anzahl der Übertragungsfehler erkennen. Manche können sich sogar anpassen. Dazu senken oder erhöhen die Sender (die den Videostream encodieren) die Datenrate des Videostreams je nachdem ob mehr oder weniger Übertragungsfehler auftreten. Die Datenrate des Streams kann durch stärkere Kompression bei gleicher Auflösung oder durch geringere Auflösung bei gleicher Kompressionsrate gesenkt werden.
Gruss, Jonek.
Gruss, Jonek.
Hallo zusammen,
das ist mein erster Post hier, allerdings lese ich schon seit Monaten mit. Seit April beschäftige ich mich mit digitaler Bildübertragung für FPV. Meine Erkenntnisse bis jetzt. WHDI wird über größere Entfernungen nicht gut funktionieren, die zu übertragende Datenmenge bei unkomprimiertem HD Video ist viel zu hoch. Selbst mit höherer Sendeleistung und Richtantennen wird man wahrscheinlich keine für FPV ausreichende Entfernung schaffen.
Man muss das Video komprimieren, dazu bietet sich entweder MJPG oder H.264 an. MJPG komprimiert nicht ganz so gut, ist aber fehlertoleranter. H.264 dagegen komprimiert sehr gut, für ein 1080p Video mit 30 Bildern/s reicht eine Bitrate von 3 MBit/s bei guter Qualität. Allerdings kommt es schneller zu störenden Artefakten oder sogar zu Bildaussetzern bei Packetverlust.
Unter diesem Link gibts auch eine Menge interessanter Informationen, das hatte mir schon sehr weitergeholfen.
Momentan nutze ich eine Logitech C920 Webcam mit Hardware H.264 Encoderchip, die Webcam liefert einen FullHD H.264 Stream über USB, der angeschlossene PC muss also nur noch den komprimierten Stream über USB entgegennehmen. Bei Ebay habe ich einen MK802 Mini PC für 70€ bekommen. Darauf läuft Ubuntu. Am zweiten USB Port hängt ein Zioncom wl0162 Wlan Stick. Für die Übertragung habe ich eine eigene Anwendung geschrieben, die auf möglichst niedrige Latenz optimiert ist. Die Anwendung schickt die Datenpakete dann über 802.11b Wlan mit 11 Mbit/s an mein Macbook. Dort wird der Stream wieder zusammengesetzt und von der GPU decodiert.
Ich hab alles soweit wie möglich auf niedrige Latenz optimiert, trotzdem liegt die Latenz bei 150ms. Die Reichweite liegt bei max. 400m mit Stabantennen. Das codieren/encodieren ist bei H.264 sehr zeitaufwending. Wenn ich die Komprimierung auf MJPG umstelle, erreiche ich Latenzen von 80-90ms. Allerdings muss die Auflösung dann wegen der höheren Bitrate auf VGA reduziert werden.
Also selbst die 80ms nimmt man schon als störend wahr, bei 150ms merkt man eine deutliche Verzögerung. Ohne gute Stabilisierung ist fliegen also ziemlich riskant. Man steuert zu spät und auch zu lange gegen. Wenn man versucht den Copter mit kleinen Korrekturen wieder zu stabilisieren, man man es nur noch schlimmer. In bin gerade dabei mir einen Quad mit Arducopter aufzubauen und das ganze dann damit zu testen.
Gruß Mathias
das ist mein erster Post hier, allerdings lese ich schon seit Monaten mit. Seit April beschäftige ich mich mit digitaler Bildübertragung für FPV. Meine Erkenntnisse bis jetzt. WHDI wird über größere Entfernungen nicht gut funktionieren, die zu übertragende Datenmenge bei unkomprimiertem HD Video ist viel zu hoch. Selbst mit höherer Sendeleistung und Richtantennen wird man wahrscheinlich keine für FPV ausreichende Entfernung schaffen.
Man muss das Video komprimieren, dazu bietet sich entweder MJPG oder H.264 an. MJPG komprimiert nicht ganz so gut, ist aber fehlertoleranter. H.264 dagegen komprimiert sehr gut, für ein 1080p Video mit 30 Bildern/s reicht eine Bitrate von 3 MBit/s bei guter Qualität. Allerdings kommt es schneller zu störenden Artefakten oder sogar zu Bildaussetzern bei Packetverlust.
Unter diesem Link gibts auch eine Menge interessanter Informationen, das hatte mir schon sehr weitergeholfen.
Momentan nutze ich eine Logitech C920 Webcam mit Hardware H.264 Encoderchip, die Webcam liefert einen FullHD H.264 Stream über USB, der angeschlossene PC muss also nur noch den komprimierten Stream über USB entgegennehmen. Bei Ebay habe ich einen MK802 Mini PC für 70€ bekommen. Darauf läuft Ubuntu. Am zweiten USB Port hängt ein Zioncom wl0162 Wlan Stick. Für die Übertragung habe ich eine eigene Anwendung geschrieben, die auf möglichst niedrige Latenz optimiert ist. Die Anwendung schickt die Datenpakete dann über 802.11b Wlan mit 11 Mbit/s an mein Macbook. Dort wird der Stream wieder zusammengesetzt und von der GPU decodiert.
Ich hab alles soweit wie möglich auf niedrige Latenz optimiert, trotzdem liegt die Latenz bei 150ms. Die Reichweite liegt bei max. 400m mit Stabantennen. Das codieren/encodieren ist bei H.264 sehr zeitaufwending. Wenn ich die Komprimierung auf MJPG umstelle, erreiche ich Latenzen von 80-90ms. Allerdings muss die Auflösung dann wegen der höheren Bitrate auf VGA reduziert werden.
Also selbst die 80ms nimmt man schon als störend wahr, bei 150ms merkt man eine deutliche Verzögerung. Ohne gute Stabilisierung ist fliegen also ziemlich riskant. Man steuert zu spät und auch zu lange gegen. Wenn man versucht den Copter mit kleinen Korrekturen wieder zu stabilisieren, man man es nur noch schlimmer. In bin gerade dabei mir einen Quad mit Arducopter aufzubauen und das ganze dann damit zu testen.
Gruß Mathias
Nein, ich habe WHDI noch nicht selbst getestet. Allerdings kamen alle Seiten die ich zu dem Thema gefunden hatte zum Schluss, dass große Reichweiten damit nicht möglich sind. Für FPV sollten es ja schon min. 400m sein.
Das Problem von WHDI ist sicher die hohe Datenrate von bis zu 1,5GBit/s. Ich habe einige Tests mit Wlan Hardware gemacht, die Reichweite hängt sehr stark von der zu übertragenden Datenmenge ab. Bei niedriger Datenrate kann man eine stabilere Modulation und bessere Fehlerkorrektur wählen. Außerdem sind die Wlan Empfänger bei niedriger Datenrate empfindlicher. Z.B. der von mir eingesetzte Stick hat bei einer Übertragungsrate von 130MBit/s -75dbM, bei 11MBit/s sind es -95dbM und bei 1 MBit/s -101dbM.
Zwischen 130MBit/s und 11Mbit/s liegt ein Unterschied von 20dbM. Das entspricht dann schon dem Antennengewinn einer sehr guten Yagi Antenne.
Das Problem von WHDI ist sicher die hohe Datenrate von bis zu 1,5GBit/s. Ich habe einige Tests mit Wlan Hardware gemacht, die Reichweite hängt sehr stark von der zu übertragenden Datenmenge ab. Bei niedriger Datenrate kann man eine stabilere Modulation und bessere Fehlerkorrektur wählen. Außerdem sind die Wlan Empfänger bei niedriger Datenrate empfindlicher. Z.B. der von mir eingesetzte Stick hat bei einer Übertragungsrate von 130MBit/s -75dbM, bei 11MBit/s sind es -95dbM und bei 1 MBit/s -101dbM.
Zwischen 130MBit/s und 11Mbit/s liegt ein Unterschied von 20dbM. Das entspricht dann schon dem Antennengewinn einer sehr guten Yagi Antenne.
Digitale Video Übertragung ?
Hallo,
ich bin seit einiger Zeit an einer Digitalen Funkübertragung (Video) interessiert, bei RC Groups findet man ja einiges darüber aber leider alles nur "Bastelprojekte"
Eventuell weiß ja jemand hier im Forum etwas genaueres darüber ? Und eventuell kennt ja der ein oder andere auch eine Bezugsadresse.
Die Zeitverzögerung und das recht hohe Gewicht sind mir bekannt
Hallo,
ich bin seit einiger Zeit an einer Digitalen Funkübertragung (Video) interessiert, bei RC Groups findet man ja einiges darüber aber leider alles nur "Bastelprojekte"
Eventuell weiß ja jemand hier im Forum etwas genaueres darüber ? Und eventuell kennt ja der ein oder andere auch eine Bezugsadresse.
Die Zeitverzögerung und das recht hohe Gewicht sind mir bekannt
Mit dem Teil hier sind laut Hersteller Latenzen mit 100ms machbar :
http://www.teradek.com/pages/cube
MfG
http://www.teradek.com/pages/cube
MfG
Ich arbeite seit ein paar Wochen immer mal wieder (im Kopf) an einer "All in One" Lösung. Es gibt halt zwei einander widerstrebende Anforderungen unter einen Hut zu bringen: Einerseits möglichst viele Daten auf engem Raum ("Bandbreite"), andererseits möglichst geringe Latenz. Je mehr Kompressionsarbeit zu leisten ist (speziell mit dem Wunsch hoher Bildqualität), desto höher wird notgedrungen die Latenz (das Standardproblem bei MPEG ist, dass MPEG eben gerade STREAMS komprimiert, also einige Bilder hintereinander braucht, um überhaupt komprimieren zu können - würde man nur i-Frames übertragen, könnte man gleich JPEGs senden, was man dann als MJPEG bezeichnen kann - und was auch die Lösung ist, die ich anstrebe).
MPEG hat mehrere grundsätzliche Nachteile für FPV: Zum einen die angesprochene, "immanente Latenz", die man grundsätzlich nicht vermeiden kann (ohne damit automatisch von MPEG wegzukommen), zweitens die Zahl der i-Frames, die man relativ hoch ansetzen muss, um abreißende Streams abzufangen (was zum selben Ergebnis führt wie die Reduzierung der Latenz durch kurze Streambuffer: Man sendet quasi Einzelbilder).
Da ich einige Jahre lang gut davon gelebt habe, automatisierte Bildverarbeitungssysteme zu entwickeln, kann ich mir vorstellen, eine Stream-Komprimierung selbst zu schreiben, die etwas besser als MJPEG ist. Es bleibt aber auch dann das Problem der Bandbreite: Will man, wie ich, dasselbe gestreamte Signal sowohl für Live-View als auch für die Aufzeichnung verwenden, braucht man wenigstens D2 Auflösung (ergibt ca. 24MB/sec für 25 Frames ohne Kompression, im Idealfall bei MJPEG also immer noch deutlich über 2MB/sec - wo soll man die unterbringen, ohne dass es zu ständigen Aussetzern kommt UND die Reichweite auf deutlich unter 300m eingeschränkt bleibt?).
Kurzum: Das Thema ist sehr, sehr spannend - und leider nicht trivial. Ich würde mich gerne mit ernsthaft Interessierten intensiv dazu austauschen (aber bitte nicht hier im Forum).
Marc
P.S. Eine einfache Überlegung zur Frage der glaubwürdigen Latenz ohne spezialisierte Codecs: Ein Frame bei 25 Bildern pro Sekunde ist 40ms lang. Zwei Frames also schon 80ms. Für eine streambasierte Kodierung sind zwei Frames eigentlich noch zu wenig, das heißt, dass man rein logisch bereits bei 120ms minimaler Latenz ist, die Zeit für Kodierung und Dekodierung nicht gerechnet. Wer also eine einfache streambasierte Lösung mit Latenzen von 100ms anbietet, versteht unter Latenz etwas anderes als ich
MPEG hat mehrere grundsätzliche Nachteile für FPV: Zum einen die angesprochene, "immanente Latenz", die man grundsätzlich nicht vermeiden kann (ohne damit automatisch von MPEG wegzukommen), zweitens die Zahl der i-Frames, die man relativ hoch ansetzen muss, um abreißende Streams abzufangen (was zum selben Ergebnis führt wie die Reduzierung der Latenz durch kurze Streambuffer: Man sendet quasi Einzelbilder).
Da ich einige Jahre lang gut davon gelebt habe, automatisierte Bildverarbeitungssysteme zu entwickeln, kann ich mir vorstellen, eine Stream-Komprimierung selbst zu schreiben, die etwas besser als MJPEG ist. Es bleibt aber auch dann das Problem der Bandbreite: Will man, wie ich, dasselbe gestreamte Signal sowohl für Live-View als auch für die Aufzeichnung verwenden, braucht man wenigstens D2 Auflösung (ergibt ca. 24MB/sec für 25 Frames ohne Kompression, im Idealfall bei MJPEG also immer noch deutlich über 2MB/sec - wo soll man die unterbringen, ohne dass es zu ständigen Aussetzern kommt UND die Reichweite auf deutlich unter 300m eingeschränkt bleibt?).
Kurzum: Das Thema ist sehr, sehr spannend - und leider nicht trivial. Ich würde mich gerne mit ernsthaft Interessierten intensiv dazu austauschen (aber bitte nicht hier im Forum).
Marc
P.S. Eine einfache Überlegung zur Frage der glaubwürdigen Latenz ohne spezialisierte Codecs: Ein Frame bei 25 Bildern pro Sekunde ist 40ms lang. Zwei Frames also schon 80ms. Für eine streambasierte Kodierung sind zwei Frames eigentlich noch zu wenig, das heißt, dass man rein logisch bereits bei 120ms minimaler Latenz ist, die Zeit für Kodierung und Dekodierung nicht gerechnet. Wer also eine einfache streambasierte Lösung mit Latenzen von 100ms anbietet, versteht unter Latenz etwas anderes als ich
Zuletzt bearbeitet:
könnte man nicht bei einer digitalen Übertagung auf mehrere kannäle ausweichen? beispielsweise du strebst es an, 2MB/s zu übertragen, dann könntest du doch beispielsweise auf 10 kanäle splitten, hört sich vllt. unrealistisch an, aber beispiel WLAN, dort stehen ja mehrere Kanäle zur verfügung, im grunde ist es dem SENDER egal welchen kanal er nehmen soll, einziges problem währe es die Syncronisation von Sender und Empfänger, aber auch dies sollte keine große schwierigkeit, da ja beispielsweise monitoring wie bei WLAN auch auf mehreren Kanälen "Lauscht"
Also die reine Übertragung sollte wohl klappen.
Also die reine Übertragung sollte wohl klappen.
Ja, natürlich liegt Splitting nahe (die WLAN-802-Lösung will ich im Januar ohnehin austesten, die hat aber natürlich den Nachteil der sehr begrenzten Reichweite). Die Synchronisierung ist nicht so schwierig zu realisieren, Splitting heißt aber natürlich auch Vervielfältigung der Fehler (wenn kein fehlertolerantes Protokoll wie z.B. bei WLAN verwendet wird, das wieder Overhead und Latenz bedeutet). Es kann nicht nur ein Kanal ausfallen, sondern mehrere. An der Reichweitengrenze hat man also - abhängig vom Codec - dann sehr viel schneller sehr viel schwärzere Bilder ...
Mein Gedanke geht daher in die Richtung "bewusstes Splitting", also Aufteilung des Originalbildes in z.B. 9 Felder, die autonom übertragen und im Empfänger erst wieder zusammengesetzt werden. Jedes Feld für sich darf jederzeit ausfallen, für FPV wäre das kein so großer Verlust (davon ausgehend, dass eben nur ein oder zwei Frames verloren gehen und der Codec ein schnelles Catch-Up erlaubt, also eben nicht MPEG mit wenigen i-Frames ist).
Mein Gedanke geht daher in die Richtung "bewusstes Splitting", also Aufteilung des Originalbildes in z.B. 9 Felder, die autonom übertragen und im Empfänger erst wieder zusammengesetzt werden. Jedes Feld für sich darf jederzeit ausfallen, für FPV wäre das kein so großer Verlust (davon ausgehend, dass eben nur ein oder zwei Frames verloren gehen und der Codec ein schnelles Catch-Up erlaubt, also eben nicht MPEG mit wenigen i-Frames ist).
- Status
