FPV Wifi Broadcasting HD Video - Thread zum Raspberry HD Videolink von Befi
- Themenstarter trailblazer
- Beginndatum
- Status
Ich habe bei the Pi hut bestellt (www.thepihut.com); die Lieferung ist aber noch nicht da
Hatte gehofft dass das aus UK schneller geht
Hatte gehofft dass das aus UK schneller geht
Zuletzt bearbeitet:
"Erstmal vielen Dank für die bisherige Hilfe, es klapp alles wie gewünscht. Eine Frage noch zur Verbindung im Fall Option B. Im App-Thread steht
"wenn sich die channels nicht stören, ist jedoch auch eine wlan hotspot verbindung möglich & angenehm (fatshark like -kein kabel am boden )"
Wie realisiere ich das - also Rpi >> Rpi >> Bild per WLAN ans Handy ? Fand dazu im Thread nirgends eine Antwort. Oder verstehe ich das Zitierte falsch?"
Ich erlaube mir das Mal zu pushen.
Ich fand keine Lösung um das zu realisieren. Mit udp4-datagram klappt es nicht. Wie bekomme ich das hin?
"wenn sich die channels nicht stören, ist jedoch auch eine wlan hotspot verbindung möglich & angenehm (fatshark like -kein kabel am boden )"
Wie realisiere ich das - also Rpi >> Rpi >> Bild per WLAN ans Handy ? Fand dazu im Thread nirgends eine Antwort. Oder verstehe ich das Zitierte falsch?"
Ich erlaube mir das Mal zu pushen.
Ich fand keine Lösung um das zu realisieren. Mit udp4-datagram klappt es nicht. Wie bekomme ich das hin?
So, bekomme demnächst mal das SDK für die Biteye HD Cam, dann kann ich mal schauen, ob WBC direkt auf der Cam läuft... Ich mach mir erstmal nicht zuviel Hoffnung, da es ein doch recht komplexes System ist und nicht so leicht zu debuggen wie am Raspberry, aber ich schau mal was möglich ist.
Für Fatshark Nutzer, die nicht mehr als 640x480 Auflösung haben könnte man so übrigens eine Digitale Übertragung im RAW Videoformat anbieten, dadurch hat man von der Cam-Seite her quasi kaum Latenz und am Raspberry könnte man den AV-Out nutzen um die Fatshark direkt mit Video zu versorgen. Bin mal gespannt ob das funktioniert, denn das wäre ja immernoch besser als das analoge Videosignal.
Für Fatshark Nutzer, die nicht mehr als 640x480 Auflösung haben könnte man so übrigens eine Digitale Übertragung im RAW Videoformat anbieten, dadurch hat man von der Cam-Seite her quasi kaum Latenz und am Raspberry könnte man den AV-Out nutzen um die Fatshark direkt mit Video zu versorgen. Bin mal gespannt ob das funktioniert, denn das wäre ja immernoch besser als das analoge Videosignal.
Das kommt drauf an, man kommt halt an die Daten viel schneller, da man den WLAN Stick direkt an die Cam machen kann, somit macht man nicht den Umweg über die IP-Cam Schnittstelle und den Raspi. WBC muss dann halt auf der Cam direkt laufen.
Die Latenz wird sich an sich nicht groß ändern, das liegt einfach am H264 Codec der 3 Frames Buffer braucht. Bei 30fps sind das dann eben 100ms und bei 60fps sind das eben 50ms. Bei Raw könnte man direkt jeden Frame abgreifen, die Latenz ist also nur so hoch wie das auslesen des Bildes dauert. Raw ist aber eben eine viel größere Datenmenge, deshalb wird da nur 640x480 oder 800x600 und eventuell wenn man die Datenrate vom WLAN hoch genug macht (was weniger Reichweite bedeutet) noch 720p gehen.
Die Idee dahinter ist auch nicht die Latenz zu reduzieren, das geht nurnoch mit MIMO Systemen und RAW Video oder wenn man die FECs komplett abschaltet.
Mit 8 Blocks, 4 FECs und 1024 Blockgröße dauert die WBC Übertragung ca 90-100ms. Das kann man bei WBC nicht mehr reduzieren, außer man optimiert den Code, aber da blick ich nicht durch. Andere Parameter könnten eventuell auch die Latenz beeinflussen, das müsste man mal durchtesten. Es können dann aber auch deutlich mehr Artefakte auftreten.
Die Raspi Cam selbst braucht bei 48fps ca 63ms. Somit kommt man insgesamt ca auf 150-160ms. Das wird eben nicht besser, aber durch die Biteye Cam wesentlich kompakter und die Bildquali ist besser und es ist von vornherein eine richtige Linse dabei. Außerdem hat die Biteye Cam ein Hardware OSD eingebaut, man könnte also theoretisch auch Daten einblenden.
Die Latenz wird sich an sich nicht groß ändern, das liegt einfach am H264 Codec der 3 Frames Buffer braucht. Bei 30fps sind das dann eben 100ms und bei 60fps sind das eben 50ms. Bei Raw könnte man direkt jeden Frame abgreifen, die Latenz ist also nur so hoch wie das auslesen des Bildes dauert. Raw ist aber eben eine viel größere Datenmenge, deshalb wird da nur 640x480 oder 800x600 und eventuell wenn man die Datenrate vom WLAN hoch genug macht (was weniger Reichweite bedeutet) noch 720p gehen.
Die Idee dahinter ist auch nicht die Latenz zu reduzieren, das geht nurnoch mit MIMO Systemen und RAW Video oder wenn man die FECs komplett abschaltet.
Mit 8 Blocks, 4 FECs und 1024 Blockgröße dauert die WBC Übertragung ca 90-100ms. Das kann man bei WBC nicht mehr reduzieren, außer man optimiert den Code, aber da blick ich nicht durch. Andere Parameter könnten eventuell auch die Latenz beeinflussen, das müsste man mal durchtesten. Es können dann aber auch deutlich mehr Artefakte auftreten.
Die Raspi Cam selbst braucht bei 48fps ca 63ms. Somit kommt man insgesamt ca auf 150-160ms. Das wird eben nicht besser, aber durch die Biteye Cam wesentlich kompakter und die Bildquali ist besser und es ist von vornherein eine richtige Linse dabei. Außerdem hat die Biteye Cam ein Hardware OSD eingebaut, man könnte also theoretisch auch Daten einblenden.
Zuletzt bearbeitet:
Ich hab zuerst die Cam in hello_video gepiped, sodass man sieht, wieviel Latenz die Cam an sich hat, was sich ungefähr mit der Bufferberechnung gedeckt hat und dann geschaut, wie lang es insgesamt dauert.
Da bei dem ersten Test die Anzeige schon mit drin ist, habe ich den Wert davon einfach vom Gesamtwert abgezogen und man kommt auf die Übertragung.
1. Test:
cam->raspivid->hello_video->bildschirm
2. Test
cam->raspivid->wbc->hello_video->bildschirm
So kommt beim 2. also nur WBC dazu, dadurch kann man es dann ausrechnen. Sind halt alles nur grobe Werte, aber die Tendenz ist so halt erkennbar.
Ich hab übrigens gelesen, dass die Latenz mit MJPEG geringer sein soll, dadurch ist die Datenrate höher. Raspivid unterstützt MJPEG, man müsste mal schauen, wie hoch die Bitrate wird... Wenn sie unter 24Mbit ist, sollte es kein Problem sein... Werde ich mal testen. MJPEG hat glaub nur 1 Frame Buffer... Das heißt letztendlich, dass die Camlatenz quasi rausfällt.
Ist noch neu und gibt es erst seit April:
https://github.com/raspberrypi/userland/commit/4e259dcbecf2ee5898a118916d2236c43f5ef713
Mal sehen ob es schon in der aktuellen Version drin ist oder ob ich selber bauen muss...
Da bei dem ersten Test die Anzeige schon mit drin ist, habe ich den Wert davon einfach vom Gesamtwert abgezogen und man kommt auf die Übertragung.
1. Test:
cam->raspivid->hello_video->bildschirm
2. Test
cam->raspivid->wbc->hello_video->bildschirm
So kommt beim 2. also nur WBC dazu, dadurch kann man es dann ausrechnen. Sind halt alles nur grobe Werte, aber die Tendenz ist so halt erkennbar.
Ich hab übrigens gelesen, dass die Latenz mit MJPEG geringer sein soll, dadurch ist die Datenrate höher. Raspivid unterstützt MJPEG, man müsste mal schauen, wie hoch die Bitrate wird... Wenn sie unter 24Mbit ist, sollte es kein Problem sein... Werde ich mal testen. MJPEG hat glaub nur 1 Frame Buffer... Das heißt letztendlich, dass die Camlatenz quasi rausfällt.
Ist noch neu und gibt es erst seit April:
https://github.com/raspberrypi/userland/commit/4e259dcbecf2ee5898a118916d2236c43f5ef713
Mal sehen ob es schon in der aktuellen Version drin ist oder ob ich selber bauen muss...
Zuletzt bearbeitet:
Vielleicht mal noch ein anderer Ansatz. Raspivid schiebt ja nach der Initialisierung eigentlich nur Puffer mit den Rohdaten der Cam in den Encoder und holt die encodierten Daten wieder ab. Der Encoder erwartet IMHO mindestens 64 Zeilen als Videogröße. Wenn man nun einen Frame der Cam in Subframes a 64 Zeilen teilen würde und den Encoder mit diesen Subframes füttert, würde man die Latenz deutlich reduzieren. Auf Empfängerseite müssten dann die decodierten Subframes wieder zu einem vollen Frame zusammengesetzt werden. Die Datenrate sollte sich nicht all zu sehr erhöhen, da auch aufeinanderfolgende Subframes oft recht ähnlichen Inhalt (Himmel, Wiese, ...) haben. Man müsste also raspivid derart anpassen, dass der Encoder passend initialisiert wird und die Puffer entsprechend gehandelt werden.
Vielleicht hat hier ja jemand Lust, Laune und das nötige Wissen, das mal zu testen oder das ganze mal auf rcgroups zu diskutieren. Mir fehlt leider aktuell die Zeit dazu.
Vielleicht hat hier ja jemand Lust, Laune und das nötige Wissen, das mal zu testen oder das ganze mal auf rcgroups zu diskutieren. Mir fehlt leider aktuell die Zeit dazu.
Elyot:
Das wäre sowas wie h264 slices wenn ich das richtig verstehe.
Hier ist mehr info dazu:
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=79825
Den Patch hab ich noch nicht probiert, soll angeblich was bringen:
https://github.com/sonium0/userland/commit/a7afc2d11ab18960fd69adddc5979470f0d65b44
Ansonsten hier noch mehr Infos und Ideen in Befis Blog (auch in den Kommentaren):
https://befinitiv.wordpress.com/2015/09/10/latency-analysis-of-the-raspberry-camera/
Deckt sich nur irgendwie nicht wirklich mit dem was Rangarid sagt bezüglich der Latenzen (ausser der Gesamtsumme).
Einer der ex Broadcom-Entwickler meint auch da wären nirgends 3 frames latency im encoder:
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=119475
Das wäre sowas wie h264 slices wenn ich das richtig verstehe.
Hier ist mehr info dazu:
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=79825
Den Patch hab ich noch nicht probiert, soll angeblich was bringen:
https://github.com/sonium0/userland/commit/a7afc2d11ab18960fd69adddc5979470f0d65b44
Ansonsten hier noch mehr Infos und Ideen in Befis Blog (auch in den Kommentaren):
https://befinitiv.wordpress.com/2015/09/10/latency-analysis-of-the-raspberry-camera/
Deckt sich nur irgendwie nicht wirklich mit dem was Rangarid sagt bezüglich der Latenzen (ausser der Gesamtsumme).
Einer der ex Broadcom-Entwickler meint auch da wären nirgends 3 frames latency im encoder:
https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=119475
Vielleicht noch mal allgemeiner formuliert. Statt den gesamten Frame in den Encoder zu schieben, wird dieser streifenförmig geteilt. Die einzelnen Streifen werden nun nacheinander an den Encoder verfüttert, als wären es komplette aufeinanderfolgende Frames. Statt einem einzelnen Frame fällt aus dem Encoder quasi ein Stream /eine Sequenz aus den Streifenframes raus. Auf der Empfängerseite müssen die decodierten Streifenframes dann wieder zu einem Vollbild zusammengesetzt werden. Durch die "kleinere Auflösung" stehen die Daten schneller zum Senden bereit, da die Framerate des Encoders ansteigt.
Rechenbeispiel:
720p30:
alle 33ms ein Frame für den Encoder + Zeit, die der Encoder braucht
720p30 als 10 Streifen a 72 Pixel Höhe:
alle 3 ms ein Streifenframe für den Encoder + deutlich kürzere Zeit für das encodieren
Während der Encoder im ersten Fall noch fleißig encodiert, ist im Fall 2 schon ein Großteil des Bildes übertragen.
Programmtechnische Umsetzung:
Der Cam-Puffer wird für den Encoder zum Ringpuffer. Außerdem müssen die Subframes noch irgendwie markiert/nummeriert werden, damit sie auf Empfängerseite wieder an der richtigen Position eingefügt werden können.
Rechenbeispiel:
720p30:
alle 33ms ein Frame für den Encoder + Zeit, die der Encoder braucht
720p30 als 10 Streifen a 72 Pixel Höhe:
alle 3 ms ein Streifenframe für den Encoder + deutlich kürzere Zeit für das encodieren
Während der Encoder im ersten Fall noch fleißig encodiert, ist im Fall 2 schon ein Großteil des Bildes übertragen.
Programmtechnische Umsetzung:
Der Cam-Puffer wird für den Encoder zum Ringpuffer. Außerdem müssen die Subframes noch irgendwie markiert/nummeriert werden, damit sie auf Empfängerseite wieder an der richtigen Position eingefügt werden können.
Ja, das ist genau das was ich meine und wovon im oben verlinktem Raspberry Forum Thread gesprochen wird:
"LOW_LATENCY mode is not a mode intended for general use. There was a specific use case for it where the source could feed the image in a stripe at a time, and the encoder would take the data as it was available"
Das Problem an der Umsetzung ist, das diese Dinge in der closed-source Firmware geschehen ...
"LOW_LATENCY mode is not a mode intended for general use. There was a specific use case for it where the source could feed the image in a stripe at a time, and the encoder would take the data as it was available"
Das Problem an der Umsetzung ist, das diese Dinge in der closed-source Firmware geschehen ...
Ideal wäre, wenn die Kamera die Daten gleich in Streifenform liefern würde bzw. wenn man genau wüßte, wann der nächste Streifen im Puffer liegt. Das würde nur im Closed-Source-Teil möglich sein. Bleibt also nur auf das gesamte Bild warten. Das Pufferschieben (raspivid) ist aber OpenSource. Hier könnte man ansetzen. Dann ist der Zeitgewinn kleiner, aber die Latenz dürfte dennoch gesenkt werden.
- Status
