W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

[whatwg] media resources: addressing media fragments through URIs spec

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 1 Jul 2010 14:56:38 -0700
Message-ID: <AANLkTimLk_qsaqWKvFVWpVfCmblH_IxiR9LvlzZM35_G@mail.gmail.com>
That would be great. I guess it's unclear to me how the UIs would differ for

video.ogv#t=40,50
and
video.ogv#t=40

In particular it seems strange to me that video.ogv#t=40 represents
the whole range from the selected point to the end of the video, given
that most commonly when wanting to point out a particular point in a
video you actually just want to represent a point.

/ Jonas

On Thu, Jul 1, 2010 at 2:46 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com> wrote:
> BTW: I will try and make a screencast of that firefox plugin, which
> should clarify things further. Stay tuned...
> Cheers,
> Silvia.
>
>
> On Thu, Jul 1, 2010 at 7:44 PM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> Hi Jonas,
>>
>> On Thu, Jul 1, 2010 at 4:41 AM, Jonas Sicking <jonas at sicking.cc> wrote:
>>> Hi Silvia,
>>>
>>> Back in may last year I brought [1] up the fact that there are two use
>>> cases for temporal media fragments:
>>>
>>> 1. Skipping to a particular point in a longer resource, such as
>>> wanting to start a video at a particular point while still allowing
>>> seeking in the entire resource. This is currently supported by for
>>> example YouTube [2]. It is also the model used for web pages where
>>> including a fragment identifier only scrolls to a particular point,
>>> while allowing the user to scroll to any point both before and after
>>> the identified fragment.
>>>
>>> 2. Only displaying part of a video. For example out of a longer video
>>> from a discussion panel, only displaying the part where a specific
>>> topic is discussed.
>>>
>>> While there seemed to be agreement [3][4] that these are in fact two
>>> separate use cases, it seems like the media fragments draft is only
>>> attempting to address one. Additionally, it only addresses the one
>>> that has the least precedence as far as current technologies on the
>>> web goes.
>>>
>>> Was this an intentional omission? Is it planned to solve use case 1
>>> above in a future revision?
>>>
>>> [1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019596.html
>>> [2] http://www.youtube.com/watch?v=fyQrKvc7_NU#t=201
>>> [3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019718.html
>>> [4] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019721.html
>>
>>
>> I think you may have misunderstood the specification. Use case 1 is
>> indeed the main use case being addressed in the specification. There
>> is a Firefox plugin implementation[1] of the specification that shows
>> exactly use case 1 in a video element - a URI with a fragment such as
>> video.ogv#t=40,50 is being included in a <video> element and the
>> effect is that the video is displayed from 40s to 50s, but the
>> transport bar (or controls) are still those of the complete resource,
>> so you can still seek to any position.
>>
>> To be sure, this is just a recommendation of how it is supposed to be
>> implemented (see
>> http://www.w3.org/TR/media-frags/#media-fragment-display). The group
>> only defined what URIs look like that point to such a segment - it
>> cannot prescribe what an application (such as a HTML document) does
>> with the URI. I would propose that this discussion should be had about
>> HTML5 and a sentence be added to the HTML5 spec on how UAs are
>> expected to deal with such segments.
>>
>> Further, if you are indeed only interested in a subpart of the
>> original media resource and want to completely blend out all context
>> (i.e. all other bits of the media resource), you should be using the
>> URI query addressing method instead of the URI fragment, e.g.
>> video.ogv?t=40,50. This URI is supposed to create a new resource that
>> consist only of the segment - it will only do so, of course, if your
>> server supports this functionality.
>>
>> All of this is described in more detail in the spec [2]. If that is
>> unclear or anything is confusing, please do point it out so it can be
>> fixed.
>>
>> Best Regards,
>> Silvia.
>>
>>
>>
>> [1] http://www.w3.org/2008/WebVideo/Fragments/code/plugin/ (expect some bugs)
>> [2] http://www.w3.org/TR/media-frags/
>>
>
Received on Thursday, 1 July 2010 14:56:38 UTC

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