[whatwg] <video> element feedback

[Sander Tekelenburg]

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/>