KR20140105298A

KR20140105298A - 클라이언트에서 캐시를 이용하여 서버의 멀티 미디어 컨텐트를 스트리밍 재생하는 방법 및 이를 위한 장치

Info

Publication number: KR20140105298A
Application number: KR1020130019379A
Authority: KR
Inventors: 강필섭; 방한민; 함성일
Original assignee: 삼성전자주식회사
Priority date: 2013-02-22
Filing date: 2013-02-22
Publication date: 2014-09-01
Also published as: US20140244727A1; US10051013B2; WO2014129747A1; KR102047495B1

Abstract

본 발명은 클라이언트가 서버의 컨텐트를 스트리밍하는 기술에 관한 것으로, 클라이언트에 설치된 서비스가 미디어 플레이어를 대신하여 서버로부터 컨텐트를 수신하고 미디어 플레이어의 메모리 버퍼가 아닌 대용량의 캐시에 컨텐트를 다운로드한 후 캐시에 저장된 데이터를 미디어 플레이어에게 전달한다. 본 발명에 의하면 메모리 버퍼가 꽉 찬 경우에도 서버로부터의 데이터 수신이 중단되지 않으므로 서버 및 클라이언트의 전력 소모를 줄일 수 있고 서버와의 접속을 미디어 플레이어 대신 서비스가 수행하므로 미디어 플레이어의 변경 없이 다양한 소켓 인터페이스를 지원할 수 있으며 캐시에 데이터가 저장되기 때문에 버퍼링 시간을 줄일 수 있다.

Description

클라이언트에서 캐시를 이용하여 서버의 멀티 미디어 컨텐트를 스트리밍 재생하는 방법 및 이를 위한 장치{Method and apparatus for playing multimedia content of server via streaming at client using cache}

본 발명은 스트리밍을 이용한 멀티미디어 컨텐트의 재생 방법 및 이를 위한 장치에 관한 것이다.

스트리밍(streaming)은 멀티 미디어 컨텐트를 재생하는 클라이언트가 미디어 서버로부터 컨텐트 전체를 다운로드하기 전 일부분만 수신한 상태에서도 컨텐트를 재생할 수 있도록 하는 기술이다. 클라이언트에 설치된 미디어 플레이어는 서버에 존재하는 컨텐트를 재생하기 위해 컨텐트의 주소, 예를 들면 URL(Universal Resource Locator)를 이용하며, 많은 미디어 플레이어는 URL이 나타내는 컨텐트를 가져오기 위해서 HTTP(HyperText Transfer Protocol)를 사용한다. 즉, 클라이언트의 미디어 플레이어는 HTTP request를 통해 미디어 서버에 존재하는 컨텐트를 컨텐트의 앞부분부터 수신하기 시작한다. 미디어 플레이어는 컨텐트 앞부분에 존재하는 Header 정보를 분석하여 Decoder를 설정함으로써 영상이 재생될 수 있는 환경을 준비한다.또한, Decoder는 컨텐트의 bit rate에 따라 영상이 원활하게 재생될 수 있도록 메모리 버퍼의 용량을 설정한다. 버퍼가 설정된 후 버퍼에 A/V 데이터를 재생 순서대로 저장해야 하는데 이를 위해서는 A/V 데이터의 Index 정보(예를 들면, MOOVatom)가 필요하다. 그러나 멀티미디어 컨텐트가 HTTP 기반의 스트리밍에 최적화 되지 않은 경우, Index 정보가 컨텐트 Header 부분이 아닌 다른 위치(예를 들면, 컨텐트 데이터의 끝 부분)에 존재할 수 있다. 이 경우, Decoder는 해당 부분을 가져오기 위해 HTTP의 Range옵션을 이용하여 특정 위치에 저장된 Index 정보의 비트 스트림 만을 서버로부터 가져온다. 결국, 컨텐트가 HTTP 기반 스트리밍에 최적화 되어 있지 않은 경우, 미디어 플레이어는 헤더 정보를 가져오기 위한 Request, Index 정보를 가져오기 위한 Request, Index 정보를 바탕으로 버퍼에 데이터를 순서대로 저장하기 위한 Request를 수행하게 된다. 이러한 복수 개의 Request는 동시에 발생할 수도 있으며 하나의 request는 다른 request에 의한 세션을 종료시킨 후에 발생할 수도 있다. 전자의 경우 여러 개의 HTTP Request가 동일한 bit stream 영역을 서버에 요청할 경우 데이터를 중복해서 수신하기 때문에 network bandwidth 자원을 낭비하게 되며, 결국 재생에 필요한 최소한의 데이터를 수신하는데 소요되는 시간 (최초 버퍼링 시간)을 증가시킨다. 후자의 경우에도 기존 연결을 끊고 새로운 연결을 다시 맺는 것을 반복하기 때문에 역시 초기 버퍼링 시간을 증가시킨다.

일반적으로 미디어 플레이어는 컨텐트 재생을 위한 버퍼를 가지며, 버퍼에 데이터를 적재하고 데이터가 특정 임계값 이상으로 누적되면 재생을 시작한다. 하지만 대부분의 미디어 플레이어들은 멀티미디어 컨텐트 크기에 비해 매우 작은 한정된 메모리 버퍼를 사용하기 때문에 컨텐트의 일부 데이터만 수신하여도 버퍼가 꽉 차서 더 이상의 데이터 수신을 하지 못하고 재생을 시작한다. 재생을 통해 버퍼에 있는 데이터를 어느 정도 소진한 후에 다시 버퍼에 데이터 적재를 재개한다. 컨텐트 크기에 비해 메모리 버퍼의 크기가 작을수록 컨텐트를 재생하는 시간 내내 네트워크를 통해 데이터를 조금씩 수신해서 버퍼에 채울 수 밖에 없기 때문에 클라이언트 기기의 네트워크 사용 시간은 길어지게 되며, 그에 따라 전력 소모가 발생한다. 나아가, 데이터 수신을 잠시 멈추면 TCP 연결은 자신의 congestion window 크기를 줄이기 때문에 다시 데이터 수신을 재개하더라도 기존의 congestion window를 회복하기까지는 다소 시간이 걸리기 때문에 결국 network bandwidth를 낭비하게 된다.

한편, 대부분의 미디어 플레이어들은 스트리밍을 위해 HTTP를 사용하기 때문에, TCP 소켓을 사용하여 서버에 연결을 시도한다. 하지만, 서버가 TCP 소켓을 지원하지 않는 경우, 미디어 플레이어는 서버의 컨텐트를 스트리밍하기 어렵다. 예를 들어, 서버와 클라이언트가 같은 로컬 네트워크에 연결되지 않은 경우 클라이언트는 NAT Traversal을 통해 연결할 수 있는 IP 주소와 포트 번호를 알아야만 한다. 그러나, 만약 방화벽이 있는 경우에는 IP 주소와 포트 번호를 알더라도 연결은 성공할 수 없으며 미디어 플레이어는 UDP 소켓을 사용하거나 Public IP 주소를 사용하는 중계기 서버(Relay Server)에 연결할 수 있는 논리적 소켓을 사용해야 한다. 그러나, HTTP 스트리밍 만을 지원하는 미디어 플레이어는 이런 서버 디바이스에 연결할 방법이 없다. 물론, 미디어 플레이어에 새로운 소켓을 지원하는 기능을 추가하면 문제는 해결되지만, 많은 미디어 플레이어들을 모두 수정하는 것은 현실적으로 어렵다.

본 발명은 클라이언트가 서버에 저장된 멀티미디어 컨텐트를 스트리밍할 때 버퍼링 시간을 최소화하기 위한 방법 및 장치를 제공하고자 한다.

