Open peterpan192 opened 1 year ago
Now you can monitor whether you have a five nights at freddy's situation going on with your teddy bear tracker.
Ah yeah, I encountered a few flavors of this error over time. It currently does use two threads on the livestream mode. One thread for receiving frames, pushing them to a queue, and the other pops them off. This greatly reduce the frequency I would see these kind of stream processing errors. It's almost a pub/sub pattern, and gets around a lot of issues like you're seeing w/ streaming images in and processing in real time.
I still run into it once and awhile however, and I haven't spent time digging further yet. One thing you can try which has made my currently running system nearly completely stable, is drop the resolution of your baby camera. Looks like you're running w/ 1080p. On my reolink I have a low/med/high option... I believe I have it at medium now (720?) & might drop to low to see if the issue goes away entirely.
Now you can monitor whether you have a five nights at freddy's situation going on with your teddy bear tracker.
Yeah :-D My Reolink does not support 720p - it has a clear mode (min resolution and kbps 1080p and 1024 kbps) and a fluent mode (640x360 with 15 fps max) I tried both but I still run into the error from time to time. Could the problem be related to not having build ffmpeg from source?
Last time I got this error as well right before the above mentioned one:
cabac decode of qscale diff failed at 11 30
Hm, try keeping it on fluent and restart your camera from the reolink app. Don't open your camera on the reolink app for at least 60 seconds, and restart the app. Then see how long it runs for (can look at your camera in reolink app after the app is rebooted). My system is usually stable after this sequence, at least for a week or so.
Could the problem be related to not having build ffmpeg from source?
You could be correct on this, I just haven't gotten around to debugging further
Alright, it tried what you suggested. I also changed the stream from "..h264Preview_01_main" to "..h264Preview_01_sub" in main.py.
The script ran for way longer but after a few hours I still got the same failure.
So I compiled ffmpeg with the help of this guide: https://pimylifeup.com/compiling-ffmpeg-raspberry-pi/ resulting in a running script from 10.43 p.m. - 5.17 a.m.
Interestingly, there is no failure message this time - the script just stopped working. However, the cursor is still blinking.
Might it be worth a try to compile opencv from source as well? My system runs on wifi btw - I could try on LAN but the raspi is in the same room a few meters away from the router..
Hi @peterpan192, I had a similar issue to yours. I'm new to coding and GitHub, so I'm not sure how to quote or link my closed issue. My workaround for missing an argument gamma_correction()
was to remove self
. After making this change I haven't receive an error.
Might it be worth a try to compile opencv from source as well? My system runs on wifi btw - I could try on LAN but the raspi is in the same room a few meters away from the router..
My setup is all wifi as well, might make a difference in some way to be plugged in, but that's annoying. Like @TaintedIron said, for now I would remove self
from gamma_correction()
. There's a PR open which includes that change as well as some other usability improvements.
@peterpan192, next time my system goes down I'll check the logs for that/a similar error, and dig further into the ffmpeg
stuff, maybe try compiling as you suggest. Will keep this ticket open for now
So I compiled ffmpeg with the help of this guide: https://pimylifeup.com/compiling-ffmpeg-raspberry-pi/ resulting in a running script from 10.43 p.m. - 5.17 a.m.
@peterpan192 did compiling ffmpeg help you view the live stream? I saw your comment in the [https://github.com/calebolson123/BabySleepCoach/pull/6](Open PR) the other day and was wondering if you ever got the live stream going? I'm able to run the script without it erroring out or anything but again I'm not receiving a live stream.
I feel like I'm missing a dependency or something since I'm new to all of this. I have this on a Samba drive on an old desktop running Ubuntu, and I been working on the code remotely on my Windows desktop.
So I compiled ffmpeg with the help of this guide: https://pimylifeup.com/compiling-ffmpeg-raspberry-pi/ resulting in a running script from 10.43 p.m. - 5.17 a.m.
@peterpan192 did compiling ffmpeg help you view the live stream? I saw your comment in the [https://github.com/[/pull/6](https://github.com/calebolson123/BabySleepCoach/pull/6)](Open PR) the other day and was wondering if you ever got the live stream going? I'm able to run the script without it erroring out or anything but again I'm not receiving a live stream.
I feel like I'm missing a dependency or something since I'm new to all of this. I have this on a Samba drive on an old desktop running Ubuntu, and I been working on the code remotely on my Windows desktop.
Yeah I got it going. After removing self
from gamma_correction()
I got another error in debug mode. I needed to remove self
from maintain_aspect_ratio_resize()
as well. After this the live stream opened up automatically.
The issue highlighted in this PR likely still exists, but I've been testing a change here for awhile now, and it seems more stable. Try swapping it in on your side and lmk results. I'm not sure all RTSP-supporting cameras support substream
, but poking around, it pretty common
The issue highlighted in this PR likely still exists, but I've been testing a change here for awhile now, and it seems more stable. Try swapping it in on your side and lmk results. I'm not sure all RTSP-supporting cameras support
substream
, but poking around, it pretty common
I tested the branch last night. The script worked from 10.36 p.m. until 1 a.m. It stopped without any failure messages. (see picture no. 1 - log entries leading to this behaviour see picture no. 2). So the issue was not the ffmpeg thing this time.
edit: There it is again. (picture 3)
Haha dang it, broke so quickly for you. Mines been going for a week straight. I'm going on vacation, I'll try to dig into the root cause when I'm back
Hey there, has anyone had a similar issue? I believe it has to do with ffmpeg. I could be mistaken but I think it happens more often when things inside the crib are being moved. (Blankets moving, teddy bear leaves the crib etc.) At this point, my baby's body is not being recognized by the script but one of our teddy bears is. :-D So I'm testing with him a bit. I'm using a Reolink E1 Pro Camera
No body found, vote awake No face found, depreciate queue Not voting on eyes, eye queue too short. No body found, depreciate movement queue. [h264 @ 0x7f500d2fe0] error while decoding MB 1 45, bytestream -6 No body found, vote awake No face found, depreciate queue Not voting on eyes, eye queue too short. No body found, depreciate movement queue.
"ffprobe -rtsp_transport tcp rtsp://admin:pw@192.168.177.82:554/h264Preview_01_main"
gives me this output:
Input #0, rtsp, from 'rtsp://admin:pw@192.168.177.82:554/h264Preview_01_main': Metadata: title : Session streamed by "preview" comment : h264Preview_01_main Duration: N/A, start: 0.000000, bitrate: N/A Stream #0:0: Video: h264 (High), yuv420p(progressive), 1920x1080, 25 fps, 25 tbr, 90k tbn Stream #0:1: Audio: aac (LC), 16000 Hz, mono, fltp
I tried to favour tcp over udp but it makes no difference. Here someone suggests to increase the shm-size but I dont know what that is or how to crank it up. https://github.com/blakeblackshear/frigate/issues/1403#issuecomment-883009979
I'm on a Raspberry Pi 4 running Raspberry Pi OS (64 bit)
This right here could be another solution: https://stackoverflow.com/questions/49233433/opencv-read-errorh264-0x8f915e0-error-while-decoding-mb-53-20-bytestream
@calebolson123 Does the code use multithreading?