The Windows 10 Anniversary Update, aka version 1607, has been found to leave many webcams inoperable. The update prevents the use of webcams in applications such as Skype and Open Broadcaster Software (OBS), along with all manner of custom CCTV programs. Extremely popular hardware, such as Logitech's C920 and C930e cameras, in conjunction even with Microsoft's own Skype, will fail to properly broadcast video.
People first noticed the issue earlier this month. But it's only within the last couple of days that the exact cause became clear via a post by Brad Sams on thurott.com.
Microsoft has said that a fix is in development, but has not yet said when that fix will be distributed.
The Anniversary Update changes some aspects of how Windows handles cameras, and the issue appears to affect both USB webcams and network-connected IP devices. Traditionally in Windows, only one program has been permitted to access a webcam at a time. If you're using the camera in Skype, for example, other applications such as OBS or the Windows Hello facial recognition cannot use the camera.
Windows 10 1607 includes a new component to address this. A system service called the Windows Camera Frame Server connects to the data streams from the webcams. Regular applications connect not to the camera hardware directly, but to this new frame server component. The frame server supports multiple connections from applications and shares the video data from the camera to every connected app. This puts an end to the "exclusive" use of devices, and it's arguably a change that Windows should have made long ago. Third-party software for sharing cameras between applications exists, but the operating system should support this scenario natively, as it already does for audio devices.
Microsoft explains that the design of the frame server is the issue.
Squeezing 1080p video over a USB 2 connection
USB webcams typically offer data in a variety of formats. This includes compressed video streams that use standard video codecs such as H.264 and MJPEG, as well as uncompressed streams of YUV or NV12 data. The reasons for this variety are complexity and bandwidth. On the one hand, uncompressed data are easier to programmatically manipulate—they're already ready to use, and they don't need to be decompressed first. On the other hand, many webcams are USB 2 devices. USB 2, at a theoretical 480Mb/s, doesn't have enough bandwidth for uncompressed 1920×1080 video at 30 frames per second. USB 2 webcams that support 1080p30 must therefore do so using compressed data, with both MJPEG and H.264 common.
The version 1607 frame server, however, only supports uncompressed data. Microsoft's rationale for this is that most applications receiving compressed data will have to immediately uncompress that data in order to actually manipulate it. With the new camera-sharing capability, this means that multiple applications could be performing the MJPEG-to-YUV or H.264-to-YUV conversion simultaneously. It's more efficient in this situation to simply read YUV data from the camera in the first place and skip those extra conversions. H.264 adds additional complexity: applications can negotiate specific compression parameters with the camera to alter the compression quality on the fly. This isn't an issue when an application has exclusive control of the camera but becomes a problem when two different applications try to use different parameters with the same camera.
By preventing the use of the compressed formats, Microsoft avoided these issues. But it came at a great cost. Applications demanding or expecting support for MJPEG or H.264 data have stopped working. This could manifest in strange ways. I have a Logitech C920 camera, and I use it with Skype. Skype progressively enhances video quality; a connection may start out using a lower quality, and it'll then be upgraded as bandwidth and processor usage settle down. What I found was that an initial video call would connect, with the application using something like 640×480 YUV data. After a few seconds, however, Skype would try to upgrade the call to 720p or 1080p video. This should work, and in old versions of Windows, was seamless. But with the Anniversary Update it means switching from an uncompressed data stream to a compressed stream—and so it fails. The video just freezes after a few seconds of correct operation.
Unfortunately, I didn't report this as a bug. Instead, I thought that perhaps my webcam was failing. Its predecessor failed (albeit in a different way), and the camera's driver had blue-screened my PC in the past. So I was inclined to believe that my webcam was just malfunctioning in some way. The webcam integrated into Microsoft's Surface Book worked just fine in this same scenario (though it uses USB 3), so I didn't immediately think this was a software issue.
Microsoft's fix is to reintroduce support for these compressed streams. The company says a MJPEG fix will come first, as this is the easier situation to handle. The frame server will offer, and applications will be able to demand, MJPEG data, re-enabling high-quality video over USB 2 cameras. Later, a fix for H.264 (and other non-standard formats that some specialized cameras and applications make use of) will be developed. The H.264 fix is more complex, due to H.264's ability to negotiate the compression parameters between apps and the hardware.
This extra complexity means that the company intends to first deliver the H.264 fix to members of the Windows Insider program. However, this points to a broader problem. The Insider builds have had this frame server change for many months. If anyone noticed the change break their software, whatever response they created was muted at best. For my own part, I tend to use the Insider Previews only in virtual machines, which raise few of these hardware concerns. I didn't install the preview on my main PC—the PC that happens to have a USB 2 webcam, among many other peripherals—until a few days before the final release. Even then, I misattributed the problem.
I suspect I'm not alone. Microsoft cautions against running the Insider Previews on a primary PC—the PC that's most likely to have a wide range of hardware, software, and the heaviest usage. This is a fair warning. Many Insider builds have not been suitable for day-to-day operation. But what this means is that, even though millions of people have tested the preview builds, that testing has holes in it.
I'm not surprised that users of CCTV systems did not install the Insider Previews. On some level, I can see how this scenario slipped through testing. But the Logitech C920 plus Skype combination is extremely common. The C920 and closely related C930e webcams, though long in the tooth, are the best external cameras available for Windows systems, and they're still the cameras of choice of many online streamers. That the problems when using this pairing should go essentially undetected suggests that the Insider program is nowhere near as thorough as it needs to be.
How do you know what to test when you don't know what's new?
Microsoft's poor communication over what each Windows build changes and brings to the table also, I feel, has some responsibility. The webcam stack changes were not widely publicized. Microsoft's own site makes no mention of the new frame server service, for example. This means that there was little reason to believe that something was fundamentally different in the way that Windows is handling webcams, so when something breaks, it's much harder to diagnose what the cause of that problem is. I didn't know if it was the camera hardware, Logitech's camera drivers, or Windows itself, and I figured the first two were much more likely than the third. If Microsoft had clearly communicated that the webcam stack was changed, I would have been much less likely to ascribe the problems I saw to the camera itself. I would have been much more likely to ascribe them to the Anniversary Update. This would have meant in turn that I would have filed a bug.
I've written before about Microsoft's lack of release notes for Windows builds. While the situation has improved somewhat, and Microsoft has done more to explain fixes and known issues, this new webcam issue highlights the large gap between what each new Windows build changes and what Microsoft says it changes. Without a concerted effort to fill that gap, issues like this will inevitably recur. Microsoft has to start telling us what's changing in each Windows build and each Windows release. That means more than promoting the user-visible changes like Edge's extensions.
Until a proper fix is developed, affected users can disable the frame server feature and revert to the older behavior in which each application takes exclusive control of the camera. Rafael Rivera determined that some registry keys can be modified to prevent use of the frame server.
Specifically, a DWORD named EnableFrameServerMode at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media Foundation\Platform (for 32-bit Windows, and 64-bit applications on 64-bit Windows) and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows Media Foundation\Platform (for 32-bit applications on 64-bit Windows) set to the value zero will restore expected camera functionality.
The usual registry warnings—don't mess it up and don't change it if you don't know what you're doing—apply to making this change. Once the fix is tested and shipped, this value can be removed.