Actually, I still use the image standalone-chrome:4.34.0-20250707 and simply add the screencastlinuxv2 app to run in the background.
This helps capture every frame using Chrome's debug mode in port 9222
Then after test finish ,i will convert it to videos
I'm just curious and want to use a headless browser.

Dockerfile

FROM selenium/standalone-chrome:4.34.0-20250707
# Set working directory for app scripts
WORKDIR /usr/src/app
# Copy screencast binary with execution permission
COPY --chmod=755 screencastlinuxv2 /usr/src/app/screencastlinuxv2

I took a few minutes to read through. I guess people come to headless browser for a few reasons, like run faster, less resource consumption, web scraping, etc (top Google results mentioned this). However, come to the solution is taking screenshot continuously and cast to a video (might it impact above benefits?).
Come to the initial demo, thanks for your initiative. However, to me, it is still complex since it requires many steps from client code to tooling.

• Key things is CDP and debug port enabled. Let's say expose container port 9222, then script controller app.js, binary screencast can run on host and be controlled in part of test fixtures. No need extra Dockerfile to copy banary screencast to container and start app.js on host, also need consider host is using which OS to run particular shell script. But I know this is not easy, since it requires FFmpeg, which also needs to install on host, so reasonable that you let it reuse FFmpeg in browser node.
• If come to containerization principle, better is consider to wrap everything and make everything is ready to use. So, from client code, user just add browser args to enable debug port, and the rest of works (app.js, binary running in container, trigger if dedicated port is open, similar way current video recording works) and then mount container volume to get output files on host.

Btw, sometime before I also tried to evaluate the popularity of "video recording in browser headless", there were many people also curious, few tutorials there but might not be up-to-date, Selenide also applied this screencast approach (selenide/selenide#2145).
I also would like to use containerization to solve this. However, to bring it here, need to consider that the solution is simple, maintainable, extendable (for someone who wants to customize their own), and independent (easy to remove once it's no longer supported).

Where can I see performance metrics that prove headless uses less resources?

Also, the containers can record video already. Why not using a regular browser?

Thanks, @VietND96 — that's correct. The key point is CDP, and it seems Playwright and Cypress also use it.
I also agree with you: every solution should be simple, maintainable, extendable,Customers shouldn't need to configure too much.