W3C home > Mailing lists > Public > public-html-a11y@w3.org > April 2011

RE: Track kinds

From: Bob Lund <B.Lund@CableLabs.com>
Date: Fri, 29 Apr 2011 09:24:48 -0600
To: Mark Watson <watsonm@netflix.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: HTML Accessibility Task Force <public-html-a11y@w3.org>
Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D01843E762F@srvxchg>


> -----Original Message-----
> From: public-html-a11y-request@w3.org [mailto:public-html-a11y-
> request@w3.org] On Behalf Of Mark Watson
> Sent: Thursday, April 28, 2011 11:44 PM
> To: Silvia Pfeiffer
> Cc: HTML Accessibility Task Force
> Subject: Re: Track kinds
> 
> 
> On Apr 28, 2011, at 6:07 PM, Silvia Pfeiffer wrote:
> 
> > On Fri, Apr 29, 2011 at 6:52 AM, Mark Watson <watsonm@netflix.com>
> wrote:
> >> All,
> >> I updated the wiki page
> >> (http://www.w3.org/WAI/PF/HTML/wiki/Track_Kinds)
> >> based on our discussion yesterday. There are now three tables, the
> >> kinds in the current spec, the kinds that have been suggested and the
> >> subset that we have agreed should be added to the spec (currently
> just "captions").
> >> If I understand rightly, the general idea is that we should provide
> >> precise, container-independent definitions for all the kinds we agree
> >> on in a W3C document other than the HTML specification and propose
> >> that the HTML specification just define the text labels to be used
> with HTML.
> >> In parallel, various people will work on introducing the same kinds
> >> to various container specifications.
> >> We decided to continue the discussion of which ones to propose should
> >> be added to the specification on the list. To that end the three that
> >> Sylvia suggested yesterday were:
> >> - supplementary
> >> - commentary
> >> - clear audio
> >> Comments ?
> >
> > Thanks for the great work on the wiki page. It is good to pull this
> together.
> >
> > I think the list that we have in the spec right now is a good start
> > and should likely be sufficient for a reply to the 3GPP.
> >
> > As for further values:
> >
> > I think adding "supplementary" makes sense, because it states that a
> > track can be active at the same time as the "main" tracks.
> 
> The "supplementary" value from 3GPP is rather subtle. Usually the main
> audio and video tracks have equal "importance" to the overall
> presentation. "supplementary" was supposed to convey the idea that this
> track is somehow less important than the "main" one. One use for this
> information would be that in an extreme bandwidth crunch you should
> maintain the "main" track in preference to the "supplementary" one.
> Examples are that for a music video the audio is more important than the
> video (though I wonder if that is more true of music videos from the 80s
> than today) or for sports the video is more important than the audio
> (except perhaps competitive yodeling?!?).
> 
> >
> > I am not so fussed about any of the others because I think as we
> > implement this the list will likely grow. I don't mind adding
> > "captions" and "commentary" because I know there is material that has
> > in-line captions and there are commentary tracks. Alternatively,
> > "captions" could be marked as "alternative" and "commentary as
> > "supplementary" with a description of what it actually is in the
> > label.
> 
> If they are for well-understood things then explicit values are useful
> because people can create UI elements specifically for those things.
> Particularly for captions it would be nice for them to be accessed
> through the UI in the same way, whether they are burned in or in text
> tracks.
> 
> For UI consistency, also, I would prefer to have a "Directors
> Commentary" UI element, rather than relying on every directors
> commentary track having the same label.
> 
> Btw, what is the situation with labels in media container formats ? I
> don't think DASH has anything yet.
> 
> >
> > As for "clear audio", I think we first need to clarify what it is
> > exactly. As I understood from our requirements discussions, a "clear
> > audio" track is a track that has only the speech part of the video so
> > that it is possible to turn this sound up through controls in
> > comparison to the main audio track. If this is the case, then it
> > compares to the "audio/speech" value of the Ogg roles. If instead it
> > is as David describes a track which has the speech part amplified in
> > comparison to the main audio, then it is actually a replacement for
> > the main audio track and would be covered with "alternative" and a
> > description in label as "clear audio".
> 
> This is a more general question about how to signal whether a track is
> "additive" or "alternative". I think we discussed this before (or maybe
> that was a different list, I forget).
> 
> In the context of audio descriptions I've seen it stated that sometimes
> an audio description track is a replacement for the main audio track and
> in other cases it's intended to be mixed in (i.e. the descriptions fit
> somehow into gaps in the main audio track.)
> 
> Does anyone on this list know whether that is true ?
> 

Yes, this is true for commercial video providers delivering content to devices that do not have the capability to mix two audio tracks. So the "descriptive video" track will be a composite of the main and descriptions. They will want to repurpose this same content to HTML5 based devices.

Bob Lund

> As with the repetitive stimulus question there are three approaches:
> (a) treat it as a new property (additive vs alternative)
> (b) allow multiple kinds (so we wold have "alternate clearaudio" and
> just "clearaudio")
> (c) define separate kinds for the different cases, where it makes sense
> ("clearaudio-alt" and "clearaudio-mix")
> 
> Personally, I prefer (c) as I don't think the concept is universal
> enough to warrant a separate property.
> 
> ...Mark
> 
> >
> > Cheers,
> > Silvia.
> >
> 
Received on Friday, 29 April 2011 15:25:14 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:19 UTC