KR20100012830A - Ｒｔｐ 패킷들을 포함하는 데이터 스트림, 그러한 데이터 스트림을 인코딩/디코딩하기 위한 방법 및 디바이스 - Google Patents

Ｒｔｐ 패킷들을 포함하는 데이터 스트림, 그러한 데이터 스트림을 인코딩/디코딩하기 위한 방법 및 디바이스 Download PDF

Info

Publication number
KR20100012830A
KR20100012830A KR1020090068257A KR20090068257A KR20100012830A KR 20100012830 A KR20100012830 A KR 20100012830A KR 1020090068257 A KR1020090068257 A KR 1020090068257A KR 20090068257 A KR20090068257 A KR 20090068257A KR 20100012830 A KR20100012830 A KR 20100012830A
Authority
KR
South Korea
Prior art keywords
packet
data
layer
rtp
rtp packet
Prior art date
Application number
KR1020090068257A
Other languages
English (en)
Other versions
KR101650571B1 (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 톰슨 라이센싱
Publication of KR20100012830A publication Critical patent/KR20100012830A/ko
Application granted granted Critical
Publication of KR101650571B1 publication Critical patent/KR101650571B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing 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/234327—Processing 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/85—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression
    • H04N19/89—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using pre-processing or post-processing specially adapted for video compression involving methods or arrangements for detection of transmission errors at the decoder
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440227—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/6437—Real-time Transport Protocol [RTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

에러가 발생하기 쉬운 송신 채널을 통한 송신 동안의 패킷 손실의 경우에, 일부 디코더들은 에러 은폐를 수행할 수 있다. 실시간 시스템들에서, 애플리케이션 디코더들은 데이터 손실을 단독으로 취급하여 어느 데이터가 누락되어 있는지를 찾아내야 한다. 패킷들이 멀티-레이어 애플리케이션 디코더에 공급되기 이전에, RTP 패킷들과 이들이 나르는 애플리케이션 레이어 데이터간의 관계를 식별하고 표시하는 것에 기초하는 패킷-기반 프레임워크 내의 특별 구문이 제공된다. 이것은 디코더가 에러 은폐 기술들을 제때에 활용하는데 도움을 주고, 디코더에서의 불필요한 처리를 방지한다. 데이터 스트림은 멀티-레이어 애플리케이션의 애플리케이션 데이터를 포함하는 RTP 패킷들을 포함하고, 여기에서 RTP 패킷(p2)은 2가지 종류의 애플리케이션 레이어 정보(NBf, NBn), 즉 다음 RTP 패킷(p3)과 관련된 하나 및 이전 RTP 패킷(p1)과 관련된 하나를 포함한다. 패킷 손실의 경우에, 디코더는 누락 데이터의 양 및 타입(VCLx)을 즉시 결정할 수 있다.
패킷 손실, 디코더, RTP 패킷, 데이터 스트림, 인코딩, 디코딩

Description

ＲＴＰ 패킷들을 포함하는 데이터 스트림, 그러한 데이터 스트림을 인코딩/디코딩하기 위한 방법 및 디바이스{DATA STREAM COMPRISING RTP PACKETS, AND METHOD AND DEVICE FOR ENCODING/DECODING SUCH DATA STREAM}
본 발명은 멀티-레이어 애플리케이션의 애플리케이션 데이터를 포함하는 패킷화된 실시간 프로토콜(real-time protocol : RTP) 데이터 스트림들에 관한 것이다. 특히, 본 발명은 RTP-기반 스케일링가능한 비디오 송신(RTP-based scalable video transmission)에 관한 것이다.
스케일링가능한 비디오, 스케일링가능한 오디오 등과 같은 다양한 멀티-레이어 멀티미디어 애플리케이션들이 존재한다. 멀티미디어 데이터는 종종 패킷화된 데이터 스트림들을 통해 송신되고, 그럼으로써 개별 레이어들의 멀티미디어 데이터는 시간-멀티플렉싱되어 단일 데이터 스트림이 된다. 특히, H.264/AVC 표준의 스케일링가능한 비디오 코딩(SVC) 익스텐션(extension)은 3가지의 스케일러빌리티(scalability) 타입들, 즉 시간, 공간(spatial) 및 품질을 채택한다. 시간 스케일러빌리티는 H.264/AVC에서 잘 지원되고, SVC의 베이스 레이어는 H.264/AVC를 따르도록 의도적으로 설계된다.
통상 인터넷 및 모바일 네트워크들을 통한 실시간 비디오 송신은 RTP/IP에 기초하고 있다. IETF는 SVC 비디오에 대해 RTP 페이로드 포맷을 제안했다. 그러나, RTP-기반 SVC 비트스트림들의 디코딩 및 렌더링을 용이하게 하기 위해 추가 개선들이 만들어졌고, 그럼으로써 송신 스킴은 일반적인 표준 디코더들과의 호환성이 유지될 수 있다.
디코더들은 일부 초기 정보, 예를 들면 스케일링가능한 비디오의 경우에 전체 공간 및 품질 스케일러빌리티 레이어들의 수를 필요로 할 수 있다. 이러한 초기 정보는 디코더가, 예를 들면 메모리 할당 및 관련된 파라미터 구성을 초기화하는데 도움을 줄 수도 있다. 레이어 종속성 또는 프레임 타입과 같은 다른 정보도 또한 디코더들이 더 효율적이고 안정적으로 되는데 도움을 줄 수 있다.
그러나, 송신 채널들은 종종 에러가 발생하기 쉽다. 그러한 에러가 발생하기 쉬운 채널을 통한 송신 동안의 패킷 손실의 경우에, 일부 디코더들은 에러 은폐 프로세스(error concealment process)를 수행할 수 있다. 그러나, 디코더들은 종종 RTP와 같은 트랜스포트 스트림의 포맷에 의존한다. 예를 들면, 표준 RTP 헤더는 타이밍 정보 및 RTP 패킷 번호를 포함하고, 이들은 패킷들이 정확한 순서로 디코딩되는 것을 보장하는데 이용될 수 있다. 그러나, 패킷이 손실되는지를 검출하기 위해 추가 프로토콜이 필요하다. 보통의 인터넷 애플리케이션들에 대해 TCP가 이용되는데, TCP는 실시간 애플리케이션들에 대해 너무 느리다. 그러므로, 실시간 지원가능 시스템들에서, 애플리케이션 디코더는 데이터 손실 상황을 취급해야만 하고, 혼자서 어느 데이터가 누락되는지를 찾아내야만 한다. 이것은 애플리케이션 디코더를 교란시킬 수 있고 일부 경우에 심지어 재-초기화를 요구할 수도 있다.
멀티-레이어 애플리케이션들에 대해, 애플리케이션 디코더는 손실된 데이터 패킷의 타입 및 관련된 애플리케이션 레이어에 좌우되어, 데이터 손실에 대응하기 위한 상이한 옵션들을 가지고 있다는 것이 발견되었다. 그러나, 통상적으로 누락된 패킷이 어느 애플리케이션 레이어에 속하는지는 알려져 있지 않다. 종래의 멀티-레이어 애플리케이션 디코더는 그러한 상황을 복원하기 위한 어느 정도의 처리 시간을 필요로 한다. 손실된 데이터의 타입을 더 빨리 알게 될수록, 디코더가 더 잘 대응할 수 있다. 본 발명이 해결하고자 하는 하나의 과제는 트랜스포트 패킷 손실의 경우에, 특히 관련된 애플리케이션의 측면에서 손실된 데이터의 타입에 관한 더 빠르고 더 상세한 정보를 디코더에게 제공하는 것이다.
본 발명은 패킷들이 멀티-레이어 애플리케이션 디코더에 공급되기 이전에 RTP 패킷들과 이들이 나르는 애플리케이션 레이어/프레임간의 관계를 식별하고 표시하는 것에 기초하는 패킷-기반 프레임워크 내의 특별한 구문(special syntax)을 제공한다. 이것은 디코더가 적절한 에러 은폐 기술들을 제때에 활용하는데 도움을 주고 디코더에서의 불필요한 처리를 방지한다.
본 발명은 상기 언급된 문제들을 해결하는 데이터 스트림 포맷, 대응하는 인코딩 방법 및 디바이스, 및 디코딩 방법 및 디바이스를 제공한다.
본 발명의 하나의 양태에 따르면, 데이터 스트림은 멀티-레이어 애플리케이션의 애플리케이션 데이터를 포함하는 RTP 패킷들을 포함하고, 여기서 적어도 하나의 RTP 패킷은 다음 RTP 패킷의 콘텐츠와 관련된 제1 애플리케이션 레이어 정보 및 이전 RTP 패킷의 콘텐츠와 관련된 제2 애플리케이션 레이어 정보를 (송신 순서대로) 포함한다.
본 발명의 또 하나의 양태에 따르면, RTP 패킷들을 이용하여 멀티-레이어 애플리케이션 데이터를 인코딩하기 위한 방법은, 멀티-레이어 애플리케이션 데이터의 제1, 제2 및 제3 부분을 각각 제1, 제2 및 제3 RTP 패킷에 팩킹(packing)하는 단계 - 애플리케이션 데이터의 제1, 제2 및 제3 부분은 애플리케이션의 제1, 제2 및 제3 레이어를 표시(refer)함 -, 제1 패킷이 표시하는 애플리케이션의 제1 레이어를 정의하는 적어도 제1 데이터 및 제3 패킷이 표시하는 애플리케이션의 제3 레이어를 정의하는 제2 데이터를 제2 RTP 패킷에 추가하는 단계, 및 제1, 제2 및 제3 RTP 패킷을 (이 송신 순서대로) 송신하는 단계를 포함한다.
RTP 패킷들을 이용하여 멀티-레이어 애플리케이션 데이터를 인코딩하기 위한 각 디바이스는 멀티-레이어 애플리케이션 데이터의 제1, 제2 및 제3 부분을 각각 제1, 제2 및 제3 RTP 패킷에 팩킹하기 위한 삽입 수단 - 애플리케이션 데이터의 제1, 제2 및 제3 부분은 애플리케이션의 제1, 제2 및 제3 레이어를 표시함 -, 제1 패킷이 표시하는 애플리케이션의 제1 레이어를 정의하는 적어도 제1 데이터 및 제3 패킷이 표시하는 애플리케이션의 제3 레이어를 정의하는 제2 데이터를 제2 RTP 패킷에 추가하기 위한 삽입 수단, 및 제1, 제2 및 제3 RTP 패킷을 (이 송신 순서대 로) 송신하기 위한 송신 수단을 포함한다. 멀티-레이어 애플리케이션 데이터의 제1, 제2 및 제3 부분을 제1, 제2 및 제3 RTP 패킷에 팩킹하기 위한 삽입 수단은 하나, 둘 또는 모두 3개의 RTP 패킷들을 순차적으로 또는 동시에 처리할 수 있다. 제2 RTP패킷에 데이터를 추가하기 위한 삽입 수단은 제1 데이터 및 제2 데이터를 순차적으로 또는 동시에 처리하여 제2 패킷에 삽입할 수 있다.
본 발명의 또 하나의 양태에 따르면, 멀티-레이어 애플리케이션 데이터를 포함하는 RTP 패킷들의 디코딩(또는 디코딩을 준비하는 방식)을 위한 방법은, 적어도 제1 및 후속되는 제2 RTP 패킷을 수신하는 단계, 제1 RTP 패킷의 보디로부터 멀티-레이어 애플리케이션 데이터의 제1 부분을 추출하고 제1 RTP 패킷의 패딩(padding) 바이트들로부터 제1 이웃 정보를 추출하는 단계, 제2 RTP 패킷의 보디로부터 멀티-레이어 애플리케이션 데이터의 제2 부분을 추출하고 제2 RTP 패킷의 패딩 바이트들로부터 제2 이웃 정보를 추출하는 단계, 제1 RTP 패킷 및 제2 RTP 패킷에서 멀티-레이어 애플리케이션 데이터의 타입을 결정하는 단계, 제2 RTP 패킷의 멀티-레이어 애플리케이션 데이터의 결정된 타입과 제1 RTP 패킷으로부터 추출된 제1 이웃 정보를 비교하는 것과, 제1 RTP 패킷의 멀티-레이어 애플리케이션 데이터의 결정된 타입과 제2 RTP 패킷으로부터 추출된 제2 이웃 정보를 비교하는 것 중 어느 하나를 수행하거나 또는 양쪽을 수행하는 단계, 제1 RTP 패킷으로부터 추출된 제1 이웃 정보와 제2 RTP 패킷으로부터 추출된 제2 이웃 정보를 비교하는 단계, 및 상기 추출 단계 및 비교 단계의 결과들을 상기 멀티-레이어 애플리케이션을 위한 디코더에 제공하는 단계를 포함한다.
멀티-레이어 애플리케이션 데이터를 포함하는 RTP 패킷들을 디코딩하기(디코딩을 준비하기) 위한 각 디바이스는, 적어도 제1 및 후속되는 제2 RTP 패킷을 수신하기 위한 수신 수단, 제1 RTP 패킷의 보디로부터 멀티-레이어 애플리케이션 데이터의 제1 부분을 추출하고 제1 RTP 패킷의 패딩 바이트들로부터 제1 이웃 정보를 추출하기 위한 제1 추출 수단, 제2 RTP 패킷의 보디로부터 멀티-레이어 애플리케이션 데이터의 제2 부분을 추출하고 제2 RTP 패킷의 패딩 바이트들로부터 제2 이웃 정보를 추출하기 위한 제2 추출 수단, 제1 RTP 패킷 및 제2 RTP 패킷에서 멀티-레이어 애플리케이션 데이터의 타입을 결정하기 위한 결정 수단, 제2 RTP 패킷의 멀티-레이어 애플리케이션 데이터의 결정된 타입과 제1 RTP 패킷으로부터 추출된 제1 이웃 정보를 비교하거나, 제1 RTP 패킷의 멀티-레이어 애플리케이션 데이터의 결정된 타입과 제2 RTP 패킷으로부터 추출된 제2 이웃 정보를 비교하거나 또는 양쪽 모두를 수행하기 위한 제1 비교 수단, 제1 RTP 패킷으로부터 추출된 제1 이웃 정보와 제2 RTP 패킷으로부터 추출된 제2 이웃 정보를 비교하기 위한 제2 비교 수단, 및 제1 및 제2 추출 수단 및 제1 및 제2 비교 수단의 결과들을 상기 멀티-레이어 애플리케이션을 위한 디코더에 제공하기 위한 제공 수단을 포함한다.
예시적으로, 멀티-레이어 애플리케이션 데이터는 베이스 레이어(base layer) 및 하나 또는 그 이상의 인핸스먼트 레이어(enhancement layers)를 구비하는 계층적 데이터일 수 있다.
본 발명의 양호한 실시예들이 종속 청구항들, 이하의 설명 및 도면들에 개시되어 있다.
도 1은 패킷화된 데이터 스트림의 구조를 도시하고 있다. 데이터 스트림의 연속적인 패킷들 p1, p2, p3은 멀티-레이어 애플리케이션의 애플리케이션 데이터를 포함하는데, 제1 패킷 p1은 제1 애플리케이션 레이어 VCLp의 애플리케이션 데이터를 포함하며, 후속하는 제2 및 제3 패킷들 p2, p3은 각각 제2 애플리케이션 레이어 VCLc 및 제3 애플리케이션 레이어 VCLn의 애플리케이션 데이터를 포함한다. 도시된 바와 같이, 패킷들은 바로 이웃하는 시퀀스로 송신/수신된다. 예를 들면 실시간 프로토콜(RTP)이 트랜스포트 프로토콜로서 이용되는 경우, 패킷들은 RTP 패킷 번호들을 가지고 있다. 그러므로, 수신기는 패킷들을 그들의 정확한 시퀀스 순서로 가져올 수 있지만, 만약 예를 들면 제2 패킷 p2가 송신 동안에 손실되는 경우에 디코더는 누락된 데이터가 어느 애플리케이션 레이어에 속하는지 알지 못할 것이다. 본 발명에서, 디코딩 및 에러 은폐의 효율을 개선하기 위해, 트랜스포트 패킷들의 오버헤드에 더 많은 정보를 추가하는 스킴이 제안된다. 이것은 디코더들이 더 유연한 방식으로 대응할 수 있게 한다. 예를 들면, 디코더는 누락된 패킷이 멀티-레이어 애플리케이션의 인핸스먼트 레이어에 속한다는 것을 발견할 수 있고 결과적으로 베이스 레이어를 계속해서 디코딩할 수 있다. 그러므로, 종래에는 애플리케이션이 중단되었을 상황에서도 사용자는 일시적인 품질 손실만을 경험하게 될 것이다. 대신에, 애플리케이션은 기본 모드로, 예를 들면 더 낮은 해상도로 계속해서 운용된다.
도 1에 도시된 바와 같이, 본 발명은 멀티-레이어 애플리케이션의 애플리케이션 데이터를 구비하는 트랜스포트 패킷이 그 자신의 레이어뿐만 아니라, 2가지 종류의 이웃 정보, 즉 선행하는 (f=이전) 트랜스포트 패킷의 애플리케이션 데이터의 레이어 VCLf를 지정하는 하나의 NBf 및 후속하는 (n=다음) 트랜스포트 패킷의 애플리케이션 데이터의 레이어 VCLn를 지정하는 하나의 NBn도 지정하는 정보를 포함한다. 그러므로, 가장 가능성있는 경우인 하나 또는 2개의 RTP 패킷이 손실된 경우에 어떤 타입의 애플리케이션 데이터가 누락되어 있는지를 알아내는 것이 가능하다.
이하에서, SVC 기반 실시예들이 설명된다. 상기 설명된 바와 같이, 본 발명은 또한 다른 멀티-레이어 멀티미디어 애플리케이션들에도 적용가능하다. 임의의 다른 비디오 디코더와 같이, SVC 디코더는 송신 에러들에 민감하다. RTP를 기반으로 하는 SVC 비디오 송신에 대해, 어떠한 실효적 에러 은폐 기술들도 이용되지 않는 경우에 패킷 손실은 디코더에 중대 장애를 일으킬 수 있다. 거의 모든 에러 은폐 방법에 대해, 손실된 데이터가 어느 슬라이스/레이어/프레임에 속하는지를 신속하게 아는 것이 매우 중요하다. 이것은 전통적으로 수신된 패킷들을 디코딩함으로써 결정될 수 있지만, 이것은 불필요하게 복잡한 접근법으로 보인다. 또한, 이것은 디코더에서 소프트웨어 문제, 예를 들면 크래시(crash)의 위험을 야기한다. 추가적인 문제의 양태는 패킷 포맷의 변경을 요구하지 않으면서 RTP와 같은 기존 시스템들에 대한 솔루션이 필요하다는 것이다.
본 발명에 따르면, 데이터가 SVC 디코더에 공급되기 이전에 수신기가 손실된 패킷들의 식별 정보를 얻는 것을 돕기 위해, RTP 패킷들의 패딩 바이트들에 몇몇 오버헤드 정보가 삽입된다. 그 결과, 디코더는 상이한 솔루션들로 어떻게 진행할지를 종래 방법들보다 더 일찍 결정할 수 있다. 예를 들면, 하나의 가능한 대응은 손실된 패킷이 관련된 전체 슬라이스를 폐기하고 대신에 이전 픽쳐의 같이 로케이팅된(co-located) 슬라이스를 이용하는 것, 예를 들면 같이 로케이팅된 슬라이스를 현재 픽쳐 버퍼에 복사하는 것이다.
양호하게도, 이것은 디코더의 안정된 처리 및 불필요한 계산의 감소를 의미한다.
식별 정보를 패딩 바이트들에 넣음으로써, 스킴은 패딩 바이트들, 따라서 식별 정보를 완전히 무시하는 일반적인 표준 SVC 디코더들과 호환성이 유지될 수 있다. 제안된 방법은 멀티-레이어 디코더들에서 에러 은폐를 지원할 수 있다. 원리상으로, 현재 RTP 패킷의 이후 및 이전에 있는, 이후 및 이전 RTP 패킷의 기본 SVC 정보는 현재 RTP 패킷에 저장된다. 이러한 방법에 있어서, SVC 디코더는 에러 은폐 처리를 더 일찍 및 더 용이하게 수행할 수 있다.
도 2의 a)는 본 발명에 따른 RTP 패킷의 구조에 대한 개관을 도시하고 있다. 도 2의 b) 및 c)는 동일한 패킷의 추가 세부사항들을 도시하고 있다. 도 2의 각 라인은 32비트들을 가지는 패킷의 하나의 워드이다. 제1-제5 워드들은 아래에 지정된 바와 같이, 일반적인 헤더 정보를 포함한다.
H.264 및 SVC는 소위 네트워크 추상화 레이어(NAL)를 이용하여 인코딩된 비 디오 데이터를 처리하여 패킷들, 소위 NAL 유닛들로 포맷한다. NAL 유닛들은 송신을 위한 RTP 패킷들과 같은 트랜스포트 패킷들에, 통상적으로는 디코딩 순서로 매핑된다. 상이한 타입들의 NAL 유닛들이 정의된다. NAL 유닛은 자신의 nal_type이 1, 5 또는 20과 동일한 경우에 매크로 블록들로부터 생성되는 실제 픽쳐 데이터를 나른다. nal_type이 이들 값들과 동일하지 않는 경우, NAL은 시퀀스 파라미터 세트(SPS) 또는 픽쳐 파라미터 세트(PPS)와 같은 제어 정보를 나른다. 각 프레임은 SVC에서 1, 5, 또는 20과 동일한 nal_type의 하나 또는 그 이상의 NAL 유닛들로 인코딩된다. 이러한 종류의 RTP 패킷, 및 따라서 NAL 유닛이 전달 동안에 손실되는 경우, 대응하는 프레임이 정확하게 디코딩되지 않을 것이다. 이것은 중요한 정보이므로, 우리는 별도의 플래그를 추가하여, 디코더에게 nal_type=1, 5, 또는 20을 가지는 NAL의 손실이 있었다는 것을 사전에 통지한다.
V는 버전 필드이다. 예시적으로 V는 도 2에서 V=2로 설정된다. P는 RTP 패킷의 종료부에서 추가적인 패딩 바이트들을 나타내는 일 비트 플래그이다. P=1인 경우, 패킷은 종료부에서 하나 또는 그 이상의 추가적인 패딩 바이트들을 포함한다. M은 RTP 패킷이 특별한지의 여부, 예를 들면 현재 슬라이스의 최종 RTP 패킷인지 여부를 나타내는 일 비트 플래그이다. RTP 패킷 헤더들의 다른 종래의 필드들은 페이로드 타입, 시간 스탬프, 동기화 소스 ID(SSRC) 및 기여하는 소스들(CSRC) 필드들이다. 페이로드는 실제적인 비디오 데이터를 포함한다. 2개의 페이로드 워드들이 예시적으로 도시되어 있지만, 패킷들은 통상적으로 더 많은 페이로드를 나른다. 페이로드 이후에, P 플래그로 표시된 패딩 바이트들이 뒤따른다.
본 발명에 따르면, 이전 및 다음 RTP 패킷에 관한 추가적인 애플리케이션-관련 정보는 패딩 바이트들에 저장된다. 예를 들면, SVC는 표 1에 도시된 구조 및 대응하는 구조-관련된 파라미터들을 정의한다.
SVC에서의 예시적인 스케일러빌리티 구조
레이어
dependency_id = 2 품질 레이어; quality_id=1 공간 해상도; 4CIF(704 x 576) F
품질 레이어; quality_id=0 공간 해상도; 4CIF(704 x 576) E
dependency_id = 1 품질 레이어; quality_id=0 공간 해상도; CIF(352 x 288) D
dependency_id = 0 품질 레이어; quality_id=2 공간 해상도; QCIF(176 x 144) C
품질 레이어; quality_id=1 공간 해상도; QCIF(176 x 144) B
품질 레이어; quality_id=0 공간 해상도; QCIF(176 x 144) A
표 1에 도시된 구조는 하나의 예이다. 전체 7개의 레이어들, A-F가 있다. 베이스 레이어는 A, D, E이다. 모든 품질 레이어들 B, C, F는 그들 각각의 베이스 레이어와 동일한 공간 해상도를 가지고 있다. 공간 레이어들 D, E는 그들 베이스 레이어들과 상이한 공간 해상도를 가지고 있다.
"품질 레이어(quality layer)"로 명명된 레이어는 SVC에서 스케일러빌리티 중 한 종류인 품질 스케일러빌리티에 의해 생성된다. SVC는 품질 레이어가 그 베이스 레이어와 동일한 공간 해상도를 가질 것을 요구한다. 품질 스케일러빌리티 레이어의 인코딩 타입은 공간 스케일러빌리티 레이어와는 상이하다. 그러므로, 디코딩 접근법 및 품질 레이어 데이터에 대한 NAL 유닛 손실을 취급하는 방법은 공간 스케일러빌리티 데이터에 대한 것들과는 상이하다. "quality_id"는 SVC 비트 스트림들에서 각 품질 레이어의 ID를 나타내는 구문 요소(syntax element)이다.
"dependency_id"는 SVC에서 공간 레이어를 나타내는데 이용된다. 8개의 공간 레이어들이 허용된다. 공간 레이어는 베이스 레이어가 존재하는 경우에, 그 베이스 레이어(또는 기준 레이어)와는 상이한 공간 해상도를 가지고 있다. 구문 요소 "dependency_id"로, 우리는 현재 레이어가 어느 공간 레이어에 속하는지를 알고 있다. quality_id=0인 경우, 이것은 현재 레이어가 공간 레이어이고 공간 레이어로서 디코딩되어야 한다는 것을 의미한다. 그렇지 않으면, 현재 레이어는 품질 레이어로서 디코딩되어야 한다.
원리상으로, "dependency_id"는 공간 해상도의 변경을 나타내고 "quality_id"는 인코딩 접근법의 변경을 나타낸다.
이러한 정보는 SVC 디코더에서 가지는 것이 유용할 것이다.
본 발명의 하나의 실시예에서, 이하의 정보가 패딩 바이트들에 포함된다(인덱스들 n 및 f는 각각 다음 또는 이전 패킷을 지칭함).
Vn: 일 비트 플래그. Vn=1은 (송신 순서로) 다음 RTP 패킷이 나르는 NAL 유닛의 nal_type이 1, 5 또는 20과 동일하다는 것을 나타낸다. 이것은 다음 패킷이 매크로블록 데이터, 즉 실제 픽쳐 데이터를 포함한다는 것을 의미한다. 각 비디오 프레임은 nal_type=1, 5 또는 20인 하나 또는 그 이상의 NAL 유닛들로 인코딩된다.
Qn: 일 비트 플래그. Qn=1은 뒤따르는 RTP 패킷이 나르는 다음 NAL 유닛이 품질 레이어에 속한다는 것을 나타낸다(quality_id > 0). 그렇지 않으면, Qn = 0이고 뒤따르는 RTP 패킷은 공간 레이어에 속한다.
Dn: 일 비트 플래그. Dn=1은 뒤따르는 RTP 패킷이 나르는 다음 NAL이 현재 NAL과 동일한 dependency_id 값을 가지고 있다는 것을 나타낸다. 그렇지 않으면, Dn=0이다.
POCn: 10 비트 부호없는(unsigned) 정수로서, 뒤따르는 RTP 패킷이 나르는 다음 NAL의 POC 번호를 나타낸다.
PIC_idxn: 10비트 부호없는 정수로서, 뒤따르는 RTP 패킷이 나르는 다음 NAL의 IDR 번호를 나타낸다. 이는 nal_type=5를 가지는 새로운 NAL이 처리될 때마다 하나씩 증가된다. 이것이 최대값 1023에 도달된 경우에, 제로로 리턴한다.
Vn=1인 경우, 이것은 (송신 순서로) 다음 RTP 패킷이 나른 NAL의 nal_type이 1, 5 또는 20과 동일하다는 것을 의미한다. Vn, Qn, Dn, POCn 및 PIC_idxn 플래그들의 모든 값들은 다음 RTP 패킷의 NAL과 관련된다. 그렇지 않은 경우, Vn=0인 경우, 모든 이들 값들은 더 나중 RTP 패킷에 있는 (SVC 비트 스트림에서 저장 순서로) 다음 NAL과 관련된다.
Vf: 일 비트 플래그. Vf=1은 이전 RTP 패킷(즉, 송신 순서에서 바로 선행하는 패킷)이 나른 NAL의 nal_type이 1, 5 또는 20과 동일하다는 것을 나타낸다.
Qf: 일 비트 플래그. Qf=1은 이전 RTP 패킷이 나른 NAL이 품질 레이어에 속한다는 것을 나타낸다(quality_id >0). 그렇지 않으면, Qf=0이다.
Df: 일 비트 플래그. Df=1은 이전 RTP 패킷이 나른 NAL이 현재 NAL과 동일한 dependency_id 값을 가지고 있다는 것을 나타낸다. 그렇지 않으면, Df=0이다.
POCf: 10 비트 부호없는 정수로서, 이전 RTP 패킷이 나르는 NAL의 POC 번호를 나타낸다.
PIC_idxf: 10 비트 부호없는 정수로서, 이전 RTP 패킷이 나르는 NAL의 IDR 번호를 나타낸다. 이는 nal_type=5를 가지는 새로운 NAL이 처리될 때마다 하나씩 증가된다. 이것이 최대값 1023에 도달하는 경우, 제로로 리턴한다.
또 하나의 선택적인 파라미터는 '패딩 길이'이다. 이것은 자신을 포함하여 패딩 바이트들의 수이다. 패딩 바이트들은 반드시 32 비트 보더(border) 상에서 반드시 정렬될 필요는 없다.
플래그 Vx(x=n 또는 f)는 다음/이전 RTP 패킷의 NAL이 VCL NAL인지 여부를 나타낸다. 플래그 Qx에 의해 제공되는 정보로, 디코더는 다음/이전 RTP 패키지의 NAL이 품질 레이어에 속하는지 여부를 용이하게 알 수 있다. 플래그 Dx로, 공간/CGS 레이어가 용이하게 얻어질 수 있다.
단일 RTP 패킷이 손실되면, Vn=1 및 Qn=0인 경우(즉, 픽쳐 데이터를 가지는 공간 레이어), 에러 은폐는 SVC 디코더에 의해 수행되어야 한다. 이 경우에, 요구되는 픽쳐 데이터는 누락되어 있다. 손실된 NAL이 속하는 프레임은 POCn에 따라 결정될 수 있고, 간단하고 빠른 에러 은폐 알고리즘이 SVC 디코더에 활용될 수 있다.
수개의 연속적인 RTP 패킷들이 손실되면, SVC 디코더는 Vn=1이고 Qn=0이거나 Vf=1이고 Qf=1인 경우에 에러 은폐를 수행해야 한다. 제1 손실된 RTP 패킷 이전의 RTP에서의 Dn, POCn 및 PIC_idxn의 정보 및 최종 손실된 RTP 패킷 이후의 RTP에서의 Df, POCf 및 PIC_idxf의 정보로, 손실된 픽쳐들의 수 및 그들 GOP 및 레이어 정보가 결정될 수 있고, 그리고나서 SVC 디코더에 제공될 수 있다. 이러한 정보는 SVC 디코더가 간단하고 빠른 에러 은폐를 수행하는데 도움을 줄 것이다.
도 3은 본 발명의 하나의 양태에 따른 인코딩을 위한 블록도를 도시하고 있다. 하나의 실시예에서, 인코딩 방법은 멀티-레이어 애플리케이션 데이터의 적어도 제1, 제2 및 제3 계속적인 부분들을 각각의 제1, 제2 및 제3 RTP 패킷들, p1, p2, p3에 팩킹하거나 삽입하는 단계(305)를 포함한다. 상기 설명된 바와 같이, 애플리케이션 데이터의 상이한 부분들은 애플리케이션의 제1, 제2 및 제3 레이어 VCLf, VCLc, VCLn을 표시한다. 레이어들은 상이하거나, 임의의 2개 또는 모든 패킷들이 동일한 레이어를 표시할 수 있다.
다음 단계 320에서, (이전, 제1 패킷이 표시하는) 애플리케이션의 제1 레이어를 정의하는 적어도 제1 데이터 Vf 및 (뒤따르는, 제3 패킷이 표시하는) 애플리케이션의 제3 레이어를 정의하는 제2 데이터 Vn은 제2 RTP 패킷에 추가된다. 특히, 이러한 정보는 상기 설명된 바와 같이 패딩 바이트들에 추가된다. 제3 단계에서, 제1, 제2 및 제3 RTP 패킷들이 (이러한 순서대로) 송신된다(참조번호 325).
그러나, 또 하나의 실시예에서, 일시적으로 버퍼링될 수도 있는, 삽입된 각각의 이전 및 다음 패킷에 관한 애플리케이션 레이어 정보를 얻기만 한다면, 단일 패킷을 한 번에 인코딩하는 것도 충분하다.
도 3은 또한 본 발명의 하나의 양태에 따른 인코더의 일반적인 구조를 도시하는 것으로도 이해될 수 있다. RTP 패킷들을 이용하여 멀티-레이어 애플리케이션 데이터를 인코딩하기 위한 그러한 인코더는, 멀티-레이어 애플리케이션 데이터의 제1, 제2 및 제3 부분을 제1, 제2 및 제3 RTP 패킷 p1, p2, p3으로 각각 팩킹하기 위한 삽입 수단(305) - 여기에서 애플리케이션 데이터의 제1, 제2 및 제3 부분은 제1, 제2 및 제3 애플리케이션 레이어를 표시함 -, 제1(=이전) 패킷을 표시하는 적어도 제1 애플리케이션 레이어 데이터 및 제3(= 다음) 패킷과 관련된 제2 애플리케이션 레이어 데이터를 제2 RTP 패킷에 추가하기 위한 삽입 수단(320), 및 제1, 제2 및 제3 RTP 패킷을 (이러한 순서로) 송신하기 위한 송신 수단(340)을 포함한다.
도 4는 실제 애플리케이션 레이어 디코딩 이전에 수행되어야 하는, 디코딩 준비의 원리의 블록도를 도시하고 있다. 실제 구현들은 더 정밀하거나 예를 들면 디코더에 통합될 수 있다.
이 방법은 멀티-레이어 애플리케이션 데이터를 포함하는 RTP 패킷들의 디코딩을 준비하기 위한 것으로, 적어도 제1 및 후속 제2 RTP 패킷을 수신하는 단계(401), 제1 RTP 패킷의 보디로부터 멀티-레이어 애플리케이션 데이터의 제1 부분(415), 및 제1 RTP 패킷의 패딩 바이트들로부터 제1 이웃 정보 NBn를 추출하는 단계(410), 및 동일한 방식으로 제2 RTP 패킷의 보디로부터 멀티-레이어 애플리케이션 데이터의 제2 부분(425), 및 제2 RTP 패킷의 패딩 바이트들로부터 제2 이웃 정보 NBf를 추출하는 단계(420)를 포함한다. 상기 설명된 바와 같이, 이웃 정보는 다음 패킷이 관련되는 한, Vn, Qn, Dn, POCn 및 PIC_idxn 중 적어도 하나를 포함하고, 이전 패킷이 관련되는 한 Vf, Qf, Df, POCf 및 PIC_idxf 중 적어도 하나를 포함한다.
다음 단계에서, 제1 RTP 패킷 typn 및 제2 RTP 패킷 typn+1에서의 멀티-레이어 애플리케이션 데이터의 타입이 결정된다(참조번호 430, 440).
다음 단계는 제2 RTP 패킷의 멀티-레이어 애플리케이션의 결정된 타입 typn+1과 제1 RTP 패킷으로부터 추출된 제1 이웃 정보 NBn을 비교하는 단계(450) 및/또는 제1 RTP 패킷의 멀티-레이어 애플리케이션의 결정된 타입 typn과 제2 RPT 패킷으로부터 추출된 제2 이웃 정보 NBff를 비교하는 단계(460)이다. 두 개의 비교들 모두가 수행되는 경우, 이들은 이하에 설명되는 바와 같이, 3가지 다른 결과들을 가져올 수 있다.
다음 단계에서, 제1 RTP 패킷으로부터 추출된 제1 이웃 정보 NBn 및 제2 RTP 패킷으로부터 추출된 제2 이웃 정보 NBf가 비교된다(단계 470). 양쪽이 동일하고 패킷이 누락되어 있는 경우, 단지 하나의 패킷만이 누락되어 있는 것으로 결론지을 수 있다. 양쪽이 다르고 패킷이 누락되어 있는 경우, 하나보다 많은 패킷이 누락되어 있는 것으로 결론지을 수 있다.
이어서, 상기 추출 및 비교 단계의 결과들이 상기 멀티-레이어 애플리케이션을 위한 디코더에 제공된 후, 이는 누락 정보에 대한 길게 지속되는 분석을 수행할 필요가 없으므로 적절한 방식으로 매우 빠르게 대응할 수 있다.
하나의 비교 결과 신호(455)는 현재 패킷의 타입이 뒤따르는 패킷에서 표시된 대로인지의 여부를 나타낸다. 하나의 비교 결과 신호(465)는 현재 패킷의 패킷 타입이 이전 패킷에 표시된 대로인지의 여부를 나타낸다. 이들 2개의 455, 465 신호들은 데이터가 누락되어 있는지 여부를 나타내므로 제1차 비교 결과들로서 간주된다. 하나의 비교 결과 신호(475)는 이전 패킷에서 "다음"으로 표시된 패킷 타입과 현재 패킷에서 "이전"으로 표시된 패킷 타입이 동일한 지 여부를 나타낸다. 이것은 데이터가 누락되어 있는 경우에만 관련되므로 제2차 비교 결과이다.
하나의 실시예에서, 모든 이들 비교 결과 신호들은 예상되는 다음 및 이전 패킷 타입들 typn, typn+1과 함께 멀티-레이어 애플리케이션 디코더에 전달된다. 디코더는 이하에 설명된 바와 같이 정보를 활용할 수 있다.
예시적으로, 2개의 수신된 패킷들에 대해 3가지 상이한 상항들이 발생할 수 있으므로, 단지 2개의 계속적인 패킷들의 수신 및 평가가 설명된다.
제1의 경우에, 제1 패킷의 "다음" 정보는 제2 패킷의 패킷 타입과 동일하고, 제2 패킷의 "이전" 정보는 제1 패킷의 패킷 타입과 동일하다. 이 경우에, 제1차 비교 결과 신호들(455 및 465)은 모든 것이 OK이고 어떠한 패킷도 손실되지 않은 것을 나타낸다.
제2의 경우에, 제1 패킷의 "다음" 정보는 제2 패킷의 실제 패킷 타입과 상이하고(또는 제2 패킷의 "이전" 정보가 제1 패킷의 실제 패킷 타입과 상이함), 추가적으로 제1 패킷의 "다음" 정보는 제2 패킷의 "이전" 정보와 동일하다. 환언하면, 제1차 신호들(455, 465) 중 적어도 하나는 데이터가 누락되어 있다는 것을 나타내고, 제2차 신호(475)는 양 패킷들 모두 동일한 타입의 누락 데이터를 나타낸다는 것을 나타낸다. 이 경우에, 제1 및 제2 패킷 사이에서 단지 하나의 패킷만이 누락되어 있고 그 타입은 "다음" 및 "이전" 정보로부터 알려진다고 결론지을 수 있다.
제3의 경우에, 제1 패킷의 "다음" 정보는 제2 패킷의 실제 패킷 타입과 다르고(또는 제2 패킷의 "이전" 정보가 제1 패킷의 실제 패킷 타입과 다름), 추가적으로 제2 패킷의 "이전" 정보는 제1 패킷의 "다음" 정보와 다르다. 환언하면, 제1차 신호들(455, 465) 중 적어도 하나는 데이터가 누락되어 있는 것을 나타내고, 제2차 신호(475)는 양 패킷들 모두 상이한 타입들의 누락 데이터를 나타내는 것을 나타낸다. 이 경우에, 제1 및 제2 패킷 사이에 적어도 2개의 패킷들이 누락되어 있다는 것으로 결론지을 수 있다.
이러한 정보가 제공된 상태에서, 멀티-레이어 애플리케이션 디코더는 현재 상황에 따라 매우 빠르게 대응할 수 있다.
하나의 실시예에서, 추가적인 패킷들에 의해 또 다른 도움이 디코더에게 제공된다. RTP 프로토콜에서, RTCP 패킷들이 이 목적에 이용될 수 있다. 도 5는 추가적인 정보를 디코더에 송신하는데 RTCP 패킷들을 효율적으로 활용하는 방법을 도시하고 있다. 양호하게도, 이와 같은 방식으로 더 빠른 디코더 초기화를 허용하는 구조적인 정보가 송신될 수 있다.
하나의 실시예에서, (공간 및/또는 품질) 레이어들의 수는 애플리케이션-정의 RTCT 패킷 내에서 수신기에 전송된다. 이는 디코더의 초기화를 용이하게 하려는 것이고, 랜덤 액세스를 위해, 이 정보는 주기적으로, 예를 들면 IDR 프레임 또는 SPS처럼 빈번하게 전송될 수 있다. 도 5는 그러한 RTCP 패킷의 포맷을 도시하고 있고, 여기에서 수개의 필드들이 이하에 설명된다.
"서브타입": "이름" 필드와 함께 이용되어 패킷의 콘텐츠를 식별하는데 이용될 수 있다.
"길이": 헤더를 포함하여,「32-비트 워드들 - 1」로 이러한 RTCP 패킷의 길이를 제공한다. 디폴트는 2이다.
"이름": 4개의 ASCII 문자들의 시퀀스로 해석되고, 대문자 및 소문자가 다르게 다루어진다. "이름"은 SVC 관련된 RTP-기반 애플리케이션을 나타내는데 이용될 수 있다. SVC 디코더 또는 디코딩 절차를 초기화하기 위해, 수신기는 수신된 SVC 비트-스트림의 전체적 정보를 신속하게 얻을 수 있다. SVC 디코더 초기화를 위한 정보를 RTCP 패킷들에 삽입하는데 2가지 종류의 방법들이 가능하다.
제1의 경우: "서브타입" 필드는 항상 "이름" 필드와 함께 이용되어 패킷의 콘텐츠를 식별한다. "이름" 필드가 RTP 패키지의 페이로드가 SVC 비트 스트림이라는 것을 나타내는 경우, 임의의 3개의 비트는 SVC 비트 스트림에서 구문 요소 "dependency_id"의 최대값을 나타내는데 이용될 수 있다. 예시적으로, 우리는 도 5의 b)에 도시된 바와 같이 처음 3개의 비트를 이용하여 이 값을 저장한다. maxD_id는 전송될 SVC 비트 스트림에서 "dependency_id"의 최대값을 나타내는 부호없는 3 비트 정수이다. "dependency_id"의 최대값은 SVC 비트 스트림의 공간/CGS의 전체 레이어들을 나타낸다. 이 값은 SVC 디코더 기본 초기화에 매우 중요하다. 로컬 비트 스트림 플레이를 위해, 이 값은 SVC 비트 스트림 종속성을 체크함으로써 얻어질 수 있다. 그러나, 에러가 발생하기 쉬운(예를 들면, 네트워크 기반) SVC 애플리케이션에 대해, SVC 비트 스트림 종속성을 체크함으로써 얻어지는 "dependency_id"의 최대값은 패킷 손실로 인해 잘못될 수 있다. maxID_id의 값은 수신기에 의해 SVC 디코더를 초기화하는데 이용될 수 있다.
레이어 정보를 처음에 전달하는 또 하나의 방법은 도 5의 c)에 도시된 바와 같이, "이름" 필드의 끝에 초과 페이로드를 추가하는 것이다. maxD_id는 상기 설명대로이다. maxT_id는 SVC 비트 스트림에서 구문 요소 "temporal_id"의 최대 값을 나타내는 3개의 비트를 가지고 있다. maxQ_id는 SVC 비트 스트림에서 구문 요소 "quality_id"의 최대값을 나타내는 4개의 비트를 가지고 있다.
"길이"의 디폴트 값은 2이다. "이름"이 SVC 관련 애플리케이션을 나타내고 "길이"가 디폴트 값과 동일하지 않은 경우, "이름" 필드의 다음의 10 비트들이 maxD_id, maxT_id 및 maxQ_id를 저장한다. 수신기 측에서, maxD_id는 SVC 디코더의 기본 초기화를 위해 이용될 수 있고, maxT_id 및 maxQ_id는 향상된 SVC 디코더 초기화에 이용될 수 있다. 디코더에 있어서의 장점은, 실제 디코딩이 시작되기 이전에 파라미터들을 결정하기 위해 데이터 스트림을 분석할 필요가 없다는 점이다. 그러므로, 초기화가 더 빠르게 되고 디코딩은 더 일찍 시작할 수 있다.
본 발명은 순전히 예로서 설명되었고 본 발명의 범주에서 벗어나지 않고서도 세부사항의 변형이 만들어질 수 있다는 것은 자명하다. 상세한 설명 및 (적절한 경우에) 청구항 및 도면들에 개시된 각 특징은 독립적으로 또는 임의의 적절한 조합으로 제공될 수 있다. 특징들은 적절한 경우에 하드웨어, 소프트웨어, 또는 2가지의 조합으로 구현될 수 있다. 접속들은 적용가능한 경우에 무선 접속 또는 유선, 반드시는 아니지만 직접 또는 전용 접속들로서 구현될 수 있다. 청구항들에 나타나는 참조번호들은 단지 예시를 위한 것이고 청구항들의 범주에 어떠한 제한적인 영향도 미치지 않을 것이다.
본 발명의 예로 든 실시예들은 첨부된 도면들을 참조하여 설명되었다.
도 1은 본 발명에 따른 데이터 스트림의 구조를 나타내는 도면.
도 2는 패딩 바이트들을 구비하는 RPT 패킷들의 포맷을 나타내는 도면.
도 3은 인코딩의 블록도.
도 4는 디코딩 준비의 블록도.
도 5는 본 발명의 하나의 양태에 따른 RTCP 패킷들의 포맷을 나타내는 도면.

