AVELUNE

WebGPU and browser acceleration — Draft Generation 1

Optional WebGPU presentation, experimental codec-compute work, and the boundary between GPU and Rust/WASM responsibilities.

View source
Documentation navigation

Use

  1. CLI guide

Browser

  1. Browser streaming contract
  2. WebGPU and browser acceleration — Draft Generation 1

Architecture

  1. Codec direction (non-normative)

Development

  1. Independent conformance oracle
  2. Testing Avelune
  3. Avelune document authoring profile
  4. Versioning and compatibility
  5. Avelune web style
  6. Release checklist

Project

  1. IPR / prior-art notes — Draft Generation 1

History

  1. Historical internal Avelune “1.0.0” snapshot (superseded)
On this page
  1. Decision
  2. Support matrix
  3. Hybrid architecture
  4. Compute prototypes
  5. Validation requirements

Decision

WebGPU is a supported optional presentation backend and an experimental codec-compute backend. It is not a conformance dependency. Every Draft Generation 1 stream is decodable and encodable by Rust/WASM without WebGPU.

Primary references:

WebGPU exposes compute shaders, storage resources, and explicit command submission. Those are useful for regular data-parallel image operations; they are a poor fit for moving the codec’s serial parser, entropy state, and reference bookkeeping wholesale onto the GPU.

Support matrix

Backend Decode Encode Status

scalar native Rust

complete

complete

required project baseline

scalar/SIMD128 WASM

complete

complete codec APIs, including streaming browser A/V encoding

required browser codec path

WebGPU presentation

YUV upload/conversion/render

n/a

supported in player, Canvas2D fallback

WebGPU compute

inverse-WHT/reconstruction prototype

integer motion-SAD prototype

experimental

WebCodecs

foreign-format ingest/export bridge only

foreign-format ingest/export bridge only

integration aid, not ALV1/ALA1 implementation

The browser demo’s ordinary-media importer currently uses an embedded FFmpeg WebAssembly build for foreign container/codec ingest. WebCodecs remains a possible integration path where browser support and format coverage make it useful.

Hybrid architecture

Bitstream parsing, canonical varints, rANS decoding, immutable-reference bookkeeping, mode decisions, and container assembly stay in Rust/WASM. Their control flow is serial or irregular, and moving them to the GPU would add synchronization and staging costs.

Candidate GPU work is coarse and batchable:

  • encoder motion-search SAD/SSE grids;

  • transforms and inverse transforms;

  • distortion metrics for RDO;

  • block reconstruction and future local filtering;

  • scale/composite/color conversion for editing;

  • keeping decoded or source frames GPU-resident through an editor pipeline.

For browser editing, a possible topology is:

WebCodecs / canvas / camera / uploaded frames
                   |
                   v
        WebGPU editor + analysis graph
          |                    |
          | bulk costs/blocks  | GPU-resident preview
          v                    v
       Rust/WASM control -> ALV1/ALA1/container

WebCodecs does not make a custom codec automatically available through VideoDecoder or VideoEncoder; Avelune therefore uses its own WASM decoder.

Compute prototypes

web/webgpu/motion_sad.wgsl evaluates the full integer-pixel candidate grid for one 8x8 source block, one workgroup per motion candidate.

web/webgpu/reconstruct_wht.wgsl receives entropy-decoded/dequantized coefficients and prediction samples and performs the normative integer inverse WHT plus clipped reconstruction, one workgroup per 8x8 block.

web/webgpu/smoke.html compiles and exercises both kernels, checks zero-motion SAD, and checks a known inverse-WHT reconstruction.

The prototypes keep rANS and syntax on the CPU side. A production GPU codec path would need to batch many blocks per submission and avoid CPU readback in the inner loop.

Validation requirements

WebGPU presentation has a Canvas2D fallback and does not affect decoded semantics. Experimental compute kernels are not considered a validated codec backend until they have CPU/GPU differential coverage on real WebGPU implementations and hardware.

Any reconstruction work moved to WebGPU must remain bit-exact with the Draft Generation 1 integer specification. Performance claims should be reported with the tested browser, GPU, driver, workload, and comparison path rather than inferred from shader compilation alone.