Build Incrementing for Visual Studio C++ Projects

Over long time I used an automatic build incrementer add-in for Visual Studio and C++ projects, which proved to be helpful. Having increments in file information, the binaries were easy to identify. It was easy to find a matching symbol information etc. Long story short, a tool like this has been a must.

The add-in has problems or downsides though. It kept patching the .RC source and touched it when no other changes existed in the build, touching source code forced rebuilds on its own and reloaded resource-related files opened in Visual Studio editors. I was annoying even though more or less acceptable.

Visual Studio 2015 Community Edition does not support add-ins because of 2015 or because it’s Community Edition. Either way it was time to update the incrementer ot make things nicer overall.

This time I preferred to change things a bit. No longer source code patching: the incrementer can be attached as a post-build event and patch VERSIONINFO resource on the built binary. This requires that current build number is kept somewhere but not in the .RC text, so I am using an additional .INI file. The good thing is that this file can still be included in version control system and the version history can be tracked relatively easily. No longer source code modification which makes code base dirty and forces another rebuild.

Command line syntax:

C:\>IncrementBuild-Win32
Syntax: IncrementBuild-Win32.exe argument [argument...]

Arguments:
  help - displays syntax
  configuration <path> - path to .INI file holding configuration information (mandatory)
  binary <path> - path to binary to be patched with file version update (mandatory)
  string <name> <value> - add, update or remove specific version information string (optional; multiple arguments possible)
  dump - print version information data block dump before and after update

Additional feature is that incrementer can attach additional version strings (see example below – it adds build configuration as a version information string).

Setting up is easy. First, the project should have a version information resource, so that the binary has data to patch in first place.

Then, there should be an .INI file which tracks version numbers. The binary will be build with .RC numbers and then incrementer will apply the least significant number from the .INI file incrementing it along the way.

[General]

[VersionInformation]
;Language=133 ;MAKELANGID(LANG_ENGLISH, SUBLANG_ENGLISH_US)
;Version String Format=%d.%d.%d.%d
Current Build Number=4

Next thing, project post-build event needs a command for patching:

Post-Build Event in VS for C++ Project

"$(AlaxInfo_Common)\..\Utilities\IncrementBuild\_Bin\IncrementBuild-$(PlatformName).exe" configuration "$(ProjectDir)Module.ini" binary "$(TargetPath)" string "ConfigurationName" "$(ConfigurationName)" 

The command takes Module.ini from the projects directory for configuration file, patches build output and also attaches build configuration as an additional version information string.

Build output looks like this:

—— Rebuild All started: Project: EnumerateTransforms, Configuration: Release Win32 ——
stdafx.cpp
Application.cpp
Generating code
Finished generating code
EnumerateTransforms.vcxproj -> D:\Projects…_Bin\Win32\Release\EnumerateTransforms.exe
EnumerateTransforms.vcxproj -> D:\Projects…_Bin\Win32\Release\EnumerateTransforms.pdb (Full PDB)
Configuration Path: D:\Projects…\Module.ini
Binary Path: D:\Projects…_Bin\Win32\Release\EnumerateTransforms.exe
Incrementing build number, product version 1.0.0.1, file version 1.0.0.4
Applying version information string, name “ConfigurationName”, value “Release”

Presumably, it is not necessary to use same bitness tool for a binary, since version information patching API should be able to patch resources of mismatching build, but I normally use a matching tool anyway, why not?

Download links

KB3176938’s Frame Server update visually

  1. M-JPEG and H.264 media types are available again (good)
  2. Nevertheless connected, H.264 video is not processed correctly; new bug or old one? Not clear. Even though it sort of works, in DirectShow it looks broken in another new way (this and not just this), perhaps a collateral damage and maybe never ever fixed…
  3. There is no camera sharing between the applications even though it was the justification for the changes in first place. For now Frame Server is just useless overhead, which adds bad stuff, is polished a bit to do not so much harm, and maybe turns to be good some time later.
    • for the record, the camera works in Skype when it is not consumed elsewhere concurrently

BTW the hack that bypasses FrameServer survived the update and remains in good standing.

DirectShowCaptureCapabilities and MediaFoundationCaptureCapabilities: API version of EnableFrameServerMode state

Both tools now include exact version of the API and also include an export or registry key related to frame server.

Capture Capabilities: API Version and State

mfcore.dll version of 10.0.14393.105 corresponds to Cumulative Update for Windows 10 Version 1607: August 31, 2016 also known as KB3176938 with DirectShow and Media Foundation improvement for Windows 10 Anniversary Update that restores availability of compressed media types.

See:

Enumeration of DirectShow Capture Capabilities (Video and Audio)

Media Foundation Video/Audio Capture Capabilities

