[whatwg] Video feedback

[Eric Carlson]

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