feat(trace-viewer): webm-based film strip - #42319
Conversation
A new trace event, {type: 'video', file, width, height,
timestampOrigin}, points at a video bundled in the trace zip. The
viewer decodes it in the browser at load time — an offscreen <video>
seek-stepped at 2 thumbnails per second, capped at 120 — and renders
the same film strip lanes and hover preview that screencast-frame
JPEGs drive, progressively as thumbnails land. timestampOrigin maps
the video's own clock onto the trace timeline, so a sparse recording
(frames only where the screen changed) still lines up with actions.
Recorders that capture the screen as compressed video can now bundle
one webm instead of hundreds of JPEG frames; the screenshot-based
strip is unchanged and the two can coexist in one trace.
|
|
||
| const cache = new Map<string, CacheEntry>(); | ||
|
|
||
| const maxThumbnails = 120; |
There was a problem hiding this comment.
should this depend on the filmstrip width?
Test results for "tests 1"21 flaky51199 passed, 1233 skipped Merge workflow run. |
Test results for "MCP"3 failed 8107 passed, 1341 skipped Merge workflow run. |
|
Hi, I'm the Playwright bot and I took a first look at the CI failures here. 🟢 Green — the failures are pre-existing flakes, this PR is clearThe three failures are all in MCP tests ( DetailsOverall: The Pre-existing flake / infra
Triaged by the Playwright bot - agent run |
0d86401
into
microsoft:main
2 participants
A new trace event,
{type: 'video', file, width, height, timestampOrigin}, points at a video file bundled in the trace zip. The viewer decodes it in the browser at load time — an offscreen<video>seek-stepped at 2 thumbnails per second, capped at 120 — and renders the same film strip lanes and hover preview thatscreencast-frameJPEGs drive, progressively as thumbnails land.timestampOriginmaps the video's own clock onto the trace timeline, so a sparse recording (frames only where the screen changed) still lines up with the actions.