[PATCH v4 2/5] winegstreamer: Add stub bytestream handler.
Derek Lesho
dlesho at codeweavers.com
Tue Sep 1 08:54:04 CDT 2020
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.
More information about the wine-devel
mailing list