요약

  • BMPEG는 비디오 슬라이스 전체, 오디오 프레임 전체, 90 kHz 픽처 클록, 부호 있는 Audio Offset을 하나의 RTP 스트림에 결합했다.
  • 이 계약은 패킷을 해석할 수 있게 해 줄 뿐, 바이트가 도착했는지, MPEG 상태가 유효했는지, A/V가 동기화된 채 출력됐는지, 시청자가 프로그램을 인지했는지는 단언하지 않는다.

객체는 근거보다 더 완전해 보였다

BMPEG 패킷은 축소된 프로그램처럼 보였다. 비디오가 앞쪽을 차지하고 오디오가 그 뒤를 따랐다. RTP 헤더는 시퀀스, 시각, 픽처의 끝을 제공했다. 전용 헤더는 픽처 타입, 비디오 헤더가 바뀌었는지, 패킷에 오디오 바이트가 얼마나 들어 있는지, 그 시작이 시간상 얼마나 떨어져 있는지를 선언했다.

이 설계는 1998년의 실제 비용을 겨냥했다. 온디맨드 비디오 세션은 프로그램마다 포트 하나를 쓸 수 있었다. 서버는 이미 저장된 자료를 인터리브 방식으로 분리하는 일을 피했고, 클라이언트는 두 개의 포트 경로 비용을 내지 않았으며, 결합 헤더는 오버헤드를 다소 줄였다. RFC의 예는 4 Mbps 콘텐츠 기준 약 1%의 절감을 계산했다.

공용 버퍼를 더 잘 크기 조정하고 프로그램 전체 대역폭을 제어하는 것도 가능했다. 명세는 그 결과로 생긴 동기화를 "암묵적"이라 불렀다. 암묵적인 것은 전송 계층 안에서의 결합이었고, 재생은 여전히 그 이후의 동작이었다.

묶음 처리는 위험의 배분을 바꿨다

RFC 2343은 Experimental이었고 인터넷 표준을 수립하지 않았다. 절감과 공동 조정이 더 중요할 때는 분리된 스트림의 모듈성 일부를 포기하는 선택을 제시했다.

포트 하나는 단순하지만 실패를 묶었다. 패킷 하나의 손실이 비디오와 오디오를 함께 가져갈 수 있었다. 매체를 독립적으로 선택하는 일이 더 어려워졌다. 커진 패킷은 path MTU를 넘어 분할될 수 있었다. 인코더의 변경은 수신기가 복구를 시도하는 바로 그 시점에 새로운 상태를 요구할 수 있었다.

BMPEG는 또한 RTP와 중복된다고 판단한 MPEG systems 계층의 정보를 제거했다. 필드를 제거한다고 기능이 사라지는 것은 아니었다. 그 기능은 packetizer, 수신기, 애플리케이션 사이의 계약으로 옮겨졌다. 두 구현이 같은 문법을 받아들이더라도 버퍼링, 은폐, 재동기화에 대해 서로 다른 결정을 내릴 수 있었다.

packetizer는 재시작 지점을 만들어야 했다

MPEG 헤더는 규율 있는 위치에 놓였다. Video_Sequence_Header가 나타난다면 페이로드의 시작을 맡았다. GOP_header는 거기서 시작하거나 앞 것을 따랐다. Picture_Header는 페이로드를 시작하거나 GOP를 따랐다. 각 패킷은 비디오 슬라이스 정수 개를 담았다.

이는 알려진 경계로 되돌아가는 데 필요한 작업을 줄였다. 다만 IP 단편화를 막지는 못했다. MTU를 넘지 않도록 슬라이스 크기와 패킷당 수량을 조정하는 것은 애플리케이션의 책임이었다. 패킷이 한도를 넘기면 하위 계층이 분할할 수 있고, integrated services 분류조차 복잡해질 수 있었다.

오디오는 프레임 단위로 비디오 세그먼트의 길이를 덮었다. 오디오 프레임 하나가 패킷의 비디오보다 더 긴 시간을 커버할 수 있으므로 이후 패킷에는 오디오가 없을 수 있었다. 마지막 프레임을 반복하는 것은 복원력을 위한 옵션이었다.

