KR20140004218A - 바이트 범위 요청들을 이용한 비디오 데이터의 네트워크 스트리밍 - Google Patents

Abstract

일 예에서, 멀티미디어 데이터에 대한 정보를 수신하는 디바이스는 소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현의 파일의 바이트 범위를 결정하고, 소스 디바이스의 요건들에 따른 파일 및 바이트 범위를 템플릿에 따른 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 URL 을 형성하고, 그 형성된 URL 을 규정하는 GET 요청을 소스 디바이스에 발행하도록 구성된 하나 이상의 프로세서들을 포함한다.

Description

바이트 범위 요청들을 이용한 비디오 데이터의 네트워크 스트리밍{NETWORK STREAMING OF VIDEO DATA USING BYTE RANGE REQUESTS}

본 출원은 2011년 4월 7일자에 출원된, 미국 가출원 번호 제 61/473,105호의 이익을 주장하며, 이는 본원에 전체적으로 참고로 포함된다.

본 개시물은 인코딩된 멀티미디어 데이터의 저장 및 전송에 관한 것이다.

디지털 비디오 능력들은 디지털 텔레비전, 디지털 직접 브로드캐스트 시스템들, 무선 브로드캐스트 시스템들, 개인 휴대 정보 단말기들 (PDAs; personal digital assistants), 랩탑 또는 데스크탑 컴퓨터들, 디지털 카메라들, 디지털 레코딩 디바이스들, 디지털 미디어 플레이어들, 비디오 게이밍 디바이스들, 비디오 게임 콘솔들, 셀룰러 또는 위성 무선 전화기들, 원격 화상회의 디바이스들 등을 포함하는, 광범위한 디바이스들에 포함될 수 있다. 디지털 비디오 디바이스들은 MPEG-2, MPEG-4, ITU-T H.263 또는 ITU-T H.264/MPEG-4, 파트 10, AVC (Advanced Video Coding) 에 의해 정의된 표준들, 및 이런 표준들의 확장판들에 설명된 기법들과 같은 비디오 압축 기법들을 구현하여, 디지털 비디오 정보를 더욱 효율적으로 송수신하도록 한다.

비디오 데이터가 인코딩된 후, 비디오 데이터는 송신 또는 저장을 위해 패킷화될 수도 있다. 비디오 데이터는 ISO (International Organization for Standardization) 베이스 미디어 파일 포맷 및 그 확장판들, 예컨대 MP4 파일 포맷 및 AVC (Advanced Video Coding) 파일 포맷과 같은 다양한 표준들 중 임의의 표준에 따르는 비디오 파일로 어셈블링될 수도 있다. 이런 패킷화된 비디오 데이터는 네트워크 스트리밍을 이용하는 컴퓨터 네트워크를 통한 송신과 같은 다양한 방법들로 전송될 수도 있다.

2000년대 중반에, 인터넷을 통해 실시간 전송 프로토콜 (Real-time Transport Protocol; RTP) 을 통한 비디오 및 오디오 트래픽의 성장은 인터넷을 다량의 네트워크 트래픽으로 가득 채우기 시작했으며, 이들 프로토콜들에 대해 어떤 혼잡 제어들도 없었다. 이것은 기업 정보 기술 (IT) 관리자들이 그들의 방화벽들을 프로그래밍하여 기업들에서 게이트웨이들을 채우고 있던 비디오 및 오디오 스트림들을 포함한 RTP 패킷들을 차단하도록 하였다.

방화벽들은 비디오 및 오디오 스트리밍 서비스들의 존재를 위협하였다. 따라서, 서비스 제공자들은 콘텐츠를 TCP (더욱 구체적으로는, TCP 의 HTTP 포트) 가상 회로들을 통해 제공하기 시작하였다. 그들은 그들의 비디오 및 오디오 트래픽을 유용한 HTTP 트래픽으로 위장하기 위해 이것을 행하였다. IT 방화벽 관리자들은 HTTP/TCP 를 통한 비디오 및 오디오를 용이하게 차단할 수 없었으며, 따라서, 한동안, HTTP 와 TCP 를 통한 비디오 및 오디오가 번창하였다.

처음에, "프로그레시브 다운로드 (progressive download)" 방법이 대부분의 비디오들의 다운로드를 위해 사용되었다. 이 메커니즘에서, 단일 HTTP 접속 및 전송이 전체 비디오 파일을 다운로드하는데 사용된다. 다운로드가 일어나는 것을 사용자가 지켜 보고, 전체 스트림-뷰잉 경험 (entire stream-viewing experience) 을 지원할 정도로 충분한 데이터가 버퍼링되었다고 그들이 느낄 때, 그들은 "플레이 (PLAY)" 를 눌러, 비디오를 디스플레이하기 시작한다. 플레이어는 일단 충분한 데이터가 다운로드되면 자동적으로 플레이아웃하기 시작하므로, 의사-스트리밍 경험 (pseudo-streaming experience) 을 제공할 수도 있다. 그러나, 이 방법은 사용자가 비디오를 특히, 저-용량 링크들 상에서 곧바로 보기를 원할 때, 문제점들을 초래한다. 또 다른 문제점은, 변하는 무선 환경에서, 적응적 다운로드가 아주 느린 속도로 갑자기 다운시프트하여, 비디오의 중간에 중단 (stalls) 을 초래한다는 점이다.

2005년 이후, 이들 문제점들을 해결하려고 시도하는, HTTP 를 통한 적응적 스트리밍을 구현하는 작업이 진행 중에 있다. 적응적 스트리밍 프로토콜들의 예들은 MSS (Microsoft Smooth Streaming), ALS (Apple Live Streaming), AHDS (Adobe HTTP Dynamic Streaming), 및 3GPP 표준, DASH (Dynamic Adaptive Streaming over HTTP) 를 포함한다. 2011년에, 저녁에, 피크 시간들에서, (MSS 에 기초한) Netflix 비디오 스트리밍 서비스는 비디오 패킷들을 고객 홈들로 전달하는 북미 인터넷 백홀 (backhaul) 의 30% 를 소비하였다.

적응적 스트리밍 방법들은 비디오를 HTML 웹 페이지와 매우 유사하게 편성한다. 예를 들어, DASH 에서, "비디오 웹 페이지" 는 비디오를 구성하는 "프래그먼트들 (fragments)" (서브-파일들, 또한 서브-세그먼트들로서 지칭됨) 의 모두를 참조하도록 정의된다. 프래그먼트는 일반적으로 2 초의 실시간 비디오 또는 오디오이며, 비디오의 경우 일반적으로 MPEG I-프레임 (본질적으로, 풀 (full) JPEG-인코딩된 화상) 으로 시작한다. H.264/AVC 에서, 이런 프레임들은 IDR (Instantaneous Decoder Refresh) 프레임들로서 지칭된다. DASH 에서, "비디오 웹 페이지" 는 "미디어 프리젠테이션 설명 (Media Presentation Description; MPD)" 으로서 지칭된다. 2-시간 비디오에 있어 MPD 는 3600 개의 비디오 URL (uniform resource locator) 들, 및 3600 개의 오디오 URL들을 참조할 것이며, 이들 각각은 플레이백될 때 2 초의 미디어에 대응할 수도 있다. 그리고, 비디오가 인코딩되는 각각의 비트-레이트에 대해 3600 개의 비디오 URL들이 제공될 수도 있음에 유의한다.

DASH 의 하나의 향상은 동일한 비디오가 여러 상이한 비트-레이트들에서 기술될 수도 있지만 플레이어가 비트-레이트들을 (예를 들어, 매 2 초 마다) 스위칭할 수 있다는 점이다. MPD 는 일반적으로 표현 (representation) 들로서 지칭되는, 동일한 비디오의 3 개 내지 8 개의 상이한 렌더링들을 기술한다. 인터넷이 혼잡할 때, 또는 터미널이 낮은-용량 링크 상에 있을 때, 낮은 비트 레이트 프래그먼트가 페치될 수도 있다. 인터넷이 혼잡하지 않고 터미널이 높은-용량 링크를 가질 때, 높은 비트 레이트 프래그먼트가 페치될 수도 있다. 일반적으로는, 단일 오디오 스트림이 페치되고, 어떤 비트 레이트 스위칭도 오디오에 대해 일어나지 않는다. 네트워크 또는 링크 상태들이 변할 때, 플레이어는 더 높은 또는 더 낮은 비트 레이트들에서 비디오 프래그먼트들을 페치함으로써 적응할 수도 있다. 플레이어는 일반적으로 프래그먼트의 경계에서 적응한다. 따라서, 플레이어는 인터넷 상의 변하는 혼잡 상태들에 동적으로 적응하여, 오디오 및 비디오 데이터 양자를 HTTP 를 통해 전송할 수도 있다. 8 개의 상이한 표현들이 제공되면, 총 3600*8 = 28,800 개의 프래그먼트들이 기점 서버 상에서 관리될 수도 있음에 유의한다.

HTTP 0.9 가 1993년에 도입된 이후, 매우 성공적이어서, 인터넷은 곧 HTTP 요청들로 채워졌다. 그 후 1997년에, HTTP 1.0 은 RFC 2068 에서 표준화되었으며, 캐싱을 포함하였다. 브라우저들은 오브젝트들을 캐싱하기 시작했으며, 그러나 또한, 연구자들은 HTTP 1.0 에서 새로운 캐싱 특성들을 이용하기 위해 투명한 HTTP 프록시 캐시 디바이스들을 개발하기 시작하였다. 프록시 캐시 디바이스는 HTTP GET 요청들을 감시하고 일반적으로 그 요청들을 변경 없이 포워딩한다. 프록시 캐시가 HTTP 응답을 20 분간 jpeg 화상 또는 주식 시세 상품 (stock quote good) 과 같은 ~5 HTTP "캐싱" 헤더들 중 하나 (콘텐츠가 긴 수명을 갖고 캐싱될 수 있다는 것을 의미함) 로 통지할 때, 프록시 캐시 디바이스는 캐싱가능한 응답을 저장하고, 동일한 또는 상이한 사용자가 그 콘텐츠를 추후에 요청할 때에 재생할 수도 있다. 네트워크 관리자는 모든 HTTP 트래픽을 그들의 프록시 캐시를 통해 라우팅하도록 스위치들 또는 라우터들을 재프로그래밍할 수도 있다.

게다가, (RFC 2616 에 규정된 바와 같은) HTTP 1.1 은 부분 GET 요청들 (partial GET requests) 을 가능하게 한다. 부분 GET 요청들은 목표 URL 뿐만 아니라, "Range:" 헤더와, 뒤이어서, 원하는 바이트 범위 (byte range) 를 나타내는 값들을 규정하는 정보를 포함한다. HTTP 1.1 에 의한 제공 (provision) 에도 불구하고, 모든 웹 브라우저들이 부분 GET 요청들의 사용을 구현하지는 않는다. 더욱이, 심지어 웹 브라우저들 (또는, 클라이언트 디바이스에 의해 실행되는 다른 애플리케이션들) 이 부분 GET 요청들을 구현할 때에도, 프록시 서버들, 프록시 캐시 디바이스들, 또는 다른 프록시 디바이스들과 같은 중간 네트워크 디바이스들은 종종, 꼭 클라이언트 디바이스에 의해 요청되는 부분이 아닌, 풀 파일을 취출하도록 구성된다.

프록시 디바이스들은 일반적으로 바이러스들 또는 다른 악의적인 네트워크 트래픽을 검출하기 위한 심층 패킷 검사, (동일한 데이터에 대한 다른 요청들에 응답하기 위한) 캐싱, 또는 전체 파일의 취출을 요구하는 다른 기능들과 같은, 네트워크 트래픽에 관련한 추가적인 액션들을 수행하도록 구성된다. 따라서, 이런 프록시 디바이스들은 범위 요청 (range request) 을 벗겨 내어 그 규정된 URL 에서 전체 파일을 취출하고, 이에 따라, 전체 취출된 파일을 요청하는 클라이언트 디바이스에 제공하려는 경향이 있다. 예를 들어, 어떤 바이러스 스캐닝 알고리즘들은 전체 파일을 스캐닝하는 것을 필요로 하며, 이 경우, 전체 파일을 다운로드하는 것이 필요하다. 그러나, (2 시간 영화와 같은) 비교적 큰 멀티미디어 파일에 있어, 요청되는 바이트 범위 대신 풀 파일을 취출하는 것은, 요청하는 클라이언트 디바이스에의 비교적 작은 바이트 범위의 송신에 대해 상당한 지연들을 부과할 수도 있다.

일반적으로, 본 개시물은 미디어 데이터를 네트워크를 통해 스트리밍하기 위해 바이트 범위 요청들을 서브밋 (submit) 하는 것에 관련된 기법들을 설명한다. 바이트 범위 요청들을 부분 GET 요청들을 이용하여 서브밋하는 대신, 본 개시물의 기법들은 요청되는 바이트 범위들을 HTTP GET 요청들의 URL들에 규정하는 것에 관련된다. 이 방법으로, 바이트 범위 요청이 "Range:" 헤더를 규정할 필요가 없어, 중간 프록시 캐시 디바이스들에 의한 원하지 않는 거동을 회피한다. 즉, 풀 파일 (full file) 을 취출하도록 구성되는 프록시 캐시 디바이스들은, 부분 GET 요청을 수신하는 것에 응답하여, 요청된 URL 의 부분 데이터를 단지 취출해야 한다. 그 요청된 URL 이 바이트 범위를 규정할 때, 취출된 데이터는 베이스 URL 에서 풀 파일보다 상당히 더 작아야 한다.

일 예에서, 멀티미디어 데이터를 취출하는 방법은, 소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현 (representation) 의 파일의 바이트 범위를 결정하는 단계, 소스 디바이스의 요건들에 따른 파일 및 바이트 범위를 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 URL 을 형성하는 단계, 및 형성된 URL 을 규정하는 GET 요청을 소스 디바이스에 발행하는 단계를 포함한다.

또 다른 예에서, 멀티미디어 데이터에 대한 정보를 취출하는 디바이스는, 하나 이상의 프로세서들을 포함하고, 그 하나 이상의 프로세서들은, 소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현의 파일의 바이트 범위를 결정하고, 소스 디바이스의 요건들에 따른 파일 및 바이트 범위를 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 URL 을 형성하며, 형성된 URL 을 규정하는 GET 요청을 소스 디바이스에 발행하도록 구성된다.

또 다른 예에서, 멀티미디어 데이터에 대한 정보를 취출하는 디바이스는, 소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현의 파일의 바이트 범위를 결정하는 수단, 소스 디바이스의 요건들에 따른 파일 및 바이트 범위를 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 URL 을 형성하는 수단, 및 형성된 URL 을 규정하는 GET 요청을 소스 디바이스에 발행하는 수단을 포함한다.

또 다른 예에서, 컴퓨터 프로그램 제품은, 명령들을 저장하고 있는 컴퓨터 판독가능 매체를 포함하고, 그 명령들은, 실행될 때, 멀티미디어 데이터를 취출하는 디바이스의 하나 이상의 프로세서들로 하여금, 소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현의 파일의 바이트 범위를 결정하게 하고, 소스 디바이스의 요건들에 따른 파일 및 바이트 범위를 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 URL 을 형성하게 하며, 형성된 URL 을 규정하는 GET 요청을 소스 디바이스에 발행하게 한다.

또 다른 예에서, 비디오 데이터에 대한 정보를 전송하는 방법은, 멀티미디어 콘텐츠에 대한 매니페스트 파일 (manifest file) 을 제공하는 단계로서, 매니페스트 파일은 URL (uniform resource locator) 템플릿 및 바이트 범위 템플릿을 규정하고, URL 템플릿 및 바이트 범위 템플릿은, URL 내에 바이트 범위 요청을 포함하도록 URL 을 형성하기 위한 템플릿을 제공하는, 그 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하는 단계, URL 템플릿 및 바이트 범위 템플릿에 따라 구성된 URL 을 포함하는 요청을 수신하는 단계로서, 요청의 URL 은 멀티미디어 콘텐츠의 표현의 바이트 범위를 규정하는, 그 요청을 수신하는 단계, 및 그 요청에 응답하여, 요청의 바이트 범위에 대응하는 표현의 멀티미디어 데이터를 출력하는 단계를 포함한다.

또 다른 예에서, 비디오 데이터에 대한 정보를 전송하는 디바이스는 하나 이상의 프로세서들을 포함하고, 그 하나 이상의 프로세서들은, 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하는 것으로서, 매니페스트 파일은 URL (uniform resource locator) 템플릿 및 바이트 범위 템플릿을 규정하고, URL 템플릿 및 바이트 범위 템플릿은, URL 내에 바이트 범위 요청을 포함하도록 URL 을 형성하기 위한 템플릿을 제공하는, 그 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하고, URL 템플릿 및 바이트 범위 템플릿에 따라 구성된 URL 을 포함하는 요청을 수신하는 것으로서, 요청의 URL 은 멀티미디어 콘텐츠의 표현의 바이트 범위를 규정하는, 그 요청을 수신하며, 그 요청에 응답하여, 요청의 바이트 범위에 대응하는 표현의 멀티미디어 데이터를 출력하도록 구성된다.

또 다른 예에서, 비디오 데이터에 대한 정보를 전송하는 디바이스는, 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하는 수단으로서, 매니페스트 파일은 URL (uniform resource locator) 템플릿 및 바이트 범위 템플릿을 규정하고, URL 템플릿 및 바이트 범위 템플릿은, URL 내에 바이트 범위 요청을 포함하도록 URL 을 형성하기 위한 템플릿을 제공하는, 그 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하는 수단, URL 템플릿 및 바이트 범위 템플릿에 따라 구성된 URL 을 포함하는 요청을 수신하는 수단으로서, 요청의 URL 은 멀티미디어 콘텐츠의 표현의 바이트 범위를 규정하는, 그 요청을 수신하는 수단, 및 그 요청에 응답하여, 요청의 바이트 범위에 대응하는 표현의 멀티미디어 데이터를 출력하는 수단을 포함한다.

또 다른 예에서, 컴퓨터 프로그램 제품은, 명령들을 저장하고 있는 컴퓨터 판독가능 저장 매체를 포함하고, 그 명령들은, 실행될 때, 멀티미디어 데이터를 제공하는 디바이스의 하나 이상의 프로세서들로 하여금, 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하게 하는 것으로서, 매니페스트 파일은 URL (uniform resource locator) 템플릿 및 바이트 범위 템플릿을 규정하고, URL 템플릿 및 바이트 범위 템플릿은, URL 내에 바이트 범위 요청을 포함하도록 URL 을 형성하기 위한 템플릿을 제공하는, 그 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하게 하고, URL 템플릿 및 바이트 범위 템플릿에 따라 구성된 URL 을 포함하는 요청을 수신하게 하는 것으로서, 요청의 URL 은 멀티미디어 콘텐츠의 표현의 바이트 범위를 규정하는, 그 요청을 수신하게 하며, 그 요청에 응답하여, 요청의 바이트 범위에 대응하는 표현의 멀티미디어 데이터를 출력하게 한다.

하나 이상의 예들의 세부 사항들이 첨부도면 및 아래의 상세한 설명에서 개시된다. 다른 특성들, 목적들, 및 이점들은 설명 및 도면들로부터, 그리고 청구항들로부터 명백히 알 수 있을 것이다.

도 1 은 네트워크를 통해 미디어 데이터를 스트리밍하는 기법들을 구현하는 예시적인 시스템을 예시하는 블록도이다.
도 2 는 도 1 의 네트워크의 부분을 형성하는 디바이스들의 예시적인 세트를 예시하는 블록도이다.
도 3 은 여러 콘텐츠 배포 네트워크 (content distribution network; CDN) 들을 포함하는 예시적인 시스템을 예시하는 블록도이다.
도 4 는 예시적인 멀티미디어 콘텐츠의 엘리먼트들을 예시하는 개념도이다.
도 5 는 멀티미디어 콘텐츠의 표현의 세그먼트에 대응할 수도 있는 예시적인 비디오 파일의 엘리먼트들을 예시하는 블록도이다.
도 6 은 URL 템플릿 데이터의 표시들을 제공하고, 그리고 클라이언트 디바이스에 의해 URL 템플릿 데이터를 이용하여 바이트 범위 요청들을 발생시키는 예시적인 방법을 예시하는 플로우차트이다.
도 7 은 URL 내에 바이트 범위를 규정하는 GET 요청을 발생시키는 예시적인 방법을 예시하는 플로우차트이다.
도 8 은 HTTP GET 요청이 중간 네트워크 디바이스를 통해 클라이언트 디바이스와 서버 디바이스 사이에서 교환되는 예시적인 방법을 예시하는 플로우차트이다.
도 9 는 멀티미디어 콘텐츠의 데이터를 취출할 CDN 을 결정하는 예시적인 방법을 예시하는 플로우차트이다.

일반적으로, 본 개시물은 네트워크를 통한, 오디오 및 비디오 데이터와 같은 멀티미디어 데이터의 스트리밍에 관련된 기법들을 설명한다. 본 개시물의 기법들은 DASH (Dynamic Adaptive Streaming over HTTP) 와 관련하여 사용될 수도 있다. 본 개시물은 네트워크 스트리밍과 관련하여 수행될 수도 있는 여러 기법들을 설명하며, 이 기법들 중 임의의 기법 또는 모두는 단독으로 또는 임의의 조합으로 구현될 수도 있다. 아래에서 더욱 자세히 설명하는 바와 같이, 네트워크 스트리밍을 수행하는 여러 디바이스들은 본 개시물의 기법들을 구현하도록 구성될 수도 있다.

DASH 및 네트워크를 통해 데이터를 스트리밍하는 유사한 기법들에 따르면, 멀티미디어 콘텐츠 (예컨대, 영화 또는 다른 미디어 콘텐츠, 이는 또한 오디오 데이터, 비디오 데이터, 텍스트 오버레이들, 또는 다른 데이터를 포함할 수도 있음) 는 다양한 방법들로, 그리고 다양한 특성들 (characteristics) 로 인코딩될 수도 있다. 콘텐츠 준비 디바이스는 동일한 멀티미디어 콘텐츠의 다수의 표현 (representation) 들을 형성할 수도 있다. 각각의 표현은 여러 코딩 및 렌더링 능력들을 가진 다양한 상이한 클라이언트 디바이스들에 의해 사용가능한 데이터를 제공하기 위해, 코딩 및 렌더링 특성들과 같은, 특성들의 특정 세트에 대응할 수도 있다. 더욱이, 여러 비트레이트들을 갖는 표현들은 대역폭 적응을 가능하게 할 수도 있다. 즉, 클라이언트 디바이스는 현재 이용가능한 대역폭의 양을 결정하고, 클라이언트 디바이스의 코딩 및 렌더링 능력들에 따라, 그 가용 대역폭의 양에 기초하여, 표현을 선택할 수도 있다.

일부 예들에서, 콘텐츠 준비 디바이스는 표현들의 세트가 공통 특성들의 세트를 갖는다는 것을 나타낼 수도 있다. 콘텐츠 준비 디바이스는 그 후 그 세트에서의 표현들이 대역폭 적응을 위해 사용될 수 있도록, 그 세트에서의 표현들이 또한 적응 세트 (adaptation set) 로서 지칭되는 적응 세트를 형성한다는 것을 나타낼 수도 있다. 즉, 세트에서의 표현들은 비트레이트가 상이하지만, 그렇지 않으면 동일한 특성들을 실질적으로 공유할 수도 있다. 이 방법으로, 클라이언트 디바이스는 멀티미디어 콘텐츠의 적응 세트들에 대해 공통 특성들의 여러 세트들을 결정하고, 그리고 클라이언트 디바이스의 코딩 및 렌더링 능력들에 기초하여 적응 세트를 선택할 수도 있다. 그 후, 클라이언트 디바이스는 대역폭 이용가능성에 기초하여, 그 선택된 적응 세트에서의 표현들 사이를 적응적으로 스위칭할 수도 있다.

표현들에 대한 데이터는 개개의 파일들로 분리될 수도 있다. 파일들의 각각은 특정의 URL (uniform resource locator) 에 의해 어드레스가능할 수도 있다. 클라이언트 디바이스는 그 파일을 취출하기 위해 특정의 URL 에 그 파일에 대한 GET 요청을 서브밋 (submit) 할 수도 있다. 본 개시물의 기법들에 따르면, 클라이언트 디바이스는 URL 경로 자체 내에, 예컨대, 대응하는 서버 디바이스에 의해 제공되는 URL 템플릿에 따라, 원하는 바이트 범위의 표시를 포함시킴으로써, GET 요청을 수정할 수도 있다. 본 개시물에서, 용어 "경로" 는 HTTP abs_path [RFC2616] 또는 HTTP rel_path [RFC2616][RFC2396] 을 나타낼 수도 있음에 유의한다. 바이트 범위는 오직 그 나타낸 바이트 범위가 소망되는 서버 디바이스에 대해서만 나타낸다.

이 방법으로, 본 개시물의 기법들은 종래의 부분 GET 요청들을 대체하고, 대신, URL 내에, 예컨대, URL 경로 자체 내에 원하는 바이트 범위를 규정하는 것을 포함한다. 예를 들어, 본 개시물의 기법에 따르면, 표현의 URL-어드레스가능한 파일의 특정의 바이트 범위가 소망된다는 결정시, 클라이언트 디바이스는 URL 경로 내에 원하는 바이트 범위를 규정함으로써 URL 에 대한 GET 요청을 구성할 수도 있다. 매니페스트 파일 생성자 (manifest file creator) 는 이러한 방법으로 URL들을 구성하는 템플릿을 제공할 뿐만 아니라, 템플릿이 요구되는지 또는 옵션적인지 여부에 관한 정보를 제공할 수도 있다. 게다가, 본 개시물의 기법에 따르면, 프록시 디바이스들 또는 다른 중간 네트워크 디바이스들은 수신된 부분 GET 요청들을 수정된 URL들로 변환하도록 구성될 수도 있다. 이 방법으로, 본 개시물의 기법들에 따르면, 부분 GET 요청들을 인식하도록 구성된 프록시 디바이스들은 업스트림 프록시 디바이스들이 부분 GET 요청을 풀 GET 요청으로 수정하는 것을 회피하기 위해, 부분 GET 요청들을 변환할 수도 있다. 더욱이, 본 개시물의 기법에 따르면, 서버 디바이스들은 부분 GET 요청들에 응답할 뿐만 아니라, 수정된 URL들에 응답하고, 그리고 파일의 바이트 범위들을 규정하는 이런 수정된 URL들을 구성하는 방법을 규정하도록 구성될 수도 있다.

본 개시물은 또한 일부 예들에서, URL 내에 명시적으로 규정된 바이트 범위들에 관련된 멀티미디어 콘텐츠의 특성들을 시그널링하는 기법들을 제공한다. 본 개시물은 "MustUseRangeURL" 로 라벨링된, MPD 파일의 부분을 형성하는 열거 속성 (enumerated attribute) 을 제공한다. 이 속성에 대응하는 필드에 대한 값은 클라이언트 디바이스가 URL 자체 내에 원하는 바이트 범위를 규정할 수도 있는지 (또는, 규정해야 하는지) 여부를 나타낸다. 본 개시물은 또한 "AllowedByteRanges" 로 라벨링된, MPD 파일의 부분을 형성하는 열거 속성을 제공한다. 요청가능한 바이트 범위들이 MPD 파일 내에, 표현의 세그먼트 인덱스 (SIDX) 박스 내에, 규정되거나 또는 규정되지 않을 수도 있다. AllowedByteRanges 속성은 클라이언트 디바이스가 MPD 파일, SIDX 박스, 또는 멀티미디어 콘텐츠의 다른 데이터 구조들에 의해 규정된 바와 같이, 바이트 범위들을 요청할 수 있는지 여부의 표시를 제공한다.

본 개시물은 바이트 범위가 어떻게 규정되는지를 나타내는 ByteRangeTemplate 필드를 추가로 제공한다. ByteRangeTemplate 필드는 $URL$ 필드, $StartByte$ 필드, 및 $EndByte$ 필드를 포함할 수도 있으며, 이들은 또한 바이트 범위를 규정하는 적절히-형성된 수정된 URL 에 따라 순서화될 수도 있다. ByteRangeTemplate 필드는 순방향-슬래시들 또는 마침표들 (periods) 과 같은 추가적인 캐릭터들, 또는 다른 ASCII 심볼들을 추가로 규정할 수도 있다. ByteRangeTemplate 을 이용하여, 클라이언트 디바이스 (또는, 프록시 디바이스) 는 ("Range:" 필드를 포함하는) 부분 GET 요청을, 본 개시물의 기법에 따라 "Range:" 필드의 사용 없이 바이트 범위를 규정하는 수정된 URL 로 변환할 수도 있다.

