From 12fc7c3c59ace191a2792ce07ed32756680f82fa Mon Sep 17 00:00:00 2001 From: RoboSchmied Date: Wed, 31 Jan 2024 13:10:31 +0100 Subject: [PATCH 1/5] Update README.md fix grammar and typo --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 4f0d9239..e5be8b12 100644 --- a/README.md +++ b/README.md @@ -122,9 +122,9 @@ If you like WFB-ng you can make a donation to `bitcoin:bc1qfvlsvr0ea7tzzydngq5cf **A:** Any UDP with packet size <= 1445. For example x264 inside RTP or Mavlink. -**Q: What are transmission guarancies?** +**Q: What are transmission guarantees?** -**A:** Wifibrodcast use FEC (forward error correction) which can recover 4 lost packets from 12 packets block with default settings. You can tune it (both TX and RX simultaniuosly!) to fit your needs. +**A:** Wifibrodcast uses FEC (forward error correction) which can recover 4 lost packets from 12 packets block with default settings. You can tune it (both TX and RX simultaniuosly!) to fit your needs. **Q: Is only Raspberry PI supported?** From 7973ac817956cf4aba72d040bdae98b250b4ced6 Mon Sep 17 00:00:00 2001 From: RoboSchmied Date: Wed, 31 Jan 2024 13:30:00 +0100 Subject: [PATCH 2/5] Update README.md fix typo and grammar --- README.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index e5be8b12..f7bf9824 100644 --- a/README.md +++ b/README.md @@ -124,15 +124,15 @@ If you like WFB-ng you can make a donation to `bitcoin:bc1qfvlsvr0ea7tzzydngq5cf **Q: What are transmission guarantees?** -**A:** Wifibrodcast uses FEC (forward error correction) which can recover 4 lost packets from 12 packets block with default settings. You can tune it (both TX and RX simultaniuosly!) to fit your needs. +**A:** Wifibrodcast uses FEC (forward error correction) which can recover 4 lost packets from 12 packets block with default settings. You can tune it (both TX and RX simultaneously!) to fit your needs. **Q: Is only Raspberry PI supported?** -**A:** WFB-NG is not tied to any GPU - it operates with UDP packets. But to get RTP stream you need a video encoder (with encode raw data from camera to x264 stream). In my case RPI is only used for video encoding (becase RPI Zero is too slow to do anything else) and all other tasks (including WFB-NG) are done by other board (NanoPI NEO2). +**A:** WFB-NG is not tied to any GPU - it operates with UDP packets. But to get RTP stream you need a video encoder (with encodes raw data from camera to x264 stream). In my case RPI is only used for video encoding (becase RPI Zero is too slow to do anything else) and all other tasks (including WFB-NG) are done by other board (NanoPI NEO2). **Q: What is a difference from original wifibroadcast?** -**A:** Original version of wifibroadcast use a byte-stream as input and splits it to packets of fixed size (1024 by default). If radio packet was lost and this is not corrected by FEC you'll got a hole at random (unexpected) place of stream. This is especially bad if data protocol is not resistent to (was not desired for) such random erasures. So i've rewritten it to use UDP as data source and pack one source UDP packet into one radio packet. Radio packets now have variable size depends on payload size. This reduces video latency a lot. +**A:** Original version of wifibroadcast uses a byte-stream as input and splits it to packets of fixed size (1024 by default). If radio packet was lost and this is not corrected by FEC you'll got a hole at random (unexpected) place of stream. This is especially bad if data protocol is not resistant to (was not desired for) such random erasures. So i've rewritten it to use UDP as data source and pack one source UDP packet into one radio packet. Radio packets now have variable size depending on payload size. This reduces video latency a lot. ## Theory WFB-NG puts the wifi cards into monitor mode. This mode allows to send and receive arbitrary packets without association and waiting for ACK packets. @@ -145,7 +145,7 @@ Sample usage chain: Camera -> gstreamer --[RTP stream (UDP)]--> wfb_tx --//--[ RADIO ]--//--> wfb_rx --[RTP stream (UDP)]--> gstreamer --> Display ``` -For encode logitech c920 camera: +For encoding logitech c920 camera: ``` gst-launch-1.0 uvch264src device=/dev/video0 initial-bitrate=6000000 average-bitrate=6000000 iframe-period=1000 name=src auto-start=true \ src.vidsrc ! queue ! video/x-h264,width=1920,height=1080,framerate=30/1 ! h264parse ! rtph264pay ! udpsink host=localhost port=5600 From 53c704175def0252d2b4671a5979b8aa262237ca Mon Sep 17 00:00:00 2001 From: RoboSchmied Date: Wed, 31 Jan 2024 13:46:32 +0100 Subject: [PATCH 3/5] Update README.md grammar and typo --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index f7bf9824..e5b41c59 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ Main features: - 1:1 map of RTP to IEEE80211 packets for minimum latency (doesn't serialize to byte steam) - Smart FEC support (immediately yeild packet to video decoder if FEC pipeline without gaps) - [Bidirectional mavlink telemetry](https://github.com/svpcom/wfb-ng/wiki/Setup-HOWTO). You can use it for mavlink up/down and video down link. - - IP-over-WFB tunnel support. You can transmit ordinary ip packets over WFB link. Note, don't use ip tunnel for high-bandwidth transfers like video or mavlink. It use less efficient FEC coding and doesn't aggregate small packets. + - IP-over-WFB tunnel support. You can transmit ordinary ip packets over WFB link. Note, don't use ip tunnel for high-bandwidth transfers like video or mavlink. It uses less efficient FEC coding and doesn't aggregate small packets. - Automatic TX diversity (select TX card based on RX RSSI) - Stream encryption and authentication ([libsodium](https://download.libsodium.org/doc/)) - Distributed operation. It can gather data from cards on different hosts. So you don't limited to bandwidth of single USB bus. From 248b8b1188a44191c6d4e83cee9925b400163705 Mon Sep 17 00:00:00 2001 From: RoboSchmied Date: Wed, 31 Jan 2024 13:55:04 +0100 Subject: [PATCH 4/5] Update README.md fix grammar --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index e5b41c59..4ce5e5be 100644 --- a/README.md +++ b/README.md @@ -128,11 +128,11 @@ If you like WFB-ng you can make a donation to `bitcoin:bc1qfvlsvr0ea7tzzydngq5cf **Q: Is only Raspberry PI supported?** -**A:** WFB-NG is not tied to any GPU - it operates with UDP packets. But to get RTP stream you need a video encoder (with encodes raw data from camera to x264 stream). In my case RPI is only used for video encoding (becase RPI Zero is too slow to do anything else) and all other tasks (including WFB-NG) are done by other board (NanoPI NEO2). +**A:** WFB-NG is not tied to any GPU - it operates with UDP packets. But to get RTP stream you need a video encoder (which encodes raw data from camera to x264 stream). In my case RPI is only used for video encoding (becase RPI Zero is too slow to do anything else) and all other tasks (including WFB-NG) are done by other board (NanoPI NEO2). **Q: What is a difference from original wifibroadcast?** -**A:** Original version of wifibroadcast uses a byte-stream as input and splits it to packets of fixed size (1024 by default). If radio packet was lost and this is not corrected by FEC you'll got a hole at random (unexpected) place of stream. This is especially bad if data protocol is not resistant to (was not desired for) such random erasures. So i've rewritten it to use UDP as data source and pack one source UDP packet into one radio packet. Radio packets now have variable size depending on payload size. This reduces video latency a lot. +**A:** Original version of wifibroadcast uses a byte-stream as input and splits it to packets of fixed size (1024 by default). If radio packets were lost and this is not corrected by FEC you'll got a hole at random (unexpected) place of stream. This is especially bad if data protocol is not resistant to (was not desired for) such random erasures. So i've rewritten it to use UDP as data source and pack one source UDP packet into one radio packet. Radio packets now have variable size depending on payload size. This reduces video latency a lot. ## Theory WFB-NG puts the wifi cards into monitor mode. This mode allows to send and receive arbitrary packets without association and waiting for ACK packets. From afde0fba7ae0412421a0257201783c89255556d2 Mon Sep 17 00:00:00 2001 From: RoboSchmied Date: Wed, 31 Jan 2024 14:51:55 +0100 Subject: [PATCH 5/5] Update README.md got -> get --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 4ce5e5be..182a165a 100644 --- a/README.md +++ b/README.md @@ -132,7 +132,7 @@ If you like WFB-ng you can make a donation to `bitcoin:bc1qfvlsvr0ea7tzzydngq5cf **Q: What is a difference from original wifibroadcast?** -**A:** Original version of wifibroadcast uses a byte-stream as input and splits it to packets of fixed size (1024 by default). If radio packets were lost and this is not corrected by FEC you'll got a hole at random (unexpected) place of stream. This is especially bad if data protocol is not resistant to (was not desired for) such random erasures. So i've rewritten it to use UDP as data source and pack one source UDP packet into one radio packet. Radio packets now have variable size depending on payload size. This reduces video latency a lot. +**A:** Original version of wifibroadcast uses a byte-stream as input and splits it to packets of fixed size (1024 by default). If radio packets were lost and this is not corrected by FEC you'll get a hole at random (unexpected) place of stream. This is especially bad if data protocol is not resistant to (was not desired for) such random erasures. So i've rewritten it to use UDP as data source and pack one source UDP packet into one radio packet. Radio packets now have variable size depending on payload size. This reduces video latency a lot. ## Theory WFB-NG puts the wifi cards into monitor mode. This mode allows to send and receive arbitrary packets without association and waiting for ACK packets.