DOI QR코드

DOI QR Code

An Overhead Comparison of MMT and MPEG-2 TS in Broadcast Services

방송 서비스에서 MMT와 MPEG-2 TS의 오버헤드 비교

  • Park, MinKyu (Department of Electrical and Computer Engineering, University of Seoul) ;
  • Kim, Yong Han (Department of Electrical and Computer Engineering, University of Seoul)
  • 박민규 (서울시립대학교 전자전기컴퓨터공학과) ;
  • 김용한 (서울시립대학교 전자전기컴퓨터공학과)
  • Received : 2016.05.04
  • Accepted : 2016.05.16
  • Published : 2016.05.30

Abstract

This paper compares the transport overhead of MMT (MPEG Media Transport) with that of MPEG-2 TS (Transport Stream). MPEG-2 TS is globally used in multiplexing compressed audio and video data in digital broadcast industry, including areas of DTV (Digital Television), IPTV (Internet Protocol Television), and DMB (Digital Multimedia Broadcasting). It was the early 1990s when MPEG-2 TS standard was established. After more than two decades of years since its first establishment, many parts of MPEG-2 TS turned out to be inappropriate to today's broadcast and communication environment. Given the situations, in 2014 MPEG (ISO/IEC JTC 1 SC 29/WG 11) standardized MMT as the next-generation multimedia transport standard hopefully that can replace MPEG-2 TS. In this paper, with assumptions of broadcast service scenarios we applied both MMT and MPEG-2 TS to each scenario and we calculated their transport overheads. We used a software program that counts the transport overhead, which was developed in our laboratory for this paper. And we conducted a comparative analysis based on the calculated result of transport overhead.

본 논문에서는 MMT(MPEG Media Transport)와 MPEG-2 TS(Transport Stream)의 전달 오버헤드(overhead)를 비교한다. MPEG-2 TS는 DTV(Digital Television), IPTV(Internet Protocol Television), DMB(Digital Multimedia Broadcasting) 등 디지털 방송 분야에서 압축된 오디오 및 비디오 데이터를 다중화하여 전송하기 위한 프로토콜로서 전 세계적으로 널리 사용되고 있다. MPEG-2 TS 표준은 1990년대 초에 제정되었으며, 그 후 20여 년이 지나면서 MPEG-2 TS의 많은 부분들이 오늘날의 방송과 통신 환경에 적합하지 않게 되었다. 이러한 상황에서, 2014년 MPEG(ISO/IEC JTC 1 SC 29/WG 11)에서는 MPEG-2 TS를 대체할 수 있는 차세대 멀티미디어 전달 표준으로서 MMT를 표준화하였다. 본 논문에서는 방송 서비스 시나리오를 가정하고, MMT와 MPEG-2 TS를 적용하여 그에 따른 전달 오버헤드를 계산하였다. 본 논문을 위해 연구실에서 제작한 전달 오버헤드 계산 소프트웨어를 사용하였으며, 계산 결과를 바탕으로 이 두 방식의 전달 오버헤드를 비교, 분석하였다.

Keywords

Ⅰ. 서 론

MPEG-2 TS(Transport Stream)는 MPEG-2 표준의 첫 번째 부(Part)[1]로서 압축된 비디오, 오디오, 부가 데이터, AV(Audio-Visual) 동기화 정보, 다중화 정보 등을 하나의 비트스트림(bitstream)으로 구성하여 전달하거나 저장하기 위해 MPEG(Moving Picture Experts Group)에서 표준화하였다. 처음 MPEG-2 TS 표준이 제정된 후 20여 년이 지나면서, 방송과 통신 환경이 많이 발전하였다. 특히 인터넷이 급속히 확산됨에 따라 IP(Internet Protocol) 기반의 서비스들이 대세가 되었고, 비디오 획득 기술, 압축 기술, 데이터 전송기술 등이 발전함에 따라, 근래에는 UHD(Ultra High Definition) 화질의 고전송률 멀티미디어 콘텐츠까지 제작되어 이를 방송하거나 스트리밍 서비스하기 위한 기술들이 등장하고 있다. 이에 따라 MPEG-2 TS는 188바이트의 비교적 짧은 패킷 크기를 사용하기 때문에 고전송률 멀티미디어 서비스에 대해서 점차 비효율적이 되고 있다. 이런 상황에서, MPEG에서는 2009년부터 새로운 AV 전달 포맷(format)에 대한 요구사항을 정리하였으며, 2014년에 공식 표준 번호 ISO/IEC 20008-1(MPEG-H Part 1: MPEG media transport, MMT)[2]로서 표준화하였다. MMT는 다양한 네트워크 환경이 IP 기반으로 발전함에 따라 IP 친화적으로 설계되었고, 방송 물리 채널이나 인터넷과 같은 다른 유형의 네트워크를 동시에 사용해서 멀티미디어 콘텐츠를 전달하는 것이 쉽도록 설계되었다. MMT에 대한 개괄적인 소개와 상기 장점들에 대한 분석에 대해서는 [3]~[5]를 참고하도록 한다.

MPEG-2 TS는 188바이트의 고정 길이 패킷을 사용하는 반면, MMT는 최대 MTU(Maximum Transmission Unit) 길이를 갖는 가변 길이의 MMTP(MMT Protocol) 패킷을 사용한다. 따라서 보통 MMTP의 패킷 크기는 MPEG-2 TS에 비해 훨씬 크지만 이로 인해 패킷 헤더로 인한 오버헤드 측면에서 MMT가 MPEG-2 TS에 비해 적다고 판단하는 것은 성급할 수 있다.

우선 MPEG-2 TS와 MMT는 전송 계위 상에서 차지하는 위치가 다르다. 즉 MPEG-2 TS에는 TS 패킷 내에 동기 바이트(sync byte)를 포함하고 있기 때문에 전달 계층의 기능뿐만 아니라 데이터 링크 계층의 기능인 프레이밍(framing) 기능까지 포함되어 있는 반면, MMT는 응용 계층에 가까운 전달 계층의 기능만을 지원하기 때문에 UDP/IP와 데이터 링크 계층을 하위 계층으로서 필요로 한다.

