Update https://w3c.github.io/mediacapture-record/#dom-blobeventinit-timecode.

[handellm]

The spec text was unclear. From offline discussion with the original spec author it's believed that the initial intent of the spec language was meant to convey that the first produced timecode would contain an absolute timestamp. However, it's not clear what use case is unlocked by that, as the user can construct their own absolute timestamp with performance.now() on event reception. This ignores the fact that the event handler can execute delayed, but since it's not clear what problem this fixes, this PR simply makes the timestamp sequence start with zero instead.

Fixes #222.

---

Preview | Diff

[bradisbell]

From offline discussion with the original spec author it's believed that the initial intent of the spec language was meant to convey that the first produced timecode would contain an absolute timestamp.

@handellm Actually, that makes sense... that way, the user can know when recording started.

We know from MediaRecorder's start event roughly what browser time the recorder started, but we don't know the browser timestamp of the first recorded audio/video data.

So, if a user clicks record and we start recording a MediaStream with a MediaRecorder, with a timeslice of 5_000...

• 2024-09-05 15:19:32.500Z We ask MediaRecorder to start
• 2024-09-05 15:19:33.000Z MediaRecorder start fires
• 2024-09-05 15:19:33.100Z The next video frame comes in... this is the first frame since the MediaRecorder has started, and suppose it's a screen recording so frames are random and sparse.
• ... more frames here ...
• 2024-09-05 15:19:38.222Z MediaRecorder dataavailable fires. This is the first chunk.

Now, in this sequence we know when we asked MediaRecorder to start, but this isn't a good timestamp to use for the actual start time because it can take quite a bit of time for MediaRecorder to get moving, especially with hardware codecs involved that need to be woken up and initialized. MediaRecorder tells us when it starts, but that isn't a good timestamp either because it isn't relative to the MediaStream. There could be several seconds of nothing before the next frame. Only when dataavailable fires do we know what was captured and when.

I might just be hopeful here, but if the original intent in the spec was to give a timestamp for that first recorded data... maybe we should find a way to make that clearer rather than abandon it? Or, if this is an expansion of the API and not how browsers work today, then maybe this is worthy of a future addition?

[jan-ivar]

+1 with nit

[handellm]

@bradisbell - if the time of arrival of the first frame is to be timestamped, there are better ways of observing this such as using MediaStreamTrackProcessor/generator. I'm going to merge this PR now and follow up with WPTs and Chromium change.

[alvestrand]

Added "editors can integrate" label to PR too (it was wrongly applied to just the issue).