Re: TextTrackCue discussions

On Sat, Sep 7, 2013 at 5:24 PM, Glenn Adams <glenn@skynav.com> wrote:
>
> On Fri, Sep 6, 2013 at 10:54 PM, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
> wrote:
>>
>> On Sat, Sep 7, 2013 at 12:29 PM, Glenn Adams <glenn@skynav.com> wrote:
>> >
>> > On Fri, Sep 6, 2013 at 6:04 PM, Silvia Pfeiffer
>> > <silviapfeiffer1@gmail.com>
>> > wrote:
>> >>
>> >> On Sat, Sep 7, 2013 at 7:11 AM, Brendan Long <self@brendanlong.com>
>> >> wrote:
>> >> > On 08/30/2013 07:36 PM, Silvia Pfeiffer wrote:
>> >> >
>> >> >> What would be the reason for hiding the actual format that the
>> >> >> browser
>> >> >> parsed from the JS developer? Why wouldn't we specify another
>> >> >> interface
>> >> >> for
>> >> >> such a parsed format that is actually able to give the JS developer
>> >> >> more
>> >> >> specific information/attributes about the Cue format just like we
>> >> >> did
>> >> >> with
>> >> >> VTTCue?
>> >> >
>> >> > Because it's too specific. Right now JS developers can easily get the
>> >> > raw
>> >> > cue data,
>> >>
>> >> The raw cue data is only exposed in the GenericCue interface that we
>> >> are just now proposing, or in the current W3C version of TextTrackCue.
>> >> The WHATWG version of TextTrackCue does not expose the raw cue data.
>> >>
>> >>
>> >> > but they need to know the type of cue to get anything useful.
>> >>
>> >> That's information that the @inBandMetadataTrackDispatchType of
>> >> TextTrack contains.
>> >>
>> >>
>> >> > For
>> >> > example, if I want to know the start time of a cue, I can easily get
>> >> > it
>> >> > if I
>> >> > know that the original on-the-wire format was WebVTT. Otherwise, I
>> >> > can
>> >> > hope
>> >> > browser implementers will be consistent, but there's no standard for
>> >> > what
>> >> > that attribute might be named in other cues.
>> >>
>> >> There is in HTML5: the interface is called TextTrackCue and contains
>> >> the start and end times.
>> >>
>> >>
>> >> >> What cue formats do you see being supported by browsers as generic
>> >> >> parsed
>> >> >> cues without their own special interface?
>> >> >
>> >> > What I want is for all of these special classes to support a common
>> >> > (useful)
>> >> > interface, not a new special class.
>> >> >
>> >> > That's why I proposed this:
>> >> >
>> >> > interface WebVTTCue : ParsedTextTrackCue {
>> >> >     attribute DOMString regionId;
>> >> >     attribute DirectionSetting vertical;
>> >> >     attribute boolean snapToLines;
>> >> >     attribute (long or AutoKeyword) line;
>> >> >     attribute long position;
>> >> >     attribute long size;
>> >> >     attribute AlignSetting align;
>> >> > };
>> >> >
>> >> > interface TTMLCue : ParsedTextTrackCue {
>> >> >     ...
>> >> > };
>> >> >
>> >> > interface CEA708Cue: ParsedTextTrackCue {
>> >> >     ...
>> >> > };
>> >>
>> >> That looks like 3 identical interfaces, unless you have specific ideas
>> >> what "..." would add?
>> >
>> >
>> > TTMLCue will have at least:
>> >
>> > interface TTMLCue {
>> >   DocumentFragment getCueAsTTML(); // obtain TTML intermediate
>> > synchronic
>> > document (ISD)
>>
>>
>> I would expect that to end up in .text - makes more sense to me.
>
>
> That would be a waste of effort, i.e., to serialize XML into text only to
> expose it to JS which would have to deserialize it from text as XML

I follow you up to here - after this, JS would interpret the XML and render it.

> to
> modify then mutate deserialize by setting text attribute than have
> implementation deserialize once more into XML.

I don't know why you would need to do all this.


> No, that's the last reasonable choice of exposing TTML content. It will be
> parsed from XML, mapped to a sequence of TTML ISDs, each an XML document,
> then exposed to JS in the latter form. The text attribute will remain null
> valued.

It would be better to not have .text at all and directly inherit from
TextTrackCue.

Assuming a browser does *not* implement TTML parsing and rendering,
but can extract it from MPEG4 in-band. What would you expose in
GenericCue .text ? I was under the impression that it would be TTML
fragments as XML documents that would be included in-band in MPEG4,
and thus .text would only need to be filled with what is extracted
directly from the MPEG4 container.


Silvia.

Received on Saturday, 7 September 2013 08:12:11 UTC