- From: <bugzilla@jessica.w3.org>
- Date: Fri, 28 Feb 2014 15:44:52 +0000
- To: public-html-admin@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24859 Bug ID: 24859 Summary: Automatic Video and Audio Track Selection Based on User Preferences and Terminal Characteristics Product: HTML WG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: CR HTML5 spec Assignee: robin@w3.org Reporter: oipfjon@gmail.com QA Contact: public-html-bugzilla@w3.org CC: public-html-admin@w3.org This issue is raised on behalf of HbbTV - see http://www.hbbtv.org, an organisation specifying the use of web technologies in television receivers. HbbTV is in the process of adding the HTML5 video element to its specification. The current HbbTV specification uses the <object> element for presenting video in an HTML page. The HTML5 spec defines automatic track selection based on user preferences for text tracks as follows; http://www.w3.org/TR/html5/embedded-content-0.html#perform-automatic-text-track-selection Specifically; "If the user has expressed an interest in having a track from candidates enabled based on its text track kind, text track language, and text track label," There is no equivalent language for video and audio tracks. Further, for video tracks and audio tracks, the resource fetch algorithm includes the following; "If either the media resource or the address of the current media resource indicate a particular set of audio or video tracks to enable, then the selected audio tracks must be enabled in the element's audioTracks object, and, of the selected video tracks, the one that is listed first in the element's videoTracks object must be selected. All other tracks must be disabled." The last sentence of this can be interpreted as excluding the UA selecting video or audio tracks based on user preferences and/or terminal characteristics. We have two use-cases where automatic track selection based on user preferences and other terminal characteristics for video and audio tracks is important. 1) In TV receivers, typically users can set a range of preferences in the receiver for preferred audio language, preferred subtitle language and other audio and subtitle preferences related to accessibility (e.g. a preference for so-called "clean" audio or for audio tracks including description). These preferences are held in the receiver and applied automatically by the receiver for broadcast television. The user can also change these dynamically, for example depending on the sound track of a particular TV show. In our current specification, the media player underlying the <object> element follows these preferences automatically unless the HTML page over-rides it. This particular use-case is very related to audio. It is generally believed that a single consistent way of setting these kind of preferences for TV (regardless of how it is delivered) benefits users. 2) Our current specification supports MPEG DASH for HTTP adaptive streaming. The MPEG DASH manifest file (MPD) can contain multiple "adaptation sets" (sets of interchangeable encoded versions of a media component) which can differ in terms of codec, DRM, language, kind (called "role" by MPEG) and for audio, number of channels, e.g. stereo / 5.1 / 7.1. In our current specification, the DASH player automatically selects which video and audio adaptation set to present based on user preferences and terminal characteristics such supported codec / DRM and the number of audio channels on the output - stereo, 5.1 or 7.1. The adaptation sets are made visible to apps as our equivalent of VideoTracks and AudioTracks so that an app can over-ride the automatic selection if it so desires. We are deliberately not very prescriptive about how the automatic track selection works and there are a number of situations when an app might want to over-ride it. Given these use-cases, we would appreciate your feedback about whether the HTML5 specification does indeed exclude automatic track selection for video and audio tracks based on user preferences and terminal characteristics. If this is excluded, can you please say if this is deliberate or accidental? If it's deliberate, can you please share the reasons for this? If it is excluded, can you to consider removing this exclusion. -- You are receiving this mail because: You are on the CC list for the bug.
Received on Friday, 28 February 2014 15:44:54 UTC