From c604b93ed777bb7d3ee8f6059dec0b52155b79b9 Mon Sep 17 00:00:00 2001 From: Bernard Aboba Date: Fri, 12 Jul 2019 11:04:06 -0700 Subject: [PATCH] Apply fixes --- webrtc-stats.html | 58 ++++++++++++++++++++++++++--------------------- 1 file changed, 32 insertions(+), 26 deletions(-) diff --git a/webrtc-stats.html b/webrtc-stats.html index 519c37fd..83fdd6ad 100644 --- a/webrtc-stats.html +++ b/webrtc-stats.html @@ -213,7 +213,7 @@

  • An RTCStats object should correspond to an object defined in the specification it supports.
    • -
  • The object MUST define a new value in the "RTCStastType" enum, and MUST define the +
  • The object MUST define a new value in the RTCStatsType enum, and MUST define the syntax of the stats object it returns either by reference to an existing sub-dictionary of RTCStats or by defining a new sub-dictionary of RTCStats.
    • @@ -290,11 +290,12 @@

    appears in stats.

    - If a monitored object can only exist in a few instances over the lifetime of a - RTCPeerConnection, it may be simplest to consider it "eternal" and never delete it from the - set of objects reported on in stats. This type of object will remain visible until the - RTCPeerConnection is no longer available; it is also visible in getStats() after pc.close(). - This is the default when no lifetime is mentioned in its specification. + If a monitored object can only exist in a few instances over the lifetime of an + RTCPeerConnection, it may be simplest to consider it "eternal" and never + delete it from the set of objects reported on in stats. This type of object will + remain visible until the RTCPeerConnection is no longer available; it is + also visible in getStats() after pc.close(). This is the + default when no lifetime is mentioned in its specification.

    Objects that might exist in many instances over time should have a defined time at which @@ -308,9 +309,9 @@

    When a monitored object is deleted, a final stats object is produced, carrying the values current at the time of deletion. This object will be made available using the - statsended event on the associated RTCPeerConnection. This is important - in order to report consistently on short-lived objects and to be able to consistently - report totals over the lifetime of a RTCPeerConnection. + statsended event on the associated RTCPeerConnection. This is + important in order to report consistently on short-lived objects and to be able to + consistently report totals over the lifetime of an RTCPeerConnection.

    When an object is deleted, we can guarantee that no subsequent getStats() call will @@ -360,19 +361,23 @@

    defined set of stats object types including proposals for new standard types.

    - This document specifies the interoperable stats object types. Proposals for new object types may be made in the editors draft maintained on GitHub. New standard types may appear in future revisions of the W3C Recommendation. + This document specifies the interoperable stats object types. Proposals for new object + types may be made in the editors draft + maintained on GitHub. New standard types may appear in future revisions of the W3C + Recommendation.

    If a need for a new stats object type or stats value within a stats object is found, an - issue should be raised on Github, and a review process will decide on - whether the stat should be added to the editors draft or not. + issue should be raised on + Github, and a review process will decide on whether the stat should be added to the + editors draft or not.

    - A pull request for a change to the editors draft may serve as guidance for the discussion, - but the eventual merge is dependent on the review process. + A pull request for a change to the editors draft may serve as guidance for the + discussion, but the eventual merge is dependent on the review process.

    - While the WebRTC WG exist, it will serve as the review body; once it has disbanded, the + While the WebRTC WG exists, it will serve as the review body; once it has disbanded, the W3C will have to establish appropriate review.

    @@ -487,13 +492,13 @@

    When there are multiple RTP streams connected to the same sender, such as when using simulcast or RTX, there will be one - RTCOutboundRtpStreamStats per - RTP stream, with distinct values of the "ssrc" attribute, - and all these senders will have a reference to the same - "sender" object (of type RTCAudioSenderStats or + RTCOutboundRtpStreamStats per RTP stream, + with distinct values of the "ssrc" attribute, and all these + senders will have a reference to the same "sender" object + (of type RTCAudioSenderStats or RTCVideoSenderStats) and "track" object (of type - RTCSenderAudioTrackAttachmentStats - or RTCSenderVideoTrackAttachmentStats). + RTCSenderAudioTrackAttachmentStats or + RTCSenderVideoTrackAttachmentStats).

    @@ -524,10 +529,10 @@

    - Statistics for the media produced by a MediaStreamTrack that is currently - attached to an RTCRtpSender. This reflects the media that is fed to the - encoder; after getUserMedia() constraints have been applied (i.e. not the - raw media produced by the camera). It is either an + Statistics for the media produced by a MediaStreamTrack that is + currently attached to an RTCRtpSender. This reflects the media that is + fed to the encoder; after getUserMedia() constraints have been applied + (i.e. not the raw media produced by the camera). It is either an RTCAudioSourceStats or RTCVideoSourceStats depending on its kind.

    @@ -689,7 +694,8 @@

    The dictionaries for RTP statistics are structured as a hierarchy, so that those stats - that make sense in many different contexts are represented just once in IDL.

    + that make sense in many different contexts are represented just once in IDL. +

    The lifetime of all RTP monitored objects starts when the RTP stream is first used: When the first RTP packet is sent or