fix(video): embed recording start time in WebM metadata

[Devin Rousso (dcrousso)]

recorded videos discard the wall clock origin for their timeline

store the recording origin in standard creation_time metadata and preserve the delay before the first presented frame

this lets consumers synchronize external timelines without using onFrame, which creates a JPEG for every frame

fixes #42361

[Pavel Feldman (pavelfeldman)]

Check out #42480

[github-actions]

Test results for "tests 1"

9 failed
❌ [firefox-library] › library/video.spec.ts:152 › screencast › should continue recording main page after popup closes @firefox-ubuntu-22.04-node20
❌ [firefox-library] › library/video.spec.ts:294 › screencast › should capture navigation @firefox-ubuntu-22.04-node20
❌ [firefox-library] › library/video.spec.ts:326 › screencast › should capture css transformation @firefox-ubuntu-22.04-node20
❌ [firefox-library] › library/video.spec.ts:390 › screencast › should scale frames down to the requested size @firefox-ubuntu-22.04-node20
❌ [firefox-library] › library/video.spec.ts:664 › screencast › should capture full viewport @firefox-ubuntu-22.04-node20
❌ [firefox-library] › library/video.spec.ts:699 › screencast › should capture full viewport on hidpi @firefox-ubuntu-22.04-node20
❌ [firefox-library] › library/video.spec.ts:736 › screencast › should work with video+trace @firefox-ubuntu-22.04-node20
❌ [webkit-library] › library/video.spec.ts:152 › screencast › should continue recording main page after popup closes @webkit-ubuntu-22.04-node20
❌ [webkit-library] › library/video.spec.ts:294 › screencast › should capture navigation @webkit-ubuntu-22.04-node20

7 flaky

⚠️ [chromium-library] › library/chromium/chromium.spec.ts:179 › serviceWorker(), and fromServiceWorker() work `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/video.spec.ts:699 › screencast › should capture full viewport on hidpi `@chromium-ubuntu-22.04-arm-node20`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@realtime-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node22`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:257 › third party 'Partitioned;' cookies `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-library] › library/browsercontext-cookies-third-party.spec.ts:470 › top level 'Partitioned;' cookie and same origin iframe `@firefox-ubuntu-22.04-node20`
⚠️ [firefox-page] › page/page-event-request.spec.ts:181 › should return response body when Cross-Origin-Opener-Policy is set `@firefox-ubuntu-22.04-node20`

51274 passed, 1241 skipped

---

Merge workflow run.

[github-actions]

🔴 The video.spec.ts screencast failures look caused by this PR

Hi, I'm the Playwright bot and I took a look at the failing CI.

The latest "tests 1" run failed 9 screencast tests in library/video.spec.ts on Firefox and WebKit — and that's exactly the code path this PR rewrites. The change moves frame numbering from a first-frame origin to a wall-clock _recordingStartTimestamp (Date.now()/1000) and adds -copyts, in videoRecorder.ts. In the CI results DB, all seven failing Firefox tests come from this PR's own run (33453357375, sha aa0fb23), and each of them otherwise passes ~967/968 runs. Seven independent ~0.1% tests failing together in one run isn't chance — it's a regression, and it repeats on your latest sha. I'm calling this red.

Details

Overall: the diff is scoped to packages/playwright-core/src/server/videoRecorder.ts (ffmpeg args + frame-timestamp origin), tests/library/screencast.spec.ts, and a docs line — and the failures are the video-recording tests that this exact code drives. So the CI signal points straight back at the change.

Caused by this PR

• [firefox-library] › library/video.spec.ts — should continue recording main page after popup closes (:152), should capture navigation (:294), should capture css transformation (:326), should scale frames down to the requested size (:390), should capture full viewport (:664), should capture full viewport on hidpi (:699), should work with video+trace (:736).

• [webkit-library] › library/video.spec.ts — should continue recording main page after popup closes (:152), should capture navigation (:294).

  These are content-capture assertions on the recorded frames. The DB is decisive: all seven Firefox failures above trace to run 33453357375 / sha aa0fb23 — a run of this PR — and they recur on the current sha in the latest report. Baseline for each is ~1 failure in ~850–968 runs (~0.1%), so seven of them going red in the same run is a systematic break, not coincident flakes. Chromium mostly survives (only flaking on :699 and :736), which fits a timing regression that bites hardest where the browser's frame clock diverges from Date.now().

  Likely mechanism: frameNumber = Math.floor((timestamp - _recordingStartTimestamp) * fps) now anchors to a wall-clock origin captured at construction, but the browser-supplied timestamp isn't on the same clock as Date.now(), so frames land at the wrong positions (and -copyts preserves those offsets). Keeping frame numbering relative to the first frame — and using the recording-start time only for the creation_time metadata — would likely restore these.

Not real failures

• The other "tests 1" entries (Firefox COOP/cookies, page-event-request, chromium serviceWorker, ui-mode-trace) and the Chromium video.spec.ts entries are listed as flaky — they passed on retry, so nothing to triage there.

_{Triaged by the Playwright bot - agent run}

[github-actions]

Test results for "MCP"

3 failed
❌ [chromium] › mcp/screenshot.spec.ts:77 › --output-dir should work @mcp-windows-latest-chromium
❌ [firefox] › mcp/annotate.spec.ts:349 › should annotate when context has no fixed viewport @mcp-windows-latest-firefox
❌ [firefox] › mcp/annotate.spec.ts:386 › should cancel browser_annotate when the MCP request is aborted @mcp-windows-latest-firefox

8302 passed, 1367 skipped

---

Merge workflow run.

[github-actions]

🔴 The video.spec.ts screencast failures are caused by this PR

Hi, I'm the Playwright bot and I took a look at the failing CI.

This is a regression in the video-recording change, not flake. The latest "tests 1" run failed 9 library/video.spec.ts screencast tests on Firefox and WebKit — exactly the code path videoRecorder.ts rewrites. In the CI results DB these tests are effectively never red on their own (~0.1% each over 800–970 runs), yet all 9 go red together in a run of this PR (33453357375, sha aa0fb23) and repeat on your latest sha. Nine independent ~0.1% tests failing in one run isn't chance. The MCP report's failures are separate and unrelated (see below).

Details

Overall: the diff is scoped to packages/playwright-core/src/server/videoRecorder.ts (ffmpeg args + frame-timestamp origin), tests/library/screencast.spec.ts, and one docs line. The failing tests are the video-recording tests this exact code drives, so the CI signal points straight at the change.

Caused by this PR

• [firefox-library] › library/video.spec.ts — should continue recording main page after popup closes (:152), should capture navigation (:294), should capture css transformation (:326), should scale frames down to the requested size (:390), should capture full viewport (:664), should capture full viewport on hidpi (:699), should work with video+trace (:736).

• [webkit-library] › library/video.spec.ts — should continue recording main page after popup closes (:152), should capture navigation (:294).

  The DB is decisive: across the entire recent window, essentially the only failing runs for these tests are this PR's own run (33453357375 / sha aa0fb23, branch fix-42361). Baselines are ~1 failure in 849–969 runs; the sole unrelated hit is one old should work with video+trace failure on PR chore(tracing): reference trace and har blobs via relative file paths #42192 (branch har_file), a true one-off. Chromium mostly survives (it only flakes on :699/:736), which fits a timing regression that bites where the browser's frame clock diverges from Date.now().

  Likely mechanism: frame numbering moved from a first-frame origin (_firstFrameTimestamp, clock-agnostic) to a wall-clock origin captured at construction — _recordingStartTimestamp = Date.now() / 1000. But the browser-supplied timestamp passed to writeFrame isn't on the Date.now() clock, so frameNumber = Math.floor((timestamp - _recordingStartTimestamp) * fps) lands frames at wrong (often huge/negative) positions, and -copyts preserves the bad offsets. Chromium's screencast timestamps happen to sit near epoch-seconds so it mostly copes; Firefox/WebKit don't, so they break. Keeping frame numbering relative to the first frame — and using the recording-start time only for the creation_time metadata — should restore these.

Pre-existing flake / infra (the MCP report)

• [firefox] › mcp/annotate.spec.ts:349 › should annotate when context has no fixed viewport and :386 › should cancel browser_annotate when the MCP request is aborted — pre-existing Firefox/Windows flakes. Each fails ~6 of ~717 runs (~0.8%) and passes the rest, on main and unrelated PRs (feat(chromium): roll to r1242 #42356, Revert "chore(deps-dev): bump fast-uri from 3.1.3 to 3.1.4" #41978, feat(firefox): roll Firefox to M155 #42445, fix(mcp): bump firefox action timeout for flaky dialog cli tests #42088, feat(mcp): add browser_emulate_media tool and --color-scheme option #42244 / Revert "chore(deps-dev): bump fast-uri from 3.1.3 to 3.1.4" #41978, feat(storage): capture OPFS in storage state #42248, feat(chromium): roll to r1242 #42356, fix(cli): parse negative numbers as arguments #42333, fix(aria): annotate aria-hidden elements in AI snapshots #42268). This PR doesn't touch the MCP annotate flow.
• [chromium] › mcp/screenshot.spec.ts:77 › --output-dir should work — uncertain, but not this PR. It has no prior failures in the DB (0 of 726), so I can't call it a proven flake, but the diff doesn't touch MCP or screenshot at all — this reads as a one-off/infra blip on Windows, unrelated to the video change.

Not real failures

• The other "tests 1" entries (Firefox COOP/cookies, page-event-request, chromium serviceWorker, ui-mode-trace, and the Chromium video.spec.ts :699/:736) are listed as flaky — they passed on retry, so nothing to triage there.

_{Triaged by the Playwright bot - agent run}