[Bug 26927] New: [InbandTracks] MPEG-2 TS Mapping

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26927

            Bug ID: 26927
           Summary: [InbandTracks] MPEG-2 TS Mapping
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Sourcing In-band Media Resource Tracks
          Assignee: silviapfeiffer1@gmail.com
          Reporter: cyril.concolato@telecom-paristech.fr
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 29 September 2014 12:23:24 UTC