또한 MMT에는 MPEG-2 TS에 비해 훨씬 다양한 전달 계층의 기능이 포함되어 있기 때문에 이로 인해 전달 오버헤드가 증가한 부분이 존재한다. MMT는 인터넷과 같은 IP 기반의 통신망을 통한 멀티미디어 전달에 대한 요구사항도 함께 수용하여 설계되었기 때문에, 중간 네트워크 요소에서 전달 포맷과 저장 포맷 간의 변환이 효율적으로 달성될 수 있도록 하였다. 이를 위해 MMT에서는 MMTP 패킷에 미디어를 싣기 전에 ISOBMFF(ISO Base Media File Format)[6]를 사용하여 미디어를 캡슐화(encapsulation)하는 구조를 채택하였다. ISOBMFF는 기본적으로 파일 포맷이기 때문에 매우 다양한 메타데이터(metadata)를 포함할 수 있으며, 이로 인해 MMT에 의해 전달되는 미디어는 중간 네트워크 요소의 캐시(cache)에 그 분할된 미디어 조각들이 파일 형태로 임시로 저장될 수 있어, 이들을 식별하는 것이 매우 용이하다. 그러나 이러한 파일 포맷 구조는 많은 양의 메타데이터로 인해 전달 오버헤드를 증가시킬 수 있다.

따라서 전송 계위 상에서 차지하는 위치가 다르고, 패킷의 크기는 커졌지만, 파일 포맷 메타데이터로 인한 오버헤드도 커졌기 때문에, MMT가 MPEG-2 TS에 비해 전달 효율이 반드시 높다고 쉽게 단정하기는 어렵다. 이러한 점들은 이 두 표준 간의 오버헤드 비교를 어렵게 한다.

본 논문에서는 MPEG-2 TS와 MMTP 스트림의 전달 오버헤드 비교를 위해 기존의 방송 서비스에 MPEG-2 TS와 MMT를 적용하는 실험에 의해 이 두 방식의 오버헤드를 계산하였으며, 그 계산 결과를 바탕으로 가능한 한 공정하게 전달 오버헤드를 비교하였다. 이를 위해서, 지상파 HDTV 방송 신호를 수신하여 MPEG-2 TS를 녹화하였고, 녹화한 MPEG-2 TS로부터 압축된 비디오와 오디오 데이터를 추출하였다. 추출한 미디어 데이터로부터 녹화한 MPEG-2 TS와 동일한 서비스를 제공할 수 있는 MMTP 스트림을 제작하였다.

본 논문의 구성은 다음과 같다. 2장에서는 MMTP 스트림 제작 방법에 대해서 설명하고, 3장에서는 MPEG-2 TS의 전달 오버헤드 계산 방법과 그 결과에 대해서 설명한다. 4장에서는 제작한 MMTP 스트림에 대한 전달 오버헤드 계산 결과에 대해서 설명하고, 5장에서는 실제 방송 서비스에 상기 기본적인 전달 오버헤드 계산 결과를 적용하여 실제 전달 오버헤드를 비교한다. 마지막으로 6장에서 결론을 맺는다.

 

Ⅱ. MMTP 스트림 제작 방법

공정한 전달 오버헤드 비교를 위해서, 지상파 HDTV 방송 신호를 수신하여 이로부터 약 4분 28초 분량의 MPEG-2 TS를 녹화하였고, 그로부터 압축된 비디오와 오디오 ES (Elemantry Stream)와 같은 미디어 데이터를 추출하였다. 추출한 미디어 데이터로부터 녹화한 MPEG-2 TS와 동일한 서비스를 제공할 수 있는 MMTP 스트림을 제작하였으며, 이 역시 녹화된 MPEG-2 TS와 마찬가지로 약 4분 28초의 재생 시간을 갖도록 하였다. 녹화한 MPEG-2 TS에는 PSI(Program Specific Information)에 추가하여 PSIP(Pro- gram and System Information Protocol, ATSC A/65[7])과 같은 시그널링(signalling) 정보가 포함되어 있다. PSIP에 해당하는 정보는 MMT에서 직접 지원하지 않으며, 이를 채택하여 사용할 서비스별로 다른 형태로 제공될 것이므로, 공정한 전달 오버헤드 비교를 위해 MMTP 스트림 제작에서는 이러한 정보를 제외하였다. 즉, 제작한 MMTP 스트림은 비디오, 오디오 하나씩만을 제공하고, 이를 위한 기본적인 시그널링 정보만 포함하는 형태로 제작되었다.

<그림 1>은 MPU(Media Process Unit)의 구조를 나타내고, <그림 2>는 MPU를 MMTP 유료부하(payload)에 싣는 방법을 나타낸다. MMT는 미디어 데이터를 MPU라 불리는 ISOBMFF 기반의 미디어 구조로 캡슐화하며, MPU들은 MMTP의 유료부하에 실려 전송된다. 하나의 MPU는 <그림 2>와 같이 MPU 메타데이터(MPU metadata), 파편 메타데이터(fragment metadata), MFU(Media Fragment Unit) 등의 3가지 유형의 유료부하 즉 데이터 단위(data unit)로 구성되며, MMTP의 유료부하에는 한 가지 유형의 데이터 단위만 실을 수 있다. 하나의 MPU는 한 개의 MPU 메타데이터와 여러 개의 파편 메타데이터들과 MFU들로 나뉘게 되며, MFU 유형의 MMTP 유료부하에는 하나 또는 둘 이상의 MFU들이 실릴 수 있다. 파편 메타데이터에는 moof 박스와 mdat 박스의 앞 부분(박스 이름, 박스 크기)이 포함된다. 그리고 MFU의 앞 부분에는 해당 미디어 샘플 또는 슬라이스에 대한 힌트 샘플(hint sample)이 추가된다. 미디어 샘플은 비디오의 경우, 한 개의 비디오 프레임을 압축한 데이터이고, 오디오의 경우, 하나의 오디오 프레임 즉 일정 구간의 오디오 샘플들을 압축한 데이터이다. 힌트 샘플은 MFU들의 경계를 알려주는 역할을 하며, MMT 힌트 트랙(hint track)에 포함되어 있다. 즉, MMT 송신 측에서 MPU로부터 MFU들을 구분해 내는 데에 필요한 정보를 MMT 힌트 트랙에서 제공하며, 이를 바탕으로 MPU 내의미디어 데이터는 전달될 시점에서 MPU로부터 추출되어 힌트 샘플과 함께 MMTP 유료부하에 실리게 된다. MPEG-2 TS의 PES(Packetized Elementary Stream) 구조와 비교했을 때, MPU에는 주기적으로 전송해야 하는 데이터가 더 많이 존재한다. 그러므로 MMT의 MPU 구조는 MPEG-2 TS와의전달 오버헤드 비교에서 불리하게 작용한다. MPU의 구조와 MPU를 MMTP에 싣는 방법에 대한 더 자세한 내용에 대해서는 MMT 표준[2]과 ISOBMFF 표준[6] 그리고 [3]~[5]를 참고하도록 한다.

