add zip to SMIL 3.0 players

[jose-11]

Hello,

With SMIL 3.0 getting close to Recommendation status.

Could the developers of SMIL 3.0 Language profile players borrow a page
from OpenDocument.

http://en.wikipedia.org/wiki/OpenDocument

And add the ability to open zip files with SMIL content.

I can see SMIL 3.0 Language profile being successful on private networks
where the connections are fast.

On the Internet a lot of people still have dial-up and slower broadband
access.

SMIL zips could make sure all will view the SMIL presentation as the
author intended.

And if zipping SMIL files is proven helpful, the next SMIL version can
make it part of the spec.


Good Luck and keep up the good work SMIL WG,
Jose Ramirez

[Daniel Weck]

Hi !

There are a number of challenges with packaging a multimedia file set,
such as the issue of network streaming, or the fact that SMIL is often
used as an aggregator for external data sources that are not necessarily
located at the same place.

Some related concerns have been addressed by Open-Office or Microsoft
Office's respective ZIP-based packaging standards. It is also worth
noting that IDPF's ePub format uses a packaging method that is derived
from the Open-Office standard (multi-parts, manifest, compression, etc.).

Food for thoughts.
Regards, Daniel

On 18/10/08 17:57, Jose Ramirez wrote:

> Hello,
>
> With SMIL 3.0 getting close to Recommendation status.
>
> Could the developers of SMIL 3.0 Language profile players borrow a page
> from OpenDocument.
>
> http://en.wikipedia.org/wiki/OpenDocument
>
> And add the ability to open zip files with SMIL content.
>
> I can see SMIL 3.0 Language profile being successful on private networks
> where the connections are fast.
>
> On the Internet a lot of people still have dial-up and slower broadband
> access.
>
> SMIL zips could make sure all will view the SMIL presentation as the
> author intended.
>
> And if zipping SMIL files is proven helpful, the next SMIL version can
> make it part of the spec.
>
>
> Good Luck and keep up the good work SMIL WG,
> Jose Ramirez
>
>
>

[jose-11]

Hello Daniel,

SMIL players could support both methods.

The SMIL zip link can be placed under the SMIL link on a webpage. For
those with a slow connection they can still view content as intended.

Mobile and Daisy profiles have their own containers, the SMIL Language
profile would benefit too IMHO.

IDPF's ePub format looks interesting:
https://www.idpf.org/forums/viewtopic.php?t=22

Jose Ramirez



-------- Original Message --------
Subject: Re: add zip to SMIL 3.0 players
From: Daniel Weck <daniel.weck@...>
Date: Sat, October 18, 2008 10:39 am
To: Jose Ramirez <jose@...>
Cc: www-smil@...


Hi !

There are a number of challenges with packaging a multimedia file set,
such as the issue of network streaming, or the fact that SMIL is often
used as an aggregator for external data sources that are not necessarily

located at the same place.

Some related concerns have been addressed by Open-Office or Microsoft
Office's respective ZIP-based packaging standards. It is also worth
noting that IDPF's ePub format uses a packaging method that is derived
from the Open-Office standard (multi-parts, manifest, compression,
etc.).

Food for thoughts.
Regards, Daniel



On 18/10/08 17:57, Jose Ramirez wrote:

> Hello,
>
> With SMIL 3.0 getting close to Recommendation status.
>
> Could the developers of SMIL 3.0 Language profile players borrow a page
> from OpenDocument.
>
> http://en.wikipedia.org/wiki/OpenDocument
>
> And add the ability to open zip files with SMIL content.
>
> I can see SMIL 3.0 Language profile being successful on private networks
> where the connections are fast.
>
> On the Internet a lot of people still have dial-up and slower broadband
> access.
>
> SMIL zips could make sure all will view the SMIL presentation as the
> author intended.
>
> And if zipping SMIL files is proven helpful, the next SMIL version can
> make it part of the spec.
>
>
> Good Luck and keep up the good work SMIL WG,
> Jose Ramirez
>
>
>

