Send Motion-user mailing list submissions to
motion-user@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/motion-user
or, via email, send a message with subject or body 'help' to
motion-user-requ...@lists.sourceforge.net
You can reach the person managing the list at
motion-user-ow...@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."
Today's Topics:
1. Re: Video view position with lower resolution (Adam Goryachev)
2. Re: Video view position with lower resolution (Gotcha IT)
----------------------------------------------------------------------
Message: 1
Date: Tue, 22 Jan 2019 13:16:05 +1100
From: Adam Goryachev <mailingli...@websitemanagers.com.au>
To: motion-user@lists.sourceforge.net
Subject: Re: [Motion-user] Video view position with lower resolution
Message-ID:
<c3d85901-3856-701d-5ab9-a47e469eb...@websitemanagers.com.au>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
On 22/1/19 1:26 am, tosiara wrote:
> Motion does not select which part of the sensor to grab, it asks
> camera to provide 1024x600 and you will see whatever camera gives
> Also, there is no way to crop picture by motion, but you can setup a
> middleware, like ffmpeg, that will grab picture from camera,
> resize/crop and feed it to motion (if it is really worth)
>
> On Mon, Jan 21, 2019 at 2:15 AM Gotcha IT <i...@gotcha.net.au
> <mailto:i...@gotcha.net.au>> wrote:
>
> Hi Guys,
>
> New subscriber here.
> I use MotionEyeOS on several Raspberry Pi Zero W's as security
> cameras. With cameras connected to a 4G service, I need to use my
> bandwidth wisely, especially as the cameras are not the only
> devices using the 4G service.
> To reduce bandwidth I use a lower resolution (with only 1 frame
> per second) than the camera supports (a 120 degree FoV MMAL
> camera). Because I'm more interested in a wide than high view I
> prefer a resolution like 1024x600 over 1024x768.
> However, if I specify 1024x600, Motion grabs the top part of the
> camera view (CCD), not the middle part. Is this configurable? If
> not I would prefer?it to default to the middle, but ideally I'd
> like to configure this as ?in my case I need the bottom part more
> than I need the top. The top part of the camera view is generally
> ceiling, which is of no interest.
>
> With MotionEyeOS I can provide Motion options for the video
> device, but I couldn't find anything related to this.
> Does anyone know if this is configurable and if yes, how?
>
> If not, perhaps this could be included as a feature request?
>
>
Interesting.... I've been using the RPi 3 for a while for a similar
purpose, but after reaching around 20 or so cameras, I realised that
this was not going to be scalable. The only solution is to run motion on
the camera itself to do the motion detection/etc. I've also currently
left the recordings on the camera, but eventually was planning on
forwarding low res videos to the server (using rsync or similar), and
potentially hi-res motion events during "alarm" periods (ie, nights) and
send those straight away (to prevent against the "intruder" stealing the
camera or damaging it and destroying the recordings).
Anyway, you could equally run motion locally to do all the motion
detection and recording locally, and then use the motion remote view
(with a lower framerate and/or quality).
Regards,
Adam
--
The information in this e-mail is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this e-mail by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance
on it, is prohibited and may be unlawful. If you have received this message
in error, please notify us immediately. Please also destroy and delete the
message from your computer. Viruses - Any loss/damage incurred by receiving
this email is not the sender's responsibility.
--
Adam Goryachev Website Managers www.websitemanagers.com.au
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
Message: 2
Date: Tue, 22 Jan 2019 03:13:35 +0000
From: Gotcha IT <i...@gotcha.net.au>
To: Motion discussion list <motion-user@lists.sourceforge.net>,
"motion-user@lists.sourceforge.net"
<motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Video view position with lower resolution
Message-ID: <em87fec92c-7807-49fb-a77a-56e0891f4116@m046-dhp3130>
Content-Type: text/plain; charset="utf-8"
I think they can be quite scalable.
The cameras I've built have two 120 degree fov cams (each connected to it's own
RPi Zero W) fitted in a aluminium travel cigar tube
(https://www.amazon.com/Aluminium-Cigar-Travel-Hygrometer-Humidifier/dp/B01BLW7NEG).
Those tubes are fitted onto a superclamp
(http://studio-assets.com/super-clamp-with-5-8-stud) which allows me to fit
them to trusses in our popup shops.
The RPi's are fed via a single cable which is split in the tube to power both
RPi's. They then connect to a Wifi router which itself connects to 4G.
All cameras stream video to a Synology NAS (the Synology Surveilance software
works great for this) and imagery is recorded on the NAS.
I only use 1024x768 resolution at the moment (cameras support HD), and only
stream 1 frame per second. That results in about 350-400kbps data per camera.
As everything is streamed over 4G, and the cameras are not the only devices
using 4G, (we also upload raw images from photography cameras, each 30MB in
size or so) data consumption needs to be kept low.
The setup works well enough though, and would scale fairly well, easily to 20
cams.
Our popup shops usually sit in shopping centres and the cameras are used to
monitor foot traffic around the set and for security purposes. With a
resolution of 1024x768, I get nice wide view (and as the cameras in the tube
are mounted back to back I have an almost 360 degree view. There's now newer
RPi cameras available that have 170 degree fov, which leaves just 20 degrees on
each end.
But I don't really care for the ceiling, and reducing the resolution to
1024x600 gives me a much lower bandwidth usage.
Unfortunately, the cameras hardware determines where it pulls video from the
CCD when using a lower resolution. Which means I need to get the cameras back
at some stage and tilt them downwards, or mount them upside down.
------ Original Message ------
From: "Adam Goryachev"
<mailingli...@websitemanagers.com.au<mailto:mailingli...@websitemanagers.com.au>>
To: "motion-user@lists.sourceforge.net"
<motion-user@lists.sourceforge.net<mailto:motion-user@lists.sourceforge.net>>
Sent: 22/01/2019 12:16:05 PM
Subject: Re: [Motion-user] Video view position with lower resolution
On 22/1/19 1:26 am, tosiara wrote:
Motion does not select which part of the sensor to grab, it asks camera to
provide 1024x600 and you will see whatever camera gives
Also, there is no way to crop picture by motion, but you can setup a
middleware, like ffmpeg, that will grab picture from camera, resize/crop and
feed it to motion (if it is really worth)
On Mon, Jan 21, 2019 at 2:15 AM Gotcha IT
<i...@gotcha.net.au<mailto:i...@gotcha.net.au>> wrote:
Hi Guys,
New subscriber here.
I use MotionEyeOS on several Raspberry Pi Zero W's as security cameras. With
cameras connected to a 4G service, I need to use my bandwidth wisely,
especially as the cameras are not the only devices using the 4G service.
To reduce bandwidth I use a lower resolution (with only 1 frame per second)
than the camera supports (a 120 degree FoV MMAL camera). Because I'm more
interested in a wide than high view I prefer a resolution like 1024x600 over
1024x768.
However, if I specify 1024x600, Motion grabs the top part of the camera view
(CCD), not the middle part. Is this configurable? If not I would prefer it to
default to the middle, but ideally I'd like to configure this as in my case I
need the bottom part more than I need the top. The top part of the camera view
is generally ceiling, which is of no interest.
With MotionEyeOS I can provide Motion options for the video device, but I
couldn't find anything related to this.
Does anyone know if this is configurable and if yes, how?
If not, perhaps this could be included as a feature request?
Interesting.... I've been using the RPi 3 for a while for a similar purpose,
but after reaching around 20 or so cameras, I realised that this was not going
to be scalable. The only solution is to run motion on the camera itself to do
the motion detection/etc. I've also currently left the recordings on the
camera, but eventually was planning on forwarding low res videos to the server
(using rsync or similar), and potentially hi-res motion events during "alarm"
periods (ie, nights) and send those straight away (to prevent against the
"intruder" stealing the camera or damaging it and destroying the recordings).
Anyway, you could equally run motion locally to do all the motion detection and
recording locally, and then use the motion remote view (with a lower framerate
and/or quality).
Regards,
Adam
--
Adam Goryachev Website Managers
www.websitemanagers.com.au<http://www.websitemanagers.com.au>
-- The information in this e-mail is confidential and may be legally
privileged. It is intended solely for the addressee. Access to this e-mail by
anyone else is unauthorised. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. If you have received this
message in error, please notify us immediately. Please also destroy and delete
the message from your computer. Viruses - Any loss/damage incurred by receiving
this email is not the sender's responsibility.
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------
Subject: Digest Footer
_______________________________________________
Motion-user mailing list
Motion-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/motion-user
------------------------------
End of Motion-user Digest, Vol 151, Issue 36
********************************************