그림 1.MPU의 구조 Fig 1. The structure of MPU

그림 2.MPU를 MMTP 유료부하에 싣는 방법 Fig 2. The method of loading an MPU as MMTP payloads

보통 비디오 MPU는 GOP(Group of Picture) 단위로 구성된다. 오디오 MPU는 GOP의 개념이 없기 때문에 짝을 이루는 비디오 MPU의 시간 정보를 참조하여 구성된다. 본 논문의 연구를 위해 제작한 MMTP 스트림에서도 비디오 MPU의 첫 샘플이 I 프레임(Intra frame)이 되도록 구성하였고, 녹화한 MPEG-2 TS의 비디오 GOP와 동일하게 15개의 샘플로 구성된 하나의 GOP를 하나의 비디오 MPU로 구성하였다. 오디오 MPU는 비디오 MPU의 재생 시간에 해당하는 0.5초의 재생 시간을 갖도록 구성하였다.

MMT에서는 미디어 서비스에 대한 다중화 정보 및 제어 정보를 시그널링 메시지(signaling message)를 통해 전달한다. <그림 3>은 패킷 소비를 위한 시그널링 메시지와 이에 포함될 수 있는 테이블들을 나타낸다. 시그널링 메시지에는 PA(Package Access), MPI(Media Presentation Information), MP(MMT Package), DCI(Device Capability Information), CRI(Clock Relation Information) 메시지 등이 존재하며, 테이블에는 메시지와 마찬가지로 PA, MPI, MP, DCI, CRI 테이블 등이 존재한다. 각 메시지는 동일 명칭의 테이블을 포함하며, 필요에 따라 다른 테이블도 포함할 수 있다. 또 계층화 전달(scalable transport) 기능을 사용하는 경우에는 하나의 메시지가 각 계층별 메시지로 나뉘어 전달될 수도 있는데, 이러한 경우에 해당되는 메시지는 MPI 메시지와 MP 메시지 두 가지이다. 계층화 전달 기능을 사용하는 경우, 각 메시지에 포함될 테이블들도 적절하게 분할되어 각 계층별 메시지에 포함된다. PA 테이블은 어떤 패키지의 소비와 관련된 모든 시그널링 테이블에 대한 정보를 포함하고 있다. MPI 테이블은 화면 구성에 관련된 HTML5.0 파일과 MPEG CI(Composition Information)[8] 파일을 포함한다. MP 테이블은 하나의 패키지를 소비하는 데 필요한 모든 정보를 포함하며, MPEG-2 TS의 프로그램 맵 테이블(Program Map Table, PMT)과 유사한 기능을 한다. DCI 테이블은 패키지를 소비하기 위해 요구되는 수신기 능력에 대한 정보를 포함한다. CRI 테이블은 NTP(Network Time Protocol) 타임스탬프(timestamp)와 MPEG-2 시스템 시간 클록을 짝짓기하는 데 사용되는 클록 관계 정보를 포함한다. 따라서 CRI 메시지와 그 테이블은 MPEG-2 TS에 포함된 AV ES 중 하나를 MMT 애셋(asset)으로서 활용하는 경우에만 사용된다. 또한 패키지 획득 지연시간(package acquisition delay)을 최소화할 수 있도록 하나의 메시지가 여러 가지 테이블을 포함할 수도 있는데, PA 메시지와 MPI 메시지의 경우가 그러하다. 특히 방송 서비스 시나리오에서 MMT가 사용되는 경우, PA 메시지는 패키지 소비에 필요한 모든 테이블들을 포함한다. 또 계층화 전달 기능할 사용하는 경우, 상위 계층을 위한 MPI 테이블과 MP 테이블이 하나의 MPI 메시지에 포함되도록 하여, 상위 계층 정보 획득 지연시간을 최소화할 수 있게 하고 있다. 물론 이와 같이 다른 메시지에 어떤 테이블이 함께 포함되어 전달되는 경우, 해당 테이블을 위한 메시지는 추가로 전달하지 않는다.

그림 3.패키지 소비를 위한 시그널링 메시지와 테이블의 구조[2] Fig 3. Structure of the signalling messages and tables for Package consumption[2]

제작한 MMTP 스트림은 비디오 하나, 오디오 하나만 서비스하고, 시간에 따른 화면 구성이 변하지 않기 때문에, PA 메시지만을 사용하였다. 지상파 DTV 표준[9]에서는 PMT의 주기를 0.4초 이내로 전송하도록 명시하였기 때문에, 제작한 MMTP 스트림에서도 공정한 오버헤드 비교를 위해 PA 메시지의 주기를 0.4초로 하였다. MMT는 화면 구성 정보를 MPI 테이블에 포함하여 전송하는데, 본 논문에서 제작한 MMTP 스트림의 MPI 테이블 내에는 화면 구성을 위해 비디오와 오디오 하나씩만을 서비스할 수 있는기본적인 내용의 HTML5와 MPEG CI를 포함시켰다. 이 화면 구성 정보는 MPEG-2 TS에서는 지원하지 않기 때문에, 오버헤드 비교 시 MMT에 불리하게 작용한다.

MMTP 패킷의 최대 크기는 MTU 크기가 허용되는 만큼까지 설정할 수 있다. 이 MTU의 크기는 이더넷(Ethernet)에서는 1,492바이트 또는 1,500바이트로 정의되어 있으며, 본 논문에서는 MTU 크기를 1,500바이트로 가정하여 MMTP 스트림을 제작하였다. 제작한 MMTP 스트림에 대한 검증을 위해, 자체적으로 개발한 MMT 클라이언트 프로그램을 이용하였다. <그림 4>는 이러한 MMT 클라이언트 프로그램의 구조도를 나타낸다. 본 논문에서는 <그림 4>에 표현된 MMT 클라이언트의 기능 중, 파일 형태로 저장된 MMTP 스트림으로부터 미디어를 읽어 재생하는 기능을 활용하였다. MMTP 스트림을 저장하는 파일의 포맷은 매우 단순하게 정의하였는데, 각 패킷을 저장하기 직전 해당 패킷의 바이트 길이를 먼저 저장하도록 하였다. 자세한 내용에 대해서는 [10]을 참조하도록 한다. <그림 5>는 이 클라이언트를 활용한 검증 화면에 대한 화면 캡처이다.

그림 4.[10]에서 개발된 MMT 클라이언트 구조도 Fig 4. The structure of the MMT client developed in [10]

그림 5.[10]에서 개발된 MMT 클라이언트를 이용한, 본 논문에서 생성한 MMTP 스트림에 대한 검증 실험 Fig 5. Verification experiment of the generated MMTP stream using the MMT client developed in [10]

 

Ⅲ. 녹화한 MPEG-2 TS의 전달 오버헤드 계산

MPEG-2 TS는 188바이트의 고정 길이 패킷을 사용하며, 기본적으로 4바이트의 TS 헤더(header)와 보통 184바이트의 유료부하로 구성되지만, 가변길이 확장 헤더인 적응 필드(adaptation field)가 추가된 TS 패킷의 경우에는 그 만큼 유료부하의 크기가 줄어든다. 유료부하에는 압축된 미디어 데이터를 포함하는 PES 데이터 또는 시그널링 정보를 포함하는 테이블이 포함된 섹션(section) 데이터 중 한 가지가 포함될 수 있다. PES 패킷에는 PES 패킷 헤더와 불특정 크기로 나누어진 ES 데이터가 유료부하로서 포함된다. MPEG-2 TS에는 프로그램 연결 테이블(Program Association Table, PAT)과 PMT가 반드시 포함되어 있어야 하며, 추가로 다른 시그널링 테이블이 포함될 수 있다. 그리고 MPEG-2 TS가 ATSC 또는 DVB(Digital Video Broadcasting) 표준에서 정의한 방송 시스템에 적용될 때에는 엄격한 고정 비트율이 요구된다. 따라서 MPEG-2 TS가 고정 비트율를 유지하기 위해 다중화기는 필요한 만큼 추가 패킷을 전송하며, 이 패킷을 널(null) 패킷이라고 부른다. 널 패킷에는 유효 데이터가 전혀 포함되어 있지 않다. 널 패킷의 크기는 MPEG-2 TS가 고정 길이 패킷을 사용하므로 항상 188바이트이어야 한다. 널 패킷을 수신 받은 수신기는 이를 무시하게 된다.

MPEG-2 TS 오버헤드 계산에 있어서 본 논문에서 제작한 MMTP 스트림과의 형평성을 고려하여 녹화한 MPEG-2 TS에서 비디오, 오디오에 대한 기본 시그널링 정보 이외의 PSIP 정보와 같은 부가 정보를 제외하고 오버헤드를 계산하였다. 널 패킷인 경우도 마찬가지로 고정 비트율를 유지하기 위한 부가 데이터이므로 이를 제외하고 오버헤드를 계산하였다. 마지막으로 MMT의 경우, MPEG-2 TS의 PAT에 해당하는 시그널링 정보가 정의되어 있지 않고 이를 채택하여 사용하는 시스템에서 별도로 유사 기능의 시그널링 정보를 정의하여 사용하도록 되어 있기 때문에, 두 방식의 전달 오버헤드를 비교할 때는 이를 제외하였다. <표 1>은 녹화한 MPEG-2 TS를 본 논문에서 구현한 스트림 분석 프로그램으로 분석한 결과이다. 분석 결과 중에 전달 오버헤드 계산에 필요하지 않은 부분은 <표 1>에 보이지 않았다.

표 1.녹화된 MPEG-2 TS의 분석 결과 Table 1. The result of recorded MPEG-2 TS analysis

MPEG-2 TS에는 PES 패킷의 첫 바이트가 TS 패킷의 유료부하 첫 바이트부터 시작해야 한다는 조건이 있고, TS 패킷의 길이가 고정되어 있기 때문에 PES 패킷의 마지막 부분을 담는 TS 패킷에는 사용하지 않는 공간이 발생할 수 있다. 이러한 경우, MPEG-2 TS 표준이 의도한 바에 따르면, 적응 필드에 채워넣기(stuffing) 바이트를 필요한 만큼 넣음으로써, TS 패킷이 188바이트가 되도록 한다. 이러한 채워넣기 바이트들은 TS의 오버헤드로 간주되어야 한다.

