-
Notifications
You must be signed in to change notification settings - Fork 651
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
All recorded videos have a 3 seconds freeze in the beginning #2887
Comments
I have the same problem where first 3 seconds of every recorded video is frozen. Running on Raspberry Pi 5 with 64-bit OS. |
I have the same problem. I thought it was the encoder using too much cpu but changing the codec makes no difference |
I also have the same problem. Is it possible to downgrade to version 0.42.1 under dietpi? |
I think that is a issue on 0.43.
I'll reinstall using 0.42.
This is really annoying.
…On Fri, May 24, 2024, 10:15 bnhnbnhn ***@***.***> wrote:
I also have the same problem. Is it possible to downgrade to version
0.42.1 under dietpi?
—
Reply to this email directly, view it on GitHub
<#2887 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZN6I5LNLA7PGMBKHLWXL3ZD44OLAVCNFSM6AAAAABARPWLXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRZGUYTANBQGE>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Maybe this has something to do with the pre_capture value: Can someone who is experiencing this issue set the 'Captured Before' in motionEye to 0 and see if it makes a difference? |
Indeed, EDIT: Also strange, while there should be 1 second of still frames at the beginning of the recording, it is not. Or the number of changed frames of the 1st second is not above the threshold, and would be missing without |
The "captured before" and the "captured after" are defined in frames, not
seconds. Any tip? Here "motion gap" is defined to 5 seconds, "Captured
Before" and "Captured After" are defined to 10 frames, and the "Minimum
Motion Frames" are defined to 10 frames.
See attached image.
Best regards.
Henrique
[image: image.png]
…On Sun, Jun 30, 2024 at 9:14 AM MichaIng ***@***.***> wrote:
Indeed, pre_capture is set to 1 (second) by default. Not sure whether it
can take 3 seconds to process this 1 second though. At least worth an
attempt. Can be changed in motionEye UI.
—
Reply to this email directly, view it on GitHub
<#2887 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZN6I57N7OCEBECXGNLPN3ZJ7ZBHAVCNFSM6AAAAABARPWLXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGU2DEMZYGY>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
What type of camera did you use? |
Oh right. Please assign "0" to "captured before", to see if it plays a role at all. "captured after" and "motion gap" do not matter in this regards.
Images cannot be posted when you answer via email. |
Even if you have set pre_capture=0 there is probably still a buffer: |
But that section of the docs at least does not state that one will miss frames until the buffer has been processed. I am not sure how motion handles this internally, so worth a try to disable pre-capture, where this is mentioned explicitly. But if it does not help, also setting minimum motion frames to "1" could be tested. motionEye sets this to 20 by default, but can be adjusted in web UI as well. |
Hi. |
@hpicelli |
Activating the button still causes the same problem. |
Hi there,
I'm facing this problem.
In a recorded video (all videos have this issue), it plays one second, freeze for 3 seconds, then plays normal until the end.
I'm using mp4 (h264) now, but tested avi (mpeg4) and the problem persists on all formats i've tested.
Check attached video.
motionEye Version: 0.43.0
Motion Version: 4.5.1
OS Version: Linux 6.1.0-13-686-pae (Debian 12 32bit)
*Using 32bit OS because i'ts a old machine. This issue is only on 0.43.0, 0.42 runs ok.
Best regards,
Henrique
ENTRADA_07-20-32.mp4
The text was updated successfully, but these errors were encountered: