[whatwg] Start position of media resources
silviapfeiffer1 at gmail.com
Tue Apr 7 01:26:15 PDT 2009
On Tue, Apr 7, 2009 at 5:12 PM, Philip Jägenstedt <philipj at opera.com> wrote:
> On Tue, 07 Apr 2009 06:11:51 +0200, Chris Double <chris.double at double.co.nz>
>> On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson <eric.carlson at apple.com>
>>> Media time values are expressed in normal play time (NPT), the absolute
>>> position relative to the beginning of the presentation.
>> I don't see mention of this in the spec which is one of the reasons I
>> raised the question. Have I missed it? If not I'd like to see the spec
>> clarified here.
> Indeed clarification is needed. In my opinion time 0 should correspond to
> the beginning of the media resource, no matter what the timeline of the
> container format says. This means that currentTime doesn't jump when
> playback begins and never goes beyond duration.
I humbly disagree. If a media file explicitly knows at what time
offset it starts, the timeline needs to represent that, otherwise
there are contradictory user experiences.
For example, take a video that is a subpart of a larger video and has
been delivered through a media fragment URI
When a user watches both, the fragment and the full resource, and both
start at 0, he/she will assume they are different resources, when in
fact one is just a fragment of the other. Worse still: if he/she tries
to send a URI with a link to a specific time offset in the video to a
friend, he/she will come up with diverging URIs based on whether
he/she watched the fragment or the full resource. Representing the
wrong timeline for a media fragment will only cause confusion and
> Taking Ogg as an example, there's no requirement that the granulepos start
> at zero nor does a non-zero granulepos imply any special semantics such as
> "the beginning of the file has been chopped off". A tool like oggz-chop
> might retain the original granulepos of each packet or it could just as well
> adjust the stream to start at granulepos 0. Neither is more correct than the
> other, so I'd prefer we not try to infer anything from it, especially since
> such low-level timing information might be hidden deep inside the platform
> media framework (if it normalizes the time like XiphQT presumably does).
For Ogg and the definition of Skeleton
(http://wiki.xiph.org/index.php/Ogg_Skeleton), both the original
basetime of the beginning of the file and the presentation time of the
chopped off part are recorded, so it actually does imply special
More information about the whatwg