Tutorial (beta)
OPTION A:
Vorteile:schnell&easy, Nachteile: KEIN "wifibroadcast" ! ,sondern ein direkter wlan link - reicht nur für ~200m herumcruisen
Benötigt: rpi mit camera und wlan Stick,handy mit neuester app
Weg der Daten: Licht->rpi cam->rpi h.264 encoder->wlan(raw h.264 data byte-stream over udp)->handy->hw h.264 decoder des Handy's->Screen
Stepp 1) Herstellen der Verbindung Pi-Handy
Auf dem Handy einen wlan Hotspot starten,und den rpi mit dem Hotspot verbinden.
Test: Der rpi sollte nun bspw. google öffnen können
Stepp 2) Ip Adresse des Handy's finden & aufschreiben
Entweder findet man die ip des Handy's in den Einstellungen, oder man startet "TestActivity"; dort stehen die ip adressen des Handy's. Ich sage Adressen- das Handy kann mehrere ip's haben (bspw. 1 für das Heim-Wlan, 1 für den Hotspot), von denen nur 1 die gesuchte ist.
In der App muss man in diesem fall das richtige interface suchen; diese haben leider keine "gewohnten" Trivialnamen.
Bei mir:"wlan0"= home wlan
"rmnet0"= wlan hotspot
"xxx"= usb hotspot
Zur not hilft jedoch google schnell weiter.
In meinem fall ist das Handy per wlan Hotspot mit dem pi verbunden; Ich schreibe mir also 10.69.47.45 als ip Adresse auf.
Test: auf dem pi sollte die ip mit "ping 10.69.47.45" ereichbar sein; Achtung: es sind alle ip's des Handy's "ping-bar",aber nur die vom richtigen Interface funktioniert später.
Stepp 3) Camera starten & daten an's handy senden
Auf dem pi folgendes Kommando eingeben "raspivid -w 960 -h 810 -b 3000000 -fps 49 -t 0 -pf baseline -ih -g 49 -o - | socat -b 1024 - udp4-datagram:10.69.47.45:5000 ";
dabei nun natürlich anstatt 10.69.47.45 die aufgeschriebene ip verwenden.
Test: In "testActivity" sollte nun nicht mehr das toast "couldn't receive any bytes" erscheinen,sondern die empfangenen frames&bytes:
Wenn nicht: die pipeline nochmal überprüfen.
Stepp 4) Decodiertes video anzeigen:
Eine Anzeigeart auswählen & das video checken.
Wenn kein Video angezeigt wird: es kann bis zu 10 sec. dauern,bis der decoder initialisiert ist & ein key-frame empfangen hat.
Wenn nicht: mal in den Einstellungen -> Latency file schauen, ob der decoder wirklich frames decodiert.
es kann jedoch auch sein,dass der decoder mit dem rpi cam byte-stream nicht kompatibel ist - dann mal im thread schreiben, ich versuche dann,eine Lösung zu finden.
OPTION B:
Vorteile:Reichweite,"wifibroadcast" übertragung
Nachteile: komplizierter
Benötigt: "normalen" tx und rx pi, Handy, app, USB kabel
Weg der Daten: Licht->rpi cam->rpi h.264 encoder->wifibroadcast tx-> air(wifibradcast packets)->wifibradcast rx->usb-kabel->handy-app->hw h.264 decoder des Handy's->Screen
Vorgehensweise: wie bei Option A); wir verbinden das Handy aber mit dem rx pi,und verändern die rx pipeline:
1)Für die,die keines von den "prebuild" images nehmen:
./rx -b 4 -r 2 -f 1024 wlan2 | socat -b 1024 - udp4-sendto:10.69.47.45:5000" ( parameter -b , -r ,und die ip müssen natürlich angepasst werden )
2)Für die mit den prebuild images:
ungefähr so: $WBC_PATH/rx -p $PORT -b $BLOCK_SIZE -r $FECS -f $PACKET_LENGTH $NICS | socat -b 1024 - udp4-sendto:192.168.0.104:5000;
die "raspivid pipeline" durch die "socat pipeline" ersetzen
Ich persönlich verbinde das Handy am liebsten per usb hotspot mit dem rx pi; wenn sich die channels einstellen lassen, ist jedoch auch eine wlan hotspot verbindung möglich & angenehm (fatshark like -kein kabel am boden )
----------------------------------------------------------------------------------------------------
Settings:
1)Video Format: wenn die Auflösung bspw. 800*600 beträgt,so ist das Format 800/600=1.333.
2)Data Source: die app kann die raw h.264 streams entweder auf dem udp port 5000 empfangen,oder ein raw .h264 file(wie es die rpi cam erzeugt) parsen
Praktisch zum testen; man muss nur aufpassen,wenn die app ein File parst,wird der encoder so schnell wie möglich gefüttert, und es besteht keine time-synchronisation
3)File Name 1: receiving data from file; das file muss auf demselben ort gespeichert sein,wo auch das "GroundRecording" file liegt;
4)Ground Recording on/off. Kann latenz erhöhen,muss aber nicht.
5)File Name 2: ground recording file
6)Latency: zeigt die messbare latenz der app an; wie viele frames android buffert,ist schwer zu sagen, und hängt auch vom hersteller ab; mein huawei hat einen input lag von ~60ms (getestet,wer will kann mal die App OpenGLLagTest ausprobieren) ; angenommen der touchscreen hat 12ms verzögerung,dann buffert android wohl 3 frames (48ms)
7)Decoder MultiThread: Reduziert die Latenz bei den meisten Geräten - manche decoder sind jedoch schon von Haus aus schnell genug,und manche Decoder können kein MultiThread.
8)Unlimited openGl FPS: Wenn das Handy es schnell genug ist,kann dies vlt. die latenz geringfügig verbessern; mein Handy schaltet jedoch mit dieser funktion nach ~5sec. auf die 60fps (OpenGL) zurück.
9)UserDebug: zeigt Toasts mit wichtigen Meldungen,und schreibt Exceptions in das "Debug File". Es empfiehlt sich,zum Fliegen diese Funktion zu deaktivieren (kann Latenz erhöhen).
-----------------------------------------------------------------------------------------------------
FAQ:
1)warum kann ich nicht das wlan vom handy für wifibroadcast benutzen,und brauche den rx pi ?
-Android unterstützt keinen "Monitor mode" und auch wifibradcast hat noch niemand auf Android portiert; für die technisch versierten: Es geht schon,ist jedoch kompliziert; info's hier:
https://befinitiv.wordpress.com/2015/04/18/porting-wifibroadcast-to-android/
2)wie hoch ist der Lag der App ?
Bei meinem Handy (Huawei ascend p7 , mali 450 mp gpu) gehen bei 49 fps von 130ms end-to-end latency etwa 60ms auf die app.
In den Einstellungen findet ihr ein "Latency file". Der "overall measured lag of the app" sollte nicht höher als 20ms sein (bei mir: ~10ms); wenn er größer ist,dann Buffert der hw decoder vermutlich frames (ein feature von manchen herstellern,das für real-time streaming jedoch nur von Nachteil ist).
Der restliche Lag (etwa 48 ms) entsteht durch "Android's SurfaceFlinger",welcher bis zu 3 "display-frames (16ms)" latency erzeugt.
Die App ist schon so weit,wie es für einen "nicht-breadcom-hw-engineerer" geht, auf real-time optimiert. Und ich sage nicht ohne Stolz,dass ich mit dem "Software x264 encoder" und avconv auf meinem linux pc den Bildschirm bei 120fps unter 70ms auf mein Handy spiegeln kann - das ist mindestens genau so gut,wie die "GameStream" Angebote von nVidia oder steam (
https://youtu.be/a9-bdXUC0j0 ).
3) Mein usb Tethering beendet sich von selbst !
Sobald das Handy am USB hängt wird es natürlich geladen - und der Ladestrom kann so hoch sein,dass der rpi diesen nicht mehr liefern kann.
Solution: in der Datei /boot/config.txt den Eintrag max_usb_current=1 hinzufügen.
nun fehlt auf dem s6 nurnoch das bild. Leider bisher nicht erfolgreich. Auf dem s5 wie gesagt kein Problem mit dem selben setup.
