unified plan: unannounced streams are not played |
||||||
Issue descriptionsplit from https://bugs.chromium.org/p/chromium/issues/detail?id=906988#c46 -- see there for history/comments. Steps to reproduce: 1) Apply the attached patch to a checkout of https://github.com/webrtc/samples 2) run a http server, e.g. with python -m SimpleHTTPServer 3) visit http://localhost:8000/src/content/peerconnection/pc1/ in Chrome Canary 4) make a call 5) open the JS console, run `renegotiate()` This will make pc1 send media. You can see in the pc2 stats in webrtc-internals this is received. 6) run `pc2.setRemoteDescription(pc1.localDescription)` This makes the third ssrc visible on pc2 in webrtc-internals. The video turns black but that is just the ontrack handler being silly. The new ssrc doesn't seem to receive anything.
,
Dec 10
,
Dec 10
,
Dec 10
I'm having some difficulty interpreting what is the correct behavior here. Could you please explain a bit more what the issue is and what you expect should happen?
,
Dec 10
After step 6 the second stream (desktop) should be displayed. All the stats for that stream remain empty in webrtc-internals. Whether it should be displayed before step 6 is an interesting question... See also your comment 35 in the other bug.
,
Dec 10
If I run pc2.setLocalDescription(pc1.remoteDescription) after step #6 it seems like everything works.
The packets should be getting dropped on pc2 before step 6 since BUNDLE says:
If the MID associated with the RTP stream is not in the table
mapping MID to "m=" section, then the RTP stream is not decoded
and the payload data is discarded.
It looks like they don't get passed down to the media engine after just step 6 since playout is not turned on until the local description is set: https://codesearch.chromium.org/chromium/src/third_party/webrtc/pc/channel.cc?l=306&rcl=69540f44196eba13cb7c9046aa838c461eba9029
So I'm inclined to say this bug is "working as intended".
,
Dec 10
good point. But that merely means we have no repro for the "early media" case from issue #906908 ?
,
Dec 10
I'm not 100% sure I understand what the problem is from the other issue beyond the track ID not getting set in the stats. Maybe raulbenitezmejias@gmail.com can say if the change (which can be downloaded with the latest dev build) has fixed the issue entirely?
,
Dec 11
,
Dec 11
,
Dec 11
setRemoteDescription(offer) does not set the transports of transcievers, this happens at setLocalDescription(...) or setRemoteDescription(answer). It is also only the answer, whether you are the offerer or the answerer, that updates the current direction of the transceiver.
,
Dec 11
in that case... should the stats already show up? :-) |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by philipp....@googlemail.com
, Dec 102.4 KB
2.4 KB Download