/watch — 만든 도구

영상을 던지면 요약이 아니라 만들 수 있는 설계 스펙이 돌아옵니다.

/watch 는 AI(Claude)에게 영상을 «보게» 해 주는 스킬입니다. 출발점은 YouTube Summary 라는 사이트였습니다 — 유튜브 링크를 넣으면 자막을 읽고 요약해 주는 곳입니다. /watch 는 거기에 «눈»과 «귀»를 더했고, 돌려받는 것을 «요약»에서 «만들 수 있는 설계서»로 바꿨습니다.

스킬은 AI에게 특정한 일을 시키는 방법을 적은 설명서와, 그 일을 하는 스크립트를 한 폴더에 묶은 것입니다. 영상 주소를 던지면, «요약»이 아니라 «만들 수 있는 설계서»가 돌아옵니다.

먼저 YouTube Summary 가 하는 일 — 이 스킬의 기준점

YouTube Summary(youtubesummary.com)는 유튜브 링크를 붙여 넣으면 30초 안에 요약을 돌려주는 무료 사이트입니다. 가입도 필요 없습니다. 이 사이트가 자기 블로그에 밝힌 순서는 이렇습니다.

영상에 달린 자막을 가져옵니다. 자막은 영상 속 말을 시각과 함께 글로 적어 둔 것입니다
긴 자막은 몇 덩어리로 나눕니다
제목과 앞부분을 보고 영상 종류를 고릅니다 — 강의, 제품 리뷰, 요리, 뉴스 같은 것
종류마다 다른 질문지로 요약합니다. 요리 영상이면 재료와 순서를, 리뷰면 장단점과 결론을 묻습니다
덩어리별 요약을 하나로 합칩니다

그리고 스스로 밝힌 한계가 둘 있습니다. 화면은 보지 않습니다. 그래프나 시연, 화면에만 나오는 글자는 모릅니다. 자막이 없으면 멈춥니다. 소리를 받아 적는 일은 비용과 시간이 커서 기본으로 하지 않는다고 적어 두었습니다.

/watch 는 거기에 눈과 귀를 더했습니다

YouTube Summary 가 스스로 밝힌 두 한계 — 화면을 안 본다, 자막이 없으면 멈춘다 — 를 메우는 쪽으로 만들었다.

	YouTube Summary	/watch
읽는 것	자막(글)만	자막 + 화면 사진
자막이 없으면	멈춘다	소리를 받아써서 대본을 만든다
어디서 도나	그 사이트의 서버	내 컴퓨터 — 영상 파일은 밖으로 안 나간다
돌려주는 것	요약	질문에 대한 답, 그리고 설계서

화면 사진은 영상에서 멈춰 찍은 한 장 한 장(프레임)입니다. AI는 그 사진을 직접 열어 봅니다.

어떻게 도나

주소를 주면 이렇게 진행합니다.

영상을 받음
화면을 사진으로 뽑음 — 몇 장 뽑을지는 영상 길이로, 어디서 뽑을지는 «마지막으로 찍은 사진 이후 얼마나 달라졌나»로 정함. 장면이 통째로 바뀐 곳은 반드시, 글자가 한 자씩 써지는 것처럼 천천히 바뀌는 화면도 달라진 게 쌓이면 찍힘, 멈춘 구간은 성기게. 아무리 길어도 100장을 넘지 않음
자막에서 대본을 가져옴 — 자막이 없으면 소리를 받아써서 만듦
사진과 대본을 시각 순서로 맞춰 넘김 — AI가 사진을 한 장씩 열어 보고 답함

첫 버전은 쓸모없었습니다

솔직하게 적습니다. 처음 만든 건 YouTube Summary 처럼 요약을 냈습니다.

요약은 「무슨 일이 있었는지」를 알려 줍니다. 그건 안 볼 사람에게 필요한 것입니다.

그런데 제가 영상을 보는 이유는 만들려고입니다. 그러면 요약은 아무 값이 없습니다.

	요약이 주는 것	제가 필요한 것
