KR102118678B1 - 부호화된 비디오 스트림 전송 장치 및 방법 - Google Patents

Abstract

TCP와 UDP의 장점을 모두 이용할 수 있는 본 발명의 일 측면에 따른 부호화된 비디오 스트림 전송 장치는, 미리 정해진 압축 규격을 이용하여 비디오 스트림을 부호화하는 엔코더; 상기 부호화된 비디오 스트림을 복수개의 서브 스트림으로 구분하고, 각 서브 스트림을 파싱하는 파서; 파싱된 서브 스트림으로부터 SPS(Sequence Parameter Set), PPS(Picture Parameter Set), 또는 슬라이스 헤더(Slice Header)를 갖는 NAL(Network Adaptation Layer) 유닛인 제1 데이터와 슬라이스 데이터(Slice Data)를 갖는 NAL 유닛인 제2 데이터로 구분하는 먹스; 상기 서브 스트림 별로 상기 제1 데이터를 이용하여 TCP(Transmission Control Protocol) 패킷을 생성하고, 생성된 TCP 패킷을 TCP 터널을 통해 전송하는 제1 패킷 생성부; 및 상기 서브 스트림 별로 상기 제2 데이터를 이용하여 UDP(User Datagram Protocol) 패킷을 생성하고, 생성된 UDP 패킷을 UDP 터널을 통해 전송하는 제2 패킷 생성부를 포함하는 것을 특징으로 한다.

Description

부호화된 비디오 스트림 전송 장치 및 방법{Apparatus and Method for Transmitting Encoded Video Stream}

본 발명은 데이터 전송에 관한 것으로서, 보다 구체적으로는 부호화된 비디오 스트림 전송 장치 및 방법에 관한 것이다.

WLAN 상에서 HD 비디오 스트리밍이 가능해졌고, 네트워크 대역폭과 같은 중요한 기술들이 지속적으로 향상되고 있으며, 스마트폰, 모바일 인터넷 장치, 및 무선 디스플레이 장치의 사용이 증가하고 있다.

일부 주목할 만한 무선 HD 스트리밍 기술들에는 애플사의 에어 플레이, 인텔사의 WiDi, 및 캐비움 사의 WiVu가 있다. 이 기술들은 애드혹(ad-hoc) 모드에서 적용되고 있다. 최신 비디오 압축 표준인 H.264는 더 효율적인 압축 알고리즘을 제공함으로써 무선 비디오 스트리밍을 용이하게 하였고, 이로 인해 네트워크를 통해 전송되어야 하는 데이터의 양이 감소하게 되었다. 더욱이, H.264는 데이터 분할(Data Partitioning: DP), 플렉서블 매크로 블록 오더링(Flexible Macroblock Ordering: FMO), 및 네트워크 어댑테이션 레이어(Network Adaption Layer: NAL) 구조와 같이 에러 내성적이고 네트워크 친화적인 많은 기술들을 제공한다. 하지만, 무선 HD 비디오 스트리밍은 여전이 많은 어려움에 직면해 있다. 이것은 일반적인 데이터 전송과는 달리, 비디오 스트리밍은 데이터 무결성(Data Integrity) 뿐만 아니라 패킷 지연 및 유실의 존재 하에서 엄격한 출력 마감시한(Playout Deadline)을 갖는 프레임들을 요구하기 때문이다. 또한, 이 두 가지 팩터들은 전송 프로토콜과 밀접하게 관련되어 있다.

TCP(Transmitting Control Protocol) 및 UDP(User Datagram Protocol)는 네트워크를 통해 비디오 데이터를 전송하기 위해 사용되는 2개의 기본적인 전송 계층(Transport Layer) 프로토콜들이다. TCP는 신뢰할만한 프로토콜이지만 유실된 패킷들의 재전송으로 인한 지연 및 대역폭 소모가 있고, 이것들이 패킷 유실 가능성을 더욱 증가시킨다. 예를 들면, HTTP에 기반한 비디오 스트리밍은 TCP에 기초하고 있다. TCP에 의해 발생되는 지연을 가리거나 감소시키기 위한 많은 연구가 수행되었지만, 실시간 비디오 스트리밍에 있어서 이것은 여전히 중요한 문제로 남아 있다. 반대로, UDP는 최소한의 지연을 제공하지만 패킷전송을 보장하지는 못한다. 유실된 패킷들은 연속하는 프레임들로 전파되는 에러의 원인이 된다.

비디오 스트리밍을 향상시키기 위해 TCP 및 UDP에 대해 주목할만한 양의 연구가 진행되었을 지라도, 무선 비디오 스트리밍에 있어서 TCP 및 UDP 사용의 이점을 활용하는 데에는 거의 주의를 기울이지 못했다. Porter 및 Peng은 "Hybrid TCP/UDP Video Transport For H.264/AVC Content Delivery In Burst Loss Networks"라는 제목으로 발표된 논문에서, 하이브리드 TCP/UDP 스트리밍 방법을 제안했다. 이 방법은 우선순위가 높은 데이터는 TCP에 기초하여 전송하고 우선순위가 낮은 데이터는 UDP에 기초하여 전송한다. 하지만, Porter 및 Peng은 현실의 네트워크 환경에서 그들의 방법을 실제 구현하지 않았고, 대신에 UDP에 의한 패킷 유실을 시뮬레이터하기 위해 부호화된 비디오로부터 부분적으로 랜덤하게 데이터를 제거하는 기법을 사용했다. 이 평가 프로세스는 엄격함이 결여되었고, TCP 및 UDP를 사용함에 의해 발생되는 영상품질 및 버퍼링 시간과 같은 중요한 결과를 제공하지는 못했다.

비디오 스트리밍과 관련하여 아래와 같은 선행특허문헌들이 존재한다. 먼저, 미국 등록특허 제8,356, 109호에서는, 인트라 부호화된 프레임들 및 높은 우선순위를 갖는 인터 부호화된 프레임들은 복수개의 TCP 채널들 상에서 전송하고, 낮은 우선선위를 갖는 인터 부호화된 프레임들은 복수개의 UDP 채널들을 통해 전송함에 의해 수신된 비디오의 품질을 향상시킨다. 이 발명은 복수개의 통신 채널을 갖는 네트워크에 포커싱하고 있다. 추가적으로, 높은 우선순위를 갖는 데이터 및 낮은 우선순위를 갖는 데이터의 분리는 프레임 레벨에서 수행된다. 하지만, 항상 복수개의 통신 채널들이 실행 가능할 수는 없다. 예컨대, 가정환경에서 비디오 스트리밍은 점대점 방식으로 수행되고, 이것은 하나의 통신 채널만이 가용적이라는 것을 의미한다. 이 발명은 이러한 환경에서는 적용되지 않는고, 더욱이 이 발명은 TCP 채널을 통해 단지 완벽한 프레임만을 전송할 수 있다는 제한이 있다.

다음으로, 미국 공개특허 제2012/0173748호에서는, 미디어를 스트리밍하기 위해 TCP 및 UDP 프로토콜 모두가 이용된다. 이 발명은 높은 우선선위 미디어 데이터를 TCP 상에서 클라이언트에게 전달하고, 낮은 우선순위 미디어 데이터를 UDP 상에서 클라이언트에게 전달한다. 비록, 이 특허가 높은 우선순위 데이터 및 낮은 우선순위 데이터가 무엇인지 구체적으로 규정하고 있지는 않지만, 이 특허는 다음과 같이 말하고 있다. "미디어 데이터가 일련의 픽쳐(Picture)로써 부호화되는 경우, 미디어 데이터의 제1 부분은 높은 우선순위를 갖는 인트라 부호화된 픽쳐들을 포함하고, 미디어 데이터의 제2 부분은 하나 이상의 낮은 우선순위를 갖는 인터 부호화된 픽쳐들을 포함한다". 위의 진술은 이 발명 또한 프레임 레벨에서 데이터를 분리하는 것임을 명확하게 나타낸다. 더욱이, 높은 우선순위 데이터가 인트라 부호화된 프레임으로써 규정되고, 반면 낮은 우선순위 데이터가 인터 부호화된 프레임들로 규정되고 있다. 추가적으로, 이 발명은 비디오 스트리밍의 QoE의 핵심사항인 이니셜 버퍼링 및 리버퍼링을 고려하지 않았다는 한계가 있다.

다음으로, 미국 등록특허 제6,771,594호에서는, 실시간 데이터 스트리밍의 QoS를 모니터링하여, QoS가 임계값 이하로 떨어지는 경우 실시간 데이터는 TCP와 같은 신뢰성있는 네트워크 서비스를 통해 라우팅하고, QoS가 적절한 경우 데이터는 UDP와 같이 신뢰성이 없는 서비스 네트워크로 라우팅하는 것을 제시하고 있다. 이 발명을 이용하는 경우 수신된 실시간 데이터의 품질은 변동적일 수 있다는 문제점이 있다. QoS가 임계값이하가 되어 남은 데이터가 TCP를 통해 라우팅되면, 이미 그 기간 동안 스트리밍되는 비디오 품질은 열악해질 것이다. 따라서, TCP와 UDP간의 일정한 스위칭으로 인해 스트리밍 품질이 일정해 질 수 없게 된다. 더욱이, 이 발명은 비디오 스트리밍에 비해 데이터 양이 훨씬 적은 VoIP에만 적용된다는 한계가 있다.

