RE: change proposals for issue-152

> -----Original Message-----
> From: Mark Watson [mailto:watsonm@netflix.com]
> Sent: Thursday, March 24, 2011 4:04 PM
> To: Bob Lund
> Cc: Silvia Pfeiffer; public-html
> Subject: 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
> 

For inband metadata in an MPEG-2 TS it would be to map information in the PID map tables to a descriptive text string that could be assigned to either the "kind" or "label" for the track exposed by the UA. Potentially multiple PIDs will be carrying different types of metadata and this would result in multiple metadata tracks. In the case where a manifest file provides information about tracks in the media then the mapping would be in a manner appropriate to that manifest file type - URN or some other type information about the track. Seems to me that the mapping rules will be specific to the type of media transport format and what inband metadata one expects to find in that type of transport format. Make sense?

Bob

> >
> > 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_Proposa
> >>>>> l
> >>>>>
> >>>>> 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_Proposa
> >>>>> l_
> >>>>> 2 [3]
> >>>>> http://lists.w3.org/Archives/Public/public-html/2011Mar/0436.html
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >
> >

Received on Thursday, 24 March 2011 22:34:46 UTC