W3C home > Mailing lists > Public > www-smil@w3.org > October to December 2008

Re: add zip to SMIL 3.0 players

From: Daniel Weck <daniel.weck@gmail.com>
Date: Sat, 18 Oct 2008 22:44:54 +0100
Message-ID: <48FA58D6.6010902@gmail.com>
To: Jack Jansen <Jack.Jansen@cwi.nl>
CC: Jose Ramirez <jose@multimedia4everyone.com>, www-smil@w3.org

On 18/10/08 21:38, Jack Jansen wrote:
> Daisy books, on the other hand, sometimes have immense SMIL files (one
> guy I know always talks about this dictionary or encyclopedia that gives
> no end to problems because of its size). These will probably want each
> of the SMIL files to be zipped separately, so a rader doesn't have to
> unzip a whole encyclopedia, only the index and the relevant chapter.

Just a note to make things clear: compression is not necessary. What's 
more important is a packaging mechanism that produces a single file with 
well-defined de-multiplexing rules. Extracting the individual streams is 
a pretty straight-forward operation with minimal performance overhead.

I'm not sure how live streaming would work though. For example, Ogg is 
specialized in the way in interweaves data streams that are supposed to 
be rendered in a time-aligned fashion. SMIL is a much more complex use-case.

MMS is a small subset of SMIL but I haven't looked at the streaming 
capabilities, so I would not know how to compare.

> In the mean time, if someone want to register mimetype
> application/x-zip+xml+smil (if that's allowable syntax:-): go ahead. The
> magic of HTTP should even allow server-side decoding for clients that
> don't understand it.

The MIME-type should not have to change I think. For example, with 
compressed SVG (not ZIP, but GZIP), a typical Apache configuration would 
look like that:

AddType image/svg+xml svgz
AddEncoding gzip svgz
Received on Saturday, 18 October 2008 21:45:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:53:32 GMT