Unfortunately, the still image is not available locally. Apparently, the “fix” for some vulnerabilities was to disable local access to everything but RTSP in the camera’s firmware. The still image link authenticates successfully, but only returns an “Access Error”.
The lack of a still image can be hacked around with a cron job:
MotionEye only provides an MJPEG stream. This component requires an h264 stream. Try the URL you used to add the camera to MotionEye, and find a still image source for your camera.
Anyone with the reolink configuration find that the video does not play on first launch, but if you close it and launch it again it plays the second time consistently?
Thanks for the reply, wasn’t aware of this. Unfortunately the stream does not work with the url, and somehow my Mac mini goes in turbo overdrive after added the camera url to the config file so somehow it is taking a lot of resources without actually working.
Just a workaround for those who only have RTSP-stream and no still image URL. Install MotionEye en don’t let it do the streaming, but just the Still Image. Works like a charm!
Streaming is working well for some old Escam QD520 camera’s, except casting to my Chromecasts. In the log I see this error:
ERROR (stream_worker) [libav.rtsp] Too short data for FU-A H.264 RTP packet
I use the Hikvision camera.
Streaming image is not working.
There are no errors in the log.
I tried to reduce the resolution to 640 \ 480
However, the rtsp string works fine in vlc.
Still image is working fine. Even better than before ffmpeg.
hardware - RPI 3B+
HASSIO HA 0.9.1
@Maikl_Sh I have the same issue on a RPI 3B+ venv install. I enabled component level logging and the only entry was that streaming started, but the browser doesn’t receive data and will continue to show the loading animation until it times out. This is with the Hikvison DS-2CD2385FWD-I.
I have similar issues. Have you tried to cast the stream to a chromecast device. I suspect you’ll find it’s working. I’m just unable to view the stream via UI (chrome or iOS)
I’ve just come to the realization that the Dahua stream configuration that works for the ffmpeg component or VLC app is not a usable configuration for streaming via the generic camera component. (I had the same errors that @DeadEnd reported in post 89). One would think that the configs should be the same and using VLC is a valid test to get it right.
I’ve had no luck following the Dahua example in the OP, but I did finally get something to work (sort of) following @Zpeed 's example in post 131. Yes, the streaming was choppy, but it was also much lower resolution than the Dahua Starlight’s 3MP.
I guess I need to reset my expectations of what an RPi3 B+ as a streaming host is capable of in the current Hassio version. Many times, during this testing, I have brought the system to its knees and essentially killed it, requiring a restart.
EDIT: well, it worked once. Just tried again using the same config as Zpeed’s, and it just quits right away with errors. I submitted an error report to HA, but here’s a snippet of the errors:
2019-03-24 12:50:36 ERROR (stream_worker) [libav.h264] left block unavailable for requested intra mode
2019-03-24 12:50:36 ERROR (stream_worker) [libav.h264] error while decoding MB 0 9, bytestream 32507
2019-03-24 12:50:42 ERROR (stream_worker) [libav.NULL] SEI type 54 size 1104 truncated at 272
2019-03-24 12:50:42 ERROR (stream_worker) [libav.NULL] SEI type 114 size 1920 truncated at 1176
2019-03-24 12:50:44 ERROR (stream_worker) [libav.NULL] SEI type 199 size 1816 truncated at 1368
2019-03-24 12:50:54 ERROR (stream_worker) [libav.NULL] SEI type 53 size 1920 truncated at 288
2019-03-24 12:51:00 ERROR (stream_worker) [libav.NULL] SEI type 129 size 1208 truncated at 752
2019-03-24 12:51:18 ERROR (stream_worker) [libav.NULL] SEI type 99 size 1728 truncated at 1720
2019-03-24 12:51:24 ERROR (stream_worker) [libav.NULL] non-existing SPS 6 referenced in buffering period
2019-03-24 12:51:24 ERROR (stream_worker) [libav.NULL] SEI type 69 size 968 truncated at 944