This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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
Should say TextTrack.kind?
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?
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 :)
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 :)
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.
(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?
(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?
*** Bug 25044 has been marked as a duplicate of this bug. ***
(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.
(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?
(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.
(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
*** Bug 23362 has been marked as a duplicate of this bug. ***
@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 ?
(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
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.