내용	「전투 시스템을 설명했다」	「체력 막대가 «하나»이고 둘이 밀어낸다」
쓸 수 있나	못 씀	그대로 만들 수 있음

그래서 요약을 버리고 「설계서」를 내게 바꿨습니다. 무엇이 어떻게 동작하는지, 숫자는 어떤지, 화면 어디에 무엇이 있는지.

같은 영상을 봐도 「무슨 내용이었나」와 「어떻게 만들어졌나」는 다른 결과물입니다.

세 가지가 문제였습니다

	문제
프레임 예산	비용이 거의 전부 화면 캡처에 있는데, 영상 길이는 무한히 늘어납니다
대본	자막이 있을 때와 없을 때가 완전히 다른 길입니다
경계와 실패	남의 영상을 다루는 도구가 무엇을 밖으로 보내는가

어디에 쓰이나

지금까지 16건 돌렸습니다. 결과가 두 군데로 갑니다.

이 사이트의 분석 기록
게임 프로젝트 — 남의 발표에서 뽑은 설계가 거기서 실제로 구현되고 테스트됩니다

두 번째가 이 도구를 만든 이유입니다. 영상을 보고 「좋네」로 끝나면 남는 게 없습니다. 설계서로 나와야 다음 단계로 넘어갑니다.

직접 만들고 싶다면 — 재료는 넷입니다

이 스킬은 생각보다 단순합니다. 이미 있는 도구 셋을 순서대로 부르는 스크립트와, AI에게 «언제, 어떻게 부르라»고 알려 주는 설명서 한 장이 전부입니다.

재료	하는 일
yt-dlp	영상과 자막을 내려받는다 (무료)
ffmpeg	영상에서 사진을 뽑고, 필요하면 소리만 떼어 낸다 (무료)
Whisper (Groq 또는 OpenAI)	자막이 없을 때 소리를 글로 받아쓴다 — 유일하게 돈이 드는 곳
SKILL.md	AI가 읽는 설명서. 언제 이 스킬을 쓰고 결과를 어떻게 읽을지 적는다

단계별 순서와 숫자, 만들 때 걸리는 함정은 아래 «자세한 기록»의 「만들기」 절들에 적었습니다. 코드 원본은 맨 위 출처의 bradautomates/claude-video(MIT 라이선스)입니다.

여기부터는 자세한 기록입니다

URL을 주면 영상을 받고, 영상 길이로 정한 장수를 화면이 바뀌는 곳에 나눠 프레임을 뽑고, 자막에서 대본을 가져오고 — 자막이 없으면 직접 받아쓰고 — 전체를 읽을 수 있는 하나로 넘긴다.

첫 버전은 쓸모없었다

요약을 냈다. 요약은 무슨 일이 있었는지를 알려준다. 만들려고 본 사람에겐 아무 값이 없다.

고친 건 “무엇을 요구하는가”였다. “이 영상이 무엇에 관한 것인가”가 아니라 “이 동작을 내려면 뭘 만들어야 하는가” — 메커니즘, 상태 전이, 실패 케이스, 발표자가 건너뛴 부분. 산출물이 설명에서 입력으로 바뀌었다.

이 한 줄이 도구 전체의 설계를 정한다. 설명을 만들 거면 대본만 있어도 되지만, 스펙을 만들려면 화면을 봐야 하고, 화면을 보는 순간 비용 문제가 시작된다.

세 가지가 문제였다

	문제
프레임 예산	비용이 거의 전부 프레임에 있는데, 영상 길이는 무한히 는다
대본	자막이 있을 때와 없을 때가 완전히 다른 경로다
경계와 실패	남의 영상을 다루는 도구가 무엇을 밖으로 보내는가

어디로 가나

지금까지 16건. 두 군데로 흘러간다. 이 사이트의 분석 아카이브, 그리고 게임 프로젝트 — 남의 발표에서 뽑은 스펙이 거기서 구현되고 테스트된다.

