Skip to content

Commit

Permalink
Fix alignment
Browse files Browse the repository at this point in the history
  • Loading branch information
@aboba
aboba committed Jan 21, 2019
1 parent bfe4b29 commit 1084b12
Showing 1 changed file with 37 additions and 41 deletions.
78 changes: 37 additions & 41 deletions webrtc.html
View file
Expand Up @@ -7510,44 +7510,40 @@ <h2>Methods</h2>
</div>
<section>
<h3>Simulcast functionality</h3>
<p>Simulcast functionality is provided via the
<code>addTransceiver</code> method of the <code><a>RTCPeerConnection</a></code> object
and the <code>setParameters</code> method of the <code><a>RTCRtpSender</a></code> object.</p>
<p>The <code>addTransceiver</code> method establishes the <dfn>simulcast envelope</dfn> which includes
the maximum number of simulcast streams that can be sent, as well as the ordering of the <code>encodings</code>.
While characteristics of individual simulcast streams can be modified using the <code>setParameters</code>
method, the <a>simulcast envelope</a> cannot be changed. One of the implications of this model is that
the <code>addTrack</code> method cannot provide simulcast functionality since it
does not take <code>sendEncodings</code> as an argument, and therefore cannot configure
an <code><a>RTCRtpTransceiver</a></code> to send simulcast.</p>
<p>While <code>setParameters</code> cannot modify the <a>simulcast envelope</a>, it is still possible to control the
number of streams that are sent and the characteristics of those streams.
Using <code>setParameters</code>, simulcast streams can be made inactive by setting the <code>active</code>
attribute to <code>false</code>, or can be reactivated by setting the <code>active</code>
attribute to <code>true</code>. Using <code>setParameters</code>, stream characteristics can be changed
by modifying attributes such as <code>maxBitrate</code> and <code>maxFramerate</code>.</p>
<p>This specification does not define how to configure <code>createOffer</code> to
receive multiple RTP encodings. However when <code>setRemoteDescription</code> is called with a
corresponding remote description that is able to send
multiple RTP encodings as defined in [[!JSEP]], the
<code><a>RTCRtpReceiver</a></code> may receive multiple RTP
encodings and the parameters retrieved via the transceiver's
<code>receiver.getParameters()</code> will reflect the
encodings negotiated.</p>
<p class="note">An <code><a>RTCRtpReceiver</a></code> can receive multiple RTP streams in a scenario
where a Selective Forwarding Unit (SFU) switches between simulcast streams it receives from user agents.
If the SFU does not rewrite RTP headers so as to arrange the switched streams into a single RTP
stream prior to forwarding, the <code><a>RTCRtpReceiver</a></code> will receive packets from
distinct RTP streams, each with their own SSRC and sequence number space.
While the SFU may only forward a single RTP stream at any given time, packets
from multiple RTP streams can become intermingled at the receiver due to reordering.
An <code><a>RTCRtpReceiver</a></code> equipped to receive multiple RTP streams will therefore
need to be able to correctly order the received packets, recognize potential loss events and
react to them. Correct operation in this scenario is non-trivial and therefore is optional
for implementations of this specification.</p>
<section class="informative" id="rtcrtpencodingspatialsim-example*">
<h3>Encoding Parameter Examples</h3>
<div>
<p>Simulcast functionality is provided via the <code>addTransceiver</code> method of the
<code><a>RTCPeerConnection</a></code> object and the <code>setParameters</code> method of the
<code><a>RTCRtpSender</a></code> object.</p>
<p>The <code>addTransceiver</code> method establishes the <dfn>simulcast envelope</dfn> which
includes the maximum number of simulcast streams that can be sent, as well as the ordering of the
<code>encodings</code>. While characteristics of individual simulcast streams can be modified using
the <code>setParameters</code> method, the <a>simulcast envelope</a> cannot be changed. One of the
implications of this model is that the <code>addTrack</code> method cannot provide simulcast
functionality since it does not take <code>sendEncodings</code> as an argument, and therefore cannot
configure an <code><a>RTCRtpTransceiver</a></code> to send simulcast.</p>
<p>While <code>setParameters</code> cannot modify the <a>simulcast envelope</a>, it is still possible
to control the number of streams that are sent and the characteristics of those streams. Using
<code>setParameters</code>, simulcast streams can be made inactive by setting the <code>active</code>
attribute to <code>false</code>, or can be reactivated by setting the <code>active</code>
attribute to <code>true</code>. Using <code>setParameters</code>, stream characteristics can be
changed by modifying attributes such as <code>maxBitrate</code> and <code>maxFramerate</code>.</p>
<p>This specification does not define how to configure <code>createOffer</code> to receive multiple
RTP encodings. However when <code>setRemoteDescription</code> is called with a corresponding remote
description that is able to send multiple RTP encodings as defined in [[!JSEP]], the
<code><a>RTCRtpReceiver</a></code> may receive multiple RTP encodings and the parameters retrieved
via the transceiver's <code>receiver.getParameters()</code> will reflect the encodings negotiated.</p>
<p class="note">An <code><a>RTCRtpReceiver</a></code> can receive multiple RTP streams in a scenario
where a Selective Forwarding Unit (SFU) switches between simulcast streams it receives from user agents.
If the SFU does not rewrite RTP headers so as to arrange the switched streams into a single RTP
stream prior to forwarding, the <code><a>RTCRtpReceiver</a></code> will receive packets from distinct
RTP streams, each with their own SSRC and sequence number space. While the SFU may only forward a single
RTP stream at any given time, packets from multiple RTP streams can become intermingled at the receiver
due to reordering. An <code><a>RTCRtpReceiver</a></code> equipped to receive multiple RTP streams will
therefore need to be able to correctly order the received packets, recognize potential loss events and
react to them. Correct operation in this scenario is non-trivial and therefore is optional for
implementations of this specification.</p>
<section class="informative" id="rtcrtpencodingspatialsim-example*">
<h3>Encoding Parameter Examples</h3>
<div>
<p>Examples of simulcast scenarios implemented with encoding parameters:</p>
<pre class="example highlight">

Expand All @@ -7564,9 +7560,9 @@ <h3>Encoding Parameter Examples</h3>
{rid: 'h', active: false, maxFramerate: 30},
{rid: 'q', active: true, maxFramerate: 15}
];
</pre>
</div>
</section>
</pre>
</div>
</section>
</section>
<section>
<h3>"Hold" functionality</h3>
Expand Down

0 comments on commit 1084b12

Please sign in to comment.