Low Cost HD-Video Übertragung + Telemetrie

Status
Nicht offen für weitere Antworten.
#61
Bei MCast gibt es ja eben genau keinen Buffer.

Halte ich ja mal für ein ziemliches Gerücht.

http://www.juniper.net/techpubs/en_US/junos10.4/topics/concept/multicast-uses.html

With unicast traffic, many streams of IP packets that travel across networks flow from a single source, such as a Web site server, to a single destination such as a client PC. This is still the most common form of information transfer on networks.

Broadcast traffic flows from a single source to all possible destinations reachable on the network, which is usually a LAN. Broadcasting is the easiest way to make sure traffic reaches its destinations.

Television networks use broadcasting to distribute video and audio. Even if the television network is a cable television (CATV) system, the source signal reaches all possible destinations, which is the main reason that some channels' content is scrambled. Broadcasting is not feasible on the public Internet because of the enormous amount of unnecessary information that would constantly arrive at each end user's device, the complexities and impact of scrambling, and related privacy issues.

Multicast traffic lies between the extremes of unicast (one source, one destination) and broadcast (one source, all destinations). Multicast is a “one source, many destinations” method of traffic distribution, meaning only the destinations that explicitly indicate their need to receive the information from a particular source receive the traffic stream.

On an IP network, because destinations (clients) do not often communicate directly with sources (servers), the routers between source and destination must be able to determine the topology of the network from the unicast or multicast perspective to avoid routing traffic haphazardly. Multicast routers replicate packets received on one input interface and send the copies out on multiple output interfaces.

In IP multicast, the source and destination are almost always hosts and not routers. Multicast routers distribute the multicast traffic across the network from source to destinations. The multicast router must find multicast sources on the network, send out copies of packets on several interfaces, prevent routing loops, connect interested destinations with the proper source, and keep the flow of unwanted packets to a minimum. Standard multicast routing protocols provide most of these capabilities, but some router architectures cannot send multiple copies of packets and so do not support multicasting directly.

http://forum.golem.de/kommentare/in...t-vs.-unicast/72136,3311194,3311194,read.html

http://www.haveyouherd.com/pg43.cfm

http://security.americandynamics.ne...mission-vs-Unicast-video-transmission-methods

http://forums.anandtech.com/showthread.php?t=1277407

Und da sind wir wieder, da W-LAN Hardware halb duplex ist und sich nicht wesentlich anders verhält wie ein Hub, würde ich von Multicast mal die Finger lassen.

Zu mal ich den Sinn von mehrern Listeners bei FPV nicht sehe.
 
Zuletzt bearbeitet:

aargau

Erfahrener Benutzer
#62
Es geht ja nicht um mehrere Listeners, sondern das keine Antworten gesendet werden. Okay das selbe passiert bei UDP auch ;) Aber ein unverschlüsseltes wlan z.B. würde demit helfen die FPV Brille und ein Monitor gleichzeitig ohne zusätzliche Last zu Empfangen. Das ganze war auch nur eher ein Beispiel. dass Wlan durchaus in der Lage ist ohne grosse Verzögerung einen Videostream zu übertragen.

Aber back2topic:
Ich habe gerade mal etwas experimentiert. Streaming über 3G wäre keine schwierige sache auch nicht hinter NAT.
Nat2Nat lässt sich ziemlich simpel lösen:
Client schicht an einen Server ein UDP Paket über Port xyz. Server schickt die IP und den Port an den Streamer und der wiederherum sendet die Daten einfach direkt an die IP vom Empfänger und schwupps kommen die Daten da an.
Habe das jetzt mal kurz von zuhause auf einen meiner Server getestet und klappt wunderbar.

Ev. könnte man also eine ultralow Stream über 3G noch einbauen oder dann zumindest mal testen. Es braucht zwar einen Server, aber da würde dann ja einer für alle schon reichen ;)
 
#63
Woah, 170 ms das ist echt schon gut!
Hast du mal geschaut wieviel Verzögerung vom Client verursacht wird? Ich könnte mir gut vorstellen, dass ein großer Teil durch deinen Laptop verursacht wird.
 
#66
Den Latenzanteil des Laptops zu messen ist glaub nicht so einfach. Besonders unter Windows. Hast du Linux auf deinem Rechner? Dann könntest du mal schauen ob dort die Latenz anders ist.
Oder hast du ein zweites Pi? Dann könntest du versuchen es dort abzuspielen. Wichtig ist dabei, dass das Decoding auf der GPU ausgeführt wird. Sonst geht das Pi in die Knie. ;)
ich hab gerade gesehen, dass auf deinem Profilbilder der Vierzylinder drauf ist .. bist du auch aus München?

Edit: gerade noch gefunden
http://diydrones.com/profiles/blog/...t:1433488&xg_source=activity&page=18#comments
Comment by Pod on February 17, 2014 at 4:04pm
I see your 200ms and I raise you a 180ms:
Transmit side:
raspivid -n -w 1280 -h 720 -b 1000000 -fps 30 -vf -hf -t 0 -pf high -o - | gst-launch-1.0 -v fdsrc ! h264parse ! rtph264pay ! udpsink host=192.168.0.14 port=9000
Receive side:
gst-launch-1.0 udpsrc port=9000 caps='application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264' ! rtph264depay ! h264parse ! omxh264dec ! videoconvert ! queue max-size-time=100 ! eglglessink sync=false

(Needs "deb http://vontaene.de/raspbian-updates/ . main" added to /etc/apt/sources, and sudo apt-get install gstreamer-tools-1.0 gstreamer1.0-omx gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad)


Verwendest du die selbe Pipeline? 180 ms scheint so das Limit zu sein.
 
Zuletzt bearbeitet:
#67
http://www.globe-flight.de/DJI-Lightbridge-24-Ghz-Full-HD-Videouebertragung

Das DJI Lightbridge-System bietet digitale Videoübertragung mit 1920x1080 bei 30fps und einer Latenz von weniger als 80ms.

Na dann fehlen ja nur noch 90ms

http://www.raspberrypi.org/forums/viewtopic.php?f=43&t=45793

http://stackoverflow.com/questions/20921541/raspberry-pi-mjpg-streamer-low-latency

I think I have found from experimentation that the camera board does most of the processing relieveing the raspi from much load at all. You can see this by running top on the pi as it captures and streams.

First I run the following on a linux client:

nc -l -p 5001 | mplayer -fps 31 -cache 512 -

Then I run the following on the raspi:

/opt/vc/bin/raspivid -t 999999 -o -w 1920 -h 1080 - | nc 192.168.1.__ 5001

This was done over an ethernet connection from raspi to linux desktop both connected to a common ethernet hub.

I have made the following observations:

these settings give me a pretty low lag (<100ms)
increasing the cache size (on the client) only leads to a larger lag, since the client will buffer more of the stream before it starts
decreasing the cache size below some lower limit (512 for me) leads to a player error: "Cannot seek backward in linear streams!"
specifying dimensions less than the default 1920x1080 leads to longer delays for smaller dimensions especially when they are less than 640x480
specifying bitrates other than the default leads to longer delays
I'm not sure what the default bitrate is
for any of the scenarios that cause lag, it seems that the lag decreases gradually over time and most configurations I tried seemed to have practically no lag after a minute or so

It's unfortunate that very little technical information seems to be available on the board apart from what commands to run to make it operate. Any more input in the comments or edits to this answer would be appreciated.

HDMI IN:

http://www.geeky-gadgets.com/raspberry-pi-hdmi-input-allows-hd-recording-video-14-03-2014/

https://www.kickstarter.com/project...ur-hd-camcorder-to-your-raspberry-pi?ref=live

http://raspberry-hardware.com/hdmi-eingang-board-fuer-den-raspberry-pi/

At this point of time it is not possible to get the video from an HDMI input via the CSI interface into the Raspberry Pi. Unfortunately the Raspberry Pi is not architected for such an application.

So I would like to ask you, to stop pledging for this project. If things change and I find a way to get around this show stopping issue (possibly in a year from now), I will reconsider this project and I might restart it again.

If you are still interested in getting video into the Raspberry Pi short term, I have a couple of plan B proposals for you.


Von einem Problem zum Nächsten ... dass mit dem 3G / 4G halte ich mal jetzt fürn verspäteten Aprilscherz , wäre zwar voll duplex aber ....
 
