FPV Wifi Broadcasting HD Video - Thread zum Raspberry HD Videolink von Befi

Status
Nicht offen für weitere Antworten.

just_different

Erfahrener Benutzer
Hat denn irgendwer.. (ich glaube das hatte ich in irgendeinem Post gelesen...) schon 5.8GHz am laufen? Mit welchen Sticks?

@Ronaldofpv, danke, das wäre schon mal klasse, mit dem neuen Image... und 4GB hört sich schon besser an als die 8GB (uncompressed) bisher.

RonaldoFPV, dennoch die Frage, wird denn automatisch auf dem TX-PI das Video gespeichert?
Eventuell sogar auf beiden?

Wenn ja, wo findet man die dann?

Warst Du das nicht auch, der das mit Windows schon mal getestet hatte?
Ich habe nämlich in meinem Laptop eine "Intel Wireless N-2230" 3x3, und laut einigen Foren auch den Monitormode können.
Zumindest in der VBOX unter Linux. Treiber und Firmware gibt es wohl inzwischen. Wobei unter Win7/64 wäre schon praktischer.

Dann bräuchte ich den 2. PI gar nicht.. und könnte ihn für den anderen Copter nutzen.
 

just_different

Erfahrener Benutzer
Ich wollte mir so ein Paar Antennen (Skew-Polar TX & Cloverleaf RX) bauen...auch wenn ich mal zwei Antennen bestellt habe 16 & 20DBi.. für je rund 2€ + 2€ Versand.

Doch, irgendwie habe ich Probs, die passenden Stecker und Buchsen zu bekommen.
Hat da jemand vielleicht gute und passende Links?

Bei Pollin ist irgendwie immer etwas verkehrt... mal die Buchse.. als frei Gewindeausführung (sollte aber mit der Überwurfmutter sein, mal den Stecker mit Mutter...grr.
Eine Verlängerung habe ich passend gefunden.. 50cm, wäre auch OK, doch brauche ich noch ein Gegenstück an der Antennenseite.
Wollte auch mal die Helicoil Antenne nachbauen und einfach mal schauen, was für mich das Beste ist.
 
Zuletzt bearbeitet:

moritzz06

Erfahrener Benutzer
Habe gerade mal meine Funke auf France Mode umgestellt. Dann sendet sie nur bis 2400Mhz (je nach Modell darüber mit 10mW statt 100mW).
Wenn jetzt das Video auf Kanal 13 sendet (2472Mhz) sollten die Störungen deutlich zurück gehen bzw. ganz weg sein.
Ich werde berichten sobald ich es getestet habe :)
 

just_different

Erfahrener Benutzer
@ronaldofpv, wenn Du schon mal dran bist, wäre es eventuell möglich, das mit dem automatischen Aufzeichnen, AUCH auf der TX-Seite zu machen.. auch auf Stick?
Womöglich sogar die Sticks, wenn sie als FAT32 formatiert sind. Dann hat man es super einfach, sich das hinterher anzuschauen.

Auch auf TX, weil da hat man ja die Artefakte nicht, und hat wenigstens vom Flug ein schönes Video.

Hey, dank Euch, wird das ja ein super Projekt... danke dafür.
 

bubu10

Erfahrener Benutzer
Ne frage kann man Vieleicht per Knopf druck per Taster (Script) die Aufnahme Starten oder stopen ?? wäre doch auch ein coole Gimick ,weil ich brauche nicht immer ne Aufnahme .

Gruß Rene
 
Hi,
ich beobachte den Thread seit einiger Zeit. Während ich auf den step-up Wandler warte um meine cam mobil zu machen, habe ich etwas gelesen und ein paar Experimente gemacht. Mein Ziel war es die besten settings bezüglich der Latenz des Encodings der Kamera heraus zu bekommen. Damit lässt sich bei den späteren Optimierungen das erste Glied schon mal abhaken. Ich wollte euch gerne meine Erkenntnisse mitteilen.

