[Triage] Stefan: Is pri 2 correct? I guess adding this would fall on the video folks, can you or Magnus find an owner?

I think this is a bug that must have been introduced in webrtc-internals. googFrameWidthInput has been visualized on that page before, but has disappeared. It's still reported at the video layers.

It would be good to get back in there as it's now more difficult to debug issues related with capturing in incorrect resolutions.

This should not be on the audio team, I believe.
Reassigning to mflodman@ for further triaging.

Henrik, can you look into what happened here?

Can you take a look hta?

This is a goog stats, so it shouldn't be in the new stats. What was it supposed to represent?

The OLD stats show:
- googFrameWidthReceived for incoming tracks (called "SSRC" in old stats)
- googFrameWidthSent for outgoing tracks

So it seems that it's not shown to Javascript, at least.

The webrtc-internals page looks as if it's displaying a graph for everything that looks like a number and isn't on a specific blacklist. So if it was generated, it should have been there.

The name is still present in the WebRTC codebase.

Lowering to P3, as 1) it doesn't seem to be urgent, and 2) we should be aligning webrtc-internals to the new stats anyway.

Holmer, if you want this stat (whatever it means) in the new stats, please raise an issue against the spec describing what it is and why you think it's useful.

https://github.com/w3c/webrtc-stats

 Issue 463916  has been merged into this issue.

It's useful to have the input width/height to know what resolution the capturer provided to the PC, so we can differentiate between PC problems causing low res and capturer problems causing low res when we get big reports. 

I filed this bug since it had disappeared and I missed it when I was debugging something, so I suspect it might be needed in the future.

Is this something that I still should file a spec bug on?

I think you should file a spec bug. It won't come into the new stats without a spec bug, and we're encouraging people to plan on using the new stats in the future.

(At the moment webrtc-internals is generated from the old stats. That will change sooner or later, too.)

Also see https://bugs.chromium.org/p/webrtc/issues/detail?id=9234. Apps such as Hangouts meet could use these to tell if there's something wrong in the capturing phase, for the lack of a better signal, and to debug adaptation / video resolution problems as it has had happened before.

qaz, please explain why it's now urgent.
Stefan, have you filed a spec bug for this?

Sorry, forgot to mention that I bumped it up since this was a regression.

the oldest version I have is M59 which is not having it. It was probably still in stable when I wrote https://testrtc.com/webrtc-internals-parameters/ in December 2016.

Original report was from October, so it's been 6 months at least.
Dumping priority back down to 3, since so few people noticed.

Where do I file a spec bug?

I think this becomes urgent whenever someone needs to investigate bugs that can be capture related, and needs to determine if frames are scaled down in the capturer or in the encoder layer. Without this stat it's hard. We may not hit those bugs often, but when we do this is problematic.

Stats spec issues: https://github.com/w3c/webrtc-stats/issues
See also (public) guidelines doc: https://docs.google.com/document/d/1q1CJVUqJ6YW9NNRc0tENkLNny8AHrKZfqjy3SL89zjc/edit?usp=sharing.

Seems like it should be straightforward to make the case for this in the new stats.