- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 16 Feb 2011 10:45:22 +1100
- To: "Ali C. Begen (abegen)" <abegen@cisco.com>
- Cc: Glenn Adams <glenn@skynav.com>, Jean-Claude Dufourd <jean-claude.dufourd@telecom-paristech.fr>, "Richard Maunder (rmaunder)" <rmaunder@cisco.com>, public-web-and-tv@w3.org
The choice should be at the mime type level, not at the codec level IMO. Silvia. On Wed, Feb 16, 2011 at 10:40 AM, Ali C. Begen (abegen) <abegen@cisco.com> wrote: > I think folks need to agree on the container format not the codec type. A good container format will be good for several codecs that exist today and will yet to come. > > -acbegen > > On Feb 15, 2011, at 6:33 PM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote: > >> I am increasingly thinking that even if we agree between browser >> vendors on a common baseline codec, we will not want to restrict HTML5 >> to just deal with that codec, so the notion of alternative resources >> will continue into the future, making it possible to even introduce >> new codecs in the future. This then raises the question whether for >> RTC there needs to be some kind of negotiation between the involved >> browsers of users as to agree on a codec that they all support for the >> duration of a RTC (and possibly other parameters, of course). >> >> This reminds me of similar negotiations happening between a HTTP >> client and server on mime types in which content should be delivered. >> Maybe it is possible to build on that. >> >> Cheers, >> Silvia. >> >> >> On Wed, Feb 16, 2011 at 5:20 AM, Glenn Adams <glenn@skynav.com> wrote: >>> I would not argue with your premise, but it is out of the question I think >>> whether such a baseline would be included in HTML5. The best you might hope >>> for (IMO) is an informative reference and an example usage shown in the spec >>> text. But even that is unlikely to be attractive to the HTML5 editor. >>> G. >>> >>> On Tue, Feb 15, 2011 at 11:11 AM, Ali C. Begen (abegen) <abegen@cisco.com> >>> wrote: >>>> >>>> I see a certain value for offering a baseline adaptive streaming client as >>>> part of the html5 standard. At the end, if all the vendors will eventually >>>> converge to what DASH spec offers, a baseline client would only accelerate >>>> this convergence. A common client across different browsers and platforms >>>> will make life easier for many of us. >>>> >>>> As long as the wg also includes provisions for parameterization of the >>>> baseline client through an API (scripting or something else), one can still >>>> customize the behavior of the player. Making all this codec independent is >>>> of course highly desirable. >>>> >>>> -acbegen >>>> >>>>> -----Original Message----- >>>>> From: public-web-and-tv-request@w3.org >>>>> [mailto:public-web-and-tv-request@w3.org] On Behalf Of Jean-Claude Dufourd >>>>> Sent: Tuesday, February 15, 2011 12:57 PM >>>>> To: Glenn Adams >>>>> Cc: Richard Maunder (rmaunder); public-web-and-tv@w3.org >>>>> Subject: Re: HTML5 Last Call May 2011 & DASH/Adaptive Streaming >>>>> >>>>> 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:46:15 UTC