[whatwg] On the subtitle format for HTML5

2010/5/22 Carlos Andr?s Sol?s <csolisr at gmail.com>:
> Hello, I've been writing lately in the WHATWG and WebM mail-lists and would
> like to hear your opinion on the following idea.
>
> Imagine a hypothetical website that delivers videos with subtitles that can
> be chosen by the user. And also imagine there is the possibility of
> downloading a file with the video, along with either the chosen subtitle
> tracks, or all of them at once. The problems on multiple tracks I have
> already discussed in another thread; this one deals mainly with subtitle
> formats. There is still an issue on which format should be used for
> subtitling in HTML5. As you might know, there are basic subtitle formats
> that are formed by timed plain text and little else (like SRT or the
> proposed WebSRT), and there are full-blown subtitle formats that allow for
> extreme formatting and typesetting (like Advanced SubStation Alpha). The
> basic subtitles have the advantage of being easily editable by hand, but
> sacrificing capabilities that advanced formats allow with the cost of
> harder-to-understand syntax. It would be a shame to drop advanced subtitles
> from the HTML5 specs, but it would be bothersome if everybody is forced to
> use a complex-to-write format. So a middle ground could be handy: allowing
> WebSRT for the simple tasks, and using another format for advanced
> typesetting. To put an example, ASSA allows to modify the text font, size,
> border, shadow, scale, rotation, position, and some other properties; it
> also allows movement of text, text animation, karaoke, and even some
> vectorial graphing.

There is little, if any, reason to bake most of that directly into the
subtitle format.  WebSRT just grabs all the necessary use-cases (size,
karaoke, etc) and bakes them in, in approximately the simplest way
possible.  Then more advanced stuff can be done through existing
technology.  In a browser, you can do it with ordinary CSS.  In other
devices, they can either come up with their own way of doing things,
or embed a CSS-compliant renderer and just use CSS like everyone else.
 The latter is probably going to prove to be the most popular, since
you can just embed a modified webkit or similar into your device and
be done with it.


> But all of that could be achieved with HTML5 programming
> on top of the WebSRT format (or whichever gets chosen). This, of course,
> causes a pair of problems.
> * The first one is that there would be no tools to edit HTML5 subtitles
> specifically, forcing to make a type of subset which would have to be
> standardized, plus an editor to be able to create such subtitles without
> having to learn how to create a full-blown website.
> * The second one is that media players that wanted to use such subtitles
> would be forced to ship an HTML5 decoder. Most media players are NOT web
> browsers, though, or based on one either. The only exceptions I remember are
> media players built on top of XUL, like Songbird or Nightingale. But players
> like WMP, WinAmp, VLC, Xine family, GStreamer family or MPlayer family would
> be left out, since they have no need (and no time) to plug in a web browser
> in a program that hasn't needed it.

This is why you want the format as simple as possible, and then just
layer existing technology on top of it.  Simple devices that don't
want to care about advanced styling don't have to; as long as they
support the handful of things that WebSRT requires, they're good.

~TJ

Received on Sunday, 23 May 2010 17:00:17 UTC