[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 #17 from Glenn Adams <glenn@skynav.com> 2011-10-12 00:13:22 UTC ---
(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 00:13:25 UTC