루프가 핵심이다. 보고, 뽑고, 만들고, 부순다.

출처와 계보 — 기준은 YouTube Summary, 코드는 claude-video

이 스킬에는 원본이 둘 있다.

원본	무엇을 가져왔나
YouTube Summary	기준점. 자막을 가져와 덩어리로 나누고, 종류를 가린 뒤 종류별 질문지로 요약해 합치는 다섯 단계가 공개 블로그에 적혀 있다. /watch 는 그 파이프라인이 스스로 밝힌 두 빈칸 — 화면을 안 본다, 자막이 없으면 멈춘다 — 을 메우는 쪽으로 만들었다
bradautomates/claude-video	코드. MIT 라이선스. 다운로드·프레임·대본·받아쓰기·점검·입구 스크립트 여섯 개를 윈도에서 돌도록 옮겼다

옮기면서 바꾼 것은 셋이다. 실행 명령을 python3 에서 python 으로 바꿨다 — 윈도의 python3 는 마이크로소프트 스토어로 보내는 바로가기라서 스크립트가 아예 안 돈다. 필요한 도구는 자동으로 깔지 않고 winget 설치 명령을 보여 주기만 한다 — 자동 설치는 관리자 권한 창을 예고 없이 띄운다. 그리고 답을 채팅에만 남기지 않고 HTML 보고서로 저장해 영상 분석 색인에 등록하는 단계를 더했다. 게임 설계서를 뽑는 일은 /watch 위에 얹은 별도 스킬이 맡는다.

만들기 ① — 스킬은 설명서 한 장과 스크립트 여섯 개다

폴더 하나(~/.claude/skills/watch/)에 아래가 들어간다.

파일	역할
`SKILL.md`	AI가 읽는 설명서. 맨 위 `description` 한 문장이 «언제 이 스킬을 부를지»를 정한다 — AI는 그 문장을 보고 스킬을 고른다
`scripts/setup.py`	준비물 점검. 도구 셋과 받아쓰기 키가 있는지 본다
`scripts/watch.py`	입구. 나머지를 순서대로 부르고 결과를 한 번에 출력한다
`scripts/download.py`	yt-dlp 로 영상과 자막을 받는다
`scripts/frames.py`	ffmpeg 로 사진을 뽑는다
`scripts/transcribe.py` · `whisper.py`	자막을 정리하고, 없으면 받아쓰기를 요청한다

점검은 매번 돌지만 다 갖춰져 있으면 아무것도 출력하지 않는다. 매번 「준비 완료」를 말하면 그게 소음이 된다. 뭔가 빠졌을 때만 종료 코드로 알린다 — 2는 도구 없음, 3은 받아쓰기 키 없음, 4는 둘 다. 키는 ~/.config/watch/.env 파일에 GROQ_API_KEY= 나 OPENAI_API_KEY= 한 줄로 넣는다.

만들기 ② — 사진 수는 영상 길이로 먼저 정한다

길이부터 잰다(ffprobe). 그다음 «몇 장 뽑을지»를 정한다. 장수를 먼저 못 박지 않으면 긴 영상에서 사진이 끝없이 늘고, 비용도 같이 는다.

영상 길이 (전체를 볼 때)	뽑는 사진
30초 이하	12~30장 (대략 1초에 1장)
1분 이하	40장
3분 이하	60장
10분 이하	80장
그보다 길면	100장 — 이게 상한이다. `--max-frames` 로 낮출 수는 있어도 더 올릴 수는 없다

어느 경우든 1초에 2장을 넘지 않는다. 폭 512픽셀이 기본이고, 화면 속 작은 글자를 읽어야 할 때만 1024로 올린다. 시작·끝 시각(--start · --end)을 주면 그 구간 안에서 더 촘촘한 표를 쓴다. 비용이 어디서 나오는지는 프레임 예산 편에 따로 적었다.

만들기 ③ — 어디서 뽑을지는 «마지막으로 찍은 사진 이후 얼마나 달라졌나»로 정한다