<표 1>의 내용 중에 괄호의 숫자는 전체 TS 데이터 크기 대비 해당 데이터의 크기 백분율을 나타낸다. 실제 녹화한 MPEG-2 TS의 분석 결과에서는 PAT와 PMT는 각기 한 개의 TS 패킷에 완전하게 실려 있을 정도로 분량이 작았지만, PAT와 PMT의 패킷 수는 각기 약 5.72 x 103개 및 약 2.14 x 103개로서 <표 1>에 보인 것보다 훨씬 많이 검출되었다. 이렇게 되어 있는 이유는, MPEG-2 TS의 비트율을 채널의 전송률에 맞추기 위해 널 패킷이 들어가야 하는 경우, 널 패킷을 넣는 대신 PAT와 PMT를 담은 패킷들을 넣음으로써, 수신기에서의 프로그램 획득 지연 시간(program acquisition delay)을 최대한 줄일 수 있도록 하기 위한 것으로 추정된다. 실제 녹화한 MPEG-2 TS에는 AV를 포함한 프로그램 1개와 텍스트가 들어있는 다른 프로그램 1개가 별도로 들어 있어서 각 프로그램에 해당하는 PMT마다 PAT가 들어 있는 관계로 AV가 포함된 1개 프로그램을 기준으로 보면 PAT가 PMT에 비해 2배 정도 더 많이 들어 있다. 하지만 제작한 MMTP 스트림과의 공정한 비교를 위해 PAT와 PMT의 전송 주기가 0.4초가 되는 것으로 가정하여, 그에 해당하는 PAT와 PMT만, 녹화된 MPEG-2 TS에 들어 있는 것으로 간주하여 <표 1>에 그 수를 표시하였다. <표 1>에 나와 있는 TS 패킷 헤더 크기의 총합에는 4바이트의 고정길이 헤더뿐만 아니라, PCR(Program Clock Reference) 전달을 위한 적응 필드와 채워넣기 바이트가 포함된 적응 필드의 바이트 수도 모두 포함되어 있다.

상기 조건 하에서 MPEG-2 TS 전달 오버헤드 분석 결과는 다음과 같다. 녹화한 MPEG-2 TS에서 본 논문의 전달 오버헤드 계산을 위해 유효한 패킷 수는 약 3.24 x 106개(PMT, Video, Audio 패킷 수의 합)이며, 이 유효 패킷 크기 합은 약 6.09 x 108바이트이다. 이 중에 오디오와 비디오 ES 데이터의 합은 약 5.96 x 108바이트이며, 이를 제외한 오버헤드 크기의 합(비디오, 오디오 크기를 제외한 나머지 데이터의 합)은 약 1.34 x 108바이트이다. 따라서 녹화한 MPEG-2 TS에서 전체 데이터 대비 오디오와 비디오 ES 데이터 전달에 필요한 전달 오버헤드 데이터의 비율은 2.201%라는 결과를 얻었다. 본 논문에서는 “전달 오버헤드”를 “전달하고자 하는 데이터 바이트 수” 대비 “이를 전달하기 위해 추가되는 데이터의 바이트 수”로 정의한다. 이러한 정의에 따르면 MPEG-2 TS의 전달 오버헤드는 다음과 같다.

 

Ⅳ. 제작한 MMTP 스트림의 오버헤드 계산

II장에서 설명한 바와 같이 MMTP 패킷의 최대 크기는 MTU 크기가 허용되는 만큼까지 설정할 수 있으며, 이 크기는 언급한 바와 같이 보통 1,492바이트 또는 1,500바이트이다. 본 논문에서는 1,500바이트의 MTU 크기를 사용하여 전달 오버헤드 비교 실험을 위한 MMTP 스트림을 제작하였다. MMTP 패킷의 최대 크기는 MTU 크기인 1,500바이트에서 IP 패킷 헤더 크기(20바이트)와 UDP(User Datagram Protocol) 패킷 헤더 크기(8바이트)를 뺀 나머지 1,472 바이트가 된다.

<표 2>와 <표 3>은 MTU 크기를 1,500바이트(즉 MMTP 패킷의 최대 크기를 1,472바이트)라고 가정하고, 본 논문의 비교 분석을 위해, 녹화한 MPEG-2 TS에 포함된 오디오와 비디오 ES를 전달하기 위한 MMTP 스트림을 제작한 후, 이에 대해서 본 논문에서 구현한 스트림 분석 프로그램으로 분석한 결과이다. MMT 표준에서는 미디어 데이터를 전송 시 MMTP 헤더로 인한 오버헤드를 줄일 수 있도록 MMTP 헤더 압축 기능을 제공한다. 이 MMTP 헤더 압축 방법에서는 송신단은 원래 크기 헤더(full size header) 즉 비압축 헤더를 주기적으로 전송하고, 인접한 두 비압축 헤더 사이 구간에서는 압축 헤더(compressed header)를 전송한다. 수신단에서는 비압축 헤더를 먼저 전송 받고 그 이후에 전달되는 압축 헤더들에 대해서는 최근 비압축 헤더를 참조하여 원래의 헤더를 복원한다. 이러한 MMTP 헤더 압축 기능은 MMTP 패킷 내에 수송하고자 하는 데이터의 종류 별 즉 패킷 ID 별로 시행된다. 본 논문의 실험에서는 비압축 헤더의 주기로서 MMT 표준에서 허용하는 최대 주기인 256패킷을 사용하였다. <표 2>는 MMTP 헤더 압축 기능을 사용하지 않은 경우의 결과이며, <표 3>은 이를 사용한 경우의 결과이다. 본 논문에서는 이들에 의한 MMTP 스트림을 각기 “버전1” 및 “버전2”라 부르기로 한다. <표 2>와 <표 3>의 내용 중에 패킷화에 필요한 추가 데이터에는 MMTP 유료부하 헤더 데이터와 MPU에 대한 부가 정보 즉, II장에서 언급한 MPU 메타데이터, 파편 메타데이터, MFU 앞머리에 추가되는 힌트 샘플 데이터, MFU 헤더 등이 포함된다. 그리고 MMTP 스트림 제작 시, MPEG-2 TS와의 공정한 비교를 위해, PA 메시지인 경우에는 0.4초 당 한 개를 넣었다.

표 2.MMTP 스트림 분석 결과(MTU : 1,500 바이트, MMTP 헤더 압축 기능 사용 않음, 버전1) Table 2. The result of MMTP stream analysis (MTU: 1,500 bytes, MMTP header compression not used, Version1)

