Re: Track kinds

Sent from my iPhone

On May 6, 2011, at 4:25 PM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com<mailto:silviapfeiffer1@gmail.com>> wrote:

On Sat, May 7, 2011 at 9:16 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

On May 6, 2011, at 2:18 PM, Silvia Pfeiffer wrote:

On Sat, May 7, 2011 at 5:22 AM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

I also have a procedural question: do we consider that we have received the

liaison from 3GPP (mentioned on the above page) ? Are we going to answer it

?

There should be an email by a 3GPP member with all the relevant
requests to the WG list. I haven't seen one such.

I doubt the 3GPP staff will post to the list. They will send the liaison to
the chair of the group, possibly via W3C staff members, and expect them to
distribute it to the list. I imagine it is stuck somewhere in that path.

Unless that arrives,
there is nothing to reply to.

We can see that it has been sent from their minutes and we can see the text
of the document in their archives, so we can at least prepare for its
arrival ;-)


Do poke the chairs to forward it, or ask them to reply to it. It
doesn't seem right for us to just go ahead and try to represent the
HTML WG in a reply to the 3GPP WG.


Oh, I don't mean that this group should do any more than agree a proposal for what we should say in a potential reply. I don't have any sense for what formalities are necessary to get such a thing agreed as an _actual_ reply.



One question they ask is whether we will define a URN to identify the
space of kind values defined by W3C. One advantage of doing that is that

these kinds are then immediately supported in 3GPP and MPEG adaptive

streaming manifests, which means that there *is* a media container

supporting those kinds (perhaps addressing one of the editor's concerns

about new kind values).

I don't think HTML needs these values as anything else but short
strings that we now have.

Agreed.

If 3GPP and MPEG need them as URNs

No, they need a URN that refers to the codepoint space containing these
values. But I notice W3C doesn't appear to have a top-level URN space. It
could use urn:fdc:w3.org:2011....

Seems to make sense to me... would such a URN be useful for anything else?

Probably not.



The 3GPP and DASH specs allow you to tag a track with any number of "Roles"
- so it can be tagged with roles from this W3C space (if anyone defines a
URN) as well as equivalent roles from other spaces if necessary for some
application.

- and they probably have a swag
more that they have proposed and will use

Not really - they'd prefer W3C to define some container-format-independent
ones, as I understand it.

- it makes a lot more sense
to me for them to define these themselves.

They seem to think the opposite ;-) In particular it's been stated at MPEG
that the W3C HTML a11y group has more a11y expertise than the MPEG group.
And there is nothing container-format-specific about this concept of track
kinds. The abstract kinds and their definitions need to be defined somewhere
with responsibility for all containers or for none, not in the groups
focussed on particular containers. The containers (and HTML) just need to
define how those kinds are labeled in their syntax.

Well, MPEG caters for a lot more than just the Web and the kinds
required elsewhere may need to be a lot more diverse. So, I agree that
they do well in looking to us for a11y related kinds and it's great
that they want to pick up the ones that we define here, but I highly
doubt that will be the end of their list.


Some of the kinds that
media containers will expose may just end up creating getLabel() text
rather than be exposed in getKind(). Ogg already seems to have a few
of those.

Agreed, but I think this is a symptom of having media container formats lead
the definition of kinds: they define kinds which are either not very
well-defined or not universally applicable and so we decide not to expose
these over HTML because we want the HTML interface to be clean and
well-defined. The best way to achieve that is to define these things in a
container-independent place and ask the containers to align.


Well, we don't need anyone to align. All we need is a mapping, which
your wiki page provides perfectly.

Yes, but a mapping does imply semantic alignment, which is the kind I mean.

That is, for there to be a mapping from Role X in container Y to clearaudio in HTML, the X has to mean the same as clearaudio, not something similar but awkwardly different.

If the names are identical, the
better so. It's ok when not everything that a container can contain is
exposed to HTML. Only what gets exposed needs to be compatible. I
think we're on the best way there anyway. :-)


Agreed.

...Mark
Cheers,
Silvia.



Finally, we discussed the "commentary" kind here at Netflix and in the end

we are happy to have it dealt with simply as "alternative". I do think

though that in principle there could be other (UI-related) reasons for

exposing a new track kind than triggering default behavior or application of

user preferences. This is certainly the case for accessibility use-cases

where the UI to enable/disable a particular track could usefully be tailored

