RT-AV was created to overcome the bandwidth limitations of USB bridging. Webcams (especially now that they are HD) require a large amount of bandwidth to transfer the uncompressed pixels from the camera. This is fine when they are plugged into a physical PC with a high-speed USB bus that is only microseconds away from the CPU. USB bridging places that webcam on a lower bandwidth network connection that is now milliseconds away from the CPU. This additional latency is enough to significantly limit the peak bandwidth that can be supported by USB bridging even on a LAN.
The solution to this problem is to compress the pixels at the remote client before sending them to the virtual machine over the network. This is what RT-AV does. However, the current RT-AV design does not leverage the fact that almost all modern HD webcams have hardware compression for MJPEG (and some for H.264) built into the webcam. Instead, RT-AV uses a software compression codec, Theora, that has to run on the remote client CPU. Zero Clients do not have a CPU to run the Theora codec, but would be able to send MJPEG compressed streams to the virtual machine if VMware supported MJPEG as well as Theora for RT-AV. This would have the added advantage of offloading the Webcam compression for Thin Clients or PCs as well.
VMware does respond to requests for new features if enough customers ask for them, but they don't if they do not see demand. However, until they decide to add this support, USB bridging is the only option for webcams on Zero Clients and those bandwidth limitations will restrict you to the resolutions you are seeing.
