[whatwg] Video feedback

On Wed, 08 Jun 2011 02:46:15 +0200, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:

> On Tue, Jun 7, 2011 at 7:04 PM, Philip J?genstedt <philipj at opera.com>  
> wrote:
>> On Sat, 04 Jun 2011 03:39:58 +0200, Silvia Pfeiffer
>> <silviapfeiffer1 at gmail.com> wrote:
>>
>>
>>> On Fri, Jun 3, 2011 at 9:28 AM, Ian Hickson <ian at hixie.ch> wrote:
>>>>
>>>> On Thu, 16 Dec 2010, Silvia Pfeiffer wrote:
>>>>>
>>>>> I do not know how technically the change of stream composition works  
>>>>> in
>>>>> MPEG, but in Ogg we have to end a current stream and start a new one  
>>>>> to
>>>>> switch compositions. This has been called "sequential multiplexing"  
>>>>> or
>>>>> "chaining". In this case, stream setup information is repeated, which
>>>>> would probably lead to creating a new steam handler and possibly a  
>>>>> new
>>>>> firing of "loadedmetadata". I am not sure how chaining is  
>>>>> implemented in
>>>>> browsers.
>>>>
>>>> Per spec, chaining isn't currently supported. The closest thing I can
>>>> find
>>>> in the spec to this situation is handling a non-fatal error, which  
>>>> causes
>>>> the unexpected content to be ignored.
>>>>
>>>>
>>>> On Fri, 17 Dec 2010, Eric Winkelman wrote:
>>>>>
>>>>> The short answer for changing stream composition is that there is a
>>>>> Program Map Table (PMT) that is repeated every 100 milliseconds and
>>>>> describes the content of the stream.  Depending on the programming,  
>>>>> the
>>>>> stream's composition could change entering/exiting every  
>>>>> advertisement.
>>>>
>>>> If this is something that browser vendors want to support, I can  
>>>> specify
>>>> how to handle it. Anyone?
>>>
>>> Icecast streams have chained files, so streaming Ogg to an audio
>>> element would hit this problem. There is a bug in FF for this:
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=455165 (and a duplicate
>>> bug at https://bugzilla.mozilla.org/show_bug.cgi?id=611519). There's
>>> also a webkit bug for icecast streaming, which is probably related
>>> https://bugs.webkit.org/show_bug.cgi?id=42750 . I'm not sure how Opera
>>> is able to deal with icecast streams, but it seems to deal with it.
>>>
>>> The thing is: you can implement playback and seeking without any
>>> further changes to the spec. But then the browser-internal metadata
>>> states will change depending on the chunk you're on. Should that also
>>> update the exposed metadata in the API then? Probably yes, because
>>> otherwise the JS developer may deal with contradictory information.
>>> Maybe we need a "metadatachange" event for this?
>>
>> An Icecast stream is conceptually just one infinite audio stream, even
>> though at the container level it is several chained Ogg streams.  
>> duration
>> will be Infinity and currentTime will be constantly increasing. This  
>> doesn't
>> seem to be a case where any spec change is needed. Am I missing  
>> something?
>
>
> 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. I agree that if  
we start exposing things like sampling rate or want to support arbitrary  
chained Ogg, then there is a problem.

-- 
Philip J?genstedt
Core Developer
Opera Software

Received on Wednesday, 8 June 2011 01:14:31 UTC