Closed tonyherre closed 9 months ago
we had #169 for that? Either way, the PR fixes both.
I thought the same re #169 , but re-reading it before filing the PR it seems to be suggesting that we should try to map the existing timestamp
field to the WebCodecs encoded frame timestamp by changing to long long
etc.
AIUI, the path we settled on in #173 was a little different - adding the new long long Metadata.timestamp
field holding the presentation time, so matching the WebCodecs field, and rename the old unsigned long timestamp
to make it explicit that it's holding the RTP timestamp.
I'll add a comment over there too.
Oh, hmm, maybe I misunderstood #169 after all and this is the same?
We agree on what needs to be done - thank for pushing it! 💪
Currently both RTCEncodedAudioFrame and RTCEncodedVideoFrame have a
timestamp
field directly on the frame defined as the RTP timestamp, and atimestamp
in their Metadata dict defined as the Presentation timestamp (to match WebCodecs). This is quite a confusing situation.As discussed during the April Interim and on https://github.com/w3c/webrtc-encoded-transform/pull/173, it makes sense to move the RTP timestamp to the metadata and rename it
rtpTimestamp
.