W3C home > Mailing lists > Public > public-media-fragment@w3.org > February 2010

Re: marking some sections as "ready for implementation"

From: Conrad Parker <conrad@metadecks.org>
Date: Wed, 3 Feb 2010 21:39:08 +0900
Message-ID: <dba6c0831002030439p5dcc8f5vf385f3faabcfb128@mail.gmail.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Cc: Media Fragment <public-media-fragment@w3.org>
On 3 February 2010 20:57, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
> Hi all,
> We have both Firefox and Opera waiting for a "go-ahead" from us on
> what is ready for implementation and I don't really want to make them
> wait, since I believe we can do with a reality check.
> For this we should mark sections that we agree on as "ready to
> implement". But to make that call, we need a group agreement.
> I'd like us to move towards such a decision on the following sections:
> Section 5.2.1, http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-protocol-UA-mapped
> together with the specification part for NPT time:
> Section
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#npt-time
> and the general structure of media URI fragments.
> ...
> I believe what is required is to say basically:
> * this is the specification of such temporal URIs using fragments (normative)
> * when you get such a URI in a video element or in the URI bar, parse
> it in this way (normative)
> * then resolve it through byte range requests if you can (Firefox
> already is able to do this for Ogg though it takes multiple byte range
> requests to get to the right location; with new indexed Ogg files,
> this will improve) (informative)

for this part (which only relates to how a client acts on a #t=), I
don't think it's necessary for the Media Fragments spec to say how a
user agent actually retrieves the data for a given media-type. This is
really dependent on that media-type; it may involve one or more
byte-range requests (eg. in the two schemes you mention for Ogg), or
it may involve loading auxiliary resources which describe where to get
various bits required for a time offset (eg. for quicktime adaptive
streaming or MS smooth streaming), and these may then involve requests
of many different resources that make up the media. Basically my point
is that the specific mechanism depends on both what the media-type
specifies and what the client is capable of, and doesn't belong in
this section of the Media Fragments spec.

It might be simpler to just say that if the client is capable of
seeking in a resource, then the #t= indicates to the client that it
should seek to that time -- and perhaps we can even word that
unambiguously enough to be normative.

Received on Wednesday, 3 February 2010 12:39:41 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:44 UTC