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.
The durationchange is a different type of event. It has not much to do
with having a change of a media format, but more one with getting new
information that more data is available than previously expected. It's
one that allows streaming of long video resources, even if they are
just a of a single encoding setting. In contrast what we are talking
about is that the encoding settings change mid-stream.
Cheers,
Silvia.