Fooling Around

// Oprogramowanie Roman Ryltsov

Anniversary Webcam Saga: It’s clear who’s guilty, now what to do? (Updated)

Posted on by Roman

As new and new people discover the Windows 10 Anniversary Update breaking changes (expectedly running mad), let’s reiterate the possible solutions:

  1. You don’t like the idea that video sharing service adds latency, and adds man-in-the-middle access/spying over a video feed.
    See #6 below.
  2. You are consuming raw video from camera using one of the uncompressed modes within USB 2.0 bandwidth.
    You are likely to be not affected by the changes.
  3. You are consuming raw video from camera but resolution/rate combination makes it unable to capture raw video, so you captured M-JPEG instead and decoded that, via DirectShow API.
    It is no longer possible, but you can use Media Foundation API instead. Or someone will develop a wrapper that re-exposes Media Foundation captured video via DirectShow.
  4. Same as #3 above but via Media Foundation API.
    You have the option to consume already decoded video, new subsystem will automatically capture M-JPEG and decode into NV12.
  5. You take advantage of compressed format of video captured (DirectShow or Media Foundation) so that you don’t need compress it for storage or network transmission purposes.
    Compressed captured video is no longer available, see #6 below.
  6. You take advantage of H.264 video capture offered by UVC 1.5 device, including fine tuning of hardware H.264 compression.
    Just as in #1 and #5 above, you are in trouble. Windows Camera Frame Server no longer offers access to such video feed. You need a hack (yes, it’s confirmed to be possible) that restores original behavior of video capture hardware.

These and other reasons related to the fact that applications no longer talk to real capture device, but rather a Frame Server Client that proxies a web camera, will possibly require that video capture applications are updated in order to work well in new version of the operating system.

It is unclear if and how Microsoft and Media Foundation team will respond to customer pain voices. First, it looked as a bug and one could expect a response and fix. But with the information from Windows Camera Team it looks completely different. No, they did not accidentally break it up – it was a planned change. Then they connected new behavior with new Microsoft Products – new products rely on new behavior. Then they did a few nasty things, not just one: added proxy service, killed UVC related compression control over the device, reduced range of operation modes for DirectShow they look for ways to deprecate, conceptually removed compressed video capture modes. I think there is no way back – Windows Camera Frame Server is new reality. The best to expect is that some of the mentioned problems are relaxed by offering greater flexibility by the platform. Maybe they will add some sort of exclusive modes for video capture or “professional” hardware which offers more through the API. In any event these changes are unlikely to appear soon, as they will go through the full cycle of development and take months to get delivered. Public pressure might force that to appear rather earlier than later, but I don’t think it is what is going to happen.

16 Aug update: Windows Camera Team reported that they see customer pain and will do something to ease it shortly. As I see it, they will address scenarios #3, #4, #5 above, for MJPG video, to allow compressed formats pass Frame Server so that users could consume them from their applications and Frame Server would be able to release frames not just after decoder, but also before the shared decoder. Also as use of H.264 is limited, it might be not included into hotfix at all, or will be included much later being given more serious consideration (which might end up as dropped support in DirectShow and something new introduced for Media Foundation).

19 Aug update: Someone took time to locate a registry value. User WithinRafael on MSDN Forums:

Try opening up

HKLM\SOFTWARE\Microsoft\Windows Media Foundation\Platform (32- and 64-bit OS)
HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Media Foundation\Platform (64-bit OS)

and add a DWORD value with name EnableFrameServerMode. Set its value to 0 and try again.

Put a sticky note on your monitor to revisit this if/when Microsoft issues a fix.

Also:

Untitled

