KR100739308B1 - 비디오 스트림의 알티피 패킷화 방법 - Google Patents

비디오 스트림의 알티피 패킷화 방법 Download PDF

Info

Publication number
KR100739308B1
KR100739308B1 KR1020000077100A KR20000077100A KR100739308B1 KR 100739308 B1 KR100739308 B1 KR 100739308B1 KR 1020000077100 A KR1020000077100 A KR 1020000077100A KR 20000077100 A KR20000077100 A KR 20000077100A KR 100739308 B1 KR100739308 B1 KR 100739308B1
Authority
KR
South Korea
Prior art keywords
rtp
video object
video
payload
rtp packet
Prior art date
Application number
KR1020000077100A
Other languages
English (en)
Other versions
KR20020046770A (ko
Inventor
곽승훈
이해영
Original Assignee
주식회사 케이티
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 주식회사 케이티 filed Critical 주식회사 케이티
Priority to KR1020000077100A priority Critical patent/KR100739308B1/ko
Publication of KR20020046770A publication Critical patent/KR20020046770A/ko
Application granted granted Critical
Publication of KR100739308B1 publication Critical patent/KR100739308B1/ko

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234318Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into objects, e.g. MPEG-4 objects
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

1. 청구범위에 기재된 발명이 속한 기술분야
본 발명은 비디오 스트림의 알티피 패킷화 방법에 관한 것임.
2. 발명이 해결하려고 하는 기술적 과제
본 발명은, 복호화의 기본 단위가 되는 기본 계층(base layer)에 해당하는 비디오 객체(Video Object)에 대한 RTP 페이로드(payload) 포맷만을 정의하여 페이로드(payload) 포맷의 정의를 최소화하여 부가적인 오버헤드를 줄이고, 복원된(unpacketized) 비디오 스트림에 대한 독립적인 복호화를 보장하기 위한 비디오 스트림의 알티피 패킷화 방법과 상기 방법을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공하고자 함.
3. 발명의 해결방법의 요지
본 발명은, 비디오 스트림의 RTP(Real Time transfer Protocol) 패킷화 방법에 있어서, 가변적인 크기를 가지는 RTP 패킷의 크기를 결정하는 단계; 상기 크기를 결정한 RTP 패킷의 페이로드에 적어도 하나의 비디오 객체로 이루어진 비디오 스트림을 비디오 객체 단위로 할당하는 비디오 객체 단위의 비디오 스트림 할당 단계; 연속된 RTP 패킷이 동일한 비디오 객체에 대한 정보인지, 아니면 다른 비디오 객체에 대한 정보인지를 표시하는 정보 표시 단계; 및 상기 할당한 비디오 객체를 RTP 패킷의 페이로드에 수용하고, 상기 표시정보를 RTP 패킷의 헤더에 수용하는 단계를 포함함.
4. 발명의 중요한 용도
본 발명은 통신 시스템 등에 이용됨.
RTP 패킷, 엠펙(MPEG)-4 요소 스트림(Elementary Stream), RTP, RTP 페이로드 포맷(payload format)

Description

비디오 스트림의 알티피 패킷화 방법{Method of RTP Packetization for Video Streams}
도 1 은 본 발명이 적용되는 통신망의 구성 예시도.
도 2 는 일반적인 프로토콜 스택에서의 전송 단위(Transfer Unit)의 일실시예 구조도.
도 3 은 본 발명에 따른 RTP 패킷의 일실시예 구조도.
도 4 는 본 발명에 따른 비디오 스트림의 패킷화 방법에 대한 일실시예 흐름도.
* 도면의 주요 부분에 대한 부호의 설명
101 : 영상 획득부 102 : 엠펙(MPEG)-4 요소 스트림 부호화부
103 : 알티피(RTP) 패킷화부 104 : 전송부
105 : 수신부 106 : 알티피(RTP) 패킷 복원부
107 : 엠펙(MPEG)-4 요소 스트림 복호화부
108 : 영상 재생부
본 발명은 비디오 전송시스템에서 비디오 스트림의 송수신을 위해 RTP 프로토콜을 사용할 때 비디오 스트림의 알티피 패킷화 방법과 상기 방법을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체에 관한 것이다.
엠펙(MPEG)-4는 실세계의 음성, 영상, 객체 데이터를 멀티미디어 콘텐츠로 표현하기 위한 디지털 비트 스트림 형식과 이에 관련된 프로토콜을 규정한 ISO(International Organization for Standardization)/IEC(International Electrotechnical Commission) 표준이다.
기존의 H.261/3 표준, 엠-제이펙(M-JPEG) 표준, 엠펙(MPEG)-1 및 엠펙(MPEG)-2 표준 등의 국제적인 영상 압축 표준은 입력 영상에 담긴 내용과는 무관하게 영상의 화소 값만을 기본으로 데이터 압축을 수행하여 그 성능에 한계가 있다. 따라서, 통신, 방송, 컴퓨터 등의 다양한 멀티미디어 서비스의 응용 분야에서 요구되는 여러 가지 기능을 모두 충족하기에는 곤란한 점이 있다.
그러나, 엠펙(MPEG)-4는 단순히 블럭 단위의 부호화를 수행했던 기존의 표준과 달리 압축 효율이 높은 내용 기반 부호화(Content-based Coding) 방식을 채택함으로써, 10kbps정도 이하의 낮은 대역폭에서 수Mbps의 높은 대역폭에 이르기까지 광범위한 범위의 대역폭에서도 사용 가능한 부호화 기술을 사용한다.
영상의 내용에 대한 이해를 바탕으로 한 내용 기반 부호화 방식은 영상 내용 을 각각의 객체(Object) 단위로 나누어 처리하여 전송하므로, 객체 단위의 데이터 압축, 재생, 전송, 조작이 가능하고, 서비스의 질을 조절할 수 있는 스케일러블 처리 기술 등을 특징으로 하여 사용자의 의도에 따라 다양한 형태의 조작이나 디스플레이가 가능하다. 따라서, 엠펙(MPEG)-4에서는 사용하는 서비스의 내용을 자신의 기호에 따라 좀 더 능동적으로 조작하여 자신에게 적합한 환경을 만들 수 있다.
이러한 이유로, 엠펙(MPEG)-4 영상 압축 기술의 적용은 기존의 영상 압축 기술에 비하여 고품질의 멀티미디어 응용 서비스에 매우 적합하다. 또한, 엠펙(MPEG)-4 단말시스템의 계층적인 특징은 다양한 전송 매체를 통한 자유로운 접근과 스트림의 투명한 전송을 가능하게 하며, 전송 오류에 대한 내성이 강하기 때문에 이동 통신망 및 인터넷 등과 같은 오류 환경에 적합하다.
엠펙(MPEG)-4 시스템에서는 타이밍과 시퀀스넘버 등의 정보를 가지고 있기 때문에 엠펙(MPEG)-4 비디오 스트림을 사용자데이터그램프로토콜/인터넷프로토콜(이하 "UDP/IP"라 함) 상에서 전송하는 것이 가장 간단하고 수월한 방법처럼 보인다. 하지만 여기에는 몇 가지 문제점이 있다.
첫째, UDP(User Datagram Protocol) 상에서 바로 전송된 엠펙(MPEG)-4 비디오 스트림은 다른 종류의 멀티미디어 데이터 스트림과 동기가 불가능하고, 게다가 엠펙(MPEG)-4의 동영상 및 세션 제어 개념을 엠펙(MPEG)-4로 처리가 안된 데이터에 확장할 수 없다. 이와 같은 이유로 UDP(User Datagram Protocol) 상의 엠펙(MPEG)-4 비디오 스트림의 전송은 엠펙(MPEG)-4로 처리가 안된 데이터와의 정합에 문제가 있다.
둘째, 가변적인 지연이 존재하는 인터넷 상에서 서로 다른 서버로부터 온 엠펙(MPEG)-4 스트림의 동기를 맞출 수 있는 방법을 제공하지 못하고, 멀티캐스트 세션에서 두 개의 서버로부터 생성된 엠펙(MPEG)-4 스트림은 충돌 가능성이 있다. 엠펙(MPEG)-4에서는 피드백 제어를 필요로 하는데 순수한 UDP(User Datagram Protocol)는 이런 알고리즘을 제공하지 않는다.
상기와 같은 이유로 인터넷상에서 RTP(Real Time transfer Protocol)가 엠펙(MPEG)-4 비디오 스트림을 전송하는 적합한 프로토콜로 인식되며, RTP를 사용함으로써 얻을 수 있는 이점은 다음과 같다.
첫 번 째로, 엠펙(MPEG)-4 비디오 스트림과 다른 RTP 페이로드(payload)와의 동기화가 가능하고, RTCP(Real Time Control Protocol)를 통하여 전송 성능에 대한 감시가 가능하다.
두 번 째로, 엠펙(MPEG)-4 비디오 스트림은 RTP 믹서를 이용하여 다중 단말로부터 수신된 다른 실시간 데이터 스트림의 통합이 가능하고, 또한 RTP 번역루틴을 통하여 데이터 타입을 변환시킬 수 있다.
엠펙(MPEG)-4 부호화기로부터 생성된 엠펙(MPEG)-4 요소 스트림(Elementary Stream)을 위한 기존의 RTP 페이로드(payload) 포맷은 IETF Internet Draft(Kikuchi, Nomura, Fukunaga, Kimara, Matsui, RTP payload format for MPEG-4 Audio/Visual streams, Internet Draft, Internet Engineering Task Force, Sep.2000)에 표현되어 있는데, 상기 기법은 엠펙(MPEG)-4 부호화기로부터 생성된 계층적 구조를 가질 수 있는 엠펙(MPEG)-4 요소 스트림(Elementary Stream)을 RTP 페이로드(payload)로 바로 매핑하는 방법으로, 엠펙(MPEG)-4 시스템의 동기화 및 스트림 관리 기능을 사용하지 않는 엠펙(MPEG)-4 비디오 스트림을 전송하기에 적합한 포맷이다. 하지만 상기 방법은 다음과 같은 문제점을 갖고 있다.
첫 번 째로, 계층적 구조를 가지는 엠펙(MPEG)-4 요소 스트림(Elementary Stream)에 대해 고려함으로써, 각 계층별 요소 스트림(Elementary Stream)에 대한 각각의 페이로드(payload) 포맷을 정의해야 한다. 이는 송신단과 수신단에서 여러가지 페이로드(payload) 포맷에 대한 정보를 유지해야 하는 부담이 있다.
두 번 째로, 송신단에서는 RTP 페이로드(payload)의 데이터가 엠펙(MPEG)-4 요소 스트림(Elementary Stream)의 어느 계층에 속한 정보인지를 표시해야 하는 오버헤드가 있고, 역으로 수신단에서는 수신된 RTP 패킷의 페이로드(payload) 데이터가 엠펙(MPEG)-4 요소 스트림(Elementary Stream)의 어느 계층에 속한 정보인지를 알아내야 한다.
세 번 째로, 위와 같은 오버헤드가 존재함에도 불구하고, 실제로 엠펙(MPEG)-4 복호화기는 하나의 완전한 엠펙(MPEG)-4 요소 스트림(Elementary Stream)을 구성하는 기본 계층(base layer)에 해당하는 모든 데이터가 구성되기 전까지는 복호화가 불가능하다. 따라서, 이런 오버헤드를 감수하면서 엠펙(MPEG)-4 요소 스트림(Elementary Stream)의 계층적 구성을 고려하여, 다양한 RTP 페이로드(payload) 포맷을 정의하고 운용하는 것에는 그 효율성에 한계가 있다.
본 발명은, 상기한 바와 같은 문제점을 해결하기 위하여 제안된 것으로, 복호화의 기본 단위가 되는 기본 계층(base layer)에 해당하는 비디오 객체(Video Object)에 대한 RTP 페이로드(payload) 포맷만을 정의하여 페이로드(payload) 포맷의 정의를 최소화하여 부가적인 오버헤드를 줄이고, 복원된(unpacketized) 비디오 스트림에 대한 독립적인 복호화를 보장하기 위한 비디오 스트림의 알티피 패킷화 방법과 상기 방법을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공하는 데 그 목적이 있다.
상기 목적을 달성하기 위한 본 발명의 방법은, 비디오 스트림의 RTP(Real Time transfer Protocol) 패킷화 방법에 있어서, 가변적인 크기를 가지는 RTP 패킷의 크기를 결정하는 단계; 상기 크기를 결정한 RTP 패킷의 페이로드에 적어도 하나의 비디오 객체로 이루어진 비디오 스트림을 비디오 객체 단위로 할당하는 비디오 객체 단위의 비디오 스트림 할당 단계; 연속된 RTP 패킷이 동일한 비디오 객체에 대한 정보인지, 아니면 다른 비디오 객체에 대한 정보인지를 표시하는 정보 표시 단계; 및 상기 할당한 비디오 객체를 RTP 패킷의 페이로드에 수용하고, 상기 표시정보를 RTP 패킷의 헤더에 수용하는 단계를 포함하는 것을 특징으로 한다.
한편, 본 발명은, 대용량 프로세서를 구비한 알티피(RTP) 패킷화 장치에, 가변적인 크기를 가지는 RTP 패킷의 크기를 결정하는 기능; 상기 크기를 결정한 RTP 패킷의 페이로드에 적어도 하나의 비디오 객체로 이루어진 비디오 스트림을 비디오 객체 단위로 할당하는 비디오 객체 단위의 비디오 스트림 할당 기능; 연속된 RTP 패킷이 동일한 비디오 객체에 대한 정보인지, 아니면 다른 비디오 객체에 대한 정보인지를 표시하는 정보 표시 기능; 및 상기 할당한 비디오 객체를 RTP 패킷의 페이로드에 수용하고, 상기 표시정보를 RTP 패킷의 헤더에 수용하는 기능을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체를 제공한다.
상술한 목적, 특징들 및 장점은 첨부된 도면과 관련한 다음의 상세한 설명을 통하여 보다 분명해 질 것이다. 이하, 첨부된 도면을 참조하여 본 발명에 따른 바람직한 일실시예를 상세히 설명한다.
도 1 은 본 발명이 적용되는 통신망의 구성 예시도이다.
도 1 에 도시된 바와 같이, 본 발명이 적용되는 통신망의 송신단은, 자연영상을 획득하는 영상 획득부(101), 상기 영상 획득부(101)에서 획득된 영상을 부호화기에서 엠펙(MPEG)-4 요소 스트림(Elementary Stream)으로 코딩하는 엠펙(MPEG)-4 요소 스트림(Elementary Stream) 부호화부(102), 상기 엠펙(MPEG)-4 요소 스트림(Elementary Stream) 부호화부(102)로부터 전달받은 엠펙(MPEG)-4 요소 스트림(Elementary Stream)을 RTP 패킷 페이로드(payload)에 수용하는 RTP 패킷화부(103), 그리고 상기 RTP 패킷화부(103)에서 만들어진 RTP 패킷을 전송하는 전송부(104)를 포함한다.
그리고, 본 발명이 적용되는 통신망의 수신단은, 상기 전송부(104)에서 전송되어진 연속된 RTP 패킷을 인터넷을 통하여 수신하는 수신부(105), 상기 수신부(105)에서 수신된 RTP 패킷을 엠펙(MPEG)-4 복호화기에서 복호가 가능하도록 각 RTP 패킷을 복원하는 RTP 패킷 복원부(106), 상기 RTP 패킷 복원부(106)에서 복원된 복호화가 가능한 데이터를 재생 가능한 비디오 데이터로 변환하는 엠펙(MPEG)-4 요소 스트림(Elementary Stream) 복호화부(107), 그리고 상기 엠펙(MPEG)-4 요소 스트림(Elementary Stream) 복호화부(17)에서 복호화된 영상을 재생하는 영상재생부(108)를 포함한다.
본 발명에서의 RTP 패킷 크기는 하부 구조를 이루는 프로토콜의 특성에 맞게 결정하는데, 이는 각각의 프로토콜에 따라 IETF RFC 1191(Internet Engineering Task Force Request For Comment 1191)에 명시된 최대 전송 단위(MTU)에서 28바이트를 뺀 값과 동일하게 설정한다. 이는 IP(Internet Protocol) 헤더가 20바이트이고, UDP(User Datagram Protocol) 헤더가 8바이트를 차지하기 때문이다. 예를 들면, X.25 프로토콜을 사용할 시는 RTP 패킷의 크기는 548(576-28)바이트가 되며, 이더넷(Ethernet)을 사용할 때는 1472(1500-28)바이트가 RTP 패킷의 크기가 된다. 또한, RTP 헤더는 최소 16바이트인데 확장 헤더 등을 고려하여 20 바이트로 설정한다. 따라서, RTP 패킷 페이로드(payload)의 크기는 최대 전송 단위(MTU)에서 각종 헤더 정보를 위해 사용되는 공간을 제외한 부분이 된다.
도 2 는 일반적인 프로토콜 스택에서의 전송 단위(Transfer Unit)에 대한 일실시예 구조도이다.
도 2 에 도시된 바와 같이, 엠펙(MPEG)-4 압축 계층(Compression Layer)(210), RTP 계층(RTP Layer)(220), UDP 계층(UDP Layer)(230), 그리고 IP 계층(Internet Protocol Layer)(240)은 프로토콜 스택의 각 계층을 나타낸다.
상기 엠펙(MPEG)-4 압축 계층(Compression Layer)(210)에서는 엠펙-4 데이터(211)를 만들고, 상기 RTP 계층(RTP Layer)(220)에서는 상기 엠펙(MPEG)-4 압축 계층(Compression Layer)(210)에서 만들어진 엠펙-4 데이터(211)에 RTP 헤더(221)를 첨부한다. 그리고, 상기 UDP 계층(UDP Layer)(230)에서는 상기 RTP 계층(RTP Layer)(220)에서 만들어진 RTP 헤더(232), 엠펙(MPEG)-4 데이터(233)에 UDP 헤더(231)를 붙이고, 상기 IP 계층(240)에서는 상기 UDP 계층(230)에서 만들어진 UDP 헤더, RTP 헤더, 엠펙(MPEG)-4 데이터의 구조에 IP헤더(241)를 부가한다.
상기 과정은 엠펙(MPEG)-4 압축 계층(210)에서 IP 계층(240)까지 순서대로 진행되며, 특히 상기 IP 계층에서 만들어진 구조의 크기가 최대 전송 단위(MTU)보다 작아야 된다.
상기 엠펙(MPEG)-4 데이터(211, 222, 233, 244)는 실제의 유료정보인 엠펙(MPEG)-4 비디오 스트림을 나타내는데, 상기 정보가 RTP 페이로드(payload) 부분이 된다.
RTP 헤더(header)(221, 232, 243)는 RTP 패킷의 헤더 부분을 나타내는 것으로 확장 헤더까지 고려하여 20바이트의 크기를 갖는다.
UDP 헤더(header)(231, 242)는 UDP 패킷 헤더를, IP 헤더(header)(241)는 IP 패킷 헤더를 나타낸다.
한편, 본 발명은 엠펙(MPEG)-4 요소 스트림(Elementary Stream)의 계층적 구조를 고려하지 않고, 복호화의 기본 단위가 되는 기본 계층(base layer)에 해당하는 비디오 객체(Video Object)에 대한 RTP 페이로드(payload) 포맷만을 정의하여 페이로드(payload) 포맷의 정의를 최소화하여 부가적인 오버헤드를 줄이고, 비디오 객체(Video Object)에 대한 페이로드(payload) 포맷만을 정의함으로써, 복원된(unpacketized) 비디오 스트림에 대한 독립적인 복호화를 보장하고자 하는 것이다.
도 3 은 본 발명에 따른 RTP 패킷의 일실시예 구조도이다.
엠펙(MPEG)-4 요소 스트림(Elementary Stream)의 기본 계층(base layer)인 비디오 객체(Video Object)에 대한 RTP 페이로드(payload) 포맷을 정의하는 전략은 다음과 같이 한다.
첫째, 하나의 패킷에는 단 하나의 비디오 객체(Video Object)에 대한 정보만을 저장하여 비디오 객체(Video Object)간의 종속성을 배제한다.
둘째, 비디오 객체(Video Object)가 패킷의 페이로드(payload) 부분과 크기가 같거나 작으면, 상기 비디오 객체(Video Object)를 하나의 패킷에 패킷화한다.
셋째, 비디오 객체(Video Object)가 패킷의 페이로드(payload) 부분보다 크면 패킷의 페이로드(payload) 크기만큼 비디오 객체(Video Object)를 패킷화한다. 이후, 패킷화되지 않은 비디오 객체(Video Object)의 나머지 부분이 없을 때까지 이 과정을 반복한다. 그리고, 뒤따라오는 패킷이 동일한 비디오 객체(Video Object)에 대한 정보인지를 나타내기 위해 RTP 헤더의 마커(Marker) 비트를 이용한다. 즉, 상기 마커(Marker) 비트가 0이면 연속되는 패킷이 동일한 비디오 객체(video Object)에 대한 정보임을 나타내고, 1인 경우 뒤따라오는 패킷은 다른 비디오 객체(Video Object)에 대한 정보임을 나타낸다.
넷째, 패킷화를 위한 최소단위는 바이트 단위로 한다 즉, RTP 페이로드(payload)에 수용 가능한 바이트 수만큼 패킷화함으로써 바이트 정렬 방식을 사용한다.
다섯째, 비디오 객체(Video Object)의 마지막 부분을 담은 패킷의 페이로드(payload) 부분이 다 차지 않아 가용한 공간이 있다 할지라도, 이 패킷에는 또 다른 비디오 객체(Video Object)를 위한 패킷화를 하지 않고, 나머지 부분을 패딩(padding) 바이트로 채운다. 이는 인접한 비디오 객체(Video Object) 간의 독립성을 유지하기 위함이다.
RTP 페이로드(payload) 포맷 정의 전략에 의한 패킷화 알고리즘의 일예는 다음과 같다.
[알고리즘]
procedure packetize;
begin
while ( there is encoded data to be packetized ) do
begin
search next VO_start_code
and count the number of bytes;
if ( (next VO_start_code is found) and (ByteCount MaxPL) )
then packetize the bytes before next VO_start_code);
else if ( ByteCount > MaxPL )
then packetize as many bytes as possible without exceeding MaxPL
and crossing into next VideoObject;
else packetize the remaining data;
end; {of while}
end; {of packetize}
상기 [알고리즘]에서 사용되는 파라메터와 기능은 다음과 같다.
"ByteCount"는 현재 패킷화가 진행되는 비디오 객체(Video Object)의 총 바이트 수이고, 하나의 RTP 패킷이 완성된 후에는 완성된 바이트 수 만큼 감소하게 된다.
"MaxPL(Maximum Payload Length)"은 하나의 패킷 안에 수용 가능한 페이로드(payload)의 길이를 뜻한다.
"VO_start_code"는 비디오 객체(Video Object)의 시작코드를 의미한다.
도 3 에 도시된 바와 같이, 비디오 객체 헤더(Video Object header)(312, 322)와 비디오 객체(Video Object)(313, 323, 325)는 엠펙(MPEG)-4 데이터(205)에 해당하는 부분으로, 비디오 객체 헤더(VO header)는 엠펙(MPEG)-4 비디오 스트림에서 비디오 객체(Video Object)의 헤더를 나타낸다.
도면에서 "310" 구조는 하나의 패킷에 하나의 비디오 객체(Video Object)에 대한 모든 정보를 다 수용할 수 있을 때 가능한 모델이고, "320" 구조는 하나의 패킷에 하나의 비디오 객체(Video Object)에 대한 정보를 모두 수용할 수 없을 때 세 크먼트로 분할하여 수용하는 모델이다. 이 때, 동일한 비디오 객체(Video Object)에 대한 정보를 갖는 마지막 패킷에 다른 비디오 객체(Video Object)를 위한 가용한 공간이 존재하더라도 인접한 비디오 객체(Video Object) 간의 독립성을 유지하기 위해 패딩(padding) 바이트로 채운다.
도 4 는 본 발명에 따른 비디오 스트림의 패킷화 방법에 대한 일실시예 흐름도이다.
먼저, 연속된 비디오 객체(Video Object)를 입력받아(401), 상기 입력된 비디오 객체의 시작 코드를 검색한다(402). 그리고, 지금 처리해야 하는 비디오 객체의 패킷화를 수행하지 않은 남은 바이트 수(ByteCount)를 계산하고(403), 다음 비디오 객체의 시작코드가 있고 비디오 객체의 패킷화를 수행하지 않은 바이트 수(ByteCount)가 페이로드 길이의 최대값(MaxPL)보다 작거나 같은지를 판단한다(404).
상기 판단 결과(404), 다음 비디오 객체의 시작코드가 있고 비디오 객체의 패킷화를 수행하지 않은 바이트 수(ByteCount)가 페이로드 길이의 최대값(MaxPL)보다 작거나 같으면 다음 비디오 객체 시작 코드 전까지 비디오 객체를 패킷화하고 패킷화시킬 비디오 데이터가 더 있는지 확인하는 과정(409)으로 진행한다. 이때, 다음 비디오 객체에 대해서는 동일한 패킷에 넣지 않는다.
상기 판단 결과(404), 다음 비디오 객체의 시작코드가 있고 비디오 객체의 패킷화를 수행하지 않은 바이트 수(ByteCount)가 페이로드 길이의 최대값(MaxPL)보다 작거나 같은 경우가 아니면, 페이로드 길이 최대값(MaxPL)을 초과하지 않는 범 위에서 가능한 바이트 수만큼 패킷화를 수행한다(406). 그리고, 다시 비디오 객체의 패킷화를 수행하지 않은 남은 바이트 수(ByteCount)가 페이로드 길이의 최대값(MaxPL)보다 큰가를 판단한다(407).
상기 판단 결과(407), 비디오 객체의 패킷화를 수행하지 않은 남은 바이트 수(ByteCount)가 페이로드 길이의 최대값(MaxPL)보다 크면 페이로드 길이 최대값(MaxPL)을 초과하지 않는 범위에서 가능한 바이트 수만큼 패킷화를 수행하는 과정(406)으로 진행한다.
상기 판단 결과(407), 비디오 객체의 패킷화를 수행하지 않은 남은 바이트 수(ByteCount)가 페이로드 길이의 최대값(MaxPL)보다 크지 않으면 비디오 객체의 패킷화되지 않은 남은 데이터를 패킷화하고(408), 패킷화시킬 비디오 데이터가 더 있는지를 확인하는 과정(409)으로 진행한다. 여기서도 다음 비디오 객체에 대해서는 동일한 패킷에 넣지 않는다.
한편, 패킷화시킬 비디오 데이터가 더 있는지를 확인하여(409), 패킷화시킬 비디오 데이터가 있으면 비디오 객체의 시작 코드를 검색하는 과정(402)으로 진행하고, 아니면 종료한다.
상술한 바와 같은 본 발명의 방법은 프로그램으로 구현되어 컴퓨터로 읽을 수 있는 형태로 기록매체(씨디롬, 램, 롬, 플로피 디스크, 하드 디스크, 광자기 디스크 등)에 저장될 수 있다.
이상에서 설명한 본 발명은 전술한 실시예 및 첨부된 도면에 의해 한정되는 것이 아니고, 본 발명의 기술적 사상을 벗어나지 않는 범위 내에서 여러 가지 치 환, 변형 및 변경이 가능하다는 것이 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 있어 명백할 것이다.
상기한 바와 같은 본 발명은, 다양한 접속 환경이 존재하는 인터넷에서 고품질의 영상을 제공하기 위하여 비디오 스트림의 전송을 위한 프로토콜로서 RTP를 이용함으로써 순수한 UDP를 이용할 때의 단점을 제거하였고, 복호화의 기본 단위가 되는 기본 계층(base layer)에 해당하는 비디오 객체(Video Object)에 대한 RTP 페이로드(payload) 포맷만을 정의하여 페이로드(payload) 포맷의 정의를 최소화하여 부가적인 오버헤드를 줄이고, 복원된(unpacketized) 비디오 스트림에 대한 독립적인 복호화를 보장할 수 있는 효과가 있다.
또한, 본 발명은 비디오 스트림과 RTP를 이용한 인터넷 상에서의 고화질 영상과 실시간성을 보장하는 전송시스템을 구축할 수 있는 효과가 있다.

Claims (7)

  1. 비디오 스트림의 RTP(Real Time transfer Protocol) 패킷화 방법에 있어서,
    가변적인 크기를 가지는 RTP 패킷의 크기를 결정하는 단계;
    상기 크기를 결정한 RTP 패킷의 페이로드에 적어도 하나의 비디오 객체로 이루어진 비디오 스트림을 비디오 객체 단위로 할당하는 비디오 객체 단위의 비디오 스트림 할당 단계;
    연속된 RTP 패킷이 동일한 비디오 객체에 대한 정보인지, 아니면 다른 비디오 객체에 대한 정보인지를 표시하는 정보 표시 단계; 및
    상기 할당한 비디오 객체를 RTP 패킷의 페이로드에 수용하고, 상기 표시정보를 RTP 패킷의 헤더에 수용하는 단계
    를 포함하는 비디오 스트림의 RTP 패킷화 방법.
  2. 제 1 항에 있어서,
    상기 비디오 객체 단위의 비디오 스트림 할당 단계는,
    비디오 객체의 시작 코드를 검색하여 해당 비디오 객체의 바이트 수를 계산하는 단계;
    상기 계산한 비디오 객체의 바이트 수가 RTP 패킷의 페이로드 길이를 초과하는지 판단하는 단계;
    상기 판단 결과, 초과하지 않으면 상기 비디오 객체를 RTP 패킷화하는 단계; 및
    상기 판단 결과, 초과하면 상기 비디오 객체를 RTP 패킷의 페이로드 길이만큼씩 분할하여 다수의 RTP 패킷으로 패킷화하는 분할 패킷화 단계
    를 포함하는 비디오 스트림의 RTP 패킷화 방법.
  3. 제 1 항에 있어서,
    상기 정보 표시 단계는,
    마커비트(Marker bit)를 이용하여 연속되는 RTP 패킷이 동일한 비디오 객체인지 다른 비디오 객체인지를 표시하는 것을 특징으로 하는 비디오 스트림의 RTP 패킷화 방법.
  4. 제 2 항에 있어서,
    상기 분할 패킷화 단계는,
    상기 비디오 객체를 RTP 패킷의 페이로드 길이만큼씩 분할하고 남은 최종 비디오 객체의 바이트 수가 RTP 패킷의 페이로드 길이보다 작은 경우 다른 비디오 객체를 혼합하여 패킷화하지 않는 것을 특징으로 하는 비디오 스트림의 RTP 패킷화 방법.
  5. 제 1 항 내지 제 4 항 중 어느 한 항에 있어서,
    상기 비디오 객체는,
    엠펙(MPEG)-4에서의 기본 계층(base layer)인 것을 특징으로 하는 비디오 스트림의 RTP 패킷화 방법.
  6. 대용량 프로세서를 구비한 알티피(RTP) 패킷화 장치에,
    가변적인 크기를 가지는 RTP 패킷의 크기를 결정하는 기능;
    상기 크기를 결정한 RTP 패킷의 페이로드에 적어도 하나의 비디오 객체로 이루어진 비디오 스트림을 비디오 객체 단위로 할당하는 비디오 객체 단위의 비디오 스트림 할당 기능;
    연속된 RTP 패킷이 동일한 비디오 객체에 대한 정보인지, 아니면 다른 비디오 객체에 대한 정보인지를 표시하는 정보 표시 기능; 및
    상기 할당한 비디오 객체를 RTP 패킷의 페이로드에 수용하고, 상기 표시정보를 RTP 패킷의 헤더에 수용하는 기능
    을 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록매체.
  7. 삭제
