W3C home > Mailing lists > Public > public-media-fragment@w3.org > August 2009

Re: Fwd: [whatwg] Remove addCueRange/removeCueRanges

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sun, 23 Aug 2009 00:43:08 +1000
Message-ID: <2c0e02830908220743o72e95222v137ecd7490aa385@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Media Fragment <public-media-fragment@w3.org>
On Sat, Aug 22, 2009 at 9:21 PM, Philip Jägenstedt<philipj@opera.com> wrote:
> On Fri, 14 Aug 2009 14:56:16 +0200, Silvia Pfeiffer
> <silviapfeiffer1@gmail.com> wrote:
>> On Fri, Aug 14, 2009 at 9:21 PM, Philip Jägenstedt<philipj@opera.com>
>> wrote:
>>> As far as browsers are concerned, query strings will not be given any
>>> special treatment, so personally I am only interested in the syntax for
>>> proper fragments.
>> So, let's look at the query case a bit more in-depth.
>> A video file with a query is being treated as a different resource to
>> the video resource without the query.
>> The media server  returns only the specified time segment of the
>> video. This is the "new resource".
>> Since the browser doesn't give it special treatment, the browser
>> regards this "segment" as the full video.
>> As the time display for a video starts by default at 0, this "segment"
>> will by default be displaying a start and end time that does not
>> reflect the start and end time used in the URL. Correct?
> Correct
>> This is where I see a need for the browser to do something.
>> What we should do IMO is to fix the start and end time displayed in
>> the video controls.
>> Alternatively, we could display the controls that would relate to the
>> original resource, but I think that's semantically wrong because it's
>> a different resource, and I also think it's information that is not
>> available in the given resource (at least not the duration of the
>> original resource) so would require an extra retrieval action.
>> Fixing the start/end time displayed is not as much of a problem for
>> Ogg files: the browser can parse the start time in the skeleton header
>> (assuming such a skeleton track is present) and get the duration in
>> the usual way. For other containers I don't think such a start time
>> offset is available.
>> Alternatively, the browser can use the information given in the URL to
>> display the start and end times. Since these may not be 100% correct,
>> this may be a problem.
>> So, what would be the right thing to do?
> In my opinion that is completely a UI design choice. My personal preference
> is that ?query resources should be aligned to zero (ignoring skeleton
> headers) and that #fragment resources should display the full time-line with
> the ability to seek outside the specified range. Different browsers will
> experiment with different solutions and if the author isn't happy she/he
> could use a script-based interface more to her/his liking.

I don't think there is a need for a single prescription. I just think
that part of what we do needs to describe the different effects that
the display choice has and that the implementer has a choice. I also
believe we need to leave it up to some more experimentation, though
for some situations it is quite clear already from previous experience
what choices they require. I just think that the best way in which we
can arm implementers is to give them some intelligent information
about the options.

Received on Saturday, 22 August 2009 14:44:03 UTC

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