On Thu, 08 Mar 2012 11:11:06 +0100, Philip Jägenstedt <phil...@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
