Re: Notify user agent available fragment

Dear Jeroen,

> Pardon my ignorance if this question was already addressed. There seems
> to be no reference in the working draft, but I realize you could
> consider this topic out of scope.

I will just complement Jack and Davy answers. the issue you mentioned is 
not completely out of scope of the group but it will not be directly and 
totally addressed by the group.

> How do you see the user-agent being notified in advance of the
> fragmentation possibilities of a certain resource?

As Jack said, this is the problem of discovery, and as Davy rightly 
pointed out, if you are concerned of how a UA can know in advance which 
tracks (if any) are available in a media resource, then there are at 
least two ways:
   - use the Media Multitrack Javascript API developed by the 
accessibility task force of the HTML5 WG, 
http://www.w3.org/WAI/PF/HTML/wiki/Media_MultitrackAPI
   - try to get a description of the media, using for example the Media 
Ontology API, http://www.w3.org/TR/mediaont-10/
Note that these 2 approaches migh converge in a close future ...

> As a second example, that first video
> might have a VIDEO track with keyframe-interval of two seconds and the
> second video might have a VIDEO track with keyframe-interval of four
> seconds. The server might not be able to return a 2-second fragment of
> the second video without transcoding (which should be avoided).

For your second example, this falls more into the work of the WG. 
Requesting a media fragment does not mean you will receive exactly this 
media fragment! The server will follow a best approach (for example 
seeking to the previous/next I-frame). However, the server will also 
specify in its reply what are the actual time ranges it is serving. 
Consequently, the UA will then be free to either playing a slightly 
longer sequence, or freeze during the non-expected seconds and just play 
what the user has requested.

> User agents would like to have this exact information in advance,
> without relying on fallback actions (e.g. the server returning an error
> in the first example and a 4-second fragment in the second example).

If a user is requesting a track that does not exist, or cannot be 
extracted, I think the WG will prefer to send the full media resource 
rather than a 4xx, but this is still subject of discussion. We would be 
also happy to hear from the developer community what do they think.
Best regards.

   Raphaël

-- 
Raphaël Troncy
EURECOM, Multimedia Communications Department
2229, route des Crêtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Monday, 3 May 2010 14:50:56 UTC