W3C home > Mailing lists > Public > public-html-a11y@w3.org > August 2010

Re: text-format discussion from today's call

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 7 Aug 2010 16:08:35 +1000
Message-ID: <AANLkTinYQb7Mf_V+j8h1NNALHqZif+0jWWGJrCKqFhvf@mail.gmail.com>
To: Sean Hayes <Sean.Hayes@microsoft.com>
Cc: Geoff Freed <geoff_freed@wgbh.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, Judy Brewer <jbrewer@w3.org>
On Sat, Aug 7, 2010 at 2:24 AM, Sean Hayes <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
it clearly deals with multiple captions at the same time and WebSRT
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.


>  *From:* 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> 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
Received on Saturday, 7 August 2010 06:09:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:42 UTC