Versuchsaufbau:
raspberry pi A+ als transmitter, TP-Link TL-WN722N direkt am USB-Port, raspi WW-Cam
Arch for Arm als OS
der raspi fungiert als AP
ein Aromebook (chromebook mit Arch) mit Haswell Celeron und dem onboard Chip AR9462 ist der receiver
zum bequemen editieren der raspi-scripte ist ssh eingerichtet
die ausgabe von raspivid wird mittels netcat weitergereicht, Beispielscript:

default.sh
Code:
#!/bin/bash
/opt/vc/bin/raspivid -t 0 -n -fps 30 -b 4000000 -w 1280 -h 720 -o - | nc -k -l 5001 &
-l listen-mode, netcat wartet auf port 5001 auf eingehende Verbindungen
-k Wiederaufnahme, unterbrochene Verbindungen können fortgesetzt werden (funktioniert nur mit openbsd-netcat)

bei allen Versuchen wurde folgender Befehl zum empfangen verwendet

listen.sh
Code:
#!/bin/bash
mplayer -fps 200 -demuxer h264es ffmpeg://tcp://192.168.12.1:5001
mit der cam wurde Kronometer gefilmt, eine Stoppuhr für KDE. Mit SimpleScreenRecorder wurde der Desktop mit 1-fps aufgenommen.

Durchführung:
unter http://picamera.readthedocs.org/en/latest/fov.html findet man eine Auflistung und kurze Erläuterung der von der Kamera unterstützten Hardwaremodi. Das interessanteste daran, nutzt man eine Auflösung die nicht von der Kamera unterstützt wird, so nutzt die Kamera die native Auflösung die der gewünschten am nächsten kommt und der Encoder startet eine zweite Runde um das Bild entsprechend zu skalieren. Im Umkehrschluss bedeutet das, halten wir uns an die vorgegebenen Modi, sparen wir einen Encoderdurchlauf.
Niedrigere Frameraten haben keinen Einfluss auf die Geschwindigkeit des Encoders, höhere Frameraten bedeuten der Puffer wird schneller gelesen.
Für mich bedeutet das, ich halte mich an die nativen Modi und benutze die für diesen Modus höchstmögliche Framerate. Da ich mindestens HD-ready(1080x720) bei 30fps nutzen möchte, kommen die Modi 1,4 und 5 in Frage.
Ein paar kurze Tests, '-ex sports' für kurze shutterzeiten damit die millisekunden nicht so verschwommen sind. Ich habe den Stream gestartet und etwa 20 sekunden vorlaufen lassen, bevor ich den Timer und das Desktoprecording angemacht habe. Dann etwa 30s aufgenommen und angeschaut um einen Eindruck zu bekommen, dabei alle paar Sekunden pausiert und kurz überschlagen.

1. Mode 1 1920x1080 30fps
mode1.sh
Code:
#!/bin/bash
/opt/vc/bin/raspivid -t 0 -n -fps 30 -w 1920 -h 1080 -b 4000000 -ex sports -o - |\
 nc -k -l 5001 &
ergab ~170ms Latenz, schwankend zwischen 140ms und 200ms
2. Mode 4 1296x972 42fps
Code:
... -fps 42 -w 1296 -h 972...
ergab ~140ms, schwankend zwischen ~110ms und ~170ms
3. Mode 5 1296x730 49fps
Code:
... -fps 49 -w 1296 -h 730...
ergab ~110ms, schon stabiler zwischen ~95ms und ~120ms. Hier gehts weiter.

Hier https://raw.githubusercontent.com/raspberrypi/userland/master/host_applications/linux/apps/raspicam/RaspiCamDocs.odt gibts die aktuelle Version des raspicam Handbuchs, mal schauen was uns raspivid so bietet um die Latenz weiter zu verringern.

mit '-b 0 --qp (10-40)' bekommt man variable Bitraten, 10 für höchste, 40 für niedrigste (wirklich allermieseste) Qualität. Ein kompletter Reinfall, Latenz zwischen ~200ms(40) und ~2s(10).

mit '--profile (baseline, main, high)' setzt man das Profil des h264 Encoders, hier gibt es spürbare Latenzunterschiede.

