Low Cost HD-Video Übertragung + Telemetrie
- Themenstarter Lonestar78
- Beginndatum
- Status
Na ist ja schön zu sehen, dass hier nach einem provokanten Bild doch noch ein bisschen was los ist 
Um erst einmal den Haken an der Sache anzusprechen: ohne iOS 8 könnt ihr diese Latenzen aller Voraussicht nach vergessen. Erst mit iOS 8 ist es möglich, den Hardware-Decoder 'direkt' zu nutzen. Vorher wurden natürlich das Abspielen von Videofiles usw. auch beschleunigt, aber das direkte Füttern mit eigenen Daten ging nicht (oder zumindest nicht ohne irgendwelchen weiteren Tricks, die sehr aufwendig werden dürften). Mir ist jedenfalls nichts dergleichen bekannt.
Das erst einmal als Schock am Anfang. Jetzt vielleicht noch ein bisschen mehr Hintergrund: Als aller erstes hatte ich eine ganz einfache GStreamer Pipe mit Softwaredecoder laufen, was an sich auch funktioniert hat. Die Latenz war so um die 140 ms herum. Allerdings fiel mir auf, dass die CPU bei 1080p30 und etwas höheren Bitraten gut ins Schwitzen kam. War die Datenrate zu hoch (auf meinem Device bei 1080p30 war das irgendwas über 600 kBit/s), kam es auch zu Bildfehlern, weil die CPU schlichtweg nicht hinterher kam. Ähnlich sah es auch bei 720p49 aus. Da mir das nicht ganz so gefallen hat, und ich auch Wind davon bekommen hatte, dass ab iOS 8 der HW-Decoder frei zugänglich gemacht worden ist, habe ich mich direkt mal daran gemacht, die Daten in GStreamer abzuzapfen und durch den HW-Decoder zu schieben. Das wollte erst nicht so recht (siehe hier) und ungefähr gleichzeitig hatte einer der Core Developer in seinem Blog verkündet, dass nun auch GStreamer direkt die HW-Decodierung unterstützt. Das kam mir also recht passend und ich habe es dann auch irgendwann soweit laufen gehabt, nachdem noch einige Bugs im Head-Branch behoben werden mussten, damit die Cross-Kompilierung keine Probleme mehr machte. Soweit so gut, also nichts wie ausprobieren: Und siehe da, die CPU-Last war auf die Hälfte gesunken, und es gab keine Bildfehler bei höheren Bitraten mehr. Blöderweise hat das ganze eine erhebliche Latenzsteigerung mit sich gebracht, und es waren meist so um die 300 ms. Also war der Ansatz gut, aber irgendwas noch nicht effizient. Mein nächster Schritt war es deswegen, GStreamer komplett rauszuschmeißen, und selbst das bisschen RTP Depacktization zu machen. Durch die offene und gute Dokumentation dazu (insbesondere natürlich RFC6184) lief auch das irgendwann und ich konnte die NALUs in den HW-Decoder schubsen. Damit liegt die CPU-Last nun nur noch bei 25% und die Latenz habt ihr ja gesehen Nun werde ich mal noch einige Komfortfunktionen zu Ende basteln (also Auflösung, Framerate etc. in der App über Sledge's Webserver einstellen), um dann alles mal ausführlich testen zu können.
Fürs Erste soll es das an Einblicken gewesen sein. Jetzt würde mich mal noch interessieren, ob jemand von den Android-Fanatikern hier genaueres zu der Decodierung auf seiner Platform sagen kann (also HW oder SW) und wie die Single-Core-Auslastung so ist?! Oder läuft GStreamer auf Android sogar multithreaded? Ich hab keine Ahnung...
Und was ich eben mit den Rahmenbedingungen für die Latenzmessungen meinte, war eher weniger die WLAN-Strecke, als viel mehr Auflösung, Framerate etc. Außerdem stelle ich immer wieder fest, dass das Verfahren mit der Stoppuhr auf dem Bildschirm eher semigut geeignet ist; es gibt einfach zu viele Unbekannte (Rendering-Framerate von Javascript im Browser (zumindest wenn man die Stoppuhr im Browser laufen lässt ^^)). So habe ich auch eine Messung, wo ich einmal eine Latenz von 44 ms habe, und eine Bildschirm-im-Bildschirm-Ebene tiefer auf 130 ms komme. Es war also innerhalb von Bruchteilen einer Sekunde und eine Schwankung der realen Latenz um den Faktor 3 halte ich dann doch für sehr unwahrscheinlich. Und das habe ich nicht nur einmal beobachtet, sondern mehrfach. Falls also jemand eine bessere Idee hat, wie man das vernünftig ermitteln könnte, immer her damit. Ich habe auch schon an so eine LED-Wand gedacht, wie sie für Auslöseverzögerungsmessungen von Kameras verwendet werden, aber extra dafür eine bauen ist wohl doch zu aufwendig. Zumal Vergleiche damit auch nicht besser gehen, falls nicht noch jemand so eine baut
Um alle Nichtleser meines Beitrags noch ein bisschen zu schocken, hänge ich mal noch die oben geschilderte Messung an
Edit: Bild nachgereicht.
Um erst einmal den Haken an der Sache anzusprechen: ohne iOS 8 könnt ihr diese Latenzen aller Voraussicht nach vergessen. Erst mit iOS 8 ist es möglich, den Hardware-Decoder 'direkt' zu nutzen. Vorher wurden natürlich das Abspielen von Videofiles usw. auch beschleunigt, aber das direkte Füttern mit eigenen Daten ging nicht (oder zumindest nicht ohne irgendwelchen weiteren Tricks, die sehr aufwendig werden dürften). Mir ist jedenfalls nichts dergleichen bekannt.
Das erst einmal als Schock am Anfang. Jetzt vielleicht noch ein bisschen mehr Hintergrund: Als aller erstes hatte ich eine ganz einfache GStreamer Pipe mit Softwaredecoder laufen, was an sich auch funktioniert hat. Die Latenz war so um die 140 ms herum. Allerdings fiel mir auf, dass die CPU bei 1080p30 und etwas höheren Bitraten gut ins Schwitzen kam. War die Datenrate zu hoch (auf meinem Device bei 1080p30 war das irgendwas über 600 kBit/s), kam es auch zu Bildfehlern, weil die CPU schlichtweg nicht hinterher kam. Ähnlich sah es auch bei 720p49 aus. Da mir das nicht ganz so gefallen hat, und ich auch Wind davon bekommen hatte, dass ab iOS 8 der HW-Decoder frei zugänglich gemacht worden ist, habe ich mich direkt mal daran gemacht, die Daten in GStreamer abzuzapfen und durch den HW-Decoder zu schieben. Das wollte erst nicht so recht (siehe hier) und ungefähr gleichzeitig hatte einer der Core Developer in seinem Blog verkündet, dass nun auch GStreamer direkt die HW-Decodierung unterstützt. Das kam mir also recht passend und ich habe es dann auch irgendwann soweit laufen gehabt, nachdem noch einige Bugs im Head-Branch behoben werden mussten, damit die Cross-Kompilierung keine Probleme mehr machte. Soweit so gut, also nichts wie ausprobieren: Und siehe da, die CPU-Last war auf die Hälfte gesunken, und es gab keine Bildfehler bei höheren Bitraten mehr. Blöderweise hat das ganze eine erhebliche Latenzsteigerung mit sich gebracht, und es waren meist so um die 300 ms. Also war der Ansatz gut, aber irgendwas noch nicht effizient. Mein nächster Schritt war es deswegen, GStreamer komplett rauszuschmeißen, und selbst das bisschen RTP Depacktization zu machen. Durch die offene und gute Dokumentation dazu (insbesondere natürlich RFC6184) lief auch das irgendwann und ich konnte die NALUs in den HW-Decoder schubsen. Damit liegt die CPU-Last nun nur noch bei 25% und die Latenz habt ihr ja gesehen
Nun werde ich mal noch einige Komfortfunktionen zu Ende basteln (also Auflösung, Framerate etc. in der App über Sledge's Webserver einstellen), um dann alles mal ausführlich testen zu können. Fürs Erste soll es das an Einblicken gewesen sein. Jetzt würde mich mal noch interessieren, ob jemand von den Android-Fanatikern hier genaueres zu der Decodierung auf seiner Platform sagen kann (also HW oder SW) und wie die Single-Core-Auslastung so ist?! Oder läuft GStreamer auf Android sogar multithreaded? Ich hab keine Ahnung...
Und was ich eben mit den Rahmenbedingungen für die Latenzmessungen meinte, war eher weniger die WLAN-Strecke, als viel mehr Auflösung, Framerate etc. Außerdem stelle ich immer wieder fest, dass das Verfahren mit der Stoppuhr auf dem Bildschirm eher semigut geeignet ist; es gibt einfach zu viele Unbekannte (Rendering-Framerate von Javascript im Browser (zumindest wenn man die Stoppuhr im Browser laufen lässt ^^)). So habe ich auch eine Messung, wo ich einmal eine Latenz von 44 ms habe, und eine Bildschirm-im-Bildschirm-Ebene tiefer auf 130 ms komme. Es war also innerhalb von Bruchteilen einer Sekunde und eine Schwankung der realen Latenz um den Faktor 3 halte ich dann doch für sehr unwahrscheinlich. Und das habe ich nicht nur einmal beobachtet, sondern mehrfach. Falls also jemand eine bessere Idee hat, wie man das vernünftig ermitteln könnte, immer her damit. Ich habe auch schon an so eine LED-Wand gedacht, wie sie für Auslöseverzögerungsmessungen von Kameras verwendet werden, aber extra dafür eine bauen ist wohl doch zu aufwendig. Zumal Vergleiche damit auch nicht besser gehen, falls nicht noch jemand so eine baut
Um alle Nichtleser meines Beitrags noch ein bisschen zu schocken, hänge ich mal noch die oben geschilderte Messung an
Edit: Bild nachgereicht.
Wie meine Vermutung schon war liegt es größtenteils an der Software.
Ich persönlich bevorzuge Android der Offenheit halber und denke ein ähnlicher Ansatz wie du es gemacht hast wird sich für andre auch finden lassen.
Als beste Lösung für mich sehe ich die Laptop Lösung.
Ich bin gespannt wie sich das hier weiter entwickelt.
Die Sticheleien hier bezüglich Apfel und Android tuht der gesamten sache in diesem fall mal gut.
Danke senseless, jaja, die Optionen habe ich gefunden. Nur trau ich mich nicht mehr rein, da ich die Befehle für die Configänderung nicht mehr genau weis. Und ich möchte es nicht verbocken.... Und darum kann ich die Pipe grad auch nicht teilen...
Danke und gern geschehen. Habe gerade mal kurz gegoogelt und ich denke es ist auch unter Android gut machbar. Aber da ich davon keine Ahnung habe, und auch nicht vorhab, mir welche anzueignen, will ich mich da jetzt auch nicht zu weit aus dem Fenster lehnen.
Ansonsten weiß ich nicht, ob die Stichelein irgendwas bringen, aber leider Gottes gehört diese ewige Diskussion ja offenbar zu allem, was auch nur ansatzweise mit Smartphones oder Tabletes zu tuen hat.
Ja, ließe sie sich, wenn du gejailbreakt hast. Ansonsten wird dein iPad nichts ausführen, was nicht Code Signed ist. Und wann und ob es einen iOS 8 JB gibt, weiß ich nicht.
Ach ja, ich verwende ein iPad mini Retina. Also mit A7.
Zuletzt bearbeitet:
Mhm schade... Dass du die App bei so einer geringen Nachfrage nicht in den Store bringen willst, verstehe ich natürlich. Aber gibt es nicht nicht andere Möglichkeiten die App zu verteilen: https://developer.apple.com/library...uide/TestingYouriOSApp/TestingYouriOSApp.html
Wäre mal Interessant zu wissen ob die Latenz mit einem A6 ähnlich gut ist... Deine Latenz hat mich jetzt echt heiß auf die App gemacht
Wäre mal Interessant zu wissen ob die Latenz mit einem A6 ähnlich gut ist... Deine Latenz hat mich jetzt echt heiß auf die App gemacht
Zum Thema Ground Recording habe ich mir auch schon die Finger wund gegoogelt. Es ist mit gstreamer Bordmitteln scheinbar nicht so einfach den empfangenen Stream zu speichern. Auf dem airpi ist es aber kein Thema. Vielleicht hat dazu noch jemand eine Idee.
Bzgl. Deiner Linux Kenntnisse kann Dir geholfen werden. Ich habe ein image fertig gemacht auf dem ein Webserver läuft um alles einzustellen was man zum Streamen braucht. Ganz bequem per Browser oder über eines der apps von lonestar und senseles. Im Moment stimme ich mich mit den beiden ab damit alles nahtlos ineinander greift. Für den Appzugriff muss ich noch ein paar Anpassungen machen und die beiden müssen ihre Apps noch etwas anpassen damit alles läuft. Sobald es fertig ist Stelle ich das Image zur Verfügung. Wer nicht warten möchte findet in diesem thread aber sämtliche Informationen um sich das Image selbst zu basteln.
Bzgl. Deiner Linux Kenntnisse kann Dir geholfen werden. Ich habe ein image fertig gemacht auf dem ein Webserver läuft um alles einzustellen was man zum Streamen braucht. Ganz bequem per Browser oder über eines der apps von lonestar und senseles. Im Moment stimme ich mich mit den beiden ab damit alles nahtlos ineinander greift. Für den Appzugriff muss ich noch ein paar Anpassungen machen und die beiden müssen ihre Apps noch etwas anpassen damit alles läuft. Sobald es fertig ist Stelle ich das Image zur Verfügung. Wer nicht warten möchte findet in diesem thread aber sämtliche Informationen um sich das Image selbst zu basteln.
hi,
ich wollte mich hier auch mal zu Wort melden
Sehr interessantes Thema, welches ich schon länger verfolge.
Zum speichern des Streams hab ich bereits folgende Pipeline ausprobiert:
d:\gstreamer\1.0\x86_64\bin\gst-launch-1.0.exe -e rtspsrc location=rtsp://192.168.5.29:8554/test latency=0 ! application/x-rtp, payload=96 ! rtpjitterbuffer ! rtph264depay ! tee name=t ! queue ! h264parse ! matroskamux ! filesink location=D:\test.mkv t. ! queue ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false
Das splittet den Stream (mit dem tee-Element in der Pipeline) und erzeugt neben der Anzeige auf dem Bildschirm eine mit VLC-Player abspielbare mkv-Datei. Allerdings stimmt da etwas überhaupt nicht, da ich darin weder vor- noch zurückspulen kann. Kenn mich da aber überhaupt nicht aus und weiß daher nicht woran das liegen könnte (evtl. Timestamp-Problem?). Hatte mich aber auch noch nicht weiter damit beschäftigt. Wie sich das auf die Latenz auswirkt kann ich ebenfalls nicht sagen, da ich das noch nicht getestet habe.
Zum Thema Multicast:
Einen wirklichen Multicast-Stream hab ich leider auch mit der test-multicast anwendung des gst-rtsp-servers noch nicht zum laufen bekommen.
Ergänzt man aber in der test-launch.c folgende Zeile und kompiliert erneut, kann man sich mit mehreren Clients am Server anmelden.
gst_rtsp_media_factory_set_shared (factory, true);
Damit verwendet der Server der test-launch-Anwendung dann dieselbe Source für mehrere Clients, die sich anmelden. Das erzeugt natürlich auch vielfachen Traffic über die Funkverbindung und ist daher keine gute Lösung.
Nochmal vielen Danke an alle hier.
ich wollte mich hier auch mal zu Wort melden
Sehr interessantes Thema, welches ich schon länger verfolge.
Zum speichern des Streams hab ich bereits folgende Pipeline ausprobiert:
d:\gstreamer\1.0\x86_64\bin\gst-launch-1.0.exe -e rtspsrc location=rtsp://192.168.5.29:8554/test latency=0 ! application/x-rtp, payload=96 ! rtpjitterbuffer ! rtph264depay ! tee name=t ! queue ! h264parse ! matroskamux ! filesink location=D:\test.mkv t. ! queue ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=false
Das splittet den Stream (mit dem tee-Element in der Pipeline) und erzeugt neben der Anzeige auf dem Bildschirm eine mit VLC-Player abspielbare mkv-Datei. Allerdings stimmt da etwas überhaupt nicht, da ich darin weder vor- noch zurückspulen kann. Kenn mich da aber überhaupt nicht aus und weiß daher nicht woran das liegen könnte (evtl. Timestamp-Problem?). Hatte mich aber auch noch nicht weiter damit beschäftigt. Wie sich das auf die Latenz auswirkt kann ich ebenfalls nicht sagen, da ich das noch nicht getestet habe.
Zum Thema Multicast:
Einen wirklichen Multicast-Stream hab ich leider auch mit der test-multicast anwendung des gst-rtsp-servers noch nicht zum laufen bekommen.
Ergänzt man aber in der test-launch.c folgende Zeile und kompiliert erneut, kann man sich mit mehreren Clients am Server anmelden.
gst_rtsp_media_factory_set_shared (factory, true);
Damit verwendet der Server der test-launch-Anwendung dann dieselbe Source für mehrere Clients, die sich anmelden. Das erzeugt natürlich auch vielfachen Traffic über die Funkverbindung und ist daher keine gute Lösung.
Nochmal vielen Danke an alle hier.
Moin,
interessanter Beitrag hier. Jetzt würde ich das ganze gerne nachbauen.
Was ist derzeit das optimale Equipment für das 5GHz Band? Möchte gerne weiter meine Steuersignale über 2,4GHz über tragen.
Wenn ich das richtig gelesen haben benötige ich folgendes:
- Raspberry Pi (würde das neuste B+ nehmen)
- Ubiquiti Rocket M5 für den Boden
- Ubiquiti Picco für den Copter
- Passende Antennen (würde die ImmersionRC nehmen)
- Laptop (habe einen flotten mit Ubuntu 14.04)
Passt das alles soweit?
Und noch eine Frage: Kann ich am Raspberry den HD Ausgang meiner Kamera nutzen oder geht das ganze nur mit der Raspberry Platinen Kamera?
Gruß
Fabi
interessanter Beitrag hier. Jetzt würde ich das ganze gerne nachbauen
.Was ist derzeit das optimale Equipment für das 5GHz Band? Möchte gerne weiter meine Steuersignale über 2,4GHz über tragen.
Wenn ich das richtig gelesen haben benötige ich folgendes:
- Raspberry Pi (würde das neuste B+ nehmen)
- Ubiquiti Rocket M5 für den Boden
- Ubiquiti Picco für den Copter
- Passende Antennen (würde die ImmersionRC nehmen)
- Laptop (habe einen flotten mit Ubuntu 14.04)
Passt das alles soweit?
Und noch eine Frage: Kann ich am Raspberry den HD Ausgang meiner Kamera nutzen oder geht das ganze nur mit der Raspberry Platinen Kamera?
Gruß
Fabi
das würde auch mich brennend interessieren. Ich würde auch gerne das System lediglich als HD Downlink nutzen,w enns geht mit einem OSD drüber (das am Tablet angezeigt wird) Dann wäre das die perfekte PiBridge.... oder CubieBridge falls jemand sowas mit dem hier hinbekäme
http://de.wikipedia.org/wiki/Cubieboard
ich würde so ein PRojekt auch Finanziell voll unterstützen wollen (mit 3 Summe Zahlen)
http://de.wikipedia.org/wiki/Cubieboard
ich würde so ein PRojekt auch Finanziell voll unterstützen wollen (mit 3 Summe Zahlen)
Also nochmal langsam:
Der Pi erzeugt entweder aus dem unkomprimierten Stream einer per CSI angeschlossenen Kamera per Hardware einen H264 Stream oder man nutzt eine USB-Cam, die bereits einen encodierten Stream liefert.
Der Pi macht also nix Anderes als den Stream zu transportieren und ggf. zusätzlich für das Hardware-Encoding zu sorgen.
Was Ihr sucht ist einen HDMI-Eingang. Den hat der Pi NICHT. Es gab mal ein Projekt dazu auf Kickstarter, dass ist aber erstmal eingeschlafen wegen technischer Unzulänglichkeiten.
Was es Braucht ist ein HDMI zu CSI Converter, damit der Pi dann das Encodieren machen kann.
Es gibt solche Bausteine, aber keine Lösung für den Pi, die Einsetzbar wäre.
Ich hoffe das macht das Thema klarer als die kurze Aussage in meinen vorletzten (;-)) Post.
Ansonsten ist das nur eine Wiederholung von schon Diskutiertem.
Der Pi erzeugt entweder aus dem unkomprimierten Stream einer per CSI angeschlossenen Kamera per Hardware einen H264 Stream oder man nutzt eine USB-Cam, die bereits einen encodierten Stream liefert.
Der Pi macht also nix Anderes als den Stream zu transportieren und ggf. zusätzlich für das Hardware-Encoding zu sorgen.
Was Ihr sucht ist einen HDMI-Eingang. Den hat der Pi NICHT. Es gab mal ein Projekt dazu auf Kickstarter, dass ist aber erstmal eingeschlafen wegen technischer Unzulänglichkeiten.
Was es Braucht ist ein HDMI zu CSI Converter, damit der Pi dann das Encodieren machen kann.
Es gibt solche Bausteine, aber keine Lösung für den Pi, die Einsetzbar wäre.
Ich hoffe das macht das Thema klarer als die kurze Aussage in meinen vorletzten (;-)) Post.
Ansonsten ist das nur eine Wiederholung von schon Diskutiertem.
sehr schade.... weil das würde einiges vereinfachen. Über HDMI könnte man halt beliebige kameras anschließen...
wie wäre so eine Lösung?
https://new.livestream.com/broadcaster
kombiniert mit dem vorher genannten WLAN Repeater könnte man damit wohl einen stream aufs Handy oder Tablet schicken...
Frage: müsste der Weg eigentlich nicht der sein, das Signal in ein DNLA Stream umzuwandeln. Das könnte man innerhalb des Netzwerkes natürlich mit gängigen Android, iPad und windows apps abrufen... ohne Probleme... hier endet aber auch schon mein Wisssen darüber... leider...
wie wäre so eine Lösung?
https://new.livestream.com/broadcaster
kombiniert mit dem vorher genannten WLAN Repeater könnte man damit wohl einen stream aufs Handy oder Tablet schicken...
Frage: müsste der Weg eigentlich nicht der sein, das Signal in ein DNLA Stream umzuwandeln. Das könnte man innerhalb des Netzwerkes natürlich mit gängigen Android, iPad und windows apps abrufen... ohne Probleme... hier endet aber auch schon mein Wisssen darüber... leider...
Zuletzt bearbeitet:
Naja nicht wirklich:
Grundsätzlich könnte man direkt Kameras mit integriertem WIFI verwenden, für die es eine App mit Live Preview gibt(zb Gopro). Mit dem Raspberry Pi kann man sich dann damit verbinden und indem man eine Routing Tabelle anlegt könnte man den Zugriff auf die Kamera über die Ubis realisieren. Die Gopro hat zwar kein HD Live Preview aber immerhin bräuchte man dann keine analoge Übertragung mehr... Allerdings ist die Live Preview bei der Gopro während einer Aufnahme sehr abgehakt, deswegen verwende ich dafür noch analoge Übertragung.
Grundsätzlich könnte man direkt Kameras mit integriertem WIFI verwenden, für die es eine App mit Live Preview gibt(zb Gopro). Mit dem Raspberry Pi kann man sich dann damit verbinden und indem man eine Routing Tabelle anlegt könnte man den Zugriff auf die Kamera über die Ubis realisieren. Die Gopro hat zwar kein HD Live Preview aber immerhin bräuchte man dann keine analoge Übertragung mehr... Allerdings ist die Live Preview bei der Gopro während einer Aufnahme sehr abgehakt, deswegen verwende ich dafür noch analoge Übertragung.
Zuletzt bearbeitet:
mhhh. ich nochmals... sorry wenn ich störe und Euch hier nerve....
ich habe hier im Studio so ein portables Capture Gerät von AverMedia
http://www.avermedia.eu/avertv/DE/Product/ProductDetail.aspx?Id=494
das wandelt und Caputred ein HDMI Signal direkt in ein H264 Stream um und kostet gerade mal 100 EUR... Strom erhält es via USB und über die mitgelieferte Software kann man den HDMI Stream auch direkt mittels USB 2.0 am PC ansehen...
müsste es also nicht möglich sein, diesen USB H264 Stream abzufangen und an RasPi weiterzugeben, um das dann zu funken?
Das AverMedia Gerät wär sozusagen das zwischenteil zwischen standard Kamera und dem RasPi...
falls es gar nicht geht, bleibe ich still.... und entschuldige mich falls ich hier den Brainstorm gestört habe...
ich habe hier im Studio so ein portables Capture Gerät von AverMedia
http://www.avermedia.eu/avertv/DE/Product/ProductDetail.aspx?Id=494
das wandelt und Caputred ein HDMI Signal direkt in ein H264 Stream um und kostet gerade mal 100 EUR... Strom erhält es via USB und über die mitgelieferte Software kann man den HDMI Stream auch direkt mittels USB 2.0 am PC ansehen...
müsste es also nicht möglich sein, diesen USB H264 Stream abzufangen und an RasPi weiterzugeben, um das dann zu funken?
Das AverMedia Gerät wär sozusagen das zwischenteil zwischen standard Kamera und dem RasPi...
falls es gar nicht geht, bleibe ich still.... und entschuldige mich falls ich hier den Brainstorm gestört habe...
Bei anderen Kameras geht das aber sehr flüssig... Canon, Nikon und Panasonic... wir hatten das mal auch im studio verwendet um bei den Canons mittels eines TP-Link Routers und geflashtem OpnWRT mittels DSLRController oder DSLRDashboard die Canons über Wifi und einem Android Phone gesteuert und Live Preview gehabt mit bis zu 25 fps...
für Panasonic gibt es auch live Apps... allerdings sind die nicth sehr ausgereift... außer man kann der Panasonic Lumix Android App unter RasPi eine hohe display Auflösung vorgaukeln beim Verbinden mit der Kamera...
aber ist ein WLAN direkt am Copter nicht ein Problem für die Funke?
oder sowas als Gerät?
http://www.dexteralabs.com/inogeni/
kann angeblich sogar zu USB an einem Android Gerät streamen
für Panasonic gibt es auch live Apps... allerdings sind die nicth sehr ausgereift... außer man kann der Panasonic Lumix Android App unter RasPi eine hohe display Auflösung vorgaukeln beim Verbinden mit der Kamera...
aber ist ein WLAN direkt am Copter nicht ein Problem für die Funke?
oder sowas als Gerät?
http://www.dexteralabs.com/inogeni/
kann angeblich sogar zu USB an einem Android Gerät streamen
Zuletzt bearbeitet:
Naja die Ubis laufen auch mit 2,4ghz wifi... Deswegen wird ja auch an einer Steuerung über Wlan gearbeitet.
Die Live Preview einer Kamera über die Ubis zu schicken wäre wohl die einfachste Möglichkeit. Da kann man die Kamera dann auch gleich noch über das Tablet/Smartphone steuern.
Ich denke aber, dass diese Lösung mit dem Raspberry nur für FPV in Verbindung mit der Pi Kamera gedacht ist...
Für dich wäre die Lightbridge wohl am besten geeignet.
Die Live Preview einer Kamera über die Ubis zu schicken wäre wohl die einfachste Möglichkeit. Da kann man die Kamera dann auch gleich noch über das Tablet/Smartphone steuern.
Ich denke aber, dass diese Lösung mit dem Raspberry nur für FPV in Verbindung mit der Pi Kamera gedacht ist...
Für dich wäre die Lightbridge wohl am besten geeignet.
ja mir ist klar dass es LowCost sein soll. aber um ehrlich zu sein, wenn wir mit 100, 200 oder 300 eine gute Lösung bekommen, ist doch das geld keine rolle mehr...
stellt euch vor das signal käme aufs handy... dann druckt man sich einfach eine FPV Brille aus in der das Handy reinkommt, und fertig...
Die Lightbridge wäre genial, funkt aber in 2,4ghz und wird daher nicht neben der funke empfholen... also müsste man komplett im DJI system bleiben (A2, ighbridge, zenmuse Gimbal) und genau das will ich nicht...
wenn aber jemand ein bus Systm für die Lightbridge (mit Autoquad) hinbekäme dass das Funksignal einen Passtrough durch die LB zum FC bekommt... dann wäre ich sofort dabei
Frage: was sind Ubis?
stellt euch vor das signal käme aufs handy... dann druckt man sich einfach eine FPV Brille aus in der das Handy reinkommt, und fertig...
Die Lightbridge wäre genial, funkt aber in 2,4ghz und wird daher nicht neben der funke empfholen... also müsste man komplett im DJI system bleiben (A2, ighbridge, zenmuse Gimbal) und genau das will ich nicht...
wenn aber jemand ein bus Systm für die Lightbridge (mit Autoquad) hinbekäme dass das Funksignal einen Passtrough durch die LB zum FC bekommt... dann wäre ich sofort dabei
Frage: was sind Ubis?
- Status
