Motion - Streaming Netcam Without Curl
You are here: Foswiki>Motion Web>StreamingNetcamWithoutCurl (17 Apr 2005, AngelCarpintero)Edit Attach

Streaming Netcam Without Curl

Introduction

This patch was originally submitted by Christopher Price on 14th of August 2004 on the Motion Mailing List

Description of Patch

From the original email

Below is a link to Christophers Home Page. Instead go to his homepage http://www.cs-home.com/~cprice/code/motion/

Update

AngelCarpintero has continued the work on the patch.

He is releasing the newer versions attached to this topic. You are encouraged to test his newer versions instead.

Installation of Patch

Changelog of Patch

  • snap9-pre1

  • Fixed memory leaks.
  • Fixed REQUEST and added REQUEST_AUTH.
  • Added support and avoid segfault if netcam_userpass is not supplied.
  • Fixed problem with DCS-1000W.
  • Checks for http response to get any error ( 401 Auth required , 503 Service Unavailable, etc ... ).

  • snap9-pre2

  • Remove buggy header check.
  • Increase static buffer for non content-lenght.
  • Included in snap10.

  • snap10-pre1

  • Fixed the problem with despeckle memory allocation
  • Added a sanity check for JPEG images
  • Read functions are Fault tolerant ( if no more than 10 wrong images are read).

  • snap10-pre2
  • Avoid duplicated images if framerate is higher than network camera supports.

  • snap10-pre3
  • Added Reconnection feature ( rsynchronizing sockets if connection breaks ).
  • Released with snap11 and motion-3.1.18 stable

  • motion-3.1.18 stable

  • post-2
  • merged with Christopher patch sent to M/L.
  • redessign of mjpg without content-lenght support.
  • fix netcam_read_single().
  • change pthread_cond_wait() by pthread_cond_timedwait().
  • Increase buffer for images ( no content-lenght support).
  • Motion doesn't exit if a thread fails and others threads still are running, only this thread exits.

  • post-3
  • fix possible race condictio with netcam_close()
  • fix bug when boundary_string is not found

  • motion-3.1.19_snap1

  • 3.1.19-netcam
  • Change printf() by fprintf().
  • Cleanup memory netcam (netcam.c , motion.c ).
  • Redesign of reconnection feature.
  • Added debug , conditional compile of xmlrpc-c
  • Fix a non allocated pointer to be freed.
  • Added fix to BugReport2005x02x11x170019
  • Added fix to BugReport2005x02x11x150802
  • Released with motion-3.1.19_snap3

  • motion-3.1.19_snap3

  • motion-3.1.19-pre_snap4
  • Fixed netcam->userpass problem.
  • Added support in configure for athlon64 from BugReport2005x01x30x190907
  • Fixed some gcc warnings.

  • motion-3.1.19-pre2_snap4 include in motion-3.1.19_snap4

TODO List

  • Frozen state , fix possible bugs.

Discussion and Comments