본 발명의 일 실시예는, 클라이언트에서 서비스가 서버의 컨텐트를 스트리밍 재생하는 미디어 플레이어를 제어하는 방법에 있어서, 상기 서버 상의 컨텐트 주소를 파라미터로 가지며 상기 서비스를 가리키는 주소인 캐시 주소를 상기 미디어 플레이어에게 상기 컨텐트의 주소로서 전달하는 단계; 상기 컨텐트를 상기 서버로부터 상기 클라이언트 내의 미디어 플레이어의 메모리 버퍼와는 독립된 저장 공간인 캐시로 다운로드하는 단계; 상기 캐시 주소에 대한 액세스 요청에 대한 응답으로 상기 캐시에 저장된 컨텐트를 상기 미디어 플레이어에게 스트리밍하는 단계를 포함한다.

상기 캐시 주소를 전달하는 단계는, 상기 미디어 플레이어에게 상기 컨텐트에 대한 스트리밍을 요청하는 어플리케이션으로부터 상기 캐시 주소에 대한 문의를 수신하는 단계; 상기 캐시 주소에 대한 문의에 대한 응답으로 상기 어플리케이션에게 상기 캐시 주소를 통지하는 단계를 포함하며, 상기 다운로드하는 단계는 상기 캐시 주소에 대한 문의에 의해 트리거되는 것이 바람직하다.

상기 다운로드하는 단계는, 상기 미디어 플레이어로부터 상기 캐시 주소에 대한 액세스 요청을 수신하는 단계; 상기 캐시 주소의 파라미터를 참조하여 상기 컨텐트를 상기 캐시에서 검색하는 단계; 상기 검색 결과에 따라 상기 컨텐트의 데이터 중 상기 캐시에 저장되지 않은 부분만을 상기 서버에게 요청하는 단계를 포함하는 것이 바람직하다.

상기 캐시 주소는 상기 미디어 플레이어에서는 지원하지 않지만 상기 서버로부터 상기 컨텐트를 다운로드하기 위해 요구되는 소켓 인터페이스 형식을 나타내는 파라미터를 포함하며, 상기 다운로드하는 단계는 상기 소켓 인터페이스 형식을 나타내는 파라미터를 참조하여 상기 서버와 접속하는 단계를 포함하는 것이 바람직하다.

상기 다운로드하는 단계는, 상기 컨텐트에 대한 다운로드가 완료되면 상기 미디어 플레이어의 재생 목록에 있는 다른 컨텐트에 대한 다운로드를 시작하는 단계를 포함하는 것이 바람직하다.

상기 제어 방법은, 상기 캐시의 가용 용량이 소정 임계값보다 작은 경우 상기 캐시의 데이터 일부를 삭제하는 단계를 더 포함하고, 상기 다운로드하는 단계는, 상기 컨텐트의 데이터를 복수 개의 부분(chunk)들로 분할하여 저장하는 단계; 상기 복수 개의 부분들에 대해 각 부분들의 특성에 따라 보존 필요성에 대한 우선 순위를 설정하는 단계를 포함하며, 상기 삭제하는 단계는 상기 우선 순위가 낮은 부분을 우선적으로 삭제하는 것이 바람직하다.

상기 우선 순위를 설정하는 단계는, 상기 복수 개의 부분들 중 상기 컨텐트의 헤더 정보 또는 인덱스 정보를 포함하는 부분의 우선 순위가 상기 컨텐트의 A/V 데이터를 포함하는 부분보다 높은 우선 순위를 가지도록 설정하는 것이 바람직하다.

상기 특성은 생성 시간, 최근 사용 시간, 사용 횟수, 해당 부분에 포함된 정보의 속성 중 적어도 하나를 포함하는 것이 바람직하다.

본 발명의 다른 실시예는, 상기 제어 방법을 수행하는 컴퓨터 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록 매체를 제공한다.

본 발명의 다른 실시예는, 적어도 하나의 메모리 및 상기 메모리에 저장된 적어도 하나의 프로그램을 실행함으로써, 서버의 컨텐트를 스트리밍 재생하는 미디어 플레이어를 제어하는 서비스를 동작시키는 프로세서를 포함하고, 상기 적어도 하나의 프로그램은, 상기 서버 상의 컨텐트 주소를 파라미터로 가지며 상기 서비스를 가리키는 주소인 캐시 주소를 상기 미디어 플레이어에게 상기 컨텐트의 주소로서 전달하는 단계; 상기 컨텐트를 상기 서버로부터 상기 클라이언트 내의 미디어 플레이어의 메모리 버퍼와는 독립된 저장 공간인 캐시로 다운로드하는 단계; 상기 캐시 주소에 대한 액세스 요청에 대한 응답으로 상기 캐시에 저장된 컨텐트를 상기 미디어 플레이어에게 스트리밍하는 단계를 수행하는 명령어들을 포함한다.

도 1은 본 발명의 일 실시예에 따라 클라이언트가 서버의 컨텐트를 재생하는 과정을 나타낸 순서도,
도 2는 본 발명의 일 실시예에 따라 클라이언트가 컨텐트를 서버로부터 다운로드하는 과정을 나타낸 순서도,
도 3은 본 발명의 일 실시예에 따라 스트리밍을 수행하는 클라이언트 장치의 구성을 나타낸 도면,
도 4는 본 발명의 일 실시예에 따라 캐시에 저장되지 않은 하나의 컨텐트 항목을 재생하는 경우를 설명하기 위한 신호 흐름도,
도 5는 본 발명의 다른 실시예에 따라 캐시에 저장되지 않은 하나의 컨텐트 항목을 재생하는 경우를 설명하기 위한 신호 흐름도,
도 6은 본 발명의 일 실시예에 따라 여러 컨텐트 항목들이 포함된 재생 목록의 컨텐트들을 재생하는 경우를 설명하기 위한 신호 흐름도,
도 7은 본 발명의 일 실시예에 따라 캐시에 데이터의 일부가 존재하는 컨텐트를 재생하는 경우를 설명하기 위한 신호 흐름도,
도 8은 본 발명의 일 실시예에 따라 캐시에 모든 데이터가 존재하는 컨텐트를 재생하는 경우를 설명하기 위한 신호 흐름도,
도 9는 본 발명의 일 실시예에 따라 컨텐트를 스트리밍한 경우 클라이언트에서의 실제 전력 소비량을 측정한 실험의 결과 그래프,
도 10는 본 발명의 일 실시예에 따라 컨텐트를 스트리밍한 경우 클라이언트에서의 실제 전력 소비량을 측정한 실험의 결과 그래프를 도시한 것이다.　

이하에서 첨부된 도면을 참조하여, 본 발명의 바람직한 실시예를 상세히 설명한다.

도 1은 본 발명의 일 실시예에 따라 클라이언트가 서버의 컨텐트를 재생하는 과정을 나타낸 순서도이다.

본 발명에서는 클라이언트의 스트리밍을 제어하기 위해 클라이언트에 설치되는 새로운 서비스가 제안된다. 여기서, 서비스는 사용자와의 인터랙션 없이 지속적으로 동작하며, 다른 어플리케이션들에게 기능성(functionality)을 제공하는 어플리케이션 컴포넌트를 의미한다. 구체적인 설명이 없어도 서비스의 의미는 당업자에게 명확하게 이해될 수 있을 것이다. 이하, 본 발명에서 제안하는 서비스를 '캐시 서비스'로 칭하기로 한다. 도 1 및 도 2에서의 동작들은 모두 캐시 서비스에 의해 수행되는 것이다. 또한, 이하에서 '스트리밍'은 별도의 설명이 없더라도 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자라면 문맥상 송신, 수신, 재생 중 어느 것을 의미하는 것인지 쉽게 이해할 수 있다.

