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.

Cheers,
Silvia.
Received on Saturday, 22 August 2009 14:44:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:34 GMT