How about the following idea: Example.html contains:
<video id="myvideo_1" src="video.ogg"> to provide the full video <video id="myvideo_2" src="video.ogg?t=0:12:35"> to provide the video from offset 12:35 <video id="myvideo_3" src="video.ogg?t=0:12:35/0:20:40"> to provide the video segment between offset 12:35 and 20:40 <video id="myvideo_4" src="video.ogg?id=section4"> to provide the video from named offset "section4" These provide the Web page author with the power to do offsets. And example URLs relating to the webpage: http://example.com/example.html#myvideo_1&t=0:12:35 to provide the Web page with the first video playing from offset 12:35, offset action provided by the UA (i.e. video gets fully downloaded) http://example.com/example.html#myvideo_1?t=0:12:35/0:20:40 to provide the Web page with the first video playing section 12:35-20:40, UA resolves this to create a query for video.ogg?t=0:12:35/0:20:40, offset action provided by the server These provide the user with control over the start points of the videos on the Webpage. These two URIs with fragment offsets would currently not work in a Web browser. However the set of URIs that I provided inside the <video> tag above already work through the Annodex framework for ogg files. Regards, Silvia. On 3/24/07, Kornel Lesinski <[EMAIL PROTECTED]> wrote:
On Fri, 23 Mar 2007 10:24:30 -0000, Silvia Pfeiffer <[EMAIL PROTECTED]> wrote: >> Let's say there's http://example.com/example.html page which contains >> embedded video: >> ...<video src="video.ogg">... >> >> I'd like to be able to construct URL like: >> http://example.com/[EMAIL PROTECTED]:35 >> that would cause UA to start playing the embedded video.ogg from 12:35. > > That would be hard, because how would you identify which embedded > video or audio file on the example.html page this temporal offset is > referring to? I think it might work like this: when play() is called on a <video> element, and it hasn't been called on any other video element in this document yet, read time from location.hash and call seek(). This would work with dynamically created <video> elements and would probably be the best choice even if there are multiple <video> elements in the document. If such altered behavior of play() is not unacceptable, then that might work: http://example.com/[EMAIL PROTECTED]:35 Where "myvideo" part is interpreted as ID of element in the document (and if there's no such element - assume document.body). If the element is a <video>, then seek() that video. If it isn't, then seek first <video> descendant of that element (something like: (document.getElementById("myvideo") || document.body).getElementsByTagName('video')[0].seek(12*60000+35000))). My rationale: * it doesn't require any changes to the document, so user can control starting position in any document, even if author didn't think of such possibility * It's part of document's URL, not URL of the video file, so user doesn't have to extract video file URL from the document and can still use the page (which provides controls for the video). * it can be implemented in JavaScript with current <video> API (also in User JavaScript, but I think for interoperability it's important to be part of the spec). * it's orthogonal to server-side support for seeking > Also, it could be interpreted by the UA only, since > everything after "#" will not be transferred to the server. Yes, that's intentional. It allows user to modify *any* URL without risk of breaking it (some servers/applications may not like extra query string). I think use of hash for this is appropriate - just like UA scrolls HTML to given element, UA would "scroll" the video - it's just a change of axis from Y to time :) -- regards, Kornel Lesiński