단계 101에서, 캐시 서비스는 서버에 존재하는 컨텐트의 주소를 파라미터로 가지며 목적지로 캐시 서비스(구체적으로는, 캐시 서비스를 구성하는 특정 서비스 모듈)를 가리키는 캐시 주소를 생성한다. 여기서, 캐시는 클라이언트에 설치된 미디어 플레이어가 사용하는 메모리 버퍼와는 구별되는 저장 공간을 의미하며, 메모리 버퍼보다 저장 용량이 큰 저장 매체라면 특정한 것으로 한정되지 않는다. 예를 들면, 하드 디스크가 캐시로 이용될 수 있다.

단계 102에서, 캐시 서비스는 캐시 주소를 미디어 플레이어에게 컨텐트의 스트리밍 주소로서 직접적 또는 간접적으로 전달한다. 따라서, 캐시 주소를 수신한 미디어 플레이어는 캐시 주소를 서버 상의 컨텐트 주소로 인지하게 된다.

단계 103에서, 캐시 서비스는 컨텐트를 서버로부터 다운로드하여 캐시에 저장한다. 여기서의 다운로드는 미디어 플레이어로부터의 스트리밍 요청에 의해 시작될 수도 있지만, 스트리밍 요청이 있기 전에 수행될 수도 있다. 후자는 컨텐트를 미리 가져오는(prefetching) 경우로서, 이에 대한 보다 상세한 설명은 도 5와 함께 후술한다.

한편, 스트리밍이 요청된 컨텐트 외에도 그 컨텐트를 포함하는 재생 목록의 다른 컨텐트들을 미리 다운로드 할 수도 있다. 예를 들면, 웹 페이지에서 미디어 플레이어에게 여러 음악 항목들을 포함하는 재생 목록을 제공하였는데, 사용자가 재생 목록 중 하나의 항목을 선택하였더라도 캐시 서비스는 미리 다른 음악 항목들도 다운로드하여 캐시에 저장할 수 있다. 이 경우, 사용자가 다른 음악 항목을 선택하더라도 미디어 플레이어는 버퍼링을 위해 대기할 필요 없이 캐시로부터 즉시 선택된 음악 항목을 스트리밍할 수 있게 된다.

단계 104에서, 캐시 서비스는 미디어 플레이어로부터의 캐시 주소에 대한 액세스 요청, 즉 컨텐트 스트리밍 요청에 대해 캐시에 저장된 컨텐트를 미디어 플레이어에게 송신(스트리밍)한다.

이와 같이, 본 발명에서는 버퍼링을 위해 미디어 플레이어의 메모리 버퍼만을 사용하는 것이 아니라 저장 공간이 큰 캐시를 버퍼로 이용하기 때문에 메모리 버퍼가 꽉 찼을 경우 데이터 수신을 중단할 필요가 없으며, 동일한 컨텐트를 두 번 이상 재생하는 경우 서버에 접속할 필요 없이 캐시에 저장된 데이터를 이용할 수 있기 때문에 전력과 네트워크 자원의 소모를 줄일 수 있다.

또한, 미디어 플레이어를 대신하여 캐시 서비스가 서버에 접속하고 컨텐트를 수신하기 때문에 미디어 플레이어와 서버에서 지원하는 소켓 인터페이스가 서로 호환되지 않아도 컨텐트의 스트리밍이 가능하다.

도 2는 본 발명의 일 실시예에 따라 클라이언트가 컨텐트를 서버로부터 다운로드하는 과정을 나타낸 순서도이다. 즉, 도 2는 도 1에서의 단계 103을 보다 구체적으로 나타낸 것이다.

단계 201에서, 캐시 서비스는 캐시 주소에 대한 액세스 요청, 즉 서버 상의 컨텐트에 대한 스트리밍 요청을 수신한다.

단계 202에서, 캐시 서비스는 캐시 주소에 의해 특정되는 컨텐트의 모든 데이터가 캐시에 존재하는지 검색한다. 전술한 바와 같이, 캐시 주소에는 원래의 컨텐트 주소, 즉 서버 상의 컨텐트에 대한 URL이 파라미터로 포함되어 있으므로 캐시 주소만으로 컨텐트를 특정할 수 있다. 또는, HTTP에서 사용되는 ETAG를 사용할 수도 있다. 그 외에도, 컨텐트 크기, 생성 날짜 등의 조합으로도 컨텐트를 식별할 수 있다. 만약 컨텐트 전부가 캐시에 존재한다면 서버에 접속할 필요가 없으므로 다운로드 단계는 종료된다. 컨텐트 전부가 캐시에 존재하는 것이 아니라면 단계 203으로 진행한다.

단계 203에서, 컨텐트의 일부 데이터가 캐시에 존재하는지 검색한다. 만약 컨텐트 일부가 캐시에 저장되어 있다면 단계 205로 진행하고, 그렇지 않은 경우 즉, 컨텐트의 데이터가 캐시에 전혀 저장되어 있지 않은 경우에는 단계 204로 진행한다.

단계 204에서, 캐시 서비스는 서버에 접속하여 컨텐트 전체를 요청한다.

단계 205에서, 캐시 서비스는 컨텐트 데이터 중 캐시에 저장되지 않은 부분만을 서버에 요청한다.

단계 206에서, 캐시 서비스는 서버로부터 컨텐트를 다운로드하여 캐시에 저장한다.

도 3은 본 발명의 일 실시예에 따라 스트리밍을 수행하는 클라이언트 장치의 구성을 나타낸 도면이다.

도 3에는 도시되지 않았으나, 본 발명의 일 실시예에 따른 클라이언트 장치(300)는 적어도 하나의 메모리, 프로세서, 저장 장치를 포함한다.　 캐시 서비스를 제공하는 명령어들은 메모리에 저장(로드)되며, 프로세서가 그 프로그램을 실행함으로써 클라이언트에서 캐시 서비스가 수행된다. 저장 장치는 캐시로 이용된다.

도 3에 도시된 바와 같이, 본 실시예에서 캐시 서비스(310)는 여러 서비스 모듈들로 구성된다. 구체적으로, 캐시 서비스(310)는Request Accepter(311), Session Manager(312), Cache Manager(313), Advance Fetcher(314), Cache Repository(315), Cache Sweeper(316), Prefetching Manager(317), Prefetcher(318)를 포함한다. 이러한 서비스 모듈들은 소프트웨어로 구현될 수 있으며, 메모리에 로드된 후 CPU에 의해 구동된다.

Request Accepter(311)는 미디어 플레이어(301)로부터 컨텐트에 대한 스트리밍 요청, 즉 캐시 주소에 대한 HTTP Request를 수신하는 입력 인터페이스이다. Session Manager(312)는 미디어 플레이어(301)에게 캐시에 저장된 컨텐트를 전달한다. Cache Manager(313)는 컨텐트를 스트리밍 요청이 수신되기 전에 미리 가져오는(prefetching) 작업을 관리한다. Advance Fetcher(314)는 스트리밍 요청된 컨텐트가 캐시에 없는 경우 서버(350)로부터 컨텐트를 수신한다. Cache Repository(315)는 Session Manager(312), Advance Fetcher(314), Prefetcher(318)로부터 데이터를 전달받아 캐시(디스크)에 데이터를 읽고 쓰는 작업을 수행한다. Cache Sweeper(316)는 캐시의 여유 공간을 관리한다. Prefetching Manager(317)는 prefetching 작업의 우선 순위를 관리한다. Prefetcher(318)는 서버로부터 컨텐트를 수신하여 pretching 작업을 수행한다.

