요약

  • RFC 3016은 MPEG-4 오디오와 비디오를 RTP에 직접 매핑했지만, 가장 중요한 규칙은 실패 도메인을 다루었다. 여러 복구 가능한 단위를 묶으면 오버헤드가 절감되었지만, 한 패킷의 손실이 그 전부를 지울 수 있었다.
  • RTP 일련번호, 타임스탬프, 마커 비트는 전송 구조를 기술했다. 그것은 구성이 살아남았는지, 디코더가 미디어를 만들었는지, 시청자가 그것을 받았는지를 증명하지 않았다.

경보는 모순의 형태로 도착했다. 인코더는 오류를 보고하지 않았다. 협상된 프로필은 일치했다. RTP 일련번호는 증가했고, 타임스탬프는 그럴듯했으며, 마커 비트는 마지막 프래그먼트가 있어야 할 위치에 나타났다. 그러나 영상은 한 데이터그램의 손실로 정당화되기에 너무 긴 시간 동안 멈춰 있었다.

문제는 코덱 안에 숨어 있지 않았다. 그것은 한 계층 앞서, 패킷izer가 여러 논리적 비디오 패킷을 하나의 네트워크 패킷 안에 넣기로 결정한 시점에 정해졌다. 네트워크는 하나의 단위를 잃었다. 애플리케이션은 여러 단위를 잃었다.

2000년 11월에 발표된 RFC 3016은 보통 그 제목으로 설명된다:RTP Payload Format for MPEG-4 Audio/Visual Streams. 이 문서는 MPEG-4 Systems의 동기화 및 스트림 관리 기능을 사용하지 않고 MPEG-4 오디오와 MPEG-4 비디오를 전송하는 방법을 구현체에 알려주었다. H.323은 H.245를 사용할 수 있었고, SIP와 RTSP는 MIME과 SDP를 사용할 수 있었다. 그렇게 하면 엘리멘터리 스트림은 RTP의 공통 메커니즘을 통해 비 MPEG-4 코덱과 나란히 이동할 수 있었다.

그러한 아키텍처적 단순화는 책임을 제거한 것이 아니라 이전시켰다. 코덱 문법, 세션 기술, 패킷 경계, 수신기 메모리는 별개의 관할 도메인이 되었다. 패킷izer는 네트워크 손실이 어디에 떨어질지를 결정해야 했다.

패킷 경계는 실패 경계였다

MPEG-4 비디오에는 이미 오류 복원력 도구가 있었다. 따라서 RFC 3016은 일부 초기 비디오 페이로드 형식이 사용한 미디어 전용 RTP 헤더를 추가하지 않았다. 비트스트림을 바이트 정렬 상태로 직접 매핑하고 문법 요소를 그대로 유지했다.

직접 매핑이 임의라는 뜻은 아니었다. 구성과 Group-of-VideoObjectPlane 자료는 RTP 페이로드의 시작에 오거나 문법적으로 더 높은 헤더를 따라야 했다. 헤더가 존재하는 경우 페이로드는 가장 높은 헤더로 시작해야 했다. 헤더는 RTP 패킷 사이에서 분할될 수 없었다.

이 규칙들은 미적 정돈이 아니라 복구에 관한 것이었다. 수신기는 잘 배치된 시작 코드를 만나면 랜덤 액세스 지점을 찾거나 코덱이 정의한 경계에서 재개할 수 있었다. 두 데이터그램에 걸쳐 분할된 헤더는 양쪽의 인질이 되었다. 어느 쪽 패킷이든 잃으면 수신기는 여전히 도착하는 바이트를 해석하는 데 필요한 기술 정보를 잃을 수 있었다.

