[whatwg] media resources: addressing media fragments through URIs spec
silviapfeiffer1 at gmail.com
Fri Jul 2 01:55:19 PDT 2010
Actually, a point in time is nothing - it's an empty set. You never
want to actually point to a point in time, but rather to either the
point in time and an interval after that point in time, or everything
from that point onwards. That's what these URIs represent.
On Fri, Jul 2, 2010 at 7:56 AM, Jonas Sicking <jonas at sicking.cc> wrote:
> That would be great. I guess it's unclear to me how the UIs would differ for
> 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...
>> 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  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 . 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  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?
>>>>  http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019596.html
>>>>  http://www.youtube.com/watch?v=fyQrKvc7_NU#t=201
>>>>  http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-May/019718.html
>>>>  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 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 . If that is
>>> unclear or anything is confusing, please do point it out so it can be
>>> Best Regards,
>>>  http://www.w3.org/2008/WebVideo/Fragments/code/plugin/ (expect some bugs)
>>>  http://www.w3.org/TR/media-frags/
More information about the whatwg