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 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