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.

...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 20:20:05 UTC