exec_proxy

Description of Patch

A hack to allow you to specify an external program that will function as the source for a MJPEG video stream.

This is useful for accessing cams that do not provide a standard MJPEG image stream or accessing via other image acquisition methods.

The program is specified in the netcam_proxy configuration option with the service type "exec" instead of "http", the host part is ignored, using remaining path as the path to the executable. The netcam_url configuration option is passed as a argument. The executable is expected to provide a MJPEG stream to the calling process via stdout.

eg:

   netcam_proxy  exec://localhost/usr/local/sbin/nc800 
   netcam_url http://10.1.1.44:80/cgi-bin/Stream?Video webcamPWD=RootCookie00000=%BR%

Also provided is a program (nc800.c) for obtaining a streaming MJPEG feed from a GadSpot NC800 ( a camera that provide a compatible video feed )

-- EvilPete - 19 Nov 2005

Installation of Patch

Download the patch file. If it is packed as a gz or tar.gz unpack it first. Then copy it to the motion source directory and issue the command (assuming the patch file is called motion-3.2.4_snap4-proxy_exec-v1.diff)

patch < motion-3.2.4_snap4-proxy_exec-v1.diff

Then re-build Motion and test the patch.

Change History of Patch

• 1.0 Initial revision

Discussion and Comments

---

Hi , i did also a tool to get the stream from that camera. I'll upload here as soon as it will very stable ( it's being tested by the guy who sent the "request" to M/L).

BTW i'm not sure is a good idea to use that tool patching motion to use ExecProxy , because that means that this tool MUST to be in the same machine of motion while if this tool works as an standlone daemon can be anywhere and motion won't be affected in any way.

camera nc800 <--- tool-that-fix-mjpg <---- motion

So in motion.conf user just need to set netcam_url

netcam_url http://ip_of_tool-that-fix-mjpg:port_of_tool-that-fix-mjpg/

I've tried to compile nc800.c but it failed :

gcc -O -g nc800.c -o nc800
nc800.c: En la función 'nc_connect_to_cam':
nc800.c:503: aviso: el puntero que apunta en el paso del argumento 5 de 'getsockopt' difiere en signo
nc800.c: En la función 'sig_action':
nc800.c:870: aviso: la asignación crea un puntero desde un entero sin una conversión
/tmp/ccdE4Ea3.o: En la función `nc_connect_to_cam':
/home/gstreamer/dev/relay-nc800/nc800.c:450: referencia a `setproctitle' sin definir
/home/gstreamer/dev/relay-nc800/nc800.c:478: referencia a `setproctitle' sin definir
/home/gstreamer/dev/relay-nc800/nc800.c:483: referencia a `setproctitle' sin definir
/tmp/ccdE4Ea3.o: En la función `nc_cam_next':
/home/gstreamer/dev/relay-nc800/nc800.c:605: referencia a `setproctitle' sin definir
/tmp/ccdE4Ea3.o: En la función `procstats':
/home/gstreamer/dev/relay-nc800/nc800.c:786: referencia a `setproctitle' sin definir
collect2: ld devolvió el estado de salida 1

setproctitle isn't found anywhere , do you know in what header is included ?

-- AngelCarpintero - 19 Nov 2005

---

your network approach can be convenient in certain installations, I feel the local exec is a good approach, because it will ( greatly ) simplify the writing of the "fix tools" while not adding extra network load.

For testing i had simple perl and shell scripts functioning as video stream sources.

I also found it very useful for getting frames / video streams from some usb video cams that do not have devices, that is the images are only avalible from user level applications with minimal extra effort.

I run on FreeBSD, 'setproctitle' is a part of libc. I "ifdef freebsd" the code in and uploaded a new version. the 'procstats' was more or less for debugging so to see the state of app from the process table (The setproctitle() library routine sets the process title that appears on the ps(1) command.

-- EvilPete - 20 Nov 2005

---

Could this be used for using e.g. VLC streams as sources? i bet VLC can stream or output to MJPEG, and this way i could stream from anywhere to a motion-server suing some fancy compression scheme, and do the otion-detecting on the server.

-- MoritzVonSchweinitz - 21 Dec 2005

---

Well. VLC is AFAIK a video streamer program that streams via TCP. So if it can provide an mjpeg (not mpeg) stream Motion should be able to connect directly to it.

If you just want to create a local proxy program that connects to something else you can simply make the program with a TCP socket. When you connect to it - no matter how - it should send some HTTP headers and start sending mjpeg on the socket. Then Motion can connect to this via http://localhost:portnumber without the exec patch.

-- KennethLavrsen - 21 Dec 2005

---

I keep on coming back to this patch.

One one hand I think what it was made for could be solved better ways. On the other hand the idea that you can create a local executable that can handle those "hard to deal with special cameras" is also a good idea.

A local program could however create a tcp/ip socket instead of a local socket so I am not sure if this feature is really needed - or wanted.

My biggest problem is that I cannot test it myself without creating some executable small program that provides a test mjpeg stream.

And then we come to the last things I do not like. IF we add a new exec feature why would it pick up an mjpeg stream? That would make the program only work with network cameras that makes a non-compatible mjpeg. But what if we want to decode real mpeg, or something else crazy. Then we would first convert to mjpeg and then inside Motion we convert again to yuv420p which is the format Motion uses inside.

Maybe it would be better of the exec interface was more universal and could provide a yuv420p "stream" also.

And it concerns me then to put that in a netcam_url feature.

I have great doubts about this one so I will leave it parked here and wait for other peoples oppinions and initiatives.

I just wanted to share my throught and show that I do not completely ignore this patch.

-- KennethLavrsen - 25 May 2006

---