Can this integration be configured to use go2rtc url as stream input?

[MichlW]

I plan to proxy my cams through go2rtc to get rid of the poor perfomance of my three yi outdoor cameras running yi-hack-v5 0.4.1.
Therefore I am interested to change the rtsp url of the incoming stream for the Cam entity but I can not find any option for that. Everything is configured seamlessly in the background.
I dont want to switch over to more configurable camera integrations and loose all the integration features like motion detection and config options.
Can you please helb me with an advice what options I have?

And a second question: Is the stream handled as passthrough from the camera or does the integration result in reencoding?
Thank you very much in advance.

[roleoroleo]

Sorry, I don't understand. What url would you like to use?
The url of the go2rtc installed on another host?
At the moment there is no options to change the rtsp address, it is negotiated between ha and the cam during setup.
Maybe you could try the onvif integration, motion detection should be supported.

The integration doesn't encode the stream, it's the stream coming from the cam.

[MichlW]

Yes, you're right. Unfortunately, my Yi Outdoor 9CUS cameras with yi-hack-v5 perform very poorly, and accessing the streams from multiple systems (Home Assistant, Apple Home, etc.) at the same time causes problems.
That's why I want to access the cameras via go2rtc (optimized for performance, without any re-encoding) and distribute the streams to the systems from there.
Your integration is fantastic and really lets me do a lot of helpful things, but it always connects directly to the cameras’ original streams.
Unfortunately, I haven't yet found a way - not even a workaround - to get the “Cam” entities in your integration to access other stream urls.
The only option right now seems to be to disable the cam entities in your integration and use separate picture or WebRTC entities instead. However, this means I lose some of the nice organization I have across my devices.

[MichlW]