KR1020000077100A 2000-12-15 2000-12-15 비디오 스트림의 알티피 패킷화 방법 KR100739308B1 (ko)

Priority Applications (1)

Application Number Priority Date Filing Date Title
KR1020000077100A KR100739308B1 (ko) 2000-12-15 2000-12-15 비디오 스트림의 알티피 패킷화 방법

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020000077100A KR100739308B1 (ko) 2000-12-15 2000-12-15 비디오 스트림의 알티피 패킷화 방법

Publications (2)

Publication Number Publication Date
KR20020046770A KR20020046770A (ko) 2002-06-21
KR100739308B1 true KR100739308B1 (ko) 2007-07-12

Family

ID=27682283

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020000077100A KR100739308B1 (ko) 2000-12-15 2000-12-15 비디오 스트림의 알티피 패킷화 방법

Country Status (1)

Country Link
KR (1) KR100739308B1 (ko)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR19990027052A (ko) * 1997-09-27 1999-04-15 구자홍 인터넷에서의 엠펙 티피 패킷 전송 방법
KR19990037501A (ko) * 1997-10-30 1999-05-25 마사키 우에닷 분배형 인터넷 프로토콜 기반의 실시간 멀티미디어 스트리밍 아키텍쳐
KR100243187B1 (ko) * 1996-01-20 2000-02-01 윤종용 분산 멀티미디어 서버
JP2000078573A (ja) * 1998-09-03 2000-03-14 Hitachi Ltd 階層符号化データ配信装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100243187B1 (ko) * 1996-01-20 2000-02-01 윤종용 분산 멀티미디어 서버
KR19990027052A (ko) * 1997-09-27 1999-04-15 구자홍 인터넷에서의 엠펙 티피 패킷 전송 방법
KR19990037501A (ko) * 1997-10-30 1999-05-25 마사키 우에닷 분배형 인터넷 프로토콜 기반의 실시간 멀티미디어 스트리밍 아키텍쳐
JP2000078573A (ja) * 1998-09-03 2000-03-14 Hitachi Ltd 階層符号化データ配信装置

Also Published As

Publication number Publication date
KR20020046770A (ko) 2002-06-21

Similar Documents

Publication Publication Date Title
Hoffman et al. RTP payload format for MPEG1/MPEG2 video
US7372858B2 (en) Data transmission device and data transmission method
RU2518383C2 (ru) Способ и устройство для переупорядочивания и мультиплексирования мультимедийных пакетов из мультимедийных потоков, принадлежащих взаимосвязанным сеансам
US6580756B1 (en) Data transmission method, data transmission system, data receiving method, and data receiving apparatus
US20090003389A1 (en) Saf Synchronization Layer Packet Structure and Server System Therefor
US7764708B2 (en) Data transmission system, header-information adding device, data-format converting device, and data transmission method
AU2012207704B2 (en) Apparatus and method for transmitting multimedia data in a broadcast system
KR20050052531A (ko) Ip 네트워크를 통해 스캐일 가능한 코드화된 비디오를전송하기 위한 시스템 및 방법
JP2000078573A (ja) 階層符号化データ配信装置
WO2007045140A1 (fr) Methode en temps reel pour transferer des donnees multimedia
EP1936908A1 (en) Method, apparatus and data container for transferring high resolution audio/video data in a high speed IP network
Herpel et al. MPEG-4 Systems: Elementary stream management
US20170171365A1 (en) Method for encoding and decoding scheme using time stamp
WO2010049312A1 (en) Data container for transferring high resolution audio/video data in a high speed ip network
EP2039155A1 (en) Method for transforming terrestrial dmb contents and gateway employing the same
KR100762718B1 (ko) Mpeg-4 데이터 스트림들을 인터넷 네트워크에 적합시키는 전처리 방법
US7860366B2 (en) Information processing device and method, recording medium, and program
JP2001148853A (ja) 動画像符号化装置および復号化装置
KR100739308B1 (ko) 비디오 스트림의 알티피 패킷화 방법
JP2004519908A (ja) Mpeg4ビデオデータを符号化する方法及び装置
KR20050037847A (ko) 멀티미디어 스트리밍 시스템에서의 에러 검출 방법
Herpel et al. MPEG-4 systems: elementary stream management and delivery
Paik et al. Media-aware scheduling method for transmitting signalling message over MPEG media transport-based broadcast
Ohlenroth et al. RTP packetization of MPEG-4 elementary streams
WO2009037113A1 (en) Method, server and client apparatuses for transferring high resolution multimedia data in a high speed network

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20120702

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20130701

Year of fee payment: 7

LAPS Lapse due to unpaid annual fee