Blast

A Binary Large Structured Transmission Format for the Web

Jan Sutter, Kristian Sons, Philipp Slusallek

Background

What affects transmission time?

FactorApproach
Network BandwidthReduce Size (Compression)
Network LatencyReduce N° of Requests
Decoding TimeParallelize
User ExperienceEarly Results

Compression

* Dozens of approaches in literature * Good compressors use domain-specific knowledge * Mesh compression looks different from mesh animation compression * Often restricted to one specific characteristics (e.g. manifold meshes) * Best solution depends on application, network and device

There is no "one fits all" solution

Real-life settings

* Never trust a paper with Stanford Buddha * It is a single mesh!

Real-life settings

* One request per mesh: 468 requests * Browsers spawn 6-8 requests in parallel

Number of request becomes the bottleneck

Real-life settings

Single Mesh

Common Web Formats

* One request per mesh * JSON * OpenCTM * Multiple requests * JSON with binary buffer URLs * X3D BinaryGeometry [Behr et al. 2012] * SIG [Behr et al. 2012] * POP [Limper et al. 2013]

Structured Formats

* XML * Addressing: id / fragment * Compression: gzip * Slow to parse, hard to stream * Binary XML formats not suitable for Web * glTF * Scene structure: JSON * Buffers: Binary container * Addressing: URL / Offset / Size * Compression: Registry * Streaming?

Single request for all resources?

Single Request

Aggregated

Some resources per request

Motivation

* We require a format that is: * Generic * 3D data is heterogeneous * Structured * 3D data is and structured * Single request per mesh does not scale * Streamable * Need early results * Supports arbitrary compression * Compression is domain-specific

Idea

* JSON as basis * Plus support for Typed Arrays * Plus addressing schema * Sender * Applies encoder compression * Encodes used encoder as URL * Flattens and chunks the result * Receiver * Can request decoder on demand * Is able to reconstruct JS object

Blast

A streamable, encoder agnostic, structured binary container

Inside a Blast Transmission

Header

[{
  path: '/mesh/16',
  offset: 0,
  size: 12345,
  decodingSpecification: 'http://blast-format.com/decoders/open3dgc'
},
{
  path: '/textures/fabric',
  offset: 12345,
  size: 12345,
  decodingSpecification: 'http://blast-format.com/decoders/png'
}]

1. Grab binary blob 2. Decode blob 3. Attach result to JS object based on path 4. Result may also be a structured JS object

Generic / Schemaless

* Designed but not limited to 3D data * Blast is typeless by design, it only knows about binary blobs * Container format for binary transmission of key-value structures (JSON-like) * Only information necessary for reconstruction is transported

Structured

* Each value in a key-value data structure is uniquely identifiable by its path * Blast uses this path to address individual sub-resources inside a transmission * Slash-separated property path similar to XPath

Chunk-Based Streaming

* Each chunk is self-contained * It contains all information necessary to decode the transported data * Can be processed in parallel * Can be cached and reordered on the server * Multiple blobs can be sent together in a single chunk * Each blob can be processed independently * A blob is never split across multiple chunks

Encoder Agnostic

* No encoding defined in Blast * Each value inside the key-value structure can be encoded differently * Each encoding is uniquely identified by a URL * Clients can request a decoding implementation on demand (Code on Demand) * Different implementation can be provided (content-negotiation) * Clients can use the URL to identify and map to existing high performance implementations (RiverTrail, WebCL, ...)

Versatile

Blast allows for three different transmission approaches

* A single request per resource * Multiple or all resources in a single request * Streaming all resources in chunks

Results

Evaluation

* Minimal overhead * Leverage existing codecs * OpenCTM * Open3DGC * Overcome their limitations * Predefined schema * Structureless

Transparent Decoding

* Client only interested in the data not the en/decoding * Blast handles the decoding * Code on Demand * Structured * However: * URL is unique identification * Short circuit possible * Client always in full control

Limitations

* No API for streamed binary XHR * Firefox: ``moz-chunked-arraybuffer`` * [Streams API](http://www.w3.org/TR/streams-api/) to come? * Can be used with WebSocket API

Conclusion

FactorApproachBlast
Network BandwidthReduce Size (Compression)Arbitrary Compression
Network LatencyReduce N° of RequestsStructured
Decoding TimeParallelizeSelf-contained
Chunks / Blobs
User ExperienceEarly ResultsStreamable

Thanks!

Questions?

* Intel Visual Computing Institute * EU Future Internet PPP: * FI-CONTENT, FI-WARE/FI-Core, FITMAN * EU FP7 project: VERVE