요약

  • RFC 3984는 H.264 화면 데이터를, 그 데이터를 디코딩 가능하게 만드는 시퀀스·화면 파라미터 셋과 분리했다. 슬라이스는 규칙을 실어 나르지 않고 규칙을 가리키는 이름만 지닐 수 있었다.
  • 운영상 위험은 구성 경합이었다. 셋이 누락되거나, 의존하는 미디어보다 늦게 도착하거나, 이전 패킷이 아직 전송 중일 때 덮어써지거나, 다른 쓰기 측이 같은 식별자를 쓰는 것과 충돌할 수 있었다.

패킷 캡처는 안심시키는 듯 보인다. RTP 시퀀스 번호는 연속적이고, 타임스탬프는 진행하고, 페이로드 바이트는 송신자가 보낸 것과 일치한다. 그런데도 수신기는 안정적인 화면을 만들어내지 못한다. 조사가 미디어 패킷의 도착 여부만 묻는다면, 한 계층 아래에서부터 시작한 셈이다.

RFC 3984는 2005년 2월 H.264 영상을 위한 RTP 페이로드 형식을 기술했다.상태 기록,정오표 기록,Datatracker 이력은 이후 RFC 6184로 대체되었음을 보여준다. 역사적 관심은 단순히 큰 NAL 단위를 분할하거나 작은 것들을 집계한 방식이 아니다. 화면 패킷이 전제하면서도 반드시 담고 있지는 않은 제어 상태에 있다.

H.264는 여러 슬라이스가 사용하는 정보를 파라미터 셋으로 옮겼다. 시퀀스 파라미터 셋은 코딩된 비디오 시퀀스의 속성을 기술하고, 화면 파라미터 셋은 코딩된 화면에 쓰이는 속성을 제공한다. 그 사이에는 화면 크기, 코딩 모드, 슬라이스 그룹 매핑 같은 사실들이 놓인다. 슬라이스 헤더는 관련 셋을 선택하는 식별자를 담는다. 반복을 줄여 주지만, 동시에 간접 참조를 만든다. 식별자는 참조일 뿐 참조되는 규칙 자체가 아니다.

따라서 디코더에는 자체적인 타임라인이 있다. 의존하는 NAL 단위가 디코딩 순서에 도달하기 전에, 필요한 파라미터 셋이 기대되는 식별자 아래에서 사용 가능해야 한다. RTP 기준으로 제시간에 도착한 패킷이 디코더 상태 기준으로는 너무 이를 수 있다. 패킷이 온전하더라도 그 이름이 가리키는 식별자에 새 의미가 부여되었을 수 있다. 전송 정확성과 해석 준비성은 별개의 주장이다.

이 경계는RFC 3550에서 드러난다. RTP 시퀀스 번호는 손실 감지와 패킷 순서 복원을 지원하고, 타임스탬프는 샘플링 시점을 표현해 재생 타이밍과 동기화를 돕는다.상태 페이지,정오표 페이지,Datatracker 기록은 어느 필드도 디코더 구성의 버전 번호로 만들지 않는다. RTP는 전송에 대해 많은 것을 알려 줄 수 있지만, 수신기의 슬롯에 어떤 SPS나 PPS가 놓여 있었는지는 말해 주지 않는다.

RFC 3984는 파라미터 셋 전송을 세 가지 원칙으로 조직했다. 원칙 A에서는 셋이 RTP 세션 전에 신뢰할 수 있는 대역외 경로로 이동한다. 원칙 B에서는 세션이 진행되는 동안 갱신된 셋이 신뢰할 수 있는 대역외 경로로 이동한다. 원칙 C에서는 셋이 미디어와 함께 대역내로 이동한다. 원문은 앞의 두 경우에 대해 신뢰 가능한 대역외 전송을 권고했고, 대역내 전송에는 반복, 재전송, 순방향 오류 정정 같은 방어가 필요했다. 파라미터 셋 하나를 잃으면 이후의 수많은 NAL 단위 해석이 훼손될 수 있기 때문이다.

초기 상태에 대해서는 미디어 타입 파라미터sprop-parameter-sets가 파라미터 셋 NAL 단위의 base64 표현을 전달할 수 있었다. 그 셋들은 디코딩 순서에서 이를 참조하는 NAL 단위들보다 먼저 와야 했다. 이 속성은 기능 선언이 아니었다. 스트림이 사용하리라 기대하는 상태를 기술하는 것이지, 수신기가 받아들일 수 있는 모든 구성을 증명하는 것이 아니었다. 이를 기능 목록처럼 다루면 수신기가 실제로 제공하지 않은 근거 위에서 스트림을 협상하게 될 수 있다.

대역외 전송은 미디어 문제를 세션 시그널링과 연결했다.RFC 4566은 SDP를 기술 형식으로 정의하며,상태,정오표,Datatracker 기록은 사양 이력을 보존한다.RFC 3264는 offer/answer 교환을 정의하고 한 번에 하나의 미결 offer만 허용한다.상태,정오표,Datatracker 기록도 참고하라. 직렬화는 변경을 조율하는 데 도움이 된다. 그러나 SDP를 디코더 설치의 보편적인 전달 확인증으로 만들지는 않는다.

