On 9/1/20 9:13 AM, Nikolay Sivov wrote:
On 9/1/20 4:54 PM, Derek Lesho wrote:
On 9/1/20 2:29 AM, Nikolay Sivov wrote:
On 8/28/20 11:48 PM, Derek Lesho wrote:
@@ -6030,7 +6030,7 @@ static HRESULT resolver_get_bytestream_handler(IMFByteStream *stream, const WCHA for (i = 0, hr = E_FAIL; i < ARRAY_SIZE(hkey_roots); ++i) { - const WCHAR *namesW[2] = { mimeW, url_ext }; + const WCHAR *namesW[3] = { mimeW, url_ext, L"wine/all" }; HKEY hkey, hkey_handler; if (RegOpenKeyA(hkey_roots[i], streamhandlerspath, &hkey))
Is it a way to avoid registering specific types/extensions? Could you explain why this is better than regular registration.
Yes, this is a way to avoid registering specific types. This was zebediah's suggestion, and his reasoning was:
Even if some application creates CLSID_MPEG4ByteStreamHandler manually, and we need to hook up this decoder thereto, I think it makes more sense for the original patch to create it under a generic name (maybe CLSID_GStreamerByteStreamHandler) and custom CLSID. Then, in another patch, we can hook up CLSID_MPEG4ByteStreamHandler to the same object.
Media Foundation doesn't make it as easy as DirectShow to plug in a generic catch-all handler, i.e. we can't just set some registry keys and have done, but regardless I think it's something we want to do, even if that means making the modification in mfreadwrite instead.
I don't know, I don't see a problem in registering whole list of mime types/extensions, which then could be tweaked. Is it the size of this list that makes this undesirable? In practice it will grow to maybe 20 entries I think.
I agree with you, although it would probably grow to be longer than that, as I think Zebediah wants us to support media types not supported on windows:
The point of doing this is mainly for generic media players (which, as bug reports will tell you, are used quite frequently with Wine, for one reason or another). It also has the benefit of obviating most of the registry entries (like the ones below) and CLSID mappings that we'd otherwise have to add.
P.S. mfreadwrite was mentioned, should that be mfplat.dll or does mfreadwrite need special handling for some reason?
I think Zebediah was just mistaken here.