Snow picture on new repo updates (SOLVED) bitrate issue about wfb-ng HOT 18 CLOSED

I also notice you are now using a different port for the gst-launch port=5602 but it is the same in tx_standalone.sh should I be following the new Setup and installing as a service? Ive been using this for quite a while now and I never had problems til now. I may just reinstall my entire 16.04 drone OS and report back....

from wfb-ng.

Okay did a complete new install on my Nvidia TX1 board and same results snowy picture. Here is my gs-launch command;

I am using a usb v4l capture device with a gopro attached (analog NTSC output) this worked for me in the past with wifbroadcast. Works fine sending video directly to QGC via IP 192.x.x.x:5600

gst-launch-1.0 -vvv -e v4l2src device=/dev/video0 do-timestamp=true norm=NTSC pixel-aspect-ratio=1 ! video/x-raw, format=YUY2, width=720, height=480 ! queue max-size-buffers=0 max-size-time=0 max-size-bytes=0 ! tee name=t ! queue ! videoconvert ! omxh264enc ! video/x-h264, width=720, height=480 ! h264parse ! rtph264pay config-interval=1 ! udpsink host=127.0.0.1 port=5600 t. ! queue ! videoconvert

from wfb-ng.

Tried with Logitech webcam same result. Now I am thinking this is an omxh264enc issue.

gst-launch-1.0 -vvv -e v4l2src device=/dev/video0 ! tee name=t ! queue ! videoconvert ! omxh264enc ! video/x-h264, width=1920, height=1080, framerate=30/1, stream-format=byte-stream ! h264parse ! rtph264pay config-interval=1 ! udpsink host=127.0.0.1 port=5600 t. ! queue ! videoconvert

from wfb-ng.

With release 19.01 config file format was slightly changed:
Peer definition now not in form connect = XXXX or listen = XXXX, but peer = 'connect://' or peer = 'listen://'. This needed to avoid cases when connect and listen keys was both defined.

[gs_mavlink]
peer = 'connect://127.0.0.1:14550'  # outgoing connection
# peer = 'listen://0.0.0.0:14550'   # incoming connection

[gs_video]
peer = 'connect://127.0.0.1:5600'  # outgoing connection for
                                   # video sink (QGroundControl on GS)

[drone_mavlink]
peer = 'listen://0.0.0.0:14550'   # incoming connection
# peer = 'connect://127.0.0.1:14550'  # outgoing connection

[drone_video]
peer = 'listen://0.0.0.0:5600'  # listen for video stream (gstreamer on drone)

from wfb-ng.

Also by default telemetry port on drone was changed from 14550 to 14560. Also video port on drone was changed from 5600 to 5602. To override default settings alter your /etc/wifibroadcast.cfg

from wfb-ng.

See default values in https://github.com/svpcom/wifibroadcast/blob/master/telemetry/conf/master.cfg

from wfb-ng.

Also by default WFB now use 20MHz bandwidth (was 40MHz in previous releases). You can change it back in config file. If your video + telemetry streams doesn't fit into 20MHz (it has effective BW ~ 7MBit/s for both directions in sum because wifi is half-duplex) you can reduce it by specify max h264 bitrate (I use 4Mbit/s for 720p@60fps with RPI video codec) in omxh264enc. See gst-inpect1.0 omxh264enc for reference

from wfb-ng.

Great thanks for all the fantastic tips. Much appreciated. I will report back my findings tonight. Thanks again!

from wfb-ng.

I THINK my issue was the bitrate may have been too high. I will confirm when I can connect a video test stream later tonight.

gst-launch-1.0 -vvv -e v4l2src device=/dev/video0 do-timestamp=true norm=NTSC pixel-aspect-ratio=1 ! video/x-raw, format=YUY2, width=720, height=480 ! tee name=t ! queue ! videoconvert ! omxh264enc bitrate=400000 ! video/x-h264, width=720, height=480 ! h264parse ! rtph264pay config-interval=1 ! udpsink host=127.0.0.1 port=5600 t. ! queue ! videoconvert

from wfb-ng.

It seems that bitrate should be 4000 (in kbps), not 400000

from wfb-ng.

ok thanks again I was going off of a forum topic https://devtalk.nvidia.com/default/topic/973295/jetson-tx1/constant-bitrate-help/

I will reduce to bitrate=4000 and test with video shortly

from wfb-ng.

Okay so did a little conversion and I am thinking in bitrate form 4000000 is correct. Please correct me if I am wrong using this conversion tool:

https://www.gbmb.org/bit-kbit-mbit-gbit

from wfb-ng.

Nevermind you were correct from looking at the cheat sheet it is in kb.

bitrate is specified in kbps. Note that I've changed the size to 640x480. For H.264 (and most other modern codecs) it is advantageous to use width and height that is an integer multiple of 16. There are also many other options that can be used to optimize compression, quality and speed.

http://wiki.oz9aec.net/index.php/Gstreamer_cheat_sheet

from wfb-ng.

Okay this was a bitrate issue marked as solved.

One thing to note is using a bitrate of 4000 was extremely pixelated so I did end up using a much higher bitrate and I think this is due to using nvidia omx hardware codecs:

gst-launch-1.0 -vvv -e v4l2src device=/dev/video0 do-timestamp=true norm=NTSC pixel-aspect-ratio=1 ! video/x-raw, format=YUY2, width=720, height=480 ! tee name=t ! queue ! videoconvert ! omxh264enc bitrate=400000 ! video/x-h264, width=720, height=480 ! h264parse ! rtph264pay config-interval=1 ! udpsink host=127.0.0.1 port=5600 t. ! queue ! videoconvert

from wfb-ng.

another note to add gst-inspect-1.0 omxh264enc;

bitrate : Target bitrate
flags: readable, writable, changeable in NULL, READY, PAUSED or PLAYING state
Unsigned Integer. Range: 0 - 4294967295 Default: 4000000

from wfb-ng.

To increase WFB bandwidth you can use higher MCS scheme (for example 2) and/or switch to 40MHz channel. See http://mcsindex.com. To get effective bandwith divide radio bandwidth value by two. Or use wfb-test-latency program to test bandwith. This requires that TX and RX cards are connected to same machine.

from wfb-ng.

Note, that 40Mhz channel is more sensitive to radio interference than 20MHz.

from wfb-ng.

Awesome! Again thank you @svpcom Much appreciation for your fantastic project and guided support. I will test both 40 and 20 Mhz channels and test bandwidth and sensitivity differences between both.

from wfb-ng.