Re: [media] Moving forward with captions / subtitles

On Feb 13, 2010, at 5:03 PM, Silvia Pfeiffer wrote:

> 
> On Sun, Feb 14, 2010 at 3:42 AM, Eric Carlson <eric.carlson@apple.com> wrote:
> 
>>   I like the idea of reusing <source> to list alternate tracks. We should
>> also include the "media" attribute, it would help in defining the selection
>> criteria. Can we use "media" instead of adding a "lang" attribute?
> 
> The spec already has the "media" attribute. As for "lang" - I'm happy
> to put it into "media", but it might be useful as a general attribute
> for audio and video, too.
> 
  I agree. I meant that if we use a <source> element to list tracks, it should be the same <source> element used by the audio/video element. If we extend "media" to include "lang" (or rather if we convince the CSS WG to extend it), it should be usable by the audio/video elements too.


> 
>>>> However, I must say I really like the idea of making it independent of
>>>> "text", i.e. leaving the possibility open to add "tracks" of audio or
>>>> video in future.
>>>> 
>>>> I'd be happy for something that essentially means "external parallel track".
>>> 
>>> Considering how many different names we have already come up with, I doubt
>>> <track> will be the last :) Brainstorm away!
>> 
>>   To me the singular "track" implies that only one <source> will be chosen
>> which will not be true in all cases. Maybe <tracks>?
> 
> I actually think that within a list of tracks only one should ever be
> activated. I don't think it makes sense to have more than one subtitle
> track active at a time. For those who have that need, they can always
> do that in JavaScript. It certainly doesn't make sense to have more
> than one caption track active, or more than one textual audio
> description, or more than one lyrics or karaoke track.
> 
  I agree that only one track *with a given role* should be chosen by the selection algorithm.


> 
>>   We also need to define a mechanism to mark tracks as being part of an
>> alternate group. Is an attribute on <source> enough?
>>     <tracks>
>>         <source type="text/srt" src="en-captions.srt" lang="en" role="caption">
>>         <source type="text/srt" src="zh-captions.srt" lang="zh" role="caption">
>> 
>>         <source type="text/srt" src="en-chapters.srt" lang="en" role="chapters">
>>         <source type="text/srt" src="zh-chapters.srt" lang="zh" role="chapters">
>>     </tracks>
>> 
>> Or should we have a grouping element like Silvia had in her early proposal?
>>     <tracks>
>>         <track role="caption">
>>             <source type="text/srt" src="en-captions.srt" lang="en">
>>             <source type="text/srt" src="zh-captions.srt" lang="zh">
>>         </track>
>> 
>>         <track role="chapters">
>>             <source type="text/srt" src="en-chapters.srt" lang="en">
>>             <source type="text/srt" src="zh-chapters.srt" lang="zh">
>>         </track>
>>     </tracks>
>>   I hesitate to define yet another element, but I think the markup in a
>> complex case like Silvia's Elephants Dream
>> sample, http://annodex.net/~silvia/itext/elephant_no_skin_v2.html, is
>> clearer because of it. On the other hand, will complex cases like this be
>> common enough that we need it?
> 
> The two-level mechanism is already in the current proposal. I think it
> is more flexible.
> 

  Yes, I was suggesting that we might want to have a third level, with a containing element for all of the <track> elements. It occurred to me that a containing element might be clearer as I was thinking about what the markup would look like in an element that several movie <source> elements as well as <track> elements:

    <video>
        <source media="accessibility(captions:yes audio-description:no)" src="A">
        <source media="accessibility(captions:no audio-description:yes)" src="B">
        <source src="C">
    
        <tracks>
            <track role="caption">
                <source type="text/srt" src="en-captions.srt" lang="en">
                <source type="text/srt" src="zh-captions.srt" lang="zh">
            </track>
    
            <track role="chapters">
                <source type="text/srt" src="en-chapters.srt" lang="en">
                <source type="text/srt" src="zh-chapters.srt" lang="zh">
            </track>
        </tracks>
    </video>

  Looking at it now am not at all certain it is necessary...

> But we can always do it the way in which the video
> and audio element work and directly attach a src to the track if there
> is only one:
> 
> <video src="video.ogg">
>  <track src="captions.srt" type="text/srt">
> </video>
> 
> This makes it really flexible and simple. However, it might encourage
> ppl to do stupid things such as list all their alternative subtitle
> tracks as parallel tracks. OTOH, that could be a way to do more than
> one parallel track. These would probably not have a role, since there
> is no distinction between these tracks.
> 
  I think allowing a "src" attribute directly on a <track> is a good idea because it will make simple markup easier to write. We will never be able to prevent people from doing stupid things. We just need to define the resource selection algorithm precisely so it is clear what a UA should do when presented with stupid markup.

eric