I found one ffmpeg parameter that maybe helps me to define the other stream url.
-i [rtsp stream url] (rtsp://...)
Do you know if that parameter will work in context of your integration? Will it overwrite the camera's stream URL, which is automatically retrieved by the integration?

[Melectro1]

Hi and thank you for the great Yi firmware project and all the work you have put into it.

I am using RTSP with a Yi camera (1080p H.264, TCP transport) together with go2rtc/WebRTC on a Raspberry Pi. The camera works and the stream is detected correctly, but I am seeing intermittent RTSP disconnects.

The RTSP stream itself appears valid:

rtsp:///ch0_0.h264

Testing with ffprobe works and detects the stream correctly. However, during longer viewing sessions I occasionally see interruptions where the image freezes for around 20–30 seconds before recovering.

go2rtc logs typically show:

read tcp ... :554: i/o timeout

or:

error=EOF

The stream then reconnects automatically, but the interruption is visible to the viewer. I have also noticed that the camera timestamp/clock overlay sometimes appears slightly jerky even when video is otherwise live.

This makes me wonder if the RTSP server may occasionally stop sending packets or close the TCP session unexpectedly during long-running connections.

Would it be possible to improve long-duration RTSP stability, for example by:

• keeping RTSP TCP sessions alive more consistently
• reducing unexpected EOF/session termination
• improving handling of long-lived RTSP clients such as go2rtc, FFmpeg or Home Assistant integrations
• or perhaps adding configurable RTSP keepalive/session parameters if technically feasible

I really appreciate the firmware and understand this may be related to hardware or upstream RTSP behavior, but I wanted to share my observations in case it helps.

Thanks again for the project and your continued work.

data about my cam:
Hack (SD) Firmware Version | 0.4.1
Baseline Firmware Version | 0.4.1
Base Version | 3.0.0.0D_201809111054
Model Suffix | yi_outdoor
Hardware ID | 4CUS

WiFi Strength | 142 %

[roleoroleo]

I found one ffmpeg parameter that maybe helps me to define the other stream url. -i [rtsp stream url] (rtsp://...) Do you know if that parameter will work in context of your integration? Will it overwrite the camera's stream URL, which is automatically retrieved by the integration?

Probably doesn't work.
This integration uses links.sh service to ask the cam for the rtsp url.
https://github.com/roleoroleo/yi-hack-Allwinner-v2/blob/master/src/www/httpd/cgi-bin/links.sh
You can edit it, if you want.
But it will be overwritten in the next update.

[roleoroleo]

@Melectro1
I worked very hard with the RTSP library to obtain a reliable stream but I know it doesn't work perfectly.
The first problem is that I'm not a good C++ developer and then the poor cpu/mem performance it's a big issue.
So I think I've reached the maximum of what I can do.

[Melectro1]

First of all, thank you for your earlier reply and for taking the time to look into this project.

I should also mention that I am absolutely not a C programmer. However, your response got me thinking, and it inspired me to let an AI perform a deeper analysis of the codebase. I found the results interesting enough to share here in case they help point toward the root cause of the long-term RTSP stability issues.

The AI's analysis concluded that the architecture consists of:

/tmp/view (shared-memory ring buffer written by the camera firmware)
h264grabber (reads the ring buffer and pushes frames into a FIFO)
rRTSPServer (reads the FIFO and serves RTSP clients through live555)
wd_rtsp.sh (watchdog script responsible for restarting processes)

According to the analysis, the most likely root cause is a frame counter wrap-around issue in h264grabber.c.

1. Frame Counter Wrap-Around (Most Critical)

The camera's frame counter appears to be a 16-bit value that wraps from 65535 back to 0 approximately every 18 minutes at 60 fps.

The validation logic compares frame counters using signed arithmetic. When a wrap occurs, a transition such as:

0 - 65535 = -65535

fails the validation check, causing repeated frame counter errors, loss of synchronization, and eventually a full rescan of the frame table.

During this resynchronization period, no data is written to the FIFO, causing RTSP clients to freeze or disconnect.

2. Full Rescan After Sync Loss

Once enough invalid frame counter events accumulate, h264grabber breaks out of its processing loop and rescans the entire frame table looking for the newest frame.

For a 1080p stream this can take several seconds, during which no frames are forwarded to the RTSP server.

3. Watchdog Monitors the Wrong Failure Mode

The watchdog script appears to assume that a healthy rRTSPServer process should consume CPU time.

If h264grabber stops delivering data, rRTSPServer simply waits on the FIFO and naturally uses 0% CPU. The watchdog interprets this as a server failure and restarts rRTSPServer, while the actual problem remains in h264grabber.

4. FIFO Blocking

The analysis also pointed out that if the RTSP server temporarily stops consuming data, the FIFO can fill up and cause fwrite() in h264grabber to block indefinitely.

5. FIFO Restart Race Conditions

There may also be a possibility of stale FIFO descriptors after watchdog-triggered restarts, resulting in situations where data is written but never reaches the RTSP server.

6. Resource Cleanup

Finally, some error paths appear to leave memory mappings open because munmap() is only reached through the normal exit path, which is effectively never used during normal operation.

AI's Conclusion

The AI ranked the issues in the following order:

Frame counter wrap-around every ~18 minutes.
Long resynchronization after frame counter failure.
Watchdog restarting the wrong process.
FIFO blocking under load.
FIFO restart race conditions.
Memory mapping cleanup issues.

Its overall conclusion was that the long-term streaming instability is most likely caused by the frame counter wrap-around combined with the expensive resynchronization logic, while the watchdog fails to detect and recover from the actual fault.

-> The variables frame_counter, frame_counter_tmp and next_frame_counter are declared as int (signed 32-bit) in the code. A 32-bit signed int does not wrap at 32768 — it wraps at 2,147,483,647. So these variables themselves will never wrap.
The actual problem is different: the values read from the camera's shared memory are only 16-bit wide (two bytes are read and combined). So the values stored in those int variables stay in the range 0–65535. When the camera's internal counter goes from 65535 back to 0, next_frame_counter becomes 0 and frame_counter is still 65535. The subtraction 0 - 65535 = -65535 as a signed int, which fails the > 0 check, and sync is lost.
So to summarize correctly:

The variables are int (signed 32-bit) — no wrap issue with the variables themselves
The values only span 0–65535 because only 2 bytes are read from shared memory
The bug is that the validation code uses signed subtraction and fails when the 16-bit value read from the camera wraps from 65535 to 0

Since I am not a C developer myself, I cannot judge how accurate this analysis is. I am posting it here simply because it may provide useful clues for those who understand the codebase better than I do.

I'd be very interested to hear your thoughts on whether any of these observations make sense or if the AI has completely gone down the wrong path.

[roleoroleo]

I checked the possible issues (yi-hack-v5 code) and there shouldn't be any big problems:
1 - The frame counter is a 16 bit unsigned int but it's copied to a 32 bit signed integer variable (both next_frame_counter and frame_counter):

                if (((next_frame_counter - frame_counter > 0) && (next_frame_counter - frame_counter <= 10)) ||
                            ((next_frame_counter + 65536 - frame_counter > 0) && (next_frame_counter + 65536 - frame_counter <= 10))) {

so it should work.
2 - True but it should be a very rare event
3 - True but h264grabber must not stop delivering data. If it stops, it needs to be restarted.
4 - True but it's not a problem since rRTSPServer has stopped working. If rRTSPServer starts again, h264grabber will restart writing.
5 - Need to delve deeper.
6 - True but it does not impact normal functioning.

I don't understand why the AI ​​found problem number 1. IMHO the code is clear.

Did you try to run the grabber with a debug log?

[Melectro1]

No I did not, please tell me how to activate the debug log and I will try to help.