일반적인 기존의 HTTP 스트리밍은 웹 브라우저와 같은 어플리케이션(302)이 컨텐트 URL을 미디어 플레이어(301)에게 전달하며 스트리밍을 요청하고, 미디어 플레이어(301)는 메모리 버퍼를 이용하여 스트리밍을 수행한다. 그러나, 본 발명에서 미디어 플레이어(301)는 원본 URL 대신 캐시 URL을 전달받는다. 이를 위해, 어플리케이션(302)은 미디어 플레이어(301)에게 원본 URL 대신 캐시 URL을 전달하도록 동작해야 한다. 여기서, 어플리케이션(302)은 컨텐트를 사용자에게 표시해주는 것이라면 특정한 것으로 한정하지 않는다. 미디어 플레이어(301)는 실제 컨텐트 파일을 재생하기 위해 실행되는 소프트웨어 모듈이다. 예를 들면, 안드로이드 OS에서의 <비디오 플레이어>는 동영상을 사용자에게 보여주는 어플리케이션(302)이며, <비디오 플레이어>를 실행하였을 때 실제 동영상 파일을 디코딩하기 위해 실행되는 내부 재생기가 미디어 플레이어(301)이다.

캐시 URL은 원본 URL을 파라미터로 포함하고 Request Acceptor에 접속할 수 있는 URL을 의미한다. 애플리케이션(302)으로부터 캐시 URL을 요청 받은 Cache Manager(313)는 원본 URL을 변환하여 캐시 URL을 생성하고 어플리케이션을 통해 미디어 플레이어(301)에게 전달한다.

미디어 플레이어(301)는 Request Acceptor에게 HTTP Request를 보내서 컨텐트 스트리밍을 요청한다. 미디어 플레이어(301)의 HTTP Request를 수신한 Request Acceptor는Session Manager(312)에게 전달하고, Session Manager(312)는 HTTP Request 를 파싱하여 원본 URL을 알아낸다.

Session Manager(312)는 요청 받은 컨텐트가 캐시에 없는 경우, 일부 데이터만 있는 경우, 모든 데이터가 있는 경우 각각 다르게 동작한다. 이하에서는 각 경우에 있어서 서비스 모듈들이 어떻게 동작하는지 순차적으로 설명한다.

우선, 재생하려는 컨텐트의 데이터가 캐시에 전혀 저장되지 않은 경우, Session Manager(312)는 다른 prefetching 작업에 네트워크 대역폭이 소모되는 것을 방지하기 위해 Cache Manager(313)에게 현재 진행 중인 모든 prefetching 작업을 일시 정지할 것을 요청한다.

Session Manager(312)는 요청된 컨텐트의 크기에 따라 데이터를 우선 캐시에 저장하고 캐시에 저장된 데이터를 미디어 플레이어(301)에게 전달할지 아니면 서버로부터 수신된 데이터를 캐시에 저장하지 않고 직접 미디어 플레이어(301)에게 전달할지 여부를 결정한다. 결정 기준이 되는 임계값은 구현 예에 따라 다양하게 설정될 수 있다. 예를 들면, 컨텐트 크기가 메모리 버퍼 크기보다 작으면 메모리 버퍼만을 사용하여도 서버로부터의 데이터 수신이 중단되지 않기 때문에 당장 컨텐트 재생을 위해서는 굳이 버퍼에 컨텐트를 저장할 필요가 없다.

하지만 반대의 경우에는 메모리 버퍼가 꽉 차면 데이터 수신이 일시 정지될 것이기 때문에 끊김 없이 데이터를 수신하기 위해 캐시에 컨텐트를 우선 저장한 후 미디어 플레이어(301)에게 전달하는 것이 바람직하다. 이 경우 Session Manager(312)는 Advance Fetcher(314)를 생성하고, Advance Fetcher(314)는 서버로부터 컨텐트를 수신하여 캐시에 저장한다. Session Manager(312)는 캐시에서 저장된 데이터를 미디어 플레이어(301)에 전달한다. 서버로부터 컨텐트 수신이 완료되면 Session Manager(312) 또는 Advance Fetcher(314)는 Cache Manager(313)에게 일시 정지된 다른 prefetching 작업들을 재개할 것을 요청한다.

한편, 컨텐트 크기가 임계값보다 작은 경우에도 Session Manager(312)는 미디어 플레이어(301)에게 전달한 컨텐트가 나중에 다시 사용될 경우에 대비하여 컨텐트를 캐시에 저장한다.

다음으로, 캐시에 저장된 데이터가 일부만 있는 경우를 설명한다. 이 경우에도 마찬가지로, Session Manager(312)는 Cache Manager(313)에게 현재 진행 중인 모든 prefetching 작업을 일시 정지할 것을 요청한다. 그리고, Session Manager(312)는 재생하려는 컨텐트의 데이터 중 캐시에 저장되지 않은 부분에 대한 정보를 Advance Fetcher(314)에 알려준다. Advance Fetcher(314)는 그 정보를 기반으로 캐시에 저장되지 않은 부분의 데이터만 서버로부터 수신한다. 이 때, Advance Fetcher(314)는 당장 재생에 필요한 데이터를 먼저 수신하는 것이 바람직하므로, 재생 시점의 데이터 오프셋 보다 뒤에 위치하면서 재생 시점과 근접한 데이터를 우선적으로 수신한다. 재생 시점의 데이터 오프셋 앞에 위치하는 데이터는 오프셋 뒤에 있는 데이터를 모두 수신한 후에 수신된다. Advance Fetcher(314)는 데이터 수신이 모두 끝난 후 Cache Manager(313)에게 일시 정지된 다른 prefetching 작업들을 재개할 것을 요청한다.

마지막으로, 캐시에 컨텐트의 데이터가 모두 존재하는 경우, Session Manager(312) 는 네트워크를 통해 서버에 접속할 필요가 없기 때문에 Cache Manager(313)의 prefetching 작업을 중단할 필요가 없다. Session Manager(312)는 캐시에서 컨텐트 데이터를 읽어서 미디어 플레이어(301)에게 전송한다.

한편, Session Manager(312)와Advance Fetcher(314)는 서버로부터 컨텐트의 크기, 이름, ETAG 등에 대한 정확한 정보를 수신하기 위해서 서버에게 송신하는 HTTP request의 버전을 1.0으로 하는 것이 바람직하다. 예를 들어 HTTP Request 헤더에서 'if-none-match' 'if-range' 등의 필드가 사용되면 서버는 컨텐트 크기 등의 정보를 http response에 입력하지 않기 때문이다. 따라서, 만약 미디어 플레이어(301)가 Request Accepter(311)에게 1.1 버전의 HTTP request를 보냈더라도, Session Manager(312)는 1.0 버전의 HTTP Request를 서버에 보내는 것이 바람직하다.

이상 설명한 세 가지 경우들에서는 모두 미디어 플레이어(301)가 캐시 주소에 대한 액세스 요청, 즉 컨텐트 스트리밍 요청을 한 이후에 서버로부터 컨텐트를 수신한다. 만약, 미디어 플레이어(301)로부터의 컨텐트 스트리밍 요청이 있기 전에, 예를 들면 어플리케이션(302)이 Cache Manager(313)에게 캐시 URL을 요청하였을 때 즉시 컨텐트의 다운로드가 시작된다면 초기 버퍼링 시간을 더욱 줄일 수 있다. 이하에서는 컨텐트 스트리밍 요청이 있기 전에 컨텐트의 다운로드를 시작하는 작업을 의미하는 미리 가져오기(prefetching)에 대해 설명한다.