5 Replies to “Anniversary Webcam Saga: It’s clear who’s guilty, now what to do? (Updated)”

  1. A copy of Mike M’s posts from MSDN Forums because it’s getting harder and harder to pull the updated from the thread:

    TL;DR: Good news, we’re working on an update to address this feedback! Read on for my long-winded reply and a little more context.

    The team has been reading through all your replies over the weekend. I can understand your and your customers’ frustration, and the team can very much relate. Some of the points raised in this thread cannot be argued with, and we appreciate you bringing those to our attention in this discussion.

    Right now we’re investigating the best way to address the behavior that is causing these problems. Once we have that, MJPEG and H.264 will no longer be filtered out, so your applications should continue to work as before without any changes. At the moment we have a prototype of the MJPEG update being tested, and once we validate it works well, we’ll look to publishing it out to customers who have already updated to the Anniversary Update, through our servicing channels.

    For the case of H.264 it could be a little more complicated, and it might require a little bit more planning. Because of this, there is a chance that we’ll flight the updates for H.264 to our Windows Insiders first, to assess the impact it has. If any of you are using H.264 with DirectShow, please let me know, as that scenario is proving to be a little challenging. I’ll continue to update you on this as we figure things out. I do promise that we are working on getting all these changes out to you and your customers as soon as we can, though!
    The decoded formats will continue to be offered, and as time passes, we hope that application developers will adopt these where possible, since we still believe they bring benefits in the new camera landscape. That being said, we’ve learned a lot from this launch and will be making improvements based on these learnings for the future, and we again would like to apologize for the confusion this may have created.
    More to come, stay tuned!

    I think I had a correct sense of coming updates and fixes, in part that Frame Server is still in the game and MF team is addressing specific customer issues. They resolve MJPG first because it’s widely used and because the compression is non-temporal and easier to deal with.

    Hey folks, I have a couple of updates for you all, but before we get to that part, we want to thank you. The specific hardware and usage scenarios you’ve provided are excellent insight for us. We have been focusing on the Windows Insider Program flight data to monitor any issues. We hope in future we can get even better coverage through this data for the enterprise and business scenarios you’ve outlined. Now, let’s give you a little bit of insight into the engineering work being done to address your feedback. We have work in progress where the changes will be split up into three items.
     
    The first change will cover the MJPEG issue. We have an internal prototype ready and it’s going through testing as fast as we can to verify it doesn’t introduce regressions. Once testing is complete, we will release it to servicing so it reaches you and your customers automatically through Windows Update. We expect this update path will happen in September. I remain committed to communicating more specific dates once I have confirmation.
     
    The second change is exposing the H.264 media type. This change is more involved. The implementation is soon wrapping up, and once it does, this change will follow a similar process as the above. In addition to our internal testing, we plan to flight this change to our Windows Insiders, to get further verification insight and gather feedback from the community. We do this because, while we have many of the most popular commercially available cameras, the hardware ecosystem is so vast that it’s practically impossible for us to test every product out there. Since it will take some extra time for the H.264 work to go through this additional layer of testing, and we would prefer not to delay the MJPEG changes, we will ship these two separately. You can expect the MJPEG media type work to reach you first.
     
    Finally, there is one last update that we’re working on which is to enable custom media types (like Bayer). This set of code changes is related to the H.264 work I mention above, so it’s likely that we’ll ship them together.
     
    To ensure these changes will allow you to continue using your current devices, drivers and/or applications without changes we would appreciate your input. Please let me know what combinations of camera, driver (you can get the driver provider and version from Device Manager) and applications you’re using. This will help us cross check our current lab testing setups, broaden our validation coverage, and catch any issues earlier in the development cycle.
     
    Once again, I’d like to reiterate our commitment to making these improvements in a timely fashion. We’re aiming to provide you and our customers with a camera experience as you knew it from before the Anniversary Update, without requiring you to update your applications or custom camera drivers, and we believe we’ll be able to achieve this goal. I’ll continue doing my best to give you regular updates on our progress, and I’ll let you know the dates when you can expect the updates to be published as soon as we have that information. The team greatly appreciates your patience!

  2. Further update:

    Hi everyone, I’m back with an update. We’re pushing a set of changes through Windows Update today (that is, 31 Aug 2016), which should address most feedback from this thread, regarding exposing MJPEG and H.264. We still have some work in the pipeline for other custom media types, that we’ll work to get you very soon.

    We’d like to thank you for your patience as we learned from your specific configurations and worked to support them better. If you have any issues after installing KB3176938, please use the Feedback Hub to send us a note. Tag the title with the KB number, and specify the camera you’re using, its driver version, desired media type format, and expected vs. actual results in the description. Thanks!

  3. Another update:

    Hello, all! I’m back with another update.

    We have just released KB3194496, which will be installed automatically on your and your customers’ machines through Windows Update. This update includes the changes I mentioned before, and will improve compatibility with custom cameras and custom media types.

    As a representative of the camera team, I’d like to reiterate how much we appreciate your feedback and your patience, as you outlined the use cases and requirements through our various communication channels. Your constructive input has directly contributed to making Windows a better product for everyone, so please continue to send us your comments through the Feedback Hub app. If you believe that your specific scenario appears to still be affected after updating to OS Build 14393.222 (see: Windows 10 update history), please create a new feedback item under the “Hardware, Devices, and Drivers” > “Device Camera or Webcams” category, include “KB3194496” in the title along with a short summary of your feedback, and in the description specify: the camera you’re using, its driver version, desired media type format, application used, expected vs. actual results, and any other details you consider relevant. We’ll continue monitoring your input.

  4. From the same topic again (Oct 10):

    The Logitech C920 is a UVC 1.1 camera that behaves slightly differently depending on the OS version it’s running on. If you look at the USB Device Class Specifications for UVC 1.1 (more specifically: USB_Video_Payload_H 264_1.0 section 4.1.1 and USB_Video_FAQ_1.1 section 2.11), you’ll get a better understanding of how it is that the C920 implements the H.264 support they offer since Windows 8. Basically, through an extension unit, an application can configure the camera to send the H.264 frames using the MJPEG media type as a container to the H.264 frame data. This behavior has not changed recently, and new versions of Windows 10 have not affected it in any way; the Logitech C920 would not advertise H.264 as an individual media type on any versions of Windows going back as far as Windows 8, so we believe your observations are unrelated to any of the changes made in Windows 10. Is there a specific reason you’re expecting to see H.264 as an advertised media type?

    All that being said, if you need H.264 as an individual media type, the easiest way is to use a UVC 1.5 camera, like the Logitech C930.

  5. 27 Oct 2016:

    One final update for this thread. The KB3176938 and KB3194496 updates we released a while back has improved webcam compatibility for people experiencing the behavior initially outlined in this thread, so we’re confident that the changes we’ve made have addressed their concerns.

    We continue to see some posts that we believe are related to driver compatibility. These reports are in line with what we usually see on an ongoing basis, and it’s unlikely that they are related to any OS changes. You may find it useful to run through the troubleshooting guide from this support page as a first step to address such driver issues.

    Because this forum is mainly aimed at developers, if you require further assistance, please search for or create a thread in the Microsoft Community forums for Windows Camera. There, you’ll find more targeted support to help you with your specific installation. Thank you!

Leave a Reply