Rebase and update

Author: handellm

index.html

@@ -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>
@@ -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