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 (Steven Haigh)
----------------------------------------------------------------------
Message: 1
Date: Thu, 07 Apr 2022 01:35:01 +1000
From: Steven Haigh <[email protected]>
To: Motion discussion list <[email protected]>
Subject: Re: [Motion-user] Configuration help
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
You might be right.... The code to write the picture is here:
<https://github.com/Motion-Project/motion/blob/master/src/picture.c#L824>
I actually wonder if line 827 on that file shouldn't unlink a file if
it already exists.... then the open / write / close. It seems like that
would be the sane way to overwrite files :|
I was trying to find the code that does the snapshots - but I haven't
been able to find that as yet :\
--
Steven Haigh
? [email protected] <mailto:[email protected]>
? https://www.crc.id.au <https://www.crc.id.au/>
On Wed, Apr 6 2022 at 10:11:13 -0500, Roger Heflin
<[email protected]> wrote:
> Well, the posix comment might apply if a new file/inode was being
> created. You seem to be assuming that a new file must be getting
> created, it does not have to be creating a new file, and it appears
> to be re-using the same inode.
>
> I have not looked at the code to see how the write is being done, but
> the inode is not changing, so am guessing it is some sort of append
> type open and a seek to the start of the file since that would act
> this way. From a simple copy test in a loop from the file being
> updated at 15fps, I get 50% of the files with all data and 50% of the
> files with no data (0-size).
>
> Now if I do the copy with a dd using a 4k buffer (standard io if you
> don't make calls to adjust the settings) I get files of various sizes
> some of which are non-zero size and missing parts of the image.
>
> However they are doing the open may not be wise, or there may be a
> reason for them doing the open that way, but with the current way the
> open is being done it won't appear to work.
>
>
>
> On Wed, Apr 6, 2022 at 8:51 AM Steven Haigh <[email protected]
> <mailto:[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] <mailto:[email protected]>
>> ? https://www.crc.id.au <https://www.crc.id.au/>
>>
>> On Tue, Apr 5 2022 at 09:20:55 -0500, Roger Heflin
>> <[email protected] <mailto:[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]
>>> <mailto:[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] <mailto:[email protected]>
>>>> ? https://www.crc.id.au <https://www.crc.id.au/>
>>>>
>>>> On Tue, Apr 5 2022 at 08:41:06 -0500, Roger Heflin
>>>> <[email protected] <mailto:[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]
>>>>> <mailto:[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] <mailto:[email protected]>
>>>>>> ? https://www.crc.id.au <https://www.crc.id.au/>
>>>>>>
>>>>>> On Tue, Apr 5 2022 at 08:19:37 -0500, Roger Heflin
>>>>>> <[email protected] <mailto:[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]
>>>>>>> <mailto:[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
>>>>>>>>
>>>>>>>> <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
>>>>>>>>
>>>>>>>> ? [email protected] <mailto:[email protected]>
>>>>>>>> ? https://www.crc.id.au <https://www.crc.id.au/>
>>>>>>>> _______________________________________________
>>>>>>>> Motion-user mailing list
>>>>>>>> [email protected]
>>>>>>>> <mailto:[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]
>>>>>> <mailto:[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 10
********************************************