CDP startScreencast 가 deviceScaleFactor 를 무시한다

뷰포트를 390×844, deviceScaleFactor: 3 으로 잡았다. page.screenshot() 은 1170×2532 로 나온다. 그런데 녹화한 영상만 390×844 다. 같은 페이지, 같은 설정인데.

2026-08-13. 유튜브 쇼츠에 실제로 돌아가는 웹 화면을 넣으려고 녹화 부품을 만들었다. playwright 로 조작하고, ffmpeg 으로 합치고, Remotion 으로 영상을 조립하는 구성이다. 폰 화면을 찍어야 하니 390×844 를 3배로 받아 1170×2532 를 만들어야 했다. 그래야 유튜브에서 글자가 안 뭉갠다.

정석처럼 보이는 API 를 먼저 짰다

처음엔 CDP Page.startScreencast 로 짰다. 크롬이 프레임을 스트림으로 밀어주니 스크린샷을 반복해서 찍는 것보다 부드럽고 효율적이다. 이게 정석으로 보였다.

돌려보니 390×844 였다. 3배가 통째로 무시됐다.

Emulation.setDeviceMetricsOverride 로 deviceScaleFactor: 3 을 CDP 쪽에서 한 번 더 걸어봤다. 그래도 390×844. 같은 페이지에서 page.screenshot() 을 부르면 1170×2532 가 나오는데도 그랬다.

세 방식을 같은 페이지·같은 설정에서 재봤다.

방식	나온 크기
playwright recordVideo	뷰포트 그대로
CDP Page.startScreencast	390×844
page.screenshot() 루프	1170×2532

screencast 는 원래 원격 디버깅용 썸네일을 위한 것이라 고해상도가 목적이 아니었다. 이름과 모양이 그럴듯해서 용도까지 맞다고 읽은 것이 틀렸다.

부드러움과 해상도 중 하나를 버려야 했다

screencast 는 크롬이 주는 대로 받으니 프레임이 촘촘하다. screenshot 루프는 한 장에 50~150ms 가 걸려서 초당 17장쯤밖에 안 나온다. 30fps 영상에 넣으면 미세하게 툭툭 끊긴다.

그런데 내가 찍는 건 카메라가 움직이는 장면이 아니라 버튼이 눌리고 결과가 채워지는 장면이다. 17장이면 그건 다 보인다. 반대로 390px 폭은 글자가 안 읽혀서 영상 자체가 쓸모없어진다.

부드러움은 조금 나빠져도 되고 해상도는 안 되는 것이었다. 그래서 제일 투박한 쪽을 택했다.

캡처 간격이 들쭉날쭉해서, 프레임을 균등 간격으로 붙이면 실제보다 빠르거나 느린 영상이 된다. 그래서 장수가 아니라 프레임마다 붙은 시각으로 길이를 만들었다(ffmpeg concat 의 duration).

숫자는 맞았는데 화면이 틀렸다

1170×2532. 정확히 원하던 크기다. 그런데 렌더해서 눈으로 보니 두 개가 틀렸다.

첫째, 폰 화면이 상단 채널 마크를 덮었다. 세로 상한을 1100px 로 줬는데, 영상 레이아웃이 실제로 내주는 높이는 약 1000px 이었다. 1920 에서 위쪽 안전영역 150, 아래쪽 560, 자막 약 150, 여백 56 을 빼면 그렇게 된다. 계산하면 나오는 값인데 계산을 안 하고 줬다.

둘째, 데스크톱 화면 글자가 안 읽혔다. 1280×800 을 2배로 찍어 2560px 짜리를 만들었는데, 그걸 영상 폭 1080 에 넣으면 2.4배로 축소된다. 해상도가 높아서 좋은 게 아니라 원본이 넓을수록 최종 화면에서 작아진다.

이건 반대로 알고 있었다. 뷰포트를 960 CSS폭으로 좁히니 오히려 커졌다 — 960 이 1080 에 들어가면 1.125배 확대다. 담기는 양은 줄지만, 쇼츠는 한 컷에 한 가지만 보여주는 매체라 그 방향이 맞다.

바꾼 것

• 녹화 방식을 CDP screencast → page.screenshot() 루프로 교체
• 영상 쪽 세로 상한 1100 → 960
• 데스크톱 촬영 뷰포트 1280(2배) → 960(3배)
• 세 방식을 잰 표를 코드 주석에 그대로 박아뒀다. 다음에 「screencast 가 정석 아닌가」 하고 다시 짜는 걸 막으려고

1170×2532 는 통과 조건이었지 정답이 아니었다. 정답은 그 화면을 최종 매체에 얹어 봐야 나왔다.