Send Motion-user mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Motion-user digest..."
Today's Topics:
1. Re: lightswitch (Kenneth Lavrsen)
2. Re: lightswitch (John Baker)
3. Re: lightswitch (Kenneth Lavrsen)
4. pb gcc : compile build motion on a raspberry 3 (Michel WILS)
----------------------------------------------------------------------
Message: 1
Date: Fri, 12 Aug 2016 17:15:46 +0200
From: Kenneth Lavrsen <[email protected]>
Subject: Re: [Motion-user] lightswitch
To: Motion discussion list <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
John
I totally fail to understand how that YAML format can be simpler for a human to
understand. It is so geek that even your example below makes no sense. The most
simple way to make a config will always be that 1 line means 1 thing and with a
syntax "option value" or "option=value" and where the order of the options is
not important. It just cannot be simpler than that.
I remember old email smtp programs with this kind of context dependent syntax.
They were impossible to configure by hand. You had to use a GUI or rely on the
defaults. YML and XML formats are made for machines. Not for humans
When you look at the updates in the new Motion version an important improvement
is that many options changed from cryptic names to names that makes sense and
are consistant. That is a great improvement even if the upgrade will require a
rewrite of the config file.
The lightswitch option is one of the original Jeroen options and it never
really worked very well probably because many of the other features that limit
the pixels detected as Motion are applied in the wrong order of the lightswitch
setting and in the context of the reference frame. The lightswitch feature
should probably have been implemented so it calculates the average intensity of
the entire image and detect when it changes more than a specific value.
Counting changed pixels is probably not the right way. So it is not as much the
pixels vs percentage that is the problem. The feature is simply not working
very well. A candidate for improvement and for a lot of practical
experimentation. If it gets changed to detecting intensity level a value
between 0 and 255 would be the technical correct range. And then give the
feature a better name.
Kenneth
On 12 Aug 2016, at 08:00, John Baker <[email protected]> wrote:
>> This goes back to what was said earlier and how large we want to make
>> motion. Currently it is lean and complex to setup, but that gives it an
>> advantage in a reduced environment
>
> Mike, i agree the motion binary should be kept simple, but an easy to
> follow configuration does not have to mean a less lean binary, ie.
>
> 1. The value for lightswitch should be 'greater for more effect', not
> 'less for more'. That's not lots of extra coding, but probably 1 / at
> some point.
>
> 2. Use a YAML parser to read a YAML formatted configuration file, which
> I assume motion can link to, and hence eject all of the custom code to
> read the config file and assemble structures (if that's how it works -
> it works that way in python), which in turn makes config easier to read,
> ie.
>
> # Include another file with a set of shared options
> include: globals.yml
>
> detection:
> # Comment ...
> lightswitch: 20
> threshold: ....
>
> output:
> snapshots:
> directory: /tmp/camera/snapsots
> format: yyyy-MM-dd.jpg
> timelapse:
> # Every X mlliseconds
> frequency: 1000
> directory: ...
> format: ...
> detection:
> directory: ...
>
> and so on.
>
> Simply providing a structure to configuration will make it /so/ much
> easier to read/follow, and should reduce hand cranked code too.
>
>
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Motion-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/motion-user
> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
------------------------------
Message: 2
Date: Fri, 12 Aug 2016 16:27:44 +0100
From: John Baker <[email protected]>
Subject: Re: [Motion-user] lightswitch
To: [email protected]
Message-ID:
<1471015664.1611849.693614409.32b71...@webmail.messagingengine.com>
Content-Type: text/plain
Kenneth
Sorry, but structuring config files (you mentioned XML, very old school)
is fairly typical. The problem with the key=value approach is that it's
not simple to follow. You may think it's simple, because you know the
structure very well, but to a mere new user, it's terrible.
I can see that structure is already implied with prefixed keys.
ffmeg_this and ffmeg_that. What's wrong with:
ffmeg:
option1: xx
option2: yy
Easier on the eye, all options in one place, etc. It's more obviously a
better solution when one starts considering why there are motion
settings in one place, and directory locations / formats in another.
They are all related, to motion, so should be grouped :)
I only picked YAML as it's more user friendly on the eye than JSON,
which would of course be the markup for a REST interface.
If I were any good at C, I'd get on with it. But I'm not. However, "ini
file" like configuration belongs in the year 1993, and a well structured
config file, read via a modern parser, validated by a well defined
schema, into a Python-like dictionary structure, would reduce lines of
code.
Ref lightswitch: I'm finding higher values reduce videos triggered by
light, not smaller values as discussed yesterday.
John
On Fri, Aug 12, 2016, at 04:15 PM, Kenneth Lavrsen wrote:
> John
>
> I totally fail to understand how that YAML format can be simpler for a
> human to understand. It is so geek that even your example below makes no
> sense. The most simple way to make a config will always be that 1 line
> means 1 thing and with a syntax "option value" or "option=value" and
> where the order of the options is not important. It just cannot be
> simpler than that.
>
> I remember old email smtp programs with this kind of context dependent
> syntax. They were impossible to configure by hand. You had to use a GUI
> or rely on the defaults. YML and XML formats are made for machines. Not
> for humans
>
> When you look at the updates in the new Motion version an important
> improvement is that many options changed from cryptic names to names that
> makes sense and are consistant. That is a great improvement even if the
> upgrade will require a rewrite of the config file.
>
> The lightswitch option is one of the original Jeroen options and it never
> really worked very well probably because many of the other features that
> limit the pixels detected as Motion are applied in the wrong order of the
> lightswitch setting and in the context of the reference frame. The
> lightswitch feature should probably have been implemented so it
> calculates the average intensity of the entire image and detect when it
> changes more than a specific value. Counting changed pixels is probably
> not the right way. So it is not as much the pixels vs percentage that is
> the problem. The feature is simply not working very well. A candidate for
> improvement and for a lot of practical experimentation. If it gets
> changed to detecting intensity level a value between 0 and 255 would be
> the technical correct range. And then give the feature a better name.
>
> Kenneth
>
> On 12 Aug 2016, at 08:00, John Baker <[email protected]> wrote:
>
> >> This goes back to what was said earlier and how large we want to make
> >> motion. Currently it is lean and complex to setup, but that gives it an
> >> advantage in a reduced environment
> >
> > Mike, i agree the motion binary should be kept simple, but an easy to
> > follow configuration does not have to mean a less lean binary, ie.
> >
> > 1. The value for lightswitch should be 'greater for more effect', not
> > 'less for more'. That's not lots of extra coding, but probably 1 / at
> > some point.
> >
> > 2. Use a YAML parser to read a YAML formatted configuration file, which
> > I assume motion can link to, and hence eject all of the custom code to
> > read the config file and assemble structures (if that's how it works -
> > it works that way in python), which in turn makes config easier to read,
> > ie.
> >
> > # Include another file with a set of shared options
> > include: globals.yml
> >
> > detection:
> > # Comment ...
> > lightswitch: 20
> > threshold: ....
> >
> > output:
> > snapshots:
> > directory: /tmp/camera/snapsots
> > format: yyyy-MM-dd.jpg
> > timelapse:
> > # Every X mlliseconds
> > frequency: 1000
> > directory: ...
> > format: ...
> > detection:
> > directory: ...
> >
> > and so on.
> >
> > Simply providing a structure to configuration will make it /so/ much
> > easier to read/follow, and should reduce hand cranked code too.
> >
> >
> >
> > ------------------------------------------------------------------------------
> > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> > patterns at an interface-level. Reveals which users, apps, and protocols
> > are
> > consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> > J-Flow, sFlow and other flows. Make informed decisions using capacity
> > planning reports. http://sdm.link/zohodev2dev
> > _______________________________________________
> > Motion-user mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/motion-user
> > http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and
> traffic
> patterns at an interface-level. Reveals which users, apps, and protocols
> are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Motion-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/motion-user
> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
------------------------------
Message: 3
Date: Fri, 12 Aug 2016 18:05:02 +0200
From: Kenneth Lavrsen <[email protected]>
Subject: Re: [Motion-user] lightswitch
To: Motion discussion list <[email protected]>
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
I do not follow your logic.
First - you can group the many options in many ways.
I know because I have tried to group them when we wrote Motion and again when
we wrote the documentation.
You can group all the database options together.
Or you can put the database option that relates to pictures with the picture
settings and database options that relates to movies with the movie options.
Different people will group same set of options in different ways. It is not as
logical as you may think.
And if I have a line saying
filename: xyz%2
Then I like that it means the same no matter where I put it.
The default Motion.conf file is written so options are grouped today. Grouped
in the way we thought it was logical. But the option names are made so you
could move it to whereever you want and it will still work. It is also made so
if you write the configs from the webcontrol interface, then the configs get
cleaned up. All options are sorted in their groups and the help texts and group
headers are reapplied.
I think that is very user friendly.
It is not the format of the config that created the problem for the original
poster which was a problem with lightswitch. No config format would have
improved that. Lightswitch is confusing because it is a badly implemented
feature which does not work as described and hardly works at all
Kenneth
> On 12 Aug 2016, at 17:27, John Baker <[email protected]> wrote:
>
> Kenneth
>
> Sorry, but structuring config files (you mentioned XML, very old school)
> is fairly typical. The problem with the key=value approach is that it's
> not simple to follow. You may think it's simple, because you know the
> structure very well, but to a mere new user, it's terrible.
>
> I can see that structure is already implied with prefixed keys.
> ffmeg_this and ffmeg_that. What's wrong with:
>
> ffmeg:
> option1: xx
> option2: yy
>
> Easier on the eye, all options in one place, etc. It's more obviously a
> better solution when one starts considering why there are motion
> settings in one place, and directory locations / formats in another.
> They are all related, to motion, so should be grouped :)
>
> I only picked YAML as it's more user friendly on the eye than JSON,
> which would of course be the markup for a REST interface.
>
> If I were any good at C, I'd get on with it. But I'm not. However, "ini
> file" like configuration belongs in the year 1993, and a well structured
> config file, read via a modern parser, validated by a well defined
> schema, into a Python-like dictionary structure, would reduce lines of
> code.
>
> Ref lightswitch: I'm finding higher values reduce videos triggered by
> light, not smaller values as discussed yesterday.
>
>
> John
>
>> On Fri, Aug 12, 2016, at 04:15 PM, Kenneth Lavrsen wrote:
>> John
>>
>> I totally fail to understand how that YAML format can be simpler for a
>> human to understand. It is so geek that even your example below makes no
>> sense. The most simple way to make a config will always be that 1 line
>> means 1 thing and with a syntax "option value" or "option=value" and
>> where the order of the options is not important. It just cannot be
>> simpler than that.
>>
>> I remember old email smtp programs with this kind of context dependent
>> syntax. They were impossible to configure by hand. You had to use a GUI
>> or rely on the defaults. YML and XML formats are made for machines. Not
>> for humans
>>
>> When you look at the updates in the new Motion version an important
>> improvement is that many options changed from cryptic names to names that
>> makes sense and are consistant. That is a great improvement even if the
>> upgrade will require a rewrite of the config file.
>>
>> The lightswitch option is one of the original Jeroen options and it never
>> really worked very well probably because many of the other features that
>> limit the pixels detected as Motion are applied in the wrong order of the
>> lightswitch setting and in the context of the reference frame. The
>> lightswitch feature should probably have been implemented so it
>> calculates the average intensity of the entire image and detect when it
>> changes more than a specific value. Counting changed pixels is probably
>> not the right way. So it is not as much the pixels vs percentage that is
>> the problem. The feature is simply not working very well. A candidate for
>> improvement and for a lot of practical experimentation. If it gets
>> changed to detecting intensity level a value between 0 and 255 would be
>> the technical correct range. And then give the feature a better name.
>>
>> Kenneth
>>
>> On 12 Aug 2016, at 08:00, John Baker <[email protected]> wrote:
>>
>>>> This goes back to what was said earlier and how large we want to make
>>>> motion. Currently it is lean and complex to setup, but that gives it an
>>>> advantage in a reduced environment
>>>
>>> Mike, i agree the motion binary should be kept simple, but an easy to
>>> follow configuration does not have to mean a less lean binary, ie.
>>>
>>> 1. The value for lightswitch should be 'greater for more effect', not
>>> 'less for more'. That's not lots of extra coding, but probably 1 / at
>>> some point.
>>>
>>> 2. Use a YAML parser to read a YAML formatted configuration file, which
>>> I assume motion can link to, and hence eject all of the custom code to
>>> read the config file and assemble structures (if that's how it works -
>>> it works that way in python), which in turn makes config easier to read,
>>> ie.
>>>
>>> # Include another file with a set of shared options
>>> include: globals.yml
>>>
>>> detection:
>>> # Comment ...
>>> lightswitch: 20
>>> threshold: ....
>>>
>>> output:
>>> snapshots:
>>> directory: /tmp/camera/snapsots
>>> format: yyyy-MM-dd.jpg
>>> timelapse:
>>> # Every X mlliseconds
>>> frequency: 1000
>>> directory: ...
>>> format: ...
>>> detection:
>>> directory: ...
>>>
>>> and so on.
>>>
>>> Simply providing a structure to configuration will make it /so/ much
>>> easier to read/follow, and should reduce hand cranked code too.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
>>> patterns at an interface-level. Reveals which users, apps, and protocols
>>> are
>>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>>> planning reports. http://sdm.link/zohodev2dev
>>> _______________________________________________
>>> Motion-user mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/motion-user
>>> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>>
>> ------------------------------------------------------------------------------
>> What NetFlow Analyzer can do for you? Monitors network bandwidth and
>> traffic
>> patterns at an interface-level. Reveals which users, apps, and protocols
>> are
>> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
>> J-Flow, sFlow and other flows. Make informed decisions using capacity
>> planning reports. http://sdm.link/zohodev2dev
>> _______________________________________________
>> Motion-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/motion-user
>> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
>
> ------------------------------------------------------------------------------
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> _______________________________________________
> Motion-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/motion-user
> http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
------------------------------
Message: 4
Date: Fri, 12 Aug 2016 21:27:19 +0200
From: Michel WILS <[email protected]>
Subject: [Motion-user] pb gcc : compile build motion on a raspberry 3
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Hello,
I buy a Raspberry pi 3.
I've gcc (Raspbian 4.9.2-10) 4.9.2
I'm compiling motion : motion Unofficial-Git-2caced3 because I use RTSP
When I submit : ./configure , I've this error :
Detected CPU: ARMv7 Processor rev 4 (v7l)
*** Error in `gcc': double free or corruption (top): 0x013cf5e8 ***
./configure: line 6778: 7080 Aborted ( $COMPILER
$CPU_OPTIONS -o $TMPO $TMPC ) 2>&1
Could you help me please ?
Frendly.
M WILS.
------------------------------
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
------------------------------
_______________________________________________
Motion-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/motion-user
End of Motion-user Digest, Vol 123, Issue 36
********************************************
