대본

프레임이 비싼 만큼 대본은 싸다. 10분짜리 영상의 대본이 몇천 토큰이다. 그래서 가능하면 대본으로 채우고 프레임을 아낀다.

문제는 대본을 어디서 얻느냐다. 길이 둘이고, 둘의 성격이 완전히 다르다.

첫 번째 길 — 플랫폼 자막

먼저 원본 플랫폼의 자막을 시도한다. 공짜고, 시간축이 이미 붙어 있다.

시간축이 붙어 있다는 게 핵심이다. 프레임에는 각각 시각이 있으니까, 대본에도 시각이 있으면 둘을 맞춰 읽을 수 있다. “3분 12초 화면에서 이 말을 하고 있었다”가 성립하고, 그게 스펙을 뽑을 때 필요한 형태다.

자동 생성 자막이라도 충분하다. 단어가 몇 개 틀려도 시각이 맞으면 쓸 수 있고, 틀린 단어는 프레임이 고쳐 준다.

두 번째 길 — 직접 받아쓰기

자막이 없거나 로컬 파일이면 음성을 뽑아 받아쓰기 API로 보낸다.

여기서 나가는 건 영상이 아니라 오디오다. 화면은 어디에도 안 올라간다. 그리고 오디오도 원본이 아니라 모노 16kHz로 다시 인코딩한 것 — 분당 0.5MB 정도다. 사람 말을 알아듣는 데는 그 정도면 충분하고, 그 이상은 올릴 이유가 없다.

제공자는 키가 설정된 쪽을 쓴다. 한쪽이 실패하면 다른 쪽으로 강제할 수 있고, 아예 끄는 스위치도 있다. 받아쓰기를 끄면 프레임만으로 진행하고, 대본이 없다는 사실을 결과에 적는다.

없으면 없다고 말한다

자막도 없고 받아쓰기도 못 하면 프레임만으로 간다. 그리고 그 사실을 결과에 명시한다.

이게 규칙으로 있어야 하는 이유는, 대본 없는 결과물이 겉보기에는 멀쩡하기 때문이다. 프레임 80장으로도 그럴듯한 요약이 나온다. 그런데 발표자가 말로만 설명한 부분은 통째로 빠져 있고, 읽는 사람은 그걸 모른다.

“대본 없음”이라고 한 줄 적히면 읽는 쪽이 그 결과를 다르게 취급한다. 그 한 줄이 없으면 없다는 걸 아무도 모른다.

25MB 벽

받아쓰기 API에 업로드 상한이 있다. 아주 긴 영상은 오디오만으로도 그 상한을 넘는다.

모노 16kHz로 줄여 놓은 게 여기서도 값을 한다 — 분당 0.5MB면 50분까지는 한 번에 들어간다. 그보다 길면 애초에 구간을 지정해서 볼 영상이지, 통째로 받아쓸 영상이 아니다.

실패하면 에러를 그대로 보여준다. 상한 초과인지, 키가 틀렸는지, 호출 한도인지가 메시지에 나오고, 원인을 안 숨기는 게 재시도 판단에 필요하다.