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 <marq...@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 > <silviapfeiff...@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 <jo...@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 >>> <silviapfeiff...@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 >>>> <silviapfeiff...@gmail.com> wrote: >>>>> Hi Jonas, >>>>> >>>>> On Thu, Jul 1, 2010 at 4:41 AM, Jonas Sicking <jo...@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/ >>>>> >>>> >>> >> >
