Closed
Bug 784517
Opened 12 years ago
Closed 9 years ago
Signaling support to allow multiple audio and/or multiple video streams in PeerConnection
Categories
(Core :: WebRTC: Signaling, defect, P2)
Core
WebRTC: Signaling
Tracking
()
RESOLVED
DUPLICATE
of bug 1095218
People
(Reporter: ehugg, Assigned: bwc)
References
(Blocks 1 open bug)
Details
Attachments
(8 obsolete files)
Allow multiple audio and/or multiple video streams in PeerConnection Currently we only do one of each.
Updated•12 years ago
|
Whiteboard: [WebRTC], [blocking-webrtc+]
Comment 1•12 years ago
|
||
REALLY want this, but wouldn't block first preffed-on release. Mostly signaling, but may involve other parts (dep bugs)
Priority: -- → P2
Whiteboard: [WebRTC], [blocking-webrtc+] → [WebRTC], [blocking-webrtc-]
Updated•11 years ago
|
Summary: Allow multiple audio and/or multiple video streams in PeerConnection → Signaling support to allow multiple audio and/or multiple video streams in PeerConnection
Comment 2•11 years ago
|
||
This is the main bug for signaling support for more than 1 audio and more than 1 video flows. Adam will lead the effort on this bug and start work on this after Bug 784491 (signaling for BUNDLE) is completed. Bug 784491 is scheduled to be completed on 11-18. I expect this bug will become a meta bug. We're estimating the signaling effort for multiple flows to take about 20 man-weeks, which is about 33 weeks if we discount by 40% (the amount of time Adam spends on other work -- largely standards work) and assume only Adam works on it. If Adam starts this work in mid-November, he'd be done in late July assuming this initial estimate is accurate (which is probably isn't). I think it makes sense to break this bug down into smaller bugs after Adam finishes with Bug 784491. At that time we'll also see if we can parallelize some of the work. In the meantime, I'll set a placeholder deadline of late July and not bother with a target milestone.
Assignee: nobody → adam
Comment 3•11 years ago
|
||
Until this bug is completed, interested parties may find the following information useful: https://hacks.mozilla.org/2013/09/webrtc-update-and-workarounds/
Comment 4•10 years ago
|
||
This issue is related to https://bugzilla.mozilla.org/show_bug.cgi?id=977864. However I believe emcho answer gives an excellent statement of the current situation: 1. Chrome currently provides support for handling multiple media streams (SSRCs) within a single connection. It does so through a non-standard mechanism known as “Plan B”. We currently rely on this mechanism for efficient multiparty video conferencing in Jitsi Meet. 2. In early 2013 a debate took place on the IETF about finding a standard way for managing multiple streams within a peer connection. There were several proposals, one of which, known as “Plan A” was authored by and very strongly supported by Mozilla. Arguments that “Plan A” would imply substantial complexity were vigorously countered. 3. After long debates the IETF agreed to adopt a “Plan UNIFIED” as a solution, which was basically a somewhat adjusted version of “Plan A”. All other proposals were rejected and in other words: Mozilla won! 4. AFAIK Mozilla has not even started implementing their own Plan UNIFIED and people are cautioned not to hold their breath because its implementation implies substantial complexity. 5. In the mean time, Mozilla is often encouraging people to basically abandon usage of multiple streams within a single PeerConnection and advising adoption of other means for handling multiparty conferencing 6. There seems to be absolutely no inclination in Mozilla to even consider compromises or alternative solutions. It's very sad that Mozilla can not support multiple video streams in same PeerConnection. Many great open source webrtc rely on that. I would like to see at least some willingness to dialogue this issue on Mozilla side.
Comment 5•10 years ago
|
||
(In reply to Peter Stern from comment #4) > This issue is related to https://bugzilla.mozilla.org/show_bug.cgi?id=977864. > > However I believe emcho answer gives an excellent statement of the current > situation: > > 1. Chrome currently provides support for handling multiple media streams > (SSRCs) within a single connection. It does so through a non-standard > mechanism known as “Plan B”. We currently rely on this mechanism for > efficient multiparty video conferencing in Jitsi Meet. > 2. In early 2013 a debate took place on the IETF about finding a standard > way for managing multiple streams within a peer connection. There were > several proposals, one of which, known as “Plan A” was authored by and very > strongly supported by Mozilla. Arguments that “Plan A” would imply > substantial complexity were vigorously countered. > 3. After long debates the IETF agreed to adopt a “Plan UNIFIED” as a > solution, which was basically a somewhat adjusted version of “Plan A”. All > other proposals were rejected and in other words: Mozilla won! > 4. AFAIK Mozilla has not even started implementing their own Plan UNIFIED > and people are cautioned not to hold their breath because its implementation > implies substantial complexity. > 5. In the mean time, Mozilla is often encouraging people to basically > abandon usage of multiple streams within a single PeerConnection and > advising adoption of other means for handling multiparty conferencing > 6. There seems to be absolutely no inclination in Mozilla to even consider > compromises or alternative solutions. > > It's very sad that Mozilla can not support multiple video streams in same > PeerConnection. Many great open source webrtc rely on that. I would like to > see at least some willingness to dialogue this issue on Mozilla side. This is not an appropriate comment. Please read: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Why is it inappropriate here while in the other issue it was accepted? Peter Stern could you provide links and quotes to proof your statements.
Comment 7•10 years ago
|
||
Is this bug also targeted for delivery in FF 35 like Bug 907339 is?
Flags: needinfo?(adam)
Comment 8•10 years ago
|
||
(In reply to karim.tajdin2 from comment #7) > Is this bug also targeted for delivery in FF 35 like Bug 907339 is? I'm actually working on other aspects of the system at the moment; this bug should have been reassigned. Maire Reavy is managing project timelines for WebRTC features -- I'm lateraling this request to her.
Assignee: adam → nobody
Flags: needinfo?(adam) → needinfo?(mreavy)
Comment 9•10 years ago
|
||
Adding Multistream support (which means this bug, Bug 907339, BUNDLE, and the unified plan) is our next big feature push. We're shipping screen sharing and OpenH264 in Fx 33 with cleanup, and improvements coming in Fx 34 and then I want to turn our attention to multistream during the Fx35 dev cycle. I don't know yet how long it will take us to complete. I'll be looking to prioritize work that gets us the biggest bang for our buck as early as possible. Any contributions to help us get this done more quickly and efficiently are appreciated.
Flags: needinfo?(mreavy)
Assignee | ||
Comment 10•10 years ago
|
||
Prototype work. Passes multistream mochitests, need to verify with an actual multistream-based service.
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → docfaraday
Status: NEW → ASSIGNED
Assignee | ||
Comment 11•10 years ago
|
||
Allow mochitests to render more than one stream of each type.
Assignee | ||
Updated•10 years ago
|
Attachment #8529487 -
Attachment is obsolete: true
Assignee | ||
Comment 12•9 years ago
|
||
Refactor to use MST track ids instead of MSG track ids.
Assignee | ||
Updated•9 years ago
|
Attachment #8531302 -
Attachment is obsolete: true
Assignee | ||
Comment 13•9 years ago
|
||
Remove a bad assert
Assignee | ||
Updated•9 years ago
|
Attachment #8534521 -
Attachment is obsolete: true
Assignee | ||
Comment 14•9 years ago
|
||
Moved some stuff to the msid patch.
Assignee | ||
Updated•9 years ago
|
Attachment #8535072 -
Attachment is obsolete: true
Assignee | ||
Comment 15•9 years ago
|
||
Unrot
Assignee | ||
Updated•9 years ago
|
Attachment #8535250 -
Attachment is obsolete: true
Assignee | ||
Comment 16•9 years ago
|
||
Surface remote track ids to content via MediaStreamTrack, and check that track ids are surfaced in mochitests.
Assignee | ||
Updated•9 years ago
|
Attachment #8538826 -
Attachment is obsolete: true
Assignee | ||
Comment 17•9 years ago
|
||
Clean up a bit.
Assignee | ||
Updated•9 years ago
|
Attachment #8539578 -
Attachment is obsolete: true
Assignee | ||
Comment 18•9 years ago
|
||
Comment on attachment 8544234 [details] [diff] [review] Multistream support. Since this is so tangled up with msid, I'm just moving this over to bug 1095218.
Attachment #8544234 -
Attachment is obsolete: true
Assignee | ||
Updated•9 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•