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.

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

Reply via email to