Skip to content

Commit

Permalink
Rebase and update
Browse files Browse the repository at this point in the history
  • Loading branch information
handellm committed Dec 18, 2024
1 parent 1acc485 commit 3ee4f43
Showing 1 changed file with 53 additions and 0 deletions.
53 changes: 53 additions & 0 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -72,6 +72,19 @@ <h2>Terminology</h2>
<p>
The process of <dfn data-lt="free|freed|freeing">freeing</dfn> a candidate is defined in [[RFC8445]] Section 8.3.
</p>

<p>
<!-- TODO: use the xref mechanism when mediacapture-extensions spec status is cleared up.
See https://github.com/w3c/mediacapture-extensions/issues/132 -->
The following terms are defined in <a href="https://w3c.github.io/mediacapture-extensions">mediacapture-extensions</a>
<a href="https://w3c.github.io/mediacapture-extensions/#video-timestamp-concepts/">video timestamp concepts</a>
</p>
<ul>
<li><dfn>presentation timestamp</dfn></li>
<li><dfn>capture timestamp</dfn></li>
<li><dfn>receive timestamp</dfn></li>
<li><dfn>RTP timestamp</dfn></li>
</ul>
</section>
<section id="ice-csp">
<h3>
Expand Down Expand Up @@ -1540,6 +1553,46 @@ <h2>Event summary</h2>
</tbody>
</table>
</section>
<section class="informative">
<h2>Timestamp behavior</h2>
<h2>RTCRtpSender timestamp effects on packet NTP and RTP timestamps</h2>
<p>
The user agent defines a <dfn class="export">frame timestamp</dfn> being the same as the [=capture timestamp=]
of the frame being produced on the {{RTCRtpSender}} {{MediaStreamTrack}} if it is set.
If it is unset the user agent estimates a timestamp from the sent frame's [= presentation timestamp =] together with the
time it was received by the {{RTCRtpSender}}.
</p>
<p>
The NTP and RTP timestamps of the encoded frame corresponding to the frame being produced on the {{RTCRtpSender}}
{{MediaStreamTrack}} are sourced from the [= frame timestamp =].
</p>
<p>
The [=RTP timestamp=] of frames being produced on the {{RTCRtpSender}} is ignored.
</p>
<h2>RTCRtpReceiver timestamps</h2>
<h3>Remote capture timestamp</h3>
<p>
<!-- TODO: How this is estimated is under specified and should be fixed, but the section holds the requestVideoFrameCallback text for now -->
For a frame produced in a {{RTCRtpReceiver}} track, the user agent computes a
<dfn class="export">remote capture timestamp</dfn>. It is a best-effort estimate of the local capture
time on the sender translated to the receiver clock, and can use methods like using RTCP SR
as specified in [[?RFC3550]] Section 6.4.1, or by other alternative means if use by RTCP SR
isn't feasible.
</p><p>
Each frame's [= capture timestamp =] is set to the [= remote capture timestamp =], if available.
</p>
<h3>Received RTP timestamp</h3>
<p>
For a frame produced in a {{RTCRtpReceiver}} track, the frame's [=RTP timestamp=] is set
from the RTP timestamp of constituent packets of the corresponding received encoded frame.
</p>
<h3>Receive timestamp</h3>
<p>
For a frame produced in a {{RTCRtpReceiver}} track, the [=receive timestamp=] is set
as the time the corresponding encoded frame was received by the platform, i.e. the time at which the
last packet belonging to this frame was received over the network.
</p>
</section>
<section class="informative" id="security-considerations">
<h2>
Security Considerations
Expand Down

0 comments on commit 3ee4f43

Please sign in to comment.