- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Tue, 09 Aug 2011 10:00:19 +0200
- To: public-webapps@w3.org
Hi Charles, > I believe that GPAC seeks through large SVG files via offsets and small buffers, from what I understood at SVG F2F. > http://gpac.wp.institut-telecom.fr/ > The technique is similar to what PDF has in it's spec. I don't know what you're referring to. > SVG does not have byte offset hints, but GPAC expects > data to be processed by an authoring tool and otherwise works with transcoding, much as VLC (VideoLan) does. The details of how we can do it is here: http://biblio.telecom-paristech.fr/cgi-bin/download.cgi?id=7129 Basically, for long running SVG animations (e.g. automatic translation from Flash to SVG), it is interesting to load only some SVG parts when they are needed and to discard them (using the SVG Tiny 1.2 <discard> element), when they are no longer needed. For that, we use an auxiliary file that indicates how to fragment the SVG file into a stream, giving timestamps to each SVG file fragment. That auxiliary file is then used to store the SVG fragments as regular access units in MP4 files, we use MP4Box for that. The manipulation of those fragments for storage and playback is then similar to what you would do for audio/video streams. We don't do transcoding for SVG fragments but for instance individual gzip encoding is possible. I think an interesting use case for XHR would be to be able to request data with some synchronization, i.e. with a clock reference and timestamp for each response data. Cyril -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.institut-telecom.fr/
Received on Tuesday, 9 August 2011 08:00:06 UTC