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?
IPVMU Certified | 06/17/13 12:54pm
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?
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.
IPVMU Certified | 06/17/13 05:07pm
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.
IPVMU Certified | 06/17/13 05:43pm
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).
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"