- From: Philip Jägenstedt <philipj@opera.com>
- Date: Wed, 08 Jun 2011 14:01:27 +0200
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
Received on Wednesday, 8 June 2011 05:01:27 UTC