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

[Silvia Pfeiffer]

The idea or returning a single image for a URI that points at a video
has indeed been discussed. It is not possible to do with a URI
fragment, since a URI fragment (#) can only return the same mime type
as the main URI. But the suggestion for this is to use a URI query.
Then, it is possible to return an image. A URI scheme such as
video.ogv?image=64 could be used to provide this (or anything else
that your server will make up and provide to clients). Since providing
an image in return for a video URI requires some form of
"transcoding", a URI query is the only way to realise this.

On Fri, Jul 2, 2010 at 8:18 PM, Marques Johansson <marques at displague.com> wrote:
> A point in time, if it relates to an I-frame, is very small set and it
> represents an image.
>
> It would be interesting to have
> <img src="file.ogg#t=1:00.5,1:00.5">
>
> or animated images in the sense of:
> <img src="file.ogg#t=1:00,1:15">

(Note: I'm sure you meant s/ogg/ogv/ so we can talk about video files.)

This latter one is already defined as a 5 sec video extract from the
full file.ogv - it's not possible to overload that with turning the
byte range into an animated gif. You will also need to use transcoding
for this and thus will want to create a new URI query scheme.


> I think the earlier post was looking to display video thumbnails using
> this sort of fragment notation.
>
> If the video wasn't being played I would hope that a browser would
> fetch the meta data first and then just seek the byte ranges for that
> fragment.

The whole media fragment URI spec is based on retrieving byte ranges.
I'd encourage you to read it and see if it matches your expectations.

Cheers,
Silvia.


> On Fri, Jul 2, 2010 at 4:55 AM, Silvia Pfeiffer
> <silviapfeiffer1 at gmail.com> wrote:
>> 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.
>>
>> Cheers,
>> Silvia.
>>
>> 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
>>>
>>> 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/
>>>>>
>>>>
>>>
>>
>