Closed
Bug 1608877
Opened 4 years ago
Closed 4 years ago
RtpRtcSender.replaceTrack should not start the stream if it has stopped
Categories
(Core :: WebRTC: Audio/Video, defect, P3)
Core
WebRTC: Audio/Video
Tracking
()
RESOLVED
FIXED
mozilla74
| Tracking | Status | |
|---|---|---|
| firefox74 | --- | fixed |
People
(Reporter: achronop, Assigned: achronop)
References
(Regression)
Details
(Keywords: regression)
Attachments
(1 file)
This can happen if many stops arrive after a replaceTrack() call when the tracks belonging to different MTGs. This is implemented internally by stopping and restarting the transmission. Restart happens asynchronously when stop has finished. If a second stop arrives in the meantime we need to cancel the pending start.
|
Assignee | |
Comment 1•4 years ago
|
||
In MediaPipelineTransmit::SetTrack() when a track of different MTG is replaced, the transmission is stopped and restarted asynchronously. This can create a problem if a new stop has arrived in the meantime. The transmission should not be restarted in that case.
This change adds a boolean, to check when an asynchronous start is expected and ignores it if not needed.
|
||
Updated•4 years ago
|
Has Regression Range: --- → yes
Keywords: regression
Pushed by achronopoulos@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c2938179dbb9 Ignore async transmission start if a new stop has arrived. r=padenot
|
||
Comment 3•4 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox74:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla74
You need to log in
before you can comment on or make changes to this bug.
Description
•