[Jack Jansen]

I agree that a container definition would be beneficial but it's not something you can graft on in a couple of days.

For one thing, people will want containers for many different reasons. For example, MMS uses containers because they want to ship the media with the SMIL presentation. They didn't really care about size (their SMIL files are tiny), so they decided to use mime-multipart like containers.

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.

If the SYMM group defined one standard container format it would  likely do more damage than good, unless all the use cases were studied and catered for.

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.

--

Jack Jansen, <Jack.Jansen@...>, http://www.cwi.nl/~jack

If I can't dance I don't want to be part of your revolution -- Emma Goldman

[jose-11]

The other containers were not created by the SYMM group.

The main beneficiaries of a SMIL 3 Language profile zip would be
Ambulant and Helix/RealPlayer. And everybody on the net :)

Is it feasible to ask Ambulant and Helix/RealPlayer developers to work
together to create a SMIL zip container?

jose

Web 1 HTML
Web 2 SMIL

-------- Original Message --------
Subject: Re: add zip to SMIL 3.0 players
From: Jack Jansen <Jack.Jansen@...>
Date: Sat, October 18, 2008 1:38 pm
To: Jose Ramirez <jose@...>
Cc: www-smil@...

I agree that a container definition would be beneficial but it's not
something you can graft on in a couple of days.


For one thing, people will want containers for many different reasons.
For example, MMS uses containers because they want to ship the media
with the SMIL presentation. They didn't really care about size (their
SMIL files are tiny), so they decided to use mime-multipart like
containers.


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.


If the SYMM group defined one standard container format it would  likely
do more damage than good, unless all the use cases were studied and
catered for.

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.
 --
 Jack Jansen, <Jack.Jansen@...>, http://www.cwi.nl/~jack
 If I can't dance I don't want to be part of your revolution -- Emma
Goldman
 

[Daniel Weck]

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

[George Kerscher]

Hello,

I  don't comment often, but there is interest in the IDPF to move their package file forward, perhaps under ISO. If that were to happen, it would be great for it to have the ability to package up SMIL presentations.

Best
George

> -----Original Message-----
> From: www-smil-request@... [mailto:www-smil-request@...] On
> Behalf Of Jose Ramirez
> Sent: Saturday, October 18, 2008 3:33 PM
> To: Jack Jansen
> Cc: www-smil@...
> Subject: RE: add zip to SMIL 3.0 players
>
>
>
> The other containers were not created by the SYMM group.
>
> The main beneficiaries of a SMIL 3 Language profile zip would be
> Ambulant and Helix/RealPlayer. And everybody on the net :)
>
> Is it feasible to ask Ambulant and Helix/RealPlayer developers to work
> together to create a SMIL zip container?
>
> jose
>
> Web 1 HTML
> Web 2 SMIL
>
> -------- Original Message --------
> Subject: Re: add zip to SMIL 3.0 players
> From: Jack Jansen <Jack.Jansen@...>
> Date: Sat, October 18, 2008 1:38 pm
> To: Jose Ramirez <jose@...>
> Cc: www-smil@...
>
> I agree that a container definition would be beneficial but it's not
> something you can graft on in a couple of days.
>
>
> For one thing, people will want containers for many different reasons.
> For example, MMS uses containers because they want to ship the media
> with the SMIL presentation. They didn't really care about size (their
> SMIL files are tiny), so they decided to use mime-multipart like
> containers.
>
>
> 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.
>
>
> If the SYMM group defined one standard container format it would
> likely
> do more damage than good, unless all the use cases were studied and
> catered for.
>
> 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.
>  --
>  Jack Jansen, <Jack.Jansen@...>, http://www.cwi.nl/~jack
>  If I can't dance I don't want to be part of your revolution -- Emma
> Goldman
>
>
>
>
>
>
>