RE: A new proposal for how to deal with text track cues

>Be honest to yourself: how much further is TTML? 
>It doesn't have a rendering algorithm yet,

Depends on what you mean by algorithm. It has a reference semantics for expected visual output. It's had that for 5 years or more; the fact that certain parties don't like the language its expressed in doesn't change that fact.  If you don't think that's a rendering algorithm then HTML and CSS have got along just fine without a rendering algorithm for decades, so we're good there. Perhaps you mean that the re-expression of the visual semantics in HTML/CSS is not at rec status yet. That is true, however even the re-expression has been around for a couple of years now and has been implemented a couple of times.

> It doesn't have a JavaScript API that browsers would need to implement it properly (so application developers can manipulate the format), 

Of course it does - in fact it had the API before the format even existed, it's XML so the XML DOM just works. If you mean we don't have a final published shim that layers it into the HTML5 track API, well no, we hardly could have because you keep moving the goalposts, but we are attempting to keep our draft in sync with your changes so as soon as you are done we will be too.

>it still has bugs that prevent interoperable implementations in details. 
If you know of such bugs please report them. The 70 outstanding issues are in fact extension requests for the next version based on implementation and roll out experience gathered over the last 5 years or so for 10's of thousands of hours of content There are multiple implementations that pass the test suite. It is however always the case that there will be implementations and users that don't follow the spec, and report that as interoperability issues that's just life and not a lot we can do as spec writers to change it

WebVTT even has a validator:
http://quuz.org/webvtt/.

As does TTML:
https://github.com/skynav/ttv 

Hope this helps bring you up to speed.

Sean.

-----Original Message-----
From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com] 
Sent: 14 June 2013 11:14
To: John Birch
Cc: Glenn Adams; public-tt
Subject: Re: A new proposal for how to deal with text track cues

Hi John,

On Thu, Jun 13, 2013 at 1:30 AM, John Birch <John.Birch@screensystems.tv> wrote:
> Hmmm... I don't know where to start with this one. The following comments may seem harsh, but they do reflect my **personal** perspective of WebVTT.

It is indeed sad that there is so much misinformation about VTT out there and so much prejudice. Hopefully I can help to clarify some aspects here.


> Email threads can only go so far... and promoting a half-finished strawman as a standard and inviting people to comment / fix it does not seem to be an efficient route to a clear and effective standard either?

Be honest to yourself: how much further is TTML? It doesn't have a rendering algorithm yet, it doesn't have a JavaScript API that browsers would need to implement it properly (so application developers can manipulate the format), it still has bugs that prevent interoperable implementations in details. WebVTT even has a validator:
http://quuz.org/webvtt/.

Please don't get me wrong: I'm not trying to attack TTML - HTML is another example of a format that continues to change. I'm just trying to put this statement into perspective. All formats always evolve to support more features. Bugs continue to be found and fixed. That doesn't mean that the format is a "half-finished strawman", which, incidentally, is rather derogatory language and doesn't sound very welcoming to anyone trying to work with WebVTT .


> (Especially when there are other open public standards that may be 
> more advanced in progress and may have followed a more conventional 
> route?)

The route in which standards are created has nothing to do with the quality of the outcome. Many de-facto standards and industry standards were created over the years that are of high quality, and many specifications that "real standards bodies" following "real standardisation processes" have created have come out bloated and unusable and were never implemented.


> RE: lack an evident appreciation of current captioning /subtitling workflows and conventions.

> There seems to be no cognisance of the wider community of captioning / subtitling... no sense of how WebVTT content might be created by conversion from other formats (like 608/708, or from Teletext etc).

You may have missed that there is an actual spec for this:
https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html
Other conversions are planned, but have not been required yet.


> There does not seem to be a huge awareness of the role of a professional captioner or subtitler. Or of the role of commercial subtitling and captioning organisations, or of the existence of (internal) quality standards for caption / subtitling services that are adopted (insisted upon) by those organisations.
> The professional captioning and subtitling profession is largely ignorant of WebVTT.

If this statements implies that professional captioning and subtitling organisations are ignoring WebVTT, then you may have overlooked that some are already supporting it and others are keeping a close eye.
They don't seem to be making a big fuss about it though. For example:

http://www.cpcweb.com/webcasts/webcast_samples.htm#WebVTT
http://www.automaticsync.com/captionsync/captionsync-delivers-webvtt-output/
http://www.synchrimedia.com/
http://www.longtailvideo.com/support/jw-player/29360/basic-vtt-captions/
http://www.wowza.com/forums/content.php?498-How-to-stream-WebVTT-subtitles-to-iOS-for-closed-captioning


> IMHO to be adoptable by the commercial / professional community:
>
> WebVTT (as a standard) needs to:
>         clearly and directly express the professional author's intent (not indirectly).
>         support current conventions (positioning, style, timing).
>         result in implementations that allow content to be identically displayed regardless of which implementation is rendering it.


Agreed (though I don't know what you mean by "indirectly expressing author's intent"). WebVTT as it is specified does all these things, minus bugs.

Hope this clarifies some of the misunderstandings that this group has with WebVTT.

Best Regards,
Silvia.



> Best regards,
> John
>
> John Birch | Strategic Partnerships Manager | Screen Main Line : +44 
> 1473 831700 | Ext : 270 | Direct Dial : +44 1473 834532 Mobile : +44 
> 7919 558380 | Fax : +44 1473 830078 John.Birch@screensystems.tv | 
> www.screensystems.tv | https://twitter.com/screensystems
>
> Visit us at
> Broadcast Asia 2013, 18 - 21 June 2013, Booths 5E4-01 & 5E4-02, UK 
> Pavillion, Marina Bay Sands, Singapore
>
>
> P Before printing, think about the environment-----Original 
> Message-----
> From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
> Sent: 12 June 2013 14:06
> To: John Birch
> Cc: Glenn Adams; public-tt
> Subject: Re: A new proposal for how to deal with text track cues
>
> On Wed, Jun 12, 2013 at 10:50 PM, John Birch <John.Birch@screensystems.tv> wrote:
>> I'm not personally over concerned with where or who does this kind of 
>> work, but am far more concerned with how it is done.
>>
>>
>>
>> For me, a process that involves substantial requirements analysis 
>> performed with the involvement of all potentially interested parties 
>> seems far more likely to result in a workable specification.
>
> Agreed. That's what the email threads are after.
>
>
>> If WebVTT is targeted at commercial use cases, it does IMHO seem to 
>> lack an evident appreciation of current captioning /subtitling 
>> workflows and conventions.
>
> Please explain. What workflows and conventions does WebVTT break?
>
> Best Regards,
> Silvia.
>
> This message may contain confidential and/or privileged information. 
> If you are not the intended recipient you must not use, copy, disclose 
> or take any action based on this message or any information herein. If 
> you have received this message in error, please advise the sender 
> immediately by reply e-mail and delete this message. Thank you for 
> your cooperation. Screen Subtitling Systems Ltd. Registered in England 
> No. 2596832. Registered Office: The Old Rectory, Claydon Church Lane, 
> Claydon, Ipswich, Suffolk, IP6 0EQ

Received on Friday, 14 June 2013 12:22:16 UTC