본 발명은 전술한 종래의 문제점을 해결하기 위해 고안된 것으로서, TCP와 UDP의 장점을 모두 이용할 수 있는 부호화된 비디오 스트림 전송 장치 및 방법을 제공하는 것을 그 기술적 특징으로 한다.

또한, 본 발명은 비디오 스트림을 복수개의 서브 스트림들로 분할하고, 각 서브 스트림에 대해 높은 우선순위를 갖는 데이터는 TCP를 통해 전송하고 낮은 우선선위를 갖는 데이터는 UDP를 통해 전송할 수 있는 부호화된 비디오 스트림 전송 장치 및 방법을 제공하는 것을 다른 기술적 특징으로 한다.

또한, 본 발명은 길이가 긴 비디오 스트림에 대해 리버퍼링의 가능성을 감소시키고 이니셜 버퍼링을 최소화시키기 위해 서브 스트림들을 중첩해서 전송할 수 있는 부호화된 비디오 스트림 전송 장치 및 방법을 제공하는 것을 그 기술적 특징으로 한다.

상술한 목적을 달성하기 위한 본 발명의 일 측면에 따른 부호화된 비디오 스트림 전송 장치는, 미리 정해진 압축 규격을 이용하여 비디오 스트림을 부호화하는 엔코더; 상기 부호화된 비디오 스트림을 복수개의 서브 스트림으로 구분하고, 각 서브 스트림을 파싱하는 파서; 파싱된 서브 스트림으로부터 SPS(Sequence Parameter Set), PPS(Picture Parameter Set), 또는 슬라이스 헤더(Slice Header)를 갖는 NAL(Network Adaptation Layer) 유닛인 제1 데이터와 슬라이스 데이터(Slice Data)를 갖는 NAL 유닛인 제2 데이터로 구분하는 먹스; 상기 서브 스트림 별로 상기 제1 데이터를 이용하여 TCP(Transmission Control Protocol) 패킷을 생성하고, 생성된 TCP 패킷을 TCP 터널을 통해 전송하는 제1 패킷 생성부; 및 상기 서브 스트림 별로 상기 제2 데이터를 이용하여 UDP(User Datagram Protocol) 패킷을 생성하고, 생성된 UDP 패킷을 UDP 터널을 통해 전송하는 제2 패킷 생성부를 포함하는 것을 특징으로 한다.

상술한 목적을 달성하기 위한 본 발명의 다른 측면에 따른 부호화된 비디오 스트림 전송 방법은, 미리 정해진 압축 규격을 이용하여 비디오 스트림을 부호화하는 단계; 상기 부호화된 비디오 스트림을 복수개의 서브 스트림으로 구분하는 단계; 상기 서브 스트림으로부터 SPS(Sequence Parameter Set), PPS(Picture Parameter Set), 또는 슬라이스 헤더(Slice Header)를 갖는 NAL(Network Adaptation Layer) 유닛인 제1 데이터와 슬라이스 데이터(Slice Data)를 갖는 NAL 유닛인 제2 데이터로 구분하는 단계; 상기 제1 데이터를 이용하여 TCP(Transmission Control Protocol) 패킷을 생성하고, 상기 제2 데이터를 이용하여 UDP(User Datagram Protocol) 패킷을 생성하는 단계; 및 상기 생성된 TCP 패킷을 TCP 터널을 통해 전송하고, 상기 생성된 UDP 패킷을 UDP 터널을 통해 전송하는 단계를 포함하는 것을 특징으로 한다.

상술한 바와 같은 본 발명에 따르면 높은 우선순위를 갖는 데이터와 낮은 우선순위를 갖는 데이터를 구분하는 기본 단위가 NAL 유닛이기 때문에, H.264 기반의 어떠한 신택스 엘리먼트에 대해서도 우선순위를 결정할 수 있어 매우 유연하게 적용할 수 있다는 효과가 있다.

또한, 본 발명에 따르면 비디오 스트림을 복수개의 서브 스트림들로 분할하고, 분할된 서브 스트림들을 중첩하여 전송하기 때문에 이니셜 버퍼링을 최소화함은 물론 리버퍼링의 발생 및 리버퍼링의 시간을 최소화할 수 있다는 효과가 있다.

또한, 본 발명에 따르면 각 서브 스트림에 대해, 높은 우선순위를 갖는 데이터(예컨대, SPS(Sequence Parameter Set), PPS(Picture Parameter Set), 및 슬라이스 헤더)가 TCP를 통해 우선 전송되므로, 낮은 우선선위를 갖는 데이터(예컨대, 슬라이스 데이터)가 패킷 유실로 인해 도달하지 못하는 경우에 있어서도 디코더가 EC(Error Concealment)의 적용을 통해 프레임을 복원하는 것이 가능하다는 효과가 있다.

또한, 본 발명에 따르면, H.264의 데이터 분할 기법을 이용하지 않기 때문에 재부호화되어야 하는 비디오가 요구되지 않고 네트워크 또한 데이터 분할을 지원할 필요가 없기 때문에 시스템의 유연성이 증가할 뿐만 아니라, 더욱이 비디오 스트림으로부터 획득된 어떠한 신택스 엘리먼트들도 분리되거나 우선순위가 결정될 수 있다는 효과가 있다. 예컨대, 영상품질의 향상을 위해 SPS, PPS, 및 슬라이스 헤더뿐만 아니라 슬라이스 데이터의 일부를 분리하여 우선순위를 결정할 수 있다.

또한, 본 발명에 따르면 서브 스트림들 간의 슬랙타임을 이용하여 I 슬라이스를 전송하기 때문에, I프레임의 영상 품질이 향상되고, 에러 전파가 감소된다는 효과가 있다.

도 1은 H.264 신택스의 구조를 보여주는 도면이다.
도 2는 HD 비디오 클립을 구성하는 하나의 프레임 상에서의 패킷 유실의 효과를 보여주는 도면이다.
도 3은 본 발명의 제1 실시예에 따른 부호화된 비디오 스트림 전송장치의 구성을 개략적으로 보여주는 블록도이다.
도 4는 본 발명의 일 실시예에 따라 서브 스트림을 중첩하여 전송하는 방법을 보여주는 도면이다.
도 5는 OEFMON의 일반적인 구조를 보여주는 도면이다.
도 6은 스트리밍 동안의 큐 상태를 보여주는 도면이다.
도 7은 시뮬레이터된 네트워크 시나리오를 보여주는 도면이다.
도 8은 도 7에 도시된 3개의 시나리오들에 대한 PSNR의 비교결과를 보여주는 도면이다.
도 9는 도 7에 도시된 3개의 시나리오들에 대한 패킷 유실을 보여주는 도면이다.
도 10은 도 7에 도시된 시나리오 2에서 본 발명에 따라 복호화된 프레임 134를 보여주는 도면이다.
도 11은 본 발명의 제2 실시예에 따른 부호화된 비디오 스트림 전송 장치의 구성을 개략적으로 보여주는 블록도이다.
도 12는 PBP 모듈을 갖지 않는 본 발명의 PSNR, 50% PBP의 PBP 모듈을 갖는 본 발명의 PSNR, 및 90% PBP의 PBP모듈을 갖는 본 발명의 PSNR을 비교하여 보여주는 도면이다.
도 13은 프레임 1187의 영상을 비교하여 보여주는 도면이다.

본 명세서에서 각 도면의 구성요소들에 참조번호를 부가함에 있어서 동일한 구성 요소들에 한해서는 비록 다른 도면상에 표시되더라도 가능한 한 동일한 번호를 가지도록 하고 있음에 유의하여야 한다.

한편, 본 명세서에서 서술되는 용어의 의미는 다음과 같이 이해되어야 할 것이다.

단수의 표현은 문맥상 명백하게 다르게 정의하지 않는 한 복수의 표현을 포함하는 것으로 이해되어야 하고, "제 1", "제 2" 등의 용어는 하나의 구성요소를 다른 구성요소로부터 구별하기 위한 것으로, 이들 용어들에 의해 권리범위가 한정되어서는 아니 된다.

"포함하다" 또는 "가지다" 등의 용어는 하나 또는 그 이상의 다른 특징이나 숫자, 단계, 동작, 구성요소, 부분품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

먼저, 본 발명에 대해 설명하기에 앞서, H.264 비디오를 부호화하는 방법과 스트리밍 하는 방법 관계, H.264로 부호화되어 스트리밍 되는 비디오의 영상 품질 상에서의 패킷 지연 및 유실로 인한 효과에 대해 설명한다.

H.264는 최신 비디오 압축 표준이다. H.264의 이전 압축버전과 비교할 때, H.264는 더 공격적인 압축비율을 제공하고, 모바일 비디오 스트리밍에 더 유리하게 만드는 네트워크 친화적 특징을 갖는다.

효과적인 비디오 스트리밍을 위해 H.264의 중요한 몇 가지 특징들이 있다. 2개의 가장 중요한 특징은 비디오 데이터를 비트 스트림 데이터로 부호화하기 위한 신택스와 이 정보의 일부분이 다른 것들보다 얼마나 중요한지이다.