표 3.MMTP 스트림 분석 결과(MTU : 1,500 바이트, MMTP 헤더 압축 기능 사용, 버전2) Table 3. The result of MMTP stream analysis (MTU: 1,500 bytes, MMTP header compression used, Version2)

<표 2>를 보면 제작한 MMTP 스트림의 MMTP 패킷의 수는 총 4.26 x 105개이며, 그 크기는 약 6.08 x 108바이트이다. 그리고 비디오와 오디오 ES의 크기의 합은 약 5.95 x 108바이트이며, 이를 제외한 오버헤드의 합(PA 메시지 패킷, 비디오와 오디오의 패킷 헤더 및 전송을 위해 필요한 메타데이터의 합 즉, 비디오, 오디오 ES를 제외한 나머지 데이터의 합)은 1.31 x 107바이트이다. 여기서 녹화된 MPEG-2 TS의 비디오 크기와 본 논문에서 제작한 MMTP 스트림 내의 비디오 데이터의 크기가 다른 이유는 다음과 같다. 비디오를 MPU로 구성할 때에는 첫 MFU는 I 프레임이어야 한다. 그러므로 녹화한 MPEG-2 TS로부터 비디오 데이터를 추출할 때, 첫 I 프레임 이전의 비디오 프레임 데이터들을 MPU 구성에서 제외하였다. 이로 인해 오디오의 경우에도 첫 MPU 구성 시, AV 동기화를 위해 녹화된 MPEG-2 TS 첫 부분의 오디오 데이터 일부가 제외되었다. <표 1>에 제시된 녹화된 MPEG-2 TS에 대한 분석 결과에서는 PAT와 PMT의 삽입 위치가 GOP의 처음과 일치하지 않았기 때문에 PAT와 PMT이후 처음 등장하는 GOP 직전 미디어 데이터도 비디오와 오디오 ES로서 간주하였다.

<표 2>와 <표 3>의 내용 중에 괄호 내의 숫자는 전체 MMTP 스트림 크기 대비 해당 데이터 크기의 백분율을 나타낸다. 버전1의 MMTP 스트림에서 전체 MMTP 스트림 크기 대비 전달 오버헤드에 해당하는 데이터의 비율은 2.154%라는 결과를 얻었다. 이를 본 논문에서 정의한 전달 오버헤드로 나타내면 다음과 같다.

<표 3>에는 MMTP 스트림 버전2에 대해 본 논문에서 구현한 스트림 분석 프로그램으로 분석한 결과를 보였다. PA 메시지를 포함하는 MMTP 패킷은 0.4초 당 한 패킷만 등장하기 때문에 그 수가 작고 비압축 헤더의 주기가 매우 길어지기 때문에 PA 메시지 패킷에 압축 기능을 사용하더라도 압축 효과가 미미하다. 따라서 MPU인 경우에만 MMTP 헤더 압축 기능을 적용하였다.

<표 3>의 결과에서 확인할 수 있듯이, MMTP 패킷의 수는 총 4.24 x 105개이며, 그 크기는 약 6.06 x 108바이트이다. <표 2>의 결과에 비해, MMTP 패킷 수가 줄어든 이유는 MMTP 헤더 압축 기능을 사용함에 따라 동일한 MMTP 패킷 내에서 유료부하 공간이 커져서, 동일한 크기의 비디오와 오디오 ES 데이터를 넣었을 때, MMTP 패킷 수가 줄어들었기 때문이다. 물론 이에 따라 MMTP 스트림의 크기도 <표 2>의 결과에 비해 작아졌다. 그리고 비디오와 오디오 ES의 크기의 합은 버전1과 마찬가지로 약 5.95 x 108바이트이며, 이를 제외한 오버헤드 크기의 합은 약 1.05 x 107바이트이다. 그래서 버전2의 MMTP 스트림에서 전체 MMTP 스트림 크기 대비 전달 오버헤드에 해당하는 데이터의 비율은 1.740%라는 결과를 얻었다. 이를 본 논문에서 정의한 전달 오버헤드로 환산하면 다음과 같다.

참고로, <표 3>의 내용을 <표 2>의 내용과 비교했을 때, 미디어 데이터 내의 고유 메타데이터 부분인 MPU 메타데이터, 파편 메타데이터, MFU 데이터 단위 헤더, 힌트 샘플 데이터 등에 해당하는 전달 오버헤드 바이트 수는 동일하며, MMTP 헤더 압축 기능에 의해 줄어든 MMTP 패킷 헤더와 MMTP 유료부하 헤더에 해당하는 전달 오버헤드 바이트 수만 줄어들었음을 알 수 있다. MMTP 패킷 헤더의 경우, MMTP 헤더 압축 기능에 의해 데이터가 줄어들었을 뿐만 아니라 전체 패킷 수가 줄어듦에 따라 데이터가 줄었다. 또 MMTP 유료부하 헤더의 경우에는 전체 패킷 수가 줄어듦에 따라 데이터가 줄었다.

<표 3>의 버전2의 결과와 <표 2>의 버전1의 결과를 비교하였을 때, 전달 오버헤드가 버전1의 2.202%에서 버전2의 1.771%로 0.431% 낮아져 MMTP 헤더 압축 효과가 나타났음을 확인할 수 있다.

MMTP 헤더 압축 기능을 사용하여 전달 오버헤드를 줄일 수 있지만 그 대가도 존재한다. 만약 전송 환경이 좋지 않아 패킷을 잃어버리는 경우가 발생한다면, 비압축 헤더를 포함한 기준 패킷을 잃어버리는 경우가 발생할 수 있다. 이러한 경우, 이를 참고해야 하는 압축 헤더는 수신기에 의해 복원될 수 없기 때문에 해당 패킷들은 버려져야 하고, 이로 인해 방송의 질이 그만큼 떨어지게 될 것이다.

