New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 11 users

Issue metadata

Status: Assigned
NextAction: ----
OS: ----
Pri: 3
Type: Bug

issue chromium:611927
issue chromium:633550

Sign in to add a comment

getStats: switching the video codec resets the packetsSent/bytesSent counters on a ssrc report

Reported by, Dec 14 2015

Issue description

What steps will reproduce the problem?
1. go to
2. open chrome://webrtc-internals
3. go through the steps, wait a bit
4. go through the steps again, this time replacing "100 101" in the video m-line with "101 100" to change the video codec sent to VP9 before calling the "set answer" step

What is the expected result?
the packet and bytes sent counters increase

What do you see instead?
counters are reset. This confuses the bits per second graphs in webrtc-internals which display a large negative value.
    "ssrc_2475299415_send-bytesSent": {
     "startTime": "2015-12-13T23:52:51.765Z",
     "endTime": "2015-12-13T23:53:33.273Z",
     "values": "[0,0,70212,252632,456491,661645,876830,1092471,1309617,1525435,1731916,1954702,2172454,2386761,2601692,2816221,3034293,3254329,3467917,3686208,3897768,4115354,4330922,4548231,4762688,114900,303989,436511,648135,863374,1079430,1296051,1507127,1724484,1942912,2161616,2371500,2591954,2805493,3023302,3238067,3451133,3665782]"
    "ssrc_2475299415_send-packetsSent": {
     "startTime": "2015-12-13T23:52:51.765Z",
     "endTime": "2015-12-13T23:53:33.273Z",
     "values": "[0,0,68,238,427,617,814,1015,1217,1417,1605,1807,2007,2204,2402,2599,2800,3001,3198,3398,3594,3795,3994,4196,4394,108,283,403,596,797,999,1196,1392,1591,1792,1996,2191,2392,2589,2789,2986,3182,3378]"

What version of the product are you using? On what operating system?
chrome 48.0.2564.22

Please provide any additional information below.
I think the counters should increase and not be reset. @hta?
If not, webrtc-internals needs to deal with this negative delta in the number of bytes/packets sent.

Comment 1 by, Dec 14 2015

(a dump says more than 1000 words...)
344 KB View Download
Project Member

Comment 2 by, Dec 14 2015

Components: Stats
hta@, please help to comment!
Project Member

Comment 3 by, Dec 17 2015

This is clearly a bug. The SSRC counters should never be reset over the lifetime of the PC.

Comment 4 by, Jan 11 2016

hrm. I could have filed another bug but this is strongly related and/or the same root cause:
1) go to
2) make a call, have webrtc-internals open
3) restart ice, watch the # of packets on conn-audio-1-0 reset.

Comment 5 by, Jan 14 2016

