Re: HTML 5, SMIL, Video

Hi Dick,

On Fri, Feb 19, 2010 at 10:21 PM, dcab <Dick.Bulterman@cwi.nl> wrote:
> Hi John and Silvia,
>
> A couple of comments that address the batch of recent mails:
>
> On the availability of smilText, see:
>  http://ambulantplayer.org/Toys.shtml
> There are two items here of interest -- the smilText javascript engine, and
> a simple captioning interface for youTube video.
> (Silvia will be thrilled to see that the captioning tools allows you to
>  export to either smilText or .srt!!)
> [Note also that the in-line version of smilText requires timing markers in
> the form: <tev ...> </tev>. This is a browser XML problem, not a smilText
> issue.]

Is any of this used by anyone outside CWI? I am not asking to make a
case about the number of users, but rather a case about: who is
screaming to have support for this? I have seen several players that
are widely used online (both commercially and free) support DFXP, but
I have only seen jwplayer support smilText in the past and they have
removed it. Obviously there was no business case for it. Is there
anything that smilText does that is above what DFXP does?

> On .srt -- my view is that people are making a passive choice for SRT. It is
> a format that is easy to hand edit and is playable on the desired target
> platform. Other than that, it has no inherent value -- it has no path to
> expansion, it has no broader model, and it has no easy fit as an in-line
> format for HTML pages. Instead of wasting time on an RFC for SRT, we should
> simply provide a converter to whatever format is ultimately chosen. Anyone
> who values placing captions in Web pages can than move their old content in
> nano-seconds.

Converters will be necessary anyway.

The combination of DFXP and SRT actually make a lot of sense. DFXP
provides the complicated markup that you need to get non-Web players
to have feature-rich subtitles. SRT provides the basic markup that you
want if you want to control all display needs from HTML and don't care
how simple the subtitles look in normal players. Let's stop discussing
the need for SRT and DFXP and start discussing the need for smilText.


> As for the future, it seems to me that we need a format that can be used
>  in-line in a HTML document (for incidental labels, captions or
> (sub)titles), and as an external specification. I don't see ANY advantage to
> SRT here.

I don't see any advantage of this markup:
<smilText dur="6s">
	Hello<br/>world!
	<tev next="2s"/>
	How are you today?
	<clear begin="4s"/>
	I gotta go now!
</smilText>

over this markup:
1
00:00:00,000 --> 00:00:04,000
Hello world!

2
00:00:02,000 --> 00:00:04,000
How are you today?

3
00:00:4,000 --> 00:00:06,000
I gotta go now!

If anything, the SRT markup is more readable.

> Note that counting the current number of smilText, DFXP or SRT
> files out there is in no way a useful measure -- as long as we don't
> disenfranchise users with existing content, then the added value of having
> timed text in web pages will hugely compensate for the initial conversion.
> (When HTML was introduced, there were way more .doc files out there than
> .html....)

doc files don't fulfill the same need as html files. If smilText
fulfills the same need as DFXP, then I don't see a need to add that
format support. If they fulfill different needs, I'd like to see use
cases - what can smilText do that DFXP cannot? I think you have
started some reasons below...

> We debated the SRT issue intensely within SYMM before starting on smilText.
> Our reason for not using SRT was that there is no growth path based on any
> inherent value in the SRT format -- everything you would potentially want to
> do for future enhancement would have to be added anyway. What are these
> enhancements? We felt:
>  - text styling
>  - text motion
>  - suitability for Labels, informal text annotation (such was: wow, this is
> cool!)
>  - the potential for using text as a temporal navigation tool by allowing
> (timed) anchors in captions.

Yup, that's what I am looking for in DFXP.


> From my perspective, DFXP goes a long way to meet the needs of professional
> captions and subtitles, but the in-line integration in HTML is not trivial.

So, the inline integration is an interesting issue. Cue Ranges have
been the proposal for this in HTML5 before. They are just timed pieces
of html and the SMIL area element has been proposed as a container for
such. That strikes me as even more flexible than prescribing a
specific external file format for internal use. But the discussion
about cue ranges will have to return, since that problem has not been
solved.


> I am convinced that the 'kids' that John spoke of care about impact. Having
> your content be supported within a web page is much, much, much more
> important that having it be in any particular format.

This is an argument for SRT in my opinion, since it will be simple for
the browser vendors to provide support for it. There are no xml
namespaces, markup mergers, security issues for tag parsing from other
resources and similar xml-related issues to solve. Much easier than
trying to merge a xml format into html.


Best Regards,
Silvia.

Received on Saturday, 20 February 2010 06:32:35 UTC