On 9/2/20 5:02 AM, Nikolay Sivov wrote:
On 9/1/20 5:58 PM, Zebediah Figura wrote:
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.
The suggestion was based on the quartz model, which I think in hindsight works quite well.
Granted, we could certainly try to anticipate every host format and add registry entries for those, or even pick a few common ones and hang the rest, but I don't see why we should, when we can just as easily throw everything into one bucket. It makes our entire job that much easier.
We can also just completely ignore host integration, but I really think that's not a good idea.
Can we hardcode CLSID as a fallback equivalent of wine/all? Or is it not flexible enough.
The thing that potentially bothers me about that is that we might want to leave room for another backend besides GStreamer (in particular, whatever the replacement for QT is.) But it'd also be easy enough to code in two fallback CLSIDs instead of one.
P.S. mfreadwrite was mentioned, should that be mfplat.dll or does mfreadwrite need special handling for some reason?
mfreadwrite has some handling for MIME type detection; I only skimmed the code so I don't know if it's what's relevant here.
I don't think it's relevant, it will try to through format magics, but resolver is free to ignore that hint. That part does not have to change.