W3C home > Mailing lists > Public > public-html@w3.org > September 2008

Re: Acessibility of <audio> and <video>

From: Eric Carlson <eric.carlson@apple.com>
Date: Thu, 04 Sep 2008 08:29:37 -0700
To: Henri Sivonen <hsivonen@iki.fi>
Cc: HTML WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>, W3C Style List <www-style@w3.org>
Message-id: <5C9276BE-B77A-453F-AE07-723FA2B2AEFF@apple.com>

On Sep 4, 2008, at 1:17 AM, Henri Sivonen wrote:

>
> On Sep 4, 2008, at 01:13, Dave Singer wrote:
>
>> 2.1.2 Configuring
>> Sometimes, similarly, the media format itself can carry optional  
>> features. An example might be the 3GPP file format (or any file  
>> format from that family, such as MP4) with a text track in 3GPP  
>> Timed Text format. Enabling this track (and thereby causing it to  
>> be presented) may be a way to satisfy a need within a single media  
>> file.
>
> It seems to me that for captioning, an off-by-default track within  
> the main file is preferable over burned-in open captions, because  
> tracks within the main file travel better, compress better (and  
> transferring the captions even when not needed is not burdensome in  
> terms of relative network bandwidth) and make video more searchable.
>
   I am not sure if you are suggesting otherwise, but a a 3GPP Timed  
Text track is exactly what you describe: a relatively small text track  
carried within the media file. It may nor may not be enabled by  
default, that is a decision that is made at authoring time.

>> (In some cases, the media format may also need to disable a track;  
>> for example, a track providing audio description of video may  
>> incorporate the standard audio within it, and the normal audio  
>> track would be disabled if the audio description were enabled.)
>
> I would guess that content providers would opt for alternative files  
> in this case, because additional audio tracks show up on the  
> bandwidth bill if served even when not needed.
>
   This is not necessarily true. Even for progressive download files,  
some media-subsystems only read the parts of a file necessary for the  
presentation.


>> We therefore also need the ability to apply the same preferences  
>> used for selection, to configuring the file. Note that not all  
>> media sub-systems will offer the user-agent such an API; that is  
>> acceptable  for media files associated with those systems, the  
>> files are not configurable and selection must be used instead.
>
> This seems alarming. Does at least one of QuickTime, GStreamer or  
> DirectShow lack such an API? If one of those lacks such an API, can  
> such an API be put in place in a timely manner?
>
> It seems to me that if automatic selection isn't reliable, content  
> providers will shy away from an automatic selection system.
>
   I believe David is pointing out that not all sub-systems have this  
capability to emphasize that is it crucial for content authors to be  
able to structure their markup so one of several files is selected  
based on the user's stated preferences.

Eric Carlson
Apple
Received on Thursday, 4 September 2008 21:57:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:58 UTC