- From: Peter Linss via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Dec 2017 20:16:20 +0000
- To: public-media-capture-logs@w3.org
> 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. -- GitHub Notification of comment by plinss Please view or discuss this issue at https://github.com/w3c/mediacapture-record/issues/140#issuecomment-352545417 using your GitHub account
Received on Monday, 18 December 2017 20:16:21 UTC