[whatwg] Video feedback

[Silvia Pfeiffer]

On Thu, Jun 9, 2011 at 1:57 AM, Bob Lund <B.Lund at cablelabs.com> wrote:
>
>
>> -----Original Message-----
>> From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-
>> bounces at lists.whatwg.org] On Behalf Of Eric Carlson
>> Sent: Wednesday, June 08, 2011 9:34 AM
>> To: Silvia Pfeiffer; Philip Jägenstedt
>> Cc: whatwg at lists.whatwg.org
>> Subject: Re: [whatwg] Video feedback
>>
>>
>> On Jun 8, 2011, at 3:35 AM, Silvia Pfeiffer wrote:
>>
>> >> Nothing exposed via the current API would change, AFAICT.
>> >
>> > Thus, after a change mid-stream to, say,  a smaller video width and
>> > height, would the video.videoWidth and video.videoHeight attributes
>> > represent the width and height of the previous stream or the current
>> > one?
>> >
>> >
>> >> I agree that if we
>> >> start exposing things like sampling rate or want to support arbitrary
>> >> chained Ogg, then there is a problem.
>> >
>> > I think we already have a problem with width and height for chained
>> > Ogg and we cannot stop people from putting chained Ogg into the @src.
>> >
>> > I actually took this discussion away from MPEG PTM, which is where
>> > Eric's question came from, because I don't understand how it works
>> > with MPEG. But I can see that it's not just a problem of MPEG, but
>> > also of Ogg (and possibly of WebM which can have multiple Segments).
>> > So, I think we need a generic solution for it.
>> >
>>   The characteristics of an Apple HTTP live stream can change on the
>> fly. For example if the user's bandwidth to the streaming server
>> changes, the video width and height can change as the stream resolution
>> is switched up or down, or the number of tracks can change when a stream
>> switches from video+audio to audio only. In addition, a server can
>> insert segments with different characteristics into a stream on the fly,
>> eg. inserting an ad or emergency announcement.
>>
>>   It is not possible to predict these changes before they occur.
>>
>> eric
>
> 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.

Silvia.