Number of streams served by IMFSourceReader interface

It looks confusing that IMFSourceReader interface does not offer a dedicated method to find out the number of streams behind it. There is a IMFMediaSource instance behind the reader, and its streams are available through IMFMediaSource::CreatePresentationDescriptor method and IMFPresentationDescriptor::GetStreamDescriptorCount method call.

I am under impression that source reader’s method just has to be there even though I am not seeing it looking at the list of methods. Okay, there are other methods, namely IMFSourceReader::GetStreamSelection method, which takes either ordinal stream index or an alias as the first argument, then returns MF_E_INVALIDSTREAMNUMBER if you run out of streams. However the problem is that this is associated with an internal exception, and I consider exceptions as exceptional conditions the code should not normally hit. I would expect to have a legal exception-free way to find out the number of streams. I am using debugger that breaks on exception or at least pollutes output log for no reason, I use other tools that intercept and log exceptions as something that needs attention – getting number of streams is nowhere near there.

Internal MF_E_INVALIDSTREAMNUMBER Exception

Even though it is not a real drawback of the API since it is still possible to get the data and the API acts as documented, I still think someone overlooked this and API like this should have have a normal method or argument to request number of streams explicitly. Or I am just not seeing it even though I am trying thoroughly.

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.

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

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

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

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

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

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

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

Try opening up

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

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

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

Also:

Untitled

Video Capture in Windows 10 Anniversary Update Again: MJPG is still here but hidden by new Frame Server thing

The problem with video capture issues looks more or less clear.

As explained by Mike M here, the breaking changes in Windows 10 Anniversary Update are caused by intentional redesign of the platform that enable shared access to video capture devices.

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

Originally video capture application were highly performance sensitive due to insufficient horsepower of computers overall, and sharing of video capture sessions between the applications was not on agenda. Then Microsoft hibernated for over a decade and did not do updates to the platform to follow software and hardware trends. Those needing camera in 2+ applications had to use third party camera splitting software. Time has come to include video sharing to the platform and… that washed away support for compressed video formats. If camera is shared, who is going to decode video into presentable format? Guys at Microsoft decided that they will, that is it’s now “decode then share between applications” scenario.

When an application runs video capture session, Windows 10 Anniversary Update now runs the actual session in a service process. A new Windows Camera Frame Server service is responsible to acquire video, decode and distribute it.

Windows Camera Frame Server Service

Applications access FrameServer service with the help of FSClient.dll connecting to shared service which runs actual session.

I am not sure how sharing works exactly, but I was unable to start two TopoEdit instances doing video capture from the same camera. Presumably, default behavior is still imitating exclusive use of hardware and possibly priority clients (like mentioned Windows Hello) have new ways to take over video capture device on demand, or we will see new functionality with respective SDK/documentation update.

Applications now – as it is assumed from the description – get the only option to communicate to FrameServer service and not the video capture source directly. On that way, formats like MJPG and H264 are lost.

As recent comments indicate this to be a well planned and scheduled scenario, it looks unlikely that things are going to change. It was decided that there is no exclusive mode video capture, just shared. Developers are to wait for possibly changed attitude and something similar to WASAPI exclusive low-latency mode for those specific application which need it.

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.

A small relief is that they restructured the platform and not dropped the support for MJPG and H264 in first place. Okay, there is no formal access to compressed streams using standard API but a stab into doing it undocumented way shows that all the gear remains in place.

A small proof-of-concept DirectShow video source filter that talks to Logitech C930e camera bypassing newly introduced stuff is confirming that streams like 1920×1080@30 MJPG are still supported by the camera and are operational. That is, it is still possible to stream MJPG and H264 from USB web cameras, specifically at modes exceeding standard USB 2.0 bandwidth limit for raw video, and eliminating software compression:

DirectShowLogitechC930eVideoSource

Logitech C930e Live

This of course takes again exclusively control over the camera and prevents from sharing video feed as the update intended. However, the video itself is where is was.

Logitech C930 Running 1920x1080@30 MJPG

There is no public source and/or details on this filter because it’s sensitive to undocumented behavior of Media Foundation platform. Just as a demo, the DLLs are there: Win32, x64. (limited to Logitech Webcam C930e’s highest MJPG mode but basically the method could work for any MJPG camera, and C930e’s H264 too).

That is, if your application is broken by Windows 10 Anniversary Update because you simply assumed availability of specific modes, then there is a chance that update of the application to make it compatible to new platform design with FrameServer service could fix it. If you intentionally consumed compressed video for quality, rate and performance reasons then you’re in trouble and there is no really a solution from Microsoft is expected soon. Perhaps the best would be to not upgrade to Anniversary Update.