처음엔 장수를 길이로 나눠 일정한 간격으로 뽑았다. 그러면 멈춘 슬라이드에도 싸우는 장면과 같은 수를 쓰고, 순간적인 동작은 두 장 사이로 빠진다. 지금은 영상을 두 번 읽는다.

요약하기. 0.5초마다 한 장씩, 화면을 가로 32칸·세로 18칸으로 나눠 칸마다 평균 밝기만 남긴다. 한 장이 숫자 576개가 된다. 줄이는 계산은 ffmpeg 가 하고 파이썬은 숫자만 다룬다 — fps=2:round=up,…,scale=32:18:flags=area,format=gray. 같은 읽기에서 ffmpeg 장면 점수도 함께 받는다. 장면이 통째로 바뀐 곳(컷)을 찾는 데만 쓴다.
고르기. 앞에서부터 걸어가며, 마지막으로 찍은 사진과 비교해 확실히 달라진 칸이 K개 이상이면 찍는다. 「확실히」는 밝기 3단계 이상, 그리고 그 칸이 평소 2초 사이에 흔들리는 폭의 3배 이상이다. 그래서 늘 움직이는 웹캠 구석은 크게 바뀔 때만 센다. K는 예산의 ¾에 맞는 가장 작은 값을 자동으로 찾는다. 컷(장면 점수 0.3 이상)은 반드시 넣고, 사진 사이엔 평균 간격의 ¼ 이상을 둔다.
빈틈 채우기. 남겨 둔 예산 ¼은 가장 긴 빈틈의 가운데에 하나씩 넣는다. 멈춘 구간도 0장이 되지 않게 하려는 것이다.
뽑기. 고른 번호만 같은 필터로 다시 읽어 512픽셀 JPEG로 쓴다 — select='eq(n\,12)+eq(n\,57)+…'. 컷에서 뽑힌 장에는 목록에 scene cut 이 붙는다.

⚠ ffmpeg 장면 점수로는 «얼마나 바뀌었나»를 잴 수 없다 — 바뀌는 속도가 일정하면 0이 된다. 계산식이 「이번 변화」와 「이번 변화 − 직전 변화」 중 작은 쪽이라서다. 컷처럼 갑자기 바뀌는 것만 크게 나온다. 정답을 아는 시험 영상(멈춤·글자 입력·느린 이동·빠른 움직임을 이어 붙인 70초)으로 재 보니 이랬다.

구간	장면 점수	실제 화소 차이 (0.5초 사이)
멈춤	0.000	0.002
글자 입력	0.000	0.023
느린 이동	0.012	25.5
빠른 움직임	0.004	16.8

이 페이지의 첫 판(같은 날)은 이 점수에 비례해 사진을 나눴고, 그래서 글자 입력을 멈춘 화면과 똑같이 대했다(초당 0.80장 대 0.73장). 지금은 이 점수를 컷 찾기에만 쓴다.

⚠ 화면 전체로 재도 안 된다. 글자 몇 자는 화면 전체 평균에 묻힌다 — 해상도를 네 배로 올려도 글자 입력 신호는 0.023 그대로였고 잡음만 커졌다. 그리고 실제 강의 영상에는 「멈춘 화면」이 거의 없다. 오른쪽 아래 웹캠 얼굴이 말하는 내내 움직이기 때문이다. 그래서 칸으로 나누고, 칸마다 평소 흔들림을 따로 잰다.

⚠ 직전 장이 아니라 «마지막으로 찍은 사진»과 비교한다. 조금씩 쌓이는 변화는 0.5초 전과 비교하면 매번 작지만, 마지막 사진과 비교하면 쌓여서 커진다. 한 칸이 0.5초에 1단계씩만(문턱 3단계 아래) 밝아지는 시험에서도 쌓인 만큼 찍혔다.

5개 영상으로 값을 고르고, 고르는 데 쓰지 않은 3개로 확인했다. 잣대는 「매 순간의 화면이 마지막으로 찍힌 사진과 얼마나 다른가」의 평균, 즉 놓친 변화다. 낮을수록 영상을 잘 따라간 것이다. 바뀐 칸 수와 화소 차이 두 가지로 쟀다.

