Logitech camera video freezes in Skype after Windows 10 Anniversary Update

Windows 10 Anniversary Update broke Skype video conferencing in classic Skype desktop application for many users.

Video from Logitech cameras is freezing in Skype

There is a number of pieces of software running together to power video conferencing and standing in front of the end user application people don’t see whose fault is the broken video. There is Microsoft, Logitech, Skype (oh wait, Skype was acquired by Microsoft, so some think that that somehow changed the internals and the core of the existing at the time of the acquisition application).

This really confuses me. The Logitech cameras got a skype certificate. But then MS decides to make a change that renders those devices uselss? […]

The reality is that even though Anniversary Update does an extremely extravagant change in the API used by many applications, that it changed behavior of the applications, and that it constrained the capabilities of such nice cameras as Logitech’s C920, C930e and other. The reality is that video capture using these Logitech cameras is still well functioning in updated Windows. The update made highest modes unavailable, destroyed ability to capture M-JPEG and H.264 video,but the cameras still work in other simpler raw video modes smoothly.

So what’s the heck the problem with this videoconferencing? Skype’s implementation for video capture in desktop application has been terrible for years. There was noone there to ask questions why they support some devices and not others, what was the problem in their inability to work with certain cameras while other application work with them well etc. Instead, they hid the problem by offering certified cameras. This is leading to nowhere in long term, and this case of broken videoconferencing is the respective example. The video capture was not done right in first place and relied on things it should not have relied on.

Another question is that videoconferencing is one of the key Skype features. Insider builds of new Windows were available over months.

… 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…

Somehow it appeared that Skype’s guys were unable to respond timely to the coming update deployment, and ended up with a tornado of customer complaints. Who are the partners whom Microsoft worked with to make sure that the change is not fatal for their applications and hardware? Logitech and Skype don’t seem to be on that list.

German users discuss it here:

Wobei das auch ein perfektes Beispiel ist, wie ignorant Entwickler und User gegenüber den angebotenen Möglichkeiten von Microsoft sind.

Mir geht es nicht um den technischen Aspekt, der ist in der Tat diskutabel und auch wenn Microsoft da noble Absichten hat (gleichzeitiger Zugriff mehrerer Apps auf die Kamera etc. – steht ja alles im MS Foren Link), ist das nen breaking Change der viele eiskalt erwischt hat und wohl übers Ziel hinaus geschossen ist.

Nur da muss man sich fragen warum. Microsoft gibt zwar zu, dass die Änderung besser dokumentiert sein könnte, aber sie ist seit Januar! in den Insider Builds live. Im MS Forum beschweren sich User, dass tausende ihrer Kunden von einen Tag auf den anderen Probleme mit ihren Produkten haben aufgrund dieser Änderung und ich frag mich nur – was hat die Firma das halbe Jahr gemacht seit die Änderung zum testen verfügbar ist? So wichtig kann denen ihr Kundenstamm ja nicht sein… Jeder kann kostenfrei Insider Builds beziehen und Entwickler sollten die Möglichkeit nutzen ihre Produkte frühzeitig zu testen. Ich verstehe diese Ignoranz nicht – warten bis ein Update kommt und hoffen es hat sich nichts geändert. Früher war das leider die Regel und es gab bei jedem großen OS Release immer ne ganze Weile bis Softwarehersteller Inkompatibilitäten behoben haben, aber das sollte gerade durch das Insider Programm sehr zurückgegangen sein. Stattdessen warten Hersteller immer noch ab und betreiben lieber Flickschusterei statt pro aktiv Ihre Software im Vorhinein anzupassen, so dass ihre Kunden auch beim Start der neuen OS Version gleich ein funktionierendes System haben.

Im Forum sieht man auch wie redebereit Microsoft ist und wie kurzfristig auf das Userfeedback eingegangen wird und dementsprechend zügig auch ein wenig ihrerseits von den Einschränkungen des System zurückgenommen werden (MJPEG wird im ersten Schritt wieder zugelassen). Aber die Diskussion ist nen halbes Jahr zu spät, nicht seitens Microsoft sondern auf der Seite der entsprechenden Entwickler die nicht die angebotenen Möglichkeiten genutzt haben, frühzeitig die Änderungen zu testen.

OK, Skype is acquisition, what about Skype for Business (previously known as Lync)?