mit '-b xxxx' setzt man die bitrate, es kommt hier vor allem auf die zur Verfügung stehende Bandbreite des Wifi-Links an und kann je nach Noise sehr unterschiedlich ausfallen, ich hab > 30 APs in Reichweite... . In meinem Fall hatte ich die besten ergebnisse mit 3000000 bps, eine weitere Verringerung brachte keine Verbesserung, bei mehr als 4000000 nahmen die Schwankungen zu. In meinem Fall liegt der Sweet-Spot also zwischen 3- und 4000000. Ich bin damit erstmal zufrieden.

Vorläufiges Ergebnis:
mode5-gut.sh
Code:
#!/bin/bash
/opt/vc/bin/raspivid -t 0 -n -fps 49 -w 1296 -h 730 -b 3000000 -g 49 -ex sports --profile baseline -o - |\
 nc -k -l 5001 &
mittel < 100ms, zwischen ~80ms und 120ms

snapshot4.png

Dingdong, mein Spannungswandler ist da, das trifft sich ja gut. Ich muss jetzt löten.

Verbesserungspotential,
- '--qp xx' mit fester bitrate
- raspivid nutzt mmal, evtl. ist v4l2 als treiber schneller
- shootout 'gstreamer vs mplayer vs ???' beim abspielen

Todo:
-wifibroadcast compilieren und die Ergebnisse im Ernstfall verifizieren

Ich hoffe ich konnte euch damit etwas helfen die besten Einstellungen für latenzfreies HD-Vergnügen zu finden.

Grüße

cbl
 

rodizio

Erfahrener Benutzer
Interessant. Danke fur die Infos. Um die 100ms ist ja schonmal nicht schlecht.

Befinitiv konnte nochmal einen Frame Latenz beim Raspivid sparen:
I've found where in the pipeline the last frame gets stuck. Raspivid uses fwrite to output the h264 data to stdout. Since fwrite is buffered, not all data received from the encoder has been written out immediately. Therefore I modified raspivid to use a plain "write" function call to get rid of the buffering.
Another issue is the conversion of a stream of bytes into NALU units. Afaik the only way to determine the length of the current NALU is to wait until the start header (0x00000001) of the next NALU. But if you do that you are already one frame too late. Appareantly raspivid (with my change from fwrite to write) always outputs complete NALUs in a single write. Therefore I made a hack that appends the NALU start header at the end of the current write call and removes the start header at the beginning of the next write (and so on).
My changes allowed me to repeat the encoding latency tests without any frame being stuck in the pipeline. This time I worked directly on the Raspi with the camera to really get the encoding latency (without transmission and decoding). I attached a screen to the raspi with a timestamp running on it. In parallel I captured video data from my modified raspivid and timestamped each NALU. In case of 1280x720, 700kbps, 2fps, every second frame a keyframe I measured the encode latency to be somewhere between 70 and 80ms. This of cause also includes the latency of my screen. So the actual latency should be some ms below that.
While my hacks helped to reduce latency a bit (roughly by the time of a frame, in case of 48fps 20ms) it wasn't a big step forward. But at least now we have an understanding what part of the system causes what latency.
Geht eigentlich auch MJPEG mit der Raspicam? (braucht natürlich mehr Wifi-Bandbreite, aber auf 5.8Ghz ist ja genug Platz im Spektrum für 40MHz breite Kanäle...)

Edit: Mir fällt gerade ein, mplayer hat noch einen -cache parameter, vielleicht lohnt es sich damit herumzuprobieren
 
Zuletzt bearbeitet:
MJPEG ist meiner Meinung nach für die für uns real erreichbaren Netto-Datenraten keine praktikable Lösung. Sicherlich könnte man sehr niedrige Latenzen erreichen, aber die Bildqualität würde stark darunter leiden.
Wenn man die Keyframerate auf 1 oder 2 setzt kann man im übrigen sehen, was bei einem zu hohen Bandbreitenverbrauch für einzelne Frames am Ende überbleibt - das sieht imo nicht mehr sehr schön aus.

