-
|
The example is renegotiate every time a transceiver is added. But in a real application, I would like to replace a track without re-negotiating. Something similar to the browser's In my script, I pre-prepare all the transceivers and then add the actual tracks. I would like to understand how to use the library, but so far, the only thing I've managed to run is the example. |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments 2 replies
-
|
If you are using the frame-based API you can just start sending data from a different track whenever you want. As long as the m-line is negotiated to handle the codecs of the new track. You can pause tracks, either by just not sending any more traffic or by setting the m-line to inactive and negotiating using You'll also get an event |
Beta Was this translation helpful? Give feedback.
-
|
Correct me if I'm wrong. Is this place for making this replacement?: fn handle_media_data_out(&mut self, origin: ClientId, data: &MediaData) {
// Figure out which outgoing track maps to the incoming media data.
let Some(mid) = self
.tracks_out
.iter()
.find(|o| {
o.track_in
.upgrade()
.filter(|i| i.origin == origin && i.mid == data.mid)
.is_some()
})
.and_then(|o| o.mid())
else {
return;
};
if data.rid.is_some() && data.rid != Some("h".into()) {
// This is where we plug in a selection strategy for simulcast. For
// now either let rid=None through (which would be no simulcast layers)
// or "h" if we have simulcast (see commented out code in chat.html).
return;
}
// Remember this value for keyframe requests.
if self.chosen_rid != data.rid {
self.chosen_rid = data.rid;
}
let Some(writer) = self.rtc.writer(mid) else {
return;
};
// Match outgoing pt to incoming codec.
let Some(pt) = writer.match_params(data.params) else {
return;
};
if let Err(e) = writer.write(pt, data.network_time, data.time, data.data.clone()) {
warn!("Client ({}) failed: {:?}", *self.id, e);
self.rtc.disconnect();
}
} |
Beta Was this translation helpful? Give feedback.
-
|
@Razzwan that's right. So it depends on what you mean by "replace track". If you intend to change codec, you would have a different codec under another |
Beta Was this translation helpful? Give feedback.
-
|
In my case, I need to pre-create all 12 transceivers in the browser client when generating the offer, since the room will always have exactly 12 participants. Each participant must be able to receive both H.264 and VP8 video, potentially with different payload types for the same codec. When a user joins a specific seat, I want to start streaming their video to all others. Each seat has a fixed mid, so if two users swap seats, no renegotiation should occur — only the video sources should be switched. Currently, the
Can I do that on the fly without renegotiation? If yes, what should I do for that?
Actually, in previous implementation I sent PLI each time users swap seats. So, I don't think, that ensuring the new data is keyframe is strongly required. I don't have limitations by sending PLI requests each time someone connected the room or just refreshing the page, but if library allow that, it would be grate feature to improve performance |
Beta Was this translation helpful? Give feedback.
-
str0m tries to follow If I was in your situation, with fixed tracks,
In SDP, first time you try to send video, the OFFER side goes "here are ALL the codecs/parameters I support". Each codec has a unique PT. The ANSWER side responds by keeping the PTs it agrees on, in the preferred order. Notice the receiver of media decides. Some pitfalls documented here: https://github.com/algesten/str0m/blob/main/docs/SDP.md#the-sdp-offeranswer-spec If your m-lines are bi-directional |
Beta Was this translation helpful? Give feedback.
-
Actually, I can. The first transceiver is assigned mid = 0, the second gets mid = 1, and so on. This behavior is consistent across most browsers, including all major ones.
What is the difference betwee For example: can I change only this part of code, or should I change all the places where api touched, because dirrect API is completely differen way of interract with library: // can I replace only this place to use dirrect_api, or it will not be possible just only in one place?
let mut change = self.rtc.sdp_api();
for track in &mut self.tracks_out {
if let TrackOutState::ToOpen = track.state {
if let Some(track_in) = track.track_in.upgrade() {
let stream_id = track_in.origin.to_string();
let mid = change.add_media(
track_in.kind,
Direction::SendOnly,
Some(stream_id),
None,
None,
);
track.state = TrackOutState::Negotiating(mid);
} else {
tracing::warn!("Не удалось upgrade исходящий трек");
}
}
}
Yes, great! So, I would like to change pt for the same codec on the fly to keep it always the same as it was difined within negotiation process. Can I do that?
I have only uni-directional transceivers. What does it mean, that receiver CAN change it? For example, I sent offer that I will support h264 with pt 98 and vp8 with pt 96, answer respond the same thing: h264 pt 98 and vp8 pt 96. Then I send h264 pt 98 and receiver can change it somehow? |
Beta Was this translation helpful? Give feedback.
-
I don't believe that behavior is guaranteed by spec.
Big question, but I think the short answer is "No", the idea is that you either use SDP or Direct API. If you use Direct API, you make the equivalent changes in the browser by mangling (manually change the SDP) in javascript before calling setLocalDescription. The goal of SDP, or Direct API is, roughly, to get both sides to share a config of mid/rid/pt. With SDP this is a negotiation with the OFFER/ANSWER dance. With Direct API you make local changes and make sure they are consistent on both sides.
No. Once negotiated, the m-line is locked and the PT is assigned to a specific codec. To change codec, you use another PT (that was also negotiated).
With "the receiver" here I mean the direction on the m-line. Having said that, in str0m you can't have asymmetric PT assignment (different in the two directions (vp8 96 in one direction and vp8 99 in the other), and you can't have different PT assignments in different m-lines (vp8 96 in mid:0, but vp8 99 in mid:1). str0m considers the PT session wide in both directions. |
Beta Was this translation helpful? Give feedback.
-
You wrote about Not a standard WebRTC "Peer Connection" API and I completely agree, that blind following specs could not lead to success. The best way to interact with specifications is to propose adjustments to the specification and discuss with those who wrote the original specification why the new ideas are better than what was already written. That's why I really like str0m: you don't try to blindly follow the specification
This is m-line which was generated as |
Beta Was this translation helpful? Give feedback.
-
|
@Razzwan Notice that
You will force str0m to lock down the PTs the way the javascript side has them. The first |
Beta Was this translation helpful? Give feedback.
If you are using the frame-based API you can just start sending data from a different track whenever you want. As long as the m-line is negotiated to handle the codecs of the new track.
You can pause tracks, either by just not sending any more traffic or by setting the m-line to inactive and negotiating using
SdpApi::set_direction.You'll also get an event
Event::SteamPausdwhen str0m detects an incoming stream has been paused.