사양은 하나의 비디오 패킷을 하나의 RTP 패킷에 넣고 결과 크기를 Path MTU 이하로 유지할 것을 권고했다. 손실이 잦은 경로에서는 이 매핑 덕분에 VOP 헤더를 담은 패킷이 사라지더라도 다른 비디오 패킷이 자체 Header Extension Code를 통해 디코딩 가능성을 유지할 수 있었다. 네트워크의 손실 단위와 코덱의 손상 단위가 거의 같은 크기로 유지되었다.

그러나 이 규칙은 의도적으로 절대적이지 않았다. 낮은 비트레이트에서는 작은 비디오 패킷 옆에서 RTP와 IP 헤더가 비용이 될 수 있었다. 오버헤드를 줄이기 위해 여러 패킷을 하나의 RTP 패킷에 연결할 수 있었다. 그 거래는 명시적이었다. 이제 하나의 RTP 손실이 그 안의 모든 비디오 패킷을 폐기한다.

이것은 “패킷 손실이 발생했다”보다 더 깊은 운영적 사실이다. 동일한 손실 카운터가 서로 다른 피해를 기술할 수 있다. 하나의 사라진 데이터그램은 독립적으로 복구 가능한 한 영역을 제거했을 수도, 경제성을 위해 묶인 여러 영역을 제거했을 수도, 이후 자료가 의존하는 헤더를 제거했을 수도 있다. 카운터는 전송 단위를 기록한다. 그 단위 내부의 의존성 그래프를 재구성하지는 않는다.

두 패킷이 서로 다른 위험을 가질 수 있었다

RFC 3016에는 이 문제를 우아하게 드러내는 금지된 배치가 포함되어 있었다. 두 개의 논리적 비디오 패킷은 두 개의 RTP 패킷에 여러 방식으로 분배될 수 있었다. 건전한 배치에서는 두 번째 RTP 패킷을 잃으면 두 번째 비디오 패킷만 잃는다. 잘못된 배치에서는 첫 번째 논리 패킷이 경계에 걸쳐 있고, 두 번째 패킷의 헤더가 그 잔여물 뒤에 놓인다. 이때 두 번째 RTP 패킷을 잃으면 둘 모두 파괴된다.

RTP 패킷 수는 동일했다. 바이트 수도 비슷할 수 있었다. 코덱 패밀리, 프로필, 클럭은 변하지 않았다. 배치만 달랐는데, 복구 결과는 달라졌다.

그래서 패킷화는 인코딩과 전송 사이의 사무적 단계가 아니다. 그것은 배분 결정이다. 패킷izer는 고립을 보존하기 위해 오버헤드를 반복 지불할지, 손실 단위를 확대해 그 비용을 상각할지를 결정한다. 수신기가 인식 가능한 헤더로 시작할 수 있는지, 살아남은 프래그먼트가 독립적 해석을 가지는지도 결정한다.

동일한 논리가 임의 분할에도 적용되었다. 코더가 비디오 패킷을 비활성화한 경우, VOP는 임의의 바이트 위치에서 분할될 수 있었다. 오류가 없다고 가정되는 경로에서 고정 크기 청크는 견딜 만할 수 있다. 그러나 오류가 잦은 경로에서는 RFC가 그 결과가 손실 복원력이 떨어진다고 경고했다. 스트림은 표준에 부합했고, 배포 가정이 취약한 부분이었다.

마커는 성공이 아니라 구조를 표시했다

MPEG-4 비디오에서 RFC 3016은 RTP 마커 비트를 VOP의 마지막 또는 유일한 패킷에 할당했다. 여러 VOP가 하나의 패킷을 공유할 때도 마커가 설정되었다. RTP 타임스탬프는 그 페이로드에서 가장 이른 VOP를 기술하며, 이후 VOP의 타이밍은 각자의 헤더에서 왔다.

이것은 디패킷화를 안내하기에 충분했다. 그러나 배달 확인증은 아니었다. 송신자는 패킷이 드롭되기 전에 마커를 완벽하게 설정할 수 있었다. 수신기는 이른 프래그먼트가 사라진 뒤에 마커를 관찰할 수 있었다. 디패킷izer는 디코더가 이후 거부할 단위를 닫을 수 있었다. 디코더가 성공하더라도 표시 과정은 멈추거나 무음일 수 있었다.

