[whatwg] <video> element feedback - integration, fragments, and queries

[Dave Singer]

At 4:04  +0000 9/10/07, Ian Hickson wrote:
>This e-mail replies to e-mails sent to both whatwg at whatwg.org and
>public-html at w3.org, as the thread in question ended up spilling over both
>mailing lists.
>
>WHEN REPLYING TO THIS E-MAIL PLEASE PICK ONE MAILING LIST AND REPLY TO
>JUST THAT ONE. PLEASE DO NOT CROSS-POST THIS THREAD TO BOTH LISTS.

OK, I choose....whatWG.  Hope that's right.

>  > Alternatively (thinking of XSPF playlists), what if <video>'s src
>>  attribute pointed to an XML (or text/html-esque) file which contained
>>  these separate elements? It would be a powerful way of building a level
>>  of transparent accessibility into the system, without requiring users to
>>  download and play high-bandwidth content to find out if it has the
>>  features they need.
>
>Most video formats already have support for timed text and other features
>for accessible content. So effectively what the spec says today is pretty
>much what you describe here, except that we side-step the problem of
>having to invent a new format.

I agree.  'An XML file which contains separate elements' of timed 
media resources is almost a definition of SMIL.  We should allow the 
embedding of SMIL in video and audio tags, and allow SMIL to be the 
integration language that it intends to be.

By allowing both selecting of sources, and the selected source to be 
configured, we have the expressive power we need at the HTML level, 
IMHO.


* * * * *


Much of the rest of the message discusses fragment (#) and query (?) 
syntax and use.  They are outside the scope of HTML (except for 
fragment syntax for HTML documents themselves) as query syntax is 
owned by the server hosting the resource, and interpreted there, and 
fragment syntax is owned by the MIME type of the resource and its 
user-side implementation.

Having said that, I applaud the annodex effort, and the MPEG-21 query 
format effort, (both spearheaded from Australia, for some reason) to 
establish some good norms for what could be reasonably expected of 
timed resources.

For true streams, and some resources, server-side 'time-slicing' is 
fairly easy (thing.xxx?start=10s;end=20s presents a 10 second 
resource over the link).

For many media formats, they can interpret #start=10s;end=20s, and do 
the byte-range request to get any table of contents (e.g. an MP4 
movie atom) and then the needed bytes.


-- 
David Singer
Apple/QuickTime