<표 2>와 <표 3>의 결과는 UDP/IP와 데이터 링크 계층의 오버헤드가 더해지지 않은 것이므로, 이 결과만으로 MPEG-2 TS와의 전달 오버헤드를 비교하기에는 적절하지 않다. 공정한 비교를 위해서는 실제 방송 서비스 별로 MPEG-2 TS가 통신 계위 상 어떤 계층에서 사용되는지를 살펴 적절하게 비교하는 것이 필요하다.

 

Ⅴ. 방송 서비스 별 전달 오버헤드 비교

본 장에서는 IPTV(Internet Protocol Television)와 지상파 HDTV 등의 실제 방송 서비스들에서 MPEG-2 TS를 사용할 때와 MMTP를 사용할 때에 발생하는 전달 오버헤드에 대해 가능한 한 공정하게 비교하고자 한다.

1. IPTV

<그림 4>는 IPTV에서 사용하는 전송 프로토콜 스택(stack)에 대한 그림이다. 해당 표준[11]에 의하면 IPTV에서 MPEG-2 TS를 전송하기 위해서 MPEG-2 TS 패킷을 UDP 혹은 RTP(Real-time Transport Protocol) 패킷으로 캡슐화하며 그 방법은 DVB-IPI 표준[12]의 7.1절의 내용을 따른다. 다만, MPEG-2 TS를 RTP 없이 직접 UDP로 전송하는 경우에는 QoS(Quality of Service)가 보장되는 네트워크(managed network)이어야 한다. IPTV의 경우에는 MPEG-2 TS가 가지고 있는 기능 중 데이터 링크 계층의 프레이밍 기능은 전혀 사용하지 않으며, MPEG-2 TS 데이터를 미디어 데이터처럼 간주하여 전송한다.

그림 4.IPTV에서 사용하는 전송 프로토콜 스택[11] Fig 4. Transport Protocol Stack in IPTV[11]

DVB-IPI 표준에서는 MPEG-2 TS를 RTP/UDP/IP로 캡슐화하는 데에 소요되는 최소의 오버헤드 크기를 <그림 5>와 같이 설명하고 있다. 해당 표준에 의하면 RTP 또는 UDP에서는 TS 패킷 단위로 유료부하를 채운다. 따라서 IPTV에서, 녹화한 MPEG-2 TS를 전송할 때 발생하는 전달 오버헤드를 계산하는 방법은 다음과 같다.

그림 5.RTP 캡슐화를 위한 최소 패킷 포맷(IPv4)[12] Fig 5. Minimal packet format (IPv4) for RTP encapsulation[12]

IPTV에서 MMT 표준을 사용할 경우, 오버헤드 계산은 MPEG-2 TS와 달리 UDP/IP 캡슐화로 인해 발생하는 오버헤드만을 IV장의 오버헤드 계산 결과에 추가하면 된다. 다음은 제작한 MMTP 스트림을 IPTV에서 전송한다고 할 때의 전달 오버헤드를 계산하는 방법이다.

<표 4>는 녹화된 MPEG-2 TS와 제작된 MMTP 스트림에 대한 IPTV의 전달 오버헤드 계산 결과를 보여준다. 결과에서 확인할 수 있듯이 IPTV에서는 MMT가 MPEG-2 TS에 비해 MMTP 헤더 압축 기능을 사용하지 않은 경우에도 전달 오버헤드 측면에서 유리함을 확인할 수 있다.

표 4.IPTV의 경우, MPEG-2 TS와 MMTP의 전달 오버헤드 비교 결과 4. The result of transport overhead comparison between MPEG-2 TS and MMTP in IPTV

참고로 [13]에서 IP 스트리밍 시, MPEG-2 TS의 패킷화 오버헤드를 제시하고 있으나, 이는 4바이트의 고정길이 TS 패킷 헤더만 오버헤드에 포함시킨 결과로서, 매우 대체적인 결과일 뿐이다.

2. 지상파 HDTV

현재 우리나라의 지상파 HDTV에서는 MPEG-2 TS의 프레이밍 기능을 사용하기 때문에 MPEG-2 TS를 직접 디지털 변조하여 안테나를 통해 송신한다. 만약 지상파 HDTV에서 MPEG-2 TS 대신 MMTP를 사용한다고 가정하면, MMTP 패킷을 UDP/IP로 캡슐화한 후 프레이밍 기능을 갖는 데이터 링크 계층을 새롭게 정의하여 송신하여야 한다. 따라서 지상파 HDTV에서 MMTP를 MPEG-2 TS 대신 사용한다고 할 때의 전달 오버헤드는 다음과 같이 계산할 수 있을 것이다.

따라서 상기 α가 III장 및 IV장의 결과로부터 얻은 MPEG-2 TS 전달 오버헤드 대비 MMTP 전달 오버헤드의 차이를 상회한다면, MMTP를 사용하더라도 전달 오버헤드 측면에서는 MPEG-2 TS에 비해 불리하다고 할 수 있을 것이다. 그러나 이는 전달 오버헤드에 국한된 평가이며, MPEG-2 TS 대신 MMTP를 사용한다면, PCR을 전달하지 않기 때문에 전달 스트림에 대한 편집이 용이하며, 동일한 스트림을 IP 기반의 브로드밴드 통신망으로 통해 전달할 때 훨씬 용이하므로 방송 통신 융합 환경에서의 IBB(Integra-ted Broadcast Broadband) 서비스 측면에서 여러 가지 장점을 얻을 수 있다.

마지막으로 MMT의 경우, AV 동기화를 위해 월클록(wall clock)을 NTP을 통해 송신 측으로부터 수신 측으로 별도로 전달하는 것을 가정하고 있는데, 이로 인해 약간의 오버헤드가 더 추가될 수 있음을 지적해 둔다. 물론 IPTV 단말기와 같이 이미 NTP에 의해 월클록을 획득하는 기능을 갖추고 있는 경우에는 MMT를 사용한다고 하여도 이를 추가로 전달할 필요는 없을 것이다.

 

Ⅵ. 결 론