영상	바뀐 칸 놓침 (첫 판 → 지금)	화소 놓침 (첫 판 → 지금)
웹캠 화면 녹화 강의 16분	17.1 → 14.7	2.89 → 2.66
편집 영상 9분 (컷 45 → 53)	76.9 → 64.6	56.0 → 35.0
게임 쇼츠 24초	7.2 → 4.2	2.83 → 1.92
게임 플레이 녹화 60초	22.1 → 19.9	8.38 → 7.91
발표 32분 (확인용)	15.6 → 10.5	5.43 → 3.47
AI 강의 7분 (확인용)	18.7 → 17.8	4.05 → 3.47
한영 발표 19분 (확인용)	33.3 → 32.7	7.75 → 7.01

실제 영상 7개 모두 두 잣대가 다 좋아졌다. 글자 입력만 있는 시험 영상에서는 두 사진 사이에 쓰인 보이는 글자가 최대 5자 → 2자로 줄었다. 대가는 둘이다. 가장 긴 빈틈이 평균 간격의 2.5배까지 벌어지고(첫 판 2.2배), 영상을 두 번 읽느라 고정 간격보다 시간이 약 두 배 든다. 분석을 못 하면 고정 간격으로 돌아가고, 보고서에 그렇게 적힌다. --fps 를 주면 일부러 고정 간격으로 간다.

만들기 ④ — 대본은 공짜 자막부터 찾고, 없을 때만 돈을 쓴다

자막 받기는 두 번에 나눈다. 먼저 영상은 받지 않고 정보만 읽어(--skip-download --write-info-json) 그 영상이 무슨 언어로 말하는지(language)와 어떤 자막 트랙이 있는지 본다. 그 언어로 된 트랙을 하나 고른다 — 사람이 단 자막이 먼저, 없으면 원래 음성을 받아 적은 자동 자막(ko-orig 처럼 -orig 가 붙은 것), 그다음 그 언어의 다른 트랙. 그리고 영상과 그 트랙 하나만 받는다(--sub-langs "-all,^ko\-orig$" 꼴). 형식은 VTT(시각과 글이 번갈아 적힌 텍스트 파일)로 통일한다.
⚠ -orig 가 여럿일 수 있다. 유튜브가 자동 더빙을 붙인 영상은 더빙 언어마다 -orig 트랙이 따로 생긴다. 실제로 한국어 영상 하나에 en-US-orig·id-orig·ko-orig 셋이 있었다. 「-orig 아무거나」로 고르면 알파벳 순으로 영어 더빙 받아쓰기가 걸린다. 그래서 언어는 트랙 이름이 아니라 영상 정보의 language 에서 읽는다.
겹친 줄 합치기. 자동 자막은 한 문장이 여러 줄에 걸쳐 굴러가듯 반복된다. 바로 앞 줄과 같은 줄은 합치고 시각 범위만 늘린다.
자막이 없거나 내 컴퓨터의 파일이면 소리만 떼어 낸다(ffmpeg -vn -ac 1 -ar 16000 -b:a 64k — 한 채널·16kHz, 1분에 약 0.5MB). 그걸 Groq 의 whisper-large-v3(기본 — 싸고 빠르다) 또는 OpenAI 의 whisper-1 로 보낸다. 한 번에 올릴 수 있는 크기는 25MB다.
둘 다 안 되면 사진만으로 가고, 대본이 없다는 사실을 결과 머리말에 적는다.

만들기 ⑤ — 스크립트가 돌려주는 건 사진 경로 목록이고, 보는 건 AI다

입구 스크립트는 머리말(제목·길이·대본 출처가 captions 인지 whisper 인지)과 대본, 그리고 사진 경로 목록을 t=MM:SS 시각과 함께 찍는다. 여기까지는 그림을 아무도 안 봤다.

