Block Media Format (BMF) — Composable On-Chain Audio/Video

Abstract

Block Media Format (BMF) is an open format for composable, on-chain-native audio/video. Instead of one monolithic encoded file, a "video" is expressed as a small timing manifest that references independently-owned media components — each of which can be minted once on-chain, provenanced, and reused many times. BMF defines two file types: .bmf (the manifest / "recipe") and .bmc (a portable ZIP container bundling a .bmf with its media). BMF introduces no new codec — it carries standard WebP, FLAC and MP3 inside — and requires no IANA registration to use. It is the media-composition layer that sits above component-level token/provenance standards.

The Abstract section should concisely describe your proposal at a high-level.

Motivation

Conventional video is a single opaque file: content is duplicated wherever it recurs, and the individual parts (a loop, a stem, the master audio) carry no independent ownership. On a chain that can carry media payloads, each component can instead be its own on-chain asset with its own author and royalty.

BMF exists to make that structure expressible and playable:

1. Store once, reference many. A clip used at five moments is one stored component plus five cue lines — not five copies.
2. Component-level provenance. Every clip and the song is an owned on-chain asset; a composition is a composition of owned parts, each independently attributable and monetizable. This complements token/provenance standards (e.g. BRC-113, MPT¹).
3. Fully on-chain composable video. When a manifest references components by txid, the "video" is nothing but a tiny manifest; a player fetches each component from chain and sequences it — no fat file anywhere.
4. Standard media, universal decode. No bespoke codec; anything that plays WebP/FLAC/MP3 can implement a player.
5. Tempo-native authoring. Cues are absolute seconds, so scenes can be placed on the beat.

The Motivation section should let people know the context for your proposal, and why it was written.

Specification

1. Two file types.

   • .bmf — Block Media Format: the manifest — a timeline that references media components (by on-chain txid/outpoint or by local filename) with start-time cues.
   • .bmc — Block Media Container: a ZIP holding exactly one .bmf plus the media files it references by local name — the portable, self-contained form. A .bmc contains a .bmf + media; a standalone .bmf references on-chain content. One spec, two delivery forms.

2. Manifest encodings. A .bmf MAY be written in either encoding, and a conformant player SHOULD accept both:

   A. Cue form (LRC-compatible). References components by local filename. Lines are [mm:ss.cc]<name>, with optional # key: value headers:

   # bmf: 0
   # audio: supersonic.mp3
   # tempo: 110
   [00:00.00]forgotten-control-room.webp
   [00:04.36]power-low.webp
   [00:08.72]power-high.webp
   

   B. JSON form. Carries on-chain txid references (the pure on-chain form):

   {
     "bmf": 0,
     "audio": { "tx": "6059dfef894d83be6df1ca858e7d644dfbc1256b7611f98abb1a1111765ba0e5", "name": "supersonic.mp3" },
     "tempo": 110,
     "scenes": [
       { "t": 0.00, "tx": "dff809f6ab5052ed96f7a75e2f9751e88cedcf9aca2e8211b9c46b1ec76de128", "name": "forgotten-control-room" },
       { "t": 4.36, "tx": "2722b170aace00cc992bf671dc458f30588e96ad4a5992308c46dc01f574e5bc", "name": "power-low" },
       { "t": 8.72, "tx": "2722b170aace00cc992bf671dc458f30588e96ad4a5992308c46dc01f574e5bc", "name": "power-high" }
     ]
   }
   

3. Fields.

   • bmf — format version integer (currently 0).
   • audio — the master audio track, by tx (on-chain) and/or name (local).
   • tempo — OPTIONAL BPM metadata to aid beat-aligned authoring.
   • scenes[] — ordered scene cues: t = scene start in seconds; tx = on-chain reference (txid/outpoint of the minted component); name = filename/label (used inside a .bmc, or as a human label).

4. Playback semantics. A scene plays until the next scene's t. Looping media (e.g. animated WebP) restarts from frame 0 on its cue, so loops stay phase-locked to the beat.

5. Resolution algorithm. To resolve a .bmf a player MUST:

   1. Load the manifest (cue or JSON).
   2. Resolve audio and each scene reference: if tx is present, fetch that component from chain (raw tx → extract media payload); else read name from the accompanying .bmc / folder.
   3. Play the audio; at each cue time, switch to that scene and restart its loop; hold until the next cue.

6. Media constraints. Components MUST use standard, universally-decodable media — WebP (including animated and variable-frame-rate, where a long hold costs a single frame), FLAC, or MP3. BMF defines no new codec.

7. MIME types (informal). .bmf → application/x.bmf (or application/vnd.blockmedia+json when JSON); .bmc → application/x.bmc (or application/vnd.blockmedia+zip). The x. experimental tree is used today; a vnd. registration MAY follow if native OS/browser recognition is ever required.

The Specification section of your proposal should stipulate all information needed to implement the standard, and make up the bulk of the document. Generally, people should be able to create a compatible implementation with only the specification.

Implementations

1. Authoring tool — a local-first studio ("Pole Position") whose music-video timeline exports a .bmc (media files + a .bmf cue manifest).
2. Player — a smart-NFT player reads the manifest, resolves each component (by txid from chain, or by name from the container), and sequences the scenes to the audio, restarting loops on cue.
3. Reference repository (MIT): https://github.com/sun-dive/block-media-format — full v0 spec, examples, and the .bmf / .bmc definitions.
4. First real-world components (BSV mainnet). The "Supersonic" release ships its building blocks as individually-minted, provenanced, reusable on-chain assets — each resolvable today and composable in a .bmf by {tx, name} reference²:
   • Forgotten Control Room — an SOS-flicker loop BMF atom: dff809f6ab5052ed96f7a75e2f9751e88cedcf9aca2e8211b9c46b1ec76de128.
   • Suited Up — three tube-power loops published as ONE .bmc set, each member addressable by {tx, name}: 2722b170aace00cc992bf671dc458f30588e96ad4a5992308c46dc01f574e5bc (members power-low, power-medium, power-high).
   • Supersonic master audio: 6059dfef894d83be6df1ca858e7d644dfbc1256b7611f98abb1a1111765ba0e5.

The Implementations section should contain information about places where the standard is implemented, or examples of its implementation.

References

• <a name="footnote-1">1</a>: Merkle Proof Token (MPT) protocol — BRC-113, https://github.com/bitcoin-sv/BRCs
• <a name="footnote-2">2</a>: Block Media Format reference implementation and examples, https://github.com/sun-dive/block-media-format

The References section should contain any footnotes used throughout the document.