Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Play media streams #227

Merged
merged 5 commits into from Apr 2, 2019
Merged

Play media streams #227

merged 5 commits into from Apr 2, 2019

Conversation

@ferjm
Copy link
Member

ferjm commented Mar 29, 2019

No description provided.

@ferjm ferjm force-pushed the ferjm:media.streams branch 2 times, most recently from 02cb4d0 to acda3e4 Mar 29, 2019
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.

@Manishearth

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.

@ferjm

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.

@Manishearth

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.

@Manishearth

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.

@ferjm

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.

@Manishearth

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.

@ferjm

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.

@Manishearth

Manishearth Apr 2, 2019

Member

Yeah. ANyway, we don't have to solve this yet.

@Manishearth
Copy link
Member

Manishearth commented Mar 29, 2019

I can verify that the audio reaches the other end of the proxysink. Unsure where it's getting dropped.

@bors-servo
Copy link
Contributor

bors-servo commented Apr 1, 2019

The latest upstream changes (presumably #229) made this pull request unmergeable. Please resolve the merge conflicts.

@ferjm ferjm force-pushed the ferjm:media.streams branch from aac752a to c3d14b7 Apr 1, 2019
@ferjm
Copy link
Member Author

ferjm commented Apr 1, 2019

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 tee so we can have one src pad per consumer.

.dynamic_cast::<gst::Pipeline>()
.unwrap();
let clock = gst::SystemClock::obtain();
playbin.set_base_time(clock.get_time());

This comment has been minimized.

@philn

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.

@Manishearth

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.

@Manishearth
Copy link
Member

Manishearth commented Apr 2, 2019

Is it possible to have multiple proxysrcs associated with a single proxysink? If so we won't need the tee element, instead we can unify all mediastreams as a single proxysrc element.

(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.

@ferjm
Copy link
Member Author

ferjm commented Apr 2, 2019

Is it possible to have multiple proxysrcs associated with a single proxysink? If so we won't need the tee element, instead we can unify all mediastreams as a single proxysrc element.

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.

@ferjm ferjm force-pushed the ferjm:media.streams branch from c3d14b7 to 8780452 Apr 2, 2019
@ferjm
Copy link
Member Author

ferjm commented Apr 2, 2019

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

@ferjm ferjm changed the title [WIP] Play media streams Play media streams Apr 2, 2019
Copy link
Member

Manishearth left a comment

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.

@Manishearth

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.

@ferjm

ferjm Apr 2, 2019

Author Member

I'll defer the answer to @philn :)

This comment has been minimized.

@philn

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

@Manishearth
Copy link
Member

Manishearth commented Apr 2, 2019

I'll look into getting this working with the webrtc example.

@Manishearth
Copy link
Member

Manishearth commented Apr 2, 2019

If you want multiple media stream consumers, perhaps try it with video + 2x autovideosink?

@ferjm
Copy link
Member Author

ferjm commented Apr 2, 2019

@bors-servo r=Manishearth

@bors-servo
Copy link
Contributor

bors-servo commented Apr 2, 2019

📌 Commit 9a963a1 has been approved by Manishearth

@bors-servo
Copy link
Contributor

bors-servo commented Apr 2, 2019

Testing commit 9a963a1 with merge 3fb362c...

bors-servo added a commit that referenced this pull request Apr 2, 2019
Play media streams
@bors-servo
Copy link
Contributor

bors-servo commented Apr 2, 2019

☀️ Test successful - checks-travis
Approved by: Manishearth
Pushing 3fb362c to master...

@bors-servo bors-servo merged commit 9a963a1 into servo:master Apr 2, 2019
2 checks passed
2 checks passed
Travis CI - Pull Request Build Passed
Details
homu Test successful
Details
@ferjm ferjm deleted the ferjm:media.streams branch Apr 2, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

4 participants
You can’t perform that action at this time.