It's not working with AXIS 2100, both patches ( motion-3.1.16-p5.diff and motion-3.1.16-p6.diff ) motion segfault if netcam_userpass is not set and it doesn't allow to specify login:pass in the url ( i.ex http://login:pass@ip/ as is defined in RFC and was working before in motion with curl ). Once you specify :

netcam_url http://192.168.1.10/axis-cgi/jpg/image.cgi

netcam_userpass login:pass

Seems to work but is not able to get any image every time i got that :

Thread0 device: http://192.168.1.10/axis-cgi/jpg/image.cgi input: -1

Netcam: thread 0: starting...

Netcam: jpeg file

Not a JPEG file: starts with 0x00 0x00

and motion exits due this fatal error , Any idea why ? ( i'll try anyway to figure out why ).

Trying to get the mjpeg stream :

netcam_url http://192.168.1.10/axis-cgi/mjpeg/video.cgi

netcam_userpass login:pass

Seems to have the same problem :

Thread0 device: http://192.168.1.10/axis-cgi/mjpg/video.cgi input: -1

Netcam: thread 0: starting...

Netcam: mjpeg stream

JPEG datastream contains no image

That happens when motion checks the jpeg header :

netcam.c:428 jpeg_read_header(&cinfo, TRUE);

-- AngelCarpintero - 29 Sep 2004

Patch is working with my Axis 211. I experienced the same results as AngelCarpintero except that if I left a password off of my guest account on my camera, and included the following in motion.conf:

netcam_userpass

without actually specifying a netcam_userpass, then motion would not segfault. I also notice that motion captures more than 10 frames per second through the mgpg stream, and sometimes the images are duplicates of themselves (ie timestamp on the image is exactly 16:24:23.24 on both images, with exactly the same image output). To counter this problem, I've reduced the framerate to 5 frames per second.

-- asbarrus - 30 Sep 2004
It seems there's some memory corruption , i got segfault in :

(netcam_start function) netcam->response = (struct rbuf *) mymalloc(sizeof(struct rbuf));

That happens when i specify the netcam_userpass , so maybe this memory corruption comes from base64_encode because if i comment the call to this function the segfault doesn't happen. Anyway i still didn't get motion working with this patch and AXIS 2100.

-- AngelCarpintero - 01 Oct 2004

To correct this problem, modify netcam.c as following

     netcam_parse_url (&netcam->url, cnt->conf.netcam_url);
     netcam->userpass =
          (char *) mymalloc(BASE64_LENGTH(strlen(cnt->conf.netcam_userpass))+1);
     {
       char *userpass=mymalloc(strlen(cnt->conf.netcam_userpass)+4);
       /* base64_encode can read 3 bytes after the end of the string,
       initialize it */
       memset(userpass,0,strlen(cnt->conf.netcam_userpass)+4);
       strcpy(userpass,cnt->conf.netcam_userpass);
       base64_encode(userpass, netcam->userpass, strlen(cnt->conf.netcam_userpass));
       free(userpass);
     }
     netcam->response = (struct rbuf *) mymalloc(sizeof(struct rbuf));
     netcam->image[0].buffer_size = 5000;

-- ChristopheGRENIER - 28 Dec 2004

Thanks for the bugfix. I am happy to see that this patch is not completely dead. It is a feature I really would like to see in Motion.

Note that I changed the code above by placing <VERBATIM> </VERBATIM> tags around the code and removing the %BR%. This is a very nice TWiki feature for showing code sniplets.

-- KennethLavrsen - 28 Dec 2004


I've post a patch against last version which fix the problem with AXIS 2100 and other network cameras that doesn't support the field "Content-Length", i.ex :

  • For single image


telnet 192.168.1.10 80
GET /axis-cgi/jpg/image.cgi HTTP/1.0^M
Authorization: Basic bW90aW9uOjEyMzQ1=^M

HTTP/1.0 200 OK^M
Connection: Close^M
Server: Camd^M
Content-Type: image/jpeg^M
<image>^M   
                                                                                                                                                                                                                                                       

  • For MJPEG stream


telnet 192.168.1.10 80
GET /axis-cgi/mjpg/video.cgi HTTP/1.0^M
Authorization: Basic bW90aW9uOjEyMzQ1=^M^M
                                                                                                                                                                                                                                                          
HTTP/1.0 200 OK^M
Connection: Close^M
Server: Camd^M
Content-Type: multipart/x-mixed-replace; boundary=--myboundary^M
                                                                                                                             
--myboundary^M
Content-Type: image/jpeg^M                                                                                                                            
<image>^M
--myboundary^M
Content-Type: image/jpeg^M                                                                                                                            
<image>^M

It's just a test patch i need to clean the code and improve it ... but i guess is a good step to finally include this patch to motion-3.1.18 release. patch it's include in last snapshot ( snap9)

  • Download last snapshot motion-3.1.18_snap9

-- AngelCarpintero - 02 Jan 2005

There's some problems i'm fixing with last snap and cameras with content-length support as Axis 211, this is the stream format:


telnet 192.168.1.10 80
GET /axis-cgi/mjpg/video.cgi?compression=10 HTTP/1.0^M
Authorization: Basic bW90aW9uOjEyMzQ1=^M^M

HTTP/1.0 200 OK^M
Cache-Control: no-cache^M
Pragma: no-cache^M
Expires: Thu, 01 Dec 1994 16:00:00 GMT^M
Connection: close^M
Content-Type: multipart/x-mixed-replace; boundary=--myboundary^M
                                                                                                                                                                                                                                                          
--myboundary^M
Content-Type: image/jpeg^M                                                                                                                       
Content-Length: 56290^M
<image>^M
--myboundary^M
Content-Type: image/jpeg^M
Content-Length: 53940^M
<image>^M
                                                                                                                                                                                                                                   

So the patch against snap9 will be attached here.

-- AngelCarpintero - 05 Jan 2005
Finally i have found a way to enable content-length in Axis 2100 :

http://192.168.1.12/axis-cgi/mjpg/video.cgi?showlength=1 http://192.168.1.12/axis-cgi/jpg/image.cgi?showlength=1

More info Axis HTTP API

-- AngelCarpintero - 05 Jan 2005

The current patch has a bug with DCS-1000W , i've already fixed , so it will be included in the next patch. The stream header for DCS-1000W is :


telnet 192.168.1.10 8001
GET /video.cgi HTTP/1.0^M^M
                                                                                                                             
HTTP/1.0 200 OK^M
Server: Web Server/1.0^M
Auther: Steven Wu^M
MIME-version: 1.0^M
Cache-Control: no-cache^M
Content-Type:multipart/x-mixed-replace;boundary=--video boundary--^M
                                                                                                                             
--video boundary--^M
Content-length: 8311^M
Content-type: image/jpeg^M                                                                                                                             
<image>^M
--video boundary--^M
Content-length: 8632^M
Content-type: image/jpeg^M                                                                                                                             
<image>^M

The stream header for AU-CCIP350 is :


telnet 192.168.1.10 80
GET /video.cgi HTTP/1.1^M
Authorization: Basic bW90aW9uOm1vdGlvbg==^M^M
                                                                                                                             
HTTP/1.1 200 OK^M
Cache-Control: no-cache^M
Content-type: multipart/x-mixed-replace;boundary=--myboundary^M
Date: Mon, 10 Jan 2005 11:32:04 GMT^M
Age: 0^M
Connection: close^M
                                                                                                                             
--myboundary^M
Content-Type: image/jpeg^M
Content-Length: 39998^M
<image>^M
--myboundary^M
Content-Type: image/jpeg^M
Content-Length: 39998^M
<image>^M

Note : ^M is \r\n

-- AngelCarpintero - 10 Jan 2005

I have a Dlink DCS 900W. It looks the same as the 1000W, except I think the 900W has an extra CR-LF before and after the image data. Here is a summary of what I caught with ethereal.

GET /video.cgi HTTP/1.0
User-Agent: Wget/1.9+cvs-stable (Red Hat modified)
Host: localhost:8880
Accept: */*
Connection: Keep-Alive
Authorization: Basic Z3Vlc3Q6

HTTP/1.0 200 OK
Server: Camera Web Server/1.0
Auther: Steven Wu
MIME-version: 1.0
Cache-Control: no-cache
Content-Type:multipart/x-mixed-replace;boundary=--video boundary--

--video boundary--
Content-length: 39646
Content-type: image/jpeg

<image>

--video boundary--
Content-length: 39768
Content-type: image/jpeg

<image>
A 80k ethereal/tcpdump dump file can be found at http://www.pza.net.au/~pza/dcs900w.ethereal I'm going to try out the latest snapshot and see how it goes.

-- PhilAnderson - 16 Jan 2005

I added a small tool to RelatedProjects which is called MjpegSniffer. The idea of the program is to get raw data from a Network camera for analysis. If a camera does not work with Motion you can use this tool to make a file containing the raw data stream returned from the camera so the developers can better find out what it takes to make Motion work with the camera.

-- KennethLavrsen - 18 Jan 2005

I changed the status back to PatchTesting so that it becomes more visible on the patch overview and signals work in progress. "Come and help us testing".

-- KennethLavrsen - 07 Feb 2005

I have one D-Link DCS-900W (thread2, cam2) and two Logitech Quickam pro 4000 cameras (thread 1,2, cam1,2; uses pwc driver; these camera works fine)

after some experiments with some version (3.1.18 - 3.1.19-snap3, _snap2 with patch) i found that thay all fails

While using link with 3.1.19-snap2+patch :
netcam_url http://192.168.77.230/IMAGE.JPG
netcam_userpass
 
motion oftenly fails before first capturing with error:

Processing thread 0 - config file /usr/local/etc/motion.conf
Processing thread 1 - config file /usr/local/etc/motion0.conf
Processing thread 2 - config file /usr/local/etc/motion1.conf
Processing thread 3 - config file /usr/local/etc/motion2.conf
Webcam port for thread 1 is 88
Webcam port for thread 2 is 89
Webcam port for thread 3 is 90
Thread1 device: /dev/video0 input: 8
Thread2 device: /dev/video1 input: 8
Thread3 device: http://192.168.77.230/IMAGE.JPG input: -1
Netcam: thread 3: starting...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
[HTTP/1.0 200 OK]
Netcam: thread 3: jpeg file
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
Netcam single: thread 3 : Content-length NO supported
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
Netcam: thread 3: error reading image : Interrupted system call
Netcam: thread 3: error frame [1]
Netcam netcam_start(): thread 3: Image size 0

while using 3.1.19_snap2 with patch:
netcam_url http://192.168.77.230/video.cgi
netcam_userpass
 

oftenly it works fine first 10-20 minutes and then fails

Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
Segmentation fault

New threshold: 72
cam0
90
New threshold: 72
Closing devices ...
File of type 1 saved to: /usr/local/motion/cam0/triggered.jpg
Closing devices ...
261
New threshold: 72
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
cam0
107
New threshold: 72
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
79
New threshold: 72
Closing devices ...
File of type 1 saved to: /usr/local/motion/cam0/triggered.jpg
Closing devices ...
105
New threshold: 72
cam0
65
New threshold: 80
File of type 2 saved to: /usr/local/motion/cam2/snapshot.jpg
Closing devices ...
54
New threshold: 72
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
Closing devices ...
File of type 1 saved to: /usr/local/motion/cam2/triggered.jpg
Closing devices ...
815
New threshold: 80
cam2
21
New threshold: 72
31
New threshold: 72
Closing devices ...
File of type 1 saved to: /usr/local/motion/cam2/triggered.jpg
Closing devices ...
849
New threshold: 80
cam2
File of type 2 saved to: /usr/local/motion/cam2/snapshot.jpg
Closing devices ...
Closing devices ...
File of type 1 saved to: /usr/local/motion/cam0/triggered.jpg
Closing devices ...
86
New threshold: 72
cam0
54
New threshold: 72
Netcam: thread 3: error reading image, not complete
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
Netcam: thread 3: re-connection done
[HTTP/1.0 200 OK]
Netcam: thread 3, mjpeg stream
Netcam: thread 3: netcam->boundary_string [--video boundary--]
Netcam: thread 3: re-connection got frame
Closing devices ...
File of type 1 saved to: /usr/local/motion/cam2/triggered.jpg
Closing devices ...
705
New threshold: 80
cam2
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
Netcam: thread 3: error reading image, not complete
Netcam: thread 3: re-connection done
[HTTP/1.0 200 OK]
Netcam: thread 3, mjpeg stream
Netcam: thread 3: netcam->boundary_string [--video boundary--]
30
New threshold: 72
Netcam: thread 3: re-connection got frame
Closing devices ...
File of type 1 saved to: /usr/local/motion/cam2/triggered.jpg
Closing devices ...
399
New threshold: 80
cam2
File of type 2 saved to: /usr/local/motion/cam2/snapshot.jpg
Closing devices ...
Closing devices ...
File of type 1 saved to: /usr/local/motion/cam0/triggered.jpg
Closing devices ...
126
New threshold: 72
cam0
Netcam: thread 3: error reading image, not complete
35
New threshold: 72
52
New threshold: 72
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
47
New threshold: 72
Netcam: thread 3: re-connection done
[HTTP/1.0 200 OK]
Netcam: thread 3, mjpeg stream
Netcam: thread 3: netcam->boundary_string [--video boundary--]
Closing devices ...
File of type 1 saved to: /usr/local/motion/cam0/triggered.jpg
Closing devices ...
141
New threshold: 72
cam0
Netcam: thread 3: re-connection got frame
3737
New threshold: 80
572
New threshold: 72
Closing devices ...
File of type 1 saved to: /usr/local/motion/cam0/triggered.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
240
New threshold: 72
cam0
Netcam: thread 3: error reading image, not complete
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
50
New threshold: 72
26
New threshold: 72
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
Netcam: thread 3: re-connection done
30
New threshold: 72
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
Segmentation fault
 

with 3.1.19_snap3 and "/IMAGE.JPG" also fails after starting

and with /video.cgi:

starts from

Processing thread 0 - config file /usr/local/etc/motion.conf
Processing thread 1 - config file /usr/local/etc/motion0.conf
Processing thread 2 - config file /usr/local/etc/motion1.conf
Processing thread 3 - config file /usr/local/etc/motion2.conf
Webcam port for thread 1 is 88
Webcam port for thread 2 is 89
Webcam port for thread 3 is 90
Thread1 device: /dev/video0 input: 8
Thread2 device: /dev/video1 input: 8
Thread3 device: http://192.168.77.230/video.cgi input: -1
Netcam: thread 3: starting...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam1/snapshot.jpg
Closing devices ...
File of type 2 saved to: /usr/local/motion/cam0/snapshot.jpg
Closing devices ...
[HTTP/1.0 200 OK]
Netcam: thread 3, mjpeg stream
Netcam: thread 3: netcam->boundary_string [--video boundary--]
Netcam stream : thread 3: Content-length supported
Netcam: thread 3: thread PID: 13164
Closing devices ...
File of type 1 saved to: /usr/local/motion/cam1/triggered.jpg
Closing devices ...

and then after 10 minutes of work fails with:
Netcam thread 3 : Error checking JPEG not start code
Not a JPEG file: starts with 0x43 0x6f
Netcam: thread 3: error reading image, not complete
Segmentation fault

PS:
Configure status
pthread Support:     Yes
jpeg Support:        Yes
V4L included:        Yes
FFmpeg Support:      No
xmlrpc-c Support:    No
MYSQL Support:       No
PostgreSQL Support:  No

PPS: between server (Fedora Core2 (kernel 2.6.10), P4 3Hz/1Gb) and camera - 100Mbit ethernet

-- DmitryPupkov - 16 Feb 2005

I have Dlink DCS-900W, have same problem, first run only last less than 20 mins, then just "Segmentation fault", tons of reconnect. Did firmware upgrade(even same firmware version 2.28, I think the firmware still different, since it fixed the date issue), and run a dedicated network for this camera, now it's much better, it can last for whole night. But still not stable. It may still running but not capturing any image. Funny thing, it reported: "Somebody stole the video device, lets hope we got h is picture" yesterday, then quit. This camera really not for serious business, ipview lite came with it even worse. Don't know what to do, may be run a cron job, kill it and restart it every hour?

-- JerryZhu - 28 Feb 2005

I am starting to continue some of my development on the netcam driver. I have continue to have problems with the netcams, while the USB cams work fine. The netcams frequently dead lock and proceed to peak CPU usage. This may be caused due to a race condition when starting the netcams. I'm currently testing this live at my webcam site.

Current changes (more coming):
  • fixed possible race condition when starting netcam in video.c
  • added defines for initial buffer sizes and debugging mode
  • beginnings of some cleanup of syslog/fprintf messages
  • beginnings of some code style cleanup

Please reference my website for current patches made by me.

-- ChristopherPrice - 15 Mar 2005

I am happy to see further development in getting the Netcam code stable. It has turned out to be more difficult than we thought.

Any reason why you do not use the Motion wiki? It gets difficult for me to manage patches both here and at external sites.

Maybe this patch topic is a bit worn out. Then just start a new one.

On the wiki people can post comments, suggest fixes and give bug reports. Your site is a one-way communication path from you to us.

It would also be nice if the patches are made for 3.2.1_snaps in addition since this is where the new development is happening. 3.1.X is now only for bugfixes.

There has been made a lot of changes to the 3.2.1 code probably also in the Netcam code with the setup feature so I doubt a 3.1.19 patch will run cleanly on 3.2.1. The 3.2.1 is currently open to all sorts of experiments so it may make more sense to develop on that and backport bug fixes to the Netcam code back to 3.1.X once the improved netcam code actually works.

The advantage is that I will include your interrim fixes in 3.2.1 snap releases which we know gets tested by much more people than if you only have a patch file. Download statistics of snaps versus patches clearly shows this.

-- KennethLavrsen - 15 Mar 2005

Okay, I've ported the patch to motion-3.2.1-snap5 and uploaded the patch as an attachment. It will take me a little while before I can do much more than that, as I'm completely new to the wiki thing. Once I get the hang of it, I'll update the page with some more information on the patch.

Note that I have this patched version now running on my website. It took a while to figure out how to change my camera control to the http interface (which was one of my primary reasons for not trying to patch at this revision).

-- ChristopherPrice - 16 Mar 2005

Per Kenneth's suggestion:

Should we open a new Netcam topic for the 3.2.1 development branch and use this to continue support for backported fixes?

-- ChristopherPrice - 18 Mar 2005

I have created a new clean patch topic to start on. I propose we only use one for now. The Netcam code (except for printf messages) should be identical and porting to both 3.2.1 and 3.1.19 easy.

The topic name is NetcamStabilityPatch

-- KennethLavrsen - 18 Mar 2005

This patch has been closed because there's a new patch that includes this one and future features. Please follow up NetcamStabilityPatch

-- AngelCarpintero - 17 Apr 2005
I Attachment Action Size Date Who Comment
motion-3.1.19-pre2_snap4.diff.gzgz motion-3.1.19-pre2_snap4.diff.gz manage 4 K 25 Feb 2005 - 19:55 AngelCarpintero Last patch before releasing motion-3.1.19_snap4
motion-3.2.1-snap5-p1.diff.gzgz motion-3.2.1-snap5-p1.diff.gz manage 6 K 16 Mar 2005 - 08:38 UnknownUser Patch against motion-3.2.1-snap5, possible to fix race condition during netcam_start, also includes initial start of code cleanup
Topic revision: r74 - 17 Apr 2005, AngelCarpintero
Copyright © 1999-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Please do not email Kenneth for support questions (read why). Use the Support Requests page or join the Mailing List.
This website only use harmless session cookies. See Cookie Policy for details. By using this website you accept the use of these cookies.