- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Sun, 11 Apr 2010 22:30:41 +1000
Hi Chris,
On Sun, Apr 11, 2010 at 6:38 PM, Chris Double <chris.double at double.co.nz> wrote:
> On 10/04/10 10:41, Silvia Pfeiffer wrote:
>>
>> This proposal introduces declarative markup to associate external
>> timed text resources (such as captions and subtitles) with a media
>> resource. It introduces<track> ?and<trackgroup> ?elements to be used
>> inside media elements and provides some recommendations on how to
>> render the text resources.
>> --------------
>
> The proposal mentions SRT. There is no official specification for SRT is
> there? If so, will there be a definition of the version of SRT that is
> expected to be supported? The Wiki entry [1] mentioned lists a number of
> optional extensions for example. Are these expected to be supported?
A very good question. Right now, we have only discussed supporting the
bare essentials of SRT, i.e. unformatted text. That makes also sense
for example for textual audio descriptions. I would propose to stick
with that.
I've discussed the missing spec issue once with Ian and others before
and we agreed that it wouldn't be difficult to write an RFC for SRT
and in this way also register a "decent" MIME type for it. I've
already found out who to work with at the IETF, so when I get around
to it, I will write the IETF Internet-Draft, so we can start on the
process. It should be fairly painless (done it before with Ogg).
> Is it expected that all of TTML will be required? The proposal suggests
> 'starting with the simplest profile', being the transformation profile. Does
> this mean only the transformation profile is needed to provide subtitle
> features equivalent to SRT?
That is also something that still has to be discussed further. Initial
feedback from browser vendors was that the full TTML spec is too
complicated and too much to support from the start. Thus, the
implementation path with the TTML profiles is being suggested.
However, it is as yet unclear if there should be a native parsing
implementation of TTML implemented in browsers or simply a mapping of
TTML markup to HTML/CSS/JavaScript. My gut feeling is that the latter
would be easier, in particular since such a mapping has been started
already with Philippe's implementation, see
http://www.w3.org/2009/02/ThisIsCoffee.html . The mapping would need
to be documented.
> The later note ("two formats are proposed to be supported, one of which is
> trivially simple and the other has all the bells and whistles required for
> high-quality caption and subtitles") seems to imply that more than the
> transformation profile will be required.
Yes, ultimately that is the idea. I would even suggest that TTML as it
stands now needs further extension to be a generic timed text markup
language - I for one am missing hyperlinks in it and I'm sure others
would like other features. I for one think the we require a bit more
experience with the complexer format features (probably through
JavaScript based implementations) before we can really describe a what
next to implement after the transformation profile.
> I am wary of being required to implement the entire TTML specification and
> an underspecified SRT format.
Understood. I hope I have been able to paint a path that makes you
more comfortable about it.
Cheers,
Silvia.
Received on Sunday, 11 April 2010 05:30:41 UTC