RE: text-format discussion from today's call

Actually I think there is a typo in the WebSRT description. As it does preclude cues that start at the same time, not surprising for a new un-implemented spec.
The time represented by this WebSRT timestamp<http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-timestamp> must be greater than the start time offsets of all previous cues in the file
But as you say the abstract cue list allows for it; so I think this must be an error.

It also needs the ability to record both the vertical and horizontal size of the cue in order for this to work properly (e.g. capture 608 captions).

It also has a very flat markup structure, so it can't be styled to the same extent as TTML (without using some text selection type selectors which would be very clunky). For example having bold italic would be a problem.

In a sense one can think of WebSRT as 'unrolled'  TTML. It is possible to compute all of the 'events' from a TTML file and map them to this cue architecture, although I think a cue should just have an HTML fragment as its payload, and leave it to formats to define how they map to the HTML fragment.

From: Silvia Pfeiffer [mailto:silviapfeiffer1@gmail.com]
Sent: 07 August 2010 07:09
To: Sean Hayes
Cc: Geoff Freed; HTML Accessibility Task Force; Judy Brewer
Subject: Re: text-format discussion from today's call

On Sat, Aug 7, 2010 at 2:24 AM, Sean Hayes <Sean.Hayes@microsoft.com<mailto:Sean.Hayes@microsoft.com>> wrote:

"WebSRT by the WHATWG is already capable of supporting almost all of TTML, so I am not worried about this."
I don't think this is true. WebSRT doesn't for example doesn't support arbitrary positioning of multiple captions in the video rectangle at the same time.  TTML is a superset of WebSRT in terms of functionality.


It actually does. If you read up on http://www.whatwg.org/specs/web-apps/current-work/complete/rendering.html#timed-tracks-0 , it clearly deals with multiple captions at the same time and WebSRT allows for such.


However I've looked at what Ian is up to recently, and I think that TTML could map fairly well into his evolving architecture, so all we need to make sure is that he doesn't explicitly rule it out.

I also would prefer to keep the <track> platform open to any file format. Though I do believe we need a baseline format that all browsers implement. What happens on top of that can be flexible.


He has special cased a bunch of stuff because of his insistence that WebSRT is all that is needed, but I think that might be straightened out, if it ever gets proposed back into the HTML process, and assuming that he is open to technical feedback.


I'm trying to give technical feedback now also.

Cheers,
Silvia.


From: public-html-a11y-request@w3.org<mailto:public-html-a11y-request@w3.org> [mailto:public-html-a11y-request@w3.org<mailto:public-html-a11y-request@w3.org>] On Behalf Of Silvia Pfeiffer
Sent: 06 August 2010 01:07
To: Geoff Freed
Cc: HTML Accessibility Task Force; Judy Brewer
Subject: Re: text-format discussion from today's call

Hi Geoff,

This is all very interesting indeed.

I do wonder, however, how much "automatism" can be in there from saying because "SMPTE is using TTML as their transcoding format for IP delivery of captions" to saying "TTML also has to be supported by the Web". The problem about this statement is implementation support in Web browsers. If no Web browser is implementing support for TTML, TTML will not mean much on the Web, no matter how many TTML documents exist from repurposed broadcast captions.

But, to be honest, I do not see that as a big problem. Transcoding from one text format to another is not a big issue where those formats support the same functionality. I believe that whatever format will be chosen for HTML5, it will support all the TTML features, so there should be no problem in transcoding. In fact, even the proposed draft WebSRT by the WHATWG is already capable of supporting almost all of TTML, so I am not worried about this.

In fact, if I was a broadcaster, I would probably just create both file types from my existing broadcast captions and use them as appropriate. It has been done with video before and is a much bigger problem there since transcoding in video means data loss. This is not the case for text, so won't be much of an issue, IMHO.

But, you are right, it is good to know these things and to make sure they are compatible. Thanks for sharing!

Regards,
Silvia.
On Fri, Aug 6, 2010 at 2:52 AM, Geoff Freed <geoff_freed@wgbh.org<mailto:geoff_freed@wgbh.org>> wrote:

Greetings, all:

Regarding the conversation on the call today about timed-text formats, I'd like to offer some further thoughts regarding the format eventually recommended by the a11y group and/or HTML5 and how it may affect others.  At a minimum these comments may further complicate matters.  Sorry...

Some on the list may be aware that SMPTE (Society of Motion Picture and Television Engineers) is coming close to completing a standard for the repurposing of broadcast captions for IP delivery.  This standard, called SMPTE-TT, is based almost entirely on TTML.  SMPTE-TT will provide broadcasters a clearly defined method for converting huge libraries of existing captions for Web delivery.

Many here may also be aware of legislation making its way through the U.S. Congress that will, in some form, mandate the inclusion of captions and descriptions on some types of video material on the Web, most likely related to material that originates in the broadcast sphere and is then transferred to the Web.  The U.S. House of Representatives passed its version of the bill (HR3101, The 21st-Century Communications and Video Accessibility Act; http://www.coataccess.org/node/9733) last week, and the Senate is still debating its version but is expected to complete its work soon.

Among its many provisions, HR3101 contains the following language:

============
(1) CLOSED-CAPTIONING REPORT.-Within 6 months after the date of the first meeting of the Advisory Committee, the Advisory Committee shall develop and submit to the Commission a report that includes the following:

(A) An identification of the performance objectives for protocols, technical capabilities, and technical procedures needed to
permit content providers, content distributors, Internet service providers, software developers, and device manufacturers to
reliably encode, transport, receive, and render closed captions of video programming delivered using Internet protocol.

(B) An identification of additional protocols, technical capabilities, and technical procedures beyond those available as of the
 date of enactment of this Act for the delivery of closed captions of video programming delivered using Internet protocol that
are necessary to meet the performance objectives identified under subparagraph (A).

(C) A recommendation for any regulations that may be necessary to ensure compatibility between video programming
delivered using Internet protocol and devices capable of receiving and displaying such programming in order to facilitate
access to closed captions.
============

C is most relevant here:  it's stating that the committee must recommend a format for IP delivery of captions.  The committee specified in (1) will probably have significant representation from the broadcast world, and my educated guess is that broadcasters are probably going to push for SMPTE-TT as the standard to specify in the regulations.  If there is a disconnect between this recommendation and what is recommended in HTML5, it could create a significant headache for the broadcast industry.  In short, harmonization of the text-display formats would be ideal.

It's important to keep this specific issue in mind while debating the text-format problem, and I raise it just to remind everyone that a good deal of video on the Web, especially captioned video, originates elsewhere and will continue to do so for some time.  The amount of captioned programming repurposed from the broadcast world is significant, and we should be paying close attention to what is happening there.  Broadcasters will probably favor a single conversion format for captions from terrestrial/cable to Web.  In other words, if they're already having to convert from CEA-608/708 to SMPTE-TT (not a done deal), they're probably not going to want to do another conversion, with potentially different results or limitations, to whatever format is recommended by HTML5 and its implementers.

Discuss.

Thanks.
Geoff/NCAM