Quantcast
Channel: DirectShow – Fooling Around
Viewing all 74 articles
Browse latest View live

DirectShow VCam source code

$
0
0

Introducing another popular DirectShow project: Vivek’s source filter which emulates a video capture device. For a long time the code was hosted on P “The March Hare” W’s website, which was eventually taken down.

I placed the recovered project, binaries, README and upgrade to Visual Studio 2019 on GitHub: roman380/tmhare.mvps.org-vcam: Original Vivek’s popular sample project implementing virtual DirectShow video source filter (github.com)

The project itself is described in the repository, so I will not duplicate the text here.

See also: How to build and run Vivek’s Virtual Camera on Windows 10? on StackOverflow.


DirectShow filter built with Visual Studio 2019 Preview to run on Windows Server 2012

$
0
0

I pushed a few commits to my fork of DirectShow Win7 Samples (BaseClasses library specifically).

One of small problems I happened to deal with is that a filter built with current/recent toolset produces code incompatible with legacy operating systems, which are still widely present in the wild. This could be solved by using outdated versions of Visual Studio, outdated Windows SDK etc. This is however not really necessary because even Visual Studio 2019 Preview builds DirectShow code perfectly (including using v142 toolset), and you are generally not limited in using 30 year old codebase alone. I had a filter using Windows Implementation Libraries (WIL) helpers, C++17 code and C++/WinRT for COM object implementation, however a few rough places of BaseClasses resulted in filter binary incompatible with Windows Server 2012 runtime.

