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)

defect

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.
Whiteboard: [WebRTC], [blocking-webrtc+]
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-]
Summary: Allow multiple audio and/or multiple video streams in PeerConnection → Signaling support to allow multiple audio and/or multiple video streams in PeerConnection
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
Until this bug is completed, interested parties may find the following information useful: https://hacks.mozilla.org/2013/09/webrtc-update-and-workarounds/
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.
(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.
Is this bug also targeted for delivery in FF 35 like Bug 907339 is?
Flags: needinfo?(adam)
(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)
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)
Blocks: 1056650
Whiteboard: [WebRTC], [blocking-webrtc-]
Depends on: sdparta
Attached patch (WIP) Multistream support (obsolete) — Splinter Review
Prototype work. Passes multistream mochitests, need to verify with an actual multistream-based service.
Assignee: nobody → docfaraday
Status: NEW → ASSIGNED
Depends on: 1095218
Attached patch (WIP) Multistream support (obsolete) — Splinter Review
Allow mochitests to render more than one stream of each type.
Attachment #8529487 - Attachment is obsolete: true
Attached patch (WIP) Multistream support (obsolete) — Splinter Review
Refactor to use MST track ids instead of MSG track ids.
Attachment #8531302 - Attachment is obsolete: true
Attached patch (WIP) Multistream support (obsolete) — Splinter Review
Remove a bad assert
Attachment #8534521 - Attachment is obsolete: true
Attached patch (WIP) Multistream support (obsolete) — Splinter Review
Moved some stuff to the msid patch.
Attachment #8535072 - Attachment is obsolete: true
Attached patch (WIP) Multistream support (obsolete) — Splinter Review
Unrot
Attachment #8535250 - Attachment is obsolete: true
See Also: → 1108248
Attached patch (WIP) Multistream support (obsolete) — Splinter Review
Surface remote track ids to content via MediaStreamTrack, and check that track ids are surfaced in mochitests.
Attachment #8538826 - Attachment is obsolete: true
Blocks: 1115823
Attached patch Multistream support. (obsolete) — Splinter Review
Clean up a bit.
Attachment #8539578 - Attachment is obsolete: true
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
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.

Attachment

General

Created:
Updated:
Size: