KR101453239B1

KR101453239B1 - 인코딩된 비디오 데이터의 스트리밍

Info

Publication number: KR101453239B1
Application number: KR1020137028642A
Authority: KR
Inventors: 잉 천; 마르타 카르체비츠
Original assignee: 퀄컴 인코포레이티드
Priority date: 2009-10-28
Filing date: 2010-10-27
Publication date: 2014-10-23
Also published as: US20110196982A1; KR20120085870A; CN105187850B; TW201138471A; KR20130129481A; JP2014212538A; ES2746051T3; US20110099594A1; CN102598688A; CN105187850A; JP6054337B2; BR112012009832A2; JP5619908B2; KR101396628B1; JP2013509818A; HUE045239T2; EP3038367B1; EP2494779A1; WO2011053658A1; CN102598688B

Abstract

소스 디바이스는, 목적지 디바이스가 MPD 파일에 대응하는 다수의 프리젠테이션들 중의 하나를 선택하고 그 선택된 프리젠테이션의 하나 이상의 비디오 파일들을 취출할 수도 있도록, 미디어 프리젠테이션 설명 (MPD) 파일의 특성들을 시그널링한다. 일 예에서, 인코딩된 비디오 데이터를 전송하기 위한 장치는, 소정 수의 비디오 세그먼트들을 포함하는 인코딩된 비디오 데이터를 수신하고, 소정 수의 비디오 파일들을 포함하는 프리젠테이션을 형성하도록 구성된 관리 유닛으로서, 비디오 파일들의 각각은 비디오 세그먼트들의 각각의 비디오 세그먼트에 대응하는, 상기 관리 유닛, 및 비디오 데이터의 시간 섹션을 특정하는 요청에 응답하여, 요청된 시간 섹션의 소정 수의 비디오 세그먼트들에 대응하는 비디오 파일들 중의 적어도 하나를 출력하도록 구성된 네트워크 인터페이스를 포함한다. 클라이언트는 프리젠테이션들 중 상이한 것들로부터 시간적으로 순차적인 프래그먼트들을 요청할 수도 있다.

Description

인코딩된 비디오 데이터의 스트리밍{STREAMING ENCODED VIDEO DATA}

본 출원은 2009년 10월 28일 출원된 미국 가출원 제 61/255,767 호에 기초하여 우선권을 주장하며, 그 전체 내용은 참조에 의해 본원에 명백히 통합된다.

본 개시는 인코딩된 비디오 데이터의 전송에 관한 것이다.

디지털 비디오 성능은, 디지털 텔레비젼들, 디지털 다이렉트 브로드캐스트 시스템들, 무선 브로드캐스트 시스템들, PDA 들, 랩톱 또는 데스크톱 컴퓨터들, 디지털 카메라들, 디지털 레코딩 디바이스들, 디지털 미디어 플레이어들, 비디오 게임 디바이스들, 비디오 게임 콘솔들, 셀룰러 또는 위성 라디오 전화기들, 비디오 원격 회의 디바이스들, 및 기타 등을 포함하는 넓은 범위의 디바이스들 내로 통합될 수 있다. 디지털 비디오 디바이스들은 디지털 정보를 더욱 효율적으로 송신 및 수신하기 위해, MPEG-2, MPEG-4, ITU-T H.263 또는 ITU-T H.264/MPEG-4, Part 10, AVC (Advanced Video Coding) 에 의해 정의된 표준들 및 이러한 표준들의 확장들에서 설명된 것들과 같은 비디오 압축 기술들을 구현한다.

비디오 압축 기술들은 비디오 시퀀스들에 내재하는 리던던시 (redundancy) 를 감소 또는 제거하기 위해 공간 예측 및/또는 시간 예측을 수행한다. 블록 기반 비디오 코딩에 있어서, 비디오 프레임 또는 슬라이스 (slice) 는 매크로블록들로 분할될 수도 있다. 각각의 매크로블록은 추가적으로 분할될 수 있다. 인트라-코딩된 (I) 프레임 또는 슬라이스 내의 매크로블록들은 이웃하는 (neighboring) 매크로블록들에 대해 공간 예측을 이용하여 인코딩된다. 인터-코딩된 (P 또는 B) 프레임 또는 슬라이스 내의 매크로블록들은 동일 프레임 또는 슬라이스 내의 이웃하는 매크로블록들에 대해 공간 예측을 사용하거나 다른 참조 프레임들에 대해 시간 예측을 사용할 수도 있다.

비디오 데이터가 인코딩된 후에, 그 비디오 데이터는 송신 또는 저장을 위해 멀티플렉서 (multiplexer) 에 의해 패킷화 (packetize) 될 수도 있다. MPEG-2 표준은, 예를 들어, 많은 비디오 인코딩 표준들에 대해 전송 레벨을 정의하는 "시스템" 섹션을 포함한다. MPEG-2 전송 레벨 시스템들은 MPEG-2 비디오 인코더들, 또는 상이한 비디오 인코딩 표준들에 호환되는 다른 비디오 인코더들에 의해 사용될 수도 있다. 예를 들어, MPEG-4 표준은 MPEG-2 와는 상이한 인코딩 및 디코딩 방법들을 규정하지만, MPEG-4 표준의 기술들을 구현하는 비디오 인코더들은 여전히 MPEG-2 전송 레벨 방법들을 이용할 수도 있다. 제 3 세대 파트너쉽 프로젝트 (3GPP) 또한 인코딩된 비디오 데이터에 대해 특정 멀티미디어 컨테이터 (container) 포맷을 이용하여 인코딩된 비디오 데이터를 전송하기 위한 기술들을 제공한다.

일반적으로, 본 개시는 예를 들어 하이퍼텍스트 전송 프로토콜 (HTTP) 과 같은 네트워크 프로토콜을 통한, 인코딩된 비디오 데이터의 스트리밍 전송을 지원하는 기술들을 설명한다. 소스 디바이스는 인코딩된 미디어 데이터의 다중 프리젠테이션 (presentation) 들을 리스트 (list) 하는 미디어 프리젠테이션 디스크립션 (media presentation description; MPD) 파일을 형성할 수도 있다. 각각의 프리젠테이션은 공통의 비디오를 위한 상이한 인코딩에 대응한다. 예를 들어, 각각의 프리젠테이션은, 인코딩 및/또는 렌더링 (rendering) 성능들뿐만 아니라 다양한 평균 비트 레이트들의 면에서 목적지 (destination) 디바이스의 상이한 기대를 가질 수도 있다.

소스 디바이스는 각각의 프리젠테이션의 특성들을 시그널링 (signaling) 하여 목적지 디바이스로 하여금, 그 목적지 디바이스의 디코딩 및 렌더링 성능들에 기초하여 그 프리젠테이션들 중 하나를 선택하고, 네트워크 환경 변화 및 프리젠테이션들의 대역폭들에 기초하여 상이한 프리젠테이션들 사이에서 스위칭하도록 허용한다. 프리젠테이션들은 프리(pre)-인코딩되거나 실시간 인코딩될 수도 있고, 예를 들어 ISO 기반 미디어 파일 포맷 및 그것의 확장들에 호환되는 파일(들) 또는 파일 프래그먼트 (fragment) 들로서 서버에 저장될 수도 있다. 목적지 디바이스는 예를 들어 HTTP 를통해 다양한 시간들에서 프리젠테이션들 중 하나 이상으로부터 데이터를 검색할 수도 있다. 소스 디바이스는, 목적지 디바이스들이 예를 들어 HTTP 요청들에 기초하여 다양한 프리젠테이션들로부터 개별적인 비디오 프래그먼트들을 취출 (retrieve) 할 수도 있도록, 각각의 프리젠테이션 내의 비디오 프래그먼트들의 바이트 범위들 및 대응하는 시간적 위치들과 같이, 각각의 프리젠테이션의 프래그먼트들을 추가적으로 시그널링할 수도 있다.

일 예에서, 인코딩된 비디오 데이터를 전송하는 방법은, 소스 디바이스에 의해 소정 수의 비디오 세그먼트들을 포함하는 인코딩된 비디오 데이터를 수신하는 단계, 소정 수의 비디오 파일들을 포함하는 프리젠테이션을 형성하는 단계로서, 비디오 파일들의 각각은 비디오 세그먼트들의 각각의 비디오 세그먼트에 대응하는, 상기 프리젠테이션을 형성하는 단계, 및 비디오 데이터의 시간 섹션을 특정하는 요청에 응답하여, 요청된 시간 섹션의 소정 수의 비디오 세그먼트들에 대응하는 비디오 파일들 중의 적어도 하나를 출력하는 단계를 포함한다.

다른 예에서, 인코딩된 비디오 데이터를 전송하기 위한 장치는, 소정 수의 비디오 세그먼트들을 포함하는 인코딩된 비디오 데이터를 수신하고, 소정 수의 비디오 파일들을 포함하는 프리젠테이션을 형성하도록 구성된 관리 유닛으로서, 비디오 파일들의 각각은 비디오 세그먼트들의 각각의 비디오 세그먼트에 대응하는, 상기 관리 유닛, 및 비디오 데이터의 시간 섹션을 특정하는 요청에 응답하여, 요청된 시간 섹션의 소정 수의 비디오 세그먼트들에 대응하는 비디오 파일들 중의 적어도 하나를 출력하도록 구성된 네트워크 인터페이스를 포함한다.

다른 예에서, 인코딩된 비디오 데이터를 전송하기 위한 장치는, 소정 수의 비디오 세그먼트들을 포함하는 인코딩된 비디오 데이터를 수신하는 수단, 소정 수의 비디오 파일들을 포함하는 프리젠테이션을 형성하는 수단으로서, 비디오 파일들의 각각은 비디오 세그먼트들의 각각의 비디오 세그먼트에 대응하는, 상기 프리젠테이션을 형성하는 수단, 및 비디오 데이터의 시간 섹션을 특정하는 요청에 응답하여, 요청된 시간 섹션의 소정 수의 비디오 세그먼트들에 대응하는 비디오 파일들 중의 적어도 하나를 출력하는 수단을 포함한다.

다른 예에서, 비일시적 (non-transitory) 컴퓨터-판독가능 저장 매체는, 실행될 때, 인코딩된 비디오 데이터를 전송하기 위한 소스 디바이스의 프로세서로 하여금, 소정 수의 비디오 세그먼트들을 포함하는 인코딩된 비디오 데이터를 수신하고, 소정 수의 비디오 파일들을 포함하는 프리젠테이션 (presentation) 을 형성하되, 비디오 파일들의 각각은 비디오 세그먼트들의 각각의 비디오 세그먼트에 대응하고, 비디오 데이터의 시간 섹션을 특정하는 요청에 응답하여, 요청된 시간 섹션의 소정 수의 비디오 세그먼트들에 대응하는 비디오 파일들 중의 적어도 하나를 출력하도록 하는 명령들을 포함한다.

또 다른 예에서, 인코딩된 비디오 데이터를 취출 (retrieve) 하는 방법은, 클라이언트 디바이스에 의해, 비디오 데이터의 프리젠테이션 (presentation) 의 특성들을 설명하는 프리젠테이션 설명 데이터를 취출하는 단계로서, 비디오 데이터는 소정 수의 비디오 세그먼트들을 포함하고, 프리젠테이션은 소정 수의 비디오 파일들을 포함하며, 비디오 파일들의 각각은 비디오 세그먼트들의 각각의 비디오 세그먼트에 대응하는, 상기 프리젠테이션 설명 데이터를 취출하는 단계, 비디오 데이터의 시간 섹션을 특정하는 요청을 소스 디바이스로 제출하는 단계, 요청에 응답하여, 소스 디바이스로부터 요청된 시간 섹션의 소정 수의 비디오 세그먼트들에 대응하는 비디오 파일들 중의 적어도 하나를 수신하는 단계, 및 비디오 파일들 중의 적어도 하나를 디코딩 및 디스플레이하는 단계를 포함한다.

다른 예에서, 인코딩된 비디오 데이터를 취출하기 위한 장치는, 네트워크 인터페이스, 그 네트워크 인터페이스를 통해, 비디오 데이터의 프리젠테이션의 특성들을 설명하는 프리젠테이션 설명 데이터를 취출하는 것으로서, 비디오 데이터는 소정 수의 비디오 세그먼트들을 포함하고, 프리젠테이션은 소정 수의 비디오 파일들을 포함하며, 비디오 파일들의 각각은 비디오 세그먼트들의 각각의 비디오 세그먼트에 대응하는, 상기 프리젠테이션 설명 데이터를 취출하는 것을 수행하고, 비디오 데이터의 시간 섹션을 특정하는 요청을 소스 디바이스로 제출하며, 요청에 응답하여, 소스 디바이스로부터 요청된 시간 섹션의 소정 수의 비디오 세그먼트들에 대응하는 비디오 파일들 중의 적어도 하나를 수신하도록 구성된 제어 유닛, 비디오 파일들 중의 적어도 하나를 디코딩하도록 구성된 비디오 디코더, 및 비디오 파일들 중의 디코딩된 적어도 하나를 디스플레이하도록 구성된 디스플레이를 포함하는 사용자 인터페이스를 포함한다.

다른 예에서, 인코딩된 비디오 데이터를 취출하기 위한 장치는, 비디오 데이터의 프리젠테이션의 특성들을 설명하는 프리젠테이션 설명 데이터를 취출하는 수단으로서, 비디오 데이터는 소정 수의 비디오 세그먼트들을 포함하고, 프리젠테이션은 소정 수의 비디오 파일들을 포함하며, 비디오 파일들의 각각은 비디오 세그먼트들의 각각의 비디오 세그먼트에 대응하는, 상기 프리젠테이션 설명 데이터를 취출하는 수단, 비디오 데이터의 시간 섹션을 특정하는 요청을 소스 디바이스로 제출하는 수단, 요청에 응답하여, 소스 디바이스로부터 요청된 시간 섹션의 소정 수의 비디오 세그먼트들에 대응하는 비디오 파일들 중의 적어도 하나를 수신하는 수단, 및 비디오 파일들 중의 적어도 하나를 디코딩 및 디스플레이하는 수단을 포함한다.

다른 예에서, 비일시적 (non-transitory) 컴퓨터-판독가능 저장 매체는, 실행될 때, 인코딩된 비디오 데이터를 취출 (retrieve) 하기 위한 클라이언트 디바이스의 프로세서로 하여금, 비디오 데이터의 프리젠테이션의 특성들을 설명하는 프리젠테이션 설명 데이터를 취출하는 것으로서, 비디오 데이터는 소정 수의 비디오 세그먼트들을 포함하고, 프리젠테이션은 소정 수의 비디오 파일들을 포함하며, 비디오 파일들의 각각은 비디오 세그먼트들의 각각의 비디오 세그먼트에 대응하는, 프리젠테이션 설명 데이터를 취출하는 것을 수행하고, 비디오 데이터의 시간 섹션을 특정하는 요청을 소스 디바이스로 제출하며, 요청에 응답하여, 소스 디바이스로부터 요청된 시간 섹션의 소정 수의 비디오 세그먼트들에 대응하는 비디오 파일들 중의 적어도 하나를 수신하고, 클라이언트 디바이스의 비디오 디코더가 비디오 파일들 중의 적어도 하나를 디코딩하게 하고, 클라이언트 디바이스의 디스플레이가 디코딩된 비디오 파일들 중의 적어도 하나를 디스플레이하게 하도록 하는 명령들을 포함한다.

하나 이상의 예들의 상세한 내용들이 첨부 도면 및 이하의 설명에서 전개된다. 다른 특징들, 목적들, 및 이점들은 상세한 설명 및 도면들, 및 청구범위로부터 명백하게 될 것이다.

도 1 은 오디오/비디오 (A/V) 소스 디바이스가 오디오 및 비디오 데이터를 A/V 목적지 디바이스로 전송하는 예시적인 시스템을 나타내는 블록도이다.
도 2 는 멀티플렉서의 컴포넌트들의 예시적인 배열을 나타내는 블록도이다.
도 3 은 프로그램 특정 정보 테이블들의 예시적인 셋트를 나타내는 블록도이다.
도 4 는 다양한 프리젠테이션들의 제 3 세대 파트너쉽 프로젝트 (3GPP) 파일들과 대응하는 비디오 세그먼트들 사이의 정렬을 나타내는 개념도이다.
도 5 는 소스 디바이스로부터 목적지 디바이스로 인코딩된 비디오 데이터를 전송하는 예시적인 방법을 나타내는 플로우차트이다.
도 6 은 예시적인 3GPP 파일의 엘리먼트들을 나타내는 블록도이다.
도 7 은 3GPP 파일 내의 시간적 위치에 대한 탐색 요청에 응답하여 3GPP 파일의 프래그먼트를 요청하는 예시적인 방법을 나타내는 플로우차트이다.

본 개시의 기술은 일반적으로 예를 들어 하이퍼텍스트 전송 프로토콜 (HTTP) 과 같은 프로토콜 및 HTTP 의 HTTP 스트리밍 애플리케이션을 이용하여 비디오 데이터의 스트리밍 전송을 지원하는 것을 지향한다. 일반적으로, HTTP 에 대한 참조들은 본 개시 내의 HTTP 스트리밍에 대한 참조들을 포함할 수도 있다. 본 개시는, 예를 들어 비디오 데이터의 프래그먼트들이 프리젠테이션들 내에 저장되는 것과 같이 비디오 데이터의 다수의 프리젠테이션들의 특성 엘리먼트들을 시그널링하는 비디오 프리젠테이션 디스크립션 (MPD) 파일을 제공한다. 각각의 프리젠테이션은 예를 들어 제 3 세대 파트너쉽 프로젝트 (3GPP) 파일들과 같이 다수의 개별 파일들을 포함할 수도 있다. 일반적으로, 각각의 프리젠테이션은 예를 들어 비트 레이트, 프레임 레이트, 해상도, 비월 주사 타입 또는 순차 주사 타입, 인코딩 타입 (예를 들어, MPEG-1, MPEG-2, H.263, MPEG-4/H.264, H.265 등), 또는 다른 특성들과 같은 개별적 특성들의 셋트를 포함할 수도 있다.

