if you don't have any problem on other sites so it means the problem comes from this website and should contact them rather than post your issue here.
Yeah, if you're seeing this with both Flash and WebRTC (i.e. not Flash) and across multiple browsers, it's more likely that something is happening at a lower level, like at the camera driver. We don't really interact directly with the hardware. It's all abstracted away by DirectX.
Given that you only see this problem with this website, could be that this particular website sets the camera feed up a particular size or something that tickles a bug in the underlying driver (it's making a logic error that only shows up at a particular dimension or bitrate, etc.) It could also just be a problem at their end, although that generally wouldn't cause the browser to hang.
You might want to check that you have the latest available drivers (and/or firmware) for your camera installed. Aside from that I don't have a lot of great suggestions.
You might consider a nice external camera, like one of the Logitech ones with their own built-in H.264 encoders. In my experience, they're really nice quality and have rock-solid performance.
does it mean that a webcam with builtin encoder Flash/webrtc will bypass any video encoding?
That's a good question. WebRTC is going to be entirely dependent on the browser implementation.
I'm not actually sure what desktop Flash Player does at this point. I know for sure that we used the system hardware H.264 encoder exclusively back when we built Flash Player for mobile devices (Android, etc.). My bet is that desktop Flash Player probably doesn't utilize the on-board hardware encoding, and that would also require that the stream is configured to use H.264 and not an older codec like the original Sorenson VP6 implementation.
My thought process on suggesting that kind of camera was that it's limited to the higher-end consumer webcams, which is going to get you better quality hardware and drivers. I'm well aware of a couple of cheap webcams that just regularly lock up without assistance from Flash. Since all of this stuff is mediated by DirectX, we don't get an opportunity to put the hardware in a bad state directly.
Looking at the marketing materials for Logitech's cameras, they specifically cite Skype and Lynx, so I'm not sure if it's something that would just automatically get exposed to us via DirectX, or if we'd need lower-level access to even get to it.
I'll have to go ask around. I'm pretty sure that if we do support it, it's going to be on newer Windows versions, where DirectX might just handle it for us.
thanks for the details. Not to go so deeply I thought that Flash is able to detect the type of stream coming from the webcam and if it fits the right specs so the stream just goes through so it would avoid to decode re-encode it, as long as the user is just ok about the H264 settings from the webcam settings.
I know that we provide guidelines on the size of the webcam feed, but everything that's documented is basically recommending VGA resolutions. That was more about avoiding rescaling in order to fit the requested video size for the stream (i.e. always request the camera's default resolution, so you're not chewing up the CPU more than you need to). I didn't see anything in the docs for the Camera or NetStream APIs that really spells out exactly what's going on beyond needing to explicitly setup an H.264 encoder object if you want to create an H.264 stream. I suspect that any hardware support for the camera is messy and highly platform dependent (e.g. it would probably not work on Linux or WinXP). We probably just encode everything in software to ensure that you're getting consistent behavior across the supported platforms.
that makes sense indeed..