Allow consuming stream data from a client app #372
Conversation
ferjm
changed the title
|
r? Manishearth |
There was a problem hiding this comment.
I'm not a fan of this approach, it seems like we're overloading media capture streams with this mode, whereas I'd prefer to not affect that code path.
I don't think push_data should live on the stream either.
What I would imagine we do here is that we have a ClientStreamSource object that contains an appsrc, and you can obtain a stream from it using create_video_from. This is how this API is used elsewhere, GStreamerMediaStream doesn't contain explicit logic for any stream producer, instead it lets you create a stream from an element.
| @@ -245,12 +245,20 @@ impl Backend for GStreamerBackend { | |||
| media_capture::create_audioinput_stream(set) | |||
| } | |||
|
|
|||
| fn create_videoinput_stream(&self, set: MediaTrackConstraintSet) -> Option<MediaStreamId> { | |||
| fn create_videoinput_stream( | |||
There was a problem hiding this comment.
I don't think we should be doing this in create_videoinput_stream, that's specifically for screen capture input. We should have a separate create_capture_stream IMO.
| self.video_app_source = Some(source.clone()); | ||
| } | ||
|
|
||
| pub fn create_video_from(source: gst::Element, size: Option<Size2D<u32>>) -> MediaStreamId { |
There was a problem hiding this comment.
We shouldn't be doing decoding within create_video_from, it's the responsibility of the client to do that (see webrtc, all media streams are raw, this was a deliberate choice and without it we will have problems)
|
☔ The latest upstream changes (presumably #390) made this pull request unmergeable. Please resolve the merge conflicts. |
This is required to implement servo/servo#26861
Tested with 2d and 3D content.