Zuletzt bearbeitet:

Lonestar78

Erfahrener Benutzer
#68
@timoski: Ja genau das ist die Pipeline, die ich verwende. Aus München bin ich nicht (Mannheim), da war ich nur zum fliegen :)


@MBR89: Zum Thema Lightbridge 80ms: Siehe erster Post. Da ist es deutlich mehr.
Ich glaube ja sogar, dass die Lightbridge schon 80ms bringt. Aber es geht hier um Glas to Glas Latency. Und da ist das Problem durchaus auch die Latency, die die Cams mit HDMI out schon von alleine mitbringen...ich hab da für die GoPro sowas von 100ms im Kopf, mag mich da aber irren.
Unsere 170/180ms sind Glas to Glas....
Die Netcat-Variante werde ich auf jeden Fall testen...
 
Zuletzt bearbeitet:

d3frost

bsst jetzt nix mehr Licht
#69
wie Du bist aus Mannheim ..... Lonestar , wo fliegst Du denn ?

Könnte man sich Dein Proto ja mal fast Live anschauen :)
 

Lonestar78

Erfahrener Benutzer
#72
Kleines update zu Netcat: bringt mich von der Latenz nicht weiter, bestes ergebnis so um die 160ms aufwärts.
Bei stabilem Lauf um die 180ms
Subjektiv ist die Latenz etwas schwankender als bei GStreamer.

Raspberry:
raspivid -n -w 1920 -h 1080 -b 8000000 -fps 30 -vf -hf -t 0 -o - | nc 192.168.137.1 5001

Windows (netcat und MPlayer):
nc.exe -l -p 5001 | mplayer.exe -fps 120 -cache 512 -

Die fps 120 habe ich, damit der Player schnellstmöglich den Buffer aufholt. Das klappt gut.

Auflösung und Bandbreite ändern nichts daran.
 

muerzi

Erfahrener Benutzer
#74
Das wird dir zum jetzigen zeitpunkt niemand beantworten können. Aus sicherheitsgründen würd ich das aber nicht machen. Lieber wenige/keine eingriffe in die steuerung des modells
 

Lonestar78

Erfahrener Benutzer
#75
Ich persönlich glaube auch, dafür ist es viel zu früh.
Ich denke im moment nichtmal darüber nach, den WLAN link uach als Steuersignalträger zu nutzen.
Verlockend, aber mir zu gefährlich.
Ein volles linux ist mir zu komplex, da kenne ich mich einfach nicht gut genug aus, um das bullet proof zu machen.
 

Lonestar78

Erfahrener Benutzer
#77
Mini Update:
Meine WLAN Module (Ubiquiti rocket M5) sind jetzt komplett, hatte noch CP Antennen bestellt, 2x Cloverleaf und 2x Skew Planar Wheel. Jetzt fehlen noch die Anschlusskabel um per PoE Energie in die WLAN-Module zu bringen.
Dann gibts vieleicht nächste Woche einen ersten Range-Test...

ansonsten ist das hier interessant:
https://github.com/thaytan/gst-rpicamsrc

ein GStreamer Wrapper für raspivid.
Damit lässt sich vieleicht eine dynamische Pipe mit variabler Bitrate, abhängig vom WLAN RSSI basteln...mals sehen.
 

Lonestar78

Erfahrener Benutzer
#78
So wieder ein kleiner Schritt in die richtige Richtung: Dat ganze tut jetzt über die WLAN-Module.
Ping 1-3ms.
Gesamtlatenz steigt nur unmerklich im Rahmen der Messgenauigkeit:
AirbornePiHD_WLAN_1stTest.jpg

Heisst: Latenz so um die 170-180ms :)
Ich glaube mehr ist mit dem Pi nicht ohne weiteres rauszuholen.
 

nique

Legal-LongRanger
#79
Hey Lonestar

Warum eigentlich die Ubiquiti rocket M5? Haste noch andere in die Überlegungen einbezogen? Wie machste das mit der Stromversorgung aufm Flieger? Verbaust Du die mit Gehäuse oder allenfalls offen? Was würde die GPS-Version noch bringen?
 
Status
Nicht offen für weitere Antworten.
FPV1

Banggood

Oben Unten