T
thegreatcircleofinterdependence
I think this is a question to either people who took part in developing at least the Shell APIs in Windows or those documenting these APIs, as published at Windows Shell - Win32 apps. I have read a large number of articles under the "Windows Shell" topic, but am left with scattered and vague understanding on how Windows file associations work.
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.
Continue reading...
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.
Continue reading...