만든 도구진행 중

프레임 예산

비용은 거의 전부 프레임에 있고, 예산은 세 배 느는데 길이는 예순 배 늡니다.

100장 상한

비용이 거의 전부 «화면 캡처»에 있습니다. 그런데 예산은 세 배 느는데 영상 길이는 예순 배 늡니다.

비용 구조가 아주 단순합니다

무엇 비용
대본(말을 글로 옮긴 것) 10분짜리도 몇천 단위 — 사실상 공짜
화면 캡처 여기가 전부

숫자로 보면 이렇습니다. 캡처를 80장 뽑으면 5~8만 단위가 나갑니다. 대본의 열 배 이상입니다.

그리고 해상도를 두 배로 올리면 장당 비용이 대략 네 배가 됩니다.

그래서 상한을 걸었습니다

총 100장, 초당 2장까지. 그 안에서 영상 길이에 따라 나눠 씁니다.

여기가 문제입니다 — 「예산은 세 배, 길이는 예순 배」

상한이 왜 어려운 문제인지 여기서 나옵니다.

1분 영상 60분 영상
길이 1배 60배
쓸 수 있는 캡처 조금 100장 (상한)

길이는 예순 배가 되는데 예산은 안 늡니다. 그러면 긴 영상일수록 점점 성기게 봅니다. 60분을 100장으로 보면 36초에 한 장입니다.

36초에 한 장이면 대부분을 못 봅니다.

「대본만 있으면 되지 않나」 — 저도 처음에 그랬습니다

대본은 싸고 캡처는 비쌉니다. 그러면 대본만 쓰면 되지 않나 싶습니다.

안 됩니다. 이유가 있습니다.

발표자가 화면을 가리키며 「여기 이 값을 보시면」이라고 말합니다. 대본에는 그 문장만 남습니다. 「여기」가 어디인지, 「이 값」이 뭔지는 안 남습니다.

그리고 게임 영상은 더 심합니다. 말은 거의 안 하고 화면만 움직입니다. 대본이 텅 비어 있습니다.

대본은 「말한 것」만 담고, 화면은 「보여 준 것」을 담습니다. 만들려면 뒤쪽이 필요합니다.

그래서 긴 영상은 「잘라서」 봅니다

이게 이 도구의 답입니다.

60분을 성기게 훑는 것보다, 필요한 구간을 촘촘히 보는 게 거의 항상 낫습니다.

구간을 지정하면 그 안에서 예산을 다 씁니다.

방식 결과
60분 전체를 100장으로 36초에 한 장 — 거의 못 봄
2분 15초~2분 45초만 지정 60장이 그 30초에(초당 2장 — 이게 상한) — 거의 모든 동작이 잡힘

사진 수는 오히려 적은데 어디에 쓰느냐로 결과가 완전히 달라집니다.

그리고 대개 제가 보고 싶은 건 전체가 아니라 한 장면입니다. 「저 연출 어떻게 한 거지」 같은 것이요.

같은 영상을 두 번 안 봅니다

같은 대화 안에서 후속 질문이 오면 다시 안 돌립니다.

캡처와 대본이 이미 눈앞에 있는데 또 뽑는 건 같은 비용을 두 번 내는 것입니다.

이게 안 되어 있으면 「아까 그 장면 다시 봐 줘」 한 마디에 전체 비용이 다시 나갑니다.

해상도는 안 올립니다

기본이 낮은 해상도입니다. 두 배로 올리면 장당 비용이 네 배가 되어, 80장이 20~30만 단위가 됩니다.

그리고 대개 해상도를 올려서 얻는 것보다 장수를 늘려서 얻는 게 큽니다. 흐릿해도 동작의 순서는 보이는데, 장수가 적으면 동작 자체를 못 봅니다.

프레임 예산 — 거의 안 는다 실효 프레임률 — 무너진다 30초 30장 1.0 1분 40장 0.67 3분 60장 0.33 10분 80장 0.13 30분 100장 0.06
왼쪽은 예산, 오른쪽은 그 예산으로 실제 몇 초에 한 장을 보게 되는지. 왼쪽이 세 배 느는 동안 오른쪽은 17분의 1이 된다.

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

이 도구의 비용 구조는 단순하다. 대본은 10분짜리라도 몇천 토큰이면 끝난다. 프레임이 전부다 — 512px 폭으로 80장이면 5~8만 토큰이고, 해상도를 1024로 올리면 장당 비용이 대략 네 배가 된다.

그래서 상한을 걸었다. 총 100장, 초당 2장. 그 안에서 길이에 따라 예산을 배분한다.

여기서 문제가 보인다. 예산은 30장에서 100장으로 세 배 남짓 느는데, 길이는 60배가 는다. 그래서 30분짜리를 통째로 넘기면 18초에 한 장을 보는 셈이 된다. 그 사이에 일어난 건 전부 대본으로만 아는 것이다.

대본이 있어도 프레임이 필요하다

“대본만 있으면 되지 않나”는 처음에 나도 했던 생각이다. 대본은 싸고 프레임은 비싸니까.

안 된다. 말로 안 하고 지나가는 게 너무 많다. 화면 배치, 어떤 버튼이 어디 있는지, 그래프가 어느 방향으로 꺾이는지, 데모에서 실제로 뭐가 움직이는지 — 발표자는 “여기 보시면”이라고만 하고 넘어간다. 대본에는 “여기”라고만 남는다.

그리고 만들려고 보는 사람이 필요한 건 대개 그 “여기” 쪽이다. 그래서 비싼 걸 알면서도 프레임을 산다.

그래서 긴 영상은 잘라서 본다

긴 영상을 성기게 훑는 것보다 필요한 구간을 촘촘히 보는 게 거의 항상 낫다. 구간을 지정하면 그 안에서 예산을 다 쓴다 — 2:15부터 2:45까지 지정하면 60장이 그 30초에 들어간다. 초당 2장이 코드에 박힌 상한이라(--fps 로 더 달라고 해도 2로 깎인다) 30초 구간은 60장이 끝이다.

같은 60장인데 커버리지가 60배 차이 난다. 30분 전체에 뿌리면 30초에 한 장이고, 30초 구간에 몰면 초당 2장이다.

그래서 긴 영상을 받으면 먼저 어디를 볼지 묻는다. 구간을 안 정하고 태우는 토큰이 제일 아깝다. 그리고 10분이 넘어가면 경고를 찍는데, 그 경고를 그냥 넘기지 말고 답변에 같이 적게 해 뒀다 — 성기게 봤다는 사실 자체가 결과의 일부이기 때문이다.

같은 영상을 두 번 안 본다

같은 세션에서 후속 질문이 오면 다시 돌리지 않는다. 프레임과 대본이 이미 맥락에 있는데 또 뽑는 건 같은 비용을 두 번 내는 것이다.

이게 규칙으로 적혀 있어야 하는 이유가 있다. 도구를 부르는 쪽 입장에서는 “새 질문 = 새 실행”이 자연스럽게 느껴져서, 안 적어 두면 두 번째 질문에서 8만 토큰이 또 나간다.

해상도는 올리지 않는다

기본이 512px 폭이다. 1024로 올리면 장당 토큰이 대략 네 배가 되므로, 80장이 20~30만 토큰이 된다.

올릴 만한 경우는 하나뿐이다 — 화면의 작은 글자를 읽어야 할 때. 그때도 전체가 아니라 그 구간만 올린다. 전 구간 고해상도는 예산 설계 전체를 무의미하게 만든다.