[whatwg] Video feedback

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?


> 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...?

Silvia.

> 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
>

Received on Wednesday, 8 June 2011 04:38:18 UTC