[Bug 26929] [InbandTracks] How to expose ISOBMFF Tracks

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

Bob Lund <b.lund@cablelabs.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b.lund@cablelabs.com

--- Comment #2 from Bob Lund <b.lund@cablelabs.com> ---
(In reply to Cyril Concolato from comment #0)
> 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 fact that the UA could look at other fields doesn't make the use of the
'hdlr' box wrong. ISO/IEC 14496-12:2012(E) states that the 'hdlr' box is
mandatory and "This box within a Media Box declares the process by which the
media-data in the track is presented, and thus, the nature of the media in a
track. For example, a video track would be handled by a video handler."

> 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) ?

What part the following spec text isn't clear?

text track: the 'handler_type' value is "meta", "subt" or "text"
video track: the 'handler_type' value is "soun"
audio track: the 'handler_type' value is "vide"
> 
> 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.

Please provide a reference to this amendment.

> 
> 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.

TTML and WebVTT are not carried in TS AFAIK. CEA708 is not spec'd for MP4. And
as commented on in 26921, how TTML, WebVTT, CEA-708 is identified and found is
container specific. It might make sense to centralize how Cues are created from
TTML and WebVTT content once found in the container.

> 
> 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 Thursday, 2 October 2014 21:40:25 UTC