Cache Manager(313)는 prefetching에 대한 요청이 수신되면 Prefetcher(318)를 통해 서버로부터 데이터를 수신하고 캐시에 저장한다. Prefetcher(318)가 데이터를 수신하는 도중 미디어 플레이어(301)의 요청으로 Session Manager(312)가 동일한 데이터에 대한 수신을 시작하는 경우가 있을 수 있다. 이 때, Session Manager(312)는 Cache Manager(313)에게 동일 컨텐트에 대한 Prefetcher(318)의 작업을 취소할 것을 요청한다. 그리고, Session Manager(312)는 Prefetcher(318)가 이미 수신하여 캐시에 저장한 부분을 스킵하고 나머지 부분을 수신한다. 다만, 크기가 작은 컨텐트의 경우 Session Manager(312)는 Prefetcher(318)의 작업을 취소하지 않고, Prefetcher(318)의 다운로드가 완료된 후 캐시에 저장된 데이터를 미디어 플레이어(301)에게 스트리밍하는 것이 바람직하다. prefetching 작업을 취소하고 다운로드를 다시 시작하는 것은 리소스도 낭비되고 시간 지연도 발생하기 때문이다.

prefetching 은 하나의 컨텐트 항목이 아니라 복수 개의 컨텐트 항목들로 확장할 수 있다. 즉, 당장 재생하려는 컨텐트는 아니더라도 재생 목록에 있는 다른 컨텐트를 미리 prefetching할 수 있다. 예를 들면, 재생 목록의 모든 컨텐트들을 prefetching함으로써 이미지 슬라이드 쇼를 구현할 수 있다. 또한, 하나의 음악 앨범에 포함된 전 곡을 첫 곡을 감상 중에 모두 prefetching하면 다음 곡을 감상할 때 버퍼링 지연이 발생하지 않도록 할 수 있다. 어플리케이션은 재생 목록에 대한 prefetching을 Cache Manager(313)에게 요청할 수 있으며 Cache Manager(313)는 Prefetcher(318)를 재생 목록에 포함된 컨텐트들의 개수만큼 생성해서 prefetching을 수행한다. 여기서 각 Prefetcher는 동시에 수행될 수도 있고 순서대로 수행될 수도 있다. 다만, 재생 목록의 prefetching은 캐시 서비스(310)가 서버(350)와의 통신으로 수행하는 작업 중 우선 순위가 가장 낮아서, 전술한 바와 같이 하나의 컨텐트 항목에 대한 prefetching이 시작되거나 Session Manager(312)로부터의 요청에 의해 일시 정지된다.　

캐시의 여유 공간을 효율적으로 관리하기 위해 Cache Repository(315)는　하나의 컨텐트 데이터를 여러 개의 부분(chunk)들로 분할하여 저장하고, 각 부분에 대해 우선 순위를 설정하며, Cache Sweeper(316)는 캐시의 여유 공간을 확보할 필요가 있을 때 우선 순위가 낮은 부분들부터 삭제하는 것이 바람직하다. 예를 들면, 영상이 재생되기 위해 미디어 플레이어(301)는 멀티미디어 컨텐트의 header와 index 정보를 가장 먼저 필요로 하기 때문에, 헤더와 인덱스 정보가 포함된 부분들이 AV 데이터보다 높은 우선 순위를 가지도록 하면 초기 버퍼링 시간을 줄일 수 있다. 다른 예로, 최근 사용 시간, 사용 횟수 등에 기초하여 우선 순위를 결정할 수도 있다. 또 다른 예로, 사용자가 마지막으로 감상한 위치보다 뒤에 위치한 데이터를 저장한 부분들에게 높은 우선 순위를 부여함으로써 사용자가 이어 보기를 수행할 때 Cache Hit 발생률을 최대한 높일 수 있다.

한편, 본 발명에서는 미디어 플레이어(301)가 캐시 서비스를 통해 서버에 접속하기 때문에 HTTP 스트리밍을 사용하는 미디어 플레이어(301)도 TCP 소켓을 지원하지 않는 서버의 컨텐트를 스트리밍할 수 있다. 일반적으로, 기존의 미디어 플레이어(301) 는 네트워크 스트리밍 을 위해서 어플리케이션으로부터 다음과 같은 형식의 URL을 입력 받는다.

http://{서버 IP address }:{서버 port }/{ content location }/{ contents name}?{parameter}

위 URL을 입력 받은 미디어 플레이어(301)는 서버의 IP address 정보를 이용하여 서버와 연결을 시도하고 HTTP Request를 생성하여 서버에게 전송한다. 하지만 NAT 장비나 방화벽 장비 뒤에 숨어 있는 디바이스들에게는 위의 URL로는 접속하지 못한다. 이를 해결하기 위한 다양한 기존의 P2P 기술들이 존재한다. 하나의 예가 XMPP 서버를 signaling 서버로 이용하는 방법이다. 각 단말기들은 고유의 Full JID을 가지고 이를 XMPP 서버가 관리한다. 단말 A가 단말 B에게 연결을 시도하는 경우, A는 B의 Full JID를 서버에게 보내고, 그 서버를 통해서 B와 접속한다. 즉, IP 주소 대신 Full JID를 사용하기 때문에 기존의 미디어 플레이어(301)는 이 방식을 직접 사용할 수 없다.

그러나, 본 발명에서는 미디어 플레이어를 대신하여 캐시 서비스가 서버와 접속하기 때문에 기존 미디어 플레이어(301)에서 아무런 수정 없이도 P2P 연결을 통해 서버의 컨텐트를 스트리밍할 수 있다. 예를 들면, 다음과 같은 형식의 캐시 주소가 사용될 수 있다.

http://{ Request Acceptor IP address }:{ Request Acceptor port}?method={Connect Method }& target ={ Target Full JID }& content ={ Content name}&...

위의 캐시 주소는 원본 URL에서 서버의 IP address와 Port 는 미디어 플레이어(301)가 Request Accepter(311)의 주소로 변경되고, 상대 단말과의 연결 방식, Server의 주소와 컨텐트에 대한 정보는 원본 URL 의 Parameter 값들을 그대로 사용한 것이다. 위와 같은 형식의 URL을 받은 미디어 플레이어(301) 는 Parameter 정보를 포함한 HTTP Request를 생성하여 Request Accepter(311)에게 보내고, Request Accepter(311)는 이를 Session Manager(312)에게 전달한다. Session Manager(312)는 HTTP Request의 파라미터를 분석하여, 서버와 P2P, TCP 연결, RUDP 연결 등 다양한 소켓 인터페이스 중 어떤 것이 요구되는지 알아내고 적절한 연결 방식을 통해 서버와 접속한다. 파라미터에는 위에 예시한 method, target, content 외에도 구현 예에 따라 다양한 정보가 더 추가될 수 있다. 이와 같은 캐시 주소를 사용하면 미디어 플레이어(301) 의 수정 없이 다양한 서버의 스트리밍 컨텐트를 이용할 수 있으며, 동일한 컨텐트를 다양한 미디어 플레이어(301)로 재생할 수 있게 된다. 물론, 캐시 서비스는 미디어 플레이어(301)를 대신하여 다양한 소켓 인터페이스를 구비해야 할 것이다.

도 4는 본 발명의 일 실시예에 따라 캐시에 저장되지 않은 하나의 컨텐트 항목을 재생하는 경우를 설명하기 위한 신호 흐름도이다.

단계 401에서, 어플리케이션은 캐시 서비스에게 캐시 URL을 요청한다. 예를 들면, 웹 브라우저에서 동영상이 포함된 웹 페이지를 열 때, 웹 브라우저는 캐시 서비스에게 동영상의 URL을 전달하며 캐시 URL로 변환해 줄 것을 요청한다.

