- From: Daniel Weck <daniel.weck@gmail.com>
- Date: Sat, 18 Oct 2008 22:44:54 +0100
- 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 UTC