H.264로 부호화된 비디오 스트림은 연속하는 GOP(Group of Picture)들로 구성된다. 각 GOP는 인트라 프레임(I프레임), 예측 프레임들(P프레임), 및 양방향 예측 프레임들(B프레임)로 구성된다. I프레임은 완전한 프레임을 복원하기 위해 요구되는 모든 데이터를 포함하고 다른 프레임들을 참조하지 않는다. 반대로, P프레임 및 B프레임들은 복호화과정에서 다른 프레임들의 참조를 요구한다. 만약, 참조 프레임이 에러들을 포함한다면, 이 에러들은 이 프레임을 참조하는 연속하는 프레임들을 통해 전파될 것이다. I프레임은 어떤 다른 프레임에 의존하지 않기 때문에, 새로운 I프레임이 도달하면 에러 전파는 중단될 것이다. 결과적으로, 가능하다면 I프레임들에게는 높은 우선순위가 주어져야만 한다.

H.264 비트 스트림 신택스 구조는 도 1에 도시된 바와 같다. H.264 비트 스트림 신택스는 연속하는 NAL(Network Analysis Layer)유닛들로 구성된다. 3개의 공통된 NAL 유닛들은 시퀀스 파라미터 셋(Sequence Parameter Set: SPS), 픽쳐 파라미터 셋(Picture Parameter Set: PPS), 및 슬라이스(Slice)이다. SPS는 프로파일 및 부호화된 비디오가 따르는 레벨과 같이 비디오 전체에 공통되는 파라미터들을 포함한다. 따라서, 만약 SPS가 유실되면 전체 비디오가 부호화될 수 없다. PPS는 적용된 엔트로피 코딩 모드와 같이 연속하는 프레임들에 적용되는 공통 파라미터들을 포함한다. 만약, 연속 프레임들에 대한 PPS가 유실되면 이 프레임들은 부호화될 수 없다. 슬라이스는 프레임을 구성하기 위한 하나의 유닛이고, 하나의 프레임은 싱글 슬라이스 또는 멀티플 슬라이스 중 어느 하나를 가질 수 있다. 슬라이스는 I슬라이스, P슬라이스, B스라이스, 또는 IDR (Instantaneous Decoder Refresh)슬라이스일 수 있다. IDR 슬라이스는 그 이전의 다른 슬라이스를 참조하지 않는 I슬라이스의 특별한 형태로써 참조 프레임 버퍼의 내용을 클리어하기 위해 사용된다. 슬라이스는 슬라이스 헤더와 복수개의 매크로 블록들을 포함하는 슬라이스 데이터를 포함한다. 슬라이스 헤더는 하나의 슬라이스에 포함된 모든 매크로 블록들에 공통된 정보를 포함한다. 각 슬라이스는 전송을 위해 하나 또는 복수개의 패킷들로 세분화된다. 따라서, 만약 슬라이스 헤더에 포함된 패킷이 유실되면 나머지 슬라이스 데이터가 적절하게 수신되더라도 전체 슬라이스가 부호화될 수 없다.

도 2는 VLC 미디어 플레이어를 이용하여 UDP를 통해 스트리밍되는 "배틀필드"라는 HD 비디오 클립에서 하나의 프레임 상에서의 패킷유실의 효과를 보여준다. 이는 Wireshark 및 Elecard StreamEye Studio를 통해 분석되어진 것이다. 도 2a는 원본 전송 프레임을 보여준다. 도 2b는 패킷 유실로 인해 유실된 일부정보를 갖는 수신 프레임을 보여준다. 이 예에서, 슬라이스 4에 대한 슬라이스 헤더가 유실되었기 때문에 전체 슬라이스가 부호화될 수 없다. 반대로, 슬라이스 5에 대한 슬라이스 헤더는 수신되었고 슬라이스 데이터의 일부분을 포함하는 마지막 2개의 RTP 패킷들이 유실된 경우 대부분의 슬라이스들이 부호화된다. 그 뒤에 약간의 결함을 갖는 유실된 정보를 복원하기 위해 에러 은폐(Error Concealment: EC)기술이 사용될 수 있다. 따라서, PPS, SPS들 및 슬라이스 헤더들은 가장 중요한 데이터이므로 비디오 스트리밍 과정에서 그들에 대한 더 많은 배려가 주어져야한다.

데이터 분할(Data Partitioning: DP)은 H.264의 에러내성적인 특성이다. 각 슬라이스에 대해 부호화된 데이터는 3개의 분리된 데이터 파티션인 A, B, 및 C에 위치된다. 파티션 A는 슬라이스 헤더 및 각 매크로블록에 대한 헤더(예컨대, MB타입, 양자화 파라미터, 및 모션 벡터들)를 포함한다. 파티션 B는 인트라 부호화된 매크로블록들에 대한 부호화된 블록 패턴들(Coded Block Patterns: CBPs) 및 계수를 포함한다. 파티션 C는 인터 부호화된 매크로블록들에 대한 CBPs 및 계수를 포함한다. 파티션 B를 복호화하기 위해서는 파티션 A가 반드시 존재해야만 한다. 파티션 C를 복호화하기 위해서는 파티션 A 및 B가 반드시 존재해야만 한다. 데이터 분할은 스트리밍 성능을 향상시키기 위해 비균등 오류정정(Unequal Error Protection: UEP) 기법과 함께 이용될 수 있다. 비록 데이터 분할이 에러 내성을 위한 강력한 도구일지라도 아직까지 넓게 적용되고 있지는 못하다. 이는 재부호화되어질 비디오와 802.11e 네트워크가 요구되기 때문이다.

현존하는 스트리밍 프로토콜들은 RTSP(Real Time Streaming Protocol), HTTP(HyperText Transfer Protocol), MMS(Microsoft Media Server), 및 RTP(Real-time Transport Protocol)를 포함한다. RTSP, HTTP, MMS, 및 RTP는 응용계층 프로토콜(Application Layer Protocol)들이기 때문에 그들 스스로가 스트림들을 전달하지 않는다는 것을 주목해야 한다. 예를 들면, RTP는 멀티미디어 데이터를 전달하기 위해 UDP 또는 TCP를 이용한다. RTSP, HTTP, 및 MMS는 스트리밍을 위해 더 많은 제어 특징들을 부가하지만 그들 또한 멀티미디어 데이터를 전달하기 위해 TCP 또는 UDP를 이용한다.

RTSP는 클라이언트가 원격에서 스트리밍 미디어 서버를 제어하는 것을 허용한다. 예를 들면, 클라이언트는 스트리밍동안 비디오를 재생, 정지, 및 탐색할 수 있다. RTSP는 QoS 상에서 통계적 데이터를 획득하기 위해 RTP 제어 프로토콜(RTCP)과 함께 이용될 수 있다. 전형적으로, RTSP는 제어 신호를 전달하기 위해 TCP를 이용하고, 멀티미디어 데이터를 전달하기 위해 RTP/UDP를 이용한다.

HTTP 또한 클라이언트가 스트리밍을 제어하는 것을 허용하고, 멀티미디어 데이터 및 제어 데이터 모두의 전송을 위해 TCP를 이용한다. HTTP는 TCP를 이용하기 때문에, 패킷들이 결코 유실되지 않는다. HTTP의 또 다른 장점은 HTTP 포트가 켜져 있을 때 방화벽 상에서도 동작한다는 것이다. 하지만, HTTP는 유실 패킷들이 재전송될 때 높은 종단간 지연이 발생할 것이다.

RTP는 멀티미디어 데이터의 전달을 위해 전형적으로 UDP를 이용한다. RTP 헤더는 시퀀스 넘버 및 타임스탬프를 포함한다. 시퀀스 넘버는 전송된 각 패킷에 대해 1씩 증가되고 패킷유실 검출을 위해 이용된다. 타임스탬프는 비디오 및 오디오와 같은 멀티플 스트림들을 동기화하기 위해 이용될 수 있다. 단지 RTP/UDP를 이용한 제어 기능은 없다는 것을 주목해야 한다.

본 발명의 목적에 있어서, 핵심은 RTP/UDP 및 RTP/TCP 다이렉트 스트리밍에 있다. 이는 그들이 다른 스트리밍 프로토콜에 대해 기초적인 것이기 때문이다.

UDP는 실시간 비디오 스트리밍에 대해 일반적으로 TCP보다 더 적절한 것으로 인식되고 있다. 이는 UDP가 TCP에 비해 부드러운 비디오 출력을 위해 낮은 종단간 지연을 제공하기 때문이다. 비록 UDP가 데이터 유실이 발생하기 쉬울지라도, 멀티 미디어 데이터는 일반적인 데이터와 달리 어느 정도의 손실내성(Loss-Tolerant)을 갖기 때문이다. 추가적으로, 디코더는 데이터 손실에 의한 결함을 감소시키기 위해 EC기법을 이용한다. 패킷유실에 의한 영향을 감소시키기 위한 많은 EC기법들이 개발되었다. 하지만, 만약 유실패킷이 SPS, PPS들, 및 슬라이스 헤더와 같이 중요한 정보를 포함한다면, 디코더는 비록 EC의 도움을 받더라도 단순하게 비디오를 복원할 수는 없다.

