W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2009

[whatwg] Start position of media resources

From: Philip Jägenstedt <philipj@opera.com>
Date: Tue, 07 Apr 2009 09:12:09 +0200
Message-ID: <op.urz8yjy1atwj1d@sisko.linkoping.osa>
On Tue, 07 Apr 2009 06:11:51 +0200, Chris Double  
<chris.double at double.co.nz> wrote:

> On Tue, Apr 7, 2009 at 3:40 AM, Eric Carlson <eric.carlson at apple.com>  
> 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.

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).

Perhaps we would like to have some way to express where a resource is  
positioned on a timeline external to the resource itself, but could SMIL  
do this perhaps?

I suppose that an UA could parse the media fragment in the URL and adjust  
the timeline accordingly, but I'm not sure if it's a great idea...

-- 
Philip J?genstedt
Opera Software
Received on Tuesday, 7 April 2009 00:12:09 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:11 UTC