Is there a way to associate an entire class of files with an application on Windows?

Question

I have a vanilla Windows 10 installation -- there aren't any third party video players of any kind, there is only Windows Media Player and the new Movies app. I have verified to be unable to play back, say, WebM (video) files.

However, I do have .webm Registry key under the HKEY_LOCAL_MACHINE\Software\Classes key, with ContentType value of "video/webm" and PerceivedType value of "video". It's a similar situation with the other novel extensions there too, like .webp and .mkv, and others. I don't know why it's there and what created these keys.

That makes me at least believe that Windows should be capable to classify different video containers into a some sort of "video" class of files, given how it at least theoretically knows these are "video/" major MIME type each and the fact that they share the same "perceived type".

Is there a way then for me to associate all such video files with my application, without explicitly creating one association for every known video format? I want to benefit, if possible, from the kind of classification I think Windows might be able to do.

Thing is, my application doesn't explicitly support or reject individual video container formats like WebM (.webm extension) or MPEG-4 (.mp4 extension), or any other -- it passes the file for playback to DirectShow, which in turn by design relies on installed filters to try and play back media files. Since these filters can be installed separately from my application, I don't see how I can reliably maintain a by-file-type association. I'd rather delegate this to whatever Windows subsystem created the .webm key under HKEY_LOCAL_MACHINE\Software\Classes key in the first place. Perhaps Microsoft updates these as part of Windows Update?

If I could associate whatever Windows considers video files, however it does so, with my application, per entire class that is video files, at least I could allow the user to attempt to play back whatever they throw at my application, by virtue of it being available in the context menu if Windows thinks it's a media file. Certainly, this is no worse than the old situation where Windows Media Player typically registers itself with a number of media container formats and still is unable to play every file of every supported format because of missing codecs. At least I won't have to update my application every time a new video format comes out.

Answer 1

I do not think it is possible to make it the way you want and there are objective reasons for this.

First, shell association process starts from extension to application mapping and this is a well defined process without classes of files built on top of set of extensions.

Second, there is no such thing as "video files" in first place. .mp4 and .webm are not exactly video files, because, in particular, they can hold just audio tracks and so be audio files. Media APIs start reading the files with examining container format details, identification of tracks and announcing track/stream availability for peer APIs such as codecs. That is, "video files" is not a very strict definition in first place.

Third, media APIs such as DirectShow and Media Foundation do not use shell association when playback is in question. Shell association and HKEY_CLASSES_ROOT is only in use when it comes to choosing handler application. APIs define their own method to build a pipeline for a given file, and their have their own separate collection of extension defined handlers. Then these APIs are capable to identify format of files with "wrong" extension by looking into payload data itself: if you rename .wav to .avi, the file would remain playable even though formats are different.

That is, if you want to identify a video file in your application without thinking too much about file format, why not just use one of the mentioned media APIs and open the file. If you can see through the API that the file exposes a video track then it is a video file. Even though I don't think I grasped the detail why you need to filter out video files exactly, I would probably recommend this approach.

You could probably also use shell property handlers - PSLookupPropertyHandlerCLSID and friends - to check if a file is a media file. Video file would report one of video related properties such as PKEY_Video_FrameWidth.

Then if you just need an approximate guess whether the file is a video file, you could possibly check extension against HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\KindMap list.

Another quick method to check if it might be a video file is to check extension against API specific association list such as this HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media Foundation\ByteStreamHandlers. It is similar to using Media Foundation API I mentioned above but without actually using it. This registry key is where extensions are associated with API specific primitives, as opposed to shell extension associations.