- From: Brad Isbell via GitHub <sysbot+gh@w3.org>
- Date: Sun, 16 Jun 2024 22:38:32 +0000
- To: public-webrtc@w3.org
bradisbell has just created a new issue for https://github.com/w3c/mediacapture-main: == MediaRecorder BlobEvent timecode clarification == From: https://w3c.github.io/mediacapture-record/#dom-blobeventinit-timecode > `timecode`, of type `DOMHighResTimeStamp`, readonly > The difference between the timestamp of the first chunk in data and the timestamp of the first chunk in the first BlobEvent produced by this recorder as a DOMHighResTimeStamp [HR-TIME]. Note that the timecode in the first produced BlobEvent does not need to be zero. I don't think I've ever fully understand this sentence. If this is the value of the timestamp of the first chunk in `data`, compared to the value of the first chunk in `data` of the first event produced by this recorder, and if this is the first event, how could the value of `timecode` not be zero `0`? I believe at some point in the past, `timecode` would actually start at zero `0` for the first event, and then subsequent `dataavailable` `BlobEvent` `timecode` could be used to determine the duration of recorded MediaStream data thus far. It seems that the current way is to note the first event's `timecode` and offset subsequent `timecode` events by that first event's `timecode` value to see how much time has passed. That's fine, but depends on the assumption that the first event's `timecode` is the zero relative to other events. Please view or discuss this issue at https://github.com/w3c/mediacapture-main/issues/1008 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 16 June 2024 22:38:32 UTC