microlinkhq / browserless / 28116432932

84%

push

github

feat(capture): record from navigation start at a constant frame rate (#803)

* feat(capture): record from navigation start at a constant frame rate

The animated capture produced ~4fps of an already-loaded page. Two causes:
frames were only emitted on repaint (no frame-rate constraint on the tab
stream), and recording started only after `goto` fully resolved, so the
page load and intro animations were over before the first frame.

- Pin minFrameRate/maxFrameRate in the tab-capture constraints (default
  30fps) so Chromium's capturer delivers a constant cadence instead of one
  frame per repaint, and set a resolution-scaled videoBitsPerSecond so the
  extra frames aren't starved of bitrate.
- Start the recorder before navigation via an `onStarted` hook: resolve the
  viewport up front with goto.getDevice, roll the recorder, then run goto —
  so the video begins at t=0 of the load.

Verified on vercel.com: 10 frames/~4fps -> 67 frames/~23fps, and the load
+ hero animation is now captured from the first frame.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* refactor(capture): dedupe viewport scaling and resolve default device

- Extract `getScaledSize` so `getVideoConstraints` and `getVideoBitrate`
  share one DPR/width/height computation instead of duplicating it.
- Simplify the `videoBitsPerSecond` resolution so the user-supplied value
  always wins and the derived bitrate is a clear fallback.
- Drop the redundant `Promise.resolve` around the `onStarted` hook.
- Resolve the recording viewport via `opts.device ?? goto.defaultDevice`,
  mirroring how `goto` navigates. Previously a capture without an explicit
  device sized the recorder from a different viewport than the page loads
  in. Exposes `goto.defaultDevice` and adds a regression test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

* fix(capture): surface navigation failure without waiting full duration

When `onStarted` (navigation) failed after the recorder had started,
`i... (continued)

540 of 641 branches covered (84.24%)

Branch coverage included in aggregate %.

77 of 78 new or added lines in 4 files covered. (98.72%)

2561 of 2872 relevant lines covered (89.17%)

174456.7 hits per line