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

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

--- Comment #3 from Cyril Concolato <cyril.concolato@telecom-paristech.fr> ---
(In reply to Bob Lund from comment #2)
> (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."
What you cite does not describe the full process. The sentence in the sourcing
spec is wrong because it is incomplete and because knowing the track is a video
does not tell you if it's AVC or HEVC. Actually, the same sample entry could be
used with different handler, and you'd still be able to process it because that
is the SampleEntry that defines the track format (not the handler). The handler
is just a very limited indication. 

>  
> > 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"
I meant: Should a UA expose a track it does not understand? 

> > 
> > 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.
The reference is: ISO/IEC 14496-12:2012/DAM 4. This draft is available here:
http://mpeg.chiariglione.org/sites/default/files/files/standards/parts/docs/w14574-v2-w14574.zip

> 
> > 
> > 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. 
Sorry, I should have said "could". The could be in WebM, Ogg, or whatever. My
point here is that it should be out of the MP4 section. MP4 defines how to get
the WebVTT file back so our purpose, we can just say the same processing as for
WebVTT out-of-MP4 but in MPD applies.

> CEA708 is not spec'd for MP4.
I think Apple has a spec for that. We've had request to support it in GPAC.


> 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.
Yes, please!

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

Received on Wednesday, 8 October 2014 20:10:56 UTC