RFC 3984의 실무 조언은 더 엄격했다. 갱신된 파라미터 셋이 신뢰할 수 있는 대역외 경로로 전송될 때, 송신자는 그 셋에 의존하는 NAL 단위를 보내기 전에 시그널링에 대한 확인 응답을 기다려야 한다는 것이었다. 순서가 중요한 이유는 확인 응답이 미디어 전환 이전에 경계를 만들기 때문이다. 그렇더라도 시그널링 체계가 말해 주는 것만큼만 증명한다. 운영 설계는 여전히 수신 확인이 언제 설치가 되고, 설치가 언제 활성 디코더 상태가 되는지를 정의해야 한다.

식별자 재사용은 경합을 더 위험하게 만들었다. 하나의 식별자를 가진 화면 파라미터 셋이 이전 화면 구성을 정의한다고 가정하자. 송신자가 그 식별자를 새 정의로 덮어쓰는 동안 이전 의존 NAL 단위들이 네트워크나 수신기 버퍼에 남아 있다. 그 오래된 슬라이스들은 여전히 같은 작은 참조를 담고 있지만, 디코더는 이제 그 참조를 다른 규칙 셋으로 해석한다. 어떤 패킷 체크섬도 실패할 필요가 없다. 손상은 의미론적이다.

그래서 사양은 충분히 오랜 기간 동안 사용되지 않은 식별자를 선택하거나, 활성 식별자를 덮어쓰는 대신 새 식별자를 추가할 것을 권고했다. 안전한 간격은 단순한 네트워크 왕복이 아니었다. 전송 중인 패킷, 재정렬, 지터 버퍼, 디코더의 보유 기간까지 포함한다. 다자간 세션에서는 소유권 문제가 커진다. 공통 컨트롤러가 이름 공간을 분할하거나 재작성하지 않으면, 그 외에는 잘 동작하는 두 소스가 같은 식별자를 고를 수 있다.

전송 경로를 섞는 것도 오래된 상태를 만든다. RFC 3984는 원칙 B와 C를 충분한 동기화 없이 한 세션에서 결합하지 말라고 했다. 늦게 참여한 수신기는 대역외 셋으로 시작하다가 대역내 갱신을 놓칠 수 있다. 갱신을 잃은 수신기는 이후 화면 패킷이 깨끗하게 도착하는 동안에도 이전 버전 기준으로 디코딩을 계속할 수 있다. 채널 간에 식별자를 분할하는 것은 방어책 하나다. 두 경로가 같은 슬롯에 조용히 다른 의미를 부여하는 것을 막기 때문이다.

이후 표준은 선호 메커니즘을 바꾸면서도 제어 문제 자체를 해소하지 않았다.RFC 6184와상태,정오표,Datatracker 이력은 대역내와 대역외 파라미터 셋 전송을 모두 허용하고in-band-parameter-sets같은 협상을 추가했다. 2005년의 일반적인 대역외 선호 권고를 현재의 교리로 앞서 투영해서는 안 된다. 남은 것은 방식을 선언하고, 구성을 의존 미디어와 조율해야 한다는 요구였다.

RFC 7798은 이후상태,정오표,Datatracker 기록과 함께 RTP를 통한 HEVC를 다뤘다. 비교 근거로 유용하다. 압축 영상 페이로드 형식은 그 효과가 많은 미디어 단위에 걸치는 상태를 반복적으로 마주한다. 그렇다고 모든 구현이 똑같이 동작했거나 이전 형식이 보편적으로 배치되었다는 근거는 아니다.

보안 시사점도 같은 비대칭을 따른다. 일반 화면 패킷 하나를 훼손하는 것은 유한한 영역을 손상시킬 수 있다. 그러나 파라미터 셋을 훼손하거나 주입하면 이후 수많은 NAL 단위의 해석 방식을 바꿀 수 있다. 그래서 RFC 3984는 무결성 보호와 출처 인증을 논의한다. 영향 범위는 패킷 크기가 아니라 상태에 속한다.

인시던트 대응에서는 '완전한 패킷 캡처'라도 구성 이야기를 담지 않으면 불완전하다. SDP 교환, 확인 응답, 대역내 파라미터 셋 NAL 단위, 식별자 배정, 페이로드 타입 전환, 수신기의 버퍼 범위를 보존하라. 각 SPS/PPS 버전이 언제 활성화되었는지, 식별자의 소유자가 누구였는지, 오래된 의존 슬라이스가 비워졌는지를 물어라. 결정적인 증거는 화면 패킷 자체에는 나타나지 않을 수 있다.

RFC 3984의 지속적인 교훈은 시스템 교훈이다. 내용과 내용을 해석하는 규칙은 서로 다른 채널로, 서로 다른 신뢰성 전제 아래, 서로 다른 시계로 이동할 수 있다. 패킷 안의 참조가 그 시계들을 접어 주지는 않는다. 안정적인 운영은 시스템이 구성 준비성을 미디어 도착의 낙관적인 부수 효과가 아니라 자체 상태 기계로 다루기 시작할 때 비로소 시작된다.

출처