라이브 재생목록의 창을 6초로 만들려던 요구가 당시 MediaMTX·gohlslib LL-HLS의 최소 조각 수와 충돌했습니다. 6초를 지키려면 라이브러리를 포크해야 할 수도 있었습니다. 저는 코드부터 바꾸기 전에, 목록이 14초를 담으면 시청도 14초 늦어지는지 요구의 의미를 다시 봤습니다.
결론은 7조각·GOP 2초의 약 14초 창을 허용하고 녹화 4초는 독립 유지하는 것이었습니다. 목록에 남길 범위와 실제 시청 지연, 저장할 파일 길이를 나누자 6초를 맞추기 위해 포크할 이유가 약해졌습니다. 조사·실측은 AI와 협업했고, 저는 요구를 정정해 기존 구현을 유지하는 방향을 확정했습니다.
14초 창은 14초 늦게 본다는 뜻이 아닙니다
재생목록 창은 플레이어가 현재 참고할 수 있는 과거 조각의 범위입니다. 라이브 가장자리에서 얼마나 뒤를 재생하는지는 hold-back, 파트, 플레이어 동작 등 다른 조건을 따릅니다. 목록에 14초 분량이 있다고 시청자가 반드시 14초 전 화면을 보는 것은 아닙니다.
HLS의 서버·플레이어 동작을 정의한 규격은 목록과 미디어의 해석을 다룹니다. 이 사례의 7조각은 당시 채택한 구현의 제약이며, 모든 HLS 구현에 동일한 수치를 요구하는 일반 규칙으로 쓰지 않습니다. 제품의 되감기도 별도 URL에서 제공하려 했으므로 짧은 라이브 창 하나로 되감기 요구까지 충족할 필요는 없었습니다.
| 값 | 의미 | 당시 선택 |
|---|---|---|
| 라이브 목록 창 | 목록에서 볼 수 있는 과거 조각 범위 | 7조각 × 실제 약 2초 ≈ 14초 |
| 실제 시청 지연 | 현재 송출과 재생 위치의 간격 | hold-back·플레이어 조건으로 별도 확인 |
| 녹화 길이 | 저장·편집용 파일의 작업 단위 | 약 4초 유지 |
이 세 값을 분리하면 라이브러리를 바꾸지 않고도 저장·편집용 4초 단위를 유지할 수 있었습니다. 반대로 최소 조각 수를 줄이는 포크는 상류를 업데이트할 때마다 검증할 차이를 남깁니다. 실제 시청 지연을 뜻하지 않는 6초 창 요구를 위해 그 비용을 맡을 근거는 부족했습니다. 선택 요약에 요구 정정과 포크 보류를 함께 남긴 이유입니다.
GOP 2초인데 최소 길이는 왜 1초인가
세그먼트는 설정값의 시계가 울린 순간에 무조건 잘리는 것이 아닙니다. 키프레임 경계에서 잘라야 하므로, 최소 길이와 키프레임 간격이 맞물립니다. 최소값을 정확히 2초로 두고 GOP도 2초로 두면, 키프레임이 한 tick 일찍 도착했을 때 최소 길이에 못 미칠 수 있습니다. 그러면 다음 키프레임까지 기다려 약 4초 조각이 생길 수 있습니다.
이 경계 때문에 최소 길이는 1초, 실제 키프레임은 2초로 분리했습니다. 설정 1초마다 자르려는 의도가 아니라 2초 키프레임이 최소 길이에 걸리지 않도록 여유를 주는 선택입니다. 설정값만 보고 약 14초 창이 유지된다고 결론낼 수 없어서, 다음 항목을 실제 결과의 확인 조건으로 남겼습니다.
| 확인할 값 | 확인 목적 |
|---|---|
| 실제 EXTINF가 약 2초인가 | 설정이 실제 조각 길이로 이어지는지 |
| 관측 중 TARGETDURATION이 2를 유지하는가 | 예기치 않은 긴 조각 발생 여부 |
| PART-HOLD-BACK과 당시 파트 실측의 관계 | 저지연 설정의 조건 정합성 |
| 녹화 파일의 약 4초 분할 | 라이브 변경이 저장 작업 단위를 바꾸지 않는지 |
위 항목은 2026년 8월 28일 결정의 확인 조건입니다. 이 사례에서 확정한 것은 창·GOP·최소 길이·녹화를 어떻게 나눠 설정할지이며, 서비스 시청 지연의 전후 실측값은 없습니다. 창이 약 14초라는 값에서 지연 개선율을 계산할 수 없는 이유도 같습니다.
포크하지 않는 결정에도 남겨야 할 작업이 있습니다
포크를 보류했다고 작업이 사라진 것은 아닙니다. 기존 문서의 6초 요구를 대체 표시하고 후속 구현이 낡은 파라미터를 따르지 않도록 정리해야 합니다. 설정, 키프레임, 목록 창, 녹화의 관계를 팀이 같은 의미로 읽을 수 있어야 합니다.
포크를 보류했어도 미디어 의존성의 동작과 버전 전제는 계속 확인해야 합니다. 이후 재현되는 공통 결함은 별도로 상류에 제안했습니다. 의존성·상류 기여 기록과 이 결정의 차이는 수정량이 아니라, 실제로 해결해야 하는 문제의 근거입니다.
여기서는 6초 창 요구를 고치면 라이브러리 차이를 유지하지 않아도 됐습니다. 동시에 녹화 4초 단위는 그대로 남겨 편집 경로에 불필요한 변경을 전파하지 않았습니다. 목록 길이와 시청 지연을 분리해 설명한 것이, 코드 변경보다 앞서 해결한 문제였습니다.
이 글은 PokeClip의 개발·검증 기록을 2026년 10월 15일 기준으로 정리한 CASE 29입니다. 전체 기술 기록에서 연결되는 결정을 함께 읽을 수 있습니다.