Skip to content

Commit

Permalink
Merge pull request #173 from fippo/respec-woes
Browse files Browse the repository at this point in the history 
editorial: fix respec / validation woes
  • Loading branch information
@jan-ivar
jan-ivar committed Jul 27, 2023
2 parents cbae391 + 793546b commit 9601ac8
Showing 1 changed file with 32 additions and 36 deletions.
68 changes: 32 additions & 36 deletions index.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -55,12 +55,12 @@ <h2>Terminology</h2>
<p>
The following terms are defined in
<a href="https://webrtc.org/experiments/rtp-hdrext/abs-capture-time"><dfn>RTP Header Extension for Absolute Capture Time</dfn></a>:
<ul>
<li><a href="https://webrtc.org/experiments/rtp-hdrext/abs-capture-time#absolute-capture-timestamp"><dfn>absolute capture timestamp</dfn></a>
<li><a href="https://webrtc.org/experiments/rtp-hdrext/abs-capture-time#timestamp-interpolation"><dfn>timestamp interpolation</dfn></a>
<li><a href="https://webrtc.org/experiments/rtp-hdrext/abs-capture-time#estimated-capture-clock-offset"><dfn>estimated capture clock offset</dfn></a>
</ul>
</p>
<ul>
<li><a href="https://webrtc.org/experiments/rtp-hdrext/abs-capture-time#absolute-capture-timestamp"><dfn>absolute capture timestamp</dfn></a>
<li><a href="https://webrtc.org/experiments/rtp-hdrext/abs-capture-time#timestamp-interpolation"><dfn>timestamp interpolation</dfn></a>
<li><a href="https://webrtc.org/experiments/rtp-hdrext/abs-capture-time#estimated-capture-clock-offset"><dfn>estimated capture clock offset</dfn></a>
</ul>
<p>The process of <dfn>chaining</dfn> an operation to an <dfn>operations chain</dfn> is defined in [[WEBRTC]] Section 4.4.1.2.</p>
</section>
<section id="ice-csp">
Expand Down Expand Up @@ -414,8 +414,6 @@ <h2>Attributes</h2>
<p>Set <var>receiver</var>'s {{RTCRtpReceiver/[[JitterBufferTarget]]}}
to <var>target</var>.</p>
</li>
<li>
</li>
<li>
<p>Let <var>track</var> be <var>receiver</var>'s
{{RTCRtpReceiver/[[ReceiverTrack]]}}.</p>
Expand All @@ -427,26 +425,26 @@ <h2>Attributes</h2>
<p>Update the underlying system about the new <var>target</var>,
or that there is no application preference if <var>target</var> is
<code>null</code>.</p>
</li>
<p>
If <var>track</var> is synchronized with another
{{RTCRtpReceiver}}'s track for
<a data-cite="RFC5888#section-7">audio/video synchronization</a>,
then the <a>user agent</a> SHOULD use the larger of the two receivers'
{{RTCRtpReceiver/[[JitterBufferTarget]]}} for both receivers.
</p>
<p>
When the underlying system is applying a jitter buffer target, it will
continuously make sure that the actual jitter buffer target is clamped
within the <a>minimum allowed target</a> and <a>maximum allowed
target</a>.
<p class="note">
If the <a>user agent</a> ends up using a target different from the
requested one (e.g. due to network conditions or physical memory
constraints), this is not reflected in the
{{RTCRtpReceiver/[[JitterBufferTarget]]}} internal slot.
<p>
If <var>track</var> is synchronized with another
{{RTCRtpReceiver}}'s track for
<a data-cite="RFC5888#section-7">audio/video synchronization</a>,
then the <a>user agent</a> SHOULD use the larger of the two receivers'
{{RTCRtpReceiver/[[JitterBufferTarget]]}} for both receivers.
</p>
</p>
<p>
When the underlying system is applying a jitter buffer target, it will
continuously make sure that the actual jitter buffer target is clamped
within the <a>minimum allowed target</a> and <a>maximum allowed
target</a>.
<p class="note">
If the <a>user agent</a> ends up using a target different from the
requested one (e.g. due to network conditions or physical memory
constraints), this is not reflected in the
{{RTCRtpReceiver/[[JitterBufferTarget]]}} internal slot.
</p>
</p>
</li>
<li>
<p>Modifying the jitter buffer target of the underlying system SHOULD
affect the internal audio or video buffering gradually in order not
Expand Down Expand Up @@ -824,7 +822,6 @@ <h2>Dictionary {{RTCRtpContributingSource}} Members</h2>
{{RTCRtpContributingSource.timestamp}} -
<var>receiverCaptureTimestamp</var>.
</p>
</p>
</dd>
</dl>
</section>
Expand All @@ -838,7 +835,7 @@ <h3>
Transferable Data Channels
</h3>
<p>This section extends {{RTCDataChannel}} by making it <a data-cite="!HTML/#transferable-objects">transferable</a>.</p>
This allows sending and receiving messages outside the context the connection was created, for instance in workers or third-party iframes.</p>
<p>This allows sending and receiving messages outside the context the connection was created, for instance in workers or third-party iframes.</p>
<div>
<p>The WebIDL changes are the following:
<pre class="idl">
Expand Down Expand Up @@ -959,23 +956,22 @@ <h3>
the transceiver is sending enrypted RTP header extensions as defined in
[[CRYPTEX]].
</p>
<div>
<pre class="idl">
partial interface RTCRtpTransceiver {
readonly attribute boolean rtpHeaderEncryptionNegotiated;
};</pre>
<pre class="idl">
partial interface RTCRtpTransceiver {
readonly attribute boolean rtpHeaderEncryptionNegotiated;
};</pre>
<section>
<h2>
Attributes
</h2>
<dl data-link-for="RTCRtpTransceiver" data-dfn-for=
"RTCRtpTransceiver" class="attributes">
<dt>
<dfn id="dom-rtptransceiver-rtpHeaderEncryptionNegotiated">rtpHeaderEncryptionNegotiated</dfn> of type <span class=
<dt>
<dfn id="dom-rtptransceiver-rtpHeaderEncryptionNegotiated">rtpHeaderEncryptionNegotiated</dfn> of type <span class=
"idlAttrType">Boolean</span>, readonly, nullable
</dt>
<dd>
<p>
<p>
The {{rtpHeaderEncryptionNegotiated}} attribute indicates whether [[CRYPTEX]] has been
negotiated. On getting, the attribute MUST
return the value of the {{RTCRtpTransceiver/[[RtpHeaderEncryptionNegotiated]]}} slot.
Expand Down

0 comments on commit 9601ac8

Please sign in to comment.