Low Cost HD-Video Übertragung + Telemetrie

Bezüglich VR: Mal schauen, lässt sich sicherlich ne Menge cooles Zeug mit anstellen. Aber der hauptsächliche Hintergedanke war eigentlich erst einmal 3D HD-FPV

Anfänglich war ich ja noch ganz optimistisch, die App in den Store zu bringen, aber offenbar will sie wirklich kaum einer verwenden, sodass ich mir den Aufwand wohl doch schenken werden. Das soll jetzt aber nicht heißen, dass ich die App an den Nagel hänge, für zumindest mich entwickle ich auf jeden Fall noch ein bisschen weiter.

Schön dass du dich mal wieder zu Wort meldest. Allerdings hätte dein Inhalt ruhig ein anderer sein dürfen, um mein Bild von dir nicht zu festigen. Aber hate ruhig weiter, mich soll es nicht stören... Ich weiß warum ich was verwende, und da wirst du mit deinen intelligent-argumentativen Beiträgen wohl wenig dran ändern können.
Sicherlich hast du aber ja in deiner langen Abwesenheit dein HUD zu einem repräsentablen Zustand weiterentwickelt, und möchtest uns das bald vorstellen, oder was ist daraus geworden?

Naja, wir sollten uns noch einmal über die Rahmenbedingungen von Latenztests unterhalten. Ansonsten schaut in den Anhang, was so geht

"Apple kannst knicken" war ne anspielung auf das neue iphone 6. Aber das ist dir wohl entgangen xD.

Schön wie ich sehe steht es um die Latenz nicht besser als auf anderen Plattformen.

Außerdem steht es jedem frei ob er seine software frei gibt oder nicht. Ich will mich hier nicht beweisen. Ich weis was ich kann und was nicht. Ein urteil von jemandem wie dir ist das letzte was mich interessiert

Wow, das ist echt beeindruckend! Das kann doch nicht sein, dass ich der einzige bin, der ein iPad/iPhone hat...
Könntest du dir denn vorstellen die App hier zur Verfügung zu stellen? Es gibt doch auch Möglichkeiten Apps ohne iTunes und ohne Jailbreak zu installieren?!
Unter Android habe ich mindestens die doppelte Latenz!
Edit:
Liegt die Latenz hier nicht bei 90ms? Wo werden denn noch 90ms erreicht??

Hey Senseless, 90ms....NICE
Genau, Vorschlag zu Rahmenbedingungen für Latenztests für die Zukunft.
Immer das gesamte System, also inklusive WLAN.

Irgendeine Idee, wie man sinnvoll 200m Abstand simulieren kann?

Im Autokino einen Timer auf die Leinwand werfen?!

Hmm ne im Ernst, das habe ich mich auch schon gefragt, gar nicht so leicht. Ich denke da helfen nur Praxistests. Wenn man selbst fliegt spürt man ja ob das Bild an die Stickeingaben gekoppelt sind.

200m Simulieren? an beide Ubis je 100m Lan kabel und auseinander damit xD *spass*
Denke das brauchst du nicht gross zu simulieren, da kommen wenn dann eh nur ein paar ms hinzu. Dann besser fix auf 1m abstand testen. Aber 90ms sind schon beeindruckend.. Wenn ich sehe, dass ich mit meinem S5 gar nichts hinkriege (geht von Sekunde zu Sekunde weiter hoch...)
Der Grund wieso es beim einten phone so gut geht und bei einem anderen wieder nicht ist mir auch irgend wie ein rätsel

Aargau, hast Du mal versucht die Sender Pipeline auf 30fps zu stellen?
Steigt die Latenz dann immer noch an?

Evtl. lässt Samsung ein paar Dienste mit hoher Priorität laufen und das App bekommt einfach zu wenig cpu time. Wenn dann noch ein Cache eingestellt ist addiert sich die Latenz gegen unendlich auf. Zum Thema Cache kann Lonestar sicher was sagen. Ansonsten hast Du wahrscheinlich nur die Möglichkeit ein custom rom ohne blinkiblinki zu installieren. Auf meinem htc one läuft es zumindest ganz ordentlich. Aber auch hier überlege ich ob ich das Handy nicht lieber exklusiv für fpv verwende und ein stock android drauf baller.

