Bob's Adventures in Wireless and Video Headline Animator

Saturday, August 28, 2010

IP Video Transport Protocols

There was a post on LinkedIn regarding why the transport protocol between the the VMS software (NVR) and an IP Camera matters. I thought I would share my response.

Camera and VMS manufacturers are big on promoting their video compression algorithms such as Motion JPEG, MPEG4, or H.264. But try to pry out of them what transport protocols they use to communicate and it is a completely different story.

The need to know transport protocols supported (HTTP, Unicast, Multicast, RTSP/RTP over TCP, RTSP/RTP over UDP, TFTP/proprietary) is essential for determining performance over wireless and wide area network links.

For instance, if the VMS and the camera are remote from each other over a routed network (aka Internet) protocols like TFTP simply will not work at all. HTTP may work, but it will depend on how much buffer the camera has and how much jitter buffer the VMS will have, and how important latency is to your application.

Then we get to RTSP/RTP. ONVIF decided to implement RTSP/RTP over TCP as the preferred transport protocol because it is efficient and easy (lets the application off the hook for verifying guaranteed delivery). ONVIF used TCP because they wanted to enforce guaranteed packet delivery for chain of evidence and intrusion detection. But TCP forces packet level acknowledgment which is sub optimal on limited bandwidth networks. IPTV has been using RTP/RTP over UDP for years because it is more efficient and runs well over networks that are not deterministic (aka Internet). But UDP does force the application (aka VMS) to verify data delivery. We really wish that ONVIF had specified the use of UDP as the preferred method so that surveillance could scale over the Internet. UDP is an optional method in ONVIF, but we know of only one VMS system that supports it.

Anyway, for the last two years we have been testing cameras and VMS systems over our wireless links and carefully watching their transport protocol behavior and efficiency. We keep a list of the best and the worst VMS/camera combinations and have developed work around solutions (full duplex wireless for example) for transport protocols that are sub-optimal. Typically these sub-optimal protocols are very latency

Since our wireless protocol is optimized for video (TDMA derivative) we only say how these combinations work with our gear and not over 802.11, mesh, EV-DO, or other networks.

Our preference list for transport is:
RTSP/RTP over UDP (IPTV spec)
RTSP/RTP over TCP (ONVIF spec)
TFTP (these are always proprietary implementations, not actual TFTP) 

We have found that getting information on what transport the VMS has implemented with a particular camera is impossible. Many of the VMS tech support folks don't even know. We have even been told by some VMS mfgs that they are using RTSP/RTP but when we sniff it, they are actually using HTTP.

We are hoping that an independent third party would provide a definitive list of who is using what as it would help people out immensely. One place to start is which at least tells you which cameras support RTSP, but not how they have implemented it or which VMS are supporting same.

Let me know if you have other ideas about how to solve this.

Saturday, August 21, 2010

Greetings and Solicitations

What I am going to try to do here is chronicle my daily experiences in designing, building, installing and trouble shooting wireless and video applications. We may wander through the world of video, RF, construction, mobile, lighting, police, perimeter security, fire fighting, DOD, EMS and who knows what else.

For those of you who don't know me, I am engaged in two different companies at present: HauteSpot Networks, who makes wireless routers for video and voice streaming; and MicroPower Technologies who makes ultra power efficient wireless cameras (really small and really wireless -- no power cord).

HauteSpot has been something that I have been working at for almost 5 years now. We started by trying to sell high performance wireless IP routers to the TV broadcast market. We built low cost routers (relative to COFDM solutions that were available at the time). Unfortunately we were about 4 years ahead of the market. Broadcasters really didn't need the performance that we offered.

About 2 years ago, the video surveillance market started to really adopt IP cameras and we shifted our focus to this market. The early offerings in IP surveillance were bandwidth hogs and used transport protocols that were impossible for standard wireless technologies such as WiFi to handle well. Having a lot of experience in moving video without jitter (delay variation that makes video unreliable and full of artifacts), we were able to deliver great performance for video over wireless when our competitors fell down.

Now we are seeing broad adoption of our wireless routers in the public safety, commercial security, homeland security and more. So the market is finally catching up with us.

One gap that we identified was battery/solar powered and wearable operations. Particularly in building wireless solar powered cameras there really were no good options. Our routers, while delivering excellent performance, were not designed for low power. So solar panels are large, batteries are large, construction costs are get the idea.

This led me to MicroPower, who has an excellent technology for running wireless IP cameras at very little power. I associated myself with MicroPower in a business development role and started using my years of experience in the surveillance market to build up MicroPower's position.

So now I am immersed at the center of the storm of wireless and video, with contemporary technologies (some might say bleeding edge). I would like to think that I have become a trusted source for technical information to my customers.

So now that you know me, I will move forward with my world of learning...Call me out if I am wrong, pat me on the back if I help you.