RtcStats doesn't report remote data properly with unified plan
Reported by
raulbeni...@gmail.com,
Nov 20
|
||||||||||||||||||||||||||||||||||||||||||||
Issue description
Chrome Version (from the about:version page): 71.0.3551.3
Is this the most recent version: Yes
Behavior in Linux Firefox: Yes
What steps will reproduce the problem?
In chrome-rtcstats.txt there are the steps, with the sdps, to reproduce the problem.
I used Chrome-dev with unified plan, vp8 as video codec and opus as audio codec.
The are two browsers:
Browser A starts without media (0 video track, 0 audio track)
Browser B starts with (1 video track, 1 audio track)
When we try to recover the remote rtcstats from Browser A, we find the problem. There isn't data for each remote tracks, but we are sure that Browser B is sending media.
What is the expected result?
After a receiver track is added, and it receives media, the RtcStats must update its values properly.
What happens instead?
"{\"id\":\"RTCInboundRTPVideoStream_2222271640\",\"timestamp\":1542640720853.16,\"type\":\"inbound-rtp\",\"ssrc\":2222271640,\"isRemote\":false,\"mediaType\":\"video\",\"kind\":\"video\",\"transportId\":\"RTCTransport_0_1\",\"codecId\":\"RTCCodec_1_Inbound_96\",\"firCount\":0,\"pliCount\":1,\"nackCount\":0,\"qpSum\":10457,\"packetsReceived\":302,\"bytesReceived\":275642,\"packetsLost\":0,\"fractionLost\":0,\"framesDecoded\":99}"
This entry doesn't have "trackId" associated and looks like it causes the media is not decoded by video tag. In chrome-rtcstats.txt, you can find more information.
,
Nov 20
Are you sure it is sending media, because I don't see any outbound RTP stats from browser B. Have you exchanged ice candidates? Does this work in Plan B? Can you reproduce the problem in a short snippet, for example in https://codepen.io/?
,
Nov 20
Yes, I'm sure.
In chrome-rtcstats.txt, you can see
Browser B asks by Senders RtcStats (It's sending media)
"{\"id\":\"RTCMediaStreamTrack_sender_4\",\"timestamp\":1542640720827.627,\"type\":\"track\",\"trackIdentifier\":\"24f80a8a-cfb0-49a0-9183-86c8fa9b0155\",\"remoteSource\":false,\"ended\":false,\"detached\":false,\"kind\":\"video\",\"frameWidth\":480,\"frameHeight\":360,\"framesSent\":103,\"hugeFramesSent\":0}"
And here there is more information:
Mon Nov 19 07:18:35 PST 2018;INFO;https://172.22.6.14:8443/js/vms-test.js 87:101 "{\"id\":\"RTCOutboundRTPVideoStream_1152639192\",\"timestamp\":1542640715827.7,\"type\":\"outbound-rtp\",\"ssrc\":1152639192,\"isRemote\":false,\"mediaType\":\"video\",\"kind\":\"video\",\"trackId\":\"RTCMediaStreamTrack_sender_4\",\"transportId\":\"RTCTransport_0_1\",\"codecId\":\"RTCCodec_3_Outbound_96\",\"firCount\":0,\"pliCount\":2,\"nackCount\":0,\"qpSum\":1378,\"packetsSent\":51,\"bytesSent\":37650,\"framesEncoded\":13}"
With Plan B works properly.
,
Nov 20
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 20
guidou@ to take a look and see if he can reproduce.
,
Nov 20
I have the pcap file for browserA with the traffic during the execution. If you decode as RTP the traffic and search by "udp.port == 17480 && rtp.ssrc == 2222271640" with wireshark, you can see how the media is arriving in through that ssrc.
,
Nov 20
Can you provide a URL where we can reproduce the issue, preferably a jsfiddle or similar? The list of steps in the attached text file is not easy to reproduce.
,
Nov 20
,
Nov 20
I'll try to create something. We detect the problem with our application and using our SFU.
,
Nov 20
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 20
I can't reproduce p2p, but if could activate any debug log in the console logs, I can run our case in our application and recollect them for you.
,
Nov 20
Could the problem be with the SFU? Note this line: a=msid:- 24f80a8a-cfb0-49a0-9183-86c8fa9b0155 We are no longer signaling track IDs because local and remote track IDs are not guaranteed to match. https://github.com/w3c/webrtc-pc/issues/2005 There's some ongoing discussion about legacy use cases expecting default streams. https://github.com/w3c/webrtc-pc/issues/2027
,
Nov 20
The point is, in other cases with this kind of line => a=msid:- 24f80a8a-cfb0-49a0-9183-86c8fa9b0155 ; All works properly. I've added one sdp offer with this kind of line and the remote rtc stats for the same msid. The msid is: 0568432a-22db-4b6b-8fb9-00be9e1d31df
,
Nov 20
the msid:- <trackid> is the special "no stream" stream id. Note that plan-b misinterprets this and fires onaddstream with the "default" mediastream. If you could try the SDP without a different stream id that will allow determining whether this is related to the lack of a stream or renegotiation.
,
Nov 21
Did you see the example where all works properly with a=msid:- 0568432a-22db-4b6b-8fb9-00be9e1d31df?
,
Nov 21
Could you try the same thing but with a stream for the sake of debugging? Instead of pc.addTrack(track); do pc.addTrack(track, new MediaStream());
,
Nov 21
Sure, I will try in our application, but in our case we use addTransceiver, but I'll add in the init object the stream associated. I'll tell you something.
,
Nov 21
I did the test and the result is the same. In the file, you can see a remote offer from Browser B, and the stats recover in Browser A, for Receivers. ssrc: 2258652874 msid: 3908118b-124d-415f-8e50-704c709ba04e And now the track has associated a stream. If you need more information, tell me.
,
Nov 21
We'll keep this bug open, but it is not actionable until we get repro steps that are relatively easy to reproduce. Since the problem does not reproduce in the peer-to-peer case, it is not clear if the problem is in Chrome or the server side.
,
Nov 21
> This entry doesn't have "trackId" associated and looks like it causes the media is not decoded by video tag So part of the problem is that video is not shown? This might be because -- with the - stream there is no mediastream in ontrack. You'll need to create one yourself in order to set srcObject. There might be an issue with the stats during renegotiaton. But without at least a webrtc-internals dump as a semi-standard format for understanding how the peerconnection is used that is hard to tell.
,
Nov 21
>So part of the problem is that video is not shown? This might be because -- with the - stream there is no mediastream in ontrack. You'll need to create one yourself in order to set srcObject. In other situations all works properly, with the same - stream situation. Can I activate any chrome debug logs? I'll try to recollect webrtc-internals dump.
,
Nov 21
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 21
Hi!, I've the webrtcdump for both browsers. Also I've added the pcap for each browser. The important file is BrowserA's pcap, where you can see how the SSRCs (audio/video) are receiving video according to the information of the sdp. In this case, browserA looks like doesn't receive media in these tracks: Audio: 5a460b87-6283-42fc-a3ec-8514b0d1c3b7 Video: 59b830db-4f11-42c8-900d-a77f15f49076 As I said before, we are using a SFU. Chrome-dev and unified-plan. If you need more information, tell me.
,
Nov 21
,
Nov 21
It sounds to be like Browser <-> Browser works, but Browser <-> SFU <-> Browser doesn't. The logs show that bytes are sent but not received, but there isn't much to go on on our end. There could be a problem with the SFU?
,
Nov 21
hbos: I wonder why the dumps show only a signaling state of stable... raulbenitezmejias: I think you mixed up A and B? So in browser A you are doing renegotiation going from two m-lines which are inactive to two inactive and two where the other side says a=recvonly in the second SDP. That side is sending data. In browserB you have a=sendrecv and a=ssrc: lines. No data is received there however according to the ssrc stats. One can see that around 1.9mbps are received however. Are we on the same page so far? If so this might be a problem with demuxing -- either the wrong ssrc or the sdes:mid extension interferes somehow.
,
Nov 22
philippe: You are right, I mixed up A and B, sorry. And your resume about m lines is correct. But the browserA_PCAP.pcap is correct. After decode as RTP the packages, I've filtered by "udp.port == 13396 && rtp.ssrc == 2168458171" And the result is in the image. So, the media is arriving in that SSRC.
,
Nov 22
And about sdes:mid, I will review again.
,
Nov 22
right, the pcap looks good. Steve: can you advise what logs would be needed to figure out why demultiplexing does not work? I checked the pcap and it doesn't contain the sdes:mid header extension so ssrc demuxing should be used.
,
Nov 22
Hello every body!!
Raul and I have been working together in order to figure out what is happening.
I would like to expose the "debugging state" (where we have reached).
Our first assumption was that the problem was in our SFU, but after digging into it we didn't find anything regarding:
SDP signaling: everything regarding m-lines direction,
ICE, DTLS, SSRC PT, a=mid, a=msid, a=ssrc, seems to be correct.
Next is the m-line related to the unexpected track behavior:
sdp: v=0
o=- 3751805050 3751805051 IN IP4 0.0.0.0
...
m=video 1 UDP/TLS/RTP/SAVPF 127
c=IN IP4 0.0.0.0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtpmap:127 H264/90000
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtcp:9 IN IP4 0.0.0.0
a=rtcp-mux
a=mid:video0
a=setup:actpass
a=sendrecv
a=msid:0NNIsEXKlshmfeF9b54cGg7Dzht3lEWpB3es 59b830db-4f11-42c8-900d-a77f15f49076
a=ssrc:2168458171 cname:user488204020@host-906169bd
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 ccm fir
a=ice-ufrag:vJVx
a=ice-pwd:LAuXvyhR7z+qZ2WdSzRAPV
a=candidate:2 1 UDP 2013266430 34.229.97.224 13396 typ host
a=candidate:2 2 UDP 2013266429 34.229.97.224 16775 typ host
a=fingerprint:sha-256 36:01:2D:28:1C:05:44:34:48:9B:63:9B:D1:13:8C:0F:1D:C0:6C:54:09:98:27:4F:D3:CA:80:2A:84:DE:03:63
...
Media: the expected RTP packets are received by the BrowserB host in the
expected ICE port as we can see in the PCAP provided by Raul,
fully matching with the signaled in the SDP:
src port: 13396
dst port: 42480
RTP SSRC: 2168458171 (0x81400BBB)
RTP PT: 127
Please notice that our SFU does not support RTP sdes:mid yet,
so SSRC demuxing should be used, as @philippe has pointed out.
In addition I think the next info is useful for detecting where is exactly the problem:
- It seems that it does not depends on the codec, as it is failing with VP8, H264 and OPUS.
- We have tested several scenarios with UnfiedPlan and renegotiations (adding and removing tracks) and they properly work.
From this analysis I totally agree with @philippe and I guess there might be a bug in the demuxing logic at Chrome side.
If you need more info from our side, please let us know ;).
,
Nov 22
Assigning to steveanton@ for follow-up on demuxing or to help in further triaging.
,
Nov 22
Only an hypothesis to help: Could be a problem regarding early media (as it is a renegotiation and the ICE transport is already established)? Specifically, a race condition where the media arrives before the SDP or something like that?
,
Nov 22
what supports the hypothesis from #32 is that the first reports show the ssrc stats without a track id. Servers shouldn't be sending media for a m-line before the answer (this is somewhat different in plan-b and i recall firefox crashing because of such issues). Even in that case it should work (tm)
,
Nov 26
,
Nov 27
The lack of track ID I believe indicates that the stream is being created as an "unsignaled SSRC" stream. Could you please capture and attach WebRTC text logs from the start of the call to when the media starts flowing? https://webrtc.org/native-code/logging/
,
Nov 27
Sure, @steveanton
,
Nov 27
In this case, Browser A doesn't receive media through this track: 1c05e41a-5184-47cf-b064-ae05d9b5035e but the SSRC (1912839464) is receiving media In the RtcStats doesn't appear information about this.
,
Nov 27
I've added browserB log too
,
Nov 28
Thanks for the logs -- that helped a lot. I think the issue is that the WebRTC code that looked up track IDs was not updated for Unified Plan so it just looked at the first audio and first video sections. In this example the SSRCs are in the second audio and second video sections. I've written up a fix and will let you know when it lands in canary so you can try it to confirm.
,
Nov 28
Great! I'll wait for that patch with desire Regards
,
Nov 28
Hello @steveanton!! First of all thank you for debugging the issue :D. If I properly understand you, the issue would affect any case using more than one m-line per media type, doesn't it? The point is that this case sometimes works OK, and we have more tests having several m-lines which work fine.
,
Nov 28
Give the bug, with multiple m= sections you'd still get stats if the track of interest happens to be the first m= section.
,
Nov 28
Hello @hbos!! The point is that it also (sometimes) works for tracks of interest happening to be non the first m-lines. Because of that I guess there should be another problem apart of what @steveanton commented :S.
,
Nov 28
It think there are two issues here: 1) the stats issue. As far as I can see this only affects legacy stats (used in webrtc-internals). This is pretty easy to reproduce reliably by adding another video track e.g. from getDisplayMedia to https://webrtc.github.io/samples/src/content/peerconnection/pc1/ -- the second video m-line in webrtc-internals will have no track. (hint: this is a QA-able change :-)) 2) if media is received before signaling this gets treated as unsignaled. That might be possible to reproduce p2p if you do some funky stuff like negotiating, then adding a second video track and *not* set the remote description
,
Nov 28
I guess @philipp is right. Regarding (1), we are not using legacy stats, because of that it is working for us in some cases. In relation to (2), I think it is the problem we are experienced as we commented before. Another way to force it in in p2p keeping the same behavior could be just using sleep() before applying the 2nd offer which signals new track added.
,
Nov 28
I think I have a good repro. STR: 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.
,
Nov 28
The following revision refers to this bug: https://webrtc.googlesource.com/src.git/+/a41959e550925f09e6b2cc29c044f088d81e6932 commit a41959e550925f09e6b2cc29c044f088d81e6932 Author: Steve Anton <steveanton@webrtc.org> Date: Wed Nov 28 20:22:10 2018 [Unified Plan] Fix old GetStats() not associating track id The method for looking up track ID by SSRC was never updated for Unified Plan so it only looked at the first audio section and the first video section. This CL changes the method to look through all audio and video media sections rather than just the first. Bug: chromium:906988 Change-Id: Ie79e6162b2bd24b8ac9e983b5fa7360c96f030da Reviewed-on: https://webrtc-review.googlesource.com/c/112223 Commit-Queue: Steve Anton <steveanton@webrtc.org> Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Seth Hampson <shampson@webrtc.org> Cr-Commit-Position: refs/heads/master@{#25833} [modify] https://crrev.com/a41959e550925f09e6b2cc29c044f088d81e6932/pc/peerconnection.cc [modify] https://crrev.com/a41959e550925f09e6b2cc29c044f088d81e6932/pc/peerconnection.h [modify] https://crrev.com/a41959e550925f09e6b2cc29c044f088d81e6932/pc/peerconnection_integrationtest.cc [modify] https://crrev.com/a41959e550925f09e6b2cc29c044f088d81e6932/pc/peerconnectioninternal.h [modify] https://crrev.com/a41959e550925f09e6b2cc29c044f088d81e6932/pc/statscollector.cc [modify] https://crrev.com/a41959e550925f09e6b2cc29c044f088d81e6932/pc/statscollector.h [modify] https://crrev.com/a41959e550925f09e6b2cc29c044f088d81e6932/pc/test/fakepeerconnectionbase.h [modify] https://crrev.com/a41959e550925f09e6b2cc29c044f088d81e6932/pc/test/fakepeerconnectionforstats.h [modify] https://crrev.com/a41959e550925f09e6b2cc29c044f088d81e6932/pc/test/mockpeerconnectionobservers.h
,
Nov 30
Is this fixed now?
,
Nov 30
there is still the "associating stuff doesn't work" from #46?
,
Dec 2
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a4fc95699a752eb1f14d7e83f47e462cd6f242fc commit a4fc95699a752eb1f14d7e83f47e462cd6f242fc Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com> Date: Sun Dec 02 16:22:36 2018 Roll src/third_party/webrtc 0cc11b4b947e..21d8b181f663 (47 commits) https://webrtc.googlesource.com/src.git/+log/0cc11b4b947e..21d8b181f663 git log 0cc11b4b947e..21d8b181f663 --date=short --no-merges --format='%ad %ae %s' 2018-12-02 kwiberg@webrtc.org Remove some unused forward declarations 2018-12-01 zstein@webrtc.org Add transaction id to candidate pair event log parser and encoder. 2018-12-01 zstein@webrtc.org Log DTLS writable changes to RtcEventLog 2018-12-01 benwright@webrtc.org Add BufferedFrameDecryptor to cleanly deal with receiving encrypted frames. 2018-12-01 qingsi@webrtc.org Revert "Fix output period in RtcEventLogImpl" 2018-11-30 magjed@webrtc.org Android: Add constant for native EGL NO_CONTEXT 2018-11-30 zstein@webrtc.org Reland "Add transaction id to CandidatePairEvents." 2018-11-30 chromium-webrtc-autoroll@webrtc-ci.iam.gserviceaccount.com Roll chromium_revision 173a384b25..3546854f59 (612554:612694) 2018-11-30 ouj@fb.com Parse `ice_unwritable_timeout` and `ice_unwritable_min_checks` from RTCConfiguration into IceConfig 2018-11-30 steveanton@webrtc.org Add integration test for new GetStats() with many tracks 2018-11-30 eladalon@webrtc.org Fix output period in RtcEventLogImpl 2018-11-30 sprang@webrtc.org Remove deprecated VideoEncoder metadata methods 2018-11-30 mirtad@webrtc.org Add metadata from VideoEncoderFactory::CodecInfo to VideoEncoder::EncoderInfo 2018-11-30 nisse@webrtc.org Move implementation of LoopbackMediaTransport to .cc file 2018-11-30 srte@webrtc.org Fixes DCHECK bug in LinkCapacityEstimator. 2018-11-30 srte@webrtc.org Friendlier error messages from data unit classes. 2018-11-30 sprang@webrtc.org Revert "Add transaction id to CandidatePairEvents." 2018-11-30 chromium-webrtc-autoroll@webrtc-ci.iam.gserviceaccount.com Roll chromium_revision 77dd2659f0..173a384b25 (612445:612554) 2018-11-30 braveyao@webrtc.org desktop_capture: apply scale to cursor relative positon on Mac only 2018-11-30 chromium-webrtc-autoroll@webrtc-ci.iam.gserviceaccount.com Roll chromium_revision d6514607ce..77dd2659f0 (612330:612445) 2018-11-29 zstein@webrtc.org Add transaction id to CandidatePairEvents. 2018-11-29 chromium-webrtc-autoroll@webrtc-ci.iam.gserviceaccount.com Roll chromium_revision 0a7ee90062..d6514607ce (612216:612330) 2018-11-29 srte@webrtc.org Extracts LinkCapacityEstimator from AimdRateControl. 2018-11-29 sprang@webrtc.org Cap probing bitrate to max total allocated bitrate 2018-11-29 crodbro@webrtc.org Unittests for loss based bandwidth estimation. 2018-11-29 chromium-webrtc-autoroll@webrtc-ci.iam.gserviceaccount.com Roll chromium_revision f85d2e4da0..0a7ee90062 (612092:612216) 2018-11-29 phoglund@webrtc.org Revert "Various VP9 high fps fixes" 2018-11-29 phoglund@webrtc.org Try UWP with msvc. 2018-11-29 sprang@webrtc.org Make simulcast screenshare default-on 2018-11-29 nisse@webrtc.org Delete method EncodedFrame::GetBitstream, part 2 2018-11-29 nisse@webrtc.org Move size() method to EncodedImage base class 2018-11-29 phoglund@webrtc.org Disable goma for uwp bots. 2018-11-29 chromium-webrtc-autoroll@webrtc-ci.iam.gserviceaccount.com Roll chromium_revision 2f5059a4ae..f85d2e4da0 (611832:612092) 2018-11-29 phoglund@webrtc.org Add Win UWP bots. 2018-11-28 chromium-webrtc-autoroll@webrtc-ci.iam.gserviceaccount.com Roll chromium_revision 28d6168850..2f5059a4ae (611644:611832) 2018-11-28 steveanton@webrtc.org [Unified Plan] Fix old GetStats() not associating track id 2018-11-28 zstein@webrtc.org Log DTLS state changes to RtcEventLog 2018-11-28 hta@webrtc.org Add API for returning a webrtc::DtlsTransport for a MID on a PC 2018-11-28 yvesg@webrtc.org [Cleanup] Add missing #include. Remove useless ones. IWYU part 2. 2018-11-28 oprypin@webrtc.org Add new names of perf bots that will be migrated to LUCI 2018-11-28 ssilkin@webrtc.org Keep bitrate constraints. 2018-11-28 artit@webrtc.org Reland "Run robolectric tests for Android on several Android API versions" 2018-11-28 nisse@webrtc.org Add video support to LoopbackMediaTransport 2018-11-28 nisse@webrtc.org Delete ssrc book-keeping in NetEq 2018-11-28 andersc@webrtc.org React to changes in either width or height in iOS Metal renderer. 2018-11-28 sakal@webrtc.org Add missing files to AAR. 2018-11-28 nisse@webrtc.org Delete method EncodedFrame::GetBitstream, part 1 Created with: gclient setdep -r src/third_party/webrtc@21d8b181f663 The AutoRoll server is located here: https://autoroll.skia.org/r/webrtc-chromium-autoroll Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, please contact the current sheriff, who should be CC'd on the roll, and stop the roller if necessary. CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux_chromium_archive_rel_ng;luci.chromium.try:mac_chromium_archive_rel_ng BUG=chromium:None,chromium:None,chromium:None,chromium:None,chromium:909784,chromium:None,chromium:None,chromium:none,chromium:None,chromium:690537,chromium:None,chromium:None,chromium:906988,chromium:907849,chromium:908001 TBR=webrtc-chromium-sheriffs-robots@google.com Change-Id: Ia2a0ebb98aeece46ef99b2c5f9e622f088ba3822 Reviewed-on: https://chromium-review.googlesource.com/c/1357892 Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com> Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#612977} [modify] https://crrev.com/a4fc95699a752eb1f14d7e83f47e462cd6f242fc/DEPS
,
Dec 3
The NextAction date has arrived: 2018-12-03
,
Dec 3
Did the stats fix not make the cut? Do we need to back-merge?
,
Dec 3
No, it did not make the cut and will need a merge to M72. I think we need to wait for it to roll to canary first, and it doesn't look like it has done so yet: https://chromiumdash.appspot.com/commit/a4fc95699a752eb1f14d7e83f47e462cd6f242fc
,
Dec 5
The NextAction date has arrived: 2018-12-05
,
Dec 6
Requesting merge of WebRTC commit a41959e550925f09e6b2cc29c044f088d81e6932 to M72. It should have landed in the first M73 canaries.
,
Dec 6
This bug requires manual review: DEPS changes referenced in bugdroid comments. Please contact the milestone owner if you have questions. Owners: govind@(Android), kariahda@(iOS), djmm@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 6
steveanton@ Is this change verified in canary ? Can you also confirm which version of canary this was part of. How risky is this change and how confident are you that this does not cause other regressions.
,
Dec 6
Commit a4fc9569... initially landed in 73.0.3630.0
Validated with the attached page.
In Version 71.0.3578.80 the console has:
stats[12] is type 'ssrc' with googTrackId = '6243ddf8-b8a9-402c-b8ae-3fb20b3a0ed1'
stats[13] is type 'ssrc' with googTrackId = ''
stats[14] is type 'ssrc' with googTrackId = '364376ad-6d22-48ec-80f3-d5b32ad634db'
stats[15] is type 'ssrc' with googTrackId = ''
In Version 73.0.3633.0 (Developer Build) the console has:
stats[12] is type 'ssrc' with googTrackId = 'e4ab88d9-c9d3-479e-85c9-d2c0f4585580'
stats[13] is type 'ssrc' with googTrackId = 'fe6e2981-dac0-4c12-aee1-fc3c26d44c9e'
stats[14] is type 'ssrc' with googTrackId = '5584664a-6443-44c4-9fa6-6258a14f4545'
stats[15] is type 'ssrc' with googTrackId = 'd9ade00f-b080-4738-800b-e086fb5ce42f'
The change should be low risk since it only affects one field of the old getStats() API and only when running with {sdpSemantics: 'unified-plan'}.
,
Dec 7
Approving the merge for 72.0 . Branch 3626.
,
Dec 10
This was merged on Dec 7, not sure why it doesn't show on this bug: https://webrtc-review.googlesource.com/q/Ie79e6162b2bd24b8ac9e983b5fa7360c96f030da
,
Dec 10
See https://crbug.com/913384 for remaining issues about "unannounced streams are not played". This bug is about the status of the missing stats.
,
Dec 11
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 11
,
Dec 20
The following revision refers to this bug: https://webrtc.googlesource.com/src.git/+/54fa02486a7c67dacd7c745f05882f945220866c commit 54fa02486a7c67dacd7c745f05882f945220866c Author: Seth Hampson <shampson@webrtc.org> Date: Thu Dec 20 00:54:52 2018 Removed log from StatsCollector::GetTrackIdBySsrc. Bug: chromium:906988 Change-Id: I353db16687e66c265a6121ee24e6353971d7884e Reviewed-on: https://webrtc-review.googlesource.com/c/115120 Reviewed-by: Steve Anton <steveanton@webrtc.org> Reviewed-by: Seth Hampson <shampson@webrtc.org> Commit-Queue: Steve Anton <steveanton@webrtc.org> Cr-Commit-Position: refs/heads/master@{#26064} [modify] https://crrev.com/54fa02486a7c67dacd7c745f05882f945220866c/pc/statscollector.cc
,
Dec 20
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/947a70c1735706f398d8bc081640222ad4483232 commit 947a70c1735706f398d8bc081640222ad4483232 Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com> Date: Thu Dec 20 05:11:30 2018 Roll src/third_party/webrtc b27578801673..54fa02486a7c (2 commits) https://webrtc.googlesource.com/src.git/+log/b27578801673..54fa02486a7c git log b27578801673..54fa02486a7c --date=short --no-merges --format='%ad %ae %s' 2018-12-20 shampson@webrtc.org Removed log from StatsCollector::GetTrackIdBySsrc. 2018-12-20 steveanton@webrtc.org Fail SetLocalDescription if a=mid lines are missing Created with: gclient setdep -r src/third_party/webrtc@54fa02486a7c The AutoRoll server is located here: https://autoroll.skia.org/r/webrtc-chromium-autoroll Documentation for the AutoRoller is here: https://skia.googlesource.com/buildbot/+/master/autoroll/README.md If the roll is causing failures, please contact the current sheriff, who should be CC'd on the roll, and stop the roller if necessary. CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux_chromium_archive_rel_ng;luci.chromium.try:mac_chromium_archive_rel_ng BUG= chromium:906988 TBR=webrtc-chromium-sheriffs-robots@google.com Change-Id: I4b87a0b17a91c827ffde3cfcea924147fa9e03c3 Reviewed-on: https://chromium-review.googlesource.com/c/1385591 Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com> Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com> Cr-Commit-Position: refs/heads/master@{#618115} [modify] https://crrev.com/947a70c1735706f398d8bc081640222ad4483232/DEPS |
||||||||||||||||||||||||||||||||||||||||||||
►
Sign in to add a comment |
||||||||||||||||||||||||||||||||||||||||||||
Comment 1 by blum@chromium.org
, Nov 20Labels: -Pri-3 Pri-2
Owner: hbos@chromium.org