… Optimized for Skype for Business, the C930e Webcam supports H.264 with Scalable Video Coding and UVC 1.5 encoding to minimize its dependence on computer and network resources.

I suppose Lync team is also not on the mentioned list of partners. With some knowledge of Lync’s internals the Anniversary Update is likely to block the optimization cited above. As a video capture source, Logitech C930e cameras no longer offer H.264 video and Skype for Business is unlikely to be able to utilize it – the camera is likely to operate in fallback mode, just as other cameras. Perhaps someone from Lync should have mentioned that in January or earlier. Or maybe they did it, who knows.

Long story short, supposed Skype update will fix freezing soon (also good news they are delivering it not using Windows Update, hence fix will come faster), and then Media Foundation team will provide solution that restores H.264 optimizations later in a few months.

Lync (Skype for Business) and H.264

A blog reader asked an interesting question a question about H.264 support in Lync. There have been a number of announcements on H.264 integration with multiple pieces of software:

Fantastic news! I will just leave the links here (perhaps they are not even all quite relevant) for the time I would want to revisit this pile of issues (or this would hopefully never happen). Some of them are from quite some past. Presently, however people having really hard time getting stuff working well one with another:

Let’s just make one thing clear. I do have Windows 8.1 system which is supposed to pick up UVC 1.5 compliant camera, and I do have “1st of New Generation of UVC 1.5 H.264 WebCams” Logitech Webcam C930e camera.

More to that, I do see it does do H.264 (in a weird way but still – and the camera itself is really cool, I like it!):

H.264 Video Capture with Logitech C930e

As a user, I expect that Lync 2013 (Skype for Business 2015) somehow figure the H.264 support out and do the thing out of the box. This is what the original question I was asked was about. What I do see – and this is what I was able to “touch” myself to avoid guesswork – is that a preview video feed from the device is NOT using H.264:

Video Preview with Lync 2013 and Logitech C930e

Well, maybe it is leveraging H.264 in real conference? Not sure.

Perhaps Skype can capture H.264? Oops, not it cannot (this is from real video call session):

Skype Video Call and Logitech C930e

Okay, it simply does not all work yet. As a guess, this worked with Windows 7 style of H.264 webcam and then the way Windows 8 offered support for UVC 1.5 devices broke it (if it at all ever worked!).

Bringing virtual DirectShow devices back to life with Skype 6

As mentioned before, new Skype 6 broke compatibility with all virtual DirectShow devices out there. Just oops, nothing works any longer if only it is not a full driver exposing virtual device through WDM.

Since quite some people are interested in details (Skype 6 Virtual Camera issues, Skype Client for Windows – SCW-3881 – Virtual cameras no longer work with Skype 6), here goes a bit of relevant information on the problem.

New Skype still uses DirectShow as API to interface capture devices and to discover such it enumerates them the way all decent applications do: Enumerating Devices and Filters. Presumably, there was a good reason to touch the video capture code and from moderately terrible it started being even worse. Skype guys decided that if a video device does not have a DevicePath property then it is not good enough for them.

The “DevicePath” property is not a human-readable string, but is guaranteed to be unique for each video capture device on the system. You can use this property to distinguish between two or more instances of the same model of device.

The documentation is unfortunately confusing in this part and perhaps developers thought they were doing the right thing, nevertheless multiple discussions online suggest a different approach.

Unfortunately, DevicePath is not a mandatory property. And it does not exist in virtual devices, and you cannot use it to distinguish between them. And Skype started – supposedly – skipping devices without it. And this is why all virtual devices were left overboard.

Virtual devices are not that rare. It might not only be a gate into IP camera, instead it might be a device that splits exclusive use type video camera device between applications, or something that adds an overlay onto captured image. That is, the whole class of devices failed to work with Skype from there. Including, of course, IP Video Source which is a virtual DirectShow device with the backend network connection into an IP camera or video encoder.

Adding missing DevicePath is the key to fix the problem and give Skype what it thinks is a must. Let’s hope we have a fix from Skype soon and there is no need in working things around any longer, but if someone needs a quick solution – it also exists (apart from rewriting everything into kernel mode driver, and other hackery).

Since the properties an application reads from IPropertyBag interface (which is in turn obtained from IMoniker when enumerating devices) are [partially] backed by system registry, it is sufficient to add “DevicePath” value into specific key of the registry and make the fake property available for those devices that don’t have kernel path.