단계 402에서, 캐시 서비스는 캐시 URL을 어플리케이션에게 보낸다.

단계 403에서, 어플리케이션은 미디어 플레이어에게 캐시 URL을 전달하며 스트리밍(재생)을 요청한다.

단계 404에서, 미디어 플레이어는 캐시 URL을 컨텐트 URL로 인지하고 http request를 생성하여 캐시 URL로 보냄으로써 컨텐트에 대한 스트리밍(전송)을 요청한다.

단계 405에서, 미디어 플레이어가 보낸 캐시 URL은 캐시 서비스가 수신한다. 전술한 바와 같이, 캐시 URL은 캐시 서비스를 가리키는 주소이기 때문이다.

단계 405에서, 캐시 서비스는 캐시 URL의 파라미터를 참조하여 요청된 컨텐트가 캐시에 저장되어 있는지 판단한다.

단계 406에서, 캐시 서비스는 미디어 플레이어로부터 수신한 http request에서 캐시 URL의 파라미터들, 즉 method, target, content 등을 참조하여 http request를 생성한 후 서버에게 보낸다. 본 실시예에서는 컨텐트의 데이터가 전혀 캐시에 존재하지 않는 것으로 가정하였기 때문에 컨텐트 데이터를 모두 서버로부터 수신해야 하기 때문이다.

단계 407에서, 서버는 캐시 서비스에게 http response를 보낸다.

단계 408에서, 캐시 서비스는 미디어 플레이어에게 http response를 보낸다.

단계 409에서, 서버는 캐시 서비스에게 http request를 통해 요청된 컨텐트를 송신한다.

단계 410에서, 캐시 서비스는 서버로부터 수신한 컨텐트를 캐시에 저장한다. 즉, 서버로부터 수신되는 컨텐트는 미디어 플레이어의 메모리 버퍼가 아니라 큰 용량의 캐시에 저장되기 때문에 컨텐트 전송이 완료되지 않은 상태에서 메모리 버퍼가 가득 차더라도 캐시 서비스와 서버 간의 데이터 통신은 중지되지 않는다.

단계 411에서, 캐시 서비스는 캐시에 저장된 컨텐트 데이터를 미디어 플레이어에게 스트리밍하고 미디어 플레이어는 컨텐트를 재생한다. 이와 같이 캐시 서비스가 미디어 플레이어와 서버 사이에서 스트리밍의 요청/응답을 리디렉션(redirection)하기 때문에 미디어 플레이어와 서버의 소켓 인터페이스가 서로 다른 경우에도 미디어 플레이어는 서버의 컨텐트를 스트리밍으로 재생할 수 있다.

도 5는 본 발명의 다른 실시예에 따라 캐시에 저장되지 않은 하나의 컨텐트 항목을 재생하는 경우를 설명하기 위한 신호 흐름도이다.

본 실시예에서는 초기 버퍼링 시간을 줄이기 위해 도 4와는 달리 미디어 플레이어가 캐시 서비스에게 스트리밍을 요청하기 전에 컨텐트의 다운로드를 시작한다.

단계 501에서, 어플리케이션은 캐시 서비스에게 원본 URL을 전달하며 캐시 URL을 요청(문의)한다. 이 때, 캐시 URL을 요청하는 메시지, 즉 캐시 서비스가 제공하는 API 함수를 호출하는 메시지에는 prefetching을 요청하는 키 값이 포함된다.

단계 502에서, 캐시 서비스는 어플리케이션으로부터 수신한 원본 URL 을 이용하여 컨텐트에 액세스하기 위한 http request를 생성하고 서버에게 보낸다.

단계 503에서, 캐시 서비스는 단계 501에서의 요청에 대한 응답으로 캐시 URL을 어플리케이션에게 제공한다.

단계 504에서, 서버는 캐시 서비스에게 http response를 보낸다.

단계 505에서, 서버는 캐시 서비스가 요청한 컨텐트를 송신한다.

단계 506에서, 캐시 서비스는 서버로부터 수신한 컨텐트를 캐시에 저장한다.

단계 507에서, 어플리케이션은 미디어 플레이어에게 캐시 URL에 대한 스트리밍을 요청한다.

단계 508에서, 미디어 플레이어는 스트리밍하려는 컨텐트에 대한 액세스 요청, 즉 캐시 URL에 대한 http request를 캐시 서비스에게 보낸다.

단계 509에서, 캐시 서비스는 요청 받은 컨텐트가 캐시에 저장되어 있는지 확인한다.

단계 510에서, 캐시 서비스는 http response를 미디어 플레이어에게 반환한다. 본 실시예에서는 이미 해당 컨텐트가 캐시에 저장되어 있기 때문에 클라이언트가 서버와 접속할 필요가 없다.

단계 511에서, 캐시 서비스는 캐시에 저장된 컨텐트를 미디어 플레이어에게 스트리밍한다.

도 6은 본 발명의 일 실시예에 따라 여러 컨텐트 항목들이 포함된 재생 목록의 컨텐트들을 재생하는 경우를 설명하기 위한 신호 흐름도이다.

단계 601에서, 어플리케이션은 캐시 서비스에게 재생 목록에 포함된 N개의 컨텐트들을 모두 prefetching할 것을 요청한다. 이 때 호출되는 API 함수는 도 5의 단계 501에서 사용되는 API 함수와는 서로 다른 것으로 가정한다.

단계 602에서, 캐시 서비스는 서버로부터 재생 목록에 포함된 컨텐트 항목들을 다운로드 한다. 다만, 이 다운로드 작업들은 미디어 플레이어의 http request에 의해 시작되는 다운로드 작업에 비해 우선 순위가 낮다. 예를 들면, 재생 목록의 컨텐트 항목들을 다운로드하는 도중 도 4의 단계 409 또는 도 5의 단계 505에 해당하는 우선 순위의 다운로드가 시작되면 재생 목록의 컨텐트 항목들에 대한 다운로드는 일시 정지되었다가 우선 순위의 다운로드가 모두 완료되면 재개된다.

단계 603에서, 다운로드 된 컨텐트 항목들은 캐시에 저장된다.

단계 604에서, 어플리케이션은 재생 목록의 컨텐트 항목들 중 컨텐트 1에 대한 캐시 URL을 요청한다.

단계　605에서, 캐시 서비스는 컨텐트 1에 대한 캐시 URL을 어플리케이션에게 통지한다.

단계 606에서, 어플리케이션은 컨텐트 1에 대한 캐시 URL을 미디어 플레이어에게 전달하며 스트리밍을 요청한다.

단계 607 내지 단계 609에서, 캐시 서비스는 캐시에 저장된 컨텐트 1을 미디어 플레이어에게 스트리밍한다.

단계 610 내지 단계 611에서, 캐시 서비스는 재생 목록에 컨텐트 항목들 중 미디어 플레어어가 요청하는 항목을 캐시에서 읽어서 미디어 플레이어에게 전달한다.

만약 단계 607 이전에 재생 목록의 모든 컨텐트 항목이 캐시에 다운로드 된다면 미디어 플레이어는 재생 목록의 모든 컨텐트들을 버퍼링 시간 없이 재생할 수 있다.

