Re: change proposals for issue-152

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.

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 15:58:00 UTC