- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 16 Feb 2011 10:28:47 +1100
- To: Bob Lund <B.Lund@cablelabs.com>
- Cc: Mark Watson <watsonm@netflix.com>, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>, Glenn Adams <glenn@skynav.com>, Richard Maunder <rmaunder@cisco.com>, "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
Note that there is also an activity in the WHATWG about exposing more statistics about the media resource to JavaScript, see http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-January/030083.html . This could address the remaining issues in 4). Silvia. On Wed, Feb 16, 2011 at 8:37 AM, Bob Lund <B.Lund@cablelabs.com> wrote: > 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> 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 > >
Received on Tuesday, 15 February 2011 23:35:54 UTC