단계 601에서의 prefetching 요청은 어플리케이션이 하나의 컨텐트 항목에 대해 캐시 서비스에게 캐시 URL을 요청할 때 또는 미디어 플레이어에게 캐시 URL에 대한 스트리밍을 요청할 때 함께 수행될 수 있다. 또는, 미디어 플레이어가 하나의 컨텐트 항목에 대해 스트리밍을 요청하고, 그 컨텐트 항목에 대한 다운로드가 완료되었을 때 수행될 수도 있다. 전술한 바와 같이, 단계 601에서의 prefetching 요청에 의한 다운로드 작업들은 미디어 플레이어의 http request에 의해 시작되는 다운로드 작업에 비해 우선 순위가 낮기 때문에 미디어 플레이어의 http request에 의해 시작되는 다운로드 작업이 완료된 후에 재생 목록의 다른 컨텐트들이 다운로드된다.

본 실시예에 따르면, 사용자가 하나의 컨텐트 항목을 재생했더라도 캐시 서비스가 그 컨텐트와 연관된 다른 컨텐트들, 즉 재생 목록에 있는 다른 컨텐트 항목들을 자동적으로 미리 다운로드한다. 예를 들면, 사용자가 자신이 좋아하는 가수의 앨범에 포함된 음악 한 곡을 스트리밍으로 재생하는 경우 스트리밍 재생 도중에 해당 음악 데이터가 모두 캐시에 다운로드되면 캐시 서비스는 그 앨범의 다른 곡들도 모두 prefetching한다. 따라서, 사용자는 동일 앨범의 다른 곡들을 버퍼링 없이 감상할 수 있다.

도 7은 본 발명의 일 실시예에 따라 캐시에 데이터의 일부가 존재하는 컨텐트를 재생하는 경우를 설명하기 위한 신호 흐름도이다.

단계 701 내지 단계 705는 도 4에서의 단계 401 내지 단계 405와 동일하므로 여기서는 설명을 생략한다.

단계 706에서, 캐시 서비스는 http response 를 어플리케이션에게 보낸다.

단계 707에서, 캐시 서비스는 캐시에 저장된 컨텐트의 일부 데이터를 우선 미디어 플레이어에게 송신한다.

단계 708에서, 캐시 서비스는 캐시에 없는 데이터만을 요청하기 위해 http request를 생성한다. 이 때, 캐시 서비스는 캐시에 없는 데이터 중 우선 순위가 높은 데이터를 먼저 수신할 수 있도록 http request를 생성한다. 예를 들면, 동영상 파일에서는 헤더 정보와 인덱스 정보를 포함하는 데이터가 AV 데이터보다 우선 순위가 높으며, 재생 시점의 오프셋과 가까운 위치의 오프셋을 가지는 AV 데이터가 그렇지 않은 데이터보다 우선 순위가 높다.

단계 709에서, 캐시 서비스는 http request를 서버에게 보낸다.

단계 710에서, 서버는 단계 709에서의 http request에 대한 응답으로 http response를 캐시 서비스에게 보낸다.

단계 711에서, 서버는 캐시 서비스에게 요청된 데이터를 송신하며, 캐시 서비스는 수신한 데이터를 캐시에 저장한다.

단계 712에서, 캐시 서비스는 단계 711에서 서버로부터 수신한 데이터를 캐시로부터 읽어서 미디어 플레이어에게 송신한다.　

도 8은 본 발명의 일 실시예에 따라 캐시에 모든 데이터가 존재하는 컨텐트를 재생하는 경우를 설명하기 위한 신호 흐름도이다.

단계 801 내지 단계 805는 도 4에서의 단계 401 내지 단계 405와 동일하므로 여기서는 설명을 생략한다.

단계 806에서, 캐시 서비스는 http response를 미디어 플레이어에게 반환한다. 본 실시예에서는 미디어 플레이어가 요청한 컨텐트의 모든 데이터가 이미 캐시에 저장되어 있기 때문에 클라이언트가 서버와 접속할 필요가 없다.

단계 807에서, 캐시 서비스는 캐시에 저장된 컨텐트를 미디어 플레이어에게 스트리밍한다.

도 9는 본 발명의 일 실시예에 따라 컨텐트를 스트리밍한 경우 클라이언트에서의 실제 전력 소비량을 측정한 실험의 결과 그래프이다. 실험에 사용된 컨텐트는 720p 해상도, 1.1GB 크기의 동영상이며 재생시간은 41분 정도이다. 위 그래프에 도시된 바와 같이, 컨텐트 재생 초반에는 전력 소모량이 다소 많지만 시간이 흐름에 따라 대폭 줄어들어서 결국 전체적으로는 기존 스트리밍 방식에 비해 전력 소모량이 더 적다는 것을 알 수 있다.

본 발명을 적용한 스트리밍 방법은 재생 초기에 네트워크에 수신된 데이터를 받아 캐시(로컬 파일 디스크)에 read/write 작업이 빈번하게 일어나기 때문에 메모리 버퍼만을 사용하는 기존 스트리밍 방식에 비해 전력 소모량이 많다. 하지만 컨텐트 데이터가 캐시에 저장된 후에는 네트워크 자원을 더 이상 사용하지 않기 때문에 전력 소모량이 줄어든다. 반면, 기존 스트리밍 방식은 컨텐트 재생이 거의 완료될 때까지 네트워크 연결이 종료되지 않기 때문에 전력 소비가 지속적으로 유지된다.

도 9는 본 발명의 일 실시예에 따라 컨텐트를 스트리밍한 경우 서버에서의 실제 전력 소비량을 측정한 실험의 결과 그래프이다. 실험에 적용된 조건은 도 8에서와 동일하다.　

도 9에 도시된 바와 같이, 서버의 전력 소비량을 나타낸 그래프의 패턴은 도 8의 그래프와 유사하다. 즉, 재생 초기에는 서버의 read/write 작업과 네트워크 자원 사용으로 인해 전력 소모량이 많지만, 데이터 전송이 완료된 이후에는 기존 방식에 비해 전력 소모량이 훨씬 더 적은 것을 알 수 있다. 네트워크 환경이 개선되어 데이터 전송이 더 빠르게 일어날수록 전력 소모량은 더욱 줄어들 것이다.

한편, 상술한 본 발명의 실시예들은 컴퓨터에서 실행될 수 있는 프로그램으로 작성 가능하고, 컴퓨터로 읽을 수 있는 기록매체를 이용하여 상기 프로그램을 동작시키는 범용 디지털 컴퓨터에서 구현될 수 있다.

상기 컴퓨터로 읽을 수 있는 기록매체는 마그네틱 저장매체(예를 들면, 롬, 플로피 디스크, 하드디스크 등), 광학적 판독 매체(예를 들면, 시디롬, 디브이디 등) 및 캐리어 웨이브(예를 들면, 인터넷을 통한 전송)와 같은 저장매체를 포함한다.

이제까지 본 발명에 대하여 그 바람직한 실시예들을 중심으로 살펴보았다. 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자는 본 발명이 본 발명의 본질적인 특성에서 벗어나지 않는 범위에서 변형된 형태로 구현될 수 있음을 이해할 수 있을 것이다. 그러므로 개시된 실시예들은 한정적인 관점이 아니라 설명적인 관점에서 고려되어야 한다. 본 발명의 범위는 전술한 설명이 아니라 특허청구범위에 나타나 있으며, 그와 동등한 범위 내에 있는 모든 차이점은 본 발명에 포함된 것으로 해석되어야 할 것이다.

Claims

