# Browser Playback Align Node

> Browser-first web playback alignment skill. Use when reproducing or debugging `tv.cctv.com` playback, worker decrypt, transmux, `moduleDecData`, `vmptag`, or local Node playback, including when the user provides a page URL such as `https://tv.cctv.com/...shtml`. This skill requires opening the real page with Chrome DevTools MCP first, tracing the exact browser playback and decrypt path, saving the flow locally, getting user confirmation on that flow, then reproducing it in Node only with `jsdom` for environment shims and `ffmpeg`/`ffprobe` for validation. Do not use HTML players. Do not invent browser environment fields or request flows without browser evidence.

- Skill: `aresbit/browser-playback-align-node` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add aresbit/browser-playback-align-node`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aresbit/browser-playback-align-node/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: aresbit (https://skillmd.com/u/aresbit)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/aresbit/browser-playback-align-node

---


# Browser Playback Align Node

Use this skill for browser playback reverse engineering when the goal is to reproduce the real browser path locally in Node.

## Mandatory Rules

- Always open the target page with Chrome DevTools MCP first. Do not start from local Node guesses.
- The browser is authoritative. Every environment field, worker message, request, and timing assumption must be sourced from browser evidence.
- Use Node only for the local reproduction. Do not build an HTML page or browser-side mock player.
- Use `jsdom` for DOM-like environment shims in Node when the browser path requires them.
- Use the bundled `ffmpeg` and `ffprobe` under `assets/ffmpeg/bin/` to validate decrypted or remuxed output.
- Any JavaScript downloaded locally for later analysis must be formatted into a readable version before further analysis. Save both the original file and the formatted file.
- Save the discovered playback flow locally before implementing the Node reproduction.
- Present that saved flow to the user and get confirmation that the flow is correct before doing the full Node recreation.
- Keep the local replay order identical to the browser order. Treat browser `postMessage` order as data.
- Do not invent missing fields. If a property, request, callback order, or worker API has not been observed in the browser, do not add it.
- If the user provides a page URL, treat that URL as the only required starting input and derive the local environment from that exact page.

## Required Workflow

1. Accept the exact playback page URL, for example `https://tv.cctv.com/2026/02/09/VIDELzvof8kxHmOVyT8f1CMa260209.shtml`.
2. Open that exact page with Chrome DevTools MCP.
3. Trace the browser playback path completely before writing Node code.
4. Dump the real page and worker environment from the browser.
5. Save the discovered flow locally in an artifact file.
6. Save the discovered browser-derived environment locally in an artifact file.
7. Show the flow and environment summary to the user and ask whether this is the correct flow.
8. Only after user confirmation, reproduce the flow in Node with browser-matched inputs and browser-matched environment.
9. Validate the output with bundled `ffmpeg` and `ffprobe`.

## URL-Driven Entry Rule

When the user provides a page URL, the skill must be able to start from that URL alone and do all of the following:

- open the real page in Chrome DevTools MCP
- discover the real worker chain from that page
- discover the real playback requests from that page
- discover the real runtime environment fields read by the page, worker, and wasm
- save those findings locally
- build the local Node environment from those findings so it matches the current browser-derived environment

Do not require the user to manually provide worker URLs, playlist URLs, media tags, or environment fields if they can be discovered from the page.

## Environment Reconstruction Rule

The Node environment must be reconstructed from browser evidence so that it matches the currently observed browser environment for the target page. This includes, when observed:

- `pageHref`
- `workerHref`
- `location.href`
- `location.origin`
- `location.host`
- `location.protocol`
- `location.pathname`
- `navigator.userAgent`
- `window` / `self` alias behavior
- `document` presence or absence
- `Date.now()`
- `new Date()`
- `performance.now()`
- `indexedDB`
- `XMLHttpRequest`
- `fetch`
- `importScripts`

If the current local environment module already reproduces part of this correctly, keep it only if it still matches the browser evidence for the new URL. Re-check rather than assuming.

## Environment Output Requirement

For each traced page URL, save a local environment summary that explains exactly what the Node shim is reproducing. At minimum save:

- the page URL
- the worker URL
- which globals exist
- which globals are absent
- which network APIs are used
- which storage APIs are used
- which values were fixed from browser capture
- which values are still unknown and therefore must not be guessed

## Browser-First Discovery Checklist

Read [references/browser-playback-flow.md](references/browser-playback-flow.md) before tracing.

Capture at least these items from the browser:

- Page URL and final worker/blob URL
- Browser environment dump for the page and for the worker
- Loaded script chain
- Worker creation path and worker roles
- `fetch` / `XMLHttpRequest` / `importScripts` / `indexedDB` usage
- `H5player.json` and any other runtime config fetches
- Wasm/module initialization sequence
- `MediaSource` creation, `SourceBuffer` codecs, and append order
- HLS playlist selection and actual segment URLs
- Main-thread to worker message order
- Worker to main-thread message order
- Whether the bytes sent to `probeTs` / `push` match the fetched TS bytes
- Where `moduleActive`, `moduleDecData`, decrypt, transmux, and mux/remux actually occur

## What Must Be Confirmed Before Node Reproduction

The saved local flow must answer these questions:

- How is playback bootstrapped?
- Which scripts and workers are loaded, in what order?
- Which network requests are required, in what order?
- Where does decrypt happen, if any?
- Where does transmux happen?
- Where does mux/remux happen?
- What exact messages are exchanged between main thread and worker?
- Which environment fields are read by wasm or worker code?
- Which parts must be mirrored in Node and which parts can remain browser-only observations?

If any of these are still inferred instead of observed, keep investigating in the browser.

## Node Reproduction Rules

- Node is the only local runtime target.
- Use `jsdom` only to reproduce browser fields that were actually observed.
- Match `pageHref`, `workerHref`, `location`, `navigator`, `Date.now()`, `performance.now()`, and related runtime values only when they were observed to matter.
- When the user starts from a page URL, the Node environment must end up matching the browser-derived environment for that exact page URL, not a generic template.
- Reuse the browser's exact worker source when possible instead of reimplementing equivalent logic.
- If a worker path requires host-worker code plus appended hooks, keep the host-worker source unchanged and append hooks separately.
- Keep browser and Node inputs identical: same `mediaTagID`, same segment URLs or exact saved segment bytes, same message order, same alignment payloads.

## Validation Rules

- Use `assets/ffmpeg/bin/ffprobe.exe` to inspect the produced media.
- Use `assets/ffmpeg/bin/ffmpeg.exe` to remux, decode-check, or compare output.
- Validation is required even when the output "looks playable".
- Report:
  - container and stream info
  - decode errors
  - packet corruption warnings
  - zero-length decrypt outputs
  - any byte-length deltas between decrypt input and output

## Local Saving Rules

Save artifacts locally for each run, including:

- browser-traced flow summary
- captured worker message order
- request list
- segment list
- downloaded JavaScript sources in both original and formatted forms when JS is saved locally
- `moduleActive` / `moduleDecData` traces when available
- Node reproduction summary
- `ffprobe` or `ffmpeg` validation output summaries

## Preferred Artifact Pattern

- Save browser flow under the current workspace, usually `artifacts/cctv_player_capture/...`
- Keep one machine-readable summary file and one short human-readable flow file
- If `moduleDecData` is hooked, save both JSON and CSV summaries

## Tooling

- Browser tracing: Chrome DevTools MCP only
- Node env shim: `jsdom`
- Media validation: `assets/ffmpeg/bin/ffmpeg.exe` and `assets/ffmpeg/bin/ffprobe.exe`