On Tue, Apr 7, 2009 at 5:12 PM, Philip Jägenstedt <[email protected]> wrote: > On Tue, 07 Apr 2009 06:11:51 +0200, Chris Double <[email protected]> > wrote: > >> On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson <[email protected]> >> wrote: >>> >>> 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. >> >> Chris. > > 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 (http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/). 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 inconsistencies. > 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 semantics. Regards, Silvia.
