ScorePlayer 2

이 글은 ScorePlayer 시리즈의 3번째 기록입니다. (총 6개)

오늘 한 일

스택을 정하기 전에 실험부터 돌렸다. 악보는 그리지 않고 사각형과 원만으로 4K 화면을 만들어 ffmpeg에 파이프로 밀어 넣고, 프레임당 시간과 파일 크기를 쟀다.
- 이유: 여기서 막히면 어떤 언어를 골라도 똑같이 막힌다. 스택 비교보다 먼저 알아야 했다.
- 화면은 실제 악보와 비슷한 성김으로 만들었다(투명 배경 + 오선 두 단 + 음표 스물넷 + 재생선 + 볼). 꽉 찬 화면으로 재면 압축률 측정이 무의미해진다.
알파를 담을 수 있는 코덱 여섯 가지를 뽑아 Vegas에서 직접 열어 봤다.
추출 코덱을 ProRes 4444로 확정하고, 인코더 옵션을 조절해 네 배 빠르게 만들었다.
화질과 투명도가 유지되는지 두 가지 방법으로 검증했다 — 무손실 원본과의 수치 비교, 그리고 네 배 확대해 나란히 놓고 눈으로 비교.
측정 환경·수치·근거를 작업 문서에 남겼다. 나중에 “왜 이 코덱이었나”를 다시 묻지 않도록.

측정만 보면 QuickTime RLE이 압승이었다. 무손실인데 ProRes보다 2.6배 빠르고 4.4배 작았다.

코덱	실시간 대비	5분 곡 환산
4K QuickTime RLE	0.27x	18분, 1.5GB
4K ProRes 4444	0.10x	50분, 6.7GB

그런데 Vegas에 끌어다 놓으니 드롭 자체가 되지 않았다. 예전에 QuickTime 지원을 걷어낸 여파로 보인다. CineForm과 Hap Alpha도 같이 떨어졌다.

파일이 임시 폴더 깊숙이 있어서, 드롭이 안 되는 게 코덱 때문인지 경로나 프로그램 설정 때문인지 구분이 안 됐다.

해결: 알파가 없는 평범한 H.264 파일을 대조군으로 같이 넣어 한 폴더에 모았다. 그게 정상으로 들어가는 걸 확인하고 나서야 “코덱 문제”라고 말할 수 있었다.
확실히 되는 것을 하나 끼워 넣으면 원인이 절반으로 갈린다.

ProRes로 확정한 뒤 인코딩 옵션을 훑다가, 품질값을 명시하는 것과 안 하는 것의 차이가 이상하게 컸다.

4K 기본값(품질값 미지정)   166ms/프레임   0.10x 실시간   1.33GB/분
4K -qscale:v 9              43ms/프레임   0.39x 실시간   1.05GB/분

원인은 인코더의 비트레이트 맞추기였다. 품질값을 안 주면 슬라이스마다 목표 비트레이트에 맞는 양자화 값을 탐색하는데, 값을 고정하면 그 탐색이 통째로 사라진다. 게다가 결과 파일이 더 작아졌다 — 기본 목표 비트레이트가 이 성긴 화면에는 과했다는 뜻이다.

해결: -qscale:v 9로 고정. 5분 곡 기준 50분 걸리던 게 13분으로 줄었다.
화질은 무손실 대비 62.7dB이고, 네 배 확대해 비교했을 때 오선 가장자리·음표 원·반투명 재생선 모두 구분되지 않았다. 딱딱한 흰 선은 압축 번짐이 가장 잘 드러나는 그림인데도 깨끗했다.
알파 채널은 이 값에 영향받지 않는다. ProRes 4444는 알파를 따로 코딩해서, 어떤 설정에서도 투명 영역이 그대로 유지됐다.

ffmpeg에 Vulkan으로 도는 ProRes 인코더가 있길래 기대하고 붙였다. 처음에는 아예 실패했고(원본 프레임을 GPU로 올리는 필터가 필요했다), 배선을 고치고 나니 이번엔 CPU보다 느렸다.