w3c / w3c/webcodecs

Samples restrictive

Open
#406 5 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

samples
Dominant language
HTML
Stars
1.3k
Forks
194
Avg merge
1d 13h
Merged PRs (30d)
3

Description

The video/audio samples provided in samples/ all have issues that make them difficult to use to demonstrate WebCodecs in isolation (which, for me, makes it difficult to use them with a polyfill or, thus, to demonstrate or test said polyfill):

  • MP4 Decoding uses a codec controlled by the Misanthropic Patent Extortion Gang, so it's unlikely to be supported by any fully F/OSS implementations.
  • Webcam in Worker uses the MediaStreamTrackProcessor API, which is a separate API entirely (and also experimental, and somewhere between difficult and impossible to polyfill).
  • Capture to File uses MediaStreamTrackProcessor and the FileSystem API, which is also a separate, experimental API.

Admittedly, this is of particular nuisance only to me, because it means I can't say "supports the WebCodecs samples", but regardless it's a breadth issue.

It'd be nice to see simple transcoding (VP9/FLAC to VP8/Opus, for instance), or even just a trivial decoder or encoder with no surrounding bells and whistles. I have some in-progress samples (using my polyfill) at https://github.com/ennuicastr/libavjs-webcodecs-polyfill/tree/master/samples/ .

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing samples/ directory to identify which APIs and codecs each example depends on, then compare the requested scope with the linked polyfill samples. Done means adding a simple WebCodecs-focused example that avoids the unrelated experimental APIs and restrictive codec dependency described in the issue.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
web-dev
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.