- From: Sun Shin via GitHub <sysbot+gh@w3.org>
- Date: Fri, 03 Mar 2023 00:44:46 +0000
- To: public-webrtc-logs@w3.org
> Ah i see, can you say more about the kinds of cases that would cause `decoderFallback` to be true? I thought `decoderFallback` just meant "software renderer", which could be true for all sorts of persistant reasons (the device doesn't have relevant hardware, or the OS has been upgraded/ changed and so the hardware isn't supported, etc). Could you give some other examples of when `decoderFallback` would be true, and which would be temporary vs semi-persistant?
@pes10k Thanks you for the response. To share the transitions of this metric, it may look like following:
- In case of no HW Decoder: stays false
- In case of HW Decoder: starts with false and turns to true only when the decoder gets fallback get triggered and changes to false again when the decoder gets recovered to HW.
FYI, in case of the Chromium browser case, the fallback gets triggered by the following [reasons](https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/peerconnection/rtc_video_decoder_fallback_recorder.h;l=15;bpv=1;bpt=1):
```
enum class RTCVideoDecoderFallbackReason {
kSpatialLayers = 0,
kConsecutivePendingBufferOverflow = 1,
kReinitializationFailed = 2,
kPreviousErrorOnDecode = 3,
kPreviousErrorOnRegisterCallback = 4,
kConsecutivePendingBufferOverflowDuringInit = 5,
kMaxValue = kConsecutivePendingBufferOverflowDuringInit,
};
```
--
GitHub Notification of comment by xingri
Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/730#issuecomment-1452775979 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 3 March 2023 00:44:48 UTC