Am Ende ist natürlich alles ein Trade-off der verschiedenen Parameter. Ich versuche deswegen die Anforderungen an mein HD Link nach den Prioritäten zu sortieren.
bei mir an erster Stelle:
Linkqualität und Reichweite: in einem recht störungsfreiem Umfeld (d.h. Flugwiese) reichen mir 2 Re-transmissions (ist aber auch Minimum, da ganz ohne zuviele Artefakte auftreten). Dazu dann mindestens einfaches Diversity am RX. Die fest eingestellte 26MBit Bruttodatenrate ist ein gut gewählter Kompromiss, deren Modulation noch nicht ganz so empfindlich ist.

Dann Latenz und FPS:
Vom analogen Link bin ich ein flüssiges Bild gewohnt, bei 30 FPS geht mir die Immersion etwas flöten, deswegen also so hoch wie möglich. Das beeinflusst natürlich gleichzeitig die Latenz positiv (auf Kosten der Bildqualität durch die begrenzte Bandbreite). Die Latenz lässt sich durch die Keyframrate auch recht gut verringern, eine zu niedrige ist dann aber auch wieder kontraproduktiv (ich bin aktuell auf 12).
Eine niedrige Blockrate wirkt sich nach meinem Empfinden auch positiv auf die Latenz aus, wenn man nicht mit starken Störern rechnen muss, kann man damit ruhig mal etwas experimentiern (bei mir aktuell 4)

Bildqualität:
HD Auflösung muss es mindestens sein, also ab 720p. Die mögliche maximale Bitrate liegt dann mit den oben angegebenen Werten so um die 4000 bis 4500 kbit.

Das sind so meine Erfahrungen bisher, die weiteren Analysen und Optimierungen von Befi hören sich aber sehr interessant an :cool:
 
mmal, der treiber den raspivid nutzt, kann mjpeg. das ist aber noch nicht bis in raspivid vorgedrungen. Man könnte sich jedoch mit picamera schnell was zusammenstricken, Näheres hier http://picamera.readthedocs.org/en/latest/api_encoders.html entsprechende Beispiele sind vorhanden und bedürfen nur geringfügiger Änderung http://picamera.readthedocs.org/en/latest/recipes1.html#recording-to-a-network-stream. Damit könnte man dann auch Kontrast, Helligkeit, Schärfe, Shutter, Weißabgleich, und so weiter on-the-fly ändern wenn man nen uplink hat. Hat schonmal jmd ausprobiert ob man befi's tx und rx parallel auf dem gleichen interface laufen lassen kann?

v4l2 kann auch mjpeg und h264
Code:
sudo modprobe bcm2835-v4l2
sudo v4l2-ctl --list-formats
Ich halte h264 aber auch wegen der Datenraten ohne Buffering für geeigneter als mjpeg

unrelated, afair sind einige auf der Suche nach Displays für DIY-Brillen, das hier müsste das Display aus der Headplay-HD Brille sein.

btw: der Spannungswandler hat magischen Rauch gespuckt als er das erste mal nen Akku sah, mal schauen was der Kundendienst dazu meint. Alos weiter warten und die Zeit vertreiben. Jetzt wird erstmal wifibroadcast compiliert.

@rodizio, ich hab die Aussage von befinitiv gefunden. Leider dazu noch keinen patch im bitbucket. Man wird sehen.

@Constantin, danke, hab ich noch was zu lesen^^. Das gleiche nochmal zu testen macht mir nicht soviel aus, hab ja was dabei gelernt.
 

rodizio

Erfahrener Benutzer
Ja, ist natürlich immer ein trade-off. Mir persönlich ist niedriege Latenz wichtig und da scheint bei 80-100ms langsam das Ende der Fahnenstange erreicht mit der h264 implementation des pi. Low latency h264 features hat der pi ja leider nicht. Bei Bandbreite gibt's aber noch recht viel Optimierungspotenzial. Befinitiv hat jetzt angefangen das interleaving/fec aus udpcast in wifibroadcast einzubauen, das sollte schonmal einiges bringen (im Moment wird die Bandbreite durch die retransmissions halbiert). Dann kann man auch noch auf 40MHz Kanalbandbreite gehen. Und vielleicht später mal mit zwei wifi-Karten auf zwei verschiedenen Frequenzen senden. Bei MCS2 wären das ca. 40Mbit nutzbare Datenrate ohne fec. Mit fec dann vielleicht noch 30mbit. Sollte eigentlich reichen für MJPEG (?)
 

