- From: Eric Winkelman <E.Winkelman@cablelabs.com>
- Date: Fri, 17 Dec 2010 11:23:38 -0700
On Wednesday, December 15, 2010 6:33 AM Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote: > On Wed, Dec 15, 2010 at 3:31 AM, Philip J?genstedt <philipj at opera.com> > wrote: > > On Wed, 24 Nov 2010 17:11:02 +0100, Eric Winkelman > > <E.Winkelman at cablelabs.com> wrote: > > > >> I'm investigating how TimedTracks can be used for in-band-data-tracks > >> within MPEG transport streams (used for cable television). > >> > >> In this format, the number and types of in-band-data-tracks can change > >> over time. ?So, for example, when the programming switches from a > football > >> game to a movie, an alternate language track may appear that wasn't > there > >> before. ?Later, when the programming changes again, that language track > may > >> be removed. > >> > >> It's not clear to me how these changes are exposed by the proposed > Media > >> Element events. > > > > The thinking is that you switch between different streams by setting the > > src="" attribute to point to another stream, in which case you'll get an > > emptied event along with another bunch of events. If you have a single > > source where audio/video/text streams appear and disappear, there's not > > really any way to handle it. > > I believe "in-band" was the keyword in the request. That is correct. I'm working on synchronizing JavaScript applications with video content using in-band EISS signals. > 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. 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. > In a live situation you basically don't have a choice and you have to > use chaining when your input streams change. For a canned situation > you can set up all the required tracks from the start and just have > them send data later or stop sending earlier. In the canned document > situation therefore the number of tracks does not change. It's just > that data may not be available for all the time. > > >> The "loadedmetadata" event is used to indicate that the TimedTracks are > >> ready, but it appears that it is only fired before playback begins. ?Is > >> this event fired again whenever a new track is discovered? ?Is there > >> another event that is intended for this situation? > > There is an "onload" event on the TimedTrack to indicate that a track > is finished loading. But there is no event to indicate that a new > track is available. Does the "onload" event fire on in-band tracks? My current implementation only uses the "oncuechange" event, as you can't be sure the in-band track is ever completely loaded. > >> Similarly, is there an event that indicates when a track has been > >> removed? > >> ?Or is this also handled by the "loadedmetadata" event somehow? > > No, there is no "onunload" event on the TimedTracks. It's possible that you wouldn't need to unload a TimedTrack, if empty tracks were "recycled" for new tracks as needed. I'm looking at this approach now. > > No, the loadedmetadata event is only fired once per resource, it's not > > the event you're looking for. > > > > As for actual solutions, I think that having loadedmetadata fire again > > if the number or type of streams change would make some sense. This is the way I'm currently doing this, but we're evaluating if this will cause other problems. > > -- > > Philip J?genstedt > > Core Developer > > Opera Software > > > > Cheers, > Silvia. Thanks! Eric Winkelman --- e.winkelman cablelabs.com Cable Television Laboratories, Inc.
Received on Friday, 17 December 2010 10:23:38 UTC