Comart XED 4040
Comart XED 4040
I have a machine running linux with one of these cards in it:
http://www.comartsystem.com/AM/PRODUCTS/dvr_board/xed/
I know there is no direct support for this card in Zone Minder and that the driver for this card does not use the V4L interface/API.
What am I am contemplating is this. Write an application that talks to the card's driver and presents the stream from each input (camera) as an RTSP stream on the localhost interface. Yes, this essentially involves writing a video streaming server. Am I correct in my assumption that Zone Minder could then be set up to treat each stream (camera) as an Ip camera?
Looking for comments on feasability at this stage, oh, and of course let me know if I'm barking up the wrong tree lol.
Cheers,
badone
http://www.comartsystem.com/AM/PRODUCTS/dvr_board/xed/
I know there is no direct support for this card in Zone Minder and that the driver for this card does not use the V4L interface/API.
What am I am contemplating is this. Write an application that talks to the card's driver and presents the stream from each input (camera) as an RTSP stream on the localhost interface. Yes, this essentially involves writing a video streaming server. Am I correct in my assumption that Zone Minder could then be set up to treat each stream (camera) as an Ip camera?
Looking for comments on feasability at this stage, oh, and of course let me know if I'm barking up the wrong tree lol.
Cheers,
badone
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
zm can only grab from a jpeg source, not rtsp.
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
or mjpeg yes
James Wilson
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
Disclaimer: The above is pure theory and may work on a good day with the wind behind it. etc etc.
http://www.securitywarehouse.co.uk
OK, I have started looking at this. The sample code I have provided by the card manufacturer does an ioctl call to /dev/xecap0 to get the size of the buffer and then memcpys directly from a memory map of the dev file to an SDL_Overlay's pixels field.
IIUC this represents a "frame", can anyone provide me with a fast track on what I need to do to convert that to a frame suitable for storage as part of a motion jpeg, or at least point me in the right direction please?
Cheers,
badone
IIUC this represents a "frame", can anyone provide me with a fast track on what I need to do to convert that to a frame suitable for storage as part of a motion jpeg, or at least point me in the right direction please?
Cheers,
badone
statement about jpegs and mjpegs is true for ip cams, but you have capture card. when using "local" cameras ZM just captures raw frames (see src/zm_local_camera.cpp)
somebody on the forums posted solution that uses v4l loopback driver to feed video to ZM from unsupported device, maybe you can use the same approach here?
somebody on the forums posted solution that uses v4l loopback driver to feed video to ZM from unsupported device, maybe you can use the same approach here?
if common sense is so uncommon, why is it called common then?
Hi W,
I'm actually at the point whre I can capture raw frames from the card driver now. Am I correct in my assumption that I have come to that the raw frame is essentially a jpeg or mjpeg frame or is it RAW (I'm new to video but not new to programming, file formats, etc.)?
I will take a look at zm_local_camera.cpp and hopefully it will enlighten me some more. I'll also do a search for the V4L loopback solution (although my card of course is not supported by V4L and has no V4l driver). Thanks for the feedback, I must say that my foray into the video world has so far been kind of fun in a "stick needles in your eyeballs" kind of way lmfao
thanks,
badone
I'm actually at the point whre I can capture raw frames from the card driver now. Am I correct in my assumption that I have come to that the raw frame is essentially a jpeg or mjpeg frame or is it RAW (I'm new to video but not new to programming, file formats, etc.)?
I will take a look at zm_local_camera.cpp and hopefully it will enlighten me some more. I'll also do a search for the V4L loopback solution (although my card of course is not supported by V4L and has no V4l driver). Thanks for the feedback, I must say that my foray into the video world has so far been kind of fun in a "stick needles in your eyeballs" kind of way lmfao
thanks,
badone
-
- Posts: 1
- Joined: Thu Mar 20, 2008 1:11 am
Re: V4l loopback
No, I hadn't thanks felix.felixdecat wrote:Have you seen this page on the wiki?
http://www.zoneminder.com/wiki/index.php/Vpipe
So, there appear to be a few ways to do this. One is to alter the source for zm_local_camera.cpp so that it talks to the XED board, two: add a zm_local_xed4040_camera.cpp file and make that a selectable option at compile time or through the interface at runtime, three: write a daemon that grabs the raw frame from /dev/xecap0 and feeds it to the v4l loopback device.
Is there a dev mailing list? Any opinions on which constitutes the best way to proceed?
Cheers,
badone
Re: V4l loopback
this appears to be mostly one man show (i might be wrong though) and the man is zoneminder himself try PMing him and ask as to what is best route in his opinion. I would go with either 2nd or 3rd option and just post results in user contributions section.badone wrote: Is there a dev mailing list? Any opinions on which constitutes the best way to proceed?
if common sense is so uncommon, why is it called common then?
I'm in similar situation. Have you made any progress? http://www.zoneminder.com/forums/viewtopic.php?t=11788