예를 들어, 웹 서버가 바이트 범위들을 이용하거나 또는 그 범위가 URL 내에 내장되어 있는 범위 요청들을 서빙함으로써, 멀티미디어 콘텐츠 (예컨대, 영화 "TRON") 를 제공한다고 가정한다. 이 예에서, 웹서버 (Webserver) 는 www.example.com 이다. 웹 서버는 멀티미디어 콘텐츠 "TRON:" 에 대한 MPD (또는, 매니페스트 파일) 에 다음 표시들을 제공할 수도 있다:

이 예에서, MPD 파일은 바이트 범위 템플릿이 URL 에 뒤이어서, 슬래시 및 원하는 바이트 범위의 시작 바이트가 따르며, 뒤이어서 또 다른 슬래시 및 원하는 바이트 범위의 종료 바이트가 따른다는 것을 나타낸다. MustUseRangeURL 은 바이트 범위 템플릿이 옵션적임을 나타내며, 이는 서버가 범위 요청들을 포함하는 수정된 URL들뿐만 아니라 HTTP 1.1 부분 GET 요청들에 응답할 것임을 의미하며, AllowedByteRanges 필드는 MPD 에 명시적으로 나타낸 오직 바이트 범위들만이 규정되도록 허용된다는 것을 나타낸다.

이 예에 계속해서, 종래의 URL 및 바이트 범위 (byte range) 는 다음 부분 GET 요청과 같이 HTTP 1.1 에 따라 표현될 수도 있다:

본 개시물의 기법들에 따르는 클라이언트 디바이스 (또는, 프록시 디바이스) 는 상기 부분 GET 요청을 수정하여 다음 수정된 URL 을 형성할 수도 있다:

일반적으로, 클라이언트 디바이스는 종래의 부분 GET 요청을 발생시키는 대신, 이 예시적인 요청을 발생시킬 수도 있다. 이 예에서, URL 은 명시적으로 (예의 목적들을 위해, 멀티미디어 콘텐츠에 대한 MPD 에 규정되는 것으로 가정되는) 원하는 바이트 범위를 규정한다.

본 개시물은 또한 URL 이 바이트 범위를 포함한다는 것을 나타내는 HTTP 에 대한 확장 헤더의 사용을 제안한다. 이것은 프록시 디바이스로 하여금, 프록시 디바이스가 그 요청을 제공한 클라이언트 디바이스에 대해 멀티미디어 콘텐츠에 대한 데이터를 미리 페치하도록, URL 이 바이트 범위를 포함하는 시점을 결정하게 할 수도 있다.

본 개시물은 또한 콘텐츠 배포 네트워크 (content distribution network; CDN) 또는 콘텐츠 서버 팜을 선택하는 기법들을 제공한다. 일부 예들에서, 클라이언트 디바이스는 그 요청의 보디 (body) BaseURL 에 포함된 POST 요청을 재지향 (redirection) URL 로 발행할 수도 있다. 재지향 서버 디바이스는 POST 를 수신하고 예컨대, 클라이언트 디바이스의 로케이션 브라우저 유형, 네트워크 지형도, 또는 아래에 설명한 바와 같은 다른 선택 기준들과 같은, 요청하는 클라이언트 디바이스의 특성들에 기초하여, BaseURL 에 대응하는 파일에 대한 요청을 선택된 CDN 에 발행할 수도 있다. 다른 예들에서, 선택 기준들은 시각, 라운드 트립 지연, 홉 수, 로케이션, 및 기타 등등과 같은 복수의 CDN들에 의해 규정될 수도 있다. 클라이언트 디바이스는 이들 기준들을 이용하여 CDN 을 선택할 수도 있다. 이 선택은 이 기준들에 기초하여, 또는 선택 기준들에 대응하는 네트워크 특성들을 측정함으로써 무작위로 이루어질 수도 있으며, 이들 기준들을 이용하여, CDN 을 결정론적으로 선택할 수 있다.

일반적으로, 본 개시물의 기법들은 특히, 멀티미디어 콘텐츠의 요청하는 부분들 (예컨대, 프래그먼트들 또는 서브-세그먼트들) 에 대해, 멀티미디어 데이터의 스트리밍에 관련되는 하나 이상의 문제들을 극복하는데 사용될 수도 있다. 이들 문제들은 모든 브라우저들이 바이트 범위 요청들을 구현하지는 않는다는 점을 포함한다. 바이트 범위가 URL 사양의 부분이 아니기 때문에 (실제로는, "Range:" 헤더가 URL 로부터 개별적으로 전송된 옵션적인 헤더이다), HTML 웹 페이지들은 바이트 범위들을 참조할 수 없으며, 따라서, 브라우저들이 바이트 범위 요청들을 구현할 필요가 없다. 바이트 범위 요청들을 구현하는 브라우저들에서, 이런 브라우저들은 비디오 플러그-인과 같은 플러그-인이 바이트-범위 요청을 발행하지 못하게 할 수도 있다. 이 문제는 Adobe PDF 리더 플러그-인과 같은 브라우저 플러그-인들의 설계에서 이슈로 되어 왔다. 브라우저를 위한 플러그-인들이 바이트-범위 요청들을 발행할 수 없으면, DASH 플러그-인은 MPEG 비디오 파일로부터 바이트들의 범위를 페치할 수 없을 것이다.

게다가, HTTP 범위 요청들을 협업하는 (cooperating) CDN들에게 발행함으로써, 풀 MPEG 비디오 파일들을 협업하는 CDN들에게 배포하여 부분 MPEG 파일들을 취출하는 것이 가능할 수도 있지만, 동일한 것을 프록시 캐시 디바이스들로 행하기에는 용이하지 않다. 프록시 캐시 디바이스들은 바이트 범위 요청들을 구현하도록 요구되지 않는다. 여러 프록시 캐시 디바이스들은 일반적으로 수백의 상이한 조직들에 의해 관리되고, 수십의 상이한 구현예들이 존재하므로, 모든 프록시 캐시 디바이스들이 바이트 범위 요청들을 구현하는 것을 보장하는 것이 불가능하다. HTTP 1.1 에서, 바이트 범위 요청에 풀 파일로 응답하는 것은 합법적이다. 이것은 브라우저가 바이트 범위 요청을 무시하거나, 또는 그 요청이 의도적으로 이루어질 수도 있기 때문일 수도 있다. 프록시 캐시가 바이러스 스캐너를 구현하면, 스캐너는 콘텐츠를 바이트-범위 결과로서 서빙하기 전에, 모든 것들을 취출하여 바이러스-스캐닝하기 위해, 바이트-범위 요청을 풀-파일 요청으로 변환할 것이다. 오늘날 대표적인 웹 요청은 3 개 이상의 프록시 디바이스들 (기점 서버 프록시 캐시, 국내 백홀 프록시, 로컬 ISP 프록시) 을 통과할 것이며, 임의의 단일 프록시 디바이스 (또는, 프록시 디바이스들 모두) 는 바이트 범위 요청을 무효화하도록 구성될 것이다.

더욱이, 비교적 적은 프록시 캐시 디바이스들이 예컨대, 통상적인 비디오의 2-시간 기간에 걸쳐서 일어나는 일련의 바이트-범위 요청들로부터 MPEG 파일을 재구성하기에는 너무 복잡하다. 아주 적은 브라우저들 및 오직 브라우저 플러그-인들의 서브세트가 바이트-범위 요청들을 발행할 수 있을 때, 파일 재구성은 구현하기가 어렵다. 캐시가 (a) 바이트 범위 요청들을 전혀 캐싱하지 않거나 또는 (b) 오직 주어진 파일로부터의 가장 최근 바이트-범위 요청만을 유지하거나, 또는 (c) 각각의 별개의 바이트-범위 요청을 별개의 파일로서 처리할 가능성이 더 크다. 마지막의 경우, 이것은 2-초 프래그먼트들을 가진 10 개의 스트림들을 가진 2-시간 영화에 대해 프록시 캐시에서 72,000 개까지의 프래그먼트들이 발생하게 될 것이다. 이 경우, 각각의 영화에 대해 수천의 많은 프래그먼트들을 관리하는 오버헤드가 캐싱하는데 너무 비효율적이고 부담스럽게 될 것이다.

본 개시물의 기법들은 브라우저에 의해 페치되는 URL 내의 바이트-범위 요청들을 발행하기 위해, 3GPP DASH 프로토콜에 따르는 멀티미디어 콘텐츠와 같은 멀티미디어 콘텐츠의 스트리밍을 위한 메커니즘을 포함한다. 이들 기법들은 또한 일부 예들에서, 바이트 범위가 URL 에 맵핑될 수 있는 방법, 템플릿의 사용이 요구되는지 또는 단지 허용되는지 (즉, 옵션적인지) 여부를 나타내는 방법, URL 에 내장된 바이트 범위가 있음을 나타내는, 클라이언트 디바이스로부터의 데이터를 기점 서버들 및 프록시 디바이스들에 제공하는 방법, 및 BaseURL 및/또는 ByteRangeTemplateURL 에 대한 CDN 유형에 기초하여 템플릿을 선택하는 방법을 정의하는 일반 템플릿 (generic template) 을 포함한다. 이들 기법들의 임의의 기법 또는 모두는 단독으로 또는 조합하여 사용될 수도 있다.

미디어 콘텐츠의 표현들의 세그먼트들과 같은, 비디오 파일들은 ISO 베이스 미디어 파일 포맷, 스케일러블 비디오 코딩 (SVC) 파일 포맷, AVC (Advanced Video Coding) 파일 포맷, 3GPP (3rd Generation Partnership Project) 파일 포맷, 및/또는 멀티뷰 비디오 코딩 (MVC) 파일 포맷, 또는 다른 유사한 비디오 파일 포맷들 중 임의의 포맷에 따라 캡슐화된 비디오 데이터에 따를 수도 있다.

ISO 베이스 미디어 파일 포맷은 미디어의 교환, 관리, 편집, 및 프리젠테이션을 용이하게 하는 유연하고 확장가능한 포맷으로 프리젠테이션을 위한 타임드 미디어 정보 (timed media information) 를 포함하도록 설계된다. ISO 베이스 미디어 파일 포맷 (ISO/IEC 14496-12:2004) 은 시간-기반의 미디어 파일들에 대한 일반 구조를 정의하는 MPEG-4 파트-12 에 규정되어 있다. ISO 베이스 미디어 파일 포맷은 H.264/MPEG-4 AVC 비디오 압축에 대한 지원이 정의된 AVC 파일 포맷 (ISO/IEC 14496-15), 3GPP 파일 포맷, SVC 파일 포맷, 및 MVC 파일 포맷과 같은 계열에서 다른 파일 포맷들에 대한 기준으로서 사용된다. 3GPP 파일 포맷 및 MVC 파일 포맷은 AVC 파일 포맷의 확장판들이다. ISO 베이스 미디어 파일 포맷은 시청각 프리젠테이션들과 같은 미디어 데이터의 타임드 시퀀스들에 대한 타이밍, 구조, 및 미디어 정보를 포함한다. 파일 구조는 객체지향적일 수도 있다. 파일은 기본적인 오브젝트들로 매우 간단히 분해될 수 있으며, 오브젝트들의 구조는 그들의 유형으로부터 추론된다.

ISO 베이스 미디어 파일 포맷 (및, 그 확장판들) 에 따르는 파일들은 일련의 오브젝트들, 소위 "박스들 (boxes)" 로서 형성될 수도 있다. ISO 베이스 미디어 파일 포맷의 데이터는 박스들에 포함될 수도 있어서, 그 파일 내에 어떤 다른 데이터도 포함될 필요가 없고 데이터가 그 파일 내에서 박스들 외부에 있을 필요가 없다. 이것은 특정의 파일 포맷에 의해 요구되는 임의의 초기 서명 (initial signature) 을 포함한다. "박스" 는 고유한 유형 식별자 및 길이에 의해 정의되는 객체지향적인 빌딩 블록일 수도 있다. 일반적으로, 프리젠테이션은 하나의 파일에 포함되며, 미디어 프리젠테이션은 독립적 (self-contained) 이다. 영화 컨테이너 (영화 박스) 는 미디어의 메타데이터를 포함하며, 비디오 및 오디오 프레임들은 미디어 데이터 컨테이너에 포함될 수도 있으며, 다른 파일들에 있을 것이다.

표현 (모션 시퀀스) 은 종종 세그먼트들로서 지칭되는 여러 파일들에 포함될 수도 있다. 타이밍 및 프레이밍 (포지션 및 사이즈) 정보는 일반적으로 ISO 베이스 미디어 파일에 있으며, 보조 파일들은 본질적으로 임의의 포맷을 이용할 수도 있다. 이 프리젠테이션은 프리젠테이션을 포함하는 시스템에 '로컬'일 수도 있거나, 또는 네트워크 또는 다른 스트림 전달 메커니즘을 통해 제공될 수도 있다.

미디어가 스트리밍 프로토콜을 통해 전달될 때, 미디어는 그 파일에 나타내어지는 방법으로부터 변환될 필요가 있을 수도 있다. 이것의 일 예는 미디어가 실시간 전송 프로토콜 (Real-time Transport Protocol; RTP) 을 통해 송신될 때이다. 그 파일에서, 예를 들어, 비디오의 각각의 프레임은 파일-포맷 샘플로서 인접하게 저장된다. RTP 에서, 사용되는 코덱에 특정된 패킷화 규칙들 (rules) 은 이들 프레임들을 RTP 패킷들에 배치하도록 지켜져야 한다. 스트리밍 서버는 이런 패킷화를 런-타임에서 계산하도록 구성될 수도 있다. 그러나, 스트리밍 서버들의 보조를 위한 지원이 존재한다.

본 개시물의 기법들은 HTTP 스트리밍과 같은 네트워크 스트리밍 프로토콜들에, 예컨대, HTTP 를 통한 동적 적응적 스트리밍 (DASH) 에 따라, 적용가능할 수도 있다. HTTP 스트리밍에서, 빈번하게 사용되는 동작들은 GET 및 부분 GET 을 포함한다. GET 동작은 주어진 URL (uniform resource locator) 또는 다른 식별자, 예컨대, URI 와 연관되는 전체 파일을 취출한다. 부분 GET 동작은 바이트 범위를 입력 파라미터로서 수신하고, 수신된 바이트 범위에 대응하는 파일의 연속적인 개수의 바이트들을 취출한다. 따라서, 부분 GET 동작이 하나 이상의 개개의 영화 프래그먼트들을 취득하기 때문에, 영화 프래그먼트들이 HTTP 스트리밍에 제공될 수도 있다. 영화 프래그먼트에서, 상이한 트랙들의 여러 트랙 프래그먼트들이 있을 수 있다는 점에 유의한다. HTTP 스트리밍에서, 미디어 표현은 클라이언트에 액세스가능한 데이터의 구조화된 컬렉션일 수도 있다. 클라이언트는 미디어 데이터 정보를 요청하고 다운로드하여, 스트리밍 서비스를 사용자에게 제시할 수도 있다.

HTTP 스트리밍을 이용하여 3GPP 데이터를 스트리밍하는 예에서, 멀티미디어 콘텐츠의 비디오 및/또는 오디오 데이터에 대해 다수의 표현들이 있을 수도 있다. 이런 표현들의 매니페스트는 미디어 프리젠테이션 설명 (Media Presentation Description; MPD) 데이터 구조로 정의될 수도 있다. 미디어 표현은 HTTP 스트리밍 클라이언트 디바이스에 액세스가능한 데이터의 구조화된 컬렉션에 대응할 수도 있다. HTTP 스트리밍 클라이언트 디바이스는 미디어 데이터 정보를 요청하고 다운로드하여, 스트리밍 서비스를 클라이언트 디바이스의 사용자에게 제시할 수도 있다. 미디어 표현은 MPD 데이터 구조로 기술될 수도 있으며, MPD 의 업데이트들을 포함할 수도 있다.

각각의 기간은 동일한 미디어 콘텐츠에 대해 하나 이상의 표현들을 포함할 수도 있다. 표현은 오디오 또는 비디오 데이터의 다수의 대안적인 인코딩된 버전들 중 하나일 수도 있다. 표현들은 인코딩 유형들과 같은 여러 특성들에 의해, 예컨대, 비디오 데이터에 대한 비트레이트, 해상도, 및/또는 코덱과, 오디오 데이터에 대한 비트레이트, 언어, 및/또는 코덱에 따라 상이할 수도 있다. 용어 표현 (representation) 은 멀티미디어 콘텐츠의 특정의 기간에 대응하며 특정의 방법으로 인코딩된 인코딩된 오디오 또는 비디오 데이터의 섹션을 지칭하기 위해 사용될 수도 있다.

특정의 기간의 표현들이 그룹에 할당될 수도 있으며, 이 그룹은 MPD 에서 그룹 속성으로 나타낼 수도 있다. 동일한 그룹에서의 표현들은 일반적으로 서로에 대해 대안으로서 간주된다. 예를 들어, 특정의 기간에 대한 비디오 데이터의 각각의 표현은 동일한 그룹에 할당될 수도 있어서, 대응하는 기간 동안 멀티미디어 콘텐츠의 비디오 데이터를 디스플레이하기 위해 표현들 중 임의의 표현이 디코딩을 위해 선택될 수 있다. 하나의 기간 내 미디어 콘텐츠는 일부 예들에서, 존재 한다면, 그룹 0 으로부터의 하나의 표현, 또는 각각의 논-제로 그룹으로부터의 최대 하나의 표현의 조합으로 표현될 수도 있다. 기간의 각각의 표현에 대한 타이밍 데이터는 그 기간의 시작 시간에 대해 표현될 수도 있다.

표현은 하나 이상의 세그먼트들을 포함할 수도 있다. 각각의 표현은 초기화 세그먼트를 포함할 수도 있거나, 또는 표현의 각각의 세그먼트는 자기-초기화 (self-initializing) 할 수도 있다. 존재할 경우, 초기화 세그먼트는 그 표현에 액세스하기 위한 초기화 정보를 포함할 수도 있다. 일반적으로, 초기화 세그먼트는 미디어 데이터를 포함하지 않는다. 세그먼트는 URL (uniform resource locator) 과 같은 식별자에 의해 고유하게 참조될 수도 있다. MPD 는 각각의 세그먼트에 대한 식별자들을 제공할 수도 있다. 일부 예들에서, MPD 는 또한 바이트 범위들을 범위 속성의 유형으로 제공할 수도 있으며, 이것은 URL 또는 URI 에 의해 액세스가능한 파일 내 세그먼트에 대한 데이터에 대응할 수도 있다.

각각의 표현은 또한 하나 이상의 미디어 컴포넌트들을 포함할 수도 있으며, 여기서, 각각의 미디어 컴포넌트는 오디오, 비디오, 및/또는 타임드 텍스트 (예컨대, 폐쇄 자막에 대해) 와 같은 하나의 개개의 미디어 유형의 인코딩된 버전에 대응할 수도 있다. 미디어 컴포넌트들은 하나의 표현 내에서 연속되는 미디어 세그먼트들의 경계들에 걸쳐 시간-연속적일 수도 있다. 따라서, 표현은 개개의 파일 또는 세그먼트들의 시퀀스에 대응할 수도 있으며, 세그먼트들 각각은 동일한 코딩 및 렌더링 특성들을 포함할 수도 있다.

본 개시물의 기법들은, 일부 예들에서, 하나 이상의 이점들을 제공할 수도 있다. 예를 들어, 이들 기법들은 중간 프록시 노드들이 바이트 범위 응답들을 적절히 캐싱하게 할 수도 있다. 이들 기법들은 비록 프록시 노드들이 요청되는 바이트 범위들을 캐싱하도록 구성되지 않고 전체 파일을 취출하도록 구성되더라도, 프록시 노드들이 요청되는 바이트 범위들을 적절히 캐싱하도록 할 수도 있다. 이런 적절한 캐싱을 가능하게 하기 위해, 바이트 범위는 URL 의 파일 경로 부분에 포함될 수도 있다. 바이트 범위를 파일 경로에 포함시킴으로써, 정확히 동일한 바이트 범위에 대한 미래의 요청들이 (URL 파일 경로를 키로서 이용하여) 적절히 탐색되어, 캐시 "히트 (hit)" 를 발생시킬 수도 있다. 이것은 탐색이 일반적으로 URL를 통해 오직 수행되기 (그리고, Range: 헤더를 탐색 키로서 포함하지 않기) 때문에, 일어날 수도 있다.

이들 기법들은 또한 기점 서버가 2-초 프래그먼트 당 하나의 파일 대신, 표현 당 하나의 파일을 이용하여 (일반적으로 3 내지 8 개인) 비디오 표현들을 저장하게 하면서도, 동시에 이들 파일들이 중간 노드들에 의해 캐싱될 수 있게 할 수도 있다. 이것은 기점 서버 상의 파일들의 개수를 9600 개 내지 28,800 개로부터 아래로 3 개 내지 8 개까지 감소시킬 수도 있으며, 기점 서버를 비디오 파일들을 저장하고 취출할 때 상당히 더욱 효율적으로 될 수도 있다.

더욱이, 이들 기법들은 바이트 범위들을 HTTP GET 요청의 URL 에 포함시키는데 사용되는 방법들에 따라 구성된 캐싱 서버들 (종종, 콘텐츠-배포 프록시들) 에 이점들을 제공할 수도 있다. 이들 서버들이 요청을 인식할 수 있으면, 그들은 꼭 기점 서버처럼, 바이트 범위 프래그먼트들을 재어셈블링하고 2-시간 비디오에 대해 3 개 내지 8 개의 파일들을 저장할 수 있다. 이 맞춤-캐싱 및 취출 정책을 달성하기 위해 이들 중간 프록시들 상에 "콘텐츠-특정의 애플리케이션들" 을 전개하는 것은 콘텐츠 배포 네트워크들에 있어 일반적이다. 따라서, 이것은 개방된 인터넷에서 매우 실질적이고 실현가능한 이점이다.

더욱이, 이들 기법들은 하나의 비디오가 여러 상이한 콘텐츠 배포 네트워크들에 의해 캐싱될 때 이점들을 제공할 수도 있다. "콘텐츠-특정의 애플리케이션들" 의 상이한 정책들 또는 상이한 능력들로 인해, URL 내 바이트 범위 요청의 정확한 패턴은 상이한 콘텐츠 배포 네트워크들에 대해 상이할 필요가 있을 수도 있다. 본 개시물에서 설명하는 기법들은 쉽고 자연스러운 방법으로 이를 촉진할 수도 있으며, 클라이언트 디바이스로 하여금 상이한 콘텐츠 배포 네트워크들에 대해 바이트 범위 요청들을 상이하게 내장하게 할 수도 있다.

도 1 은 네트워크를 통해 미디어 데이터를 스트리밍하는 기법들을 구현하는 예시적인 시스템 (10) 을 예시하는 블록도이다. 이 예에서, 시스템 (10) 은 콘텐츠 준비 디바이스 (20), 서버 디바이스 (60), 및 클라이언트 디바이스 (40) 를 포함한다. 클라이언트 디바이스 (40) 및 서버 디바이스 (60) 는 네트워크 (74) 에 의해 통신가능하게 커플링되며, 이 네트워크는 인터넷을 포함할 수도 있다. 일부 예들에서, 콘텐츠 준비 디바이스 (20) 및 서버 디바이스 (60) 는 또한 네트워크 (74) 또는 또 다른 네트워크에 의해 커플링될 수도 있으며, 또는 직접 통신가능하게 커플링될 수도 있다. 일부 예들에서, 콘텐츠 준비 디바이스 (20) 및 서버 디바이스 (60) 는 동일한 디바이스를 포함할 수도 있다. 일부 예들에서, 콘텐츠 준비 디바이스 (20) 는 준비된 콘텐츠를 서버 디바이스 (60) 를 포함한, 복수의 서버 디바이스들로 배포할 수도 있다. 이와 유사하게, 클라이언트 디바이스 (40) 는 일부 예들에서 서버 디바이스 (60) 를 포함한, 복수의 서버 디바이스들과 통신할 수도 있다.

아래에서 더욱 자세히 설명하는 바와 같이, 콘텐츠 준비 디바이스 (20), 서버 디바이스 (60), 및 클라이언트 디바이스 (40) 중 임의의 디바이스 또는 모두는 본 개시물의 대응하는 기법들을 수행하도록 구성될 수도 있다. 예를 들어, 서버 디바이스 (60) 및/또는 콘텐츠 준비 디바이스 (20) 는 일반 템플릿을 정의하고 예컨대, 클라이언트 디바이스 (40) 로부터의 요청에 응답하여, 데이터를 클라이언트 디바이스 (40) 로 전송함으로써, 예컨대, 서버 디바이스 (60) 로부터 데이터를 요청하기 위해 클라이언트 디바이스 (40) 에게 어떻게 바이트 범위들을 URL 에 맵핑할 지를 통지할 수도 있다. 이와 유사하게, 클라이언트 디바이스 (40) 는 URL 로부터 데이터를 취출하도록 요청을 서브밋할 수도 있으며, 여기서, 그 요청의 URL 은 일반 템플릿에 따라 요청된 바이트 범위를 포함한다. 더욱이, 서버 디바이스 (60) 및/또는 콘텐츠 준비 디바이스 (20) 는 템플릿의 사용이 요구되는지 또는 옵션적인지 여부를 나타내는 정보를 클라이언트 디바이스 (40) 에 제공할 수도 있다.

게다가, 클라이언트 디바이스 (40) 는 중간 네트워크 디바이스들에게 URL 내에 내장된 바이트 범위가 있다는 것을 통지하는 데이터를 중간 네트워크 디바이스들 (도 1 에 미도시) 에 제공할 수도 있다. 중간 네트워크 디바이스들은 프록시 디바이스들, 데이터를 캐싱 또는 검사하도록 구성된 라우터들 등을 포함할 수도 있으며, 도 2 에 나타낸 바와 같이, 아래에서 더 자세히 설명된, 네트워크 (74) 내에 포함될 수도 있다. 더욱이, 클라이언트 디바이스 (40) 는 매니페스트 파일을 이용하여, 데이터를 요청할 콘텐츠 배포 네트워크 (CDN) 를 선택하는 기법들을 결정할 수도 있다. 서버 디바이스 (60) 는 CDN 에 포함될 수도 있는 서버 디바이스의 일 예를 나타낸다. 다른 서버 디바이스들 또는 중간 네트워크 디바이스들은 예컨대, 도 4 에 나타낸 바와 같이, 아래에서 더 자세히 설명된, 다른 CDN들 내에 포함될 수도 있다. 일반적으로, CDN 은 (HTML 매니페스트 파일 또는 DASH MPD 로 된) 매니페스트 파일을 생성하는 엔터티에 의해 일반적으로 선택되며 구성된다. HTML 의 경우에, CDN 선택은 URL들 내 호스트네임 (hostname) 을 변경함으로써 달성될 수도 있다. DASH 의 경우, CDN 은 본 개시물의 기법들에 따라, URL들 내 호스트네임의 조합 및 CDN URL-패턴 발생에 의해 선택될 수도 있다. 본 개시물의 기법들에 따르면, 각각의 CDN 은 CDN 에 특정된 URL 자체 내에 바이트 범위 요청들을 발생시키기 위한 템플릿을 규정할 수도 있다.

콘텐츠 준비 디바이스 (20) 는, 도 1 의 예에서, 오디오 소스 (22) 및 비디오 소스 (24) 를 포함한다. 오디오 소스 (22) 는 예를 들어, 오디오 인코더 (26) 에 의해 인코딩되는 캡처된 오디오 데이터를 나타내는 전기 신호들을 발생시키는 마이크로폰을 포함할 수도 있다. 이의 대안으로, 오디오 소스 (22) 는 이전에 기록된 오디오 데이터를 저장하는 저장 매체, 컴퓨터화된 신시사이저와 같은 오디오 데이터 발생기, 또는 오디오 데이터의 임의의 다른 소스를 포함할 수도 있다. 비디오 소스 (24) 는 비디오 인코더 (28) 에 의해 인코딩되는 비디오 데이터를 발생시키는 비디오 카메라, 이전에 기록된 비디오 데이터로 인코딩된 저장 매체, 컴퓨터 그래픽스 소스와 같은 비디오 데이터 발생 유닛, 또는 비디오 데이터의 임의의 다른 소스를 포함할 수도 있다. 콘텐츠 준비 디바이스 (20) 는 모든 예들에서 반드시 서버 디바이스 (60) 에 통신가능하게 커플링될 필요는 없지만, 그러나, 멀티미디어 콘텐츠를 서버 디바이스 (60) 에 의해 판독되는 별개의 매체에 저장할 수도 있다.

미가공 오디오 및 비디오 데이터는 아날로그 또는 디지털 데이터를 포함할 수도 있다. 아날로그 데이터는 오디오 인코더 (26) 및/또는 비디오 인코더 (28) 에 의해 인코딩되기 전에 디지털화될 수도 있다. 오디오 소스 (22) 는 대화 참가자가 말하고 있는 동안에 대화 참가자로부터 오디오 데이터를 획득할 수도 있으며, 비디오 소스 (24) 는 대화 참가자의 비디오 데이터를 동시에 획득할 수도 있다. 다른 예들에서, 오디오 소스 (22) 는 저장된 오디오 데이터를 포함하는 컴퓨터 판독가능 저장 매체를 포함할 수도 있으며, 비디오 소스 (24) 는 저장된 비디오 데이터를 포함하는 컴퓨터 판독가능 저장 매체를 포함할 수도 있다. 이 방법으로, 본 개시물에서 설명하는 기법들은 라이브, 스트리밍, 실시간 오디오 및 비디오 데이터에, 또는 아카이브된, 미리 기록된 오디오 및 비디오 데이터에 적용될 수도 있다.

비디오 프레임들에 대응하는 오디오 프레임들은, 일반적으로 비디오 프레임들 내에 포함된, 비디오 소스 (24) 에 의해 캡처된 비디오 데이터와 동시에 오디오 소스 (22) 에 의해 캡처된 오디오 데이터를 포함하는 오디오 프레임들이다. 예를 들어, 대화 참가자가 일반적으로 말하여 오디오 데이터를 발생시키는 동안에, 오디오 소스 (22) 는 오디오 데이터를 캡처하고, 즉, 오디오 소스 (22) 가 오디오 데이터를 캡처하고 있는 동안에, 비디오 소스 (24) 는 대화 참가자의 비디오 데이터를 동시에 캡처한다. 그러므로, 오디오 프레임은 하나 이상의 특정의 비디오 프레임들에 시간적으로 대응할 수도 있다. 따라서, 비디오 프레임에 대응하는 오디오 프레임은 일반적으로, 오디오 데이터 및 비디오 데이터가 동시에 캡처되었으며 오디오 프레임 및 비디오 프레임이 동시에 캡처된 오디오 데이터 및 비디오 데이터를 각각 포함하는 상황에 대응한다.

오디오 인코더 (26) 는 일반적으로 인코딩된 오디오 데이터의 스트림을 발생시키지만, 비디오 인코더 (28) 는 인코딩된 비디오 데이터의 스트림을 발생시킨다. 데이터 (오디오이든 또는 비디오이든) 의 각각의 개개의 스트림은 기본 스트림으로서 지칭될 수도 있다. 기본 스트림은 표현의 단일의, 디지털적으로 코딩된 (가능한 한, 압축된) 컴포넌트이다. 예를 들어, 표현의 코딩된 비디오 또는 오디오 부분은 기본 스트림일 수 있다. 기본 스트림은 비디오 파일 내에 캡슐화되기 전에 패킷화 기본 스트림 (packetized elementary stream; PES) 으로 변환될 수도 있다. 동일한 표현 내에서, 스트림 ID 는 하나의 기본 스트림에 속하는 PES-패킷들을 다른 패킷들과 식별하는데 사용될 수도 있다. 기본 스트림의 데이터의 기본적인 유닛은 패킷화 기본 스트림 (PES) 패킷이다. 따라서, 코딩된 비디오 데이터는 일반적으로 기본 비디오 스트림들에 대응한다. 이와 유사하게, 오디오 데이터는 하나 이상의 각각의 기본 스트림들에 대응한다.

많은 비디오 코딩 표준들에서와 같이, H.264/AVC 는 구문, 시맨틱스 (semantics), 및 에러없는 비트스트림들을 위한 디코딩 프로세스를 정의하며, 이들 중 임의의 것은 특정 프로파일 또는 레벨에 따른다. H.264/AVC 는 인코더를 규정하지 않으나, 인코더는 발생된 비트스트림들이 디코더에 대해 표준에 부합한다는 것을 보장할 임무가 있다. 비디오 코딩 표준의 상황에서, "프로파일" 은 알고리즘들의 서브세트, 특성들, 또는 툴들 및 툴들에 적용하는 제약들에 대응한다. H.264 표준에 의해 정의된 바와 같이, 예를 들어, "프로파일" 은 H.264 표준에 의해 규정된 전체 비트스트림 구문의 서브세트이다. "레벨" 은 화상들의 해상도, 비트 레이트, 및 매크로블록 (MB) 프로세싱 레이트에 관련되는, 예를 들어, 디코더 메모리 및 계산과 같은 디코더 리소스 소비의 제한들에 대응한다. 프로파일은 profile_idc (프로파일 표시자) 값으로 시그널링될 수도 있는 한편, 레벨은 level_idc (레벨 표시자) 값으로 시그널링될 수도 있다.

H.264 표준은 예를 들어, 주어진 프로파일의 구문에 의해 부과되는 바운드들 내에서, 디코딩된 화상들의 규정된 사이즈와 같은, 비트스트림 내의 구문 엘리먼트들에 의해 취해진 값들에 따라, 인코더들 및 디코더들의 성능의 큰 변화를 여전히 필요로 할 수 있다는 것을 인정한다. H.264 표준은 추가로 많은 애플리케이션들에서, 특정의 프로파일 내 구문의 모든 가정 용법들을 처리할 수 있는 디코더를 구현하는 것은 유용하지도 경제적이지도 않다는 것을 인정한다. 따라서, H.264 표준은 "레벨" 을 비트스트림 내의 구문 엘리먼트들의 값들에 부과되는 규정된 제약들의 세트로서 정의한다. 이들 제약들은 값들에 관한 단순 한계들일 수도 있다. 이의 대안으로, 이들 제약들은 값들의 산술적 조합들 (예컨대, 화상 폭 × 화상 높이 × 초당 디코딩된 화상들의 개수) 에 관한 제약들의 형태를 취할 수도 있다. H.264 표준은 추가로 개개의 구현예들이 각각의 지원된 프로파일에 대해 상이한 레벨을 지원할 수도 있다는 것을 제공한다. 멀티미디어 콘텐츠의 여러 표현들이, H.264 내에서 코딩의 여러 프로파일들 및 레벨들을 고려할 뿐만 아니라, 차기 HEVC (High Efficiency Video Coding) 표준과 같은 다른 코딩 표준들을 고려하기 위해, 제공될 수도 있다.

프로파일에 따르는 디코더는 통상 프로파일에 정의된 모든 특성들을 지원한다. 예를 들어, 코딩 특성으로서, B-화상 코딩은 H.264/AVC 의 베이스라인 프로파일에서 지원되지 않지만, H.264/AVC 의 다른 프로파일들에서 지원된다. 특정의 레벨에 따르는 디코더는 디코딩 그 레벨에 정의된 제한들을 넘어서 리소스들을 요구하지 않는 임의의 비트스트림을 디코딩가능해야 한다. 프로파일들 및 레벨들의 정의들은 해석 능력에 도움이 될 수도 있다. 예를 들어, 비디오 송신 동안, 프로파일 및 레벨 정의들의 쌍은 전체 송신 세션에 대해 협상되어 합의될 수도 있다. 더욱 구체적으로는, H.264/AVC 에서, 레벨은 예를 들어, 프로세싱될 필요가 있는 블록들의 개수, 디코딩된 화상 버퍼 (DPB) 사이즈, 코딩된 화상 버퍼 (CPB) 사이즈, 수직 모션 벡터 범위, 2 개의 연속되는 MB들 당 모션 벡터들의 최대 개수, 및 B-블록이 8 x 8 픽셀들 미만의 서브-블록 파티션들을 가질 수 있는지 여부에 관한 제한들을 정의할 수도 있다. 이 방법으로, 디코더는 디코더가 비트스트림을 적절히 디코딩할 수 있는지 여부를 결정할 수도 있다.

ITU-T H.261, H.262, H.263, MPEG-1, MPEG-2, H.264/MPEG-4 파트 10, 및 차기 HEVC (High Efficiency Video Coding) 표준과 같은 비디오 압축 표준들은 시간 리던던시를 감소시키기 위해 모션 보상된 시간 예측을 이용한다. 비디오 인코더 (28) 와 같은 인코더는 일부 이전에 인코딩된 화상들 (또한, 본원에서 프레임들로서 지칭함) 로부터의 모션 보상되는 예측을 이용하여, 모션 벡터들에 따라 현재의 코딩된 화상들을 예측할 수도 있다. 대표적인 비디오 코딩에서는 3 개의 주요 화상 유형들이 있다. 그들은 인트라 코딩된 화상 ("I-화상들" 또는 "I-프레임들"), 예측된 화상들 ("P-화상들" 또는 "P-프레임들") 및 양방향 예측된 화상들 ("B-화상들" 또는 "B-프레임들") 이다. P-화상들은 시간 순서로 현재의 화상 이전의 참조 화상을 이용할 수도 있다. B-화상에서, B-화상의 각각의 블록은 하나 또는 2 개의 참조 화상들로부터 예측될 수 있다. 이들 참조 화상들은 시간 순서로 현재의 화상 전후에 로케이트될 것이다.

파라미터 세트들은 일반적으로 시퀀스 파라미터 세트들 (sequence parameter sets; SPS) 에 시퀀스-계층 헤더 정보를, 그리고, 화상 파라미터 세트들 (picture parameter sets; PPS) 에 드물게 변하는 화상-계층 헤더 정보를 포함한다. 파라미터 세트들에 의하면, 이 드물게 변하는 정보는 각각의 시퀀스 또는 화상에 대해 반복될 필요가 없으며; 따라서, 코딩 효율이 향상될 수도 있다. 더욱이, 파라미터 세트들의 사용은 헤더 정보의 대역외 송신을 가능하게 하여, 에러 복원을 달성하기 위한 여분의 송신들에 대한 요구를 피할 수도 있다. 대역외 송신에서, 파라미터 세트 NAL 유닛들은 다른 NAL 유닛들과는 상이한 채널 상에서 송신된다.

도 1 의 예에서, 콘텐츠 준비 디바이스 (20) 의 캡슐화 유닛 (30) 은 코딩된 비디오 데이터를 포함하는 기본 스트림들을 비디오 인코더 (28) 로부터, 그리고, 코딩된 오디오 데이터를 포함하는 기본 스트림들을 오디오 인코더 (26) 로부터 수신한다. 일부 예들에서, 비디오 인코더 (28) 및 오디오 인코더 (26) 는 인코딩된 데이터로부터 PES 패킷들을 형성하기 위한 패킷화기 (packetizer) 들을 각각 포함할 수도 있다. 다른 예들에서, 비디오 인코더 (28) 및 오디오 인코더 (26) 는 인코딩된 데이터로부터 PES 패킷들을 형성하기 위한 각각의 패킷화기들과 각각 인터페이스할 수도 있다. 또한 다른 예들에서, 캡슐화 유닛 (30) 은 인코딩된 오디오 및 비디오 데이터로부터 PES 패킷들을 형성하는 패킷화기들을 포함할 수도 있다.

비디오 인코더 (28) 는, 픽셀 해상도들, 프레임 레이트들, 여러 코딩 표준들에 대한 적합성 (conformance), 여러 코딩 표준들에 대한 여러 프로파일들 및/또는 프로파일들의 레벨들에 대한 적합성, (예컨대, 2차원 또는 3차원의 플레이백을 위한) 하나 또는 다수의 뷰들을 갖는 표현들, 또는 다른 이런 특성들과 같은 여러 특성들 그리고 여러 비트레이트들로 멀티미디어 콘텐츠의 상이한 표현들을 발생시키기 위해, 멀티미디어 콘텐츠의 비디오 데이터를 다양한 방법들로 인코딩할 수도 있다. 표현은, 본 개시물에서 사용될 때, 오디오 데이터 및 비디오 데이터의 조합, 예컨대, 하나 이상의 오디오 기본 스트림 및 하나 이상의 비디오 기본 스트림들을 포함할 수도 있다. 각각의 PES 패킷은 PES 패킷이 속하는 기본 스트림을 식별하는 stream_id 를 포함할 수도 있다. 캡슐화 유닛 (30) 은 기본 스트림들을 여러 표현들의 비디오 파일들로 어셈블링하는 것을 담당한다.

캡슐화 유닛 (30) 은 오디오 인코더 (26) 및 비디오 인코더 (28) 로부터 표현의 기본 스트림들에 대한 PES 패킷들을 수신하고, 그 PES 패킷들로부터 대응하는 네트워크 추상화 계층 (network abstraction layer; NAL) 유닛들을 형성한다. H.264/AVC (Advanced Video Coding) 의 예에서, 코딩된 비디오 세그먼트들은 NAL 유닛들로 조직화되며, 이 유닛들은 비디오 전화 통신, 저장, 브로드캐스트, 또는 스트리밍과 같은 "네트워크-친화적인" 비디오 표현 어드레싱 (addressing) 애플리케이션들을 제공한다. NAL 유닛들은 비디오 코딩 계층 (Video Coding Layer; VCL) NAL 유닛들 및 비-VCL NAL 유닛들로 분류될 수 있다. VCL 유닛들은 코어 압축 엔진을 포함할 수도 있으며, 블록, 매크로블록, 및/또는 슬라이스 레벨 데이터를 포함할 수도 있다. 다른 NAL 유닛들은 비-VCL NAL 유닛들일 수도 있다.

캡슐화 유닛 (30) 은 멀티미디어 콘텐츠의 하나 이상의 표현들에 대한 데이터를, 매니페스트 파일 (예컨대, MPD) 과 함께, 출력 인터페이스 (32) 에 제공할 수도 있다. 출력 인터페이스 (32) 는 네트워크 인터페이스 또는 범용 시리얼 버스 (USB) 인터페이스, CD 또는 DVD 라이터 또는 버너와 같은, 저장 매체에 기록하기 위한 인터페이스, 자기 또는 플래시 저장 매체들에의 인터페이스, 또는 미디어 데이터를 저장하거나 또는 송신하는 다른 인터페이스들을 포함할 수도 있다. 캡슐화 유닛 (30) 은 멀티미디어 콘텐츠의 표현들의 각각의 데이터를 출력 인터페이스 (32) 에 제공할 수도 있으며, 이 출력 인터페이스는 데이터를 서버 디바이스 (60) 로 네트워크 송신, 직접 송신, 또는 저장 매체들을 통해 전송할 수도 있다. 도 1 의 예에서, 서버 디바이스 (60) 는 여러 멀티미디어 콘텐츠 (64) 를 저장하는 저장 매체 (62) 를 포함하며, 멀티미디어 콘텐츠 각각은 각각의 매니페스트 파일 (66) 및 하나 이상의 표현들 (68A 내지 68N) (표현들 (68)) 을 포함한다. 본 개시물의 기법들에 따르면, 매니페스트 파일 (66) 의 부분들은 잠재적으로는, 프록시 디바이스와 같은 네트워크 (74) 의 또 다른 디바이스의 별개의 로케이션들, 예컨대, 저장 매체 (62) 또는 또 다른 저장 매체의 로케이션들에 저장될 수도 있다.

일부 예들에서, 표현들 (68) 은 적응 세트들로 분리될 수도 있다. 즉, 표현들 (68) 의 여러 서브세트들은 코덱, 프로파일 및 레벨, 해상도, 뷰들의 개수, 세그먼트들의 파일 포맷, 표현과 함께 디스플레이되는 텍스트의 언어 또는 다른 특성들, 및/또는 디코딩되어 예컨대, 스피커들에 의해 제공되는 오디오 데이터를 식별할 수도 있는 텍스트 유형 정보, 적응 세트에서의 표현들에 대한 장면의 카메라 각도 또는 실제-세계 카메라 관점을 기술할 수도 있는 카메라 각도 정보, 특정의 시청자들에 대한 콘텐츠 적합성을 기술하는 등급 정보 등과 같은, 특성들의 각각의 공통 세트들을 포함할 수도 있다.

매니페스트 파일 (66) 은 특정의 적응 세트들에 대응하는 표현들 (68) 의 서브세트들 뿐만 아니라, 적응 세트들에 대한 공통 특성들을 나타내는 데이터를 포함할 수도 있다. 매니페스트 파일 (66) 은 또한 적응 세트들의 개개의 표현들에 대해, 비트레이트들과 같은 개개의 특성들을 나타내는 데이터를 포함할 수도 있다. 이 방법으로, 적응 세트는 단순화된 네트워크 대역폭 적응에 대비할 수도 있다. 적응 세트에서의 표현들은 매니페스트 파일 (66) 의 적응 세트 엘리먼트의 자식 엘리먼트들을 이용하여 나타낼 수도 있다.

서버 디바이스 (60) 는 요청 프로세싱 유닛 (70) 및 네트워크 인터페이스 (72) 를 포함한다. 일부 예들에서, 서버 디바이스 (60) 는 네트워크 인터페이스 (72) 를 포함한 복수의 네트워크 인터페이스들을 포함할 수도 있다. 더욱이, 서버 디바이스 (60) 의 특성들 중 임의 또는 모두의 특성은 라우터들, 브릿지들, 프록시 디바이스들, 스위치들, 또는 다른 디바이스들과 같은, 콘텐츠 배포 네트워크의 다른 디바이스들 상에서 구현될 수도 있다. 일부 예들에서, 콘텐츠 배포 네트워크의 중간 디바이스들은 멀티미디어 콘텐츠 (64) 의 데이터를 캐싱할 수도 있으며, 서버 디바이스 (60) 의 컴포넌트들에 실질적으로 부합하는 컴포넌트들을 포함할 수도 있다. 일반적으로, 네트워크 인터페이스 (72) 는 데이터를 네트워크 (74) 를 통해 전송하고 수신하도록 구성된다.

요청 프로세싱 유닛 (70) 은 저장 매체 (72) 의 데이터에 대한, 클라이언트 디바이스 (40) 와 같은 클라이언트 디바이스들로부터의 네트워크 요청들을 수신하도록 구성된다. 예를 들어, 요청 프로세싱 유닛 (70) 은 1999년 6월, IETF, 네트워크 작업 그룹, R. Fielding 등에 의한, RFC 2616, "Hypertext Transfer Protocol - HTTP/1.1" 에 설명된 바와 같은, 하이퍼텍스트 전송 프로토콜 (HTTP) 버전 1.1 을 구현할 수도 있다. 즉, 요청 프로세싱 유닛 (70) 은 HTTP GET 또는 부분 GET 요청들을 수신하고 그 요청들에 응답하여 멀티미디어 콘텐츠 (64) 의 데이터를 제공하도록 구성될 수도 있다. 요청들은 표현들 (68) 의 하나의 세그먼트를, 예컨대, 세그먼트의 URL을 이용하여 규정할 수도 있다. 일부 예들에서, 요청들은 또한 세그먼트의 하나 이상의 바이트 범위들을 규정할 수도 있다. 일부 예들에서, 세그먼트의 바이트 범위들은 부분 GET 요청들을 이용하여 규정될 수도 있다. 다른 예들에서, 본 개시물의 기법들에 따르면, 세그먼트의 바이트 범위들은 일반 템플릿에 따라, 세그먼트에 대한 URL 의 부분으로서 규정될 수도 있다.

요청 프로세싱 유닛 (70) 은 표현들 (68) 의 하나의 세그먼트의 헤더 데이터를 제공하기 위해 HTTP 헤드 요청들을 서비스하도록 추가로 구성될 수도 있다. 어느 경우든, 요청 프로세싱 유닛 (70) 은 요청되는 데이터를 클라이언트 디바이스 (40) 와 같은 요청하는 디바이스에 제공하기 위해, 그 요청들을 프로세싱하도록 구성될 수도 있다. 더욱이, 요청 프로세싱 유닛 (70) 은 바이트 범위들을 규정하는 URL들을 구성하기 위한 템플릿을 발생시키고, 그 템플릿이 요구되는지 또는 옵션적인지 여부를 나타내는 정보를 제공하고, 그리고 임의의 바이트 범위가 허용가능한지 여부 또는 오직 바이트 범위들의 특정 세트만이 허용되는지를 나타내는 정보를 제공하도록 구성될 수도 있다. 오직 특정의 바이트 범위들만이 허용될 때, 요청 프로세싱 유닛 (70) 은 허용된 바이트 범위들의 표시들을 제공할 수도 있다.

도 1 의 예에 예시된 바와 같이, 멀티미디어 콘텐츠 (64) 는 매니페스트 파일 (66) 을 포함하며, 이 파일은 미디어 프리젠테이션 설명 (MPD) 에 대응할 수도 있다. 매니페스트 파일 (66) 은 상이한 대안적인 표현들 (68) 의 설명들 (예컨대, 상이한 품질들을 가진 비디오 서비스들) 을 포함할 수도 있으며, 이 설명은 예컨대, 코덱 정보, 프로파일 값, 레벨 값, 비트레이트, 및 표현들 (68) 의 다른 서술적인 특성들을 포함할 수도 있다. 클라이언트 디바이스 (40) 는 미디어 프리젠테이션의 MPD 를 취출하여, 표현들 (68) 의 세그먼트들에 어떻게 액세스할 지를 결정할 수도 있다. 종래의 DASH 에서, 바이트 범위들을 규정하는데는 2가지 방법들이 있다. 제 1 방법은 명시적으로 바이트 범위들을 개개의 프래그먼트 정의들에 삽입하여, 바이트 범위들을 MPD XML 에 저장하는 것이다. 제 2 방법은 MPEG 파일 내 SIDX 박스로부터 바이트 범위 정보를 페치하고, 그 SIDX 바이트 범위 정보를 이용하여 미디어에 대한 바이트 범위 요청들을 발행하는 것이다. 위에서 설명한 바이트 범위들은 이들 기법들, 또는 당업자들이 주지하는 바와 같은, 다른 기법들을 이용하여 규정될 수도 있다.

클라이언트 디바이스 (40) 의 웹 애플리케이션 (52) 은 클라이언트 디바이스 (40) 의 하드웨어-기반의 프로세싱 유닛에 의해 실행되는 웹 브라우저, 또는 이런 웹 브라우저에의 플러그-인을 포함할 수도 있다. 웹 애플리케이션 (52) 에 대한 언급들은 일반적으로 웹 브라우저, 독립형 비디오 플레이어와 같은 웹 애플리케이션, 또는 웹 브라우저에의 플레이백 플러그-인을 포함하는 웹 브라우저를 포함하는 것으로 이해되어야 한다. 웹 애플리케이션 (52) 은 클라이언트 디바이스 (40) 의 구성 데이터 (미도시) 를 취출하여, 비디오 디코더 (48) 의 디코딩 능력들 및 클라이언트 디바이스 (40) 의 비디오 출력 (44) 의 렌더링 능력들을 결정할 수도 있다.

구성 데이터는 또한 클라이언트 디바이스 (40) 의 사용자에 의해 선택된 언어 선호사항, 클라이언트 디바이스 (40) 의 사용자에 의해 설정된 깊이 선호사항들에 대응하는 하나 이상의 카메라 관점들, 및/또는 클라이언트 디바이스 (40) 의 사용자에 의해 선택된 등급 선호사항 중 임의의 것 또는 모두를 포함할 수도 있다. 웹 애플리케이션 (52) 은 예를 들어, 웹 브라우저, 또는 HTTP GET 및 부분 GET 요청들을 서브밋하도록 구성된 미디어 클라이언트를 포함할 수도 있다. 웹 애플리케이션 (52) 은 클라이언트 디바이스 (40) 의 하나 이상의 프로세서들 또는 프로세싱 유닛들 (미도시) 에 의해 실행되는 소프트웨어 명령들에 대응할 수도 있다. 일부 예들에서, 웹 애플리케이션 (52) 에 대해 설명하는 기능 중 일부 또는 모두가 하드웨어, 또는 하드웨어, 소프트웨어, 및/또는 펌웨어의 조합으로 구현될 수도 있으며, 이 때, 필수 하드웨어가 소프트웨어 또는 펌웨어에 대한 명령들을 실행하기 위해 제공될 수도 있다.

웹 애플리케이션 (52) 은 클라이언트 디바이스 (40) 의 디코딩 및 렌더링 능력들을, 매니페스트 파일 (66) 의 정보에 의해 나타내는 표현들 (68) 의 특성들과 비교할 수도 있다. 웹 애플리케이션 (52) 은 시초에 매니페스트 파일 (66) 의 적어도 일부분을 취출하여, 표현들 (68) 의 특성들을 결정할 수도 있다. 예를 들어, 웹 애플리케이션 (52) 은 하나 이상의 적응 세트들의 특성들을 기술하는 매니페스트 파일 (66) 의 부분을 요청할 수도 있다. 웹 애플리케이션 (52) 은 클라이언트 디바이스 (40) 의 코딩 및 렌더링 능력들에 의해 만족될 수 있는 특성들을 갖는 표현들 (68) 의 서브세트 (예컨대, 적응 세트) 를 선택할 수도 있다. 웹 애플리케이션 (52) 은 그 후 적응 세트에서의 표현들에 대해 비트레이트들을 결정하고, 네트워크 대역폭의 현재 가용 양을 결정하고, 그리고, 네트워크 대역폭에 만족될 수 있는 비트레이트를 갖는 표현들 중 하나로부터 세그먼트들 (또는, 바이트 범위들) 을 취출할 수도 있다.

일반적으로, 더 높은 비트레이트 표현들은 더 높은 품질 비디오 플레이백을 유발하지만, 낮은 비트레이트 표현들은 가용 네트워크 대역폭이 감소할 때 충분한 품질 비디오 플레이백을 제공할 수도 있다. 따라서, 가용 네트워크 대역폭이 비교적 높을 때, 웹 애플리케이션 (52) 은 비교적 높은 비트레이트 표현들로부터 데이터를 취출하는 반면, 가용 네트워크 대역폭이 낮을 때, 웹 애플리케이션 (52) 은 비교적 낮은 비트레이트 표현들로부터 데이터를 취출할 수도 있다. 이 방법으로, 클라이언트 디바이스 (40) 는 네트워크 (74) 를 통해 멀티미디어 데이터를 스트리밍하는 동안 또한 네트워크 (74) 의 변하는 네트워크 대역폭 가용성에 적응시킬 수도 있다.

위에서 언급한 바와 같이, 일부 예들에서, 클라이언트 디바이스 (40) 는 사용자 정보를, 예컨대, 서버 디바이스 (60) 또는 콘텐츠 배포 네트워크의 다른 디바이스들에게 제공할 수도 있다. 사용자 정보는 브라우저 쿠키의 형태를 취할 수도 있거나, 또는 다른 형태들을 취할 수도 있다. 웹 애플리케이션 (52) 은, 예를 들어, 사용자 식별자, 사용자 식별자, 사용자 선호사항들, 및/또는 사용자 인구통계 정보를 수집하고, 이런 사용자 정보를 서버 디바이스 (60) 에 제공할 수도 있다. 웹 애플리케이션 (52) 은 그 후 목표되는 광고 미디어 콘텐츠와 연관되는 매니페스트 파일을 수신하고, 플레이백 동안 목표되는 광고 미디어 콘텐츠로부터의 데이터를 요청되는 미디어 콘텐츠의 미디어 데이터에 삽입하는데 사용할 수도 있다. 이 데이터는 매니페스트 파일, 또는 매니페스트 서브-파일에 대한 요청의 결과로서 직접 수신될 수도 있거나, 또는 이 데이터는 (사용자 인구통계들 및 다른 타겟팅 정보를 저장하는데 사용되는, 제공된 브라우저 쿠키에 기초한) 대안적인 매니페스트 파일 또는 서브-파일로의 HTTP 재지향을 통해 수신될 수도 있다.

때로는, 클라이언트 디바이스 (40) 의 사용자는 키보드, 마우스, 스타일러스, 터치스크린 인터페이스, 버튼들, 또는 다른 인터페이스들과 같은 클라이언트 디바이스 (40) 의 사용자 인터페이스들을 이용하여, 웹 애플리케이션 (52) 과 인터페이스하여, 멀티미디어 콘텐츠 (64) 와 같은 멀티미디어 콘텐츠를 요청할 수도 있다. 사용자로부터의 이런 요청들에 응답하여, 웹 애플리케이션 (52) 은 예컨대, 클라이언트 디바이스 (40) 의 디코딩 및 렌더링 능력들에 기초하여, 표현들 (68) 중 하나를 선택할 수도 있다. 표현들 (68) 중 선택된 하나의 데이터를 취출하기 위해, 웹 애플리케이션 (52) 은 표현들 (68) 중 선택된 표현의 특정 바이트 범위들을 순차적으로 요청할 수도 있다. 이 방법으로, 하나의 요청을 통해 풀 파일을 수신하는 대신, 웹 애플리케이션 (52) 은 다수의 요청들을 통해 파일의 부분들을 순차적으로 수신할 수도 있다. 본 개시물의 기법들에 따르면, 웹 애플리케이션 (52) 은 예컨대, 템플릿에 따라 바이트 범위들을 규정하는 URL 을 포함하는 요청들을 형성할 수도 있다.

