[whatwg] How to handle multitrack media resources in HTML
silviapfeiffer1 at gmail.com
Wed Feb 16 12:34:01 PST 2011
I'm curious: if you are using @kind=metadata - which is not
generically applicable, but only has application-specific data in it -
then this implies that the web page knows what type of data is in the
track's cues and knows how to parse it. Why do you need a mime type on
the cues then? Is it because MPEG has metadata cue tracks that can
contain different types of structured content? Can you clarify?
On Thu, Feb 17, 2011 at 6:44 AM, Eric Winkelman
<E.Winkelman at cablelabs.com> wrote:
> Silvia, all,
> The biggest issue we've faced is that there isn't an obvious way to tell the browser application what type of information is contained within the metadata track/cues. The Cues can contain arbitrary text, but neither the Cue, nor the associated TimedTrack, has functionality for specifying the format/meaning of that text.
> Adding a @type attribute to the Cues would certainly help, though it would still require the browser application to examine individual cues to see if they were useful.
> An alternate approach would be to add a @type attribute to the <track> tag/TimedTrack that would specify the mime type for the associated cues. This would allow a browser application to determine from the TimedTrack whether or not it needed to process the associated cues.
> Eric Winkelman
>> -----Original Message-----
>> From: whatwg-bounces at lists.whatwg.org [mailto:whatwg-
>> bounces at lists.whatwg.org] On Behalf Of Silvia Pfeiffer
>> Sent: Wednesday, February 09, 2011 5:41 PM
>> To: WHAT Working Group
>> Subject: [whatwg] How to handle multitrack media resources in HTML
>> Hi all,
>> One particular issue that hasn't had much discussion here yet is the issue of
>> how to deal with multitrack media resources or media resources that have
>> associated synchronized audio and video resources.
>> I'm concretely referring to such things as audio descriptions, sign language
>> video, and dubbed audio tracks.
>> We require an API that can expose such extra tracks to the user and to
>> inside the media resource or are given as separate resources, but should be
>> linked to the main media resource through markup.
>> I am bringing this up now because solutions may have an influence on the
>> inner workings of TimedTrack and the <track> element, so before we have
>> any implementations of <track>, we should be very certain that we are
>> happy with the way in which it works - in particular that <track> continues to
>> stay an empty element.
>> We've had some preliminary discussions about this in the W3C Accessibility
>> Task Force and the alternatives that we could think about are captured in
>> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API . This
>> may not be the complete list of possible solutions, but it provides ideas for
>> the different approaches that can be taken.
>> I'd like to see what people's opinions are about them.
>> Note there are also discussion threads about this at the W3C both in the
>> Accessibility TF  and the HTML Working Group , but I am curious about
>> input from the wider community.
>> So check out
>> and share your opinions.
>>  http://lists.w3.org/Archives/Public/public-html-a11y/2011Feb/0057.html
>>  http://lists.w3.org/Archives/Public/public-html/2011Feb/0205.html
More information about the whatwg