UDP 스트리밍에 의한 패킷 유실을 용인하기 위해, 비균등 오류 정정기법(UEP)이 종종 이용된다. 비균등 오류정정기법은 다른 데이터들보다 중요한 데이터를 우선처리하는 것을 목적으로 한다. 이는 일부 신택스 엘리먼트들은 다른 것들보다 더 중대한 것이기 때문이다. 기본적인 비균등 오류정정기법은 중요한 패킷들을 몇 번이고 전송한다. 이는 수신단에 패킷들의 도착 가능성을 높이게 된다. 더 향상된 비균등 오류정정기법은 순방향 오류 정정(Forward Error Correction: FEC)을 포함한다. 반복성을 가지고 중요한 패킷들을 부호화하기 위해 순방향 오류정정을 이용함으로써, 수신단은 유실 패킷들을 재전송없이 복구할 수 있다. 하지만, 순방향 오류정정은 추가적인 오버헤드를 야기하고, 그것은 비디오를 전송하기 위해 요구되는 네트워크 대역폭을 증가시킨다.

스트리밍에 있어서 TCP는 바람직하지 않다는 일반적인 견해에도 불구하고, 상업적 비디오 스트리밍 트래픽의 중요한 부분에서는 TCP를 이용한다. TCP는 보장된 서비스를 제공하고, 따라서 전송된 패킷들이 항상 보존된다. 그럼에도 불구하고, TCP의 재전송 및 전송률 메커니즘은 지연을 발생시키고, 그것은 출력마감시한 이후에 패킷들이 도착하게 되는 원인이 된다. 이 문제에 대한 전형적인 해법은 비디오 디코더 전단에 버퍼를 추가하는 것이다. 비디오 스트리밍의 시작시점에서, 디코더는 최초 처리량 변화 또는 패킷간 지터(Jitter)를 수용하기 위해 비디오를 디스플레이하기 이전에 버퍼가 채워질 때까지 대기한다. 이 대기시간은 이니셜 버퍼링이라 불려진다. 디코더가 버퍼에서 비디오 데이터를 디코드하기 시작한 이후에, TCP 세션 내에서 처리량의 감소는 버퍼 고갈의 원인이 된다. 이것이 발생되면, 디코더는 충분한 개수의 패킷들이 수신될 때까지 비디오 디스플레이를 중지시킨다. 이 대기시간은 리버퍼링이라 불려진다. 버퍼링은 지연 패킷들이 드롭되는 것을 방지한다. 하지만, 긴 이니셜 버퍼링은 네트워크 혼잡의 원인이 될 수 있고, 빈번한 리버퍼링은 사용자의 느낌을 저하시킨다. 리버퍼링의 빈도를 감소시키기 위한 적절한 버퍼 크기를 결정하기 위한 많은 연구가 있었다.

무선 비디오 스트리밍을 향상시키기 위한 또 다른 접근은 IEEE 802.11e 네트워크를 이용하는 것이다. 그것은 MAC(Media Access Control)계층에 대한 변경을 통해 QoS향상 조합을 규정한다. 802.11e 네트워크에서, 비디오 및 오디오와 같이 지연에 민감한 데이터는 우선선위가 높은 클래스에 할당될 수 있다. 만약, MAC계층에서 충돌이 발생한다면 높은 우선순위를 갖는 데이터를 전송하기 위해 더 작은 충돌 윈도우 크기가 이용될 수 있다. 이에 따라 더 낮은 전송 지연이 달성될 수 있다. 802.11e는 특별히 멀티미디어에 잘 맞도록 되어 있다. 하지만, 하드웨어 변경이 요구되기 때문에 넓게 채택되지 못하고 있다.

이하, 첨부된 도면들을 참조하여 본 발명에 따른 부호화된 비디오 스트림 전송 장치 및 방법에 대해 보다 구체적으로 설명한다.

도 3은 본 발명의 제1 실시예에 따른 부호화된 비디오 스트림 전송 장치의 구성을 개략적으로 보여주는 블록도이다.

도 3에 도시된 바와 같이, 본 발명의 제1 실시예에 따른 부호화된 비디오 스트림 전송 장치(300)는 전송기(310) 및 수신기(320)를 포함한다.

전송기(310)는 엔코더(311), 파서(312), 먹스(313), 제1 패킷 생성부(314), 및 제2 패킷 생성부(315)를 포함한다.

엔코더(311)는 원본 비디오 스트림을 미리 정해진 비디오 압축 규격을 이용하여 부호화한다. 미리 정해진 비디오 압축 규격은 H.264 또는 H.265와 같은 H.26x계열일 수 있다. 일 실시예에 있어서, 본 발명에 따른 장치(300)는 H.26x계열의 압축 규격에서 정의된 비디오 분할 기법을 적용하지 않기 때문에, 엔코더(311)는 원본 비디오 스트림이 데이터 분할(Data Partitioning: DP) 프로파일을 포함하지 않도록 부호화한다.

파서(312)는 부호화된 비디오 스트림을 복수개의 n초(n-second) 서브 스트림들로 분할한다. 각 서브 스트림은 복수개의 프레임들로 구성된다. 파서(312)는 복수개의 서브 스트림들을 파싱하여 각 서브 스트림으로부터 SPS, PPS, 슬라이스 헤더, 및 슬라이스 데이터를 획득한다. 스트리밍 이전에 파서(312)는 시작주소(Start Address), 길이(Length), NAL 유닛의 타입 등과 같은 각 서브 스트림들의 신택스 정보를 먹스(313)의 입력으로 제공한다. 본 발명의 일 실시예에 있어서, 파서(312)는 H.264 신택스 파서로 구현될 수 있다. 또한, 본 발명의 일 실시예에 있어서, 스트리밍 동안 각 NAL 유닛들은 RTP 패킷으로 인캡슐레이션 된다.

먹스(MUX, 313)는 파싱된 서브 스트림으로부터 획득된 데이터들을 제1 및 제2 데이터로 분리한다. 제1 데이터는 SPS, PPS, 또는 슬라이스 헤더와 같이 우선선위가 높은 데이터를 의미한다. 제2 데이터는 슬라이스 데이터와 같이 우선순위가 낮은 데이터를 의미한다. 이러한 경우에, 먹스(313)는 RTP 패킷이 제1 데이터인 NAL 유닛을 포함하는지 여부를 판단한다. 만약, RTP 패킷이 제1 데이터인 중요한 NAL 유닛을 포함하는 경우, 먹스(313)는 중요한 NAL 유닛을 포함하는 RTP 패킷을 제1 패킷 생성부(314)로 제공하고, 제2 데이터인 NAL 유닛을 포함하는 RTP 패킷은 제2 패킷 생성부(315)로 제공한다.

제1 패킷 생성부(314)는 제1 데이터를 이용하여 TCP 패킷을 생성하고, 생성된 TCP 패킷들을 TCP 터널을 통해 전송한다. 제2 패킷 생성부(315)는 제2 데이터를 이용하여 UDP 패킷을 생성하고, 생성된 UDP 패킷들을 UDP 터널을 통해 전송한다. 일 실시예에 있어서, TCP 패킷을 전송하기 위한 TCP 세션과 UDP 패킷을 전송하기 위한 UDP 세션은 비디오 스트리밍 동안 액티브 상태로 유지된다. 다시 말하면, 부호화된 비디오 스트림 전송장치(300)는 부호화된 비디오 스트림을 전송하기 위해 듀얼 터널링(TCP+UDP)를 이용한다.

본 발명의 일 실시예에 있어서, 전송기(310)는 먼저 TCP를 통해 제1 데이터를 전송한 후에 UDP를 통해 제2 데이터를 전송한다. 다시 말하면, 전송기(310)는 제1 데이터를 포함하는 TCP 패킷을 먼저 전송하고, 이후에 제2 데이터를 포함하는 UDP 패킷을 전송한다. 예컨대, 12초 길이를 갖는 비디오 스트림에 대해, 이니셜 버퍼링(Initial Buffering, 즉, TCP를 통해 제1 데이터를 전송하는데 소요되는 시간)은 2초보다 작다. 하지만, 전체 비디오 스트림을 스트리밍 할 때 이니셜 버퍼링은 허용할 수 없을 정도로 길어진다. 따라서, 본 발명에 따른 전송기(310)는 이니셜 버퍼링 조건을 감소시키기 위해, n번째 서브 스트림에 포함된 UDP 패킷과 n+1번째 서브 스트림에 포함된 TCP 패킷을 동시에 전송한다. 즉, 본 발명은 서브 스트림의 전송을 중첩시킨다.

도 4는 본 발명의 일 실시예에 따른 서브 스트림의 중첩전송을 보여준다. 도 4에 도시된 바와 같이, 전체 비디오 스트림은 몇 개의 n초 서브 스트림들로 분할된다. 도 4에서는 처음 2개의 서브 스트림들만 도시하였다. 전송기(310)는 TCP를 통해 서브 스트림 1의 제1 데이터를 포함하는 TCP 패킷을 전송할 것이다. 이후, 전송기(310)는 일반적인 UDP 스트리밍을 시작할 것이다. 전송기(310)가 특정 UDP 패킷을 전송하지 않는 한, 전송기(310)는 서브 스트림 2의 제1 데이터를 포함하는 TCP 패킷을 TCP를 통해 전송할 것이다. 만약, 출력 마감시한이 될 때까지 서브 스트림 1의 제1 데이터를 포함하는 TCP 패킷이 준비되지 않는다면 전송기(310)는 비디오 스트리밍을 중단하고 리퍼퍼링을 수행할 것이다.