rodizio

Erfahrener Benutzer
Noch was vergessen: Tx und Rx auf einem Interface sollte nichts gegens prechen. Problem ist nur das shared medium, zuviel traffic vom Boden-Pi zum Luft-Pi wird das Video stören. Time division multiplexing in Software zu bauen würde wohl recht aufwendig bis unmöglich ohne Realtime-OS
 

rodizio

Erfahrener Benutzer
Bin mir grad nicht sicher ob's eine minimale Frame Länge gibt. Wenn Du nur ein byte payload hättest (würde ja reichen) hättest Du praktisch den kurzmöglichsten Frame. Wenn der nicht zu oft gesendet wird (nur 1x pro Sekunde oder so) müsste das klappen.

Paketgroesse müsste dazu so klein wie möglich gestellt werden im wifibroadcast. Dann im gewünschten Takt genau die Menge an bytes in wifibroadcast pipen die ein Paket ergeben, damit die Pakete auch so rausgehen wie sie sollen.

Vielleicht könnte man auch irgendeinen Manangement Frame (beacon, ack, wasweisich) dafür missbrauchen oder abändern, aber dazu muss man C können.
 

just_different

Erfahrener Benutzer
Ich habe jetzt auch mal etwas gespielt und wollte sowohl das Video verbessern (ronaldofpv sei dank) und auch das mit TEE-Command mal einbauen und das Video speichern.

Meine TX-zeile sieht nun so aus:
raspivid -ih -t 0 | tee /home/pi/wifibroadcast/videos/test_video.h264 | -w 1280 -h 720 -fps 48 -b 4500000 -n –ex backlight –awb horizon -g 60 -pf high -o - | sudo /home/pi/wifibroadcast/tx -b 8 -r 2 wlan0

Das hat mir ein mal, eine Datei "test_video.h264" angelegt, mit Länge 0.
Bei späteren Starts, erhalte ich am RX nur noch "Paket lost.."

Irgendwo habe ich dann wohl doch ein Bug eingebaut. Kann mir da jemand bitte helfen?
 
Dir ist was verrutscht
Code:
raspivid -ih -t 0  -w 1280 -h 720 -fps 48 -b 4500000 -n –ex backlight –awb horizon -g 60 -pf high -o - | tee /home/pi/wifibroadcast/videos/test_video.h264 | sudo /home/pi/wifibroadcast/tx -b 8 -r 2 wlan0
so müsste es klappen
 

just_different

Erfahrener Benutzer
Super, danke und werde es nach Feierabend mal testen.
Dann kann ich auch mal zeigen, wie es bei mir aussieht.

Wobei ich immer noch Staune, dass mein Alfa-Stick mit dem 8187-Chip nicht angesprochen wird .. zumindest nicht in dem Image was ich drauf habe (wohl auch ne Einstellung).

Da ich hier, und in den verschiedenen Foren um BEFI´s Thema, immer wieder auch ein Performance-Problem zu sein scheint...
Wäre es da nicht denkbar, auf der RX-Seite nicht einen Raspberry PI einzusetzen, sondern wie sicher der ein oder andere hat, einen leistungsfähigen Laptop mit z.B. Kali Linux, oder welches Linux auch immer. Das gibt es in einer schlanken Variante mit 390MB.
Den TP-Link nutzen Pentester / Wardriver usw. ja auch dafür und sie nutzen doch auch den "Monitor-Mode".. oder nicht?

So könnte man auch schauen, ob es ein Leistungsproblem beim Encoden ist, oder am Prinzip liegt.

Leider bin ich jetzt nicht der Linux Crack.. und kann auch nicht programmieren, aber wenn mir jemand ein paar Tips gibt.. dann kan ich gerne mal schauen. Leistung hat meiner eigentlich genug (M17R4).
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten