[whatwg] Video feedback

> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-
> bounces at lists.whatwg.org] On Behalf Of Eric Carlson
> Sent: Wednesday, June 08, 2011 9:34 AM
> To: Silvia Pfeiffer; Philip J?genstedt
> Cc: whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Video feedback
> 
> 
> On Jun 8, 2011, at 3:35 AM, Silvia Pfeiffer wrote:
> 
> >> Nothing exposed via the current API would change, AFAICT.
> >
> > Thus, after a change mid-stream to, say,  a smaller video width and
> > height, would the video.videoWidth and video.videoHeight attributes
> > represent the width and height of the previous stream or the current
> > one?
> >
> >
> >> I agree that if we
> >> start exposing things like sampling rate or want to support arbitrary
> >> chained Ogg, then there is a problem.
> >
> > I think we already have a problem with width and height for chained
> > Ogg and we cannot stop people from putting chained Ogg into the @src.
> >
> > I actually took this discussion away from MPEG PTM, which is where
> > Eric's question came from, because I don't understand how it works
> > with MPEG. But I can see that it's not just a problem of MPEG, but
> > also of Ogg (and possibly of WebM which can have multiple Segments).
> > So, I think we need a generic solution for it.
> >
>   The characteristics of an Apple HTTP live stream can change on the
> fly. For example if the user's bandwidth to the streaming server
> changes, the video width and height can change as the stream resolution
> is switched up or down, or the number of tracks can change when a stream
> switches from video+audio to audio only. In addition, a server can
> insert segments with different characteristics into a stream on the fly,
> eg. inserting an ad or emergency announcement.
> 
>   It is not possible to predict these changes before they occur.
> 
> eric

For commercial video providers, the tracks in a live stream change all the time; this is not limited to audio and video tracks but would include text tracks as well. 

Bob Lund

Received on Wednesday, 8 June 2011 08:57:00 UTC