-
Notifications
You must be signed in to change notification settings - Fork 18
Add WebRTC-specific interactions with capture/receive/RTP timestamps #224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from all commits
1acc485
3ee4f43
92a79db
18a0c80
427dec6
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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,43 @@ <h2>Event summary</h2> | |
</tbody> | ||
</table> | ||
</section> | ||
<section> | ||
<h2>Timestamp behavior</h2> | ||
<h2>RTCRtpSender video track frame timestamp effects on outgoing 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. | ||
Comment on lines
+1558
to
+1561
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sorry, I'm not following what this timestamp is by the name "frame timestamp". Not all track sources will insert capture timestamps in the tracks they produce. Is this what you mean by "if it is set"? |
||
If it is unset the user agent MUST estimate a timestamp from the sent frame's [=presentation timestamp=] together with the | ||
time it was received by the {{RTCRtpSender}}. This estimate MUST NOT be based on [= RTP timestamp =]. | ||
Comment on lines
+1562
to
+1563
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What does "received by the RTCRtpSender" mean? Do you mean RTCRtpReceiver? |
||
</p> | ||
<p> | ||
The NTP and RTP timestamps of the encoded frame corresponding to the frame being produced on the {{RTCRtpSender}} | ||
{{MediaStreamTrack}} MUST be sourced from the [=frame timestamp=]. | ||
</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 video frame produced in a {{RTCRtpReceiver}} track, the frame's [=RTP timestamp=] MUST be 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=] MUST be 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 | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Due to the unclear state of the mediacapture-extensions spec (not listed in browser-specs) I had to make some temporary reference structure as per below, when referring to concepts defined there.