| name | browser-playback-align-node |
| description | 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. |
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
- Accept the exact playback page URL, for example
https://tv.cctv.com/2026/02/09/VIDELzvof8kxHmOVyT8f1CMa260209.shtml.
- Open that exact page with Chrome DevTools MCP.
- Trace the browser playback path completely before writing Node code.
- Dump the real page and worker environment from the browser.
- Save the discovered flow locally in an artifact file.
- Save the discovered browser-derived environment locally in an artifact file.
- Show the flow and environment summary to the user and ask whether this is the correct flow.
- Only after user confirmation, reproduce the flow in Node with browser-matched inputs and browser-matched environment.
- 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