일부 예들에서, 서버 디바이스 (60) 는 클라이언트 디바이스 (40) 와 같은 클라이언트 디바이스들로부터의 URL들에 대한 일반 템플릿을 규정할 수도 있다. 클라이언트 디바이스 (40) 는, 결국, 그 템플릿을 이용하여, HTTP GET 요청들에 대한 URL들을 구성할 수도 있다. DASH 프로토콜에서, URL들은 각각의 세그먼트 내에 명시적으로 그들을 리스팅함으로써, 또는 URLTemplate 를 제공함으로써 형성되며, 이 URLTemplate 은 (DASH 의 현재 안의 표 9 에 설명된) $$, $RepresentationID$, $Index$, $Bandwidth$, 또는 $Time$ 과 같은 하나 이상의 널리 공지된 패턴들을 포함하는 URL 이다. URL 요청을 행하기 전에, 클라이언트 디바이스 (40) 는 '$$', 표현 id, 세그먼트의 인덱스 등과 같은 텍스트 스트링들을, 일반적인 페치되는 최종 URL 에 대한 URLTemplate 로 대체할 수도 있다. 본 개시물은 DASH 파일의 SegmentInfoDefault 엘리먼트에, 예컨대, 멀티미디어 콘텐츠 (64) 에 대한 매니페스트 파일 (66) 과 같은 멀티미디어 콘텐츠에 대한 MPD 에, 추가될 수도 있는 여러 추가적인 XML 필드들을 정의한다.

일부 예들에서, 서버 디바이스 (60) 는 일반 템플릿의 사용을 나타내는 데이터, 예컨대, 템플릿이 요구되는지 또는 옵션적인지 여부를, 제 1 필드에 제공할 수도 있다. 예를 들어, 서버 디바이스 (60) (또는, 프록시 디바이스) 는 템플릿을 사용하는데 클라이언트 디바이스 (40) 가 요구되는지, 또는 간단히 허용되는지 여부를 나타내는 정보를 클라이언트 디바이스 (40) 에 제공할 수도 있다. 서버 디바이스 (60) 는 템플릿의 사용을 나타내기 위해 엘리먼트의 값을 매니페스트 파일 (66) 에 설정할 수도 있다. 예를 들어, (매니페스트 파일 (66) 의 일 예를 나타내는) MPD 파일은 "MustUseRangeURL" 로 라벨링된 필드를 포함할 수도 있으며, 이 필드는 3 개의 값들, 즉, DoNotIncorporateByteRangeIntoUrl(0), ByteRangeTemplateOptional(1), 또는 ByteRangeTemplateMandatory(2) 중 하나를 취할 수도 있다. 일부 예들에서, 서버 디바이스 (60) 가 그 값을 제로로 설정하면, 페치된 URL들은 바이트 범위들을 포함하지 않아야 하며, ByteRangeTemplate 은 사용되지 않아야 한다. 일부 예들에서, 서버 디바이스 (60) 는 그의 자신의 옵션에서, 그 값이 1 인 것으로 설정하고, DASH 플레이어 (예컨대, 웹 애플리케이션 (52)) 는 규칙적인 바이트 범위 요청들을 발행하거나, 또는 바이트 범위들을 URL 자체 내에 내장할 수도 있다. 일부 예들에서, 서버 디바이스 (60) 가 그 값을 2로 설정하면, DASH 플레이어는 URL 내에 바이트 범위 요청들을 발행해야 한다.

본 개시물에 의해 제공되는 또 다른 필드는 3 개의 값들 중 하나를 취할 수 있는 열거 속성, "AllowedByteRanges" 이다. 제 1 값은 RangesOnlyFromMPD(0) 이다. 서버 디바이스 (60) 가 이 값을 규정할 때, DASH 플레이어 (예컨대, 웹 애플리케이션 (52)) 는 (표현들 (68) 의 각각의 하나의 데이터 내에 포함될 수도 있는) SIDX 로부터의 바이트 범위들을 이용하는데 허용되지 않는다. 따라서, DASH 플레이어는 DASH MPD, 예컨대, 매니페스트 파일 (66) 로부터의 바이트 범위들을 오직 이용하는 데에만 제한받을 수도 있다. 제 2 값은 RangesFromSIDX(1) 이다. 서버 디바이스 (60) 가 이 값을 규정할 때, DASH 플레이어는 (또한, 표현들 (68) 의 각각의 하나의 세그먼트 내에 데이터로서 포함될 수도 있는) SIDX 로부터의 바이트 범위들을 오직 이용하여, 프래그먼트 또는 세그먼트 요청들을 발생시킬 수도 있다. 제 3 값, RangesFromAnywhere(3) 는 2개 이상의 세그먼트들을 동시에 요청하기 위해 SIDX 또는 MPD 를 이용하고 세그먼트 요청시 2개 이상의 프래그먼트들을 조합하는 능력을 포함한, 임의의 바이트 범위 요청들, 또는 바이트 범위 요청시, 하나 이상의 세그먼트들 또는 세그먼트들의 부분들에 대한 요청들의 다른 하이브리드들 (hybrids) 을 허용한다.

또한, 본 개시물에 제공되는 또 다른 필드는 ByteRangeTemplate 필드이다. 서버 디바이스 (60) 는 이 필드에 데이터를 제공할 수도 있다. 본 개시물의 기법들에 따르면, ByteRangeTemplate 는 필드들 $Url$, $StartByte$, 및 $EndByte$ 을 포함하는 스트링 패턴을 규정할 수도 있다. 게다가, ByteRangeTemplate 는 URL-기반의 바이트-범위 요청들을 발행하는데 사용되는 여분의 ASCII 캐릭터들을 포함할 수 있거나, 또는 심볼 "$$" 을 포함할 수도 있으며, 이 심볼은 URLTemplate 엘리먼트에서와 같이, 단일 달러 기호 (dollar sign) 를 나타낸다. 클라이언트 디바이스 (40) 는 ByteRangeTemplate 의 3 개의 필드들의 각각에 대해 데이터를 대체할 수도 있다. 특히, 클라이언트 디바이스 (40) 는 URLTemplate 필드의 값에 대응하는 $Url$ 필드로 값을 대체할 수도 있다. 클라이언트 디바이스 (40) 는 또한 요청되는 바이트 범위의 시작 및 종료 바이트들을 $StartByte$ 및 $EndByte$ 필드들에서의 최종 URL 로 대체할 수도 있다. 이 방법으로, 클라이언트 디바이스 (40) 는 바이트-범위 요청에 대한 정보를 포함하는 URL 을 발생시킬 수도 있다. 클라이언트 디바이스 (40) 는 이 구성된 URL 로부터 그 내에 어떤 "Range:" 필드를 포함하지 않는 GET 요청을 통해 데이터를 페치할 수도 있다. 즉, 클라이언트 디바이스 (40) 는 발생된 URL 을 포함한 GET 요청을 서버 디바이스 (60) 에 서브밋할 수도 있다.

바이트 범위 템플릿에 대한 스트링 패턴들이 ByteRangeTemplate 속성에 저장되어 있는지 여부를, 또는 대신, 그들이 URLTemplate 에 저장되어 있는지는 중요하지 않은 것으로 어떤 당업자는 이해해야 한다. ByteRangeTemplate 및 URLTemplate 속성들에 템플릿에 대한 스트링 패턴들의 저장은 단지 예의 목적들을 위해 제공된다. 일반적으로, 이들 스트링 패턴들은 매니페스트 파일 내 어떤 로케이션, 또는 다른 어디든지 저장될 수도 있다.

이들 필드들에 대해 데이터를 규정하는 요청들의 일 예가 아래에 제공된다. 이 예에서, (서버 디바이스 (60) 와 같은) 웹 서버는 바이트 범위들을 이용하여 또는 그 범위가 URL 내에 내장되어 있는 범위 요청들을 서빙함으로써, 멀티미디어 콘텐츠 (예컨대, 영화 "TRON") 를 서빙한다. 웹서버 (Webserver) 는 예를 들어, www.mp4player.com 일 수도 있다. 아래에 제시된 것은 이 제 1 예에 대한 값들이다:

이 예에서, "www.mp4player.com" 에서의 웹 서버는 '1' 의 값을 엘리먼트 "MustUseRangeURL" 에 할당함으로써, 바이트 범위 템플릿이 클라이언트 디바이스들에 대해 옵션적임을 나타낸다. 즉, 클라이언트 디바이스 (40) 는 바이트 범위를 URL 템플릿 및 바이트 범위 템플릿에 따라 형성된 URL 의 부분으로서 규정하거나, 또는 클라이언트 디바이스 (40) 는 종래의 부분 GET 요청을 이용할 수도 있다. 클라이언트 디바이스 (40) 가 이 템플릿을 이용하기로 선택하면, 클라이언트 디바이스는, 슬래시 '/', $StartByte$ 에 대한 값, 또 다른 슬래시 '/', 그리고 그 후에 $EndByte$ 에 대한 값이 후속하는 URL ("http://www.mp4player.com/TRON/segment.$Bandwidth$.$Index$") 에 대한 요청을 서브밋할 것이다. 따라서, 클라이언트 디바이스 (40) 는 2 개의 부분들, 즉, 특정의 표현 및 그의 세그먼트에 대응하는 베이스 부분, 및 요청된 바이트 범위의 시작 바이트 및 종료 바이트를 규정하는 바이트 범위 부분을 갖는 URL 을 구성할 수도 있다. 바이트 범위 부분은 본질적으로 부분 GET 요청에서의 "Range:" 헤더의 기능을 수행할 수도 있지만, "Range:" 헤더로서 대신, URL 경로 자체에 규정된다. 당업자에게, 바이트 범위가 URL 경로에 규정되기 때문에, GET 요청의 결과들이 투명한 (또는, 명시적인) 웹 프록시 디바이스와 같은 임의의 중간 디바이스들에 의해 잠재적으로 캐싱가능하다는 것이 명백할 것이다. 당업자에게, 수천 또는 심지어 수백만의 클라이언트들이 동일한 콘텐츠를 동시에 요청가능하게 하기 위해서, 캐싱가능한 요청들이 비디오 플레이백을 스케일링하게 할 수 있다는 것이 명백할 것이다. 당업자에게, 바이트 범위가, 상이한 콘텐츠 배포 네트워크에 대해 상이할 수 있는 템플릿에 따라 규정되기 때문에, url-경로 내-바이트-범위 요청들 (byte-range-within-url-path requests) 에 대해, 하나 및 오직 하나의 포맷을 채택하기 위해서 상이한 콘텐츠 배포 네트워크들을 취하는 부담이 경감된다는 것이 명백할 것이다.

더욱이, 이 예에서, 웹 서버는 '0' 의 값을 엘리먼트 "AllowedByteRanges" 에 할당함으로써, MPD 에 규정된 오직 바이트 범위들만이 규정될 수 있다는 것을 나타낸다. 따라서, 클라이언트 디바이스가 바이트 범위들을 바이트 범위 템플릿을 이용하여 또는 부분 GET 요청으로서 규정하기로 선택하든 아니든, 클라이언트 디바이스는 MPD 파일에서 식별되는 바이트 범위들을 규정하는 것이 오직 허용될 것이다.

클라이언트 디바이스에 의해 실행되는 웹 브라우저 (예컨대, 클라이언트 디바이스 (40) 의 웹 애플리케이션 (52)) 가 바이트 범위 요청들을 지원하고 플러그-인들에 대해 지원한다고 가정하면, DASH 플러그-인은 바이트 범위 요청들을 HTTP 1.1 의 Range: 헤더를 이용하여 발행할 수도 있다. 세그먼트 ID=27 을 가진 1000 Kbps 비트레이트 비디오를 가정하면, 바이트 범위를 규정하는 종래의 부분 GET 요청은 다음과 같을 수도 있다:

웹 브라우저가 그의 플러그-인들로 하여금 바이트 범위 요청들을 발행하지 않게 하면, 그 요청은, 상기 예에 따르면, 다음과 같을 수도 있다:

이 방법으로, 본 개시물의 기법들은 비록 관련된 브라우저가 정식 HTTP 1.0 "Range:" 헤더로 하여금 그 요청 헤더로 발행되지 않게 하더라도, (클라이언트 디바이스 (40) 와 같은) 클라이언트 디바이스에 의해 실행되는 (웹 애플리케이션 (52) 과 같은) 웹 브라우저 플러그-인으로 하여금, 바이트 범위 요청들을 발행하는 것을 가능하게 할 수도 있다. 이와 유사하게, 웹 브라우저 플러그-인은 비록 웹 브라우저가 바이트 범위 요청들을 지원하지 않더라도, 예컨대, (중간 네트워크 디바이스들, 예컨대, 라우터들과 같은) 다른 네트워크 디바이스들이 부분 GET 요청들을 지원하지 않거나 적절히 처리하지 않는 상황들을 처리하기 위해, 이들 기법들을 이용하여 이러한 방법으로 바이트 범위 요청을 발행할 수도 있다.

서버 디바이스 (60) 에 웹 애플리케이션 (52) 에 의해 서브밋된 요청들에 응답하여, 네트워크 인터페이스 (54) 는 선택된 표현의 수신된 세그먼트들의 데이터를 수신하여, 웹 애플리케이션 (52) 에 제공할 수도 있다. 웹 애플리케이션 (52) 은 결과적으로 세그먼트들을 캡슐화 해제 유닛 (50) 에 제공할 수도 있다. 캡슐화 해제 유닛 (50) 은 비디오 파일의 엘리먼트들을 구성성분 PES 스트림들로 캡슐화 해제하고, PES 스트림들을 패킷화 해제하여 인코딩된 데이터를 취출하고, 그리고, 그 인코딩된 데이터가 예컨대, 스트림의 PES 패킷 헤더들에 의해 나타낸 바와 같은, 오디오 또는 비디오 스트림의 부분인지에 따라, 그 인코딩된 데이터를 오디오 디코더 (46) 또는 비디오 디코더 (48) 로 전송할 수도 있다. 오디오 디코더 (46) 는 인코딩된 오디오 데이터를 디코딩하고, 디코딩된 오디오 데이터를 오디오 출력 (42) 로 전송하는 한편, 비디오 디코더 (48) 는 인코딩된 비디오 데이터를 디코딩하고, 스트림의 복수의 뷰들을 포함할 수도 있는 그 디코딩된 비디오 데이터를 비디오 출력 (44) 으로 전송한다.

비디오 인코더 (28), 비디오 디코더 (48), 오디오 인코더 (26), 오디오 디코더 (46), 캡슐화 유닛 (30), 웹 애플리케이션 (52), 및 캡슐화 해제 유닛 (50) 각각은 적용가능한 경우, 하나 이상의 마이크로프로세서들, 디지털 신호 프로세서들 (DSPs), 주문형 집적회로들 (ASICs), 필드 프로그래밍가능 게이트 어레이들 (FPGAs), 이산 로직 회로, 소프트웨어, 하드웨어, 펌웨어 또는 임의의 이들의 조합들과 같은, 다양한 적절한 프로세싱 회로 중 임의의 것으로서 구현될 수도 있다. 비디오 인코더 (28) 및 비디오 디코더 (48) 각각은 하나 이상의 인코더들 또는 디코더들에 포함될 수도 있으며, 이들 중 어느 쪽이든 결합된 비디오 인코더/디코더 (코덱) 의 부분으로서 통합될 수도 있다. 이와 유사하게, 오디오 인코더 (26) 및 오디오 디코더 (46) 의 각각은 하나 이상의 인코더들 또는 디코더들에 포함될 수도 있으며, 이들 중 어느 쪽이든 결합된 코덱의 부분으로서 통합될 수도 있다. 비디오 인코더 (28), 비디오 디코더 (48), 오디오 인코더 오디오 인코더 (26), 오디오 디코더 (46), 캡슐화 유닛 (30), 웹 애플리케이션 (52), 및/또는 캡슐화 해제 유닛 (50) 을 포함하는 장치는 집적 회로, 마이크로프로세서, 및/또는 무선 통신 디바이스, 예컨대 셀룰러 전화기를 포함할 수도 있다.

이 방법으로, 클라이언트 디바이스 (40) 는 소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현의 파일의 바이트 범위를 결정하고, 소스 디바이스의 요건들에 따른 파일 및 바이트 범위를 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 URL 을 형성하고, 그리고 그 형성된 URL 을 규정하는 GET 요청을 소스 디바이스에 발행하도록 구성된 하나 이상의 프로세서들을 포함할 수도 있는, 멀티미디어 데이터에 대한 정보를 취출하는 디바이스의 일 예를 나타낸다.

더욱이, 서버 디바이스 (60) 는 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하고, URL 템플릿 및 바이트 범위 템플릿에 따라 구성된 URL 을 포함하는 요청을 수신하고, 그리고, 그 요청에 응답하여, 그 요청의 바이트 범위에 대응하는 표현의 멀티미디어 데이터를 출력하도록 구성된 하나 이상의 프로세서들을 포함할 수도 있는, 비디오 데이터에 대한 정보를 전송하는 디바이스의 일 예를 나타내며, 상기 매니페스트 파일은 URL (uniform resource locator) 템플릿 및 바이트 범위 템플릿을 규정하며, 상기 URL 템플릿 및 바이트 범위 템플릿은 URL 내에 바이트 범위 요청을 포함하도록 URL 을 형성하기 위한 템플릿을 제공하며, 상기 요청의 URL 은 멀티미디어 콘텐츠의 표현의 바이트 범위를 규정한다.

도 2 는 도 1 의 네트워크 (74) 의 부분을 형성하는 디바이스들의 예시적인 세트를 예시하는 블록도이다. 이 예에서, 네트워크 (74) 는 라우팅 디바이스들 (80A, 80B) (라우팅 디바이스들 (80)) 및 프록시 캐시 디바이스 (82) 를 포함한다. 라우팅 디바이스들 (80) 및 프록시 캐시 디바이스 (82) 는 네트워크 (74) 의 부분을 형성할 수도 있는 작은 개수의 디바이스들을 나타내도록 의도된다. 다른 네트워크 디바이스들, 예컨대, 스위치들, 허브들, 게이트웨이들, 방화벽들, 브릿지들, 및 다른 이런 디바이스들이 또한 네트워크 (74) 내에 포함될 수도 있다. 더욱이, 추가적인 네트워크 디바이스들이 서버 디바이스 (60) 와 클라이언트 디바이스 (40) 사이의 네트워크 경로를 따라서 제공될 수도 있다.

일반적으로, 라우팅 디바이스들 (80) 은 네트워크 데이터를 네트워크 (74) 를 통해 교환하도록 하나 이상의 라우팅 프로토콜들을 구현한다. 일부 예들에서, 라우팅 디바이스들 (80) 은 아래에 설명된 바와 같은 프록시 캐시 디바이스 (82) 에 기인되는 기능과 같은 프록시 또는 캐시 동작들을 수행하도록 구성될 수도 있다. 따라서, 일부 예들에서, 라우팅 디바이스들 (80) 은 또한 프록시 디바이스들로도 지칭될 수도 있다. 일반적으로, 라우팅 디바이스들 (80) 은 라우팅 프로토콜들을 실행하여, 네트워크 (74) 를 통한 루트들 (routes) 을 발견한다. 이런 라우팅 프로토콜들을 실행함으로써, 라우팅 디바이스 (80B) 는 자신으로부터 라우팅 디바이스 (80A) 를 경유해서 서버 디바이스 (60) 까지의 네트워크 루트를 발견할 수도 있다.

따라서, 라우팅 디바이스 (80B) 는 서버 디바이스 (60) 를 목적지로 하는 TCP-IP 캡슐화된 HTTP GET 요청들과 같은 네트워크 통신들을 클라이언트 디바이스 (40) 로부터 수신할 수도 있다. 이런 통신들에 응답하여, 라우팅 디바이스 (80B) 는 서버 디바이스 (60) 까지의 루트를 결정하고, 추가로, 그 루트가 프록시 캐시 디바이스 (82) 를 포함한다고 결정할 수도 있다. 예를 들어, 프록시 캐시 디바이스 (82) 는 그 루트를 따라서 "다음 홉 (next hop)" 을 포함할 수도 있거나, 또는 하나 이상의 추가적인 네트워크 디바이스들은 라우팅 디바이스 (80B) 를 프록시 캐시 디바이스 (82) 에 통신가능하게 커플링할 수도 있다. 프록시 캐시 디바이스 (82) 는 또한 그 통신을 라우팅 디바이스 (80A) 로 지향하게 수도 있으며, 그 라우팅 디바이스는 그 통신을 서버 디바이스 (60) 로 포워딩할 수도 있다.

프록시 캐시 디바이스 (82) 는 프록시 캐싱 기능들을 수행할 수도 있다. HTTP 프록시 캐싱은 동작할 인터넷에서 중요하다. 프록시 캐시 디바이스 (82) 와 같은 HTTP 프록시 캐시 디바이스들은 임의의 또는 모든 HTTP 프로토콜 버전들 (예컨대, HTTP 0.9, HTTP 1.0, 및/또는 HTTP 1.1) 을 구현할 수도 있다. 더욱이, 프록시 캐시 디바이스 (82) 와 같은 프록시 캐시 디바이스들은 HTTP GET 요청시에 나타나는 고유한 "URL (Uniform Resource Locator)" 에 기초하여 콘텐츠를 캐싱할 수도 있다. 이 URL 은 후속하여 캐시에서 페치 요청들을 탐색하는데 키로서 사용될 수도 있다. 프록시 캐시 디바이스 (82) 는 멀티미디어 콘텐츠의 표현들의 세그먼트들 또는 서브-세그먼트들을 캐싱하도록 구성될 수도 있으며, 이 멀티미디어 콘텐츠의 표현들의 세그먼트들 또는 서브-세그먼트들은 본 개시물의 기법에 따르는, 수정된 URL 과 같은 URL 에 대응할 수도 있다.

일부 예들에서, 콘텐츠 배포 네트워크 (CDN) 들은 네트워크 (74) 내에 제공되거나, 또는 네트워크 (74) 에 통신가능하게 커플링될 수도 있다. CDN들을 제공하는 기업들의 예들은 Akamai, Level 3 Communications, 및 Limelight 를 포함한다. CDN들의 디바이스들은 프록시 캐시 디바이스 (82) 와 유사한 기능들을 수행할 수도 있다. CDN들은 ISP들에서 및 국가 백홀 제공자들의 포털들에서 프록시 캐시 디바이스들에 매우 유사한 디바이스들을 배치할 수도 있다. 요금을 위해, CDN들은 콘텐츠를 배포하거나 또는 프록시 캐시 디바이스들을 고객의 콘텐츠로 "미리 채울" 수도 있다. 고객은 그러면 콘텐츠를 일반적으로 DNS 스위즐링 (swizzling) 으로서 알려진 기법을 통해 참조할 수도 있으며, 스마트 네임 서버는 콘텐츠에 대한 요청을 가장 가까운 로컬 CDN 캐시로 지향하게 할 수 있어, 웹 페이지가 로딩하고 있을 때 귀중한 라운드-트립 시간을 절감할 수 있다. 대안적으로, 고객은 상이한 요금을 지불할 수도 있으며, 콘텐츠는 미리 "미리 채워져" 있지 않고 다만 캐싱될 수도 있다.

위에서 설명한 바와 같이, 스트리밍 네트워크 프로토콜들은 동일한 멀티미디어 콘텐츠의 복수의 표현들을 제공할 수도 있다. 따라서, DASH 와 같은 적응적 스트리밍 프로토콜들이 적응가능하더라도, 이 이점은 높은 비용으로 취할 수도 있다. 수십, 수백, 수천, 수백만, 또는 더 많은 개수의 바이트들을 나타낼 수도 있는 멀티미디어 콘텐츠가 예를 들어, 8 개의 상이한 비트 레이트들에서 인코딩되어, 2-초 세그먼트들, 플러스 하나 이상의 오디오 스트림들 (예컨대, 스테레오 또는 Dolby 5.1) 로 분할될 수 있으며, 이것은 또한 조각들로 분할될 수도 있다. 따라서, 2-시간 비디오는 3600 개 이상의 프래그먼트들, 곱하기 10 스트림들을 초래할 수도 있으며, 대응하는 데이터는 프록시 캐시 또는 CDN 에서 다량의 디렉토리 저장을 소비할 수도 있다.

많은 양의 저장을 피하기 위해, 서버 디바이스 (60) 는 스트림들의 각각에 대해 개개의 파일들 (예컨대, 상기 예에서는, 10 개의 파일들) 을 수신하도록 구성될 수도 있다. 클라이언트 디바이스 (40) 는 본 개시물의 기법에 따라, HTTP GET 또는 부분 GET 요청들, 또는 GET 요청들의 URL들에 규정된 바이트 범위 요청들을 이용하여, 세그먼트들 또는 서브-세그먼트들을 취출할 수도 있다. 일부 예들에서, HTTP 프로토콜 스택들이 바이트 범위 요청들을 발행하기 위해 클라이언트 디바이스 (40) 에 의해 사용될 수도 있다. 이 방법으로, 예컨대, 36,000 개의 프래그먼트들의 통상적인 영화는 10 개의 파일들, 즉, 8 개의 오디오 및 2 개의 비디오로 컬랩스 (collapse) 될 수도 있다. 본 개시물의 기법들에 따르면, 클라이언트 디바이스 (40) 는 바이트 범위를 스스로 규정하는 URL 을 나타내는 데이터를 포함하는 HTTP GET 요청들을 이용하여 파일들의 특정의 바이트 범위들을 취출할 수도 있다.

일부의 경우, 프록시 디바이스가 "Range:" 헤더를 적절히 처리하지 못하지만 HTTP 1.1 "Range:" 헤더를 수신할 때, 프록시 디바이스는 그 헤더를 무시하고 파일들의 요청된 부분들 대신, 전체 파일들을 페치하여 제공할 수도 있다. 이것은 수 기가바이트 사이즈까지 실행할 수도 있는 2-시간 MPEG 비디오 파일에 대해 재앙일 것이다. 이런 스트림 도중에 레이트 스위치는 프록시 캐시가 새로운 레이트에 대해 전체 파일을 페치하기 시작하도록 하여, (캐시가 콘텐츠 응답을 되전송할 수 있는 앞선 시간 (earlier time) 인, 적어도 절반의 데이터가 캐시에 도달할 때까지) 지연을 초래할 것이다. 이것은 네트워크 스트리밍을 달성하기 위해 파일의 작은 부분들을 시퀀스로 취출하려는 부분 GET 요청들의 의도되는 목적을 방해한다. 이 문제를 극복하기 위해, 본 개시물은 바이트 범위 요청을 URL 에 투명하게 내장함으로써 "Range:" 헤더 요청들을 전체-파일 요청들로 변환하는 프록시 캐시를 우회하는 기법들을 제공한다. 더욱이, 본 개시물은 또한 기점 서버가 바이트 범위 요청을 찾아야 한다는 것을 시그널링하는 기법들을 제공한다.

특히, 본 개시물은 바이트 범위들을 바이트 범위 요청들을 지원하지 않는 중간 프록시들을 통해 시그널링하는 기법들을 제공한다. 즉, 클라이언트 디바이스 (40) 는 바이트 범위 요청들이 라우팅 디바이스들 (80) 및 프록시 캐시 디바이스들 (82) 과 같은 중간 네트워크 디바이스들에 의해 적절히 처리되도록, 바이트 범위 요청들을 서브밋할 수도 있다. 위에서 언급한 바와 같이, 클라이언트 디바이스 (40) 에 의해 실행되는 웹 애플리케이션 (52) 과 같은 웹 브라우저는, 웹 브라우저가 HTTP 1.1 에 따라 바이트 범위 요청들을 구현하지 않을 (또는, 플러그인들을 이용가능하게 하지 않을) 뿐만 아니라, 중간 디바이스들이 부분 GET 요청들을 지원하거나 또는 적절히 처리하지 않을 때 범위 요청을 서브밋하는 경우들에서, 바이트 범위 템플릿에 따라 URL 에 범위 요청을 내장할 수도 있다. 이 방법에 따라, 바이트 범위가 URL 에 내장되기 때문에, 라우팅 디바이스들 (80) 및/또는 프록시 캐시 디바이스 (82) 와 같은 프록시 디바이스들은 비록 프록시 디바이스들이 바이트-범위 요청들을 파악하지 못하더라도, 부분 바이트 범위 응답들을 저장가능할 수도 있다. 따라서, 정확한 동일한 바이트 범위의 미래의 페치들은 프록시 디바이스들이 그의 캐시로부터 데이터의 바이트 범위를 정확히 페치하도록 해야 한다.

