Hi all.
Sorry to post this here, but as i know we have already a lot of experts here, so i can get more useful answers.
The problem is that i need to make a Wireless network of surveillance. I have 2 buildings and each one with 2 cameras, so 4 cameras.
I dont need actually to record any image, so i dont think i should be using zm.
I only need to stream the live video without much delay from one building to another.
I was wondering about using Helix Server and some codec for realtime video like RealVideo or something like it.
The camera will be attached in a single channel Bt878 card.
What do you think about it ?
Thanks for your answers .
Victor Diago
A different application with CCTV
- victor_diago
- Posts: 245
- Joined: Wed Jan 21, 2004 2:44 pm
- Location: Brazil, sao paulo
- Contact:
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
how much bandwidth you got to play with, as if you have (as i think you have) a wireless lan why not keep it simple and use ip cameras (wireless) and use the cameras alone without a zm box?
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
- victor_diago
- Posts: 245
- Joined: Wed Jan 21, 2004 2:44 pm
- Location: Brazil, sao paulo
- Contact:
Hi.
Because today we have 2 buildings, but we plan to sell surveillance over wireless to more buildings.
Imagine we have 10 buildings and the distance from one to another is about 5 km.
I really will help me save bandwidth and make things better by encoding it in rtp/rtsp or something like that.
Thanks For answer
Victor Diago
Because today we have 2 buildings, but we plan to sell surveillance over wireless to more buildings.
Imagine we have 10 buildings and the distance from one to another is about 5 km.
I really will help me save bandwidth and make things better by encoding it in rtp/rtsp or something like that.
Thanks For answer
Victor Diago
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
oh i see.
I know by something i read on here that the new 207 has a little lag (5 secs i think) when using mpeg, and i dont personally know of anything else as all i use linux for really is zm.
Sorry and good luck
I know by something i read on here that the new 207 has a little lag (5 secs i think) when using mpeg, and i dont personally know of anything else as all i use linux for really is zm.
Sorry and good luck
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
- victor_diago
- Posts: 245
- Joined: Wed Jan 21, 2004 2:44 pm
- Location: Brazil, sao paulo
- Contact:
Here ive found something REALLY interesting
http://www.litech.org/spook/
Thanks for now.
Victor Diago
http://www.litech.org/spook/
Spook is a Linux server application to capture live video and audio and stream it over an IP network. Currently, Spook supports capturing from a Firewire IIDC camera or Video4Linux(2) source and streaming MPEG4 with RTSP or JPEG stills with HTTP.
This really seems promising.Spook encodes MPEG4 with XviD. Because MPEG4 is a very efficient compression method, decent-looking 30fps streams can be produced with about 200 kbps, which is less than the upstream bandwidth of most cable modems and DSL lines. Spook also provides JPEG stills from a built-in HTTP server for bandwidth-limited environments.
Thanks for now.
Victor Diago
-
- Posts: 5111
- Joined: Wed Jun 08, 2005 8:07 pm
- Location: Midlands UK
Cant ffmpeg stream from a v4l source? i think you can run ffmpeg to do this too, and run multiple instances for multiple inputs
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
maybe using RTP will not help on compressing the video signal, unless you the whole purpose is a video distribution system wich require control over the multiedia traffic
For video surveillance, the goal is to centralize video flows into a "surveillance server", regardless the origin (physically (cable, usb) or virtual - IP). It goes beyond capturing video signals.
Regarding wireless you've got take into account in a large area if repeaters are needed, be carefull since repeating cut the bandwith in half, per hop, unless you use sort of sophisticated Ap with dual radios.
as far as I am concerned, the zm must bet enough to deal with the surveillance functionality (or DVR. or DVS). The IP part,is a matter of network design.
For video surveillance, the goal is to centralize video flows into a "surveillance server", regardless the origin (physically (cable, usb) or virtual - IP). It goes beyond capturing video signals.
Regarding wireless you've got take into account in a large area if repeaters are needed, be carefull since repeating cut the bandwith in half, per hop, unless you use sort of sophisticated Ap with dual radios.
as far as I am concerned, the zm must bet enough to deal with the surveillance functionality (or DVR. or DVS). The IP part,is a matter of network design.
sounds like a job for VLC...
it's a bit complex to start, but it's not too hard to figure out
it will take whatever feed you have, convert it on the fly (if required) and stream it out via many ways.. RTSP UDP UPD Multicast, etc
VLC = Video Lan somethingorother... just google it,
BTW, it's multiplatform.
Hope this helps!
Dan
it's a bit complex to start, but it's not too hard to figure out
it will take whatever feed you have, convert it on the fly (if required) and stream it out via many ways.. RTSP UDP UPD Multicast, etc
VLC = Video Lan somethingorother... just google it,
BTW, it's multiplatform.
Hope this helps!
Dan
Dan the Computer Man