W3C home > Mailing lists > Public > public-tt@w3.org > February 2003

RE: SMIL [Point of order] was : Proposal 0.0

From: Neil Smith <neil@fresh-toast.com>
Date: Wed, 12 Feb 2003 08:57:37 +0000
Message-Id: <5.2.0.9.0.20030212084917.00a83de0@pop.freeserve.net>
To: public-tt@w3.org

At 10:42 11/02/2003 +0000, Johnb@screen.subtitling.com wrote:
>
> > > The point I am trying to make wrt to SMIL timing models is:  How do you
> > > synchronise the 'presentation' of the text with an external often
>discontinuous timebase.

>FileX is indexed against the timecode that is stored as VBI data on TapeX.
>So unlike SMIL - the media are separate - subtitles in one - video and audio
>on another.

Not true : SMIL is only a container with *references* to the media. SMIL 
contains no actual content data (images, video, audio *or* streaming text). 
Though it can have text segments if its constructed badly (or very brief !)

Additionally, about the size of SMIL files, they are often under 1k. 
Streamed text (eg realtext) is usually minimal in size compared to even 
static images used as slides in a presentation (let alone audio or video 
content).

Even better, this text can be compressed - most internet user agents 
(quicktime 4+, media player6.4+, real player 5+) will send an accept gzip 
header.

Looking for this on the server and sending gzip deflate-encoded data will 
reduce the file size to well under 50% (more with an XML based format 
because of compression of repeated tag names).

I frequently see XML zip compression to 15-25% of the original file size. 
So I don't think we need to be too concerned about the verbosity of XML as 
a wire format. Even without server side compression, most modems do a good 
enough job of compressing text for non-web applications.

Cheers,
Neil.

I 
Received on Wednesday, 12 February 2003 12:40:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 2 November 2009 22:41:26 GMT