그래서 설명서에 «목록의 사진을 한 메시지에서 전부 열어 보라»고 적는다. AI의 파일 읽기 도구는 JPEG를 그림으로 보여 주고, 여기서 처음으로 AI가 영상을 «본다». 그다음 순서도 설명서에 적는다 — 질문이 있으면 시각을 들어 답하고, HTML 보고서를 쓰고, 다 끝나면 영상·사진·소리가 든 작업 폴더를 지운다. 남기는 건 보고서뿐이다.

실패할 때의 행동도 설명서 몫이다. 로그인이 필요하거나 지역이 막힌 영상이면 다시 시도하지 않고 그대로 말한다. 이유는 경계와 실패 편에 있다.

만들기 ⑥ — 요약을 설계서로 바꾸는 건 코드가 아니라 질문지다

YouTube Summary 가 품질을 올린 방법은 «종류별 질문지»였다. 요리 영상에는 재료와 순서를 묻고, 리뷰에는 장단점과 결론을 묻는다. 같은 원리가 /watch 에도 그대로 선다 — 무엇이 돌아오느냐는 스크립트가 아니라 무엇을 묻느냐가 정한다.

게임 설계서를 뽑는 스킬은 기법마다 다섯 칸을 채우게 한다. 이름, 무엇인가, 근거가 된 시각, 구현 방법, 그리고 신뢰도다. 신뢰도는 셋 중 하나다 — 영상에서 확인함 / 숫자가 안 나와서 통상값으로 추정함 / 영상 밖에서 가져온 참고. 이 칸들이 지키는 규칙은 하나다. 영상에 없는 것을 있는 척 넣지 않는다.

만들 때 걸리는 함정 — 일곱, 그중 둘은 에러 없이 틀린다

증상	원인과 처방
⚠ 천천히·꾸준히 바뀌는 화면이 멈춘 화면 취급을 받는다 (에러 없음)	ffmpeg 장면 점수를 «변화량»으로 썼기 때문이다. 이 점수는 바뀌는 속도가 일정하면 0이 된다(만들기 ③의 표 — 글자 입력 0.000). 컷 찾기에만 쓰고, 변화는 칸별 밝기를 마지막 사진과 비교해 잰다
⚠ 사진에 붙은 시각보다 화면이 늦다 (에러 없음)	ffmpeg `fps` 필터는 기본값에서 칸마다 마지막 프레임을 쓴다. 9.4분 영상에서 모든 사진이 이름표보다 정확히 3.5초(반 칸) 늦은 화면이었다. `fps=…:round=up` 이면 이름표 시각의 화면이 나온다 — 같은 시각을 따로 한 장 뽑아 비교해(PSNR) 완전히 같은 것을 확인했다
⚠ 정보를 먼저 읽고 그 정보로 영상을 받으면 가끔 403	`--load-info-json` 으로 재사용한 유튜브 영상 주소가 3번 중 2번 막혔다. 두 번째 받기는 URL 로 다시 한다 — 몇 초 더 들고 매번 됐다
`python3` 로 부르면 아무 일도 안 일어난다	윈도의 `python3` 는 스토어 바로가기다. `python` 으로 부른다
방금 깐 ffmpeg·yt-dlp 를 못 찾는다	`winget` 으로 깐 직후 같은 창은 PATH 가 아직 옛것이다. 터미널을 다시 열거나 설치 경로를 앞에 붙인다
yt-dlp 가 JS 런타임 경고를 낸다	deno 가 없어서다. 경고일 뿐 동작은 한다
영상은 받았는데 yt-dlp 가 실패 코드를 낸다	자막 하나가 막혀도(429) 0이 아닌 코드로 끝날 수 있다. 종료 코드가 아니라 영상 파일이 생겼는지로 판정한다

고친 것과 못 한 것 — 큰 움직임과 느린 변화가 한 영상에 있으면 움직임이 이긴다

