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

Status
Nicht offen für weitere Antworten.

just_different

Erfahrener Benutzer
@rangarid, wie wäre es denn, wenn man das mit dem Home-Punkt einmal per Taster festlegen kann?

Ich denke die meisten haben doch sicher das geordnete runterfahren auf nem Taster, der ja nun kein Hexenwerk darstellt.

Warum nicht einen 2. Taster, und wenn der 3d/4d SATfix da ist (könnte man komfortabel mit LED anzeigen), dann den Taster drücken, und die aktuellen Koordinaten werden als Homepunkt gespeichert (könnte man theoretisch auch noch per LED bestätigen, dass er gesetzt ist), bis Strom weg ist.
Ob das jetzt über eine mehrfarben LED geht, oder über einzelne.. egal.

Ich halte das für mehere Dinge eine sehr elegante und flexible Lösung zugleich.
So kann man den Ort für Home ganz gezielt steuern und festlegen, unabhängig davon, wo der Flieger/Copter seinen Satfix bekommen hat.

Wäre das viel Arbeit?
 

Rangarid

Erfahrener Benutzer
So grad mal Latenz gemessen. Liegt bei ca 165ms mit den aktuellen Images von Befi und den Standard Einstellung (8 4 1024).

Folgende tests hatte ich eben gemacht:
8/4/1024 48fps keyframes 48 ca 165ms Latenz
8/4/1024 48fps keyframes 60 ca 167ms Latenz
8/2/1024 48fps keyframes 60 ca 167ms Latenz

Natürlich alles höchst unprofessionel mit Stoppuhr im Browser und Foto von der Handykamera XD.

Also latenz ist bei allen 3 gleich, was kann man noch mal versuchen zu ändern, um eine bessere Latenz zu bekommen?
 

action

Erfahrener Benutzer
FPV Wifi Broadcasting HD Video - Thread zum Raspberry HD Videolink fon Befi

bezüglich Latenz: Ich hatte bei meinem HDMI Monitor so ein Lebhafter Modus drin, der hat mir um die 60ms gekostet :) jetzt ist mein uralter laptop doch nicht Vorreiter :p

Ich hab auch in allen Konstellationen gleich viel ms...

PS: Hat jemand 1080p Werte gemessen?
 

just_different

Erfahrener Benutzer
endlich ist mir auch klar, warum ein Upload auf meinem Server immer abgebrochen wurde und sich wiederholte.

Es war einfach nicht genug Platz. Wir hatten schon rund 6,4GB an Images oben.

Ich habe etwas aufgeräumt, und lade gerade das neuste RX-PI2B Image von Schalonsus hoch (FTP sagte 20min.), das durch ändern des Startscriptes auch TX kann.

Es ist bei HDMI auf 1280x800 voreingestellt, kann Diversity und macht auch bei Vorhandensein des "Video"- Verzeichnisses automatisch Aufnahmen.

Damit sollten zumindest alle Plattformen verteten sein.
 

Schalonsus

Erfahrener Benutzer
Habe eben mit den raspivid Parametern experimentiert.
Als vorteilhaft haben sich -ISO 100 und -ss 7000 herausgestellt.
Latenz so bei 720p und 8/4 Modulation konstante 130ms.
Latenz bei 1080p 220ms.
 

Rangarid

Erfahrener Benutzer
Ich hatte mir noch folgende Params mal vorgemerkt:
[-vs] video stabilisation
[-ex antishake] Exposure modus für viel gewackel?
[-drc high] dynamic range compression high -> so ähnlich wie WDR?

Inwiefern das die Latenz beeinflusst weiß ich aber nicht. Denk aber eher, dass hie rnoch was dazu kommt...
 

Rangarid

Erfahrener Benutzer
So, neue Tests:
4/2/1024 48fps 60 keyframes 150ms 1280x720
4/2/512 ca 149ms aber deutlich mehr Fehler im Bild
meine beste Latenz hatte ich gerade bei 145ms mit 8/4/512 rest wie oben

raspivid mit -vs -ex antishake und 8/4/512 lag bei ca 170-180ms
raspivid mit -ex antishake und 8/4/1024 lag bei ca 149ms
raspivid mit -ex antishake -drc high und 8/4/1024 lag bei ca 175ms
raspivid mit -ex antishake -drc high -vs und 8/4/1024 lag bei ca 200ms
raspivid mit standard und 8/4/512 lag bei ca 150ms
raspivid mit standard und 8/4/1024 lag bei ca 150-160ms