본 개시물은 또한 HTTP 에 대해 새로운 "확장 헤더" 를 제공한다. 일반적으로, HTTP 는 HTTP "GET" 요청들에서 그리고 HTTP 응답들에서 사용자-정의된 확장 헤더들을 가능하게 한다. RFC 2616 의 섹션 7.1 에 정의되어 있는 바와 같이, "미인식된 (unrecognized) 헤더 필드들은 수신자에 의해 무시되어야 하며, 투명한 프록시들에 의해 포워딩되어야 한다". 이들 확장 헤더들은 "GET" 요청에서 확장-헤더 필드들로 감소하는 엔터티-헤더 필드들로서 파싱된다. 확장 헤더 명칭은 임의의 미인식된 HTTP 헤더 (즉, 임의의 알파벳 토큰) 이다. 확장 헤더는 HTTP 에 의해 아직 정의되지 않은 임의의 알파벳 토큰일 수도 있지만, 일반적으로 SMTP 메시지 헤더들에서, RFC822 에 정의되어 있는 바와 같이, 접두사 "X-" 는 SMTP 의 임의의 미래 버전에서 절대로 사용되지 않도록 보장된다. HTTP 프로토콜 자체는 RFC822 에 정의된 헤더 메커니즘들에 기초하며, "X-" 약속 (convention) 은 또한 일반적으로 미변경된 채 기점 서버로 포워딩되고 그 후 미변경된 채 클라이언트로 다시 포워딩되는 비-HTTP 확장 헤더들을 식별하기 위해 HTTP 프록시들에 의해 사용된다.

본 개시물은 "X-Dash-ByteRange-URL" 로 불리는 새로운 확장 헤더를 제공하는데, 이 헤더는 HTTP GET 요청들에서만 나타난다. 접두사 "X-" 는 HTTP 와의 미래 충돌들을 피하기 위해 사용된다. 접두사 "Dash-" 는 DASH 클라이언트가 헤더를 발생시키고 있다는 것을 시그널링한다. 당업자는 이 헤더의 정확한 명칭이 중요하지 않다는 것을 알 수 있을 것이다; 이들 기법들은 클라이언트 디바이스들 및 서버 디바이스들이 확장 헤더에 대한 공통 명칭에 따라 구성된다고 가정한다.

이 헤더는 바이트 범위가 HTTP GET 요청에 포함되어 있다는 정보를 중간 노드들 및 (헤더를 해석하도록 구성된) 프록시 디바이스들에 제공한다. 이것은 기점 서버 또는 CDN 로 하여금 MPEG 파일을 단일 파일로서 저장가능하게 하며, 이 헤더를 파악하면, "X-Dash-ByteRange-URL" 헤더를 이용하여, URL 에 내장된 바이트 범위가 존재한다고 결정할 수 있다.

따라서, 클라이언트 디바이스 (40) 는 범위 요청시에 GET 요청의 URL 내에 내장된 확장 헤더를 제공할 수도 있다. 더욱이, 라우팅 디바이스들 (80) 및/또는 프록시 캐시 디바이스 (82) 와 같은 프록시 디바이스들이 헤더를 인식하도록 구성될 때, 프록시 디바이스들은 오직 요청된 바이트 범위를 취출하여 클라이언트 디바이스 (40) 에 제공할 수 있다. 더욱이, 프록시 캐시 디바이스 (82) 및/또는 라우팅 디바이스들 (80) 은 동일한 파일에 대한 바이트 범위 요청들의 시퀀스로부터 파일을 재어셈블링하도록 구성될 수도 있다. 한편, 라우팅 디바이스들 (80) 및/또는 프록시 캐시 디바이스 (82) 와 같은 프록시 디바이스들이 헤더를 해석하도록 구성되지 않을 때, 프록시 디바이스들은 간단히 헤더를 포함하는 GET 요청을 계속 서버 디바이스 (60) 로 전달할 수 있다.

"X-Dash-ByteRange-URL" 헤더는 페이로드를 가질 수 있다. 페이로드의 2 개의 예들이 이하에서 설명된다. 일 예에서, 페이로드는 비어 있다. 바이트 범위의 존재는 헤더의 존재에 의해 시그널링된다. 바이트 범위는 항상 HTTP GET URL 요청의 끝에 첨부될 수도 있다. 기점 서버 (예컨대, 서버 디바이스 (60)) 또는 프록시 디바이스 (예컨대, 라우팅 디바이스들 (80) 또는 프록시 캐시 디바이스 (82) 중 하나) 는 그 후 최종 캐릭터로부터 URL 을 탐색하고, 최대 길이의 바이트-범위 요청을 (예컨대, RFC 2616 에서 바이트 범위 요청 사양에 의해 정의되어 있는 바와 같은, 캐릭터들 "0-9" 및 "-" 및 "," 에 대한 탐색을 이용하여) 추론할 수도 있다.

기점 서버 또는 프록시 디바이스는 그 후, 일부 예들에서, URL 로부터 바이트 범위를 제거하고, 그 파일을 (바이트 범위를 제거한 URL 을 이용하여) 열고, 필요한 바이트들을 페치하고, 그리고, 범위의 바이트들을 클라이언트 디바이스 (40) 로 다시 서빙할 수 있다. 이 설계는 "X-Dash-ByteRange-URL" 헤더를 구현하지 않는 이전의 중간 프록시들과 호환가능하며, 이들 중간 프록시 디바이스들은 바이트 범위를 정확히 캐싱하여 추후 요청들 시에 클라이언트들 또는 클라이언트 프록시들로 서빙할 것이다. 예를 들어, 프록시 캐시 디바이스 (82) 는 X-Dash-Byterange-URL 헤더를 인식하여 처리하도록 구성될 수도 있으며, 반면 라우팅 디바이스 (80B) 는 X-Dash-Byterange-URL 헤더를 처리하도록 구성되지 않을 수도 있다. 그럼에도 불구하고, 라우팅 디바이스 (80B) 는 이 헤더를 포함하는 요청들을 프록시 캐시 디바이스 (82) 에 전달할 수도 있으며, 프록시 캐시 디바이스 (82) 는 이런 요청들로부터 헤더를 제거하고, 요청된 바이트 범위를 취출하고, 요청된 바이트 범위의 데이터를 캐싱하고, 그리고, 요청된 바이트 범위를 클라이언트 디바이스 (40) 로 라우팅 디바이스 (80B) 를 통해 제공할 수도 있다. 프록시 캐시 디바이스 (82) 는 동일한 파일의 후속 바이트 범위들을 캐싱할 수도 있으며, 그리고, 일부 예들에서, 이런 바이트 범위 요청들의 시퀀스로부터 풀 파일을 재어셈블링할 수도 있다. 이 방법으로, 프록시 캐시 디바이스 (82) 는 오직 그 요청된 바이트 범위를 클라이언트 디바이스 (40) 에 제공하기 전에 전체 파일을 로딩하는 것을 피할 수도 있으며, 그렇지 않으면, 클라이언트 디바이스 (40) 로의 송신시 상당한 지연을 초래할 수도 있다.

한편, 서버 디바이스 (60) 와 같은 기점 서버는 전체 비디오 스트림을 단일 MPEG 파일로 유지할 수 있으며, 서비스 요청들을 더욱 효율적으로 서비스하고 MPEG 비디오를 더욱 효율적으로 디스크 상에 또는 비휘발성 (예컨대, 플래시) 저장부에 저장할 수 있다. 예를 들어, 다음 요청이 본 개시물의 기법들에 따라 비디오의 바이트 범위를 취출하는데 사용될 수도 있다:

또 다른 예에서, X-Dash-ByteRange-URL 헤더의 페이로드는 URL 자체로부터의 실제 바이트 범위 요청 사양을 포함한다. 따라서, 사용자-정의된 "Range:" 헤더와 유사하게 작동하지만, 거동은 상이하다. 서버 디바이스 (60) 와 같은 기점 서버는 페이로드를 가진 "X-Dash-ByteRange-URL" 헤더를 해석하고, 요청 URL 에 대해 이 헤더의 페이로드를 매칭하도록 구성될 수도 있다. 패턴 매칭을 컴퓨팅함으로써, 기점 서버는 URL 로부터 바이트-범위 지정자를 제거하고 새로운 URL 을 형성할 수 있으며, 이 새로운 URL 은 그의 디스크 또는 비휘발성 저장부로부터 풀 MPEG 파일을 페치하는데 사용된다. 기점 서버는 그 후 바이트 범위 사양을 이용하여 (또한, RFC 2616 에 의해 규정된 바와 같은 동일한 구문을 이용하여) MPEG 파일로부터 필요한 바이트들을 추출할 수도 있다. 예를 들어, 다음 요청이 본 개시물의 기법들에 따라 비디오의 바이트 범위를 추출하는데 사용될 수도 있다:

서버, 프록시, 또는 CDN 디바이스 (예컨대, 서버 디바이스 (60), 라우팅 디바이스들 (80), 또는 프록시 캐시 디바이스 (82) 중 하나) 는 예컨대, 다음과 같이, 그 요청이 종래의 부분 GET 요청으로서 이루어졌더라도, 그 후 이 요청을 재기록하고 콘텐츠를 서빙할 수도 있다:

NFS 및 UNIX 파일 시스템들 상에서, 2개 이상의 "/" 캐릭터들의 존재는 단일 "/" 캐릭터와 동일하게 취급된다는 점에 유의한다. 이 기법에 대해 많은 이점들이 있을 수도 있다. HTTP 에 대한 이 향상들을 구현하도록 구성된 CDN 또는 프록시 디바이스는 단일 MPEG 파일로부터의 바이트 범위 요청들을 서빙하므로, 디스크 상의 저장 공간을 절감할 수 있다. 스마트 프록시 캐시 또는 CDN 은 심지어 일련의 이들 범위 요청들로부터 MPEG 파일을 만들어, 모든 이들 범위 요청들을 단일 캐싱된 파일로 결합한다. 예를 들어, 프록시 캐시 디바이스 (82) 는 풀 MPEG 파일, 또는 다른 비디오 파일을, 복수의 순차적인 바이트 범위 요청들로부터, 예컨대, 클라이언트 디바이스 (40) 또는 다른 클라이언트 디바이스들로부터 구성하도록 구성될 수도 있다.

기점 서버에 의해 제거될 수도 있는, URL 로 바이트 범위의 존재를 시그널링하기 위해 패턴이 "X-Dash-ByteRange-URL" 헤더에, 또는 또 다른 확장 헤더에 규정되어 있는 경우와 같이 다른 가능한 구현예들이 있다. 모든 이런 다른 구현예들이 또한 본 개시물의 기법들을 구현하기 위해 고려된다.

이 방법으로, 프록시 캐시 디바이스 (82) 는 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하고, URL 템플릿 및 바이트 범위 템플릿에 따라 구성된 URL 을 포함하는 요청을 수신하고, 그리고, 그 요청에 응답하여, 그 요청의 바이트 범위에 대응하는 표현의 멀티미디어 데이터를 출력하도록 구성된 하나 이상의 프로세서들을 포함할 수도 있는, 비디오 데이터에 대한 정보를 전송하는 디바이스의 일 예를 나타내며, 상기 매니페스트 파일은 URL (uniform resource locator) 템플릿 및 바이트 범위 템플릿을 규정하며, 상기 URL 템플릿 및 바이트 범위 템플릿은 URL 내에 바이트 범위 요청을 포함하도록 URL 을 형성하기 위한 템플릿을 제공하며, 상기 요청의 URL 은 멀티미디어 콘텐츠의 표현의 바이트 범위를 규정한다.

도 3 은 여러 콘텐츠 배포 네트워크들 (92A 내지 92N) (CDN들 (92)) 을 포함하는 예시적인 시스템 (90) 을 예시하는 블록도이다. 이 예에서, 콘텐츠 준비 디바이스 (20) 는 멀티미디어 콘텐츠를 다양한 표현들로 준비하고, 하나 이상의 표현들을 CDN들 (92) 의 각각에 제공한다. 일부 예들에서, CDN들 (92) 의 각각은 동일한 표현들을 수신할 수도 있으며, 반면, 다른 예들에서, CDN들 (92) 은 다른 CDN들 (92) 에 대해 상이한 표현들의 세트들을 수신할 수도 있다. 서버 디바이스 (60) 와 유사한 서버 디바이스가, 도 1 및 도 2 에 대해 설명한 바와 같이, CDN들 (92) 의 각각에 제공될 수도 있다. 이의 대안으로, 프록시 또는 캐시 디바이스가 CDN들 (92) 의 각각에 제공될 수도 있다. 더욱이, 일부 예들에서, CDN들 (92) 중 일부는 서버 디바이스들을 포함하지만, CDN들 (92) 의 나머지들은 프록시 디바이스들을 포함한다. 용어 "CDN" 은 일반적으로 본 개시물에서 콘텐츠 전달 네트워크, 콘텐츠 배포 네트워크, 콘텐츠 서버 팜, 또는 다른 유사한 시설을 지칭하기 위해 사용된다. 본 개시물의 기법들에 따르면, CDN들 (92) 의 각각은 각각의 CDN 에 특정된 바이트 범위들을 규정하는 URL들에 대한 템플릿을 포함할 수도 있다.

일부 예들에서, CDN들 (92) 중 어떤 것들은 오직 일간, 주간, 월간, 년간, 또는 다른 기간의 특정 시간들 동안 액티브하다. 예를 들어, CDN (92A) 는 아침 및 오후 시간들 동안 액티브할 수도 있지만, CDN (92B) 은 저녁 및 야간 시간들 동안 액티브할 수도 있다.

본 개시물은 CDN 또는 콘텐츠 서버 팜을, 예컨대, 도 3 에 대해 설명된 바와 같은, 클라이언트 디바이스 (40) 에 의해 선택하는 기법들을 제공한다. DASH MPD 파일이 DASH 콘텐츠에 대한 요청을 발생시키는데 사용되는 일련의 BaseURL들을 나타내는 데이터를 포함한다고 가정된다. 더욱이, 각각의 BaseURL 이 고유한 CDN, 예컨대, CDN들 (92) 중 고유한 CDN 을 지칭한다고 가정된다. 따라서, (클라이언트 디바이스 (40) 에 의해 실행되는) DASH 플레이어는 대응하는 BaseURL 을 선택함으로써, 적절한 CDN 을 선택하도록 구성될 수도 있다. 아래 표 1 에서, 선택을 행하는데 사용될 수 있는 5 개 선택 기준들의 시리즈가 나타나 있다. (추가적으로 또는 대안적으로) 사용될 수 있는 다른 기준들이 있으며, 이들 5 개는 가능한 선택 기준들의 훨씬 더 넓은 세트를 나타낸다. 따라서, 표 1 에 나타낸 것에 대해, 추가적인 또는 대안적인 선택 기준들이 제공될 수도 있다.

표 1 - 예시적인 CDN 선택 기준들

인덱스	명칭	설명
1	가중 무작위 (Weighted Random)	1.0 까지 합산한 가중치들의 옵션적인 리스트
2	시각	자정 이후 secs단위의 시간들의 리스트
3	라운드 트립 지연	ms 단위로 규정됨
4	홉 수 (Hopcount)	네트워크 디바이스 홉들의 개수
5	로케이션	3GPP 명칭 영역, 셀 ID, 우편번호 등

일 예에서, 클라이언트 디바이스 (40) 는 재지향 서비스를 명명하는 재지향 URL 을 규정함으로써 CDN들 (92) 중 하나를 선택할 수도 있다. 재지향 서버 디바이스 (94) 는 재지향 서비스를 실행하는, 재지향 URL 에서 이용가능한, 디바이스를 나타낸다. 이 경우, 클라이언트 디바이스 (40) 는 POST 메시지를 재지향 URL 로 전송하여, POST 메시지가 재지향 서버 디바이스 (94) 로 지향되게 할 수도 있다. 메시지의 보디에서, 클라이언트 디바이스 (40) 는 유일한 BaseURL 을 규정할 수도 있다. 재지향 서버 디바이스 (94) 는 그 후 BaseURL 이 CDN들 (92) 중 어느 CDN 을 사용할 지에 관한 결정을 행하는 것을 검사하고, HTTP 응답의 보디 내의 새로운 BaseURL 을 클라이언트 디바이스 (40) 에 반환할 수도 있다. 결정은 POSTing 클라이언트 디바이스의 로케이션 (로케이션 프로토콜이 클라이언트 IP 어드레스를 로케이션에 맵핑할 것이다), (POST 요청시에 나타내는) 브라우저 유형, 네트워크 지형도, 및/또는 표 1 에 리스트된 선택 기준들 중 임의의 기준, 또는 유사한 기준들과 같은 콘셉트들에 기초할 수 있다. POST 방법을 이용하는 대신, 클라이언트 디바이스 (40) 가 대안적으로 (콘텐츠를 GET 방법의 보디에 전송하는) GET 방법을 이용할 것이며, 재지향 서버가 HTTP 301 (Content Moved) 또는 307 (Temporary Redirect) 응답을 이용하여, 클라이언트 디바이스 (40) 를 직접 CDN 상의 콘텐츠의 제 1 조각으로 직접 재지향하게 할 것이라는 점에 유의한다.

일부 경우, 클라이언트는 MPD 내 CDN 선택 정보에 대해 작용하도록 구성되지 않을 것이며, 따라서 BaseURL 을 재지향 서버로 포스트할 뿐만 아니라, 또한 선택 기준들을 서버로 포스트할 수도 있으며, 그리고 세번째로, (지오로케이션 정보, 홉 수들, 로컬 시각 등과 같은) 그의 로컬 정보의 모두 또는 일부를 재지향 서버 디바이스 (94) 로 포스트할 수도 있다. 이 경우, 재지향 서버 (94) 는 전체 결정-수행 프로세스를 수행하고 클라이언트 디바이스 (40) 에 의해 사용되어야 하는 BaseURL 을 반환할 수도 있다.

게다가, 재지향 서비스 디바이스 (94) 는, 클라이언트 디바이스 (40) 가 뷰잉하기를 요청하는 특정의 멀티미디어 콘텐츠에 의존할 수도 있는 정보를 분석하도록 구성될 수 있다. 일부 비디오 타이틀들은 반드시 CDN들 (92) 의 각각에 이용할 수 있는 것은 아니다. 예를 들어, 어떤 콘텐츠는 수출 또는 저작권 제한 사항들로 인해 어떤 국가에서는 CDN 에 이용할 수 없을 수도 있다. 이런 콘텐츠-선택 결정들은 이 예의 구현예를 통해 이루어질 수 있다. DASH 의 상황에서, "BaseURL@redirectionUrl" 로 명명되는 옵션적인 속성은 HTTP 를 통한 이런 POST 요청들에 사용되는 URL 을 포함할 수도 있다.

다른 예들에서, BaseURL@selectionAttribute 로 명명되는 새로운 DASH 속성이 하나 이상의 선택 속성들을 나타내기 위해 사용될 수도 있다. 즉, 클라이언트 디바이스 (40) 는 이 속성에 대한 데이터를 서버 또는 다른 디바이스, 예컨대, CDN들 (92) 중 하나의 디바이스 또는 또 다른 디바이스로부터 수신할 수도 있다. 이 속성의 콘텐츠는 제로 이상의 숫자들의 리스트이며, 이 리스트는 하나 이상의 선택 기준들을 규정할 수도 있다. 게다가, 어떤 숫자들은 일련의 인수 (argument) 들을, 각각의 BaseURL 에 대해 하나의 인수로 가질 수 있다. 이들 예들에서, redirectionURL 이 있을 필요가 없다. 더욱이, 어떤 selectionAttribute 도 규정될 필요가 없다. 즉, 디폴트로, selectionAttribute 거동이 요청된다. 이 경우, 클라이언트 디바이스 (40) 상에서 실행하는 DASH 플레이어는 마치 선택 기준들이 모든 가능한 BaseURL들에 대해 동일한 가중치들로 "가중 무작위 (Weighted Random)" 인 것처럼 거동할 수도 있다. DASH 플레이어는 모든 BaseURL들 간에 무작위 및 균일한 선택을 행하고 그 후 그 선택된 BaseURL 을 이용하여 모든 미래 요청들을 행할 수도 있다.

여전히, 또 다른 예에서, 오직 하나의 선택 기준들이 selectionAttribute 에 나타난다. 이 예에서, DASH 플레이어는 CDN들 (92) 중 적절한 CDN 을 간단한 선택 기준들을 이용하여, 예컨대, 서버들을 로드 밸런싱하기 위한 무작위 선택에 의해, 시각에 의해, 최소 라운드 트립 지연에 의해, 최소 홉 수에 의해, 및/또는 로케이션 기준들을 이용하여 결정한다. DASH 클라이언트는 그 후 선택된 BaseURL 을 이용하여 모든 미래 요청들을 행한다. 예를 들어, <selectionAttribute="1(0.2, 0.2, 0.3, 0.3)"> 의 값은 클라이언트 디바이스에 의해 실행되는 로드 밸런싱 메커니즘이 모든 가능한 BaseURL들 간을 무작위로 선택하도록 할 수도 있다. 그러나, 첫번째 2 개의 BaseURL들을 고르는데 20% 기회가 있고, 마지막 2 개의 BaseURL들을 고르는데 30% 기회가 있다. 일단 BaseURL 이 선택되면, DASH 클라이언트는 미래 요청들에 대해 그 선택된 BaseURL 을 계속 재사용할 것이다.

또한 또 다른 예에서, 하나보다 많은 selectionAttribute 이 규정될 수도 있다. 예를 들어, <selectionAttribute="3, 4, 2 (0-359, 359-1439, 0-1439, 1080-1439), 1(0.2, 0.2, 0.2, 0.4)"> 와 같은 값일 수도 있다. 이 예에서, 여분의 selectionAttributes 의 존재는, DASH 플레이어가 기준들 3 을 먼저, 그 후 기준들 4 를 사용하고, 그 후 기준들 2 를 사용하고, 그 후 주어진 가중치들, 즉, 0.2, 0.2, 0.2, 및 0.4 에 따르는 기준들 1 과의 관계를 끊어야 한다는 것을 나타낸다. 일부 BaseURL들이 이미 제거되었으면, 나머지 가중치들이 그들의 합계가 1.0 이 되도록 스케일링 확대될 수도 있다는 것에 유의한다.

이 예를 예시하기 위해, 4 개의 잠재적인 BaseURL들, 즉, A, B, C, 및 D 가 있다고 가정하며, 여기서, BaseURL들은 각각의 CDN들에 대응한다. 예를 들어, A 는 CDN (92A) 에 대응할 수도 있으며, B 는 CDN (92B) 에 대응할 수도 있으며, C 는 CDN (92C) 에 대응할 수도 있으며, D는 CDN (92D) 에 대응할 수도 있다. 첫째, 라운드 트립 지연 (RTD) 은 A, B, C, 및 D 의 각각에 대해, 예컨대, 핑 메시지 (ping message) 들을 이용하여, 계산될 수도 있다. 이것은 RTD들이 다음, 즉, A - 20 ms; B - 20 ms; C - 33 ms; D - 40 ms 과 같다는 것을 나타낼 수도 있다. 그 후, 선택 리스트는, 선호사항을 감소시킬 때에, A, B, C, D 이며, 여기서, A 및 B 가 최초로 묶여 진다. 따라서, A, B, C, 및 D 의 각각에 대한 홉 수는 예컨대, 인터넷 제어 메시지 프로토콜 (ICMP) 핑 메시지들을 이용하여 측정될 수도 있다. 즉, 클라이언트 디바이스 (40) 는 각각에 대해 홉 수를 계산하기 위해 ICMP 핑 메시지들을 CDN들 (92) 의 각각의 CDN 들에 서브밋될 수도 있다. 예의 목적들을 위해, 홉 수들에 대한 다음 값들, 즉 A - 5 개의 홉들; B - 3 개의 홉들; C - 12 개의 홉들; D - 20 개의 홉들이 결정된다고 가정한다. 그 후, B 가 A 보다 더 적은 홉들을 갖도록 결정되어 B 를 더 바람직하게 만들기 때문에, 선호사항을 감소시킬 때에 선택 리스트는 B, A, C, D 이다.

이 예에 계속해서, 시각은 예컨대, 3:00 pm 으로서 결정될 수도 있다. BaseURL들에 대해 시그널링된 시각 값들은 다음과 같을 수도 있다: A - 6pm 내지 자정; B - 자정 내지 6 am; C - 6am 내지 자정; D - 온 종일. 클라이언트 디바이스는 그 후 현재의 시간이 3:00 pm 이라고 가정하면, 이 예에서, A 및 B 에 대해 3:00 pm 이 시각 범위들 바깥에 있기 때문에, A 및 B 를 제거할 수도 있다. 따라서, 최종 선택은 C 또는 D (예컨대, CDN들 (92C 또는 92D)) 까지 내려갈 수도 있다. 최소 사전식 선택이 이루어질 수도 있으며, 33 ms < 40 ms 이기 때문에, C 에 대응한다.

여전히, 또 다른 예에서, 적은 개수의 CDN들이 있지만, 다수의 시각 제약들, 로드 밸런싱 가중치들, 또는 CDN들에 대한 유사한 제한 사항들이 있을 수도 있다. 이 예에서, N 개의 BaseURL들이 있으면, selectionAttribute 은 적은 제약들을 포함할 수도 있지만, 각각의 제약은 N 보다 많은 인수들을 가질 수도 있다. (N+1) 번째 인수는 URL #1 을 가리킬 수도 있으며, (N+2) 번째 인수는 URL #2 등을 가리킬 수도 있다. 이 방법으로, BaseURL들은 N 개보다 많은 인수들이 있을 때 반복될 수도 있다. 이 예는 BaseURL들을 반복하는 것을 불필요하게 함으로써 저장 공간을 절감할 수도 있다. 이 경우, 각각의 제약에 대한 인수들의 개수는 매칭되어야 한다. 이것은 시각과 같은 제약들에 특히 유용한다.

이 예를 예시하기 위해, 4 개의 CDN들 A, B, C, D 에 의하면, 시각에 따라 상이한 로드 밸런싱 제약들이 있을 것이다. 아침에, CDN들 (92A 및 92B) 은 균일하게 밸런싱된, 로드의 80% 를 수신할 수도 있으며, 그러나 저녁에, CDN들 (92C 및 92D) 은 균일하게 밸런싱된, 로드의 70% 를 취한다. 이 제약은 다음과 같이 기술될 것이다: <selectionAttribute="2(0-719, 0-719, 0-719, 0-719, 720-1439, 720-1439, 720-1440, 720-1439) 1(0.4, 0.4, 0.1, 0.1, 0.1, 0.2, 0.35, 0.35)">.

도 4 는 예시적인 멀티미디어 콘텐츠 (100) 의 엘리먼트들을 예시하는 개념도이다. 멀티미디어 콘텐츠 (100) 는 멀티미디어 콘텐츠 (64) (도 1), 또는 메모리 (62) 에 저장된 또 다른 멀티미디어 콘텐츠에 대응할 수도 있다. 도 4 의 예에서, 멀티미디어 콘텐츠 (100) 는 미디어 프리젠테이션 설명 (MPD) (102) 및 복수의 표현들 (110 내지 120) 을 포함한다. 표현 (110) 은 옵션적인 헤더 데이터 (112) 및 세그먼트들 (114A 내지 114N) (세그먼트들 (114)) 을 포함하지만, 표현 (120) 은 옵션적인 헤더 데이터 (122) 및 세그먼트들 (124A 내지 124N) (세그먼트들 (124)) 을 포함한다. 문자 N 은 표현들 (110, 120) 의 각각에서 최종 영화 프래그먼트를 지정하기 위해 편의상 사용된다. 일부 예들에서, 표현들 (110, 120) 사이에 상이한 개수들의 영화 프래그먼트들이 있을 수도 있다.

