RE: [blink-dev] WebVTT vs TTML Features

Why will you prefer a roll-up over pop-ons ???
All On-Demand videos are pop-ons and roll-up were just a constraint of the
past - not a good solution if you ask anyone who actually uses the captions.
I fail to see the reasoning, just keeping things AS THEY WERE is not a good
choice...

-----Original Message-----
From: Goldstein, Glenn [mailto:glenn.goldstein@viacom.com] 
Sent: Thursday, December 12, 2013 4:32 PM
To: Nigel Megitt; David Singer; Andreas Tai
Cc: Silvia Pfieffer; Glenn Adams; Victor Cărbune; Silvia Pfeiffer;
public-texttracks@w3.org
Subject: Re: [blink-dev] WebVTT vs TTML Features

i'll chime in for Viacom here - TTML is widely used.

We have thousands of TTML files here, used for closed captioning and
subtitling across dozens of web sites and mobile applications. For closed
captioning, our native authoring format continues to be 608/708, and our
architecture accommodates a conversion step to a format such as TTML or
webVTT.

The big issue for us is that the conversion from 608/708 to TTML or webVTT
be as lossless as possible, faithfully preserving positioning and roll-up
styles from the original authored captions. from what i've seen, TTML and
webVTT are both doing this pretty well now with the exception of roll-up
support. i hope/assume that both webVTT and TTML renderers will begin to
support roll-ups soon, as it is the standard for live captioned programs.


Glenn Goldstein
Chief Technology Convergence Officer
Tel: (212) 846-3210
Email: glenn.goldstein@viacom.com






On 12/12/13 5:48 AM, "Nigel Megitt" <nigel.megitt@bbc.co.uk> wrote:

>On 11/12/2013 22:11, "David Singer" <singer@apple.com> wrote:
>
>>Hi Andreas,
>>
>>thanks for the thoughtful points.
>>
>>On Dec 11, 2013, at 8:52 , Andreas Tai <tai@irt.de> wrote:
>>
>>> The decision to build upon SRT instead of  TTML and the reasons that 
>>>led to this decision have to be respected. But it seems not correct 
>>>to me now to deny that TTML is a rendering format for "web 
>>>distribution of captions" and ignore the fact that it is widely used for
this purpose.
>>>It was used before WebVTT reached a stable status. This fact seems 
>>>not to be well known and it is often mistrusted so indeed a list 
>>>which content providers already use TTML would make this more
transparent.
>>>
>>> It seems like an irony of the story that the format that were added 
>>>at a later stage for the same purpose makes a claim to be the only 
>>>legitimate candidate for that purpose.
>>
>>I think actions or words that attempt to denigrate, pigeonhole, 
>>spindle, fold, or mutilate [1] either format are not helpful.  We need 
>>to focus our energies on what we care about most: making multimedia 
>>web content accessible.
>
>Agreed - and we need to recognise the sensitivities and try to avoid 
>actions or words that could be interpreted as being derogatory even if 
>they're not intended as such.
>
>As we've seen, we may need to be more explicit about exactly what we 
>mean than we'd normally be while we're collectively developing a common 
>understanding and developing accepted shorthands or jargon.
>
>>>We have two W3C rendering formats for captions on the web. This is 
>>>not a pleasant situation. But we have to cope with it. The new 
>>>development to combine both efforts in one group is a good, pragmatic 
>>>start. It can work out if on both sides co-existence on the same field is
accepted.
>>
>>Completely agree.
>
>Likewise.
>
>Nigel
>
>
>>
>>[1]
>>http://en.wikipedia.org/wiki/Do_Not_Fold,_Spindle_or_Mutilate#cite_not
>>e-1
>>
>>
>>David Singer
>>Multimedia and Software Standards, Apple Inc.
>>
>
>
>
>-----------------------------
>http://www.bbc.co.uk
>This e-mail (and any attachments) is confidential and may contain 
>personal views which are not the views of the BBC unless specifically 
>stated.
>If you have received it in
>error, please delete it from your system.
>Do not use, copy or disclose the
>information in any way nor act in reliance on it and notify the sender 
>immediately.
>Please note that the BBC monitors e-mails sent or received.
>Further communication will signify your consent to this.
>-----------------------------
>

Received on Thursday, 12 December 2013 14:46:06 UTC