Hi, @craig ,
this is a really good test, one of the most important ones, that I could analyze and I’ve some thoughts to share here. Thanks a lot for testing and sharing!
Just a quick question, was WiFi set to 2.4Ghz or to 5ghz?
-
In the office at the first half, stream was good, becuase wifi Mesh network coverage was quite good I noticed at one of the corners Z1 lost connection to actual router BUT it switched to the next one. This is very important. This camera is the only 360 device that I’m aware of which can switch between WiFi routers without loosing connection (I tested this with Qoocam 8k Enterprise version and it just can’t switch between routers while streaming). Clearly some frames were dropped, but if the WiFi mesh network is properly set, it can provide seamless/fast roaming without loosing connection. However 20mbps is a bit too much, it requires WiFi mesh routers to be placed closer to each other, the best is if bitrate is set to ~16mbps in this scenario, also instead of VBR, for live streaming CBR is much better, also I think there was a small 200-300ms video audio sync delay noticeable. while for recording video VBR is preferred. Switching between routers happens faster if CBR is set. For now on flow.tours configuration page I allow all these settings, once I collect more data, I will add some notices and suggestions to UI directly.
-
When you left the office space, there were coverage issues, this could be minimized if at the WiFi mesh network “beamforming” feature would be turned on and also a “prioritization” would be given to your Z1 device. Second, if 2.4ghz WiFi is used it provides longer distance coverage, however lowering a bit bitrate to 14-16mbps provides better coverage in space, less frames would be dropped, less interruptions. In some scenarios 5ghz provides better coverage, that depends on WiFi network too, which one is “better”, so you have to try and test before doing a “real” live streaming event.
-
After you left the office, you were on first floor walking a garden was visible outside, you walked toward stairway to go down, there was a bigger interruption behind the wall, I think at that point you were also not sure if it will work further. You were right, there connection was lost, it couldn’t switch to any other proper network, so it went to “sleep” for 0.5seconds and the plugin retried, again it failed to connect, and was waiting another 1 second to try again, and again for another 2 seconds, so viewers lost probably 4-5 seconds all together, but it started to stream again just fine in the garden.
Clearly the best is to use WiFi mesh network to cover bigger area, to walk around, routers should be put a bit closer to each other than usually to satisfy high and stable upload speed requirement. I’m doing some additional tests to find the best settings for these scenarios, like to set buffer size to lower number and also to increase max buffer items (frames) to keep in internal RAM if needed a bit longer to set to 400-600 (default is 200). Also experimenting to see effect of “send buffer size” to lower value, like 65000 bytes. If this is too high it can try to send to big packets from z1 toward router and to youTube, which can be a problem as it’s harder to switch to another WiFi router fast enough…
Earlier I spent building a cool machine, RAspberry Pi 4, with my own customized WiFi network driver. I used Raspberry Pi4 was a WiFi extender/repeater. It was using it’s WLAN card to connect to WiFi mesh network and I really optimized to switch over faster to the closest router and also used a detachable antenna to extend range. By default these “drivers” are not optimized for live streaming use case, but to get the maximum bandwidth. For us, “live streamers” it was more important to keep a stable bandwidth 16-18mbps and even if that speed is still available, but there is a closer router to initiate switch over. Usually “switch” happened too late, causing much more frames lost. The default WPA_Supplicant on Ubuntu wasn’t good at all with handling switch over, so I took IWD iNet Wireless Daemon, which is maintained by Intel and designed to offer better efficiency. Any way as it’s open source, I modified it’s code a bit for these use cases. Also Z1 was connecting to the same Raspberry Pi 4 on a secondary WiFi WLAN card in Pi. At the end I’m not using that device for now. I’m planning to extend it with a 4g or 5g mobile network connection, so it could work from a battery and with a detachable antenna could double mobile connection to 4g networks. As 5g cards cost is really high for raspberry pi, I think 4g would be better. Also regarding speed indoor, it’s faset enough and usually the signal strength is bigger issue than limitations of 4g speed. 4g provides for me 20mbps upload and lot of cases even more than needed.
Now if we talk about flow.tours as platform, all above settings we can almost forget, as we can get the same quality if bitrate is set to 12mbps in case og HEVC/h.265. This is a huge difference, even if we compare with 16mbps/H.264. Switching over to another router with 12mbps is much easier, faster, etc. operation range of routers is also better, you can walk longer distances too without interruption.
Also another point, imagine doing the same live streaming toward flow.tours with 1-2 second latency only and same quality… Also hearing your viewers at the same time directly using earplugs, or you to speak to the same earplug microphone instead of z1 inbuilt microphone and audio would be synced and combined to stream on flow.tours on the fly.
Thanks for testing, Craig, I would give you a huge heart, but no size options on this forum for that! 