MPD (102) 는 표현들 (110 내지 120) 과는 별개인 데이터 구조를 포함할 수도 있다. MPD (102) 는 도 1 의 매니페스트 파일 (66) 에 대응할 수도 있다. 이와 유사하게, 표현들 (110 내지 120) 은 도 1 의 표현들 (68) 에 대응할 수도 있다. 일반적으로, MPD (102) 는 코딩 및 렌더링 특성들, 적응 세트들, MPD (102) 가 대응하는 프로파일, 텍스트 유형 정보, 카메라 각도 정보, 등급 정보, 트릭 (trick) 모드 정보 (예컨대, 시간 서브-시퀀스들을 포함하는 표현들을 나타내는 정보), 및/또는 (예컨대, 플레이백 동안 미디어 콘텐츠에의 목표로 하는 광고 삽입을 위해) 리모트 피리어드 (remote period) 들을 취출하기 위한 정보와 같은, 표현들 (110 내지 120) 의 특성들을 일반적으로 기술하는 데이터를 포함할 수도 있다. 리모트 피리어드들은 또한 외부 피리어드들로서 지칭될 수도 있다. 이하에 더 자세히 설명되는, 도 4 내지 도 7 은, MPD 및/또는 표현들 중 어느 하나 또는 양자에 (예컨대, 표현들의 세그먼트들 또는 표현들의 헤더 데이터 내에) 포함된 여러 엘리먼트들을 가진 멀티미디어 콘텐츠의 여러 예들을 예시한다. 도 4 내지 도 7 의 MPD들 중 임의의 것 또는 모두는 실질적으로 도 4 의 MPD (102) 에 대응할 수도 있다.

본 개시물의 기법들에 따르면, 도 4 의 MPD (102) 는 예를 들어, 템플릿이 요구되든 또는 옵션적이든, 바이트 범위들에 대한 URL 템플릿, 및 CDN 선택 기준들과 같은 정보를 규정할 수도 있다. 본 개시물의 기법들에 따르는 MPD 유형 사양의 예시적인 엘리먼트들은 아래의 XML 의사 코드로 제공된다.

이 방법으로, MPD (102) 는 멀티미디어 콘텐츠 (100) 에 대한 재지향 URL 을 나타내는 데이터를 포함할 수도 있다. 도 3 에 대해 위에서 설명한 바와 같이, BaseURL 은 CDN들 (92) 중 하나로 재지향될 수도 있다. 즉, 클라이언트 디바이스 (40) 는 HTTP POST 를 재지향 URL 에 서브밋할 수도 있으며, 그 재지향 URL 은 재지향 서버 디바이스 (94) 에 대응할 수도 있다. 클라이언트 디바이스 (40) 는, BaseURL 에 기초하여 재지향 서버 디바이스 (94) 로부터 응답을 수신할 수도 있어서, 그 응답이 멀티미디어 콘텐츠 (100) 의 표현들 (110 내지 120) 중 하나로부터 데이터를 수신하기 위한 새로운 URL 을 나타내는 정보를 포함한다. 특히, BaseURL 는 CDN들 (92) 중 적절한 CDN 을 선택하는데 사용될 수도 있다.

더욱이, 상기 예시적인 의사 코드에 따라, MPD (102) 는 선택 속성을 나타내는 데이터를 포함할 수도 있다. 위에서 설명한 바와 같이, 선택 속성은 선택 기준들을 나타내는 숫자 데이터를 포함할 수도 있으며, 이 데이터는 BaseURL들에 대한 인수들이 동반되거나 또는 동반되지 않을 수도 있다. 따라서, 클라이언트 디바이스 (40) 또는 프록시 캐시 디바이스 (82) (도 2) 와 같은 프록시 디바이스는 선택 속성의 데이터를 이용하여, 클라이언트 디바이스 (40) 로 하여금 멀티미디어 콘텐츠 (100) 에 대한 데이터를 취출하게 할 CDN들 (92) (도 3) 중 적절한 CDN 을 선택할 수도 있다.

다음 XML 의사 코드는 디폴트 세그먼트 액세스 정보에 대한 예시적인 엘리먼트들의 세트를 제공하며, 이 엘리먼트들의 세트는 MPD (102) 로 제공될 수도 있다.

아래의 XML 의사 코드는 세그먼트 액세스 정보에 대한 예시적인 엘리먼트들의 세트를 제공하며, 이 엘리먼트들의 세트는 MPD (102) 에 의해 제공될 수도 있다.

이 방법으로, MPD (102) 는 URL 템플릿을 나타내는 데이터를 포함할 수도 있으며, 이 데이터는 클라이언트 디바이스 (40) 와 같은 클라이언트 디바이스들이 "Range:" 헤더 대신, URL 자체 내에서 바이트범위 (byterange) 를 요청하는 HTTP GET 요청시에 URL 을 어떻게 구조화할 수 있는지를 규정할 수도 있다. 따라서, 클라이언트 디바이스 (40) 는 MPD (102) 의 데이터를 이용하여, "Range:" 헤더를 사용하는 대신, URL 내에 바이트 범위를 규정하는 HTTP GET 요청을 구성할 수도 있다. 따라서, 그 요청이 HTTP GET 요청으로서 구성되더라도, 그 요청은 서버 디바이스 (60) 와 같은 서버 디바이스로 하여금, URL 자체에 의해 규정된 오직 요청된 바이트 범위를 제공하도록 할 수도 있다. 즉, URL 의 모든 데이터를 제공하는 대신, 서버 디바이스 (60) 는 요청되는 바이트 범위를 URL 자체 내에서 대신 제공할 수도 있다. 따라서, 서버 디바이스 (60) 는 "Range:" 헤더 이후의 데이터를 평가할 필요가 없으며, 대신 URL 자체로부터 요청된 바이트 범위를 결정할 수도 있다. 이와 유사하게, 프록시 캐시 디바이스 (82) 는 HTTP GET 요청들의 URL들을 분석하고, URL 내의 그 요청된 바이트 범위를 캐싱하여 클라이언트 디바이스 (40) 에게 제공하고, 동시에 또한 그 요청된 바이트 범위를 동일한 파일의 이전 및/또는 후속 바이트 범위들과 연쇄시키도록 구성될 수도 있다.

아래의 XML 의사 코드는 SegmentInfo 및 SegmentInfoDefault 에 공통인 속성들을 그룹화하기 위한 예시적인 엘리먼트들의 세트를 제공하며, 이 엘리먼트들의 세트는 MPD (102) 에 의해 제공될 수도 있다. SegmentInfo 및 SegmentInfoDefault 의 예들은 다음을 포함한다:

아래의 XML 의사 코드는 세그먼트 URL 에 대한 예시적인 엘리먼트들의 세트를 제공하며, 이 엘리먼트들의 세트는 MPD (102) 에 의해 제공될 수도 있다.

아래의 XML 의사 코드는 URL 템플릿에 대한 예시적인 엘리먼트들의 세트를 제공하며, 이 엘리먼트들의 세트는 MPD (102) 에 의해 제공될 수도 있다.

이 방법으로, MPD (102) 는 URL 템플릿을 나타내는 정보를 포함할 수도 있다. 즉, 엘리먼트 byteRangeTemplate 은 요청되는 바이트 범위를 규정하는 URL 템플릿에 대한 데이터를 나타낸다. 더욱이, 이 방법으로, MPD (102) 는 템플릿의 사용이 요구되는지 또는 옵션적인지 여부를 나타내는 정보를 포함할 수도 있다. 즉, mustUseRangeURL 에 대한 데이터는 클라이언트 디바이스 (40) 가 종래의 HTTP 부분 GET 요청들 또는 템플릿을 이용하여 바이트 범위를 요청하는 것이 허용되는지 여부, 또는 클라이언트 디바이스 (40) 가 템플릿을 이용하는 것이 요구되는지를 나타낼 수도 있다. 더욱이, allowedByteRanges 에 대한 데이터는 요청될 수 있는 특정의 바이트 범위들, 또는 바이트 범위들에 대해 어떤 제한 사항들도 없는지 여부를 나타낼 수도 있다.

아래의 XML 의사 코드는 세그먼트 리스트에 대한 예시적인 엘리먼트들의 세트를 제공하며, 이 엘리먼트들의 세트는 MPD (102) 에 의해 제공될 수도 있다.

헤더 데이터 (112) 는, 존재할 때, 세그먼트들 (114) 의 특성들, 예컨대, 무작위 액세스 포인트들의 시간 로케이션들을 기술할 수도 있으며, 이 세그먼트들 (114) 중 어느 세그먼트는 무작위 액세스 포인트들, 세그먼트들 (114) 내 무작위 액세스 포인트들까지의 바이트 오프셋들, 세그먼트들 (114) 의 URL (uniform resource locator) 들, 또는 세그먼트들 (114) 의 다른 양태들을 포함한다. 헤더 데이터 (122) 는, 존재할 때, 세그먼트들 (124) 에 대한 유사한 특성들을 기술할 수도 있다. 이에 추가적으로 또는 대안적으로, 이런 특성들은 MPD (102) 내에 완전히 포함될 수도 있다.

세그먼트들 (114) 은 하나 이상의 코딩된 비디오 샘플들을 포함하며, 이 비디오 샘플들 각각은 비디오 데이터의 프레임들 또는 슬라이스들을 포함할 수도 있다. 세그먼트들 (114) 의 코딩된 비디오 샘플들의 각각은 유사한 특성들, 예컨대, 높이, 폭, 및 대역폭 요건들을 가질 수도 있다. 이런 특성들은 MPD (102) 의 데이터에 의해 기술될 수도 있지만, 이런 데이터는 도 4 의 예에 예시되지 않는다. MPD (102) 는 본 개시물에서 설명되는 시그널링된 정보 중 임의의 정보 또는 모두를 추가하여, 3GPP 사양에 의해 기술된 것과 같은 특성들을 포함할 수도 있다.

세그먼트들 (114, 124) 의 각각은 고유한 균일한 리소스 식별자 (URI), 예컨대, URL (uniform resource locator) 과 연관될 수도 있다. 따라서, 세그먼트들 (114, 124) 의 각각은 DASH 와 같은 스트리밍 네트워크 프로토콜을 이용하여, 독립적으로 취출가능할 수도 있다. 이 방법으로, 클라이언트 디바이스 (40) 와 같은 목적지 디바이스는 HTTP Get 요청을 이용하여 세그먼트들 (114 또는 124) 을 취출할 수도 있다. 일부 예들에서, 클라이언트 디바이스 (40) 는 HTTP 부분 GET 요청들을 이용하여, 세그먼트들 (114 또는 124) 의 특정의 바이트 범위들을 취출할 수도 있다.

위에서 언급한 바와 같이, MPD (102) 는 특정의 MPD 프로파일에 따를 수도 있다. MPD (102) 는 MPD (102) 및/또는 멀티미디어 콘텐츠 (100) 에 대한 MIME (Multipurpose Internet Mail Extension) 유형을 나타내는 정보를 포함할 수도 있다. 그러나, MIME 유형들은 일반적으로 어떤 코덱이 멀티미디어 콘텐츠를 제시하기 위해 요구되는지를 나타내지 않는다. 일반적으로, 디바이스가 MPD (102) 와 같은 멀티미디어 콘텐츠에 대한 MPD 를 취출할 수 있으면, 디바이스가 MPD 에 대응하는 멀티미디어 콘텐츠의 데이터를 플레이백할 수 있다고 가정된다. 그러나, 이 가정은 항상 안전하지는 않을 수도 있다. 따라서, 일부 예들에서, MPD (102) 는 MPD (102) 가 대응하는 프로파일을 나타내는 정보를 포함할 수도 있다.

MPD들이 대응할 수도 있는 비교적 작은 개수의 프로파일들이 있을 수도 있다. 프로파일들은 H.264/AVC 가 비디오 코딩을 위한 프로파일들 및 레벨들을 포함하는 방법과 유사하게, 해결 능력들에 대한 레벨들에 의해 지원될 수도 있다. MPD 프로파일들은 더 높은 프로파일이 모든 낮은 프로파일들의 모든 특성들을 포함할 수도 있다는 점에서, 어니언-쉘화 (onion-shelled) 될 수도 있다. 여러 프로파일들을 등록하는 등록 기관 (registration authority) 에 의한 등록 프로세스가 있을 수도 있다. 일부 예들에서, 클라이언트 디바이스 (40) 와 같은 클라이언트 디바이스는 MPD (102) 에 의해 시그널링된 표현들 (110 내지 120) 의 특성들과 같은, MPD 의 다른 데이터를 취출하기 전에, MPD (102) 와 같은 MPD 에 대한 프로파일을 나타내는 정보를 취출하도록 구성될 수도 있다. 이 방법으로, MPD (102) 에 대한 프로파일은 MPD (102) 에의 액세스가 제공되기 전에, 시그널링될 수도 있다.

프로파일 식별자는 보통 텍스트로 (예컨대, 보통 명칭 (plain name) 으로서), 또는 예비된 도메인 네임으로 제공될 수도 있다. 보통 명칭들은 3GPP 또는 또 다른 등록 기관과 같은 등록 기관에 의해 예비될 수도 있다. 프로파일은, 대응하는 멀티미디어 콘텐츠가 프로파일에 부합하고, 그리고, MPD 를 읽고 인식한 것을 번역하고 그리고 파악하지 못하는 자료 (material) 를 무시하기 위해 그 프로파일을 구현하는 리더 (예컨대, 클라이언트 디바이스) 에게 허가를 주도록 프로파일이 요구할 수도 있다는 점에서, 요구 및 허가로서 간주될 수도 있다.

프로파일들은 예를 들어, MPD (102) 의 특성들, 네트워크의 사용량, 미디어 포맷(들), 사용되는 코덱(들), 보호 포맷들, 및/또는 양적 척도들 (measures), 예컨대, 비트레이트들, 스크린 사이즈들 등과 같은 특성들을 기술할 수도 있다. 이 방법으로, MPD (102) 의 프로파일은 어느 코덱들이 MPD (102) 및/또는 멀티미디어 콘텐츠 (100) 의 데이터를 취출하기 위해 지원될 필요가 있는지를 나타내는 정보를 제공할 수도 있다. 프로파일들은 또한 "적합 포인트들 (conformance points)" 로서 기술될 수도 있다. MPD 가 부합하는 프로파일들은 MPD 의 "프로파일들 (Profiles)" 속성으로 나타낼 수도 있다. 따라서, 클라이언트 디바이스는 MPD (102) 의 추가적인 데이터를 취출하기 전에 "프로파일들" 속성에 관련된 정보를 포함하는 MPD (102) 의 부분을 취출하도록 구성될 수도 있다. 이의 대안으로, 프로파일들은 파라미터로서 MPD 의 MIME 유형으로 나타낼 수도 있다. 예를 들어, 프로파일들 "X, Y, 및 Z" 는 예컨대, 콘텐츠 준비 디바이스 (20) 에 의해, 다음 방식으로 시그널링될 수도 있다:

video/vnd.mpeg.mpd;profil="X,Y,Z"

도 5 는 예시적인 비디오 파일 (150) 의 엘리먼트들을 예시하는 블록도이며, 이 엘리먼트들은 도 4 의 세그먼트들 (114, 124) 중 하나와 같은, 표현의 세그먼트에 대응할 수도 있다. 세그먼트들 (114, 124) 의 각각은 도 5 의 예에 예시된 데이터의 배열에 실질적으로 부합하는 데이터를 포함할 수도 있다. 위에서 설명한 바와 같이, ISO 베이스 미디어 파일 포맷 및 그 확장판들에 따르는 비디오 파일들은 "박스들" 로서 지칭되는, 일련의 오브젝트들로 데이터를 저장한다. 도 5 의 예에서, 비디오 파일 (150) 은 파일 유형 (FTYP) 박스 (152), 영화 (MOOV) 박스 (154), 영화 프래그먼트들 (162) (또한, 영화 프래그먼트 박스들 (MOOF) 로서 지칭됨), 및 영화 프래그먼트 무작위 액세스 (MFRA) 박스 (164) 를 포함한다.

비디오 파일 (150) 은 일반적으로 멀티미디어 콘텐츠의 세그먼트의 일 예를 나타내며, 이 세그먼트는 표현들 (110 내지 120) (도 4) 중 하나에 포함될 수도 있다. 이 방법으로, 비디오 파일 (150) 은 세그먼트들 (114) 중 하나, 세그먼트들 (124) 중 하나, 또는 또 다른 표현의 세그먼트에 대응할 수도 있다. 본 개시물의 기법들에 따르면, 클라이언트 디바이스 (40) 와 같은 클라이언트 디바이스는 영화 프래그먼트들 (162) 의 서브세트를 바이트 범위를 규정하는 URL 을 이용하여 취출하도록 요청할 수도 있다. 바이트 범위는 영화 프래그먼트들 (162) 의 서브-시퀀스에 대응할 수도 있다. 이와 유사하게, 프록시 캐시 디바이스 (82) 와 같은 프록시 캐시 디바이스는 특정의 바이트 범위를 취출하라는 요청에 응답하여, 비디오 파일 (150) 의 데이터 모두를 취출할 수도 있다. 다른 예들에서, 프록시 캐시 디바이스 (82) 는 그 요청들의 세트가 비디오 파일 (150) 에 대한 전체 양의 데이터에 대응한다고 가정하면, 비디오 파일 (150) 의 바이트 범위들에 대한 요청들의 세트에 뒤따르는 비디오 파일 (150) 을 어셈블링할 수도 있다.

도 5 의 예에서, 비디오 파일 (150) 은 하나의 세그먼트 인덱스 (SIDX) 박스 (161) 를 포함한다. 일부 예들에서, 비디오 파일 (150) 은 추가적인 SIDX 박스들을, 예컨대, 영화 프래그먼트들 (162) 사이에 포함할 수도 있다. 일반적으로, SIDX 박스 (161) 와 같은 SIDX 박스들은 영화 프래그먼트들 (162) 중 하나 이상에 대한 바이트 범위들을 기술하는 정보를 포함한다. 다른 예들에서, SIDX 박스 (161) 및/또는 다른 SIDX 박스들은 MOOV 박스 (154) 내에, MOOV 박스 (154) 다음에, MFRA 박스 (164) 앞에 또는 다음에, 또는 비디오 파일 (150) 내의 다른 곳에서 제공될 수도 있다.

파일 유형 (FTYP) 박스 (152) 는 일반적으로 비디오 파일 (150) 에 대한 파일 유형을 기술한다. 파일 유형 박스 (152) 는 비디오 파일 (150) 에 대한 최상의 사용을 기술하는 사양을 식별하는 데이터를 포함할 수도 있다. 파일 유형 박스 (152) 는 MOOV 박스 (154), 영화 프래그먼트 박스들 (162), 및 MFRA 박스 (164) 앞에 배치될 수도 있다.

MOOV 박스 (154) 는, 도 5 의 예에서, 영화 헤더 (MVHD) 박스 (156), 트랙 (TRAK) 박스 (158), 및 하나 이상의 영화 확장 (MVEX) 박스들 (160) 을 포함한다. 일반적으로, MVHD 박스 (156) 는 비디오 파일 (150) 의 일반적인 특성들을 기술할 수도 있다. 예를 들어, MVHD 박스 (156) 는 비디오 파일 (150) 이 최초에 생성된 시점, 비디오 파일 (150) 이 마지막 수정된 시점, 비디오 파일 (150) 에 대한 시간척도, 비디오 파일 (150) 에 대한 플레이백의 지속기간을 기술하는 데이터, 또는 비디오 파일 (150) 을 일반적으로 기술하는 다른 데이터를 포함할 수도 있다.

TRAK 박스 (158) 는 비디오 파일 (150) 의 트랙에 대한 데이터를 포함할 수도 있다. TRAK 박스 (158) 는 TRAK 박스 (158) 에 대응하는 트랙의 특성들을 기술하는 트랙 헤더 (TKHD) 박스를 포함할 수도 있다. 일부 예들에서, TRAK 박스 (158) 는 코딩된 비디오 화상들을 포함할 수도 있지만, 다른 예들에서, 트랙의 코딩된 비디오 화상들은 영화 프래그먼트들 (162) 에 포함될 수도 있으며, 이 영화 프래그먼트들은 TRAK 박스 (158) 의 데이터에 의해 참조될 수도 있다.

일부 예들에서, 비디오 파일 (150) 은 하나보다 많은 트랙을 포함할 수도 있지만, 이것이 DASH 프로토콜이 동작하는데 필수적이지는 않다. 따라서, MOOV 박스 (154) 는 비디오 파일 (150) 에서 트랙들의 개수와 동일한 다수의 TRAK 박스들을 포함할 수도 있다. TRAK 박스 (158) 는 비디오 파일 (150) 의 대응하는 트랙의 특성들을 기술할 수도 있다. 예를 들어, TRAK 박스 (158) 는 대응하는 트랙에 대한 시간 및/또는 공간 정보를 기술할 수도 있다. MOOV 박스 (154) 의 TRAK 박스 (158) 와 유사한 TRAK 박스는 캡슐화 유닛 (30) (도 1) 이 비디오 파일 (150) 과 같은 비디오 파일에 파라미터 세트 트랙을 포함할 때 파라미터 세트 트랙의 특성들을 기술할 수도 있다. 캡슐화 유닛 (30) 은 파라미터 세트 트랙을 기술하는 TRAK 박스 내 파라미터 세트 트랙에서의 시퀀스 레벨 SEI 메시지들의 존재를 시그널링할 수도 있다.

MVEX 박스들 (160) 은 예컨대, 있다면, MOOV 박스 (154) 내에 포함된 비디오 데이터에 더해서, 비디오 파일 (150) 이 영화 프래그먼트들 (162) 을 포함한다는 것을 시그널링하기 위해, 대응하는 영화 프래그먼트들 (162) 의 특성들을 기술할 수도 있다. 비디오 데이터를 스트리밍하는 상황에서, 코딩된 비디오 화상들은 MOOV 박스 (154) 대신, 영화 프래그먼트들 (162) 에 포함될 수도 있다. 따라서, 모든 코딩된 비디오 샘플들은 MOOV 박스 (154) 대신, 영화 프래그먼트들 (162) 에 포함될 수도 있다.

MOOV 박스 (154) 는 비디오 파일 (150) 에서 영화 프래그먼트들 (162) 의 개수와 동일한 다수의 MVEX 박스들 (160) 을 포함할 수도 있다. MVEX 박스들 (160) 의 각각은 영화 프래그먼트들 (162) 의 대응하는 하나의 특성들을 기술할 수도 있다. 예를 들어, 각각의 MVEX 박스는 영화 프래그먼트들 (162) 의 대응하는 하나에 대한 시간 지속기간을 기술하는 영화 확장 헤더 박스 (MEHD) 박스를 포함할 수도 있다.

위에서 언급한 바와 같이, 캡슐화 유닛 (30) 은 시퀀스 데이터 세트를 실제 코딩된 비디오 데이터를 포함하지 않는 비디오 샘플에 저장할 수도 있다. 비디오 샘플은 일반적으로 특정의 시간 인스턴스에서 코딩된 화상의 표현인 액세스 유닛에 대응할 수도 있다. AVC 의 상황에서, 코딩된 화상은, 액세스 유닛의 모든 픽셀들을 구성하는 정보를 포함하는 하나 이상의 VCL NAL 유닛들, 및 SEI 메시지들과 같은 다른 관련 비-VCL NAL 유닛들을 포함한다. 따라서, 캡슐화 유닛 (30) 은 영화 프래그먼트들 (162) 중 하나에, 시퀀스 레벨 SEI 메시지들을 포함할 수도 있는 시퀀스 데이터 세트를 포함할 수도 있다. 캡슐화 유닛 (30) 은, 시퀀스 데이터 세트 및/또는 시퀀스 레벨 SEI 메시지들의 존재를, 영화 프래그먼트들 (162) 중 하나에 대응하는 MVEX 박스들 (160) 중 하나의 MVEX 박스 내의 영화 프래그먼트들 (162) 중 하나의 영화 프래그먼트에 존재하고 있는 것으로 시그널링할 수도 있다.

영화 프래그먼트들 (162) 은 하나 이상의 코딩된 비디오 화상들을 포함할 수도 있다. 일부 예들에서, 영화 프래그먼트들 (162) 은 하나 이상의 화상들의 그룹들 (GOPs) 을 포함할 수도 있으며, 그 화상들의 그룹들 각각은 다수의 코딩된 비디오 화상들, 예컨대, 프레임들 또는 화상들을 포함할 수도 있다. 게다가, 위에서 설명한 바와 같이, 영화 프래그먼트들 (162) 은 일부 예들에서, 시퀀스 데이터 세트들을 포함할 수도 있다. 영화 프래그먼트들 (162) 의 각각은 영화 프래그먼트 헤더 박스 (MFHD, 도 5 에 미도시) 를 포함할 수도 있다. MFHD 박스는 영화 프래그먼트에 대한 시퀀스 번호와 같은, 대응하는 영화 프래그먼트의 특성들을 기술할 수도 있다. 영화 프래그먼트들 (162) 은 시퀀스 번호의 순서로 비디오 파일 (150) 에 포함될 수도 있다.

MFRA 박스 (164) 는 비디오 파일 (150) 의 영화 프래그먼트들 (162) 내 무작위 액세스 포인트들을 기술할 수도 있다. 이것은 비디오 파일 (150) 내 특정의 시간 로케이션들에 대한 추적들을 수행하는 것과 같은, 트릭 모드들을 수행하는 것을 보조할 수도 있다. MFRA 박스 (164) 는 일반적으로 옵션적이며, 일부 예들에서, 비디오 파일들에 포함될 필요는 없다. 이와 유사하게, 클라이언트 디바이스 (40) 와 같은 클라이언트 디바이스는 비디오 파일 (150) 의 비디오 데이터를 정확히 디코딩하여 디스플레이하기 위해 반드시 MFRA 박스 (164) 를 참조할 필요는 없다. MFRA 박스 (164) 는 비디오 파일 (150) 의 트랙들의 개수와 동일하거나, 또는 일부 예들에서는, 비디오 파일 (150) 의 미디어 트랙들 (예컨대, 비-힌트 트랙들) 의 개수와 동일한, 다수의 트랙 프래그먼트 무작위 액세스 (TFRA) 박스들 (미도시) 을 포함할 수도 있다.

도 6 은 URL 템플릿 데이터의 표시들을 제공하고 URL 템플릿 데이터를 이용하여 클라이언트 디바이스에 의해 바이트 범위 요청들을 발생시키는 예시적인 방법을 예시하는 플로우차트이다. 비록 도 6 의 방법은 서버 디바이스 (60) 및 클라이언트 디바이스 (40) 에 대해 설명되지만, 다른 디바이스들이 도 6 의 방법의 방법들과 유사한 기법들을 구현할 수도 있는 것으로 이해되어야 한다. 예를 들어, 콘텐츠 준비 디바이스 (20) 또는 콘텐츠 배포 네트워크의 하나 이상의 네트워크 디바이스들, 예컨대 프록시 캐시 디바이스 (82) 또는 라우팅 디바이스들 (80) 이 서버 디바이스 (60) 에 기인하는 기능들 중 일부 또는 모두를 수행할 수도 있다.

도 6 에 나타내지는 않지만, 일부 예들에서, 클라이언트 디바이스 (40) 는 처음에 멀티미디어 콘텐츠를 요청하는 CDN 을 결정할 수도 있다. 일부 예들에서, 클라이언트 디바이스 (40) 는 복수의 CDN들로부터 CDN 을 선택할 수도 있으며, 반면 다른 예들에서, 재지향 서버 디바이스 (94) 와 같은 재지향 서버는 CDN 을 선택하고 선택된 CDN 을 나타내는 정보를 클라이언트 디바이스 (40) 에 제공할 수도 있다. 따라서, 클라이언트 디바이스 (40) 는 CDN 을 선택하거나 또는 CDN 의 표시를 수신하여, 멀티미디어 콘텐츠의 데이터를 요청하는 CDN 을 결정할 수도 있다. CDN 을 선택하는 하나의 예시적인 프로세스는 도 9 에 대해 아래에서 더 자세히 설명된다.

서버 디바이스 (60) 는 적응 세트들 및 URL 템플릿 데이터의 표시들을 클라이언트 디바이스 (40) 에 제공할 수도 있다 (200). 예를 들어, 서버 디바이스 (60) 는 MPD (102) (도 4) 를 클라이언트 디바이스 (40) 에 제공할 수도 있다. 위에서 설명한 바와 같이, MPD (102) 는 URL 템플릿 뿐만 아니라, 템플릿이 바이트 범위 요청들에 요구되는지 또는 옵션적인지 여부를 나타내는 정보를 포함할 수도 있다. 클라이언트 디바이스 (40) 는 적응 세트 특성들을 기술하는 정보를 예컨대, 서버 디바이스 (60) 로부터 수신된 MPD 파일로부터 수신할 수도 있다 (202). 이와 유사하게, 클라이언트 디바이스 (40) 는 URL 템플릿 및 템플릿의 사용이 바이트 범위들을 요청하기 위해 요구되는지 또는 옵션적인지 여부를 기술하는 정보를, 예컨대, 그 수신된 MPD 파일로부터 수신할 수도 있다.

