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

[Derek Lesho]

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