구조적 유효성은 조각이 빠졌는지, 반복된 소리가 부자연스러운지, 버퍼가 비기 전에 다음 오디오가 도착했는지를 답하지 않았다.

네트워크 순서, 디코딩 순서, 표시 순서

RTP 타임스탬프는 32비트, 90 kHz 클록을 사용했다. 픽처의 샘플링 시각을 나타냈고 해당 픽처의 모든 패킷에서 같았다. Marker는 픽처의 끝을 담은 패킷을 표시했다.

B 픽처는 순진한 해석을 깨뜨렸다. 디코딩을 위해 표시 순서와 다른 순서로 전송될 수 있었으므로 타임스탬프가 항상 증가할 필요는 없었다. 헤더만 담은 패킷은 다음 픽처의 시각을 따랐다. 시퀀스 번호는 여전히 전송 순서를 기술했다.

Audio Offset은 오디오 프레임 시작과 패킷 타임스탬프 사이의 차이를 부호 있는 샘플 수로 표현했다. 44.1 kHz에서 약 ±750 ms를 커버했다. RFC는 초당 1픽처 수준의 낮은 주기는 범위를 벗어날 수 있다고 경고했다.

오디오는 B 픽처와 함께 재배열되지 않았다. 전송 순서를 따랐고 오프셋으로 언제 들려야 하는지를 나타냈다. 따라서 올바른 오프셋은 좌표만 줄 뿐, 출력 클록으로의 변환, 장치 지연, 사람이 지각하는 동기화를 보증하지 않았다.

손상 위치 찾기는 정보 복구가 아니었다

sequence number와 타임스탬프의 조합으로 손실을 탐지할 수 있었다. slice number와 첫 매크로블록 위치는 손상 영역을 추정하는 데 도움이 되었다. 손실이 픽처 내부에 머물면 디코더는 계속 진행하며 이전 픽처의 픽셀을 반복할 수 있었다. 오디오는 간격을 숨기고 lip-sync를 유지하기 위해 배경 잡음이나 대체 프레임을 넣을 수 있었다.

그 결과는 재생 가능하면서도 원본이 아닐 수 있었다. 반복된 픽셀과 삽입된 소리는 concealment의 결정이지 잃어버린 자료의 재구성이 아니었다.

N 비트는 시퀀스, 확장, GOP 또는 픽처 헤더의 변경을 경고했다. 그 상태를 잃었다면 새로운 시작점까지 데이터를 버리는 편이 더 안전할 수 있었다. 심한 손실 후 수신기는 새 sequence header가 필요할 수 있었다.

BMPEG는 RFC 2250에서 보조 수단으로 쓰인 temporal reference에 해당하는 픽처 카운터를 포함하지 않았다. GOP_header 손실은 알아차리지 못한 채 이후 B 픽처의 잘못된 디코딩을 초래할 수 있었다. 패킷 수용은 그것을 해석하는 데 필요한 이력이 온전하다는 것을 증명하지 않았다.

소켓에서 시청자까지 여러 세계가 있었다

기한 내 도착, 조각의 재조립, 픽처 패킷의 무결성, 시퀀스·GOP·픽처 상태의 정확성, 디코딩, 출력 시각 계산, 렌더링, 화면과 스피커의 물리 경로, 그리고 시청자의 존재는 각각 따로 검증해야 했다.

RTP는 자원을 예약하지 않았고 서비스 품질을 보장하지 않았다. 유효한 패킷이 늦게 도착할 수 있었다. 픽처 하나가 완성되려면 앞서 잃어버린 헤더에 의존할 수 있었다. 디코더가 만든 프레임을 렌더러가 버릴 수 있었다. 비디오가 가려지거나 오디오가 음소거될 수 있었다. 켜진 화면조차 앞에 아무도 없을 수 있었다.

RFC 2343의 기여는 공동 패키징 언어를 정밀하게 정의한 것이었다. 그 정밀함이 패킷의 권위를 넓히지는 않았다. 정확히 어디서 끝나는지를 보여주었을 뿐이다.