본 논문에서는 차세대 멀티미디어 전달 표준인 MMT와 기존에 널리 사용되고 있는 MPEG-2 TS의 전달 오버헤드를 실험을 통해 비교하였다. 공정한 전달 오버헤드 비교를 위해서 지상파 HDTV로 방송 중인 MPEG-2 TS를 실제로 녹화하여 저장한 후, 이로부터 동일한 비디오와 오디오 압축 데이터에 대한 MMTP 스트림을 제작하였으며, MPEG-2 TS와 MMTP 스트림을 분석하는 프로그램을 개발하였다. 개발된 스트림 분석 프로그램을 사용하여 얻은 분석 결과를 바탕으로 각 표준의 전달 오버헤드를 제시하였다. 또한 이 두 표준이 통신 계위 상 차지하는 위치가 다르기 때문에, 실제적인 비교를 위해 IPTV와 지상파 HDTV에서 MPEG-2 TS를 대체하여 MMTP를 사용한다고 가정하였을 때의 전달 오버헤드를 분석하였다.

MPEG-2 TS와 비교해서 MMTP는 미디어의 캡슐화 구조로서 ISOBMFF를 사용하고 화면 구성 정보를 사용하기 때문에 전달 오버헤드가 증가할 요인을 갖고 있으나, 반면 패킷의 크기를 MPEG-2 TS의 고정 패킷 길이인 188바이트보다 큰 MTU 크기(1,500바이트)로 사용함으로써 전달 오버헤드를 줄일 수 있는 요인도 갖고 있다. 본 논문의 실험 결과에 따르면, UDP/IP와 데이터 링크 계층에서 발생하는 전달 오버헤드를 제외한 상태에서는 비디오 1개와 오디오 1개로 이루어진 1개의 프로그램을 전달하는 데 필요한 전달 오버헤드는 전달하고자 하는 데이터 대비 MPEG-2 TS의 경우 약 2.25%, MMTP 헤더 압축 기능을 사용하지 않은 MMTP의 경우 약 2.20%, MMTP 헤더 압축 기능할 사용하는 MMTP의 경우, 약 1.77%로서, 상기 상충되는 요인들이 서로 상쇄되어 MMTP가 MPEG-2 TS 보다 전달 오버헤드 측면에서 서로 비슷하거나 다소 유리함을 알 수 있었다. 하지만 이들을 실제 방송 서비스에 적용한다고 할 때, MMTP의 경우 MPEG-2 TS와 달리 패킷들을 UDP/IP를 통해서만 전달해야 하고, IP 패킷을 프레이밍하기 위한 전달 오버헤드가 추가로 발생한다. 이러한 추가 전달 오버헤드가 MPEG-2 TS와 MMTP 모두 비슷한 정도로 필요한 IPTV의 경우에는, 예상한 바와 같이 MMTP가 MPEG-2 TS보다 전달 오버헤드 측면에서 유리하다는 결과를 얻었으며, 지상파 HDTV의 경우에는 추가되어야 하는 전달 오버헤드의 양에 따라 상대적인 유불리가 달라질 수 있다는 결과를 얻었다.

References

  1. ISO/IEC 13818-1, Information technology -Generic coding of moving pictures and associated audio information: Systems, Third Edition, Int'l Organization for Standardization, 2007.
  2. ISO/IEC 23008-1, Information technology -High efficiency coding and media delivery in heterogeneous environments - Part 1: MPEG Media Transport, Int'l Organization for Standardization, 2014.
  3. K. Park, Y. Lim, D. Suh, “Delivery of ATSC 3.0 Services With MPEG Media Transport Standard Considering Redistribution in MPEG-2 TS Format”, IEEE Transactions on Broadcasting, vol. 62, no. 1, pp. 338–351, Mar. 2016. https://doi.org/10.1109/TBC.2016.2518625
  4. Y. Lim, S. Aoki, I. Bouazizi, and J. Song, “New MPEG Transport Standard for Next Generation Hybrid Broadcasting System with IP”, IEEE Trans. on Broadcasting, vol. 60, no. 2, pp. 160-169, June 2014. https://doi.org/10.1109/TBC.2014.2315472
  5. K. Park, Y. Lim, D. Suh, “Delivery of ATSC 3.0 Services With MPEG Media Transport Standard Considering Redistribution in MPEG-2 TS Format”, IEEE Transactions on Broadcasting, vol. 62, no. 1, pp. 338–351, Mar. 2016. https://doi.org/10.1109/TBC.2016.2518625
  6. ISO/IEC 14496-12, Information technology - Coding of audio-visual objects - Part 12: ISO Base Media File Format, Int'l Organization for Standardization, 2012.
  7. ATSC Standard, Document A/65, Program and System Information Protocol for Terrestrial Broadcast and Cable, Advanced Television Systems Committee, 2013.
  8. ISO/IEC 23008-11, Information technology -High efficiency coding and media delivery in heterogeneous environments - Part 11: MPEG Media Transport Composition Information, Int'l Organization for Standardization, 2015.
  9. TTAK.KO-07.0014/R4, Standard of Transmission and Reception for Digital Terrestrial Television Broadcasting, Telecommunications Technology Association, 2012.
  10. J. Jeong, "An implementation of Internet multimedia streaming by MMTP", Masters Thesis, University of Seoul, 2015.
  11. TTAK.KO-08.0012/R2, IPTV Middleware (ICSP: IPTV Convergence Service Platform), Telecommunications Technology Association, 2010.
  12. ETSI TS 102 034, 'Digital Video Broadcasting (DVB); Transport of MPEG-2 TS Based DVB Services over IP Based Networks', European Telecommunications Standards Institute, 2014.
  13. A. MacAulay, B. Felts, Y. Fisher, Envivio WHITE PAPER - IP Streaming of MPEG-4: Native RTP vs MPEG-2 Transport Stream, http://pdf.textfiles.com/manuals/STARINMANUALS/Envivio/Manual/White%20Paper%20-%20IP%20Streaming%20of%20MPEG-4%20-%20Native%20RTP%20vs%20MPEG-2%20Transport%20Stream.pdf, Oct. 2005.