feat(video): allow configuring screencast bitrate

[Devin Rousso (dcrousso)]

video recordings use a fixed bitrate that can make UI details unreadable during motion

add a bitrate option to screencast recording and video-start while preserving the existing default

fixes#42375

[github-actions]

Test results for "tests 1"

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node20`

46514 passed, 1065 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files @mcp-windows-latest-firefox

8258 passed, 1361 skipped

---

Merge workflow run.

[github-actions]

🟡 One MCP failure I can't fully pin on the PR — but the diff can't reach it

Hi, I'm the Playwright bot and I took a first look at the CI failures here.

The one real failure is mcp/cli-core.spec.ts:149 › upload multiple files on Firefox/Windows — a file-upload modal-state race. This PR only adds a bitrate param to the video-start path, so I don't see how it could cause it, but I couldn't find the same test failing on another SHA to certify a pre-existing flake. Calling it uncertain, leaning flake.

Details

Overall: nothing in this PR touches file upload or modal state. The diff (SHA 52c4fb4) is a purely additive bitrate option threaded through videoRecorder.ts, the video-start MCP tool/CLI command, and the protocol. The failing area is unrelated, so I don't think this PR degraded CI — but I'm flagging one failure I can't prove either way.

Uncertain (leaning pre-existing flake)

• [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files@mcp-windows-latest-firefox — failed with The tool "browser_file_upload" can only be used when there is related modal state present, i.e. the file-chooser modal wasn't registered when the tool ran. That's a classic first-pass race. Across the results DB this test has 366/367 passing on this exact bot and 0 failures on every other bot — its only recorded failure is this PR's own run (SHA 52c4fb4), so I can't cite another SHA to call it a confirmed flake. But the change here (video bitrate only) doesn't exercise the upload/modal path, so a causal link is implausible. A rerun of the MCP job would most likely clear it.

Pre-existing flake / infra

• [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace — reported flaky (rescued on retry), not a failure. Confirmed pre-existing flake: across the DB it was retry-rescued 647 times over 428 distinct SHAs with only 10 final failures, so it flakes independently of this PR. Nothing to triage, though it's worth noting it's the video feature this PR touches — the flake predates it.

_{Triaged by the Playwright bot - agent run}

[Dmitry Gozman (dgozman)]

Last time we discussed a similar thing, we ended up not doing it. See this comment. We should make a decision about requests like this.

[Devin Rousso (dcrousso)]

closing as per #41007 (comment)

[Devin Rousso (dcrousso)]

video recordings use a fixed bitrate that can make UI details unreadable during motion

add a bitrate option to screencast recording and video-start while preserving the existing default

fixes#42375

[github-actions]

Test results for "tests 1"

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node20`

46514 passed, 1065 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files @mcp-windows-latest-firefox

8258 passed, 1361 skipped

---

Merge workflow run.

[github-actions]

🟡 One MCP failure I can't fully pin on the PR — but the diff can't reach it

Hi, I'm the Playwright bot and I took a first look at the CI failures here.

The one real failure is mcp/cli-core.spec.ts:149 › upload multiple files on Firefox/Windows — a file-upload modal-state race. This PR only adds a bitrate param to the video-start path, so I don't see how it could cause it, but I couldn't find the same test failing on another SHA to certify a pre-existing flake. Calling it uncertain, leaning flake.

Details

Overall: nothing in this PR touches file upload or modal state. The diff (SHA 52c4fb4) is a purely additive bitrate option threaded through videoRecorder.ts, the video-start MCP tool/CLI command, and the protocol. The failing area is unrelated, so I don't think this PR degraded CI — but I'm flagging one failure I can't prove either way.

Uncertain (leaning pre-existing flake)

• [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files@mcp-windows-latest-firefox — failed with The tool "browser_file_upload" can only be used when there is related modal state present, i.e. the file-chooser modal wasn't registered when the tool ran. That's a classic first-pass race. Across the results DB this test has 366/367 passing on this exact bot and 0 failures on every other bot — its only recorded failure is this PR's own run (SHA 52c4fb4), so I can't cite another SHA to call it a confirmed flake. But the change here (video bitrate only) doesn't exercise the upload/modal path, so a causal link is implausible. A rerun of the MCP job would most likely clear it.

Pre-existing flake / infra

• [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace — reported flaky (rescued on retry), not a failure. Confirmed pre-existing flake: across the DB it was retry-rescued 647 times over 428 distinct SHAs with only 10 final failures, so it flakes independently of this PR. Nothing to triage, though it's worth noting it's the video feature this PR touches — the flake predates it.

_{Triaged by the Playwright bot - agent run}

[Dmitry Gozman (dgozman)]

Last time we discussed a similar thing, we ended up not doing it. See this comment. We should make a decision about requests like this.

[Devin Rousso (dcrousso)]

closing as per #41007 (comment)

[Devin Rousso (dcrousso)]

video recordings use a fixed bitrate that can make UI details unreadable during motion

add a bitrate option to screencast recording and video-start while preserving the existing default

fixes#42375

[github-actions]

Test results for "tests 1"

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node20`

46514 passed, 1065 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files @mcp-windows-latest-firefox

8258 passed, 1361 skipped

---

Merge workflow run.

[github-actions]

🟡 One MCP failure I can't fully pin on the PR — but the diff can't reach it

Hi, I'm the Playwright bot and I took a first look at the CI failures here.

The one real failure is mcp/cli-core.spec.ts:149 › upload multiple files on Firefox/Windows — a file-upload modal-state race. This PR only adds a bitrate param to the video-start path, so I don't see how it could cause it, but I couldn't find the same test failing on another SHA to certify a pre-existing flake. Calling it uncertain, leaning flake.

Details

Overall: nothing in this PR touches file upload or modal state. The diff (SHA 52c4fb4) is a purely additive bitrate option threaded through videoRecorder.ts, the video-start MCP tool/CLI command, and the protocol. The failing area is unrelated, so I don't think this PR degraded CI — but I'm flagging one failure I can't prove either way.

Uncertain (leaning pre-existing flake)

• [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files@mcp-windows-latest-firefox — failed with The tool "browser_file_upload" can only be used when there is related modal state present, i.e. the file-chooser modal wasn't registered when the tool ran. That's a classic first-pass race. Across the results DB this test has 366/367 passing on this exact bot and 0 failures on every other bot — its only recorded failure is this PR's own run (SHA 52c4fb4), so I can't cite another SHA to call it a confirmed flake. But the change here (video bitrate only) doesn't exercise the upload/modal path, so a causal link is implausible. A rerun of the MCP job would most likely clear it.

Pre-existing flake / infra

• [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace — reported flaky (rescued on retry), not a failure. Confirmed pre-existing flake: across the DB it was retry-rescued 647 times over 428 distinct SHAs with only 10 final failures, so it flakes independently of this PR. Nothing to triage, though it's worth noting it's the video feature this PR touches — the flake predates it.

_{Triaged by the Playwright bot - agent run}

[Dmitry Gozman (dgozman)]

Last time we discussed a similar thing, we ended up not doing it. See this comment. We should make a decision about requests like this.

[Devin Rousso (dcrousso)]

closing as per #41007 (comment)

[Devin Rousso (dcrousso)]

video recordings use a fixed bitrate that can make UI details unreadable during motion

add a bitrate option to screencast recording and video-start while preserving the existing default

fixes#42375

[github-actions]

Test results for "tests 1"

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node20`

46514 passed, 1065 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files @mcp-windows-latest-firefox

8258 passed, 1361 skipped

---

Merge workflow run.

[github-actions]

🟡 One MCP failure I can't fully pin on the PR — but the diff can't reach it

Hi, I'm the Playwright bot and I took a first look at the CI failures here.

The one real failure is mcp/cli-core.spec.ts:149 › upload multiple files on Firefox/Windows — a file-upload modal-state race. This PR only adds a bitrate param to the video-start path, so I don't see how it could cause it, but I couldn't find the same test failing on another SHA to certify a pre-existing flake. Calling it uncertain, leaning flake.

Details

Overall: nothing in this PR touches file upload or modal state. The diff (SHA 52c4fb4) is a purely additive bitrate option threaded through videoRecorder.ts, the video-start MCP tool/CLI command, and the protocol. The failing area is unrelated, so I don't think this PR degraded CI — but I'm flagging one failure I can't prove either way.

Uncertain (leaning pre-existing flake)

• [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files@mcp-windows-latest-firefox — failed with The tool "browser_file_upload" can only be used when there is related modal state present, i.e. the file-chooser modal wasn't registered when the tool ran. That's a classic first-pass race. Across the results DB this test has 366/367 passing on this exact bot and 0 failures on every other bot — its only recorded failure is this PR's own run (SHA 52c4fb4), so I can't cite another SHA to call it a confirmed flake. But the change here (video bitrate only) doesn't exercise the upload/modal path, so a causal link is implausible. A rerun of the MCP job would most likely clear it.

Pre-existing flake / infra

• [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace — reported flaky (rescued on retry), not a failure. Confirmed pre-existing flake: across the DB it was retry-rescued 647 times over 428 distinct SHAs with only 10 final failures, so it flakes independently of this PR. Nothing to triage, though it's worth noting it's the video feature this PR touches — the flake predates it.

_{Triaged by the Playwright bot - agent run}

[Dmitry Gozman (dgozman)]

Last time we discussed a similar thing, we ended up not doing it. See this comment. We should make a decision about requests like this.

[Devin Rousso (dcrousso)]

closing as per #41007 (comment)

[Devin Rousso (dcrousso)]

video recordings use a fixed bitrate that can make UI details unreadable during motion

add a bitrate option to screencast recording and video-start while preserving the existing default

fixes#42375

[github-actions]

Test results for "tests 1"

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node20`

46514 passed, 1065 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files @mcp-windows-latest-firefox

8258 passed, 1361 skipped

---

Merge workflow run.

[github-actions]

🟡 One MCP failure I can't fully pin on the PR — but the diff can't reach it

Hi, I'm the Playwright bot and I took a first look at the CI failures here.

The one real failure is mcp/cli-core.spec.ts:149 › upload multiple files on Firefox/Windows — a file-upload modal-state race. This PR only adds a bitrate param to the video-start path, so I don't see how it could cause it, but I couldn't find the same test failing on another SHA to certify a pre-existing flake. Calling it uncertain, leaning flake.

Details

Overall: nothing in this PR touches file upload or modal state. The diff (SHA 52c4fb4) is a purely additive bitrate option threaded through videoRecorder.ts, the video-start MCP tool/CLI command, and the protocol. The failing area is unrelated, so I don't think this PR degraded CI — but I'm flagging one failure I can't prove either way.

Uncertain (leaning pre-existing flake)

• [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files@mcp-windows-latest-firefox — failed with The tool "browser_file_upload" can only be used when there is related modal state present, i.e. the file-chooser modal wasn't registered when the tool ran. That's a classic first-pass race. Across the results DB this test has 366/367 passing on this exact bot and 0 failures on every other bot — its only recorded failure is this PR's own run (SHA 52c4fb4), so I can't cite another SHA to call it a confirmed flake. But the change here (video bitrate only) doesn't exercise the upload/modal path, so a causal link is implausible. A rerun of the MCP job would most likely clear it.

Pre-existing flake / infra

• [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace — reported flaky (rescued on retry), not a failure. Confirmed pre-existing flake: across the DB it was retry-rescued 647 times over 428 distinct SHAs with only 10 final failures, so it flakes independently of this PR. Nothing to triage, though it's worth noting it's the video feature this PR touches — the flake predates it.

_{Triaged by the Playwright bot - agent run}

[Dmitry Gozman (dgozman)]

Last time we discussed a similar thing, we ended up not doing it. See this comment. We should make a decision about requests like this.

[Devin Rousso (dcrousso)]

closing as per #41007 (comment)

[Devin Rousso (dcrousso)]

video recordings use a fixed bitrate that can make UI details unreadable during motion

add a bitrate option to screencast recording and video-start while preserving the existing default

fixes#42375

[github-actions]

Test results for "tests 1"

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node20`

46514 passed, 1065 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files @mcp-windows-latest-firefox

8258 passed, 1361 skipped

---

Merge workflow run.

[github-actions]

🟡 One MCP failure I can't fully pin on the PR — but the diff can't reach it

Hi, I'm the Playwright bot and I took a first look at the CI failures here.

The one real failure is mcp/cli-core.spec.ts:149 › upload multiple files on Firefox/Windows — a file-upload modal-state race. This PR only adds a bitrate param to the video-start path, so I don't see how it could cause it, but I couldn't find the same test failing on another SHA to certify a pre-existing flake. Calling it uncertain, leaning flake.

Details

Overall: nothing in this PR touches file upload or modal state. The diff (SHA 52c4fb4) is a purely additive bitrate option threaded through videoRecorder.ts, the video-start MCP tool/CLI command, and the protocol. The failing area is unrelated, so I don't think this PR degraded CI — but I'm flagging one failure I can't prove either way.

Uncertain (leaning pre-existing flake)

• [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files@mcp-windows-latest-firefox — failed with The tool "browser_file_upload" can only be used when there is related modal state present, i.e. the file-chooser modal wasn't registered when the tool ran. That's a classic first-pass race. Across the results DB this test has 366/367 passing on this exact bot and 0 failures on every other bot — its only recorded failure is this PR's own run (SHA 52c4fb4), so I can't cite another SHA to call it a confirmed flake. But the change here (video bitrate only) doesn't exercise the upload/modal path, so a causal link is implausible. A rerun of the MCP job would most likely clear it.

Pre-existing flake / infra

• [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace — reported flaky (rescued on retry), not a failure. Confirmed pre-existing flake: across the DB it was retry-rescued 647 times over 428 distinct SHAs with only 10 final failures, so it flakes independently of this PR. Nothing to triage, though it's worth noting it's the video feature this PR touches — the flake predates it.

_{Triaged by the Playwright bot - agent run}

[Dmitry Gozman (dgozman)]

Last time we discussed a similar thing, we ended up not doing it. See this comment. We should make a decision about requests like this.

[Devin Rousso (dcrousso)]

closing as per #41007 (comment)

[Devin Rousso (dcrousso)]

video recordings use a fixed bitrate that can make UI details unreadable during motion

add a bitrate option to screencast recording and video-start while preserving the existing default

fixes#42375

[github-actions]

Test results for "tests 1"

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node20`

46514 passed, 1065 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files @mcp-windows-latest-firefox

8258 passed, 1361 skipped

---

Merge workflow run.

[github-actions]

🟡 One MCP failure I can't fully pin on the PR — but the diff can't reach it

Hi, I'm the Playwright bot and I took a first look at the CI failures here.

The one real failure is mcp/cli-core.spec.ts:149 › upload multiple files on Firefox/Windows — a file-upload modal-state race. This PR only adds a bitrate param to the video-start path, so I don't see how it could cause it, but I couldn't find the same test failing on another SHA to certify a pre-existing flake. Calling it uncertain, leaning flake.

Details

Overall: nothing in this PR touches file upload or modal state. The diff (SHA 52c4fb4) is a purely additive bitrate option threaded through videoRecorder.ts, the video-start MCP tool/CLI command, and the protocol. The failing area is unrelated, so I don't think this PR degraded CI — but I'm flagging one failure I can't prove either way.

Uncertain (leaning pre-existing flake)

• [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files@mcp-windows-latest-firefox — failed with The tool "browser_file_upload" can only be used when there is related modal state present, i.e. the file-chooser modal wasn't registered when the tool ran. That's a classic first-pass race. Across the results DB this test has 366/367 passing on this exact bot and 0 failures on every other bot — its only recorded failure is this PR's own run (SHA 52c4fb4), so I can't cite another SHA to call it a confirmed flake. But the change here (video bitrate only) doesn't exercise the upload/modal path, so a causal link is implausible. A rerun of the MCP job would most likely clear it.

Pre-existing flake / infra

• [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace — reported flaky (rescued on retry), not a failure. Confirmed pre-existing flake: across the DB it was retry-rescued 647 times over 428 distinct SHAs with only 10 final failures, so it flakes independently of this PR. Nothing to triage, though it's worth noting it's the video feature this PR touches — the flake predates it.

_{Triaged by the Playwright bot - agent run}

[Dmitry Gozman (dgozman)]

Last time we discussed a similar thing, we ended up not doing it. See this comment. We should make a decision about requests like this.

[Devin Rousso (dcrousso)]

closing as per #41007 (comment)

[Devin Rousso (dcrousso)]

video recordings use a fixed bitrate that can make UI details unreadable during motion

add a bitrate option to screencast recording and video-start while preserving the existing default

fixes#42375

[github-actions]

Test results for "tests 1"

2 flaky

⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@frozen-time-library-chromium-linux`
⚠️ [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace `@chromium-ubuntu-22.04-node20`

46514 passed, 1065 skipped

---

Merge workflow run.

[github-actions]

Test results for "MCP"

1 failed
❌ [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files @mcp-windows-latest-firefox

8258 passed, 1361 skipped

---

Merge workflow run.

[github-actions]

🟡 One MCP failure I can't fully pin on the PR — but the diff can't reach it

Hi, I'm the Playwright bot and I took a first look at the CI failures here.

The one real failure is mcp/cli-core.spec.ts:149 › upload multiple files on Firefox/Windows — a file-upload modal-state race. This PR only adds a bitrate param to the video-start path, so I don't see how it could cause it, but I couldn't find the same test failing on another SHA to certify a pre-existing flake. Calling it uncertain, leaning flake.

Details

Overall: nothing in this PR touches file upload or modal state. The diff (SHA 52c4fb4) is a purely additive bitrate option threaded through videoRecorder.ts, the video-start MCP tool/CLI command, and the protocol. The failing area is unrelated, so I don't think this PR degraded CI — but I'm flagging one failure I can't prove either way.

Uncertain (leaning pre-existing flake)

• [firefox] › mcp/cli-core.spec.ts:149 › upload multiple files@mcp-windows-latest-firefox — failed with The tool "browser_file_upload" can only be used when there is related modal state present, i.e. the file-chooser modal wasn't registered when the tool ran. That's a classic first-pass race. Across the results DB this test has 366/367 passing on this exact bot and 0 failures on every other bot — its only recorded failure is this PR's own run (SHA 52c4fb4), so I can't cite another SHA to call it a confirmed flake. But the change here (video bitrate only) doesn't exercise the upload/modal path, so a causal link is implausible. A rerun of the MCP job would most likely clear it.

Pre-existing flake / infra

• [chromium-library] › library/video.spec.ts:736 › screencast › should work with video+trace — reported flaky (rescued on retry), not a failure. Confirmed pre-existing flake: across the DB it was retry-rescued 647 times over 428 distinct SHAs with only 10 final failures, so it flakes independently of this PR. Nothing to triage, though it's worth noting it's the video feature this PR touches — the flake predates it.

_{Triaged by the Playwright bot - agent run}

[Dmitry Gozman (dgozman)]

Last time we discussed a similar thing, we ended up not doing it. See this comment. We should make a decision about requests like this.

[Devin Rousso (dcrousso)]

closing as per #41007 (comment)