On Thu, Jun 9, 2011 at 1:57 AM, Bob Lund <[email protected]> wrote: > > >> -----Original Message----- >> From: [email protected] [mailto:whatwg- >> [email protected]] On Behalf Of Eric Carlson >> Sent: Wednesday, June 08, 2011 9:34 AM >> To: Silvia Pfeiffer; Philip Jägenstedt >> Cc: [email protected] >> 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.
OK, all this indicates to me that we probably want a "metadatachanged" event to indicate there has been a change and that JS may need to check some of its assumptions. Silvia.