The registry key is located under HKLM, SOFTWARE\Classes\CLSID\{860BB310-5D01-11d0-BD3B-00A0C911CE86}\Instance (note it’s SOFTWARE\Classes\Wow6432Node\CLSID... in 64-bit OS for 32-bit app space), where every subkey corresponds to a registered device (find yours there). Note that CLSID above is actually CLSID_VideoInputDeviceCategory.

Adding new value there will create a fake property on the property bag and improve compatibility with such picky software as Skype. Note that the value will be destroyed with re-registration of the device filter, and will have to be created once again.

Skype improved support for video devices for richer user experience

A new release of Skype is out there, version

  • Metro look on the main (roster) window – good job!
  • Broken compatibility with software (virtual) video capture devices – good job!
  • Broken compatibility with some of hardware capture devices – good job!

While stripping virtual video devices in favor of true cameras, to avoid issues, might be intentional (though it would still be hard to justify anyway), the update also screwed the operation with a true hardware WDM driver backed PCI video capture board… Nice – with a dozen of cameras around the table I no longer have a single one compatible with Skype.

A little bit of hackery brings virtual DirectShow sources back to life, including those created by IP Video Source, however the issue is clearly Skype’s: I have no intention to work it around, let’s hope Skype guys are given some piece of mind to fix that soon.

Be aware and DO NOT UPGRADE if operation of virtual video source in Skype is is essential!

NOTE: There is an open issue on Skype’s tracker for the virtual camera compatibility.

DirectShow App Mess: Google Video Chat vs. Skype

Two widely popular applications, which use DirectShow API appeared to be locked in a combat: Google video chat is installing a plugin which registers artificial video capture sources “Google Camera Adapter 0” and “Google Camera Adapter 1”.

As the application does not announce any integration capabilities and is only using video for internal purposes for in-browser video, the approach with system-wide device registration is, well, questionable.

No need to mention, that devices are not operational: they are giving ERROR_DLL_INIT_FAILED (Error 0x8007045A) as soon as you try to instantiate a filter in a DirectShow video capture enabled application.

In-browser Google Video Chat itself does work and shows video from “real” DirectShow devices, including such artificial as created by IP Video Source tool. Google developers prefer still to take data off the device and as soon as possible leave DirectShow domain, as their graph looks like:

Video Capture Source -> Smart Tee Filter -> Sample Grabber Filter -> Null Renderer Filter

While Google plugin developers might need some interprocess synchronization, as the plugin runs in a child “plugin container” process (plugin-container.exe), introduction of virtual video capture devices is not necessary, but is a plain garbage for the operating system and DirectShow environment.

For some reason, Google developers decided to introduce a special thing: they mirror captured video left-to right when it comes to showing picture capture locally. Well, quite possibly it starts a new era in video conferencing: one will not see a direct copy of video sent remotely, but instead he will be given a mirrored thing.

The curious part is, however, the effect the broken devices introduce to another popular software – Skype.


IP Video Source: 64-bit version, resolution flexibility, Adobe FMLE

The IP Video Source update provides several improvements to the driver:

  • copy/paste feature to backup, restore, or synchronize installed devices between 32-bit and 64-bit versions
  • 64-bit version and .MSI
  • dynamic video resizing (via Video Resizer DSP)
  • Adobe FMLE compatibility

Updates in greater detail follow.

Device Copy/Paste Feature

The video device management window is providing Copy and Paste buttons, which let user transfer device information, including name and settings, through clipboard for various purposes:

  • save data in order to be able to restore devices later
  • restore devices from saved list, or re-create from a list saved on another machine
  • duplicate a device
  • synchronize devices between 32-bit and 64-bit versions

The device data is a text, one line per device, lines in comma-separated values (CSV) format.


DirectShow Video Source Filter for JPEG and M-JPEG IP Cameras

This implements a DirectShow driver/wrapper over a HTTP based JPEG/M-JPEG streamed video, widely available with IP cameras. Once installed, it provides a Start Menu shortcut to manage video capture devices, where a user can add/remove devices. The devices are automatically registered with DriectShow and are available to applications.

The compatibility list includes:

  • Windows SDK AmCap Sample (reference)
  • VideoLan VLC
  • Skype (see below)
  • Google Talk Video Chat
  • Luxriot (as rather an example as Luxriot has its own generic JPEG/M-JPEG device driver, however this still demonstrates compatibility and interoperability of applications)
  • GraphEdit, GraphStudio and similar tools