Update Stats #85
Comments
w3c#59 -Fixes for error handling, as described in Issue 75 w3c#75 - Fixes for miscellaneous NITs, as described in Issue 76 w3c#76 - Enable retrieval of the SSRC to be used by RTCP, as described in Issue 77 w3c#77 - Support for retrieval of audio and video capabilities, as described in Issue 81 w3c#81 - getStats interface updated, as described in Issue 82 w3c#82 - Partially addressed SVC issues described in Issue 83 w3c#83 - Partially addressed statistics update issues described in Issue 85 w3c#85
|
Progress on this issue is awaiting the next WebRTC 1.0 API revision, which will presumably include a revised stats API section |
|
Version 3 revision from Harald: |
|
Note that there are a number of definitions in the Stats proposal that look like they can be reconciled with existing objects: enum RTCStatsIceCandidateType { dictionary RTCIceCandidate : RTCStats { dictionary RTCCodec : RTCStats { dictionary RTCCertificateStats : RTCStats { |
…3c#66 Added Identity support, as described in Issue w3c#78 Reworked getStats method, as described in Issue w3c#85 Removed ICE restart method described in Issue w3c#93 Addressed CNAME and synchronization context issues described in Issue w3c#94 Fixed WebIDL issues noted in Issue w3c#97 Addressed NITs described in Issue w3c#99 DTLS transport issues fixed as described in Issue w3c#100 ICE transport issues fixed as described in Issue w3c#101 ICE transport controller fixes made as described in Issue w3c#102 Sender and Receiver object fixes made as described in Issue w3c#103 Fixed RTCRtpEncodingParameter default issues described in Issue w3c#104 Fixed 'Big Picture' issues descibed in Issue w3c#105 Fixed RTCRtpParameter default issues described in Issue w3c#106 Added a multi-stream capability, as noted in Issue w3c#108 Removed quality scalability capabilities and parameters, as described in Issue w3c#109 Added scalability examples as requested in Issue w3c#110 Addressed WebRTC 1.0 Data Channel compatibility issue described in Issue w3c#111 Removed header extensions from RTCRtpCodecParameters as described in Issue w3c#113 Addressed RTP/RTCP non-mux issues with IdP as described in Issue w3c#114 Added getParameter methods to RTCRtpSender and RTCRtpReceiver objects, as described in Issue w3c#116 Added layering diagrams as requested in Issue w3c#117 Added a typedef for payload type, as described in Issue w3c#118 Moved onerror from the RTCIceTransport object to the RTCIceListener object as described in Issue w3c#121 Added explanation of Voice Activity Detection (VAD), responding to Issue w3c#129 Clarified the meaning of maxTemporalLayers and maxSpatialLayers, as noted in Issue w3c#130 Added RFC 6051 to the list of header extensions and removed RFC 5450, as noted in Issue w3c#131 Addressed ICE terminology issues, as described in Issue w3c#132 Separated references into Normative and Informative, as noted in Issue w3c#133
|
Harald and Varun have now prepared a separate stats draft in W3C format (see below), which will be progressed as a separate W3C document. This raises the question of what we should be doing in the ORTC API specification to ensure compatibility with this effort. Section 13 currently in the ORTC API spec incorporates material from an earlier version of Harald & Varun’s document. With the move to a separate stats document, one question of whether much of Section 13 has been “overtaken by events” and should be removed, or whether it makes more sense to sync with a revised Stats Section in WebRTC 1.0 which may appear in a forthcoming editor’s draft.
|
|
IMO, 13.4 onwards could be removed, but 13.1-13.3 is the WEBIDL and needs to be part of ORTC. Assuming we will move 5.1 and 5.2 from webrtc-stats to webrtc-pc. |
|
Am working on the assumption that 13.1-13.3 (getStats(), RTCStatsReport, and RTCStats) will remain, the enumeration will point to individual sections of webrtc-stats, and that 13.4 will be removed. We should talk about statistics relating to SVC (particularly for SST-SS where RTCP reporting would not break down loss by layer). Here is the proposed text for Section 13.3.2: 13.3.2 enum RTCStatsType enum RTCStatsType { inboundrtp outboundrtp session track transport candidatepair localcandidate remotecandidate |
I believe the stats are reported on the candidate pair, meanwhile the local and remote candidates expose the attributes. |
#48 Update to the Statistics API, reflecting: #85 Update on 'automatic' use of scalable video coding, as noted in: #156 Update to the H.264 parameters, as noted in: #158 Update to the 'Big Picture', as noted in: #159 Added support for maxptime, as noted in: #160 Changed 'RTCIceTransportEvent' to 'RTCIceGathererEvent' as noted in: #161 Update to RTCRtpUnhandledEvent as noted in: #163 Added support for RTCIceGatherer.state as noted in: #164 Revised the text relating to RTCIceTransport.start() as noted in: #166 Added text relating to DTLS interoperability with WebRTC 1.0, as noted in: #167 Revised the text relating to RTCDtlsTransport.start() as noted in: #168 Clarified handling of incoming connectivity checks by the RTCIceGatherer as noted in: #170 Added a reference to the ICE consent specification, as noted in: #171
|
The Statistics API document has been updated at http://www.w3.org/TR/webrtc-stats/. Here is a proposed update to Section 13 to sync up with the changes. Statistics API interface RTCStatsProvider { 13.1 Methods getStats When the getStats() method is invoked, the user agent must queue a task to run the following steps: For RTCDtlsTransport.getStats(), check whether RTCDtlsTransport.start() has been called; if not, throw an InvalidStateError exception. For RTCIceTransport.getStats(), check whether RTCIceTransport.start() has been called; if not, or if RTCIceTransport.stop() has been called, throw an InvalidStateError exception. For RTCRtpSender.getStats(), check whether RTCRtpSender.send(parameters) has been called; if not, or if parameters.encodings[j].active has a value of false, throw an InvalidStateError exception. For RTCRtpReceiver.getStats(), check whether RTCRtpReceiver.receive(parameters) has been called; if not, or if parameters.encodings[j].active has a value of false, throw an InvalidStateError exception. Return, but continue the following steps in the background. Start gathering the stats. When the relevant stats have been gathered, return a new RTCStatsReport object, representing the gathered stats. No parameters. The getStats() method delivers a successful result in the form of a RTCStatsReport object. A RTCStatsReport object represents a map between strings, identifying the inspected objects (RTCStats.id), and their corresponding RTCStats objects. An RTCStatsReport may be composed of several RTCStats objects, each reporting stats for one underlying object. One achieves the total for the object by summing over all stats of a certain type; for instance, if an RTCRtpSender object is sending RTP streams involving multiple SSRCs over the network, the RTCStatsReport may contain one RTCStats object per SSRC (which can be distinguished by the value of the ssrc stats attribute). interface RTCStatsReport { RTCStats The set of supported property names [WEBIDL] is defined as the ids of all the RTCStats objects that has been generated for this stats report. The order of the property names is left to the user agent. Parameter Type Nullable Optional Description An RTCStats dictionary represents the stats gathered by inspecting a specific object. The RTCStats dictionary is a base type that specifies as set of default attributes, such as timestamp and type. Specific stats are added by extending the RTCStats dictionary. Note that while stats names are standardized, any given implementation may be using experimental values or values not yet known to the Web application. Thus, applications must be prepared to deal with unknown stats. Statistics need to be synchronized with each other in order to yield reasonable values in computation; for instance, if "bytesSent" and "packetsSent" are both reported, they both need to be reported over the same interval, so that "average packet size" can be computed as "bytes / packets" - if the intervals are different, this will yield errors. Thus implementations must return synchronized values for all stats in a RTCStats object. dictionary RTCStats { id of type DOMString timestamp of type DOMHiResTimeStamp type of type RTCStatsType The type attribute must be initialized to the name of the most specific type this RTCStats dictionary represents. 13.3.2 enum RTCStatsType enum RTCStatsType { Statistics for the inbound RTP stream. It is accessed via the RTCInboundRTPStreamStats defined in [WEBRTC-STATS] Section 4.2.3. Local inbound RTP statistics can be obtained from the RTCRtpReceiver object; remote inbound RTP statistics can be obtained from the RTCRtpSender object. outboundrtp session datachannel track Statistics relating to the MediaStreamTrack object. It is accessed via the RTCMediaStreamTrackStats defined in [WEBRTC-STATS] Section 4.4.2. transport Transport statistics related to the RTCDtlsTransport object. It is accessed via the RTCTransportStats and RTCCertificateStats defined in [WEBRTC-STATS] Sections 4.6 and 4.9. candidatepair ICE candidate pair statistics related to RTCIceTransport objects. It is accessed via the RTCIceCandidatePairStats defined in [WEBRTC-STATS] Section 4.8. localcandidate ICE local candidates, related to RTCIceGatherer objects. It is accessed via the RTCIceCandidateAttributes defined in [WEBRTC-STATS] Section 4.7. remotecandidate C. References C.1 Normative references [WEBRTC-STATS] |
Update the Stats with Harald's latest proposal: https://www.w3.org/2011/04/webrtc/wiki/Stats
The text was updated successfully, but these errors were encountered: