Re: Track kinds

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.

Received on Tuesday, 3 May 2011 18:56:25 UTC