This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The MPEG-2 TS section has some problems: That sentence: "The order in which elementary streams are listed in the "Program Map Table" (PMT) of a MPEG-2 TS is maintained when sourcing multiple MPEG-2 tracks into HTML." should be rewritten using normative statements and should indicate what happens when PMT changes occur, as follows: "UA shall expose elementary streams as HTML Tracks in the order of the "Program Map Table" (PMT) of a MPEG-2 TS. UA shall trigger addtrack or removetrack events when PMT changes are detected." That other sentence: "A user agent recognises and supports data from a MPEG-2 TS resource as being equivalent to a HTML track based on the value of the 'stream_id' field of an elementary stream as given in a Transport or Program Stream header and which maps to a "stream type":" It refers to 'stream_id' or 'stream type'. It is unclear if those are the MPEG-2 TS 'PID', 'stream_type', 'PES stream_id' ... or if they are new terms introduced in this text. I think we should also clearly indicate that Program Streams are out-of-scope. Note also that the stream_type 0x02 is mapped twice: as a TextTrack and as a VideoTrack. The overall idea is also not very clear: - Does a UA have to expose all tracks from a TS? all tracks that have characteristics described in the table? I agree it may be desirable from an application point of view but it may be too resource consuming. Maybe we should think of a mechanism to register tracks for which the application would like data to be exposed, a bit like addSourceBuffer - Why would a UA expose data as a VideoTrack if it does not support it for rendering, e.g. ISO/IEC 14496-2 ? It should rather expose it as a TextTrack. So I think if we should if the data is supported, then it shall be exposed as VideoTrack otherwise it may be exposed as a TextTrack.
(In reply to Cyril Concolato from comment #0) > The MPEG-2 TS section has some problems: > > That sentence: > "The order in which elementary streams are listed in the "Program Map Table" > (PMT) of a MPEG-2 TS is maintained when sourcing multiple MPEG-2 tracks into > HTML." > should be rewritten using normative statements No, per agreement with [1] > and should indicate what > happens when PMT changes occur, as follows: > "UA shall expose elementary streams as HTML Tracks in the order of the > "Program Map Table" (PMT) of a MPEG-2 TS. UA shall trigger addtrack or > removetrack events when PMT changes are detected." Agreed. > > That other sentence: > "A user agent recognises and supports data from a MPEG-2 TS resource as > being equivalent to a HTML track based on the value of the 'stream_id' field > of an elementary stream as given in a Transport or Program Stream header and > which maps to a "stream type":" > It refers to 'stream_id' or 'stream type'. It is unclear if those are the > MPEG-2 TS 'PID', 'stream_type', 'PES stream_id' ... or if they are new terms > introduced in this text. I think we should also clearly indicate that > Program Streams are out-of-scope. This wording was confusing and will be changed to "A user agent recognizes and supports data in an MPEG-2 TS elementary stream identified by the 'elementary_PID' field in the Program Map Table as being equivalent to an HTML track based on the value of the 'stream_type' field associated with that 'elementary_PID'" > > Note also that the stream_type 0x02 is mapped twice: as a TextTrack and as a > VideoTrack. Are you referring to the caption service in an stream_type 0x02? That is only mapping the caption in the video stream, if present, to a text track. > > The overall idea is also not very clear: > - Does a UA have to expose all tracks from a TS? all tracks that have > characteristics described in the table? I agree it may be desirable from an > application point of view but it may be too resource consuming. Maybe we > should think of a mechanism to register tracks for which the application > would like data to be exposed, a bit like addSourceBuffer Bug 26893 was submitted to address this. TextTracks are created with mode = "disabled". No UA resources, beyond creating the track are consumed until the app changes the mode. > - Why would a UA expose data as a VideoTrack if it does not support it for > rendering, e.g. ISO/IEC 14496-2 ? It should rather expose it as a TextTrack. > So I think if we should if the data is supported, then it shall be exposed > as VideoTrack otherwise it may be exposed as a TextTrack. It is unclear what the specific problem is. [1] http://lists.w3.org/Archives/Public/public-html-admin/2014Jun/0050.html
(In reply to Bob Lund from comment #1) > (In reply to Cyril Concolato from comment #0) > > The MPEG-2 TS section has some problems: > > > > That sentence: > > "The order in which elementary streams are listed in the "Program Map Table" > > (PMT) of a MPEG-2 TS is maintained when sourcing multiple MPEG-2 tracks into > > HTML." > > should be rewritten using normative statements > > No, per agreement with [1] > > > and should indicate what > > happens when PMT changes occur, as follows: > > "UA shall expose elementary streams as HTML Tracks in the order of the > > "Program Map Table" (PMT) of a MPEG-2 TS. UA shall trigger addtrack or > > removetrack events when PMT changes are detected." > > Agreed. > > > > > That other sentence: > > "A user agent recognises and supports data from a MPEG-2 TS resource as > > being equivalent to a HTML track based on the value of the 'stream_id' field > > of an elementary stream as given in a Transport or Program Stream header and > > which maps to a "stream type":" > > It refers to 'stream_id' or 'stream type'. It is unclear if those are the > > MPEG-2 TS 'PID', 'stream_type', 'PES stream_id' ... or if they are new terms > > introduced in this text. I think we should also clearly indicate that > > Program Streams are out-of-scope. > > This wording was confusing and will be changed to "A user agent recognizes > and supports data in an MPEG-2 TS elementary stream identified by the > 'elementary_PID' field in the Program Map Table as being equivalent to an > HTML track based on the value of the 'stream_type' field associated with > that 'elementary_PID'" > > > > Note also that the stream_type 0x02 is mapped twice: as a TextTrack and as a > > VideoTrack. > > Are you referring to the caption service in an stream_type 0x02? That is > only mapping the caption in the video stream, if present, to a text track. > > > > > The overall idea is also not very clear: > > - Does a UA have to expose all tracks from a TS? all tracks that have > > characteristics described in the table? I agree it may be desirable from an > > application point of view but it may be too resource consuming. Maybe we > > should think of a mechanism to register tracks for which the application > > would like data to be exposed, a bit like addSourceBuffer > > Bug 26893 was submitted to address this. TextTracks are created with mode = > "disabled". No UA resources, beyond creating the track are consumed until > the app changes the mode. > > > - Why would a UA expose data as a VideoTrack if it does not support it for > > rendering, e.g. ISO/IEC 14496-2 ? It should rather expose it as a TextTrack. > > So I think if we should if the data is supported, then it shall be exposed > > as VideoTrack otherwise it may be exposed as a TextTrack. > > It is unclear what the specific problem is. > > > [1] http://lists.w3.org/Archives/Public/public-html-admin/2014Jun/0050.html Fixed with PR #39 https://github.com/w3c/HTMLSourcingInbandTracks/pull/39
Actually, my comment about "should" being "must" initially rejected is still valid now that the relationship with HTML5 regarding the normative/informative reference is clarified. Also, the wording "A user agent recognizes and supports data in an MPEG-2 TS elementary [...] as being equivalent to an HTML track [...]" is still very confusing to me. I'd very much prefer: "If a UA decides to expose an MPEG-2 TS elementary stream as an HTML Track, it shall expose tracks as follows [...]". This would make is clearer in terms of conformance.
Open a new bug?