사진 간격이 고정이었다 — 2026-10-01 에 «마지막 사진 이후 달라진 정도» 기반으로 바꿨다(만들기 ③). 이 페이지도 한동안 「내용이 움직이는 속도에 맞춰 뽑는다」고 틀리게 적고 있었다. 코드(frames.py)를 열어 보니 고정 간격이었고, 문장을 고친 같은 날 실제로 그렇게 돌게 만들었다. 그 과정에서 고정 간격 사진의 시각이 반 칸씩 늦게 붙어 있던 것도 찾아 함께 고쳤다(함정 표). 그 전까지 /watch 가 답에 단 시각은 실제 화면보다 반 칸 앞서 있었다 — 10분 영상이면 3초 남짓.
천천히 바뀌는 화면이 멈춘 화면 취급을 받았다 — 같은 날 다시 고쳤다. 이 페이지는 처음에 원인을 「0.5초 사이 변화가 작아서」로 짐작했다. 재 보니 진짜 원인은 장면 점수의 계산식이었고, 꾸준히 빠르게 움직이는 화면까지 같이 놓치고 있었다. 짐작과 원인이 달랐다.
큰 움직임이 함께 있으면 느린 변화가 밀린다. 질감 있는 화면이 15초 동안 흐르는 구간과 글자 입력이 한 영상에 있으면, 흐르는 쪽이 0.5초마다 「크게 바뀜」이 되어 예산을 먼저 가져간다. 그 시험 영상에서는 두 사진 사이 놓친 글자가 4 → 6자로 오히려 늘었다. 「같은 내용이 밀려 지나감」과 「새 내용이 나옴」을 가르려면 화면이 얼마나 밀렸는지 계산하는 움직임 보정이 필요하고, 아직 안 했다. 사진 사이에 1초 바닥을 두는 방법도 시험했지만, 액션이 1초 안에 계속 바뀌는 게임 쇼츠에서 1.35배 나빠져 버렸다.
기준값(밝기 3단계 · 평소 흔들림 3배 · 빈틈 몫 ¼ · 최소 간격 ¼)은 영상 5개로 고르고 3개로 확인했다. 빈틈 몫은 ⅕ · ¼ · 30% 셋 중에서 골랐는데, 이때는 확인용 영상의 빈틈 수치도 함께 봤다(30%는 확인용 하나에서 첫 판보다 나빠져 뺐다). 애니메이션처럼 다른 종류에서는 다시 재 봐야 한다.
거의 같은 사진을 따로 걸러 내지는 않는다. 「마지막 사진과 달라졌을 때」만 찍으니 대부분은 애초에 생기지 않는다. 다만 빈틈 채우기로 들어간 장은 앞 장과 거의 같을 수 있다. 멈춘 구간에도 최소한은 남기려는 선택이다.
자막을 영어 계열만 요청하고 있었다 — 2026-10-01 에 고쳤다. 한국어 영상을 넣으면 영어 더빙·번역 자막이 왔다(재현: 한국어 영상에서 「Okay, in the last video…」). 지금은 영상의 언어를 먼저 읽고 그 언어 트랙 하나만 받는다. 고친 뒤 같은 영상에서 한국어 대본(ko-orig)이, 영어 영상에서는 전처럼 사람이 단 en-US 자막이 나오는 것을 확인했다. 받는 자막이 한 개로 줄어 자막 요청이 막히는(429) 일도 덜하다.
설명서와 코드의 숫자가 어긋나 있었다 — 2026-10-01 에 고쳤다. 설명서는 10분 넘는 영상에 100장이라 적었는데, 입구 스크립트의 기본 상한이 80장이라 실제로는 80장만 나왔다(11분 시험 영상으로 재현). 이 어긋남은 원본 레포에서 물려받은 것이었고, 원본도 나중에 기본 80을 걷어냈다. 그래서 같은 쪽 — 코드를 100으로 — 맞췄다. 바뀐 건 10분 넘는 영상 전체 보기와 1분 넘는 구간 지정, 둘뿐이다(80 → 100장). 10분 이하 영상을 통째로 볼 때는 그대로다.