RTP 자체가 이 구분을 유지한다. 일련번호는 갭을 드러내고 전송 순서 복원을 돕는다. 타임스탬프는 샘플링 시점을 나타내며 동기화와 지터 계산을 지원한다. 실제 표시는 나중에 수신기에서 일어난다. 마커의 의미는 페이로드 프로필에서 온다. 그것은 보편적인 “프레임이 동작했다” 비트가 아니다.

그 필드들을 녹색 미디어 상태 표시등으로 승격시키는 운영 시스템은 추가적인 계약을 발명하는 것이다.

오디오는 사라질 수 있는 지도를 실었다

오디오 측은 LATM, 즉 Low-overhead MPEG-4 Audio Transport Multiplex를 사용했다. 완전한audioMuxElement또는 그 프래그먼트가 RTP 페이로드에 직접 들어갔다. 첫 바이트는 페이로드의 첫 위치에서 시작했다. RTP 패킷당 하나의 엘리멘트가 권고되었고, 엘리멘트가 Path MTU를 초과할 때는 분할이 가능했다.

미묘한 실패는 구성 메모리였다. 인밴드 모드에서useSameStreamMux는 수신기에게 이전 프레임의StreamMuxConfig를 재사용하라고 지시할 수 있었다. 이는 반복되는 구성 바이트를 절감했다. 그러나 이전 프레임이 잃어버렸다면 현재 프레임은 온전히 도착했음에도 디코딩 불가능할 수 있었다. 따라서 RFC 3016은 네트워크 상태에 따라StreamMuxConfig를 반복할 것을 권고했다.

사라진 패킷은 자신의 오디오만 없앤 것이 아니었다. 이후 오디오에 필요한 지도를 없앨 수 있었다. 반복은 그 의존성을 단축했고, 생략은 길게 했다. 아웃오브밴드 구성은 SDP의config매개변수 같은 시그널링으로 관할을 이전했지만, 수신기가 현재 스트림에 대해 올바른 값을 확보했음을 증명해야 할 필요를 없애지는 않았다.

원시 손실 카운트가 불완전한 또 하나의 이유가 여기 있다. 사라진 패킷은 일반 미디어, 재동기화 지점 또는 이후 일련의 패킷이 의존하는 구성을 실었을 수 있다.

능력은 구성이 아니었다

RFC 3016은video/MP4V-ES와audio/MP4A-LATM을 등록하고 그 매개변수를 SDP에 매핑했다. 비디오에서profile-level-id는 코덱 능력 조합을 기술할 수 있었다.config값은 해당 비트스트림의 구성을 기술하며, 명시적으로 능력 선언이 아니었다.

이 차이는 운영적으로 날카롭다. 디코더는 프로필과 레벨을 지원하면서도 정확한 현재 구성을 갖지 않을 수 있다. 두 피어는 호환되는 도구 집합을 광고하면서도 스트림 매개변수에 대해 불일치할 수 있다. 잘 형성된 SDP 기술은 진정하면서도 오래되었거나 잘못 라우팅되었거나 도착하는 바이트와 불일치할 수 있다.

세션 기술은 참여자에게 미디어가 어떻게 표현되고 어디로 가야 하는지를 알려준다. 그것은 경로를 감시하지 않고, 잃어버린 인밴드 구성을 보존하지 않고, 표시되는 화면을 인증하지 않는다.

복구 메커니즘은 경계 선택 이후에 시작되었다

RFC 3016은 복원력을 높이기 위해 범용 FEC와 중복 오디오를 허용했다. 그 메커니즘들은 중요하지만, 이후의 질문에 답한다. FEC는 패킷izer가 각 보호 패킷의 내용을 결정한 이후에만 패킷을 보호할 수 있다. 하나의 소스 패킷이 세 개의 논리적 복구 단위를 담는다면, 그 패킷을 복구하면 세 개를 모두 되찾고 복구에 실패하면 세 개를 모두 잃는다. 패킷화 결정이 판독액을 정했다.

