Skip to content

Commit

Permalink
editorial: clarify relayProtocol stats
Browse files Browse the repository at this point in the history 
following
  w3c/webrtc-pc#2763
  • Loading branch information
@fippo
fippo committed Aug 19, 2022
1 parent b708dd3 commit 474693e
Showing 1 changed file with 30 additions and 30 deletions.
60 changes: 30 additions & 30 deletions webrtc-stats.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -601,9 +601,9 @@ <h3>
that make sense in many different contexts are represented just once in IDL.
</p>
<p>
The metrics exposed here correspond to local measurements and those reported by RTCP packets.
Compound RTCP packets contain multiple RTCP report blocks, such as <a>Sender Report</a> (SR) and
<a>Receiver Report</a> (RR) whereas a non-compound RTCP packets may contain just a single
The metrics exposed here correspond to local measurements and those reported by RTCP packets.
Compound RTCP packets contain multiple RTCP report blocks, such as <a>Sender Report</a> (SR) and
<a>Receiver Report</a> (RR) whereas a non-compound RTCP packets may contain just a single
RTCP SR or RR block.
</p>
<p>
Expand Down Expand Up @@ -687,11 +687,11 @@ <h2>
<dd>
<p>
The synchronization source (ssrc) identifier is an unsigned integer value per [[RFC3550]]
used to identify the stream of RTP packets that this stats object is describing.
used to identify the stream of RTP packets that this stats object is describing.
</p>
<p>
For outbound and inbound local, ssrc describes the stats for the track that were
sent and received, respectively by those endpoints.
For outbound and inbound local, ssrc describes the stats for the track that were
sent and received, respectively by those endpoints.
For the remote inbound and remote outbound, ssrc describes the stats for the track
that were received by and sent to the remote endpoint.
</p>
Expand Down Expand Up @@ -880,7 +880,7 @@ <h2>
<p>
Only [= map/exist =]s for video. The total number of frames dropped prior to decode or dropped
because the frame missed its display deadline for this receiver's track. The measurement
begins when the receiver is created and is a cumulative metric as defined in
begins when the receiver is created and is a cumulative metric as defined in
Appendix A (g) of [[!RFC7004]].
</p>
</dd>
Expand Down Expand Up @@ -1048,7 +1048,7 @@ <h2>
<p>
The definition of QP value depends on the codec; for VP8, the QP value is the
value carried in the frame header as the syntax element <code class=vp8>y_ac_qi</code>, and defined in
[[RFC6386]] section 19.2. Its range is 0..127.
[[RFC6386]] section 19.2. Its range is 0..127.
<!-- Need appropriate references for VP9 and H.264 -->
</p>
<p>
Expand Down Expand Up @@ -1254,15 +1254,15 @@ <h2>
<dd>
<p>
The purpose of the jitter buffer is to recombine RTP packets into frames (in the case of video)
and have smooth playout. The model described here assumes that the samples or frames are
and have smooth playout. The model described here assumes that the samples or frames are
still compressed and have not yet been decoded.
It is the sum of the time, in seconds, each <a>audio sample</a> or a video frame takes from
the time the first packet is received by the jitter buffer (ingest timestamp) to the
time it exits the jitter buffer (emit timestamp).
In the case of audio, several samples belong to the same RTP packet, hence they will have the same
ingest timestamp but different jitter buffer emit timestamps.
the time the first packet is received by the jitter buffer (ingest timestamp) to the
time it exits the jitter buffer (emit timestamp).
In the case of audio, several samples belong to the same RTP packet, hence they will have the same
ingest timestamp but different jitter buffer emit timestamps.
In the case of video, the frame maybe is received over several RTP packets, hence the ingest timestamp
is the earliest packet of the frame that entered the jitter buffer and the emit timestamp is
is the earliest packet of the frame that entered the jitter buffer and the emit timestamp is
when the whole frame exits the jitter buffer.
This metric increases upon samples or frames exiting, having completed their time in the buffer (and
incrementing {{jitterBufferEmittedCount}}). The average jitter buffer
Expand Down Expand Up @@ -1292,7 +1292,7 @@ <h2>
The total number of <a>audio sample</a>s or video frames that have come out of the
jitter buffer (increasing {{jitterBufferDelay}}).
</p>

</dd>
<dt>
<dfn>jitterBufferMinimumDelay</dfn> of type <span class=
Expand Down Expand Up @@ -1336,7 +1336,7 @@ <h2>
are samples from lost packets (reported in {{RTCReceivedRtpStreamStats/packetsLost}}) or samples from packets that arrive
too late to be played out (reported in {{RTCInboundRtpStreamStats/packetsDiscarded}}).
</p>