다시 말하면, 서브 스트리밈의 중첩 전송의 과정은 다음의 4단계로 구분될 수 있다. 첫 번째 단계로, 비디오 스트림이 복수개의 n초 서브 스트림들로 분할된다. 두 번째 단계로, 첫 번째 n초 서브 스트림의 제1 데이터만이 TCP를 통해 전송된다. 세 번째 단계로, 일반적인 UDP 스트리밍이 시작된다. 네 번째로, 만약 네트워크가 상대적으로 여유가 있다면, 다음번 n초 서브 스트림들의 제1 데이터가 TCP를 통해 전송된다.

네 번째 단계에서, 네트워크가 상대적으로 여유가 있는지 여부를 판단하는 조건은 네트워크 레이어 큐(Network Layer Queue, 미도시)를 모니터링함에 의해 수행된다. 만약, 네트워크 레이어 큐(이하, '큐'라 함)에 저장된 패킷들의 개수가 임계치보다 작으면, 전송기(310)는 이전 서브 스트림의 UDP 스트리밍 동안 다음번 서브 스트림들의 TCP 패킷을 전송할 것이다.

다시 도 3을 참조하면, 수신기(320)는 제1 패킷 수신부(321), 제2 패킷 수신부(322), 디먹스(323), 및 디코더(324)를 포함한다.

제1 패킷 수신부(312)는 TCP 터널을 통해 TCP 패킷을 수신하고, 수신된 TCP 패킷을 디먹스(323)로 전달한다. 제2 패킷 수신부(322)는 UDP 터널을 통해 UDP 패킷을 수신하고, 수신된 UDP 패킷을 디먹스(323)로 전달한다.

디먹스(DEMUX, 323)는 지연된 UDP 패킷을 드롭(Drop)시키고, 정시에 도착한 UDP 패킷을 TCP 패킷과 결합시킨다. 이후, 디먹스(323)는 결합된 UDP 패킷과 TCP 패킷을 디코더(324)로 전달한다. 구체적으로, TCP 패킷이 수신되면, 디먹스(323)는 TCP 패킷을 저장부(325)에 저장한다. UDP 패킷이 수신되면, 디먹스(323)는 우선 UDP 패킷을 파싱하여 RTP 타임 스탬프(Time Stamp)를 획득한다. 만약, RTP 타임 스탬프가 출력 마감시한보다 크면, 디먹스(323)는 해당 UDP패킷은 지연된 것으로 판단하여 드롭시킨다. 만약, RTP 타임 스탬프가 출력 마감시한 이하이면 디먹스(323)는 UDP 패킷을 파싱하여 RTP 시퀀스 넘버(Sequence Number)를 획득한다. 이후, 디먹스(323)는 저장부(325)를 파싱하여 RTP 시퀀스 넘버가 UDP 패킷의 RTP 시퀀스 넘버보다 작은 TCP 패킷이 존재하는지 여부를 판단한다. 만약, 존재한다면, 디먹스(323)는 이 TCP 패킷을 현재 UDP 패킷과 결합시키고, 결합된 UDP 패킷과 TCP 패킷을 디코더(324)로 전달한다.

디코더(324)는 결합된 UDP 패킷과 TCP 패킷을 복호화하여 비디오 스트림을 복원하고, 복원된 비디오 스트림을 디스플레이를 통해 출력한다. 디코더(324)는 FFmpeg로 구현될 수 있다.

본 발명의 제1 실시예에 따른 부호화된 비디오 스트림 전송 장치(300)는 Direct-Show multimedia 및 QualNet 네트워크 시뮬레이터를 통합한 Open Evaluation Framework for Multimedia Over Networks(OEFMON, 이하 'OEFMON'이라 함)에서 구현될 수 있다. OEFMON의 개략적인 구성도가 도 5에 도시되어 있다. 도 5에 도시된 바와 같이, 핵심구성은 퀄넷 컨넥터(QualNet Connector), 비디오 소스 필터(Video Source Filter), 및 비디오 라이터 필터(Video Writer Filter)이다. 퀄넷 컨넥터는 RTP 패킷화를 수행한다. 비디오 소스 필터는 H.264파일을 리드하고, 리드된 데이터를 퀄넷 컨넥터로 전송한다. 비디오 라이터 필터는 복호화된 프레임 데이터를 원본 비디오 데이터로 기록한다. 이하, 본 발명에 따른 부호화된 비디오 스트림 전송장치의 구현을 위한 OEFMON의 핵심구성들에 대해 구체적으로 설명한다.

OEFMON은 퀄넷 네트워크 시뮬레이터에서 UDP 스트리밍을 구현한다. 듀얼 터널링을 구현하기 위해, UDP 스트리밍을 위한 기존의 코드 변경이 요구되고 TCP 스트밍 모듈의 구현이 요구된다. 퀄넷은 이산-이벤트(Discrete-event) 시뮬레이터이고, 이벤트는 MESSAGE로 불려지는 데이터 구조에 의해 표현된다. 오리지널 코드는 UDP를 위한 메시지에 미리 포함되고, 한 쌍의 MESSAGE가 있다. 하나는 전송기(310)용이고 나머지 하나는 수신기(320) 용이다. UDP를 위해 요구되는 변화들 대부분은 해당 MESSAGE들을 조작하기 위한 코드를 복원하는데 관련된 것이다. 하지만, TCP의 구현은 3-way 핸드쉐이킹을 이용하기 때문에 더 많은 MESSAGE들을 요구한다. APP_TcpOpenConnectionWithPriority (오픈 TCP 소켓에 대한 요청)와 같은 퀄넷 API들 및 MSG_APP_FromTransListenResult(요청에 대한 응답)와 같은 MESSAGE들은 비디오 데이터 전송 이전에 적절하게 조작되어야 한다. 듀얼 터널링을 구현하기 위해, UDP 및 TCP MESSAGE들을 조작하기 위한 기능들은 퀄넷의 app_fdspvideo.cpp라 불리는 단일 어플리케이션 파일 내에 구현되어 있다.

파서(312)는 h264bitstream이라 불리는 오픈소스 라이버러리에 기초하여 개발되었다. 파서(312)는 퀄넷내에서 구현되었고 app_fdspvideo.cpp에 링크되어 있다. 스트리밍 이전에 파서(312)는 비디오 스트림을 파싱하고 그것의 신택스 정보(시작주소, 길이, 및 각 NAL유닛의 타입과 같은)를 먹스(313)에 대한 입력으로써 돌려준다. 스트리밍동안, 각 NAL유닛은 OEFMON의 퀄넷 컨넥터에 의해 RTP 패킷으로 인캡슐레이션된다. 동시에, 먹스(313)는 RTP패킷이 포함하는 NAL 유닛이 SPS, PPS, 또는 슬라이스 헤더인지를 판단하기 위해 저장된 신택스 정보를 이용한다. 만약, RTP패킷이 중요한 NAL 유닛을 포함한다면, 먹스(313)는 그것을 TCP 터널로 제공할 것이고, 그렇지 않다면 해당 패킷을 UDP 터널로 제공할 것이다.

수신기(320)가 TCP 패킷을 수신하면, 디먹스(323)는 수신된 패킷을 디스크 드라이버 상에서 "tcpdata.h264"라 불리는 파일 내에 저장할 것이다. 수신기(320)가 UDP패킷을 수신하면, 디먹스(323)는 먼저 UDP 패킷을 파싱하여 RTP 타임스탬프를 획득할 것이다. 만약, 타임스탬프가 출력 마감시한보다 크면, 이 UDP패킷은 지연된 것이기 때문에 디먹스(323)는 이 UDP패킷을 드롭시킬 것이다. 만약, 타임스탬프가 출력 마감시한보다 작으면 디먹스(323)는 UDP패킷을 파싱하여 RTP 시퀀스 넘버를 획득할 것이다. 이후, 디먹스(323)는 "tcpdata.h264"파일을 분석하여 RTP 시퀀스 넘버가 UDP 패킷의 RTP시퀀스 넘버보다 작은 TCP 패킷이 있는지 여부를 확인한다. 만약, 그렇다면 디먹스(323)는 이 TCP패킷을 현재 UDP 패킷과 결합시켜 디코더(324)로 전달할 것이다.