to the intended users of that track (for example, enabling/disabling tracks

intended for the blind or those with low vision should ideally not involve

complex visual UI elements).

OK. I think we'll cross that bridge when we get to it.

Cheers,
Silvia.


...Mark


On May 3, 2011, at 10:12 PM, Silvia Pfeiffer wrote:

I understand the problem of additive/alternative tracks, too, and have

tried to approach it with markup before. However, I think this is

making something that is supposedly simple much too difficult. The

ultimate choice of active tracks has got to be left to the user. For

this reason, I think @kind (or getKind()) should only ever expose what

content is available in the track, but there should not be an

automatic choice made by the browser. It's up to the user to

activate/deactivate the correct tracks.

Before we dive into anything more complex, we should get some

experience with an implementation of multitrack and the roles. I don't

think we will have much to go by for making a decision beforehand.

Cheers,

Silvia.


On Wed, May 4, 2011 at 2:02 PM, Mark Watson <watsonm@netflix.com<mailto:watsonm@netflix.com>> wrote:

So, if we are looking for a generic approach, where a track can have

multiple "roles", then I think the correct logic is indeed to pick the

fewest number of tracks which fulfill the intersection of the desired roles

and the available roles such that no role is fulfilled more than once. You

need a priority list of roles to drop from the desired list if that isn't

possible (which would mean some badly authored content, but has to be dealt

with). It may be a mouthful, but I think it would be reasonably

straightforward to implement.

However, I'm still not sure a generic approach is necessary. A "simpler"

approach is to say every track has a single role. But for some applications

(like audio descriptions) there are two distinct role values defined - an

additive one and an alternative one. The problem is addressed at a semantic

level - i.e. people implement support for audio descriptions - and they know

what these are and how to handle them - rather than trying for a generic

descriptor matching algorithm.

Regarding Repetitive Stimulus Safe, I guess that since most content is

unfortunately not labeled one way or the other the default assumption has to

be up to the user themselves. i.e. that user preferences associated with

this aspect should support required, preferred and don't care. In a really

generic approach every role may have a status from { require, prefer, don't

care, prefer not, require not }.

Again, this suggests that a generic approach might be over-ambitious - who

says some new role doesn't come along next week with a sixth user-preference

status of "required unless role Y present" or similar ... I think maybe the

UA needs to understand what these things are and act appropriately.

...Mark





On May 3, 2011, at 11:55 AM, David Singer wrote:


On May 2, 2011, at 16:55 , Mark Watson wrote:


I think it's evidence that there is something to be solved.

I'd prefer a solution where adding a track to an existing presentation

didn't require me to change the properties of existing tracks, though, since

there is an error waiting to happen in that case.


Yes.  This idea made some sense when it was the tracks in a multiplex (e.g.

MP4 file), perhaps makes sense when all the tracks are annotated in the

markup (e.g. in HTML5 or DASH MPD) but makes much less sense when some

tracks are in a multiplex and some are added in the markup - a track added

in the markup might need the annotations in a multiplex changed, ugh.

So, thinking out loud here.

Assume the user has a set of roles that they would kinda like to experience.

The default is 'main, supplementary', I think, or something like.

Now, we have a set of tracks, each of which satisfies some roles.  Let's

ignore tracks we have discarded because they are the wrong mime type, codec,

language, etc., and focus just on this selection mechanism.  What is the

right simple way to get the set of tracks?

It's easy to 'go overboard' and treat this as a very general problem of

finding the minimal set of tracks that will span a set of design roles.  I

don't think anyone will author *for the same language*

track - main

track - captions

track - main +  captions

so an algorithm designed to pick only (3) instead of (1 + 2) for the

main+captions desiring user is probably overkill.

'enable the tracks whose roles are a subset of the desired roles, and

disable the rest' may be too simple, unless tracks are ordered from the

most-labelled to the least-labelled.

So, audio-description replacing the main audio:

track - main description

track - main

Audio description adding to the main audio

track - main

track - description

The same works for all the adaptations that might require re-authoring or

might be achievable with an additional track (captions, burned in or

separate, for example).


Where this fails is when the 'base content' is good enough for both the

plain user and the user who desires more roles.  The obvious case here (Mark

will laugh) is repetitive-stimulus-safeness;  we have to assume unlabelled

content is unsafe, but much content is naturally safe and can be labelled as

such.

David Singer

Multimedia and Software Standards, Apple Inc.