Blue Iris losing RTSP connection to WyzeCam V2

[ark-git]

I was able to connect to Blue Iris using RTSP. However after sometime it will lose connection and the only way to connect back to Blue Iris is to reboot. I also verified its not Blue Iris since it doesn't work with VLC also.

[mchipser]

I did, if your talking about the RTSP keep alive..

[paumove]

Same behavior with a Xiafang 1S using uboot, last kernel and rootfs.

I can connect through VLC, but after some minutes (random) the image gets freezed (but not disconnected). I still can connect to the web. If I stop the VLC and start it again, the image becomes correct again until the same problem reoccurs.

Maybe the same problem reported in #595 and #566 ??

[ark-git]

@nik0 The Connection to Blue Iris still drops every few seconds and recovers. I noticed that the fps is around 1 or 2 even though I have set it to 10fps. The resolution is 1280x720. I have installed the new boot loader, full HD is working with the same dropped connections. I still think there is an issue with the rtsp server. Looks like a few connection request in the logs. The drop connection is an issue since Blue Iris wont trigger the recording if the connections keeps on dropping.

[ark-git]

@nik0 Logs below rtspsever.log

[nik0]

What do you have in dmesg? Blue iris is a remote client right ? What about local network with VLC ?

[ark-git]

Blue Iris is a DVR software. Yesterday I got it to work with the following settings (15fps, 2000kbps Bit rate, 1920x1080). Today, however the drop signals is happening again. Logs attached. I see a lot of errors in the dmesg.log file. dmesg.log rtspsever.log

[nik0]

The dmesg errors seems to come from the beginning of the bootup. So it should not be related (even if they are weird ...)

• can you try without audio (-A option)
• and with more traces: -vv (tons of logs ...)

[ark-git]

See attached logs. I think there might be an issue with Bit rate, since when I set it to 2000kbps, I still see it more than 2Mbps on Blue Iris. Initially by default the bit rate was 5Mbps so the drop out rate was really bad. I am not sure the "-vv" option worked since there are not much additional logs dmesg.log rtspsever.log

[nik0]

Sorry the verbose option is not working ... When you restart the camera the FPS is not set ?

[ark-git]

After a restart the Log says "Attempt to changed fps to 15,1", however when I view the fps in blue iris its coming at around 2-4fps, then it goes to zero, stays at zero for a few seconds then recovers to about 3fps,then repeats itself.

[nik0]

check with VLC but for me it is working the fps is correct (go in tools/codec info/codec tab) I guess blue Iris is not happy of something, stream rate going down and just want to reconnect. Do you have another camera and it is working ? I'll try to install it

[ark-git]

could you provide the correct path for "tools/codec info/codec tab". Thanks

[nik0]

Sorry my VLC is in french. There is a menu "tools" and then "codec information" or something like that