도 6은 이하에서 설명될 시나리오 1에 대한 순수 UDP를 이용한 비디오 스트리밍 동안의 큐 상태를 보여준다. X축은 본 발명에 따른 전송 장치(300)가 전송하고 있는 프레임을 나타낸다. "Num. of Pkts in Que"는 각 프레임을 전송할 때 네트워크 레이어 큐에 있는 패킷들의 개수를 나타낸다. "Num. of UDP to Be Sent"는 현재 프레임을 포함하는 UDP 패킷들의 개수를 나타낸다. 이 패킷들은 큐로 옮겨져서 전송되어야 하는 패킷들이다. 예컨대, 프레임 1의 경우, 큐는 빈 상태여야 하기 때문에 "Num. of Pkts in Que"는 0이다. 프레임 1은 177 UDP 패킷들을 포함하므로 "Num. of UDP to Be Sent"는 177이 된다. 임계치의 조건은 네트워크 조건 및 서브 스트림의 길이에 따라 달라진다. 만약, 네트워크가 혼잡하다면 "Num. of Pkts in Que"는 천천히 감소할 것이다. 예컨대, "Num. of Pkts in Que"는 프레임 18 대신에 프레임 30까지는 20이하로는 떨어지지 않을 것이다. 출력 마감시한 이전에 다음 서브 스트림의 TCP 데이터가 준비되도록 하기 위해, 전송장치(300)가 TCP 데이터를 전송할 더 많은 시간을 갖도록 상기 임계치는 20보다 큰 값으로 증가될 필요가 있다. 서브 스트림 길이가 증가하면, 다음 서브 스트림에 대해 요구되는 TCP 데이터가 증가되고, 이와 동시에 TCP 데이터를 전송하기 위해 사용할 수 있는 시간 또한 증가한다. 만약, 네트워크가 혼잡하지 않다면, TCP 데이터를 전송하기 위해 사용 가능한 충분한 시간이 있을 것이다. 반대로, 만약 네트워크가 혼잡하다면, "Num. of Pkts in Que"가 천천히 감소할 것이고, 비록 TCP 데이터를 전송하기 위해 사용 가능한 시간이 증가하더라도 TCP 데이터를 전송하기 위한 충분한 시간이 되지 않을 수도 있다. 이 상황에서 임계치는 증가되어야만 한다. 본 발명에서는 20패킷을 임계치로 결정하고, 10초를 서브 스트림 길이로 결정하기로 한다.

이하, 본 발명의 제1 실시예에 따른 부호화된 비디오 스트림 전송 장치 및 방법의 시뮬레이션 및 시뮬레이션 결과에 대해 설명한다. 본 발명의 실험을 위해 선택된 프라이머리 비디오는 "아프리카 고양이" 예고편에 포함된 원본 HD YUV 비디오의 1200 프레임들이다. YUV파일은 4Mbps의 평균 비트레이트를 갖고 프레임당 한 개의 슬라이스를 갖는 x264를 이용하여 부호화된 것이다. OEFMON을 이용하여, 54Mbps의 대역폭을 갖는 802.11g 애드 혹 네트워크가 셋업 되었고 비디오 스트리밍 성능을 평가하기 위해 3개의 네트워크 시나리오가 생성되었다. 도 7에 도시된 바와 같은 3개의 시나리오들에 대한 노드들의 위치는 집 환경(Home Environment)으로 모델링한다. 시나리오 1에서, 노드 쌍 1 및 2는 네트워크 상에서 프라이머리 비디오를 스트리밍한다. 동시에, 2개의 추가적인 노드쌍들은 백그라운드 트래픽으로써 도 7에서 CBR1 및 CBR2로 마크된 일정한 비트레이트(CBR) 데이터를 생성한다. 시나리오 2는 CBR3로 마크된 CBR 데이터를 한 개 더 추가한다. 시나리오 3은 시나리오 1의 네트워크 트래픽을 반복하고, 노드 쌍 7 및 8이 추가되고 클래식 히든 노드 배열(Classic hidden-node arrangement) 내에 위치된다. 도 7의 파라미터들은 아래와 같이 정의된다. Distt1=5m, Dist2=1m, Dist3=50m, CBR1=20Mbps, CBR2=20Mbos, CBR3=10Mbps(시나리오 3을 제외하고 CBR3=5Mbps이다). 이 값들에 기초하여 네트워크는 시나리오 2에 대해 만족된다. 스트리밍은 각 NAL 유닛을 패킷화함에 의해 수행된다. 만약, NAL 유닛의 크기가 최대전송유닛(MTU)크기 이하이면 하나의 RTP 패킷은 단지 하나의 NAL유닛을 포함한다. 만약, NAL유닛의 크기가 MTU크기보다 크면 NAL 유닛은 복수개의 RTP패킷들로 분할될 것이다. 비디오 스트리밍이 완료된 이후, 송수신된 비디오 파일들은 FFmpeg 및 PSNR 값을 이용하여 복호화된다. 이때, PSNR값은 Avisynth를 이용하여 2개의 YUV파일에 대해 계산된다. 유실된 프레임들 및 2개의 동일한 프레임들에 대한 PSNR 계산은 잘 규정되어 있지 않기 때문에, 본 발명은 유실된 프레임들에 대한 PSNR값은 0db를 사용하고, Avisynth에 의해 사용된 방법을 따르기로 한다. 그 방법에서 111db는 완벽한 PSNR을 나타낸다. PSNR 정보에 추가하여 이니셜 버퍼링 및 리버퍼링은 종단간 지연을 평가하기 위해 기록된다.

이 실험에 대한 주요 목적은 전통적인 순수 UDP 및 순수 TCP 스트리밍 방법에 비해 본 발명의 장점을 보여주는 것이다. 본 발명에 대해, 모든 중요한 데이터(SPS, PPS들, 및 슬라이스 헤더들)는 TCP를 통해 먼저 전송될 것이고 이후 나머지 데이터들이 UDP로 전송될 것이다. 본 발명에서 중요한 데이터를 전송하기 위해 소요되는 시간은 이니셜 버퍼링으로 처리된다. 순수 TCP 방법에 있어서, 이니셜 버퍼링과 리버퍼링을 시뮬레이션 하기 위해 버퍼가 추가된다. 본 발명과 순수 TCP를 비교하기 위해, 순수 TCP의 버퍼 크기를 적절하게 조절하여 2개의 방법이 동일한 이니셜 버퍼링 시간을 갖도록 하였다.

모든 시나리오들에 대한 PSNR 비교가 도 8에 도시되어 있다. 도 8은 프레임 크기를 포함한다. 하나의 그래프로 나타내기에 1200개의 프레임은 너무 많기 때문에, PSNR, 패킷유실, 및 프레임 크기는 모두 1초 상에서 평균되었다(이는 30프레임으로 환산된다). 추가적으로, 순수 TCP 방법의 경우 항상 PSNR은 111db이고 패킷유실율은 0이기 때문에 순수 TCP의 PSNR 및 패킷유실은 생략하였다.

도 8a에 도시된 시나리오 1에 대해, 예측된 바와 같이 순수 UDP에 대한 PSNR은 본 발명보다 나빴다. 순수 UDP는 평균 93db에 도달하지만 본 발명은 102db에 도달한다. 도 8b에 도시된 시나리오 2에 대해, 순수 UDP방법은 평균 PSNR이 51db로써 83db인 본 발명보다 훨씬 낮다. 도 8c에 도시된 시나리오 3에 대해, 노드 쌍 7 및 8은 시나리오 1 및 2와 비교할 때 PSNR 및 지연의 저하에 대해 숨겨진 노드 이펙트를 유발시킨다. 순수 UDP의 평균 PRNS은 52db이지만, 이와 반대로 본 발명은 평균 PSNR은 76db이고 그것은 여전이 순수 UDP보다 좋다.

도 9는 3개의 모든 시나리오에 대한 패킷 유실율을 보여준다. 도 8 및 도 9를 함께 고려할 때, 패킷유실과 PSNR간에는 직접적인 상호관계가 있다. 이들 그래프에서, 각 PSNR 강등은 일부 패킷 손실에 의해 발생되었다. 예를 들면 전체 시간을 평균한 프로세스에 기인하여 관찰하기는 어려울 지라도 도 8a에서 순수 UDP에 대해 5초에서 0.2%의 패킷유실율이 있고, 그것은 PSNR을 111db에서 76db까지 감소시킨다. 도 9b 및 도 9c에서 알 수 있는 바와 같이, 패킷 유실이 85%이상인 경우 PSNR값은 프레임이 유실되었다는 것을 나타내는 0db이다. 시나리오 1에서, 순수 UDP에 대해 전체 1200개의 프레임들 중에서 32개의 프레임들이 유실되었다. 반대로, 본 발명을 이용하면 모든 1200개의 프레임들에 대한 슬라이스 헤더들은 모두 수신되었고, 따라서 모든 1200개의 프레임들이 복구 및 복호화될 수 있다. 시나리오 2에서, 순수 UDP를 이용하면 148개의 프레임들이 유실되었지만 본 발명의 경우 유실된 프레임들은 없었다. 시나리오 3에서, 순수 UDP의 경우 103개의 프레임들이 유실되었다. 또 다시 본 발명은 TCP를 이용하여 슬라이스 헤더들이 우선처리되었기 때문에 유실된 프레임은 없었다.

위에서 설명했듯이, 슬라이스 헤더의 존재는 디코더(324)가 프레임을 복구하는데 있어서 중요하다. 일단 슬라이스 헤더가 적절하게 수신되면, 디코더(324)는 비록 나머지 데이터들이 유실되더라도 유실된 매크로블록들을 숨기기 위한 다양한 EC기법을 이용할 수 있다. 예를 들면, 도 10은 복호화된 프레임 134를 보여준다. 프레임 134는 P프레임이고 슬라이스 헤더 및 슬라이스의 일부를 포함하는 하나의 패킷으로부터 복구되었다. 좌측상단 워터마크는 프레임 번호 134를 보여주는 것으로서, 이는 패킷으로부터 획득된 정보이다. 우측하단 워터마크는 프레임 번호 132를 보여주는 것으로서, 이는 EC를 이용하는 FFmpeg가 현재 프레임 134를 복원하기 위해 이전 프레임 132로부터 복사한 정보이다.

