401
edits
Accessibility/Video a11y Study08: Difference between revisions
Jump to navigation
Jump to search
Accessibility/Video a11y Study08 (view source)
Revision as of 08:41, 5 February 2009
, 5 February 2009added link
(added link) |
(added link) |
||
| Line 148: | Line 148: | ||
To make this available, the Web browser needs to have the ability to gain a full picture of the tracks available for a video or audio resource before being able to choose the ones requested through the user's preferences. The text tracks may come from the video or audio resource itself, or through "text" tracks inside the "video" tag. To gain information about the text tracks available inside an Ogg file, a browser can start downloading the first few bytes of the Ogg file, which contain the header data and therefore the description of the tracks available inside it. For Ogg, the skeleton track knows which text tracks are available. However, we need to add the category description into skeleton to allow per-category content selection. | To make this available, the Web browser needs to have the ability to gain a full picture of the tracks available for a video or audio resource before being able to choose the ones requested through the user's preferences. The text tracks may come from the video or audio resource itself, or through "text" tracks inside the "video" tag. To gain information about the text tracks available inside an Ogg file, a browser can start downloading the first few bytes of the Ogg file, which contain the header data and therefore the description of the tracks available inside it. For Ogg, the skeleton track knows which text tracks are available. However, we need to add the category description into skeleton to allow per-category content selection. | ||
In a general audio or video file that is not Ogg, typically downloading the first few bytes will also provide the header data and thus the description of the available tracks. However, an encapsulated text track does not generally expose the category types of the text tracks. The Xiph community has developed ROE, the XML-based Rich Open multitrack media Exposition file format. ROE is essentially a textual description of the tracks that are composed inside an Ogg file and can be used generically to describe the tracks available inside any audio or video file. Thus, a Web browser could first download the ROE file associated with an audio or video resource to gain a full picture of all the available content tracks. It can then decide which ones to display. | In a general audio or video file that is not Ogg, typically downloading the first few bytes will also provide the header data and thus the description of the available tracks. However, an encapsulated text track does not generally expose the category types of the text tracks. The Xiph community has developed [http://wiki.xiph.org/index.php/ROE ROE], the XML-based Rich Open multitrack media Exposition file format. ROE is essentially a textual description of the tracks that are composed inside an Ogg file and can be used generically to describe the tracks available inside any audio or video file. Thus, a Web browser could first download the ROE file associated with an audio or video resource to gain a full picture of all the available content tracks. It can then decide which ones to display. | ||
Taking this a step further, if there is a mechanism for the browser to tell the server which tracks it needs, then the server could multiplex together a custom resource for that request. This can potentially be done through a media fragment URI as is currently under specification with the W3C Media Fragments Working Group. Such a content adaptation approach is particularly important for deaf and blind people, who can only consume specific tracks and should not be required to use bandwidth and pay for content that they cannot actually consume. | Taking this a step further, if there is a mechanism for the browser to tell the server which tracks it needs, then the server could multiplex together a custom resource for that request. This can potentially be done through a media fragment URI as is currently under specification with the W3C Media Fragments Working Group. Such a content adaptation approach is particularly important for deaf and blind people, who can only consume specific tracks and should not be required to use bandwidth and pay for content that they cannot actually consume. | ||