- From: <bugzilla@jessica.w3.org>
- Date: Mon, 29 Sep 2014 12:36:05 +0000
- To: public-html-bugzilla@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 the QA Contact for the bug.
Received on Monday, 29 September 2014 12:36:06 UTC