아래의 표 1은 3개의 모든 시나리오들에 대한 버퍼링 조건을 보여준다.

순수 TCP 및 본 발명 모두 동일한 이니셜 버퍼링 시간을 갖고 네트워크 포화에 대한 반응으로써 2초부터 2.56초까지 증가시킨다. 하지만, 순수 TCP는 빈번한 리버퍼링을 발생시키고, 40초의 비디오 스트리밍동안 리버퍼링이 6~19번 발생하였으며, 각각은 0.95~1.46초 동안 지속되었다. 빈번한 리버퍼링은 사용자의 경험 변화를 유발하는 중요한 팩터이다. 순수 TCP가 완벽한 영상품질을 제공하더라도 리버퍼링의 높은 빈도는 매우 짜증스러운 것이 될 수 있다. 반대로, 본 발명은 어떠한 리버퍼링을 가지지 않는다. 이것은 순수 UDP 및 순수 TCP가 각각 영상 품질 및 지연 측면에서 허용될 수 없는 경향이 있기 때문에, 본 발명이 혼잡한 네트워크에서 매우 효과적이라는 것을 다시 한번 보여준다.

표 2는 본 발명에 있어서 서브 스트림들에 대한 준비시간 및 출력 마감시한을 보여준다.

서브 스트림 1의 준비시간은 표 1에 도시된 이니셜 버퍼링 시간이므로 표 2에서 도시하지는 않았다. 각 서브 스트림에 대한 출력 마감시한은 그것의 길이, 예컨대 10초에 의해 결정된다. 준비시간이 출력 마감시한보다 작은 한, 리버퍼링은 요구되지 않는다. 네트워크 혼잡도가 증가할수록 준비시간 또한 증가된다. 하지만, 모든 서브 스트림들에 대한 준비시간은 여전히 그들의 출력 마감시한보다 빠르다. 따라서, 표 1에서 나타낸 바와 같이 리버퍼링이 요구되지 않는다.

위에서 언급했듯이, 3개의 모든 시나리오들에 대한 서브 스트림들의 준비시간은 출력 마감시한보다 빠르다. 예컨대, 시나리오 2에서, 4번째 서브 스트림의 준비시간은 11,47초로써 그것은 출력 마감시한인 30초보다 18.53초 빠르다. 이것은 더 많은 데이터가 우선처리되어 TCP 터널을 통해 전송될 수 있도록 네트워크 조건을 조절할 수 있다는 것을 의미한다. 만약 본 발명이 TCP를 통해 데이터를 추가적으로 전송할 수 있다면, 영상품질은 훨씬 더 개선될 것이다.

슬랙타임(Slack Time, 예컨대, 서브 스트림 준비시간과 출력 마감시한간의 차이)을 이용하고 영상품질을 더 개선하기 위해, 본 발명의 제2 실시예에 따른 부호화된 비디오 스트림 전송 장치 및 방법이 제안된다. 도 11은 본 발명의 제2 실시예에 따른 부호화된 비디오 스트림 전송 장치를 보여주는 블록도이다. 도 11에 도시된 바와 같이, 부호화된 비디오 스트림 전송 장치(1100)은 PBP(Percentage Based Prioritization) 모듈(316)이라 불리는 새로운 모듈을 추가함으로써 SPS, PPS, 및 슬라이스 헤더 외에 더 많은 비트 스트림 신택스 엘리먼트들을 우선처리한다.

PBP 모듈(316)은 PERCENT라 불리는 입력 파라미터에 따라 신택스 엘리먼트를 선택한다. 예컨대, 만약 PERCENT가 10%인 것으로 규정되면, 10개의 패킷들 중 11개의 패킷이 TCP를 통해 전송될 수 있다. PBP 모듈(316)은 원한다면 어떠한 신택스 엘리먼트도 우선처리할 수 있기 때문에 부호화된 비디오 스트림 전송 장치(1100)의 가변성을 확장시킨다.

본 발명의 일 실시예에 있어서, PBP 모듈(316)은 100kbyte보다 더 큰 프레임들을 우선처리하기 위해 이용된다. 이 거대한 프레임들은 일반적으로 I프레임이고 따라서 B프레임들 보다 더 중요하다.

본 발명의 제2 실시예에 따른 부호화된 비디오 스트림 전송 장치 및 방법을 위에서 기재된 네트워크 시나리오 2를 이용하여 시뮬레이션하였다. 시각적 향상을 보여주기 위해 입력 파라미터 PRECENT는 2개의 다른 값으로 설정되었다. 첫 번째 경우에 있어서, PERCENT는 50%로 설정되었고, 따라서 부호화된 비디오 스트림 전송 장치(1100)는 SPS, PPS, 및 슬라이스 헤더들에 추가하여 100kbyte 이상의 프레임 패킷들 중 50%를 TCP를 통해 전송한다. 두 번째 경우에 있어서, TCP를 통해 더 많은 데이터가 전송될 수 있도록 PERCENT는 90%로 설정된다.

도 12는 PBP 모듈(316)을 포함하지 않는 비디오 스트림 전송 장치와, 50% PBP를 갖는 PBP 모듈(316)을 포함하는 비디오 스트림 전송 장치와, 90% PBP를 갖는 PBP 모듈(316)을 포함하는 비디오 스트림 전송 장치간의 PSNR 비교를 보여준다. PBP 퍼센테이지(Percentage)가 높을수록 PSNR이 더 좋아진다는 것을 알 수 있다. PBP 모듈(316)을 포함하지 않는 비디오 스트림 전송 장치의 평균 PSNR은 83.08db였고, 50%의 PBP를 갖는 PBP 모듈(316)을 포함하는 비디오 스트림 전송 장치의 평균 PSNR은 90.99db였다. 특히, 90%의 PBP를 갖는 PBP 모듈(316))을 포함하는 비디오 스트림 전송 장치의 평균 PSNR은 완벽한 PSNR인 111db에 도달했다. 이것은 PBP 모듈(316)을 포함하는 비디오 스트림 전송 장치가 영상품질을 향상시키는데 있어서 효과적이라는 것을 나타낸다. 이는 SPS, PPS, 및 슬라이스 헤더에 추가하여 더 많은 데이터가 수신될 것이 보장되기 때문이다.

도 13은 프레임 1187에 대한 영상 비교를 보여준다. 도 13(a)는 순수 UDP를 이용한 경우의 프레임 1187을 보여주고, 도 13(b)는 PBP 모듈(316)을 포함하지 않는 본 발명의 비디오 스트림 전송 장치를 이용한 경우의 프레임 1187을 보여주며, 도 13(c)는 50%의 PBP를 갖는 PBP 모듈(316)을 포함하는 비디오 스트림 전송 장치를 이용한 경우의 프레임 1187을 보여주고, 도 13(d)는 90%의 PBP를 갖는 PBP 모듈(316)을 포함하는 비디오 스트림 전송 장치를 이용한 경우의 프레임 1187을 보여준다. 명확하게, 본 발명이 순수 UDP 보다 더 나은 성능을 갖는다는 것을 알 수 있다. 또한, 영상품질은 PBP 퍼센테이지가 증가할수록 점진적으로 향상된다는 것을 알 수 있다.

표 3은 PBP 모듈(316)을 포함하지 않는 비디오 스트림 전송 장치, 50%의 PBP를 갖는 PBP 모듈(316)을 포함하는 비디오 스트림 전송 장치, 및 90%의 PBP를 갖는 PBP 모듈(316)을 포함하는 비디오 스트림 전송 장치에 대한 서브 스트림들의 준비시간을 보여준다.

각 서브 스트림에 대한 준비시간은 PBP 퍼센테이지가 증가할수록 증가한다는 것을 알 수 있다. 하지만, 서브 스트림의 준비시간은 여전히 출력 마감시한보다 빠르고, 따라서 리버퍼링은 요구되지 않는다.

90%의 PBP를 갖는 PBP 모듈(316)을 포함하는 비디오 스트림 전송 장치는 완벽한 PSNR을 달성하고 리버퍼링이 없다. 이와 비교하여, 순수 TCP 또한 완벽한 PSNR을 달성할 수 있지만 17번의 리버퍼링이 발생한다. 더욱이, 순수 UDP와 비교하면, 90%의 PBP를 갖는 PBP 모듈(316)을 포함하는 비디오 스트림 전송 장치는 60db더 높은 PSNR을 달성하게 된다. 90%의 PBP를 갖는 PBP 모듈(316)을 포함하는 비디오 스트림 전송 장치에 의해 달성되는 결과는 순수 TCP 및 순수 UDP보다 확실히 낫고, 따라서 본 발명은 명확하게 순수 TCP 및 순수 UDP 방법에 비해 장점을 갖는다.

본 발명이 속하는 기술분야의 당업자는 상술한 본 발명이 그 기술적 사상이나 필수적 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있을 것이다.

그러므로, 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로 이해해야만 한다. 본 발명의 범위는 상기 상세한 설명보다는 후술하는 특허청구범위에 의하여 나타내어지며, 특허청구범위의 의미 및 범위 그리고 그 등가 개념으로부터 도출되는 모든 변경 또는 변형된 형태가 본 발명의 범위에 포함되는 것으로 해석되어야 한다.

