none
MJPG encoded media type is not available for USB/UVC web-cameras after Windows 10 version 1607 (OS Build 14393.10 'anniversary)) update

    Question

  • The latest update replaced uvcvideo.sys driver and 
    Dshow Camera MF Filter mfksproxy.dll
    {95FEE196-49F0-4C30-B16C-22C7B75C18EC} file version: 6.2.14393.0 product version: 10.0.14393.0
    and since then the MJPG formats are not available from streaming cameras in both Microsoft Media Foundation and Direct Show.

    We have verified that ksproxy still can get to the correct media type but the MMF and DS cannot get MJPEG media type.

    In MMF it's been replaced by NV12 unpacked data and in DirectShow it is plainly dropped.

    Here is the link for github project that can be build to illustrate the issue:
    google: github leokv uvc_mjpg_win10 (because this forum does not allow links)

    h t t p s : // github . com / leok7v / uvc_mjpg_win10 


    We've verified it on multiple hosts running Windows 10 in different hardware configuration with at least 4 different camera models.

    Ability to get MJPG encoded raw frames is very important to us from the performance perspective.

    Hope somebody from Microsoft is monitoring this forum and can help.

    Leo

    leo@zspace.com

    Monday, August 08, 2016 2:36 AM

All replies

  • Hello

    I'm experiencing the same issue. Hope Microsoft can follow up quickly on this one.

    Support for natively encoded MJPEG is also very important for our application.

    Pascal

    Monday, August 08, 2016 2:29 PM
  • I found the offending piece of code and it is mfcore.dll
    Apparently it has hard coded MF Device Filter inside it that cannot be turned off with any combination of:
    attrs->SetUINT32(MF_SOURCE_READER_ENABLE_VIDEO_PROCESSING, false);
    attrs->SetUINT32(MF_SOURCE_READER_ENABLE_ADVANCED_VIDEO_PROCESSING, false);
    attrs->SetUINT32(MF_SOURCE_READER_DISABLE_CAMERA_PLUGINS, true);
    attrs->SetUINT32(MF_SOURCE_READER_DISABLE_DXVA, true);
    attrs->SetUINT32(MF_READWRITE_DISABLE_CONVERTERS, true);
    attrs->SetUINT32(MF_READWRITE_ENABLE_HARDWARE_TRANSFORMS, false);
    attrs->SetUINT32(MF_SOURCE_READER_DISCONNECT_MEDIASOURCE_ON_SHUTDOWN, false);
    attrs->SetUINT32(MF_SOURCE_READER_ENABLE_TRANSCODE_ONLY_TRANSFORMS, false);            

    But we can copy old, working mfcore.dll from the 'Anniversary updtae) version 12.0.10586.122
    to our local bin/ folder lazy (delay) load link against it and force load old version on startup.
    This gives us MJPG encoded media types - I did not investigate further yet...
    But this is a hack and I do not expect the upstream dependencies to be happy with it in a future.

    I wish I can ping Dave Patrick here but URLs are prohibited for unconfirmed users and I did not yet figured out how to confirm myself (Login turns out to be not enough).





    Tuesday, August 09, 2016 4:10 PM
  • Hey guys, Mike from the Camera team here. We saw this concern pop up for the first time a couple of days ago, and we'd like to understand exactly what difficulties you are all facing. There are two items that I would like the discussion to focus on.

    Firstly, the media types supported on a given machine vary depending on the capabilities of the camera device you're using. There is no guarantee that a media type such as MJPEG will be supported on all cameras (for example, the Surface Pro 4 / Surface Book cameras do not support it). This means that, by taking a hard dependency on it being available, you're limiting the portability of your application to the set of cameras that do offer that media type. What applications should do instead, is query the available formats (see: IMFSourceReader::GetNativeMediaType for MediaFoundation, IAMStreamConfig::GetStreamCaps or the IPin::EnumMediaTypes article for DirectShow), and make a selection based on the one that best suits your needs or capabilities.

    Secondly, we are expecting that almost all clients using MJPEG frames will be decoding the stream as one of the first steps in their pipeline. In order for this to be done in the most efficient way, with the smallest impact to overall system performance, we want to offload that piece of the process to be taken care of by the platform. This means your application should be able to consume the uncompressed frames, which will have been decoded to NV12 for MediaFoundation applications, and YUY2 for DirectShow applications.

    If there are any other issues that you’d like to bring to our attention, please do so. We’d love to understand how we can best help you through this transition, and we'll be considering your feedback for future planning. Thanks!

    Tuesday, August 09, 2016 11:28 PM
  • Mike,

    The problem is about the Anniversary update and not about checking missing capabilities or checking them wrong way. Systems and cameras that did expose MJPG and H264 do not expose these media types anymore. They did have that before the update and they no longer have it after tha update. Yes, it's exactly IMFSourceReader::GetNativeMediaType and IAMStreamConfig::GetStreamCaps, IPin::EnumMediaTypes which no longer enumerate them.

    It's a breaking change of the update and it's definitely a bug. Automatic decompression of MJPG by the platform makes no sense. Do you mean it's intentional that compressed media types are no longer exposed because you thought it would be better to do automatic decompression? I understood it this way at least.

    What about H.264? There is no need to decompress H.264 by platform or otherwise in order to record and display video using DXVA. Camera's H.264 it's removed as well. I wonder how MS Lync is expected to utilize hardware H.264 from UVC 1.5 devices if platform no longer exposes H.264? For example, I could easily preview and record Full HD video from Logitech C930e cam using cheap tablet, it's no longer possible. I could record dual Full HD in H.264 using two cameras simultaneously - it's no longer possible.


    http://alax.info/blog/tag/directshow


    Wednesday, August 10, 2016 4:54 AM
  • I did the Anniversary update and then the update after that. I can do web browser camera applications, but cannot do Yuja client with camera. Audio is ok. I will try Skype tomorrow. Hope it isn't broken too. Please fix soon!
    Friday, August 12, 2016 1:16 AM
  • Hi Mike, 

    I would also like to raise a HUGE concern here.

    We have a working product running for years and millions of unhappy users that are unable to use it at all after this update.
    We use the jpeg frames from the camera in order to scan.
    Our application is not able to use the camera, and our customers are in huge numbers daily complaining since the update was released. 

    We are eagerly expecting windows update with a fix for this issue. Please make it with highest priority.


    • Proposed as answer by MrRuupee Wednesday, August 17, 2016 12:57 AM
    • Unproposed as answer by MrRuupee Wednesday, August 17, 2016 12:57 AM
    Friday, August 12, 2016 9:25 AM
  • I hope this bug gets fixed soon!
    Friday, August 12, 2016 2:43 PM
  • Hi Mike

    After spending days finding a solution we also stuck with the Anniversary update. Thousands of our customers can’t use our product now to process their payments by e-banking! We and especially our customers - which are your customers too - are really reliant on MJPEG!! Please fix this issue as soon as possible so our support is not overwhelmed with enquires all day and we cannot offer another solution than downgrade Windows. Thanks a lot.

    Friday, August 12, 2016 3:48 PM
  • I’d like to start off by providing you guys a little more context on the behavior you’re encountering.

    One of the main reasons that Windows is decoding MJPEG for your applications is because of performance. With the Anniversary Update to Windows 10, it is now possible for multiple applications to access the camera in ways that weren’t possible before. It was important for us to enable concurrent camera access, so Windows Hello, Microsoft Hololens and other products and features could reliably assume that the camera would be available at any given time, regardless of what other applications may be accessing it. One of the reasons this led to the MJPEG decoding is because we wanted to prevent multiple applications from decoding the same stream at the same time, which would be a duplicated effort and thus an unnecessary performance hit. This can be even more noticeable or perhaps trigger error cases on in-market devices with a hardware decoder which may be limited on how many decodes can take place simultaneously. We wanted to prevent applications from unknowingly degrading the user experience due to a platform change.

    The reasoning for H.264 being decoded can get a little more complicated (and I’m just learning the details myself as I talk to other members of the team), but the basics revolve around how H.264 allows for encoding parameters to be changed on the camera directly, and how in a situation where multiple applications are making use of this control path, they could interfere with each other. Regarding Roman’s concerns about Lync: both Lync and Skype are partner teams, and we stay in touch throughout the development process, so the camera functionality in those applications will continue to work.

    So yes, MJPEG and H.264 being decoded / filtered out is the result of a set of features we needed to implement, and this behavior was planned, designed, tested, and flighted out to our partners and Windows Insiders around the end of January of this year.  We worked with partners to make sure their applications continued to function throughout this change, but we have done a poor job communicating this change out to you guys. We dropped the ball on that front, so I’d like to offer my apologies to you all. We’re working on getting better documentation out, to help answer any questions you may have. Of course, you can always reach out to us via these forums for specific issues, as we monitor them regularly, or file feedback using the Feedback Hub. We’re constantly collecting feedback on this and other issues, so we can better understand the impact on our application developers and customers. If you’re having issues adapting your application code to the NV12 / YUY2 media types, we’d like to support you through the changes you may need to make. To get you started, please refer to the documentation links in my previous post. If there are reasons why working with this format isn’t feasible for your project, please let me know, and I’ll present them to the rest of the team, to try and find the best solution for your case.

    Dacuda and Stephan B, I’m curious about your specific situations, since you report that this change is breaking functionality for your customers. Are your customers using custom camera hardware? Is the set of supported cameras restricted by your applications? How do your applications deal with devices like the Surface Pro 4, Surface Book, or Dell Venue Pro, which wouldn’t offer the media types your applications are relying on?

    I’d like to wrap up this wall of text by letting you know that your feedback here and through other channels is greatly appreciated and something that’s on our radar. We’re trying to look into what other options we can offer you to be able to improve on this for your (and our) customers, so stay tuned! I invite you to please subscribe to this thread (use the “Alert me” link at the top), and I’ll keep you guys updated on what we find. Thanks!

    Friday, August 12, 2016 9:36 PM
  • These guys project aside this problem has rendered my Logitech c930e completly unusable.

    at 720p or 1080p settings YUY2 locks the frames at 10 for 720 and 5 for 1080 respectively.

    The previous work around for this was to use MJPEG instead of YUY2...but now that option is no longer available and I have a $140 paper weight sitting atop my PC. Logitech has no known solution on any of their support pages that I could find, doing a little looking around I am not the only person having this problem.

    Friday, August 12, 2016 9:53 PM
  • Hi Mike,

    The issue we are running into is that this change on Windows 10 broke a very popular product called FFMPEGs' capabilities (see issue filed by our company on this: https://trac.ffmpeg.org/ticket/5775)

    As a former Microsoft SDE within the Redmond campus (2004-2008), I believe that part of what made Microsoft a valuable development platform is that regressions like this are addressed in an expedient way. 

    Given the number of issues that people are reporting around this, I believe we need a reasonable way for our existing applications to work in the same manner as they did in Windows 8 or Windows 10 prior to this change.

    Please advise, so we can advise both our customers and our developers on the right course of action here.

    Thanks,
    Nathan

    Saturday, August 13, 2016 1:04 AM
  • Thanks for explaining this even though I am afraid many are going to be confused. Perhaps someone could outline all DirectShow/Media Foundation changes of this platform update.

    http://alax.info/blog/tag/directshow

    Saturday, August 13, 2016 10:59 AM
  • Thanks mike for the explanation. Ability to access the camera from multiple applications is great. It also makes sense to allow the OS to handle the decoding of of compressed media types like H.264 or MJPEG so all applications using the camera don't have to do that. So if I understand correctly then you are saying that OS now removes compressed mediaformats and instead provides the decoded mediaformat as NV12 or YUY2 frames is that a correct understanding? ( I am not a developer, but still have some technical background and trying to wrap my head around this).

    So where do now find the decoded mediaformat that we should now use to get right FPS and framerate as we were used to before with MJPEG? I see now only uncompressed YUY2 which seems to be uncompressed frames directly provided by the camera so this limits the camera to low resolution or low framerate due to limitation of USB2 bandwidth. From reading you post I got the impression that MJPEG got removed and a decoded media format now got provided instead. But I see no other YUV or NV12 mediaformats availabe in direct show.

    Result: Nothing works anymore in applications that use web cameras via direct show. How exactly should application developers resolve this? I I think we need some answers on this asap, so we can fix our applications very fast before users get highly annoyed by only getting 5 FPS from their camera. This is highly critical, and something like this is what can make users turn off auto-update in the future, and avoid to get updates. 

          
    Saturday, August 13, 2016 1:41 PM
  • >In MMF it's been replaced by NV12 unpacked data and in DirectShow it is plainly dropped.

    ok so I guess I had to read a bit better.  I think I can now boil down to this single question: When will you have a patch so

    this will be available for direct show ?


    • Edited by DoctorHel Sunday, August 14, 2016 2:15 PM
    Saturday, August 13, 2016 6:08 PM
  • I just paid  $160 for a Logitech cam  worked grate for  a week now i can't even use it 

    with every update MS brings out the worst window 10 is   so what now  we have to go out and buy a new web cam 

    just cuss of the shit  MS dose  sorry but is bull shit   and it like Logitech ant doing much to fix this ether 

    i think bill gates should send up  new web cams that work with this  shitty os 

    sorry i'm just pissed 

    Sunday, August 14, 2016 6:50 PM
  • Sees like the webcam behavior needs a little clarification.

    It's clear apps no longer directly connect to a camera, they connect to a virtual replicated camera, which allows multiple apps to use the camera at the same time. It's also clear this virtual camera does not expose compressed formats, like MJPEG or H.264, and the camera virtualization layer will, if needed, run the MJPEG/H.264 to NV12/TUY2 codec.

    If apps never can request a compressed format, it seems like there is no reason for the camera virtualization layer to ever ask the physical camera to deliver compressed frames. This seems like it means the camera virtualization layer will never actually need to decompress MJPEG/H.264 formats, UNLESS that's the ONLY format supported by the camera. This suggests a potential device workaround is to ONLY expose compressed formats from the camera driver.

    It also seems likely there would be a performance problem for cameras being asked to deliver high resolution uncompressed frames at high frame rates over USB 2 interfaces. A potential solution would be for the camera virtualization to prefer compressed formats over uncompressed formats when talking to the physical camera, so the pipeline then goes physical camera->USB2>physical camera driver->camera virtualization->software decompression->uncompressed formats to multiple apps.

    Can Microsoft clarify if the camera virtualization is preferring uncompressed formats from the physical camera? if so, is there any way, like a registry entry, to change the priority of different formats?    

     
    Sunday, August 14, 2016 8:31 PM
  • Hello Mike,

    Thanks for following up and providing some context. Your implementation indeed breaks our software and we have currently no solution for our customers apart from requesting to postpone installing the Anniversary Update. Not a user of the Insider Program either, it is your job to guarantee compatibility.

    We are providing video based performance enhancement software and having each frame recorded is very important for our users. We specifically need access to the compressed stream for recording it to a hard disk, having access to higher resolution, higher frame-rate and preventing drop frame at the same time, on entry-level laptop (not netbook, running from battery, so using low-power, etc.)

    We also use multiple webcam connected concurrently to record different angles, having access to low-bit rate stream is even more importand for us in this case.

    We are not really interested to use the build-in camera, so why not differentiate based on the type of connection or why not just ask the user ?

    Thanks,

    Pascal



    • Edited by Kickaha4 Monday, August 15, 2016 5:34 AM
    Monday, August 15, 2016 5:23 AM
  • Hi Mike,

    Thanks for your attention to the matter. Since I cannot post URLs here pointing on stackoverflow (but you can google the subject) I will have to copy/paste my notes on the subject (which I hate to do - I mean increasing entropy by information duplication).

    ---

    We also have frame server in our zSpace system design that servers decompressed images, compressed cameras feed (four of them at almost 1Gpixel per second total), blob detection information and 3D poses triangulation results to multiple clients (applications including remote) at the same time. Whole thing using shared memory and/or sockets is just few hundred of lines of straight C code. I've implemented it and it works on Windows and Linux.

    The deficiency of the Microsoft "improvement" lays in ignorance to the client needs and I believe is easy to fix. 

    For the sake of the argument let's assume camera streams compressed format (could be MJPG/H.26x/HEVC/something new and better).

    Let say there are several possible classes of clients:


     1. Client that streams the raw compressed data to the network for remote hosts (do we want transcoding there?).
     2. Client that stores the raw compressed data in the local or remote persistent storage (hard-drive, ssd). (do we want transcoding there?)
     3. Client that does raw compressed data stream analysis (from trivial to complex) but does not need pixels?
     4. Client that actually manipulates compressed data and passes it upstream - remember one can crop, rotate e.g. JPEG w/o complete decompression.
     5. Client that needs the uncompressed data in HSI format. 
     6. Client that needs uncompressed data in RGB format with some filters (e.g. gamma, color profile) applied during decompression.  

    Enough? Today they all get NV12 (which actually constitutes even bigger data loss in terms of half a bandwidth of U (Cb) and V(Cr) samples).

    Now, since Microsoft is implementing frame server, they have to decompress the data one way or another and even multiple ways. For that the uncompressed data has to land in memory and can be (conditionally) kept there in case some client can benefit from using it. The initial media graph design allowed splitters and anybody with a little coding proficiency can implement conditional splitter that only pushes data to the pins that have client (sinks) attached.

    Actually, correct implementation should take clients needs into account (and this information is already present and readily available from all the clients in a way of media type negotiations and attributes that control the graph behavior). Then it should apply decompressors and other filters only when needed paying close attention to cpu cache locality and serve requested data to appropriate clients from appropriate memory thru appropriate mechanisms. It will allow all kind of the optimizations in the potential permutations of the mix of aforementioned client and beyond.

    If Microsoft needs help in designing and implementing the frame server satisfying this simple (if not to say trivial) set of requirements - all it has to do is ask - instead of breaking huge class of applications and services.

    I wonder how Microsoft is planing to network stream Hollolens input? Via NV12? Or via yet another hack?

    ---


    Monday, August 15, 2016 6:38 AM
  • Since I cannot post URLs here pointing on stackoverflow...

    For the record, StackOverflow question is Webcam MJPG capture streams are unavailable on Windows 10.

    http://alax.info/blog/tag/directshow

    Monday, August 15, 2016 12:19 PM
  • Hi Mike, 

    Thanks for the reply. 

    To answer your questions:
    We have custom hardware made for us that provides only MJPEG. We also had custom driver made for this product that manipulates the compressed data and passes it up to the pipeline.  Making new hardware and driver is not an option for us.
    We build our technology and software applications above that. 

    Our software works only with our camera, so the ones you mentioned are irrelevant for us.  

    It is really hard to understand how you can make such decision without any notification and practically kill so many products in the market.

    We have millions of users and we are in situation now where we have to tell them not to update the Windows anymore or switch to Mac OS.

    Please consider providing workaround for this issue, because I can see we are not the only ones facing the problem. 

    If you decide to help us, can you share a timeline when we can expect a patch?

    Monday, August 15, 2016 2:01 PM
  • Mike M,

    This is the essence of it.

    Millions of Windows users purchased webcams that use H.264 and MJPEG encoding compression to boost quality over a USB 2.0 connection.  These webcams provided amazing picture quality and high frame rates because of the encoding.

    Microsoft enticed these Windows users to upgrade to Windows 10.  Their webcams still work great.

    Then Microsoft develops Windows 10 Anniversary Edition which breaks what these webcams are doing, without really telling anyone that this will happen.

    Microsoft entices Windows 10 users to upgrade to the latest and greatest.  And over time, thousands (and eventually millions) of users now (and will) have dead webcams (some of them quite expensive webcams) on top of their monitors.

    Oops, sorry.  Microsoft dropped the ball.

    So it boils down to, Mike M, what is Microsoft going to do to fix it?  Microsoft made diverse changes without consideration of the consequences.  And now there are a lot of upset people out there.

    Monday, August 15, 2016 2:55 PM
  • See, THIS describes exactly the concerns i had when i heard that Windows Updates will be forced and cannot be selected anymore.

    This just forced me to roll back and disable windowsupdate service completly. Great job! What is microsofts problem with leaving options
    to the users? Why not an option to choose the old uvc driver especially when you knew about these issues in the beta? i don't get it. Now you are forcing me to leave my win10 unupdated until you fix this. People need to work with software and it is just not ok to assume that every software has to update just because you change major stuff, without leaving the user the possibility to skip an update until those software had a chance to update! Even apple doesn't force iOS updates on their users for crying put load!

    Monday, August 15, 2016 3:09 PM
  • Ben, it's because Microsoft knows best.

    Sorry, this whole thing just really made me mad.

    Monday, August 15, 2016 3:17 PM
  • I'd like to add my voice to those who lament the loss of access to MJPEG and H264 encoded streams from webcams. There's a large community of people out here who are engaged in streaming media production that rely upon this functionality. It allows USB 2.0 connected devices to reliably deliver 1080p30. It's in the current UVC standards. It should not be cast aside.

    Beyond achieving higher resolution at acceptable frame rates, using compression over the USB connection make it much more practical for people to use more than one USB-attached camera. It reduces the chance that they will encounter a USB bus bandwidth wall. Given that many computers only expose one USB bus this is important.

    I've recently tested a dozen USB-attached cameras with Wirecast, vMix, Open Broadcaster Studio and Sparkocam...which are all applications that rely the now missing capability. Last month I could have a four camera production setup streaming 1080p from a single desktop PC. Post update that same setup is simply impossible.

    Monday, August 15, 2016 3:38 PM
  • This is not the first time someone at Microsoft has concluded that "every camera in the world obviously works exactly like the four examples I have in my office."  They were wrong then, and they are wrong now.  I (and my clients) don't give a shit about Windows Hello and Windows HoloLens, and many of them are going to be REALLY upset that there is a Windows component spying on every camera stream that is being produced.

    Jan is right.  There needs to be an "opt out" option for this dreadful decision.


    Tim Roberts, Driver MVP Providenza & Boekelheide, Inc.

    Monday, August 15, 2016 4:04 PM
  • Sees like the webcam behavior needs a little clarification.

    It's clear apps no longer directly connect to a camera, they connect to a virtual replicated camera, which allows multiple apps to use the camera at the same time. It's also clear this virtual camera does not expose compressed formats, like MJPEG or H.264, and the camera virtualization layer will, if needed, run the MJPEG/H.264 to NV12/TUY2 codec.

    If apps never can request a compressed format, it seems like there is no reason for the camera virtualization layer to ever ask the physical camera to deliver compressed frames. This seems like it means the camera virtualization layer will never actually need to decompress MJPEG/H.264 formats, UNLESS that's the ONLY format supported by the camera. This suggests a potential device workaround is to ONLY expose compressed formats from the camera driver.

    It also seems likely there would be a performance problem for cameras being asked to deliver high resolution uncompressed frames at high frame rates over USB 2 interfaces. A potential solution would be for the camera virtualization to prefer compressed formats over uncompressed formats when talking to the physical camera, so the pipeline then goes physical camera->USB2>physical camera driver->camera virtualization->software decompression->uncompressed formats to multiple apps.

    Can Microsoft clarify if the camera virtualization is preferring uncompressed formats from the physical camera? if so, is there any way, like a registry entry, to change the priority of different formats?    

     

    There are some apps that make arbitrary decisions about encoding type based upon resolutions. For example, Telestream's Wirecast is likely the most commonly used app for desktop streaming media production. The Windows version does not allow the user to specify the video type for USB-attached cameras. However, if the user selects a camera resolution >720p it will try to use MJPEG.

    That would be possible with the virtual camera layer. It's less than ideal since there are applications where MJPEG is preferred over H264 and vice versa.

    Monday, August 15, 2016 5:59 PM
  • Thanks for the explanations. It is now clear that we need to invest time and resources in developing a solution for our tens of thousands of users that purchased our products and cannot use them anymore because of Windows 10 anniversary update.

    We, like many other developers, found out about this issue only in the past few days. Our first reaction is to tell our customers to avoid installing the Anniversary update and roll it back if needed.

    Re-developing our application was not part of our development plan for this year but now we must put all other projects on-hold and assign resources to address this un-expected issue.

    As you probably know, it takes time to create a software/hardware solutions and to release a good bug-free product to customers.  

    It will help us a lot if Microsoft can provide a quick workaround or patch that will allow our users to go through the Anniversary update and continue to use our application and mjpeg. Such patch will give us time to develop a new application according to Microsoft new vision and to make the necessary changes to our hardware/firmware.

    Please let us know an expected timescale for such patch from Microsoft.    

    Monday, August 15, 2016 9:16 PM
  • Here's the deal.  We have thousands and thousands of users that suddenly can't use the hardware that worked perfectly fine on the same system (with the exception of of having pre-Windows 10AE installed) only two weeks ago.  They need a solution.  Microsoft, you broke it.  Fix it, please.

    Monday, August 15, 2016 10:35 PM
  • It's the biggest **** up I've seen in a long time.

    MS, when will you fix this mess?  My application/webcam no longer works and there seem like no clear way, if any, to make it work with this new version of Windows.

    Tuesday, August 16, 2016 1:34 AM
  • 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!
    Tuesday, August 16, 2016 1:35 AM
  • If any of you are using H.264 with DirectShow, please let me know
    I had a customer who consumed H.264 video using DirectShow. I don't think any it was anything special: just H.264 media type and straightforward video capture. On that project it was crucial that device initially delivers compact H.264 even though it also offered other options (including YUY2 and MJPG).

    http://alax.info/blog/tag/directshow

    • Proposed as answer by JA_1410 Tuesday, August 16, 2016 5:38 PM
    • Unproposed as answer by JA_1410 Tuesday, August 16, 2016 5:38 PM
    Tuesday, August 16, 2016 12:12 PM
  • Skype with C920 is broken
    Tuesday, August 16, 2016 5:32 PM
  • I hate to break it to you, but Logitech C920 camera is freezing in Skype after the anniversary update. You definitely broke perfectly good hardware. Is Microsoft ready to refund high quality me $100 webcam and recommend another with comparable video quality that works?
    Tuesday, August 16, 2016 5:36 PM
  • I have exactly the same issue. Logitech C920 is now paperweight. I find explanation by Microsoft from this thread completely inadequate. "They worked with" partners. Really? So why is my webcam failing on Skype after update? Why Logitech have no fix for it? How is it that Skype team is "looking into issue"? Microsoft, please, make a search for this issue on the Skype forum. It is one of your departments for God's Sake. Clearly caught off guard. How come Logitech, one of the largest quality peripheral manufacturers is completely unaware about this until customers started complaining about webcams not functioning? Stop the corporate BS and give us a patch to fix this. Would Microsoft prefer to refund all the webcams that were perfectly fine and now do not work? Is there a comparable product for the similar price and similar video quality that will work so we could buy it with the money you will send us as a refund?

    Tuesday, August 16, 2016 5:50 PM
  • Hi Mike,

    Skype uses H.264 for some Logitech devices such as the C920 so those devices will be non-functional or will not achieve full HD if H.264 is not supported.  You really need to consider full backward compatibility for H.264 along with MJPEG otherwise many applications including Skype will be crippled for many users.


    Tuesday, August 16, 2016 6:57 PM
  • Thanks Roman.
    Tuesday, August 16, 2016 7:21 PM
  • Thank you Mike. Yours and the team efforts are very much appreciated.
    For the future, can we (developers) hope to stay informed for the future developments e.g. via blog:
    https://blogs.msdn.microsoft.com/mediasdkstuff/
    that as of now has not been updated since May 29, 2015.
    Thank you again for all the support.

    Leo 
    Tuesday, August 16, 2016 7:30 PM
  • Hello,

    I am a IT Support Technician for a Podiatry Business. I was directed to this forum from the Software Developer that is also having issues with this Camera affect, to help give an understanding of why they have issues and that Microsoft is to blame.

    The program is called Dartfish (dartfish.com) which has Gait Analysis, vital for my Clients business to function at a high level.

    I cannot speak for Dartfish, but this is a serious affect on my clients and Dartfish clients of whom thought getting the AU would be fine.

    Essentially, the error from the Dartfish app (for my client) says the Camera is disconnected and thinks it is corrupt. No matter what webcam you put in, it thinks it is disconnected/corrupt. This is apparently due to the changes in the AU that prevent webcams from using compressed streams, among other things.

    Dartfish have a simple explanation on their blog: blog.dartfish.com/windows10-update

    I hope a resolution can be found very soon. The AU is great, but the issues it faces is frustrating. We were lucky that this issue popped up within the 10 day reverting cycle! All Dartfish PC's are now back to 1151, deferring the upgrades and are now working fine.

    Tuesday, August 16, 2016 10:34 PM
  • So I spent some time going through my app's code and seeing what Media Foundation is throwing at it different than before.  I have found out what changed and why my app failed to deliver video post Anniversary update.

    + Before Anniversary update: Media Foundation delivered YUY2

    + Post Anniversary update: Media Foundation delivers NV12 instead of YUY2

    Since my application was written for a specific web cam, this situation is totally unexpected (it would have no reason to expect the format to 'suddenly change'.)  I wrote an NV12 decoding routine and I have video again.

    Perhaps this information helps someone else.


    Tuesday, August 16, 2016 10:57 PM
  • The latest update replaced uvcvideo.sys driver and 
    Dshow Camera MF Filter mfksproxy.dll
    {95FEE196-49F0-4C30-B16C-22C7B75C18EC} file version: 6.2.14393.0 product version: 10.0.14393.0
    and since then the MJPG formats are not available from streaming cameras in both Microsoft Media Foundation and Direct Show.

    We have verified that ksproxy still can get to the correct media type but the MMF and DS cannot get MJPEG media type.

    In MMF it's been replaced by NV12 unpacked data and in DirectShow it is plainly dropped.

    Here is the link for github project that can be build to illustrate the issue:
    google: github leokv uvc_mjpg_win10 (because this forum does not allow links)

    h t t p s : // github . com / leok7v / uvc_mjpg_win10 


    We've verified it on multiple hosts running Windows 10 in different hardware configuration with at least 4 different camera models.

    Ability to get MJPG encoded raw frames is very important to us from the performance perspective.

    Hope somebody from Microsoft is monitoring this forum and can help.

    Leo

    leo@zspace.com

    Get the tools from third party devices ust like vlc pl,ayer and get the mediapacks ready for downloading also.

    videolan download

    codec

    Wednesday, August 17, 2016 12:17 AM
  • Hello Dacuda. Why not just have your customers use an Ubuntu One disk to have the functionality they need to view your information.  I realize this is not a Microsoft solution but would be a solution that will benefit your customers. Sorry for the Proposed answer on your original post. I hit the button by mistake!


    • Edited by MrRuupee Wednesday, August 17, 2016 1:04 AM
    Wednesday, August 17, 2016 1:03 AM
  • 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.

    Mike,

    It sounds like you guys are focused on fixing MJPEG and H.264.  However, from what I can tell the update has broken almost all formats.  The camera's we use are attached to our machines that we sell.  No customer will want to use them in Windows Hello.  I don't even know or care what that is.  For our color cameras we get video in bayer format.  This update breaks that IMediaControl::Run() now returns error 0x80070491.  YUY2 is not an acceptable replacement as it looses information and uses more USB bandwith.  It also causes some old USB chips to fail when the image is saturated.  For our monochrome camera's I can't even get to Run().  They fail at IMoniker::BindToObject with the same error 0x80070491.  Y800 seems to no longer be supported, so I'm guessing that's why.  At this time we are telling all of our customers to avoid this update and roll back if it automatically installs.  If your solution only fixes MJPEG and H.264, that still leaves all other formats broken.  Would it not be a better solution to simply undo these changes and put DirectShow back the way it was?  Make Windows Hello work the way you want it to without changing DirectShow.  That's what the rest of us do.

    Wednesday, August 17, 2016 2:40 AM
  • Dear Mike,

    Good to know that you are working on update for MJPEG.

    Most of our USB camera customers use more than one cameras on to the Single machine,in which case they might be able to distribute the bandwidth with the help of compressed formats.So MJPEG and H.264 formats are a basic requirement on these industrial Use cases.

    Also lot of medical application,agriculture applications require RAW bayer data in 8 bit,10-bit,12-bit format from the USB cameras in which case we were utilizing the formats FOURCC formats like BY8,Y16 etc.

    Please consider this for next update.


    Please mark it as answer or vote as helpful if my reply helps.

    Regards,

    Prabu[eMVP]

    http://prabukumar.wordpress.com

    Wednesday, August 17, 2016 9:51 AM
  • Does anyone know if a new computer that comes pre installed with version 1607 can be downgraded to 1511?  Given that uninstalling this update is the only current solution available, if that weren't possible we're in serious trouble.

    Thursday, August 18, 2016 3:25 AM
  • Hi Roman,

    Thanks for the nice article. http://alax.info/blog/1686. Since blog don't allow me to comment, i am asking my help here.

    I have industrial camera with custom format (BY8, Y16 etc..), i would like to provide temporary solutions for my customer until Microsoft take these in to consideration ( includes the support for custom formats again).  i would like to create my own capture source filter like you have done for logitech camera. can you guide me on where to start working on it?

    your help will be greatly appreciated.

    Thanks & Regards,


    <p>Please mark as answer, if it is correct.<br/> Please vote,if it is helpful post. <br/> Vinoth.R</p> <p><a title="http://vinoth-vinothblog.blogspot.com" href="http://vinoth-vinothblog.blogspot.com">http://vinoth-vinothblog.blogspot.com</a><br/> <a title="e-con systems" href="http://www.e-consystems.com/iot-gateway.asp" target="_blank">http://www.e-consystems.com/iot-gateway.asp</a></p>

    Thursday, August 18, 2016 8:57 AM
  • Hi Mike,

    Thanks for the update. Is there a sense of a timeframe for an initial fix making its way to the insider fast ring updates?

    Glad to hear it's being worked on.

    Thursday, August 18, 2016 1:09 PM
  • 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!
    Thursday, August 18, 2016 11:46 PM
  • Okay, so you give us Windows 10 Anniversary Edition.  You give us a scant 10 days to revert back.  After the 10 days is finished, we find that 10AE breaks the ability for our hardware to work.  We can't revert back.  The H.264 fix is likely months away.  In the meantime, our expensive hardware is an expensive paperweight.  What are you going to do for us while our hardware does not work?  What are you going to do to compensate for your mistakes?
    Thursday, August 18, 2016 11:55 PM
  • Hardware:

    Logitech HD Pro Webcam C920

    Driver: HD Pro Webcam C920

    Version: 13.80.853.0

    Application: Skype

    Use Case: Source video freezes during first minute of call. Receiving video and audio continues uninterrupted.

    Friday, August 19, 2016 12:57 AM
  • Logitech C930e / Firmware 8.0.875

    Driver 1.1.89.0 / 25 Nov 2015

    Windows 10 14393.51

    Skype 7.26.0.101

    After 5 to 10 secondes the video source freezes while still receiving video ok, sound is not affected.

    Starting the video again works but again only for 5 to 10 secondes.

    it seems to happen when the camera switches to 720p.

    Friday, August 19, 2016 8:59 AM
  • This really confuses me. The Logitech cameras got a skype certificate. But then MS decides to make a change that renders those devices uselss?
    I' would have expected that there is some check in place, to at least be sure not to break certified devices?

    Logitech C930e / Firmware 8.0.891 (newer then zoomelliott's version)

    Driver 1.1.89.0 / 25 Nov 2015

    Windows 10 14393.51

    Skype 7.26.0.101

    Video from my Logitech cam freezes after a few seconds in skype, video from chat partner and audio from both parties still works (NOT using logitech camera microphone)

    Logitech support has a lot of people reporting the same problem...



    • Edited by Deatheye Friday, August 19, 2016 1:02 PM
    Friday, August 19, 2016 12:51 PM
    • Logitech HD Pro Webcam C920

    • Driver: HD Pro Webcam C920

    • Version: 13.80.853.0

    • Application: Skype

    • Problem: My source video freezes during first minute of call. Receiving video and audio is OK afterwards.

    Cosmin Tataru | Contact: http://cosmin.tel

    Friday, August 19, 2016 1:56 PM
  • Hi Mike,

    Skype uses H.264 for some Logitech devices such as the C920 so those devices will be non-functional or will not achieve full HD if H.264 is not supported.

     Aside from the evidence of there being problems, how does one tell which codec Skype is using for a particular device?

    • Edited by rseiler Friday, August 19, 2016 3:36 PM
    Friday, August 19, 2016 3:33 PM
    • Logitech HD Pro Webcam C920

    • Driver: HD Pro Webcam C920

    • Version: 13.80.853.0

    • Application: QTox

    • Problem: The software can't access the webcam, so crash. no problem before win 10 anniversary
    Friday, August 19, 2016 5:10 PM
  • This should restore pre-Windows 10 Anniversary Update behavior and unblock webcams experiencing the freezing-after-few-seconds issue:

    Try opening up HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Media Foundation\Platform and add a DWORD with name EnableFrameServerMode. Set its value to 0 and try again. For 64-bit apps (e.g. UWP Skype), use the same path above, minus WOW6432Node.

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



    • Edited by WithinRafael Friday, August 19, 2016 7:51 PM Clarified applicability again
    • Proposed as answer by Ben Maas Saturday, August 20, 2016 8:34 PM
    Friday, August 19, 2016 6:18 PM
  • Try opening up HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Media Foundation\Platform and add a DWORD with name EnableFrameServerMode. Set its value to 0 and try again. For 64-bit apps (e.g. UWP Skype), use the same path above, minus WOW6432Node.

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

    What will this accomplish?

    Thanks

    Friday, August 19, 2016 7:04 PM
  • Try opening up HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Media Foundation\Platform and add a DWORD with name EnableFrameServerMode. Set its value to 0 and try again. For 64-bit apps (e.g. UWP Skype), use the same path above, minus WOW6432Node.

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

    What will this accomplish?

    Thanks

    It turns off the functionality Microsoft spoke of earlier and effectively restores pre-Windows 10 Anniversary Update behavior.
    Friday, August 19, 2016 7:25 PM
  • Try opening up HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Media Foundation\Platform and add a DWORD with name EnableFrameServerMode. Set its value to 0 and try again. For 64-bit apps (e.g. UWP Skype), use the same path above, minus WOW6432Node.

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

    What will this accomplish?

    Thanks

    It turns off the functionality Microsoft spoke of earlier and effectively restores pre-Windows 10 Anniversary Update behavior.
    I will try this when I get back home.  Thank you for the possible solution!  If it works why couldn't Microsoft come up with it?
    Friday, August 19, 2016 7:33 PM
  • I tried but it doesn't seem to work
    Friday, August 19, 2016 7:34 PM
  • I tried but it doesn't seem to work
    Did you restart?
    Friday, August 19, 2016 7:54 PM
  • I tried but it doesn't seem to work
    I don't think your crashing issue is related to the earlier discussion.
    Friday, August 19, 2016 8:12 PM
  • This should restore pre-Windows 10 Anniversary Update behavior and unblock webcams experiencing the freezing-after-few-seconds issue:

    Try opening up HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Media Foundation\Platform and add a DWORD with name EnableFrameServerMode. Set its value to 0 and try again. For 64-bit apps (e.g. UWP Skype), use the same path above, minus WOW6432Node.

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



    I added that key in both places and restarted my computer.  It didn't fix the problem.  Is it possible that this only fixes the MJPEG decoding problem but not the problem with proprietary formats like BY8, Y800?

    Update: This does seem to have changed the behavior.  Prior to the registry change the failure happened in IMediaControl::Run().  Now it's happening in RenderStream which fails with code: 0x80040217


    • Edited by Michael 47 Friday, August 19, 2016 10:28 PM Update to information
    Friday, August 19, 2016 8:20 PM
  • I tried but it doesn't seem to work

    I don't think your crashing issue is related to the earlier discussion.
    The crash is related to the windows 10 anniversary update because it use the ffmpeg library which crash. And before this update, the software was working correctly.
    I restarted my computer but your fix did nothing :/
    Friday, August 19, 2016 8:28 PM
  • Dear Mike,

    Our company, IVD Vision LLC, is focused on developing vision applications for the analytics industry – primarily for medical diagnostics and related fields.  As such we have the requirement to read cameras in the Y16 format on a windows platform. Additionally we have the requirement of being able to control the cameras, such as setting gain and exposure. We are very disappointed to learn that the current update does not support these functions under the current MS framework. The implications of this change are quite wide ranging for applications such as ours and does not bode well for Windows. When can we expect a version of Windows that will support the functions I’ve mentioned? Of course, our Linux solutions still work ...

    Regards,

    Patrick

    Friday, August 19, 2016 8:57 PM
  • My Acer-W4 tablet just upgraded to the Anniversary Edition. Internal camera now doesn't work...
    Friday, August 19, 2016 9:32 PM
  • Thank you Rafael - this worked for me with a Logitech C920, just using Skype at the moment. 

    Friday, August 19, 2016 9:44 PM
  • When are you going to correct this behaviour that when using the "camera" application on my Logitech c-920 web camera I get an error after some 10 seconds that has error code 0xA00F4271(0xC00D3EA2) and the camera stops working. These camera are NOT cheap and should continue to work after a system update.

    I am extremely disappointed that this was not corrected before the roll out of the "anniversary" update.

    Friday, August 19, 2016 11:06 PM
  • Logitech C270

    Driver: 13.80.853.0

    USB Vender ID (VID): 0X046D
    USB Product ID (PID): 0X0825
    USB Revision (BCD): 0X0010

    Application: Skype 7.26.0.101

    Video seems to be playing fine for me on Insider Build 14901.

    Saturday, August 20, 2016 6:59 AM
  • > We have been focusing on the Windows Insider Program flight data to monitor any issues.

    A lot of people have been having issues because of your new breaking change for many months now (insider users). The issue has been reported here [ https://community.skype.com/t5/Windows-desktop-client/Skype-video-freeze-when-using-Logitech-C920/td-p/4225660 ] on ‎14-12-2015.

    Yes, almost A WHOLE YEAR AGO.

    You guys not only failed to detect the issues from your telemetry/hardware lab test, you guys even failed to notice the issue even when users actually reported it to you.

    Saturday, August 20, 2016 8:45 AM
  • Mike,

    With respect, I think that you're missing the point here, and quite frankly, the Microsoft response is akin to the guys who were re-arranging the deckchairs as the Titanic was sinking.

    This decision to make a breaking change, deliberately bricking lots of otherwise perfectly good hardware/drivers is quite simply indefensible - and it is YOUR job to prevent it happening - blaming vendors for not using their physic powers to "know" about the change reminds me of the scene from the start of the HitchHikers' Guide to the Galaxy, where the details of the impending demolition of Arthur's house were "available in the local planning office"

    “But the plans were on display…”
    “On display? I eventually had to go down to the cellar to find them.”
    “That’s the display department.”
    “With a flashlight.”
    “Ah, well, the lights had probably gone.”
    “So had the stairs.”
    “But look, you found the notice, didn’t you?”
    “Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

    Fiddling around, offering solutions with a timescale of months is simply wrong and unacceptable.  The only sensible solution is to admit that this is an inexcusable error, revert the WHOLE change, go back to the working version, and THEN consider how to introduce camera sharing in a way which actually works, provides backwards compatibility and doesn't alienate the developers who support Microsoft.


    Dave Harvey

    Saturday, August 20, 2016 12:56 PM
  • This should restore pre-Windows 10 Anniversary Update behavior and unblock webcams experiencing the freezing-after-few-seconds issue:

    Try opening up HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Media Foundation\Platform and add a DWORD with name EnableFrameServerMode. Set its value to 0 and try again. For 64-bit apps (e.g. UWP Skype), use the same path above, minus WOW6432Node.

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



    I just did this on my Lenovo X1 Carbon laptop. I can confirm that it restores MJPEG access @1080p30 to a C930e in Open Broadcaster Studio and vMix.
    Saturday, August 20, 2016 1:46 PM
  • hopefully ms doesnt blank patch everybody ! let user chose. from whaty i gather . what people want back is a lagacy extension ! fine make it avail but if the optimal set-up is this new way we got now ? just explain how we re to make use of it in the long run . what supported hardware etc . ms just didnt brain fart this out of the blue ,there is benefit to this way in lot of angle .so please ms .if i say i want to keep the nv12 yuy2 way . dont leave me in the dark gees . call thurrrot or foley and do article about it .same for the patch .if people elect for the patch for legacy extension . dont leave them in the dark figuring out whats what gees . me i want to stick to nv12 yuy2 but i dont know how to go about it .make a list that do yuy2 nv12 natively

    keep up the good work ms .i think this idea is brilliant in the long run but you cant not explain anything lol

    Saturday, August 20, 2016 8:09 PM
  • Thank god I'm using Windows 10 Pro and can at least defer the forced feature updates and removals.

    By breaking a perfectly good update model (now forcing new builds on users) you've really opened up the door to massive screw-ups in the future.  This camera fiasco is just the beginning. 

    Saturday, August 20, 2016 8:22 PM
  • This should restore pre-Windows 10 Anniversary Update behavior and unblock webcams experiencing the freezing-after-few-seconds issue:

    Try opening up HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Media Foundation\Platform and add a DWORD with name EnableFrameServerMode. Set its value to 0 and try again. For 64-bit apps (e.g. UWP Skype), use the same path above, minus WOW6432Node.

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



    I just did this on my Lenovo X1 Carbon laptop. I can confirm that it restores MJPEG access @1080p30 to a C930e in Open Broadcaster Studio and vMix.

    This is a perfect example whats currently wrong with Windows. Denial of options for the user to choose from even if it is not a big deal to offer them. A simple checkbox in the controlpanel "Use Videodevice Legacy Mode" and everyone could have been happy.

    Please stop being like apple and stop forcing people to do it YOUR way! I understand that sometimes it is neccassary to cut out dead wood. But this is certainly not the case.

    Same goes for GUI and design elements. Metroscreen anyone? Or the cut of the beloved aero design? Widgets? (yeah sure, they were a security risk!)

    Saturday, August 20, 2016 8:51 PM
  • hello, i'm a streamer & game developer with VERY low income (for now), i use my webcam as my microphone AND in obs-studio (logitech c270) when i stream on twitch & livecoding; i CANNOT buy a headset.

    IF my webcam cease to work, i swear, that'll make me be forced to backup over 1 TB of data & lose about 4 days of work because i have to reinstall windows 10 without anniversary update; then i swear : i'll sue you untill you provide me hardware that work + compensation.

    fix this, allow h264, stop lying, we all know that you wanted to ban h264 for years because of it being an opensource codec.

    you're warned; many of us don't have the time to deal with stupid things like that and many of us are already pissed off at the agressive techniques you used to force us to switch to windows 10.


    • Edited by dragutux Sunday, August 21, 2016 2:15 PM
    Sunday, August 21, 2016 2:11 PM
  • Hello Mike,

    I appreciate the communication, and the attempt to keep everyone posted. It's not easy to be the one going in the pit and sharing the bad news. However I think the proposed course of action from MS is a bit unacceptable. I understand why you are trying to implement the change you did (even though this might be premature optimization as so far I guess few people have multiple apps using their webcam stream, but fair enough). But seeing as the approach is crippling hundreds of thousands of people using webcams, and apparently companies relying on Windows as well, the only acceptable course of action is to rollback the change, think hard on how to implement it better, and then test it and roll it out again. I suspect the reason this has not been proposed is that this would cripple critical features announced with Anniversary update. Very sloppy Q&A job on this one :(

    I just bought the Logitech C920 webcam as I'm taking a Coursera course, which requires that I take a picture of myself before taking the exam as an authentication measure. Now I have to stick with using my corporate laptop to do that because I won't be able to use my brand new camera.



    Sunday, August 21, 2016 3:31 PM
  • Hi Mike M.

    I just want to describe my scenario as another point of feedback.

    I develop a video application called Kinovea¹ with recording capability. It works on top of DirectShow and lets the user select the input stream format.

    The output format for recording is MJPEG. MJPEG is a good fit for the playback part of the application as we analyze sport sequences and thus focus on frame by frame, backward navigation and slow motion.

    Since the output format is MJPEG, when the input stream is also MJPEG the code goes through an optimized pathway where the stream is not decoded and the frame packets are stored as-is in the output file. This allows the recording of several full HD sources on relatively old computers as it shortcuts the decoding step on the path between camera input and storage. (For display purposes there is a step of decoding but it happens on a different thread that is not critical to the operation and will drop frames as needed to give priority to the recording).

    So in this scenario it is very important that DirectShow keeps providing the compressed stream, as it is the primary format the application is interested in. Similarly, other applications may not need to decode the stream at all, saving the compressed data directly to disk.

    Thank you.

    ¹ http://www.kinovea.org/

    Sunday, August 21, 2016 7:30 PM
  • After the Windows 10 upgrade, my NextPVR (which uses DirectShow) live TV went black. It broke my Hauppauge USB WinTV-HVR-955Q TV Tuner. 

    The registry fix repaired it and everything works normal again. 


    ~Paul

    Sunday, August 21, 2016 11:41 PM
  • We sell products (ROBOTS) that use Microsoft computers running Windows 10. Microsoft Anniversary Edition has deliberately decided to drop support to MJPG, without notice, so affecting our business and our many existing customers!!!!!

    We FORMALLY request microsoft to give us back the functionality, and to avoid breaking professional businesses that chose their operating system!

    Monday, August 22, 2016 10:23 AM
  • I have this same issue.  Hoping to get a 1511 iso if anyone has one...
    Monday, August 22, 2016 7:39 PM
  • 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.

    [...]

    To ensure these changes will allow you to continue using your current devices, drivers and/or applications without changes we would appreciate your input. 

    I do understand regular quality assurance procedures, especially as MS probably doesn't want to embarrass themselves with a serious of half-working patches in this now becoming "high profile" bug.

    However, in reference to my highlights in Mike M's reply above: The worst possible regression has already happened with the AU. Given a working hotfix/workaround will be available, users will not continue using their current devices, but they will start again using their devices, or "revert back to the previous state of using their devices without problems". This is what has to be realized by the Windows Camera Team!

    If this doesn't get fixed really fast, I expect a growing media fallout and an even greater loss of trust in MS.

    Monday, August 22, 2016 10:33 PM
  • Try opening up HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows Media Foundation\Platform and add a DWORD with name EnableFrameServerMode. Set its value to 0 and try again. For 64-bit apps (e.g. UWP Skype), use the same path above, minus WOW6432Node.

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

    What will this accomplish?

    Thanks

    It turns off the functionality Microsoft spoke of earlier and effectively restores pre-Windows 10 Anniversary Update behavior.

    I will try this when I get back home.  Thank you for the possible solution!  If it works why couldn't Microsoft come up with it?
    This partially works for me.  My c920 works again for Skype.  But, taking static images still doesn't work.

    Thank you WithinRafael
    Tuesday, August 23, 2016 12:01 AM
  • 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.

    [...]

    To ensure these changes will allow you to continue using your current devices, drivers and/or applications without changes we would appreciate your input. 

    I do understand regular quality assurance procedures, especially as MS probably doesn't want to embarrass themselves with a serious of half-working patches in this now becoming "high profile" bug.

    However, in reference to my highlights in Mike M's reply above: The worst possible regression has already happened with the AU. Given a working hotfix/workaround will be available, users will not continue using their current devices, but they will start again using their devices, or "revert back to the previous state of using their devices without problems". This is what has to be realized by the Windows Camera Team!

    If this doesn't get fixed really fast, I expect a growing media fallout and an even greater loss of trust in MS.

    AGREED.  This needs to be fixed 'yesterday'!  Any improvement over the current state of affairs is better than nothing.

    Tuesday, August 23, 2016 8:55 AM
  • Hi Mike,

    For some USB cameras it seems that the MJPEG decoded stream is merged with the YUY2 media type for Direct show, so that these cameras now provide 30 FPS at full resolution with YUY2. For other cameras this does not seem to work and the full resolution YUY2 formats just provide slow frame rate only.  

    I do understand that you guys are working hard on a solution to bring back compressed media type, thank you for that. But in our use cases we do not specifically depend on compressed format. We would be happy just to consume either YUY2 or NV12 from direct show provided that we could get the same high resolution and FPS that we could get before using mjpeg - but as mentioned this only works for some cameras and not for others. Can you elaborate more on the implementation details of the new frameserver system and why things seem to be working for some cameras and not for others?
      

    Wednesday, August 24, 2016 7:13 AM
  • As soon as I upgraded (in place) from Windows 7 Pro to Windows 10 Pro (x64) I found out that my Logitech QuickCam Pro 9000 webcam wasn't working with the Windows 10 "Camera" app (but it was working with the Logitech Webcam Software and with Skype).

    Now after upgrading to Windows 10 "Anniversary" I cannot use the Logitech Webcam Software: when I try to display the image from the webcam the application (launcher_main.exe) crashes.

    I can use the webcam in Skype and with other webcam software (specifically, iSpy) but I have implemented the registry modification documented above, and I don't know if the reason it works with these applications is the registry modification or if it would have worked anyway.

    There is an official statement on Logitech's Forums about the issue, and basically they are saying that they are waiting for a fix from Microsoft (https://community.logitech.com/s/question/0D53100005Hy18SCAR). Yet, in this case the problem is not "just" that the webcam doesn't send any image; the application crashes which is a step further. It's unclear if Logitech must also do something, or if the MS fix will be enough.

    In either case, Mike from the Camera team, let me ask a question please, what do you mean exactly with "this behavior was planned, designed, tested, and flighted out to our partners and Windows Insiders"? Is Logitech included in these categories? Was the Anniversary Update tested with Logitech webcams before releasing it? From Logitech's official (provisional) answer in their forums, it looks like they knew nothing of this change and for sure they didn't expect it to affect their products, and it's clear that MS did not test it against the Logitech Webcam Software since (at least with many webcams) the crash to desktop is immediate and inevitable. As a result, millions of webcams are now dead in the water. You guys apologized for not being adamant with the end users about this change, but what about major hardware manufacturers like Logitech?

    In case it helps, anyway here is the error code I am getting when I open the "Camera" app: 0xA00F4271(0x80070491). While we wait for the MJPG fix, I would really appreciate if you'd help me with sorting out this error. Thanks.

    • Edited by MaxFrames Wednesday, August 24, 2016 7:51 AM
    Wednesday, August 24, 2016 7:49 AM
  • Logitech did not take a trouble of checking their hardware and software with beta version of OS when it was available. Microsoft did offer this build early enough for the interested parties to identify and sort out the problems timely - it appears that few took advantage of this offering.

    Logitech has to share this fail because they could have responded earlier and not just go with the flow and come up when everything was cleared up for them.

    Same applies to Skype and other vendors. This Media Foundation update (without writing off the Microsoft's share of the issue) just revealed how careless they all are and their blind belief in their supposition that breaking changes are impossible.

    Loss of MJPG is fixed by registry update mentioned in this thread. If the problem persists then the application has other issues to fix apart from MJPG.


    http://alax.info/blog/tag/directshow


    Wednesday, August 24, 2016 9:02 AM
  • Same applies to Skype and other vendors.

    Are you aware that Skype is part of Microsoft?

    Regarding whether other vendors "knew" about the issue, see my post above comparing Microsoft's approach to that of the man from the council in HitchHikers' !


    Dave Harvey

    Wednesday, August 24, 2016 10:17 AM
  • Hi Mike,

    I think the problem does not only affect the webcam. There are also problems with Adobe Premiere Pro (various video formats will not be saved) and also with games. Fifa 16 crashes (see photo) at startup. At the very moment when by video sequences are searched.
      Regards Jo

    https://social.msdn.microsoft.com/Forums/getfile/926595

    The tip for the Registry (via Remedy registry entry
    available until the updates to loud postings in the same forum bringing improvement a registry engagement: to get up and running order 32-bit applications again, to wear in the key HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ Windows Media Foundation \ Platform a new DWORD value named EnableFrameServerMode a fashion it a value of 0 to. For 64-bit messenger applies the same registry path without WOW6432Node) works with Logitech HD Pro C920 in video mode. Unfortunately, not for still images and not the game Fifa 16 (also Fifa 15).




    • Edited by Ziguin Wednesday, August 24, 2016 11:43 AM
    Wednesday, August 24, 2016 10:37 AM
  • Mike refers to Skype above as "partner team". Which, with respect to the scale of Microsoft, is essentially the same as other partner vendors: Media Foundation teams has their own agenda, Skype has theirs.

    While Anniversary update was in beta interested parties did have the information about these changes (quick example, or this one, and I know it because I had people emailed me on this a couple of times before update went public).

    While many were caught by surprise, some were not and still let this all crash with a bang.


    http://alax.info/blog/tag/directshow

    Wednesday, August 24, 2016 10:43 AM
  • I am not saying that Logitech is 100% "innocent". But the change was brought by the Anniversary Update. Previously, the now crashing software was working perfectly in Windows 10. I think the reason it crashes now is because of changes in some driver. Whether this is due to the driver change or to bad coding on either part, we don't know because it's all closed source.

    In addition as I said, MS's "Camera" app does not work with the camera (all the other webcam apps I've tried do). Is this also Logitech's fault?

    Finally, as Dave Harvey pointed out, it's unclear if and how hardware vendors were made aware of the change. While I agree that seizing the opportunity to test an OS release in advance is advisable for any vendor, that hardly means that third party vendors are responsible for broken code or, like in this case, broken logic on the OS vendor's part.

    Wednesday, August 24, 2016 1:18 PM
  • Hi Mike,

    I think the problem does not only affect the webcam. There are also problems with Adobe Premiere Pro (various video formats will not be saved) and also with games. Fifa 16 crashes (see photo) at startup. At the very moment when by video sequences are searched.
      Regards Jo

    https://social.msdn.microsoft.com/Forums/getfile/926595

    The tip for the Registry (via Remedy registry entry
    available until the updates to loud postings in the same forum bringing improvement a registry engagement: to get up and running order 32-bit applications again, to wear in the key HKEY_LOCAL_MACHINE \ SOFTWARE \ WOW6432Node \ Microsoft \ Windows Media Foundation \ Platform a new DWORD value named EnableFrameServerMode a fashion it a value of 0 to. For 64-bit messenger applies the same registry path without WOW6432Node) works with Logitech HD Pro C920 in video mode. Unfortunately, not for still images and not the game Fifa 16 (also Fifa 15).




    Why would a game like FIFA be affected?  Does FIFA use the camera for anything?

    By the way, your image doesn't display.  It says "Page Not Found"
    Wednesday, August 24, 2016 1:24 PM
  • This is not to write off responsibility of Microsoft for the issues - I wrote it from the very start.

    Your saying that "reason it crashes now is because of changes in some driver" and "Previously, the now crashing software was working perfectly" are just assumption without reasonable support.

    Video capture through standard APIs works fine in Anniversary Update, just reduced in modes. That is, the crash cause might be equally caused by Logitech software doing certain unreasonable assumptions, and the fact they released code once it stopped giving immediate issues instead of cleaning it up to stable state.

    Regarding sudden breaking changes of the update I will give another example (to add to mentioned above): the original poster of this thread mentions on StackOverflow that he knew about the problem before public update. Here is what he writes:

    I had the Insider build since January and told Microsoft about deficiencies of this approach.

    My point here is that Microsoft released poorly documented and prepared update, and Logitech released buggy software earlier which was not stable enough to operate in environment changing within documented API contract. Both failed to act timely to resolve the problems before they reach masses. Both invested into what we have now with video capture and cameras.


    http://alax.info/blog/tag/directshow


    Wednesday, August 24, 2016 1:39 PM
  • For anyone interested in long-shots, there's a new version of Skype (7.27.0.101) to try.
    Wednesday, August 24, 2016 4:14 PM

  • Image problem: "Body text cannot contain images or links until we are able to verfy your account."
    Wednesday, August 24, 2016 4:39 PM
  • Thanks for this. 

    This did address the issue with my Thinkpad Carbon X1 2014 model. 

    Now the built-in webcam and a external presentation camera from IPEVO works again. 

    Thursday, August 25, 2016 5:32 AM
  • Hey Mike are you still monitoring this thread? I would really appreciate any feedback.

    Interestingly enough, the problems with my model of webcam were known to MS back in May:

    http://answers.microsoft.com/en-us/insider/forum/insider_wintp-insider_devices/build-14332-logitech-webcam-pro-9000-wont-work/ae6210b9-5786-4b63-8c2b-b36b008b9a1f

    I don't recall seeing a warning about it when I installed the Anniversary Update a week ago...

    Rest assured I will also continue to request feedback from Logitech... but so far, I had none on both parts.

    Thursday, August 25, 2016 10:08 AM
  • How about an Update.  We shouldn't have to keep asking for them every week.  M$FT only broke about a million webcams.. thats all.  No biggie.
    Wednesday, August 31, 2016 4:50 PM
  • Hi everyone, I’m back with an update. We’re pushing a set of changes through Windows Update today, 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!

    Wednesday, August 31, 2016 7:53 PM
  •  :(

    tracey-moragan-nope.gif

    Camera still dying, thanks for making my last month of streaming a freaking nightmare of frustration.

    • Edited by errr090 Thursday, September 01, 2016 2:00 AM i spoke too soon.
    Thursday, September 01, 2016 1:38 AM
  • Hello again Mike.

    I've installed KB3176938 and rebooted, it made no difference whatsoever.

    The Camera app is still crashing, Logitech Webcam Software is still crashing.

    At this point, the ball _may_ be in Logitech's court now, or it may not. What I know is that I have two apps crashing, one from Microsoft and one from Logitech. I'm still waiting for some detail on the cryptic error number I am getting on the Microsoft app (0xA00F4271(0x80070491) and I am baffled there is no feedback about it, considering I've been getting it since I installed Windows 10 (i.e. it wasn't brought up by the Anniversary Update).

    Anyway.... I've ended up using iSpy which is a surveillance software but can work as a webcam software substitute (it can stream and capture images and videos).

    Thursday, September 01, 2016 7:38 AM
  • Hello Max,

    Can you start up a thread in the Windows Answers forum? Please detail what Logitech device you are using.
    Windows Answers Camera Forum

    Also as Mike suggested filing a Feedback report would be helpful. The short of it is, there is an expired driver for Logitech cameras that is known to trigger the error 0x80070491 on your device when using Windows Camera. If you uninstall the driver, marking the delete driver option, then rescan for hardware changes, you should pick up a good driver. You can find steps to do this in this troubleshooting article:
    Windows 10 can not find or start the camera

    As for detail on your error, it's a generic error returned by the Logitech driver which basically is "ERROR_NO_MATCH" indicating the driver is advertising a invalid media type.

    Thanks,
    Tom


    TomA| Microsoft | Windows Camera Team [MSFT]


    Thursday, September 01, 2016 5:36 PM
  • Hi Tom,

    I've followed the instructions, but upon rebooting the Logitech driver - supposedly broken in Windows 10 - was automatically reinstalled (version 13.80.853.0).

    So I uninstalled the driver again, this time also uninstalling the Logitech Webcam Software before rebooting.

    Upon rebooting a Microsoft driver was installed for the webcam, which is now working in the Camera app (no longer crashing) and still working in iSpy. Of course I don't have the Logitech software anymore, but iSpy can make shift for that.

    Thanks for the support. I will now start annoying Logitech until they admit it's mostly their fault for not updating their drivers and software, and provide new versions.


    EDIT: I didn't reboot or do anything at all, and the Microsoft driver has been automatically replaced by that same Logitech 13.80.853.0 driver (which by now was totally deleted from the PC, so I guess it has been downloaded automatically by Windows 10's automatic driver update feature - which I'd disabled in Windows 10, but it looks like the Anniversary Update has reenabled it, without my consent - oh well, there WAS a reason I'd disabled it and now I just hope everything will be OK anyway...). The good news is that the Camera app still works. So... I must conclude that there are TWO versions of the same driver, same version number, one borked (from Logitech) and one working (from Microsoft)? Or else that the mere presence in the system of the Logitech Webcam Software makes the world crash? It gets involved...
    • Edited by MaxFrames Friday, September 02, 2016 11:01 AM
    Friday, September 02, 2016 7:35 AM
  • Hi Mike and Tom, 

    I tested the new update KB3176938, and I would like to inform you that it does NOT help for our product. 
    I have completely the same result as before. We cannot read the MJPEGs from our custom camera. 

    When I do the change in the registry as suggested above, the camera is working. 

    Can you please explain what was exactly fixed in this update?

    Can we expect that you really solve the problem any time soon?
    Friday, September 02, 2016 11:58 AM
  • Hi Tom

    We couldn't connect to our camera device with the new update. We and our customers are still waiting for a solution asap.

    Regards, Stephan

     

    Friday, September 02, 2016 1:08 PM
  • Hello, Mike and the rest of the Microsoft "camera team"...

    I just read through this thread and am amazed that there still isn't a "fix" as of today - 2 Sept 2016 - other than a work-around for the Logitech C920 [and many other webcams] to work in the "anniversary" issue of Windows 10...

    I am by no means a programmer, developer, or would I even claim to totally understand all the technical discussion that has occurred in this thread - I am just an "end user" of a product from a company that evidently wasn't notified by Microsoft of the upcoming changes in the OS Windows 10 and that their webcam - in my case the C920 - would more than likely wouldn't work once the latest Windows 10 OS was put out there and installed on many, many, many user's computers...

    Yep, the old adage - "If it ain't broke, don't fix it" - sure applies here...  I'm all for improving a product, but improve it and change a component in it that would affect millions of users...?  That doesn't make a whole lot of sense...

    Maybe it's time that Microsoft suffer the same monetary damage that car companies suffer when they have to do a massive recall on a product that doesn't work as it should [or is unsafe]...

    When a product affects millions of users in a negative way, then the producer of that product should suffer a monetary consequence - especially considering the number of businesses using Microsoft products; in this case those who have relied on an operating system for years only to have that system betray them and their customers, and continue to betray them without a providing an immediate and reliable fix to resolve the webcam not working issue...

    Your lengthy explanations are all well and good, but it does not resolve the issue at hand...  I don't want my mechanic to go on and on about how the engine and it's components work and what the mistake was when he tried to "upgrade" the system, i just want him to fix it and spare me the explanations... Fix it first then explain what happened and why...

    Thank you...  I just hope you are in contact with Logitech as well so they can help get this issue resolved YESTERDAY...!

    Saturday, September 03, 2016 12:27 AM
  • Even if Logitech was not directly notified of the change (a matter about which I've enquired here, but there was no answer), what would you do if you were a hardware vendor, Windows was the platform from which you gained 99% of your revenue, and there was a new version of Windows out there to try? May I guess "test your hardware on the new version ASAP"? Logitech is inexcusable, and even as of now they claim Microsoft has to fix the issue.  Never mind it's only their software that crashes... I don't know if Logitech is working behind the curtains or not, all I know is that Microsoft has starting to address the issue (for which they are partly to blame) but Logitech looks dead in the water.
    Monday, September 05, 2016 7:13 AM
  • Regret to say that KB3176938 does not fix the problem with our custom cam. 
    Monday, September 05, 2016 3:01 PM
  • I had the same problems you guys been having with webcam issues,  I have a logitech cam C210 and for weeks after the  Anniversary update I've experienced issues with the webcam, so today I decided to uninstall the webcam software and drivers then rebooted the computer after the reboot I reinstalled the software and drivers and it worked fine like it did before the  anniversary update . My windows version is Version 1607 OS build 14393.105. Try uninstalling the cam software and drivers then rebooting your computers then after windows load then reinstall the software and drivers again, It worked on the logitech software , skype, win 10 cam app and messengers.  Performing the uninstall and rebooting then installing the cam software and drivers worked for me, Good luck guys!
    Monday, September 05, 2016 6:52 PM
  • Someone in the Logitech forum says the latest Insider build solves the problem with the Logitech webcam software without any further ado:

    https://community.logitech.com/s/question/0D53100005Hy18SCAR

    So all you guys from the camera team: can you confirm this? Any details?

    Tuesday, September 06, 2016 12:21 PM
  • Hello guys,

    I'm a software and hardware developer and have found other problems with the 1607 update. The DirectShow event EC_DEVICE_LOST, for instance, is not being sent anymore. I created a thread for it here in this forum: "DirectShow event EC_DEVICE_LOST not being sent after Windows 10 Anniversary update 1607"

    We are also having trouble with our cameras regarding the same problems reported in this thread.

    All my customers that had W10 updated automatically for 1607 are now unable to use our solutions. We are having to give them support to rollback windows to a previous build.

    Best Regards


    • Edited by MauroAnjo Wednesday, September 07, 2016 11:01 AM
    Wednesday, September 07, 2016 10:53 AM
  • Logitech PRO9000

    LWS 13.51.828

    Try to run LWS => Launcher_Main.exe  has stopped working

    W10 AE

    Sunday, September 11, 2016 6:54 AM
  • Same issue, PRO 9000 works with Skype, but blank in everything else.  Launcher_Main.exe stopped working error.  Sent query to Logitech waiting for reply.

    Big Al

    Friday, September 16, 2016 2:02 PM
  • Same for me on my Logitech C270.

    Come on Microsoft: man up and sort the problem out.

    Thursday, September 22, 2016 1:49 PM
  • We haven't heard from Microsoft for a while now about this issue, could anyone from the camera team please update us about their progress, when would a fix be available, from this thread I can see some people can't afford to wait, could you provide us at least with a temporary workaround until a fix becomes available, your negligence and cover-up policy is forcing us to use registry tweaks.
    Sunday, September 25, 2016 8:29 PM
  • I'm a developer of an application that uses H.264.  We just recently started to get complaints from clients who have upgraded to Windows 10 Anniversary edition.  I've just confirmed with at least one of them that it still occurs with KB3176938 (OS Build 14393.105).  Could someone at Microsoft please comment on this?  Was KB3176938 supposed to fix the issue with H.264 being filtered out, or is this coming in a later release?  
    Monday, September 26, 2016 8:02 PM
  • 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.

    Thank you all!

    • Proposed as answer by Anahita Bahrami Friday, September 30, 2016 12:32 AM
    Thursday, September 29, 2016 8:08 PM
  • Hi Mike, 

    I would like to confirm that this update KB3194496, OS Build 14393.222 fixed the issue for our custom camera and we can use our product again on Windows 10.

    Thanks a lot for the support 


    Friday, September 30, 2016 11:32 AM
  • Mike,

    I'm still testing, but so far this last update seems to work for all cameras that we use without any changes on our side.  I haven't seen any problems yet.

    Thank you

    Saturday, October 01, 2016 1:51 AM
  • Hello, Mike,

    This update did not fix the problem with my webcam.

    I'm using ASUS laptop, USB 2.0 UVC HD Webcam. Driver version 10.0.14393.82

    It's freezing in Camera application.

    Skype, Google hangouts cannot detect camera, or it is blinking first but eventually "cannot detect camera" message appears anyway.

    Sorry, I could not find a link to feedback.

    Could you please help?

    Thank you


    • Edited by Svitlana K Saturday, October 01, 2016 3:43 PM
    Saturday, October 01, 2016 3:43 PM
  • Thanks for the update Mike.  OS Build 14393.222 has indeed fixed our issue.  

    Wednesday, October 05, 2016 6:01 PM
  • Unfortunately KB3194496 didn't fix the problem for at least one application using a Microsoft Lifecam Studio.Whe it tries to enumerate the video modes available it comes up empty.

    I thought this fix re-exposed MJPG format which I understand that this application is looking for

    Dave

    Thursday, October 06, 2016 4:46 PM
  • Here's what I have found:
    • Lenovo X1 Carbon
    • Win 10 Pro (KB3194496 installed on 9/30/2016)
    • In registry EnableFrameServerMode = 1 (turns on new frame server mechanism)
    • Logitech C920 can be used at 1920x1080.
    • Available video modes are: XRGB, I420 and MJPEG.
    • No access to H264.
    Thursday, October 06, 2016 9:51 PM
  • Still seeing issues after 14393.222 using DashWare (www.dashware.net). DashWare uses FFMPEG to create videos and can't load video files any more (H.264?) after the anniversary update. I assume this is related to the codec issue as it works perfectly on machines that haven't been updated yet (which are quickly dwindling). Any hope for a fix? GoPro now owns DashWare so this is a popular product that is now dead in the water due to the anniversary update.



    • Edited by Ck63028 Monday, October 10, 2016 8:40 PM
    Monday, October 10, 2016 5:10 PM
  • Hi Michael,

    For your question I had to do a bit of research and talk to some of the other engineers on the team, so I’ll try to relay the information collected as best as I can.

    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.

    Monday, October 10, 2016 8:07 PM
  • My camera still don't work.

    I have win10pro with this KB update and registry edit =1. 

    Wednesday, October 12, 2016 1:34 PM
  • Hi Michael,

    I have two laptops: Asus Zenbook UX303LB and Asus Zenbook UX301LA. Their webcams are no longer working after the anniversary update, even after the above mentioned KB update. Is it there any viable solution for this issue ?

    Marco



    • Edited by mammuth00 Monday, October 17, 2016 9:28 AM
    Monday, October 17, 2016 9:27 AM
  • Hi all,

    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!

    Thursday, October 27, 2016 5:16 PM
  • Hi Mike,

    believe what you want. The webcams of my laptops (both of them !!) simultaneosly stopped working after the anniversary update. You want me to accept that this is a driver issue ?!? Well, I'm convinced this problem is strictly connected with the update. And this is something you should have taken care of by now.

    I'm not a developer though, so OK no problem, I'll manage to look for a solution elsewhere.

    Regards.

    Marco

    Friday, November 04, 2016 7:13 PM
  • Hi Mike M,

    I have tried two different external USB webcams in addition to my laptop's integrated webcam, for every one of them, adding the "EnableFrameServerMode" registry key with value "1" makes the Camera app fail to launch with error code 0xA00F4246 (0x887A0004), changing the value to "0" fixes the problem for three of them, which makes me wonder on the number of different webcam models suffering from this issue, it's worth noting that the three were using nothing but the generic USB video device driver delivered with version 1607.

    Please do what you can to further investigate the cause of the problem, is it a driver incompatibility with say older webcams (I'm talking about the generic USB video device driver), something caused by the frame server, or the media type a webcam can provide, can this problem only concern Windows Store apps, as desktop apps seem to work properly, I'm personally in no rush to get a solution, I just hope it will come eventually.


    • Edited by Ilyes Kraïem Monday, November 07, 2016 6:23 PM Prononcuation mistake
    Monday, November 07, 2016 6:18 PM
  • Yesterday, I tried running the Camera app on my cousin's laptop using it's integrated webcam, the laptop started life in Windows 8, and it is currently running Windows 10 version 1607, it ran perfectly without a problem, it seems more recent PC's, designed for Windows 8 and more recent, don't suffer from the issue described in this thread, leaving the oldest ones with unfonctional webcams, very frustrating !!
    • Edited by Ilyes Kraïem Thursday, November 10, 2016 9:56 PM Reference clarification
    Thursday, November 10, 2016 9:55 PM
  • Same issue here. Same camera
    Tuesday, January 03, 2017 8:06 AM
  • I have some good news, I think one of the recent cumulative updates for Windows 10 solved this issue, the "EnableFrameServerMode" registry entry is no longer needed, even after deleting it the camera now works correctly, better late than never, great job Microsoft.
    Sunday, April 16, 2017 12:30 AM