Feature request
Please consider exposing the size option on Python's page.screencast.start() API, matching the Node.js Playwright API.
In Node.js, page.screencast.start() supports controlling the output frame/video size:
await page.screencast.start({
onFrame: ({ data }) => sendToVisionModel(data),
size: { width: 800, height: 600 },
});
This is useful for real-time frame capture, thumbnails, live previews, AI vision pipelines, and controlling video receipt resolution independently from the page viewport.
Current Python behavior
In Python, the async API currently exposes:
await page.screencast.start(
on_frame=...,
path="video.webm",
quality=100,
)
There is no size parameter.
I verified this in both Playwright Python 1.59.0 and 1.60.0 by inspecting the generated async API signature. In 1.60.0, the generated signature is still:
async def start(
self,
*,
on_frame: Optional[Callable[[ScreencastFrame], Any]] = None,
path: Optional[Union[pathlib.Path, str]] = None,
quality: Optional[int] = None,
) -> AsyncContextManager:
Why viewport is not enough
Changing the viewport affects page layout, but it does not give Python users a way to control screencast output resolution.
For example, with a 1920x1080 viewport, the page layout is rendered at 1920x1080, but page.screencast.start(path="video.webm") still appears to produce a video/frame stream scaled down to the default 800x800 bounding behavior, typically around 800x450 for a 16:9 viewport.
For many automation/agent workflows, this is the wrong tradeoff: we may want to keep the page viewport at 1920x1080 for desktop layout fidelity, while requesting lower-resolution frames for a vision model, or higher-resolution video receipts for human review.
Expected API
Something like this would provide parity with Node.js:
await page.screencast.start(
on_frame=lambda frame: send_to_vision_model(frame["data"]),
size={"width": 800, "height": 600},
quality=80,
)
and/or:
await page.screencast.start(
path="video.webm",
size={"width": 1920, "height": 1080},
quality=100,
)
Use case
I am using Playwright Python for browser automation with agentic video receipts and page-level evidence collection. page.screencast is a much better fit than context-level video recording because it is page-scoped and works well with multi-tab/shared-context workflows. However, without size, Python users cannot control the output resolution the way Node.js users can.
Thanks for considering this API parity improvement.
Feature request
Please consider exposing the
sizeoption on Python'spage.screencast.start()API, matching the Node.js Playwright API.In Node.js,
page.screencast.start()supports controlling the output frame/video size:This is useful for real-time frame capture, thumbnails, live previews, AI vision pipelines, and controlling video receipt resolution independently from the page viewport.
Current Python behavior
In Python, the async API currently exposes:
There is no
sizeparameter.I verified this in both Playwright Python 1.59.0 and 1.60.0 by inspecting the generated async API signature. In 1.60.0, the generated signature is still:
Why viewport is not enough
Changing the viewport affects page layout, but it does not give Python users a way to control screencast output resolution.
For example, with a 1920x1080 viewport, the page layout is rendered at 1920x1080, but
page.screencast.start(path="video.webm")still appears to produce a video/frame stream scaled down to the default 800x800 bounding behavior, typically around 800x450 for a 16:9 viewport.For many automation/agent workflows, this is the wrong tradeoff: we may want to keep the page viewport at 1920x1080 for desktop layout fidelity, while requesting lower-resolution frames for a vision model, or higher-resolution video receipts for human review.
Expected API
Something like this would provide parity with Node.js:
and/or:
Use case
I am using Playwright Python for browser automation with agentic video receipts and page-level evidence collection.
page.screencastis a much better fit than context-level video recording because it is page-scoped and works well with multi-tab/shared-context workflows. However, withoutsize, Python users cannot control the output resolution the way Node.js users can.Thanks for considering this API parity improvement.