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 upFix sink pad ordering #213
Conversation
c413cf5
to
957a4cd
|
I'm done for the day, but I do need to write some more comments for this. Will do tomorrow. |
| // | ||
| // An alternate fix is to sort pending_streams according to the m-line index | ||
| // and just do it in order. This also seems brittle. | ||
| webrtc.get_request_pad("sink_%u").unwrap(); |
This comment has been minimized.
This comment has been minimized.
Manishearth
Feb 27, 2019
Author
Member
I feel like there's an underlying bug here, this should be unnecessary
cc @slomo
378076b
to
1e15743
| @@ -21,7 +21,7 @@ lazy_static! { | |||
| &[ | |||
| ("media", &"video"), | |||
| ("encoding-name", &"VP8"), | |||
| ("payload", &(96i32)), | |||
| // ("payload", &(96i32)), | |||
This comment has been minimized.
This comment has been minimized.
| thread: WebRtcThread, | ||
| signaller: Box<WebRtcSignaller>, | ||
| /// All the streams that are connected to the |
This comment has been minimized.
This comment has been minimized.
| /// | ||
| /// When we create an offer, we're controlling the pad order, so we set request_new_pads | ||
| /// to true and forcefully link all pending streams before generating the offer. | ||
| fn link_stream(&mut self, mut boxed_stream: Box<MediaStream>, request_new_pads: bool) { |
This comment has been minimized.
This comment has been minimized.
| @@ -90,6 +90,7 @@ pub enum InternalEvent { | |||
| OnNegotiationNeeded, | |||
| OnIceCandidate(IceCandidate), | |||
| OnAddStream(Box<MediaStream>), | |||
| DescriptionAdded(SendBoxFnOnce<'static, ()>, bool, SdpType), | |||
This comment has been minimized.
This comment has been minimized.
| let element = stream.src_element(); | ||
|
|
||
| if let Some(idx) = idx { | ||
| if idx >= self.request_pad_counter { |
This comment has been minimized.
This comment has been minimized.
jdm
Mar 1, 2019
Member
Is there any risk that we could call link_stream with !request_new_pads but end up running this code that requests pads? Would that be bad? I find the logic here a little bit obtuse.
This comment has been minimized.
This comment has been minimized.
Manishearth
Mar 2, 2019
Author
Member
Yes, this code requesting new pads is fine, request_new_pads is about requesting new pads when there is no remote m-line: in that case we normally want to just buffer it up for later, except for when we're making an offer, at which point we want to flush all buffered streams.
The behavior of this function with !request_new_pads is "request pads only if they have been set up by the remote already", which is too long to fit in a variable. I can document this more explicitly.
|
|
4835ab0
to
cec05f0
cec05f0
to
f0e7554
|
@bors-servo r=jdm |
|
|
Fix sink pad ordering Fixes #210 Based on #208 This implements a version of the fix detailed in #210 (comment) Instead of unlinking/relinking, we simply keep new streams unlinked until we decide to trigger an offer, at which point we link them to new request pads. The answerer side keeps them unlinked until it gets a remote offer, at which point it also requests pads and links them to the correctly numbered request pads. A missing piece was that the payload number also has to match, so we keep track of that too. r? @jdm @slomo (last two commits only)
|
|
slomo
commented
Mar 4, 2019
|
@Manishearth You are mentioning the wrong guy in your PR. |
|
Oh, sorry about that! |
Get rid of unsafe SDP media workaround Upstream had [a bug](https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/issues/189) which we worked around in #213 by directly accessing the underlying GObject data. This is no longer necessary after the gstreamer update, pulling in #213 r? @sdroege @ferjm
Manishearth commentedFeb 27, 2019
Fixes #210
Based on #208
This implements a version of the fix detailed in #210 (comment)
Instead of unlinking/relinking, we simply keep new streams unlinked until we decide to trigger an offer, at which point we link them to new request pads. The answerer side keeps them unlinked until it gets a remote offer, at which point it also requests pads and links them to the correctly numbered request pads.
A missing piece was that the payload number also has to match, so we keep track of that too.
r? @jdm @slomo (last two commits only)