Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: Gordon <gcom@tr...> - 2005-08-17 15:21:38
|
I just noticed the 3.1.x MAIL option has been replaced with the ON_EVENT_START option in 3.2.x. Could someone suggest a simple script or program to call, please? I only need to send a simple text email message (no images attached). The MotionMail listed in Related Projects appears to be overkill for this task. I am guessing one advantage here will be the ability to change the email message text to indicate the camera (thread) detecting motion. This was not possible with the MAIL option in 3.1.x as far as I could tell. thanks in advance - Gordon |
|
From: Christophe GRENIER <grenier@cg...> - 2005-08-17 15:36:10
Attachments:
on_movie_start.pl
on_movie_end.pl
|
On Wed, 17 Aug 2005, Gordon wrote:
> I just noticed the 3.1.x MAIL option has been replaced with the
> ON_EVENT_START option in 3.2.x. Could someone suggest a simple script or
> program to call, please? I only need to send a simple text email message (no
> images attached). The MotionMail listed in Related Projects appears to be
> overkill for this task.
>
> I am guessing one advantage here will be the ability to change the email
> message text to indicate the camera (thread) detecting motion. This was not
> possible with the MAIL option in 3.1.x as far as I could tell.
Please find two small Perl scripts I am using to send email
on event start and on event end. You need to install Mail::Sender perl
module first (cpan, install Mail::Sender, exit)
Remember to modify the email address in the scripts.
Regards,
Christophe
---------------------------------------------------------------------
,-~~-.___. ._.
/ | ' \ | |"""""""""| -= GRENIER Christophe =-
( ) 0 | | |
\_/-, ,----' | | |
==== !_!--v---v--" http://www.cgsecurity.org
/ \-'~; |""""""""|
/ __/~| ._-""|| | Email: grenier@...
=( _____|_|____||________|
--------------------------------------------------------------------- |
|
From: aaron barrus <as_barrus@ya...> - 2005-08-17 16:06:34
|
Hi folks, When I install 3.2.3 pointed to my lumenera network camera, I see the following: # motion -s [0] Processing thread 0 - config file motion.conf [0] Motion running in setup mode. [0] Thread device: http://10.0.0.57/cgi-bin/video?type=lumenera-mjpeg0&framerate=5 input -1 [1] Thread is from motion.conf [1] Waiting for threads to finish, pid: 7744 [1] motion-httpd/3.2.3 running, accepting connections [1] Thread started [1] motion-httpd: waiting for data on port TCP 8080 [1] Camera thread starting... [1] Received first header [1] Received first header [1] Received first header [1] Received first header [1] Received first header [1] Received first header [1] Received first header [1] Streaming camera [1] Boundary string ["-lumenera"] No additional log is created after this point. The previous version I had been using was 3.2.1, in which I modified netcam.c to look for a header with "multipart/mixed". This was documented in the bug report at http://www.lavrsen.dk/twiki/bin/view/Motion/BugReport2005x05x06x174416. The change was included in builds >= 3.2.1, so I doubt this is really the problem - but just worth mentioning. Any ideas on where it's getting stuck now? Thanks! Aaron __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: William M. Brack <wbrack@mm...> - 2005-08-17 17:55:30
|
aaron barrus said: > Hi folks, > > When I install 3.2.3 pointed to my lumenera network camera, I see the > following: > > # motion -s > [0] Processing thread 0 - config file motion.conf > [0] Motion running in setup mode. > [0] Thread device: > http://10.0.0.57/cgi-bin/video?type=lumenera-mjpeg0&framerate=5 input -1 > [1] Thread is from motion.conf > [1] Waiting for threads to finish, pid: 7744 > [1] motion-httpd/3.2.3 running, accepting connections > [1] Thread started > [1] motion-httpd: waiting for data on port TCP 8080 > [1] Camera thread starting... This much is perfectly normal > [1] Received first header > [1] Received first header > [1] Received first header > [1] Received first header > [1] Received first header > [1] Received first header > [1] Received first header I can't imagine why it's taken this many tries to get the header information which the startup code needs to determine the camera type and the dimensions. > [1] Streaming camera > [1] Boundary string ["-lumenera"] This is normal, and indicates the startup code has made the proper indentification. > No additional log is created after this point. The previous version I had > been using was 3.2.1, > in which I modified netcam.c to look for a header with "multipart/mixed". > This was documented in > the bug report at > http://www.lavrsen.dk/twiki/bin/view/Motion/BugReport2005x05x06x174416. The > change was included in builds >= 3.2.1, so I doubt this is really the problem > - but just worth > mentioning. The new code specifically looks for 'multipart/x-mixed-replace' and 'multipart/mixed' to identify a "streaming" camera. The penultimate line in your pasted log above shows that the string was recognized, and the camera is being treated as a "streaming" type. > Any ideas on where it's getting stuck now? > > Thanks! > > Aaron At this point, no ideas. Could you try running it again, this time with the additional flag "-d 1" (i.e. "# motion -s -d 1") and post the results? That should (hopefully) give some more information as to where the trouble is coming from (you could also try higher "debug levels", but level '1' should be sufficient for now). Bill |
|
From: aaron barrus <as_barrus@ya...> - 2005-08-18 06:31:48
|
> At this point, no ideas. Could you try running it again, this time with the > additional flag "-d 1" (i.e. "# motion -s -d 1") and post the results? That > should (hopefully) give some more information as to where the trouble is > coming from (you could also try higher "debug levels", but level '1' should be > sufficient for now). Grrr . . . No level of debug provides additional output - it is identical to running it without the -d flag. Running with debug=5 on a functioning camera doesn't create any additional debug between "Processing thread 0" and "Boundary string" either. But after that, the functioning one looks like: [1] Boundary string [--video boundary--] [1] Camera handler thread [2] started [1] vid_return_code 6 [1] Raw changes: 307171 - changes after 'EeDdl': 0 - labels: 0 So the lumenera is not getting to the next step of "Camera handler thread [2] started". Thanks for any help you can provide! ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs |
|
From: William M. Brack <wbrack@mm...> - 2005-08-18 17:02:07
|
aaron barrus said: >> At this point, no ideas. Could you try running it again, this time with the >> additional flag "-d 1" (i.e. "# motion -s -d 1") and post the results? That >> should (hopefully) give some more information as to where the trouble is >> coming from (you could also try higher "debug levels", but level '1' should >> be >> sufficient for now). > > Grrr . . . No level of debug provides additional output - it is identical to > running it without > the -d flag. Running with debug=5 on a functioning camera doesn't create any > additional debug > between "Processing thread 0" and "Boundary string" either. But after that, > the functioning one > looks like: > > [1] Boundary string [--video boundary--] > [1] Camera handler thread [2] started > [1] vid_return_code 6 > [1] Raw changes: 307171 - changes after 'EeDdl': 0 - labels: 0 > > So the lumenera is not getting to the next step of "Camera handler thread [2] > started". > > Thanks for any help you can provide! Ah, well - you win some, you lose some :-). Well, we know that the netcam code has gotten through determining that this is a streaming netcam, and we also know that it has *not* gotten through the "header" for the first image from the camera (because at the end of that step it will log "Found image header record"). Now if we can just figure out "why"! The best thing to do at this point is to get a full log of what's being supplied by the camera. Could you please try the diagnostic program at http://www.lavrsen.dk/twiki/bin/view/Motion/MjpegSniffer? If you can edit and compile that program, then run it with ./mjpegsnif > rawfile, then gzip -9 rawfile and attach that to your email, I *think* I should be able to figure it out and fix it. Thanks in advance for your help, and I apologize for the difficulties caused by this problem. Regards, Bill |
|
From: aaron barrus <as_barrus@ya...> - 2005-08-18 18:19:51
|
--- "William M. Brack" <wbrack@...> wrote: > Ah, well - you win some, you lose some :-). Well, we know that the netcam > code has gotten through determining that this is a streaming netcam, and we > also know that it has *not* gotten through the "header" for the first image > from the camera (because at the end of that step it will log "Found image > header record"). Now if we can just figure out "why"! > > The best thing to do at this point is to get a full log of what's being > supplied by the camera. Could you please try the diagnostic program at > http://www.lavrsen.dk/twiki/bin/view/Motion/MjpegSniffer? If you can edit and > compile that program, then run it with ./mjpegsnif > rawfile, then gzip -9 > rawfile and attach that to your email, I *think* I should be able to figure it > out and fix it. > > Thanks in advance for your help, and I apologize for the difficulties caused > by this problem. > > Regards, > > Bill Apologize? Heavens - I'm getting a lot more than I paid for; you make me blush : -) I had to increase the size of the output file from mjpegsnif to 400k because each frame is almost 300k each. Since it would be rude to post a 400k file to an email list, I put it at http://www.camsentry.com/rawfile.gz. Let me know what you think. Thank you for your help! Aaron __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: William M. Brack <wbrack@mm...> - 2005-08-19 07:32:26
|
aaron barrus said: > > Let me know what you think. Thank you for your help! > > Aaron OK, that was better. The basic problem was caused by the "boundary-string" for this camera. The stream header has the string enclosed in quotation marks and (although that is legal according to specs) it is very unusual (no other camera which I have tested had this problem). Anyway, I have fixed that, and it should be available on tomorrow's (i.e. August 20) "daily snap". Please try it when you have the time, and let me know the results. Bill |
|
From: aaron barrus <as_barrus@ya...> - 2005-08-22 16:24:52
|
--- "William M. Brack" <wbrack@...> wrote: > OK, that was better. The basic problem was caused by the "boundary-string" > for this camera. The stream header has the string enclosed in quotation marks > and (although that is legal according to specs) it is very unusual (no other > camera which I have tested had this problem). Anyway, I have fixed that, and > it should be available on tomorrow's (i.e. August 20) "daily snap". Please > try it when you have the time, and let me know the results. > > Bill > Hi Bill, This morning I installed the daily snap motion-20050822-090555. The boundary string being enclosed in quotes is solved and it connected to the netcam successfully. But it appears that the netcam buffer is now filling with duplicate images like I'd seen in an earlier version. My framerate is set to 5, and I'm getting two or three duplicate images at a time. Before it was because the image buffer hadn't filled up in time for the next image comparison, so it just grabbed the last image that was in the buffer and used it. If I grab the individual .jpg files seperately, instead of connecting to the mjpeg stream, the behavior is the same (duplicate images). I reverted back to 3.2.1 and the problem went away again. So it must be something that has changed between 3.2.1 and the latest daily snap. Is there anything I could send to help fix this? Has nobody else experienced this problem? I remember it was a big deal about a year ago. Thanks! Aaron __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: William M. Brack <wbrack@mm...> - 2005-08-22 17:05:56
|
aaron barrus said: > --- "William M. Brack" <wbrack@...> wrote: >> OK, that was better. The basic problem was caused by the "boundary-string" >> for this camera. The stream header has the string enclosed in quotation >> marks >> and (although that is legal according to specs) it is very unusual (no other >> camera which I have tested had this problem). Anyway, I have fixed that, >> and >> it should be available on tomorrow's (i.e. August 20) "daily snap". Please >> try it when you have the time, and let me know the results. >> >> Bill >> > > Hi Bill, > > This morning I installed the daily snap motion-20050822-090555. The boundary > string being > enclosed in quotes is solved and it connected to the netcam successfully. Glad to hear that the first problem is solved! > But it appears that the > netcam buffer is now filling with duplicate images like I'd seen in an earlier > version. My > framerate is set to 5, and I'm getting two or three duplicate images at a > time. Before it was > because the image buffer hadn't filled up in time for the next image > comparison, so it just > grabbed the last image that was in the buffer and used it. > > If I grab the individual .jpg files seperately, instead of connecting to the > mjpeg stream, the > behavior is the same (duplicate images). > > I reverted back to 3.2.1 and the problem went away again. So it must be > something that has > changed between 3.2.1 and the latest daily snap. > > Is there anything I could send to help fix this? Has nobody else experienced > this problem? I > remember it was a big deal about a year ago. > > Thanks! > > Aaron Well, the current handling of netcams is a complete re-write, so it's not too surprising that there will be some differences. With regard to "duplicate images", I would suspect that it is more a problem related to the transfer rate of the data than to the logic of the code. With the "sniff" file which you previously supplied, the actual JPEG image for the first frame had a Content-length of 270,642 bytes. I don't know what kind of a network connection you are using between your camera and the machine running Motion, but that is a lot of data (probably close to 2 megabits by the time HTTP and TCP overhead is included). For your interest, the logic of the current netcam code sets up an independent "thread" to take care of the camera (irrespective of whether it's streaming or not). If it's streaming, the thread fetches the data as fast as it's available; if it's not streaming, the thread requests the next frame as soon as the main Motion loop asks for the current one. When the main Motion loop asks for a frame (which is controlled by your "framerate"), it is given the last complete frame obtained by the camera handling thread. If this last complete frame is a duplicate, it is marked as such (if you run with a non-zero debug level this will be logged as "vid_return_code 6"). If this condition continues for more than 30 seconds (this would likely indicate that the camera has died, or some other service interruption) Motion will supply a "Grey Picture" with some text indicating the condition. I really don't know anything about the Lumenera camera. Would it be reasonable for you to reduce the image size / quality? If not, would it make sense to reduce your framerate? Can you suggest an enhancement to the logic I described which would help? Regards, Bill |
|
From: aaron barrus <as_barrus@ya...> - 2005-08-23 16:32:11
|
--- "William M. Brack" <wbrack@...> wrote: > > <snip> > > When the main Motion loop asks for a frame (which is controlled by your > "framerate"), it is given the last complete frame obtained by the camera > handling thread. If this last complete frame is a duplicate, it is marked as > such (if you run with a non-zero debug level this will be logged as > "vid_return_code 6"). If this condition continues for more than 30 seconds > (this would likely indicate that the camera has died, or some other service > interruption) Motion will supply a "Grey Picture" with some text indicating > the condition. I've been playing with it more today. The problem I had yesterday was that it was actually saving files that were duplicates. I don't know why - I was getting about five frames per second, but two or three of them at a time would be duplicates. I would expect motion to recognize the duplicate (like you say it does), and ignore it and wait until the next frame is available. After your reply I turned on debugging and watched it give me the "vid_return_code 6" message between every frame. But it's not saving the duplicate images anymore, and I can't *make* it do it any more either. If I slow the camera waaaaay down to 1000 ms exposure times (one frame per second), then motion just waits with the "vid_return_code 6" until the next frame is delivered. Just like I'd expect it to. I played with the image size vs. framerate and found that motion gets about five fps with 250k frames at 2048x1536. So I'm leaving it at that for now. The computer and camera are connected via one Cisco 3600 at full duplex / 100mbit, so I can't imagine I could get the LAN speed any higher. > I really don't know anything about the Lumenera camera. Would it be > reasonable for you to reduce the image size / quality? If not, would it make > sense to reduce your framerate? Can you suggest an enhancement to the logic I > described which would help? I was going to suggest that motion drop duplicate frames instead of save them - but since it appears to be doing that, I'm happy. Maybe those duplicates were a fluke?! I can't think of anything I've changed. Motion seems to be doing it's job correctly now. FYI, I've noticed that I can get motion to saturate 100% of CPU time now, where I never could get it over about 50% before. I assume this is because the frame-grabber thread runs in parallel with the motion-comparing thread, and so it can keep the cpu busy comparing frames faster. I'm getting better framerates on netcams with this version than I ever got with previous versions. Aaron ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs |
|
From: Kenneth Lavrsen <kenneth@la...> - 2005-08-25 08:24:46
|
>I've been playing with it more today. The problem I had yesterday was >that it was actually saving >files that were duplicates. I don't know why - I was getting about five >frames per second, but >two or three of them at a time would be duplicates. I would expect motion >to recognize the >duplicate (like you say it does), and ignore it and wait until the next >frame is available. > >After your reply I turned on debugging and watched it give me the >"vid_return_code 6" message >between every frame. But it's not saving the duplicate images anymore, >and I can't *make* it do >it any more either. If I slow the camera waaaaay down to 1000 ms exposure >times (one frame per >second), then motion just waits with the "vid_return_code 6" until the >next frame is delivered. >Just like I'd expect it to. > >I played with the image size vs. framerate and found that motion gets >about five fps with 250k >frames at 2048x1536. So I'm leaving it at that for now. The computer and >camera are connected >via one Cisco 3600 at full duplex / 100mbit, so I can't imagine I could >get the LAN speed any >higher. Motion 3.2.3 has the following feature. JPEG Netcams - Motion tries to fetch an image once every 1/framerate seconds. - When the netcam fails to deliver an image - motion simply copies the previous image to fill in and maintain the framerate. This gives the duplicate images. - If the netcam fails for 30 seconds the duplicate images are replaced by a grey image with an error message MJPEG - Here the netcam sets the pace. Motion receives pictures at the rate the camera decides (and has been set up for). - If Motion is set for a framerate lower than the camera it throw away some of the images. - If Motion is set for a framerate higher than the camera it adds duplicate images. - If the netcam fails for 30 seconds the duplicate images are replaced by a grey image with an error message Now obviously this duplicate image thing may not be 100% smart. So in the next version we try to be more flexible. There is one requirement. We MUST run through the motion main loop once per second and better twice per second. Otherwise certain services such as allowing webcams to connect and maintain the webcam stream will not work. The current two ideas we work with are. JPEG - Motion fetches an image once every 1/framerate - If the camera is slow Motion will WAIT a limited period. - If the period times out Motion will add a copy of the previous image. So only duplicate images when the Netcam gets really slow or disconnected. - If the netcam fails for 30 seconds the duplicate images are replaced by a grey image with an error message MJPEG - Here the netcam sets the pace. Motion receives pictures at the rate the camera decides (and has been set up for). - If Motion is set for a framerate lower than the camera it throw away some of the images. - If Motion is set for a framerate higher than the camera it will wait a certain limited period for the next image to arrive. The arrival of an image will reset the loop timer so that Motion will not try and catch up but just timeshift a little each time it waits. The result is that Motion in reality runs at the framerate of the network camera. - If the netcam fails for 30 seconds the duplicate images are replaced by a grey image with an error message The LIMITED period can be set to different values with different results. I have no plan to make it a configurable parameter. We have been discussing a 1/framerate period. This requires that the framerate of Motion is MAX 1 higher than the mjpeg stream. And it does not leave much time for a delay of a jpeg camera before duplicate images are added. But it does gove more images to feed to a movie file so it does not jump in speed. What I am thinking is better is a fixed 0.5 second timeout. It ensures that the webcam feature works and it makes Motion much easier to setup and will cause much less duplicate images. I think this is the best solution but I am open to oppinions. The code that does the above with 0.5 seconds is available in a daily snapshot. http://www.lavrsen.dk/sources/motion-daily/motion-20050825-101655.tar.gz I would like to hear feedback from Netcam owners on how it runs. Kenneth -- Kenneth Lavrsen, Glostrup, Denmark kenneth@... Home Page - http://www.lavrsen.dk |
|
From: aaron barrus <as_barrus@ya...> - 2005-08-25 16:35:08
|
--- Kenneth Lavrsen <kenneth@...> wrote: > Motion 3.2.3 has the following feature. > > > JPEG Netcams > - Motion tries to fetch an image once every 1/framerate seconds. > - When the netcam fails to deliver an image - motion simply copies the > previous image to fill in and maintain the framerate. This gives the > duplicate images. > - If the netcam fails for 30 seconds the duplicate images are replaced by a > grey image with an error message > > MJPEG > - Here the netcam sets the pace. Motion receives pictures at the rate the > camera decides (and has been set up for). > - If Motion is set for a framerate lower than the camera it throw away some > of the images. > - If Motion is set for a framerate higher than the camera it adds duplicate > images. > - If the netcam fails for 30 seconds the duplicate images are replaced by a > grey image with an error message A couple of questions: The thread that grabs the picture from the netcam (jpeg or mjpeg) is seperate from the thread that processes motion, correct? So if the netcam thread delivers a duplicate image to motion, will motion do the same processing on it? Or when it sees that the image is just a duplicate, will it abort processing on that image and move on? I'd prefer the latter for a few reasons. First (is selfish) I upload the images, and duplicate images are just a waste of bandwidth. Second, when compiling them into video streams, the duplicate images cause an inconsistent playback speed. Third, a netcam will vary it's exposure time from 1ms during daylight to 1000ms (or whatever) at night, and motion should be able to handle this wide range of framerates. > Now obviously this duplicate image thing may not be 100% smart. > So in the next version we try to be more flexible. > There is one requirement. We MUST run through the motion main loop once per > second and better twice per second. Otherwise certain services such as > allowing webcams to connect and maintain the webcam stream will not work. > > The current two ideas we work with are. > > JPEG > - Motion fetches an image once every 1/framerate > - If the camera is slow Motion will WAIT a limited period. > - If the period times out Motion will add a copy of the previous image. So > only duplicate images when the Netcam gets really slow or disconnected. > - If the netcam fails for 30 seconds the duplicate images are replaced by a > grey image with an error message > > MJPEG > - Here the netcam sets the pace. Motion receives pictures at the rate the > camera decides (and has been set up for). > - If Motion is set for a framerate lower than the camera it throw away some > of the images. > - If Motion is set for a framerate higher than the camera it will wait a > certain limited period for the next image to arrive. The arrival of an > image will reset the loop timer so that Motion will not try and catch up > but just timeshift a little each time it waits. The result is that Motion > in reality runs at the framerate of the network camera. > - If the netcam fails for 30 seconds the duplicate images are replaced by a > grey image with an error message > > The LIMITED period can be set to different values with different results. I > have no plan to make it a configurable parameter. We have been discussing a > 1/framerate period. This requires that the framerate of Motion is MAX 1 > higher than the mjpeg stream. And it does not leave much time for a delay > of a jpeg camera before duplicate images are added. But it does gove more > images to feed to a movie file so it does not jump in speed. > > What I am thinking is better is a fixed 0.5 second timeout. It ensures that > the webcam feature works and it makes Motion much easier to setup and will > cause much less duplicate images. I think this is the best solution but I > am open to oppinions. As I said I dislike the duplicate images, and I agree that .5 would avoid them in almost any circumstance, so I like that. When motion asks the netcam thread for the image, and the image isn't available yet, what exactly will wait? Will the parent thread wait for control to return from the netcam? Or will the parent thread continue cycling through the other threads in the meantime? For example, if I have a netcam that increases exposure to 500 ms at night, then will motion stop processing the other cameras while it waits for the netcam thread to return an image for up to .5 seconds? That could be a problem, especially with a mix of cameras all running under the same parent thread. Would it slow down all the other cameras to match the single slowest camera in the group because it keeps stopping on that one waiting for the next image? ____________________________________________________ Start your day with Yahoo! - make it your home page http://www.yahoo.com/r/hs |
|
From: Kenneth Lavrsen <kenneth@la...> - 2005-08-27 12:56:07
|
>A couple of questions: > >The thread that grabs the picture from the netcam (jpeg or mjpeg) is >seperate from the thread that >processes motion, correct? So if the netcam thread delivers a duplicate >image to motion, will >motion do the same processing on it? Or when it sees that the image is >just a duplicate, will it >abort processing on that image and move on? Motion currently does not know if an image from a camera is the same it fetched maybe half a second ago. Can you guarantee that the jpeg from an indoor camera in an office after hours would not keep on sending the same jpeg again and again. We want to be able to connect to the webcam and see for our selves that indeed the picture is there and noone is there. Someone may want to detect that an image suddenly changes and then we want to process every frame to ensure the Motion detection works. >I'd prefer the latter for a few reasons. First (is selfish) I upload the >images, and duplicate >images are just a waste of bandwidth. Second, when compiling them into >video streams, the >duplicate images cause an inconsistent playback speed. Third, a netcam >will vary it's exposure >time from 1ms during daylight to 1000ms (or whatever) at night, and motion >should be able to >handle this wide range of framerates. To know that a jpeg image is the same we have to download it first. Unless you are lucky and the netcam sets some headers with a timestamp. I do not believe we can count on that from all netcams. To save bandwidth you should run your camera in mjpeg mode if possible and set the framerate IN THE CAMERA to the one you want. Then the camera decides when to send an image and it should always be a fresh image from the camera. >As I said I dislike the duplicate images, and I agree that .5 would avoid >them in almost any >circumstance, so I like that. When motion asks the netcam thread for the >image, and the image >isn't available yet, what exactly will wait? Will the parent thread wait >for control to return >from the netcam? Or will the parent thread continue cycling through the >other threads in the >meantime? Each camera thread runs independently from the others. One camera thread waiting does not at all affect the others. http://www.lavrsen.dk/twiki/bin/view/Motion/OverviewOfThreadsInMotion >For example, if I have a netcam that increases exposure to 500 ms at >night, then will motion stop >processing the other cameras while it waits for the netcam thread to >return an image for up to .5 >seconds? That could be a problem, especially with a mix of cameras all >running under the same >parent thread. Would it slow down all the other cameras to match the >single slowest camera in the >group because it keeps stopping on that one waiting for the next image? No. The other cameras continues at full speed. Kenneth -- Kenneth Lavrsen, Glostrup, Denmark kenneth@... Home Page - http://www.lavrsen.dk |
|
From: Peter Holik <peter@ho...> - 2005-08-25 09:49:40
|
About JPEG Netcams: What if a Netcam gives me a jpeg, but this is just the same image as the last one? Imagine we get those jpeg's stored on a public webserver, where the netcam stores the pictures. maybe motion should look at images and compare? cu Peter |
|
From: Kenneth Lavrsen <kenneth@la...> - 2005-08-27 12:36:07
|
At 11:49 2005-08-25, you wrote: >About JPEG Netcams: > >What if a Netcam gives me a jpeg, but this is just the same image as the >last one? > >Imagine we get those jpeg's stored on a public webserver, where the netcam >stores the pictures. > >maybe motion should look at images and compare? > >cu Peter This would mean that Motion would have to download the entire picture anyway and compare it with the previous image. I think in principle it is not very likely that a "real" new picture in jpeg format of the exact same motive and the exact same light would be the exact same jpeg file. There is always a bit of noise in the camera. But with a very low quality setting this could be the case. I want to make sure that Motion does indeed deliver a picture to the webcam or mpeg if one is fetched. If a person passes by a camera and then another person 3 seconds later - and we have a post_capture setting equivalent to 10 seconds - I want to see the 3 second quiet period even if the picture from the camera is so calm that it produced the exact same jpeg. If you get the same jpeg image from your netcam then it is because you sample it too fast. And if your netcam cannot do at least 2 frames per second Motion will fill in duplicate images to ensure that the webcam stream to for example cambozola, Firefox, Palantir etc is maintained and people see the time stamp increasing showing that the connection is alive and working. Motion cannot repair a bad network connection or a too busy netcam. That needs to be addressed in itself. Kenneth -- Kenneth Lavrsen, Glostrup, Denmark kenneth@... Home Page - http://www.lavrsen.dk |
|
From: Peter Holik <peter@ho...> - 2005-08-25 09:53:20
|
> The LIMITED period can be set to different values with different results. I > have no plan to make it a configurable parameter. We have been discussing a > 1/framerate period. This requires that the framerate of Motion is MAX 1 > higher than the mjpeg stream. And it does not leave much time for a delay > of a jpeg camera before duplicate images are added. But it does gove more > images to feed to a movie file so it does not jump in speed. > > What I am thinking is better is a fixed 0.5 second timeout. It ensures that > the webcam feature works and it makes Motion much easier to setup and will > cause much less duplicate images. I think this is the best solution but I > am open to oppinions. why not check the framerate for netcams at vid_start and stop if it differs too much to our framerate? cu Peter |
|
From: Kenneth Lavrsen <kenneth@la...> - 2005-08-27 12:46:09
|
> >why not check the framerate for netcams at vid_start and stop if >it differs too much to our framerate? > >cu Peter The framerate of a netcam can vary with load, with light conditions and other factors. It is not fixed and known when you start Motion. If you happen to stop Motion set for a framerate of 5 and the netcam is currently at 2 because of load, I would not want Motion to refuse to start. I am even thinking about making Motion even more tolerent to errors at startup so you know it always runs after a reboot of a computer. Eg. after a power out. Kenneth -- Kenneth Lavrsen, Glostrup, Denmark kenneth@... Home Page - http://www.lavrsen.dk |
|
From: Gordon <gcom@tr...> - 2005-08-18 08:55:37
|
Thank you for your reply. I would like to try your scripts. My stock Debian Sarge CPAN config has problems connecting to perl.org to get the mail::sender module. I will try to troubleshoot this issue. I would be interested in hearing about any alternative (perhaps non-perl) method as well. Christophe GRENIER wrote: > On Wed, 17 Aug 2005, Gordon wrote: > >> I just noticed the 3.1.x MAIL option has been replaced with the >> ON_EVENT_START option in 3.2.x. Could someone suggest a simple script >> or program to call, please? > Please find two small Perl scripts I am using to send email > on event start and on event end. You need to install Mail::Sender perl > module first (cpan, install Mail::Sender, exit) > Remember to modify the email address in the scripts. > > Regards, > > Christophe |
|
From: Gabor Radics <mail@ra...> - 2005-08-18 17:32:48
|
Hi, I'm simply using the following line in of the threads config file: ON_EVENT_START echo "message" | mail -s "subject" -r "your@..." your@... I can't reach my server now but i think this is how it was. It is very minimalistic but works. Good luck Gabor 2005-08-18, cs keltez=C3=A9ssel 07:08-kor Gordon ezt =C3=ADrta: > Thank you for your reply. I would like to try your scripts. My stock=20 > Debian Sarge CPAN config has problems connecting to perl.org to get the= =20 > mail::sender module. I will try to troubleshoot this issue. >=20 > I would be interested in hearing about any alternative (perhaps=20 > non-perl) method as well. >=20 > Christophe GRENIER wrote: >=20 > > On Wed, 17 Aug 2005, Gordon wrote: > >=20 > >> I just noticed the 3.1.x MAIL option has been replaced with the=20 > >> ON_EVENT_START option in 3.2.x. Could someone suggest a simple scri= pt=20 > >> or program to call, please? >=20 > > Please find two small Perl scripts I am using to send email > > on event start and on event end. You need to install Mail::Sender per= l=20 > > module first (cpan, install Mail::Sender, exit) > > Remember to modify the email address in the scripts. > >=20 > > Regards, > >=20 > > Christophe >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Pract= ices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &= QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5= sf > _______________________________________________ > Motion-user mailing list > Motion-user@... > https://lists.sourceforge.net/lists/listinfo/motion-user > http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome --=20 Gabor Radics <mail@...> |
|
From: Christophe GRENIER <grenier@cg...> - 2005-08-18 18:56:23
|
On Thu, 18 Aug 2005, Gordon wrote:
> Thank you for your reply. I would like to try your scripts. My stock Debian
> Sarge CPAN config has problems connecting to perl.org to get the mail::sender
> module. I will try to troubleshoot this issue.
Just a little note, in on_movie_end.pl, comment the exit at the beginning:
#!/usr/bin/perl -w
use Mail::Sender;
use Fcntl ':flock'; # import LOCK_* constants
use strict;
$|=1; # $OUTPUT_AUTOFLUSH up
#exit 0;
{
---------------------------------------------------------------------
,-~~-.___. ._.
/ | ' \ | |"""""""""| -= GRENIER Christophe =-
( ) 0 | | |
\_/-, ,----' | | |
==== !_!--v---v--" http://www.cgsecurity.org
/ \-'~; |""""""""|
/ __/~| ._-""|| | Email: grenier@...
=( _____|_|____||________|
---------------------------------------------------------------------
|
|
From: Kenneth Lavrsen <kenneth@la...> - 2005-08-18 22:35:42
|
Quoting Gordon <gcom@...>: > Thank you for your reply. I would like to try your scripts. My stock=20 > Debian Sarge CPAN config has problems connecting to perl.org to get the= =20 > mail::sender module. I will try to troubleshoot this issue. If you use the simple shell scripts from the Motion Guide that I suggeste= d in=20 my previous mail you will not need any Perl modules. Kenneth --=20 Kenneth Lavrsen, Glostrup, Denmark kenneth@... Home Page - http://www.lavrsen.dk |
|
From: Kenneth Lavrsen <kenneth@la...> - 2005-08-18 19:28:58
|
At 17:25 2005-08-17, you wrote: >I just noticed the 3.1.x MAIL option has been replaced with the >ON_EVENT_START option in 3.2.x. Could someone suggest a simple script or >program to call, please? I only need to send a simple text email message >(no images attached). The MotionMail listed in Related Projects appears >to be overkill for this task. > >I am guessing one advantage here will be the ability to change the email >message text to indicate the camera (thread) detecting motion. This was >not possible with the MAIL option in 3.1.x as far as I could tell. > >thanks in advance - Gordon When we did the new improved on_xxxx feature and removed mail and sms we took good care making a proposal for very simple scripts that could do both what the old feature did and so much more - by having full flexibility Joerg Weber did the scripts and they are in the Motion Guide. http://www.lavrsen.dk/twiki/bin/view/Motion/MotionGuideBasicFeatures#What_happened_to_mail_and_sms Kenneth -- Kenneth Lavrsen, Glostrup, Denmark kenneth@... Home Page - http://www.lavrsen.dk |
|
From: Gordon <gcom@tr...> - 2005-08-19 03:20:02
|
Thanks...and I have MUCH more reading to do! Your link made me notice that I have to return to the main Guide page to get to the other sections (e.g. Getting it Running, Basic Features, etc.). With no link to continue to the next section at the end of the Installation section, I thought the end of the Installation section was the end of the documentation (as it was with 3.1.x version single page guide). I need to pay closer attention to what I am reading. Back on topic: Joerg Weber's script should work fine. I'll give it a try. - thanks Kenneth Lavrsen wrote: > At 17:25 2005-08-17, you wrote: > >> I just noticed the 3.1.x MAIL option has been replaced with the >> ON_EVENT_START option in 3.2.x. Could someone suggest a simple script >> or program to call, please? I only need to send a simple text email >> message (no images attached). The MotionMail listed in Related >> Projects appears to be overkill for this task. >> >> I am guessing one advantage here will be the ability to change the >> email message text to indicate the camera (thread) detecting motion. >> This was not possible with the MAIL option in 3.1.x as far as I could >> tell. >> >> thanks in advance - Gordon > > > When we did the new improved on_xxxx feature and removed mail and sms we > took good care making a proposal for very simple scripts that could do > both what the old feature did and so much more - by having full flexibility > > Joerg Weber did the scripts and they are in the Motion Guide. > > http://www.lavrsen.dk/twiki/bin/view/Motion/MotionGuideBasicFeatures#What_happened_to_mail_and_sms > > > Kenneth > > |