300, 1100: 부호화된 비디오 스트림 전송 장치 310: 전송기
311: 엔코더 312: 파서
313: 먹스 314: 제1 패킷 생성부
315: 제2 패킷 생성부 316: PBP 모듈
320: 수신기 321: 제1 패킷 수신부
322: 제2 패킷 수신부 323: 디먹스
324: 디코더 325: 저장부

Claims (20)

1. 미리 정해진 압축 규격을 이용하여 비디오 스트림을 부호화하는 엔코더;
   상기 부호화된 비디오 스트림을 복수개의 서브 스트림으로 구분하고, 각 서브 스트림을 파싱하는 파서;
   파싱된 서브 스트림으로부터 SPS(Sequence Parameter Set), PPS(Picture Parameter Set), 또는 슬라이스 헤더(Slice Header)를 갖는 NAL(Network Adaptation Layer) 유닛인 제1 데이터와 슬라이스 데이터(Slice Data)를 갖는 NAL 유닛인 제2 데이터로 구분하는 먹스;
   상기 서브 스트림 별로 상기 제1 데이터를 이용하여 TCP(Transmission Control Protocol) 패킷을 생성하고, 생성된 TCP 패킷을 TCP 터널을 통해 전송하는 제1 패킷 생성부; 및
   상기 서브 스트림 별로 상기 제2 데이터를 이용하여 UDP(User Datagram Protocol) 패킷을 생성하고, 생성된 UDP 패킷을 UDP 터널을 통해 전송하는 제2 패킷 생성부를 포함하는 것을 특징으로 하는 부호화된 비디오 스트림 전송 장치.
2. 제1항에 있어서,
   상기 미리 정해진 압축 규격은, H.264 또는 H.265이고, 상기 부호화된 비디오 스트림은 데이터 분할(Data Partitioning: DP) 프로파일(Profile)을 포함하지 않는 것을 특징으로 하는 부호화된 비디오 스트림 전송 장치.
3. 제1항에 있어서,
   상기 TCP 패킷을 전송하기 위한 TCP 세션(Session) 및 상기 UDP 패킷을 전송하기 위한 UDP 세션은 상기 비디오 스트림의 전송 동안 액티브 상태로 유지되는 것을 특징으로 하는 부호화된 비디오 스트림 전송 장치.
4. 제1항에 있어서,
   상기 제1 패킷 생성부는, 상기 제2 패킷 생성부가 n번째 서브 스트림에 대한 UDP 패킷을 전송할 때 n+1번째 서브 스트림에 대한 TCP 패킷을 동시에 전송하는 것을 특징으로 하는 부호화된 비디오 스트림 전송 장치.
5. 제4항에 있어서,
   상기 제1 패킷 생성부는, 큐에 저장되어 있는 UDP 패킷의 개수가 미리 정해진 임계치 보다 작은 경우, 상기 제2 패킷 생성부가 n번째 서브 스트림에 대한 UDP 패킷을 전송할 때 n+1번째 서브 스트림에 대한 TCP 패킷을 동시에 전송하는 것을 특징으로 하는 부호화된 비디오 스트림 전송 장치
6. 제1항에 있어서,
   미리 정해진 퍼센트(Percent)에 따라 상기 제2 데이터로부터 상기 TCP 터널을 통해 전송될 우선 처리 데이터를 선택하는 PBP(Percentage Based Prioritization) 모듈을 더 포함하는 것을 특징으로 하는 부호화된 비디오 스트림 전송 장치.
7. 제6항에 있어서,
   상기 우선 처리 데이터는 I-frame인 것을 특징으로 하는 부호화된 비디오 스트림 전송 장치.
8. 제1항에 있어서,
   상기 TCP 터널을 통해 상기 TCP 패킷을 수신하는 제1 패킷 수신부;
   상기 UDP 터널을 통해 상기 UDP 패킷을 수신하는 제2 패킷 수신부;
   상기 수신된 UDP 패킷을 상기 수신된 TCP 패킷과 결합하는 디먹스; 및
   상기 결합된 TCP 패킷 및 UDP 패킷을 복호화하여 상기 비디오 스트림을 복원하는 디코더를 더 포함하는 것을 특징으로 하는 부호화된 비디오 스트림 전송 장치.
9. 제8항에 있어서,
   상기 디먹스는, 상기 수신된 UDP 패킷 중 미리 정해진 출력 마감시한(Playout Deadline)보다 큰 RTP(Real-time Transport Protocol) 스탬프를 갖는 UDP 패킷을 드롭(Drop)시키는 것을 특징으로 하는 부호화된 비디오 스트림 전송 장치.
10. 제8항에 있어서,
    상기 디먹스는, 상기 수신된 TCP 패킷들 중 상기 수신된 UDP 패킷의 RTP 시퀀스 넘버보다 작은 RTP 시퀀스 넘버를 갖는 TCP 패킷을 상기 수신된 UDP 패킷과 결합시키는 것을 특징으로 하는 부호화된 비디오 스트림 전송 장치.
11. 미리 정해진 압축 규격을 이용하여 비디오 스트림을 부호화하는 단계;
    상기 부호화된 비디오 스트림을 복수개의 서브 스트림으로 구분하는 단계;
    상기 서브 스트림으로부터 SPS(Sequence Parameter Set), PPS(Picture Parameter Set), 또는 슬라이스 헤더(Slice Header)를 갖는 NAL(Network Adaptation Layer) 유닛인 제1 데이터와 슬라이스 데이터(Slice Data)를 갖는 NAL 유닛인 제2 데이터로 구분하는 단계;
    상기 제1 데이터를 이용하여 TCP(Transmission Control Protocol) 패킷을 생성하고, 상기 제2 데이터를 이용하여 UDP(User Datagram Protocol) 패킷을 생성하는 단계; 및
    상기 생성된 TCP 패킷을 TCP 터널을 통해 전송하고, 상기 생성된 UDP 패킷을 UDP 터널을 통해 전송하는 단계를 포함하는 것을 특징으로 하는 부호화된 비디오 스트림 전송 방법.
12. 제11항에 있어서,
    상기 미리 정해진 압축 규격은, H.264 또는 H.265이고, 상기 부호화된 비디오 스트림은 데이터 분할(Data Partitioning: DP) 프로파일(Profile)을 포함하지 않는 것을 특징으로 하는 부호화된 비디오 스트림 전송 방법.
13. 제11항에 있어서,
    상기 TCP 패킷을 전송하기 위한 TCP 세션 및 상기 UDP 패킷을 전송하기 위한 UDP 세션은 상기 비디오 스트림의 전송 동안 액티브 상태로 유지되는 것을 특징으로 하는 부호화된 비디오 스트림 전송 방법.
14. 제11항에 있어서,
    상기 전송하는 단계에서, n번째 서브 스트림에 대한 UDP 패킷과 n+1번째 서브 스트림에 대한 TCP 패킷을 동시에 전송하는 것을 특징으로 하는 부호화된 비디오 스트림 전송 방법.
15. 제14항에 있어서,
    상기 전송하는 단계에서, 큐에 저장되어 있는 UDP 패킷의 개수가 미리 정해진 임계치 보다 작은 경우, 상기 n번째 서브 스트림에 대한 UDP 패킷과 상기 n+1번째 서브 스트림에 대한 TCP 패킷을 동시에 전송하는 것을 특징으로 하는 부호화된 비디오 스트림 전송 방법.
16. 제11항에 있어서,
    미리 정해진 퍼센트에 따라 상기 제2 데이터로부터 상기 TCP 터널을 통해 전송될 우선 처리 데이터를 선택하는 단계를 더 포함하고,
    상기 우선 처리 데이터는, 상기 TCP 패킷으로 패킷화되어 상기 TCP 터널을 통해 전송되는 것을 특징으로 하는 부호화된 비디오 스트림 전송 방법.
17. 제16항에 있어서,
    상기 우선 처리 데이터는 I-frame인 것을 특징으로 하는 부호화된 비디오 스트림 전송 방법.
18. 제11항에 있어서,
    상기 TCP 터널을 통해 상기 TCP 패킷을 수신하고, 상기 UDP 터널을 통해 상기 UDP 패킷을 수신하는 단계;
    상기 수신된 UDP 패킷을 상기 수신된 TCP 패킷과 결합하는 단계; 및
    상기 결합된 TCP 패킷 및 UDP 패킷을 복호화하여 상기 비디오 스트림을 복원하는 단계를 더 포함하는 것을 특징으로 하는 부호화된 비디오 스트림 전송 방법.
19. 제18항에 있어서,
    상기 수신된 UDP 패킷 중 미리 정해진 출력 마감시한보다 큰 RTP 스탬프를 갖는 UDP 패킷은 드롭되는 것을 특징으로 하는 부호화된 비디오 스트림 전송 방법.
20. 제18항에 있어서,
    상기 결합하는 단계에서,
    상기 수신된 TCP 패킷들 중 상기 수신된 UDP 패킷의 RTP 시퀀스 넘버보다 작은 RTP 시퀀스 넘버를 갖는 TCP 패킷을 상기 수신된 UDP 패킷과 결합하는 것을 특징으로 하는 부호화된 비디오 스트림 전송 방법.

Images