roleoroleo / yi-hack-MStar

Custom firmware for Yi 1080p camera based on MStar platform
GNU General Public License v3.0
844 stars 112 forks source link

Curl, rtsp and nvr #85

Closed buzlightyear closed 4 years ago

buzlightyear commented 4 years ago

Hi, thanks for your work. I'm going crazy with some things on my 2 home 1080p BFUS. First one: Curl is not usable. I've tried to put in the bin folder into the home, with libz.so.1 in lib folder into home, in the yi-hack/bin and lib subfolder into the sd, changing PATH... No way, it gives me always not found. Second things is for streaming, I've tried to put both camera under shinobi, motioneye, ispy... they always come disconnected after a period. (Tried also with err_detect ignore_err under shinobi). Anyway find how to make curl works is the most important things, because I've made a script for owncloud and the google drive script doesn't work for the same reason.

buzlightyear commented 4 years ago

Ok, I've found the curl that you compiled for google script... and it seems work...

roleoroleo commented 4 years ago

I'm using the cam with hass and motioneye and I have no problems with disconnections. Give me more details.

buzlightyear commented 4 years ago

It gives me an input error everytime. First both shows normally, after a period they stop showing and screen comes black. With yi app both works normally, when rtsp comes black also in ispy I've the disconnected signal.

buzlightyear commented 4 years ago

Later, if I can, I will try again and report errors that shinobi video log.

roleoroleo commented 4 years ago

Please, check if rRTSPserver and h264grabber are running.

buzlightyear commented 4 years ago

yes they're running. Shinobi gives me this FFMPEG STDERR a few seconds ago rtsp://10.0.0.10/ch0_0.h264: Invalid data found when processing input

buzlightyear commented 4 years ago

And this is what he pass for video Process Started 2 minutes ago cmd : -loglevel warning -progress pipe:5 -use_wallclock_as_timestamps 1 -analyzeduration 1000000 -probesize 1000000 -rtsp_transport tcp -err_detect ignore_err -fflags discardcorrupt -i "rtsp://10.0.0.10/ch0_0.h264" -an -segment_format_options movflags=faststart+frag_keyframe+empty_moov -strict -2 -threads 1 -vcodec copy -f segment -segment_atclocktime 1 -reset_timestamps 1 -strftime 1 -segment_list pipe:2 -segment_time 900 "/home/Shinobi/videos/Z3kmArHzlN/telecamera1/%Y-%m-%dT%H-%M-%S.mp4" -an -c:v mjpeg -f mpjpeg -boundary_tag shinobi -strict -2 -r 2 -q:v 15 pipe:1

buzlightyear commented 4 years ago

Now, that both are in that status, if I try to add them on a new reflashed motioneye os, I obtain timeout waiting for rtsp netcam response when I try to add a new camera.

buzlightyear commented 4 years ago

Manually killed rRTSPServer, restarted "ch0_0.h264" stream, from the file "stdin" Play this stream using the URL "rtsp://10.0.0.2/ch0_0.h264", but in motioneye I have camera detected (so bypassed error timeout waiting), but in motioneye on topleft on the camera streaming I have "Unable to open video device", with a grey screen.

buzlightyear commented 4 years ago

After some minutes rRTSPServer (manually started) crashed with a Segmentation fault error, note that if I don't kill service it will remain always up, also when I haven't video on rtsp softwares.

roleoroleo commented 4 years ago

Did you run rRTSPServer with the correct pipe?

h264grabber | rRTSPServer &
buzlightyear commented 4 years ago

With this pipe it works... for some time, like on reboot. Then it stop again, and this is, again, the shinobi output Camera is not streaming a few seconds ago msg : Restarting Process. Process rRTSPServer is up and it goes normally.

buzlightyear commented 4 years ago

Also h264grabber is up.

roleoroleo commented 4 years ago

May be the same issue described here? https://github.com/roleoroleo/yi-hack-MStar/issues/36

buzlightyear commented 4 years ago

maybe... Do you think we could compile a different rtsp server?

buzlightyear commented 4 years ago

like this one maybe... https://awesomeopensource.com/project/mpromonet/v4l2rtspserver

buzlightyear commented 4 years ago

To understand if it's a rtsp or h264grabber fault.

roleoroleo commented 4 years ago

The rtsp server you posted is based on the same library I used: live555. I've been looking for a long time and I didn't find other rtsp servers to use on this embedded platform. There are other projects but they require a lot of libraries (i.e. glib2).

buzlightyear commented 4 years ago

I think you can't use It due to the small space, but if we use those libs directly on sd card? only to try and see if It works?

roleoroleo commented 4 years ago

This work requires a lot of time. I started to build all libraries one month ago but i gave up because it was too hard. I need to find the time...

I don't use discord, sorry.

buzlightyear commented 4 years ago

I'm trying the bfus dome, by now it works without problem, while the 2 home has always the same problem. It's not the same hardware?

buzlightyear commented 4 years ago

Spoken too early... Same error -.-

buzlightyear commented 4 years ago

