LASeR is a scene description format, where a scene is a spatial, temporal and behavioural composition of audio media, visual media, graphics elements and text. LASeR is binary or compressed like BIFS or Flash, as opposed to textual scene descriptions such as XMT or VRML or SVG. LASeR stands for Lightweight Application Scene Representation.
SAF is a streaming-ready format for packaging scenes and media together and streaming them onto such protocols as HTTP/TCP. SAF services include:
a simple multiplex for elementary streams (media, fonts or scenes);
synchronisation and packaging signalling.
SAF stands for Simple Aggregation Format.
LASeR and SAF have been designed for use in mobile, interactive applications.
Why LASeR ?
The decision to create yet another standard for scene description was taken after a thorough survey of available open or de-facto standards: BIFS, Flash and SVGT.
Profiling of BIFS was tried to create a small enough subset to be used on mobile phones, to no avail. Flash is proprietary and is too big for most mobiles. SVGT1.1 is getting some traction, but on one hand SVGT1.1 does not have AV interfaces or dynamicity, and on the other hand its successor, SVGT1.2, is still in flux, and while it will feature AV interfaces, it will still miss dynamicity, compression, streaming and is significantly heavier than SVGT1.1. Also, SVGT in general relies on a host of other standards such as DOM, SMIL, ECMA-Script, XHTML and CSS, MIME multipartˇ¦ and to manage such a pile of standards is a true challenge in terms of interoperability.
Why SAF ?
The decision to create yet another standard for distribution of mobile content was taken after implementing and trying interactive services on small devices, based on RTP/RTSP or MP4/3GP download (progressive or not) on TCP/HTTP. In most cases, the need for a simpler, lighter solution was obvious. In order to package efficiently and download progressively or stream a scene with a few media, RTP is overkill, and MP4/3GP is not well suited to the job: MP4/3GP format is a file format, and it can only be used for progressive download by using special cases (moov atom in front of the file, media interleaved in time order). In addition, MP4/3GP has a host of features that burden a mobile implementation for no reason. In order to reduce the design time of SAF and get almost an immediate validation, SAF was designed around a simple configuration of a proven technology: the MPEG-4 Systems Sync Layer. This enables as a bonus the availability of an RTP payload format for SAF for free with RFC3640.
So as a summary, SAF has the minimal/optimal set of features for the job, and can be mapped easily to other transport mechanisms (RTP, MP4/3GP, MPEG-2 TSˇ¦)
Requirements of LASeR
The requirements which structure the design of LASeR are:
1 Support efficient and compact representation of scene data supporting at least the subset of SVG T 1.1 object set functionality. (Today LASeR is aligned as much as possible with SVGT1.2 )
2 Allow an easy conversion from other graphics formats (e.g. BIFS, SMIL/SVG, PDF, Flash, ˇ¦).
3 Provide efficient coding, to be suitable for the mobile environment.
4 Allow separate streams for 2D and 3D content.
5 Allow the representation of scalable scenes.
6 Allow the representation of adaptable scenes, for use within the MPEG-21 DIA framework.
7 Be extensible in an efficient manner.
8 Allow small profiles definition.
9 Allow the representation of error-resilient scenes.
10 Allow encoding modes easily reconfigurable and signalled in band.
11 Provide an optimal balance between compression efficiency and complexity and memory footprint of decoder and compositor code.
12 A llow integer-only implementation of decoding and rendering.
13 Allow to save/restore several scene states. The saving and restoring shall be triggerable either by the server or by the user.
14 Allow low-complexity profiles implementable on Java MIDP platform.
15 Allow the representation of differential scenes, i.e. scenes meant to build on top of another scene.
16 Allow interaction through available input devices, such as mobile keyboard or pen, and support the input of strings.
17 Allow safe implementation of scene decoder.
In addition, it is deemed crucial that LASeR is designed in such a way that implementations can:
Be as small as possible.
Be as fast as possible.
Require as small as possible runtime memory.
Be implementable at least partially in hardware.
Requirements for Simple Aggregation Format (SAF)
The requirements which structure the design of SAF are:
1 Provide a simple aggregation mechanism for Access Units for various media in aggregated packets (Video, Audio, Graphics, Images, Text/Font ˇ¦).
2 Allow a synchronized presentation of the various media elements in a packet or a sequence of such aggregated packets.
3 Be as bit efficient as possible.
4 Be byte aligned.
5 Be easily transported on popular interactive transport protocol (e.g. HTTP).
6 Be easily mapped on popular streaming protocol (e.g. MPEG-4 RTP payload format RFC 3640).
7 Be extensible in an efficient manner.
8 Allow the management of pre-loaded objects that enables the server to anticipate the downloading of the corresponding objects to improve user experience.
What is LASeR ?
a SVGT scene tree, with an SVG rendering model;
an updating protocol, allowing actions on the scene tree such as inserting an object, deleting an object, replacing an object or changing a property: this is the key to the design of dynamic services and a fluid user experience. This updating protocol can also be seen as a kind of micro-scripting language;
OpenType text and fonts, including downloadable/streamable fonts;
a binary encoding which, coupled with the updating protocol, allows the incremental loading/streaming of scenes, with excellent bandwidth usage;
a few LASeR extensions to improve the support of input devices, or the flexibility of event processing without a full scripting language, or simple axis-aligned rectangular clipping.
Because of the above, LASeR may also have:
a micro-DOM or JSR226 interface, since the scene tree is almost purely SVG, thus allowing the design of complete applications on top of the LASeR engine;
the micro-DOM interface also makes it possible to use ECMA-Script with LASeR scenes
because of the updating protocol which is similar to that of Flash, it is easy to convert Flash content to LASeR
What is SAF ?
a fixed configuration of the MPEG-4 Systems Sync Layer, providing a easy yet powerful way of packaging elementary streams;
a simplified stream description mechanism;
a simple multiplex for several media, fonts and scene streams.
SAF streams may be:
packaged in RTP/RSTP using the payload format defined in RFC3640;
packaged in MP4/3GP files using a mapping defined with SAF;
packaged in MPEG-2 Transport Stream using the SL mapping defined in ISO/IEC. 14496-8