Yi Pro 2K Home - High stream corrupts after two simultaneous connections

[Quedale]

Good day!

First, thanks for this great project!

I've had issues with the High stream profile dropping frames (especially important i-frame) when more than one client is connected. All clients no longer receive I-frames, which doesn't allow the stream to show the entire picture. It only shows a grey screen with partial updates.

I understand that the camera has limited resources, but the current behavior doesn't seem functional, since it may corrupt an existing stream fed to an NVR. If the camera simply doesn't have enough resource to serve more than one client, I would expect it to refuse additional connections to keep the existing stream healthy.

The Low profile still works fine even after the High profile was corrupted.

Here's the camera's resources while two clients are simultaneously connected:

Mem: 57956K used, 2956K free, 1124K shrd, 192K buff, 4176K cached
CPU: 38.9% usr 15.2% sys  0.0% nic 43.3% idle  0.0% io  0.0% irq  2.4% sirq
Load average: 1.46 1.37 1.31 2/108 16988

Let me know if I can provide any relevant logs to help diagnose the issue.

Thanks!

EDIT: I'm using the latest version 0.3.2.

It could related with Issue #846, but since 0.3.2 did fix the original issue, I thought I would open a separate one.

[roleoroleo]

As you can read here http://www.live555.com/liveMedia/faq.html#scalability there is no limit in the code about concurrent connections.

But 1 connection at a time is too little, with my cam I tested 5 connections (high res) without problem with these stats:

Mem: 53384K used, 7528K free, 1148K shrd, 656K buff, 6868K cached
CPU: 31.3% usr 10.8% sys  0.0% nic 57.7% idle  0.0% io  0.0% irq  0.0% sirq
Load average: 1.18 1.16 1.18 3/120 32205

Probably is related to the size of the I-Frame, like the problem fixed in #846. You should take a log of the RTSP server daemon.

killall wd_rtsp.sh
killall rRTSPServer
rRTSPServer -m y623 -r both -a no -p 554 -d 15

[Quedale]

I'm glad to hear that it's supposed to work.

The first time I ran the rRTSPServer, it failed. (Probably not relevant) Regardless, here's the log of the failure: Failed start.txt

Here's about 10 seconds worth of log, while two clients are connected: rRTSPServer_logs.txt

Thanks for this prompt response!

EDIT: Looking at the logs, I would guess it broke around '1716993824219'. Where start - fMaxSize 393216 - fLimitNumBytesToStream 0 - fPreferredFrameSize 0 started to show.

But I'm no expert, I'm just getting familiar with your project.

[roleoroleo]

The first time I ran the rRTSPServer, it failed. (Probably not relevant) Regardless, here's the log of the failure: Failed start.txt

This behavior is normal: you killed the daemon while a client connection was running. You have to wait for the system to free up network resources.

Here's about 10 seconds worth of log, while two clients are connected: rRTSPServer_logs.txt

EDIT: Looking at the logs, I would guess it broke around '1716993824219'. Where start - fMaxSize 393216 - fLimitNumBytesToStream 0 - fPreferredFrameSize 0 started to show.

This line is when the daemon starts to deliver frames, so it's not a problem. In the previous lines, the daemon was running but no clients was connected yet.

There is only a problem between lines 1716993828570 and 1716993829758: there are 23 lost frames after an I-Frame. The lost frames are related to the delivery phase, there are no errors in the capture phase. I don't know why. It could be a buffer problem (the size of the buffer is 393216 bytes) or a performance issue. The peculiarity of this model is that I-Frames are very big. In the models I own these are about 150 KB.