-ISO 100 und ss 7000 zusammen macht das Bild sehr dunkel. Beides einzeln konnte ich keine unterschiede feststellen. Eventuell reicht das für draußen, aber drinnen selbst mit Licht an und allem drum und dran zu dunkel.

Man hat eine minimal niedrigere Latenz mit Framesize 512, dafür kommen mehr Fehlerframes und das Bild wird schlechter. Auf 800x600 runter zu gehen verbesserte die Latenz auch nicht deutlich.

Die Werte 8/4/1024 sind also schon recht optimal denke ich. -ex antishake bringt keine merkliche Verzögerung, -vs und -drc aber schon.

60fps haben ebenfalls 150-170ms Latenz bei 8/4/1024.

Denke also 150ms ist schon ganz ordentlich und sollte so der Standardwert sein, den das System rausholen kann. Das mit den -ISO 100 und -ss 7000 werde ich mal tagsüber am Fenster nochmal probieren. Wenn man so tatsächlich auf 130ms kommt, ist denke ich keine weitere optimierung notwendig.
 

Schalonsus

Erfahrener Benutzer
1024 auf 512 hatte ich auch mal probiert aber das is nicht vorteilhaft. Beste Einstellung bei mir: 1280x720 keyframerate 8 48fps 4000000Bitrate 8/4/1024 -ex sports -awb horizon -drc high - ss 7000
So komm ich auf 130 konstant. - ISO 100 ist nich unbedigt notwendig
 

Rangarid

Erfahrener Benutzer
Also -drc hat bei mir ca 20-25ms draufgehauen. Wenn du das abschaltest, müsstest du ja dann theoretisch auf noch weniger kommen...

grad noch gesehen, es gibt einen Branch wo an low latency gearbeitet wird:
https://bitbucket.org/befi/wifibroadcast/commits/branch/low_lat_raspivid_hook
Hat das schonma jemand getestet?

Komme mit deinen Einstellungen auf 150-175ms. Ändert sich immer mal wieder...
 
Zuletzt bearbeitet:

Schalonsus

Erfahrener Benutzer
Wie gesagt drc ändert bei mir garnichts an der Latenz. Mit oder ohne 130ms.
Low latency branch rät befi von ab. Läuft anscheinend nicht so stabil. Habs vor paar Wochen mal getestet hab kein Unterschied gemerkt.
 

just_different

Erfahrener Benutzer
sorry, ist irgendwie an mir vorbei... da komme ich nicht wirklich mit und wüßte nicht, was zu tun ist.
 

Rangarid

Erfahrener Benutzer
Wie gesagt drc ändert bei mir garnichts an der Latenz. Mit oder ohne 130ms.
Low latency branch rät befi von ab. Läuft anscheinend nicht so stabil. Habs vor paar Wochen mal getestet hab kein Unterschied gemerkt.
Du musst das auch anders benutzen. In dem Quellcode von den Dateien steht z.B. drin
./txhook.so raspivid .... -o - und hier dann die pipe mit tx...

Das ganze soll wohl ein paar systeminterne Funktionen und die Pipe mit für wifibroadcast besser geeigneten Methoden überschreiben. Leider bekomme ich Fehler wenn ich txhook benutze... Naja mal abwarten bis er es freigibt.

Interessant fänd ich, den Codec mal auf H265 umzuändern. Leider kommt der Raspi damit nicht klar, aber der orange PI z.B. unterstützt auch H265. Da sind die Daten bei gleicher Quali nur halb so groß...

Ich hatte noch gesehen, dass mal mit gstreamer rumexpiremtiert wurde. Ich meine ich hatte irgendwo gelesen, dass die Latenz mit gstreamer besser sein soll. Hat das mal jemand probiert?
 
Zuletzt bearbeitet:

Schalonsus

Erfahrener Benutzer
Ich nutze nur gstreamer aufm Laptop und meine Latenzwerte kommen auch daher.
Aufm pi ist gstreamer glaub ich aber eher weniger förderlich da fehlt Rechenleistung.

Ok. Das mit dem txhook habe ich so nicht bedacht. Dachte es wäre automtisch aktiv wenn ich den Branch gezogen und installiert habe.
In den Kommentaren auf Befis Seite steht irgendwo das es keinen nennenwerten Vorteil bringt und die ersten Tests ernüchternd waren, deswegen wird er daran erstmal nicht weiter arbeiten.
 

Rangarid