I installed blue Iris, it seems that, indeed, the connection is dropped when the bitrate is too high (25 images per seconds, with a bitrate of 2000 , resution 1920*1080 with smart codec seem to be stable

[ark-git]

See picture below

[nik0]

So the frame rate is correctly set ... In the "statistics" tab you will have the bitrate

[ark-git]

[ark-git]

I am trying now with "SMART" Video Format with a bit rate of 2000kbps

[ark-git]

Still have a lot of "No Signal". I will try and install the other camera outside.

[nik0]

reduce again the bitrate ... do you have a good wifi connection ?

[ark-git]

I took the camera from outside and brought it indoors and its next to the wifi router and now I have a constant fps of around 15.

So it looks like its the wifi connection that is causing the drop. I took the other camera and placed it outside in now that camera is losing fps. The camera is just outside the room with the wifi router. Is there a took using ssh to measure the wifi status?

[nik0]

Maybe something like this: https://linhost.info/2013/10/download-test-files/

Le dim. 29 juil. 2018 à 22:31, ark-git notifications@github.com a écrit :

I took the camera from outside and brought it indoors and its next to the wifi router and now I have a constant fps of around 15.

[image: image] https://user-images.githubusercontent.com/39158479/43370406-81065626-934c-11e8-815f-9e6936f386ec.png So it looks like its the wifi connection that is causing the drop. I took the other camera and placed it outside in now that camera is losing fps. The camera is just outside the room with the wifi router. Is there a took using ssh to measure the wifi status?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/EliasKotlyar/Xiaomi-Dafang-Hacks/issues/351#issuecomment-408703813, or mute the thread https://github.com/notifications/unsubscribe-auth/ABx_hltj6Uwm8BvOyty1VnqngnSFSpb_ks5uLhuagaJpZM4T8jmo .

[ark-git]

I ran two test and both of them completed, however it does not report the speed. The screenshot below shows that there were 9930 drop packets.

[nik0]

try with curl --output /dev/null http://cachefly.cachefly.net/100mb.test

[ark-git]

Speed is around 4.2Mbps. Connection looks to be very good.

[Dopeyr]

@ark-git From the UI, Manage -> Network information gives you some stats too, e.g.

wlan0     IEEE 802.11bgn  ESSID:"XX"  Nickname:""
          Mode:Managed  Frequency:2.462 GHz  Access Point: 4C:09:D4:16:XX:XX   
 ---> Bit Rate:72.2 Mb/s   Sensitivity:0/0
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
 --->  Link Quality=85/100  Signal level=100/100  Noise level=0/100
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

I'm not sure how useful/accurate they are, but might be interesting to see what you see, especially when run inside vs outside the room you speak of.

I guess the other thing re: speed test is it's the upload speed that needs testing rather than download, as video is sent out of the camera.

[ark-git]

Network Stats from the UI below. I placed the other camera about 11 feet away from the router and its fps does fluctuate up and down as displayed in the Blue Iris camera properties window. One thing I did yesterday and reading through forums is that I changed the Router Bandwidth from 20/40MHz to always be 20MHz, not sure if that would help, however still missing frames. The video stream would skip about from 10 to 20seconds.

wlan0 IEEE 802.11bgn ESSID:"" Nickname:"" Mode:Managed Frequency:2.452 GHz Access Point:
Bit Rate:72.2 Mb/s Sensitivity:0/0
Retry:off RTS thr:off Fragment thr:off Encryption key:------- Security mode:open Power Management:off Link Quality=78/100 Signal level=100/100 Noise level=0/100 Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 Tx excessive retries:0 Invalid misc:0 Missed beacon:0

[ark-git]

I am not sure whether "iperf " tests the upload or download speed I have a ubuntu server and I ran iperf -s -B Server IP

On the Camera ssh I ran the following iperf -c Server IP -d -t 60 -i 10 Server Ip [ 5] 0.0-10.0 sec 23.1 MBytes 19.4 Mbits/sec [ 3] 0.0-10.0 sec 20.3 MBytes 17.0 Mbits/sec [ 5] 10.0-20.0 sec 22.7 MBytes 19.1 Mbits/sec [ 3] 10.0-20.0 sec 21.9 MBytes 18.4 Mbits/sec [ 5] 20.0-30.0 sec 23.8 MBytes 20.0 Mbits/sec [ 3] 20.0-30.0 sec 22.5 MBytes 18.8 Mbits/sec [ 3] 30.0-40.0 sec 22.2 MBytes 18.6 Mbits/sec [ 5] 30.0-40.0 sec 22.8 MBytes 19.2 Mbits/sec [ 5] 40.0-50.0 sec 23.1 MBytes 19.3 Mbits/sec [ 3] 40.0-50.0 sec 21.7 MBytes 18.2 Mbits/sec [ 3] 50.0-60.0 sec 21.3 MBytes 17.8 Mbits/sec [ 3] 0.0-60.0 sec 130 MBytes 18.1 Mbits/sec [ 5] 50.0-60.0 sec 21.8 MBytes 18.3 Mbits/sec [ 5] 0.0-60.5 sec 139 MBytes 19.3 Mbits/sec

The results below is from the Camera thats in the same room as the router [ 4] 0.0-10.0 sec 19.4 MBytes 16.3 Mbits/sec [ 5] 0.0-10.0 sec 25.2 MBytes 21.2 Mbits/sec [ 4] 10.0-20.0 sec 22.0 MBytes 18.5 Mbits/sec [ 5] 10.0-20.0 sec 21.4 MBytes 17.9 Mbits/sec [ 5] 20.0-30.0 sec 21.0 MBytes 17.6 Mbits/sec [ 4] 20.0-30.0 sec 22.2 MBytes 18.6 Mbits/sec [ 4] 30.0-40.0 sec 21.1 MBytes 17.7 Mbits/sec [ 5] 30.0-40.0 sec 22.4 MBytes 18.8 Mbits/sec [ 5] 40.0-50.0 sec 22.4 MBytes 18.8 Mbits/sec [ 4] 40.0-50.0 sec 21.4 MBytes 17.9 Mbits/sec [ 5] 50.0-60.0 sec 22.7 MBytes 19.0 Mbits/sec [ 4] 50.0-60.0 sec 21.9 MBytes 18.4 Mbits/sec [ 4] 0.0-60.0 sec 128 MBytes 17.9 Mbits/sec [ 5] 0.0-60.5 sec 137 MBytes 19.0 Mbits/sec

[nik0]

And another thing: what about CPU usage on the camera when streaming 25fps bitrate > to 2000 ?

[ark-git]

I set the FPS to 15, bit rate of 2000kbps for both cameras

Outside Camera

Inside Camera

[nik0]

Well, this is not the CPU ...

[ark-git]

How do I get CPU usage?

[nik0]

You did it with "top" %CPU column ...

[ark-git]

I misinterpreted your comment. I thought it was not the correct CPU usage, but it was a statement that the the CPU is not that cause of the issue. Any idea why in the inside camera the "lighttpd.bin" process is zero while on the outside camera its 26.6%. There is also the process "[ksdioirqd/mmc1]" that is showing 6.6% on the outside Camera, however 0% in the inside.

[nik0]

lighttpd.bin is the web server, maybe the web page was opened in your browser and it did something I don't know exactly for for mmc1, it is related to memory, and this is a kernel process

[nik0]

I made a PR and merged it ... The getimage is now less heavy and maybe there will be some gain on it (thaks @puddly) And now the -v option is working again (there is a log for every sent frame)

[ark-git]

I enabled the -v option and logs are attached. It does show a fluctuation on the fps. I searched for "fps:". v4l2rtspserver-master.log

[puddly]

@ark-git To figure out if it's a software or a network issue, can you test another program to interact with the RTSP stream? I can't find what Blue Iris uses, but I think VLC uses Live555. I've had no problems with mpv, which I think uses ffmpeg's libraries:

# UDP transport mode (what VLC uses)
mpv --rtsp-transport=udp rtsp://192.168.1.28:8554/unicast

# or TCP transport mode (default mpv uses by default)
mpv --rtsp-transport=tcp rtsp://192.168.1.28:8554/unicast

[ark-git]

@puddly I ran the two commands in my ubuntu server. It opened the stream but then close abruptly. I think the failures are due to my ubuntu dependencies since its running headless. I usually VNC into it. Can you suggest what software I need to install to make this stream work in Ubuntu. See attached logs TCP_transport_mode.log UDP_transport_mode.log

[puddly]

@ark-git Looks like a graphics driver problem. I don't have any experience running graphical applications on headless servers so I can't help you much there. mpv has builds for both MacOS and Windows so just download one and try running it with the same options.

Alternatively, you can try recording the stream for a while with a recent version of ffmpeg (or with a static build if your distribution bundles too old of a version) and see if the resulting MKVs look fine:

ffmpeg -y -rtsp_transport tcp -i "rtsp://192.168.1.28:8554/unicast" -vcodec copy -acodec copy test_tcp.mkv
ffmpeg -y -rtsp_transport udp -i "rtsp://192.168.1.28:8554/unicast" -vcodec copy -acodec copy test_udp.mkv

[ark-git]

I ran the two commands in Ubuntu server. The TCP stream did not have any drop frames (I watched the Seconds counter), however the UDP stream had skips in the seconds counter. The TCP ran smoothly while the UDP had 5 drop packets.

See attached logs.

TCP_transport_mode.log UDP_transport_mode.log

[puddly]

You can force VLC to use TCP instead of UDP by going into the advanced preferences and enabling Input / Codecs -> Demuxers -> RTP/RTSP -> Use RTP over RTSP (TCP) (see the first two screenshots here). Does that help at all?

Can you try running each of those commands for more than 20 seconds (at least a few minutes)? If you replace test_tcp.mkv with -f matroska /dev/null in the above ffmpeg commands, the video output will be discarded so you don't waste disk space.

[ark-git]

I changed VLC settings to "TCP". The stream would run for a few seconds then stop altogether.

I then ran the ffmpeg and the udp stream would run for a while with drop packets I then ran the ffmpeg and the TCP stream would run for a few seconds (approximately 30seconds) and then hang. I have to hit CTRL-C on the terminal to get out. I would run again then it would crash after a few seconds. TCP_transport_mode.log UDP_transport_mode.log

[ark-git]

I ran the same ffmpeg test on the indoor camera with the same results, udp would run fine, but then tcp would stopped working after a few seconds. Prints "[rtsp @ 0x562764fbf6c0] CSeq 5 expected, 0 received."

[puddly]

Can you re-run the iperf test as you did before, but instead run the server on the camera and the client on your Ubuntu computer? If you can, run both TCP and UDP tests. VLC's RTSP code and the embedded RTSP server used in this camera are made by the same company so I don't think it's misconfigured software.

[paumove]

I have tested the changes from @nik0 on my Xiaofang 1S 64Mb because I have the same problems that are discussed here. It works better than previously but I can't get the camera stable for an hour. So here are the logs from the last 3 tests performed.

The camera es near the router and the connection is performed with VLC.

log1.txt log2.txt log3.txt

In Log1 file there is the dmesg crash obtained by serial port and also the rtsp server log.

In Log2 and Log3 there is only the crashes obtained by serial port. In the rtsp log, when the problem is generated, garbage data is saved. That's why I don't add them.

Thanks for your help.

[ark-git]

Running the TCP iperf client test on the ubuntu and the server and the camera. See attached results iperf_TCP.txt iperf_UDP.txt

[puddly]

@paumove I think your problem is #503, not this one. You have the same sensor detection issue going on:

2018-07-31 10:15:15.269 (   2.324s) [main thread     ]         ImpEncoder.cpp:984    ERR| ##### sensor not found
2018-07-31 10:15:15.273 (   2.327s) [main thread     ]         ImpEncoder.cpp:997      0| Found Sensor with ID:-1

What do you mean by "garbage data is saved"?

[paumove]

@puddly But the camera image is good until it stops, so the sensor is working correctly.

About the garbage ... At the same time that the rtsp server is stopped, a lot of junk data is written at the end of the v4l2rtspserver-master.log file. Like:

[ark-git]

@puddly Any idea What error is this related to. I see this in the rtspserver log file RTCPInstance::RTCPInstance error: totSessionBW parameter should not be zero!

[nik0]

This is not a real error, this is the rtsp lib who log this