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

[Zebediah Figura]

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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200901/0a3eca21/attachment.sig>