A bit of massaging of BaseClasses fixed the problem. I also enabled SDL checks (and this made me fix something COutputQueue implementation – not really a bug, but it could be more accurate, and got rid of strsafe.h in favor of safe CRT string functions.

While doing that, I noticed that ancient lstrcmpW API function is documented incorrectly on MSDN.

Beyond the Possible

$
0
0

I am replaying a pretty much regular MPEG TS recording taken from air, just with a MPEG TS rollover condition inside.

  1. Microsoft Media Foundation – ? FAIL
  2. Microsoft Movies & TV Application – ? FAIL (obviously because of #1 above, but let me double this down)
  3. Media Player Classic MPC-HC – ? FAIL
  4. VLC – ? FAIL
  5. DirectShow with one commercial MPEG demultiplexer filter – ? FAIL
  6. GStreamer 1.18 – ? FAIL

Oh, come on! Anyone? The recording is absolutely known to be one hundred percent valid!

Sounds like we have a new industry standard.

Microsoft Media Foundation drops sample times at MPEG TS rollover at 30.000s on audio leg, but not on video.

Windows 11 Virtual Video Camera

$
0
0

Just a quick hookup of my test Media Foundation media source into new Windows 11 MFCreateVirtualCamera API.

Software video source is presented by Windows 11 as a video capture device. Finally, there is a nice way to create virtual cameras, even though Windows 11 (Windows Build 22000) is a minimal requirement.

Application produced video stream is accepted by both Media Foundation and DirectShow APIs:

Media Foundation API based Windows Camera application showing virtual camera
DirectShow API based GraphStudioNext application showing virtual camera

The new API works throough earlier introduced Frame Server subsystem: the new API pulls video frames from provided Media Foundation media sources and distributes data among the connected applications, the same way things happen with regular driver backed video sources.

  1. Download MediaFoundationVirtualCamera.7z and extract the contents
  2. Run “regsvr32 MediaFoundationVirtualCameraMediaSource.dll” from elevated command line prompt
  3. Run MediaFoundationVirtualCamera.exe
  4. While MediaFoundationVirtualCamera.exe is running, a new camera is registered with the system and is available for the applications

Vivek’s VCam is finally to be phased out, but it will still take some time.

For your own good we enforced real-time protection…

$
0
0

Ostatnio spedzilem dosc duzo czasu na sprawdzaniu problemu z nieoczekiwanie slaba wydajnoscia w… Oh wait I am writing in English here. So, recently I spent rather a lot of time checking a problem with unexpectedly poor performance in a legacy DirectShow real-time video encoding pipeline based on NVIDIA GPU hardware encoding.

There was also a pre-history in this story. A colleague engineer in a contracted organization complained on a similar symptom and it took me not too much time to see that some third party antivirus is showing unexpected load numbers along with video recording activity. It appeared that it was not so easy to disable the antivirus because it was managed by his company on the corporate development system, so I just left him with suggestion to find ways to kill the offender.

However then later a similar thing happened on my own system as well. Even though it was a good reason to fine tune other aspects of the pipeline it came to my attention that freezing parts are happening in disk access to produced file in MP4 Multiplexer filter here.

The whole situation is ridiculous. Geraint designed these filter back in 2009 and then those would work nicely even ten years earlier if they existed earlier. Now with all the performance progress in hardware the same code exhibits extremely weird performance behavior because… of this thing:

Real-time protection of Windows defender interferes with recording so bad that it holds the entire upstream pipeline and forces frame drops in already a few second after start. This thing is also known to automatically re-enable itself if you turn it off so ironically even when I turn the switch on the image above off, after just a few minutes of rock solid operation it re-enabled the protection and the recording defect immediately returned back (okay, maybe it popped a notification about disabled protection and I accidentally clicked).

What’s wrong with this thing at all? Is it really that important to routinely check MP4 files being written with an impact so high that you can no longer use the hardware to do that original most important operation.

Knowing this, of course, it is important to restrain the scoundrel:

Windows MP4 shell property handler sometimes destroys your media data

$
0
0

Some version of Microsoft Windows OS have rather dangerous subsystem known as MP4 property sheet handler (“MF MPEG-4 Property Handler” to be exact). Programmatically, you would use API like SHGetPropertyStoreFromParsingName and use IPropertyStore from there to read (reading is OK) and update/write certain MP4 file properties like, for example, a comment or som other metadata.

The same API is used from property sheet UI if you decide to update metadata:

It looks like the implementation is damaging some media files. An attempt to update a file breaks it and overwrites vital part of MPEG-4 Part 14 file structure with the new metadata, rendering the file unplayable.

Long story short – prefer to not use the API at all to update the metadata, or make a backup copy.

In DirectShow MP4 multiplexer created back in time by Geraint Davies, in its fork I am still using somewhere, I created IMuxFilter::SetComment method exactly for this: to be able to set comment before the file is finalized, by injecting a respective box with metadata as a part of finalization, so that stock faulty Windows API is not used and the produced file is reliably safe.

VCam: A Journey from Usenet to GitHub

$
0
0
Throughout many years of hashtag#DirectShow development, one project stood out with unwavering popularity: the Windows Virtual Camera sample ????. Originally authored by Vivek in 2005 or even earlier, it was shared on the "microsoft. public. win32. programmer. directx. video" Usenet conference. This project gained prominence because it addressed a problem that had no existing solution within the Windows SDK, and Microsoft had not expressed any intention to rectify it. The source code for this virtual camera project was once hosted by Philip “The March Hare” on his personal website. However, given the passage of time, even that website does not longer exist. We decided to breathe new life into this project, affectionately known as “VCam”, and made it available on GitHub: https://lnkd.in/dGUH9v79. Despite our confidence that the project and its approach are no longer current, there remains significant interest in this source code, with thousands of mentions across the internet. At the GitHub repository, you’ll find not only the source code and build instructions but also pre-built binaries, demonstration, and references to the original contributors.

From Webcams to 24-Hour Recordings: A Decade of Medical Video Evolution

$
0
0
For over a decade, we have been supporting a customer’s product in the field of medical video. Our journey began with their attempts of previous years to record from webcams — an endeavor that was initially partially successful. We put our expertise to bring use of this technology to stable level, and since then we have successfully captured countless hours of footage, using both standard cameras and professional-grade hardware. One particularly intriguing aspect of this evolution stands out. In the early days, our recordings were typically brief, lasting only a few minutes. Moreover, the original implementation imposed a strict 10-minute limit within the application. Why? Well, at that time, there was no robust video encoder available that could handle the application’s requirements — hardware constraints, desired quality, and real-time performance. Consequently, the signal was often recorded in an uncompressed format. The time limit served a purpose: managing disk usage and preventing accidental overflows. As the years passed, we transitioned to using proper video encoders for live content. We swiftly expanded our supported resolution to Full HD at 60 frames per second. Hardware-assisted encoding became the norm, and the duration of encoded sessions gradually increased. What started as 10-minute recordings soon extended to 15 minutes, half an hour, and eventually full procedures lasting up to 4 hours. Then came the pivotal question: “Can we record continuously for 24 hours?” The answer was a resounding yes. Despite its long history, the ongoing support, stable performance, and improvements over time have been well worth the very moderate effort, and yes, it's still a hashtag#DirectShow app. With a little hashtag#MediaFoundation insertion. Simultaneously, the need for data safety during recording intensified. Fortunately, we devised a solution, which we’ll delve into further in an upcoming piece.

Custom Filters to the Rescue: Diagnosing and Solving Media Stream Woes

$
0
0
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.

Legacy Filters, Modern Solutions: MP4 Support in DirectShow

$
0
0
Microsoft #DirectShow API was introduced long before the widespread adoption of MPEG-4. As MPEG-4 codecs and container formats became standard, DirectShow was, by Microsoft’s own admission, nearing the end of its life. That’s how this once-popular media framework for Windows found itself without support for MP4 files. Fortunately, there was a handy solution: freely available filters https://gdcl.co.uk/mpeg4/ developed by Geraint Davies. Originally published in 2006, these filters gained popularity over time. Since Geraint had other commitments after the last update, we took the liberty of placing a copy of his work on GitHub https://lnkd.in/dPsZEfpE somewhere around 2015. Despite the state of DirectShow, these filters still play a role in DirectShow applications. We’ve even made a few updates ourselves — a little bit of everything: a unit test project, some modern C++ and #COM code based on Microsoft WIL https://lnkd.in/de5nxif, a COM type library with an integration interface, and various features. One particularly valuable addition is the ability to recover broken recordings. You see, sometimes applications crash — whether due to external factors or just plain bad luck. And sometimes the cost of “re-doing things right” is too high. Oh, and the cost of data loss is high too! In such cases, we can salvage the broken recording from the crashed application and recover its content. It’s like a digital rescue mission. And in some instances, it’s even automated — like in our partner’s medical software https://lnkd.in/dCrJJRjy, where multi-hour recordings are the norm these days.

LDS Temples and Technology: The DirectShow Journey

$
0
0
A while back, we were working on a media subsystem for The Church of Jesus Christ of Latter-day Saints. They needed software-controlled multimedia playback with specific requirements for their temples worldwide. Now, the attached image isn’t an exact representation of our work, but it captures the essence: LDS and technology go hand in hand. Back in the day, we used #DirectShow as our multimedia framework, and boy, did we face some interesting challenges. One that sticks out in memory is related to audio delivery. Picture this: we had a multi-channel audio output card from AudioScience, Inc., and our task was to schedule audio delivery in perfect sync across multiple physical audio connectors. But wait, there’s more! We also had to toggle outputs on and off while others were already belting out sound. And when we turned on a fresh audio stream, it had to seamlessly match the signal already in play. Oh, and don’t forget — the video part of this signal was streaming nonstop and couldn’t be interrupted. Now, let me tell you, this wasn’t a walk in the park. The multimedia framework was designed back in the '90s, with the quaint notion that once you set up your playback topology, you couldn’t tweak anything while the show was running. But guess what? Our software spread its wings and flew to over a hundred locations worldwide. Many moons have passed, but who knows — it might still be chugging along out there.

Legacy Code and Overengineering: The MJPEG Decoder Saga

$
0
0
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. ????????????

Enhancing Video Capture: Bridging the Gap Between Hardware and Software

A codec for The Imaging Source cameras and [discontinued] IC Capture 2.5 software

$
0
0

Truly advanced industrial cameras by The Imaging Source are provided with image acquisition software, End User Software is a free IC Capture application, which ended up with a few problems to resolve.

First of all, “the older” application is a kind of discontinued. A Windows application version 2.5 was on the website as recently as a few weeks ago, but the announcement of release of IC Capture version 4 removed the older application completely.

Another The Imaging Source IC Measure application is renamed into the name of its predecessor IC Capture with a version increment… Now IC Capture 2.5 is almost gone. OK, almost – there are still some traces: https://www-st.theimagingsource.com/en-us/support/download/iccapture-2.5.1557.4007/

The question is this: the cameras are good enough to capture video with 12-bit color depth, e.g. 33U series. Is it possible to record the original video stream in certain popular video format for use in other applications?

Under “AVI Files and Codecs Support” the new application does not seem to offer AVI support anymore, and offers recording to MP4 files with H.264 or H.265 encoding. You could give it a try and record 4000×3000@20 with 12-bit wide dynamic range into one of these formats, hopefully without frame dropping.

The previous IC Capture 2.5 application in Windows had better integration options and did offer AVI recording with interoperability with third party software. It was still quite a challenge to find a suitable codec, yet it is possible now with a specialized GoPro CineForm codec designed to work with IC Capture 2.5:

  • the codec directly accepts The Imaging Source driver’s RGB64 format (original 12-bit color depth from camera without reduction to 8 bits) with WDR (wide dynamic range) option tuned on video
  • the codec retains 12-bit precision in the produced output (even though the output bitrate is pretty high!)
  • the codec does its best to not lose input frames, and uses the most of CPU with parallel processing, in order to save as much as possible from the original data acquisition; to give some estimate, an Intel i7 CPU of 12th generation or newer can handle the compression of WDR 4000×3000@20 video stream and enable its offline post-processing where all the data is securely recorded

Essentially, the codec gives fine tuning to discontinued IC Capture 2.5 extending its recording abilities so that they exceed those of current IC Capture 4 software in Windows… The produced files are nicely accepted into software like DaVinci Resolve, or good old Media Player Classic Home Cinema.

The download for the pre-release of the codec is below. Requirements:

  • Windows 10/11: minimal version is not identified, the software should be well compatible with a few last versions of Windows
  • 64-bit Windows and 64-bit of IC Capture 2.5 (x64): there is no 32-bit build as making no much sense; IC Capture 2.5 installs both Win32 and x64 variants of the application, please use x64 and there in the codec choice UI you will be able to see additional codec option
  • unregistered codec will overlay “DEMO CODEC” text, the overlay goes away with addition of valid license token for the codec (to be described later, or please get in touch for a quote)
  • the codec is designed to work only with IC Capture 2.5 x64 software
Viewing all 74 articles
Browse latest View live