- From: Eric Carlson <eric.carlson@apple.com>
- Date: Thu, 09 Jun 2011 07:32:49 -0700
On Jun 9, 2011, at 12:02 AM, Silvia Pfeiffer wrote: > On Thu, Jun 9, 2011 at 4:34 PM, Simon Pieters <simonp at opera.com> wrote: >> On Thu, 09 Jun 2011 03:47:49 +0200, Silvia Pfeiffer >> <silviapfeiffer1 at gmail.com> 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
Received on Thursday, 9 June 2011 07:32:49 UTC