Erfahrener Benutzer
Kannst du mal die Latenz mit nem Raspi als RX am Monitor messen wenn du einen da hast? Dann würde man mal sehen ob daher der Unterschied kommt.

Hab grad nochmal den alten Raspi mit analog Ausgang gemessen für Fatshark Videobrillen usw. da kommen nochmal 25-50ms zusätzlich dazu. Aber keine Ahnung, ob das am Digital2Analog vom Raspi oder Analog2Digital vom Monitor liegt. Sicher ist, dass beides etwas zusätzliche Latenz verursacht, denke aber, dass der Monitor mehr Latenz verursacht. An ner Fatshark wäre die Latenz vermutlich weniger, da die ja für analoge Signale optimiert ist.

Komisch ist natürlich trotzdem, dass -drc bei dir keinen Unterschied macht... Kann das mal wer anders messen?
 
Zuletzt bearbeitet:
Hallo zusammen,

ich lese nun schon einige Wochen hier mit, und habe nun auch alles zusammen, um die HD Übertragung aufzubauen.

Als Hardware habe ich
2x Raspbery Pi 2 B
2x TP-Link TL-WDN3200

dazu noch Kleinigkeiten wie Kamera, SD Karten und Netzteile usw.

Einzig das HDMI-Kabel habe ich vergessen (ich könnte mich :wow: ....)

So, mit Linux hatte ich noch nicht so viel am Hut. Aber viel lesen bildet :rolleyes:

Ich habe mir jetzt von hier http://www.rcgroups.com/forums/showthread.php?t=2454052&page=16
die Images runter geladen, da ich das ganze Aufgrund der verwendeten Taranis auf 5,8 Ghz aufbauen will.

Bin ich da auf dem richtigen Weg, oder ist jemand von euch schon mit dem 5,8 Ghz Image weiter?
 

Rangarid

Erfahrener Benutzer
lad dir einfach die Images von Befi hier runter:
https://github.com/befinitiv/rpi_wifibroadcast_image_builder/releases

Beides installieren

Dann in wifibroadcast_fpv_scripts tx.sh und rx.sh anpassen mit Channel auf irgendeinen 5Ghz Kanal und weiter unten wo das Wlan eingestellt wird iw reg set DE (damit gehen die Kanäle 36-48) oder RU für alle Kanäle im 5Ghz Band.

Code:
	echo "updating wifi ($1, $2)"
	killall ifplugd
	ifconfig $1 down
	iw dev $1 set monitor otherbss fcsfail
	ifconfig $1 up
	iw reg set DE
	iwconfig $1 channel $2
Das wars.
 

just_different

Erfahrener Benutzer
Rangarid, Du hast eben den Orange PI (CN Nachbau) angesprochen.

Der wäre deutlich kostengünstiger als das original, aber soweit ich eben gesehen habe, hat der Orange nicht wie der Raspberry PI, eine Braodcom GPU drauf, sondern eine Mali400 GPU.

Ist denn damit dennoch alles kompatibel?
Wenn, dann müßte der sowohl auf dem TX, wie auch auf dem RX sein, da ja die H265 nur so zu codieren und wieder zu dekodieren ist oder?
Aber wenn ich das richtig gelesen habe, dann könnte man Lubuntu auch um den H265 Codec erweitern und damit weiterhin empfangen, korrekt?

Wenn ich Dich richtig verstanden habe, dann hast Du das deshalb ins Spiel gebracht, weil mit weniger Datenvolumen ja wohl auch andere MCS-Varianten genutzt werden könnten und damit dann weniger Latenz, richtig?
 

Rangarid

Erfahrener Benutzer
Weniger Datenvolumen, kleinere Bitraten, bessere Sensitivität.

Am PC ist das kein Problem, da kann das ganze Softwareseitig dekodiert werden, die Leistung ist ja da. Der Raspi hat aber nicht genug Leistung um das in Echtzeit zu tun, daher braucht man den Hardware De/Encoder, der ja auf dem Orangepi drauf ist.

Frage ist nur, ob es anständige Kameras für den Orangepi gibt. Einen direkten Kameraanschluss hat er jedenfalls, was eine schnelle Kameraansteuerung ermöglichen sollte.

Raspivid wird vermutlich nicht gehen, hab auch keine Ahnung, was da gemacht werden muss, um die Cam ans laufen zu kriegen. Wifibroadcast an sich ist ja systemunabhängig. OSD müsste man anpassen. Muss man ja aber am PC auch.

Letztendlich müsste man also nur kucken, dass eine Cam läuft und das wars.
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten