W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > June 2019

[webrtc-stats] We should move RTCCodecStats.implementation to RTC[In/Out]boundRtpStreamStats (#445)

From: henbos via GitHub <sysbot+gh@w3.org>
Date: Thu, 13 Jun 2019 10:11:47 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issues.opened-455653631-1560420705-sysbot+gh@w3.org>
henbos has just created a new issue for https://github.com/w3c/webrtc-stats:

== We should move RTCCodecStats.implementation to RTC[In/Out]boundRtpStreamStats ==
The set of codec objects is a list based on capabilities and what is negotiated in the SDP.
Which encoder is instantiated for a given codec could theoretically be different for different RTP streams, and is a decision that could be made on-the-fly. When we create codec objects we don't know the implementation. In Chrome, one could start with a HW encoder, but then due to HW encoder errors, it falls back on the fly to a SW implementation.

The current state of the spec is unable to express codecs with multiple implementations, since they are tightly coupled with the SDP, which says nothing about implementation.

The list of codec objects is already huge, I propose we do not duplicate every codec object to have a "implementation: SW" and "implementation: HW" version of the same thing.

To minimize bloat, and to make implementation simpler (at least for Chrome that already has a googCodecImplementation), I propose we move "RTCCodecStats.implementation" to "RTC[In/Out]boundRtpStreamStats.codecImplementation" (or encoderImplementation/decoderImplementation).

This would make shipping "implementation" in Chrome require just a few lines of code, versus refactoring or special logic for the edge-case of implementation changing.

Please view or discuss this issue at https://github.com/w3c/webrtc-stats/issues/445 using your GitHub account
Received on Thursday, 13 June 2019 10:11:48 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 13 June 2019 10:11:49 UTC