Re: Notify user agent available fragment

Dear all,

Thanks for your replies. Overall, it looks like the core issue I  
raised is (and should) not be addressed by the Media Fragments  
workgroup.

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

Excellent, thanks for this information. It seems that, at present, the  
Media Multitrack API intends to provide this functionality. It is more  
aimed at the technical details of a resource whereas the Ontology API  
focuses more on describing the information provided in the resource.

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

Yes, that makes sense.  Especially when the server will include a  
descriptive Range header as described in the draft. The user-agent  
then immediately knows what it has received, and has full flexibility  
to do whatever it wants.

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

I personally think it would be good to do return a 4xx error (out of  
range?) when the requested data entirely lies outside the range of the  
mediafile:

* An audiotrack is requested for a mediafile that only contains video.
* A fragment from 50 to 60 seconds is requested for a mediafile that  
is only 30 seconds in length.
* A region from 400x300 to 600x300 is requested for an image that is  
only 200x300 in size.

In each of these cases I'd presume the full mediafile has little value  
to the user agent (why video if I requested audio? why 0-30s if I  
requested 50-60s? it's the wrong data and I either cannot or don't  
want to present it to the user.). Returning the entire resource by  
default would seem to generate a lot of traffic for data that will  
likely not be used. In case of the error, the user agent can always  
fallback to a request for the full resource in such rare cases it does  
want it.

Kind regards,

Jeroen

Received on Wednesday, 5 May 2010 14:37:27 UTC