Re: Text Subteam Minutes for 8 May

On Thu, May 10, 2012 at 4:41 PM, John Foliot <john@foliot.ca> wrote:
> Hi Silvia,
>
> Silvia Pfeiffer wrote:
>> >
>> >   <JF> @kind="metadata" is not defined to take time-stamped files
>>
>> That is wrong. All <track> resources require time-stamped content. Why do
> you
>> believe otherwise?
>
> Because it doesn't actually say that anywhere that I can see, for one, and
> specifically, the @kind value of metadata remains completely undefined
> today. Can you point to where kind="metadata" is defined as time-stamped
> content only?

The content of the @src attribute is parsed into TextTrackCues and
those are associated with the TextTrack object. Anything that doesn't
consist of cues will not fit the model. It doesn't matter what value
@kind has.

> If metadata does not require being timed content (what would
> that even look like?),

Timed metadata is absolutely what this is providing. That's what this
has been defined for. You could provide JSON objects in cues that are
handed to your JavaScript to do something with it. An Apple demo has
used metadata tracks before to provide timed keyframes. Others I have
seen trigger events such as ad displays. It's all these use cases that
timed metadata is for.

> then this refutes the assertion that all <track>s
> MUST be time-stamped.

Absolutely everything is built on the assumption that the track
element provides a list of cues and that something is done in
synchronization with the video.

You can misuse it by providing a single cue in your WebVTT file with a
duration of the full video resource and thus trick the mechanism to
use a degenerate cue list of one cue. But that is not the intention of
the <track> element.


> Finally, if we really wanted to play semantic games, I could use TTML with
> role="transcript", and off I go.

You will still need to get browsers to implement it and do the right
thing with it. Right now, IE is the only browser that accepts TTML and
I wouldn't bet on it being able to deal with a TTML file with
role="transcript" - what would that even do in a timed file?


> FWIW, there were a number of other engineers in the room while this
> discussion was had, including many with more than a passing knowledge of
> video and media on the web(*), and the "timed text only" argument did not
> seem to hold much credence with them either.

I have read the minutes and Eric has objected more than once.

 It seems to met that your proposal would introduce another type of
file format that would need to be parsed in <track> elements:
basically what we would need is a <track> element that can parse full
HTML files, Word documents and other such file as you have previously
stated that such files are often provided as transcripts.


> I respect your opinion here,
> but it is but one opinion, and I have not been convinced that it is totally
> correct.
>
> (* Frank Olivier & Adrian Bateman from Microsoft, David Dorwin & Aaron
> Colwell from Google, Bob Lund from Cable Labs, Mark Vickers from Comcast,
> Yosuke Funahashi from Tomo-Digi, and Cynthia Shelley was able to have a
> brief on-line chat with Sean Hayes who also supported using <track> in this
> fashion)

I encourage these engineers to speak up and support your argument and
state that they will implement support for non-timed transcript files
in the manner that you are proposing. This far I have not seen such
happening.


Regards,
Silvia.

Received on Thursday, 10 May 2012 07:44:45 UTC