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

I agree, it does not seem essential. The server side could merely send the
same info down via WebSockets or even by making use of a metadata timed text
track.

Regards,
Glenn Adams

On Mon, Feb 21, 2011 at 1:50 PM, Mark Watson <watsonm@netflix.com> wrote:

>
> On Feb 21, 2011, at 1:09 AM, Jan Lindquist wrote:
>
> >
> >
> > - There is a means of retrieving the available representations (from min
> to max) and the current representation.
> >
> > I'm not sure why this would be needed ?
> > [JLI>] This is the range of streams and the available "bandwidths". So
> you get a list of what is available and which one is being used.
> >
> > By why? What would you use that list for ?
> >
> > JLI> The purpose is to be able for an application to keep track of the
> available levels and to keep track of the current selected level. The timing
> for the content provider to keep track of the available levels makes it
> tricky to have an accurate view of the player. I could then show a layered
> bars each bar representating a bandwidth (id) and it can change as the
> content is being viewed. It can give a good user experience to know what is
> going on with the content similar to know the status of my WiFi connection.
> >
>
> I'm wary of saying this is as simple as exposing the available bandwidths,
> especially since the bandwidth figure is defined in terms of the
> minBufferTime and so is meaningless without it. If I have two streams, with
> ( minBufferTime, bandwidth ) pairs of ( 1s, 1000kbit/s ) and ( 2s, 900kbit/s
> ), which has higher quality ?
>
> If the requirement is just for displaying "signal strength bars" to the
> user, then it seems not to be essential - a service can always do this
> itself based on the @id. I think some better notion of quality would be
> needed to have a service-independent implementation.
>
> ...Mark
>
>
> > ...Mark
> >
> > ...Mark
> >
> >
> > Regards,
> > JanL
> >
> > ________________________________
> > From: public-web-and-tv-request@w3.org<mailto:
> public-web-and-tv-request@w3.org> [mailto:public-web-and-tv-request@w3.org]
> On Behalf Of Mark Watson
> > Sent: den 16 februari 2011 07:11
> > To: Glenn Adams
> > Cc: Philippe Le Hegaret; Ali C. Begen (abegen); Silvia Pfeiffer;
> Jean-Claude Dufourd; Richard Maunder (rmaunder); public-web-and-tv@w3.org
> <mailto:public-web-and-tv@w3.org>
> > Subject: Re: HTML5 Last Call May 2011 & DASH/Adaptive Streaming
> >
> > What I think would be useful, though, would be to specify that *if* DASH
> (say) is supported by an HTML5 video implementation *then* is should be done
> in a specific way.
> >
> > Otherwise we have the prospect of multiple different implementations
> supporting different things.
> >
> > For the examples you give below, it is at least clear what you support if
> you support a certain version of ECMAScript, say.
> >
> > For DASH used in HTML5 a minimal set of things that should be nailed down
> are:
> > - that a URL for a DASH manifest can be provided in the @src or <source>
> element
> > - what error should be reported if the manifest is invalid, or if the
> media it points to cannot be found
> > - how to label DASH tracks so that the different kinds of track map to
> the Multi-Track API (or whatever is agreed for ISSUE-152) and a single way
> to do the mapping
> > - what event to use to report automatic bitrate changes
> >
> > This is pretty basic stuff, but it would help if everyone that does it,
> does it the same way.
> >
> > ...Mark
> >
> >
> > On Feb 15, 2011, at 5:33 PM, Glenn Adams wrote:
> >
> > For that matter, HTML5 does not require a UA to support either the HTML
> syntax of HTML5 or the XML syntax of HTML5. A compliant HTML5 UA could
> support neither (albeit with little utility).
> >
> > HTML5 does *not* specify:
> >
> > *   which top-level document types must be supported
> > *   which version of ECMAScript must be supported
> > *   which version/modules of CSS must be supported
> > *   which version/modules of DOM must be supported
> > *   which URI schemes (protocols) must be supported
> > *   which non-streaming media types must be supported
> > *   which streaming media types must be supported
> >
> > HTML5 is a technology framework specification that requires other
> specifications (profiles) to fill in these gaps. In the context of certain
> TV standardization activities, such work to define one or more profiles is
> already underway.
> >
> > N.B. I am not criticizing HTML5 for not making such choices. In fact, I
> think the editor and group has taken the best approach in that regard.
> >
> > G.
> >
> > On Tue, Feb 15, 2011 at 5:59 PM, Philippe Le Hegaret <plh@w3.org<mailto:
> plh@w3.org>> wrote:
> > On Tue, 2011-02-15 at 18:40 -0500, Ali C. Begen (abegen) 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.
> >
> > My understanding is that the IP issues surrounding the codec types are
> > also surrounding the container formats and the streaming technologies.
> > So, I'd be surprised if any agreement was reached within the HTML
> > Working Group on those topics. I can't imagine a different conclusion
> > that the H.264/Theora discussion at this point. In any case, as Glenn
> > alluded to, HTML has been technology neutral since the beginning. Unless
> > I'm mistaken, we don't require implementations to support a specific
> > image format.
> >
> > Philippe
> >
> >
> >
> >
> >
> >
> >
>
>