Das Phänomen mit dem Ansteigen der Latenz habe ich bei dem Xperia Z2 auch. Eine Änderung auf 30fps hat daran nichts geändert.

Hmmm....
Ich tippe auf Abspielen in Software. Das würde das erklären.
Mal sehen, ob die nächste App-Version da Abhilfe schafft, die basiert auf GStreamer 1.4.1.
Die alte lief noch auf 1.3.9.

Ich kämpfe gerade mit dem Publishing über Google Market...Kann also noch etwas dauern.

Ich nutze eigentlich immer nur 25-30fps, da ich bei mehr auch auf dem Laptop Probleme habe und schnell mal 1-2Sek Verzögerung zusammen kommt (bei 25 erreiche ich idr 150-200ms).
Ein "nacktes" Rom wäre sicher mal ein Versuch, leider geht beim S5 die Garantie flöten wenn man da rumpfuscht und als Ersatz hätte ich aktuell nur ein LG G2 hier, welches sich aber nicht mehr sauber Laden lässt. Aber einen Versuch wäre es doch mal wert.

Also das mit der Latenz ist ja so ne sache.
Hat irgendjemand noch nen Apfel gerät und kann diese werte bestätigen? Den genau das wäre glaubwürdig. ..
Alles andre sind Stammtisch daten.
Nicht falsch verstehen aber einheitliche aussagekräftige daten bekommt man nur mit gleichen Bedingungen. Denke das da ein durchschnittlicher wert langfristig interessant ist. Und vielleicht sollte auch mal wer anders sich eine app für Android Windows Phone wagen einfach der Vielfalt halber.
Wir haben ja jetzt ziemlich oft gesehen das die meisten Fehler ja in der Software liegen und die Hardware ja für unsre Zwecke vollkommen ausreichend ist.

Welches iOS wird den vorausgesetzt, hab noch ein eingestaubtes ipad 1 rumliegen

Wie gesagt, hab ein iPad3 mit ios 7.0.4 und jailbreak... Würde mich für Tests zur Verfügung stellen.

Na das wird ja spannend ob ihr auch diese werte erreicht.

Mal einen Wert von mir. Hab ja die 5.8er Ubis. Geflogen mit einem Tek Sumo Nurflügel und bei beiden Ubis "nur" Stabantennen dran. Tja, war nicht sehr erbauend, nach ca. 200m ist das Bild eingefroren - und auch beim zurückdrehen ist es nicht mehr wiedererwacht. Ich musste landen, Strom vom Pi weg wieder ran und das Bild war wieder da.
Ok, die Ground-Antenne lag am Boden im feuchten Gras, auch nicht optimal. Ich wollte halt erst mal sehen, ob ich den Flieger mit all dem Gewicht in die Luft bekomme. Werde dann mal versuchen, die Antenne mittels Stativ auf 3m zu bekommen. Und dann werde ich auch mal CL/SPW dranhängen.
Habe ich was falsch eingestellt, dass das Bild nicht mehr kommt auch wenn der Empfang da ist?

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.

Ach soo, immer noch offen ist ein Ground-Recording. Dann könnte man hier ein paar Streams teilen. Und meine Cam musste ich kopfüber montieren, muss also auch noch da dran fummeln - und meine Linux-Kenntnisse sind leider echt mies. Viel mehr als Einloggen ist leider nicht.

Was für eine Pipe hast du verwendet? Hoffentlich aber UDP und nicht TCP?

Das mit dem Groundrecording habe ich mir noch nicht so genau angesehen, aber unter iOS ist es wohl möglich aus den Daten für den HW-Decoder auch ein Video zu erstellen.
Und zu der Geschichte mit dem Kopfüber: Du weiß, dass das Bild in der Pipe mit -hf -vf einfach geflipt werden kann?

Edit: Sorry Lonestar78, ich habs auch nur über Edit noch nachgeschoben ^^

@nique: hf und vf in der Pipe flippen das Bild

Edit: Ach zu laaaaaangsaaaammmmm