Re: text-format discussion from today's call

Hi Geoff,


On Fri, Aug 6, 2010 at 9:24 PM, Geoff Freed <geoff_freed@wgbh.org> wrote:

>
>
>
> On 8/5/10 8:07 PM, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:
>
> 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.
>
> GF:
>
> I’m saying that the decision to recommend a text-display format in HTML5
> should not be made without taking note of, and making accommodations for,
> events in progress elsewhere, especially from the source of the greater
> percentage of video material that lands on the Web.
>


I didn't disagree with this.



>  I’m not saying that TTML must be supported on the Web.  I am saying that
> it should not be ignored.  I’ll add that you should not  ignore, or merely
> toss aside with a cavalier “I’m not worried” flick of the wrist the possible
> ramifications of what you are saying in light of this new legislation.
>


I think that's a misunderstanding (maybe the Australian use of "worries"
;-). In fact, for the last 2 years and more I have been looking at how to
accommodate existing formats in the context of the Web and all I was able to
find was that for different environments there is a need for different
formats.



>  I’m happy to hear that you’re not worried about continuing to transform
> caption files to various formats.  I’m worried about it because it’s been a
> headache for a very long time and I had hoped that the problem would have
> been solved by now.  I’m worried that the use of a new text-display format,
> added to the giant pool of existing and disparate text-display formats, is
> not going to make things any easier for getting captions onto the Web.
>


Unfortunately I don't think we will ever get away from transcoding, unless
all platforms converge to using the same environment.

In the context of the SMPTE, it is very clear that they need a format that
can encapsulate everything that the broadcast industry has dealt with in the
past and it should be a single encompassing format. The TTML is perfect for
that, since it has been created as a super-format for all existing
captioning needs.

But in the Web context, where display of the captions and other
time-synchronized text has to happen, any additional implementation needs
are a problem, in particular if they mean re-implementation of things that
already exist. This is why there is a problem with XSL-FO support, XML
namespaces and diverging markup.

I am not saying that WebSRT as it currently is satisfies all needs - not by
a long shot! You might find that right now I am the one with the most
requests for improvements on WebSRT in the WHATWG and I have experimented
with an alternative called WMML which is xml-based.


> 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.
>
> GF:
>
> I guess that as a broadcaster, or even as a captioning agency, you’re not
> worried about keeping track of which caption files are compatible with which
> players, and what happens when you want to use a new player that doesn’t
> support your old text format, etc.  Your statement  fails to address the
> long-standing problem faced by captioning agencies and broadcasters:  text
> format and player incompatibility.  You’re saying that we must continue to
> transform caption source files to multiple formats to accommodate whatever
> permutations browsers and multimedia players want to support.  Well, then,
> there has been no progress.
>


I understand your position and your challenges. And I, too, would like to
see a solution to the format problem, to stopping all of these transcoding
needs. But unless all systems use the same type of software environment and
use the format for the same use cases, it will be difficult to achieve. We
still haven't a single video format, a single image format, a single text
processing format, a single vector graphics format that is used everywhere.

Regards,
Silvia.