Claims (15)

  1. RTP 패킷들(p1, p2, p3)을 포함하는 데이터 스트림으로서,
    상기 RTP 패킷들은 멀티-레이어 애플리케이션(multi-layer application)의 애플리케이션 데이터를 포함하고,
    RTP 패킷은 다음 RTP 패킷의 콘텐츠와 관련된 제1 애플리케이션 레이어 정보(NBn) 및 이전 RTP 패킷의 콘텐츠와 관련된 제2 애플리케이션 레이어 정보(NBf)를 포함하는
    데이터 스트림.
  2. 제1항에 있어서,
    상기 애플리케이션 데이터는 스케일링가능한 비디오 데이터(scalable video data)이고, 상기 애플리케이션 레이어들은 스케일링가능한 비디오 레이어들인 데이터 스트림.
  3. 제1항 또는 제2항에 있어서,
    상기 애플리케이션 레이어 정보는 NAL 타입 표시(Vn, Vf), 품질 정보(Qn, Qf), 종속성 정보(Dn, Df), IDR 번호(PIC_idxn, PIC_idxf) 및 픽쳐 순서 카운트(POCn, POCf) 정보 중 적어도 하나를 포함하는 데이터 스트림.
  4. 제1항 내지 제3항 중 어느 한 항에 있어서,
    상기 다음 RTP 패킷에 관련된 애플리케이션 레이어 정보 및 상기 이전 RTP 패킷에 관련된 애플리케이션 레이어 정보는 상기 RTP 패킷의 패딩 바이트들(padding bytes) 내에 저장되는 데이터 스트림.
  5. RTP 패킷들을 이용하여 멀티-레이어 애플리케이션 데이터를 인코딩하기 위한 방법으로서,
    멀티-레이어 애플리케이션 데이터의 제1, 제2 및 제3 부분을 각각 제1, 제2 및 제3 RTP 패킷(p1, p2, p3)에 팩킹(packing)하는 단계(305) - 상기 애플리케이션 데이터의 제1, 제2 및 제3 부분은 상기 애플리케이션의 제1, 제2 및 제3 레이어(VCLf, VCLc, VCLn)를 표시(refer)함 -;
    상기 제1 패킷이 표시하는 상기 애플리케이션의 제1 레이어를 정의하는 적어도 제1 데이터(Vf), 및 상기 제3 패킷이 표시하는 상기 애플리케이션의 제3 레이어를 정의하는 제2 데이터(Vn)를 상기 제2 RTP 패킷에 추가하는 단계(320); 및
    상기 제1, 제2 및 제3 RTP 패킷을 이 순서대로 송신하는 단계(325)
    를 포함하는 인코딩 방법.
  6. 제5항에 있어서,
    상기 제1 데이터 및 상기 제2 데이터는 상기 제2 패킷의 패딩 바이트들 내에 추가되는 인코딩 방법.
  7. 제5항 또는 제6항에 있어서,
    상기 애플리케이션의 제1 레이어(VCLf)를 정의하는 제1 데이터(Vf) 및 상기 애플리케이션의 제3 레이어(VCLn)를 정의하는 제2 데이터(Vn)는 NAL 타입 표시(Vn, Vf), 품질 정보(Qn, Qf), 종속성 정보(Dn, Df), IDR 번호(PIC_idxn, PIC_idxf) 및 픽쳐 순서 카운트(POCn, POCf) 정보 중 하나 또는 그 이상을 포함하는 인코딩 방법.
  8. 제7항에 있어서,
    상기 제1 데이터(Vf) 또는 상기 제2 데이터(Vn)는 상기 이전 또는 다음 패킷의 애플리케이션 데이터가 하나 또는 그 이상의 특정 NAL 타입들을 표시하는 것을 나타내는 플래그(Vn, Vf)를 포함하는 인코딩 방법.
  9. 제5항 내지 제8항 중 어느 한 항에 있어서,
    상기 제1, 제2 및 제3 패킷들은 바로 이웃한 시퀀스로 송신되는 인코딩 방법.
  10. 멀티-레이어 애플리케이션 데이터를 포함하는 RTP 패킷들의 디코딩을 준비하기 위한 방법으로서,
    적어도 제1 및 후속 제2 RTP 패킷을 수신하는 단계(401);
    상기 제1 RTP 패킷의 보디(body)로부터 상기 멀티-레이어 애플리케이션 데이터의 제1 부분(415)을 추출하고 상기 제1 RTP 패킷의 패딩 바이트들로부터 제1 이웃 정보(NBn)를 추출하는 단계(410);
    상기 제2 RTP 패킷의 보디로부터 상기 멀티-레이어 애플리케이션 데이터의 제2 부분(425)을 추출하고 상기 제2 RTP 패킷의 패딩 바이트들로부터 제2 이웃 정보(NBf)를 추출하는 단계(420);
    상기 제1 RTP 패킷에서 및 상기 제2 RTP 패킷에서 멀티-레이어 애플리케이션 데이터의 타입(typn, typn+1)을 결정하는 단계(430, 440);
    상기 제2 RTP 패킷에서의 멀티-레이어 애플리케이션 데이터의 결정된 타입(typn+1)과 상기 제1 RTP 패킷으로부터 추출된 상기 제1 이웃 정보(NBn)를 비교하는 단계(450);
    상기 제1 RTP 패킷에서의 멀티-레이어 애플리케이션 데이터의 결정된 타입(typn)과 상기 제2 RTP 패킷으로부터 추출된 상기 제2 이웃 정보(NBf)를 비교하는 단계(460);
    상기 제1 RTP 패킷으로부터 추출된 상기 제1 이웃 정보(NBn)와 상기 제2 RTP 패킷으로부터 추출된 상기 제2 이웃 정보(NBf)를 비교하는 단계(470); 및
    상기 추출 단계(430, 440) 및 비교 단계(450, 460, 470)의 결과들을 상기 멀티-레이어 애플리케이션을 위한 디코더에 제공하는 단계
    를 포함하는 디코딩 준비 방법.
  11. 제10항에 있어서,
    상기 제1 및 제2 RTP 패킷들의 이웃 정보는 NAL 타입 표시(Vn, Vf), 품질 정보(Qn, Qf), 예측 종속성 정보(Dn, Df), IDR 번호(PIC_idxn, PIC_idxf) 및 픽쳐 순서 카운트(POCn, POCf) 정보 중 하나 또는 그 이상을 포함하는 디코딩 준비 방법.
  12. RTP 패킷들을 이용하여 멀티-레이어 애플리케이션 데이터를 인코딩하기 위한 장치로서,
    상기 멀티-레이어 애플리케이션 데이터의 제1, 제2 및 제3 부분을 각각 제1, 제2 및 제3 RTP 패킷(p1, p2, p3)에 팩킹하기 위한 삽입 수단(305) - 상기 애플리케이션 데이터의 제1, 제2 및 제3 부분은 상기 애플리케이션의 제1, 제2 및 제3 레이어(VCLf, VCLc, VCLn)를 표시(refer)함 -;
    상기 제1 패킷이 표시하는 상기 애플리케이션의 제1 레이어를 정의하는 적어도 제1 데이터(Vf), 및 상기 제3 패킷이 표시하는 상기 애플리케이션의 제3 레이어 를 정의하는 제2 데이터(Vn)를 상기 제2 RTP 패킷에 추가하기 위한 삽입 수단(320); 및
    상기 제1, 제2 및 제3 RTP 패킷을 이 순서대로 송신하기 위한 송신 수단(340)
    을 포함하는 인코딩 장치.
  13. 제12항에 있어서,
    상기 제1 데이터 및 상기 제2 데이터는 상기 제2 패킷의 패딩 바이트들 내에 추가되는 인코딩 장치.
  14. 멀티-레이어 애플리케이션 데이터를 포함하는 RTP 패킷들의 디코딩을 준비하기 위한 장치(400)로서,
    적어도 제1 및 후속 제2 RTP 패킷을 수신하기 위한 수신 수단(401);
    상기 제1 RTP 패킷의 보디로부터 상기 멀티-레이어 애플리케이션 데이터의 제1 부분(415)을 추출하고 상기 제1 RTP 패킷의 패딩 바이트들로부터 제1 이웃 정보(NBn)를 추출하기 위한 제1 추출 수단(410);
    상기 제2 RTP 패킷의 보디로부터 상기 멀티-레이어 애플리케이션 데이터의 제2 부분(425)을 추출하고 상기 제2 RTP 패킷의 패딩 바이트들로부터 제2 이웃 정보(NBf)를 추출하기 위한 제2 추출 수단(420);
    상기 제1 RTP 패킷에서 및 상기 제2 RTP 패킷에서 상기 멀티-레이어 애플리케이션 데이터의 타입(typn, typn+1)을 결정하기 위한 결정 수단(430, 440);
    상기 제2 RTP 패킷에서의 멀티-레이어 애플리케이션 데이터의 결정된 타입(typn+1)과 상기 제1 RTP 패킷으로부터 추출된 상기 제1 이웃 정보(NBn)를 비교하기 위한 제1 비교 수단(450);
    상기 제1 RTP 패킷에서의 멀티-레이어 애플리케이션 데이터의 결정된 타입(typn)과 상기 제2 RTP 패킷으로부터 추출된 상기 제2 이웃 정보(NBf)를 비교하기 위한 제2 비교 수단(460);
    상기 제1 RTP 패킷으로부터 추출된 상기 제1 이웃 정보(NBn)와 상기 제2 RTP 패킷으로부터 추출된 상기 제2 이웃 정보(NBf)를 비교하기 위한 제3 비교 수단(470); 및
    상기 제1 및 제2 추출 수단(430, 440)과 상기 제1, 제2 및 제3 비교 수단(450, 460, 470)의 결과들을 상기 멀티-레이어 애플리케이션을 위한 디코더에 제공하기 위한 제공 수단
    을 포함하는 디코딩 준비 장치.
  15. 제14항에 있어서,
    상기 제1 및 제2 RTP 패킷들의 이웃 정보(NBn, NBf)는 NAL 타입 표시(Vn, Vf), 품질 정보(Qn, Qf), 예측 종속성 정보(Dn, Df), IDR 번호(PIC_idxn, PIC_idxf) 및 픽쳐 순서 카운트(POCn, POCf) 정보 중 하나 또는 그 이상을 포함하는 디코딩 준비 장치.
KR1020090068257A 2008-07-28 2009-07-27 Ｒｔｐ 패킷들을 포함하는 데이터 스트림, 그러한 데이터 스트림을 인코딩/디코딩하기 위한 방법 및 디바이스 KR101650571B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP08305424A EP2150022A1 (en) 2008-07-28 2008-07-28 Data stream comprising RTP packets, and method and device for encoding/decoding such data stream
EP08305424.7 2008-07-28

Publications (2)

Publication Number Publication Date
KR20100012830A true KR20100012830A (ko) 2010-02-08
KR101650571B1 KR101650571B1 (ko) 2016-08-23

Family

ID=40220088

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020090068257A KR101650571B1 (ko) 2008-07-28 2009-07-27 Ｒｔｐ 패킷들을 포함하는 데이터 스트림, 그러한 데이터 스트림을 인코딩/디코딩하기 위한 방법 및 디바이스

Country Status (6)

Country Link
US (1) US20100020865A1 (ko)
EP (2) EP2150022A1 (ko)
JP (1) JP5686506B2 (ko)
KR (1) KR101650571B1 (ko)
CN (1) CN101640640B (ko)
TW (1) TWI497982B (ko)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100825743B1 (ko) * 2005-11-15 2008-04-29 한국전자통신연구원 실시간으로 비트스트림의 공간 해상도를 변환할 수 있는스케일러블 비디오 코딩 방법 및 그 방법을 이용한 코덱
CN102752670B (zh) * 2012-06-13 2015-11-25 广东威创视讯科技股份有限公司 减少网络视频传输中马赛克现象的方法、装置及系统
CN104838649A (zh) * 2012-09-28 2015-08-12 三星电子株式会社 针对随机访问的用于对视频进行编码的方法和设备以及用于对视频进行解码的方法和设备
US8959414B2 (en) * 2013-06-13 2015-02-17 Lsi Corporation Systems and methods for hybrid layer data decoding
CN105141961B (zh) * 2015-08-03 2017-12-22 中国人民解放军信息工程大学 一种基于视频隐写的空间数据双协议传输方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080008439A1 (en) * 2006-06-06 2008-01-10 Guangqun Liu Method and System For Dynamic Management Of Multiple Media Data Streams
US20080040498A1 (en) * 2006-08-10 2008-02-14 Nokia Corporation System and method of XML based content fragmentation for rich media streaming
US20080065965A1 (en) * 2004-11-16 2008-03-13 Miska Hannuksela Buffering packets of a media stream
US20080133517A1 (en) * 2005-07-01 2008-06-05 Harsh Kapoor Systems and methods for processing data flows

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09247131A (ja) * 1996-03-07 1997-09-19 Toshiba Corp データ通信装置
CA2267450C (en) * 1997-08-01 2004-04-27 Ntt Mobile Communications Network Inc. Data sequence generator, transmitter, information data decoder, receiver, transmitter-receiver, data sequence generating method, information data decoding method, and recording medium
EP1367564A4 (en) * 2001-03-06 2005-08-10 Ntt Docomo Inc METHOD AND DEVICE FOR INTERPOLATING SOUND DATA, METHOD AND DEVICE FOR CREATING INFORMATION RELATING TO SOUND DATA, METHOD AND DEVICE FOR TRANSMITTING SOUND DATA INTERPOLATION INFORMATION, AND PROGRAM AND RECORDING MEDIUM THEREOF
JP2005512462A (ja) * 2001-12-11 2005-04-28 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ ネットワークを介した付加情報を送信するためのシステム
US7061942B2 (en) * 2002-05-31 2006-06-13 Skystream Networks Inc. Apparatus for redundant multiplexing and remultiplexing of program streams and best effort data
JP2004056169A (ja) * 2002-07-16 2004-02-19 Matsushita Electric Ind Co Ltd 画像データ受信装置、画像データ送信装置
US20050275752A1 (en) * 2002-10-15 2005-12-15 Koninklijke Philips Electronics N.V. System and method for transmitting scalable coded video over an ip network
JP4336792B2 (ja) * 2003-03-13 2009-09-30 日本電気株式会社 パケット送信方法および無線アクセスネットワーク
JP4078544B2 (ja) * 2003-03-31 2008-04-23 サクサ株式会社 音声データの伝送装置および音声データの受信装置
DE102005001286A1 (de) * 2005-01-11 2006-07-20 Siemens Ag Verfahren und Vorrichtung zur Übertragung von skalierbaren Daten
DE602006011865D1 (de) * 2005-03-10 2010-03-11 Qualcomm Inc Decoder-architektur für optimiertes fehlermanagement in multimedia-strömen
EP1773063A1 (en) * 2005-06-14 2007-04-11 Thomson Licensing Method and apparatus for encoding video data, and method and apparatus for decoding video data
EP1742476A1 (en) * 2005-07-06 2007-01-10 Thomson Licensing Scalable video coding streaming system and transmission mechanism of the same system
FR2898754B1 (fr) * 2006-03-17 2008-06-13 Thales Sa Procede de protection de donnees multimedia au moyen de couches d'abstraction reseau (nal) supplementaires
WO2008013528A1 (en) * 2006-07-25 2008-01-31 Thomson Licensing Recovery from burst packet loss in internet protocol based wireless networks using staggercasting and cross-packet forward error correction
JP2009065259A (ja) * 2007-09-04 2009-03-26 Sanyo Electric Co Ltd 受信装置
JP2009118151A (ja) * 2007-11-06 2009-05-28 Fujitsu Ltd 通信システム、送信装置、中継装置、受信装置及び送信プログラム
WO2009127961A1 (en) * 2008-04-16 2009-10-22 Nokia Corporation Decoding order recovery in session multiplexing

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080065965A1 (en) * 2004-11-16 2008-03-13 Miska Hannuksela Buffering packets of a media stream
US20080133517A1 (en) * 2005-07-01 2008-06-05 Harsh Kapoor Systems and methods for processing data flows
US20080008439A1 (en) * 2006-06-06 2008-01-10 Guangqun Liu Method and System For Dynamic Management Of Multiple Media Data Streams
US20080040498A1 (en) * 2006-08-10 2008-02-14 Nokia Corporation System and method of XML based content fragmentation for rich media streaming

Also Published As

Publication number Publication date
TW201006255A (en) 2010-02-01
KR101650571B1 (ko) 2016-08-23
JP5686506B2 (ja) 2015-03-18
EP2150024B1 (en) 2016-05-18
EP2150022A1 (en) 2010-02-03
JP2010045775A (ja) 2010-02-25
CN101640640A (zh) 2010-02-03
CN101640640B (zh) 2014-01-29
EP2150024A1 (en) 2010-02-03
TWI497982B (zh) 2015-08-21
US20100020865A1 (en) 2010-01-28

Similar Documents

Publication Publication Date Title
US11924526B2 (en) Segment types as delimiters and addressable resource identifiers
EP3243332B1 (en) Session description information for over-the-air broadcast media data
RU2518383C2 (ru) Способ и устройство для переупорядочивания и мультиплексирования мультимедийных пакетов из мультимедийных потоков, принадлежащих взаимосвязанным сеансам
KR101784051B1 (ko) 코딩된 비디오 데이터의 네트워크 스트리밍
EP2129129B1 (en) Systems and methods for channel switching
US8432937B2 (en) System and method for recovering the decoding order of layered media in packet-based communication
US20100049865A1 (en) Decoding Order Recovery in Session Multiplexing
CN112106382B (zh) 检索媒体数据的方法、设备、存储介质
KR101650571B1 (ko) Ｒｔｐ 패킷들을 포함하는 데이터 스트림, 그러한 데이터 스트림을 인코딩/디코딩하기 위한 방법 및 디바이스
KR20190010568A (ko) 샘플 엔트리들 및 랜덤 액세스
WO2023073283A1 (en) A method, an apparatus and a computer program product for video encoding and video decoding
Westin et al. RTP payload format for vp8 video
Westin et al. RFC 7741: RTP Payload Format for VP8 Video
Schierl et al. Decoding order recovery for multi flow transmission of scalable video coding (SVC) over mobile IP channels

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: 20190816

Year of fee payment: 4