- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Jul 2010 14:56:38 -0700
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