[whatwg] Video feedback

[Philip Jägenstedt]

On Wed, 08 Jun 2011 13:38:18 +0200, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:

> On Wed, Jun 8, 2011 at 9:18 PM, Philip Jägenstedt <philipj at opera.com>  
> wrote:
>> 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.
>
> Hmm.. because there is nothing in the API that actually exposes audio  
> metadata?

Yes.

>> 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.
>
> You know that you can also transmit video with icecast...?

Nope :) I guess that invalidates everything I've said about Icecast.  
Practically, though, no one is using Icecast to mix audio tracks with  
audio+video tracks and getting upset that it doesn't work in browsers,  
right?

-- 
Philip Jägenstedt
Core Developer
Opera Software