- From: Philip Jägenstedt <philipj@opera.com>
- Date: Thu, 08 Mar 2012 11:55:55 +0100
On Thu, 08 Mar 2012 11:11:06 +0100, Philip J?genstedt <philipj at opera.com> wrote: > As hinted above, I don't think that startOffsetTime should really be the > first choice for trying to sync live streams. However, knowing the date > of a video is still useful, potentially even for the streaming case, so > we do want to expose the DateUTC field from WebM. However, > startOffsetTime is a bad name for it, since it's not using the same unit > as currentTime. I suggest offsetDate, to go with offsetTime. We discussed this some more internally, specifically if the date is an offset at all and if so what it is relative to. In WebM, the DateUTC field is defined as "Date of the origin of timecode (value 0), i.e. production date." [1] Exposing this directly would mean that it is the date at currentTime=-offsetTime, an origin time that you can't actually seek to in the streaming case. We discussed the concatenation of two clips and how to represent the date. At least chained WebM and chained Ogg should be able to represent this. To reduce the possibility for confusion about what date is represented and to allow the recording date to be preserved in editing, how about exposing currentDate instead? [1] http://www.webmproject.org/code/specs/container/ -- Philip J?genstedt Core Developer Opera Software
Received on Thursday, 8 March 2012 02:55:55 UTC