This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 24997 - Add "Return values for Text.kind" table
Summary: Add "Return values for Text.kind" table
Status: RESOLVED FIXED
Alias: None
Product: HTML WG
Classification: Unclassified
Component: CR HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Silvia Pfeiffer
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
: 23362 25044 (view as bug list)
Depends on:
Blocks: 25132
  Show dependency treegraph
 
Reported: 2014-03-10 21:56 UTC by Bob Lund
Modified: 2014-06-06 04:46 UTC (History)
7 users (show)

See Also:


Attachments

Description Bob Lund 2014-03-10 21:56:40 UTC
Use cases for setting @kind for in-band text tracks for several media resources have been identified in the in-band tracks community group [1]. [2] shows a new table  "Return values for Text.kind() to be added in step 2 of [3].

[1] https://www.w3.org/community/inbandtracks/wiki/Main_Page
[2] https://www.w3.org/community/inbandtracks/wiki/Main_Page#Text_kind_table
[3] http://www.w3.org/TR/html5/embedded-content-0.html#sourcing-in-band-text-tracks
Comment 1 Philip Jägenstedt 2014-03-11 09:00:03 UTC
Should say TextTrack.kind?
Comment 2 Bob Lund 2014-03-12 19:48:14 UTC
Yes. I had copied the table caption from the audio/video kind table. That also should say Video.kind and Audio.kind?

(In reply to Philip Jägenstedt from comment #1)
> Should say TextTrack.kind?
Comment 3 Philip Jägenstedt 2014-03-13 02:30:12 UTC
The kind attributes are TextTrack.kind, AudioTrack.kind and VideoTrack.kind:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#audiotrack
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#videotrack
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#texttrack

Also note that the wiki says "kind()" which would be a function, but kind isn't a function, it's a readonly attribute.

I hope that helps :)
Comment 4 Bob Lund 2014-03-13 22:29:36 UTC
I fixed up the Wiki page. Someone might also want to change this table caption http://www.w3.org/TR/html5/embedded-content-0.html#dom-TrackList-getKind-categories

(In reply to Philip Jägenstedt from comment #3)
> The kind attributes are TextTrack.kind, AudioTrack.kind and VideoTrack.kind:
> 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-
> element.html#audiotrack
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-
> element.html#videotrack
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-
> element.html#texttrack
> 
> Also note that the wiki says "kind()" which would be a function, but kind
> isn't a function, it's a readonly attribute.
> 
> I hope that helps :)
Comment 5 Silvia Pfeiffer 2014-03-17 05:33:18 UTC
I have prepared a patch for this in a branch at https://github.com/w3c/html/commit/f91c1932220ab4272d2b2b4e6c9f3679251fefa1 .

Could you please check that this is all correct, in particular for MPEG-2, MPEG-4 and DASH (I checked Ogg and WebM and am quite confident on those). 

Further:

* In bug 25044 you're requesting some similar specifications for setting the id, label and language on AudioTrack and VideoTrack. Is that identical to the TextTrack settings for these attributes?

