RE: HTML5 Last Call May 2011 & DASH/Adaptive Streaming

There are several "features" that have been referenced that are really orthogonal to each other.


1)    Exposing alternate media and text tracks for "display". The multi-track media API discussion would cover these in a media format independent way. As noted, a proposal is due by 2/21.

2)    Exposing timed text data (or metadata) to a JavaScript. This is done in HTML5 with "Timed Text Tracks"

3)    Various playback controls, e.g. fast forward, rewind, seek. The current <video> controls appear to be adequate in this regard

4)    Access to DASH (or other adaptive bit rate format) tracks. Here we need to distinguish between tracks of the same media at different bit rates and additional (to the media) tracks. The latter are addressed in 1) and 2) above. The former, access to the different bit-rates is not exposed by any adaptive bit-rate player that I'm aware of. The player makes the determination of the optimal playback rate and uses the URN in the manifest file to retrieve content at that rate. At least one service provider has noted it would be useful to have JavaScript control over the delivery bit-rate. This could be accomplished by exposing the different bit-rates as tracks via 1) above. The track could be labeled by bit-rate and no URN information would have to be exposed.

The adaptive bit-rate delivery issue applies to all adaptive bit-rate formats, not just DASH. It would be good if was solved in a general way.

Regards,
Bob Lund
CableLabs
From: public-web-and-tv-request@w3.org [mailto:public-web-and-tv-request@w3.org] On Behalf Of Mark Watson
Sent: Tuesday, February 15, 2011 11:21 AM
To: Jean-Claude Dufourd
Cc: Glenn Adams; Richard Maunder; public-web-and-tv@w3.org
Subject: Re: HTML5 Last Call May 2011 & DASH/Adaptive Streaming

Discussion on handling multi-track media is already underway on both whatwg and HMLT5 lists. See for example Jeroen's post: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-February/030454.html

I think the intention is to include a solution to this. The deadline for solution proposals is 21 February.

This would address choice of language, subtitles, views and accessibility tracks. One issue is that DASH has a flexible labeling scheme for track types based on URNs, wheras the assumption in the HTML discussions is to use a defined list of track types. Personally I think a reasonable resolution of this would be to define URNs for the HTML-specified types and leave it at that (rather than the opposite approach of persuading HTML to expose URN types from DASH.)

Regarding trick modes, I am not sure what is missing ? The HTML5 media element has a "playbackRate" attribute which can be used to play at different rates, forwards or backwards.

...Mark





On Feb 15, 2011, at 9:56 AM, Jean-Claude Dufourd wrote:


There is no question of including DASH technology in HTML5, just means to control DASHed media.
What some participants of the workshop defended was the inclusion of a way to deal, within HTML5, with various options offered by DASH, such as choice of bit-rate, audio, subtitles, as well as support for trick modes (a.k.a. VCR-like controls).
One possible solution is to add element/attribute syntax around the video object to allow that kind of control. Another solution is to add script APIs.
Best regards
JC

On 15/2/11 18:38 , Glenn Adams wrote:
Even if it were done today, I doubt very much they would reference it from the HTML5 spec. There just isn't a strong reason to do so. Besides, they have chosen a technology neutral position with respect to both stream media formats and transports.

Glenn Adams
On Tue, Feb 15, 2011 at 8:56 AM, Richard Maunder <rmaunder@cisco.com<mailto:rmaunder@cisco.com>> wrote:
Hi,

Interesting session in Berlin last week, thanks to all involved.

While we wait from the IG process & tools to form, I was interested in the implications of the HTML5 Last Call for May, especially the window for getting any DASH baseline or other adaptive streaming requirement into the spec:

http://www.w3.org/2011/02/htmlwg-pr.html

I'm not very familiar with the W3C processes, but my reading of them suggests it would be unlikely in this round if not in the spec by May?

Any thoughts on this?

Best wishes

Richard

Legal boilerplate follows.....
Any views or opinions expressed are solely those of the author and do not necessarily represent those of Cisco.






--

JC Dufourd

Directeur d'Etudes/Professor

Groupe Multimedia/Multimedia Group

Traitement du Signal et Images/Signal and Image Processing

Telecom ParisTech, 46 rue Barrault, 75 013 Paris, France

Tel: +33145817733 - Mob: +33677843843 - Fax: +33145817144