W3C home > Mailing lists > Public > public-media-fragment@w3.org > November 2008

Re: subview syntax (Re: Combining media fragments with other time-clipping methods)

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 29 Nov 2008 12:21:56 +1100
Message-ID: <2c0e02830811281721g354df326w2e6bf62d0832297d@mail.gmail.com>
To: "Conrad Parker" <conrad@metadecks.org>
Cc: "Media Fragment" <public-media-fragment@w3.org>

On Sat, Nov 29, 2008 at 11:04 AM, Conrad Parker <conrad@metadecks.org> wrote:
>
> Hi,
>
> 2008/11/27 Dave Singer <singer@apple.com>:
>>
>>> On 26 nov 2008, at 01:27, Silvia Pfeiffer wrote:
>>>>
>>>> Hi Jack, all,
>>>>
>>>> This is indeed a very fundamental problem and has to do with exposing
>>>> the context of the resource or not. I am very torn on this issues.
>>>>
>>>> For example, when a browser plays back
>>>> http://www.example.com/myvideo.ogg#t=20s in a Web browser for a HTML5
>>>> video element, would we want to see the timeline with an offset or
>>>> without?
>>
>> t=20s could be:
>> * a clip from 20s to 20s
>> * the whole myvideo, but start playing at 20s (as if the user had dragged
>> teh slider to 20s before playback)
>> * 20s to the normal end of the media, with material before 20s removed
>>
>> The first is not very useful, but both the others are.  However, the second
>> is not a fragment, but a start-playing-at.
>
> I think it is useful to distinguish between these two with syntax. The second
> (start playing at) is an instruction from the user to the UI. This is where
> the #fragment syntax makes sense.
>
> The third (request media from 20s onwards) is a request from the user
> agent to the server. I think this is where a query parameter makes sense.
>
> To see how these are useful, think of a site like youtube. A user can
> add "#t=20s" to the URI of the web page to make the embedded video start
> playing from there, without re-loading the page. Internally, the UI might
> use the server request "myvideo.ogg?t=20s" in order to retrieve the video
> data to render.
>
> In such a use-case, there's no need to expose the query syntax to the
> user, and there's also no need to send #fragment to the server.

If I understand correctly, this is going back to the way in which
temporal URIs were defined to work. For those not across the details,
we had:
* #t=20 meaning: get the whole file, do the offset locally, and use
the data from there (e.g. for playback - depending on what the user
agent is asked to do).
* ?t=20 meaning: get just the fragment from the server and use that
data for whatever the user agent is requested to do (e.g. playback)

This is different to the discussion we had in Cannes where # and ?
were both used as syntax options to get just the fragment from the
server. In the case of using #, it would need to be signalled to the
server "out-of-band", i.e. stripped from the URI and put into protocol
paramters. There is a little information about this at
http://www.w3.org/2008/WebVideo/Fragments/wiki/Syntax .

To clarify: this is orthogonal to the question that Jack and I were
actually discussing. Jack and I both assumed the second case (just get
the fragment from the server - whichever syntax we define for it). The
question then was how to display that. Would a timeline display the
"context", i.e. would it display 0 - length, or would it display 20 -
length only and re-map 20s to 0s. The YouTube case actually falls into
this example: YouTube uses #t=20s to just get the fragment from 20s
onwards from the server, but it displays the context in the YouTube
flash player to enable the user to go back to the first 20s.

Cheers,
Silvia.
Received on Saturday, 29 November 2008 01:22:33 GMT

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