timecode issues

[plinss]

(not sure if I should have filed these as individual issues, but didn't want to spam the issues list, happy to split if desired)

1. The current description of timecode is confusing.
   a) It's not clear if the timecode is referring to the time the first data in the blob was captured or when the event was created (I presume the former as the latter is supplied by the event's timeStamp).
   b) The prose doesn't define a timecocde value for the first chunk (other than stating that it "does not need to be zero"). This should be clearly defined to be either 0 or the actual time of the capture.
   c) The first chunk's timecode is an arbitrary value, but the following chunk's timecodes are defined to be a difference from the first chunk. This puts a burden on developers to interpret the data. They should either all be simple timestamps, or the first be 0 and the following be offsets from the beginning of the recording. (FWIW Chrome's current implementation appears to be all simple timestamps.)

2. There's no way to compute a duration. If the first timecode is the start time of the first chunk, then the duration of each chunk could be computed by the difference of the timecode of the following chunk. However there's no way to compute the duration of the last chunk. (Similarly if the first chunk's timecode was a timestamp of the end of the chunk, there'd be no way to get the duration of the first chunk.) It would be useful to have a duration attribute for each chunk (or possibly a startTimecode/endTimecode).

3. It's unclear what the behavior of the timecode is when the recording is paused. Is it the real-world timestamp of the capture of the beginning of the chunk, or is it the time within the recorded stream of the beginning of the chunk? (i.e. if a recording delivers a 2 second chunk, is paused for 30 seconds, then resumes, is the timecode of the second chunk 2 or 32 seconds?) (I'd prefer the latter, e.g. the timecode/duration always refers to the data in the recorded stream, rather than the capture time, if there's a use for the capture time, it should be a separate attribute.)

[alvestrand]

what do you mean by "simple timestamp" in this case?
One thing I've learned about timestamps is that they are rarely simple, once one starts digging.
Once you have a chunk, can't you find the duration of that chunk?

[plinss]

what do you mean by "simple timestamp" in this case?
One thing I've learned about timestamps is that they are rarely simple, once one starts digging.

Sorry, don't mean to oversimplify, I know "simple" doesn't really apply to time measurements. What I really mean is that it's a useful value that has a well-defined meaning and can be reasoned with, I don't care which. A hi-res timestamp from the beginning of navigation, or an epoch timestamp (which is what Chrome appears to provide) is fine (but I'd actually rather have a hi-res time offset from the beginning of recording).

Once you have a chunk, can't you find the duration of that chunk?

Theoretically, yes, I can get the duration by decoding the chunk, but 1) the spec doesn't define what's in the chunk's data, so I can't depend on it being anything I can decode*, and 2) the point of the timecode is to let the user get basic (useful) measurements without needing to decode the data. I'm just not finding the timecode all that useful in practice so far. Let's either make it useful or get rid of it.

• I'd really like the chunk to have a well-defined content, like at-least breaking on WebM element boundaries or some such (not an expert on WebM, but I hope you get the idea), so the data in each chunk can be inspected/manipulated individually (as appropriate to the type, of course). But the spec as currently written allows the implementation to split chunks on arbitrary implementation-specific boundaries (like buffer boundaries), but I'll file that as a separate issue.