- Gstreamer on the receiving end has terrible latency, DO NOT USE
- Mplayer works great
- Mplayer -nocache cuts 28ms
best fec settings -b 8 and -r 16 using 24M rate = basically indestructible video feed: -80 db is maximum reliable video feed signal so far
using -b 8 -r 4 -75db max
b = Number of data packets in a block
r = Number fec packets per block
f = Number of bytes per packet
In latest raspbian need to use -t 9999999 to keep raspivid going
Raspivid supports mjpeg with (after raspi-update): raspivid -cd MJPEG after this commit there was no change in version number before and after. Can't find it it repositories.
Discussion on MJPEG: https://www.raspberrypi.org/forums/viewtopic.php?t=66259&p=487121
Raspi Cams are fussier than the actual raspi itself when it comes to voltage levels, 5v should be considered the minimum.
MJPEG Encoding mode has a strange tendency to ramp up in bitrate over a few seconds. Actual bandwidth requirements should be tested after waiting 10 seconds or so.
Ways of reducing buffering and ideas for settings to try here in comments
try
-if cyclicrows
instead of
-ih
IDEA: It may be possible to steam the raw v4l output over the radio and use a in input in gstreamer using
v4l2src device=/dev/video1
v4l2src device=/dev/stdin
1296x730 is the actual binned resolution for 720p, if you want more pixels, try that.
Gstreamer Videosinks:
- glimagesink
- xvimagesink
- autovideosink
- fpsdisplaysink
enable with
sudo modprobe bcm2835-v4l2
run with
v4l2-ctl -p 90
v4l2-ctl --set-fmt-video=width=640,height=480,pixelformat=H264
v4l2-ctl --stream-mmap=3 --stream-to=/dev/stdout
so far for h264 at least v4l seems much faster (less intermediary buffering?)
with default makefile - these settings use ~57% cpu
with modified makefile (add O2) - these settings use ~46% cpu
##Wifi Frequencies Flysky frequency range - 2.4055GHz to 2.475GHz
wifi channel 2484 MHz [14] is the only one outside this range
on RT5572's only works in 24M mode
only usable in japan
many wifi radios no longer support this frequency (for good reason)
(on a RT5572)
54M max: 2730
24M max: ~2100
Idea: Have a very low bitrate heavily FEC'd secondary stream to show in case of main stream corruption.
Should be first data in packet to reduce chance lost
Seems to be therorically possible
- raspivid (mjpeg) -> gstreamer = 127ms, 128ms
- raspivid (h264) -> gstreamer = 255ms
- raspivid (h264) -> mplayer = 170ms, 170ms
- raspivid (h264) -> mplayer (-nocache) = 128ms, 127ms
- raspivid (h264 baseline) -> gstreamer = 255ms (averaged x2)
- raspivid (h264 just high prfile) -> gstreamer = 298ms
- raspivid (h264 -if cyclicrows) -> gstreamer = 298ms
- raspivid (h264 -if cyclicrows and -g 5) -> gstreamer = 298ms
- raspivid (default everything benifit) -> gstreamer = 383ms
- v4l direct (h264) -> gstreamer = 300ms
Things that made no difference:
- r values between 4 and 16
- need to find 5ghz wifi dongles with antennas good candidate
- does -ex fixedfps improve feel of video?
- think about implementation of syncronised wifi channel hopping (how long does it take to switch channels, and how long does it take to get packets after switching)
- test: ffplay -fflags nobuffer and read this
- play with -f option
- test viability of 5.8ghz