Low Cost HD-Video Übertragung + Telemetrie
- Themenstarter Lonestar78
- Beginndatum
- Status
Hute...
Was geht hier denn ab?
Auf diese Weise vertreibt ihr doch alle die versuchen etwas zum Thema beizutragen!
So traut sich niemand auch mur Vermutungen zu äußern die aber ziel führend sein können.
Zieht die Hosen aus und packt die Tatsachen auf den Tisch.
Dann wissen wir wer den längsten hat. -Oder worum geht es hier?
Was geht hier denn ab?
Auf diese Weise vertreibt ihr doch alle die versuchen etwas zum Thema beizutragen!
So traut sich niemand auch mur Vermutungen zu äußern die aber ziel führend sein können.
Zieht die Hosen aus und packt die Tatsachen auf den Tisch.
Dann wissen wir wer den längsten hat. -Oder worum geht es hier?
Ich verstehe auch nicht wieso man sich so anfeinden muss. Tatsache ist nunmal, dass es schier unendliche Hardware und Software Kombinationen gibt und daher auch extrem unterschiedliche Ergebnisse bezüglich der Latenz herauskommen.
Ich arbeite mit Echtzeitbetriebssystemen auf Linux-Basis und normalen x86 Rechnern. Es ist immer wieder ein Abenteuer wenn ein Hardwaretausch ansteht oder der Linux-Kernel aktualisiert wird.
Leider bin ich im Moment mit meiner Master Thesis ausgelastet. Ich denke, für diese ganze Streaminggeschichte wäre vll ein Echtzeitbetriebssystem gar nicht mal so schlecht, da es was das zeitliche Verhalten angeht deterministischer ist, als ein normales Betriebssystem. Denn auf den normalen Betriebssystem kann es immer mal zu Verzögerungen kommen, wenn z.B. Systemprozesse Rechenzeit benötigen. Läuft das betreffende Streamingprogramm innerhalb einer Echtzeitumgebung, wäre die Ausführung gegenüber anderen Prozessen priorisiert und große Verzögerungen wären damit ausgeschlossen.
Ich arbeite mit Echtzeitbetriebssystemen auf Linux-Basis und normalen x86 Rechnern. Es ist immer wieder ein Abenteuer wenn ein Hardwaretausch ansteht oder der Linux-Kernel aktualisiert wird.
Leider bin ich im Moment mit meiner Master Thesis ausgelastet. Ich denke, für diese ganze Streaminggeschichte wäre vll ein Echtzeitbetriebssystem gar nicht mal so schlecht, da es was das zeitliche Verhalten angeht deterministischer ist, als ein normales Betriebssystem. Denn auf den normalen Betriebssystem kann es immer mal zu Verzögerungen kommen, wenn z.B. Systemprozesse Rechenzeit benötigen. Läuft das betreffende Streamingprogramm innerhalb einer Echtzeitumgebung, wäre die Ausführung gegenüber anderen Prozessen priorisiert und große Verzögerungen wären damit ausgeschlossen.
@nachbrenner. Ich habe mit dem Handy so um die 200ms Latenz. Klappt für einen copter soweit gut. Ich habe bei den Flügen keine Latenz-Schwankungen bemerken können über WLAN.
Zum Thema app und eigenartiges abspielverhalten: das kann durchaus an der Pipeline und der Hardware liegen. Ich hab keine Ahnung, wie gut gestreamer mit verschiedenen Android Modellen klar kommt.
Zum Thema app und eigenartiges abspielverhalten: das kann durchaus an der Pipeline und der Hardware liegen. Ich hab keine Ahnung, wie gut gestreamer mit verschiedenen Android Modellen klar kommt.
Ja, das wäre prima. Die Restriktion auf Geräte mit Root ist etwas hinderlich. Mir schwebt ein kleines Web Frontend auf dem airpi vor auf dem man einige Einstellungen zum Stream machen kann bevor man ihn startet. Man könnte dort für Gäste auch direkt die App verlinken damit sie sich diese runterladen können wenn Sie zufällig auf dem Feld stehen und mitsehen wollen.
Zuletzt bearbeitet:
Hallo,
mir ist schon bewusst, dass ein zugemüllter Rechner mit an sich sehr guten Komponenten langsamer sein kann als ein frisch aufgesetzter mit langsameren Komponenten. Mir geht es nur darum, zu sehen, wo man sinnvoll und unnötig investieren kann. Wenn das Decodieren auf der GPU abläuft, kann man hier ansetzen. Fragt sich nur, in wieweit der Aufwand einer noch schnelleren Grafikkarte etwas bringt.
Gibt es schon Meinung zu den unterschiedlichen Betriebssystemen? Ich könnte mir vorstellen, dass es auf Linux etwas schneller läuft, da hier das Problem des Zumüllens geringer sein dürfte. Ich weiß nur nicht, wie es unter Linux mit den Grafiktreibern aussieht. Kann man überhaupt die volle Leistung rausholen oder gibt es nur Standardtreiber, die eine Grundfunktion bieten?
Gruß.
Onkel_JF
mir ist schon bewusst, dass ein zugemüllter Rechner mit an sich sehr guten Komponenten langsamer sein kann als ein frisch aufgesetzter mit langsameren Komponenten. Mir geht es nur darum, zu sehen, wo man sinnvoll und unnötig investieren kann. Wenn das Decodieren auf der GPU abläuft, kann man hier ansetzen. Fragt sich nur, in wieweit der Aufwand einer noch schnelleren Grafikkarte etwas bringt.
Gibt es schon Meinung zu den unterschiedlichen Betriebssystemen? Ich könnte mir vorstellen, dass es auf Linux etwas schneller läuft, da hier das Problem des Zumüllens geringer sein dürfte. Ich weiß nur nicht, wie es unter Linux mit den Grafiktreibern aussieht. Kann man überhaupt die volle Leistung rausholen oder gibt es nur Standardtreiber, die eine Grundfunktion bieten?
Gruß.
Onkel_JF
Gut, um es kurz zu machen, ist es unnötig, dir überhaupt eine Graka ins Notebook zu stopfen, wenn dein i7 Intel Quick Sync unterstützt. Das ist rasend schnell und liefert wohl auch noch bessere Qualität als die Grafikkarte (laut Anandtech). Sehr interessant dazu ist die englische Wikipedia sowie der erste Link dort. Im Prinzip ist das aber auch garnicht so wichtig für uns, wie viele fps es denn nun schafft, Echtzeit reicht ja völlig aus. Deshalb hat es vermutlich auch keinen Zweck, eine schnellere Grafikkarte einzubauen, wenn sie vom gleichen Typ ist, weil sich weder die Latenz noch der Durchsatz (siehe erster Link im Wiki-Artikel) verändert. Deswegen kann es auch sein, dass dir eine schrottige ATI bessere Latenz liefert, als eine GTX880M. Und das hängt eben stark von der Software ab, und darüber wird man pauschal nicht urteilen können. Aber das sagte ich ja bereits.
Ich kann euch dazu nur soviel sagen:
Mein PC zuhause hat ein i3, 16GB RAM und keine Dedizierte Graka und ich schaffe die 150ms auch ohne Probleme.
Mein Ultrabook hat ein i7, 4GB Ram -> keine Dedizierte Graka -> 150ms gehen ebenfalls
Interessant wäre jetzt noch der vergleich zu einem Intel Atom Tablet, liegen hier auch einige rum, mal schauen wenn ich Zeit finde werde ich testen.
Sicherlich kann man noch die eine oder andere ms sparen mit der "passenden" Hardware, aber ob ich nun 150 oder 130ms habe ist mir schon fast egal, wenn ich für sowas extra einen entsprechenden Rechner bauen muss kann ich auch gleich die Lightbridge nehmen, die kostet dann insgesammt wohl weniger
Mein PC zuhause hat ein i3, 16GB RAM und keine Dedizierte Graka und ich schaffe die 150ms auch ohne Probleme.
Mein Ultrabook hat ein i7, 4GB Ram -> keine Dedizierte Graka -> 150ms gehen ebenfalls
Interessant wäre jetzt noch der vergleich zu einem Intel Atom Tablet, liegen hier auch einige rum, mal schauen wenn ich Zeit finde werde ich testen.
Sicherlich kann man noch die eine oder andere ms sparen mit der "passenden" Hardware, aber ob ich nun 150 oder 130ms habe ist mir schon fast egal, wenn ich für sowas extra einen entsprechenden Rechner bauen muss kann ich auch gleich die Lightbridge nehmen, die kostet dann insgesammt wohl weniger
Ok ich habe mein Himbeerchen jetzt 2 Tage lang gequält und sämtliche gstreamer 1.4.1 Quellen und Plugins kompiliert. Den gst-rtsp-1.4.1 habe ich ebenfalls erfolgreich installiert. Wenn ich mich direkt auf den gstreamer aufschalte funktioniert der Stream auch einwandfrei aber über den rtsp Server bekomme ich keine Verbindung hin.
Die Pipes zum direkten Aufschalten
Linux:
Windows:
läuft perfekt!
Den rtsp Server starte ich mit
Als Meldung kommt: stream ready at rtsp://127.0.0.1:8554/test
Es ist mir aber leider nicht möglich per vlc auf rtsp://192.168.178.119:8554/test zu verbinden.
Hat hier jemand einen Tip?
Ursprünglich hatte ich vor das Skript zum installieren aller Quellen zu veröffentlichen. Da der Compiler aber etliche Stunden braucht versuche ich jetzt mal Debian Pakete für den neuesten gstreamer zu bauen. Dann kann man die einfach und schnell über dpkg installieren.
Die Pipes zum direkten Aufschalten
Linux:
Code:
raspivid -n -w 1280 -h 720 -b 6500000 -fps 49 -vf -hf -t 0 -pf high -o - | gst-launch-1.0 -v fdsrc ! h264parse ! rtph264pay ! udpsink host=sledge-pc port=9000
Code:
gst-launch-1.0 -e -v udpsrc port=9000 ! application/x-rtp, payload=96 ! rtpjitterbuffer ! rtph264depay ! avdec_h264 ! fpsdisplaysink sync=false text-overlay=falseDen rtsp Server starte ich mit
Code:
./test-launch "(rpicamsrc bitrate=8500000 hflip=true vflip=true preview=false ! video/x-h264,width=1280,height=720,framerate=45/1,profile=high ! h264parse ! rtph264pay name=pay0 pt=96 )"Es ist mir aber leider nicht möglich per vlc auf rtsp://192.168.178.119:8554/test zu verbinden.
Hat hier jemand einen Tip?
Ursprünglich hatte ich vor das Skript zum installieren aller Quellen zu veröffentlichen. Da der Compiler aber etliche Stunden braucht versuche ich jetzt mal Debian Pakete für den neuesten gstreamer zu bauen. Dann kann man die einfach und schnell über dpkg installieren.
@Sledge das problem mit dem rtsp habe ich auch :/
Keine ahnung was Lonestar gemacht hat damit es bei ihm läuft.
das problem liegt irgendwie bei "rpicamsrc"
@Lonestar hast du den "rpicamsrc" manuell nach installiert ? ich musste es ! wenigstens ist bei mir dadurch die Cam Led angegangen als ich auf den RTSP server zugreifen wollte. mehr nicht ...
Ach ja habe mir heute morgen die mühe gemacht und das ganze mal mit ArchLinux versucht.
Läuft zwar stabiler und ist auch schön clean nur läuft gstreamer(1.4.0) nicht so schön wie bei Raspbian.
Dort lief der RTSP server ebenfalls nicht. auch als ich den "rpicamsrc" nachinstalliert habe.
Keine ahnung was Lonestar gemacht hat damit es bei ihm läuft.
das problem liegt irgendwie bei "rpicamsrc"
@Lonestar hast du den "rpicamsrc" manuell nach installiert ? ich musste es ! wenigstens ist bei mir dadurch die Cam Led angegangen als ich auf den RTSP server zugreifen wollte. mehr nicht ...
Ach ja habe mir heute morgen die mühe gemacht und das ganze mal mit ArchLinux versucht.
Läuft zwar stabiler und ist auch schön clean nur läuft gstreamer(1.4.0) nicht so schön wie bei Raspbian.
Dort lief der RTSP server ebenfalls nicht. auch als ich den "rpicamsrc" nachinstalliert habe.
Mir persönlich gefällt ArchLinux sehr gut. Nur beim "UDP stream" bricht die fps immer einer sobald sich etwas mehr tut im Bild. An meinem Rechner liegt es garantiert nicht. Mit Raspbian war alles stabil. Die Latenz liegt jedoch auch bei stabilen 110ms. Würde noch versuchen über TCP zu streamen. Oder den Rtsp zum laufen zu bekommen.
Hmmm rpicamsrc sollte seit der 1.2.4er Version von gstreamer eigentlich mit dabei sein.... Ich hab aber soviel rum getestet und compiliert, ich hab da derzeit keine Antwort für euch. Ansonsten kann man eine normale Pipeline an den rtsp Server streamen per TCP und dann per tcpsrc in der launch Applikation des rtsp servers gehen.
- Status
