meet-screenshots

name: meet-screenshots description: Capture documentation screenshots of the OpenVidu Meet frontend (the Angular app served at /meet) across every screen and both themes. Use when the user asks to screenshot, capture, or generate images of app screens — overview, rooms, recordings, users, login, wizard, etc. — for a docs/marketing website. Drives the running app with Playwright, logs in once and reuses the session, forces light/dark theme, seeds demo data via the REST API, and writes PNGs named by domain + navigation path. The UI route map (from each domain's *.routes.ts) and the REST API reference are documented below.

OpenVidu Meet — screenshot capture

Take consistent, theme-aware screenshots of every Meet frontend screen for documentation. The bundled capture.mjs does the work; this file is the route/API reference and the place to extend coverage to new screens.

Standard documentation resolution

1920×1080 (Full HD), deviceScaleFactor: 1 — the default. Single most common screenshot resolution; downscales cleanly into docs content columns. Pass --scale 2 for HiDPI (→ 3840×2160).

Prerequisites

• App running at http://localhost:6080/meet (verify: curl -s -o /dev/null -w "%{http_code}" http://localhost:6080/meet → 301).
• Playwright + Chromium (already in the repo root node_modules). Run from the repo root so import 'playwright' resolves.
• ffmpeg on PATH — used to transcode WebP output (the default format) and the live-scene sample webcam. Without it, use --format png; live scenes fall back to the green test pattern.
• Admin credentials (default admin/admin).

How to run

node .claude/skills/meet-screenshots/capture.mjs                          # every scene, both themes
node .claude/skills/meet-screenshots/capture.mjs --list                   # list scene ids and exit
node .claude/skills/meet-screenshots/capture.mjs --scenes login,overview  # subset
node .claude/skills/meet-screenshots/capture.mjs --themes dark --scale 2  # one theme, retina

Flags: --scenes (csv), --themes (light,dark), --width/--height/--scale, --timeout (ms, default 30000), --out, --origin, --base (/meet), --user/--password, --no-cleanup, --headed, --list, --format (webp default | png | jpeg), --quality (webp/jpeg, default 82).

Output format & optimization

Shots are written as WebP by default — far smaller than PNG (the E2EE meeting shot drops from ~1.8 MB to ~110 KB at the same 2× resolution), which keeps the docs repo and page loads light. Playwright only writes png/jpeg, so saveShot() captures a throwaway PNG and transcodes it to WebP with ffmpeg (libwebp, --quality). Use --format png for lossless output or --format jpeg when WebP isn't wanted. All scenes (static and live) go through saveShot(), so the format flag applies everywhere; the file extension follows the format.

Live meeting scenes & the sample webcam

Most scenes are single static pages, but live scenes (live: true) drive a real multi-participant meeting — e2ee-wrong-key (the wrong-key lockout, in an E2EE room), layout-settings (the Mosaic / Smart Mosaic modes and visible-participants slider) and layout-grid (6 participants — Smart Mosaic's default 4 visible slots leave a "+1" badge — with the participants panel open).

Each participant runs in its own browser (one chromium.launch per person), because a single browser can only feed one fake-camera file to all its tabs. Each browser is launched with --use-fake-device-for-media-stream + --use-fake-ui-for-media-stream and a per-person --use-file-for-fake-video-capture pointing at a Y4M transcoded from that person's portrait (sampleY4mFor() via ffmpeg, cached per file). So every tile shows a different real person — no repeated faces in a meeting. If ffmpeg or an image is missing, that participant falls back to the green test pattern.

Faces and names come from SAMPLE_ROSTER in capture.mjs (portraits in assets/, each paired with a gender-appropriate name: Emma, David, Sarah, James, Zoe). The first roster entry is the captured viewer; the rest are remote tiles in join order. Participants beyond the roster get OVERFLOW_NAMES and reuse a face — fine because Smart Mosaic hides them (only the name shows in the "+N" badge), so no duplicate face is ever rendered. To change the cast, edit SAMPLE_ROSTER and drop matching images into assets/. Live scenes seed their own room per theme (E2EE for e2ee-wrong-key, plain for the layout scenes) and delete it afterwards, so they don't collide with the empty-state safety checks.

Live captures juggle several browsers, so they are more timing-sensitive than static pages. All live scenes retry once per theme automatically; if one still times out, re-run just that theme (--themes dark). Heavier scenes (e.g. layout-grid, 6 participants) flake more often.

Mechanics: logs in once via the UI and reuses storageState across all contexts (repeated logins trip the backend rate limiter); forces theme via localStorage['ovMeet-theme'] + colorScheme; seeds demo rooms via REST for populated scenes and deletes only those; each shot retries up to 3× with backoff (data-heavy pages occasionally stall late in a long run).

Output naming — by domain + navigation path

<out>/<domain>/<navpath>[-state]-<theme>.<ext> (folder = frontend domain, file = nav path + state + theme; <ext> follows --format, WebP by default). The default run produces 38 WebP images (19 scenes × 2 themes):

auth/      login
console/   overview · overview-empty · embedded · config · error
meeting/   disconnected · e2ee-wrong-key · layout-settings · layout-grid
rooms/     rooms-empty · rooms-3rooms · rooms-new · rooms-detail · rooms-edit
recordings/recordings
users/     users · users-new · profile

e2ee-wrong-key, layout-settings and layout-grid are live multi-participant scenes (see "Live meeting scenes & the sample webcam" above); they need the app running plus ffmpeg for the sample webcam. Drop them with an explicit --scenes list if you only want the static pages.

Scene catalog (built into capture.mjs)

Full UI route map (source: domains/<domain>/routes/*.routes.ts)

Routes are assembled in shared/routes/base-routes.ts. Public routes sit at the top level under /meet; console routes are children of an authenticated shell ('' redirects to overview). Nav order: Overview(1) · Rooms(2) · Recordings(3) · Users(4) · Embedded(5) · Configuration(6).

✅ covered by a default scene · ⚙️ reachable by seeding an entity id (extend the catalog) · 🔒 needs a live session / share secret / special user state (manual setup).

REST API reference (for seeding)

Interactive docs (Scalar): http://localhost:6080/meet/api/v1/docs (public API) and http://localhost:6080/meet/internal-api/v1/docs (internal API). The /docs route returns the HTML reference, not a raw spec JSON.

• Public API — base http://localhost:6080/meet/api/v1, auth Authorization: Bearer <token> or x-api-key. Resources: rooms, recordings, users.
• Internal API — base http://localhost:6080/meet/internal-api/v1. Resources: auth (/login, /logout, /refresh), api-keys, users (/me, /change-password), rooms, meetings, config, analytics, ai.

Login (seeding): POST /internal-api/v1/auth/login {userId,password} → accessToken in body.

Key endpoints used for screenshot seeding:

Seedability: rooms ✅, users ✅, recordings ❌ (need a live meeting).

Safety rules (important)

• Never delete pre-existing rooms. Empty-list scenes (rooms-empty, overview-empty) preflight and abort if any room exists, rather than wiping data. If aborted, clear the Rooms screen (or drop those scenes from --scenes) and retry.
• The script deletes only the demo rooms it created this run (tracked by id), with cleanup on by default (--no-cleanup to keep them). Cleanup uses force/force so meeting-less demo rooms go immediately.
• Cleanup issues a backend DELETE; in stricter permission modes that call may prompt for approval (it can't tell the rooms are agent-created). If blocked/failed, the script reports what remains.

Extending coverage

Add an entry to ALL_SCENES in capture.mjs. Use the route map above for the path/roles, and pick a stable waitFor (an id on the page, or h1:has-text("…") / h1:text-is("…") — prefer :text-is when a "Loading X" header would otherwise match). For routes needing an entity id, use a build(ctx) scene (see room-detail) — ctx.roomIds / ctx.roomNames are available after seeding. For new seedable entities (e.g. members), add a REST helper mirroring createRoom/deleteRooms.