클라이언트 디바이스 (40) 는 그 후 적응 세트 특성들을 분석하여, 클라이언트 디바이스 (40) 가 취출하거나, 디코딩하거나, 또는 렌더링하기로 선택할 수 없거나 또는 선택하지 않는 적응 세트들을 제거할 수도 있다. 예를 들어, 클라이언트 디바이스 (40) 는 디코딩 및 렌더링 능력들을 적응 세트들의 특성들과 비교하여, 부적절한 적응 세트들을 결정할 수도 있다. 또 다른 예로서, 클라이언트 디바이스 (40) 는 언어, 등급, 및 (예컨대, 3차원의 비디오 플레이백을 위해 특정의 카메라 각도들을 갖는 2개 이상의 뷰들에 의해 제공될 때와 같은) 깊이의 양에 대한 사용자 선호사항들을 비교하여, 바람직하지 않은 적응 세트들을 제거할 수도 있다. 클라이언트 디바이스 (40) 는 그 후 클라이언트 디바이스 (40) 의 디코딩 및 렌더링 능력들에 적어도 부분적으로 기초하여 적절한 적응 세트를 선택할 수도 있다 (204).

적응 세트를 선택한 후, 클라이언트 디바이스 (40) 는 적응 세트의 표현들을 상세히 기술하는 MPD 부분에 대한 데이터를 요청할 수도 있다. 이에 응답하여, 서버 디바이스 (60) 는 선택된 적응 세트에서의 다른 개개의 표현 특성들 중, 표현 비트레이트들의 표시들을 클라이언트 디바이스 (40) 에 제공할 수도 있다 (206). 예를 들어, 서버 디바이스 (60) 는 적응 세트들 (260) (도 6) 에 대한 MPD 부분들 중 특정 MPD 부분에 대한 데이터를 클라이언트 디바이스 (40) 에 전송할 수도 있다. 다른 예들에서, 클라이언트 디바이스 (40) 는 멀티미디어 콘텐츠에 대한 풀 MPD (예컨대, 도 5 의 MPD (202)) 를 이미 수신하였을 수도 있으며, 그러나 그 선택된 적응 세트에 구체적으로 대응하는 MPD 의 부분들을 상세히 분석할 수도 있다. 이 방법으로, 일부 예들에서, 도 6 의 단계 (206) 는 단계 (202) 및/또는 단계 (204) 보다 앞서 일어날 수도 있다.

어느 경우든, 그 표현들에 대한 비트레이트들을 포함하는 그 선택된 적응 세트의 표현들에 특정된 특성들을 수신한 후 (208), 클라이언트 디바이스 (40) 는 네트워크 대역폭의 현재 가용 양을 결정할 수도 있다 (210). 클라이언트 디바이스 (40) 는 그 후 선택된 적응 세트로부터 표현을 선택할 수도 있어서 (212), 그 선택된 표현이 네트워크 대역폭의 결정된 현재 가용 양만큼 수용될 수 있는 비트레이트를 갖는다. 표현들의 비트레이트들은 적응 세트에서 개개의 표현들의 코딩 특성들의 예들을 나타낸다. 클라이언트 디바이스 (40) 는 그 후 그 선택된 표현의 데이터를 URL 템플릿을 이용하여 요청할 수도 있다 (214).

예를 들어, 클라이언트 디바이스 (40) 는 그 선택된 표현의 세그먼트를 요청하기 위해 HTTP GET 요청을 구성할 수도 있으며, 여기서, HTTP GET 요청에서의 URL 은 데이터의 요청되는 바이트 범위를 규정한다. 이의 대안으로, 부분 GET 요청들이 허용된다고 (즉, URL 템플릿의 사용이 옵션적이라고) 가정하면, 클라이언트 디바이스 (40) 는 그 선택된 표현의 세그먼트의 바이트 범위를 규정하는 HTTP 부분 GET 을 구성할 수도 있다. 일부 예들에서, URL 템플릿 데이터는 허용가능한 특정의 바이트 범위들을 추가로 규정할 수도 있다. 이런 경우, 클라이언트 디바이스 (40) 는 가용 바이트 범위들 중 하나를 선택할 수도 있다. 어느 경우든, 클라이언트 디바이스 (40) 는 그 요청을 서버 디바이스 (60) 에 서브밋할 수도 있다. 위에서 언급한 바와 같이, 다른 예들에서, 클라이언트 디바이스 (40) 는 그 요청을 BaseURL 에 서브밋할 수도 있으며, 이 BaseURL 은 그 요청이 서버 디바이스 대신 그 요청을 서비스할 수도 있는 프록시 디바이스 또는 캐시 디바이스에 의해 수신되게 할 수도 있다.

도 6 의 예에서, 서버 디바이스 (60) 는 그 요청을 수신하고, 그에 응답하여, 그 요청된 데이터를 클라이언트 디바이스 (40) 에 전송할 수도 있다 (216). 예를 들어, 요청 프로세싱 유닛 (70) 은 그 수신된 요청의 데이터로부터의 클라이언트 디바이스 (40) 의 네트워크 어드레스, 예컨대, 그 수신된 요청의 소스 인터넷 프로토콜 (IP) 어드레스 및 소스 포트를 결정할 수도 있다. 요청 프로세싱 유닛 (70) 는 그 요청된 데이터를 포함하는 네트워크 패킷들을 형성하고, 예컨대, 클라이언트 디바이스 (40) 의 결정된 IP 어드레스를 목적지로 하는 그 요청된 데이터를 클라이언트 디바이스 (40) 에 전송할 수도 있다.

그 요청된 데이터를 수신한 후, 클라이언트 디바이스 (40) 는 그 수신된 데이터를 디코딩하고 디스플레이하기 시작할 수도 있다 (218). 그 요청되는 데이터를 수신하는 동안, 클라이언트 디바이스 (40) 는 계속해서, 현재 가용 네트워크 대역폭을 분석하고, 네트워크 대역폭의 현재 가용 양만큼 수용될 수 있는 비트레이트들을 갖는 표현들로부터의 요청들을 서브밋할 수도 있다 (210 내지 214). 네트워크 대역폭의 양이 변하면, 클라이언트 디바이스 (40) 는 그 선택된 적응 세트에서의 상이한 표현으로 적응적으로 스위칭할 수도 있다. 예를 들어, 클라이언트 디바이스 (40) 는 적응 세트에서의 이전 표현으로부터 요청되는 최종 세그먼트의 시간 로케이션에 대응하는 새로운 표현에서의 세그먼트를 결정할 수도 있으며, 그 후 그 새로운 표현에서의 그 결정된 세그먼트 (또는, 그의 부분) 를 요청할 수도 있다.

이 방법으로, 도 6 은 소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현의 파일의 바이트 범위를 결정하는 단계, 소스 디바이스의 요건들에 따른 파일 및 바이트 범위를 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 URL 을 형성하는 단계, 및 그 형성된 URL 을 규정하는 GET 요청을 소스 디바이스에 발행하는 단계를 포함하는, 멀티미디어 데이터를 취출하는 방법의 일 예를 나타낸다.

도 6 은 또한 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하는 단계로서, 상기 매니페스트 파일은 URL (uniform resource locator) 템플릿 및 바이트 범위 템플릿을 규정하며, 상기 URL 템플릿 및 바이트 범위 템플릿은 URL 내에 바이트 범위 요청을 포함하도록 URL 을 형성하기 위한 템플릿을 제공하는, 상기 매니페스트 파일을 제공하는 단계, URL 템플릿 및 바이트 범위 템플릿에 따라 구성된 URL 을 포함하는 요청을 수신하는 단계로서, 상기 요청의 URL 은 멀티미디어 콘텐츠의 표현의 바이트 범위를 규정하는, 상기 URL 을 포함하는 요청을 수신하는 단계, 및, 그 요청에 응답하여, 그 요청의 바이트 범위에 대응하는 표현의 멀티미디어 데이터를 출력하는 단계를 포함하는, 비디오 데이터에 대한 정보를 전송하는 방법의 일 예를 나타낸다.

도 7 은 URL 내에 바이트 범위를 규정하는 GET 요청을 발생시키는 예시적인 방법을 예시하는 플로우차트이다. 도 7 의 방법은 클라이언트 디바이스 (40) 와 같은 클라이언트 디바이스에 의해 수행될 수도 있다. 파선들을 가진 박스들은 옵션적인 단계들을 나타낸다. 유사한 방법이 프록시 캐시 디바이스 (82) 와 같은 중간 네트워크 디바이스에 의해 수행될 수도 있다. 이 방법에 대한 일부 약간의 변경들은 아래에서 설명하는 바와 같이, 중간 네트워크 디바이스에 의해 수행될 때에 이루어질 수도 있다. 예의 목적들을 위해, 도 7 의 방법은 클라이언트 디바이스 (40) 에 대해 설명된다. 일부 예들에서, 단계들 (230 내지 234) 은 도 6 의 단계들 (202 및 204) 과 실질적으로 동시에 수행될 수도 있으며, 단계들 (236 내지 244) 은 도 6 의 단계 (214) 에 대응할 수도 있다. 도 6 및 도 7 의 단계들은 반드시 나타낸 순서로 수행될 필요는 없으며, 추가적인 단계들이 수행될 수도 있거나 또는 어떤 단계들이 생략되거나 또는 순차적인 대신 병렬로 수행될 수도 있다.

먼저, 클라이언트 디바이스 (40) 는 멀티미디어 콘텐츠에 대한 MPD 파일에 대응하는 정보를 수신할 수도 있다 (230). MPD 파일은 HTTP GET 요청의 URL 에 바이트 범위를 내장하기 위한 URL 템플릿을 규정하는 정보를 포함할 수도 있다. 예를 들어, URL 템플릿은 URL 및 바이트 범위 템플릿 양자에 대해, 다음을 규정할 수도 있다:

MPD 파일은 URL 템플릿이 요구되는지 또는 옵션적인지 여부를 나타내는 정보를 더 포함할 수도 있다. 따라서, 클라이언트 디바이스 (40) 는 일부 예들에서, MPD 파일의 데이터의 분석에 기초하여, URL 템플릿이 요구되는지 또는 옵션적인지 여부를 결정할 수도 있다 (232). 이와 유사하게, 일부 예들에서, MPD 파일은 요청될 수 있는 허용된 바이트 범위들의 표시를 제공할 수도 있거나, 또는 바이트 범위들이 제한되지 않는다는 것을 나타낼 수도 있다. 따라서, 클라이언트 디바이스 (40) 는 일부 예들에서, MPD 파일을 이용하여, 허용된 바이트 범위들을 결정할 수도 있다 (234).

클라이언트 디바이스 (40) 는 그 후 세그먼트의 요청되는 바이트 범위를 결정할 수도 있다 (236). 예를 들어, 클라이언트 디바이스 (40) 가 선택된 멀티미디어 콘텐츠의 스트리밍 데이터를 막 시작하였으면, 클라이언트 디바이스 (40) 는 세그먼트의 서수의 제 1 바이트 범위를 요청하기로 결정할 수도 있다. 또 다른 예로서, 클라이언트 디바이스 (40) 가 세그먼트의 N 번째 바이트 범위를 이전에 요청하였으면, 클라이언트 디바이스 (40) 는 세그먼트의 N+1 번째 바이트 범위를 요청하기로 결정할 수도 있다. 클라이언트 디바이스 (40) 는 또한 선택된 표현에 대한 베이스 URL 뿐만 아니라, 세그먼트 식별자를 결정할 수도 있다 (238). 예를 들어, 위에서 설명한 바와 같이, 베이스 URL 은 "http://www.mp4player.com/TRON/" 에 대응할 수도 있으며, 세그먼트 식별자는 숫자, 알파벳, 영숫자, 또는 현재의 세그먼트를 나타내는 다른 값을 포함할 수도 있다. 세그먼트 식별자는 세그먼트 뿐만 아니라, 그 세그먼트가 포함되는 선택된 표현을 식별할 수도 있다. 예를 들어, 세그먼트 식별자는 선택된 표현의 대역폭 및/또는 인덱스를 규정하는 값들 뿐만 아니라, 그 선택된 표현의 세그먼트를 규정하는 값을 포함할 수도 있다.

따라서, 함께, 베이스 URL 및 세그먼트 식별자는, 클라이언트 디바이스 (40) 가 다음 바이트 범위를 취출하기 위해 HTTP GET 요청에 궁극적으로 포함시키는 URL 의 제 1 부분을 형성할 수도 있다. 클라이언트 디바이스 (40) 는 세그먼트 ID 뿐만 아니라, 요청되는 바이트 범위의 식별자를 베이스 URL 에 첨부하여 (240), URL 을 HTTP GET 요청에 포함되게 형성할 수도 있다. 예를 들어, 그 세그먼트가 "segment.1000.27" 을 이용하여 식별된다고 가정하고, 그리고 요청되는 바이트 범위가 바이트들 435291 내지 560829 이라고 가정하면, 클라이언트 디바이스 (40) 는 이 예에서, "segment.1000.27/435291/560829" 를 베이스 URL 에 첨부하여, 다음 URL 을 형성할 수도 있다 : "http://www.mp4player.com/TRON/segment.1000.27/435291/560829". 이 URL 은 URL 의 파일 경로 부분에 대응한다. URL 의 또 다른 부분은 프로토콜, 예컨대, "HTTP/1.1", 또는 대응하는 파일 경로에서 그 파일을 취출하기 위한 다른 데이터를 규정할 수도 있다.

클라이언트 디바이스 (40) 는 그 후 그 구성된 URL 을 포함하는 HTTP GET 요청을 형성할 수도 있다 (242). 예를 들어, 클라이언트 디바이스 (40) 는 URL 앞에 지령 "GET" 을 미리 첨부하고 URL 뒤에 "HTTP/1.1" 를 첨부할 뿐만 아니라, 멀티미디어 콘텐츠의 호스트, 예컨대, "www.mp4player.com" 를 규정함으로써, 그 요청이 GET 요청임을 규정할 수도 있다. 일부 예들에서, 클라이언트 디바이스 (40) 는 예컨대, 본 개시물의 확장 헤더 "X-Dash-Byte-Range-URL" 를 이용함으로써, 바이트 범위가 URL 에 포함된다는 표시를 포함하도록 요청을 형성할 수도 있다. 따라서, 바이트 범위를 규정하는 URL 을 가진 그 구성된 GET 요청은 다음에 대응할 수도 있다:

클라이언트 디바이스 (40) 는 그 후 그 형성된 HTTP GET 요청을 서버, 예컨대, www.mp4player.com 으로 전송할 수도 있다 (244). 위에서 언급한 바와 같이, 중간 네트워크 디바이스는 도 7 의 방법과 유사한 방법을 수행하여, 바이트 범위를 파일 경로 부분에 규정하는 URL 을 포함하는 HTTP GET 요청을 형성할 수도 있다. 일반적으로, 중간 네트워크 디바이스는 MPD 파일을 수신하여, 서버 디바이스로부터의 멀티미디어 콘텐츠에 대한 URL 템플릿을 결정할 수도 있으며, 클라이언트 디바이스로부터 종래의 HTTP 부분 GET 요청을 수신할 수도 있다. 중간 네트워크 디바이스는 그 후 (바이트 범위 템플릿을 포함하는) URL 템플릿을 이용하여 부분 GET 요청으로부터 HTTP GET 요청을 형성할 수도 있어서, HTTP GET 요청이 부분 GET 요청에 의해 나타내는 바이트 범위를 규정하는 URL 을 포함한다.

이 방법으로, 도 7 의 방법은 멀티미디어 데이터를 취출하는 방법의 일 예를 나타낸다. 도 7 의 예시적인 방법은 소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현의 파일의 바이트 범위를 결정하는 단계, 소스 디바이스의 요건들에 따른 파일 및 바이트 범위를 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 URL 을 형성하는 단계, 및 그 형성된 URL 을 규정하는 GET 요청을 소스 디바이스에 발행하는 단계를 포함한다.

도 8 은 HTTP GET 요청이 클라이언트 디바이스와 서버 디바이스 사이에 중간 네트워크 디바이스를 통해 교환되는 예시적인 방법을 예시하는 플로우차트이다. 이 예시적인 방법이 클라이언트 디바이스 (40), 프록시 캐시 디바이스 (82), 및 서버 디바이스 (60) 에 대해 설명되지만, 다른 디바이스들이 유사한 방법을 수행하도록 구성될 수도 있는 것으로 이해되어야 한다.

도 8 의 예에서, 클라이언트 디바이스 (40) 는 멀티미디어 콘텐츠의 표현을 선택한다 (250). 그 후, 클라이언트 디바이스 (40) 는 URL 템플릿에 따라 HTTP GET 요청을 형성하여 (252), HTTP GET 요청이 그 요청의 URL 에 바이트 범위를 규정한다. URL 템플릿은 URL 의 바이트 범위 템플릿에 대한 데이터를 포함할 수도 있다. 일부 예들에서, 클라이언트 디바이스 (40) 는 예컨대, 본 개시물의 확장 헤더 "X-Dash-Byte-Range-URL" 를 이용함으로써, 바이트 범위가 URL 에 포함되어 있다는 표시를 포함하도록 요청을 형성할 수도 있다. 그 요청을 형성한 후, 클라이언트 디바이스 (40) 는 HTTP GET 요청을 서버 디바이스 (60) 에 서브밋할 수도 있다 (254).

프록시 캐시 디바이스 (82) 는 네트워크 루트를 따라서 클라이언트 디바이스 (40) 와 서버 디바이스 (60) 사이에, 이 예에서는, 예컨대, 도 2 에 나타낸 바와 같이, 놓여 있다. 따라서, 프록시 캐시 디바이스 (82) 는 클라이언트 디바이스 (40) 에 의해 발행된 요청을 수신할 수도 있다 (256). 프록시 캐시 디바이스 (82) 는 그 요청의 URL 을 분석함으로써 그 요청이 바이트 범위에 대한 요청이라고 결정하고, 그 요청을 서버 디바이스 (60) 로 포워딩할 수도 있다 (258). 이의 대안으로, 프록시 캐시 디바이스 (82) 는 확장 헤더 "X-Dash-Byte-Range-URL" 의 검출시 그 요청이 바이트 범위에 대한 요청이라고 결정할 수도 있다. 서버 디바이스 (60) 는 궁극적으로 그 요청을 수신하고 (260), 그리고 그 요청된 바이트 범위를 전송할 수도 있다 (262). 즉, 서버 디바이스 (60) 는 멀티미디어 콘텐츠의 표현의 각각의 세그먼트로부터의 그 요청된 바이트 범위에 대응하는 데이터를 클라이언트 디바이스 (40) 에 제공한다.

또, 프록시 캐시 디바이스 (82) 는 클라이언트 디바이스 (40) 와 서버 디바이스 (60) 사이의 루트에 따르는 프록시 캐시 디바이스 (82) 의 로케이션으로 인해, 그 요청된 바이트 범위의 데이터를 수신할 수도 있다 (264). 프록시 캐시 디바이스 (82) 는 그 후 그 수신된 데이터를, 대응하는 멀티미디어 콘텐츠의 임의의 이전에 캐싱된 데이터에 추가할 수도 있다 (266). 어떤 데이터도 아직 수신되지 않았으면, 프록시 캐시 디바이스 (82) 는 멀티미디어 콘텐츠에 대한 새로운 로컬로 캐싱된 데이터의 세트를 형성할 것이다. 프록시 캐시 디바이스 (82) 는 또한 멀티미디어 콘텐츠에 대한 후속 수신된 데이터를 멀티미디어 콘텐츠에 대한 현재 캐싱된 데이터와 연쇄시킬 수도 있다. 프록시 캐시 디바이스 (82) 는 또한 그 바이트 범위의 수신된 데이터를 클라이언트 디바이스 (40) 로 전송할 수도 있다 (268). 클라이언트 디바이스 (40) 는 이어서, 그 수신된 데이터를 버퍼링하고, 디코딩하며 디스플레이할 수도 있다 (270).

도 7 에 대해 언급한 바와 같이, 일부 예들에서, 중간 네트워크 디바이스는 부분 GET 요청을 바이트 범위를 규정하는 URL 을 포함하는 HTTP GET 요청으로 변환하도록 구성될 수도 있다. 이를 행하기 위해, 클라이언트 디바이스 (40) 는 단계 (252) 의 HTTP GET 요청 대신, 부분 GET 요청을 생성할 것이다. 그 후, 프록시 캐시 디바이스 (82) 는 단계들 (256 과 258) 사이에서, 예컨대, URL 템플릿 및 바이트 범위 템플릿에 따라 부분 GET 요청을 변환할 수도 있다. 이의 대안으로, 프록시 캐시 디바이스 (82) 는 본 개시물의 기법들에 따라, 검출된 "Range:" 헤더를 새로운 확장 헤더 "X-Dash-ByteRange-URL" 로 변환할 수도 있으며, 부분 GET 요청의 원래 규정된 바이트 범위가 뒤따를 수도 있다.

도 9 는 멀티미디어 콘텐츠의 데이터를 취출할 CDN 을 결정하는 예시적인 방법을 예시하는 플로우차트이다. 도 9 는 단지 하나의 예시적인 방법을 나타낸다. 위에서 설명한 바와 같이, CDN 을 선택하는 다른 방법들이 또한 예컨대, 재지향 서버 디바이스의 사용 없이, 가능하다. 예를 들어, 클라이언트 디바이스 (40) 는 재지향 서버 디바이스 대신, 선택 기준들을 수신하여 평가하도록 구성될 수도 있다. 예의 목적들을 위해, 도 9 의 방법은 클라이언트 디바이스 (40) 및 재지향 서버 디바이스 (94) 에 대해 설명된다.

이 예에서, 클라이언트 디바이스 (40) 가 MPD 파일을 이미 수신하였다고 가정하면, 클라이언트 디바이스 (40) 는 POST 메시지를 재지향 서버 디바이스 (94) 로 전송한다 (300). 멀티미디어 콘텐츠에 대한 MPD 파일은 재지향 URL 에서 재지향 서버 디바이스 (94) 에 대한 어드레스를 규정할 수도 있다. 따라서, 클라이언트 디바이스 (40) 는 POST 메시지를 재지향 URL 로 전송하여, POST 메시지가 궁극적으로 재지향 서버 디바이스 (94) 에 도달되게 할 수도 있다.

재지향 서버 디바이스 (94) 는 POST 메시지를 수신할 수도 있다 (302). 이에 응답하여, 재지향 서버 디바이스 (94) 는 CDN 을 선택하는 선택 기준들을 평가할 수도 있다 (304). 선택 기준들은 가중 무작위 기준들 (weighted random criteria), 시각, 클라이언트 디바이스 (40) 와 CDN들 사이의 라운드 트립 지연, 클라이언트 디바이스 (40) 와 CDN들 사이의 홉 수들, 클라이언트 디바이스 (40) 및 CDN들의 로케이션들, 또는 다른 기준들 중 임의의 것 또는 모두를 포함할 수도 있다. 선택 기준들을 평가함으로써, 재지향 서버 디바이스 (94) 는 선택 기준들로부터 CDN 을 결정할 수도 있다 (306). 더욱이, 재지향 서버 디바이스 (94) 는 CDN들의 각각에서 멀티미디어 콘텐츠에 대한 베이스 URL들을 나타내는 데이터로 구성될 수도 있다. 따라서, 재지향 서버 디바이스 (94) 는 그 결정된 CDN 에 대한 베이스 ULR 을 결정할 수도 있다 (308).

재지향 서버 디바이스 (94) 는 그 후 결정된 베이스 URL 을 클라이언트 디바이스 (40) 로 전송할 수도 있다 (310). 따라서, 클라이언트 디바이스 (40) 는 특정의 바이트 범위를 규정하는 HTTP GET 요청을 형성할 수도 있으며 (312), 그 HTTP GET 요청은 그 수신된 베이스 URL 을 규정할 수도 있다. 더욱이, 클라이언트 디바이스 (40) 는 HTTP GET 요청을 새로운 베이스 URL 로 전송하여 (314), HTTP GET 요청이 그 결정된 CDN 으로 지향되게 할 수도 있다. 즉, 클라이언트 디바이스 (40) 는 베이스 URL 에 관한 도메인 네임 서비스 (domain name service; DNS) 탐색을 수행하여, GET 요청을 발행할 CDN 의 디바이스의 IP 어드레스를 결정할 수도 있으며, 그 후 GET 요청을 그 결정된 IP 어드레스로 전송할 수도 있다. 그 뒤에, CDN 은 그 선택된 바이트 범위로 GET 요청에 응답할 수도 있으며, 클라이언트 디바이스 (40) 는 계속해서 일련의 바이트 범위 요청들을 동일한 CDN 에 서브밋할 수도 있다.

하나 이상의 예들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로 구현될 수도 있다. 소프트웨어로 구현되는 경우, 그 기능들은 하나 이상의 명령들 또는 코드들로서 컴퓨터 판독가능 매체 상에 저장되거나 송신되어, 하드웨어-기반의 프로세싱 유닛에 의해 실행될 수도 있다. 컴퓨터 판독가능 매체는 컴퓨터 판독가능 저장 매체들을 포함할 수도 있으며, 이 컴퓨터 판독가능 저장 매체들은 데이터 저장 매체와 같은 유형의 매체, 또는 예컨대, 통신 프로토콜에 따라 한 장소로부터 다른 장소로의 컴퓨터 프로그램의 전송을 용이하게 하는 임의의 매체를 포함한 통신 매체들에 대응한다. 이 방법으로, 컴퓨터 판독가능 매체들은 일반적으로 (1) 비일시적인 유형의 컴퓨터 판독가능 저장 매체 또는 (2) 신호 또는 캐리어 파와 같은 통신 매체에 대응할 수도 있다. 데이터 저장 매체는 본 개시물에서 설명하는 기법들의 구현을 위한 명령들, 코드 및/또는 데이터 구조들을 취출하기 위해 하나 이상의 컴퓨터들 또는 하나 이상의 프로세서들에 의해 액세스될 수 있는 임의의 가용 매체들일 수도 있다. 컴퓨터 프로그램 제품은 컴퓨터 판독가능 매체를 포함할 수도 있다.

일 예로서, 이에 한정하지 않고, 이런 컴퓨터 판독가능 저장 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광디스크 저장, 자기디스크 저장, 또는 다른 자기 저장 디바이스들, 플래시 메모리, 또는 원하는 프로그램 코드를 명령들 또는 데이터 구조들의 형태로 저장하는데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 또한, 임의의 접속이 컴퓨터 판독가능 매체로 적절히 지칭된다. 예를 들어, 동축 케이블, 광섬유 케이블, 이중 권선, 디지털 가입자 회선 (DSL), 또는 무선 기술들 예컨대 적외선, 무선, 및 마이크로파를 이용하여 명령들이 웹사이트, 서버, 또는 다른 원격 소스로부터 송신되는 경우, 동축 케이블, 광섬유 케이블, 이중 권선, DSL, 또는 무선 기술들 예컨대 적외선, 무선, 및 마이크로파가 그 매체의 정의에 포함된다. 그러나, 컴퓨터 판독가능 저장 매체들 및 데이터 저장 매체들이 접속부들, 캐리어 파들, 신호들, 또는 다른 일시적인 매체들을 포함하지 않고, 대신 비일시적인 유형의 저장 매체들에 관련되는 것으로 이해되어야 한다. 디스크 (disk) 및 디스크 (disc) 는, 본원에서 사용할 때, 컴팩트 디스크 (CD), 레이저 디스크, 광 디스크, 디지털 다기능 디스크 (DVD), 플로피 디스크 및 블루-레이 디스크를 포함하며, 본원에서, 디스크들 (disks) 은 데이터를 자기적으로 보통 재생하지만, 디스크들 (discs) 은 레이저로 데이터를 광학적으로 재생한다. 앞에서 언급한 것들의 조합들이 또한 컴퓨터 판독가능 매체들의 범위 내에 포함되어야 한다.

명령들은 하나 이상의 디지털 신호 프로세서들 (DSPs), 범용 마이크로프로세서들, 주문형 집적회로들 (ASICs), 필드 프로그래밍가능 로직 어레이들 (FPGAs), 또는 다른 등가의 통합 또는 이산 로직 회로와 같은, 하나 이상의 프로세서들에 의해 실행될 수도 있다. 따라서, 용어 “프로세서" 는, 본원에서 사용될 때 전술한 구조 중 임의의 구조 또는 본원에서 설명하는 기법들의 구현에 적절한 임의의 다른 구조를 지칭할 수도 있다. 게다가, 일부 양태들에서, 본원에서 설명하는 기능 전용 하드웨어 및/또는 인코딩 및 디코딩을 위해 구성되는 소프트웨어 모듈들 내에 제공되거나, 또는 결합된 코덱에 포함될 수도 있다. 또한, 이 기법들은 하나 이상의 회로들 또는 로직 엘리먼트들로 전적으로 구현될 수 있다.

