TS / M2TS

여기 나온 다른 모든 컨테이너는 파일 전체를 갖고 있고 헤더부터 먼저 읽을 수 있다고 가정합니다. Transport Stream은 그 반대를 가정합니다 — 내가 도착하기 전부터 이미 시작됐고 내가 떠난 뒤에도 계속될 방송에 중간에 끼어든 상황을 전제로 합니다. 그래서 디코더에 필요한 모든 것 — 스트림 구조, 타이밍 참조, 각종 매개변수 — 을 매 순간마다, 영원히 반복해서 실어 나릅니다.

188바이트짜리 패킷도 같은 발상입니다. 간섭으로 패킷 하나가 망가지면 디코더는 몇 밀리초만 잃고 계속 진행합니다. 하나의 커다란 인덱스를 중심으로 만들어진 형식이라면 그 순간 파일의 나머지 전체를 잃었을 것입니다.

목적에 맞게는 정말 훌륭한 설계지만, 디스크에 놓인 파일로서는 어울리지 않는 모양입니다. 방송을 강인하게 만드는 모든 요소가, 녹화본으로서는 다루기 힘들게 만듭니다.

인덱스가 없으니, 47분 지점으로 가고 싶은 플레이어는 추정할 수밖에 없습니다 — 비트레이트에 시간을 곱해서 대략 그 지점으로 뛰어든 다음, 디코딩 가능한 다음 프레임을 찾아 헤맵니다. 고정 비트레이트 방송이라면 꽤 근접하게 맞아떨어집니다. 가변 비트레이트 녹화본이라면 몇 초씩 어긋날 수 있고, 중단된 스트림을 이어붙인 녹화본이라면 몇 분씩 어긋날 수도 있습니다.

재생 시간도 같은 이유로 문제가 됩니다. 플레이어는 파일 전체를 읽어서 길이를 알아내거나, 아니면 비트레이트로 대충 짐작해야 합니다. 녹화본이 가끔 잘못된 길이를 보여주거나 아예 안 보여주는 이유, 탐색 바가 허구에 가까운 이유가 여기 있습니다.

해결책은 재다중화입니다 — 스트림을 한 번 읽고, 같은 영상과 오디오를 진짜 인덱스를 갖춘 MP4나 MKV에 새로 씁니다. 아무것도 재인코딩되지 않고 화질도 그대로 유지되며, 디스크 속도로 끝납니다. 그 이후로는 탐색이 즉각적이고 정확해지는데, 파일이 마침내 자기 프레임들이 어디 있는지 알게 되었기 때문입니다.