https://bugs.winehq.org/show_bug.cgi?id=52769
Bug ID: 52769 Summary: Missing MFSchemeHandler for common url schemes Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mfplat Assignee: wine-bugs@winehq.org Reporter: yshuiv7@gmail.com Distribution: ---
Right now there is only a scheme handler for "file:". Some games use Media Foundation to play videos from URLs, VRChat is one of the notable examples. Missing common scheme handler for schemes such as "http:" and "https:" means videos can't be played in those games.
https://bugs.winehq.org/show_bug.cgi?id=52769
yshuiv7@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yshuiv7@gmail.com
--- Comment #1 from yshuiv7@gmail.com --- Created attachment 72139 --> https://bugs.winehq.org/attachment.cgi?id=72139 0001-mfplat-add-generic-url-scheme-handler.patch
I implemented a generic scheme handler using GStreamer's uridecodebin. This should support all the url schemes supported by installed GStreamer plugins.
I haven't tested this in real use cases (e.g. end-to-end playing a video from a http source); but rudimentary test cases, like creating a source reader then reading samples from it, worked without a hitch.
https://bugs.winehq.org/show_bug.cgi?id=52769
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Missing MFSchemeHandler for |VRChat fails to play videos |common url schemes |(needs Media Foundation | |HTTP scheme handler) Version|unspecified |7.5
https://bugs.winehq.org/show_bug.cgi?id=52769
--- Comment #2 from Nikolay Sivov bunglehead@gmail.com --- I don't think we should rely on gstreamer for this. We should have win32 based implementations for network bytestreams, and make that work with gstreamer source the same way file streams are working now.
https://bugs.winehq.org/show_bug.cgi?id=52769
--- Comment #3 from Nikolay Sivov bunglehead@gmail.com --- Existing report for this is bug 49392.
https://bugs.winehq.org/show_bug.cgi?id=52769
--- Comment #4 from yshuiv7@gmail.com --- (In reply to Nikolay Sivov from comment #2)
I don't think we should rely on gstreamer for this. We should have win32 based implementations for network bytestreams, and make that work with gstreamer source the same way file streams are working now.
This is my original plan for implementing http and https as well. But then I realized rtsp cannot be a bytestream, as it can have multiple separate audio/video streams. It has to be exposed as a media source. Using gstreamer's uridecodebin helps us easily cover as much protocols as possible.
Implementing rtsp from scratch would be a much larger undertaking, personally I think it would be good to have something working first, for the users that need this. But I can understand if the devs here object.
https://bugs.winehq.org/show_bug.cgi?id=52769
--- Comment #5 from Nikolay Sivov bunglehead@gmail.com --- (In reply to yshuiv7 from comment #4)
(In reply to Nikolay Sivov from comment #2)
I don't think we should rely on gstreamer for this. We should have win32 based implementations for network bytestreams, and make that work with gstreamer source the same way file streams are working now.
This is my original plan for implementing http and https as well. But then I realized rtsp cannot be a bytestream, as it can have multiple separate audio/video streams. It has to be exposed as a media source. Using gstreamer's uridecodebin helps us easily cover as much protocols as possible.
It's normally a property of the container to provide multiple streams, not the protocol. Same as a disk file having one video and multiple audio streams, still exposed as a single bytestream. Is that somehow different for rtsp? Do you mean it's impossible to create a bytestream object for rtsp url at all?
Implementing rtsp from scratch would be a much larger undertaking, personally I think it would be good to have something working first, for the users that need this. But I can understand if the devs here object.
Starting with http/https is fine.
https://bugs.winehq.org/show_bug.cgi?id=52769
--- Comment #6 from yshuiv7@gmail.com --- (In reply to Nikolay Sivov from comment #5)
It's normally a property of the container to provide multiple streams, not the protocol. Same as a disk file having one video and multiple audio streams, still exposed as a single bytestream. Is that somehow different for rtsp? Do you mean it's impossible to create a bytestream object for rtsp url at all?
Yes. The server tells you what streams there are, and the client would (usually) establish separate connections for each stream.
https://datatracker.ietf.org/doc/html/rfc2326#page-5:
The Real-Time Streaming Protocol (RTSP) establishes and controls either a single or several time-synchronized streams of continuous media such as audio and video.
...
Starting with http/https is fine.
Is it worth it if we ended up using gstreamer for rtsp anyway?
https://bugs.winehq.org/show_bug.cgi?id=52769
--- Comment #7 from Nikolay Sivov bunglehead@gmail.com --- (In reply to yshuiv7 from comment #6)
(In reply to Nikolay Sivov from comment #5)
It's normally a property of the container to provide multiple streams, not the protocol. Same as a disk file having one video and multiple audio streams, still exposed as a single bytestream. Is that somehow different for rtsp? Do you mean it's impossible to create a bytestream object for rtsp url at all?
Yes. The server tells you what streams there are, and the client would (usually) establish separate connections for each stream.
https://datatracker.ietf.org/doc/html/rfc2326#page-5:
The Real-Time Streaming Protocol (RTSP) establishes and controls either a single or several time-synchronized streams of continuous media such as audio and video.
The question is how it's reflected in media foundation API, e.g. what data will be returned from bytestream created with CreateObjectFromURL("rtsp://..."), and if it's possible for application to configure which streams are requested.
Did you find an application that depends on this protocol handler? Except for ones that accept any url, including rtsp.
...
Starting with http/https is fine.
Is it worth it if we ended up using gstreamer for rtsp anyway?
I don't think we should be doing that.
https://bugs.winehq.org/show_bug.cgi?id=52769
--- Comment #8 from yshuiv7@gmail.com --- (In reply to Nikolay Sivov from comment #7)
The question is how it's reflected in media foundation API, e.g. what data will be returned from bytestream created with CreateObjectFromURL("rtsp://..."), and if it's possible for application to configure which streams are requested.
I'd assume CreateObjectFromURL would return a media source object whether you asked for it or not. Should be relatively easy to verify.
Did you find an application that depends on this protocol handler? Except for ones that accept any url, including rtsp.
VRChat uses it to play live streams.
Is it worth it if we ended up using gstreamer for rtsp anyway?
I don't think we should be doing that.
OK, then I probably won't take on the task of implementing all this from scratch. Right now I want to focus on getting this to users asap.
https://bugs.winehq.org/show_bug.cgi?id=52769
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #9 from Zeb Figura z.figura12@gmail.com --- I don't know what the mfplat considerations are, but it also strikes me as potentially reasonable to create an element wrapping GStreamer's rtspsrc, but without hooking that up directly to decodebin.
https://bugs.winehq.org/show_bug.cgi?id=52769
--- Comment #10 from Nikolay Sivov bunglehead@gmail.com --- (In reply to Zeb Figura from comment #9)
I don't know what the mfplat considerations are, but it also strikes me as potentially reasonable to create an element wrapping GStreamer's rtspsrc, but without hooking that up directly to decodebin.
Current version of it is now at https://github.com/ValveSoftware/wine/pull/142, it doesn't share mf.dll parts now.
-
WineHQ Bugzilla