#1049: WebRTC Encoded Transform Timestamps
Discussions
Log in to see TAG-private discussions.
Discussed
Mar 1, 2025 (See Github)
Lola: I'm the only one assigned to it.
Jeffrey: I can also review. Will put it on the plenary.
[General sense that Martin would actually be the right reviewer.]
Discussed
Mar 1, 2025 (See Github)
Lola: I think it's closed ...
Matthew: satisfied ... only thing to do is to close the issue.
closed
Comment by @lolaodelola Mar 20, 2025 (See Github)
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.
OpenedFeb 7, 2025
こんにちは 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.
Further details: