USB Webcam Redirect

Hi Shawn,

I'm going to try and give you some background as to how things work as far as USB redirection of webcams is concerned.

Webcams are isochronous USB devices. A simplistic view of what this means is that the webcam sends a constant stream of frames, with no handshaking aside from some initial speed/frame rate negotiation.  Webcam drivers are fairly simplistic and for many the only meaningful negotiation with regard to frame rate is whether the USB bus is USB 1.0 or USB 2.0.

To get a feel for what this means we need to think about what isochronous USB implies. And I think a good comparison is the difference between UDP and TCP packet transmission.

UDP assumes that the transmission medium is "perfect" and sends packets as fast as it can with no packet throttling or handshaking. TCP assumes the transport medium is unreliable, and has throttling (sliding window) and handshaking/retransmission built into the protoccol to handle variable bandwidth and even packet loss to reliably deliver a packet stream.

Isochronous transfer is the UDP of USB.

USB redirection, regardless of who does it, is done by having a virtual channel or equivalent (RDP/ICA/PCoIP etc) which shares the available bandwidth with other virtual channels in a client connection to a virtual (or physical) host. Virtual channels are presented to the network as data packets with a virtual channel header. Virtual channels have the equivalent of QOS prioritization and any high priority virtual channel will starve other virtual channels.

As a rule the video display virtual channel runs at the highest priority and everything else uses whatver bandwidth is left, generally with USB redirection having the lowest priority. So right from the start, the USB virtual channel is going to have only a fraction of the available bandwidth, particulalrly if you are also viewing the webcam video.

But there are some differences in how virtual channels are managed. They can be managed within a single session stream, or in multiple separate session streams, as for example with HP's RGS USB redirection.

Single stream TCP sessions may or may not provide adequate responsiveness, depending on the webcam, USB drivers, virtual channel priorities and network latency. PCoIP (UDP) does a better job on the LAN simply because it uses the UDP protocol, once it goes out on the WAN things fall apart. RGS does a brilliant job on the LAN because each virtual channel has it's own session.

What this bolis down to is there are just too many variables involved in something that's very intolerant to latency.

So can webcams work at all on EOP? The answer is yes, I've had a couple of types of webcams working but I've also had most fail. If it's a higher resolution webcam, it's more likely not to cope. If you're lucky a webcam might work, but it's more likely it won't.

vWorkspace EOP USB redirection has been significantly modified and now has compression and bandwidth control which can be configured at the client end via the systray icon  (virtual USB hub > advanced). Turning on zip compression with a packet size roughly the frame size (32-64k) may turn the odds your way. EOP ztream helps as well if network latency is greater than 20-30 msec.

But there are no guarantees that any or all webcams will work using USB redirection, not from Quest or any of Quest's competitors.

If you want something that has a fairly good chance of working, my own experience is that RGS probably gives the best results and has worked for me with most decent webcams, albeit on the LAN. I haven't had a chance to do a lot of testing with RemoteFX but some low resolution webcams definitely work as long as network latency is low. RGS and remoteFX are of course both supported by vWorkspace.

So far this probably hasn't been a lot of good news for you but it's also not the end of the story. The need for viseo conferencing on virtual machines is putting a huge amount of pressure on the industry to come up with a working solution for webcams.

Content-aware USB redirection, which could allow you to do stuff like frame dropping (queu and toss) and better compression, plus inband prioritization of control vs content could make the USB redirection story a lot better as far as webcams are concerend. But that's an awful lot of work, particularly for the many different type of client devices now being used.

I really don't think the solutions are going to happen because of improvements in USB redirection. Video stream offloading, client-side video processing and use of higher level video handling are going to provide the solutions.

As an example of something that handles webcams right now, Quest's RemoteScan does a pretty good job or frame capture, always provided the webcam drivers are WIA (windows image acqusition) compatible. RemoteScan redirects WIA content (and TWAIN), not USB through a remote desktop client virtual channel.

I've got to stress that the processing of the isochronous USB is done on the client, and it is WIA content that is redirected not USB. That's the most likely future.

regards,

Rick

Rick,

You have a huge, glow-in-the-dark brain, and are very generous with your knowledge. Kudos on your smarts and benevolence.

The UDP/TCP analogy was very helpful. Let me clarify the scenario and perhaps you can suggest a solution.

The company use EMR software on the virtuals. The software is able to take external image input from devices to add to patients' records. For example, it can find remotescan and query it communicate to the scanner attached to the thinclient and scan admittance forms to add TIFF files to a medical record.

I DO NOT need the cameras to record video or audio; just to take pictures of patients to attach to their record.

I'm not certain why WIN7 on the virtuals cannot integrate the webcam without producing the "troubleshoot" alert, but I suspect that is the reason the EMR app cant "see" it.

SO the 2 issues are:

1) getting the EMR app to see the cam (if i can't get past this part, well...)

2) getting the app (or maybe the app that came with the camera or Win7) the capture still photos ONLY

any ideas, sir? What webcams have you gotten to work?

Hi Shawn,

I have a Microsoft VX-6000 and a Logitech (M/N V-UAM37) that have worked in my lab, but I also have an HD microsoft webcam that doesn't work, nor do the webcams on my laptops work.

Simple frame image capture shouldn't stress things at all, but the webcan doesn't just send a single frame, it sends a stream of frames and you just "select" one. So from a USB redirection viewpoint the issues are the same

Single frame capture really has to be done at the client end, and WIA is the way to go, always provided the client is some flavour of windows. I'm going to see if we can look at this internally, but I suspect you need a solution that works right now.

There are a number of ways of doing single frame capture using WIA on the client (SourceForge project, VB script etc) but I'd be tempted to try RemoteScan first because it's widely used and works.

regards,

Rick