본 개시물의 기법들은 무선 핸드셋, 집적 회로 (IC) 또는 IC들의 세트 (예컨대, 칩 세트) 를 포함한, 매우 다양한 디바이스들 또는 장치들로 구현될 수도 있다. 개시한 기법들을 수행하도록 구성되는 디바이스들의 기능적 양태들을 강조하기 위해서 여러 컴포넌트들, 모듈들, 또는 유닛들이 본 개시물에서 설명되지만, 상이한 하드웨어 유닛들에 의한 실현을 반드시 필요로 하지는 않는다. 더 정확히 말하면, 위에서 설명한 바와 같이, 여러 유닛들이 코덱 하드웨어 유닛에 결합되거나 또는 적절한 소프트웨어 및/또는 펌웨어와 함께, 위에서 설명한 바와 같은 하나 이상의 프로세서들을 포함한, 상호작용하는 하드웨어 유닛들의 컬렉션으로 제공될 수도 있다.

여러 예들이 설명되었다. 이들 및 다른 예들은 다음 청구항들의 범위 이내이다.

Claims (56)

1. 멀티미디어 데이터를 취출하는 방법으로서,
   소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현 (representation) 의 파일의 바이트 범위를 결정하는 단계;
   상기 소스 디바이스의 요건들에 따른 상기 파일 및 상기 바이트 범위를 템플릿에 따른 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 상기 URL 을 형성하는 단계; 및
   형성된 상기 URL 을 규정하는 GET 요청을 상기 소스 디바이스에 발행하는 단계를 포함하는, 멀티미디어 데이터를 취출하는 방법.
2. 제 1 항에 있어서,
   상기 멀티미디어 콘텐츠에 대한 매니페스트 파일 (manifest file) 을 수신하는 단계를 더 포함하고,
   상기 매니페스트 파일은, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하며,
   상기 바이트 범위를 결정하는 단계는, 상기 복수의 바이트 범위들로부터 상기 표현의 바이트 범위를 선택하는 단계를 포함하는, 멀티미디어 데이터를 취출하는 방법.
3. 제 1 항에 있어서,
   세그먼트 인덱스 데이터 구조를 포함하는 상기 표현의 데이터를 수신하는 단계를 더 포함하고,
   상기 세그먼트 인덱스 데이터 구조는, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하며,
   상기 바이트 범위를 결정하는 단계는, 상기 복수의 바이트 범위들로부터 상기 표현의 바이트 범위를 선택하는 단계를 포함하는, 멀티미디어 데이터를 취출하는 방법.
4. 제 1 항에 있어서,
   상기 GET 요청은 "Range:" 헤더를 포함하지 않는, 멀티미디어 데이터를 취출하는 방법.
5. 제 1 항에 있어서,
   상기 GET 요청의 상기 URL 에 상기 바이트 범위의 로케이션을 나타내는 확장 헤더를 포함하도록 상기 GET 요청을 형성하는 단계를 더 포함하는, 멀티미디어 데이터를 취출하는 방법.
6. 제 1 항에 있어서,
   복수의 콘텐츠 배포 네트워크 (content distribution network; CDN) 들 중 하나의 콘텐츠 배포 네트워크를 선택하기 위한 하나 이상의 선택 기준들을 수신하는 단계; 및
   상기 선택 기준들에 기초하여 상기 복수의 CDN들로부터 CDN 을 선택하는 단계
   를 더 포함하고,
   상기 GET 요청을 발행하는 단계는, 상기 GET 요청을, 선택된 상기 CDN 에 발행하는 단계를 포함하며,
   상기 템플릿에 따른 상기 URL 을 형성하는 단계는, 상기 URL 을, 선택된 상기 CDN 에 특정된 바이트 범위 템플릿에 따라 형성하는 단계를 포함하는, 멀티미디어 데이터를 취출하는 방법.
7. 제 1 항에 있어서,
   상기 데이터를 취출할 복수의 콘텐츠 배포 네트워크 (content distribution network; CDN) 들 중 하나의 콘텐츠 배포 네트워크를 결정하기 위해 POST 메시지를 재지향 (redirection) URL 에 서브밋 (submit) 하는 단계; 및
   상기 POST 메시지에 응답하여, 상기 복수의 CDN들 중 하나의 CDN 에 대한 베이스 URL 의 표시를 수신하는 단계
   를 더 포함하고,
   상기 URL 을 형성하는 단계는, 상기 복수의 CDN들 중 하나의 CDN 에 대한 수신된 상기 베이스 URL 을 규정하기 위해 상기 URL 을 형성하는 단계를 포함하고,
   상기 템플릿에 따른 상기 URL 을 형성하는 단계는, 상기 URL 을, 선택된 상기 CDN 에 특정된 바이트 범위 템플릿에 따라 형성하는 단계를 포함하며,
   상기 GET 요청을 발행하는 단계는, 상기 GET 요청을 상기 복수의 CDN들 중 하나의 CDN 에 발행하는 단계를 포함하는, 멀티미디어 데이터를 취출하는 방법.
8. 제 7 항에 있어서,
   상기 POST 메시지를 서브밋하는 단계는,
   지오로케이션 정보, 홉 수 (hop count) 들, 및 로컬 시각 중 하나 이상을 포함하는 로컬 정보, 선택 기준들, 및 BaseURL 중 하나 이상을 나타내는 하나 이상의 POST 메시지들을 상기 재지향 URL 에 서브밋하는 단계를 포함하는, 멀티미디어 데이터를 취출하는 방법.
9. 제 1 항에 있어서,
   상기 소스 디바이스로부터 상기 템플릿을 나타내는 정보를 수신하는 단계를 더 포함하는, 멀티미디어 데이터를 취출하는 방법.
10. 제 1 항에 있어서,
    상기 결정하는 단계는, 클라이언트 디바이스에 의해 결정하는 단계를 포함하고,
    상기 형성하는 단계는, 상기 클라이언트 디바이스에 의해 형성하는 단계를 포함하며,
    상기 발행하는 단계는, 상기 클라이언트 디바이스에 의해 발행하는 단계를 포함하는, 멀티미디어 데이터를 취출하는 방법.
11. 멀티미디어 데이터에 대한 정보를 수신하는 디바이스로서,
    상기 디바이스는 하나 이상의 프로세서들을 포함하고,
    상기 하나 이상의 프로세서들은,
    소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현의 파일의 바이트 범위를 결정하고,
    상기 소스 디바이스의 요건들에 따른 상기 파일 및 상기 바이트 범위를 템플릿에 따른 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 상기 URL 을 형성하며,
    형성된 상기 URL 을 규정하는 GET 요청을 상기 소스 디바이스에 발행하도록
    구성되는, 멀티미디어 데이터에 대한 정보를 수신하는 디바이스.
12. 제 11 항에 있어서,
    상기 하나 이상의 프로세서들은 또한, 상기 멀티미디어 콘텐츠에 대한 매니페스트 파일을 수신하도록 구성되고,
    상기 매니페스트 파일은, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하며,
    상기 바이트 범위를 결정하기 위해, 상기 하나 이상의 프로세서들은 상기 복수의 바이트 범위들로부터 상기 표현의 바이트 범위를 선택하도록 구성되는, 멀티미디어 데이터에 대한 정보를 수신하는 디바이스.
13. 제 11 항에 있어서,
    상기 하나 이상의 프로세서들은 또한, 세그먼트 인덱스 데이터 구조를 포함하는 상기 표현의 데이터를 수신하도록 구성되고,
    상기 세그먼트 인덱스 데이터 구조는, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하며,
    상기 바이트 범위를 결정하기 위해, 상기 하나 이상의 프로세서들은 상기 복수의 바이트 범위들로부터 상기 표현의 바이트 범위를 선택하도록 구성되는, 멀티미디어 데이터에 대한 정보를 수신하는 디바이스.
14. 제 11 항에 있어서,
    상기 GET 요청은 "Range:" 헤더를 포함하지 않는, 멀티미디어 데이터에 대한 정보를 수신하는 디바이스.
15. 제 11 항에 있어서,
    상기 하나 이상의 프로세서들은 또한, 상기 GET 요청의 상기 URL 에 상기 바이트 범위의 로케이션을 나타내는 확장 헤더를 포함하도록 상기 GET 요청을 형성하도록 구성되는, 멀티미디어 데이터에 대한 정보를 수신하는 디바이스.
16. 제 11 항에 있어서,
    상기 하나 이상의 프로세서들은 또한,
    복수의 콘텐츠 배포 네트워크 (content distribution network; CDN) 들 중 하나의 콘텐츠 배포 네트워크를 선택하기 위한 하나 이상의 선택 기준들을 수신하고, 상기 선택 기준들에 기초하여 상기 복수의 CDN들로부터 CDN 을 선택하며, 상기 GET 요청을, 선택된 상기 CDN 에 발행하도록 구성되고,
    상기 템플릿은, 선택된 상기 CDN 에 특정된 바이트 범위 템플릿을 포함하는, 멀티미디어 데이터에 대한 정보를 수신하는 디바이스.
17. 제 11 항에 있어서,
    상기 디바이스는,
    집적 회로;
    마이크로프로세서; 및
    상기 하나 이상의 프로세서들을 포함하는 무선 통신 디바이스
    중 적어도 하나를 포함하는, 멀티미디어 데이터에 대한 정보를 수신하는 디바이스.
18. 멀티미디어 데이터를 취출하는 디바이스로서,
    소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현의 파일의 바이트 범위를 결정하는 수단;
    상기 소스 디바이스의 요건들에 따른 상기 파일 및 상기 바이트 범위를 템플릿에 따른 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 상기 URL 을 형성하는 수단; 및
    형성된 상기 URL 을 규정하는 GET 요청을 상기 소스 디바이스에 발행하는 수단을 포함하는, 멀티미디어 데이터를 취출하는 디바이스.
19. 제 18 항에 있어서,
    상기 멀티미디어 콘텐츠에 대한 매니페스트 파일을 수신하는 수단을 더 포함하고,
    상기 매니페스트 파일은, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하며,
    상기 바이트 범위를 결정하는 수단은, 상기 복수의 바이트 범위들로부터 상기 표현의 바이트 범위를 선택하는 수단을 포함하는, 멀티미디어 데이터를 취출하는 디바이스.
20. 제 18 항에 있어서,
    세그먼트 인덱스 데이터 구조를 포함하는 상기 표현의 데이터를 수신하는 수단을 더 포함하고,
    상기 세그먼트 인덱스 데이터 구조는, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하며,
    상기 바이트 범위를 결정하는 수단은, 상기 복수의 바이트 범위들로부터 상기 표현의 바이트 범위를 선택하는 수단을 포함하는, 멀티미디어 데이터를 취출하는 디바이스.
21. 제 18 항에 있어서,
    상기 GET 요청은 "Range:" 헤더를 포함하지 않는, 멀티미디어 데이터를 취출하는 디바이스.
22. 제 18 항에 있어서,
    상기 GET 요청의 상기 URL 에 상기 바이트 범위의 로케이션을 나타내는 확장 헤더를 포함하도록 상기 GET 요청을 형성하는 수단을 더 포함하는, 멀티미디어 데이터를 취출하는 디바이스.
23. 제 18 항에 있어서,
    복수의 콘텐츠 배포 네트워크 (content distribution network; CDN) 들 중 하나의 콘텐츠 배포 네트워크를 선택하기 위한 하나 이상의 선택 기준들을 수신하는 수단; 및
    상기 선택 기준들에 기초하여 상기 복수의 CDN들로부터 CDN 을 선택하는 수단
    을 더 포함하고,
    상기 GET 요청을 발행하는 수단은, 상기 GET 요청을, 선택된 상기 CDN 에 발행하는 수단을 포함하며,
    상기 템플릿에 따른 상기 URL 을 형성하는 수단은, 상기 URL 을, 선택된 상기 CDN 에 특정된 바이트 범위 템플릿에 따라 형성하는 수단을 포함하는, 멀티미디어 데이터를 취출하는 디바이스.
24. 명령들을 저장하고 있는 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품으로서,
    상기 명령들은, 실행될 때, 멀티미디어 데이터를 취출하는 디바이스의 하나 이상의 프로세서들로 하여금,
    소스 디바이스로부터의 요청에 대해 멀티미디어 콘텐츠의 표현의 파일의 바이트 범위를 결정하게 하고;
    상기 소스 디바이스의 요건들에 따른 상기 파일 및 상기 바이트 범위를 템플릿에 따른 URL (uniform resource locator) 의 파일 경로 부분에서 규정하는 상기 URL 을 형성하게 하며;
    형성된 상기 URL 을 규정하는 GET 요청을 상기 소스 디바이스에 발행하게 하는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.
25. 제 24 항에 있어서,
    상기 프로세서로 하여금, 상기 멀티미디어 콘텐츠에 대한 매니페스트 파일을 수신하게 하는 명령들을 더 포함하고,
    상기 매니페스트 파일은, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하며,
    상기 프로세서로 하여금 상기 바이트 범위를 결정하게 하는 명령들은,
    상기 프로세서로 하여금, 상기 복수의 바이트 범위들로부터 상기 표현의 바이트 범위를 선택하게 하는 명령들을 포함하는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.
26. 제 24 항에 있어서,
    상기 프로세서로 하여금, 세그먼트 인덱스 데이터 구조를 포함하는 상기 표현의 데이터를 수신하게 하는 명령들을 더 포함하고,
    상기 세그먼트 인덱스 데이터 구조는, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하며,
    상기 프로세서로 하여금 상기 바이트 범위를 결정하게 하는 명령들은,
    상기 프로세서로 하여금, 상기 복수의 바이트 범위들로부터 상기 표현의 바이트 범위를 선택하게 하는 명령들을 포함하는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.
27. 제 24 항에 있어서,
    상기 GET 요청은 "Range:" 헤더를 포함하지 않는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.
28. 제 24 항에 있어서,
    상기 프로세서로 하여금, 상기 GET 요청의 상기 URL 에 상기 바이트 범위의 로케이션을 나타내는 확장 헤더를 포함하도록 상기 GET 요청을 형성하게 하는 명령들을 더 포함하는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.
29. 제 24 항에 있어서,
    상기 프로세서로 하여금,
    복수의 콘텐츠 배포 네트워크 (content distribution network; CDN) 들 중 하나의 콘텐츠 배포 네트워크를 선택하기 위한 하나 이상의 선택 기준들을 수신하게 하고;
    상기 선택 기준들에 기초하여 상기 복수의 CDN들로부터 CDN 을 선택하게 하는
    명령들을 더 포함하고,
    상기 프로세서로 하여금 상기 GET 요청을 발행하게 하는 명령들은,
    상기 프로세서로 하여금, 상기 GET 요청을, 선택된 상기 CDN 에 발행하게 하는 명령들을 포함하며,
    상기 프로세서로 하여금 상기 템플릿에 따른 상기 URL 을 형성하게 하는 명령들은,
    상기 프로세서로 하여금, 상기 URL 을, 선택된 상기 CDN 에 특정된 바이트 범위 템플릿에 따라 형성하게 하는 명령들을 포함하는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.
30. 멀티미디어 데이터에 대한 정보를 전송하는 방법으로서,
    멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하는 단계로서, 상기 매니페스트 파일은 URL (uniform resource locator) 템플릿 및 바이트 범위 템플릿을 규정하고, 상기 URL 템플릿 및 상기 바이트 범위 템플릿은, URL 내에 바이트 범위 요청을 포함하도록 상기 URL 을 형성하기 위한 템플릿을 제공하는, 상기 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하는 단계;
    상기 URL 템플릿 및 상기 바이트 범위 템플릿에 따라 구성된 URL 을 포함하는 요청을 수신하는 단계로서, 상기 요청의 상기 URL 은 상기 멀티미디어 콘텐츠의 표현의 바이트 범위를 규정하는, 상기 요청을 수신하는 단계; 및
    상기 요청에 응답하여, 상기 요청의 상기 바이트 범위에 대응하는 상기 표현의 멀티미디어 데이터를 출력하는 단계를 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 방법.
31. 제 30 항에 있어서,
    상기 매니페스트 파일은, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하는 정보를 더 포함하고,
    상기 요청의 상기 URL 에 의해 규정된 상기 바이트 범위는 상기 복수의 바이트 범위들 중 하나의 바이트 범위를 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 방법.
32. 제 30 항에 있어서,
    상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하는 세그먼트 인덱스 데이터 구조를 제공하는 단계를 더 포함하고,
    상기 요청의 상기 URL 에 의해 규정된 상기 바이트 범위는 상기 복수의 바이트 범위들 중 하나의 바이트 범위를 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 방법.
33. 제 30 항에 있어서,
    상기 요청 내의 확장 헤더를 수신하는 단계를 더 포함하고,
    상기 확장 헤더는 GET 요청의 상기 URL 에 상기 바이트 범위의 로케이션을 나타내는, 멀티미디어 데이터에 대한 정보를 전송하는 방법.
34. 제 30 항에 있어서,
    상기 제공하는 단계는, 서버 디바이스에 의해 제공하는 단계를 포함하고,
    상기 수신하는 단계는, 상기 서버 디바이스에 의해 수신하는 단계를 포함하며,
    상기 출력하는 단계는, 상기 서버 디바이스에 의해 출력하는 단계를 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 방법.
35. 제 30 항에 있어서,
    상기 제공하는 단계는, 프록시 캐시 디바이스에 의해 제공하는 단계를 포함하고,
    상기 수신하는 단계는, 상기 프록시 캐시 디바이스에 의해 수신하는 단계를 포함하며,
    상기 출력하는 단계는, 상기 프록시 캐시 디바이스에 의해 출력하는 단계를 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 방법.
36. 제 30 항에 있어서,
    상기 요청은 상기 멀티미디어 콘텐츠의 상기 표현의 상기 바이트 범위에 대한 제 1 요청을 포함하고,
    상기 방법은,
    서버 디바이스로부터 상기 표현의 바이트 범위를 요청하는 단계;
    상기 서버 디바이스로부터 수신된 상기 바이트 범위에 대한 데이터를 캐싱하는 단계;
    상기 표현의 상기 바이트 범위에 대한 상이한 제 2 요청을 수신하는 단계; 및
    상기 제 2 요청에 응답하여, 상기 표현의 상기 바이트 범위에 대한 캐싱된 상기 데이터를 출력하는 단계를 더 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 방법.
37. 제 30 항에 있어서,
    상기 요청은 제 1 요청을 포함하고,
    상기 바이트 범위는 제 1 바이트 범위를 포함하며,
    상기 방법은,
    서버 디바이스로부터 상기 표현의 상기 제 1 바이트 범위를 요청하는 단계;
    상기 서버 디바이스로부터 수신된 상기 제 1 바이트 범위에 대한 데이터를 캐싱하는 단계;
    상기 URL 템플릿 및 상기 바이트 범위 템플릿에 따라 구성된 제 2 URL 을 포함하는 제 2 요청을 수신하는 단계로서, 상기 제 2 요청의 상기 제 2 URL 은 상기 멀티미디어 콘텐츠의 상기 표현의 제 2 바이트 범위를 규정하고, 상기 제 2 바이트 범위는 상기 제 1 바이트 범위를 뒤따르는, 상기 제 2 요청을 수신하는 단계;
    상기 서버 디바이스로부터 상기 표현의 상기 제 2 바이트 범위를 요청하는 단계; 및
    상기 제 1 바이트 범위에 대한 캐싱된 상기 데이터 및 상기 서버 디바이스로부터 수신된 상기 제 2 바이트 범위에 대한 데이터를 이용하여, 상기 표현의 로컬 카피 (local copy) 를 어셈블링하는 단계를 더 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 방법.
38. 제 30 항에 있어서,
    상기 매니페스트 파일은, 상기 바이트 범위 템플릿이 모든 콘텐츠 배포 네트워크들에게 전역적으로 적용된다는 것을 나타내는, 멀티미디어 데이터에 대한 정보를 전송하는 방법.
39. 제 30 항에 있어서,
    상기 바이트 범위 템플릿은 복수의 바이트 범위 템플릿들 중 하나의 바이트 범위 템플릿을 포함하고,
    상기 매니페스트 파일은, 상기 바이트 범위 템플릿들 각각이 복수의 콘텐츠 배포 네트워크들의 각각의 콘텐츠 배포 네트워크에게 적용된다는 것을 나타내는, 멀티미디어 데이터에 대한 정보를 전송하는 방법.
40. 멀티미디어 데이터에 대한 정보를 전송하는 디바이스로서,
    상기 디바이스는 하나 이상의 프로세서들을 포함하고,
    상기 하나 이상의 프로세서들은,
    멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하는 것으로서, 상기 매니페스트 파일은 URL (uniform resource locator) 템플릿 및 바이트 범위 템플릿을 규정하고, 상기 URL 템플릿 및 상기 바이트 범위 템플릿은, URL 내에 바이트 범위 요청을 포함하도록 상기 URL 을 형성하기 위한 템플릿을 제공하는, 상기 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하고,
    상기 URL 템플릿 및 상기 바이트 범위 템플릿에 따라 구성된 URL 을 포함하는 요청을 수신하는 것으로서, 상기 요청의 상기 URL 은 상기 멀티미디어 콘텐츠의 표현의 바이트 범위를 규정하는, 상기 요청을 수신하며,
    상기 요청에 응답하여, 상기 요청의 상기 바이트 범위에 대응하는 상기 표현의 멀티미디어 데이터를 출력하도록
    구성되는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
41. 제 40 항에 있어서,
    상기 매니페스트 파일은, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하는 정보를 더 포함하고,
    상기 요청의 상기 URL 에 의해 규정된 상기 바이트 범위는 상기 복수의 바이트 범위들 중 하나의 바이트 범위를 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
42. 제 40 항에 있어서,
    상기 하나 이상의 프로세서들은, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하는 세그먼트 인덱스 데이터 구조를 제공하도록 구성되고,
    상기 요청의 상기 URL 에 의해 규정된 상기 바이트 범위는 상기 복수의 바이트 범위들 중 하나의 바이트 범위를 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
43. 제 40 항에 있어서,
    상기 하나 이상의 프로세서들은 상기 요청 내의 확장 헤더를 수신하도록 구성되고,
    상기 확장 헤더는 GET 요청의 상기 URL 에 상기 바이트 범위의 로케이션을 나타내는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
44. 제 40 항에 있어서,
    상기 디바이스는, 서버 디바이스 및 프록시 캐시 디바이스 중 적어도 하나의 디바이스를 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
45. 제 40 항에 있어서,
    상기 요청은 상기 멀티미디어 콘텐츠의 상기 표현의 상기 바이트 범위에 대한 제 1 요청을 포함하고,
    상기 하나 이상의 프로세서들은 또한,
    서버 디바이스로부터 상기 표현의 바이트 범위를 요청하고, 상기 서버 디바이스로부터 수신된 상기 바이트 범위에 대한 데이터를 캐싱하고, 상기 표현의 상기 바이트 범위에 대한 상이한 제 2 요청을 수신하며, 상기 제 2 요청에 응답하여, 상기 표현의 상기 바이트 범위에 대한 캐싱된 상기 데이터를 출력하도록 구성되는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
46. 제 40 항에 있어서,
    상기 디바이스는,
    집적 회로;
    마이크로프로세서; 및
    상기 하나 이상의 프로세서들을 포함하는 무선 통신 디바이스
    중 적어도 하나를 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
47. 멀티미디어 데이터에 대한 정보를 전송하는 디바이스로서,
    멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하는 수단으로서, 상기 매니페스트 파일은 URL (uniform resource locator) 템플릿 및 바이트 범위 템플릿을 규정하고, 상기 URL 템플릿 및 상기 바이트 범위 템플릿은, URL 내에 바이트 범위 요청을 포함하도록 상기 URL 을 형성하기 위한 템플릿을 제공하는, 상기 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하는 수단;
    상기 URL 템플릿 및 상기 바이트 범위 템플릿에 따라 구성된 URL 을 포함하는 요청을 수신하는 수단으로서, 상기 요청의 상기 URL 은 상기 멀티미디어 콘텐츠의 표현의 바이트 범위를 규정하는, 상기 요청을 수신하는 수단; 및
    상기 요청에 응답하여, 상기 요청의 상기 바이트 범위에 대응하는 상기 표현의 멀티미디어 데이터를 출력하는 수단을 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
48. 제 47 항에 있어서,
    상기 매니페스트 파일은, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하는 정보를 더 포함하고,
    상기 요청의 상기 URL 에 의해 규정된 상기 바이트 범위는 상기 복수의 바이트 범위들 중 하나의 바이트 범위를 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
49. 제 47 항에 있어서,
    상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하는 세그먼트 인덱스 데이터 구조를 제공하는 수단을 더 포함하고,
    상기 요청의 상기 URL 에 의해 규정된 상기 바이트 범위는 상기 복수의 바이트 범위들 중 하나의 바이트 범위를 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
50. 제 47 항에 있어서,
    상기 요청 내의 확장 헤더를 수신하는 수단을 더 포함하고,
    상기 확장 헤더는 GET 요청의 상기 URL 에 상기 바이트 범위의 로케이션을 나타내는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
51. 제 47 항에 있어서,
    상기 요청은 상기 멀티미디어 콘텐츠의 상기 표현의 상기 바이트 범위에 대한 제 1 요청을 포함하고,
    서버 디바이스로부터 상기 표현의 바이트 범위를 요청하는 수단;
    상기 서버 디바이스로부터 수신된 상기 바이트 범위에 대한 데이터를 캐싱하는 수단;
    상기 표현의 상기 바이트 범위에 대한 상이한 제 2 요청을 수신하는 수단; 및
    상기 제 2 요청에 응답하여, 상기 표현의 상기 바이트 범위에 대한 캐싱된 상기 데이터를 출력하는 수단을 더 포함하는, 멀티미디어 데이터에 대한 정보를 전송하는 디바이스.
52. 명령들을 저장하고 있는 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품으로서,
    상기 명령들은, 실행될 때, 멀티미디어 데이터를 제공하는 디바이스의 하나 이상의 프로세서들로 하여금,
    멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하게 하는 것으로서, 상기 매니페스트 파일은 URL (uniform resource locator) 템플릿 및 바이트 범위 템플릿을 규정하고, 상기 URL 템플릿 및 상기 바이트 범위 템플릿은, URL 내에 바이트 범위 요청을 포함하도록 상기 URL 을 형성하기 위한 템플릿을 제공하는, 상기 멀티미디어 콘텐츠에 대한 매니페스트 파일을 제공하게 하고;
    상기 URL 템플릿 및 상기 바이트 범위 템플릿에 따라 구성된 URL 을 포함하는 요청을 수신하게 하는 것으로서, 상기 요청의 상기 URL 은 상기 멀티미디어 콘텐츠의 표현의 바이트 범위를 규정하는, 상기 요청을 수신하게 하며;
    상기 요청에 응답하여, 상기 요청의 상기 바이트 범위에 대응하는 상기 표현의 멀티미디어 데이터를 출력하게 하는, 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품.
53. 제 52 항에 있어서,
    상기 매니페스트 파일은, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하는 정보를 더 포함하고,
    상기 요청의 상기 URL 에 의해 규정된 상기 바이트 범위는 상기 복수의 바이트 범위들 중 하나의 바이트 범위를 포함하는, 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품.
54. 제 52 항에 있어서,
    상기 프로세서로 하여금, 상기 표현에 대해 요청될 수 있는 복수의 바이트 범위들을 규정하는 세그먼트 인덱스 데이터 구조를 제공하게 하는 명령들을 더 포함하고,
    상기 요청의 상기 URL 에 의해 규정된 상기 바이트 범위는 상기 복수의 바이트 범위들 중 하나의 바이트 범위를 포함하는, 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품.
55. 제 52 항에 있어서,
    상기 프로세서로 하여금, 상기 요청 내의 확장 헤더를 수신하게 하는 명령들을 더 포함하고,
    상기 확장 헤더는 GET 요청의 상기 URL 에 상기 바이트 범위의 로케이션을 나타내는, 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품.
56. 제 52 항에 있어서,
    상기 요청은 상기 멀티미디어 콘텐츠의 상기 표현의 상기 바이트 범위에 대한 제 1 요청을 포함하고,
    상기 프로세서로 하여금,
    서버 디바이스로부터 상기 표현의 바이트 범위를 요청하게 하고;
    상기 서버 디바이스로부터 수신된 상기 바이트 범위에 대한 데이터를 캐싱하게 하고;
    상기 표현의 상기 바이트 범위에 대한 상이한 제 2 요청을 수신하게 하며;
    상기 제 2 요청에 응답하여, 상기 표현의 상기 바이트 범위에 대한 캐싱된 상기 데이터를 출력하게 하는
    명령들을 더 포함하는, 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품.

Images