이것이 이 역사를 RFC 2733과 구별한다. 그 표준은 패리티 패킷이 어떻게 사라진 RTP 미디어를 재구성할 수 있는지, 그리고 그 방식이 어떤 오버헤드와 지연을 부과하는지를 설명했다. RFC 3016은 상류의 선택을 드러냈다. 얼마나 많은 미디어와 구성이 하나의 손실 또는 하나의 FEC 방정식의 대상이 될 것인가.

마찬가지로 H.263+의 RTP 형식은 그림 헤더 정보를 추가 페이로드 헤더에 복사해, 원래 헤더가 잃어버린 뒤에도 수신기가 디코딩할 수 있도록 했다. RFC 3016은 MPEG-4 비디오 자체의 오류 복원력 문법에 의존하기로 선택했다. 코덱 도구가 다르면 패킷화 계약도 달랐다. 공통 RTP 헤더가 그것들을 서호환으로 만들지는 않았다.

역사적 사양은 이후 수정되었다

RFC 6416은 2011년에 RFC 3016을 폐기했다. 개정판은 특히 MPEG-4 오디오에 대해 3GPP 패킷 교환 스트리밍 서비스와의 불일치를 바로잡았다. RFC 3016이 참조한 것과 이진 호환이 불가능한 더 새로운 LATM 버전을 의무화하고, StreamMuxConfig를 개정했으며, SBR, 파라메트릭 스테레오, 레이트, 채널, 스케일러블 계층 시그널링을 명확히 했다.

그 수정은 RFC 번호를 시간을 초월한 디코더 신원으로 다루지 말라고 경고한다. RFC 3016으로 설명된 일부 구현체는 이미 더 새로운 LATM 형태를 사용했고, RFC 3016을 엄격히 충족하지 않으면서 RFC 6416에 부합할 수 있었다. 라벨은 이진 경계를 숨길 수 있었다.

그러나 이후 RFC도 비디오 교훈은 유지했다. RTP 패킷당 하나의 비디오 패킷은 손실 고립을 보호했다. 묶음은 더 큰 손실을 대가로 헤더를 절약했다. 문법적 배치가 살아남은 바이트가 의미할 수 있는 것을 바꾸었다.

암호화는 손실 단위를 줄이지 않았다

RFC 3016은 RTP 보안 고려사항을 물려받았고, 압축된 미디어가 충돌 없이 암호화될 수 있음을 언급했다. 제한된 페이로드는 오디오와 비디오를 실었으며, 완전한 MPEG-4 System에서 가능한 활성 MPEG-J 및 스크립트 콘텐츠는 실지 않았다.

기밀성, 무결성, 출처 인증은 중요한 질문을 보호한다. 모든 질문에 답하지는 않는다. 인증된 암호화 패킷도 Path MTU를 초과할 수 있고, 필요한 구성이 사라진 뒤에 도착할 수 있으며, 여러 복구 단위를 하나의 일련번호 뒤에 묶을 수 있다. 암호학은 누가 그 묶음을 보호했는지 증명한다. 그것은 묶음이 현명하게 크기 조정되었는지를 결정하지 않는다.

여기서의 인터넷 역사는 그 배분에 살아 있다. 페이로드 형식은 코덱의 단순한 포장지가 아니었다. 그것은 코덱 경계를 네트워크 실패 도메인으로 바꾸고, 헤더 절약을 독립적 복구와 균형 맞추며, 잃어버린 구성과 살아남은 미디어 사이의 의존성을 드러냈다. 코덱은 유효한 채 남을 수 있었다. 하나의 손실로 무엇을 파괴할 수 있는지를 선택한 것은 패킷izer였다.

출처