yi-hack-v4
yi-hack-v4 copied to clipboard
TheCrypt0
RTSP does not work properly
I have a problem with the RTSP. I checked in a few applications. RTSP works very rarely, each time it either rejects the connection or shows a black screen. Several times a day a smooth image from the camera will appear. Often I have to reboot camera and sometimes the interface does not work and I have to disconnect the camera from the power supply. I have Yi Outdoor, yi-hack-v4 0.2.0, rtspv4__1.0.0
I see a similar issue. Yi outdoor 1080, latest hack b4 with license etc.
Rebooting the camera means it will work for some hours, but eventually it will get to a state where it returns a blank stream on RTSP. Funnily enough, MQTT is still triggered for motion, but video is blank. Interesting.
I also have this issue, the stream to VLC works fine but using some CCTV Monitoring Software I get a successful connection but a black video feed. Please help!
I also have this issue, the stream to VLC works fine but using some CCTV Monitoring Software I get a successful connection but a black video feed. Please help!
This is not the same as my problem. My issue is that rtsp does not work at all no vlc, no motioneye, no homebridge/homekit, no nothing.... whilst the native yi app does work and shows video.
I am assuming that there is some issue with the services that convert the video into rtsp format, or the rtsp streaming process itself.....
I have run 'ps aux' on camera before and after the bug happens, but I cannot see much difference - i could be wrong, buit it doesnt look like anything is crashing/not running at this point.
If someone could tell me what commands to run via SSH to kill and restart the services responsible for RTSP then I can give those a try to see if it is indeed an issue there, otherwise im not sure where to start diagnosing this. :(
This is not the same as my problem. My issue is that rtsp does not work at all no vlc, no motioneye, no homebridge/homekit, no nothing.... whilst the native yi app does work and shows video.
I'm also experiencing the same issue on my Yi Outdoor 1080p camera. Yi Home app works fine but the RTSP stream specifically does not work. I've tried accessing it via VLC with no luck. I have access to the RTSP page and it's enabled along with the HD stream but I'm not getting any stream at the supposed address.
Thank you for the report. I don't have a Yi Outdoor cam but if you could give me the model number (it should be on the camera below a QR code) I'll try to get one from Amazon or eBay.
Thank you for the report. I don't have a Yi Outdoor cam but if you could give me the model number (it should be on the camera below a QR code) I'll try to get one from Amazon or eBay.
Yi Outdoor Camera 1080p Model: YHS.3017
If there is anything I can do to get logs/try restarting process/etc please tell me, I am familiar with ssh/shell stuff
If there is anything I can do to get logs/try restarting process/etc please tell me, I am familiar with ssh/shell stuff
Sure, you can connect to the camera via SSH and manually start viewd (see --help for all the parameters) and then rtspv4 (opening two shells would be preferred).
If something goes wrong you should see a warning or error message from one of those programs.
Will do this tonight and see if I can recreate the problem and capture the output
@TheCrypt0 Here's the output of running viewd and rtspv4
These were the running processes
@AndreVallestero Thank you for the screenshots.
Just guessing, do you have a chinese model? It may happen that the encoder process stops if it detects that isn't in the right region.
@TheCrypt0 I don't believe I have a Chinese model. It was purchased from Amazon and it works fine with the international version of the app.
I have similar problems with my Yi Outdoor Camera. If I log in via SSH I don't see viewd & rtspv4 running, if I start them manually (as deamon) they will work, but after a while the stream becomes unresponsive and if I log in via SSH same result no viewd & rtspv4 running. Any help or ideas?
Also having this problem. RTSP is available / unavailable in almost a predictable pattern. Will try and capture some logs.
EDIT: OK, monitored the stream, and this error ALWAYS appears right when the stream drops:
[ ERROR ] dev[0] - The frames available (151) are more than than half of the maximum (300) frames. [ ERROR ] dev[0] - Preventing overlapping read, glitches in the stream may occur.
EDIT 2: Tested on both Yi Outdoor and Yi Home 27US and the frames available error is exactly the same. This seems to be a fundamental problem with viewd itself.
/tmp # viewd -S
-----------------------------------------------------------------
viewd - v1.0.0
The /tmp/view circular buffer parser daemon for Yi
cameras supported by yi-hack-v4.
Copyright (c) 2018-2019 Davide Maggioni
-----------------------------------------------------------------
[ INFO ] Delayed start, waiting 20 seconds...
[ INFO ] Starting...
[ INFO ] ---------------------------------------------
[ INFO ] INIT - viewd
[ INFO ] ---------------------------------------------
[ INFO ] HD_STREAM : ENABLED
[ INFO ] SD_STREAM : DISABLED
[ INFO ] AUDIO_STREAM : DISABLED
[ INFO ]
[ INFO ] ---------------------------------------------
[ INFO ] INIT - Virtual Devices
[ INFO ] ---------------------------------------------
[ INFO ] Starting viewd_hires thread... done!
[ INFO ] Virtual devices created!
[ INFO ]
[ INFO ] ---------------------------------------------
[ INFO ] INIT - Analyzer
[ INFO ] ---------------------------------------------
[ INFO ] Opening /tmp/view file... done!
[ INFO ] Mapping /tmp/view to memory... done!
[ INFO ]
[ INFO ] Parsing circular buffers...
[ INFO ] PARSER - /tmp/view parsed successfully!
[ INFO ]
[ WARN ] PARSER - audio_stream_size ajusted! Previous value = 0xfffb
[ INFO ]
[ INFO ] Result:
[ INFO ] hd_stream_start 0x9644
[ INFO ] hd_stream_size 0x100000
[ INFO ] sd_stream_start 0x109644
[ INFO ] sd_stream_size 0x5a000
[ INFO ] audio_stream_start 0x163644
[ INFO ] audio_stream_size 0x10000
[ INFO ]
[ INFO ] Now waiting for a client..
[ INFO ] VIRTDEVS - dev_open[0]
[ INFO ] dev[0] - Waiting for the first SPS.......... found!
[ INFO ] VIRTDEVS - dev_release[0]
[ INFO ] VIRTDEVS - dev_open[0]
[ INFO ] dev[0] - Waiting for the first SPS................... found!
[ INFO ] VIRTDEVS - dev_release[0]
[ INFO ] VIRTDEVS - dev_open[0]
[ INFO ] dev[0] - Waiting for the first SPS.......... found!
[ ERROR ] dev[0] - The frames available (151) are more than than half of the maximum (300) frames.
[ ERROR ] dev[0] - Preventing overlapping read, glitches in the stream may occur.
[ INFO ] VIRTDEVS - dev_release[0]
[ INFO ] VIRTDEVS - dev_open[0]
[ INFO ] dev[0] - Waiting for the first SPS......... found!
[ ERROR ] dev[0] - The frames available (152) are more than than half of the maximum (300) frames.
[ ERROR ] dev[0] - Preventing overlapping read, glitches in the stream may occur.
[ INFO ] VIRTDEVS - dev_release[0]
[ INFO ] VIRTDEVS - dev_open[0]
[ INFO ] dev[0] - Waiting for the first SPS............................ found!
[ ERROR ] dev[0] - The frames available (151) are more than than half of the maximum (300) frames.
[ ERROR ] dev[0] - Preventing overlapping read, glitches in the stream may occur.
[ INFO ] VIRTDEVS - dev_release[0]
[ INFO ] VIRTDEVS - dev_open[0]
[ INFO ] dev[0] - Waiting for the first SPS.... found!
[ ERROR ] dev[0] - The frames available (151) are more than than half of the maximum (300) frames.
[ ERROR ] dev[0] - Preventing overlapping read, glitches in the stream may occur.
[ INFO ] VIRTDEVS - dev_release[0]
[ INFO ] VIRTDEVS - dev_open[0]
[ INFO ] dev[0] - Waiting for the first SPS........................................ found!
Thank you for the report, I had to implement the feature to "prevent overlapping read" because sometimes the RTSP server was too slow to catch up with the frames provided by the camera.
The logic behind that feature is:
- See how many frames in the buffer haven't been read yet.
- The buffer is a circular one, so if the number above is too high the writing head might overlap with the reading one and cause corrupted video.
R : Reading pointer
W : Writing pointer
- : Frames already read
+ : Frames to be read
Normal situation
| ======================== BUFFER ======================== |
| -----------------------------R+++W---------------------- |
| ======================================================== |
Overlapping read situation
| ======================== BUFFER ======================== |
| ++++++++++++++++++++++++++++++++++++++W-----R+++++++++++ |
| ======================================================== |
As you can see, the reading pointer is too slow it might get caught by the writing one and cause issues.
Anyway, it shouldn't happen this often.. could you please try with the SD stream and see if the issue persists?
Thanks for that very detailed explanation. I have already tried the SD stream, as well is disabling EVERYTHING else on the camera(s) to free up as much CPU as possible.
I have an idea, since the RTSP server portion is having a hard time keeping up, what about having it process every other frame, perhaps with a switch option (-T or something)
Many NVR's record at 15 FPS, these Yi's seem to put out 20 FPS, so we have a bit to spare.
IMHO A 10 FPS stable stream would be MUCH more useful than a 20 FPS stream that drops / restarts every 60 seconds or so.
Screenshot from Blue Iris showing the amount of stream drops: (yioutdoor = 718 times, Yi Home = garage = 8 during an 11 hour period) Both have excellent Wi-Fi signal strength
I have similar problems with my Yi Outdoor Camera. If I log in via SSH I don't see viewd & rtspv4 running, if I start them manually (as deamon) they will work, but after a while the stream becomes unresponsive and if I log in via SSH same result no viewd & rtspv4 running. Any help or ideas?
What commands are you using to restore the daemons? I’m looking to implement a temporary hack by scripting on interval/something Else like that.
I'm having the same your issues (even if the wifi signal is quite perfect). Currently RTSP stream is unusable. Is there some news about possible fixing? Thank you for your support
Just checked mine again. Both are running SD streams only, no audio, cloud turned OFF, ftp off, etc:
For some reason the Outdoor drops WAY more often.
I think this could be fixed by limiting the frame rate so the buffer doesn't keep running out. (see my idea above)
Sorry for butting in; just having a browse through the project as thinking about using a couple of my Yi cameras for a project but haven't used it yet. I happened to read this issue and had some thoughts.
I believe I understand what the check is there to prevent, but unsure what it does when it finds this occurs, does it end the stream? I would expect to drop frames if processing is not keeping up with new data, especially for a streaming protocol. Can you just repeat the last frame and skip reading the "real" one until it catches up?
As for the root cause, I think /tmp/view is memory but does the output get written to disk (i.e. SD card)? If so writes to the card could be the cause if this blocks reading the next frame? I would be tempted to try to observe how reads from/writes to /tmp/view change over time (e.g. is the buffer being read smoothly but steadily falls behind, or do reads hang for long periods doing 'nothing' while writes continue?)
I was thinking about buying the RTSP server functionality for all my cameras (esp. for my Yi outdoor cams). But if it's so unstable/unusable, I won't spend any money on it. Too bad the problem won't get fixed.
I'm experiencing the same issue with a Yi Outdoor 1080p. The RTSP is working with VLC however it will not work on Shinobi. I just get a black screen. Anyone find a fix or work around for this?
I was able to fix the issue and got it running. Turned out unraid will not write to an unassigned mounted NTFS drive.
Im getting unstable rtsp, on yi dome 720p, where can i find this prevent overlapping feature?
I was able to fix the issue and got it running. Turned out unraid will not write to an unassigned mounted NTFS drive.
@chriseckman, could you please provide more details on your workaround ?
I have a problem with the RTSP. I checked in a few applications. RTSP works very rarely, each time it either rejects the connection or shows a black screen. Several times a day a smooth image from the camera will appear. Often I have to reboot camera and sometimes the interface does not work and I have to disconnect the camera from the power supply. I have Yi Outdoor, yi-hack-v4 0.2.0, rtspv4__1.0.0
Did you ever find a solution for this? I have an NVR with a couple of Yi Dome 1080p and after sometime the live feeds freeze and after a refresh, the feed for each camera goes black. Basically something is causing the cameras to loose connection. I am using the low quality RSTP feed on TCP on all cameras and the issue still persist. The only way is to either reboot the camera, reboot the NVR or re-enter the password on the NVR on each camera, which basically causes it to reconnect.
It's a known issue, will not be solved. Sell the camera get a cheap v380 works much better
On Fri, Jan 14, 2022, 12:00 PM idanny76 @.***> wrote:
I have a problem with the RTSP. I checked in a few applications. RTSP works very rarely, each time it either rejects the connection or shows a black screen. Several times a day a smooth image from the camera will appear. Often I have to reboot camera and sometimes the interface does not work and I have to disconnect the camera from the power supply. I have Yi Outdoor, yi-hack-v4 0.2.0, rtspv4__1.0.0
Did you ever find a solution for this? I have an NVR with a couple of Yi Dome 1080p and after sometime the live feeds freeze and after a refresh it a black screen. Basically something is causing the cameras to loose connection. I am using the low quality RSTP feed on TCP on all cameras and the issue still persist. The only way is to either reboot the camera, reboot the NVR or re-enter the password on the NVR on each camera, which basically causes it to reconnect.
— Reply to this email directly, view it on GitHub https://github.com/TheCrypt0/yi-hack-v4/issues/89#issuecomment-1013296695, or unsubscribe https://github.com/notifications/unsubscribe-auth/APKDYJNS4XG2X23I7T5WQC3UWBJBZANCNFSM4H25VSLA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID: @.***>