[Bug 13358] <video> also fire a 'change' event at VideoTrackList, AudioTrackList, and TextTrackList objects when their list of tracks changes

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13358

--- Comment #18 from Bob Lund <b.lund@cablelabs.com> 2011-10-12 18:31:21 UTC ---
I think for the MPEG-2 TS case we can safely, and should, ignore the
multi-program transport stream (MPTS) case (where the program association table
PAT comes into play). The HTMLMediaElement models the MPEG-2 single program TS
(SPTS): a media resource (MPEG-2 program) with multiple tracks (MPEG-2
elementary streams). There is no HTML5 corollary to a MPTS. Also, the IP
delivery network provides a program multiplexing scheme that would seem to
obviate the need for the equivalent function of the MPTS.

With regards to the detecting tracks that are removed, it seems that the UA
will already have the necessary information to do this. Consider an MPEG-2 SPTS
case: the program map table (PMT) has to be accessed by the UA codec so it can
locate the video/audio elementary streams to play the media resource. The PMT
has the complete description of tracks (packet IDs in MPEG-2 parlance) that are
available. The PMT will change when a track is added or deleted and so the UA
can detect that. My understanding is the WebM and Ogg have the equivalent
structure of the PMT. With regards to tracks in the program, the PMT, or
equivalent, is analogous to the manifest file used with adaptive bit rate
delivery methods.

Bob

(In reply to comment #17)
> (In reply to comment #16)
> > The current approach implies an
> > ever-growing track list and I wonder if we really should delete the "dead" ones
> > in some way.
> 
> In a typical broadcast stream, e.g., MPEG-2 TS, there are two kinds of
> significant changes that affect the existing track collection:
> 
> (1) the addition, change, or removal of entries from a PMT (program map table)
> whose content is being presented, where each entry is effectively a video,
> audio, or data (everything else) track, i.e., an Elementary Stream (ES);
> 
> (2) the addition, change, or removal of entries from the PAT (program
> association table), where each entry points at a PMT (via its PID);
> 
> Starting with case (2), removal of or change of PID for the current presenting
> PMT should cause a removal event for all tracks, followed by an add event for
> all tracks in the new PMT (if one exists). One may not exist if the current PMT
> is the only PMT, and it is removed from the PAT without adding a new PMT.
> 
> Then for case (1), removal of or change of an elementary stream entry for the
> current presenting PMT should cause a removal for the affected track, followed
> by an add if it is replaced by a new elementary stream PID.
> 
> If the only change in the TS is that the the content delivered in the currently
> presenting ESs of the currently presenting PMT changes, e.g., due to a splice
> but without changing the PID #s, then there would be no way to detect that
> change absent of some other form of metadata.
> 
> For client side code to maintain a coherent model of track collection, I don't
> see a reasonable way (or need) to avoid some form of remove track event.
> Defining HTML5 video behavior without fully plumbing the actual practice will
> likely prove a problem in the future if an over-simplistic approach is adopted
> (e.g., ignoring track removal).

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 12 October 2011 18:31:32 UTC