This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Expand on the sourcing of multitrack audio and video track attribute values for the id, kind, label and language attributes according to feedback provided by the Inband (Text) Tracks CG. See a proposed patch at https://github.com/w3c/html/commit/0d548a077fb90d35d8f1aa666cb0d116f2e1a6fa which should be applied to the AudioTrackList and VideoTrackList section: http://www.whatwg.org/specs/web-apps/current-work/#audiotracklist-and-videotracklist-objects . Explanation: The current spec is incomplete for how to fill the attribute values of (inband) audio and video tracks when parsing from a media file for the different file formats that are typically supported by UAs. Currently, it is only specified by example how .kind values are provided (there's a typo in the table title, btw, which should be .kind and not .kind() ). The suggested changes are: * the .id, .label and .language attributes (audioTrack.id and videoTrack.id etc) are sourced identically to how an inband textTrack.id etc. attribute is sourced (as described in https://github.com/w3c/html/commit /5fbd9199cc711d8ae9155da58be3d4368272e00d and bug #25132) * the .kind attribute table is expanded to be complete for Ogg, WebM, MPEG-2, MPEG-4 and DASH file formats The same specifications as in bug #25132 were used to clarify and complete the information that was prepared by the Inband Text Track CG in their wiki: https://www.w3.org/community/inbandtracks/wiki/Main_Page#Audio.2FVideo.2FText_Track_Creation The CG has reviewed and ok-ed the draft patch as prepared in bug #24986. I'm looking to have the patch adjusted and applied in a manner that suits the WHATWG style.
What's the reasoning for having this non-normative content in the spec itself rather than in a world-editable wiki? Shouldn't we in fact move towards having this more in an editable space where new formats can easily add rows and where existing formats can be updated as issues are found without having to update the specification as well?
(In reply to Ian 'Hixie' Hickson from comment #1) > What's the reasoning for having this non-normative content in the spec > itself The table in question already existed in the spec so adding to it seemed appropriate. The contents of this table, and similar text for setting track attributes and creating cues should be normative. > rather than in a world-editable wiki? Shouldn't we in fact move > towards having this more in an editable space where new formats can easily > add rows and where existing formats can be updated as issues are found > without having to update the specification as well? The in-band track CG created the input for this change. This information could be captured, in a normative manner, outside the HTML spec, perhaps in a manner similar to the MSE media format registry [1]. If this were done, then the registry should collect the related information currently in the spec [2][3][4][5][6][7], and be referenced by the HTML spec. The registry could specify, for each media resource format: 1) rules for setting video/audio/text kind, language, label, 2) guidelines for creating cues. [1] https://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/byte-stream-format-registry.html [2] http://www.w3.org/TR/html5/embedded-content-0.html#dom-audiotrack-kind [3] http://www.w3.org/TR/html5/embedded-content-0.html#text-track [4] http://www.w3.org/TR/html5/embedded-content-0.html#text-track-cue [5] http://www.w3.org/TR/html5/embedded-content-0.html#sourcing-in-band-text-tracks [6] http://www.w3.org/TR/html5/embedded-content-0.html#sourcing-out-of-band-text-tracks [7] http://www.w3.org/TR/html5/embedded-content-0.html#guidelines-for-exposing-cues-in-various-formats-as-text-track-cues
(In reply to Bob Lund from comment #2) > > The in-band track CG created the input for this change. This information > could be captured, in a normative manner, outside the HTML spec, perhaps in > a manner similar to the MSE media format registry [1]. If this were done, > then the registry should collect the related information currently in the > spec [2][3][4][5][6][7], and be referenced by the HTML spec. The registry > could specify, for each media resource format: 1) rules for setting > video/audio/text kind, language, label, 2) guidelines for creating cues. This seems reasonable. Would anyone be willing to take on the job of maintaining such a registry? (PS: please don't reference the obsolete /TR/ version of the spec, even if you feel you must reference a W3C fork. FWIW, the canonical version of the HTML standard is at http://whatwg.org/html .)
Bob and I started a spec at http://rawgit.com/silviapfeiffer/HTMLSourcingInbandTracks/master/index.html . This covers most of the fixes provided in the patch. Feedback welcome. Remaining bug to fix: in the table AudioTrack.kind() and VideoTrack.kind() should loose their brackets (they are not functions, but attribute values).
Fixed the kind() thing. I'm leaving this open to see what I should do with respect to removing the table, referencing the aforementioned doc, etc.
Checked in as WHATWG revision r8607. Check-in comment: Typo in table caption regarding *track.kind (leftover from when it was called getKind) http://html5.org/tools/web-apps-tracker?from=8606&to=8607
(In reply to Ian 'Hixie' Hickson from comment #5) > Fixed the kind() thing. > > I'm leaving this open to see what I should do with respect to removing the > table, referencing the aforementioned doc, etc. I'm thinking the inband sourcing spec could become a note in the W3C and then you can reference it and remove the table. Will keep you posted.
Seems reasonable. Let me know.
(In reply to Ian 'Hixie' Hickson from comment #8) > Seems reasonable. Let me know. After making a proposal for an HTML note, the HTML WG chairs made a counter proposal [1] to make the inband sourcing spec available "along the same lines as the "Media Source Extensions Byte Stream Format Registry" was published and referenced from the MSE specification". The sourcing spec would be informatively referenced by HTML 5.0 and 5.1. [1] http://lists.w3.org/Archives/Public/public-html-admin/2014May/0030.html
Wow, that sounds like a whole lot of bureaucracy. Well, if you want to go that route, go for it. If you'd like to just have a light-weight alternative where you just publish the document without needing any red tape or anything, let me know, I can provide that. (Either in the form of a Web page that you can edit, if you'd prefer that, or in the form of a wiki page, if that would be preferable. Whatever you want.)
(In reply to Ian 'Hixie' Hickson from comment #10) > Wow, that sounds like a whole lot of bureaucracy. > > Well, if you want to go that route, go for it. If you'd like to just have a > light-weight alternative where you just publish the document without needing > any red tape or anything, let me know, I can provide that. (Either in the > form of a Web page that you can edit, if you'd prefer that, or in the form > of a wiki page, if that would be preferable. Whatever you want.) I'm going with Silvia's and HTML WG chairs' direction. Suggestions for optimizing the process are welcome. 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
Spec is now available at http://dev.w3.org/html5/html-sourcing-inband-tracks/ I've given an edit for this bug a shot at. https://github.com/w3c/html/commit/792b76480c731e69327d997b40097d3631b61b64
Let me know if there's any other parts of the spec that should be updated.
Checked in as WHATWG revision r8715. Check-in comment: Link to the 'Sourcing In-band Media Resource Tracks from Media Containers into HTML' spec. http://html5.org/tools/web-apps-tracker?from=8714&to=8715