How I set a SourceAdapter an MoviElement ?

[coco875]

I wonder if it's possible to set a SourceAdapter (for example to get the video from another protocol then http) on a MoviElement to avoid redo the ui and everything, but it look like we go from MoviElement to MoviPlayer and MoviPlayer to Demuxer to set it. I have also try the example to set the src with .src and don't look like to work https://mrujjwalg.github.io/movi-player/api/element.html#src

[MrUjjwalG]

Hey @coco875 — good catch, this wasn't supported. Just added a sourceAdapter property on <movi-player> so you can plug any custom protocol straight into the element without touching MoviPlayer/Demuxer or reimplementing the UI.

import type { SourceAdapter } from 'movi-player';

class WebSocketSource implements SourceAdapter {
  private pos = 0;
  constructor(private url: string, private totalSize: number) {}

  async getSize() { return this.totalSize; }

  async read(offset: number, length: number): Promise<ArrayBuffer> {
    // your protocol here — return the requested byte range
  }

  seek(offset: number) { this.pos = offset; return offset; }
  getPosition() { return this.pos; }
  close() { /* cleanup */ }
  getKey() { return this.url; }
}

const el = document.querySelector('movi-player');
el.sourceAdapter = new WebSocketSource('wss://…', 12345678);

The setter mirrors src behaviour — disposes the old player, fires loadstart, re-initializes with your adapter. Setting src after will clear the adapter, and vice versa, so they stay mutually exclusive.

Re your second point — .src should work with strings/Files. If a specific URL didn't load for you, can you share what you tried? (e.g. blob:, data:, m3u8 with DRM)? There might be a separate bug there.

Will be in the next release.

[coco875]

(and we can already find some lib to only get subtitle for example without downloading everything from the file)

[MrUjjwalG]

Glad it's sorted! 🎉

Two clarifications on the MKV side:

Seeking — movi-player doesn't range-request the whole segment to seek. It reads the MKV SeekHead / Cues index, then issues a targeted Range request to the exact byte offset of the cluster you're seeking to (plus a small read-ahead window). So it's already "fast seek without ranging the whole file."

Subtitle-only without downloading everything — this is the part that isn't possible on a muxed file, and it's a container limitation rather than a demuxer one:

• In a muxed MKV, subtitle packets are interleaved with video/audio inside each cluster. To reach a subtitle packet, you have to read the byte region it lives in, which includes the surrounding video/audio bytes. There's no index that exposes "just the subtitle bytes" as a contiguous range.
• movi-player does avoid the decode cost — prefetchSubtitleCues walks the subtitle stream with AVDISCARD_ALL, so a full subtitle scan over a 700MB file decodes only subtitle packets, never the video/audio bodies. But the bytes still have to be read to traverse the container.
• The "lib that gets only subtitles" works in one of two ways: it either downloads the whole file then extracts, or it reads an already-separated subtitle track. Neither magically fetches only subtitle bytes from a remote muxed MKV.

If you want true per-track download (only pull the subtitle track over the wire), the track has to be physically separate — either:

• a sidecar .srt / .vtt / .ass at its own URL (movi-player supports this via external subtitle tracks / <source kind="subtitle">), or
• a DASH/HLS layout where each track is its own segment stream.

For muxed AV1+Opus+ASS in one MKV, full playback will always touch the interleaved clusters — same as any player, native <video> included.

Happy this unblocked you — feel free to open a new discussion if anything else comes up!

[coco875]

What I see with the network on chrome isn't necessary a http range of the full file directly but the sum of data fetch are equivalent or close to the total size of the file. I am trying thing on my side but from what I experiment with ebml format is that each ebml element have an id and a size, so technically we can jump around the file to only get what we want, without fetching the whole file, what I suspect is it see that Segment have a big size and fetch all to read it

[coco875]

Do you want that we continue our debate about mkv in another discussion to avoid flood this one ?

[MrUjjwalG]

Your EBML intuition is correct — each element carries its ID + size, and FFmpeg's matroska demuxer does use the SeekHead / Cues index to jump straight to clusters rather than reading the Segment linearly. So that part isn't the cause.

What you're seeing on the Chrome network panel — total fetched ≈ file size — is actually a deliberate caching choice in movi-player, not blind Segment reading:

• Files ≤ 250 MB: HttpSource proactively streams and caches the entire file in memory (YouTube-style — instant seek/replay, zero re-fetch). HttpSource.ts
• Files > 250 MB: it switches to an ~8% sliding window (≈60–90s of content) and only fetches around the playhead.

So for a smaller test file, fetching ≈100% is expected and intentional. It's tunable — lower the cap to force a sliding window even on small files:

<movi-player src="…" buffersize="32"></movi-player>

new MoviPlayer({ source, canvas, cache: { type: "lru", maxSizeMB: 32 } });

With that, it'll only pull clusters around the playhead via targeted Range requests, exactly like your EBML jump-around idea.

And yes — let's move the MKV deep-dive to its own discussion to keep this one focused on the original sourceAdapter question. Open one and tag me, happy to continue there. 👍