- From: <bugzilla@jessica.w3.org>
- Date: Mon, 29 Sep 2014 12:36:05 +0000
- To: public-html-admin@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26929
Bug ID: 26929
Summary: [InbandTracks] How to expose ISOBMFF Tracks
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 following sentence is wrong and does not provide normative statements:
"A user agent recognises and supports data from a MPEG-4 TrackBox as being
equivalent to a HTML track based on the value of the 'handler_type' field in
the HandlerBox ('hdlr) of the MediaBox ('mdia') of the TrackBox"
It is wrong because a UA will know if it supports the decoding of a track based
on the SampleEntry (code and content) and not only on the handler type. They
might not even care about the handler type.
The sentence should be rewritten with normative statements.
Also same remark as for bug #26927, the overall picture is not clear: when
should data be exposed as VideoTrack: it shall be exposed a VideoTrack if
supported otherwise it may be exposed as TextTrack . Should all tracks be
exposed (possibly via a negotiation mechanism) ?
We might want to update the section regarding the "KindBox" and
"ExtendedLanguageBox" which are in the on-going amendment of ISOBMFF to update
the table.
Same remark as for bug #26921, the TTML and WebVTT parts should be moved in a
separate section. CEA708 and 3GPP Timed Text as well. They can be carried in TS
or in MP4 or else.
I will provide updated text for all these changes.
Note: the whole section is also applicable to the MIME "application/mp4", which
may carry metadata only tracks.
--
You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 29 September 2014 12:36:06 UTC