On Jun 9, 2011, at 12:02 AM, Silvia Pfeiffer wrote: > On Thu, Jun 9, 2011 at 4:34 PM, Simon Pieters <[email protected]> wrote: >> On Thu, 09 Jun 2011 03:47:49 +0200, Silvia Pfeiffer >> <[email protected]> wrote: >> >>>> 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. >> >> We already have durationchange. Duration is metadata. If we want to support >> changes to width/height, and the script is interested in when that happens, >> maybe there should be a dimensionchange event (but what's the use case for >> changing width/height mid-stream?). Does the spec support changes to text >> tracks mid-stream? > > It's not about what the spec supports, but what real-world streams provide. > > I don't think it makes sense to put an event on every single type of > metadata that can change. Most of the time, when you have a stream > change, many variables will change together, so a single event is a > lot less events to raise. It's an event that signifies that the media > framework has reset the video/audio decoding pipeline and loaded a > whole bunch of new stuff. You should imagine it as a concatenation of > different media resources. And yes, they can have different track > constitution and different audio sampling rate (which the audio API > will care about) etc etc. > In addition, it is possible for a stream to lose or gain an audio track. In this case the dimensions won't change but a script may want to react to the change in audioTracks.
I agree with Silvia, a more generic "metadata changed" event makes more sense. eric
