Re: change proposals for issue-152

On Mar 24, 2011, at 2:13 PM, Bob Lund wrote:

> 
>> -----Original Message-----
>> From: public-html-request@w3.org [mailto:public-html-request@w3.org] On
>> Behalf Of Mark Watson
>> Sent: Thursday, March 24, 2011 2:20 PM
>> To: Silvia Pfeiffer
>> Cc: public-html
>> Subject: Re: change proposals for issue-152
>> 
>> 
>> On Mar 24, 2011, at 8:57 AM, Silvia Pfeiffer wrote:
>> 
>>> Hi Mark,
>>> 
>>> yes, you are right. I noticed that the in-band functionality was
>>> missing the day after sending off the change proposal. Extension of
>>> the existing tracks IDL attribute for in-band media tracks could
>>> indeed solve this. I haven't fully thought through the
>>> advantages/disadvantages in comparison to creating a new IDL attribute
>>> of mediaTracks yet.
>>> 
>>> I continue to believe that none of the existing proposals is perfect
>>> yet but that continued discussion will resolve the remaining issues,
>>> which are getting smaller and smaller.
>>> 
>>> As for kind types: We did discuss the matter of track kinds that do
>>> not fall within the given defined list. There was even a proposal to
>>> introduce a registry. I believe that would be overkill. Instead, I
>>> believe we should list the most common ones and allow other strings,
>>> which will then be handled just like "metadata" on text tracks. Then
>>> it is possible for browsers to experiment with further kinds and bring
>>> them back into the spec as the list of kinds mature.
>> 
>> I agree. In DASH they use URNs for this kind of labeling, which does
>> lead to unfortunately verbose names but at least enables people to
>> create their own namespaces if they so wish.
>> 
>> In this context we could define some specific strings as is done for the
>> text tracks and reserve all names beginning "urn:" for URNs.
>> 
>> I think the UA actually never needs to know what these strings "mean" -
>> it's the application that will interpret them.
> 
> We've been looking at how inband metadata tracks can be labeled so that the application understands what type of metadata is in a particular metadata text track. Our thought was to leave "kind" = metadata and set "label" to a descriptive string based on other relevant specification, as suggested in step 2 of WHAT WG web-apps 4.8.10.12.2 Sourcing in-band text tracks. Setting "kind" instead, as suggested, would seem to be a reasonable alternative.
> 
> I agree that it seems the UA need never know what these strings mean, only how to generate them.

Which I take to mean how to map from whatever markings are found in the types of media file the UA supports to the kind strings, right ?

...Mark

> 
> Bob Lund 
>> 
>> ...Mark
>> 
>>> 
>>> Cheers,
>>> Silvia.
>>> 
>>> On Tue, Mar 22, 2011 at 8:05 AM, Mark Watson <watsonm@netflix.com>
>> wrote:
>>>> Hi Silvia,
>>>> 
>>>> In this proposal, how do I discover and control in-band tracks ?
>>>> 
>>>> If I know in advance that a resource has, say, a sign language track,
>> I can create a video element for that track and control its rendering
>> that way. But in general I don't know this in advance: I need to be able
>> to load the metadata for a resource and find out the tracks it contains
>> (then I could create elements for the ones that I want). Or did I miss
>> something ?
>>>> 
>>>> A minor comment, but there are uses for the track "kind" which are
>> not related to accessibility, for example directors commentary or
>> multiple video viewpoints (most common with sports content).
>>>> 
>>>> ...Mark
>>>> 
>>>> On Mar 21, 2011, at 10:34 PM, Silvia Pfeiffer wrote:
>>>> 
>>>>> Dear WG chairs,
>>>>> 
>>>>> Please find a change proposal for issue-152: multitrack media API
>> here:
>>>>> 
>>>>> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposal
>>>>> 
>>>>> Best Regards,
>>>>> Silvia.
>>>>> 
>>>>> 
>>>>> NOTE:
>>>>> 
>>>>> This change proposal was created by a sub-group of the W3C Media
>>>>> Accessibility Task Force. Many alternatives were looked at during
>>>>> the process of creation of this change proposal (see [1]) and indeed
>>>>> not all possibilities have been analysed to date. In fact, some of
>>>>> the Task Force members are not in agreement with this proposal,
>>>>> which has resulted in a second change proposal (see [2]). Further,
>>>>> several members of the Task Force think that Ian's proposal (see
>>>>> [3]) is also of high quality. It seems we just simply lack further
>>>>> discussion time to arrive at a solution that everyone can agree to.
>>>>> 
>>>>> [1] http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Media_API
>>>>> [2]
>>>>> http://www.w3.org/WAI/PF/HTML/wiki/Media_Multitrack_Change_Proposal_
>>>>> 2 [3]
>>>>> http://lists.w3.org/Archives/Public/public-html/2011Mar/0436.html
>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 
> 
>

Received on Thursday, 24 March 2011 22:04:30 UTC