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.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Quedale]

I'm sorry, I've been busy for a long while.

Is there anything I can do to help determine the root cause?

It's not exactly essential to my surveillance network, but it would be nice to improve its stability.

[roleoroleo]

Please, try this beta:
https://github.com/user-attachments/files/17078115/y623_0.3.2.tgz

[Quedale]

I upgraded using these steps.

The upgrade went fine, but ONVIF and RTSP credentials no longer works.
HTTP access still works.

I tried removing the password entirely and rebooted the camera, but I still get Unauthorized response.

P.S. Thank you for trying to fix it!

[Quedale]

I would like to make a correction, I hadn't removed the credentials entirely, only the password and left the user. (Still didn't work)

I tried a fresh install and I had a different result.
I'm now authorized to access ONVIF service, but the rtsp server isn't started.
I tried all RTSP server program options, but always reverts to the standard one.

I set credentials again so that I can access SSH, but at that point I started getting Unautorized again just like after I did a manual upgrade.

rRTSPServer Logs:

1726877833165: the size of the buffer is 917872
1726877833166: capture - mapping file fshare_frame_buf, size 917872, to b6cf3000
1726877833167: capture - closing the file fshare_frame_buf
1726877833168: capture - frame header size = 28
1726877833169: capture - starting capture main loop
1726877833170: capture - buf_idx_end == buf_idx_end_prev
1726877833181: capture - buf_idx_end == buf_idx_end_prev
1726877833191: capture - buf_idx_end == buf_idx_end_prev
1726877833201: capture - buf_idx_end == buf_idx_end_prev
1726877833211: capture - buf_idx_end == buf_idx_end_prev
1726877833221: capture - buf_idx_end == buf_idx_end_prev
1726877833231: capture - buf_idx_end == buf_idx_end_prev
1726877833242: capture - buf_idx_end == buf_idx_end_prev
1726877833252: capture - buf_idx_end == buf_idx_end_prev
1726877833262: capture - buf_idx_end == buf_idx_end_prev
[...]

[roleoroleo]

Same problem described here:
#909

I'm trying to fix it.

[Quedale]

Thanks!
Looking forward to it!

No rush on my account. I'm just happy that it's being worked on.