If it helps the differences between the dome and the other is that the dome restore the rtsp connection after some, the homes, instead, remain with no video. (all configured and running at the same time)

roleoroleo commented 4 years ago

Very strange, the software is the same.

Do you use shinobi and motioneye at the same time? Does shinobi read the stream from motioneye or directly from the cam? So, how many rtsp client are you using?

buzlightyear commented 4 years ago

I've tried all config... Motioneye alone, shinobi alone, both... Nothing changes.

roleoroleo commented 4 years ago

I'm installing shinobi...

roleoroleo commented 4 years ago

Installed shinobi 20 hours ago. Running at the same time shinobi, motion and hass. No problem at the moment: h264grabber, rRTSPServer and onvif_srvd are running correctly.

Please send me your configuration. Both yi app configuration and yi-hack configuration.

buzlightyear commented 4 years ago

Which configuration you need? What in particular?

roleoroleo commented 4 years ago

I would like to check if there is something strange in your configuration and copy your config to my cam.

buzlightyear commented 4 years ago

On shinobi I have left all default options, and for camera I choose h264,h265...
rtsp://10.0.0.2/ch0_0.h264 tried both with onvif enabled and port 80, or onvif disabled (with onvif enabled the lag is better).

On motioneye only rtsp://10.0.0.2/ch0_0.h264 and all the rest default (I've tried also to change framerate to 20)

On yi-hack (if it help, I've had to restart both camera because weren't reachable, even with browser, ssh or telnet, but with the yi app they were working) I have: Disabled disable cloud Enabled Recording without cloud Enabled RTSP Enabled RTSP High Resolution Enabled ONVIF Enabled SSH Enabled FTP Disabled Legacy FTP Enabled Telnet Enabled NTPD Enabled HTTPD Disabled Proxychains

PORTS RTSP 554 Onvif 80 Httpd 8080

No auth

buzlightyear commented 4 years ago

This part

(if it help, I've had to restart both camera because weren't reachable, even with browser, ssh or telnet, but with the yi app they were working)

I think it was because I have the yi app opened on my pc, because when I have the app open network from and to cam is slow.

buzlightyear commented 4 years ago

Shinobi settings and error: https://ibb.co/BfrDxxq https://ibb.co/yBSr6wQ https://ibb.co/SJkZgdy

Camera settings: https://ibb.co/1JsRxh6 https://ibb.co/v4jZsPH https://ibb.co/cXPK2xc https://ibb.co/Fm9tB65 https://ibb.co/RCWnG0X

Processes active: https://ibb.co/xh2GjGw

buzlightyear commented 4 years ago

This is motioneye https://ibb.co/Wv2WPsj, as you can see the dome yi is visible, "telecamera1" and "telecamera2" are the home 1080p, and the other 2 are other 2 cameras. P.s. telecamera 2 is same config with default resolution (640x480) and 20fps.

roleoroleo commented 4 years ago

I copied your configuration to my system 20 hours ago and is working without problem. hass + motion + shinobi at the same time. I will test it during this weekend.

buzlightyear commented 4 years ago

I think it's a bfus problem. I'm having always Invalid data found when processing input also when I try to probe on shinobi. Now I disable the high quality streaming for rtsp and try with channel 0_1 to see if something change.

Mdleal commented 4 years ago

I am having a similar problem with blueiris and home assistant. RTSP scream dies after a day or 2. I can also not get to the scream via VLC. A reboot usually resolves the issue. I am running version 2.5 on the 6FUS.

buzlightyear commented 4 years ago

@Mdleal try to disable high quality streaming and put ch0_1.h264 into the url. I'm not recording, but it seems work

mihir8786 commented 4 years ago

Same issue as @Mdleal with Blue Iris and Homeassistant. I will try what @buzlightyear suggested of disabling RTSP high quality. Currently, I have Blue Iris restarting the cam through going to the restart URL everytime it sees no signal so at least I don't have to manually restart cam.

I'm using 2.4 on BFUS. Everything else works great.

Mdleal commented 4 years ago

Are there any logs we can look at to see why it's crashing?

roleoroleo commented 4 years ago

Since I can't solve the problem, I will try to add a watchdog to monitor the RTSP process.

buzlightyear commented 4 years ago

I think it's a h264grabber fault, because the frequent error was that ffmpeg fail to read input. After that cam will be showed as they were disconnected.

roleoroleo commented 4 years ago

In my opinion it is a live555 fault when there is a network problem. I have double checked h264grabber many times and there are too few lines of code for an error.

I had a crash yesterday and the state of the processes was this:

roleoroleo commented 4 years ago

Please try release 0.2.7

mihir8786 commented 4 years ago

0.2.7 seems to be stable. I still see an occasional signal loss in Blue Iris but may be it's more on Blue Iris side as it resolves within seconds? I don't have to manually reboot the camera anymore.

Let me know if you want me to pull any logs. Thank you for fixing this!

roleoroleo commented 4 years ago

2 or 3 seconds of signal loss is normal when the watchdog restarts the daemon.

mihir8786 commented 4 years ago

That makes sense. Thanks again.