- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Tue, 15 Nov 2022 10:14:54 +0000
- To: public-webrtc@w3.org
henbos has just created a new issue for https://github.com/w3c/webrtc-stats: == Clarify media-source frame rates (frames and framesPerSecond) == RTCVideoSourceStats contains [frame counters](https://w3c.github.io/webrtc-stats/#videosourcestats-dict*) as "frames originating from this source". But the spec is not clear about which point in the pipeline this is measured. If you measure this as early to camera capture as possible you may see more frames than if you measure this at the entry to WebRTC in rare cases such as running out of frame buffers or other errors causing us to drop frames. We should clarify the spec to say that... 1. These are the frames that have reached WebRTC. E.g. the delta between this input fps and the encoder fps would be frames that have been dropped by the webrtc encoder, not frames that were dropped between capture process and renderer process etc. This matches what libwertc is already doing. 2. Clarify that these are the frames prior to adaptation. Adaptation is an encoder implementation detail, so frames dropped due to adaptation should be part of the delta between input fps and encoder fps. libwebrtc has a [known bug](https://bugs.chromium.org/p/webrtc/issues/detail?id=12501) where we count the frames after adaptation, but this is wrong since it exposes an implementation detail that does not make sense on paper Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/708 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 15 November 2022 10:14:56 UTC