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

[Zebediah Figura]

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


-------------- 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/20200902/b0acc030/attachment.sig>