WebRTC Encoded Transform Timestamps

[guidou]

こんにちは TAG-さん!

I'm requesting an early TAG design review of WebRTC Encoded Transform Timestamps.

Exposure of capture timestamp and receive timestamp at the encoded frame level, for easier computation of delays at the frame level.

• Explainer¹: https://github.com/guidou/webrtc-encoded-transform/blob/master/timestamps.md
• User research: N/A
• Security and Privacy self-review²: https://github.com/guidou/webrtc-encoded-transform/blob/master/timestamp_sp_questionnaire.md
• GitHub repo:
  • https://github.com/w3c/webrtc-encoded-transform/pull/237/files
  • https://github.com/w3c/webrtc-encoded-transform/pull/228/files
• Primary contacts:
  • @guidou, Google
• Organization/project driving the design: Google
• Multi-stakeholder feedback³:
  • Chromium comments: Authors of the proposal.
  • Mozilla comments:
    -See PR review for receiveTime
    -See PR review for captureTime and senderCaptureTimeOffset
  • WebKit comments:
    -See PR review for receiveTime
    -See PR review for captureTime and senderCaptureTimeOffset

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done (or is intended to be done in the future): WebRTC WG
• The group where standardization of this work is intended to be done ("unknown" if not known): WebRTC WG
• Existing major pieces of multi-implementer review or discussion of this design:
  -See PR review for receiveTime
  -See PR review for captureTime and senderCaptureTimeOffset
• Major unresolved issues with or opposition to this design:
  • Waiting for the adoption of https://datatracker.ietf.org/doc/draft-alvestrand-avtcore-abs-capture-time/ by IETF, otherwise consensus in the WebRTC WG.
• This work is being funded by: Google

[lolaodelola]

Hi @guidou, thank you for submitting this for TAG review!

I originally had questions about the timestamps being exposed and if that increases the risk of security issues down the line e.g. can the timestamps be used to gain info on the receiver/sender through some kind of pattern recognition i.e. if a video/audio is sent at X time every day or something - but I think that may be irrelevant here. The timestamps are already exposed through RTCRtpContributngSource and the data being sent is encoded so I don't think the timestamps themselves introduce any new issues/concerns.

I'm happy to say we are satisfied with this design.