// Oprogramowanie Roman Ryltsov
Moving on with Widows Camera experiments. This time it is a Windows 11 Virtual Camera, a true one like this and this, and not this which should be totally archived despite people still keep on trying. So what we got this time? The application derived from old CaptureEngineVideoCapture sample still features IMFCaptureEngine API. However, it also intallls temporary…
In the years 2009 to 2011, engineers from the Microsoft Media Foundation Team shared a series of blog posts containing sample code related to the hashtag#MediaFoundation API — a successor to the venerable hashtag#DirectShow.
At that time, there was a scarcity of sample source code specifically addressing this topic. Unfortunately, the passage of time and various transformations of blog sites and the Microsoft website took their toll. The original blog posts suffered, and although they were eventually recovered and reinstated as part of the team blog archive https://lnkd.in/drKBW5tW, the source code associated with those posts vanished entirely. The links now led to the dreaded HTTP 404 “Not Found” error.
However, our quest for historical preservation and the benefit of those who remain curious led us to a solution. We unearthed the missing source code and deposited it into a GitHub repository https://lnkd.in/dXRi9PZF. There, it resides — a testament to the past and a resource for those who still harbor interest in the intricacies of the Windows Media Foundation API.
Feel free to explore the repository and delve into the code. After all, sometimes even lost fragments of the digital realm can find their way back home. ????????
So, hashtag#DirectShow virtual cameras — those elusive creatures that always turn heads. We’ve chatted about them before on LinkedIn (check out our post here https://lnkd.in/dYte5SQ5). But let’s rewind to 2011 when we decided to play mad scientist. Our mission? Whip up a batch of DirectShow filters that could snag JPEG and M-JPEG video streams from network sources (think IP cameras) and seamlessly slot them into DirectShow applications.
But wait, there’s more! We cranked it up a notch. Picture this: a secret lab, flickering monitors, and a dash of overengineering. Our filters cozied up to the stock Microsoft JPEG decoder — the one that’s been less than stellar since forever. And guess what? We wrapped it all in a nostalgic bow — a wrapper around the ancient VCM JPEG Decoder from 1992 https://lnkd.in/dYRUi84x. Yep, that’s right — the same decoder that predates most of us.
Why, you ask? Because that’s how Microsoft Windows rolls. It clings to legacy features like your favorite worn-out hoodie. The “MJPEG Decompressor” (sounds fancy, right?) is still documented https://lnkd.in/dBZzBbKK as a relic . But honestly, no one should touch it with a ten-foot pole. Not now, not 13 years ago — never.
And here’s the twist: Our Alax.Info IP Video Source DirectShow extension https://lnkd.in/diB_3vBf, born from this wild experiment, lives on. It’s like that quirky friend who insists on wearing mismatched socks. People still use it, still recommend it. Maybe it’s the retro charm or the sheer audacity. Who knows?
So next time you’re streaming video from a network source, tip your hat to those unsung heroes — the DirectShow filters that made it all happen. And raise a banana (yes, a banana) to the MJPEG Decompressor. It’s been around longer than your grandma’s favorite recipe.
There you have it — a tale of tech, tenacity, and a touch of madness. ????????????
In a recent customer project, we encountered a longstanding problem related to a broadcasted media stream captured by software.
Our customer application, built on the hashtag#DirectShow framework, was responsible for capturing the media stream. The application needed to operate 24/7 and maintain stability during continuous live media broadcasting.
Unfortunately, sporadic crashes occurred due to a third-party DirectShow filter within the topology. This filter triggered memory access violations and crashed the entire application. The vendor of this problematic component was unavailable for maintenance. Given the low incident frequency, the customer was concerned about possible regressions in the case of any update of this part of the application.
The issue manifested only in the production signal, complicating troubleshooting, and the customer’s data center required remote access via VPN and several remote desktops.
To diagnose and solve the problem effectively, we introduced a lightweight DirectShow filter. This custom filter transparently captured a dump of the recently captured MPEG-TS signal, mirroring the data flow to the faulty component. In the production environment, this solution allowed us to analyze the content in sufficient detail to reproduce the problem outside the production setup.
Eventually, we replaced the problematic third-party DirectShow filter with an in-house development that handled that particular processing step reliably and maintainably.
In summary, our custom DirectShow filter provided crucial insights, enabling us to address the issue and enhance stability in the customer’s live media broadcasting application.
Over 20+ years there have been a steady flow of questions “how to build these projects”. Back in time the problem was more about having exactly matching settings in the application/library projects and mandatory dependent static library. At some point Microsoft abandoned the samples, then removed from the SDK completely. Luckily, some point the samples…
SetFileTime is simple and does not deserve a blog post: you have a file handle, you have date/time, you set it. C++/WinRT and UWP make the journey much more exciting. There is StorageItemContentProperties Class which provides access to the content-related properties of an item (like a file or folder). This includes file times which are…
GetFileVersionInfoSizeW function in Requirements section lists: Minimum supported client Windows Vista [desktop apps only] Minimum supported server Windows Server 2008 [desktop apps only] Target Platform Windows Header winver.h (include Windows.h) Library Version.lib DLL Api-ms-win-core-version-l1-1-0.dll and this is inaccurate. The actual requirement DLL is api-ms-win-core-version-l1-1-1.dll instead. However, what does it mean exactly? Windows API sets: API Sets rely…