소리꽃 KeyBloom 35
오늘 한 일
추출한 영상을 편집툴에 올렸더니 한 프레임이 튀었다. 원인을 좁히는 데까지 했고, 고치는 건 테스트 결과를 보고 한다.
- 영상 파일 자체는 멀쩡하다는 걸 확인했다 — 문제 프레임과 앞뒤를 한 장씩 뽑아 보고, 전체 3,258프레임의 변화량도 비교했다
- 같은 영상을 두 방식으로 다시 만들어 편집툴에서 비교했다 — 포장만 바꾼 것은 여전히 튀고, 다른 인코더로 다시 압축한 것은 멀쩡했다
- 하드웨어 인코더가 만든 파일에서 규격에 어긋나는 머리 정보를 찾았다
- 원인을 가를 테스트 파일 셋을 더 만들었다
막힌 부분
추출 영상이 편집툴에서 한 프레임만 깨진다
편집툴에서 239번째 프레임 한 장이 이상하게 나왔다. 건반처럼 가만히 있는 부분은 까맣게 사라지고, 새로 퍼진 물결과 막 눌린 건반만 보였다. 두 번 추출해도 같은 자리였다. 편집툴 화면의 프레임 번호는 371이었는데, 타임라인 앞에 빈 구간이 있어서 번호가 밀려 보인 것이었다.
먼저 우리가 그린 그림이 틀렸는지를 봤다. ffmpeg(영상을 읽고 변환하는 도구)로 238~241번 프레임을 뽑아 보니 전부 정상이었다. 영상 전체에서 앞뒤 프레임과 동떨어진 장면을 찾아봐도 없었다. 파일에 담긴 그림은 멀쩡하다.
깨지는 모양이 단서였다. 영상 압축은 몇 초마다 한 장을 통째로 저장하고(키프레임), 그 사이는 앞 프레임과 달라진 부분만 저장한다. 앱은 4초(240프레임)마다 키프레임을 넣으니 239는 경계 바로 앞이다. 달라진 부분만 담긴 프레임을 기준 프레임 없이 풀면 가만히 있던 건반은 빠지고 움직인 것만 남는다. 편집툴 디코더가 여기서 기준을 놓친 모양이다.
그래서 한 가지씩만 다른 파일 둘을 만들어 편집툴에 올렸다.
- A — 영상 데이터는 그대로 두고 MP4로 다시 포장만 한 것 → 튄다
- B — 다른 인코더(x264)로 다시 압축한 것 → 멀쩡하다
앱의 빠른 추출은 AMD 그래픽카드의 하드웨어 인코더를 쓴다. 그 출력을 편집툴이 제대로 못 읽는 것이다. 파일을 뜯어보니 파일 머리에 든 SPS(영상 전체 설정을 담은 머리 정보)와 첫 프레임 안에 든 SPS가 서로 달랐다. 머리 쪽 SPS는 규격 검사에서 값이 틀렸다고 걸리기까지 했다. ffmpeg는 이런 걸 너그럽게 넘겨서 멀쩡하게 풀지만 편집툴 디코더는 그렇지 않다.
B를 만든 x264를 앱에 넣는 길은 없다. 앱에 동봉한 ffmpeg는 라이선스 문제로 x264를 뺀 빌드다. 그래서 하드웨어 인코더를 그대로 쓰면서 편집툴이 읽을 수 있게 만드는 쪽으로 간다.
- 남은 것: 테스트 파일 셋(C는 멀쩡한 B를 앱과 같은 AMD 설정으로 다시 압축, D는 A의 데이터는 그대로 두고 머리 정보만 통일, E는 AMD 인코더에 B프레임 켜기)을 편집툴에서 확인한다. D가 멀쩡하면 추출 뒤 머리 정보를 정리하는 짧은 후처리를 붙이고(재압축이 아니라 화질 그대로), E가 멀쩡하면 인코더 설정에 B프레임을 켠다
다음에 할 일
- 추출 영상 프레임 깨짐 — 테스트 파일 C·D·E 결과를 보고 인코딩 수정. 4초 경계마다 튀는지도 확인
- 크로마키 출력 — 키 색과 파티클 색이 겹치는 문제부터. 무지개 모드는 모든 색조를 써서 어떤 키 색이든 겹치고, 발광은 반투명이라 경계가 물든다
- 9:16·1:1 비율 영상 추출
- 라이브 모드 영상 촬영 기획
- 분수·파동 등 상수 미세튜닝은 실기로 보며
- 다음 릴리스에 건반 입체감 포함 — main에만 있고 아직 안 나갔다