While preparing to file another bug I noticed that actually the Conn-Audio-1-0 object seems (at least for the case of the ice restart in #4) moved to Conn-Audio-1-2, Conn-Audio-1-2 to Conn-Audio-1-4 etc.

Comment 6 by, Jan 14 2016

the behaviour in #4 actually makes sense and is likely unrelated to the bug. The Conn-audio-1-0 (type googComponent?) is essentially the spec RTCTransportStats -- so the packets/bytes here count the number of bytes and packets sent over that transport - which should be reset when the active transport changes even if the per-ssrc counter in the ssrc/RTPStreamStats keeps growing.

Comment 7 by, Jan 30 2016

I just saw another interesting effect of this. Importing the attached file with showed negative numbers for bitsSentPerSecond on Conn-sdpparta_0-1-1. In the dump this happens as well:
    "Conn-sdparta_0-1-1-bytesSent": {
     "startTime": "2016-01-30T16:38:13.273Z",
     "endTime": "2016-01-30T16:38:36.927Z",
     "values": "[930,0,0,88171,116434,0,0,0,317599,0,0,537055,605345,0,0,866480,981290,0,0,0,0,0,0,0,0]"
    "Conn-sdparta_0-1-1-bitsSentPerSecond": {
     "startTime": "2016-01-30T16:38:13.273Z",
     "endTime": "2016-01-30T16:38:36.927Z",
     "values": "[0,-7425.149700598802,0,705368,225878.1218781219,-932404.4044044045,0,0,2543335.335335335,-2540792,0,4296440,545774.2257742258,-4847607.607607608,0,6931840,906692.9911154985,-12285320.813771518,0,0,0,0,0,0,0]"
Looking a bit above that one can see that this correlates with googActiveConnection switching:
    "Conn-sdparta_0-1-1-googActiveConnection": {
     "startTime": "2016-01-30T16:38:13.273Z",
     "endTime": "2016-01-30T16:38:36.927Z",
     "values": "[true,false,false,true,true,false,false,false,true,false,false,true,true,false,false,true,true,false,false,false,false,false,false,false,false]"

This looks like the data source is switched while the label is kept (see also #5). I don't understand the rationale behind that.
223 KB View Download

Comment 8 by, May 20 2016

Blocking: chromium:611927
Project Member

Comment 9 by, May 20 2016

Components: Video
Status: Available (was: Unconfirmed)
Technical stuff/details to whoever does this:

These stats are fetched out of a VideoSendStream which contains bits sent etc. A VideoSendStream gets reset/recreated when a stream changes and is unaware of previous stats.

I think it would make sense to move storing of these stats to a transport-related object that doesn't change when sender settings changes. perkj@ is working on splitting the encoder and transport object, and bitrate-counter stats for instance would probably move there.

A workaround could be to store packets sent and bits sent for instance while recreating the object and then sum up these when gathering stats. That sounds like an ugly hack though. :)
Project Member

Comment 10 by, Jul 8 2016

perkj@ do you have any input based on #9?
It might make sense to have a central point in a PeerConnection / Call where stats are written to. 
Maybe we don't have to recreate a VideoSendStream once the encoder is split out into a separate object.

Comment 12 by, Jul 26 2016

#9: in addition it seems that receiving a FIR resets the packet loss counters. See the attached dump for ssrc_763629702_send on connection 8745-2.
877 KB View Download

Comment 13 by, Aug 30 2016

and another weird behaviour: packetsLost can drop to 0 (not constant; sometimes it is 1) and then recover to its previous value (or rather: the previous value plus roughly the amount of packets lost in the meantime)?!
Note that it recovers to the previous value after the BWE goes south and one second before the resolution adapts.

(note to self: raw log is at lo:lostdrop.json)
84.9 KB View Download
Project Member

Comment 14 by, Aug 31 2016


Comment 15 by, Sep 29 2016

Any update on this one? Would really appreciate a fix...
I just almost got a heart attack when I saw the same behaviour in Firefox. Turned out to be only on RTCP reports so I suspect this issue even spreads to remote systems... surprising this doesn't crash more!

Comment 17 by, Oct 3 2016

Blocking: chromium:633550
Just saw the following from hangouts in a webrtc-internals dump:

    "ssrc_4041506186_send-packetsLost": {
     "startTime": "2017-03-01T08:59:21.518Z",
     "endTime": "2017-03-01T09:01:40.152Z",
     "values": "[0,0,152,213,496,498,498,498,317,503,503,516,516,519,519,519,519,522,524,525,525,525,533,537,537,542,552,552,552,558,558,559,559,563,564,564,564,565,565,566,568,568,570,570,570,571,571,571,573,573,573,579,581,582,585,585,585,585,585,585,585,585,585,585,585,585,585,585,585,585,585,585,585,585,585,585,585,586,588,588,588,588,588,588,588,722,722,723,723,723,725,727,728,728,728,730,730,730,731,737,742,743,747,752,761,769,782,788,789,790,795,795,795,795,795,795,795,795,795,795,795,795,795,795,796,797,797,797,797,800,803,803,811,813,814,814,825,826,835,852]"
    "ssrc_4041506186_send-packetsSent": {
     "startTime": "2017-03-01T08:59:21.518Z",
     "endTime": "2017-03-01T09:01:40.152Z",
     "values": "[0,170,571,729,764,778,805,832,11,52,82,109,135,161,187,207,233,261,290,317,341,370,395,411,433,473,494,510,537,568,592,621,649,663,669,673,681,687,693,699,707,712,717,723,733,741,750,754,762,778,803,834,859,887,916,943,963,988,1016,1042,1069,1095,1119,1133,1157,1168,1203,1234,1262,1296,1334,1370,1409,1440,1473,1500,1526,1549,1578,1609,1637,1659,1683,1707,1731,1765,1798,1830,1856,1885,1911,1938,1949,1963,1987,2004,2012,2020,2030,2038,2052,2058,2076,2093,2123,2145,2174,2205,2219,2245,2271,2297,2317,2342,2366,2390,2413,2442,2467,2495,2516,2544,2572,2602,2628,2654,2678,2708,2733,2761,2792,2818,2835,2860,2886,2910,2933,2954,2984,3012]"

At a certain point in time packetsLost was higher than packetsSent. This is rather confusing and would indicate a bug in the server but given this bug... it was probably the client :-)

Project Member

Comment 19 by, Apr 5 2017

Project Member

Comment 20 by, Apr 5 2017

Labels: -Pri-2 Pri-3
Status: Assigned (was: Available)
Project Member

Comment 21 by, Apr 5 2017

munge-sdp sets descriptions using existing peer connections so one would indeed not expect packet counters to be reset.

Sign in to add a comment