@videojs/react 10.0.0-rc.2 → 10.0.0-rc.3

package/docs/guides/media-sources.md

@@ -0,0 +1,312 @@
+# Media sources
+
+Set what a media element plays and how its engine plays it with the structured source property
+
+Every media element takes a `src`. Elements that drive a playback engine also take `source`, a structured object that carries the URL alongside everything else about that source:
+
+```tsx
+<HlsJsVideo
+  source={{
+    src: 'https://example.com/stream.m3u8',
+    preferPlayback: 'mse',
+    engine: { hlsJs: { maxBufferLength: 60 } },
+  }}
+/>
+```
+
+## Three tiers, three homes
+
+The shape answers one question: does this option describe the source, or how to play it?
+
+| Tier | Home | Example |
+| --- | --- | --- |
+| Which source to play | `source.src`, or an element’s own identity fields | `src`, `MuxVideo`’s `playbackId` |
+| How to interpret it | `source.type` | `'video/mp4'` |
+| How Video.js plays it | `source`, at the top level | `preferPlayback`, `maxAutoResolution`, `capRenditionToPlayerSize` |
+| How a specific engine behaves | `source.engine`, under that engine’s name | hls.js’s `maxBufferLength`, in `source.engine.hlsJs` |
+| An extension’s own settings | that extension’s props | [Mux Data](./mux-data.md), [GoogleCast](../reference/components/google-cast.md) |
+
+`type` is worth reaching for when the URL lies about its contents. Video.js infers the content type from the file extension, so a manifest served from an extensionless or signed URL may need to say so explicitly:
+
+```tsx
+<HlsJsVideo source={{ src: 'https://example.com/asset?id=42', type: 'application/vnd.apple.mpegurl' }} />
+```
+
+The legacy HLS spelling `application/x-mpegURL` is accepted as an alias, and matching is case-insensitive. An HLS source whose `type` isn’t recognized is handed to the browser as-is rather than to hls.js, which leaves quality and audio-track selection unavailable.
+
+## `src` and `source` stay in sync
+
+They are two views of the same thing, and writing either updates the other. Setting `source` derives `src`. Setting `src` replaces only the identity half and **keeps the rest, such as `type` and the engine options, intact**:
+
+```tsx
+<HlsJsVideo source={{ src: 'https://example.com/a.m3u8', preferPlayback: 'native' }} />
+```
+
+A `sourcechange` event fires whenever `source` changes, from either direction.
+
+## Assigning `source` replaces it
+
+`source` is not merged. A new object is a fresh start, and keys you leave out are dropped:
+
+```tsx
+<HlsJsVideo source={{ src, type: 'video/mp4', preferPlayback: 'native' }} />
+
+// later: type and preferPlayback are gone, because the new object omits them
+<HlsJsVideo source={{ src }} />
+```
+
+## Equivalent sources cost nothing
+
+Sources are compared **structurally**, not by reference. Reassigning an object with the same values is a no-op — no reload, and no engine teardown:
+
+```tsx
+// A fresh object literal on every render. Nothing reloads.
+<HlsJsVideo source={{ src, engine: { hlsJs: { maxBufferLength: 60 } } }} />
+```
+
+This is why you can write `source` inline. React hands the element a brand new object every render, and the element recognizes it as the same source. There’s no need to memoize it or spread the previous value to avoid clobbering anything.
+
+Only a change to the engine options, `preferPlayback`, or the resolved content type recreates the playback engine.
+
+## Engine options
+
+Engine options live under `source.engine`, **namespaced by engine**. Each key there holds that engine’s own configuration object, handed over untouched — there’s no Video.js wrapper around it, so whatever the engine documents works:
+
+| Key | Elements that read it | It holds |
+| --- | --- | --- |
+| `engine.hlsJs` | [HlsJsVideo](../reference/components/hlsjs-video.md), [MuxVideo](../reference/components/mux-video.md), [MuxAudio](../reference/components/mux-audio.md) | an [hls.js config](https://github.com/video-dev/hls.js/blob/master/docs/API.md#fine-tuning) |
+| `engine.nativeHls` | [NativeHlsVideo](../reference/components/native-hls-video.md), and the three above whenever the browser plays the manifest | options for the browser’s own HLS support (today, [DRM](#licensing-one-engine-differently)) |
+| `engine.dashJs` | [DashVideo](../reference/components/dash-video.md) | [dash.js settings](https://cdn.dashjs.org/latest/jsdoc/module-Settings.html) |
+| `engine.vimeo` | [VimeoVideo](../reference/components/vimeo-video.md) | [Vimeo embed parameters](https://developer.vimeo.com/player/sdk/embed) |
+| `engine.youtube` | [YouTubeVideo](../reference/components/youtube-video.md) | [YouTube player parameters](https://developer.chrome.com/docs/youtube/iframe_api_reference#Parameters) |
+| `engine.cloudflare` | [CloudflareVideo](../reference/components/cloudflare-video.md) | [Stream player parameters](https://developers.cloudflare.com/stream/viewing-videos/using-the-stream-player/) |
+| `engine.spotify` | [SpotifyAudio](../reference/components/spotify-audio.md) | [Spotify embed options](https://developer.spotify.com/documentation/embeds) |
+| `engine.tiktok` | [TikTokVideo](../reference/components/tiktok-video.md) | [TikTok player parameters](https://developers.tiktok.com/doc/embed-player) |
+| `engine.twitch` | [TwitchVideo](../reference/components/twitch-video.md) | [Twitch embed parameters](https://dev.twitch.tv/docs/embed/video-and-clips/) |
+
+Naming the engine rather than using one generic key matters where an element has more than one to choose from. `HlsJsVideo` plays through hls.js or through the browser depending on the platform and `preferPlayback`, and only one of them runs — so a single source can describe both paths without either engine reading the other’s options.
+
+hls.js reads its options when the engine is constructed, so changing them tears down the engine and builds a new one:
+
+```tsx
+<HlsJsVideo
+  source={{
+    src: 'https://example.com/stream.m3u8',
+    engine: { hlsJs: { maxBufferLength: 60, enableWorker: false } },
+  }}
+/>
+```
+
+dash.js takes settings on a running player, so `engine.dashJs` is applied in place and playback continues uninterrupted:
+
+```tsx
+<DashVideo
+  source={{
+    src: 'https://example.com/manifest.mpd',
+    engine: { dashJs: { streaming: { abr: { maxBitrate: { video: 2000 } } } } },
+  }}
+/>
+```
+
+Because `engine.dashJs` replaces rather than merges, dropping a key restores the dash.js default instead of leaving the old value behind.
+
+### Options Video.js normalizes
+
+Where an option means the same thing across engines, it sits on `source` itself rather than inside an engine’s namespace.
+
+`preferPlayback` picks between [hls.js](https://github.com/video-dev/hls.js/) and the browser’s own HLS support:
+
+```tsx
+<HlsJsVideo source={{ src: 'https://example.com/stream.m3u8', preferPlayback: 'native' }} />
+```
+
+It’s a preference, not a demand — Video.js falls back to whichever path can actually play the source. `HlsJsVideo`, `MuxVideo`, and `MuxAudio` accept it; DASH and Vimeo have no second playback path.
+
+`maxAutoResolution` caps the highest rendition adaptive bitrate selection reaches for on its own:
+
+```tsx
+<HlsJsVideo source={{ src: 'https://example.com/stream.m3u8', maxAutoResolution: '720p' }} />
+```
+
+The cap limits automatic selection without hiding anything. Renditions above it stay in `videoRenditions`, so a viewer can still choose 1080p by hand. Reach for it to hold down bandwidth on a stream that would otherwise climb to 4K, or to keep a background or thumbnail player cheap.
+
+Renditions are matched on pixel area rather than height, which keeps unusual aspect ratios honest: an ultrawide 2560×1080 rendition carries more pixels than 16:9 1080p, so a `'1080p'` cap leaves it out. When every rendition sits above the cap, the smallest one plays.
+
+Changing the cap applies to the running engine, so playback continues uninterrupted. It needs the hls.js engine — native HLS playback ignores it, and audio-only streams have no video renditions to cap.
+
+### Capping to the player’s size
+
+A 400px-wide player has no use for a 4K rendition, so `capRenditionToPlayerSize` holds automatic selection to the smallest rendition that still covers the element. It defaults to `true`, and the cap follows the element as it’s resized:
+
+```tsx
+<HlsJsVideo source={{ src: 'https://example.com/stream.m3u8', capRenditionToPlayerSize: false }} />
+```
+
+The element is measured in device pixels, so a `2` device pixel ratio asks for twice the rendition a CSS measurement would — a 640px-wide player on a retina screen still gets 720p. Switch the cap off for a player whose layout size understates what it needs, such as one that goes fullscreen without a resize.
+
+`minAutoResolution` bounds how far down that cap can reach, and defaults to `'720p'`:
+
+```tsx
+<HlsJsVideo source={{ src: 'https://example.com/stream.m3u8', minAutoResolution: '480p' }} />
+```
+
+**It is not a quality floor.** It bounds the size-derived cap and nothing else. When bandwidth is poor, adaptive selection still drops below it — the cap is a ceiling, and selection stays free underneath. It also never raises an explicit `maxAutoResolution`: ask for at most `'360p'` alongside a `'720p'` floor and you get `'360p'`.
+
+The default is there because the low rungs of a ladder exist for poor network conditions, and capping a small player down to them looks worse than its size suggests. Name a lower rung to weaken the floor, or `'270p'` to lift it for any real ladder.
+
+### Four things that sound alike
+
+Four separate mechanisms bound which rendition plays, and they’re easy to mistake for each other:
+
+| Option | Side | What it does |
+| --- | --- | --- |
+| `source.playback.maxResolution` | Server | A Mux query param. Trims the manifest, so higher renditions never arrive — not even by hand. |
+| `source.maxAutoResolution` | Client | A ceiling on automatic selection. Everything still arrives and stays selectable by hand. |
+| `source.capRenditionToPlayerSize` | Client | The same kind of ceiling, derived from the element’s rendered size and moving with it. |
+| `source.minAutoResolution` | Client | A bound on the one above. Not a quality minimum, and not related to `playback.minResolution`. |
+
+`playback.maxResolution` and `playback.minResolution` are the server-side pair: they decide what the manifest carries. The other three only bound what adaptive selection picks from whatever does arrive.
+
+## DRM protected sources
+
+Protected content is licensed through `source.drm`, keyed by EME key system id — alongside the URL rather than inside an engine’s namespace, because which engine plays the manifest is decided later and both paths read it:
+
+```tsx
+<HlsJsVideo
+  source={{
+    src: 'https://example.com/protected.m3u8',
+    drm: {
+      'com.apple.fps': {
+        licenseUrl: 'https://license.example.com/fairplay',
+        serverCertificateUrl: 'https://license.example.com/fairplay-cert',
+      },
+      'com.widevine.alpha': { licenseUrl: 'https://license.example.com/widevine' },
+      'com.microsoft.playready': { licenseUrl: 'https://license.example.com/playready' },
+    },
+  }}
+/>
+```
+
+Name every system you hold a license server for — which one gets used is the browser’s choice. `serverCertificateUrl` is the DRM server (application) certificate FairPlay requires; Widevine and PlayReady ignore it.
+
+### What each path can license
+
+The same `drm` reaches both playback paths, and how far it gets is the one thing worth knowing about each:
+
+| Path | Key systems it negotiates | What Video.js does with `drm` |
+| --- | --- | --- |
+| hls.js (MSE) | FairPlay, Widevine, PlayReady | Hands it to hls.js as `drmSystems`, with `emeEnabled` switched on |
+| The browser’s own HLS | FairPlay | Answers the element’s key requests itself: POSTs the CDM’s license request to `licenseUrl` and hands the response back |
+
+So a source naming only Widevine plays through hls.js and cannot play on the native path — [NativeHlsVideo](../reference/components/native-hls-video.md), or any HLS element the browser ends up playing the manifest for. Video.js says so in development, and encrypted media that gets there with no `com.apple.fps` license server fails with a `MEDIA_ERR_ENCRYPTED` error rather than hanging.
+
+For Widevine on hls.js, Video.js asks for a hardware-backed CDM first, falling back to whatever robustness the browser offers, so content restricted to L1 devices plays where it can. Supplying your own `requestMediaKeySystemAccessFunc` replaces that entirely.
+
+### Licensing one engine differently
+
+An engine’s own `drmSystems` **replaces** `source.drm`, for that engine alone. Reach for it when one path licenses differently, or when you need more of [hls.js’s DRM configuration](https://github.com/video-dev/hls.js/blob/master/docs/API.md#drmsystems) than `drm` covers:
+
+```tsx
+<HlsJsVideo
+  source={{
+    src: 'https://example.com/protected.m3u8',
+    drm: { 'com.apple.fps': { licenseUrl, serverCertificateUrl } },
+    engine: {
+      // hls.js licenses from here instead, and the native path still from `drm`.
+      hlsJs: { drmSystems: { 'com.widevine.alpha': { licenseUrl: widevineLicenseUrl } } },
+    },
+  }}
+/>
+```
+
+It replaces rather than merges, so the FairPlay server above is gone as far as hls.js is concerned. `engine.nativeHls.drmSystems` does the same for the native path.
+
+## Mux sources name a playback ID
+
+[MuxVideo](../reference/components/mux-video.md) and [MuxAudio](../reference/components/mux-audio.md) identify a source by `playbackId` rather than a URL, and derive `src` from it. Everything else works the same, engine options included:
+
+```tsx
+<MuxVideo
+  source={{
+    playbackId: 'BV3YZtogl89mg9VcNBhhnHm02Y34zI1nlMuMQfAbl3dM',
+    playback: { maxResolution: '1080p' },
+    engine: { hlsJs: { maxBufferLength: 60 } },
+  }}
+  playsInline
+/>
+```
+
+`playback` params ride along in the URL, so `playback.maxResolution` decides which renditions the manifest carries in the first place. `maxAutoResolution` is the other half of that pair: it caps what adaptive selection picks from the renditions that do arrive. Use `playback.maxResolution` when a viewer should never get 4K, and `maxAutoResolution` when they should be able to ask for it.
+
+The same split applies at the bottom of the ladder, and the names are close enough to be worth restating: `playback.minResolution` asks Mux to leave the lowest renditions out of the manifest, while `minAutoResolution` is a client-side bound on the player-size cap. They are unrelated.
+
+Setting a Mux stream URL as `src` works too — the element parses the playback ID and query params back out into `source`. To play something Mux doesn’t host, name it with `src` inside `source`; engine options still apply.
+
+Two more source params describe images rather than playback. `source.storyboard` and `source.poster` carry the modifiers for the storyboard VTT and the poster still — both belong to the source, since a signed token scopes them to one playback ID:
+
+```tsx
+<MuxVideo source={{ playbackId, storyboard: { format: 'jpg' }, poster: { time: 12 } }} playsInline />
+```
+
+`MuxVideo` uses the storyboard itself, adding the thumbnail `<track>` for you so hover previews work without extra markup. Live streams have no storyboard, so the track is dropped once the stream type is known, and signed playback without a matching storyboard token adds none.
+
+### Mux signs DRM with a token
+
+Mux serves FairPlay, Widevine, and PlayReady from URLs derived from a single license token, so `source.drm` takes that token in place of the license servers it would otherwise name. Mux fills the rest in for you, so protected media plays whichever path the browser takes:
+
+```tsx
+<MuxVideo
+  source={{
+    playbackId,
+    playback: { token: playbackToken },
+    drm: { token: drmToken },
+  }}
+  playsInline
+/>
+```
+
+DRM playback is always signed, so a `playback.token` belongs alongside it — and `poster.token` / `storyboard.token` for the images. Each is scoped to a different audience, so they are four separate tokens rather than one reused four times. Sign them on your server; see [Mux’s DRM guide](https://www.mux.com/docs/guides/protect-videos-with-drm) for how.
+
+A `drm.token` that isn’t scoped to DRM is ignored rather than sent, since the license request would be rejected. License servers named alongside the token win, key by key, for the systems Mux doesn’t license:
+
+```tsx
+<MuxVideo
+  source={{
+    playbackId,
+    playback: { token: playbackToken },
+    // FairPlay and PlayReady from Mux, Widevine from your own server.
+    drm: { token: drmToken, 'com.widevine.alpha': { licenseUrl: widevineLicenseUrl } },
+  }}
+  playsInline
+/>
+```
+
+`source.poster` gets no such treatment — it’s only data, and nothing applies it to the media. Both URLs are readable from `contentData`, keyed by what each one describes:
+
+```ts
+media.contentData;
+// {
+//   poster: 'https://image.mux.com/PLAYBACK_ID/thumbnail.webp?time=12',
+//   storyboard: 'https://image.mux.com/PLAYBACK_ID/storyboard.vtt?format=jpg',
+// }
+```
+
+It’s read-only and derived from `source`, so read it again after `sourcechange`. A key is missing when its URL can’t be built: no playback ID, or signed playback with no matching image token. Changing the URLs means changing the params they’re built from.
+
+One more key arrives later. Mux publishes a small metadata document for each asset, and the media loads it alongside the stream, so `contentData.title` fills in with the asset’s title once it does — `contentdatachange` announces it. The player reads it as the fallback for its own title, so a Mux asset titled in the dashboard names itself without a `title` on the player. Any other entries the document carries ride along under their own keys. An untitled asset adds nothing.
+
+`source.poster` takes the [full set of Mux image modifiers](https://www.mux.com/docs/guides/get-images-from-a-video), so a narrower still for a small viewport is a `width`:
+
+```tsx
+<MuxVideo source={{ playbackId, poster: { width: 320 } }} playsInline />
+```
+
+## Elements without engine options
+
+[HlsVideo](../reference/components/hls-video.md) and [HlsAudio](../reference/components/hls-audio.md) take `src` and the usual media props but expose no `source`. They run on our own playback engine, which does not accept configuration from the element yet.
+
+## See also
+
+- [HlsJsVideo element reference](../reference/components/hlsjs-video.md)
+- [MuxVideo element reference](../reference/components/mux-video.md)
+- [DashVideo element reference](../reference/components/dash-video.md)

package/docs/guides/migrate-from-media-chrome.md

@@ -0,0 +1,291 @@
+# Migrate from Media Chrome
+
+Map Media Chrome's controller, elements, and attributes onto Video.js v10, where most of the work is renaming and reshaping rather than rewriting
+
+Video.js v10’s React components mirror Media Chrome’s elements — `media-play-button` becomes `PlayButton` — so most of the work is **renaming and reshaping**, not rewriting.
+
+> **Note**
+>
+> Scoped to apps that compose their own player from Media Chrome elements. If you use `<mux-player>`, follow the Mux Player migration guide instead.
+
+## Before you begin
+
+Install Video.js and choose a [preset](./presets.md) (see [Installation](./installation.md)). Start with its ready-made skin if those controls fit your player. If you need to keep a custom control bar, build it from the individual Video.js UI components instead.
+
+```bash
+npm install @videojs/react
+```
+
+## Map the controller
+
+Media Chrome wraps a slotted `<video slot="media">` in a single `<media-controller>`. Video.js splits that into two components. The player owns state and draws nothing. The container is the box everything lives in, with the media as a plain child.
+
+```html
+<!-- Media Chrome -->
+<media-controller>
+  <video slot="media" src="video.m3u8"></video>
+  <media-control-bar>
+    <media-play-button></media-play-button>
+  </media-control-bar>
+</media-controller>
+```
+
+Media Chrome’s React package wraps its custom elements. `@videojs/react` ships native components instead. `VideoPlayer` comes from the video [preset](./presets.md), and `Container` is the box the media and controls live in:
+
+```tsx
+'use client';
+
+import { Container, PlayButton } from '@videojs/react';
+import { Video, VideoPlayer } from '@videojs/react/video';
+
+export function MyPlayer() {
+  return (
+    <VideoPlayer>
+      <Container>
+        <Video src="video.mp4" />
+        <PlayButton
+          render={(props, state) => (
+            <button {...props} className="play-button">
+              {state.paused ? <span className="play-icon">Play</span> : <span className="pause-icon">Pause</span>}
+            </button>
+          )}
+        />
+      </Container>
+    </VideoPlayer>
+  );
+}
+```
+
+A preset player carries a fixed set of [features](./features.md). When you need a different set, build your own with [`createPlayer`](../reference/api/create-player.md). Hand it a feature list and you get back a typed `Player` component and `usePlayer` hook, the same pair the preset is made of. Call it once, outside your component, and reuse it.
+
+```tsx
+import { createPlayer } from '@videojs/react';
+import { videoFeatures } from '@videojs/react/video';
+
+const { Player } = createPlayer({ features: videoFeatures });
+```
+
+Read player state with [`usePlayer`](../reference/api/use-player.md), `useMedia`, and [`useStore`](../reference/api/use-store.md). Player hooks must run in a descendant component rendered inside `VideoPlayer` or the `Player` returned by `createPlayer`. A hook in the same component that returns the provider is still outside that provider.
+
+## Map controller attributes
+
+Media Chrome configures behavior through `<media-controller>` attributes. Video.js v10 has no single controller component, so these settle into three places:
+
+- **Player features** — playback behavior that comes from the player’s feature set. A preset picks one for you; `createPlayer` lets you name your own.
+- **`Container` and `Controls`** — layout, focus, and autohide.
+- **Dedicated components** — `Hotkey`, `Gesture`, and friends, rendered inside the player.
+
+| Media Chrome attribute | Video.js v10 | How |
+| --- | --- | --- |
+| `audio` | the audio preset | Choose an audio player and audio skin rather than toggling at runtime. |
+| `autohide` | `Controls` (built in) | Controls auto-hide after inactivity automatically. `autohide="-1"` becomes `visibility="always"` on `Controls.Root`; the delay is currently fixed, see [Known gaps](#known-gaps). |
+| `fullscreenelement` | `Container` | Fullscreen targets the container element. |
+| `gesturesdisabled` | `Gesture disabled`, or omit | Disable per gesture component, or leave the gestures out. |
+| `nohotkeys` | `Hotkey disabled`, or omit | Disable per hotkey component, or leave them out. |
+| `hotkeys="noarrowleft …"` | individual `Hotkey` | Each shortcut is its own component, so remove the ones you don’t want. |
+| `keyboardforwardseekoffset`, `keyboardbackwardseekoffset` | `value` on `Hotkey` | Set the signed seek amount per component. |
+| `defaultsubtitles` | `<track default>` for authored tracks | Add `default` to an authored captions or subtitles track. Tracks discovered from a provider or manifest don’t have one generic player-level default flag. |
+| `defaultstreamtype` | `streamType` feature | Partial: derived from the media, with no pre-load default. |
+| `liveedgeoffset`, `seektoliveoffset` | live media engine | Live-edge behavior lives in the playback engine, not a UI attribute. |
+| `lang` | i18n translator | Localization is configured through the [translator and locale registry](./internationalization.md). |
+
+### Hotkeys
+
+Media Chrome toggles keyboard shortcuts with `nohotkeys` and `hotkeys`. Video.js declares each shortcut as its own component, so you opt in to exactly the keys you want and set seek offsets inline:
+
+```tsx
+import { Hotkey } from '@videojs/react';
+
+<Hotkey keys="Space" action="togglePaused" />
+<Hotkey keys="m" action="toggleMuted" />
+<Hotkey keys="ArrowRight" action="seekStep" value={5} />
+<Hotkey keys="ArrowLeft" action="seekStep" value={-5} />
+```
+
+To drop a shortcut, remove its component or pass `disabled`. There’s no global “all hotkeys off” switch; omit the components you don’t need.
+
+### Gestures
+
+`gesturesdisabled` becomes per-component `Gesture` controls. Tap and double-tap behavior — click to toggle play, double-tap to seek or go fullscreen — is declared explicitly:
+
+```tsx
+import { Gesture } from '@videojs/react';
+
+<Gesture type="tap" action="togglePaused" pointer="mouse" region="center" />
+<Gesture type="doubletap" action="seekStep" value={-10} region="left" />
+<Gesture type="doubletap" action="seekStep" value={10} region="right" />
+```
+
+Remove a component or pass `disabled` to turn a gesture off.
+
+## Map the elements
+
+Most names carry over as PascalCase components without the `media-` prefix. These are the renames that bite:
+
+| Media Chrome | Video.js v10 | Note |
+| --- | --- | --- |
+| `media-controller` | a player plus `Container` | one element becomes two: state and layout |
+| `media-control-bar` | `Controls.Root`, `Controls.Group` | grouping |
+| `media-time-range` | `TimeSlider` | “range” becomes “slider” |
+| `media-volume-range` | `VolumeSlider` | “range” becomes “slider” |
+| `media-time-display`, `media-duration-display` | `Time.Value` | one component, set via `type` |
+| `media-loading-indicator` | `BufferingIndicator` | rename |
+| `media-poster-image` | `Poster` | rename, and the image source moves — see below |
+| `media-seek-backward-button`, `media-seek-forward-button` | `SeekButton` | one component, direction via signed `seconds` |
+| `media-rendition-menu` | `QualityRadioGroup` | inside `Menu` |
+| `media-captions-menu` | `CaptionsRadioGroup` | inside `Menu` |
+| `media-playback-rate-menu` | `PlaybackRateRadioGroup` | inside `Menu` |
+| `media-audio-track-menu` | `AudioTrackRadioGroup` | inside `Menu` |
+
+Unchanged names, in PascalCase: `PlayButton`, `MuteButton`, `FullscreenButton`, `PiPButton`, `AirPlayButton`, `CastButton`, `CaptionsButton`, `PlaybackRateButton`, `Tooltip`, and `Thumbnail`.
+
+> **Caution**
+>
+> Matching names do not mean matching appearance. Media Chrome buttons include default icons and styles. Individual Video.js buttons provide behavior, state, and an accessible name, but no visible content or finished styling. Add text or an SVG, plus your own CSS. Without visible content, a button can work while showing nothing. Sliders also need their child parts and CSS. Use a ready-made skin when you want finished controls.
+
+React buttons do not include visible content either. Use a button’s `render` prop to add it, as shown in [Map the controller](#map-the-controller). Build sliders from parts such as `TimeSlider.Track`, `TimeSlider.Fill`, and `TimeSlider.Thumb`, then add your own CSS.
+
+Compound parts are namespaced under their component, such as `TimeSlider.Track`. See the [UI components](./ui-components.md) concept for the full set.
+
+`Poster` is the one rename that changes shape. Put the poster URL on `VideoPlayer`; `Poster.Root` owns its state and `Poster.Image` accepts image attributes such as `alt`, `srcSet`, and `sizes`:
+
+```tsx
+<VideoPlayer poster="/poster.jpg">
+  <Container>
+    <Poster.Root>
+      <Poster.Image alt="" />
+    </Poster.Root>
+  </Container>
+</VideoPlayer>
+```
+
+## Rewrite your styles
+
+Media Chrome reflects state as `media*` attributes such as `mediapaused`; Video.js uses `data-*`.
+
+```css
+/* Media Chrome */
+media-play-button[mediapaused] .play-icon { display: inline; }
+```
+
+```css
+/* Video.js React: target the className on your rendered button */
+.play-button[data-paused] .play-icon { display: inline; }
+```
+
+Continuous values use CSS custom properties: sliders expose `--media-slider-fill` and `--media-slider-pointer`.
+
+### Map theme variables by meaning
+
+Media Chrome and Video.js both use names beginning with `--media-`, but that shared prefix is a naming convention, not a compatibility layer. Keep a variable only when its documented meaning matches.
+
+| Media Chrome theme variable | Packaged Video.js skin | Migration |
+| --- | --- | --- |
+| `--media-accent-color` or `--media-range-bar-color` | `--media-accent-color` | Closest match for slider fills and accented controls. |
+| `--media-primary-color` | no direct equivalent | Often colors every control icon in Media Chrome; Video.js’s accent variable has narrower semantics. |
+| `--media-secondary-color` | no direct equivalent | Add the skin source and author this palette role in your CSS. |
+| `--media-control-background` | no direct equivalent | Add the skin source and author the CSS. |
+| `--media-control-hover-background` | no direct equivalent | Add the skin source and author the CSS. |
+| `--media-range-track-height` | no direct equivalent | Add the skin source and author the slider CSS. |
+
+The packaged Video.js skins expose `--media-accent-color`, `--media-accent-text-color`, `--media-border-radius`, and `--media-scale-unit` for broad customization. Do not assume another Media Chrome variable will work because its name starts with `--media-`.
+
+## Themes become skins
+
+Media Chrome’s `<template>`-based themes (`media-theme`) become Video.js [skins](./skins.md) and [presets](./presets.md). Start from a preset, then [add its skin source to your project](./customize-skins.md#style-skin-source), rather than authoring a template.
+
+React skins do not use Shadow DOM. Use `render` props when you build individual controls. Add the files for a ready-made skin when you need to change its control set or layout.
+
+## Control the player imperatively
+
+Control everything through the player’s store. Media Chrome had no player object; Video.js gives you one, with an action for every operation — `play`, `togglePaused`, `seek`, `setVolume`, `toggleFullscreen` — so one mental model covers playback and the state the browser doesn’t own, such as fullscreen, captions, and quality.
+
+Select an action with the same [`usePlayer`](../reference/api/use-player.md) hook you read state with:
+
+```tsx
+import { usePlayer } from '@videojs/react/video';
+
+function FullscreenShortcut() {
+  const toggleFullscreen = usePlayer((state) => state.toggleFullscreen);
+  // Call toggleFullscreen() from your own UI.
+  return null;
+}
+```
+
+The Media Chrome habit of scripting the media element directly still works, unchanged. The media is a plain child of the player, and Video.js derives player state from the native media events, so `video.play()` or `video.currentTime = 30` never leaves the controls out of sync. The media element also stays the way to swap `src`, replace the media component, and listen for native events.
+
+Put a `ref` on the media component to reach the rendered `HTMLVideoElement`; there’s no `media` slot to reach through. For the Video.js media object, call `useMedia` from a component inside the player; media that wrap a playback engine expose it there through the `engine` escape hatch.
+
+## Known gaps
+
+These Media Chrome features have no direct equivalent yet. Several can be approximated; see [Workarounds](#workarounds).
+
+- No configurable `autohide` delay and no `autohideovercontrols` ([#1728](https://github.com/videojs/v10/issues/1728)). Disabling autohide (`autohide="-1"`) is covered by `visibility="always"` on the controls component; see [Workarounds](#workarounds).
+- No `defaultduration` placeholder before the media loads ([#1729](https://github.com/videojs/v10/issues/1729))
+- Volume and muted preferences are not persisted across sessions, so Media Chrome’s `novolumepref` and `nomutedpref` opt-outs have nothing to opt out of ([#944](https://github.com/videojs/v10/issues/944)). Video.js can choose an initial subtitle track from the locale, but it does not yet remember the viewer’s later language choice ([#1786](https://github.com/videojs/v10/issues/1786)).
+- No `breakpoints` or container-breakpoint attributes; use CSS container queries instead
+- No `seektoliveoffset` or `noautoseektolive` controls, and live-edge offset and tolerance aren’t configurable ([#1730](https://github.com/videojs/v10/issues/1730))
+- Chapters render and each time-slider segment reflects `data-active`, but there’s no player-level active chapter value, `chapterchange` event, or menu to jump between them ([#1873](https://github.com/videojs/v10/issues/1873))
+- Cue points are not supported ([#1442](https://github.com/videojs/v10/issues/1442))
+
+Chapters themselves do work. Add a default `<track kind="chapters">` and the packaged skins segment the time slider and show the chapter title on hover, via `TimeSlider.Chapters` and `TimeSlider.ChapterTitle`.
+
+## Workarounds
+
+### Disable autohide (`autohide="-1"`)
+
+Set `visibility="always"` on `Controls.Root` and the controls stay visible regardless of activity. Packaged skins don’t expose that prop; to keep a preset skin’s look, [add the skin source to your project](./customize-skins.md#style-skin-source) and set it on the skin’s controls component rather than overriding private selectors.
+
+### Breakpoints
+
+The skin root is an inline-size container named `media-root`, so write responsive styles with container queries instead of `breakpoints` attributes. This is exactly how the built-in skins adapt:
+
+```css
+@container media-root (width > 40rem) {
+  .media-controls { /* wide layout */ }
+}
+```
+
+### Default duration
+
+There’s no player input for a pre-load duration. Use `preload="metadata"`, the default, so the real duration is known almost immediately; only `preload="none"` defers it. If you must defer loading, render your own static placeholder in markup.
+
+### Preference persistence
+
+Media Chrome remembers volume, muted state, and language across sessions. Video.js v10 persists nothing, so restore and save the values yourself.
+
+```tsx
+import { selectVolume, usePlayer } from '@videojs/react';
+import { useEffect, useState } from 'react';
+
+function PersistVolume() {
+  const volume = usePlayer(selectVolume);
+  const [readyToSave, setReadyToSave] = useState(false);
+
+  useEffect(() => {
+    const saved = localStorage.getItem('vjs:volume');
+    if (saved !== null) {
+      const savedVolume = Number(saved);
+      if (Number.isFinite(savedVolume)) volume.setVolume(savedVolume);
+    }
+    setReadyToSave(true);
+  }, []);
+
+  useEffect(() => {
+    if (!readyToSave) return;
+    localStorage.setItem('vjs:volume', String(volume.volume));
+  }, [readyToSave, volume.volume]);
+
+  return null;
+}
+```
+
+### Live edge offsets
+
+`seektoliveoffset` and `noautoseektolive` are governed by the playback engine rather than the UI layer, so there’s no attribute to tune them today. The escape hatch is a custom live control built against the `selectLive` and `selectTime` player state.
+
+## See also
+
+- [Installation](./installation.md)
+- [UI components](./ui-components.md)
+- [Skins](./skins.md) and [Customize skins](./customize-skins.md)