</dd>
<dt>
<dfn>silentConcealedSamples</dfn> of type <span class=
Expand All @@ -1348,7 +1348,7 @@ <h2>
"silent". Playing out silent samples results in silence or comfort noise. This is
a subset of {{concealedSamples}}.
</p>

</dd>
<dt>
<dfn>concealmentEvents</dfn> of type <span class=
Expand All @@ -1361,7 +1361,7 @@ <h2>
consecutive concealed samples will increase the {{concealedSamples}} count multiple
times but is a single concealment event.
</p>

</dd>
<dt>
<dfn>insertedSamplesForDeceleration</dfn> of type <span class=
Expand All @@ -1374,7 +1374,7 @@ <h2>
If playout is slowed down by inserting samples, this will be the number of inserted
samples.
</p>

</dd>
<dt>
<dfn>removedSamplesForAcceleration</dfn> of type <span class=
Expand All @@ -1387,7 +1387,7 @@ <h2>
out. If speedup is achieved by removing samples, this will be the count of samples
removed.
</p>

</dd>
<dt>
<dfn>audioLevel</dfn> of type <span class=
Expand Down Expand Up @@ -1469,7 +1469,7 @@ <h2>
{{totalAudioEnergy}} to compute an average audio level over
different intervals.
</p>

</dd>
<dt>
<dfn>framesReceived</dfn> of type <span class="idlMemberType">unsigned
Expand Down Expand Up @@ -1551,11 +1551,11 @@ <h2>
</dt>
<dd>
<p>
Represents the cumulative sum of all round trip time measurements in seconds
since the beginning of the session. The individual round trip time is calculated
Represents the cumulative sum of all round trip time measurements in seconds
since the beginning of the session. The individual round trip time is calculated
based on the RTCP timestamps in the <a>RTCP Receiver Report</a> (RR) [[!RFC3550]], hence
undefined roundtrip times are not added. The average round trip time can be computed
from {{totalRoundTripTime}} by dividing it by
undefined roundtrip times are not added. The average round trip time can be computed
from {{totalRoundTripTime}} by dividing it by
{{roundTripTimeMeasurements}}.
</p>
</dd>
Expand All @@ -1575,7 +1575,7 @@ <h2>
</dt>
<dd>
<p>
Represents the total number of <a>RTCP RR</a> blocks received for this <a>SSRC</a> that contain
Represents the total number of <a>RTCP RR</a> blocks received for this <a>SSRC</a> that contain
a valid round trip time. This counter will not increment if the {{roundTripTime}} is undefined.
</p>
</dd>
Expand Down Expand Up @@ -1870,7 +1870,7 @@ <h2>
<p>
The definition of QP value depends on the codec; for VP8, the QP value is the
value carried in the frame header as the syntax element <code class=vp8>y_ac_qi</code>, and defined in
[[RFC6386]] section 19.2. Its range is 0..127.
[[RFC6386]] section 19.2. Its range is 0..127.
<!-- Need appropriate references for VP9 and H.264 -->
</p>
<p>
Expand Down Expand Up @@ -2171,7 +2171,7 @@ <h2>
Represents the cumulative sum of all round trip time measurements in seconds since the
beginning of the session. The individual round trip time is calculated based on the
DLRR report block in the <a>RTCP Sender Report</a> (SR) [[!RFC3611]], hence
undefined roundtrip times are not added. The average round trip time can be computed
undefined roundtrip times are not added. The average round trip time can be computed
from {{totalRoundTripTime}} by dividing it by {{roundTripTimeMeasurements}}.
</p>
</dd>
Expand Down Expand Up @@ -2356,7 +2356,7 @@ <h2>
{{totalAudioEnergy}} to compute an average audio level over
different intervals.
</p>

</dd>
<dt>
<dfn>echoReturnLoss</dfn> of type <span class=
Expand Down Expand Up @@ -2966,7 +2966,7 @@ <h2>
<dd>
<p>
It is the protocol used by the endpoint to communicate with the TURN server. This
is only present for local candidates. Valid values are <code>"udp"</code>,
is only present for local relay candidates. Valid values are <code>"udp"</code>,
<code>"tcp"</code>, or <code>"tls"</code>.
</p>
</dd>
Expand Down

0 comments on commit 474693e

Please sign in to comment.