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: Configuration help (Steven Haigh)
----------------------------------------------------------------------
Message: 1
Date: Wed, 06 Apr 2022 23:51:26 +1000
From: Steven Haigh <net...@crc.id.au>
To: Roger Heflin <roger.hef...@gmail.com>
Cc: Motion discussion list <motion-user@lists.sourceforge.net>
Subject: Re: [Motion-user] Configuration help
Message-ID: <qt7x9r.u13ybf88jn...@crc.id.au>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
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
? net...@crc.id.au <mailto:net...@crc.id.au>
? https://www.crc.id.au <https://www.crc.id.au/>
On Tue, Apr 5 2022 at 09:20:55 -0500, Roger Heflin
<roger.hef...@gmail.com> 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 <net...@crc.id.au
> <mailto:net...@crc.id.au>> 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
>>
>> ? net...@crc.id.au <mailto:net...@crc.id.au>
>> ? https://www.crc.id.au <https://www.crc.id.au/>
>>
>> On Tue, Apr 5 2022 at 08:41:06 -0500, Roger Heflin
>> <roger.hef...@gmail.com <mailto:roger.hef...@gmail.com>> 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
>>> <motion-user@lists.sourceforge.net
>>> <mailto:motion-user@lists.sourceforge.net>> 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
>>>>
>>>> ? net...@crc.id.au <mailto:net...@crc.id.au>
>>>> ? https://www.crc.id.au <https://www.crc.id.au/>
>>>>
>>>> On Tue, Apr 5 2022 at 08:19:37 -0500, Roger Heflin
>>>> <roger.hef...@gmail.com <mailto:roger.hef...@gmail.com>> 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
>>>>> <motion-user@lists.sourceforge.net
>>>>> <mailto:motion-user@lists.sourceforge.net>> 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
>>>>>>
>>>>>> <http://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
>>>>>>
>>>>>> <http://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
>>>>>>
>>>>>> ? net...@crc.id.au <mailto:net...@crc.id.au>
>>>>>> ? https://www.crc.id.au <https://www.crc.id.au/>
>>>>>> _______________________________________________
>>>>>> Motion-user mailing list
>>>>>> Motion-user@lists.sourceforge.net
>>>>>> <mailto:Motion-user@lists.sourceforge.net>
>>>>>> <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
>>>> Motion-user@lists.sourceforge.net
>>>> <mailto:Motion-user@lists.sourceforge.net>
>>>> <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
Motion-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/motion-user
------------------------------
End of Motion-user Digest, Vol 190, Issue 7
*******************************************
