KR20130092509A - 멀티-홉 ｒｔｐ 스트림에서의 중요 패킷 손실 처리 시스템 및 방법 - Google Patents

멀티-홉 ｒｔｐ 스트림에서의 중요 패킷 손실 처리 시스템 및 방법 Download PDF

Info

Publication number
KR20130092509A
KR20130092509A KR20130014703A KR20130014703A KR20130092509A KR 20130092509 A KR20130092509 A KR 20130092509A KR 20130014703 A KR20130014703 A KR 20130014703A KR 20130014703 A KR20130014703 A KR 20130014703A KR 20130092509 A KR20130092509 A KR 20130092509A
Authority
KR
South Korea
Prior art keywords
packet
packets
media
rtp
priority level
Prior art date
Application number
KR20130014703A
Other languages
English (en)
Other versions
KR101458852B1 (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 KR20130092509A publication Critical patent/KR20130092509A/ko
Application granted granted Critical
Publication of KR101458852B1 publication Critical patent/KR101458852B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H04N7/152—Multipoint control units therefor
    • 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/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences

Landscapes

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

Abstract

패킷 손실이 가능할 수도 있는 네트워크에 구현되는 압축 미디어 전송 시스템의 재전송 필요를 감소시키는 방법 및 시스템의 실시예가 개시되어 있다. 각 전송된 패킷에 대한 확장된 헤더는 패킷의 우선순위를 나타낼 수 있고 엔드포인트는 손실 패킷의 재전송이 요구되는지 결정할 수 있다. 멀티-홉 시스템내의 상이한 홉에서의 패킷의 버퍼링은 재전송 요청이 비디오 패킷을 전송하는 오리지널 시스템 보다 보다 최근의 홉에 의해 충족될 수 있도록 허용할 수 있다. 하나의 실시예에서 초당 7.5 프레임에서 제1 레벨 및 제2 레벨을 압축하고 초당 15 프레임에서 제3 레벨을 압축함으로써 초당 30 프레임의 신뢰할만한 프레임율을 달성하도록 우선순위의 3개의 레벨이 달성된다.

Description

멀티-홉 ＲＴＰ 스트림에서의 중요 패킷 손실 처리 시스템 및 방법{SYSTEM AND METHOD FOR HANDLING CRITICAL PACKETS LOSS IN MULTI-HOP RTP STREAMING}
본 발명은 비디오 통신에 관한 것이고 보다 상세하게는 다자간 화상회의 분야에 관한 것이다.
화상회의는 서로 멀리 위치되어 있는 개인이 대면 미팅을 할 수 있도록 한다. 화상회는 시청각 통신을 통해 실행될 수 있다. 화상회의는 2개의 사이트와 같은 적은 수의 사이트간에 이루어질 수 있고(양자간), 또는 다수의 사이트간에 이루어질 수 있다(다자간). 회의 사이트는 단일 참가자(participant)(사용자, 회의참석자(conferee)) 또는 다수의 참가자(사용자, 회의참석자)를 포함할 수 있다. 화상회의는 또한 문서, 프레젠테이션, 정보등을 공유하도록 사용될 수 있다.
참가자는 예를 들어, 화상회의 엔드포인트(EP)를 통해 화상회의에 참여할 수 있다. 엔드포인트(EP)는 예를 들어, 네트워크상의 터미널일 수 있다. 엔드포인트는 다른 터미널 및/또는 멀티포인트 컨트롤 유닛(MCU)과의 실시간, 쌍방 오디오/비주얼/데이터 통신을 할 수 있다. 엔드포인트(EP)는 오디오; 오디오 및 비디오; 데이터, 오디오 및 비디오등을 포함하는 정보/데이터를 상이한 형태로 제공할 수 있다. 용어 "터미널", "사이트" 및 "엔드포인트"는 상호교환되어 사용될 수 있다. 본 발명에서, 용어 엔드포인트는 상기 그룹에 대한 대표적인 용어로서 사용될 수 있다.
엔드포인트는 하나 이상의 리모트 사이트로부터의 비디오 이미지가 표시될 수 있는 디스플레이 유닛(스크린)을 포함할 수 있다. 엔드포인트의 예는 폴리콤 인코퍼레이티드로부터 각각 입수가능한 POLYCOM® VSX® 및 HDX® 시리즈를 포함한다. POLYCOM, VSX, 및 HDX는 폴리콤 인코퍼레이티드의 등록된 상표이다. 비디오컨퍼런싱 엔드포인트는 로컬 사이트로부터 하나 이상의 리모트 사이트로 오디오, 비디오 및/또는 데이터를 전송하고 리모트 사이트로부터 수신된 비디오 및/또는 데이터를 스크린(디스플레이 유닛)에 표시한다.
엔드포인트에서 스크린상에 표시된 비디오 이미지는 레이아웃에 배열될 수 있다. 이러한 레이아웃은 비디오 이미지를 표시하기 위한 하나 이상의 세그먼트를 포함할 수 있다. 세그먼트는 비디오컨퍼런싱 세션에 참여하는 사이트중 하나로부터 수신된 비디오 이미지에 할당될 수 있는 수용 엔드포인트의 스크린의 사전정의된 일부일 수 있다. 2개의 참가자 사이의 비디오컨퍼런스에서, 세그먼트는 엔드포인트의 스크린의 전체 디스플레이 에어리어를 커버할 수 있다. 각 사이트에서, 세그먼트는 다른 사이트로부터 수신된 비디오 이미지를 표시할 수 있다.
로컬 사이트와 다수의 리모트 사이트 사이의 비디오컨퍼런스에서의 비디오 디스플레이 모드의 예는 스위칭 모드일 수 있다. 스위칭 모드는 리모트 사이트중 오직 하나의 리모트 사이트로부터의 비디오/데이터가 한번에 로컬 사이트의 스크린상에 표시되는 모드일 수 있다. 이러한 표시된 비디오는 컨퍼런스의 다이나믹에 따라 다른 사이트로부터 수신된 비디오로 전환될 수 있다.
스위칭 모드와 반대로, 상주(常駐; CP: continuous presence; 항상 면전에 있는 것) 컨퍼런스(회의)에서, 회의참석자(참가자)는 로컬 엔드포인트에서 화상호의에 참가하는 상이한 엔드포인트로부터 다수의 다른 회의참석자를 동시에 관찰할 수 있다. 각 사이트는 레이아웃의 상이한 세그먼트에 표시될 수 있고, 이러한 세그먼트는 로컬 스크린에 표시된다. 이러한 세그먼트는 동일한 사이즈 또는 상이한 사이즈를 가질 수 있다. 스크린에 표시된 사이트 및 이들의, 레이아웃의 세그먼트와의 연관의 조합은 동일한 세션에 참가하는 상이한 회의참석자 사이에 다양할 수 있다. 상주 레이아웃에서, 사이트로부터의 수신된 비디오 이미지는 할당된 세그먼트 사이즈를 맞추기 위해 스케일링 업 또는 다운되거나 크롭핑될 수 있다. 용어 "회의참석자", "사용자" 및 "참가자"는 상호교환되어 사용될 수 있다는 것에 주목해야 한다. 본 발명에서, 용어 회의참석자는 이러한 그룹의 대표 용어로서 사용될 수 있다.
MCU는 비디오컨퍼런스를 관리하도록 사용될 수 있다. MCU는 엔드포인트로부터 다수의 채널을 수신하는 터미널 또는 네트워크의 노드에 보통 위치된 컨퍼런스 컨트롤링 엔티티이고, 특정 기준에 따라, 오디오 및/또는 비주얼 신호를 처리하고 이들을 접속된 채널의 세트에 분배한다.
MCU의 예는 폴리콤 인코퍼레이티드로부터 입수가능한 MGC-100 및 RMX®2000을 포함한다. (RMX2000은 폴리콤 인코퍼레이티드의 등록된 상표이다.) 일부 MCU는 미디어 컨트롤러(MC) 및 미디어 프로세서(MP)의 2개의 로지컬 유닛으로 구성될 수 있다. 엔드포인트 및 MCU의 보다 온전한 정의는 H.320, H.324, H.323을 포함하는 국제 통신 유니온("ITU") 규격에서 발견될 수 있다. ITU 규격 또는 세션 이니시에이션 프로토콜(SIP)와 같은 화상회의 규격 및 프로토콜에 대한 추가 정보는 ITU 웹사이트 www.itu.int에서 또는 엔지니어링 태스크 포스(IETF) 웹사이트 www.ietf.org에서 각각 발견될 수 있다.
다른 화상 회의 시스템은 미디어 릴레이 컨퍼런싱 시스템(MRC)를 사용할 수 있다. MRC에서, 미디어 릴레이 MCU(MRM)는 각 참가하는 미디어 릴레이 엔드포인트(MRE)로부터 하나 이상의 스트림을 수신한다. MRM은 컨퍼런스내의 각 엔드포인트로부터 수신된 다수의 비디오 스트림의 세트를 각 참가하는 엔드포인트에 전달한다. 각 수신하는 엔드포인트는 레이아웃에 따라 CP 비디오 이미지를 생성하도록 다수의 스트림을 사용한다. CP 비디오 이미지는 MRE의 사용자에게 제공된다. MRE는 릴레이된 미디어를 MRM으로부터 수신하고 압축된 미디어를 MRM으로부터의 명령어에 따라 전달하는 능력을 갖는 세션내의 회의참석자의 터미널일 수 있다. MRM은 모든 목적을 위해 그 전체가 언급되어 여기에 통합된 미국 특허 출원 공개 2010/0194847에 보다 상세하게 설명되어 있다. 본 발명의 목적을 위해, 용어 엔드포인트 및 MRE는 상호교환되어 사용될 수 있다.
일부 MRC 시스템에서, 전송 MRE는 품질의 2개 이상의 층, 레벨에서 비디오 이미지를 전송한다. 일부 시스템에서, 2개 이상의 층은 단일 스트림에서 전달된다. 다른 MRC 시스템에서, 각 층은 상이한 스트림과 연관되어 있다. 이러한 시스템은 레이아웃내의 상이한 윈도우 크기, 각 수신 엔드포인트에 의해 사용되는 상이한 해상도, 상이한 프레임율등을 제공할 수 있다. 또한, 복수의 층이 패킷 손실을 극복하기 위해 사용될 수 있다. 품질은 프레임율, 해상도 및/또는 신호-노이즈 비(SNR)등에서 차이가 날 수 있다.
본 명세서에서, 용어 비디오 스트림은 멀티미디어 컨퍼런싱 세션에서의 압축된 미디어(예를 들어, 오디오 및/또는 비디오)의 임의의 전송, 미디어 스트림, 또는 압축된 멀티미디어 스트림의 전송을 사용하는 임의의 애플리케이션을 나타낸다. 미디어는 스케일러블-코딩 인코더에 의해 압축되었다. 또한, 전송된 압축된 미디어는 미디어의 품질에서 서로 상이한 복수의 층을 포함할 수 있다. 상이한 층은 개시된 실시예에 의해 상이하게 처리될 수 있다. 또한, 여기에 사용된 스케일러블-코딩(SC)은 다층 미디어 코딩을 나타낸다.
비디오 스트림은 보다 인기를 얻어가고 있다. 또한, 비디오 컨퍼런싱 시스템은 물론 비디오 스트림의 보다 많은 소스가 복수의 층을 전달하는데, 이러한 층들은 압축된 비디오의 품질에 있어 서로 상이하다. 품질은 몇가지 영역으로 표현될 수 있는데, 타임 영역(예를 들어, 초당 프레임), 공간 영역(예를 들어, 고행상도(HD) 또는 공통 중간 포맷(CIF)) 및/또는 품질(예를 들어, 샤프니스)등이 있다. 비디오 스트리밍 및 멀티퀄리티 층에 대해 사용되는 비디오 압축 규격은 H.264 AVC, H.264 annex G, MPEG-4등을 포함한다. 압축 규격은 SC 규격으로 부를 수 있다. H.264와 같은 압축 규격에 대한 보다 많은 정보는 ITU 웹사이트 www.itu.int 또는 www.mpeg.org에서 발견될 수 있다.
일부 비디오 압축 기술은 2개 타입의 프레임, 인트라 프레임 및 인터 프레임을 사용한다. 인트라 프레임은 비디오 시퀀스내의 임의의 다른 프레임과 관련없고 동일한 프레임내에만 포함된 정보와 관련되어 압축된 비디오 프레임이다. 인터 프레임은 비디오 시퀀스내의 하나 이상의 다른 프레임(기준 프레임)와 관련되어 있고, 동일한 프레임내에 포함된 정보와 과련되어 압축된 비디오 프레임이다. 인터 프레임은 예측 프레임(P 프레임) 및/또는 쌍방향 예측 프레임(B 프레임)을 포함할 수 있다. 비디오 컨퍼런싱에서, B 프레임은 보통 이들이 도입하는 레이턴시 때문에 사용되지 않는다. 다음의 설명에서, 인터 프레임이 용어 P 프레임을 대표하여 사용된다.
인터넷 프로토콜(IP) 네트워크에서 전달되는, 공통 비디오 컨퍼런싱 세션의 미디어(예를 들어, 오디오 및 비디오)는 미디어 패킷의 트랜스포트 프로토콜로서 실시간 트랜스포트 프로토콜(RTP)을 사용한다. RTP 프로토컬은 실시간 컨트롤 프로토콜(RTCP)와 함께 사용된다. RTCP는 전송 통계 및 서비스 품질(QoS)을 감시하도록 사용되고 다수의 스트림의 동기화를 돕는다. 또한, RTP 패킷이 UDP/IP를 통해 전달된다. UDP/IP는 신뢰성이 떨어지고 패킷 손실이 있는 무접속 프로토콜이라는 것은 당업계에 알려져 있다. 패킷 손실을 식별하는 방법으로서, 공통 RTP 프로세서는 비디오 컨퍼런싱 스트림의 소스에서, 시퀀스 넘버를 각 미디어 패킷에 더하고 이들을 이들의 목적지에 전송한다.
압축된 비디오 스트림의 목적지에서, RTP 프로세서는 수신된 패킷을 이들의 시퀀스 넘버에 따라 정리하고 압축된 미디어를 관련 디코더에 전달한다. 패킷 손실을 극복하기 위해, RTP 프로세서는 커넥션의 양단부에서, 상이한 전송 에러 보정 기술을 사용할 수 있다. 또한, 비디오 인코더/디코더는 커넥션의 양단부에서, 패킷 손실을 극복하기 위해 상이한 회복 방법을 사용한다. 또 다른 회복 방법은 스트림의 소스쪽으로 전송되는 하나 이상의 손실 패킷에 대한 재전송 요청을 포함할 수 있다.
화상회의와 같은 실시간 통신에서, 재전송은 재전송된 프레임이 엔드포인트중 하나에 의해 요청되었을지라도, 인트라 프레임을 인코딩하여 이것을 비디오 이미지를 나타내는 모든 엔드포인트로 전송하는 단계를 포함할 수 있다. 인트라 프레임의 전송은 프레임율에서의 임시 감소로 인해 네트워크상의 대역폭 소비량을 증가시키고 사용자 경험을 감소시킨다.
패킷 손실은 보통 복수의 미디어-홉을 사용하는 세션에서 보다 일반적이다. 미디어-홉은 2개 이상의 엔드포인트 사이에 중간 노드일 수 있다. 예를 들어, 미디어-홉은 MCU, MRM, 미디어 게이트웨이등일 수 있다. 본 명세서의 목적을 위해, 용어 MCU, MRM, 미디어 게이트웨이 및 미디어-홉은 문맥에 따라 상호교환되어 사용될 수 있다. 복수의 미디어-홉이 수반되는 세션에서, 패킷은 경로의 임의의 세그먼트에서 손실될 수 있다. 따라서, 제1 홉으로의 경로중에 손실된 패킷은 스트림의 목적에서의 터미널을 포함하는 하나 이상의 연속 홉은 물론 제2 홉에 의해 요청될 수 있다. 이러한 경우에, 복수의 재전송된 패킷이 수반되는 복수의 불필요한 재전송 요청은 네트워크와 커넥션의 양단부의 엔드포인트에 부담이 될 것이다.
세션에 의한 대역폭 소비 감소는 물론 화상회의 세션의 회의참석자의 경험을 강화시키는 방법 및 시스템의 실시예가 개시되어 있다. 상이한 방법이 미디어 압축 기술이 복수의 확장가능층을 전하는, 미디어 스트리밍 시스템에서 사용될 수 있다. 예를 들어, 개시된 기술은 비디오 압축이 SC에 기초하는 비디오 컨퍼런싱 세션에서 구현될 수 있다. SC 압축 규격의 예는 SVC로 보통 부르는 H.264 annex G일 수 있다. SC에서 상이한 층은 상이한 레벨의 중요도를 갖는데, 그 이유는 층 간 종속성 때문이다. 예를 들어, 3개의 층(T0, T1, T2)이 사용되는 시간적 확장성에서, 각 층은 도 1a에 도시된 바와 같이 상이한 프레임율과 연관되어 있다. 도 1a의 X 축은 30 초당 프레임(F/s)의 프레임율으로 SC에서 인코딩되는 RTP 스트림에서의 프레임을 나타낸다. 압축된 30F/s로 전달하기 위해, 압축된 스트림은 목적지로 전송되는 3개의 층을 포함한다.
제1 층은 베이스층(BL)이다. 시간적 확장성에 대해, BL은 T0로 부를 수 있다. BL(T0)은 7.5F/s에서 압축되는 압축된 프레임을 포함하고, 각 프레임은 동일한 층 BL(T0)의 선행 프레임을 인코딩하는 동안 생성된 기준 프레임에 기초하여 압축된다. 따라서, 이러한 층 BL(T0)의 제2 프레임인 프레임 #5는 이러한 층의 제1 프레임(프레임 #1)을 인코딩하는 동안 생성된 기준 프레임에 기초하여 압축된다. 이러한 층 BL(T0)의 3번째 프레임인 프레임 #9는 이러한 층의 2번째 프레임(프레임 #5)을 인코딩하는 동안 생성된 기준 프레임에 기초하여 압축된다. 나머지도 마찬가지 방식으로 압축된다.
제2 층은 제1 강화된 층(EL1)이다. 시간적 확장성에 대해, EL1은 T1으로 부를 수 있다. EL1(T1)은 제1 층 BL(T0)로부터 2개의 프레임 시프트된 7.5 F/s에서 압축된 압축 프레임을 포함한다. 각 프레임은 제1 층 BL(T0)의 선행 프레임을 인코딩하는 동안 생성된 기준 프레임에 기초하여 압축된다. 따라서, 층 EL1(T1)의 제1 층인 프레임 #3은 층 BL(T0)의 제1 프레임(프레임 1)에 기초하여 압축된다. 층 EL1(T1)의 제2 프레임인 프레임 #7은 층 BL(T0)의 제2 프레임(프레임 5)에 기초하여 압축된다. 나머지도 마찬가지 방식으로 압축된다. 따라서, 층 BL(T0)과 EL1(T1)의 프레임을 포함하는 스트림은 디코딩되고 15 F/s의 프레임율로 표현될 수 있다.
제3 층은 제2 강화된 층(EL2)이다. 시간적 확장성에 대해, 제3 층은 T2로 부를 수 있다. EL2(T2)은 15 F/s에서 압축된 압축 프레임을 포함할 수 있는데, 이러한 층의 제1 프레임, 프레임 2는 BL(T0)의 제1 프레임, 프레임 1과 EL1(T1)의 제1 프레임, 프레임 3 사이에 있다. EL2(T2)의 각 홀수 프레임은 제1 층 BL(T0)의 선행 프레임을 인코딩하는 동안 생성된 기준 프레임에 기초하여 압축된다. EL2(T2)의 각 짝수 프레임은 제2 층 EL1(T1)의 선행 프레임을 인코딩하는 동안 생성된 기준 프레임에 기초하여 압축된다. 따라서, 층 EL2(T2)의 제1 층인 프레임 #2는 층 BL(T0)의 제1 프레임(프레임 1)에 기초하여 압축된다. 층 EL2(T2)의 제2 프레임인 프레임 #4는 층 EL1(T1)의 제1 프레임(프레임 3)에 기초하여 압축된다. 나머지도 마찬가지 방식으로 압축된다. 따라서, 층 BL(T0), EL1(T1) 및 EL2(T2)의 프레임을 포함하는 스트림은 디코딩되고 30 F/s의 프레임율로 표현될 수 있다.
상술된 상이한 층을 압축하는 방법에 기초하여, 층 사이의 우선순위가 할당될 수 있다. 베이스층, BL(T0)의 프레임은 가장 중요한 프레임이고 최고 우선순위를 가질 수 있는데, 그 이유는 다른 2개의 층, EL1과 EL2(시간적 확장성에 대해 T1과 T2)의 각각의 프레임의 디코딩이 BL(T0)의 선행 프레임에 의존하기 때문이다. EL1(T1)의 프레임은 덜 중요한데, 그 이유는 EL2(T2)의 프레임의 디코딩만이 EL1(T1)의 프레임에 기초하고 있기 때문이다. 마찬가지 방식으로, EL2(T2)의 프레임은 EL1(T1)의 프레임 보다 덜 중요하다. EL2(T2)의 프레임, 예를 들어, 프레임 8의 압축된 데이터를 전달하는 패킷을 손실하게 되면, 층 BL(T0)에 속하는, 다음 프레임, 프레임 9를 수신할 때까지 단시간 동안(~30ms) 표현 이미지의 품질이 떨어진다. 그러나, BL(T0), 프레임 13의 데이터를 전달하는 패킷이 손실되면, 장시간의 결함이 발생할 수 있고, 따라서, 인트라 프레임이 손실 패킷으로부터 회복되기 위해 필요할 수 있다.
실시예는 확장 헤더를 포함하기 위해, SC 압축된 데이터를 전달하는, 패킷의 RTP 헤더를 수정할 수 있다. 확장 헤더는 이러한 패킷에 의해 전달되는 압축된 비디오의 우선순위를 나타내는 필드를 포함할 수 있다. 이러한 필드는 PrID 필드로 부를 수 있고, Pr0는 최고 우선순위를 나타낸다. 일부 실시예에서, 전송 엔드포인트(압축된 스트림의 소스)가 우선순위 레벨을 정할 수 있다. 일부 실시예에서, 우선순위 레벨은 세션 동안 변경될 수 있다. 우선순위 변경은 예를 들어, 수신 재전송 요청의 빈번도에 종속될 수 있다. 베이스층, BL(T0)의 압축된 비디오 데이터를전달하는 패킷은 최고 우선순위, Pr0의 마크를 가질 수 있다. EL2(T2)의 압축된 비디오 데이터를 전달하는 패킷은 최하 우선순위 Pr2의 마크를 가질 수 있다. 재전송 요청이 거의 수신되지 않는 일부 세션에서, 전송 엔드포인트는 최고 우선순위 Pr0를 양층 T0 및 T1에 부여할 수 있다. 또한, 소스로부터 목적지까지의 경로를 따른 미디어 홉은 보다 낮은 우선순위를 갖는 RTP 패킷을 떨어뜨리고 보다 높은 우선순위를 갖는 RTP 패킷을 전송하도록 구성될 수 있다. 미디어 홉의 예로서 미디어 GW, MCU, MRM, 브리지등이 있을 수 있다.
또한, RTP SC 패킷의 목적지에서, RTP 프로세서는 보다 높은 우선순위의 손실 패킷과 비교하여 보다 낮은 우선순위를 갖는 손실 패킷에 상이하게 응답하도록 적용될 수 있다.
다른 실시에에서, RTP 확장 헤더는 시퀀스 넘버와 연관될 수 있는 새로운 필드를더 포함할 수 있다. 제1 시퀀스 넘버는, 스트림의 소스에 의해, Pr0 프레임의 압축된 데이터를 전달하는 각 RTP 패킷에 대해 증가될 수 있다. 이러한 필드의 값은 소스로부터 RTP 패킷의 수신 엔드포인트까지 변경되지 않은 상태로 남아 있다. 이러한 시퀀스 넘버는 Original-Pr0-Sequence Number(OPr0SN)로 부를 수 있다. OPr0SN은 SC 스트림의 목적지의 디코더에 접속된 RTP 프로세서가 손실 Pr0 패킷을 식별할 수 있도록 한다. BL(T0) 패킷과 같은 중요한 패킷이 손실된 것으로 발견되면, I-프레임에 대한 요청이 만들어질 수 있다.
제2 시퀀스 넘버는 Hop-Pr0-Sequence Number(HPr0SN)로 부를 수 있다. HPr0SN은 스트림의 경로를 따라 각 미디어-홉에 의해 대체된다. HPr0SN은 그 다음 홉에 접속된 RTP 프로세서가 이러한 RTP 프로세서 이전의 마지막 세그먼트에서 손실된 Pr0 패킷을 식별할 수 있도록 한다. 이러한 필드는 하나의 홉으로부터 그 다음 홉으로 변경된다. 각 홉은 다른 시퀀스 카운터를 사용할 수 있어서, HPr0SN의 값은 하나의 홉으로부터 다른 홉으로 극적으로 상이할 수 있다. 각 홉은 각 전송되거나 재전송된 Pr0 패킷 마다, 그 시퀀스 넘버, HPr0SN의 값을 증가시킨다.
또한, 각 홉의 RTP 프로세서는 이러한 필드를 체크하도록 적용될 수 있다. BL(T0) 패킷과 같은 중요한 패킷(Pr0)이 그 다음 RTP 수신기에 의해 손실된 것으로 발견되면, RTCP 재전송 요청을 사용하여 RTP 수신기로부터 그 전송자로 재전송 요청이 전송될 수 있다. 손실 중요 패킷(Pr0)를 식별하고 손실 핵심 패킷의 재전송을 요청하기 위해 HPr0SN 필드를 사용함으로써 하위 우선순위 손실 패킷의 재전송의 오버헤드 트래픽을 효과적으로 제거한다. 또한, 각 홉은 출구와 그다음 RTP 수신기 사이에 발생된 중요 패킷(Pr0)에 대한 재전송 요청에 국부적으로 응답하기 위해, 전송된 중요 패킷의 임시 메모리 디바이스를 처리하도록 구성될 수 있다. 예시된 임시 메모리는 수십 또는 수백개의 마지막 전송된 Pr0 패킷을 저장할 수 있다. 임시 메모리의 예는 그 주소 비트가 HPr0SN의 마지막 수 비트(예를 들어, 6,8 또는 10 비트)일 수 있는 램(RAM)일 수 있다.
또 다른 실시예에서, HPr0SN는 모든 층의 패킷을 계산하기 위해 사용될 수 있다. 이러한 실시에에서, 그다음 홉의 RTCP는 이전의 홉으로부터 세그먼트에서 발생되는 동안, 층에 관계없이 손실 패킷의 재전송을 요청함으로써 손실 패킷에 응답할 수 있다.
제3 시퀀스 넘버는 Original-Sequence Number(OSN)로 부를 수 있다. 0SN은 압축된 스트림의 소스에 의해 제어되고 모든 홉에 걸쳐 미변경 상태로 남을 것이다. 0SN은 각 전송된 패킷 마다, 그 우선순위에 관계없이, 이러한 패킷에 전달되는 확장가능한 층에 관계없이 증가된다. 0SN은 압축된 SC 스트림이 디코딩되는, 스트림의 목적지의 RTP 프로세서가 패킷을 구성한 후 이들을 비디오 디코더에 전송할 수 있도록 한다.
당업자는 본 실시예가 시간적 확장성에 관련되어 있지만 본 발명이 시간적 확장성에 제한되지 않고 예를 들어, 공간적 확장성과 같은 다른 타입의 확장성으로 구현될 수 있다는 것을 이해할 것이다.
본 발명의 다른 특징은 첨부된 도면 및 상세한 설명에 의해 명백할 것이다. 상술된 요약부분은 본 발명의 각 잠재적 실시예 또는 모든 특징을 요약하고자 하는 것이 아니고, 본 발명의 다른 특징 및 장점은 첨부된 도면 및 첨부된 청구범위와 상세한 설명을 통해 명백해질 것이다.
또한, 특정 실시예가 당업자에게 본 발명의 개념을 설명하기 위해 기술되었지만, 이러한 실시예는 당야한 수정 및 대안의 형태를 역시 포함한다. 따라서, 도면 및 설명은 본 발명의 범위를 제한하는 것은 아니다.
개시된 시스템의 실시예는 손실 패킷의 재전송을 높은 우선순위(Pr0)를 갖는 패킷만으로 제한할 수 있다. 따라서, 개시된 시스템 및 방법은 대역폭 소비량을 감소시킬 수 있고 인트라 프레임의 재전송에 대한 요청을 감소시켜 회의참석자의 경험을 향상시킬 수 있다.
도 1a는 하나 이상의 실시예에 따른 3개의 층의 시간적 확장성을 사용하는, 30F/s의 압축된 비디오 스트림의 가능한 SC 구조의 개략도이다.
도 1b는 실시예에 따른, 다양한 전자 화상회의 시스템을 포함하는 멀티미디어 컨퍼런싱 시스템(100)을 도시하는 도면이다.
도 2a는 실시예에 따른 전송 엔드포인트의 RTP 프로세서의 예의 관련 엘리먼트를 갖는 블록도이다.
도 2b는 실시예에 따른 수신 엔드포인트의 RTP 프로세서의 예의 관련 엘리먼트를 갖는 블록도이다.
도 3a는 중간 미디어 홉의 전송-RTP 프로세서의 실시예의 관련 엘리먼트를 갖는 블록도이다.
도 3b는 중간 미디어 홉의 실시예에 따른, 중간 미디어 홉의 수신-RTP 프로세서의 실시예의 관련 엘리먼트를 갖는 블록도이다.
도 4는 전송-ER-RTP-프로세서의 실시예의 전송 태스크의 관련 블록을 갖는 순서도이다.
도 5a 및 도 5b는 압축된 SC 스트림의 목적지 엔드포인트의 RTP 프로세서의 예의 수신부에 의해 구현될 수 있는 수신 방법의 관련 블록을 갖는 순서도이다.
도 6은 압축된 SC 스트림을 수신하면서 중간 미디어-홉의 RTP 프로세서의 예에 의해 구현될 수 있는 방법예의 관련 블록을 갖는 순서도이다.
도 7은 압축된 SC 스트림을 전송하면서 중간 미디어-홉의 RTP 프로세서의 예에 의해 구현될 수 있는 방법예의 관련 블록을 갖는 순서도이다.
다수의 도면에서 동일한 부재번호는 동일한 부재를 나타내는 도면에, 본 발명의 상이한 실시예가 설명되어 있다. 편의를 위해, 동일한 그룹의 일부 부재만이 번호가 매겨져 있다. 도면의 목적은 상이한 실시예를 기술하기 위한 것이고 제조를 위한 것은 아니다. 따라서, 도면에 도시된 특징은 편의 및 이해를 위해서만 선택되었다. 또한, 본 발명에 사용된 언어는 주로 이해를 위해 선택되었고, 본 발명은 한정하려는 것은 아니다.
명세서에서 "하나의 실시예" 또는 "실시예"는 이러한 실시예에 관련하여 기술된 특정 특징, 구조, 또는 특성이 본 발명의 적어도 하나의 실시예에 포함된다는 것을 의미하고, "하나의 실시예" 또는 "실시예"를 여러번 언급하는 것은 모두 반드시 동일한 실시에를 언급하는 것이 아님을 이해해야 한다.
다음의 설명의 일부가 소프트웨어 또는 펌웨어와 관련되어 기록되었지만, 실시예는 여기에 기술된 특징 및 기능을 소프트웨어, 펌웨어, 및 하드웨어의 임의의 조합을 포함하는, 소프트웨어, 펌웨어 또는 하드웨어로 구현할 수 있다. 다음의 설명에서, 단어 "유닛", "엘리먼트", "모듈" 및 "로지컬 모듈"은 상호교환되어 사용될 수 있다. 유닛 또는 모듈로서 지정된 것은 독립형 유닛 또는 전용 또는 일체화된 모듈일 수 있다. 유닛 또는 모듈은 용이하게 제거되고 또 다른 유사한 유닛 또는 모듈로 대체될 수 있는 모듈러 또는 모듈러 특징을 가질 수 있다. 각 유닛 또는 모듈은 유닛 또는 모듈에 할당된 기능을 수행하도록 프로그램화된 하나 이상의 프로세서를 얻을 수 있는, 소프트웨어, 하드웨어, 및/또는 펌웨어중 어느 하나 또는 임의의 조합일 수 있다. 또한, 동일하거나 상이한 타입의 다수의 모듈은 단일 프로세서에 의해 구현될 수 있다. 로지컬 모듈의 소프트웨어는 읽기/쓰기 하드 디스크, CDROM, 플래시 메모리, ROM, 또는 다른 메모리 또는 저장매체등과 같은 컴퓨터 판독가능 매체에 구현될 수 있다. 특정 태스크를 수행하기 위해, 소프트웨어 프로그램이 필요한대로 적합한 프로세서에 설치될 수 있다. 본 발명에서, 용어, 태스크, 방법, 프로세스는 상호교환되어 사용될 수 있다.
도 1a는 3개 층의 시간적 확장성을 사용하여, 30F/s의 SC 압축된 비디오 스트림의 압축된 프레임 사이의 관계를 설명한다. 위에서 도 1a의 설명을 참조할 수 있다.
도 1b는 본 발명의 하나의 실시예에 따른 멀티미디어 컨퍼런싱 시스템(100)을 설명한다. 시스템(100)은 네트워크(110), 하나 이상의 미디어 릴레이 MCU(MRM)(120), 및 복수의 미디어 릴레이 엔드포인트(MRE)(130)를 포함할 수 있다. 시스템(100)의 다른 실시예에서, MRM(120)은 멀티포인트 컨트롤 유닛(MCU)일 수 있고, 복수의 MRE(130)는 비디오 컨퍼런싱 엔드포인트(EP)일 수 있다. 네트워크(110)는 임의의 패킷 교환망, IP 네트워크, 또는 이들의 임의의 조합일 수 있다. 세션 관리 통신은 H.323, 및 SIP와 같은 프로토콜에 기초할 수 있고, 미디어 트랜스포트 프로토콜은 RTCP를 갖는 RTP에 기초할 수 있고, 오디오 압축 규격 G.711 및 G.719과 같은 미디어 압축 규격 및/또는 비디오 스트리밍 및 멀티-퀄리티 스트림에 사용되는 비디오 압축 규격: H.264 AVC, H.264 annex G, MPEG-4등을 사용할 수 있다.
각 EP 또는 MRE(130)는 실시간, 양방향 시청각 통신을 또 다른 엔드포인트(130) 또는 MCU(120)에 제공할 수 있다. EP(130)는 세션내의 회의참석자의 터미널일 수 있고, 이것은 MCU로부터 압축된 미디어를 수신하고 압축된 오디오 및 비디오 데이터를 MCU로부터의 명령어에 따라 전달하는 능력을 갖고 있다. 비디오 컨퍼런싱 엔드포인트 및 MCU의 공통 동작은 당업자에게 잘 알려져 있기 때문에 여기에 상세하게 설명하지 않을 것이다.
MRE(130)의 예는 MRM쪽으로 하나 이상의 압축된 비디오 스트림을 전달할 수 있고 MRM(120)으로부터 하나 이상의 선택된 압축된 비디오 스트림을 수신할 수 있다. MRE는 수신된 하나 이상의 압축된 비디오 스트림을 디코딩하고 이러한 디코딩된 스트림을 MRE(130)의 스크린상에 표시되는 비디오 이미지로 구성할 수 있다. MRM(120)은 복수의 MRE(130)로부터 복수의 압축된 비디오 스트림을 수신하고, 압축된 비디오 스트림중 하나 이상의 세트를 선택하고, 압축된 비디오 스트림의 하나 이상의 세트를 미디어 릴레이 컨퍼런싱(MRC) 세션에 참가하는 복수의 MRE(130)쪽으로 릴레이하는 미디어 릴레이 MCU이다. MRE, MRM 및 MRC에 대해 보다 배우기 원하는 독자는 여기에 언급되어 전체가 통합된 미국 특허 출원 공개 US2010/0,194,847를 참조할 수 있다.
여기에 설명된 EP 또는 MRE(130)의 공통 동작에 더하여, EP/MRE(130)가 2개의 타입의 RTP 프로세서를 포함하도록 구성될 수 있다. RTP 프로세서의 하나의 타입은 전송-엔드포인트-RTP 프로세서(TERP)로 부를 수 있다. 각 TERP는 비디오 스트림의 인코더(도면에 도시되지 않았다)와 네트워크 인터페이스 카드(도면에 도시되지 않았다) 사이에 통신가능하도록 결합될 수 있다. TERP의 실시예는 압축된 비디오 네트워크 추상 계층(NAL) 데이터 유닛의 스트림을 취득할 수 있고, 이러한 NAL 유닛을 RTP 패킷으로 통합할 수 있고, RTP 패킷을 네트워크 인터페이스쪽으로 전송하기 전에 확장된 RTP 헤더를 RTP 패킷에 더할 수 있다. 동시에, 최우선층(Pr0)의 압축된 비디오를 전달하는 RTP 패킷은 임시 메모리에 저장될 수 있다. 이러한 저장된 패킷은 전송 엔드포인트와 그 다음 미디어 홉 사이의 손실된 Pr0 패킷의 경우에(즉 패킷 손실) 재전송을 위해 사용될 수 있다.
확장된 RTP 헤더는 공통 RTP 헤더의 필드를 포함할 수 있다. 필드는 시퀀스 넘버(SN), 타입 스탬프등이 있다. 또한, 확장된 RTP 헤더는 개시된 기술의 실시에에 의해 사용되는 확장된 추가 4개의 필드를 포함할 수 있다. PrID로 부를 수 있는 하나의 필드는 RTP 패킷에 의해 전달된 압축된 비디오층의 우선순위 레벨을 나타낼 수 있고, Pr0는 최우선순위를 나타낸다. 다른 필드는 오리지널-시퀀스 넘버(OSN)으로 부를 수 있는 시퀀스 넘버에 할당될 수 있다. OSN은 모든 중간 미디어 홉을 통해 미변경 상태로 남을 것이다. OSN은 우선순위에 관계없이 패킷의 우선 전송을 위해, TERP에 의해 증가된다. OSN에 의해, 압축된 SC 스트리이 디코딩되는, 스트림의 목적지에서의 RTP 프로세서가 패킷을 구성하여 이들을 비디오 디코더(도면에 도시되지 않았다)쪽으로 전송할 수 있다.
다음 필드가 중요(critical) 프레임(Pr0 프레임)의 압축된 데이터를 전달하는 각 RTP 패킷 당 증가될 수 있는 다른 새로운 시퀀스 넘버에 할당될 수 있다. 이러한 필드의 값은 소스 EP의 TERP로부터 RTP 패킷의 수신 엔드포인트까지 미변경 상태로 남아 있다. 이러한 시퀀스 넘버는 오리지널-Pr0-시퀀스 넘버(OPr0SN)으로 부를 수 있다. OPr0SN은 각 중요 먼저 전송된 (Pr0) RTP 패킷에 대해 증가된다. OPr0SN에 의해 SC 스트림의 목적지의 디코더(도면에 도시되지 않았다)에 접속된 RTP 프로세서가 손실된 Pr0 패킷을 식별할 수 있다. BL(T0) 패킷과 같은 중요 패킷이 손실된 것으로 발견되면, 인트라 프레임(I 프레임)이 요청될 수 있다.
제4 필드가 홉-Pr0-시퀀스 넘버(HPr0SN)으로 부를 수 있는 시퀀스 넘버에 대해 할당될 수 있다. HPr0SN는 스트림의 경로를 따라 각 미디어-홉에 의해 대체될 수 있다. HPr0SN에 의해, RTP 프로세서는 그 다음 미디어-홉에서, 해당 세그먼트에서 손실된 Pr0 패킷을 식별할 수 있다. 그다음, HPr0SN 값은 하나 이상의 손실된 중요 패킷의 재전송을 요청하기 위해 이러한 미디어-홉에 의해 사용될 수 있다. TERP의 실시에에 대한 보다 상세한 정보는 도 2a 및 도 4과 관련하여 아래에 설명되어 있다.
제2 타입의 RTP 프로세서는 수신-엔드포인트-RTP 프로세서(RERP)로 부를 수 있다. RERP의 예는 엔드포인트의 네트워크 인터페이스 카드(도면에 도시되지 않음)와 이러한 엔드포인트에서의 비디오 스트림의 디코더(도면에 도시되지 않음) 사이에 통긴가능하도록 결합될 수 있다. RERP의 실시예는 압축된 비디오 NAL 데이터 유닛을 전달하는 RTP 패킷의 스트림을 취득할 수 있다. RERP의 실시예는 확장된 RTP 헤더를 파싱할 수 있다. 값 HPr0SN에 기초하여 RERP는 중요 패킷이 마지막 미디어 홉과 수신 EP 사이의 마지막 네트워크 세그먼트에서 손실되었는지 여부를 판단할 수 있다.
RERP는 확장된 RTP 헤더의 OSN 필드에 따라 수신된 RTP 패킷을 구성할 수 있고 OPr0SN은 중요 패킷이 손실되었는지 여부를 판단하기 위해 체크될 수 있고, 만약 손실되었다면, 인트라 프레임에 요청이 해당 스트림의 소스인 인코더(도면에 도시되지 않음)에 전송될 수 있다. 구성된 RTP 패킷은 압축된 NAL 데이터 유닛으로 파싱될 수 있다. 압축된 NAL 데이터 유닛은 디코더(도면에 도시되지 않음)에 전송될 수 있다. 확장된 RTP 헤더를 처리하도록 구성된 MRE(130)의 예는 MRM(120)로부터 릴레이된 압축된 비디오의 각 스트림 당 하나씩, 복수의 RERP를 포함할 수 있다. RERP의 실시예에 대한 보다 상세한 정보는 도 2b와 도 5a, 도 5b와 관련하여 아래에 나타나 있다.
본 발명에 따라 구성된 MCU의 실시예는 복수의 RERP 모듈과 복수의 TERP 모듈을 포함할 수 있다. 각 RERP 모듈은 엔드포인트에 할당된 네트워크 인터페이스 카드(도면에 도시되지 않음)와 디코더를 포함하는 입력 포트(도면에 도시되지 않음) 사이에 통신가능하도록 결합될 수 있다. 이러한 입력 포트는 해당 엔드포인트에도 할당되어 있다. 각 RERP는 상술된 EP의 RERP 유닛과 유사한 태스크를 수행할 수 있다. 입력 포트의 디코더로부터의 디코딩된 비디오는 출력 포트로 전송될 수 있다. 출력 포트는 복수의 입력 포트로부터 디코딩된 비디오를 취득할 수 있고, 디코딩된 비디오를 스케일링하고 CP 비디오 이미지를 구성할 수 있다. CP 비디오 이미지는 출력 포트(도면에 도시되지 않음)의 SC 비디오 인코더에 의해 압축될 수 있다. 각 출력 포트는 수신 EP에 할당될 수 있다.
각 출력 포트로부터의 압축된 CP 비디오 이미지의 NAL 데이터 유닛은 출력 포트와 동일한 수신 EP에 할당되고 동일한 EP에 할당된 네트워크 인터페이스 카드(도면에 도시되지 않음)에 통신가능하도록 결합되어 있는 TERP로 전송될 수 있다. 각 TERP는 상술된 바와 같이 EP의 TERP 유닛과 유사한 태스크를 수행할 수 있다.
본 발명에 따라 구성된 MRM(120)의 실시예는 하나 이상의 중간-미디어-홉-수신-RTP 프로세서(IMHRRP) 및 하나 이상의 중간-미디어-홉-전송-RTP 프로세서(IMHTRP)를 포함할 수 있다. 각 IMHRRP는 MRE(130)로부터 수신된 압축된 SC 비디오의 스트림에 할당될 수 있고 하나 이상의 다른 MRE에 릴레이될 수 있다. 공통 RTP 프로세서의 다른 태스크중에, IMHRRP의 실시예는 할당된 MRE로부터 압축된 SC 비디오의 RTP 패킷을 취득할 수 있고 확장된 RTP 헤더를 파싱할 수 있다. HPr0SN 필드에 기초하여, 중요 패킷이 마지막 세그먼트에서 손실되었는지 여부가 판단될 수 있다. 만약 손실되었다면, IMHRRP는 FPr0SN에 기초하여 이전의 미디어 HOP에 재전송 요청을 보낼 수 있다. IMHRRP의 실시예는 확장 헤더의 PrID 필드를 체크할 수 있다. Pr0ID 필드가 Pr0이라면, IMHRRP는 그 HPr0SN을 증가시킬 수 있고 RTP 헤더내의 HPr0SN 필드의 값을 IMHRRP의 HRr0SN 카운터의 새로운 값으로 대체할 수 있다. Pr0ID 값이 Pr0가 아니라면, HPr0SN 카운터는 증가되지 않고 그 이전의 값은 확장된 RTP 헤더의 HPr0SN 필드로 로딩된다. SN 값은 새로운 값으로 대체될 수 있고 RTP 패킷은 하나 이상의 MRE(130)쪽으로 전송될 수 있다. 최우선순위층(Pr0)의 압축된 비디오를 전달하는 RTP 패킷은 임시 메모리에 저장될 수 있다. 저장된 패킷은 MRM(120)과 그 다음 미디어 홉 또는 MRE 사이에 손실된 Pr0 패킷이 있는 경우에 재전송을 위해 사용될 수 있다. MRM(120)에 대한 보다 상세한 정보는 도 3a, 도 3b, 도 6 및 도 7와 관련하여 아래에 설명되어 있다.
도 2a는 전송 EP의 하나의 실시예의 전송-EP-RTP-프로세서(TERP)(200)의 관련 엘리먼트를 갖는 블록도이다. EP는 자체 CP 이미지를 구성하는 MRE 또는 MCU로부터 CP 비디오 이미지를 수신하는 공통 비디오컨퍼런싱 엔드포인트일 수 있다. 다른 엘리먼트중에, MRE의 실시예는 하나 이상의 TERP(200)을 포함할 수 있다. 각 TERP(200)는 MRE의 인코더(도면에 도시되어 있지 않음)와 연관되어 있을 수 있다. TERP(200)의 실시예는 NAL 누산기(210), RTP 헤더 빌더(215), 전송 버퍼(2200, 재전송-Pr0 버퍼(ReX Pr0 버퍼)(225), 전송 RTP 매니저(230) 및 4개의 시퀀스 카운터(235a-d)를 포함할 수 있다. 관련 EP가 비디오컨퍼런스에 참여할 때, 각 시퀀스 카운터는 예를 들어, 무작위로 생성된 수로 설정될 수 있다.
하나의 시퀀스 카운터(235a)는 공통 RTP 시퀀스 수를 카운트할 수 있고, 이러한 카운터는 LastSN으로 부를 수 있고 재전송 요청에 응답하여 또는 처음으로 엔드포인트로부터 전송된 각 RTP 패킷 마다 증가될 수 있다. LastSN의 값은 전송된 RTP 패킷의 헤더의 SN 필드에 기록딜 수 있다. 다른 시퀀스 카운터(235b)는 (도면에 도시되지 않은) 관련 EP의 연관된 인코더에 의해 압축된 오리지널 RTP 패킷을 카운트할 수 있다. 시퀀스 카운터(235b)는 LastOSN으로 부를 수 있고 처음으로 엔드포인트로부터 전송된 각 오리지널 (전송되지 않은) RTP 패킷 마다 증가될 수 있다. LastOSN의 값은 전송된 RTP 패킷의 확장된 헤더의 OSN 필드에 기록될 수 있다. 또 다른 시퀀스 카운터(235c)는 Pr0 프레임의 압축된 데이터를 전달하는 오리지널 RTP 패킷을 카운트할 수 있다. 시퀀스 카운터(235c)는 LastOPrOSN으로 부를 수 있고 Pr0 프레임의 압축된 데이터를 전달하고 처음으로 엔드포인트로부터 전송되는 각 오리지널 (재전송되지 않은) RTP 패킷 마다 증가될 수 있다. LastOPrOSN 카운터의 값은 전송된 RTP 패킷의 확장된 헤더의 OPrOSN에 기록될 수 있다. 마지막 시퀀스 카운터(235d)는 Pr0 프레임의 압축된 데이터를 전달하고 해당 EP로부터 전송된 RTP 패킷을 카운트할 수 있다. 이러한 시퀀스 카운터(235d)는 LastHPrOSN으로 부를 수 있고 Pr0 프레임의 압축된 데이터를 전달하고 엔드포인트로부터 전송되거나 재전송된 각 오리지널 및 재전송된 RTP 패킷 마다 증가될 수 있다. LastHPrOSN 카운터의 값은 RTP 패킷의 확장된 헤더의 HPrOSN에 기록될 수 있다.
TERP(200)의 실시에는 그 연관된 인코더(도면에 도시되지 않음)로부터 압축된 NAL 유닛의 스트림을 수신할 수 있다. NAL 유닛의 스트림은 상이한 우선순위를 갖는 2개 이상의 레벨의 압축된 NAL 유닛을 전달할 수 있다. NAL 유닛의 취득된 스트림은 RTP 패킷을 완성하도록 RTP 프로토콜의 조건을 충존시킬 때까지 NAL 누산기(210)에 통합될 수 있다. RTP 패킷에 대한 조건의 예는 RTP 패킷의 페이로드로서 전달되는 바이트의 수일 수 있고, 다른 조건은 비디오 프레임의 끝일 수 있고, 또 다른 조건은 다른 우선순위 레벨을 갖는 NAL일 수 있다. 이러한 조건이 나타날 때, 하나 이상의 통합된 NAL은 헤더 빌더(215)의 큐로 RTP 패킷의 페이로드로서 전송될 수 있다.
헤더 빌더(215)의 하나의 실시에에서, 패킷의 공통 RTP 헤더가 패킷의 페이로드에 추가될 수 있다. 공통 RTP 헤더의 확장 필드는 확장된 RTP 필드의 존재를 나타내도록 설정될 수 있다. 다른 필드중에, 공통 RTP 헤더는 타임 스탬프 필드에 기록된 포착된 시간을 포함할 수 있다. 다음으로, LastSN 카운터(235a)의 값은 RTP 헤더등의 SN 필드에 복제될 수 있다.
공통 헤더에 더하여, 확장된 헤더의 필드가 추가될 수 있다. 압축 데이터의 확장가능층이 인코더로부터 수신될 수 있고 패킷의 우선순위 레벨이 Pr0, Pr1등으로 정의될 수 있다. 하나의 실시에에서, 패킷의 우선순위 레벨은 수신된 재전송 요청의 빈번도에 기초할 수 있다. 복수의 재전송 요청이 수신되면, 압축된 프레임의 베이스층을 전달하는 패킷만이 Pr0로서 정의될 수 있다. 소수의 재전송 요청이 수니되었다면, 제 강화층 및 베이스층의 압축된 층을 전달하는 패킷이 Pr0 패킷으로 정의될 수 있다. 일부 실시예에서, 우선순위 레벨은 재전송 요청의 빈번도의 함수로서, 컨퍼런스 세선 동안 변경될 수 있다. Pr 값은 확장된 RTP 헤더의 Pr 필드에 저장될 수 있다.
또한, 3개의 시퀀스 카운터(각각, 235b, 235c, 235d)의 값, LastOSN, LastOPrOSN, LastHPrOSN은 확장된 RTP 헤더내의 적합한 필드, 필드 OSN, OPrOSN, HPrOSN에 각각 복제될 수 있다. 확장된 RTP 헤더를 갖는 구성된 RTP 패킷은 전송 버퍼(220)를 통해 헤더 빌더(215)로부터 네트워크 인터페이스 카드(도면에 도시되지 않음)으로 전송될 수 있다. 여기에서 네트워크 인터페이스 카드는 해당 압축된 비디오 스트림과 연관되어 있다. 동시에, 중요 프레임(Pr0)의 압축된 비디오 데이터를 전달하는 RTP 패킷은 ReX-Pr0 버퍼(225)에 저장될 수 있다.
ReX-Pr0 버퍼(225)는 RAM 디바이스일 수 있고, ReX-Pr0 버퍼(225)내의 각 어드레스는 확장된 RTP 헤더와 함께 Pr0 압축된 비디오의 전체 RTP 패킷을 저장할 수 있다. Pr0 RTP 패킷이 저장될 수 있는 어드레스는 패킷의 확장된 RTP 헤더의 HPrOSN 필드의 마지막 소수 비트를 반영할 수 있다. 마지막 소수 비트의 수는 예를 들어, HPrOSN 필드의 마지막 6-10 비트일 수 있다.
전송-RTP 매니저(230)는 TERP(200)의 전체 프로세스를 관리할 수 있다. RTP 접속의 개시 동안, 전송-RTP 매니저(230)는 4개의 시퀀스 카운터(235a-d)를 할당하고 설정할 수 있다. 각 시퀀스 카운터(235a-d)는 무작위 수로 설정될 수 있고, 전송된 RTP 패킷의 특성에 따라 증가될 수 있다. 일부 실시예에서, 하나 이상의 시퀀스 카운터가 특정 수로 설정될 수 있다. LastHPrOSN는 예를 들어, 0으로 설정될 수 있다. 또한, RTP 매니저는 RTP 접속을 제어하기 위한 RTP 접속의 수신기측의 RTP 매니저 모듈과 통신할 수 있다. 접속의 수신측의 매니저 모듈과의 통신은 RTCP 통신 프로토콜을 사용함으로써 이루어질 수 있다.
컨퍼런스 세션 동안, RTP 매니저(230)는 수신기의 RTP 매니저로부터 RTCP 재전송 요청을 수신할 수 있다. 재전송 요청의 예는 재전송-요청 리스트(ReXReqList)를 포함할 수 있다. ReXReqList는 요청된 Pr0 패킷의 리스트를 가질 수 있다. 이러한 리스트는 손실된 중요 패킷의 HPr0SN의 값을 포함할 수 있다(Pr0). ReXReqList에 기초하여, RTP 매니저(230)는 동일한 HPr0SN 값을 갖는 패킷을 찾기 위해 ReX-Pr0 버퍼(225)를 검색할 수 있다. 요청된 Pr0 패킷이 ReX-Pr0 버퍼(225)에 저장되어 있다면, 이러한 패킷은 ReX-Pr0 버퍼(225)로부터 검색될 수 있고 헤더 빌더(215)쪽으로 전송될 수 있다.
헤더 필더(215)에서, SN 및 HPr0SN의 필드는 LastSN(235a) 및 LastHPrOSN(235d) 카운터의 현재값에 따라 갱신될 수 있다. 확장된 RTP 헤더의 OSN 및 OPrOSN 필드의 값은 미변화 상태로 남을 수 있다. 그다음, LastSN(235a) 및 LastHPrOSN(235d) 카운터는 증가될 수 있고 요청된 패킷은 전송 버퍼(220)를 통해 재전송될 수 있다. 하나 이상의 요청된 Pr0 패킷이 ReX-Pr0 버퍼(225)에 존재하지 않는다면, 인트라 요청이 RTP 매니저(230)에 의해 연관된 인코더(도면에 도시되지 않음)에 전송될 수 있다. TERP(200)의 동작에 대한 보다 많은 정보는 도 4와 함께 아래에 설명되어 있다.
도 2b에, 수신-EP-RTP 프로세서(RERP)(250)의 실시예의 관련 엘리먼트가 도시된 블록도가 나타나 있다. 수신 EP는 자체 CP 이미지를 구성하는 MRE 또는 MCU로부터 CP 비디오 이미지를 수신하는 공통 비디오컨퍼런싱 엔드포인트일 수 있다. 다른 엘리먼트중에, MRE의 실시예는 하나 이상의 RERP(250)를 포함할 수 있다. 각 RERP(250)는 예를 들어, 직접 또는 MRM를 통해, 전송 MRE로부터의 수신 압축된 스트림, 및 수신된 스트림을 디코딩하기 위한 디코더(도면에 도시되지 않음)와 연관되어 있을 수 있다. RERP(250)의 실시예는 지터 버퍼(255), 구성된-OSN 버퍼(OOSNB)(260), 중요층 인증기(262), NAL 버퍼(265), RTP 헤더 파서(270) 및 수신-RTP 매니저(275)를 포함할 수 있다.
RERP(250)의 실시예는 관련 스트림과 연관된 네트워크 인터페이스 카드(도면에 도시되지 않음)로부터 압축된 비디오 NAL 데이터를 전달하는 RTP 패킷의 스트리을 취득할 수 있다. 이렇게 취득된 RTP 패킷은 지터 버퍼(255)에 저장될 수 있다. 헤더 파서(270)는 지터 버퍼(255)에 저장된 RTP 패킷의 확장된 RTP 헤더를 파싱할 수 있다. 확장된 필드 PrID 및 HPrOSN의 값에 기초하여 하나 이상의 Pr0 중요 패킷이 마지막 미디어 홉으로부터 경로에서 손실되었는지 여부를 판정할 수 있다. HPrOSN에서의 갭이 검출되면, 하나 이상의 손실=Pr0 패킷의 재전송을 위한 리스트를 갖는 요청이 전송 EP의 전송 RTP 매니저(230)(도 2a)쪽으로 수신-RTP 매니저(275)를 통해 전송될 수 있다.
지터 버퍼(255)로부터의 RTP 패킷은 OSN 확장된 필드의 값에 기초하여 전송되어 OOSNB(260)에 저장될 수 있다. 중요 레벨 인증기(262)의 실시예는 OSN 값에 기초하여 OOSNB(260)으로부터 다음 패킷을 취득할 수 있고, 그다음, 확장된 RTP 헤더의 OPr0SN의 값은 중요 패킷(Pr0)이 손실되었는지 여부를 판정하기 위해 체크될 수 있다. OPr0SN에서의 갭이 검출되면, 인트라 프레임에 대한 요청이 RTCP 접속을 사용하는 수신-RTP 매니저(275)를 통해 전송 EP의 연관된 인코더(도면에 도시되지 않음)쪽으로 전송될 수 있다. 그다음, 취득된 RTP 패킷은 하나 이상의 NAL 유닛으로 분해될 수 있고, NAL 유닛은 NAL 버퍼(265)에 저장될 수 있다. NAL 버퍼(265)내의 순서에 기초하여, NAL 유닛은 도면에 도시되지 않은 연관된 디코더에 의해 취득될 수 있다. 공통 엔드포인트에서, 연관된 디코더는 수신된 압축된 CP 비디오 이미지를 디코딩할 수 있고, 디코딩된 CP 비디오 이미지는 EP 디스플레이 유닛(도면에 도시되지 않음)에 표시될 수 있다. MRE에서, 연관된 디코더로부터의 디코딩된 비디오 이미지는 CP 비디오 이미지의 세그먼트에 놓일 수 있고 MRE 디스플레이 유닛에 CP 비디오 이미지의 일부로서 표현될 수 있는 CP 이미지 빌더(도면에 도시되지 않음)쪽으로 전송될 수 있다.
수신-RTP 매니저(275)는 RERP(250)의 전체 프로세스를 관리할 수 있다. RTP 접속의 시작 동안, 수신-RTP 매니저(275)는 RERP(250)의 리소스를 할당하고 설정할 수 있다. 또한, 수신-RTP 매니저(275)는 RTP 접속을 제어하기 위해 RTCP 커넥션을 통해 RTP 커넥션의 전속측의 전송-RTP 매니저 모듈과 통신할 수 있다. 이러한 전송측은 예를 들어, EP, MRE, MCU 또는 MRM일수 있다.
컨퍼런스 세션 동안, 수신-RTP 매니저(275)는 전송측의 전송-RTP 매니저쪽으로 RTCP 재전송 요청을 전송할 수 있다. 재전송 요청의 예는 재전송-요청 리스트(ReXReqList)를 포함할 수 있다. ReXReqList는 요청된 Pr0 패킷의 리스트를 가질 수 있다. 이러한 리스트는 손실 중요 패킷의 HPr0SN 필드의 값을 포함할 수 있다(Pr0). 또한, 수신-RTP 매니저(275)는 연관된 디코더(도면에 도시되지 않음)쪽으로 압축된 비디오를 전송하기 전에 손실 중요 패킷이 검출되면 인트라 프레임에 대한 요청을 전송할 수 있다. RERP(250)의 동작에 대한 보다 많은 정보는 도 5a 및 도 5b와 관련하여 아래에 설명되어 있다.
MCU는 복수의 EP로부터 복수의 압축된 비디오 스트림을 수신하고, 압축된 스트림을 디코딩하고, 하나 이상의 CP 비디오 이미지를 구성하고, 이러한 하나 이상의 CP 비디오 이미지를 압축하고, 이러한 하나 이상의 CP 비디오 이미지를 복수의 EP쪽으로 전송하는 미디어 홉의 예이다. 이러한 MCU는 개시된 기술의 실시에에 따라 채택될 수 있다. 이러한 MCU의 실시예는 복수의 RERP(250)를 포함할 수 있다. 각 RERP(250)는 EP로부터의 압축된 비디오 스트림과 연관된 디코더와 네트워크 인터페이스 카드 사이에 통신가능하게 위치될 수 있다. 또한, MCU의 실시에는 복수의 TERP(200)를 포함할 수 있다. 각 RERP(200)는 하나 이상의 EP쪽으로 전송되는 압축된 CP 비디오 스트림과 연관된 네트워크 인터페이스 카드와 인코더 사이에 통신가능하게 위치될 수 있다.
도 3a는 멀티미디어-미디어 홉의 실시예에 따른, 중간-미디어-홉-전송-RTP 프로세서(IMHTRP)(300)의 실시예의 관련 엘리먼트를 갖는 블록도이다. 중간-미디어-홉은 복수의 MRE로/로부터 복수의 압축된 비디오 스트림을 릴레이하는 MRM일 수 있다. 다른 엘리먼트중에, MRM의 실시예는 하나 이상의 IMHTRP(300)를 포함할 수 있다. 각 IMHTRP(300)는 MRM과 MRE 사이의 RTP 커넥션과 연관될 수 있다. IMHTRP(300)는 입력 버퍼(3100, RTP 헤더 수정기(320), 미디어-홉(MH) 전송 버퍼(325), MH 재전송-Pr0 버퍼(ReX Pr0 버퍼)(330), 전송-MH-RTP 매니저(340) 및 2개의 MH 시퀀스 카운터(335a, b)를 포함할 수 있다. 관련 RTP가 달성될 때, 각 MH 시퀀스 카운터(335a, b)는 예를 들어, 무작위로 생성된 수로 설정될 수 있다. 일부 실시에에서, 하나 이상의 시퀀스 카운터가 특정 수로 설정될 수 있다. LastHPr0SN은 예를 들어, 0으로 설정될 수 있다.
하나의 MH 시퀀스 카운터(335a)는 공통 RTP 시퀀스 수를 카운트할 수 있고, 이러한 카운터는 LastSN으로 부를 수 있고, 재전송 요청 수신에 응답하거나 처음 IMHTRP(300)로부터 전송된 각 RTP 패킷 마다 증가될 수 있다. LastSN의 값은 전송된 RTP 패킷의 헤더의 SN 필드에 기록될 수 있다. 다른 시퀀스 카운터(235b)는 중요 프레임(Pr0 프레임)의 압축된 데이터를 전달하고 IMHTRP(300)로부터 전송되는 RTP 패킷을 카운트할 수 있다. 이러한 시퀀스 카운터(235b)는 LastHPr0SN으로 부를 수 있고 IMHTRP(300)으로부터 전송되거나 재전송된 Pr0 프레임의 압축된 데이터를 전달하는 각 오리지널 그리고 재전송된 RTP 패킷 마다 증가될 수 있다. LastHPr0SN 카운터의 값은 전송된 RTP 패킷의 확장된 헤더의 HPr0SN 필드에 기록될 수 있다.
IMHTRP(300)의 실시예는 중간-미디어-홉의 내부 엘리먼트(도면에 도시되지 않음)로부터 압축된 RTP 패킷의 스트림을 수신할 수 있고 관련 RTP 커넥션쪽으로 타겟팅될 수 있다. RTP 패킷의 스트림은 상이한 우선순위를 갖는 2개 이상의 층의 압축된 NAL 유닛을 전달할 수 있다. 취득된 RTP 패킷은 각 RTP 패킷이 헤더 수정기(320)에 의해 페칭될 수 있는 입력 버퍼(310)에 저장될 수 있다.
헤더 수정기(320)의 하나의 실시예에서, 패킷의 RTP 헤더는 수정될 수 있다. MH LastSN 카운터(335a)의 값은 예를 들어, 이전의 값 대신에 RTP 헤더내의 SN 필드에 기록될 수 있다. 시퀀스 카운터 MH LastHPr0SN(335b)의 값은 이전의 값 대신에 확장된 RTP 헤더내의 HPr0SN 필드에 기록될 수 있다. HPr0SN 필드의 수정은 패킷이 처음 재전송 패킷에 대해 또는 관련 커넥션쪽으로 전송되는 때에 수행될 수 있다. 확장된 RTP 헤더를 갖는 RTP 패킷은 MH 전송 버퍼(325)를 통해 헤더 수정기(320)로부터 네트워크 인터페이스 카드(도면에 도시되지 않음)쪽으로 전송될 수 있다. 네트워크 인터페이스 카드는 해당 관련 RTP 커넥션과 연관될 수 있다. 동시에, 중요 프레임(Pr0)의 압축된 비디오 데이터를 전달하는 RTP 패킷은 MH ReX-Pr0 버퍼(330)에 저장될 수 있다.
MH ReX-Pr0 버퍼(330)는 MH ReX-Pr0 버퍼(330)의 램 내의 각 주소가 확장된 RTP 헤더와 함게 Pr0 압축된 비디오의 전체 RTP 패킷을 저장할 수 있는 램 디바이스일 수 있다. Pr0 RTP 패킷이 저장될 수 있는 주소는 패킷의 확장된 RTP 헤더의 HPr0SN 필드의 마지막 소수의 비트를 반영할 수 있다. 마지막 소수의 비트의 수는 예를 들어, HPr0SN 필드의 마지막 6-10 비트일 수 있다.
전송-MH-RTP 매니저(340)는 IMHTRP(300)의 전체 프로세스를 관리할 수 있다. RTP 커넥션의 시작 동안, 전송-MH-RTP 매니저(3400는 2개의 MH 시퀀스 카운터(335a, b)를 할당하고 설정할 수 있다. 각 MH 시퀀스 카운터(335a,b)는 무작위 수 또는 0로 설정될 수 있고, 전송된 RTP 패킷의 특성에 따라 증가될 수 있다. 또한, MH RTP 매니저(340)는 RTP 커넥션을 제어하기 위해 RTP 커넥션의 수신기측의 RTP 매니저 모듈과 통신할 수 있다. 이러한 커넥션의 수신측의 매니저 모듈과의 통신은 RTCP 통신 프로토콜을 사용하여 이루어질 수 있다.
컨퍼런스 세션 동안, MH RTP 매니저(340)는 커넥션의 수신기측의 RTP 매니저로부터 RTCP 재전송 요청을 수신할 수 있다. 재전송 요청의 예는 재전송-요청 리스트(ReXReqList)를 포함할 수 있다. ReXReqList는 요청된 Pr0 패킷의 리스트를 가질 수 있다. 이러한 리스트는 손실 중요 패킷(Pr0)의 HPr0SN 필드의 값을 포함할 수 있다. ReXReqList에 기초하여, MH RTP 매니저(340)는 동일한 HPr0SN 값을 갖는 패킷을 찾기 위해 MH ReX-Pr0 버퍼(330)를 검색할 수 있다. 요청된 Pr0 패킷이 MH ReX-Pr0 버퍼(330)에 저장되어 있다면, 일한 패킷은 MH ReX-Pr0 버퍼(330)로부터 검색될 수 있고 헤더 수정기(320)쪽으로 전송될 수 있다.
헤더 수정기(320)에서, SN 및 HPr0SN의 필드는 MH LastSN(335a) 및 MH LastHPrOSN(335b) 카운터의 현재값에 따라 갱신될 수 있다. 확장된 RTP 헤더의 OSN 및 OPrOSN 필드의 값은 불변의 상태로 남아 있다. 그다음, MH LastSN(335a) 및 MH LastHPrOSN(335b) 카운터는 증가될 수 있고 요청된 패킷은 MH 전송 버퍼(325)를 통해 전송될 수 있다. 하나 이상의 요청된 Pr0 패킷이 MH ReX-Pr0 버퍼(330)에 존재하지 않는다면, 인트라 요청이 관련 스트림을 유발한 엔드포인트쪽으로 MH RTP 매니저(340)에 의해 전송될 수 있다. 일부 실시예에서, 하나 이상의 시퀀스 카운터가 RTP 헤더내의 관련 필드를 갱신하기 전에 증가될 수 있다. IMHTRP(300)의 동작에 대한 보다 많은 정보는 도 7과 관련하여 아래에 설명되어 있다.
도 3b에는 중간-미디어-홉-수신-RTP 프로세서(IMHRRP)(350)의 실시예의 관련 엘리먼트의 블록도가 도시되어 있다. 중간-미디어-홉은 복수의 MRE로부터/로 복수의 압축된 비디오 스트림을 릴레이하는 MRM일 수 있다. 다른 엘리먼트중에서, MRM의 실시예는 하나 이상의 IMHRRP(350)를 포함할 수 있다. 각 IMHRRP(350)는 경로를 따라 MRM과 전송 MRE 또는 다른 MRM 사이의 RTP 커넥션과 연관될 수 있다. IMHRRP(350)의 실시예는 버퍼(360), MH-RTP 헤더 파서(370) 및 MH-수신-RTP 매니저(380)를 포함할 수 있다.
IMHRRP(350)의 실시예는 관련 RTP 커넥션과 연관된 네트워크 인터페이스 카드(도면에 도시되지 않음)으로부터 압축된 비디오 NAL 데이터 유닛을 전달하는 RTP 패킷의 스트림을 취득할 수 있다. 이렇게 취득된 RTP 패킷은 버퍼(360)에 저장될 수 있다. 버퍼(360)는 예를 들어, 복수의 취득된 RTP 패킷을 저장하는 사이클릭 메모리일 수 있다.
MH-헤더 파서(370)는 버퍼(360)로부터의 다음 RTP 패킷을 페칭하고, 페칭된 RTP 패킷의 확장된 RTP 헤더를 파싱하고, 이러한 페칭된 RTP 패킷을 중간 미디어 홉의 내부 유닛(도면에 도시되지 않음)쪽으로 전송할 수 있다.
확장된 필드 PrID 및 HPr0SN의 값에 기초하여 MH-헤더 파서(370)의 실시예는 Pr0 패킷, 중요 패킷이 전송 MRE 또는 MRM으로부터 경로의 마지막 세그먼트에서 손실되었는지 여부를 판단할 수 있다.
HPr0SN내의 갭이 검출되면, 수신-MH-RTP 매니저(380)는 하나 이상의 중요 패킷이 손실되었는지 그리고 하나 이상의 손실-Pr0 패킷의 재전송에 대한 리스트를 갖는 요청이 이전의 중간 MH의 전송 MH RTP 매니저(340) 또는 전송 MRE의 전송 RTP 매니저(230)(도 2a)쪽으로 RTCP 커넥션을 통해 수신-MH-RTP 매니저(380)를 통해 전송될 수 있는지 여부를 결정할 수 있다.
수신-MH-RTP 매니저(380)는 IMHRRP(350)의 전체 프로세서를 관리할 수 있다. RTP 커넥션의 시작 동안, 수신-MH-RTP 매니저(380)는 IMHRRP(350)의 리소스를 할당하고 설정할 수 있다. 또한, 수신-MH-RTP 매니저(380)는 RTP 커넥션을 제어하기 위해 RTCP 커넥션을 통해 RTP 커넥션의 전송측의 전송-MH-RTP 매니저(340) 또는 전송-RTP 매니저 모듈(230)(도 2a)과 통신할 수 있다.
컨퍼런스 세션 동안, 수신-MH-RTP 매니저(380)는 (각각) 전송 EP 또는 미디어 홉의 전송-RTP 매니저(230 또는 340)쪽으로 RTCP 재전송 요청을 전송할 수 있다. 재전송 요청의 예는 재전송-요청 리스트(ReXReqlist)를 포함할 수 있다. ReXReqlist는 요청된 Pr0 패킷의 리스트를 가질 수 있다. 이러한 리스트는 손실 중요 패킷(Pr0)의 HPr0SN 필드의 값을 포함할 수 있다. IMHRRP(350)의 동작에 대하 보다 많은 정보는 도 6과 관련하여 아래에 설명되어 있다.
도 4에, 전송-EP-RTP-프로세서(TERP)(200)의 전송 태스크(400)의 관련 블록을 갖는 순서도가 도시되어 있다. TERP(200)는 TERP(200)와 연관된 RTP 커넥션을 통해 전송되는 압축된 SC 스트림의 소스인 MRE 또는 EP와 연관될 수 있다. 방법(400)은 전송 EP/MRE와 다음 미디어 홉 사이의 RTP 커넥션의 달성 동안 시작될 수 있다(402). RTP 커넥션은 진행중인 세션에 참가할 때또는 컨퍼런스 세션의 달성 동안 시작될 수 있다.
시작 후에, TERP(200)의 리소스가 할당되고 설정될 수 있다(404). 예를 들어, 4개의 시퀀스 카운터(235a-d)(도 2a)가 할당될 수 있다. 각 카운터(LastSN, LastOSN, LastOPrOSN, LastHPrOSN)는 예를 들어, 무작위 수 또는 0으로 설정될 수 있다. 또한, ReX-Pr0 버퍼(225)(도 2a)와 같은 버퍼가 할당되고 재설정될 수 있고, LastIDR과 같은 레지스터가 할당되고 재설정될 수 있다.
다음 전송-RTP 매니저(230)(도 2a)가 ReX 요청 리스트내의 엔트리가 그 큐에 존재하는지 여부를 체크할 수 있다(410). 존재하지 않는다면, 방법(400)은 블록(412)로 진행할 수 있다. 410에서 ReX 요청이 존재한다면, 이러한 요청은 검색되고, 엔트리는 클리어되고, 검색된 요청은 파싱되고, 요청된 HPr0SN의 값이 LastIDR 레지스터에 저장된 값보다 적은지 여부를 판단할 수 있다(430). LastIDR 레지스터는 인트라 Pr0 프레임의 처음을 전달하는 제1 패킷의 HPr0SN 필드의 값을 저장한다. 430에서 이러한 값이 보다 적다면, 즉, 인트라 프레임이 손실 패킷에 의해 전달된 압축된 Pr0 비디오 데이터 후에 이미 전송되었다면 손실 패킷을 재전송할 필요가 없고 방법(400)은 블록(410)으로 돌아간다.
430에서, 이러한 값이 보다 작지 않다면, ReX-Pr0 버퍼(225)(도 2a)는 체크될 수 있고(432) Pr0 요청된 패킷이 ReX-Pr0 버퍼(225)에 존재하는지 여부에 판정이 이루어질 수 있다. 요청된 패킷이 ReX-Pr0 버퍼(225)에 존재하지 않는다면, 디코더 리프레쉬 요청(인트라 요청)이 관련 스트림의 인코더쪽으로 전송되고(436) 방법(400)은 블록(410)으로 돌아간다. 432에서, 요청된 리스트에 언급된 Pr0 패킷이 ReX-Pr0 버퍼(225)에 존재한다면, 요청된 Pr0 패킷은 페칭되고 ReX-Pr0 버퍼(225)로부터 제거되고(434) 방법(400)은 페칭된 요청된 패킷을 처리하기 위해 블록(440)으로 진행한다.
이제 블록(410)에서, ReX 요청 리스트에 더 이상의 요청이 존재하지 않는다면, NAL 누산기(210)(도 2a)가 검사되어(412) RTP 패킷의 페이로드에 대해 충분한 바이트가 존재하는지 여부를 판단할 수 있다. 414에서, 충분한 바이트가 존재하지 않는다면, 방법(400)은 관련 인코더로부터 추가 NAL 유닛을 모으기 위해 블록(410)으로 돌아간다. 414에서, RTP 패킷의 페이로드에 대해 충분한 바이트가 존재한다면, 페이로드는 NAL 누산기(210)로부터 NAL 유닛을 페칭함으로써 조합되고 페이로드는 RTP 패킷을 구축하기 위해(416) 페이로드로 확장된 헤더는 물론 RTP 헤더를 조합하기 위해 헤더 빌더(215(도 2a)에 전송된다. PrID는 인코더로부터 수신된 정보에 따라 설정될 수 있다.
OSN 시퀀스 카운터, LastOSN의 값은 증가될 수 있고, LastOSN의 새로운 값이 확장된 RTP 헤더의 OSN 필드에 기록될 수 있다(418). 다음으로, 페이로드의 콘텐트가 Pr0 프레임, 중요 프레임의 압축된 비디오를 포함하는지 여부를 판정한다(420). 포함하고 있지 않다면, LastOPrOSN의 값은 그대로 남고 그 값은 확장된 헤더의 OPrOSN 필드에 복제되고(428) 방법(400)은 블록(442)로 진행한다.
420에서, RTP 패킷의 페이로드가 중요 프레임의 압축된 데이터를 전달하면, LastOPrOSN 카운터의 값은 증가되고(422) 새로운 값은 확장된 RTP 헤더의 OPrOSN 필드에 복제된다. 다음으로, 압축된 비디오 데이터의 파싱된 헤더에 기초하여, RTP 패킷이 인트라 프레임의 처음을 전달하는지 여부를 판정한다(424). 만약 전달하지 않는다면, 방법(400)은 블록(440)으로 진행한다. 만약 전달한다면, 시퀀스 카운터 LastPr0SN 플러스 원의 값이 재전송에 대한 요청을 처리하기 위해 블록(430)에 사용되는 레지스터 LastIDR에 복제되고(426), 방법(400)은 블록(4400으로 진행할 수 있다.
블록(440)에서, 시퀀스 카운터 LastPr0SN이 증가된다. 시퀀스 카운터 LastPr0SN의 값은 확장된 RTP 헤더의 HPr0SN에 복제되고(442) 시퀀스 카운터 LastSN은 증가되고(442) LastSN의 새로운 값은 RTP 헤더의 SN 필드에 복제된다.
확장된 RTP 헤더의 시퀀스 카운터 Pr0ID에 기초하여, 패킷이 중요 프레임의 데이터를 전달하는지 여부를 판정한다(450). 450에서, 전달하지 않는다면, 방법(400)은 블록(454)로 진행하고 새로운 RTP 패킷을 네트워크 인터페이스 카드(도면에 도시되지 않음)를 통해 다음 미디어 홉쪽으로 그리고 관련 RTP 커넥션으로 전송한다. RTP 패킷을 전송한 후에, 방법(400)은 새로운 사이클을 시작하는 블록(410)으로 돌아간다. 450에서, 패킷이 중요 프레임의 데이터를 전달한다면, 방법(4000은 RTP 헤더의 카피를 ReX Pr0 버퍼(225)(도 2a)에 저장하고(452) 새로운 RTP 패킷을 네트워크 인터페이스 카드(도면에 도시되지 않음)를 통해 다음 미디어 홉쪽으로 그리고 관련 RTP 커넥션으로 전송한다(454). 그다음, 방법(400)은 새로운 사이클을 시작하는 블록(410)으로 돌아간다. RTER(200)(도 2a)의 일부 실시예에서, RTP 패킷이 ReX Pr0 버퍼(225)에 저장된 주소는 패킷의 확장된 RTP 헤더의 HPr0SN 필드의 값을 반영할 수 있다.
도 5a는 구성 방법(500)의 예의 관련 블록을 갖는 순서도이다. 구성 방법(500)은 수신-EP-RTP-프로세서(RERP)(250)의 실시예에 의해 구현될 수 있다. RERP(250)는 RERP(250)와 연관된 RTP 커넥션을 통해 전송되는 압축된 SC 스트림의 목적지에서 수신 EP 또는 수신 MRE와 연관될 수 있다. 방법(500)은 수신 EP/MRE와 이전의 미디어 홉 사이의 RTP 커넥션의 달성 동안 시작될 수 있다(502). RTP 커넥션은 컨퍼런스 세션의 달성 동안 또는 진행중인 세션으로의 수신 EP의 참가시에 시작될 수 있다.
시작 후에, RERP(250)의 리소스가 할당되고 설정될 수 있다(504). OOSNB(260)(도 2b), NALs 버퍼(262), 지터 버퍼(255), 레지스터 N, 레스터 last_Pr0 등과 같은 리소스가 할당되고 재설정될 수 있다.
지터 버퍼(255)(도 2b)로부터의 새롭게 수신된 RTP 패킷이 페칭될 수 있다. 패킷의 확장된 RTP 헤더는 파싱되고(506) HPr0SN과 PrID 필드의 값이 검색될 수 있다. 레지스터 Last_Pr0에 기록된 값과 HPr0SN의 검색된 값 사이의 차이가 계산될 수 있고(508) 그 결과는 레지스터 'N'에 저장될 수 있다.
'N'에 차이 값을 저장한 후에, 'N'의 값이 0 보다 적은지 또는 0인지 여부를 판정할 수 있다(510). 차이 값이 0보다 적거나 0이라면, 즉, 마지막 미디어 홉과 수신 EP로부터 경로를 통해 비정상적으로 수신되었다면, 페칭된 PrID의 값이 0인지 여부, 즉, 현 패킷이 중요 프레임의 데이터를 전달하는지 여부를 판정할 수 있다(512). 512에서, 전달한다면, 재전송 요청 리스트(ReXReqList)가 검사될 수 있고(514) HPr0SN의 동일한 값을 갖는 재전송 RTP 패킷에 대한 요청이 재전송 요청 리스트로부터 제거될 수 있다. 그다음, 방법(500)은 블록(530)으로 진행할 수 있다. 512에서, 페칭된 PrID의 값이 0가 아니라면, 즉, 중요 패킷이 아니라면, 방법(500)은 블록(530)으로 진행할 수 있다.
블록(530)에서, ReXReqList에 기초한 재전송 요청이 RTCP 커넥션을 통해 수신 RTP 매니저(275)(도 2b)로부터 RTP 매니저로 RTCP 커넥션의 타측으로 전송될 수 있다. 그다음, 수신된 RTP 패킷은 방법(500)(도 5b)에 의해 처리되기 위해 OOSNB(260)(도 2b)로 전송될 수 있고(532) 방법(500)은 블록(506)으로 돌아간다.
일부 실시예에서, 이러한 리스트는 인트라 프레임이 수신될 때마다 또는 리스트내의 각 엔트리의 경과시간에 기초하여 클리어될 수 있다. 그러나, 일부 실시예에서, 동일한 OSN을 갖고 있는 복사된 패킷은 OOSNB(260)(도 2b)로부터 제거될 수 있다.
이제 블록(510)으로 돌아가서, 'N'의 값이 0보다 크다면, 페칭된 PrID의 값이 0인지 여부, 즉, 현 패킷이 중요 프레임의 데이터를 전달하는지 여부를 판정할 수 있다(516). 516에서, PrID가 0이 아니라면, 즉, 하나 이상이 중요 패킷이 이전의 미디어 홉으로부터 마지막 세그먼트를 따라 손실되지 않았다면, ReXReqList는 갱신될 수 있다(518). 이러한 갱신은 확장된 RTP 헤더의 HPr0SN 필드의 값이 Last_Pr0 레지스터에 저장된 값 플러스 1, 플러스 2, 플러스 3.... 플러스 레지스터 'N'에 저장된 값과 동일한 요청된 패킷의 리스트를 기록함으로써 이루어질 수 있다. ReXReqList를 갱신한 후에, 현 수신된 RTP 패킷의 확장된 RTP 헤더의 HPr0SN 필드의 값은 레지스터 Last_Pr0의 이전의 값 대신에 저장되고(524) 방법(500)은 블록(530)으로 진행한다.
516에서, 페칭된 PrID의 값이 0라면, 즉, 현 패킷이 중요 프레임의 데이터를 전달한다면, 'N'의 값이 1인지 여부를 판정할 수 있다(520). 520에서 만약 1이라면, 즉, 아무런 중요 패킷이 손실되지 않았다면, 프로세스(500)는 블록(5240로 진행할 수 있다. 520에서, 1이 아니라면, 즉, 하나 이상의 중요 패킷이 이번 1까지 손실되었다면, ReXReqList는 갱신될 수 있다(522). 이러한 갱신은 확장된 RTP 헤더의 HPr0SN 필드의 값이 Last_Pr0 레지스터에 저장된 값 플러스 1, 플러스 2, 플러스 3....플러스 레지스터 'N'에 저장된 값 마이너스 1과 동일한 요청된 패킷의 리스트를 기록함으로써 이루어질 수 있다. ReXReqList를 갱신한 후에, 현 수신된 RTP 패킷의 확장된 RTP 헤더의 HPr0SN 필드의 값은 레지스터 Last_Pr0의 이전의 값 대신에 저장되고(524) 방법(500)은 블록(530)으로 진행한다.
도 5b는 Pr0 인증 방법(5000)의 실시예의 관련 블록을 갖는 순서도이다. Pr0 인증 방법(5000)은 수신-EP-RTP-프로세서(RERP)(250)의 실시예에 의해 구현될 수 있다. RERP(5250)는 RERP(250)와 연관된 RTP 커넥션을 통해 전송되는 압축된 SC 스트림의 목적지에서 수신 EP 또는 수신 MRE와 연관될 수 있다. 방법(5000)은 수신 EP/MRE와 이전의 미디어 홉 사이의 RTP 커넥션의 달성 동안 시작될 수 있다(550). RTP 커넥션은 컨퍼런스 세션의 달성 동안 또는 진행중인 세션에 수신 EP가 참가할 때에 시작될 수 있다.
시작 후에, 방법(5000)과 관련된 RERP(250)의 리소스가 할당되고 설정될 수 있다(552). 중요 레벨 인증기(262)(도 2b), OOSNB(260)(도 2b), NALs 버퍼(262), 레지스터 M, 레스터 Last_OPr0 등과 같은 레지스터 및 버퍼와 같은 리소스가 할당되고 재설정될 수 있다.
OOSNB(260)(도 2b)로부터의 다음 수신된 RTP 패킷이 페칭될 수 있다. 패킷의 확장된 RTP 헤더는 파싱되고(554) OPr0SN과 PrID 필드의 값이 검색될 수 있다. OPr0SN과 PrID 필드의 값이 검색될 수 있다. OPr0SN의 검색된 값과 레지스터 Last_Pr0에 기록된 값 사이의 차이가 계산될 수 있고(556) 그 결과는 레지스터 'M'에 저장될 수 있다.
레지스터 'M'에 차이 값을 저장한 후에, 페칭된 PrID의 값이 0인지, 즉, 현 패킷이 중요 프레임의 데이터를 전달하는지 여부를 판정할 수 있다(560). 560에서 0이라면, 'M'의 값이 1인지 여부를 판정할 수 있다(564). 564에서, 1이라면, 즉, 수신된 압축된 비디오 스트림의 오리지널 소스로부터 압축된 비디오 스트림의 수신 목적지까지 아무런 손실된 중요 패킷이 존재하지 않는다면, 현 수신된 RTP 패킷의 확장된 RTP 헤더의 OPr0SN의 값은 레지스터 Last_OPr0의 이전의 값 대신에 기록될 수 있고(570) 방법(5000)은 블록(572)로 진행한다. 블록(572)에서, 수신된 RTP 패킷은 NALs 버퍼(265)(도 2b)로 전송될 수 있고, 이러한 버퍼로부터 수신 EP의 디코더쪽으로 전송될 수 있다. 디코더는 관련 RTP 커넥션을 통해 전달된 압축된 비디오 스트림을 처리할 수 있다. 그다음, 방법(5000)은 OOSNB(260)내의 그다음 RTP 패킷을 처리하기 위해 블록(554)으로 돌아간다.
560에서, 페칭된 PrID의 값이 0가 아니라면, 즉, 현 패킷이 중요 패킷이 아니라면, 'M'의 값이 0인지 여부를 판정할 수 있다(562). 562에서, 0이라면, 즉, 수신된 압축된 비디오 스트림의 오리지널 소스로부터 압축된 비디오 스트림의 수신 목적지까지 아무런 손실 중요 패킷이 존재하지 않는다면, 현 수신된 RTP 패킷의 확장된 RTP 헤더의 OPr0SN 필드의 값은 레지스터 Last_Opr0의 이전의 압ㅅ 대신에 기록되고(570) 방법(5000)은 블록(572)으로 진행한다. 블록(572)에서, 수신된 RTP 패킷이 NALs 버퍼(265)(도 2b)로 전송될 수 있고, 이러한 버퍼로부터 수신 EP의 디코더쪽으로 전송될 수 있다. 디코더는 관련 RTP 커넥션을 통해 전달된 압축된 비디오 스트림을 처리할 수 있다. 그다음, 방법(5000)은 OOSNB(260)내의 그다음 RTP 패킷을 처리하기 위해 블록(554)으로 돌아간다.
이제 블록(564) 또는 블록(562)에서, 레지스터 'M'의 값이 각각, 1 또는 0이 아니라면, 즉, 하나 이상의 중요 패킷이 손실되었다면, 인트라 프레임에 대한 요청이 수신 RTP 매니저(275)(도 2b)에 의해 전송될 수 있다(568). 인트라 요청은 RTPC 커넥션을 통해 관련 압축된 비디오 스트림의 소스의, 전송 RTP 매니저쪽으로 전송될 수 있다. 인트라 요청은 하나 이상의 중간 미디어 홉을 통해 전송될 수 있다. 그다음, 방법(5000)은 블록(570)으로 진행할 수 있다.
방법(5000)의 일부 실시에에서, RTP 패킷을 디코더로 전송한 후에, 전송된 프레임내의 지터를 극복하기 위해 일정 기간 대기할 수 있다. 대기 시간은 예를 들어, 5 내지 20 밀리초 사이의 수 밀리초의 범위가 될 수 있다.
도 6은 중간-미디어-홉-수신 방법(600)의 예의 관련 블록을 가진 순서도이다. 방법(600)은 IMHRRP(350)(도 3b)의 실시예에 의해 구현될 수 있다. IMHRRP(350)는 압축된 비디오 스트림의 소스와 해당 압축된 SC 비디오 스트림의 수신 목적지 사이에 위치된 중간-미디어-홉과 연관될 수 있다. 중간-미디어-홉은 예를 들어, 2개 이상의 MRE 사이에 위치된 MRM일 수 있다. 방법(600)은 이전의 미디어 홉 또는 비디오 SC 스트림의 소스인 EP/MRE와 미디어 홉 사이의 RTP 커넥션의 달성 동안 시작될 수 있다(602). RTP 커넥션은 예를 들어, 컨퍼런스 세션의 달성 동안 또는 진행중인 세션에 전송 EP/MRE가 참여할 때에 시작될 수 있다.
시작 후에, IMHRRP(350)의 리소스가 할당되고 설정될 수 있다(604). 버퍼(360)(도 3b), 레지스터 N, 레스터 Last_Pr0' 등과 같은 리소스가 할당되고 재설정될 수 있다. 버퍼(360)(도 3b)로부터의 다음 수신된 RTP 패킷이 페칭될 수 있다. 패킷의 확장된 RTP 헤더는 파싱되고(606) HPr0SN과 PrID 필드의 값이 검색될 수 있다. HPr0SN의 검색된 값과 레지스터 Last_Pr0'에 기록된 값 사이의 차이가 계산될 수 있고(608) 그 결과는 레지스터 'N'에 저장될 수 있다.
레지스터 'N'에 차이 값을 저장한 후에, 'N'의 값이 0보다 작거나 0인지 여부를 판정할 수 있다(610). 차이 값이 0보다 작거나 0이라면, 즉, 마지막 미디어 홉과 수신 EP로부터 경로를 통해 비정상적으로 수신되었다면, 페칭된 PrID의 값이 0인지 여부, 즉, 현 패킷이 중요 프레임의 데이터를 전달하는지 여부를 판정할 수 있다(612). 612에서, 전달한다면, 재전송 요청 리스트(ReXReqList)가 검사될 수 있고(614) HPr0SN의 동일한 값을 갖는 재전송 RTP 패킷에 대한 요청이 재전송 요청 리스트로부터 제거될 수 있다. 그다음, 방법(500)은 블록(530)으로 진행할 수 있다. 612에서, 페칭된 PrID의 값이 0이 아니라면, 즉, 중요 패킷이 아니라면, 방법(600)은 블록(630)으로 진행할 수 있다.
블록(630)에서, ReXReqList에 기초한 재전송 요청이 RTCP 커넥션을 통해 수신-MH-RTP 매니저(380)(도 3b)로부터 RTP 매니저로 RTCP 커넥션의 타측에서 전송될 수 있다. 그다음, 수신된 RTP 패킷은 미디어 홉의 하나 이상의 다른 내부 유닛(도면에 도시되지 않음)으로 전송될 수 있고(632) 방법(600)은 버퍼(360)내의 다른 RTO 패킷을 처리하기 위해 블록(606)으로 돌아간다. 일부 실시예에서, ReXReqList는 인트라 프레임이 수신될 때마다, 또는 이러한 리스트내의 각 엔트리의 경과시간에 기초하여 클리어될 수 있다. 그러나, 일부 실시예에서, 블록(630)에서, 동일한 OSN을 갖고 있는 복사된 패킷은 OOSNB(260)(도 2b)로부터 제거될 수 있다.
이제 블록(610)으로 돌아가서, 'N'의 값이 0보다 크다면, 페칭된 PrID의 값이 0인지 여부, 즉, 현 패킷이 중요 프레임의 데이터를 전달하는지 여부를 판정할 수 있다(616). 616에서, 전달하지 않는다면, 즉, 하나 이상의 중요 패킷이 이전의 미디어 홉 또는 EP/MRE로부터 마지막 세그먼트를 따라 손실된 것이라면, ReXReqList가 갱신될 수 있다(618). 이러한 갱신은 확장된 RTP 헤더의 HPr0SN 필드의 값이 Last_Pr0 레지스터에 저장된 값 플러스 1, 플러스 2, 플러스 3.... 플러스 레지스터 'N'에 저장된 값과 동일한 요청된 패킷의 리스트를 기록함으로써 이루어질 수 있다. ReXReqList를 갱신한 후에, 현 수신된 RTP 패킷의 확장된 RTP 헤더의 HPr0SN 필드의 값은 레지스터 Last_Pr0'의 이전의 값 대신에 저장되고(624) 방법(600)은 블록(630)으로 진행할 수 있다.
616에서, 페칭된 PrID의 값이 0이라면, 즉, 현 패킷이 중요 프레임의 데이터를 전달한다면, 'N'의 값이 1인지 여부를 판정할 수 있다(620). 620에서 만약 1이라면, 즉, 아무런 중요 패킷이 손실되지 않았다면, 프로세스(600)는 블록(624)로 진행할 수 있다. 620에서, 1이 아니라면, 즉, 일부 중요 패킷이 이러한 1까지 손실되었다면, ReXReqList는 갱신될 수 있다(622). 이러한 갱신은 확장된 RTP 헤더의 HPr0SN 필드의 값이 Last_Pr0' 레지스터에 저장된 값 플러스 1, 플러스 2, 플러스 3....플러스 레지스터 'N'에 저장된 값 마이너스 1과 동일한 요청된 패킷의 리스트를 기록함으로써 이루어질 수 있다. ReXReqList를 갱신한 후에, 현 수신된 RTP 패킷의 확장된 RTP 헤더의 HPr0SN 필드의 값은 레지스터 Last_Pr0의 이전의 값 대신에 저장되고(624) 방법(600)은 블록(630)으로 진행할 수 있다.
도 7에, 중간-미디어-홉-전송 방법(700)의 예의 관련 블록을 갖는 순서도가 도시되어 있다. 방법(700)은 IMHTRP(300)(도 3a)의 실시예에 의해 구현될 수 있다. IMHTRP(300)는 압축된 비디오 스트림의 소스와 해당 압축된 SC 비디오 스트림의 수신 목적지 사이에 위치된 중간-미디어-홉과 연관될 수 있다. 중간-미디어-홉은 예를 들어, 2개 이상의 MRE 사이에 위치된 MRM일 수 있다. 방법(700)은 다음의 미디어 홉 또는 비디오 SC 스트림의 목적지인 EP/MRE와 미디어 홉 사이의 RTP 커넥션의 달성 동안 시작될 수 있다(702). RTP 커넥션은 예를 들어, 컨퍼런스 세션의 달성 동안 또는 진행중인 세션에 수신 EP/MRE가 참여할 때에 시작될 수 있다.
시작 후에, IMHTRP(300)의 리소스가 할당되고 설정될 수 있다(704). 예를 들어, 2개의 시퀀스 카운터(335a-d)(도 3a)가 할당될 수 있다. 각 카운터(LastSN, LastPrOSN)는 무작위 수 또는 0으로 설정될 수 있다. 또한, ReX-Pr0 버퍼(330)(도 3a)와 같은 버퍼가 할당되고 재설정될 수 있고(704), LastIDR과 같은 레지스터가 할당되고 재설정될 수 있다.
다음 MH-전송-RTP 매니저(340)(도 3a)가 ReX 요청 엔트리가 그 큐에 있는지 여부를 체크할 수 있다(710). 존재하지 않는다면, 방법(700)은 블록(712)로 진행할 수 있다. 710에서 ReX 요청 엔트리가 발견되면, 이러한 요청은 검색되고, 엔트리는 클리어되고, 검색된 요청은 파싱되고, 요청된 HPr0SN의 값이 LastIDR 레지스터에 저장된 값보다 적은지 여부를 판단할 수 있다(730). LastIDR 레지스터는 인트라 Pr0 프레임의 처음을 전달하는 제1 패킷의 HPr0SN 필드의 값을 저장한다. 720에서 이러한 값이 보다 적다면, 즉, 인트라 프레임이 이미 발행되었고, 손실 패킷에 의해 전달된 압축된 Pr0 비디오 데이터를 생성한 후에, 수신될 수 있다면, 손실 패킷을 재전송할 필요가 없고 방법(700)은 블록(710)으로 돌아갈 수 있다.
720에서, 이러한 값이 보다 작지 않다면, MH-ReX-Pr0 버퍼(330)(도 3a)는 체크될 수 있고(722) 리스트의 엔트리에서 언급되는 Pr0 패킷이 MH-ReX-Pr0 버퍼(330)에 존재하는지 여부에 대해 판정이 이루어질 수 있다. 요청된 패킷이 MH-ReX-Pr0 버퍼(330)에 존재하지 않는다면, 디코더 리프레쉬 요청(인트라 요청)이 RTP 커넥션으로 압축 SC 비디오 스트림의 소스쪽으로 전송되고(726) 방법(700)은 블록(710)으로 돌아간다. 722에서, 요청 리스트의 엔트리에서 언급되는 Pr0 패킷이 MH-ReX-Pr0 버퍼(330)에 존재한다면, 요청된 Pr0 패킷은 페칭되고 ReX-Pr0 버퍼(330)로부터 제거되고(724) 방법(700)은 페칭된 요청된 패킷을 처리하기 위해 블록(730)으로 진행할 수 있다.
이제 블록(710)에서, 큐에 아무런 계류중인 ReX 요청이 존재하지 않는다면, 입력 버퍼(310)(도 3a)가 검사될 수 있고(712) IMHTRP(300)의 내부 모듈(도면에 도시되지 않음)로부터의 다음 RTP 패킷이 페칭될 수 있다. RTP 헤더 및 페칭된 패킷의 확장된 헤더가 파싱될 수 있고 HPr0SN 필드 및 PrID 필드의 값이 검색될 수 있다(712). 다음으로, 페이로드의 콘텐트가 Pr0 프레임, 중요 프레임의 압축된 비디오를 포함하는지 여부를 판정할 수 있다(714). 714에서, 포함하고 있지 않다면, 방법(700)은 블록(732)로 진행할 수 있다.
714에서, 패킷이 중요 프레임의 데이터를 전달하면, RTP 패킷의 헤더는 RTP 패킷이 새로운 중요 인트라 프레임의 처음을 전달하는지 여부를 판정하기 위해(716) 체크될 수 있다. 716에서, 패킷이 새로운 중요 인트라 프레임의 처음을 전달하지 않는다면, 방법(700)은 블록(730)으로 진행한다. 716에서, 패킷이 새로운 중요 인트라 프레임의 처음을 전달한다면, LastPr0SN의 값 플러스 1의 합이 레지스터 LastIDR의 이전의 데이터 대신에 LastIDR에 기록될 수 있다(718).
블록(730)에서, 시퀀스 카운터 LastPr0SN이 증가될 수 있다. 시퀀스 카운터 LastPr0SN의 값은 확장된 RTP 헤더의 HPr0SN 필드에 기록될 수 있다(732). 또한, LastSN 시퀀스 카운터는 증가될 수 있고 새로운 값이 공통 RTP 헤더의 SN 필드에 기록될 수 있다.
다음으로, 확장된 RTP 헤더의 Pr0ID에 기초하여, 패킷의 페이로드가 중요 프레임의 압추된 비디오를 전달하는지 여부를 판정할 수 있다(740). 만약 전달하지 않는다면, RTP 패킷은 관련 RTP 커넥션을 통해 그리고 네트워크 인터페이스 카드(도면에 도시되지 않음)를 통해 다음 미디어-홉 또는 수신 EP/MRE 쪽으로 전송된다(744). 740에서, 패킷이 중요 프레임의 압축된 비디오를 전달한다면, RTP 패킷의 카피는 MH-ReX Pr0 버퍼(330)(도 3a)에 저장될 수 있고 패킷은 관련 RTP 커넥션을 통해 그리고 네트워크 인터페이스 카드(도면에 도시되지 않음)를 통해 다음 미디어-홉 또는 수신 EP/MRE 쪽으로 전송될 수 있다(744). RTP 패킷을 그 목적지로 전송한 후에, 방법(700)은 새로운 사이클을 시작하는 블록(710)으로 돌아갈 수 있다.
본 발명에서, "포함하다", "갖다" 및 그 파생어들은 그 동사의 목적어가 반드시 부재, 컴포넌트, 엘리먼트 또는 일부의 온전한 리스트가 아니라는 것을 나타내기 위해 사용되었다.
상술된 바와 같이, 본 발명은 미디어 전송 디바바이스에서 복수의 트랜스포트 프로토콜(TP) 패킷의 스트림을 취득하는 단계; 복수의 TP 패킷의 각각에 대한 복수의 헤더 필드의 제1 헤더 필드에 제1 시퀀스 넘버를 할당하는 단계; 및 복수의 TP 패킷을 하나 이상의 미디어 수신 디바이스에 전송하는 단계를 포함하는 방법을 포함할 수 있다. 여기에서, 상기 복수의 TP 패킷의 스트림은 스케일러블 코딩(SC) 인코더에 의해 생성된 압축된 미디어 데이터-유닛을 전달한다. 복수의 TP 패킷의 각각은 할당된 우선순위 레벨을 갖고 복수의 TP 패킷의 스트림은 제1 우선순위 레벨의 적어도 하나의 패킷 및 제2 우선순위 레벨의 적어도 하나의 패킷을 포함하고 있다. 제1 시퀀스 넘버는 제1 우선순위 레벨의 각 TP 패킷에 대해 변경된다.
또한, SC 인코더는 발신하는 미디어 전송 디바이스에 포함될 수 있다. 또한, 제2 시퀀스 넘버가 제1 우선순위 레벨의 패킷의 오리지널 시퀀스 넘버를 나타내는 제2 시퀀스 넘버로 발신하는 미디어 전송 디바이스에서 제2 헤더 필드에 할당될 수도 있다. 제2 시퀀스 넘버는 임의의 이전의 네트워크 세그먼트로부터 하나 이상의 손실 제1 우선순위 레벨 패킷을 식별하기 위해 최종 미디어 수신 디바이스에서 사용될 수도 있다. 발신하는 미디어 전송 디바이스는 또한 제3 시퀀스 넘버를 제3 헤더 필드에 할당할 수도 있는데, 제3 시퀀스 넘버는 모든 TP 패킷의 오리지널 시퀀스 넘버를 나타내고, 제3 시퀀스 넘버 필드는 우선순위에 관계없이 TP 패킷을 기록하기 위해 사용될 수도 있다.
발신하는 미디어 전송 디바이스는 MRE 또는 멀티포인트-컨트롤 유닛(MCU)에 의해 생성된 미디어를 압축하는 SC 인코더를 갖는 엔드포인트 또는 미디어 릴레이 엔드포인트(MRE)를 포함할 수도 있고 SC 인코더는 복수의 엔드포인트로부터 수신된 비디오 이미지로부터 상주(CP) 비디오 이미지를 인코딩한다. 제1 시퀀스 넘버는 하나 이상의 미디어 수신 디바이스로부터 선택된, 제1 미디어 수신 디바이스에 의해 사용될 수 있어서, 하나 이상의 손실 TP 패킷을 식별하고 제1 미디어 수신 디바이스와 연관된 네트워크 세그먼트를 통해 재전송을 요청한다.
또한, 본 방법 및 시스템은 소스-재전송 버퍼에 하나 이상의 전송된 TP 패킷을 저장하고; 수신 디바이스로부터 특정 TP 패킷의 재전송을 위한 요청을 수신하고; 특정 TP 패킷에 대한 소스-재전송 버퍼를 검색하고; 이러한 요청에 응답하여 특정 TP 패킷을 수신 디바이스쪽으로 재전송하도록 구성될 수도 있다. 옵션으로, 제1 우선순위 레벨을 갖는 TP 패킷만이 소스-재전송 버퍼에 저장되고 재전송에 대한 요청이 상주(CP) 비디오 이미지를 표시하기 위해 TP 패킷을 수신하는 엔드포인트로부터 수신될 수도 있다. 일부 경우에, 특정 TP 패킷이 소스-재전송 버퍼에서 발견되지 않았다면 인트라 프레임을 발신하는 미디어 전송 디바이스로부터 요청하는 것이 유익할 수도 있다. 물론, 상술된 방법중 일부는 중간 미디어 홉을 포함하는 미디어 전송 디바이스에 구현될 수도 있다.
상기 설명은 설명을 위한 것이고 제한을 위한 것이 아님을 이해해야 한다. 상술된 장치, 시스템 및 방법은 단계의 순서의 변경을 포함하는 많은 방법으로 수정될 수 있다. 상술된 실시예는 상이한 특징을 포함하고, 이들 모두가 본 발명의 모든 실시예에서 요구되는 것은 아니다. 또한, 본 발명의 실시예는 일부 특징 또는 가능한 조합의 특징만을 사용하고 있다. 상술된 실시예에 설명된 특징의 상이한 조합은 당업자에게 명백할 것이다. 또한, 본 발명의 실시예는 상이한 실시예와 관련되어 설명된 특징 및 엘리먼트의 조합에 의해 구현될 수 있다. 본 발명의 범위는 다음의 청구범위 및 그 동등물에 의해서만 제한된다.

Claims (32)

  1. 미디어 전송 디바이스에서 복수의 트랜스포트 프로토콜(TP) 패킷의 스트림을 취득하는 단계로서, 상기 복수의 TP 패킷의 스트림은 스케일러블 코딩(SC) 인코더에 의해 생성된 압축된 미디어 데이터 유닛을 전달하고, 상기 복수의 TP 패킷의 각각은 할당된 우선순위 레벨을 갖고 있고, 상기 복수의 TP 패킷의 스트림은 제1 우선순위 레벨의 적어도 하나의 패킷 및 제2 우선순위 레벨의 적어도 하나의 패킷을 포함하는 단계;
    상기 복수의 TP 패킷의 각각에 대해 복수의 헤더 필드중 제1 헤더 필드에 제1 시퀀스 넘버를 할당하는 단계로서, 상기 제1 시퀀스 넘버는 상기 제1 우선순위 레벨의 각 TP 패킷에 대해 변경되는 단계; 및
    상기 복수의 TP 패킷을 하나 이상의 미디어 수신 디바이스에 전송하는 단계를 포함하는 것을 특징으로 하는 방법.
  2. 제1항에 있어서, 상기 SC 인코더는 발신하는 미디어 전송 디바이스에 포함되어 있는 것을 특징으로 하는 방법.
  3. 제2항에 있어서, 상기 발신하는 미디어 전송 디바이스에서 제2 시퀀스 넘버를 제2 헤더 필드에 할당하는 단계를 더 포함하고, 상기 제2 시퀀스 넘버는 상기 제1 우선순위 레벨의 패킷의 오리지널 시퀀스 넘버를 나타내는 것을 특징으로 하는 방법.
  4. 제3항에 있어서, 상기 제2 시퀀스 넘버는 임의의 이전의 네트워크 세그먼트로부터 하나 이상의 손실 제1 우선순위 레벨 패킷을 식별하기 위해 최종 미디어 수신 디바이스에서 사용되는 것을 특징으로 하는 방법.
  5. 제2항에 있어서, 상기 발신하는 미디어 전송 디바이스에서 제3 시퀀스 넘버를 제3 헤더 필드에 할당하는 단계를 더 포함하고, 상기 제3 시퀀스 넘버는 모든 TP 패킷의 오리지널 시퀀스 넘버를 나타내는 것을 특징으로 하는 방법.
  6. 제5항에 있어서, 상기 제3 시퀀스 넘버 필드는 우선순위에 상관없이 TP 패킷을 기록하기 위해 사용되는 것을 특징으로 하는 방법.
  7. 제2항에 있어서, 상기 발신하는 미디어 전송 디바이스는 미디어 릴레이 엔드포인트(MRE)에 의해 생성된 미디어를 압축하는 SC 인코더를 갖는 엔드포인트 또는 MRE를 포함하는 것을 특징으로 하는 방법.
  8. 제2항에 있어서, 상기 발신하는 미디어 전송 디바이스는 멀티포인트 컨트롤 유닛(MCU)을 포함하고, 상기 SC 인코더는 복수의 엔드포인트로부터 수신된 비디오 이미지로부터 상주(CP) 비디오 이미지를 인코딩하는 것을 특징으로 하는 방법.
  9. 제1항에 있어서, 제1 우선순위 레벨은 높은 우선순위 레벨을 포함하는 것을 특징으로 하는 방법.
  10. 제1항에 있어서, 상기 미디어 전송 디바이스 및 상기 하나 이상의 미디어 수신 디바이스는 멀티포인트 컨퍼런싱 디바이스를 포함하는 것을 특징으로 하는 방법.
  11. 제1항에 있어서, 상기 제1 시퀀스 넘버는 상기 하나 이상의 미디어 수신 디바이스로부터 선택된 제1 미디어 수신 디바이스에 의해 사용되어, 하나 이상의 손실 TP 패킷을 식별하고 상기 제1 미디어 수신 디바이스와 연관된 네트워크 세그먼트를 통해 재전송을 요청하는 것을 특징으로 하는 방법.
  12. 제1항에 있어서,
    하나 이상의 전송된 TP 패킷을 소스-재전송 버퍼에 저장하는 단계;
    수신 디바이스로부터 특정 TP 패킷의 재전송을 위한 요청을 수신하는 단계;
    상기 특정 TP 패킷에 대한 소스-재전송 버퍼를 검색하는 단계; 및
    상기 요청에 응답하여 상기 특정 TP 패킷을 상기 수신 디바이스에 재전송하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  13. 제12항에 있어서, 상기 소스-재전송 버퍼에 제1 우선순위 레벨을 갖는 TP 패킷만이 저장되는 것을 특징으로 하는 방법.
  14. 제12항에 있어서, 상기 재전송에 대한 요청은 상주(CP) 비디오 이미지를 표시하기 위해 TP 패킷을 수신하는 엔드포인트로부터 수신되는 것을 특징으로 하는 방법.
  15. 제12항에 있어서, 상기 특정 TP 패킷이 상기 소스-재전송 버퍼에서 발견되지 않았다면 상기 발신하는 미디어 전송 디바이스로부터 인트라 프레임을 요청하는 단계를 더 포함하는 것을 특징으로 하는 방법.
  16. 제1항에 있어서, 상기 SC 인코더는 비디오 규격에 따라 인코딩하는 것을 특징으로 하는 방법.
  17. 제16항에 있어서, 상기 규격은 H.264 Annex G (SVC)를 포함하는 것을 특징으로 하는 방법.
  18. 제1항에 있어서, 상기 SC 인코더는 시간적 확장성을 포함하는 스케일러블 코딩 인코딩을 실행하고, 각 제1 우선순위 레벨 TP 패킷은 베이스층의 프레임의 압축된 비디오 데이터를 반영하는 것을 특징으로 하는 방법.
  19. 제1항에 있어서, 상기 트랜스포트 프로토콜(TP)은 실시간 트랜스포트 프로토콜(RTP)을 포함하는 것을 특징으로 하는 방법.
  20. 제1항에 있어서, 상기 제1 시퀀스 넘버는 전송되거나 재전송되는 각 전송된 제1 우선순위 레벨 TP 패킷에 대해 증가되는 것을 특징으로 하는 방법.
  21. 제1항에 있어서, 상기 미디어 전송 디바이스는 중간 미디어 홉을 포함하는 것을 특징으로 하는 방법.
  22. 미디어 전송 디바이스로서,
    네트워크 인터페이스;
    메모리; 및
    상기 네트워크 인터페이스와 상기 메모리에 통신가능하도록 결합된 프로세서를 포함하고, 상기 프로세서는,
    상기 네트워크 인터페이스를 통해, 미디어 전송 디바이스에서 복수의 트랜스포트 프로토콜(TP) 패킷의 제1 스트림을 취득하고,
    상기 복수의 TP 패킷의 각각에 대해 복수의 헤더 필드중 제1 헤더 필드에 제1 시퀀스 넘버를 할당하고,
    상기 복수의 TP 패킷을 하나 이상의 미디어 수신 디바이스에 전송하도록 구성되어 있고,
    상기 복수의 TP 패킷의 제1 스트림은 스케일러블 코딩(SC) 인코더에 의해 생성된 압축된 미디어 데이터 유닛을 전달하고, 상기 복수의 TP 패킷의 각각은 할당된 우선순위 레벨을 갖고 있고, 상기 복수의 TP 패킷의 제1 스트림은 제1 우선순위 레벨의 적어도 하나의 패킷 및 제2 우선순위 레벨의 적어도 하나의 패킷을 포함하고,
    상기 제1 시퀀스 넘버는 상기 제1 우선순위 레벨의 각 TP 패킷에 대해 변경되는 것을 특징으로 하는 미디어 전송 디바이스.
  23. 제22항에 있어서, SC 인코더를 더 포함하는 것을 특징으로 하는 미디어 전송 디바이스.
  24. 제22항에 있어서, 상기 SC 인코더는 시간적 확장성을 포함하는 스케일러블 코딩 인코딩을 실행하고, 각 제1 우선순위 레벨 TP 패킷은 베이스층의 프레임의 압축된 비디오 데이터를 반영하는 것을 특징으로 하는 미디어 전송 디바이스.
  25. 제22항에 있어서, 상기 제1 우선순위 레벨은 높은 우선순위 레벨을 포함하는 것을 특징으로 하는 미디어 전송 디바이스.
  26. 제22항에 있어서, 상기 미디어 전송 디바이스 및 상기 하나 이상의 미디어 수신 디바이스는 멀티포인트 컨퍼런싱 디바이스를 포함하는 것을 특징으로 하는 미디어 전송 디바이스.
  27. 제22항에 있어서, 상기 프로세서는 또한, 제2 시퀀스 넘버를 제2 헤더 필드에 할당하도록 구성되어 있고, 상기 제2 시퀀스 넘버는 상기 제1 우선순위 레벨의 패킷의 오리지널 시퀀스 넘버를 나타내는 것을 특징으로 하는 미디어 전송 디바이스.
  28. 제22항에 있어서, 상기 프로세서는 또한, 제3 시퀀스 넘버를 제3 헤더 필드에 할당하도록 구성되어 있고, 상기 제3 시퀀스 넘버는 모든 TP 패킷의 오리지널 시퀀스 넘버를 나타내는 것을 특징으로 하는 미디어 전송 디바이스.
  29. 제22항에 있어서, 상기 제1 시퀀스 넘버 필드는 전송되거나 재전송되는 각 전송된 제1 우선순위 레벨 TP 패킷에 대해 증가되는 것을 특징으로 하는 미디어 전송 디바이스.
  30. 영구 컴퓨터 판독가능 매체로서,
    미디어 전송 디바이스의 프로세서가,
    상기 미디어 전송 디바이스에서 복수의 트랜스포트 프로토콜(TP) 패킷의 제1 스트림을 취득하고,
    상기 복수의 TP 패킷의 각각에 대해 복수의 헤더 필드중 제1 헤더 필드에 제1 시퀀스 넘버를 할당하고,
    상기 복수의 TP 패킷을 하나 이상의 미디어 수신 디바이스에 전송하도록 상기 미디어 전송 디바이스의 프로세서를 구성하기 위해 저장된 명령어를 포함하고,
    상기 복수의 TP 패킷의 제1 스트림은 스케일러블 코딩(SC) 인코더에 의해 생성된 압축된 미디어 데이터 유닛을 전달하고, 상기 복수의 TP 패킷의 각각은 할당된 우선순위 레벨을 갖고 있고, 상기 복수의 TP 패킷의 제1 스트림은 제1 우선순위 레벨의 적어도 하나의 패킷 및 제2 우선순위 레벨의 적어도 하나의 패킷을 포함하고,
    상기 제1 시퀀스 넘버는 상기 제1 우선순위 레벨의 각 TP 패킷에 대해 변경되는 것을 특징으로 하는 영구 컴퓨터 판독가능 매체.
  31. 제30항에 있어서, 상기 명령어는 상기 프로세서가,
    하나 이상의 전송된 TP 패킷을 소스-재전송 버퍼에 저장하고,
    수신 디바이스로부터 특정 TP 패킷의 재전송을 위한 요청을 수신하고,
    상기 특정 TP 패킷에 대한 소스-재전송 버퍼를 검색하고,
    상기 요청에 응답하여 상기 특정 TP 패킷을 상기 수신 디바이스에 재전송하도록 상기 프로세서를 구성하기 위한 명령어를 더 포함하는 것을 특징으로 하는 영구 컴퓨터 판독가능 매체.
  32. 제31항에 있어서, 상기 프로세서가 하나 이상의 전송된 TP 패킷을 소스-재전송 버퍼에 저장하도록 상기 프로세서를 구성하는 명령어는 상기 프로세서가 상기 제1 우선순위 레벨을 갖는 TP 패킷만을 상기 소스-재전송 버퍼에 저장하도록 상기 프로세서를 구성하는 명령어를 포함하는 것을 특징으로 하는 영구 컴퓨터 판독가능 매체.
KR20130014703A 2012-02-10 2013-02-08 멀티-홉 ｒｔｐ 스트림에서의 중요 패킷 손실 처리 시스템 및 방법 KR101458852B1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201261597524P 2012-02-10 2012-02-10
US61/597,524 2012-02-10

Publications (2)

Publication Number Publication Date
KR20130092509A true KR20130092509A (ko) 2013-08-20
KR101458852B1 KR101458852B1 (ko) 2014-11-12

Family

ID=47678632

Family Applications (1)

Application Number Title Priority Date Filing Date
KR20130014703A KR101458852B1 (ko) 2012-02-10 2013-02-08 멀티-홉 ｒｔｐ 스트림에서의 중요 패킷 손실 처리 시스템 및 방법

Country Status (5)

Country Link
US (1) US9131110B2 (ko)
EP (1) EP2627054B1 (ko)
JP (1) JP5588527B2 (ko)
KR (1) KR101458852B1 (ko)
CN (1) CN103313026B (ko)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9843489B2 (en) * 2013-06-12 2017-12-12 Blackfire Research Corporation System and method for synchronous media rendering over wireless networks with wireless performance monitoring
US9131110B2 (en) 2012-02-10 2015-09-08 Polycom, Inc. System and method for handling critical packets loss in multi-hop RTP streaming
CN103945449B (zh) * 2013-01-18 2018-12-04 中兴通讯股份有限公司 Csi测量方法和装置
CN103475835B (zh) * 2013-09-18 2016-10-05 华为技术有限公司 一种音视频会议录制内容的处理方法及装置
US20160227229A1 (en) * 2015-02-04 2016-08-04 Harris Corporation Mobile ad hoc network media aware networking element
CN105898328A (zh) * 2015-12-14 2016-08-24 乐视云计算有限公司 包含自参考编码的参考帧集设置方法及装置
US10230948B2 (en) * 2016-02-03 2019-03-12 Mediatek Inc. Video transmitting system with on-the-fly encoding and on-the-fly delivering and associated video receiving system
US10148582B2 (en) * 2016-05-24 2018-12-04 Samsung Electronics Co., Ltd. Managing buffers for rate pacing
US10869032B1 (en) 2016-11-04 2020-12-15 Amazon Technologies, Inc. Enhanced encoding and decoding of video reference frames
US10484701B1 (en) 2016-11-08 2019-11-19 Amazon Technologies, Inc. Rendition switch indicator
US10264265B1 (en) 2016-12-05 2019-04-16 Amazon Technologies, Inc. Compression encoding of images
US10681382B1 (en) * 2016-12-20 2020-06-09 Amazon Technologies, Inc. Enhanced encoding and decoding of video reference frames
CN109687934B (zh) * 2017-10-18 2020-05-26 上海交通大学 基于媒体内容的自适应系统码fec方法、装置及系统
CN108307194A (zh) * 2018-01-03 2018-07-20 西安万像电子科技有限公司 图像编码的传输控制方法及装置
CN111246290B (zh) * 2018-11-29 2022-07-05 中国电信股份有限公司 图像接收处理方法和装置
US11477138B2 (en) * 2020-12-23 2022-10-18 Nokia Solutions And Networks Oy Packet reordering in packet switched networks
KR20220124031A (ko) 2021-03-02 2022-09-13 삼성전자주식회사 영상 패킷을 송수신하는 전자 장치 및 이의 동작 방법
CN115209231B (zh) * 2022-09-07 2024-03-22 腾讯科技（深圳）有限公司 数据传输方法、装置、设备和计算机可读存储介质

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3168894B2 (ja) * 1995-12-26 2001-05-21 三菱電機株式会社 データ伝送装置およびデータ伝送方法
JP3450771B2 (ja) * 1998-11-30 2003-09-29 松下電器産業株式会社 データ伝送方法，及びデータ送信装置
US6263022B1 (en) * 1999-07-06 2001-07-17 Philips Electronics North America Corp. System and method for fine granular scalable video with selective quality enhancement
US6870816B1 (en) * 2000-03-01 2005-03-22 Motorola, Inc. Self-organizing network with decision engine and method
US6757248B1 (en) * 2000-06-14 2004-06-29 Nokia Internet Communications Inc. Performance enhancement of transmission control protocol (TCP) for wireless network applications
JP3590949B2 (ja) 2000-08-17 2004-11-17 松下電器産業株式会社 データ伝送装置およびデータ伝送方法
JP4070420B2 (ja) * 2001-03-23 2008-04-02 フェニックス電機株式会社 超高圧放電灯の点灯方法と点灯装置
US7159108B2 (en) * 2002-10-04 2007-01-02 International Business Machines Corporation Anonymous peer-to-peer networking
US20060291468A1 (en) * 2005-06-22 2006-12-28 Rajendra Bopardikar Selective re-transmission of lost multi-media data packets
JP4874343B2 (ja) * 2006-01-11 2012-02-15 ノキア コーポレイション スケーラブルビデオ符号化における、下位互換性のあるピクチャの集約
CN101174995B (zh) * 2006-11-03 2010-05-12 中兴通讯股份有限公司 一种多媒体服务性能监测的方法和系统
KR101015888B1 (ko) * 2007-09-11 2011-02-23 한국전자통신연구원 스케일러블비디오 코딩에서 우선순위를 할당하기 위해 비디오 패킷의 왜곡값을 계산하는 장치 및 방법
US8699383B2 (en) * 2007-10-19 2014-04-15 Voxer Ip Llc Method and apparatus for real-time synchronization of voice communications
US8099512B2 (en) * 2007-10-19 2012-01-17 Voxer Ip Llc Method and system for real-time synchronization across a distributed services communication network
US8250181B2 (en) * 2007-10-19 2012-08-21 Voxer Ip Llc Method and apparatus for near real-time synchronization of voice communications
JP5142828B2 (ja) 2008-05-29 2013-02-13 キヤノン株式会社 送信装置、送信方法及びプログラム
US8228363B2 (en) 2009-01-30 2012-07-24 Polycom, Inc. Method and system for conducting continuous presence conferences
EP2437440A1 (en) * 2010-10-01 2012-04-04 Koninklijke Philips Electronics N.V. Device and method for delay optimization of end-to-end data packet transmissions in wireless networks
US9131110B2 (en) 2012-02-10 2015-09-08 Polycom, Inc. System and method for handling critical packets loss in multi-hop RTP streaming

Also Published As

Publication number Publication date
JP5588527B2 (ja) 2014-09-10
EP2627054B1 (en) 2018-12-19
EP2627054A1 (en) 2013-08-14
JP2013211835A (ja) 2013-10-10
US20130208079A1 (en) 2013-08-15
US9131110B2 (en) 2015-09-08
CN103313026B (zh) 2017-03-01
KR101458852B1 (ko) 2014-11-12
CN103313026A (zh) 2013-09-18

Similar Documents

Publication Publication Date Title
KR101458852B1 (ko) 멀티-홉 ｒｔｐ 스트림에서의 중요 패킷 손실 처리 시스템 및 방법
US11503250B2 (en) Method and system for conducting video conferences of diverse participating devices
US9426423B2 (en) Method and system for synchronizing audio and video streams in media relay conferencing
US8988486B2 (en) Adaptive video communication channel
US8228363B2 (en) Method and system for conducting continuous presence conferences
US7830409B2 (en) Split screen video in a multimedia communication system
US9215416B2 (en) Method and system for switching between video streams in a continuous presence conference
US8184142B2 (en) Method and system for composing video images from a plurality of endpoints
US20220329883A1 (en) Combining Video Streams in Composite Video Stream with Metadata
JP2013042492A (ja) 常駐表示式ビデオ会議においてビデオストリームを切替える方法およびシステム
CN114600468B (zh) 将复合视频流中的视频流与元数据组合的组合器系统、接收器设备、计算机实现的方法和计算机可读介质

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
FPAY Annual fee payment

Payment date: 20180108

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20180928

Year of fee payment: 5