- From: Sander Tekelenburg <st@isoc.nl>
- Date: Fri, 23 Mar 2007 03:21:29 +0100
At 07:53 +1100 UTC, on 2007-03-23, Silvia Pfeiffer wrote: [...] > About 8 years ago, we had the idea of using fragment offsets to start > playing from offsets of media files. However, in discussions with the > URI standardisation team at W3C it turned out that fragment offsets > are only being seen by the UA that sends them, so they will never > reach the web server. Right. See RFC 3986, section 3.5: "[...] the fragment identifier is not used in the scheme-specific processing of a URI; instead, the fragment identifier is separated from the rest of the URI prior to a dereference, and thus the identifying information within the fragment itself is dereferenced solely by the user agent, regardless of the URI scheme. [...]" > This makes it impossible to use them for "play > from this offset" since obviously the offsetting should be done by the > server While that might be useful, it's not at all obvious to me that it is a *requirement*. What is so wrong with fetching the entire file, and start playing it at the point referenced by the fragment identifier? That's how fragment identifiers work for textual resources (and they fetch the usual truckload of images along with the HTML file). Sure, with 'big' files and 'slow' connections, that would mean having to wait longer. But "big" and "slow" are relative values. And when you want to watch something only from point x on, even if that means having to wait, that's still much better than having to first watch all of the video before that point. At least while you're waiting, you can still do something useful ;) [...] > The only solution was to use the query "?" identifier for defining offsets. Unless I'm misunderstanding something, that makes things server-dependant. I recognise that the benefit of this approach is being able to only fetch the data you want, but it doesn't offer the user the benefit of easily being able to refer to a specific point in any movie (in a <video> element). -- Sander Tekelenburg The Web Repair Initiative: <http://webrepair.org/>
Received on Thursday, 22 March 2007 19:21:29 UTC