Re: Resolving TextTrackCue issues

On Thu, Sep 5, 2013 at 2:56 AM, Eric Carlson <eric.carlson@apple.com> wrote:
>
> On Sep 3, 2013, at 11:48 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>
>> On Wed, Sep 4, 2013 at 2:14 PM, Eric Carlson <eric.carlson@apple.com> wrote:
>>>
>>> On Sep 3, 2013, at 5:16 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote:
>>>
>>>> What is the content in .text ?
>>>>
>>>  The cue text.
>>
>> Just to clarify: Is that a plain text version of the original cue
>> content? For example, for CEA608 content from a SCC file it would just
>> be the plain text of the cue stripped of all the other characters? Or
>> in the case of SRT, all tags are stripped and just the plain text is
>> exposed?
>>
>
>> If you do that, then we're just pretending the in-band text track was
>> actually WebVTT content.
>>
>   AVFoundation converts the in-band cue data (CEA608, QTText, 3GPP timed text, etc) to plain text, which sometimes has position and style information. WebKit converts that to WebVTT.
>
>   This is "pretending" the in-band data is WebVTT, but does that matter? I think this is actually an advantage, both because it makes our implementation simpler and because it makes it simpler for developers.


I'd be happy if everything was exposed as WebVTT. However, that also
requires that the cue content (and not just the attributes) are
converted to WebVTT format, unless they are @kind=metadata.

Where you have styling information associated with the cue content
(italics, bold, color, etc), are you also converting the cue text to
WebVTT and thus exposing that in .text for rendered cues?



>>>> And an orthogonal question: you've probably seen the Cablelabs spec
>>>> for exposing MPEG-2 in-band text tracks of different types to HTML[1].
>>>> Seeing as both Cablelabs and the HTML spec are trying to accommodate
>>>> using in-band text tracks in HTML/JS, what do you suggest is the best
>>>> way forward to specify this?
>>>>
>>>> * Program Map Table: would you suggest to use VTTCue with
>>>> @kind=metadata, GenericCue, or a new PMTCue interface?
>>>>
>>>  It seems to me that text track content that a UA does not render itself is, by definition, metadata.
>>
>> In this case, that definition works, because no @kind value matches
>> the semantic content of a PMT track.
>> But caption data that is not rendered is still semantically of @kind=captions.
>>
>   I disagree. A generic script that sees a track with kind=captions is going to expect the UA to render those "captions" when it makes the track visible.
>
>   It seems clear to me that "caption data" that a UA is not able to render is metadata. This matches the definition of metadata in the spec: "Tracks intended for use from script. Not displayed by the user agent"


So would the "in-band metadata track dispatch type" attribute tell the
JS developer what is really in this track?

For example, TTML in MP4, not supported by the browser, not rendered
by the browser, but able to be extracted from MP4 by the browser would
in your suggestion end up as VTTCue objects of @kind=metadata with
@inBandMetadataTrackDispatchType conveying some information about it
being captions?

Silvia.

Received on Thursday, 5 September 2013 14:40:10 UTC