On Wed, 08 Jun 2011 13:38:18 +0200, Silvia Pfeiffer
<silviapfeiff...@gmail.com> wrote:
On Wed, Jun 8, 2011 at 9:18 PM, Philip Jägenstedt <phil...@opera.com>
wrote:
On Wed, 08 Jun 2011 12:35:24 +0200, Silvia Pfeiffer
<silviapfeiff...@gmail.com> wrote:
On Wed, Jun 8, 2011 at 6:14 PM, Philip Jägenstedt <phil...@opera.com>
wrote:
On Wed, 08 Jun 2011 02:46:15 +0200, Silvia Pfeiffer
<silviapfeiff...@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
