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: Configuration help (Matthew Rench)
----------------------------------------------------------------------
Message: 1
Date: Wed, 6 Apr 2022 10:16:29 -0500
From: Matthew Rench <[email protected]>
To: Motion discussion list <[email protected]>
Subject: Re: [Motion-user] Configuration help
Message-ID:
<cag6tzm6fvnhco2ynydtjrt5o+ji9tizyxjnnd-pscaecxuf...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Steven,
Just for the record, POSIX compliant operating systems will change the
> inode that a new file lives in
[...]
> As such, the open + write + close should happen on a different inode when
> overwriting a file - especially if another process contains an active file
> handle on the old inode.
I think this is true in the case where a file is unlinked, and then a new
file is created with the same name. But it does not seem to be true for an
existing file that is opened, even if another process has it open. You can
see this, for example, by running:
mdr@mithrandir: touch foo
> mdr@mithrandir: ls -i foo
> 17723369 foo
> mdr@mithrandir: perl -e 'open $F, "foo"; sleep 60' &
> [1] 28407
> mdr@mithrandir: echo asdfasdf > foo
> mdr@mithrandir: ls -i foo
> 17723369 foo
> mdr@mithrandir: rm foo ; echo asdfasdf > foo
> mdr@mithrandir: ls -i foo
> 17723370 foo
That being said, the corrupted snapshot I provided was directly from the
> filesystem - not from the ingest method at all - so its being written to
> disk like that.
If a snapshot file is read directly from the filesystem in the middle of
the "open/write/close" sequence, it could easily appear corrupt.
mdr
On Wed, Apr 6, 2022 at 8:53 AM Steven Haigh via Motion-user <
[email protected]> wrote:
> Just for the record, POSIX compliant operating systems will change the
> inode that a new file lives in - meaning that if you open a file while the
> file is being overwritten, the old inode already opened will be invalidated
> for the new file, but still persist until all file handles using the old
> inode are closed. At this point, the old inode is discarded as free.
>
> This means as long as the file open occurs before the write, you'll get
> the old contents of the file - regardless of when you read the rest of that
> file.
>
> As such, the open + write + close should happen on a different inode when
> overwriting a file - especially if another process contains an active file
> handle on the old inode.
>
> That being said, the corrupted snapshot I provided was directly from the
> filesystem - not from the ingest method at all - so its being written to
> disk like that.
>
> I have no idea why :(
> --
> Steven Haigh ? [email protected] ? https://www.crc.id.au
>
> On Tue, Apr 5 2022 at 09:20:55 -0500, Roger Heflin <[email protected]>
> wrote:
>
> ok. There is *NO* way to reliably read a file in on a file change that is
> getting re-written often. A file open+write+close is not an Atomic
> operation, it is at least 3 separate operations (it it is only 3 if the
> code writing the is carefully crafted to write the data as a single write),
> and the change will trigger on the open, and you will open the file before
> the writing is done (or possibly even started).
>
> You probably then need to have a separate snapshot stream using the
> high-res and doing a frame a second, and you likely need to add seconds to
> the file (so 60 files being written round-robin) and have the deep stack
> reading the file from a second ago, or using the file change trigger + a
> usleep to delay it enough to allow the write/close to finish.
>
> I was using inotify to spawn off a script on a file change and then copy
> that file to someplace else. The inotify was pretty often spawning the
> script and starting the copy of the file data before the file was finished
> writing and the files I was reading were not getting re-written, so I don't
> have the potential issue of reading the file a bit slow and getting caught
> on the next work.
>
>
>
> On Tue, Apr 5, 2022 at 9:02 AM Steven Haigh <[email protected]> wrote:
>
>> The process that I was using to pull the image into deepstack will do so
>> on a file change - so after the data has been written to a file.
>>
>> I've added the image as an attachment - because it seems to be the same
>> file written again and again...
>>
>> The actual picture saved by both picture_output and picture_output_motion
>> are fine.
>>
>> I do note however that picture_output is written at 15 fps - which is
>> kinda overkill for using the file changed trigger - as even though
>> deepstack is GPU accelerated, it can't do 15fps :D
>>
>> I also validated the RTMP endpoint in VLC - and that plays properly - so
>> the problem isn't there...
>>
>> I also get the correct image via:
>> - http://172.31.1.89:8001/1/current (single image)
>> - http://172.31.1.89:8001/1/stream (MJPEG stream)
>>
>> that being said, it only seems like the snapshot is of the low resolution
>> stream as well - not from netcam_high_url.
>>
>> As such, it seems like I have to use the 'picture_output' option - but
>> then I'm still stuck with the framerate problems...
>> --
>> Steven Haigh ? [email protected] ? https://www.crc.id.au
>>
>> On Tue, Apr 5 2022 at 08:41:06 -0500, Roger Heflin <
>> [email protected]> wrote:
>>
>> Do one of the cameras for the 1fps capture (but the snapshot should work
>> anyway).
>>
>> My snapshot filename definition looks like this:
>> snapshot_filename ./snapshots/%Y%m%d/%Y-%m-%d-%H%M%S-%v-%q
>> If you are using the same file name and re-writing it every second and
>> reading it into something else the is a good chance that you will read the
>> file at the wrong time a significant amount of the time. You may want to
>> have the filename just write out minutes and seconds in the name such that
>> the files get re-written each hour, or even just used seconds and let the
>> file get re-written every 60 seconds and have the other tool reading a
>> second behind so that it gets a complete file. I had some code that used
>> inotify and copied the file on the create and often that separate process
>> would copy the file before the file was completely written. I had to put
>> some delay in for it to work.
>>
>> or, do a 2nd camera with the low-res for detection + high res for capture.
>>
>> On the corruption, have you viewed the live camera feed from motion to
>> see if that is also corrupted from time to time?
>>
>> There are some camera models/vendors that don't handle packet loss at
>> all, and lose frames.
>>
>> On Tue, Apr 5, 2022 at 8:27 AM Steven Haigh via Motion-user <
>> [email protected]> wrote:
>>
>>> I was trying not to do it that way - as performing motion detect on the
>>> high resolution stream takes up 40-50% of a CPU core on my system...
>>>
>>> Running motion detect on the low resolution stream seems to be fine -
>>> but has the problem that I can't trigger captures from the high resolution
>>> stream based on motion from the low resolution one.
>>>
>>> I tried with the 'snapshot' option, but the JPG it seems to produce is
>>> garbled junk :\
>>>
>>> Right now, for the picture, I'm using:
>>>
>>> picture_output on
>>> picture_output_motion off
>>> picture_quality 50
>>> picture_filename /tmp/cameras/front_door
>>>
>>> ## This also kills the /1/stream down to 1fps - which is not ideal.
>>> #minimum_frame_time 1
>>>
>>> ## The below outputs a corrupted JPG as the snapshot...
>>> #snapshot_interval 1
>>> #snapshot_filename /tmp/cameras/front_door_snapshot
>>>
>>>
>>> --
>>> Steven Haigh ? [email protected] ? https://www.crc.id.au
>>>
>>> On Tue, Apr 5 2022 at 08:19:37 -0500, Roger Heflin <
>>> [email protected]> wrote:
>>>
>>> You should be able to setup 2 cameras in motion separately handling the
>>> 2 streams.
>>>
>>> I have a low-res URL going to one motion thread/camera that captures
>>> 2fps, and I have a separate thread using a different URL on the same camera
>>> (high resolution) that is used for motion capture.
>>>
>>> So long as the camera allows you should be able to use 2 of the same
>>> stream URL in different threads for the same camera.
>>>
>>> On Mon, Apr 4, 2022 at 11:52 PM Steven Haigh via Motion-user <
>>> [email protected]> wrote:
>>>
>>>> Hi all,
>>>>
>>>> I'm having a hell of a time trying to do some image processing with
>>>> motion + nodered + home assistant + deepstack.
>>>>
>>>> I have motion configured as follows:
>>>> netcam_url rtmp://
>>>> 172.31.1.245/bcs/channel0_ext.bcs?channel=0&stream=2&user=x&password=x
>>>> netcam_params framerate=30,capture_rate=30
>>>> width=896
>>>> height=672
>>>>
>>>> netcam_high_url rtmp://
>>>> 172.31.1.245/bcs/channel0_main.bcs?channel=0&stream=0&user=x&password=x
>>>> netcam_high_params framerate=15,capture_rate=15
>>>>
>>>> The camera outputs match the settings above - but the resolution on
>>>> netcam_high_url is 2560x1920.
>>>>
>>>> I'm trying to output the netcam_url via the motion API url /1/stream
>>>> and /1/current to show in the Home Assistant dashboard and feed as a MJPEG
>>>> camera.
>>>>
>>>> I'm also trying to output 1fps as a JPG to a file as /tmp/snapshot.jpg
>>>> so that I can ingest that into deepstack via nodered and do object
>>>> recognition.
>>>>
>>>> It seems that no matter what I do, I either destroy motion by setting
>>>> minimum_frame_time to 1, or get the 1fps output with that option - but
>>>> destroy the stream output.
>>>>
>>>> Is there a way I can ratelimit just the saving of pictures to 1 per
>>>> second from the netcam_high_url input?
>>>>
>>>> I've done every possible combination of configuration options, but just
>>>> can't seem to get this happening.
>>>> --
>>>> Steven Haigh ? [email protected] ? https://www.crc.id.au
>>>> _______________________________________________
>>>> Motion-user mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/motion-user
>>>> https://motion-project.github.io/
>>>>
>>>> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
>>>
>>> _______________________________________________
>>> Motion-user mailing list
>>> [email protected]
>>> https://lists.sourceforge.net/lists/listinfo/motion-user
>>> https://motion-project.github.io/
>>>
>>> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
>>
>> _______________________________________________
> Motion-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/motion-user
> https://motion-project.github.io/
>
> Unsubscribe: https://lists.sourceforge.net/lists/options/motion-user
-------------- next part --------------
An HTML attachment was scrubbed...
------------------------------
------------------------------
Subject: Digest Footer
_______________________________________________
Motion-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/motion-user
------------------------------
End of Motion-user Digest, Vol 190, Issue 9
*******************************************
