Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upPlay media streams #227
Play media streams #227
Conversation
02cb4d0
to
acda3e4
| gst_log!(self.cat, "Setting stream"); | ||
|
|
||
| // Append a proxysink to the media stream pipeline. | ||
| let pipeline = stream.pipeline_or_new(); |
This comment has been minimized.
This comment has been minimized.
Manishearth
Mar 29, 2019
Member
Can we just use attach_to_pipeline here? Is there a reason there needs to be a proxysrc/sink? The GstreamerMediaStream may already arise from a proxysrc element.
This comment has been minimized.
This comment has been minimized.
ferjm
Apr 1, 2019
Author
Member
What's the benefit of using attach_to_pipeline over the current approach?
In any case, I am not sure if this is possible. The GstPlayer pipeline's (playbin) source is read-only, so I am not sure if I can modify the pipeline directly. I can try if you think it is a better option though.
This comment has been minimized.
This comment has been minimized.
Manishearth
Apr 1, 2019
Member
What's the benefit of using attach_to_pipeline over the current approach?
It avoids an extra proxy.
You don't add it to the playbin's pipeline, you add it to ServoMediaStreamSrc::constructed. May need a new version of attach_to_pipeline for attach_to_bin.
Right now the code adds a proxysrc to ServoMediaStreamSrcs bin, instead we should attach the entire MediaStream pipeline to it.
This doesn't have to be done in this PR, and I can try to do it later if you want.
This comment has been minimized.
This comment has been minimized.
Manishearth
Apr 1, 2019
Member
I guess setting up the ghost pads is trickier if you want to do this, since you don't have the streams during construction. Hmm.
This comment has been minimized.
This comment has been minimized.
ferjm
Apr 2, 2019
Author
Member
Ok, I see.
I think that should be fine as long as we set the ghost pad before setting the player's uri.
This comment has been minimized.
This comment has been minimized.
Manishearth
Apr 2, 2019
Member
Oh, as in we just don't connect the ghost pad to anything? That could work, I'm not sure if ghost pads can do that.
This comment has been minimized.
This comment has been minimized.
ferjm
Apr 2, 2019
Author
Member
We need to connect the ghost pad to something and I thought that that something could be a fakesrc or such. But it does not seem to work :\
This comment has been minimized.
This comment has been minimized.
|
I can verify that the audio reaches the other end of the proxysink. Unsure where it's getting dropped. |
|
|
|
I can hear sound now with the current patch. This is not finished yet though. We need to share the mediastream with multiple consumers at the same time (i.e. player, webrtc), so I need to make the mediastream pipeline include a |
| .dynamic_cast::<gst::Pipeline>() | ||
| .unwrap(); | ||
| let clock = gst::SystemClock::obtain(); | ||
| playbin.set_base_time(clock.get_time()); |
This comment has been minimized.
This comment has been minimized.
philn
Apr 1, 2019
Collaborator
This base time might not be exactly the same as the one set on the mediastream pipeline. You'd need to share the value, somehow.
This comment has been minimized.
This comment has been minimized.
Manishearth
Apr 2, 2019
•
Member
I think we'll probably try to set basetime zero everywhere to be consistent?
Eventually all of the pipelines here should be able to talk to each other through streams.
|
Is it possible to have multiple (This is particularly nice for the webrtc case, where we have a proxysrc element already) Of course, for non-gst streams we will have to use an appsrc-proxysrc pipeline, but we don't have any of those yet. |
That would be nice, and I also thought about this, but @philn told me that proxysrcs have a 1:1 relation with proxysinks, so AFAICT we still need the tee if we want to share streams between different pipelines. |
|
Unfortunately I wasn't able to successfully run the webrtc example yet, so I'm going to leave the part to allow multiple consumers of a media stream for a follow-up. r? @Manishearth |
|
I'd already basically reviewed this when debugging it, r+ |
| pipeline.set_start_time(gst::ClockTime::none()); | ||
| pipeline.set_base_time(gst::ClockTime::from_nseconds(0)); | ||
| pipeline.use_clock(Some(&gst::SystemClock::obtain())); | ||
| pipeline.set_base_time(*BACKEND_BASE_TIME); |
This comment has been minimized.
This comment has been minimized.
Manishearth
Apr 2, 2019
Member
Is this change necessary? As I understand it the base times just need to match, they don't need to be the actual time things started.
To be clear: I don't want you to undo this change, I think it's a good step forward to use some semblance of a real base time, I'm more curious if BACKEND_BASE_TIME is really necessary (or if we can get away with using 0 everywhere)
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
philn
Apr 2, 2019
Collaborator
The base time can remain at 0 only if both pipelines start playback at the same time, which is not the case here, AFAIU? This is mentioned in the proxy docs (example): https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-bad-plugins/html/gst-plugins-bad-plugins-proxysrc.html
|
I'll look into getting this working with the webrtc example. |
|
If you want multiple media stream consumers, perhaps try it with video + 2x autovideosink? |
|
@bors-servo r=Manishearth |
|
|
|
|
ferjm commentedMar 29, 2019
No description provided.