haven
haven copied to clipboard
guardianproject
Camera motion detection not working in 0.2.0-beta3
In 0.2.0-beta3, camera motion detection simply doesn't work.
Under 'Camera Sensitivity' in the settings, it stays at '0% motion' detected, no matter how much I move the phone around and capture movement. The cameras themselves work in the app, but no motion is registered in Haven anymore.
Sound and movement (moving the phone itself) detection works, but no camera motion.
Device is a Samsung Galaxy J1 mini, model SM-J105Y.
It used to work on this device, but I can't remember what version I was on before upgrading. I can't downgrade to an older version (I get an error in F-Droid).
Uninstalling and installing 0.2.0-beta1 from F-Droid, I only get a black screen for Camera Sensitivity.
Rolling back to 0.1.0-RC-1 seems to restore camera motion detection for me :/
In 0.2.0-beta3, camera motion detection simply doesn't work.
Under 'Camera Sensitivity' in the settings, it stays at '0% motion' detected, no matter how much I move the phone around and capture movement. The cameras themselves work in the app, but no motion is registered in Haven anymore.
This is reproducible for me. In earlier versions setting the Camera sensitivity to 0 used to trigger Logs at the slightest motion. Not so in the recent build.
@archie94, can you check this commit and see if it solves/helps the issue? 19890a22b9f0f094fb1b392cda185ec2673606a4
Was seeing only 0% on legacy devices until this point, let me know. Thank you
@lukeswitz Much better 👍
For some reason the text which shows the % of motion detected is not responsive on master branch. Much better when on 19890a2
I'm on latest github,compiling from source. This Calibration / Settings screen just isn't working very well.
To me there is a fundamental design issue here: I suggest a single frame output (bottom status) isn't really sufficient. A history graph of the past 3 seconds (real time) would seem far more useful in calibrating detection.
As a quick debugging hack to reflect each time the status changes: Adding a variable changeIndex of how often the output has been touched.
// add class variable to track screen updates
private int changeIndex = 0;
private String detectSaveOutput = "";
`
BroadcastReceiver receiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
changeIndex++;
int eventType = intent.getIntExtra("type",-1);
boolean detected = intent.getBooleanExtra("detected",true);
int percChanged = intent.getIntExtra("changed",-1);
if (percChanged != -1)
{
// "C" stands for "current"
mTxtStatus.setText(percChanged + "% motion detected C" + changeIndex + detectSaveOutput);
if (percChanged > 0) {
// "P" stands for "previous detection"
detectSaveOutput = " P" + changeIndex + ":" + percChanged + "%";
}
}
}
};`
My baseline is build 118
commit a52455e9d594484aeea5b69b68334950c164f962 (tag: 0.2.0-alpha-5, origin/master,
origin/HEAD, master)
Author: n8fr8 <[email protected]>
Date: Wed Oct 3 16:43:53 2018 -0400
update to version 118
This older camera motion code did annotations of the changes in the frames. But more notable, the frame rate of comparing frames was much higher. Like 4 to 8 FPS. With the latest source checkout, sometimes 1 to 3 seconds can pass with no frames being analyzed for detection.
I think FPS of the comparison needs to be exposed - as it's going to impact battery consumption and also how quickly someone could 'dash' in front of a camera and not be detected if the rate of comparison between frames is too low.
Have you checked the camera settings to see if it works better with HD off?
On Thu, Apr 4, 2019, 7:50 PM CameraCornet [email protected] wrote:
My baseline is build 118
commit a52455e9d594484aeea5b69b68334950c164f962 (tag: 0.2.0-alpha-5, origin/master, origin/HEAD, master) Author: n8fr8 [email protected] Date: Wed Oct 3 16:43:53 2018 -0400
update to version 118This older camera motion code did annotations of the changes in the frames. But more notable, the frame rate of comparing frames was much higher. Like 4 to 8 FPS. With the latest source checkout, sometimes 1 to 3 seconds can pass with no frames being analyzed for detection.
I think FPS of the comparison needs to be exposed - as it's going to impact battery consumption and also how quickly someone could 'dash' in front of a camera and not be detected if the rate of comparison between frames is too low.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/guardianproject/haven/issues/383#issuecomment-480112707, or mute the thread https://github.com/notifications/unsubscribe-auth/AhZXIU5XPEYWramQ8ZUaXiCPMNbUef_Bks5vdp3cgaJpZM4bWHWj .
@indiglofae Haven camera settings? I don't see such a setting. And to add, I don't have video on.
This is looking at my Nokia 6.1 device, running Android ``9.
Haven uses your Android camera. Try turning it off in your Android settings and see if it works. I know it sounds too simple, but it just might work.
On Thu, Apr 4, 2019, 8:33 PM CameraCornet [email protected] wrote:
@ndiglofae Haven camera settings? I don't see such a setting. And to add, I don't have video on.
This is looking at my Nokia 6.1 device, running Android 9.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/guardianproject/haven/issues/383#issuecomment-480119354, or mute the thread https://github.com/notifications/unsubscribe-auth/AhZXIQuMUfzwZaA0yAgyag4x2iZI_1c8ks5vdqfkgaJpZM4bWHWj .
This is also present on a Moto E4 running Android 7.1.1 with Haven 0.2.0-beta-5
I installed Haven from Github on a Chromebook, Chrome OS 74.0.3729.159 Official Build, and the same thing is happening. The slider for sensitivity seems to make little difference. It sometimes detects motions if I do very dramatic things, but otherwise it is very broken.
Playing around...
The code checks each Frame getData() and getSize() against null twice. Perhaps threading is causing these problems?
getData() and getSize() is checked for null before submitting to ThreadPool:
https://github.com/guardianproject/haven/blob/b4b55a1f7c94a491388620c477d18e66cc198b44/src/main/java/org/havenapp/main/ui/CameraViewHolder.java#L244
and then on the thread, null is checked a second time inside the method processNewFrame:
https://github.com/guardianproject/haven/blob/b4b55a1f7c94a491388620c477d18e66cc198b44/src/main/java/org/havenapp/main/ui/CameraViewHolder.java#L345
NOTE: DataSpotA is class of static int variables to do counting at runtime of each execution branch.
` // revised process
public void process(@NonNull Frame frame) {
long now = System.currentTimeMillis();
if (now < CameraViewHolder.this.lastTimestamp + DETECTION_INTERVAL_MS) {
DataSpotA.processFrameTimeSkipCount++;
return;
}
final byte[] frameData = frame.getData();
final Size frameSize = frame.getSize();
if (frameData == null) {
DataSpotA.processFrameDataNullCount++;
return;
} else if (frameSize == null) {
DataSpotA.processFrameSizeNullCount++;
return;
}
CameraViewHolder.this.lastTimestamp = now;
// OLD: if (frame.getData() != null && frame.getSize() != null) {
if (!doingVideoProcessing) {
// OLD: mDecodeThreadPool.execute(() -> processNewFrame(frame));
mDecodeThreadPool.execute(() -> processNewFrameData(frameData, frameSize));
} else {
mEncodeVideoThreadPool.execute(() -> recordNewFrame(frame));
}
//}
}
`
This seems to work much better, as the frame object is not passed to the ThreadPool but instead the byte[] array and size object itself.
Otherwise, the original code, is hitting a lot of nulls on the getData() and getSize() by the time it makes it into the ThreadPool.
Following along here on what is happening?
Video recording was a good intention feature that happened to break the app entirely for a lot of folks.
Threading totally a problem, and hard to say without having written the camera activity if what you’re pointing out is the cause, but video breaks all motion capture for devices < lollipop (5.1). I’ll try the code and report back
Hoping to see some activity resume here shortly. Cheers
Another observation...
The first thing the method does is check DETECTION_INTERVAL_MS - but is that really what you want if you are capturing video?
If you are in the middle of an security incident, I would suggest that every single frame be processed.
Code is public: https://github.com/CameraCornet/haven/tree/CameraRework0
I hacked in a switch/case to allow the older MotionDetector code with visual annotation to work with the latest github source.
Video recording may be broken, I haven't tested this much. Study the commit and you will see a variable and switch/case used as to old vs. new code.
https://github.com/CameraCornet/haven/commits/SwitchMotionDetection0
Strong work- Thanks @CameraCornet, looking forward to reviewing later. I like the idea of actually capturing the incident instead of the first frame of motion. Exactly what we need here. Cheers and thanks again for the efforts!
Yes, this is the approach I have been hoping for. Coming up for air from other projects, and looking forward to digging back into Haven.
With the current (latest) code, i've integrated 2 old motion routines. Notably the commit a52455e9d594484aeea5b69b68334950c164f962 branch - which I had worked with for months and is my baseline of experience with camera motion detection.
I am a bit lost, as I seem to be running the code from commit a52455e9d594484aeea5b69b68334950c164f962 integrated with the latest, but it isn't behaving the same. Still trying to figure out why.
To me, this raises some issues regarding data testing. I think a natural progression is to allow masking of parts of the frame as many IP Camera systems allow. To test this, a static set of motion-data might make sense? I'm looking over: http://lear.inrialpes.fr/research/motionboundaries/
Can't seem to get this working on 0.2.0-beta-5. Using an EKO Star LTE g60 running Android 7.0. Camera preview displays in camera sensitivity setting, but "XX% motion detected" rarely updates (once every 5 minutes or so).
