- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Tue, 23 Feb 2021 10:28:06 +0000
- To: public-webrtc@w3.org
henbos has just created a new issue for https://github.com/w3c/webrtc-stats: == media-source video resolution: Before or after adaptation? == Imagine we have a 720p MediaStreamTrack and a single encoded stream with scaleResolutionDownBy:2 which under perfect circumstances means we encode at 360p. Now imagine there is adaptation happening. In Chromium, we may adapt 720p before sending it to the encoders. So for example, 720p gets adapted down to 480p. Now because of scaleResolutionDownBy:2, what we actually encode is 240p. My understanding of the spec is that what getStats reports is: - media-source.width and height: This refers to the MediaStreamTrack resolution of 720p. - outbound-rtp.frameWidth and frameHeight: This refers to what we actually encode, i.e. 240p in the adapted case. On the Chromium implementation side, I don't know if... 1. media-source reports the MediaStreamTrack resolution (720p) or the adapted resolution (480p). I _think_ it reports 480p: if so, this is a bug, right? 2. Do we want a metric for the adapted resolution (480p)? If neither source or encoded stream is 480p I imagine we should not expose this metric, since it seems to be a Chromium implementation detail. That value could also be derived from encoded resolution * scaleResolutionDownBy if someone wants a scaling factor-intependent representation of "how adapted are we" Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/596 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 23 February 2021 10:28:07 UTC