[whatwg] Video feedback

[Philip Jägenstedt]

On Wed, 08 Jun 2011 12:35:24 +0200, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:

> On Wed, Jun 8, 2011 at 6:14 PM, Philip Jägenstedt <philipj at opera.com>  
> wrote:
>> On Wed, 08 Jun 2011 02:46:15 +0200, Silvia Pfeiffer
>> <silviapfeiffer1 at gmail.com> wrote:
>>
>>> That is all correct. However, because it is a sequence of Ogg streams,
>>> there are new Ogg headers in the middle. These new Ogg headers will
>>> lead to new metadata loaded in the media framework - e.g. because the
>>> new Ogg stream is encoded with a different audio sampling rate and a
>>> different video width/height etc. So, therefore, the metadata in the
>>> media framework changes. However, what the browser reports to the JS
>>> developer doesn't change. Or if it does change, the JS developer is
>>> not informed of it because it is a single infinite audio (or video)
>>> stream. Thus the question whether we need a new "metadatachange" event
>>> to expose this to the JS developer. It would then also signify that
>>> potentially the number of tracks that are available may have changed
>>> and other such information.
>>
>> 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.

OK, I don't think we disagree. I'm just saying that for Icecast audio  
streams, there is no problem.

As for Ogg and WebM, I'm inclined to say that we just shouldn't support  
that, unless there's some compelling use case for it. There's also the  
option of tweaking the muxers so that all the streams are known up-front,  
even if there won't be any data arriving for them until half-way through  
the file.

I also know nothing about MPEG or the use cases involved, so no opinions  
there.

-- 
Philip Jägenstedt
Core Developer
Opera Software