KR20060011426A

KR20060011426A - Ａｖ데이터 수신시 버퍼량을 컨텐츠 속성에 따라탄력적으로 조절하는 방법 및 장치

Info

Publication number: KR20060011426A
Application number: KR20040060270A
Authority: KR
Inventors: 최준회; 안철홍; 유호정
Original assignee: 삼성전자주식회사
Priority date: 2004-07-30
Filing date: 2004-07-30
Publication date: 2006-02-03
Also published as: CN100426865C; JP2006050604A; US20060023729A1; CN1728829A; KR100678891B1

Abstract

본 발명은 AV데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 방법 및 장치에 관한 것이다.

본 발명의 일 실시예에 따른 AV데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 방법은 수신한 패킷들에서 추출된 프레임 정보에 따라 저장될 프레임의 개수를 결정하는 단계, 상기 결정된 프레임의 개수 내에서 상기 패킷들을 해당 프레임별로 연결하여 저장하는 단계 및 상기 해당 프레임별로 연결하여 저장된 패킷들을 디코딩부로 출력하는 단계를 포함한다.

스트리밍, 버퍼 제어, 프레임, 비디오 압축, 컨텐츠 속성

Description

ＡＶ데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 방법 및 장치{Method and apparatus for contents' attribute adaptive buffer control in audio-video data receiving}

도 1은 기존의 스트리밍 클라이언트의 동작을 보여주는 블록도이다.

도 2는 본 발명의 일 실시예에 따른 프레임의 데이터 크기에 따른 버퍼 저장을 보여주는 블록도이다.

도 3은 비디오 스트림의 구조를 개략적으로 보여주는 예시도이다.

도 4는 본 발명의 일 실시예에 따른 스트리밍 클라이언트의 구성을 보여주는 블록도이다.

도 5는 본 발명의 일 실시예에 따른 프레임 생성부에서 관리하는 패킷과 프레임의 구조를 보여주는 블록도이다.

도 6a와 6b는 본 발명의 일 실시예에 따른 패킷 수신에서 프레임 출력에 이르기까지의 프레임 생성부의 변화를 보여주는 블록도이다.

도 7은 본 발명의 일 실시예에 따른 프레임의 속성이 변경될 경우 프레임 생성부와 프레임 생성 정보 설정부의 변화를 보여주는 블록도이다.

도 8은 본 발명의 일 실시예에 따른 프레임 생성부에 저장되는 프레임들의 양을 보여주는 그래프이다.

도 9는 본 발명의 일 실시예에 따른 스트리밍 클라이언트가 데이터를 프레임 단위로 저장하여 출력하는 과정을 보여주는 순서도이다.

<도면의 주요 부분에 대한 부호의 설명>

100 : 스트리밍 클라이언트 110 : 지연 제어부

120 : 패킷 수신부 130 : 프레임 생성부

135 : 프레임 생성 정보 설정부

지난 수십년간 영상 데이터와 음향 데이터는 아날로그 데이터 형식으로 텔레비전에 전송되어 왔다. 그러나 디지털 신호의 다양한 장점으로 인하여 점차로 많은 영상 정보들이 디지털 정보로 표현되고 기록되고 있다. 최근에는 디지털 영상과 오디오는 위성방송이나 지상파방송 또는 케이블 방송을 통해 전송되고 있으며, 사용자는 셋톱 박스와 디지털 텔레비전을 이용하여 디지털 영상과 오디오를 시청할 수 있게 되었다.

한편, 최근에는 인터넷 기술의 발전과 더불어 VOD(Video On Demand) 서비스가 증가하고 있다. 인터넷 영화관 또는 음악 감상실이 이에 해당할 수 있는데, 사용자가 컴퓨터 상에서 요구하는 영화를 서비스업자는 인터넷을 통해 실시간 데이터 로 전송하고 사용자는 전송받은 영화를 컴퓨터 상에서 감상할 수 있다. 디지털 텔레비전이나 VOD 서비스는 모두 사용자가 인터넷 혹은 무선으로 전송받은 실시간 데이터를 통해 영상이나 음악을 감상한다는 공통점을 갖는다.

상기 영상 또는 음향 데이터는 아날로그 데이터를 디지털로 변환한 것이다. 상기 디지털 데이터는 그 양이 크기 때문에 정보의 손실을 적게 하며 압축하는 기술에 대한 연구가 꾸준히 제기되었다. 정지 영상에 있어서는 JPEG(Joint Photographic Experts Group)이 있고, 영상 부호화를 위해 H.261, H.263등이 있으며, MPEG(Motion Picture Expert Group)에서는 MPEG1, MPEG2와 MPEG4에 대한 표준을 제시하고 있으며, 이외에도, MPEG21도 준비중이다.

영상 또는 음향 데이터를 사용하는 방법에는 크게 다운로드(download) 방식과 스트리밍(streaming) 방식이 있다. 다운로드는 영상 또는 음향 데이터가 포함된 파일을 로컬 또는 개인 저장장치에 저장하여 사용하는 것을 의미한다. 스트리밍은 파일을 받지 않고 영상 또는 음향 데이터를 실시간으로 출력하는 것을 의미한다. 상기 스트리밍은 이론적으로는 실시간 출력이지만, 네트워크 상황과 파일의 속성상 일정부분이 미리 로컬 영역(저장장치 또는 디지털 장치)에 저장될 것을 요구한다. 따라서 스트리밍 클라이언트는 상기 데이터를 수신하여 버퍼와 같은 임시 저장장치에 저장한 후, 저장한 데이터를 출력하는 방식을 채택하고 있다. 상기 스트리밍 클라이언트가 영상 또는 음향 데이터를 요청한 시간부터, 버퍼에 저장한 후 저장한 데이터를 출력하기까지 걸리는 시간을 초기 지연 시간이라 한다. 또한 상기 버퍼에 일정 시간동안 출력할 데이터를 저장하는데, 상기 일정 시간을 지연 시간이라고 한 다. 그런데 기존의 스트리밍 클라이언트는 상기 지연 시간을 산술적으로 비트의 수 또는 버퍼의 일정 부분을 채우는 시기까지로 정하며, 실제 수신하는 데이터의 속성에 탄력적으로 적응하지 못한다는 문제점이 있다.

본 발명에서는 수신한 데이터의 속성에 따라 상기 버퍼에 저장할 데이터의 양을 탄력적으로 조절하고자 한다.

본 발명의 기술적 과제는 영상 또는 음향 데이터를 수신시 버퍼에 저장되는 데이터의 양을 탄력적으로 조절하는데 있다.

본 발명의 다른 기술적 과제는 영상 또는 음향 데이터의 속성에 따라 버퍼에 저장되는 데이터의 양을 조절하여, 영상 또는 음향 데이터를 스트리밍함에 있어서 발생하는 지연을 줄이고자 하는데 있다.

본 발명의 목적들은 이상에서 언급한 목적들로 제한되지 않으며, 언급되지 않은 또 다른 목적들은 아래의 기재로부터 당업자에게 명확하게 이해될 수 있을 것이다.

본 발명의 일 실시예에 따른 AV데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 장치는 수신한 패킷들을 해당 프레임별로 연결하여 저장하는 프레임 생성부, 상기 패킷에서 추출된 프레임 정보에 따라 상기 프레임 생성부에 저장될 프레임의 개수를 결정하는 프레임 생성 정보 설정부 및 상기 프레임 생성부에 해당 프레임별로 연결하여 저장된 패킷들을 디코딩부로 출력하는 프레임 출력부를 포함한다.

본 명세서에서 사용하는 용어를 정리하면 다음과 같다.

- 프레임 (frame)

화상 신호의 공간 정보를 이루는 라인(line)들의 집합이다. 한 프레임은 하나의 정지화면을 표시할 수 있고, 이들 프레임들의 결합을 통해 동영상을 구현할 수 있다. MPEG에서는 독자적으로 하나의 화면 정보를 포함하는 I 프레임과, 다른 프레임의 정보를 참조하는 B 프레임과 P 프레임이 존재한다. 이외에도, 다른 동영상 압축에 있어서도 프레임을 기반으로 수행한다. 이하 본 명세서에서 프레임이란 하나의 정지 화면을 압축한 데이터 블록으로, 이는 독자적인 정지 화면일 수 있고, 다른 프레임의 정보를 참조할 수도 있다.

- 초기 지연 시간

스트리밍 클라이언트가 스트리밍 서버에 데이터를 요청한 후, 스트리밍 서버가 데이터를 전송하여 이를 스트리밍 클라이언트가 자신의 임시 저장장치에 상기 데이터를 저장하여 일정양의 데이터가 저장되면 저장된 데이터를 출력한다. 초기 지연 시간은 상기 서버에 데이터를 요청한 후 데이터를 출력하는데 걸리는 시간을 의미한다. 버퍼에 저장할 데이터의 양이 크면 초기 지연 시간은 길어지지만, 초기에 출력할 데이터의 양이 많아지므로 끊김없이 출력할 수 있다.

- 지연 시간

스트리밍은 인터넷 혹은 무선등 네트워크를 이용하여 영상 또는 음향 데이터를 전송하는 방식이므로 네트워크의 속도에 좌우된다. 따라서 끊김없이 데이터를 출력하기 위해서는 일정양의 데이터를 스트리밍 클라이언트가 저장하고 있어야 한다. 이 지연 시간은 네트워크의 문제로 데이터를 수신하지 않은 상태에서 데이터를 출력할 수 있는 시간을 의미하며, 버퍼에 저장된 데이터의 양을 출력하는데 소요되는 시간을 의미할 수 있다. 지연 시간을 크게 잡을 경우, 버퍼에 저장해야 할 데이터의 양은 늘어나지만, 끊김없이 데이터를 출력할 수 있다.

- 스트리밍 클라이언트

서버에서 스트리밍 방식으로 전송하는 영상 또는 음향 데이터를 수신하여 재생하는 장치를 통칭한다. 컴퓨터, 휴대폰, 디지털 티비, PDA 등이 이에 속할 수 있다. 스트리밍 클라이언트는 스트리밍 데이터를 일정 시간 혹은 일정양을 저장하기 위한 저장공간(버퍼)를 가져야 하며, 수신한 데이터가 여러 영상 또는 음향 데이터의 표준에 따라 인코딩 된 경우 이를 디코딩하기 위한 기능을 제공한다.

- 멀티미디어 컨텐츠 수신 장치

멀티미디어 컨텐츠를 재생하는 장치는 다양하다. 컴퓨터, 디지털 TV와 같은 가전 제품을 비롯, 노트북, PDA, 휴대폰, 휴대용 TV등이 존재할 수 있다. 또한 디지털 셋톱박스 역시 멀티미디어 컨텐츠를 수신하여 출력하는 장치이므로 본 명세서에서 언급하는 장치의 일 실시예로 가능하다.

도 1은 기존의 스트리밍 클라이언트의 동작을 보여주는 블록도이다. 도 1은 고화질의 프레임들(210,220)과 저화질의 프레임들(310, 320)을 수신함에 있어서의 차이를 보여준다. 기존의 스트리밍 클라이언트(100)는 서버로부터 데이터를 수신하는 패킷 수신부(20)와 상기 수신된 패킷을 임시 저장하는 버퍼(30), 그리고 상기 버퍼에 저장된 양을 조절하기 위한 버퍼 제어부(10)와 상기 패킷에 저장된 영상 또는 음향 데이터를 출력하기 위해 디코딩하는 디코더(150)로 구성된다.

상기 버퍼(30)는 전술한 초기 지연 시간 또는 지연 시간을 위해 일정양의 데이터를 저장하는 공간이다. 그런데 이 버퍼에 저장될 데이터의 상한선은 수신되는 패킷의 크기로 정하고 있다. 예를 들어 2Mbyte 혹은 3Mbyte 등과 같이 수신 패킷의 데이터 양이 일정량을 만족하는지 여부로 판단한다.

이 경우, 고화질 데이터와 저화질 데이터에서는 상기 버퍼의 용량이 곧 지연 시간을 의미하지는 않는다. 예를 들어서 MPEG-2의 경우 HD와 SD 두 단계로 데이터를 생성할 수 있다. HD의 경우 고화질이므로 하나의 프레임을 표현하기 위한 정보의 양, 즉 데이터 크기가 크다. SD의 경우 저화질이므로 하나의 프레임을 표현하기 위한 정보의 양이 적다. 즉 HD의 경우 1Mbyte로 표현할 수 있는 시간이 30초라 가정할 때, SD의 경우 1Mbyte로 표현할 수 있는 시간은 30초보다 긴 50초가 될 수 있다.

그러나 도 1에서와 같이, HD 급의 데이터를 처리하는데 필요한 지연시간만을 고려하여 버퍼의 크기만을 설정한 경우, 예를 들어 HD급 데이터를 대상으로 지연시간 1분으로 한 경우 2Mbyte가 버퍼의 크기로 설정될 수 있다. 이 버퍼를 채우기 위해 SD급 데이터는 2Mbyte인 1분 40초 분량의 데이터가 필요하다. 그러나 상기 스트리밍 클라이언트는 1분을 지연시간으로 가정하여 버퍼를 설정하였으므로 SD급 데이터를 수신할 경우 40초 분량의 데이터를 더 필요로 하게 되며, SD급 데이터를 통해 빨리 출력하고자 하는 사용자의 요구를 충족시키지 못할 수 있다. 도 1에서 알 수 있듯이, 스트리밍 클라이언트의 버퍼를 채우기 위해 고화질의 데이터는 N개의 프레임(210~220)를 필요로 하지만, 저화질의 데이터는 M개의 프레임(310~320)을 필요로 한다(N<M). 기존의 기술은 컨텐츠의 속성을 고려하지 않고 단지 데이터의 크기를 버퍼 제어에 이용하였다.

본 명세서에서는 상기의 제약을 극복하기 위하여 수신되는 컨텐츠의 속성에 따라 버퍼에 저장될 데이터의 양을 조절하여, 스트리밍 클라이언트가 지연 시간을 적절히 조절할 수 있도록 한다.

컨텐츠의 속성에는 화질이 존재한다. 고화질의 경우 하나의 프레임을 나타내기 위한 데이터 크기가 크지만, 저화질의 경우에는 하나의 프레임을 나타내는데 필요한 데이터의 크기가 한정되어있다. 또한 컨텐츠의 속성에는 초당 프레임 수가 있다. 초당 30 프레임으로 생성된 데이터의 경우, 지연 시간이 30초라면 총 900 프레임의 데이터를 버퍼에 저장하여야 한다. 그러나 초당 25 프레임으로 생성된 데이터의 경우, 지연 시간이 30초라 해도 750 프레임의 데이터를 버퍼에 저장하면 된다.

상기 속성외에 또 살펴볼 수 있는 것은 컨텐츠가 끊김 없는 전송을 중요시하는가 혹은 빠른 재생을 중요시하는가를 적용하여 버퍼에 데이터를 저장하는 방식이다. 컨텐츠가 끊김없는 전송을 중요시한다면, 버퍼에 많은 프레임을 저장하여야 한다. 그러나 빠른 재생을 중요시한다면, 지연 시간을 짧게 설정하여 버퍼에 필요한 만큼의 프레임을 저장하여 버퍼링에 많은 시간이 소요되지 않도록 하는 것이 필요하다.

화질은 동일한 방식으로 비디오를 코딩시 얼마나 많은 데이터가 해당 프레임을 생성하는데 필요한가를 통해 판단할 수 있다. 하나의 프레임을 3Mbyte의 데이터로 표현할 경우 1Mbyte로 표현하는 것보다 훨씬 많은 정보를 포함하게 되고, 그 결과 프레임의 화질은 높아진다. MPEG을 예로 들 때, 같은 I 프레임 또는 같은 P 혹은 B 프레임을 가지고 화질을 비교할 수 있으며, I 와 P, 또는 I와 B 프레임을 비교하여 화질을 판단하는 것은 적당치 않다. 도 2의 두 영상 데이터(200, 300)은 동일한 방식으로 코딩되며 초당 프레임 수도 동일하다. 다만 각 프레임을 나타내기 위한 데이터의 양에 차이가 있다.

상기 스트리밍 클라이언트(100)에서 지연 시간을 T초라고 설정한 경우, 상기 T초를 채우기 위해서는 고화질의 데이터(200)도 N개의 프레임을 필요로 하며, 저화질의 데이터(300)도 N개의 프레임을 필요로 한다. N개의 프레임이면 T초동안 데이터를 보여줄 수 있기 때문이다. 반면 동일한 N개의 프레임이라 해도, 고화질인 경우와 달리 저화질의 데이터는 프레임당 데이터 크기(bit rate)가 적기 때문에 버퍼에 저장될 데이터의 크기도 고화질의 데이터보다 더 작다. 따라서 고화질의 데이터와 동일한 지연 시간을 가지면서 버퍼에 저장되는 시간을 줄일 수 있다. 도 1에서는 M개의 프레임을 필요로 하며 N < M이므로 이는 쉽게 유추될 수 있다.

도 3에서는 MPEG-2 비디오 데이터를 예를 들어 보여주고 있다. MPEG-2 비디오 데이터는 일련의 데이터 시퀀스(900)로 이루어진다. 이 데이터 시퀀스는 비트 스트림을 기반으로 하며, 그림(picture, 이하 프레임)에 대한 정보들로 구성된다. 프레임(920)은 하나의 정지영상에 대한 정보를 나타내는 것으로, 여러 개의 슬라이스(930)로 구성된다. 그리고 이 슬라이스(930)는 다시 여러 개의 매크로블록(940)으로 이루어지며, 이 매크로블록은 픽셀들에 대한 정보인 블록(950)으로 이루어진다. MPEG-2에서의 비디오 정보는 상기의 구조로 이루어져 있으며, 다른 비디오 압축 데이터 역시 도 3과 유사한 구성으로 이루어져 있다.

따라서, 비디오를 스트리밍 하기 위해서는 상기 비디오 시퀀스를 수신하는 것이 필요하다. 그런데, 상기 비디오 시퀀스를 구성하는 프레임들 및 헤더 정보들은 작은 크기의 데이터가 아니다. 이러한 프레임들의 연속인 비디오 시퀀스 역시 현재의 통신 및 데이터 처리 속도에서 하나의 데이터 묶음으로 보내거나 처리할 수 없다. 따라서 비디오 시퀀스을 약속된 길이로 나눈 패킷으로 보내게 된다.

패킷은 비트스트림으로 구성된 비디오 스트림을 미리 약속한 길이(가변 혹은 고정된 길이일 수 있음)로 나눈 단위를 의미한다. MPEG-2의 경우 고정 길이로 전송 하는 전송 스트림(Transport stream)과 가변 길이로 전송하는 프로그램 스트림(Program stream)이 있다. 전송 스트림은 한번에 많은 프로그램을 동시에 보낼 수 있는 반면, 데이터의 유실 가능성이 있다. 프로그램 스트림은 멀티미디어 어플리케이션에 적합하게 최적화되어있다. 따라서, 멀티미디어 데이터는 상기 예시한 패킷들로 전송된다.

이와는 달리, 통신상의 데이터 단위가 있다. 통상 이러한 데이터 단위도 패킷이라 칭하기도 한다. 통신상의 데이터 단위는 통신 상태와 프로토콜에 따라 다양하며, TCP/IP, UDP, HTTP 등에 따라 데이터의 정의도 달라진다.

앞에서 예시한 전송 스트림(Transport Stream)의 패킷 길이는 188byte이다. 예를 들어 1024byte를 전송 단위로 하는 통신 프로토콜에서는 상기 전송 스트림의 패킷을 5개를 보낼 수 있다.

이하, 본 명세서에서 사용하는 패킷은 비디오 스트림을 나눈 비트 스트림의 일종이다. 상기 통신을 통해 전달받은 데이터 단위는 헤더등의 부가 정보와 실제 전달하고자 하는 멀티미디어 정보가 포함되므로, 본 명세서에서의 패킷은 상기 멀티미디어 정보, 예를 들어, 비디오 스트림의 일부로 전송되는 비트 스트림을 패킷으로 지칭하고자 한다.

본 실시예에서 사용되는 '~부'라는 용어, 즉 '~모듈'은 소프트웨어, FPGA 또는 ASIC과 같은 하드웨어 구성요소를 의미하며, 모듈은 어떤 기능들을 수행한다. 그렇지만 모듈은 소프트웨어 또는 하드웨어에 한정되는 의미는 아니다. 모듈은 어드레싱할 수 있는 저장 매체에 있도록 구성될 수도 있고 하나 또는 그 이상의 프로세서들을 재생시키도록 구성될 수도 있다. 따라서, 일 예로서 모듈은 소프트웨어 구성요소들, 객체지향 소프트웨어 구성요소들, 클래스 구성요소들 및 태스크 구성요소들과 같은 구성요소들과, 프로세스들, 함수들, 속성들, 프로시저들, 서브루틴들, 프로그램 코드의 세그먼트들, 드라이버들, 펌웨어, 마이크로코드, 회로, 데이터, 데이터베이스, 데이터 구조들, 테이블들, 어레이들, 및 변수들을 포함한다. 구성요소들과 모듈들 안에서 제공되는 기능은 더 작은 수의 구성요소들 및 모듈들로 결합되거나 추가적인 구성요소들과 모듈들로 더 분리될 수 있다. 뿐만 아니라, 구성요소들 및 모듈들은 디바이스 또는 보안 멀티미디어카드 내의 하나 또는 그 이상의 CPU들을 재생시키도록 구현될 수도 있다.

스트리밍 클라이언트(100)는 크게 지연 제어부(110), 패킷 수신부(120), 송수신부(125), 프레임 생성부(130), 프레임 생성 정보 설정부(135), 프레임 출력부(140)와 디코딩부(150)로 구성된다. 스트리밍 클라이언트는 스트리밍 서버로부터 스트리밍되는 데이터를 수신한다. 이 데이터는 전술한 바와 같이 프레임을 구성하는 패킷이며, 도 3에서 살펴본 비디오 스트림의 일부분이 된다. 하나의 프레임을 생성하기 위해서는 여러 개의 패킷이 필요하다. 이는 패킷의 크기가 프레임보다 작은 경우이며, 만약 네트워크와 멀티미디어의 압축 기술이 증가할 경우, 또는 컨텐츠의 특성에 따라 하나의 패킷이 하나 이상의 프레임에 대한 정보를 포함할 수도 있다.

즉, 하나의 프레임을 둘 이상의 패킷으로 구성하는 것은 현재의 기술에 토대를 한 것이며, 프레임 하나를 생성하기 위해 반드시 다수의 패킷을 필요로 하지는 않는다. 본 발명의 일 실시예에서는 하나의 프레임을 나타내기 위해 하나 이상의 패킷이 필요한 경우를 상정하고 있으나, 이는 일 실시예에 불과하며, 이에 한정되는 것은 아니다. 향후 네트워크의 발달과 프레임 압축에 따라 하나의 패킷에 여러 프레임이 포함되어 전송되는 경우도 본 발명의 일 실시예로 적용할 수 있다.

스트리밍 클라이언트는 송수신부(125)를 통해 서버와 데이터를 송수신한다. 한편, 스트리밍 서버로부터 데이터를 수신만 하는 경우에는 상기 송수신부(125)가 패킷 수신 및 데이터 요청 등의 기능만을 수행할 수 있다.

송수신부(125)에서 수신한 데이터들은 패킷 수신부(120)로 전달된다. 패킷 수신부(120)가 수신하는 데이터는 비트스트림이다. 이 비트스트림은 전술한 바와 같이 하나의 프레임을 여러 패킷으로 나누어 전송하는 경우를 가정하며, 하나의 프레임을 만들기 위해서는 상기 패킷을 취합하는 과정이 필요하다. 따라서, 패킷을 수신하여 바로 버퍼에 저장하는 기존의 방식과 달리 이를 프레임 생성부(130)로 전달한다. 프레임 생성부는 수신된 패킷을 프레임별로 관리하게 된다.

수신한 패킷들을 프레임별로 관리하기 위해서는 패킷에서 추출한 프레임의 정보를 통해 알 수 있다. 예를 들어 패킷에서 추출한 프레임의 정보가 프레임의 헤더를 포함할 경우, 해당 패킷은 새로운 프레임의 시작을 의미하므로 프레임 관리 리스트에 새로운 프레임으로 연결한다. 그리고 프레임의 헤더를 포함하지 않는 패킷이라면 이전에 수신한 패킷과 같은 프레임을 구성하는 패킷이므로 현재 생성중인 패킷들의 연결 리스트를 링크를 통해 결합하거나 또는 이전에 수신한 패킷이 저장된 부분 이후에 순차적으로 저장할 수 있다.

상기 프레임 생성부(130)는 순차적인 저장을 위해 패킷 수신부로부터 수신한 비트스트림을 조합하는 작업을 할 수 있다. 여기서 조합이라는 것은 수신한 패킷을 덧붙여서 하나의 프레임 단위의 비트 스트림을 만드는 것을 의미한다.

프레임 출력부(140)는 프레임 생성부(130)에서 저장하는 프레임의 개수를 지속적으로 검사한다. 그 결과 지정된 프레임 수를 넘는 경우에 프레임 생성부에 있는 프레임을 가져와서 디코딩부(150)로 출력한다. 여기서 프레임을 가져와서 디코딩부로 출력한다는 것은 프레임 생성부에서 패킷들을 조합한 프레임을 비트스트림으로 전송하는 것을 의미한다. 따라서, 종래에 버퍼에 저장된 패킷들을 비트스트림으로 전송하는 것과 유사하며, 디코딩부는 종래의 디코딩부가 버퍼에서 수신하는 방식으로 프레임 출력부에서 데이터를 수신할 수 있다. 프레임 출력부(140)가 출력을 시작하면, 프레임 생성부(130)에 데이터가 없거나, 사용자가 재생 중지를 요청하기 전까지 출력을 수행한다. 그러므로 사용자에게 끊김없는 멀티미디어 재생을 위해서는 프레임 출력부(140)의 출력 속도와 패킷 수신부(120)의 패킷 수신 속도는 지연 제어부(110)를 통해 제어될 수 있다.

상기 패킷은 수신한 패킷이 비디오 혹은 오디오 스트림의 단순한 조각인 경우에는 그대로 덧붙여서 저장할 수 있고, 만약 상기의 조각 외에 다른 정보를 포함한다면 이에 대한 처리 과정을 거친 후 순차적으로 저장할 수 있다.

디코딩부(150)에서는 프레임을 출력하기 위한 디코딩 작업을 수행하고 디스 플레이부 혹은 음향출력부로 전송한다. 이를 위해서는 비디오 또는 오디오 디코딩과 관련된 작업을 필요로 한다.

프레임 생성 정보 설정부(135)는 프레임 생성부(130)에서 저장하는 프레임의 개수와 지연 시간에 관한 정보를 결정하여 저장한다. 저장하는 프레임의 개수를 좀더 상세히 살펴보면, 프레임 생성부(130)가 수용할 수 있는 최대 프레임 수와 최소 프레임 수, 초기 출력을 위해 필요한 프레임 수 등이 될 수 있다. 또한 화질에 대한 정보를 가질 수도 있다. 이러한 정보들은 모두 프레임에 대한 속성으로, 속성에 따라 얼마만큼의 프레임을 저장할 지를 결정할 수 있다. 예를 들어, 전술한 지연 시간에 대한 정보를 설정하면, 프레임을 수신하면서 해당 프레임의 속성에 따라 설정될 수 있다. 예를 들어 지연 시간을 1분으로 설정하면, 수신한 프레임이 초당 25프레임으로 코딩된 경우, 1500 프레임을 저장하면 된다. 또한 최대, 최소 프레임 수는 상기 지연 시간외에 최소 지연 시간 또는 최대 지연 시간으로 설정하여 프레임의 속성에 맞게 설정될 수 있다.

또한 고화질의 경우 수신할 패킷의 양이 많으므로, 지연에 따른 끊김 현상이 클 수 있으므로 저장 가능한 프레임의 수를 높이고, 저화질의 경우 반대로 저장 가능한 프레임의 수를 낮출 수 있다. 이는 각 시스템과 멀티미디어 컨텐츠에 따라 달리 설정될 수 있으며, 상기의 고화질과 저화질의 경우는 하나의 실시예에 불과하며, 이에 한정되는 것은 아니다.

지연 제어부(110)는 프레임 생성부(130)에 저장된 패킷들이 구성하는 프레임의 개수가 저장할 수 있는 양을 넘어서거나, 너무 적게 저장된 경우, 패킷의 수신 속도와 디코딩부로 출력시키는 속도를 제어한다. 예를 들어 프레임 생성부에 최소 프레임 수보다 적은 프레임이 저장되어 있다면 더 많은 프레임을 수신해야 하므로 빠른 전송을 요구할 수 있다. 또한, 빠른 전송이 어려운 경우에는 상기 프레임의 출력 속도를 줄여서, 최소 프레임 수보다 많은 수의 프레임이 프레임 생성부에 저장될 수 있게 한다. 출력 속도를 제어하는 것은 프레임 출력부(140)를 제어하는 것을 통해 가능하다. 또한 수신 속도를 제어하는 것은 송수신부를 통해 서버와의 데이터 수신을 조절할 수 있다.

반면 최대 프레임 수보다 많다면, 프레임 생성부가 관리할 수 있는 양의 한계를 넘어설 수 있으므로, 스트리밍 클라이언트(100)는 스트리밍 서버(900)에 데이터 전송을 줄이거나, 잠시 중지할 것을 요청할 수 있다. 스트리밍 기술을 크게 둘로 나눌 때, 클라이언트가 데이터를 가져오는 방식인 풀(Pull)방식의 경우에는 클라이언트가 흐름 제어(flow control)을 할 수 있으므로, 상기 지연 제어부(110)는 데이터 수신에 관련된 부분을 제어할 수 있다. 한편 서버가 클라이언트에 데이터를 전송하는 푸쉬(Push)방식의 경우에도 클라이언트가 속도를 제어할 수 있게 하는 프로토콜을 사용할 경우, 지연 제어부(110)는 송수신부를 통해 서버측에 데이터 전송을 중지하거나 낮은 속도로 보낼 것을 요청할 수 있다.

도 5는 본 발명의 일 실시예에 따른 프레임 생성부에서 관리하는 패킷과 프레임의 구조를 보여주는 블록도이다. 도 5의 실시예에서는 프레임이 하나 이상의 패킷으로 구성되는 경우를 상정하고 있다.

패킷 수신부(120)에서 수신한 패킷은 프레임 생성부(130)에서 프레임별로 저 장할 수 있다. 수신한 패킷에서 프레임의 헤더인지 여부를 판별할 수 있으므로, 헤더인 경우는 새로이 연결 리스트를 구성할 수 있고, 프레임의 헤더가 아니라면 기존에 존재하는 연결 리스트에 패킷을 링크로 연결할 수 있다. 이를 링크 방식이라 한다. 또한 다른 실시예에 의할 경우, 프레임 관리 리스트를 통해 프레임별로 시작 위치등의 정보를 유지할 수 있고, 패킷들은 비트스트림이므로 프레임 별로 덧붙이는 형식으로 관리할 수 있다. 이를 조합 방식이라 한다.

링크 방식에서는 하나의 프레임을 구성하기 위해 k개의 패킷이 필요한 경우, 이들 k개의 패킷을 링크로 연결하여 저장할 수 있다. 그리고 이러한 패킷 링크의 헤더는 디코딩부에 입력될 순서로 연결될 수 있다. 한편 k개의 패킷으로 하나의 프레임을 구성하게 되면 현재 프레임 생성부에 몇 개의 프레임이 저장되어있는지에 대한 정보를 변경할 수 있다. 이러한 정보는 프레임 생성 정보 설정부(135)에 저장된다. 프레임 생성 정보 설정부(135)에는 이외에도 최대/최소 지연 시간에 따른 프레임 수도 설정될 수 있다.

초당 프레임 수가 같은 경우에, 지연시간 T를 충족시키기 위한 프레임이 총 4개라면, 상기 프레임을 구성하는 패킷의 수가 화질에 따라 다름을 알 수 있다.

도 5에서는 프레임 생성부(130)에서 패킷을 프레임별로 연결 리스트를 구성하고, 그 패킷들의 헤더를 또다른 연결 리스트로 관리하고 있지만, 조합 방식을 사용하여, 패킷들을 하나의 프레임으로 조합하여, 프레임별로 하나의 연결 리스트를 구성할 수 있다.

도 6a와 6b는 본 발명의 일 실시예에 따른 패킷 수신에서 프레임 출력에 이 르기까지의 프레임 생성부의 변화를 보여주는 블록도이다.

(1), (2), (3)은 시간 순서에 따라 패킷을 수신한 후 상기 패킷이 어떻게 저장되어 출력되는지를 보여주는 블록도이다.

(1)에서 패킷 수신부(120)를 통해 패킷을 저장한다. 패킷의 헤더를 통해 상기 패킷이 프레임의 시작 패킷인지 혹은 프레임의 마지막 패킷인지를 알 수 있다. 시작 패킷인 경우, 지금까지 하나의 프레임을 구성한 211, 212과 같은 패킷들의 집합, 예를 들어 하나의 프레임을 구성하기 위해 패킷들이 연결된 리스트 또는 패킷들을 순차적으로 저장한 것을 정리하고, 다음 프레임을 구성하기 위해 프레임 관리 리스트(800)에 새로이 연결할 수 있다. 패킷들의 집합은 비트스트림으로 구성된 패킷들을 연결시킨 것으로, 일 실시예로는 저장 공간에 순차적으로 저장한 것이 될 수 있다. 이렇게 순차적으로 저장한 패킷들에서 프레임 관리 리스트(800)는 패킷 중 헤더를 포함하는 저장 위치에 대한 포인터를 유지하여, 이후 프레임 출력부(140)에서 프레임을 가져갈 수 있게 할 수 있다.

(1)에서는 최소 프레임 수보다 많고, 최대 프레임 수보다 작은 수의 프레임이 프레임 생성부에 저장되어 있다. 이러한 최대, 최소 프레임수등에 대한 정보는 프레임 생성 정보 설정부(135)에서 가지고 있다. 최대, 최소 프레임 수는 수신 속도를 조절하기 위해 필요한 정보이며, 반드시 최대, 최소 프레임 수의 형태로 유지할 필요는 없다. 단지 '저장 가능한 프레임 수' 만을 유지할 수도 있다. 이는 시스템의 구성에 따라 달라질 수 있다.

(2)에서는 최대 프레임 수까지 프레임이 프레임 생성부(130)에 저장되어 있 는 상태이다. 이 경우에는 프레임을 출력하여야 이후 패킷 수신부에서 수신되는 패킷을 저장할 수 있다. 따라서 프레임 출력부는 프레임 생성부에서 최소 프레임 수 이상을 유지하도록 패킷들을 가져와서 디코딩부로 보낼 수 있다. 가져오는 패킷들의 순서는 프레임 관리 리스트의 프레임 순서에 따라 해당 프레임별로 패킷들을 가져온다. 이들 패킷들의 순서는 전술한 링크 방식으로 연결된 경우 링크를 따라 가져올 수 있다. 또한 순차적으로 저장된 경우에는 이들 패킷들이 저장된 순서대로 가져올 수 있다. 따라서 211, 212와 같이 먼저 저장된 패킷들이 출력된다. 프레임 출력부(140)에서는 패킷들을 하나의 프레임으로 생성하여 디코딩부로 보낼 수 있다. 이때, 프레임 출력부(140)는 프레임 생성부(130)로부터 한 프레임에 해당하는 패킷들을 가져와서, 이를 프레임으로 만들어 디코딩부로 보낼 수 있다. 또한 프레임 출력부(140)에 저장 공간이 많은 경우, 일정 수량의 프레임을 구성하는 다수의 패킷들을 한꺼번에 가져와서 프레임들을 생성하여 출력할 수 있다. 이는 각 시스템의 구성에 따라 달라진다.

프레임 생성부(130)는 최대 프레임 수보다 현재 프레임 수가 작으므로 패킷을 수신할 수 있다. 그리고, 프레임 생성부(130)는 상기 패킷을 수신하면서, 저장된 프레임은 프레임 출력부(140)가 지속적으로 가져와서 출력할 수 있다. 이 과정에서 프레임 생성부(130)에 저장된 프레임의 수가 최소 프레임 수보다 많도록, 또는 저장된 프레임의 수가 최대 프레임 수보다 적도록 흐름 제어를 할 수 있다.

프레임 생성 정보 설정부(135)의 최대, 최소 프레임 수는 어떤 매체에서나 동일하게 적용되는 것이 아니다. 이는 초당 프레임 수가 컨텐츠에 따라 달라지기 때문이다. 도 7에서 알 수 있듯이 A란 컨텐츠는 초당 프레임 수가 25이므로 10초의 지연시간을 가지는 경우, 최소 프레임 수가 250개이며, 최대 프레임 수는 15초의 지연시간을 예상하여 375개를 최대로 가질 수 있다. B라는 컨텐츠는 초당 프레임 수가 30이므로 10초의 지연시간을 가지는 경우, 최소 프레임 수가 300개이며, 15초의 지연시간을 예상하여 최대 프레임 수가 450개가 된다. 따라서 이러한 상이한 컨텐츠의 경우에도 일정하게 지연 시간을 유지할 수 있어서 불필요한 버퍼링을 막을 수 있다.

한편 상기 예에서 프레임 생성에 필요한 정보는 반드시 초당 프레임 수가 아닐 수 있다. 즉 HD, SD와 같이 화질의 특성을 정의한 필드의 값을 읽어들일 수 있다. 만약 동일한 초당 프레임 수로 인코딩되었고 컨텐츠가 고화질 혹은 저화질로 나누어 진다면, 프레임 헤더에 이러한 정보를 포함할 수 있다. 또한 하나의 프레임을 구성하는 정보의 크기를 통해 얼마의 프레임을 저장할 것인가를 판단하는 근거로 사용할 수 있다. 이러한 정보들을 통해 프레임 생성부는 수신한 패킷이 구성하는 프레임의 속성에 따라 어느정도의 데이터를 저장할 수 있는지를 산출해 낼 수 있다.

이외에도, 컨텐츠가 가지는 속성에 따라, 이 컨텐츠가 끊김없이 지속적으로 재생되어야 하는 컨텐츠인지, 혹은 빨리 재생되어야 하는 컨텐츠인지를 살펴보아서, 저장할 프레임의 개수를 달리할 수 있다. 예를 들어, 컨텐츠의 전송이 네트워 크의 상황에 비추어 느리다면 이에 알맞게 저장할 프레임의 개수를 늘일 수 있다. 따라서 컨텐츠의 속성은 단순히 프레임의 수, 또는 화질만이 아니라, 컨텐츠의 재생과 전송에 관한 정보도 포함한다. 이러한 정보는 프레임 헤더에 저장될 수 있다.

도 8은 본 발명의 일 실시예에 따른 프레임 생성부에 저장되는 프레임들의 양을 보여주는 그래프이다. 도 7에서 살펴본 바와 같이 수신되는 컨텐츠의 속성이 변하는 경우 저장되는 패킷의 양이 변하는 것을 알 수 있다.

컨텐츠의 속성이 A와 B가 있다고 가정한다. A는 저화질의 컨텐츠일 수 있고, 또는 끊김없는 전송보다는 빠른 전송을 선호하는 컨텐츠일 수 있다. 반면 B는 고화질의 컨텐츠일 수 있고, 또한 빠른 전송보다는 끊김없는 전송을 선호하는 컨텐츠일 수 있다. 도 8을 저화질과 고화질인 경우를 상정하여 설명하고자 한다. 저장되는 패킷의 양은 일정하게 증가하다가 줄어드는데, 줄어드는 이유는 최대 프레임 수에 도달하면 프레임 출력부로 출력되기 때문이다.

(1)의 경우를 살펴본다. (1)에서는 컨텐츠를 초기에 필요한 양만큼 버퍼링하여 출력하는 단계이다. 초기 지연 시간에 해당하는 프레임 수는 최대치 또는 최소치와 다를 수 있기 때문이다. A 속성의 컨텐츠의 최대 프레임 수는 Amax이고 최소 프레임 수는 Amin이다. 따라서 프레임 생성부가 Amax보다 더 많은 패킷을 저장하게 되면 프레임 출력부가 프레임을 출력시킨다. 또한 Amin보다 많은 데이터가 저장되어 유지되도록 지연 제어부는 제어를 한다.

(2)에서는 Amax에 도달하여 패킷을 출력하는 것을 알 수 있다. 또한, Amax와 Amin 사이를 유지하면서 지속적으로 데이터를 출력할 수 있다. 한편 네트워크의 성 능이 뛰어나서 B 속성의 컨텐츠를 보낼 수 있는 경우, 최대 프레임 수와 최소프레임에 변화가 생길 수 있다. B 속성에서 저장하는 최대 프레임의 양은 Bmax이고, 최소 프레임의 양은 Bmin이다. 이는 수신된 프레임의 정보에서 추출할 수 있다. 따라서 B 속성의 컨텐츠를 수신중에는 A 속성의 컨텐츠를 수신하는 경우와 달라질 수 있다. B 속성의 컨텐츠를 수신하는 (3)에서 저장되는 패킷양의 패턴이 변화하는 것을 알 수 있다. 한편, 네트워크 상태의 저하로 다시 A 속성의 컨텐츠를 수신하는 경우 (4)에서와 같이 다시 Amax와 Amin으로 변경되어 이 사이에 데이터가 유지되도록 제어할 수 있다.

상기의 Amin, Amax, Bmin, Bmax는 프레임 생성 정보 설정부에 설정되어 프레임 생성부가 어느정도의 데이터를 유지해야 하는지를 알 수 있게 한다.

패킷 수신부(120)는 송수신부(125)가 스트리밍 서버로부터 수신한 데이터에서 프레임을 구성하는 패킷을 수신한다(S110). 패킷 수신부(120)는 패킷을 프레임 생성부(130)로 보낸다. 프레임 생성부는 수신한 패킷의 프레임 정보를 조사하여, 수신한 패킷이 이전에 수신한 프레임의 속성과 다른지 비교한다(S120). 프레임의 속성이 달라지는 예는 저화질의 컨텐츠를 수신하는 중에 네트워크에 트래픽이 적어서 고화질의 컨텐츠로 수신하는 경우 등을 의미한다. 또는 이전에 수신한 프레임이 없어서, 프레임 생성에 필요한 정보가 없는 경우에도 이에 해당한다. 여기서 이전에 수신한 프레임과 다른 속성의 프레임을 전송하는 패킷이라면 프레임 생성 정보 설정부에 저장된 정보를 변경하고(S122), S124로 넘어간다. 이전에 수신한 프레임과 같은 속성의 패킷이라면 S122 단계를 거치지 않고 패킷이 프레임의 시작인지 여부를 검토한다(S124).

수신한 패킷이 프레임의 시작이 아니면서, 현재 생성중인 프레임이 없다면, 이는 패킷의 수신 자체가 컨텐츠의 중간부터 전송된 것임을 의미한다. 즉 사용자가 스트리밍 되는 멀티미디어의 중간시점에 해당하는 포지션을 선택할 경우, 프레임의 시작을 포함하는 패킷이 아닌 중간 패킷부터 수신할 수 있다. 이들 패킷을 수신한 경우에는 하나의 프레임을 생성하지 못하므로 버릴 수 있다.

여기서 패킷들의 집합 또는 모음은 전술한 패킷들을 프레임 별로 링크를 구성하여 연결하거나, 또는 순차적으로 저장하는 등의 방식을 사용하여 패킷들을 프레임별로 묶은 단위를 의미한다.

수신한 패킷이 새로운 프레임의 시작이 아니라 이전에 수신한 프레임을 나타낸 패킷이라면, 생성중인, 상기 프레임을 구성하기 위해 순차적으로 저장한 패킷들의 집합(모음)에 상기 수신한 패킷을 추가한다(S130). 패킷이 새로운 프레임의 시작이라면 생성중인 패킷들의 집합(모음)을 정리하는 과정이 필요하다(S132). 현재 생성중인 패킷들의 집합은 다른 프레임(이전 프레임)에 대한 패킷들의 집합이기 때문이다. 패킷들의 집합을 정리한 후, 새로운 패킷들의 집합을 생성하여야 한다(S134). 새로운 프레임에 대한 첫 패킷이기 때문이다.

한편 하나의 프레임에 관련된 패킷들이 S132단계에서 완결되었으므로, 프레임 생성 정보 설정부의 현재 프레임 수를 1 더해준다(S136). 현재 프레임 수가 1이 더해짐에 따라 저장된 프레임이 적정한 수를 넘는지를 검토하여야 한다(S138). 적정한 수는 시스템과 상황에 따라 최대 프레임수 또는 최소 프레임수가 될 수 있다. 예를 들어, 저장된 프레임 수가 지연시간을 고려해 충분히 출력해도 좋을 만큼의 프레임 수를 넘는다면 프레임 출력부는 프레임 생성부에 저장된 프레임을 가져와서 디코딩부로 출력한다(S140). 한편, S138 단계에서 프레임 수를 넘지 않는다고 해도, 최소 프레임 수 이하로 되기 전까지는 컨텐츠가 지속적으로 출력될 수 있도록 프레임 생성부에 저장된 프레임들은 출력될 수 있다. 이는 컨텐츠의 성격과 스트리밍 시점의 상황에 따라 달라질 수 있다.

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

본 발명을 구현함으로써 영상 또는 음향 데이터를 수신시 버퍼에 저장되는 데이터의 양을 탄력적으로 조절할 수 있다.

본 발명을 구현함으로써 영상 또는 음향 데이터의 속성에 따라 버퍼에 저장되는 데이터의 양을 조절하여, 영상 또는 음향 데이터를 스트리밍함에 있어서 발생 하는 지연을 줄일 수 있다.

Claims

수신한 패킷들에서 추출된 프레임 정보에 따라 저장될 프레임의 개수를 결정하는 단계;

상기 결정된 프레임의 개수 내에서 상기 패킷들을 해당 프레임별로 연결하여 저장하는 단계; 및

상기 해당 프레임별로 연결하여 저장된 패킷들을 디코딩부로 출력하는 단계를 포함하는 AV 데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 방법
제 1항에 있어서,

상기 추출된 프레임 정보는 프레임의 화질, 초당 프레임 수, 또는 한 프레임을 구성하는 정보의 크기 중 어느 하나를 포함하는 AV데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 방법
제 1항에 있어서,

상기 추출된 프레임 정보는 해당 프레임이 구성하는 컨텐츠의 전송 속도 또는 재생에 대한 정보를 포함하는 AV데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 방법
제 1항에 있어서,

상기 저장될 프레임의 개수를 결정하는 단계는 상기 패킷들을 수신함에 있어서 네트워크의 상태에 따른 지연 시간을 계산하여 저장될 프레임의 개수를 결정하는 AV 데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 방법
제 1항에 있어서,

상기 연결하여 저장하는 단계는 상기 수신한 패킷들을 프레임별로 링크를 구성하여 저장하는 단계를 포함하는 AV 데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 방법
제 1항에 있어서,

상기 연결하여 저장하는 단계는 상기 수신한 패킷들을 프레임별로 순차적으로 저장하는 단계를 포함하는 AV 데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 방법
제 1항에 있어서,

상기 패킷들을 디코딩부로 출력하는 단계는 상기 저장될 프레임의 개수를 초과하여 패킷들이 저장된 경우, 상기 저장된 프레임별 패킷들을 디코딩부로 출력하는 단계를 포함하는 AV 데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 방법
제 1항에 있어서,

상기 저장될 프레임의 개수보다 작은 패킷들이 저장된 경우, 패킷의 출력 속도 또는 패킷의 수신 속도를 제어하는 단계를 더 포함하는 AV 데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 방법
수신한 패킷들을 해당 프레임별로 연결하여 저장하는 프레임 생성부;

상기 패킷에서 추출된 프레임 정보에 따라 상기 프레임 생성부에 저장될 프레임의 개수를 결정하는 프레임 생성 정보 설정부; 및

상기 프레임 생성부에 해당 프레임별로 연결하여 저장된 패킷들을 디코딩부로 출력하는 프레임 출력부를 포함하는 AV 데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 장치
제 9항에 있어서,

상기 프레임 생성부는 상기 수신한 패킷들을 해당 프레임별로 연결하여 저장하기 위해서 수신한 패킷들을 프레임별로 링크를 구성하여 저장하며,

상기 프레임들을 관리하기 위한 프레임 관리 리스트를 포함하는 AV 데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 장치
제 9항에 있어서,

상기 프레임 생성부는 상기 수신한 패킷들을 해당 프레임별로 연결하여 저장하기 위해서 수신한 패킷들을 프레임별로 순차적으로 저장하며,

상기 프레임들을 관리하기 위한 프레임 관리 리스트를 포함하는 AV 데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 장치
제 9항에 있어서,

상기 추출된 프레임 정보는 프레임의 화질, 초당 프레임 수, 또는 한 프레임을 구성하는 정보의 크기 중 어느 하나를 포함하는 AV데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 장치
제 9항에 있어서,

상기 추출된 프레임 정보는 해당 프레임이 구성하는 컨텐츠의 전송 속도 또는 재생에 대한 정보를 포함하는 AV데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 장치
제 9항에 있어서,

상기 프레임 생성 정보 설정부는 상기 패킷들을 수신함에 있어서 네트워크의 상태에 따른 지연 시간을 계산하여 저장될 프레임의 개수를 결정하는 AV데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 장치
제 9항에 있어서,

상기 프레임 출력부는 상기 저장될 프레임의 개수를 초과하여 패킷들이 저장된 경우, 프레임 출력부가 상기 저장된 프레임별 패킷들을 디코딩부로 출력하는 AV데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 장치
제 9항에 있어서,

상기 저장될 프레임의 개수보다 작은 패킷들이 저장된 경우, 패킷의 출력 속도 또는 패킷의 수신 속도를 제어하는 지연 제어부를 더 포함하는 AV데이터 수신시 버퍼량을 컨텐츠 속성에 따라 탄력적으로 조절하는 장치
제 1항 내지 제 8항의 방법을 수행하기 위한 컴퓨터로 읽을 수 있는 프로그램을 기록한 기록 매체
제 1항 내지 제 8항의 방법을 수행하여 멀티미디어 데이터를 수신하는 장치