[07rjain]

Split out of #2580 (embed player split).

EmbedVideo now loads the MP4/HLS player and upload tracker through next/dynamic, and uses motion/react for the chrome. An embed downloads the player it needs without adding a second animation runtime.

Metadata handling now captures events on the player container, so a player that mounts after EmbedVideo still applies the URL start-time seek. The seek remains once-only across later metadata events. Pending-loader regressions cover MP4 and HLS playback, start-time seeking, and chrome updates after play/pause.

Main has been merged.

Validation: all 33 embed playback/branding tests and scoped Biome checks pass.

Confidence Score: 4/5

The PR appears safe to merge, with a non-blocking gap in tests for delayed player loading.

Findings

1.  Late loading goes untested ▶

Fix with agent prompt

### Issue 1
apps/web/__tests__/unit/embed-video-playback-chrome.test.ts:201-203
The new `next/dynamic` mock starts every loader immediately, and `beforeAll` waits for all of them before rendering. This skips the loading behavior introduced by this PR, so the tests cannot catch problems when a player arrives after `EmbedVideo` mounts. Keep a loader pending during at least one test, resolve it after rendering, and check that playback events still update the chrome.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Summary

The PR loads the embed players and upload tracker through next/dynamic and switches the embed chrome to motion/react.

• Embedded videos load only the player and upload tracker they need.

Tests were not run.

_{Reviews (1) · Last reviewed commit: "perf(embed): code-split the players and ..." · Reviewed by Greptile}

[vercel]

@07rjain is attempting to deploy a commit to the Cap Software Inc Team on Vercel.

A member of the Team first needs to authorize it.

[greptile-apps]

Late loading goes untested

The new next/dynamic mock starts every loader immediately, and beforeAll waits for all of them before rendering. This skips the loading behavior introduced by this PR, so the tests cannot catch problems when a player arrives after EmbedVideo mounts. Keep a loader pending during at least one test, resolve it after rendering, and check that playback events still update the chrome.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/web/__tests__/unit/embed-video-playback-chrome.test.ts
Line: 201-203

Comment:
**Late loading goes untested**

The new `next/dynamic` mock starts every loader immediately, and `beforeAll` waits for all of them before rendering. This skips the loading behavior introduced by this PR, so the tests cannot catch problems when a player arrives after `EmbedVideo` mounts. Keep a loader pending during at least one test, resolve it after rendering, and check that playback events still update the chrome.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[richiemcilroy]

Thanks @07rjain, this is a nice split. It matches what ShareVideo.tsx already does (dynamic players, ssr: false upload tracker, the fetching initial state), and moving the embed onto motion/react drops the extra framer-motion runtime from the embed bundle.

The only open item is Greptile's P2 on apps/web/__tests__/unit/embed-video-playback-chrome.test.ts:203 (the next/dynamic mock resolves every loader before rendering, so the late-load path isn't exercised). It's a coverage point rather than a bug. With ssr left on and no loading option, next/dynamic doesn't add a Suspense boundary of its own, so the embed and its player hydrate together and videoRef is set before EmbedVideo's effects run (the startTime seek and usePlayerJsReceiver rely on that). Either add a small test that keeps one loader pending, resolves it after render and checks the chrome still reacts to playback events, or reply on Greptile's thread with that reasoning. Either is fine with us.

The branch is also quite far behind main now (it merges cleanly), so please merge main when you push so CI runs against current code.

It needs to reach Greptile 5/5 with green CI before we can merge. You can mention @greptileai in a comment to get a re-review after pushing. Thanks!

[greptile-apps]

Thanks — I agree the P2 is a coverage gap, not evidence that playback chrome is broken: the wrapper handles bubbled playback events, and the existing async-player case checks chrome after the video mounts. One caveat: ssr: true prerenders the player markup, but it does not guarantee the dynamic client module is hydrated before EmbedVideo’s effects run. If the player chunk resolves later, the startTime effect can see videoRef.current === null and return without retrying; unlike usePlayerJsReceiver, that effect does not wait for the player to appear. So a pending-loader test is reasonable, but the “they hydrate together” assumption doesn’t rule out that separate ref-timing case.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
cap-status	Skipped		Oct 23, 2026 11:56pm UTC