3GPP 파일들의 각각은 예를 들어 HTTP GET 및 부분적 GET 요청들을 이용하여 서버에 의해 개별적으로 저장될 수 있고 클라이언트에 의해 개별적으로 취출될 수 있다. HTTP GET 및 부분적 GET 요청들은 R. Fielding 외 저 "Hypertext Transfer Protocol - HTTP/1.1" (네트워크 워킹 그룹, RFC2616, 1999년 6월, http://tools.ietf.org/html/rfc2616 에서 이용가능) 에 설명되어 있다. 본 개시의 기술들에 따르면, 각각의 프리젠테이션의 3GPP 파일들은, 그들이 동일한 비디오의 섹션, 즉, 하나 이상의 장면 (scene) 들의 동일한 셋트에 대응하도록 정렬될 수도 있다. 또한, 서버는 유사한 명명 (naming) 방식을 이용하여 각각의 프리젠테이션의 대응하는 3GPP 파일들을 명명할 수도 있다. 이러한 방식으로, HTTP 클라이언트는 네트워크 상태들이 변화함에 따라 프리젠테이션들을 쉽게 변화시킬 수도 있다. 예를 들어, 높은 양의 대역폭이 이용가능할 때, 클라이언트는 상대적으로 더 높은 품질의 프리젠테이션의 3GPP 파일들을 취출할 수도 있는 반면, 더 낮은 양의 대역폭이 이용가능할 때, 클라이언트는 상대적으로 더 낮은 품질의 프리젠테이션의 3GPP 파일들을 취출할 수도 있다.

본 개시는 또한 MPD 파일 내에 요약된 프리젠테이션들 및 대응하는 3GPP 파일들의 특성들을 시그널링하기 위한 기술들을 제공한다. 예로서, 본 개시는, 예를 들어 각각의 프리젠테이션에 대한 클라이언트 디바이스의 예상되는 렌더링 성능 및 디코딩 성능과 같은 특성들을 서버가 시그널링할 수도 있는 기술들을 제공한다. 이러한 방식으로 클라이언트 디바이스는 클라이언트 디바이스의 디코딩 및 렌더링 성능들에 기초하여 다양한 프리젠테이션들 사이에서 선택할 수 있다. 또다른 예로서, 본 개시는 각각의 프리젠테이션에 대해 평균 비트 레이트 및 최대 비트 레이트를 시그널링하기 위한 기술들을 제공한다. 이러한 방식으로, 클라이언트 디바이스는 대역폭 이용가능성을 결정하고 그 결정된 대역폭에 기초하여 다양한 프리젠테이션들 사이에서 선택할 수 있다.

본 개시의 기술들에 따르면, 서버는, 동일 장면에 대응하는 각각의 프리젠테이션의 3GPP 파일들을 나타내는 명명 방식 (naming convention) 을 이용할 수도 있다. 본 개시는, 각각의 장면이 각각의 프리젠테이션 내의 3GPP 파일들 중 하나에 대응하도록, 각각의 프리젠테이션의 3GPP 파일들을 정렬하기 위한 기술들을 제공한다. 예를 들어, 서버는 "[program]_preX_T_T+N" 과 유사한 명명 방식을 이용하여 시간 T 에서 시간 T+N 까지, 장면에 대응하는 각각의 프리젠테이션의 3GPP 파일들을 명명할 수도 있고, 여기서, 명명 방식에서의 T 및 T+N 은 시간 T 및 시간 T+N 에 대한 값들에 대응하고, "[program]" 은 비디오의 명칭에 대응하며, "_preX" 는 프리젠테이션의 식별자에 대응한다 (예를 들어, 프리젠테이션 2 에 대해 "pre2"). 따라서, 각각의 프리젠테이션의 3GPP 파일들은, 동일 시간 주기의 3GPP 파일들의 파일 사이즈들이 각각의 프리젠테이션에 대한 순시 (instantaneous) 비트 레이트를 도출하는데 이용될 수 있도록 정렬될 수도 있다.

또한, 서버는 각각의 프리젠테이션에 대한 3GPP 파일들의 각각의 시작 시간 및 종료 시간 및/또는 지속기간을 시그널링할 수도 있다. 이러한 방식으로, 클라이언트는 서버에 의해 시그널링된바대로 3GPP 파일의 시작 시간 및 종료 시간을 취출하고 그 시작 시간 및 종료 시간에 기초하여 파일 명칭을 자동적으로 생성함으로써 파일의 명칭에 기초한 HTTP GET 를 이용하여 특정 3GPP 파일을 취출할 수 있다. 추가적으로, 서버는 또한 각각의 프리젠테이션의 3GPP 파일들의 각각에 대해 바이트 범위들을 시그널링할 수도 있다. 따라서, 클라이언트는 자동적으로 생성된 명칭 및 취출될 3GPP 파일의 바이트 범위에 기초하여 부분적 GET 를 이용하여 3GPP 파일의 전부 또는 일부를 취출할 수도 있다. 클라이언트는 특정 3GPP 파일의 파일 사이즈를 취출하기 위해 HTTP 의 HEAD 방법을 이용할 수도 있다. 일반저긍로, HEAD 요청은, 그 HEAD 요청이 다이렉팅 (directing) 되는 URN 또는 URL 에 대해 대응하는 보디 (body) 데이터 없이 헤더 데이터를 취출한다.

도 1 은 오디오/비디오 (A/V) 소스 디바이스 (20) 가 오디오 및 비디오 데이터를 A/V 목적지 디바이스 (40) 로 전송하는 예시적인 시스템 (10) 을 나타내는 블록도이다. 도 1 의 시스템 (10) 은 비디오 원격회의 시스템, 서버/클라이언트 시스템, 브로드캐스터/수신기 시스템, 게이밍 시스템, 또는 A/V 소스 디바이스 (20) 와 같은 소스 디바이스로부터 A/V 목적지 디바이스 (40) 와 같은 목적지 디바이스로 비디오 데이터가 전송되는 임의의 다른 시스템에 대응할 수도 있다. 몇몇 예들에서, 오디오 인코더 (26) 는 보코더라고도 불리는 보이스 인코더를 포함할 수도 있다.

도 1 의 예에서, A/V 소스 디바이스 (20) 는 오디오 소스 (22), 비디오 소스 (24), 오디오 인코더 (26), 비디오 인코더 (28), 미디어 프리젠테이션 디스크립션 (MPD) 관리 유닛 (230), 및 네트워크 인터페이스 (32) 를 포함한다. 오디오 소스 (22) 는 예를 들어 오디오 인코더 (26) 에 의해 인코딩될 캡쳐 (capture) 된 오디오 데이터를 나타내는 전기적 신호들을 생성하는 마이크로폰을 포함할 수도 있다. 다르게는, 오디오 소스 (22) 는 미리 레코딩된 오디오 데이터를 저장하는 저장 매체, 컴퓨터화된 신시사이저 (synthesizer) 와 같은 오디오 데이터 생성기, 또는 오디오 데이터의 임의의 다른 소스를 포함할 수도 있다. 비디오 소스 (24) 는 비디오 인코더 (28) 에 의해 인코딩될 비디오 데이터를 생성하는 비디오 카메라, 미리 레코딩된 비디오 데이터로 인코딩된 저장 매체, 컴퓨터 그래픽을 위한 비디오 데이터 생성 유닛, 또는 비디오 데이터의 임의의 다른 소스를 포함할 수도 있다. 미가공 (raw) 오디오 및 비디오 데이터는 아날로그 또는 디지털 데이터를 포함할 수도 있다. 아날로그 데이터는 오디오 인코더 (26) 및/또는 비디오 인코더 (28) 에 의해 인코딩되기 전에 디지털화될 수도 있다.

오디오 소스 (22) 는 화자가 말하고 있는 동안 화자로부터 오디오 데이터를 획득할 수도 있고, 비디오 소스 (24) 는 그 화자의 비디오 데이터를 동시에 획득할 수도 있다. 다른 예들에서, 오디오 소스 (22) 는 저장된 오디오 데이터를 포함하는 컴퓨터-판독가능 저장 매체를 포함할 수도 있고, 비디오 소스 (24) 는 저장된 비디오 데이터를 포함하는 컴퓨터-판독가능 저장 매체를 포함할 수도 있다. 이러한 방식으로, 본 개시에서 설명된 기술들은 라이브 (live), 스트리밍, 실시간 오디오 및 비디오 데이터에 적용될 수도 있고/있거나, 기록 보관된, 미리 레코딩된 오디오 및 비디오 데이터에 적용될 수도 있다.

비디오 프레임들에 대응하는 오디오 프레임들은 일반적으로, 비디오 프레임들 내에 포함되는 비디오 소스 (24) 에 의해 캡쳐된 비디오 데이터와 동시에 오디오 소스 (22) 에 의해 캡쳐된 오디오 데이터를 포함하는 오디오 프레임들이다. 예를 들어, 화자가 일반적으로 이야기하는 것에 의해 오디오 데이터를 생성하는 동안, 오디오 소스 (22) 는 그 오디오 데이터를 캡쳐하고, 비디오 소스 (24) 는 그와 동시에, 즉, 오디오 소스 (22) 가 오디오 데이터를 캡쳐하고 있는 동안 그 화자의 비디오 데이터를 캡쳐한다. 따라서, 오디오 프레임은 하나 이상의 특정 비디오 프레임들에 시간적으로 대응할 수도 있다. 따라서, 비디오 프레임에 대응하는 오디오 프레임은 일반적으로, 오디오 데이터 및 비디오 데이터가 동시에 캡쳐되었던 상황에 대응하고, 그 상황에 대해 오디오 프레임 및 비디오 프레임은 각각, 동시에 캡쳐되었던 오디오 데이터 및 비디오 데이터를 포함한다. 오디오 데이터에는 또한, 예를 들어 사운드트랙 정보, 부가된 사운드들, 음악, 음향 효과들, 및 기타 등이 부가될 수도 있다.

오디오 인코더 (26) 는, 각각의 인코딩된 오디오 프레임 내에 그 인코딩된 오디오 프레임에 대한 오디오 데이터가 기록되었던 시간을 나타내는 타임스탬프 (timestamp) 를 인코딩할 수도 있고, 유사하게, 비디오 인코더 (28) 는 각각의 인코딩된 비디오 프레임 내에 인코딩된 비디오 프레임에 대한 비디오 데이터가 기록되었던 시간을 나타내는 타임스탬프를 인코딩할 수도 있다. 이러한 예들에서, 비디오 프레임에 대응하는 오디오 프레임은 타임스탬프를 포함하는 오디오 프레임 및 동일한 타임스탬프를 포함하는 비디오 프레임을 포함할 수도 있다. A/V 소스 디바이스 (20) 는 내부 클럭 (clock) 을 포함할 수도 있고, 이 내부 클럭으로부터 오디오 인코더 (26) 및/또는 비디오 인코더 (28) 가 타임스탬프들을 생성할 수도 있고, 오디오 소스 (22) 및 비디오 소스 (24) 가 타임스탬프를 이용하여 오디오 데이터와 비디오 데이터를 연관시키기 위해 이 내부 클럭을 이용할 수도 있다.

오디오 소스 (22) 는 오디오 데이터가 레코딩되었던 시간에 대응하여 데이터를 오디오 인코더 (26) 로 전송할 수도 있고, 비디오 소스 (24) 는 비디오 데이터가 레코딩되었던 시간에 대응하여 데이터를 비디오 인코더 (28) 로 전송할 수도 있다. 몇몇 예들에서, 오디오 인코더 (26) 는, 오디오 데이터가 레코딩되었던 절대적 시간을 나타낼 필요는 없지만 인코딩된 오디오 데이터의 상대적인 시간적 순서를 나타내기 위해, 인코딩된 오디오 데이터 내에 시퀀스 식별자를 인코딩할 수도 있고, 유사하게, 비디오 인코더 (28) 또한, 인코딩된 비디오 데이터의 상대적인 시간적 순서를 나타내기 위해 시퀀스 식별자들을 이용할 수도 있다. 유사하게, 몇몇 예들에서, 시퀀스 식별자는 맵핑 (mapping) 될 수도 있고, 그 외에 타임스탬프와 상관될 수도 있다.

오디오 인코더 (26) 및 비디오 인코더 (28) 는 인코딩된 데이터를 MPD 관리 유닛 (30) 에 제공한다. 일반적으로, MPD 관리 유닛 (30) 은 인코딩된 오디오 및 비디오 데이터에 관한 요약을, 본 개시의 기술들에 따라 그 인코딩된 오디오 및 비디오 데이터에 대응하는 MPD 파일들의 형태로 저장한다. 이하에서 더 자세하게 논의할 것이지만, MPD 파일은 다수의 프리젠테이션들을 설명하고, 각각의 프리젠테이션은 예를 들어 제 3 세대 파트너쉽 프로젝트 (3GPP) 파일들로서 형성된 다수의 비디오 파일들을 갖는다. MPD 관리 유닛 (30) 은 각각의 프리젠테이션 내에 동일한 수의 3GPP 파일들을 형성할 수도 있고, 유사하게 위치결정된 3GPP 파일들이 동일한 비디오 세그먼트에 대응하도록 각각의 프리젠테이션의 3GPP 파일들을 정렬할 수도 있다. 즉, 유사하게 위치결정된 3GPP 파일들은 동일한 시간적 비디오 프래그먼트에 대응할 수도 있다. MPD 관리 유닛 (30) 은 또한, 예를 들어 3GPP 파일들의 지속기간들과 같은, 각각의 프리젠테이션의 3GPP 파일들의 특성들을 설명하는 데이터를 저장할 수도 있다.

MPD 관리 유닛 (30) 은 A/V 목적지 디바이스 (40) 와 같은 클라이언트에 비디오 데이터를 제공하기 위해 네트워크 인터페이스 (32) 와 상호작용할 수도 있다. 네트워크 인터페이스 (32) 는, 목적지 디바이스 (40) 가, MPD 관리 유닛 (30) 에 의해 저장된 MPD 파일 내에 리스트된 개별적인 3GPP 파일들을 요청하는 것을 허용하기 위해 HTTP (또는 다른 네트워크 프로토콜들) 를 구현할 수도 있다. 네트워크 인터페이스 (32) 는 따라서 3GPP 파일들에 대한 HTTP GET 요청들, 3GPP 파일들의 개별적인 바이트 범위들에 대한 부분적인 GET 요청들, MPD 및/또는 3GPP 파일들에 대한 헤더 정보를 제공하기 위한 HEAD 요청들, 및 다른 이러한 요청들에 응답할 수도 있다. 따라서, 네트워크 인터페이스 (32) 는, 예를 들어 MPD 파일에 대한 기본 명칭과 같은 MPD 파일의 특성들, MPD 파일의 프리젠테이션들의 특성들, 및/또는 각각의 프리젠테이션 내에 저장된 3GPP 파일들의 특성들을 나타내는 데이터를 목적지 디바이스 (40) 로 전달할 수도 있다. MPD 파일의 프리젠테이션, MPD 파일 그 자체, 및/또는 MPD 파일에 대응하는 3GPP 파일들의 특성들을 설명하는 데이터는 "프리젠테이션 설명 데이터" 로서 지칭될 수도 있다. 몇몇 예들에서, 네트워크 인터페이스 (32) 는 대신에 수신된 패킷들로부터 애플리케이션-레이어 데이터를 추출한 다음 그 애플리케이션-레이어 패킷들을 MPD 관리 유닛 (30) 으로 패스 (pass) 하는 네트워크 인터페이스 카드 (NIC) 를 포함할 수도 있다. 몇몇 예들에서, MPD 관리 유닛 (30) 및 네트워크 인터페이스 (32) 는 기능적으로 통합될 수도 있다.

이러한 방식으로, 사용자는 비디오 데이터를 취출하기 위해, 도 1 의 예에서, 목적지 디바이스 (40) 상에서 실행되는 웹 브라우저 (38) 애플리케이션을 통해 목적지 디바이스 (40) 와 상호작용할 수도 있다. 웹 브라우저 (38) 는 초기에 MPD 관리 유닛 (30) 에 의해 저장된 프리젠테이션들 중 하나로부터 제 1 비디오 파일 또는 그것의 프래그먼트들을 취출할 수도 있고, 그 다음, 그 제 1 비디오 파일이 비디오 디코더 (48) 및 비디오 출력 (44) 에 의해 각각 디코딩되고 디스플레이됨에 따라 후속 비디오 파일들 또는 프래그먼트들을 취출할 수도 있다. 목적지 디바이스 (40) 는, 예를 들어 디스플레이 형태의 비디오 출력 (44), 및 오디오 출력 (42), 및 예를 들어 키보드, 마우스, 조이스틱, 마이크로폰, 터치스크린 디스플레이, 스타일러스, 광 펜과 같은 다른 입력 및/또는 출력 디바이스들, 또는 다른 입력 및/또는 출력 디바이스들을 포함하는 유저 인터페이스를 포함할 수도 있다. 비디오 파일들이 오디오 데이터를 포함할 때, 오디오 디코더 (46) 및 오디오 출력 (42) 은 그 오디오 데이터를 각각 디코딩 및 현시 (present) 할 수도 있다. 또한, 사용자는 비디오 프리젠테이션의 특정 시간적 로케이션 (location) 을 "탐색" 할 수도 있다. 예를 들어, 사용자가 시작부터 끝까지 비디오 파일의 전체를 보기보다는, 비디오 데이터 내의 특정 시간적 로케이션을 요청한다는 의미로 사용자는 탐색할 수도 있다. 웹 브라우저는 목적지 디바이스 (40) 의 프로세서 또는 다른 프로세싱 유닛으로 하여금, 탐색의 시간적 로케이션을 포함하는 비디오 파일들 중의 하나를 결정하고 그 비디오 파일을 소스 디바이스 (20) 로부터 요청하게 할 수도 있다.

몇몇 예들에서, 목적지 디바이스 (40) 내의 제어 유닛은 웹 브라우저 (38)의 기능을 수행할 수도 있다. 즉, 제어 유닛은, 웹 브라우저 (38) 가 네트워크 인터페이스 (36) 를 통해 소스 디바이스 (20) 로 요청들을 제출하고, MPD 파일의프리젠테이션들 사이에서 선택하며, 네트워크 연결 (34) 의 이용가능한 대역폭을 결정하도록 하기 위한 명령들을 실행할 수도 있다. 웹 브라우저 (38) 를 위한 명령들은 컴퓨터-판독가능 저장 매체에 저장될 수도 있다. 제어 유닛은, 본 개시에서 설명되는 바와 같이 소스 디바이스 (20) 로부터의 개별적인 3GPP 파일들에 대해 요청들, 예를 들어, HTTP GET 및 부분적 GET 요청들을 추가적으로 형성할 수도 있다. 제어 유닛은 범용 프로세서, 및/또는 예를 들어 ASIC 들 FPGA 들, 또는 다른 하드웨어 또는 프로세싱 유닛들 또는 회로와 같은 하나 이상의 전용 하드웨어를 포함할 수도 있다. 몇몇 예들에서, 제어 유닛은 추가로 오디오 디코더 (46), 비디오 디코더 (48) 의 어느 것의 기능, 및/또는 목적지 디바이스 (40) 에 대해 설명된 임의의 다른 기능을 수행할 수도 있다.

일반적으로, MPD 파일의 프리젠테이션들은, 예를 들어, 목적지 디바이스의 예상되는 렌더링 성능들, 목적지 디바이스의 예상되는 디코딩 성능들, 프리젠테이션들의 비디오 파일들에 대한 평균 비트 레이트와 같은 특성들에 의해 상이하다. MPD 관리 유닛 (30) 은 예상되는 렌더링 성능들, 예상되는 디코딩 성능들, 및 MPD 파일의 프리젠테이션 헤더들에서의 프리젠테이션들에 대한 평균 비트레이트들을 시그널링할 수도 있다. 이러한 방식으로, 목적지 디바이스 (40) 는, 예를 들어 비디오 출력 (44) 의 렌더링 성능들 및/또는 비디오 디코더 (48) 의 디코딩 성능들에 기초하여, 어느 프리젠테이션들로부터 비디오 파일들을 취출할 지를 결정할 수도 있다.

목적지 디바이스 (40) 는 추가로, 예를 들어 네트워크 연결 (34) 의 현재 대역폭 이용가능성을 결정하고 프리젠테이션에 대한 평균 비트 레이트에 기초하여 프리젠테이션을 선택할 수도 있다. 즉, 비디오 출력 (44) 및 비디오 디코더 (48) 가 MPD 파일의 프리젠테이션들 중 하나보다 많은 것의 비디오 파일들을 렌더링 및 디코딩하기 위한 성능을 각각 가지는 경우, 목적지 디바이스 (40) 는 현재 대역폭 이용가능성에 기초하여 프리젠테이션들 중 하나를 선택할 수도 있다. 마찬가지로, 대역폭 이용가능성이 변화할 때, 목적지 디바이스 (40) 는 지원되는 프리젠테이션들 사이에서 동적으로 변경할 수도 있다. 예를 들어, 대역폭이 제한적으로 될 때, 목적지 디바이스 (40) 는 상대적으로 더 낮은 비트 레이트 비디오 파일들을 갖는 프리젠테이션으로부터 다음 비디오 파일을 취출할 수도 있는 반면, 대역폭이 확장될 때, 목적지 디바이스 (40) 는 상대적으로 더 높은 비트 레이트 비디오 파일들을 갖는 프리젠테이션으로부터 다음 비디오 파일을 취출할 수도 있다.

각각의 프리젠테이션의 비디오 파일들을 시간적으로 정렬하는 것에 의해, 프리젠테이션들 사이의 동적 스위치가 목적지 디바이스 (40) 와 같은 목적지 디바이스들에 대해 단순화될 수도 있다. 즉, 목적지 디바이스 (40) 는, 대역폭 상태들이 변화하였다고 결정 시, 비디오 데이터가 이미 취출된 시간 주기를 결정한 다음, 대역폭 상태들에 기초하여 프리젠테이션들 중의 하나로부터 다음 비디오 파일을 취출할 수도 있다. 예를 들어, 목적지 디바이스 (40) 에 의해 취출된 마지막 비디오 파일이 시간 T 에서 종료되고다음 파일이 기간 N 의 파일인 경우, 목적지 디바이스 (40) 는, 프리젠테이션들의 각각의 비디오 파일들이 시간적으로 정렬되어 있기 때문에, 대역폭 상태들에 기초하여, 프리젠테이션들 중 임의의 것으로부터 시간 T 에서 시간 T+N 까지 비디오 파일을 취출할 수도 있다.

또한, MPD 관리 유닛 (30) 및 웹 브라우저 (38) 는 비디오 파일들에 대한 공통 명명 방식으로 구성될 수도 있다. 일반적으로, 각각의 비디오 파일 (예를 들어, 각각의 3GPP 파일) 은, MPD 파일이 저장되는 URL (uniform resource locator), URL 에서의 MPD 파일의 URN (uniform resource name), 프리젠테이션의 명칭, 시작 시간 (starting time), 및 종료 시간 (end time) 에 기초한 명칭을 포함할 수도 있다. 따라서, MPD 관리 유닛 (30) 및 웹 브라우저 (38) 는 예를 들어 "[URL]/[URN]_pre[X]_[start time]_[end time]" 과 같은 명명 방식을 이용하도록 구성될 수도 있고, 여기서, [URL] 은 MPD 파일의 URL 로 대체되고, [URN] 은 MPD 파일의 URN 으로 대체되며, X 는 프리젠테이션의 번호로 대체되고, [start time] 은 요청되는 3GPP 파일의 시작 시간으로 대체되며, [end time] 은 요청되는 3GPP 파일의 종료 시간으로 대체된다. 다른 예들에서, 명칭은 프리젠테이션 내의 3GPP 파일의 위치에 기초할 수도 있다. 예를 들어, 3GPP 파일 M 에 대해, 3GPP 파일의 명칭은 "[URL]/[URN]_pre[X]_[M]" 으로 자동적으로 생성될 수도 있다. 몇몇 예들에서, 웹 브라우저 (38) 는, 예를 들어 상기의 명명 방식 및 파일의 바이트 범위를 이용하여 파일을 특정함으로써, 파일에 대해 HTTP 부분적 GET 요청을 제출할 수도 있다. 웹 브라우저 (38) 는, 예를 들어 상기의 명명 방식을 이용하여 특정된 파일의 사이즈를 취출하기 위해 HTTP HEAD 방법을 이용할 수도 있다.

따라서, 예를 들어, URL "www.qualcomm.com" 및 "program1" 의 URN 을 갖는 MPD 파일에 대해, 10:02 에서 시작하고 10:05 에서 종료하는 프리젠테이션 3 의 3GPP 파일을 취출하기 위해, 웹 브라우저 (38) 는 "www.qualcomm.com/program1_pre3_10:02_10:05" 에 대한 HTTP GET 요청을 제출할 수도 있다. 추가적인 예로서, 프리젠테이션 2 가 프리젠테이션 3 보다 상대적으로 더 높은 비트 레이트를 가지는 경우, 목적지 디바이스 (40) 는 이용가능한 대역폭이 증가하였다고 결정하고, 이전의 예시적 3GPP 파일을 취출한 후, 그 다음, 웹 브라우저 (38) 는 "www.qualcomm.com/program1_pre2_10:05_10:08" 에 대해 HTTP GET 요청을 제출할 수도 있다.

일반적으로, 각각의 3GPP 파일은 독립저긍로 디코딩가능할 수도 있다. 각각의 3GPP 파일은 예를 들어, 적어도 하나의 인트라-코딩된 픽쳐 (picture) 를 포함할 수도 있다. 예를 들어, 각각의 3GPP 파일은 하나 이상의 픽쳐들의 그룹 (groups of pictures; GOP) 들 또는 수퍼프레임들을 포함할 수도 있고, 여기서, GOP 또는 수퍼프레임들에 대한 적어도 하나의 키 프레임은 인트라-모드 인코딩을 이용하여 인코딩된다. 이러한 방식으로, 웹 브라우저 (38) 는 MPD 파일의 프리젠테이션들 중 임의의 것으로부터 3GPP 파일을 취출하고, 동일한 프리젠테이션의 다른 3GPP 파일들에 대한 참조 없이 그 취출된 3GPP 파일을 디코딩할 수도 있다. 예를 들어, 웹 브라우저 (38) 가, 이용가능한 대역폭이 증가하였다고 결정하는 경우, 웹 브라우저 (38) 는 더 높은 평균 비트 레이트를 갖는 프리젠테이션의 시간적으로 더 앞선 3GPP 파일들을 취출함이 없이, 현재 프리젠테이션보다 상대적으로 더 높은 평균 비트 레이트를 갖는 프리젠테이션으로부터 다음 3GPP 파일을 요청할 수도 있다.

이러한 방식으로, 소스 디바이스 (20) 는 MPD 파일들의 형태의 비디오 데이터를 목적지 디바이스 (40) 와 같은 목적지 디바이스들에 제공할 수도 있다. 몇몇 예들에서, 소스 디바이스 (20) 는 웹 서버를 포함할 수도 있다. 목적지 디바이스 (40) 는, 예를 들어 컴퓨터 또는 인터넷 액세스를 갖는 셀룰러 전화기와 같은 모바일 디바이스와 같이, 예를 들어 HTTP 를 통해 데이터를 취출할 수 있는 임의의 디바이스를 포함할 수도 있다. 소스 디바이스 (20) 는 인코딩된 비디오 데이터를 목적지 디바이스 (40) 로 전송하고 그 인코딩된 비디오 데이터의 특성들을 시그널링하기 위해 본 개시의 기술들을 구현할 수도 있다. 인코딩된 비디오 데이터는, 예를 들어 MPEG-1, MPEG-2, H.263, H.264/MPEG-4, H.265 와 같은 다양한 상이한 표준들 또는 다른 인코딩 표준들 중 임의의 것을 이용하여 인코딩될 수도 있다.

일예로서, ITU-T H.264 표준은, 루마 (luma) 컴포넌트들에 대해 16×16, 8×8, 또는 4×4, 및 크로마 (chroma) 컴포넌트들에 대해 8×8 과 같은 다양한 블록 사이즈들에서의 인트라 예측 (intra prediction), 및 루마 컴포넌트들에 대해 16×16, 16×8, 8×16, 8×8, 8×4, 4×8, 및 4×4, 및 크로마 컴포넌트들에 대해 대응하는 스케일링된 (scaled) 사이즈들과 같은 다양한 블록 사이즈들에서의 인터 예측 (inter prediction) 을 지원한다. 본 개시에서, "N×N" 및 "N 바이 (by) N" 은 수직 및 수평 디멘션 (dimension) 들의 면에서 블록의 픽셀 디멘션들, 예를 들어 16×16 픽셀들 또는 16 바이 16 픽셀들을 지칭하기 위해 상호교환가능하게 사용될 수도 있다. 일반적으로, 16×16 블록은 수직 방향으로 16 픽셀들 (y=16) 및 수평 방향으로 16 픽셀들 (x = 16) 을 가질 것이다. 마찬가지로, N×N 블록은 일반적으로 수직 방향으로 N 픽셀들 및 수평 방향으로 N 픽셀들을 가지고, 여기서 N 은 음이 아닌 정수 값을 나타낸다. 블록 내의 픽셀들은 행 (row) 들 및 열 (column)들로 배열될 수도 있다. 또한, 비디오 데이터의 블록들은 정사각형일 필요는 없고, 예를 들어, N×M 픽셀들을 포함할 수도 있으며, 여기서 N 은 M 과 동일하지 않다.

16×16 보다 적은 블록 사이즈들은 16×16 매크로블록의 분할들로서 지칭될 수도 있다. 비디오 블록들은, 픽셀 도메인 (domain) 내의 픽셀 데이터의 블록들, 또는 예를 들어 이산 코사인 변환 (DCT), 정수 변환, 웨이브릿 (wavelet) 변환, 또는 코딩된 비디오 블록들과 예측 비디오 블록들 사이의 픽셀 차이들을 나타내는 잔여 비디오 블록 데이터에 대한 개념적으로 유사한 변환과 같은 변환의 애플리케이션 등의 변환 도메인 내의 변환 계수들의 블록들을 포함할 수도 있다. 몇몇 경우들에서, 비디오 블록은 변환 도메인 내의 양자화된 변환 계수들의 블록들을 포함할 수도 있다.

더 작은 비디오 블록들은 더 양호한 해상도를 제공할 수 있고, 높은 레벨들의 상세를 포함하는 비디오 프레임의 로케이션들에 대해 이용될 수도 있다. 일반적으로, 매크로블록들 및 때로 서브-블록들로 지칭되는 다양한 파티션들이 비디오 블록들로서 고려될 수도 있다. 또한, 슬라이스는 매크로블록들 및/또는 서브-블록들과 같은 복수의 비디오 블록들인 것으로 고려될 수도 있다. 각각의 슬라이스는 비디오 프레임의 독립적으로 디코딩가능한 유닛일 수도 있다. 다르게는, 프레임들 그 자체는 디코딩가능한 유닛들일 수도 있고, 또는 프레임의 다른 부분들은 디코딩가능한 유닛들로서 정의될 수도 있다. "코딩된 유닛" 또는 "코딩 유닛" 이라는 용어는, 전체 프레임, 프레임의 슬라이스, 시퀀스라고도 불리는 픽쳐들의 그룹 (GOP), 또는 적용가능한 코딩 기술들에 따라 정의된 또다른 독립적으로 디코딩가능한 유닛과 같은 비디오 프레임의 임의의 독립적으로 디코딩가능한 유닛을 지칭할 수도 있다.

매크로블록이라는 용어는 16×16 픽셀들을 포함하는 2-차원 픽셀 어레이에 따라 픽쳐 및/또는 비디오 데이터를 인코딩하기 위한 데이터 구조를 지칭한다. 각각의 픽셀은 크로미넌스 (chrominance) 컴포넌트와 루미넌스 (luminance) 컴포넌트를 포함한다. 따라서, 매크로블록은 8×8 픽셀들의 2-차원 어레이를 각각 포함하는 4 개의 루미넌스 블록들, 16×16 픽셀들의 2-차원 어레이를 각각 포함하는 2 개의 크로미넌스 블록들, 코딩된 블록 패턴 (CBP) 과 같은 신택스 (syntax) 정보를 포함하는 헤더, 인코딩 모드 (예를 들어, 인트라 (I) 인코딩 모드, 또는 인터 (P 또는 B) 인코딩 모드), 인트라-인코딩된 블록의 분할들에 대한 분할 사이즈 (예를 들어, 16×16, 16×8, 8×16, 8×8, 8×4, 4×8, 또는 4×4), 또는 인터-인코딩된 매크로블록에 대한 하나 이상의 모션 벡터들을 정의할 수도 있다.

비디오 인코더 (28), 비디오 디코더 (48), 오디오 인코더 (26), 오디오 디코더 (46), 및 MPD 관리 유닛 (30) 은 각각, 하나 이상의 마이크로프로세서들, 디지털 신호 프로세서 (DSP) 들, 애플리케이션 특정 집적 회로 (ASIC) 들, 필드 프로그래머블 게이트 어레이 (FPGA) 들, 이산 로직 회로, 소프트웨어, 하드웨어, 펌웨어 또는 이들의 임의의 조합들과 같은 적용가능한 다양한 적합한 인코더 또는 디코더 중 임의의 것으로서 구현될 수도 있다. 비디오 인코더 (28) 및 비디오 디코더 (48)의 각각은, 결합된 비디오 인코더/디코더 (CODEC) 의 일부로서 통합될 수도 있는 하나 이상의 인코더들 또는 디코더들 내에 포함될 수도 있다. 마찬가지로, 오디오 인코더 (26) 및 오디오 디코더 (46) 의 각각은, 결합된 오디오 인코더/디코더 (CODEC) 의 일부로서 통합될 수도 있는 하나 이상의 인코더들 또는 디코더들 내에 포함될 수도 있다. 비디오 인코더 (28), 비디오 디코더 (48), 오디오 인코더 (26), 오디오 디코더 (46), MPD 관리 유닛 (30), 및/또는 웹 브라우저 (38) 에 대한 애플리케이션을 실행하는 하드웨어는 집적 회로, 마이크로프로세서, 및/또는 셀룰러 전화기와 같은 무선 통신 디바이스를 포함할 수도 있다.

도 2 는 MPD 관리 유닛 (30) (도 1 참조) 의 컴포넌트들의 예시적인 배열을 나타내는 블록도이다. 도 2 의 예에서, MPD 관리 유닛 (30) 은 MPD 형성 유닛 (60), 비디오 입력 인터페이스 (80), 오디오 입력 인터페이스 (82), MPD 파일 저장부 (84), 및 MPD 출력 유닛 (70) 을 포함한다. MPD 형성 유닛 (60) 은 도 2 의 예에서 파라미터 시그널링 유닛 (62) 및 3GPP 파일 관리 유닛 (64) 을 포함하는 한편, MPD 출력 유닛 (70) 은 3GPP 파일 취출 유닛 (72) 및 HTTP 서버 유닛 (74) 을 포함한다.

비디오 입력 인터페이스 (80) 및 오디오 입력 인터페이스 (82) 는 인코딩된 비디오 및 오디오 데이터를 각각 수신한다. 비디오 입력 인터페이스 (80) 및 오디오 입력 인터페이스 (82) 는 인코딩된 비디오 및 오디오 데이터를 그 데이터가 인코딩대로 수신할 수도 있고, 또는, 컴퓨터-판독가능 매체로부터 인코딩된 비디오 및 오디오 데이터를 취출할 수도 있다. 인코딩된 비디오 및 오디오 데이터를 수신 시, 비디오 입력 인터페이스 (80) 및 오디오 입력 인터페이스 (82) 는 그 인코딩된 비디오 및 오디오 데이터를 MPD 파일 내로의 조립을 위해 MPD 형성 유닛 (60) 으로 패스한다.

MPD 형성 유닛 (60) 은 그 인코딩된 오디오 및 비디오 데이터를 수신하여 MPD 파일들을 형성한다. MPD 형성 유닛 (60)은, 다양한 상이한 방식들로 인코딩된 비디오 데이터, 예를 들어, 상이한 사이즈들 (해상도들) 의 비디오 데이터, 다양한 인코딩 표준들에 따라 인코딩된 비디오 데이터, 다양한 프레임 레이트들 및/또는 비트 레이트들 또는 다른 변화들로 인코딩된 비디오 데이터를 수신할 수도 있다. MPD 생성 유닛 (60) 은 MPD 파일 내에 저장될 다양한 프리젠테이션들의 각각을 위해 인코딩된 비디오 데이터를 수신할 수도 있다.

3GPP 파일 관리 유닛 (64) 은, 각각의 프리젠테이션의 3GPP 파일들이 시간적으로 정렬되도록, MPD 파일의 각각의 프리젠테이션에 대해 개별적인 3GPP 파일들을 형성할 수도 있다. 즉, 각각의 프리젠테이션 내의 제 1 3GPP 파일은 동일한 지속기간, 시작 시간, 및 종료 시간을 갖는 동일한 비디오 프래그먼트에 대응한다. 동일한 시작 시간 및 종료 시간을 갖는 동일한 비디오 프래그먼트에 대응하는 3GPP 파일들은 대응하는 3GPP 파일들로서 지칭된다. 프리젠테이션들은 다양한 프레임 레이트들을 가질 수도 있기 때문에, 프리젠테이션들의 대응하는 3GPP 파일들은 상이한 수들의 인코딩된 픽쳐들을 포함할 수도 있다. 마찬가지로, 인코딩 방법들 및 비트레이트들이 프리젠테이션들 사이에서 상이할 수도 있기 때문에, 대응하는 3GPP 파일들은 상이한 파일 사이즈들을 가질 수도 있다.

몇몇 예들에서, 3GPP 파일 관리 유닛 (64) 은, 각각의 3GPP 파일이 동일한 시간적 지속기간을 가지도록 각각의 프리젠테이션에 대해 3GPP 파일들을 구축할 수도 있다. 이들 예들에서, 파라미터 시그널링 유닛 (62) 은 공통 지속기간을 나타내는 하나의 값을 이용하여 MPD 파일에 대해 모든 3GPP 파일들의 지속기간을 시그널링할 수도 있다. 다른 예들에서, 3GPP 파일 관리 유닛 (64) 은, 프리젠테이션들 사이의 대응하는 3GPP 파일들은 동일한 지속기간을 가지지만 프리젠테이션 내의 3GPP 파일들은 개별적인 지속기간들을 가질 수도 있도록 3GPP 파일들을 구축할 수도 있다. 이러한 예들에서, 파라미터 시그널링 유닛 (62) 은 각각의 3GPP 파일에 대해 지속기간을 시그널링할 수도 있다. 파라미터 시그널링 유닛 (62) 은 또한, 프리젠테이션에 대해 각각의 3GPP 파일의 시작 시간, 종료 시간, 및/또는 지속기간을 시그널링할 수도 있다.

파라미터 시그널링 유닛 (62) 은 또한, MPD 파일, 그 MPD 파일 내에 포함된 3GPP 파일들, 및 MPD 파일의 프리젠테이션들의 다른 특성들을 시그널링할 수도 있다. 예를 들어, 파라미터 시그널링 유닛 (62) 은 각각의 프리젠테이션에 대해 목적지 디바이스의 디코더의 예상 디코딩 성능들을 시그널링할 수도 있다. 디코딩 성능들은, 예를 들어, 프리젠테이션의 비디오 데이터를 인코딩하기 위해 사용되는 인코딩 표준과 같은 디코딩 방법들, 최소 매크로블록 디코딩 레이트, 최소 프레임 디코딩 레이트, 프레임 또는 블록 버퍼 사이즈, 및/또는 다른 예상되는 디코딩 성능들을 포함할 수도 있다. 몇몇 예들에서, 파라미터 시그널링 유닛 (62) 은 프로파일 표시자 (profile indicator; profile IDC) 값 및 레벨 표시자 (레벨 IDC) 값을 이용하여 예상 디코딩 성능들을 시그널링할 수도 있다.

비디오 코딩 표준들의 면에서, "프로파일 IDC" 값은 그들에 적용되는 알고리즘들, 피쳐 (feature) 들, 툴 (tool) 들, 및 제약들의 서브셋트에 대응할 수도 있다. 예를 들어, H.264 표준에 의해 정의되는 바와 같이, "프로파일 IDC" 값은 H.264 표준에 의해 특정되는 전체 비트스트림 신택스의 서브셋트를 설명한다. "레벨 IDC" 값은, 예를 들어, 픽쳐들의 해상도, 비트 레이트, 및 매크로블록 (MB) 프로세싱 레이트와 관련된 디코더 메모리 및 계산과 같은 디코더 자원 소모의 제한들을 설명한다.

파라미터 시그널링 유닛 (62) 은 또한 각각의 프리젠테이션에 대해 예상 렌더링 성능들을 시그널링할 수도 있다. 예로서, 파라미터 시그널링 유닛 (62) 은 각 프리젠테이션에 대해 픽쳐 폭, 픽쳐 높이, 및/또는 프레임 레이트를 시그널링할 수도 있다.

MPD 형성 유닛 (30) 은 생성된 MPD 파일들을, 각각의 프리젠테이션에 대한 3GPP 파일들, 및 MPD 파일, 프리젠테이션들, 및 각각의 3GPP 파일에 대한 시그널링된 특성들과 함께 MPD 파일 저장부 (84) 에 저장할 수도 있다. MPD 파일 저장부 (84) 는, 예를 들어, 하드 디스크, 솔리드 스테이드 드라이브, 자기 테이프, 광학적 저장 매체, 또는 다른 저장 매체 또는 이들의 조합과 같은 컴퓨터-판독가능 저장 매체를 포함할 수도 있다.

MPD 출력 유닛 (70) 은 예를 들어 목적지 디바이스 (40) 와 같은 목적지 디바이스들로부터 HTTP 요청들을 수신하고 이에 응답할 수도 있다. 도 2 의 예에서, 네트워크 인터페이스 (32) (도 1 참조) 는 HTTP 요청들을 포함할 수도 있는 애플리케이션-레이어 데이터를 수신된 네트워크 패킷들로부터 추출하고, 그 추출된 애플리케이션-레이어 데이터를 MPD 관리 유닛 (30) 으로 패스하는 것으로 가정한다. MPD 출력 유닛 (70) 은 일반적으로 그 수신된 요청이 무엇을 요청하고 있는지를 결정하고, 그 요청된 데이터를 MPD 파일 저장부 (84) 로부터 취출하며, 그 요청된 데이터를 요청 디바이스, 예를 들어 목적지 디바이스 (40) 에 제공한다.

이 예에서, HTTP 서버 유닛 (74) 은 GET, 부분적 GET, 및 HEAD 요청들과 같은 HTTP 요청들을 수신 및 해석하기 위해 HTTP 를 구현한다. 비록 본 개시가 예시의 목적을 위해 HTTP 의 예를 설명하지만, 다른 네트워크 프로토콜 또한 본 개시에 설명된 기술들과 함께 이용될 수도 있다.

HTTP 서버 유닛 (74) 은 요청들에 의해 요청된 데이터를 결정하기 위해 수신된 HTTP 요청들을 해석할 수도 있다. 요청은 예를 들어 특정 3GPP 파일 또는 특정 3GPP 파일의 일부, MPD 파일, MPD 파일의 프리젠테이션들, 및/또는 프리젠테이션의 3GPP 파일들의 특성들을 설명하는 헤더 데이터, 또는 MPD 의 다른 데이터를 구체화할 수도 있다. HTTP 서버 유닛 (74) 은 그 다음 그 요청된 데이터의 표시 (indication) 를 3GPP 파일 취출 유닛 (72) 으로 패스할 수도 있다. 3GPP 파일 취출 유닛 (72) 은 MPD 파일 저장부 (84) 로부터 요청된 데이터를 취출하고, 그 취출된 데이터를 HTTP 서버 유닛 (74) 으로 리턴 (return) 할 수도 있고,이 HTTP 서버 유닛 (74) 은 그 데이터를 하나 이상의 HTTP 패킷들 내로 패키징 (packaging) 하고 그 패킷들을 네트워크 인터페이스 (32) 로 보낼 수도 있다. 네트워크 인터페이스 (32) 은 그 다음 HTTP 패킷들을 캡슐화 (encapsulate) 하고 그 패킷들을 예를 들어 목적지 디바이스 (40) 로 출력할 수도 있다.

파라미터 시그널링 유닛 (62) 이 MPD 파일에 대해 3GPP 파일들의 시작 시간 및 지속기간들을 시그널링할 때, 목적지 디바이스 (40) 와 같은 목적지 디바이스들은 MPD 파일의 다양한 프리젠테이션들의 서로에 대해 대응하는 3GPP 파일들을 결정할 수도 있다. 예를 들어, HTTP 서버 유닛 (74) 은, MPD 파일, MPD 파일의 하나 이상의 프리젠테이션들, 및/또는 MPD 파일의 프리젠테이션들의 하나 이상의 3GPP 파일들의 특성들을 설명하는 데이터를 이용하여 HTTP HEAD 요청들에 응답할 수도 있다. 목적지 디바이스 (40) 는 또한, 예를 들어 3GPP 파일들이 대응하는 비디오 세그먼트의 시간적 지속기간에 의해 파일 사이즈들을 나눔으로써, 각각의 프리젠테이션에 대해 순시 비트레이트들을 도출하기 위해 대응하는 3GPP 파일들의 파일 사이즈들을 취출할 수도 있다.

HTTP 를 통한 스트리밍에서의 대역폭 적응 (adaptation) 은 다음과 같이 구현될 수도 있다. 특정 시간 T 에서, 목적지 디바이스 (40) 는 가장 가까운 비트 레이트이지만 소망되는 비트 레이트보다는 더 작은 비트 레이트를 갖는 스트림 (예를 들어, 프리젠테이션) 으로 스위칭할 수도 있다. 프리젠테이션의 순시 비트 레이트는 현재 프리젠테이션의 현재 3GPP 파일로 시간 T 를 맵핑함으로써 계산될 수 있다. 이렇게 하기 위해, 각각의 3GPP 파일은 동일한 시간적 길이 deltaT 를 갖는다고 가정하고, 목적지 디바이스는 M = T/deltaT 로서 3GPP 파일에 대해 식별자 M 을 산출할 수도 있다. 목적지 디바이스 (40) 는 그 다음 3GPP 파일에 대한 파일 명칭을 생성하고 uiFileLength 로서 3GPP 파일의 길이를 취출할 수도 있다.

목적지 디바이스 (40) 는 또한 MPD 파일로부터 3GPP 파일에 대한 시간적 지속기간을 취출할 수도 있다. 이 시간적 지속기간은 uiDuration 으로서 표시될 수도 있고, 이는 본 예에서 초 단위로 설명되는 것으로 가정된다. 목적지 디바이스 (40) 는 그 다음 순시 비트 레이트를 비트 레이트 = 8.0 * uiFileLength/uiDuration/100 으로서 산출할 수도 있고, 이는 kbps의 단위를 갖는 비트 레이트의 값이 된다. 동일 장명의 각각의 프리젠테이션에 대해 모든 비트 레이트 값을 체크함으로써, 그 값은 가장 가깝지만 소망되는 비트 레이트보다 더 작은 값이 된다. 대응하는 프리젠테이션은 그 다음 목적지 디바이스 (40) 가 스위칭해야하는 타겟 (target) 프리젠테이션일 수 있다. 즉, 목적지 디바이스 (40) 는 타겟 프리젠테이션으로부터 3GPP 파일들을 취출하는 것을 시작할 수도 있다.

또한, HTTP 서버 유닛 (74) 은, "[URN]_pre[X]_[start time]_[end time]" 과 같은 특정 명명 방식에 기초하여 3GPP 파일들을 인식하도록 구성될 수도 있고, 여기서, [URN] 은 MPD 파일의 URN 으로 대체되고, X 는 프리젠테이션의 번호로 대체되고, [start time] 은 요청되는 3GPP 파일의 시작 시간으로 대체되며, [end time] 은 요청되는 3GPP 파일의 종료 시간으로 대체된다. 따라서, HTTP 서버 유닛 (74) 은, 명명 방식을 이용하여 3GPP 파일을 식별하는 요청에 응답하여, [start time] 의 시작 시간 및 [end time] 의 종료 시간을 갖는 프리젠테이션 _pre[X] 로부터 [URN] 에 의해 식별되는 MPD 파일에 대응하는 3GPP 파일을 취출하기 위한 표시를 3GPP 파일 취출 유닛 (72) 으로 보낼 수도 있다. 마찬가지로, 3GPP 파일 취출 유닛 (72) 은 이 요청된 3GPP 파일을 취출할 수도 있다. 목적지 디바이스 (40) 는 3GPP 파일들의 시작 시간과 종료 시간에 기초한 요청들, 및 3GPP 파일들을 취출하기 위한 프리젠테이션에서의 포함을 위해 3GPP 파일들의 명칭을 자동적으로 생성할 수도 있다.

*몇몇 예들에서, HTTP 서버 유닛 (74) 은 상기 명칭 방식에 따라 식별된 파일의 바이트 범위를 구체화하는 HTTP 부분적 GET 요청을 수신할 수도 있다. HTTP 서버 유닛 (74) 은 파일의 바이트 범위의 표시를 3GPP 파일 취출 유닛 (72) 에 제공할 수도 있고, 이 3GPP 파일 취출 유닛 (72) 은 요청된 바이트 범위에 대응하는 파일의 데이터만을 취출하여 그 취출된 데이터를 HTTP 서버 유닛 (74) 에 제공할 수도 있다. HTTP 서버 유닛 (74) 은 이 데이터를 유사하게 캡슐화하고 그 데이터를 네트워크 인터페이스 (32) 로 전송할 수도 있으며, 이 네트워크 인터페이스 (32) 는 그 데이터를 추가적으로 캡슐화하여 연결 (34) 을 통해 그 데이터를 송신할 수도 있다.

비록 도 2 의 예에서 MPD 관리 유닛이 MPD 형성 유닛 (60) 및 MPD 출력 유닛 (70) 양자 모두를 포함하는 거승로 도시하였지만, 다른 예들에서, 별개의 디바이스들이 MPD 형성 유닛 (60) 및 MPD 출력 유닛 (70) 에 속하는 기능을 수행하도록 구성될 수도 있다. 예를 들어, 제 1 디바이스는 인코딩된 비디오 데이터를 MPD 파일의 형태로 캡슐화하고 MPD 파일의 파라미터들을 시그널링하는 한편, 제 2 디바이스는 제 1 디바이스에 의해 형성된 MPD 파일들에 대한 액세스를 제공하기 위한 웹 서버로서 구성될 수도 있다. 마찬가지로, 소스 디바이스 (20) 와 분리된 인코딩 디바이스는 미가공 비디오 데이터를 인코딩하고 그 인코딩된 비디오 데이터를 소스 디바이스 (20) 의 MPD 관리 유닛 (30) 으로 전송할 수도 있다. 일반적으로, 소스 디바이스 (20) 에 속하는 기능의 임의의 것이 공통 또는 별개의 디바이스들 및/또는 디바이스들의 유닛들에 포함될 수도 있다. MPD 파일 저장부 (84) 는 몇몇 예들에서 예를 들어 외부 하드 드라이브 또는 외부 파일 서버오 같은 외부 저장 디바이스에 대응할 수도 있다.

도 3 은 예시적인 MPD 파일 (90) 내에 저장된 데이터를 나타내는 블록도이다. 파라미터 시그널링 유닛 (62) 은, 예를 들어, MPD 가 저장되는 URL (예를 들어, "www.qualcomm.com/media") 을 나타내는 URL 값 (92), MPD 파일 (90) 을 위한 비디오 데이터의 시간적 지속기간을 나타내는 지속기간 값 (94), 및 MPD 파일 (90) 의 명칭, 예를 들어 "program1" 에 대응하는 베이스 URN 값 (96) 과 같은 MPD 파일 (90) 을 위한 정보를 시그널링할 수도 있다. MPD 파일 (90) 은 프리젠테이션 (100A) 의 예와 유사한 많은 수의 프리젠테이션들을 포함한다. MPD 파일 (90) 의 프리젠테이션 (100A) 의 예에 있어서, 파라미터 시그널링 유닛 (62) 은 프리젠테이션 식별자 (102A), 목적지 디바이스가 프리젠테이션 (100A) 을 지칭하기 위해 사용할 수도 있는 증분적 URN (104A) (예를 들어, "_preX"), 예를 들어 프로파일 IDC 값 (106A) 및 레벨 IDC 값 (108A) 을 포함하는 예상 디코딩 성능 값들, 및 예를 들어 프레임 레이트 값 (110A) 을 포함하는 예상 렌더링 성능 값들, 픽쳐 폭 값 (112A), 및/또는 픽쳐 높이 값 (114A) 을 시그널링할 수도 있다.

파라미터 시그널링 유닛 (62) 은 또한 프리젠테이션 (100A) 과 같은 프리젠테이션들에 대한 타이밍 정보를 시그널링할 수도 있다. 타이밍 정보 속성들 (116A) 은 예를 들어 (각각의 프리젠테이션에 대해 동일할 수도 있는) 프리젠테이션들 내의 엔트리 (entry) 들의 수, 3GPP 파일 식별자들 (118A) 에 대응하는 3GPP 파일들의 지속기간들, 및 동일한 지속기간을 갖는 3GPP 파일들의 수를 포함할 수도 있다. 몇몇 예들에서, 비록 데이터가 다른 프리젠테이션들의 각각에 대해 동일한 것으로 가정될 수도 있지만, 파라미터 시그널링 유닛 (62) 은 오직 하나의 프리젠테이션 (예를 들어, 프리젠테이션 (100A)) 에 대해서만 이 데이터를 시그널링할 수도 있다. 다음과 같은 의사코드는 프리젠테이션의 타이밍 특성들을 시그널링하는데 이용될 수도 있는 데이터 구조의 일부를 설명할 수도 있다:

timing info. attributes

unsigned int (32) number_entry;

for (i =0 ; i < number_entry ; i++) {

unsigned int (32) deltaT;

unsigned int (32) numFileWithSameDuration;

}

예시적인 의사코드에서, "number_entry" 는 동일한 프리젠테이션에 대해 3GPP 파일들의 연속적인 그룹의 수를 나타낸다. 파라미터 시그널링 유닛 (62) 은 무비 (movie) 프래그먼트들의 모든 지속기간들이 동일한 경우 number_entry 값을 1 로 설정할 수도 있다. 값 "deltaT" 는 3GPP 파일들의 연속적인 그룹의 i-번째 엔트리에서의 3GPP 파일의 지속기간을 나타낸다. 값 "numFileWithSameDuration" 은 i-번째 엔트리에서의 연속적인 3gp 파일들의 수를 나타낸다. 파라미터 시그널링 유닛 (62) 은 프리젠테이션 내의 모든 3GPP 파일들이 deltaT 의 동일한 지속기간을 갖는다는 것을 표시하기 위해 "numFileWithSameDuration" 의 값을 0 과 동일하게 설정할 수도 있다. 예를 드리어, 라이브 스트리밍에 대응하여, 파라미터 시그널링 유닛 (62) 은 모든 3GPP 파일이 동일한 지속기간을 갖는다는 것을 나타내기 위해 "number_entry" 값을 1 로 설정할 수도 있다.

프리젠테이션 (100A) 은 또한 3GPP 파일 관리 유닛 (64) 에 의해 구축된 3GPP 파일들에 대응하는 다수의 3GPP 파일 식별자들 (118A) 을 포함한다. MPD 파일 (90) 의 프리젠테이션 (100) 의 각각은 동일한 수의 3GPP 파일들을 포함할 수도 있고, 이 3GPP 파일들은 시간적으로 정렬될 수도 있다.

이 시그널링된 데이터를 이용하여, 목적지 디바이스 (40) 는 HTTP GET 및 부분적 GET 요청들을 제출하기 위해 3GPP 파일들의 명칭들을 자동적으로 생성할 수도 있다. 즉, 목적지 디바이스 (40) 는 3GPP 파일들에 대해 URN 을 자동적으로 생성할 수도 있다. 예를 들어, MPD 파일 (90) 의 베이스 URN (96) 이 "program1" 이고 프리젠테이션 (100A) 의 프리젠테이션 식별자 (102A) 가 "pre2" 라고 가정하면, 3GPP 파일 식별자들 (118A) 에 대응하는 3GPP 파일들의 URN 의 공통 부분은 "program1_pre2" 이다. 프리젠테이션 (100A) 내의 3GPP 파일 식별자들 (118A) 중 M 번째 것에 대해, 목적지 디바이스 (40) 는 "program1_pre2_M" 에 대한 HTTP GET 요청을 제출할 수도 있다. 예를 들어, 45 번째 3GPP 파일을 취출하기 위해, 목적지 디바이스 (40) 는 "program1_pre2_45.3gp" 에 대한 HTTP GET 요청을 제출할 수도 있다. 다르게는, 목적지 디바이스 (40) 는 "program1_pre2_Mstart_Mend" 에 대한 HTTP GET 요청을 제출할 수도 있고, 여기서, Mstart 는 3GPP 파일 식별자들 (118A) 에 대응하는 3GPP 파일들 중 M 번째 것의 시작 시간에 대응하고, Mend 는 3GPP 파일 식별자들 (118A) 에 대응하는 3GPP 파일들 중 M 번째 것의 종료 시간에 대응한다.

목적지 디바이스 (40) 와 같은 HTTP 클라이언트는 또한 프리젠테이션 (100A) 등과 같은 프리젠테이션의 시간 T 에 대해 탐색할 수도 있다. 시간 T 에 대응하는 3GPP 파일 식별자들 (118A) 에 대응하는 3GPP 파일들 중 M 번째 것을 취출하기 위해, 목적지 디바이스 (40) 는 M = T/deltaT 로서 M 을 산출할 수도 있고, 여기서, deltaT 는 3GPP 파일들의 각각이 동일한 지속기간을 갖는다고 가정하여 전술한 바와 같이 타이밍 정보 속성들 (116A) 내에 시그널링될 수도 있다. 한편, 3GPP 파일들이 동일한 지속기간을 갖지 않는 경우, 목적지 디바이스 (40) 는 3GPP 파일 식별자들 (118A) 에 대응하는 3GPP 파일들 중 어느 것을 취출할지를 결정하기 위해 3GPP 파일들의 각각에 대해 지속기간들을 취출할 수도 있다. M 을 산출한 후에, 목적지 디바이스 (40) 는 3GPP 파일 식별자들 (118A) 에 대응하는 3GPP 파일들 중 M 번째 것을 취출할 수도 있다.

프리젠테이션들 (100) 의 각각의 3GPP 파일들이 시간적으로 정렬되는 경우, 목적지 디바이스 (40) 는 프리젠테이션들 중 임의의 것으로부터 3GPP 파일들을 취출하기 위해 상기의 예에서 "_pre2" 에 대해 프리젠테이션들 (100) 중 임의의 것의 식별자를 대체할 수도 있다. 일례로서, MPD 파일 (90) 이 5 개의 프리젠테이션들을 가지고, 목적지 디바이스 (40) 가 프리젠테이션들 2, 3, 또는 4 중 어느 것을 디코딩 및 렌더링할 수 있다고 가정한다. 프리젠테이션 2 는 상대적으로 낮은 품질 (그리고 따라서 낮은 평균 비트레이트) 을 가지고, 프리젠테이션 3 는 더 높은 품질 및 더 높은 평균 비트 레이트를 가지며, 프리젠테이션 4 는 더욱 더 높은 품질 및 더욱 더 높은 평균 비트 레이트를 가진다고 추가적으로 가정한다. 초기에, 목적지 디바이스 (40) 는 이용가능한 대역폭이 상대적으로 낮다고 결정할 수도 있고, 그래서 예를 들어 "program1_pre2_1.3gp" 에 대한 HTTP GET 요청을 이용하여 프리젠테이션 2 로부터 3GPP 파일 "1" 을 취출할 수도 있다. 그 다음, 목적지 디바이스 (40) 는 이용가능한 대역폭이 증가하였다고 결정할 수도 있고, 그래서 "program1_pre3_2.3gp" 에 대한 HTTP GET 요청을 이용하여 다음 3GPP 파일을 취출할 수도 있다. 그 다음, 목적지 디바이스 (40) 는 이용가능한 대역폭이 더 추가적으로 증가하였다고 결정할 수도 있고, 그래서 "program1_pre4_3.3gp" 에 대한 HTTP GET 요청을 이용하여 다음 3GPP 파일을 취출할 수도 있다.

도 4 는 다양한 프리젠테이션들 (134, 140) 의 3GPP 파일들 (138, 144) 과 비디오 (146) 의 비디오 세그먼트들 (130) 사이의 정렬을 나타내는 개념도이다. 비디오 (146) 는 비디오 세그먼트들 (130A - 130N) (비디오 세그먼트들 (130)) 을 포함한다. 도 4 의 예는 본 예에서의 프리젠테이션들 (134 및 140) 을 도시하지만, 프리젠테이션들 (134 와 140) 사이의 타원들에 의해 나타나는 바와 같이 추가적인 프리젠테이션들을 포함할 수도 있다. 프리젠테이션 (134) 은 헤더 데이터 (136) 및 3GPP 파일들 (138A - 138N) (3GPP 파일들 (138)) 을 포함한다. 프리젠테이션 (140) 은 헤더 데이터 (142) 및 3GPP 파일들 (144A - 144N) (3GPP 파일들 (144)) 을 포함한다.

비록 3GPP 파일들 (138) 이 3GPP 파일들 (144) 과는 상이한 사이즈이지만, 3GPP 파일들 (138) 과 3GPP 파일들 (144) 은 비디오 (146) 의 비디오 세그먼트들 (130) 과 시간적으로 정렬된다. 도 4 의 예에서, 3GPP 파일 (138A) 및 3GPP 파일 (144A) 은 비디오 세그먼트 (130A) 에 대응하고, 3GPP 파일 (138B) 및 3GPP 파일 (144B) 은 비디오 세그먼트 (130B) 에 대응하며, 3GPP 파일 (138C) 및 3GPP 파일 (144C) 은 비디오 세그먼트 (130C) 에 대응하고, 3GPP 파일 (138N) 및 3GPP 파일 (144N) 은 비디오 세그먼트 (130N) 에 대응한다. 즉, 3GPP 파일 (138A) 과 3GPP 파일 (144A) 은, 예를 들어, 비록 잠재적으로 상이하게 인코딩 및/또는 렌더링되지만, 일반적으로 비디오 세그먼트 (130A) 와 동일한 장면들에 대응하는 비디오 데이터를 포함한다.

헤더 데이터 (136, 142) 는 프리젠테이션들 (134, 140) 을 각각 나타내는 데이터를 일반적으로 포함한다. 헤더 데이터 (136, 142) 는 도 3 의 프리젠테이션 식별자 (102A), 증분적 URN (104A), 프로파일 IDC 값 (106A), 레벨 IDC 값 (108A), 프레임 레이트 값 (110A), 픽쳐 폭 값 (112A), 픽쳐 높이 값 (114A), 및 타이밍 정보 속성들 (116A) 과 유사한 데이터를 포함할 수도 있다. 프리젠테이션들 (134 - 140) 의 3GPP 파일들 (138, 144) 을 설명하는 MPD 파일은, MPD 파일, 프리젠테이션들 (134, 140), 및 3GPP 파일들 (138, 144) 의 특성들을 설명하는 헤더 데이터 (미도시) 를 또한 포함한다.

이러한 방식으로, 목적지 디바이스 (40) (도 1 참조) 는, 목적지 디바이스 (40) 가 3GPP 파일들 (138) 및/또는 3GPP 파일들 (144) 의 비디오 데이터를 디코딩 및 디스플레이할 수 있는지 여부를 결정하기 위해 헤더 데이터 (136, 142) 를 취출할 수도 있다. 목적지 디바이스 (40) 가 3GPP 파일들 (138) 및 3GPP 파일들 (144) 양자로부터 데이터를 디코딩 및 렌더링할 수 있다고 추정하면, 목적지 디바이스 (40) 는 대역폭 이용가능성에 기초하여 프리젠테이션 (134) 과 프리젠테이션 (140) 사이에서 선택할 수도 있다. 예를 들어, 프리젠테이션 (134) 이 프리젠테이션 (140) 보다 더 낮은 평균 비트 레이트를 갖는다고 추정하면, 대역폭 이용가능성이 상대적으로 낮을 때 목적지 디바이스 (40) 는 프리젠테이션 (134) 으로부터 3GPP 파일 (138A) 을 초기에 취출할 수도 있다. 그 다음, 목적지 디바이스 (40) 가 대역폭 이용가능성이 증가하였다고 결정한다고 가정하면, 목적지 디바이스 (40) 는 다음으로 3GPP 파일 (144B) 를 취출할 수도 있다. 3GPP 파일들 (138A 및 144A) 은 시간적으로 정렬되어 있기 때문에, 목적지 디바이스 (40) 는, 그 목적지 디바이스 (40) 의 사용자가 잠재적으로 변화하는 품질이긴 하지만 비디오 세그먼트 (130A) 에 바로 이어 비디오 세그먼트 (130B) 를 볼 수 있도록, 끊김 없이 3GPP 파일들 (144B) 의 인코딩된 비디오 데이터를 디코딩 및 렌더링할 수도 있다.

도 5 는 소스 디바이스로부터 목적지 디바이스로 인코딩된 비디오 데이터를 전송하는 예시적인 방법을 나타내는 플로우차트이다. 예시적인 목적을 위해, 도 5 의 방법은 소스 디바이스 (20) 및 목적지 디바이스 (40) 에 대해 설명되었지만, 다른 디바이스들이 도 5 의 방법을 수행하도록 구성될 수도 있다는 것을 이해하여야 한다.

도 5 의 예에서, 소스 디바이스 (20) 는 비디오의 다양한 비디오 세그먼트들에 대응하는 인코딩된 비디오 데이터를 수신한다. 소스 디바이스 (20) 는 그 인코딩된 비디오 데이터를 MPD 파일내에 캡슐화한다 (180). 예를 들어, 소스 디바이스 (20) 는 도 4 에 도시된 바와 같이, 공통의 비디오 세그먼트에 대응하는 다양한 상이한 프리젠테이션들의 인코딩된 비디오 프레임들을 결정하고, 다양한 프리젠테이션들의 하나 이상의 각각의 3GPP 파일들 내에 그 비디오 프레임을 캡슐화할 수도 있다. 소스 디바이스 (20) 는 또한, MPD 파일, 프리젠테이션들, 및 3GPP 파일들의 특성들을 MPD 파일, 프리젠테이션들, 및/또는 3GPP 파일들의 헤더 부분에 시그널링한다 (182). 이 특성들은 도 3 에 도시된 예시적인 특성들에 대응할 수도 있다.

목적지 디바이스 (40) 의 사용자는 초기에 예를 들어 웹 브라우저 (38) (도 1 참조) 를 이용하여 웹 페이지 상의 링크로부터 또는 웹 페이지의 임베딩된 비디오로부터 MPD 파일을 취출할 수도 있다. 사용자가 비디오를 보기를 요청한 후에 목적지 디바이스 (40) 는 MPD 파일의 특성들을 요청할 수도 있다 (184). 예를 들어, 목적지 디바이스 (40) 는 특정 MPD 파일에 대해 소스 디바이스 (20) 로 HTTP HEAD 요청을 발행할 수도 있다. 응답하여, 소스 디바이스 (20) 는 MPD 파일의 특성들을 나타내는 데이터를 제공할 수도 있다 (186). 이 데이터는, 예를 들어, MPD 파일에 대한 프리젠테이션들의 수, 목적지 디바이스 (40) 에 대해 각각의 프리젠테이션의 3GPP 파일들을 디코딩 및 렌더링할 수 있는 것으로 예상되는 각각의 프리젠테이션에 대한 디코딩 성능들 및 렌더링 성능들, 각각의 프리젠테이션에 대한 평균 비트레이트들, (3GPP 파일들의 각각이 동일한 지속기간을 가지는 경우) 프리젠테이션들에 대한 3GPP 파일들의 지속기간, (3GPP 파일들이 프리젠테이션 내에서 상이한 지속기간들을 가질수 있지만 상이한 프리젠테이션들 사이에 시간적으로 정렬되는 경우) 하나 이상의 프리젠테이션들에 대한 3GPP 파일들의 각각의 지속기간들, 각각의 프리젠테이션에 대한 증분적 URN, 또는 MPD 파일들의 다른 특성들을 나타낼 수도 있다.

목적지 디바이스 (40) 는 프리젠테이션들 중 어느 것이 목적지 디바이스 (40) 에 의해 디코딩 및 렌더링될 수 있는지를 결정하기 위해 예상되는 디코딩 및 렌더링 성능들을 분석할 수도 있다 (188). 예를 들어, 목적지 디바이스 (40) 는 비디오 디코더 (48) 가 수신된 MPD 파일 특성들에서 예상되는 디코딩 성능들에 의해 나타나는 프로파일 IDC 값 및 레벨 IDC 값을 만족하는지 여부를 결정할 수도 있다. 목적지 디바이스 (40) 는 또한, 비디오 출력 (44) 이 예상되는 렌더링 성능들 값에 의해 나타나는 프레임 레이트에서 비디오 데이터를 디스플레이할 수 있는지 여부, 및 비디오 출력 (44) 의 사이즈가 예상되는 렌더링 성능들 값의 픽쳐 높이 및/또는 픽쳐 폭 값들과 매칭하는지 여부를 결정할 수도 있다. 몇몇 예들에서, 비디오 디코더 (48) 및/또는 비디오 출력 (44) 은 비디오 출력 (44) 내에 적절하게 맞도록 하기 위해 디코딩된 픽쳐들을 업샘플링 (upsampling) 또는 다운샘플링 (downsampling) 할 수도 있다. 마찬가지로, 비디오 디코더 (48) 및/또는 비디오 출력 (44) 은 비디오 출력 (44) 의 리프레시 (refresh) 레이트에 매칭시키기 위해 디코딩된 비디오 데이터의 프레임들을 보간 또는 데시메이팅 (decimating) (또는 스킵 (skip)) 할 수도 있다. 목적지 디바이스 (40) 는 MPD 파일의 프리젠테이션들이 디코딩 및 렌더링될 수 있다는 표시들을 컴퓨터-판독가능 저장 매체, 예를 들어, 목적지 디바이스 (40) 의 랜덤 액세스 메모리 (RAM) 에 기록할 수도 있다.

그 다음, 목적지 디바이스 (40) 는 그 자신과 소스 디바이스 (20) 사이의 네트워크의 대역폭의 상대적인 양을 결정할 수도 있다 (190). 목적지 디바이스 (40) 는 이용가능한 대역폭의 양을 결정하기 위해 이용가능한 대역폭을 추정하기 위한 임의의 아려진 기술들을 일반적으로 이용할 수도 있다. 예를 들어, 목적지 디바이스 (40) 는, 추가적으로 또는 대안으로, 라운드 트립 지연 (예를 들어, 인터넷 제어 메시지 프로토콜 (ICMP) 핑 요청을 소스 디바이스 (20) 로 발행함으로써), 평균 패킷 변질 또는 패킷 손실 (예를 들어, 전송 제어 프로토콜 (TCP) 통계에 따라 손실된 또는 변질된 패킷들을 분석함으로써), 또는 다른 네트워크 성능 메트릭들을 추정할 수도 있다.

그 다음, 목적지 디바이스 (40) 는 3GPP 파일들을 취출하기 시작할 프리젠테이션들 중의 하나를 선택할 수도 있다 (192). 목적지 디바이스 (40) 는, 비디오 디코더 (48) 가 예상된 디코딩 성능들을 만족하고 비디오 출력 (44) 이 예상된 렌더링 성능들을 만족하는 프리젠테이션들 중의 하나를 선택할 수도 있다. 목적지 디바이스 (40) 가 하나보다 많은 프리젠테이션의 인코딩된 비디오 데이터를 디코딩 및 렌더링할 수 있는 경우, 목적지 디바이스 (40) 는 프리젠테이션들의 평균 비트 레이트들을 서로에 대해 비교함으로써 대역폭의 결정된 양에 기초하여 이들 잠재적인 프리젠테이션들 중에서 선택할 수도 있다. 목적지 디바이스 (40) 는, 목적지 디바이스 (40) 가 이용가능한 대역폭이 낮을 때 상대적으로 더 낮은 평균 비트레이트를 갖는 프리젠테이션을 선택하지만 이용가능한 대역폭이 높을 때 상대적으로 더 높은 평균 비트레이트를 갖는 프리젠테이션을 선택하도록, 평균 비트레이트를 이용가능한 대역폭에 긍정적으로 연관시키는 기능을 갖도록 구성될 수도 있다.

프리젠테이션을 선택한 후에, 목적지 디바이스 (40) 는 그 프리젠테이션으로부터 3GPP 파일을 요청할 수도 있다 (194). 목적지 디바이스 (40) 는 제 1 3GPP 파일 또는 탐색 요청된 시간 (즉, 사용자가 비디오 데이터 내에서 탐색하기를 요청한 위치에 대응하는 시간적 로케이션) 을 포함하는 3GPP 파일을 선택할 수도 있다. 3GPP 파일을 요청하기 위해 목적지 디바이스는 소스 디바이스 (20) 의 URL, MPD 파일의 URN, 프리젠테이션 식별자, 및 3GPP 파일 식별자를 특정하는 HTTP GET 요청을 구축할 수도 있다. 3GPP 파일 식별자는 3GPP 파일의 숫자 식별자에 대응할 수도 있고, 또는 시작 시간 및/또는 종료 시간 중 적어도 하나를 포함할 수도 있다. 몇몇 예들에서, 목적지 디바이스 (40) 는 예를 들어 사용자가 탐색하기 위한 시간을 포함하는 3GPP 파일이 비교적 긴 경우 (예를 들어, 60 초에 가까운 경우), 부분적 GET 요청을 구축할 수도 있다.

HTTP GET 또는 부분적 GET 요청을 수신한 후에, 소스 디바이스 (20) 는 요청된 3GPP 파일 (또는 요청된 3GPP 파일의 일부) 을 취출 및 전송할 수도 있다 (196). 소스 디바이스 (20) 는 하나 이상의 HTTP 패킷들에서 3GPP 파일을 목적지 디바이스 (40) 로 전송할 수도 있다. HTTP 패킷들의 각각은 예를 들어 TCP/IP 에 따라 추가적으로 캡슐화될 수도 있다. 요청된 3GPP 파일을 수신 및 재조립한 후에, 목적지 디바이스 (40) 는 그 3GPP 파일을 디코딩 및 디스플레이할 수도 있다 (198). 즉, 목적지 디바이스 (40) 의 웹 브라우저 (38) 는 3GPP 파일을 디코딩을 위해 비디오 디코더 (48) 로 전송할 수도 있고, 비디오 디코더 (48) 는 그 디코딩된 비디오 데이터를 디스플레이를 위해 비디오 출력 (44) 으로 전송할 수도 있다.

*그 다음, 목적지 디바이스 (40) 는 디코딩 및 디스플레이되는 비디오 파일이 비디오의 마지막 3GPP 파일이었는지 여부를 결정할 수도 있다 (200). 목적지 디바이스 (40) 는, 비디오의 종단이 도달되었거나 사용자가 비디오를 보는 것을 중지하는 것을 선택하는 경우에 3GPP 파일이 마지막이었다고 결정할 수도 있다. 디코딩 및 디스플레이된 비디오 파일이 마지막 비디오 파일이 아니었던 경우 (200 의 "아니오" 분기), 목적지 디바이스 (40) 는 이용가능한 대역폭을 재평가하고 (190), 새롭게 결정된 대역폭의 양에 기초하여 프리젠테이션을 선택하며 (192), 그 선택된 프리젠테이션으로부터 다음 3GPP 파일을 요청할 수도 있다 (194). 한편, 디코딩 및 디스플레이된 비디오 파일이 마지막 파일이었던 경우 (200 의 "예" 분기), 본 방법은 종료될 수도 있다.

도 6 은 예시적인 3GPP 파일 (220) 의 엘리먼트들을 블록도이다. 목적지 디바이스 (40) 는 3GPP 파일 (220) 내의 요청된 시간에 대해 탐색하기 위해 3GPP 파일 (220) 로부터의 데이터를 이용할 수도 있다. 일반적으로, 3GPP 파일들은, 예를 들어 2 초와 60 초 사이, 또는 더 길거나 더 짧은, 임의의 시간 길이에 대응하는 비디오 데이터를 포함할 수도 있다. 3GPP 파일에 대한 시간의 길이가 비교적 짤은 경우 (예를 들어, 2 초에 가까운 경우), 목적지 디바이스 (40) 는 탐색 시간, 즉, 예를 들어 사용자에 의해 요청된 바와 같이 비디오 데이터를 디스플레이하기 시작하기 위한 비디오 데이터의 시간을 포함하는 전체 3GPP 파일을 취출하도록 구성될 수도 있다. 한편, 3GPP 파일에 대한 시간의 길이가 더 긴 경우 (예를 들어, 60 초에 가까운 경우), 목적지 디바이스 (40) 는 예를 들어 HTTP 부분적 GET 요청을 이용함으로써 탐색 이간에 가까운 3GPP 파일들의 일부를 디코딩 및 디스플레이를 위해 취출하도록 구성될 수도 있다.

3GPP 파일 (220) 은 무비 (MOOV) 박스 (222) 및 무비 프래그먼트 랜덤 액세스 (MFRA) 박스 (230) 를 포함한다. MOOV 박스 (222)는 일반적으로 인코딩된 비디오 데이터를 포함하는 한편, MFRA 박스 (230) 는 MOOV 박스 (222) 내의 데이터의 랜덤 액세스를 보조하기 위한 설명적 데이터를 포함한다. 도 6 의 예에서, MOOV 박스 (222) 는 전체 파일에 대한 메타데이터 (224) 및 가능하게는 비디오 프래그먼트들 (226A - 226C) (비디오 프래그먼트들 (226)) 을 포함하는 한편, MFRA 박스는 트랙 프래그먼트 랜덤 액세스 (TFRA) 박스 (232) 및 무비 프래그먼트 랜덤 액세스 오프셋 (MFRO) 박스 (236) 를 포함하고, 트랙 프래그먼트 랜덤 액세스 (TFRA) 박스 (232) 는 프래그먼트 시그널링 데이터 (234) 를 포함하고, 무비 프래그먼트 랜덤 액세스 오프셋 (MFRO) 박스 (236) 는 MFRA 사이즈 값 (238) 을 포함한다.

MFRA 사이즈 값 (238) 은 MFRA 박스 (230) 의 길이를 바이트 단위로 기술한다. 도 6 의 예에서, 3GPP 파일 (220) 은 N 바이트를 가진다. 목적지 디바이스 (40) 는 3GPP 파일 (220) 의 길이, 예를 들어 이 예에서 N 의 값을 결정하기 위해 3GPP 파일 (220) 에 대한 HTTP HEAD 요청을 제출할 수도 있다. 일반적으로, MFRO 박스 (236) 는 3GPP 파일 (220) 의 마지막 4 바이트를 점유한다. 따라서, MFRA 박스 (30) 의 길이를 결정하기 위해, 목적지 디바이스 (40) 와 같은 클라이언트 디바이스들은, 예를 들어 [N - 4] 에서 N 까지의 바이트 범위를 특정하는 HTTP 부분적 GET 요청을 이용하여, 3GPP 파일 (220) 의 마지막 4 바이트를 취출할 수도 있다. MFRO 박스 (236) 가 MFRA 사이즈 값 (238) 을 포함함에 따라, 목적지 디바이스 (40) 는 MFRO 박스 (236) 를 취출한 후에 MFRA 박스 (230) 의 길이를 결정할 수도 있다.

MFRA 사이즈 값 (238) 을 이용하여 MFRA 박스 (230) 의 길이를 결정한 후에, 목적지 디바이스 (40) 는 MFRA 박스 (230) 의 나머지 부분을 취출할 수도 있다. 예를 들어, 목적지 디바이스 (40) 는 [N - MFRA 사이즈] 에서 [N - 4] 의 바이트 범위를 특정하는 3GPP 파일 (220) 에 대한 HTTP 부분적 GET 를 발행할 수도 있다. 도 6 에 도시된 바와 같이, 이 부분은 TFRA 박스 (232) 를 포함하고, 이 TFRA 박스 (232) 는 프래그먼트 시그널링들 (234) 을 포함한다. 프래그먼트 시그널링들 (234) 은 예를 들어 비디오 프래그먼트들 (226) 의 시간적 로케이션들을 특정할 수도 있다. 헤더 데이터 (224)

목적지 디바이스 (40) 는 탐색 요청을 만족하기 위해 비디오 프래그먼트들 (226) 중 어느 것을 취출할 것인가를 결정하기 위해 프래그먼트 시그널링들 (234) 을 이용할 수도 있다. 즉, 목적지 디바이스 (40) 는 비디오 프래그먼트들 (226) 중 어느 것이 탐색 요청에서 특정된 시간을 포함하는지를 결정할 수도 있다. 목적지 디바이스 (40) 는 비디오 프래그먼트들 (226) 의 각각에 대해 바이트 범위들을 결정하기 위해 헤더 데이터 (224) 를 취출할 수도 있다. 프래그먼트 시그널링들 (234) 에 기초하여 비디오 프래그먼트들 (226) 중 어느 것이 탐색 요청에서 특정된 시간을 포함하는지를 결정한 후에, 목적지 디바이스 (40) 는 탐색 요청에서 특정된 시간을 포함하는 비디오 프래그먼트들 (226) 중의 하나, 및 후속하는 비디오 프래그먼트들 (226) 의 각각을 취출할 수도 있다.

몇몇 예들에서, 목적지 디바이스 (40) 는, 탐색 요청에서 특정된 시간을 포함하는 비디오 프래그먼트들 (226) 중 하나에 대해 제 1 부분적 GET 요청을 제출하고, 수신 시 이 비디오 프래그먼트를 디코딩 및 디스플레이하기를 시작하며, 그 다음, 비디오 프래그먼트들 (226) 중 후속하는 비디오 프래그먼트들을 취출하기 위해 하나 이상의 추가적인 부분적 GET 를 제출할 수도 있다. 다른 예들에서, 목적지 디바이스 (40) 는, 예를 들어 [N - MFRA 사이즈] 에 걸쳐 비디오 프래그먼트들 (226) 중 하나의 시작에 대응하는 바이트 범위를 특정함으로써, 탐색 요청에서 특정된 시간을 포함하는 비디오 프래그먼트들 (226) 중 하나 및 비디오 프래그먼트들 (226) 중 후속하는 비디오 프래그먼트들의 각각을 취출하기 위해 하나의 부분적 GET 요청을 제출할 수도 있다.

도 7 은 3GPP 파일 내의 시간에 대한 탐색 요청에 응답하여 3GPP 파일의 프래그먼트를 요청하는 예시적인 방법을 나타내는 플로우차트이다. 초기에, 목적지 디바이스 (40) 는, 예를 들어 사용자로부터 웹브라우저 (38) 를 통해, 비디오 내의 특정 시간을 탐색하기 위한 요청을 수신할 수도 있다 (250). 예를 들어, 사용자는 특정 시간적 로케이션을 탐색하기를 요청하기 위해 비디오 데이터의 시간적 위치를 나타내는 스크롤 바 (scroll bar) 의 일부분을 선택할 수도 있다.

이에 응답하여, 목적지 디바이스 (40) 는 탐색 시간을 포함하는 MPD 파일의 프리젠테이션의 3GPP 파일을 결정할 수도 있다 (252). 즉, 목적지 디바이스 (40) 는 탐색 시간보다 적은 시작 시간 및 탐색 시간보다 큰 종료 시간을 갖는 프리젠테이션의 3GPP 파일들 중의 하나를 결정할 수도 있다. 예시적 목적을 위해, 도 7 의 방법은, 3GPP 파일 식별자 (118), 3GPP 파일들 (138), 또는 3GPP 파일들 (144) 에 대응하는 3GPP 파일들 중의 임의의 것에 대응할 수도 있는, 도 6 의 3GPP 파일 (220) 에 대해 논의되었다. 3GPP 파일 (220) 은 탐색 시간보다 적은 시작 시간 및 탐색 시간보다 큰 종료 시간을 가진다. 목적지 디바이스 (40) 는 3GPP 파일 (220) 을 포함하는 프리젠테이션의 헤더 부분 내에 저장된 3GPP 파일 (220) 에 대한 타이밍 정보 속성들에 기초하여 3GPP 파일 (220) 을 식별할 수도 있다. 3GPP 파일 (220) 의 탐색 시간과 시작 시간 사이의 차이는 시간 오프셋으로 지칭될 수도 있다.

그 다음 목적지 디바이스 (40) 는, 예를 들어 소스 디바이스 (20) 에 대해 3GPP 파일 (220) 을 특정하는 HTTP HEAD 요청을 발행함으로써, 3GPP 파일 (220) 의 길이를 결정할 수도 있다. 3GPP 파일 (220) 의 길이를 바이트 (예를 들어, N 바이트) 단위로 결정 시, 목적지 디바이스 (40) 는, 3GPP 파일 (220) 로부터 MFRO 박스 (236) 를 취출하기 위해, 3GPP 파일 (220) 및 3GPP 파일 (220) 의 [N - 4] 내지 N 의 바이트 범위를 특정하는 HTTP 부분적 GET 요청을 발행할 수도 있다 (254).

도 6 의 예에서 도시된 바와 같이, MFRO 박스 (236) 는 MFRA 사이즈 값 (238) 을 포함한다. 따라서, 목적지 디바이스 (40) 는 MFRA 박스 (230) 의 나머지를 취출하기 위해, MFRO 박스 (236) 을 수신한 후에, MFRA사이즈 값 (238) 을 이용할 수도 있다 (256). 즉, 목적지 디바이스 (40) 는 3GPP 파일 (220) 의 바이트 범위 [N - MFRA 사이즈] 내지 [N - 4] 에 대해 HTTP 부분적 GET 를 발행할 수도 있다. 이러한 방식으로, 목적지 디바이스 (40) 는 MFRO 데이터에 기초하여 나머지 MFRA 데이터를 취출할 수도 있다. 목적지 디바이스 (40) 는 또한 MOOV 박스 (222) 의 MOOV 헤더 데이터, 예를 들어, 헤더 (224) 를 취출할 수도 있다 (258).

목적지 디바이스 (40) 는, 비디오 프래그먼트들 (226) 중 어느 것이 탐색 시간을 초과함이 없이 탐색 시간에 가장 가까운 시작 시간을 갖는지를 결정하기 위해, MFRA 박스 (230) 의 프래그먼트 시그널링들 (232) 및 헤더 (224) 의 데이터를 사용할 수도 있다 (260). 그 다음, 목적지 디바이스 (40) 는 3GPP 파일 (220) 로부터 비디오 프래그먼트들 (226) 중 하나 및 비디오 프래그먼트들 (226) 의 각각을 취출하기 위해 하나 이상의 HTTP 부분적 GET 요청들을 발행할 수도 있다 (262). 즉, 헤더 (224) 및 프래그먼트 시그널링들 (232) 로부터의 표시를 이용하여, 목적지 디바이스 (40) 는, 탐색 시간을 초과하지 않고 탐색 시간에 가장 가까운 시작 시간을 갖는 비디오 프래그먼트들 (226) 중의 하나를 시작 바이트로 결정할 수도 있다. 그 다음, 목적지 디바이스 (40) 는, 다양한 예들에서, 이 시작 바이트 및 비디오 프래그먼트들 (226) 중의 이 프래그먼트의 마지막 바이트 또는 MOOV 박스 (222) 중의 종단 중 어느 하나를 특정하는 HTTP 부분적 GET 요청을 구축할 수도 있다.

비록 도 7 의 방법이 MFRA 박스 (230) 로부터의 데이터의 이용에 대해 설명되었지만, 목적지 디바이스 (40) 는 3GPP 파일 (222) 로부터 비디오 프래그먼트들 (226) 을 추출하기 위한 유사한 기술을 수행하기 위해 다른 데이터를 이용할 수도 있다. 예를 들어, 목적지 디바이스 (40) 는 3GPP 파일의 아이템 로케이션 (item location; ILOC) 에 기초하여 비디오 프래그먼트들 (226) 중 어느 것을 추출할 지를 결정할 수도 있다. 3GPP 파일은, 예를 들어, 처음 4 바이트는 아이템 로케이션 오프셋 (item location offset; ILOO) 박스를 포함하고 그 바로 다음에는 ILOC 가 오도록 구축될 수도 있다. ILOO 박스는 ILOC 박스의 길이를 특정할 수도 있다. ILOO 박스는 다음과 같은 예시적인 의사코드에 따라 구축될 수도 있다:

aligned(8) class ItemLocationBoxOffset extends FullBox ('iloo' version, 0) {

unsigned int(32) size;

}

본 예의 의사코드에서, ItemLocationBoxOffset 은 ILOO 박스에 대한 새로운 클래스의 명칭을 설명한다. 본 예는 ILOC 박스의 사이즈를 나타내는 32-비트 정수 값 "사이즈" 를 특정한다. ILOO 박스에 의해 특정된 ILOC 박스의 사이즈 값은 ILOO 박스의 4 바이트를 포함할 수도 있다.

*ILOC 박스는, 3GPP 파일 내에 포함된 비디오 프래그먼트들의 타이밍 정보, 예를 들어, 각각의 프래그먼트의 시작 및 종료 시간들을 나타내는 타이밍 정보 박스를 특정할 수도 있다. 타이밍 정보는 예를 들어 비트를 절약하기 위해 자동적 방식으로 시그널링될 수도 있다. ILOC 박스는, 3GPP 파일의 MOOV 박스의 다른 설명적 데이터, 예를 들어, 도 6 의 헤더 (224) 에 의해 저장된 것과 유사한 데이터를 더 포함할 수도 있다. ILOC 및 ILOO 박스들은 무비 프래그먼트들의 타이밍 정보를 나타내기 위해 사용될 수 있다. 따라서, 목적지 디바이스 (40) 는 ILOC 및 ILOO 박스들의 데이터에 기초하여 하나 이상의 HTTP 부분적 GET 요청들을 구축함으로써 탐색 요청을 만족시키기 위해 비디오 프래그먼트들을 취출할 수도 있다.

특히, 목적지 디바이스 (40) 는 ILOC 박스에 대한 사이즈 값에 대응하는 3GPP 파일의 처음 4 바이트를 먼저 취출할 수도 있다. 즉, 목적지 디바이스 (40) 는 ILOO 박스를 취출하기 위해, 3GPP 파일의 바이트 0 내지 4 에 대해 HTTP 부분적 GET 요청을 먼저 발행할 수도 있다. ILOO 박스에 의해 특정된 ILOC 박스의 사이즈를 이용함으로써, 목적지 디바이스 (40) 는, 예를 들어 바이트 4 내지 [ILOC 사이즈] 를 특정하는 HTTP 부분적 GET 요청을 발행함으로써, ILOC 박스를 취출할 수도 있다.

ILOC 박스는, 각각의 비디오 프래그먼트에 대한 바이트 범위들 및 시간적 로케이션들, 예를 들어, 시작 시간, 종료 시간, 시작 바이트, 및 종료 바이트를 나타내는 타이밍 정보 박스 (ILOC 박스 다음으로도 지칭된다) 의 위치 및 길이를 특정할 수도 있다. 따라서, 목적지 디바이스 (40) 는 그 다음으로 ILOC 박스의 데이터에 기초하여 타이밍 정보 박스를 취출할 수도 있다. 그 다음, 목적지 디바이스 (40) 는, 비디오 프래그먼트들 중 어느 것이 탐색 시간보다 적은 시작 시간 및 탐색 시간보다 큰 종료 시간을 포함하는지를 결정하고, 3GPP 파일의 이러한 비디오 프래그먼트 및 후속하는 비디오 프래그먼트를 취출하기 위해 하나 이상의 HTTP 부분적 GET 요청들을 발행할 수도 있다.

타이밍 정보 박스는 다음과 같은 예시적인 의사코드에 따라 구현될 수도 있다:

aligned(8) class TimeMovieFragment extends FullBox ('tmfr', version = 0, 0) {

unsigned int (32) number_entry;

for (i=0; i< number_entry; i++) {

unsigned int (32) deltaTFragment;

unsigned int (32) numContinueFragWithSameDuration;

}

본 예시적 의사코드에서, "number_entry" 값은 3GPP 파일의 연속적인 무비 프래그먼트들의 수를 설명한다. number_entry 는 모든 무비 프래그먼트들의 지속기간들이 동일하다는 것을 나타내기 위해 1 의 값으로 설정될 수도 있다. "deltaTFragment" 값은 일반적으로 3GPP 파일에서의 연속적인 무비 프래그먼트들의 그룹의 i-번째 엔트리의 프래그먼트들의 지속기간을 설명할 수도 있다. "numContinueFragWithSameDuration" 값은 i-번째 엔트리에서의 연속적인 무비 프래그먼트들의 수를 설명한다. "numContinueFragWithSameDuration" 값이 0 과 동일한 경우에는, 프리젠테이션 내의 모든 3GPP 파일이 동일한 deltaT 의 지속기간을 가진다는 것을 나타낸다.

하나 이상의 예들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의적 조합으로 구현될 수도 있다. 소프트웨어로 구현되는 경우, 기능들은 컴퓨터-판독가능 매체 상에 하나 이상의 명령들 또는 코드로서 저장 또는 송신될 수도 있다. 컴퓨터-판독가능 매체는 컴퓨터 프로그램을 한 장소에서 다른 장소로 전송하는 것을 용이하게 하는 임의의 매체를 포함하는 컴퓨터 데이터 저장 매체 또는 통신 매체를 포함할 수도 있다. 데이터 저장 매체는, 본 개시에서 설명된 기술들의 구현을 위한 명령들, 코드 및/또는 데이터 구조들을 취출하기 위해 하나 이상의 컴퓨터들 또는 하나 이상의 프로세서들에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수도 있다. "컴퓨터-판독가능 저장 매체" 라는 용어는 제조 물품에 대응할 수도 있는 비일시적 (non-transitory), 유형적 (tangible) 컴퓨터-판독가능 저장 매체를 지칭하는 것으로 의도된다. 한정적이 아닌 예시적인 방식으로, 이러한 컴퓨터-판독가능 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학적 디스크 저장 매체, 자기적 디스크 저장 매체, 또는 다른 자기적 저장 디바이스들, 플래시 메모리, 또는 명령들 또는 데이터 구조들의 형태로 원하는 프로그램 코드를 운반 또는 저장하기 위해 이용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 또한, 임의의 연결이 적절하게 컴퓨터-판독가능 매체로 지칭된다. 예를 들어, 소프트 웨어가, 동축 케이블, 광섬유 케이블, 트위스트 페어 (twisted pair), 디지털 가입자 회선 (DSL), 또는 적외선, 라디오, 및 마이크로파와 같은 무선 기술들을 이용하여 웹사이트, 서버, 또는 다른 원격 소스로부터 송신되는 경우, 이러한 동축 케이블, 광섬유 케이블, 트위스트 페어 (twisted pair), 디지털 가입자 회선 (DSL), 또는 적외선, 라디오, 및 마이크로파와 같은 무선 기술들은 매체의 정의에 포함된다. 본원에 사용된 바와 같이 디스크 (disk) 및 디스크 (disc) 는 컴팩트 디스크 (CD), 레이저 디스크, 광학 디스크, DVD, 플로피 디스크 및 블루-레이 디스크를 포함하고, 여기서, 디스크 (disk) 는 통상적으로 데이터를 자기적으로 재싱하고, 디스크 (disc) 는 데이터를 레이저들을 이용하여 광학적으로 재생한다. 상기한 것들의 조합들 또한 컴퓨터-판독가능 매체의 범위 내에 포함되어야 한다.

코드는, 하나 이상의 디지털 신호 프로세서 (DSP) 들, 범용 마이크로프로세서들, 애플리케이션 특정 집적 회로 (ASIC) 들, 필드 프로그래머블 게이트 어레이 (FPGA) 들 또는 다른 등가적 접적 또는 이산 로직 회로 등과 같은 하나 이상의 프로세서들에 의해 실행된다. 따라서, 본원에서 사용된 바와 같이 "프로세서" 라는 용어는 본원에서 설명된 기술들의 구현을 위해 적합한 전술한 구조 또는 임의의 다른 구조를 지칭할 수도 있다. 또한, 몇몇 양태들에서, 본원에서 설명된 기능은 인코딩 및 디코딩을 위해 구성된 전용 하드웨어 및/또는 소프트웨어 내에 제공되거나 결합된 코덱 내에 통합된 수도 있다. 또한, 본 기술들은 하나 이상의 회로 또는 로직 엘리먼트들에서 완전히 구현될 수 있을 것이다.

본 개시의 기술들은, 무선 핸드셋, 집적 회로 (IC) 또는 집적 회로들의 셋트 (IC 들) (예를 들어, 칩 셋트) 를 포함하는 넓은 범위의 디바이스들 또는 장치들에서 구현될 수도 있다. 본 개시에서 다양한 컴포넌트들, 모듈들, 또는 유닛들은 개시된 기술들을 수행하기 위해 구성된 디바이스들의 기능적 양태들을 강조하도록 설명되었지만, 상이한 하드웨어 유닛들에 의한 실현을 반드시 요구하는 것은 아니다. 오히려, 전술한 바와 같이, 적합한 소프트웨어 및/또는 펌웨어와 함께, 전술한 하나 이상의 프로세서들을 포함하는, 코덱 하드웨어 유닛에서 결합되거나 상호협동적인 하드웨어 유닛들의 집합에 의해 제공될 수도 있다.

다양한 예들이 설명되었다. 이들 및 다른 예들은 첨부된 청구범위의 범위 내이다.

Claims

인코딩된 비디오 데이터에 대한 정보를 제공하는 방법으로서,
인코딩된 비디오 데이터 유닛들을 수신하는 단계;
상기 유닛들의 시퀀스 (sequence) 를 결정하는 단계로서, 상기 시퀀스 내의 상기 유닛들의 각각은 공통의 시간적 지속기간을 갖는, 상기 유닛들의 시퀀스를 결정하는 단계; 및
상기 유닛들의 시퀀스에 대한 상기 공통의 시간적 지속기간 및 상기 시퀀스 내의 상기 비디오 데이터 유닛들의 수를 클라이언트 디바이스에 제공하는 단계로서, 상기 공통의 시간적 지속기간에 대한 제 1 값 및 상기 시퀀스 내의 상기 비디오 데이터 유닛들의 수에 대한 제 2 값을 제공하는 단계를 포함하며, 상기 제 1 값은 상기 유닛들의 전체 시퀀스에 대응하고, 상기 제 2 값은 상기 유닛들의 전체 시퀀스에 대응하는, 상기 제공하는 단계를 포함하는, 인코딩된 비디오 데이터에 대한 정보를 제공하는 방법.
제 1 항에 있어서,
스트리밍 네트워크 프로토콜에 일치시키고 상기 유닛들의 시퀀스의 적어도 일부를 특정하기 위한 상기 클라이언트 디바이스로부터의 요청에 응답하여, 상기 스트리밍 네트워크 프로토콜에 따라 상기 클라이언트 디바이스로 상기 유닛들의 시퀀스의 상기 요청된 일부를 출력하는 단계를 더 포함하는, 인코딩된 비디오 데이터에 대한 정보를 제공하는 방법.
제 1 항에 있어서,
상기 유닛들의 시퀀스의 시작 시간을 결정하는 단계; 및
상기 유닛들의 시퀀스의 상기 시작 시간을 상기 클라이언트 디바이스에 제공하는 단계를 더 포함하는, 인코딩된 비디오 데이터에 대한 정보를 제공하는 방법.
제 1 항에 있어서,
상기 유닛들의 각각은 비디오 세그먼트에 대응하고,
상기 방법은:
상기 클라이언트 디바이스로부터, 상기 시퀀스 내의 상기 비디오 세그먼트들 중의 하나의 URL (uniform resource locator) 을 특정하는 스트리밍 하이퍼텍스트 전송 프로토콜 (HTTP) 요청을 수신하는 단계; 및
상기 요청에 응답하여, 스트리밍 HTTP 에 따라 상기 클라이언트 디바이스로 상기 요청된 비디오 세그먼트를 전송하는 단계를 더 포함하는, 인코딩된 비디오 데이터에 대한 정보를 제공하는 방법.
제 1 항에 있어서,
상기 유닛들의 각각은 비디오 세그먼트에 대응하고,
상기 방법은, 상기 비디오 세그먼트들의 각각에 고유 URL 을 할당하는 단계를 더 포함하는, 인코딩된 비디오 데이터에 대한 정보를 제공하는 방법.
제 1 항에 있어서,
상기 유닛들의 시퀀스를 결정하는 단계는, 복수의 상기 유닛들의 시퀀스들을 결정하는 단계를 포함하고, 상기 복수의 시퀀스들의 각각은 공통의 시간적 지속기간을 갖는 하나 이상의 유닛들을 포함하고, 상기 복수의 시퀀스들은 비디오 파일의 프리젠테이션 내에 연속적으로 배열되며,
상기 제공하는 단계는, 상기 비디오 데이터 유닛들 중 어느 것을 상기 클라이언트 디바이스에 전송하기 전에, 상기 비디오 파일의 특성들로서의 상기 제 1 값 및 상기 제 2 값을 상기 클라이언트 디바이스에 전송하는 단계를 포함하고, 상기 복수의 시퀀스들의 각각에 대해, 제공된 정보는 대응하는 시퀀스에 대한 공통의 시간적 지속기간 및 대응하는 시퀀스 내의 상기 비디오 데이터 유닛들의 수를 나타내는, 인코딩된 비디오 데이터에 대한 정보를 제공하는 방법.
인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치로서,
비디오 데이터의 유닛들을 포함하는 인코딩된 비디오 데이터를 수신하고, 상기 비디오 유닛들의 시퀀스 (sequence) 를 결정하되, 상기 시퀀스 내의 상기 비디오 유닛들의 각각은 공통의 시간적 지속기간을 가지며, 상기 비디오 유닛들의 시퀀스에 대한 상기 공통의 시간적 지속기간 및 상기 시퀀스 내의 상기 비디오 데이터 유닛들의 수를 생성하도록 구성된 프로세서로서, 상기 비디오 유닛들의 시퀀스에 대한 상기 공통의 시간적 지속기간 및 상기 시퀀스 내의 상기 비디오 데이터 유닛들의 수를 생성하기 위해서, 상기 프로세서는 상기 공통의 시간적 지속기간에 대한 제 1 값과 상기 시퀀스 내의 상기 비디오 데이터 유닛들의 수에 대한 제 2 값을 생성하도록 구성되고, 상기 제 1 값은 상기 유닛들의 전체 시퀀스에 대응되고, 상기 제 2 값은 상기 유닛들의 전체 시퀀스에 대응되는, 상기 프로세서; 및
상기 비디오 유닛들의 시퀀스에 대한 상기 공통의 시간적 지속기간 및 상기 시퀀스 내의 상기 비디오 데이터 유닛들의 수를 클라이언트 디바이스에 제공하도록 구성된 네트워크 인터페이스를 포함하는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
제 7 항에 있어서,
스트리밍 네트워크 프로토콜에 일치시키고 상기 비디오 유닛들의 시퀀스의 적어도 일부를 특정하기 위한 상기 클라이언트 디바이스로부터의 요청에 응답하여, 상기 네트워크 인터페이스는 상기 스트리밍 네트워크 프로토콜에 따라 상기 클라이언트 디바이스로 상기 비디오 유닛들의 시퀀스의 상기 요청된 일부를 출력하도록 구성되는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
제 7 항에 있어서,
상기 프로세서는, 상기 비디오 유닛들의 시퀀스의 시작 시간을 결정하고, 상기 비디오 유닛들의 시퀀스의 상기 시작 시간을 생성하도록 구성되고, 상기 네트워크 인터페이스는 상기 비디오 유닛들의 시퀀스의 상기 시작 시간을 상기 클라이언트 디바이스에 제공하도록 구성되는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
제 7 항에 있어서,
상기 비디오 유닛들의 각각은 비디오 세그먼트에 대응하고, 상기 네트워크 인터페이스는, 상기 클라이언트 디바이스로부터, 상기 시퀀스 내의 상기 비디오 세그먼트들 중의 하나의 URL (uniform resource locator) 을 특정하는 스트리밍 하이퍼텍스트 전송 프로토콜 (HTTP) 요청을 수신하고, 상기 요청에 응답하여, 스트리밍 HTTP 에 따라 상기 클라이언트 디바이스로 상기 요청된 비디오 세그먼트를 전송하도록 구성되는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
제 7 항에 있어서,
상기 비디오 유닛들의 각각은 비디오 세그먼트에 대응하고, 상기 네트워크 인터페이스는 상기 비디오 세그먼트들의 각각에 고유 URL 을 할당하도록 구성되는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
제 7 항에 있어서,
상기 프로세서는, 복수의 상기 유닛들의 시퀀스들을 결정하도록 구성되고, 상기 시퀀스들의 각각은 공통의 시간적 지속기간을 갖는 하나 이상의 유닛들을 포함하며, 상기 복수의 시퀀스들은 비디오 파일의 프리젠테이션 내에 연속적으로 배열되고,
상기 프로세서는, 상기 비디오 파일의 상기 비디오 데이터 유닛들 중 어느 것을 상기 클라이언트 디바이스에 전송하기 전에, 상기 비디오 파일의 특성들로서의 상기 제 1 값 및 상기 제 2 값을 상기 클라이언트 디바이스에 전송하도록 구성되고, 상기 복수의 시퀀스들의 각각에 대해, 제공된 정보는 대응하는 시퀀스에 대한 공통의 시간적 지속기간 및 대응하는 시퀀스 내의 상기 비디오 데이터 유닛들의 수를 나타내는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치로서,
비디오 데이터의 유닛들을 포함하는 인코딩된 비디오 데이터를 수신하는 수단;
상기 유닛들의 시퀀스 (sequence) 를 결정하는 수단으로서, 상기 시퀀스 내의 상기 유닛들의 각각은 공통의 시간적 지속기간을 갖는, 상기 유닛들의 시퀀스를 결정하는 수단; 및
상기 유닛들의 시퀀스에 대한 상기 공통의 시간적 지속기간 및 상기 시퀀스 내의 상기 비디오 데이터 유닛들의 수를 클라이언트 디바이스에 제공하는 수단으로서, 상기 제공하는 수단은 상기 공통의 시간적 지속기간에 대한 제 1 값 및 상기 시퀀스 내의 상기 비디오 데이터 유닛들의 수에 대한 제 2 값을 제공하는 수단을 포함하고, 상기 제 1 값은 상기 유닛들의 전체 시퀀스에 대응하고, 상기 제 2 값은 상기 유닛들의 전체 시퀀스에 대응하는, 상기 제공하는 수단을 포함하는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
제 13 항에 있어서,
스트리밍 네트워크 프로토콜에 일치시키고 상기 유닛들의 시퀀스의 적어도 일부를 특정하기 위한 상기 클라이언트 디바이스로부터의 요청을 수신하는 수단; 및
상기 스트리밍 네트워크 프로토콜에 따라 상기 클라이언트 디바이스로 상기 유닛들의 시퀀스의 상기 요청된 일부를 출력하는 수단을 더 포함하는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
제 13 항에 있어서,
상기 유닛들의 시퀀스의 시작 시간을 결정하는 수단; 및
상기 유닛들의 시퀀스의 상기 시작 시간을 상기 클라이언트 디바이스에 제공하는 수단을 더 포함하는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
제 13 항에 있어서,
상기 유닛들의 각각은 비디오 세그먼트에 대응하고,
상기 장치는:
상기 클라이언트 디바이스로부터, 상기 시퀀스 내의 상기 비디오 세그먼트들 중의 하나의 URL (uniform resource locator) 을 특정하는 스트리밍 하이퍼텍스트 전송 프로토콜 (HTTP) 요청을 수신하는 수단; 및
상기 요청에 응답하여, 스트리밍 HTTP 에 따라 상기 클라이언트 디바이스로 상기 요청된 비디오 세그먼트를 전송하는 수단을 더 포함하는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
제 13 항에 있어서,
상기 유닛들의 각각은 비디오 세그먼트에 대응하고,
상기 장치는, 상기 비디오 세그먼트들의 각각에 고유 URL 을 할당하는 수단을 더 포함하는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
제 13 항에 있어서,
상기 유닛들의 시퀀스를 결정하는 수단은, 복수의 상기 유닛들의 시퀀스를 결정하는 수단을 포함하고, 상기 복수의 시퀀스들의 각각은 공통의 시간적 지속기간을 갖는 하나 이상의 유닛들을 포함하고, 상기 복수의 시퀀스들은 비디오 파일의 프리젠테이션 내에 연속적으로 배열되며,
상기 클라이언트 디바이스에 제공하는 수단은, 상기 비디오 파일의 상기 비디오 데이터 유닛들 중 어느 것을 상기 클라이언트 디바이스에 전송하기 전에, 상기 비디오 파일의 특성들로서의 상기 제 1 값 및 상기 제 2 값을 상기 클라이언트 디바이스에 전송하는 수단을 포함하고, 상기 복수의 시퀀스들의 각각에 대해, 제공된 정보는 대응하는 시퀀스에 대한 공통의 시간적 지속기간 및 대응하는 시퀀스 내의 상기 비디오 데이터 유닛들의 수를 나타내는, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 장치.
명령들을 저장한 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품으로서,
상기 명령들은, 실행 시에, 인코딩된 비디오 데이터에 대한 정보를 제공하기 위한 디바이스의 프로세서로 하여금,
비디오 데이터의 유닛들을 포함하는 인코딩된 비디오 데이터를 수신하고;
상기 유닛들의 시퀀스 (sequence) 를 결정하되, 상기 시퀀스 내의 상기 유닛들의 각각은 공통의 시간적 지속기간을 가지며;
상기 유닛들의 시퀀스에 대한 상기 공통의 시간적 지속기간 및 상기 시퀀스 내의 상기 비디오 데이터 유닛들의 수를 클라이언트 디바이스에 제공하도록 하고,
상기 프로세서로 하여금 클라이언트 디바이스에 제공하도록 하는 명령들은, 상기 프로세서로 하여금 상기 공통의 시간적 지속기간에 대한 제 1 값 및 상기 시퀀스 내의 상기 비디오 데이터 유닛들의 수에 대한 제 2 값을 제공하도록 하는 명령들을 포함하고, 상기 제 1 값은 상기 유닛들의 전체 시퀀스에 대응하고, 상기 제 2 값은 상기 유닛들의 전체 시퀀스에 대응하는, 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품.
제 19 항에 있어서,
상기 프로세서로 하여금, 스트리밍 네트워크 프로토콜에 일치시키고 상기 유닛들의 시퀀스의 적어도 일부를 특정하기 위한 상기 클라이언트 디바이스로부터의 요청에 응답하여, 상기 스트리밍 네트워크 프로토콜에 따라 상기 클라이언트 디바이스로 상기 유닛들의 시퀀스의 상기 요청된 일부를 출력하도록 하는 명령들을 더 포함하는, 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품.
제 19 항에 있어서,
상기 프로세서로 하여금,
상기 유닛들의 시퀀스의 시작 시간을 결정하고;
상기 유닛들의 시퀀스의 상기 시작 시간을 상기 클라이언트 디바이스에 제공하도록 하는 명령들을 더 포함하는, 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품.
제 19 항에 있어서,
상기 유닛들의 각각은 비디오 세그먼트에 대응하고,
컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품은,
상기 프로세서로 하여금,
상기 클라이언트 디바이스로부터, 상기 시퀀스 내의 상기 비디오 세그먼트들 중의 하나의 URL (uniform resource locator) 을 특정하는 스트리밍 하이퍼텍스트 전송 프로토콜 (HTTP) 요청을 수신하고;
상기 요청에 응답하여, 스트리밍 HTTP 에 따라 상기 클라이언트 디바이스로 상기 요청된 비디오 세그먼트를 전송하도록 하는 명령들을 더 포함하는, 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품.
제 19 항에 있어서,
상기 유닛들의 각각은 비디오 세그먼트에 대응하고,
컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품은,
상기 프로세서로 하여금, 상기 비디오 세그먼트들의 각각에 고유 URL 을 할당하도록 하는 명령들을 더 포함하는, 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품.
제 19 항에 있어서,
상기 프로세서로 하여금 상기 유닛들의 시퀀스들을 결정하도록 하는 명령들은, 상기 프로세서로 하여금 복수의 상기 유닛들의 시퀀스를 결정하도록 하는 명령들을 포함하고, 상기 복수의 시퀀스들의 각각은 공통의 시간적 지속기간을 갖는 하나 이상의 유닛들을 포함하고, 상기 복수의 시퀀스들은 비디오 파일의 프리젠테이션 내에 연속적으로 배열되며,
상기 프로세서로 하여금 클라이언트 디바이스에 제공하도록 하는 명령들은, 상기 비디오 파일의 상기 비디오 데이터 유닛들 중 어느 것을 상기 클라이언트 디바이스에 전송하기 전에, 상기 비디오 파일의 특성들로서의 상기 제 1 값 및 상기 제 2 값을 상기 클라이언트 디바이스에 전송하도록 하는 명령들을 포함하고, 상기 복수의 시퀀스들의 각각에 대해, 제공된 정보는 대응하는 시퀀스에 대한 공통의 시간적 지속기간 및 대응하는 시퀀스 내의 상기 비디오 데이터 유닛들의 수를 나타내는, 컴퓨터 판독가능 저장 매체를 포함하는 컴퓨터 프로그램 제품.
인코딩된 비디오 데이터를 수신하는 방법으로서,
상기 인코딩된 비디오 데이터의 유닛들의 시퀀스에서의 유닛들에 대한 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수를 수신하는 단계로서, 상기 공통의 시간적 지속기간에 대한 제 1 값 및 상기 시퀀스에서의 상기 유닛들의 수에 대한 제 2 값을 수신하는 단계를 포함하고, 상기 제 1 값은 상기 유닛들의 전체 시퀀스에 대응하고, 상기 제 2 값은 상기 유닛들의 전체 시퀀스에 대응하는, 상기 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수를 수신하는 단계;
재생을 시작할 상기 인코딩된 비디오 데이터의 시간적 로케이션 (location) 의 표시를 수신하는 단계로서, 상기 시간적 로케이션은 상기 유닛들의 시퀀스 내에 있는, 상기 재생을 시작할 상기 인코딩된 비디오 데이터의 시간적 로케이션의 표시를 수신하는 단계; 및
네트워크 스트리밍 프로토콜에 따라, 상기 시간적 로케이션을 포함하는 상기 시퀀스에서의 상기 유닛들 중의 하나에서 네트워크 스트림을 시작하기 위한 요청을 자동적으로 생성하는 단계를 포함하는, 인코딩된 비디오 데이터를 수신하는 방법.
제 25 항에 있어서,
상기 수신하는 단계는, 서버 디바이스로부터 수신하는 단계를 포함하고,
상기 방법은, 상기 요청을 상기 서버 디바이스로 전송하는 단계를 더 포함하는, 인코딩된 비디오 데이터를 수신하는 방법.
제 25 항에 있어서,
상기 요청을 자동적으로 생성하는 단계는, 상기 유닛들 중의 상기 하나를 포함하는 비디오 파일에 대한 식별자를 자동적으로 생성하는 단계를 포함하고,
상기 방법은,
상기 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수에 적어도 부분적으로 기초하여, 상기 유닛들 중의 상기 하나에 대한 시작 시간을 결정하는 단계;
상기 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수에 기초하여, 상기 유닛들 중의 상기 하나에 대한 종료 시간을 결정하는 단계; 및
상기 식별자에서 상기 시작 시간 및 상기 종료 시간을 특정하는 단계를 포함하는, 인코딩된 비디오 데이터를 수신하는 방법.
제 27 항에 있어서,
상기 공통의 시간적 지속기간 및 상기 시퀀스 내의 상기 유닛들 중의 상기 하나의 수에 적어도 부분적으로 기초하여 상기 유닛들 중의 상기 하나에 대한 시작 시간을 결정하는 단계를 더 포함하는, 인코딩된 비디오 데이터를 수신하는 방법.
제 27 항에 있어서,
상기 비디오 파일에 대한 상기 식별자는 상기 비디오 파일에 대한 URL (uniform resource locator) 을 포함하는, 인코딩된 비디오 데이터를 수신하는 방법.
제 27 항에 있어서,
상기 인코딩된 비디오 데이터의 상기 유닛들은 비디오 세그먼트들을 포함하고, 상기 유닛들 중의 상기 하나는 상기 비디오 세그먼트들 중의 하나를 포함하며, 상기 비디오 파일은 상기 비디오 세그먼트들 중의 상기 하나를 포함하고, 상기 비디오 파일에 대한 상기 식별자는 상기 비디오 파일에 대한 URL 을 포함하고, 상기 요청을 자동적으로 생성하는 단계는 상기 비디오 파일 내의 상기 비디오 세그먼트들 중의 상기 하나의 바이트 범위를 특정하는 단계를 더 포함하는, 인코딩된 비디오 데이터를 수신하는 방법.
인코딩된 비디오 데이터를 수신하기 위한 장치로서,
네트워크 인터페이스; 및
상기 네트워크 인터페이스를 통해, 상기 인코딩된 비디오 데이터의 유닛들의 시퀀스에 대한 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수를 수신하되, 상기 공통의 시간적 지속기간에 대한 제 1 값 및 상기 시퀀스에서의 상기 유닛들의 수에 대한 제 2 값을 수신하도록 구성되고, 상기 제 1 값은 상기 유닛들의 전체 시퀀스에 대응하고, 상기 제 2 값은 상기 유닛들의 전체 시퀀스에 대응하고,
재생을 시작할 상기 인코딩된 비디오 데이터의 시간적 로케이션 (location) 의 표시를 수신하되, 상기 시간적 로케이션은 상기 유닛들의 시퀀스 내에 있고,
네트워크 스트리밍 프로토콜에 따라, 상기 시간적 로케이션을 포함하는 상기 시퀀스에서의 상기 유닛들 중의 하나에서 네트워크 스트림을 시작하기 위한 요청을 자동적으로 생성하도록 구성된 프로세서를 포함하는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
제 31 항에 있어서,
상기 네트워크 인터페이스는, 서버 디바이스로부터 수신하고, 상기 요청을 상기 서버 디바이스로 전송하도록 구성되는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
제 31 항에 있어서,
상기 요청을 자동적으로 생성하기 위해, 상기 프로세서는, 상기 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수에 기초하여, 상기 유닛들 중의 상기 하나에 대한 시작 시간을 결정하고, 상기 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수에 기초하여, 상기 유닛들 중의 상기 하나에 대한 종료 시간을 결정하며, 상기 유닛들 중의 상기 하나를 포함하는 비디오 파일에 대한 식별자를 자동적으로 생성하고, 상기 식별자에서 상기 시작 시간 및 상기 종료 시간을 특정하도록 구성되는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
제 33 항에 있어서,
상기 프로세서는, 상기 공통의 시간적 지속기간 및 상기 시퀀스 내의 상기 유닛들 중의 상기 하나의 수에 적어도 부분적으로 기초하여 상기 유닛들 중의 상기 하나에 대한 시작 시간을 결정하도록 구성되는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
제 33 항에 있어서,
상기 비디오 파일에 대한 상기 식별자는 상기 비디오 파일에 대한 URL (uniform resource locator) 을 포함하는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
제 33 항에 있어서,
상기 인코딩된 비디오 데이터의 상기 유닛들은 비디오 세그먼트들을 포함하고, 상기 유닛들 중의 상기 하나는 상기 비디오 세그먼트들 중의 하나를 포함하며, 상기 비디오 파일은 상기 비디오 세그먼트들 중의 상기 하나를 포함하고, 상기 비디오 파일에 대한 상기 식별자는 상기 비디오 파일에 대한 URL 을 포함하고, 상기 요청을 자동적으로 생성하기 위해 상기 프로세서는 상기 비디오 파일 내의 상기 비디오 세그먼트들 중의 상기 하나의 바이트 범위를 특정하도록 구성되는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
인코딩된 비디오 데이터를 수신하기 위한 장치로서,
상기 인코딩된 비디오 데이터의 유닛들의 시퀀스에 대한 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수를 수신하는 수단으로서, 상기 수신하는 수단은 상기 공통의 시간적 지속기간에 대한 제 1 값 및 상기 시퀀스에서의 상기 유닛들의 수에 대한 제 2 값을 수신하는 수단을 포함하고, 상기 제 1 값은 상기 유닛들의 전체 시퀀스에 대응하고, 상기 제 2 값은 상기 유닛들의 전체 시퀀스에 대응하는, 상기 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수를 수신하는 수단;
재생을 시작할 상기 인코딩된 비디오 데이터의 시간적 로케이션 (location) 의 표시를 수신하는 수단으로서, 상기 시간적 로케이션은 상기 유닛들의 시퀀스 내에 있는, 상기 재생을 시작할 상기 인코딩된 비디오 데이터의 시간적 로케이션의 표시를 수신하는 수단; 및
네트워크 스트리밍 프로토콜에 따라, 상기 시간적 로케이션을 포함하는 상기 시퀀스에서의 상기 유닛들 중의 하나에서 네트워크 스트림을 시작하기 위한 요청을 자동적으로 생성하는 수단을 포함하는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
제 37 항에 있어서,
상기 수신하는 수단은, 서버 디바이스로부터 수신하는 수단을 포함하고,
상기 장치는, 상기 요청을 상기 서버 디바이스로 전송하는 수단을 더 포함하는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
제 37 항에 있어서,
상기 요청을 자동적으로 생성하는 수단은, 상기 유닛들 중의 상기 하나를 포함하는 비디오 파일에 대한 식별자를 자동적으로 생성하는 수단을 포함하고,
상기 장치는:
상기 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수에 기초하여, 상기 유닛들 중의 상기 하나에 대한 시작 시간을 결정하는 수단;
상기 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수에 기초하여, 상기 유닛들 중의 상기 하나에 대한 종료 시간을 결정하는 수단; 및
상기 식별자에서 상기 시작 시간 및 상기 종료 시간을 특정하는 수단을 더 포함하는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
제 39 항에 있어서,
상기 공통의 시간적 지속기간 및 상기 시퀀스 내의 상기 유닛들 중의 상기 하나의 수에 적어도 부분적으로 기초하여 상기 유닛들 중의 상기 하나에 대한 시작 시간을 결정하는 수단을 더 포함하는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
제 39 항에 있어서,
상기 비디오 파일에 대한 상기 식별자는 상기 비디오 파일에 대한 URL (uniform resource locator) 을 포함하는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
제 39 항에 있어서,
상기 인코딩된 비디오 데이터의 상기 유닛들은 비디오 세그먼트들을 포함하고, 상기 유닛들 중의 상기 하나는 상기 비디오 세그먼트들 중의 하나를 포함하며, 상기 비디오 파일은 상기 비디오 세그먼트들 중의 상기 하나를 포함하고, 상기 비디오 파일에 대한 상기 식별자는 상기 비디오 파일에 대한 URL 을 포함하고, 상기 요청을 자동적으로 생성하는 수단은 상기 비디오 파일 내의 상기 비디오 세그먼트들 중의 상기 하나의 바이트 범위를 특정하는 수단을 더 포함하는, 인코딩된 비디오 데이터를 수신하기 위한 장치.
명령들을 저장한 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품으로서,
상기 명령들은, 실행 시에, 인코딩된 비디오 데이터를 수신하기 위한 디바이스의 프로세서로 하여금,
상기 인코딩된 비디오 데이터의 유닛들의 시퀀스에 대한 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수를 수신하고;
재생을 시작할 상기 인코딩된 비디오 데이터의 시간적 로케이션 (location) 의 표시를 수신하되, 상기 시간적 로케이션은 상기 유닛들의 시퀀스 내에 있는, 상기 재생을 시작할 상기 인코딩된 비디오 데이터의 시간적 로케이션의 표시를 수신하며;
네트워크 스트리밍 프로토콜에 따라, 상기 시간적 로케이션을 포함하는 상기 시퀀스에서의 상기 유닛들 중의 하나에서 네트워크 스트림을 시작하기 위한 요청을 자동적으로 생성하도록 하고,
상기 명령들은 상기 프로세서로 하여금 상기 공통의 시간적 지속기간에 대한 제 1 값 및 상기 시퀀스에서의 상기 유닛들의 수에 대한 제 2 값을 수신하도록 하며, 상기 제 1 값은 상기 유닛들의 전체 시퀀스에 대응하고, 상기 제 2 값은 상기 유닛들의 전체 시퀀스에 대응하는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.
제 43 항에 있어서,
상기 프로세서로 하여금 수신하도록 하는 상기 명령들은, 상기 프로세서로 하여금 서버 디바이스로부터 수신하도록 하는 명령들을 포함하고,
컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품은, 상기 프로세서로 하여금 상기 요청을 상기 서버 디바이스로 전송하도록 하는 명령들을 더 포함하는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.
제 43 항에 있어서,
상기 프로세서로 하여금 상기 요청을 자동적으로 생성하도록 하는 상기 명령들은, 상기 프로세서로 하여금 상기 유닛들 중의 상기 하나를 포함하는 비디오 파일에 대한 식별자를 자동적으로 생성하도록 하는 명령들을 포함하고,
상기 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품은,
상기 프로세서로 하여금,
상기 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수에 기초하여, 상기 유닛들 중의 상기 하나에 대한 시작 시간을 결정하고;
상기 공통의 시간적 지속기간 및 상기 시퀀스에서의 상기 유닛들의 수에 기초하여, 상기 유닛들 중의 상기 하나에 대한 종료 시간을 결정하며;
상기 유닛들 중의 상기 하나를 취출하기 위해 상기 식별자에서 상기 시작 시간 및 상기 종료 시간을 특정하도록 하는 명령들을 포함하는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.
제 45 항에 있어서,
상기 프로세서로 하여금, 상기 공통의 시간적 지속기간 및 상기 시퀀스 내의 상기 유닛들 중의 상기 하나의 수에 적어도 부분적으로 기초하여 상기 유닛들 중의 상기 하나에 대한 시작 시간을 결정하도록 하는 명령들을 더 포함하는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.
제 45 항에 있어서,
상기 비디오 파일에 대한 상기 식별자는 상기 비디오 파일에 대한 URL (uniform resource locator) 을 포함하는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.
제 45 항에 있어서,
상기 인코딩된 비디오 데이터의 상기 유닛들은 비디오 세그먼트들을 포함하고, 상기 유닛들 중의 상기 하나는 상기 비디오 세그먼트들 중의 하나를 포함하며, 상기 비디오 파일에 대한 상기 식별자는 상기 비디오 세그먼트들 중의 상기 하나를 포함하고, 상기 비디오 파일은 상기 비디오 파일에 대한 URL 을 포함하고, 상기 프로세서로 하여금 상기 요청을 자동적으로 생성하도록 하는 상기 명령들은, 상기 비디오 파일 내의 상기 비디오 세그먼트들 중의 상기 하나의 바이트 범위를 특정하도록 하는 명령들을 더 포함하는, 컴퓨터 판독가능 매체를 포함하는 컴퓨터 프로그램 제품.