* Please particularly check the @kind settings for MPEG-2, MPEG-4 and DASH. MPEG-2 and MPEG-4 sound particularly restrictive, e.g. there is no fallback to @kind=metadata.
Comment 6 Bob Lund 2014-03-17 16:10:56 UTC
(In reply to Silvia Pfeiffer from comment #5)
> I have prepared a patch for this in a branch at
> https://github.com/w3c/html/commit/f91c1932220ab4272d2b2b4e6c9f3679251fefa1 .
> 
> Could you please check that this is all correct, in particular for MPEG-2,
> MPEG-4 and DASH (I checked Ogg and WebM and am quite confident on those).

For MPEG-4 metadata text track, you've used a list of sample entry codes instead of 'meta' handler type. Beyond, 'mett' and 'metx', I do not know if this list is accurate or not.

The table for setting text track kind, label and language looks good. 

> 
> Further:
> 
> * In bug 25044 you're requesting some similar specifications for setting the
> id, label and language on AudioTrack and VideoTrack. Is that identical to
> the TextTrack settings for these attributes?

Yes, the rules for setting id, label and language should apply to audio and video as well as text tracks.

> 
> * Please particularly check the @kind settings for MPEG-2, MPEG-4 and DASH.
> MPEG-2 and MPEG-4 sound particularly restrictive, e.g. there is no fallback
> to @kind=metadata.

For MPEG-2 TS there are many many non-audio/video stream types beyond those explicitly identified as metadata (0x05, 0x80 - 0xff), with no identified use case for exposing them to script.

For MPEG-4, it seems that all metadata tracks would be identified by a handler type of 'meta'. Is there a use case where that is not so?
Comment 7 Bob Lund 2014-03-17 22:40:52 UTC
(In reply to Bob Lund from comment #6)
> (In reply to Silvia Pfeiffer from comment #5)
> > I have prepared a patch for this in a branch at
> > https://github.com/w3c/html/commit/f91c1932220ab4272d2b2b4e6c9f3679251fefa1 .
> > 
> > Could you please check that this is all correct, in particular for MPEG-2,
> > MPEG-4 and DASH (I checked Ogg and WebM and am quite confident on those).
> 
> For MPEG-4 metadata text track, you've used a list of sample entry codes
> instead of 'meta' handler type. Beyond, 'mett' and 'metx', I do not know if
> this list is accurate or not.
> 
> The table for setting text track kind, label and language looks good. 

While the phrase "contain private sections ("payload_unit_start_indicator" == 1)" for identifying an MPEG-2 TS metadata text track is technically correct, it requires the UA to wait for private section before creating the text track.

It might be more simple for the UA to create a metadata text track for MPEG-2 TS stream_type 0x05, 0x80 - 0xff without waiting for a private section indicated by a payload_unit_start_indicator == 1. If none are ever received, no private section cues would ever be created.

> 
> > 
> > Further:
> > 
> > * In bug 25044 you're requesting some similar specifications for setting the
> > id, label and language on AudioTrack and VideoTrack. Is that identical to
> > the TextTrack settings for these attributes?
> 
> Yes, the rules for setting id, label and language should apply to audio and
> video as well as text tracks.
> 
> > 
> > * Please particularly check the @kind settings for MPEG-2, MPEG-4 and DASH.
> > MPEG-2 and MPEG-4 sound particularly restrictive, e.g. there is no fallback
> > to @kind=metadata.
> 
> For MPEG-2 TS there are many many non-audio/video stream types beyond those
> explicitly identified as metadata (0x05, 0x80 - 0xff), with no identified
> use case for exposing them to script.
> 
> For MPEG-4, it seems that all metadata tracks would be identified by a
> handler type of 'meta'. Is there a use case where that is not so?
Comment 8 Silvia Pfeiffer 2014-03-18 10:50:20 UTC
*** Bug 25044 has been marked as a duplicate of this bug. ***
Comment 9 Silvia Pfeiffer 2014-03-18 11:28:03 UTC
(In reply to Bob Lund from comment #6)
> For MPEG-4 metadata text track, you've used a list of sample entry codes
> instead of 'meta' handler type. Beyond, 'mett' and 'metx', I do not know if
> this list is accurate or not.

I went through the list at https://www.w3.org/community/inbandtracks/wiki/Main_Page#ISOBMFF_2 and picked all those that were marked as "TextTrack". This is about how to identify that a track is indeed a text track, so if that's wrong, let me know what else I should write.


> For MPEG-2 TS there are many many non-audio/video stream types beyond those
> explicitly identified as metadata (0x05, 0x80 - 0xff), with no identified
> use case for exposing them to script.

If these are not sufficient, can you please let me know how to identify a text track of kind @metadata in MPEG-2 TS.

> For MPEG-4, it seems that all metadata tracks would be identified by a
> handler type of 'meta'. Is there a use case where that is not so?

That's what the patch says, too.
Comment 10 Bob Lund 2014-03-18 14:55:25 UTC
(In reply to Bob Lund from comment #7)
> (In reply to Bob Lund from comment #6)
> > (In reply to Silvia Pfeiffer from comment #5)
> > > I have prepared a patch for this in a branch at
> > > https://github.com/w3c/html/commit/f91c1932220ab4272d2b2b4e6c9f3679251fefa1 .
> > > 
> > > Could you please check that this is all correct, in particular for MPEG-2,
> > > MPEG-4 and DASH (I checked Ogg and WebM and am quite confident on those).
> > 
> > For MPEG-4 metadata text track, you've used a list of sample entry codes
> > instead of 'meta' handler type. Beyond, 'mett' and 'metx', I do not know if
> > this list is accurate or not.
> > 
> > The table for setting text track kind, label and language looks good. 
> 
> While the phrase "contain private sections ("payload_unit_start_indicator"
> == 1)" for identifying an MPEG-2 TS metadata text track is technically
> correct, it requires the UA to wait for private section before creating the
> text track.
> 
> It might be more simple for the UA to create a metadata text track for
> MPEG-2 TS stream_type 0x05, 0x80 - 0xff without waiting for a private
> section indicated by a payload_unit_start_indicator == 1. If none are ever
> received, no private section cues would ever be created.

I think the UA should create the metadata text track for these stream_types and NOT wait for packets to determine the payload_unit_start_indicator; script will know what to expect.

So, the specific change is at line 33161 in https://github.com/w3c/html/commit/f91c1932220ab4272d2b2b4e6c9f3679251fefa1. Drop the text "contain private sections ("payload_unit_start_indicator" == 1)"

> 
> > 
> > > 
> > > Further:
> > > 
> > > * In bug 25044 you're requesting some similar specifications for setting the
> > > id, label and language on AudioTrack and VideoTrack. Is that identical to
> > > the TextTrack settings for these attributes?
> > 
> > Yes, the rules for setting id, label and language should apply to audio and
> > video as well as text tracks.
> > 
> > > 
> > > * Please particularly check the @kind settings for MPEG-2, MPEG-4 and DASH.
> > > MPEG-2 and MPEG-4 sound particularly restrictive, e.g. there is no fallback
> > > to @kind=metadata.
> > 
> > For MPEG-2 TS there are many many non-audio/video stream types beyond those
> > explicitly identified as metadata (0x05, 0x80 - 0xff), with no identified
> > use case for exposing them to script.
> > 
> > For MPEG-4, it seems that all metadata tracks would be identified by a
> > handler type of 'meta'. Is there a use case where that is not so?
Comment 11 Bob Lund 2014-03-18 15:26:36 UTC
(In reply to Silvia Pfeiffer from comment #9)
> (In reply to Bob Lund from comment #6)
> > For MPEG-4 metadata text track, you've used a list of sample entry codes
> > instead of 'meta' handler type. Beyond, 'mett' and 'metx', I do not know if
> > this list is accurate or not.
> 
> I went through the list at
> https://www.w3.org/community/inbandtracks/wiki/Main_Page#ISOBMFF_2 and
> picked all those that were marked as "TextTrack". This is about how to
> identify that a track is indeed a text track, so if that's wrong, let me
> know what else I should write.

Current text is fine. My mistake - I thought this was related to determination of metadata kind.

> 
> 
> > For MPEG-2 TS there are many many non-audio/video stream types beyond those
> > explicitly identified as metadata (0x05, 0x80 - 0xff), with no identified
> > use case for exposing them to script.
> 
> If these are not sufficient, can you please let me know how to identify a
> text track of kind @metadata in MPEG-2 TS.

These are fine. I was responding to your question about no default to metadata in the MPEG-2 case.

> 
> > For MPEG-4, it seems that all metadata tracks would be identified by a
> > handler type of 'meta'. Is there a use case where that is not so?
> 
> That's what the patch says, too.
Comment 12 Silvia Pfeiffer 2014-03-24 04:33:39 UTC
(In reply to Bob Lund from comment #10)
> (In reply to Bob Lund from comment #7)
> > (In reply to Bob Lund from comment #6)
> > > (In reply to Silvia Pfeiffer from comment #5)
> > > > I have prepared a patch for this in a branch at
> > > > https://github.com/w3c/html/commit/f91c1932220ab4272d2b2b4e6c9f3679251fefa1 .
> > > > 
> > > > Could you please check that this is all correct, in particular for MPEG-2,
> > > > MPEG-4 and DASH (I checked Ogg and WebM and am quite confident on those).
> > > 
> > > For MPEG-4 metadata text track, you've used a list of sample entry codes
> > > instead of 'meta' handler type. Beyond, 'mett' and 'metx', I do not know if
> > > this list is accurate or not.
> > > 
> > > The table for setting text track kind, label and language looks good. 
> > 
> > While the phrase "contain private sections ("payload_unit_start_indicator"
> > == 1)" for identifying an MPEG-2 TS metadata text track is technically
> > correct, it requires the UA to wait for private section before creating the
> > text track.
> > 
> > It might be more simple for the UA to create a metadata text track for
> > MPEG-2 TS stream_type 0x05, 0x80 - 0xff without waiting for a private
> > section indicated by a payload_unit_start_indicator == 1. If none are ever
> > received, no private section cues would ever be created.
> 
> I think the UA should create the metadata text track for these stream_types
> and NOT wait for packets to determine the payload_unit_start_indicator;
> script will know what to expect.
> 
> So, the specific change is at line 33161 in
> https://github.com/w3c/html/commit/f91c1932220ab4272d2b2b4e6c9f3679251fefa1.
> Drop the text "contain private sections ("payload_unit_start_indicator" ==
> 1)"

OK, fixed: https://github.com/w3c/html/commit/bdb060f7c6a3836ef04e91d291cc50b8c63b8f10
Comment 13 Silvia Pfeiffer 2014-03-24 06:10:51 UTC
*** Bug 23362 has been marked as a duplicate of this bug. ***
Comment 14 Silvia Pfeiffer 2014-04-08 01:09:07 UTC
@Bob do you have an opinion about the suggestion of Ian's on moving all this media format specific mapping information into a wiki page, see bug 25132 ?
Comment 15 Bob Lund 2014-05-15 19:49:19 UTC
(In reply to Silvia Pfeiffer from comment #14)
> @Bob do you have an opinion about the suggestion of Ian's on moving all this
> media format specific mapping information into a wiki page, see bug 25132 ?

Bug 25733 [1] has been opened to add an HTML5 reference to the sourcing spec.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25733
Comment 16 Silvia Pfeiffer 2014-06-06 04:46:18 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the Editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the Tracker Issue; or you may create a Tracker Issue
yourself, if you are able to do so. For more details, see this document:

   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted

Change Description:
https://github.com/w3c/html/commit/c3a32873e10c45fc948541ca229914d4cf07cdee

Rationale: Accepted clarifications a provided by the Inband Text Tracks CG.