[PATCH v4 2/5] winegstreamer: Add stub bytestream handler.

[Nikolay Sivov]

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