[whatwg] Video feedback

> -----Original Message-----
> From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-
> bounces at lists.whatwg.org] On Behalf Of Mark Watson
> Sent: Monday, June 20, 2011 2:29 AM
> To: Eric Carlson
> Cc: Silvia Pfeiffer; whatwg Group; Simon Pieters
> Subject: Re: [whatwg] Video feedback
> 
> 
> On Jun 9, 2011, at 4:32 PM, Eric Carlson wrote:
> 
> >
> > 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.
> 
> The TrackList object has an onchanged event, which I assumed would fire
> when any of the information in the TrackList changes (e.g. tracks added
> or removed). But actually the spec doesn't state when this event fires
> (as far as I could tell - unless it is implied by some general
> definition of events called onchanged).
> 
> Should there be some clarification here ?
> 
> >
> >  I agree with Silvia, a more generic "metadata changed" event makes
> more sense.
> 
> Yes, and it should support the case in which text tracks are
> added/removed too.

Has there been a bug submitted to add a metadata changed event when video, audio or text tracks are added or deleted from a media resource?

Thanks,
Bob Lund

> 
> Also, as Eric (C) pointed out, one of the things which can change is
> which of several available versions of the content is being rendered
> (for adaptive bitrate cases). This doesn't necessarily change any of the
> metadata currently exposed on the video element, but nevertheless it's
> information that the application may need. It would be nice to expose
> some kind of identifier for the currently rendered stream and have an
> event when this changes. I think that a stream-format-supplied
> identifier would be sufficient.
> 
> ...Mark
> 
> >
> > eric
> >
> >

Received on Thursday, 7 July 2011 09:14:04 UTC