Re: [XHR] support for streaming data

Hi Charles,

> I believe that GPAC seeks through large SVG files via offsets and small buffers, from what I understood at SVG F2F.
> 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:
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 Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France

Received on Tuesday, 9 August 2011 08:00:06 UTC