[Bug 52769] New: Missing MFSchemeHandler for common url schemes
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(a)winehq.org Reporter: yshuiv7(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52769 yshuiv7(a)gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |yshuiv7(a)gmail.com --- Comment #1 from yshuiv7(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52769 Zeb Figura <z.figura12(a)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 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52769 --- Comment #2 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52769 --- Comment #3 from Nikolay Sivov <bunglehead(a)gmail.com> --- Existing report for this is bug 49392. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52769 --- Comment #4 from yshuiv7(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52769 --- Comment #5 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52769 --- Comment #6 from yshuiv7(a)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? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52769 --- Comment #7 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52769 --- Comment #8 from yshuiv7(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52769 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #9 from Zeb Figura <z.figura12(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=52769 --- Comment #10 from Nikolay Sivov <bunglehead(a)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. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla