Cameras That "Push" Video

Seems some problems with trying to deliver multiple cameras streams could be solved if cameras could just "push" their video out without requiring a request for video, and if the VMS could be configured to listen for and accept the video packets without having to make a call for them. Smart switches with port-mirroring could then be used to duplicate, or even triplicate the streams without the cameras having to do anymore work than deliver one stream at full frame rate and resolutions.

From a manufacturer's perspective, how hard would this really be. On the camera side I'd think it'd just be a firmware change, maybe an optional firmware that's offered.

Hi Luis, can you give an example of this? I am not sure why pushing solves any problems that 'pulling' would present. Do you mean that it would cut down the total number of streams which would reduce load / performance limitations?

Well I think push would possibly solve a few things....

1. Have remotely located cameras you want to stream back to a server across an Internet connection? Cameras that push their streams would not require any port forwarding or static IP addresses at their location. Only the remote server would need a static IP address and port forward at it's location.

2. Instead of configuring some sort of multicasting, you could use port mirroring on a switch which might make it easier for situations where you have to send out multiple streams

3. Again, which a switch using port mirroring, you could possibly overcome limitations of multi-streaming whereby either resolution has to be different betweem the multiple streams, frame rates get divided between the streams or the streams have to be different codecs, all various tradeoff's I've seen between different manufacturers when it comes to multi-streaming.

Just some ideas that occured to me and wanted to get some manufacturers take on it. Is it sound theory or vodoo?

overcome limitations of multi-streaming

Ah, I didn't address this in my last response.

Multi-streaming is limited by the camera, and it's processing capability.

If a camera had an Intel Core processor in it, I'm sure there would be no problem in replicating the live feed into a handful of H.264 streams. Then, your camera would cost $1,000 in parts alone.

It's a tradeoff. Camera manufacturers have to balance power, image quality, features, and price.

And the reality is, if you are pushing the best quality stream out of a camera into a multicast group, what else do you need?

How about another idea- a new codec. H.264 is very processor intensive, but doesn't allow for selective decoding. Take for example a JPEG. When you look at a JPEG, you can actually read only select parts of the stream and you can put together a lower resolution image. Then you can pick up the rest of the parts and decode the full image.

Why can't we do that with the codec? Why can't I just receive the 30 FPS 5MP H.264 stream from the camera, and throw out half the frames, and decode only the first 25% of the image? Boom, now I have a 15FPS 720P stream... Add multicast and you got yourself a stew!

Luis -

It is usually only the higher-end switches that support port mirroring, and several of them have limitations on just how many ports can be configured as mirror/monitoring ports. You're also getting more into the realm of complicated setups there, as different switch brands configure this feature very differently.

Personally, I think this is a neat line of thinking, but I don't think it really reduces the total amount of problems or system complexity, it just trades one set of things for another.

I can see it being another form of complexity, but I also see it as another possibility where it did not exist before. At the very least, cameras pushing their video simplifies router configuration requirements for remote cameras. We also recently had an analytics application where the camera had to serve streams to two computers, one for recording and one for analysis. This created a problem because the framerate gets cut in half at a minimum, but actually a little more because the camera had problems serving two masters. The stream was also MJPEG, and MJPEG is not compatible with multicast.

The stream was also MJPEG, and MJPEG is not compatible with multicast.

Not sure where you heard that? Anything can be streamed multicast- it's protocol agnostic.

Actually, your partly right and I'm partly wrong. Initially this was told to me by the Etherwan engineer, but I think he meant only for the camera I was using and I didn't remember the technicals.

Genetec explains it as if MJPEG is coupled with HTTP, it can only be unicast. If it's transported via RTSP, then it can be multicast (see whitepaper pages 5 to 6).

The devil is always in the details! I forgot about the transport protocol necessary, and was just assuming RTSP across the board. HTTP is not a very good streaming protocol, but can get the job done.

Thanks for the correction and the link. A good doc from Genetec- and something I probably should of read already since I'm a partner... ha!

A bit back to the original discussion (Cameras that push video); the problem or crux with this is that there is already a transport method beyond multicast for what you're proposing... called Broadcast. Unfortunately this would create more problems than it would solve. Ultimately Multicast is really the best existing solution for what you are describing.

"If a camera is Broadcasting on a network and no one is there to request its viHEY IM ANOTHER CAMERA BROADCASTING VIDEO"