클라이언트에서 서비스가 서버의 컨텐트를 스트리밍 재생하는 미디어 플레이어를 제어하는 방법에 있어서,
상기 서버 상의 컨텐트 주소를 파라미터로 가지며 상기 서비스를 가리키는 주소인 캐시 주소를 상기 미디어 플레이어에게 상기 컨텐트의 주소로서 전달하는 단계;
상기 컨텐트를 상기 서버로부터 상기 클라이언트 내의 미디어 플레이어의 메모리 버퍼와는 독립된 저장 공간인 캐시로 다운로드하는 단계;
상기 캐시 주소에 대한 액세스 요청에 대한 응답으로 상기 캐시에 저장된 컨텐트를 상기 미디어 플레이어에게 스트리밍하는 단계를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,
상기 캐시 주소를 전달하는 단계는,
상기 미디어 플레이어에게 상기 컨텐트에 대한 스트리밍을 요청하는 어플리케이션으로부터 상기 캐시 주소에 대한 문의를 수신하는 단계;
상기 캐시 주소에 대한 문의에 대한 응답으로 상기 어플리케이션에게 상기 캐시 주소를 통지하는 단계를 포함하며,
상기 다운로드하는 단계는 상기 캐시 주소에 대한 문의에 의해 트리거되는 것을 특징으로 하는 방법.
제1항에 있어서,
상기 다운로드하는 단계는,
상기 미디어 플레이어로부터 상기 캐시 주소에 대한 액세스 요청을 수신하는 단계;
상기 캐시 주소의 파라미터를 참조하여 상기 컨텐트를 상기 캐시에서 검색하는 단계;
상기 검색 결과에 따라 상기 컨텐트의 데이터 중 상기 캐시에 저장되지 않은 부분만을 상기 서버에게 요청하는 단계를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,
상기 캐시 주소는 상기 미디어 플레이어에서는 지원하지 않지만 상기 서버로부터 상기 컨텐트를 다운로드하기 위해 요구되는 소켓 인터페이스 형식을 나타내는 파라미터를 포함하며,
상기 다운로드하는 단계는 상기 소켓 인터페이스 형식을 나타내는 파라미터를 참조하여 상기 서버와 접속하는 단계를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,
상기 다운로드하는 단계는,
상기 컨텐트에 대한 다운로드가 완료되면 상기 미디어 플레이어의 재생 목록에 있는 다른 컨텐트에 대한 다운로드를 시작하는 단계를 포함하는 것을 특징으로 하는 방법.
제1항에 있어서,
상기 캐시의 가용 용량이 소정 임계값보다 작은 경우 상기 캐시의 데이터 일부를 삭제하는 단계를 더 포함하고,
상기 다운로드하는 단계는,
상기 컨텐트의 데이터를 복수 개의 부분(chunk)들로 분할하여 저장하는 단계;
상기 복수 개의 부분들에 대해 각 부분들의 특성에 따라 보존 필요성에 대한 우선 순위를 설정하는 단계를 포함하며,
상기 삭제하는 단계는 상기 우선 순위가 낮은 부분을 우선적으로 삭제하는 것을 특징으로 하는 방법.
제6항에 있어서,
상기 우선 순위를 설정하는 단계는,
상기 복수 개의 부분들 중 상기 컨텐트의 헤더 정보 또는 인덱스 정보를 포함하는 부분의 우선 순위가 상기 컨텐트의 A/V 데이터를 포함하는 부분보다 높은 우선 순위를 가지도록 설정하는 것을 특징으로 하는 방법.
제6항에 있어서,
상기 특성은 생성 시간, 최근 사용 시간, 사용 횟수, 해당 부분에 포함된 정보의 속성 중 적어도 하나를 포함하는 것을 특징으로 하는 방법.
적어도 하나의 메모리 및
상기 메모리에 저장된 적어도 하나의 프로그램을 실행함으로써, 서버의 컨텐트를 스트리밍 재생하는 미디어 플레이어를 제어하는 서비스를 동작시키는 프로세서를 포함하고,
상기 적어도 하나의 프로그램은,
상기 서버 상의 컨텐트 주소를 파라미터로 가지며 상기 서비스를 가리키는 주소인 캐시 주소를 상기 미디어 플레이어에게 상기 컨텐트의 주소로서 전달하는 단계;
상기 컨텐트를 상기 서버로부터 상기 클라이언트 내의 미디어 플레이어의 메모리 버퍼와는 독립된 저장 공간인 캐시로 다운로드하는 단계;
상기 캐시 주소에 대한 액세스 요청에 대한 응답으로 상기 캐시에 저장된 컨텐트를 상기 미디어 플레이어에게 스트리밍하는 단계를 수행하는 명령어들을 포함하는 것을 특징으로 하는 클라이언트 장치.
제9항에 있어서,
상기 캐시 주소를 전달하는 단계는,
상기 미디어 플레이어에게 상기 컨텐트에 대한 스트리밍을 요청하는 어플리케이션으로부터 상기 캐시 주소에 대한 문의를 수신하는 단계;
상기 캐시 주소에 대한 문의에 대한 응답으로 상기 어플리케이션에게 상기 캐시 주소를 통지하는 단계를 포함하며,
상기 다운로드하는 단계는 상기 캐시 주소에 대한 문의에 의해 트리거되는 것을 특징으로 하는 클라이언트 장치.
제9항에 있어서,
상기 다운로드하는 단계는,
상기 미디어 플레이어로부터 상기 캐시 주소에 대한 액세스 요청을 수신하는 단계;상기 캐시 주소의 파라미터를 참조하여 상기 컨텐트를 상기 캐시에서 검색하는 단계;
상기 검색 결과에 따라 상기 컨텐트의 데이터 중 상기 캐시에 저장되지 않은 부분만을 상기 서버에게 요청하는 단계를 포함하는 것을 특징으로 하는 클라이언트 장치.
제9항에 있어서,
상기 캐시 주소는 상기 미디어 플레이어에서는 지원하지 않지만 상기 서버로부터 상기 컨텐트를 다운로드하기 위해 요구되는 소켓 인터페이스 형식을 나타내는 파라미터를 포함하며,
상기 다운로드하는 단계는 상기 소켓 인터페이스 형식을 나타내는 파라미터를 참조하여 상기 서버와 접속하는 단계를 포함하는 것을 특징으로 하는 클라이언트 장치.
제9항에 있어서,
상기 다운로드하는 단계는,
상기 컨텐트에 대한 다운로드가 완료되면 상기 미디어 플레이어의 재생 목록에 있는 다른 컨텐트에 대한 다운로드를 시작하는 단계를 포함하는 것을 특징으로 하는 클라이언트 장치.
제9항에 있어서,
상기 적어도 하나의 프로그램은,
상기 캐시의 가용 용량이 소정 임계값보다 작은 경우 상기 캐시의 데이터 일부를 삭제하는 단계를 수행하는 명령어들을 더 포함하고,
상기 다운로드하는 단계는,
상기 컨텐트의 데이터를 복수 개의 부분(chunk)들로 분할하여 저장하는 단계;상기 복수 개의 부분들에 대해 각 부분들의 특성에 따라 보존 필요성에 대한 우선 순위를 설정하는 단계를 포함하며,
상기 삭제하는 단계는 상기 우선 순위가 낮은 부분을 우선적으로 삭제하는 것을 특징으로 하는 클라이언트 장치.
제15항에 있어서,
상기 우선 순위를 설정하는 단계는,
상기 복수 개의 부분들 중 상기 컨텐트의 헤더 정보 또는 인덱스 정보를 포함하는 부분의 우선 순위가 상기 컨텐트의 A/V 데이터를 포함하는 부분보다 높은 우선 순위를 가지도록 설정하는 것을 특징으로 하는 클라이언트 장치.
제15항에 있어서,
상기 특성은 생성 시간, 최근 사용 시간, 사용 횟수, 해당 부분에 포함된 정보의 속성 중 적어도 하나를 포함하는 것을 특징으로 하는 클라이언트 장치.
제1항 내지 제8항 중 어느 한 항에 의한 방법을 컴퓨터에서 수행하도록 하는 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록 매체.