KR101476938B1

KR101476938B1 - 미디어 컨텐츠의 선택적 수신

Info

Publication number: KR101476938B1
Application number: KR1020137007647A
Authority: KR
Inventors: 조지 칼세브; 케빈 엘. 바움; 주니어 베네디토 제이. 폰세카
Original assignee: 모토로라 모빌리티 엘엘씨
Priority date: 2010-09-27
Filing date: 2011-08-26
Publication date: 2014-12-24
Also published as: KR20130051483A; CN103155514A; BR112013007282A2; WO2012047403A1; US20120079000A1; EP2622815A1

Abstract

크기 정보를 미디어 프리젠테이션(media presentation)의 각각의 청크(chunk)와 연관시키는 방법이 개시되어 있다. 크기 정보는 엔드-유저(end-user) 장치(110)로 송신된다(700). 단순히 청크에 바이트 수를 부여하는 것을 넘어 청크의 크기를 특징지을 수 있는 많은 방법이 있다. 몇몇의 실시예에서 크기의 근사치 혹은 상대적 크기를 송신한다. 몇몇의 실시예에서, 서버(104)는 미디어 프리젠테이션에 대한 "기준" 값을 발행하고 그 다음, 기준 값에 상대적인 크기를 각각의 청크에 대해 부여한다. 장치(110)는 청크를 다운로드할지 여부를 결정한다(702). 장치(110)는 그 다음 청크가 시간에 맞추어 다운로드될 수 없을 것 같다는 결정을 할 수 있다. 그러면, 비디오 정지(video freeze)의 가능성을 피하기 위해 장치(110)는 다음 청크를 낮은 해상도로 요청할 수 있다(704). 몇몇의 실시예에서, 장치(110)는 완전히 다른 청크를 요청하기로 혹은 어떤 청크도 전혀 요청하지 않기로 결정한다(704).

Description

미디어 컨텐츠의 선택적 수신{SELECTIVELY RECEIVING MEDIA CONTENT}

본 출원은 모토로라 미합중국출원 제12/891,348호(CML07579)와 관련된 것이다.

본 발명은 일반적으로 데이터 전달(data-delivery) 시스템, 좀 더 구체적으로, 미디어 프리젠테이션을 송신 또는 수신하는 시스템에 관한 것이다.

점점 더 많은 사용자들이 점점 더 많은 미디어 프리젠테이션을 점점 더 많은 장치들에 다운로드하고 있다. (여기에서, "미디어 프리젠테이션"은 일반적으로 거의 모든 종류의 디지털 컨텐츠, 그리고 더 구체적으로, 소리, 비디오 및 인터액티브 파일(interactive files)을 포함한다.) 이러한 미디어 프리젠테이션들은 종종 거대해서, 그것들을 다운로드하는 것은 막대한 양의 가용 대역폭 및 사용자 장치의 배터리 파워를 소모한다.

다운로드 요청을 관리하기 위하여, 다운로드 서버는 종종 큰 미디어 프리젠테이션을 연속되는 "청크들(chunks)"로 나누는데, 여기서 그 각각의 청크는, 예를 들어 수 초의 비디오를 나타내는 것이다. 사용자가 미디어 프리젠테이션을 소비하고 싶을 때, 그의 장치는 다운로드 서버로부터 프리젠테이션을 위한 "재생목록 (playlist)"을 요청함으로써 시작한다. (여기에서, "소비하다(consume)"는 임의의 유형의 미디어와 인간과의 상호작용을 나타내는 일반적인 용어로서 의도되었음을 주의해야 한다. 그것은 텔레비전을 보고, 라디오를 듣고, 컴퓨터 게임을 하고, 전화기로 말하거나 문자를 보내는 것, 웹사이트와 상호 작용하는 것 등을 포함할 수 있다. 본 논의를 간소화하기 위해, 비록 미디어 소비자가 선택한 미디어가 시각적 비중을 가지지 않을 때에도 미디어 소비자는 일반적으로 "사용자" 또는 "시청자"로 불린다.) 상기 재생목록은 (대체 가능한 해상도들을 비롯하여) 프리젠테이션이 해당 서버상에서 세그먼트된(segmented) 것인 청크들의 기술목록(a list of descriptions)을 포함한다. 재생목록을 입수한 사용자의 장치는 서버에게 프리젠테이션의 첫 번째 청크를 다운로드할 것을 요청한다. 사용자가 첫 번째 청크를 보고 있는 동안, 그의 장치는 프리젠테이션의 다음 청크들을 요청함으로써 사용자가 보는 것에 "앞서 나가기"를 (그리고 그에 따라 "비디오 정지(video freeze)"를 피하는 것을) 시도한다. 그 다음 청크들이 여전히 전달되는 동안에도 사용자들이 계속하여 미디어 프리젠테이션을 볼 수 있도록 상기 청크들이 사용자 장치에 수신되고 버퍼링된다.

그러나, 사용자들이 미디어 프리젠테이션을 요청하고, 그것을 보기 시작하면, 그 다음 전체 파일은 보지 않기로 결심하는 것도 흔히 있는 일이다. 시청되지 않을 청크가 송신되는 것이므로 이는 대역폭 및 사용자 장치의 배터리 파워를 낭비한다. 또한, 사용자는 흥미로운 장면을 찾으면서 미디어 프리젠테이션의 부분들을 빨리감기(fast-forward)(또는 스킵(skip))를 할 수도 있다. (예를 들어, 사용자는 흥미로운 골을 찾기 위해 축구 경기의 많은 부분을 빨리감기 할 수 있다.) 훨씬 더 낮은 해상도로 사용자에게 빨리감기 부분을 보여주는 것이 전적으로 허락된 상황에서도 프리젠테이션이 흔히 (달리 명시된 바 없으면) 최대의 가능한 해상도로 다운로드되기 때문에, 이와 같은 빨리감기는 또한 대역폭을 낭비할 수 있다. (물론, 낮은 해상도로 미디어 프리젠테이션을 다운로드하는 것은 같은 프리젠테이션을 더 높은 해상도로 다운로드하는 것에 비해 막대한 대역폭과 배터리 파워를 절약한다.)

전술한 고려사항 및 그 밖의 것들 등이 본 발명에 의해 다루어지고, 본 발명은 명세서, 도면 및 청구항을 참고함으로써 이해될 수 있다. 본 발명의 태양들에 따르면 크기 정보가 미디어 프리젠테이션의 각각의 청크와 연관된다. 미디어 프리젠테이션을 다운로드할 때, 크기 정보가 엔드-유저(end-user) 장치로 송신되는데, 이 엔드-유저 장치는 이 크기 정보를 이용해 더욱더 지능적으로 자원을 관리한다.

단순히 청크의 바이트 수를 부여하는 것을 넘어 청크의 크기를 특징짓는 다수의 방법이 있다. 대역폭을 절약하기 위해, 몇몇의 실시예는 청크의 실제 크기를 송신하기보다 크기의 근사치 혹은 상대적인 크기를 송신한다. 몇몇의 실시예에서, 서버는 미디어 프리젠테이션을 위해 (주어진 해상도에서) "기준" 값(예를 들어, 최대 비트 레이트(bit rate))을 발행하고, 각각의 청크에 대하여 기준 값에 대한 크기(혹은 백분율)를 제공한다.

엔드-유저 장치는 서버에 의해 다운로드되는 재생목록의 일부분으로서 크기 정보를 수신할 수 있고, 또는 주어진 청크의 크기가 이전에 다운로드된 청크와 함께 포함될 수 있다. 크기 정보는 또한 제3자 서버에 의해 제공될 수 있다. 몇몇의 실시예에서, 엔드-유저 장치는 그 다음 청크에 대한, 또는 주어진 해상도에서 미디어 프리젠테이션의 다양한 청크에 대한, 또는 다양한 해상도에서 다양한 청크에 대한 크기 정보를 서버에 요청한다.

재생목록을 입수하면, 엔드-유저 장치는 청크를 다운로드할지 여부를 결정한다. 예를 들어, 엔드-유저 장치가 장치 네트워크 링크 성능을 계속하여 분석할 수 있다. 상기 분석을 기초로, 엔드-유저 장치는 그 다음 청크를 다운로드하는데 시간이 얼마나 걸려야만 하는지를 해당 청크의 크기를 바탕으로 예측한다. 엔드-유저 장치는 그 다음 청크가 시간에 맞춰 다운로드될 수 없을 것 같다는 것을 결정할 수 있다. 그러면, 비디오 정지의 가능성을 피하기 위해, 엔드-유저 장치는 낮은 해상도를 가진(즉, 더 작은 청크 크기를 가지는) 그 다음 청크를 요청할 수 있다. 몇몇의 경우에 있어, 엔드-유저 장치는 완전히 다른 청크를 요청하거나 어떠한 청크도 요청하지 않기로 결정한다.

몇몇의 실시예에서, 엔드-유저 장치는 청크의 크기뿐 아니라 청크의 "중요성"에 그 결정의 근거를 둔다.

청크 크기 정보를 사용함으로써 엔드-유저 장치가 비디오 정지 가능성을 일부의 상황에서 상당히 감소시킬 수 있음이 실험에 의해 입증된 바 있다.

첨부된 청구항은 본 발명의 특징을 기재한 것인데, 본 발명은 그 목적 및 장점과 함께 첨부된 도면과 결부하여 서술된 다음의 상세한 설명으로부터 가장 잘 이해되어 질 수 있다.
도 1은 본 발명이 실시될 수 있는 대표적 환경의 개요도.
도 2는 도 1에서 도시된 장치들 중 일부를 일반화시켜 도시한 개략도.
도 3a 및 도 3b는, 엔드-유저 장치가 중요성 정보를 사용하는 (그리고, 일부 실시예에서는, 모으는) 방법을 종합하여 나타내는 흐름도.
도 4a 및 도 4b는, 서버가 미디어 컨텐츠 및 중요성 정보를 제공하는 방법을 종합하여 나타내는 흐름도.
도 5는 엣지 서버가 지능적인 캐싱(intelligent caching)을 위해 중요성 정보를 사용하는 방법의 흐름도.
도 6은 주어진 해상도에서 미디어 프리젠테이션의 청크 크기의 다양성을 도시하는 도면.
도 7은 청크 크기 정보를 사용하기 위한 방법의 흐름도.
도 8a 및 도 8b는 청크 크기 정보의 지능적 사용이 비디오 정지를 얼마나 감소시킬 수 있는지를 보여주는 그래프.

상기 도면에서, 유사한 참조 숫자는 유사한 요소들을 나타내는 것이며, 본 발명은 적합한 환경에서 구현된 경우에 따라 도시되었다. 다음 서술은 본 발명의 실시예에 근거하며, 여기에 명시적으로 서술되지 않은 대체 가능한 실시예와 관련하여 발명을 제한하는 것으로 여겨져서는 안 된다.

본 발명의 태양들은 도 1의 대표적인 통신 환경(100)에서 실시될 수 있다. 다운로드 서버(104), 제3자 서버(106), 엣지 서버(edge server; 108)와 같은 서버들은 다양한 알려진 네트워킹 기술들(102)의 일부 혹은 전부를 이용해 함께 연결되어 있다. (서버 유형의 각각의 기능들은 아래에 서술되어 있다.) 도시의 편의성을 위해, 서버(104, 106, 108) 각각의 유형 중 오직 하나만이 도시되었으나, 아래에 서술된 바와 같이, 각각의 복수가 존재할 수 있고 함께 작동할 수도 있다.

서버(104, 106, 108)는 네트워킹 기술(102)을 통하여, 미디어 다운로드 및 관련 서비스들을 엔드-유저 장치에게 제공한다. 엔드-유저 장치의 하나의 예는 휴대전화(110)이다. 휴대전화(110)는 공중 전화 교환망(public switched telephone network), 인터넷 또는 다른 네트워크에 액세스함으로써 서버들(104, 106, 108)에 의해 제공되는 서비스에 액세스하기 위해 (도시되지 않았으나 공지 기술로 알려진) 무선 기지국과 무선으로 통신한다.

비-무선 엔드-유저 장치들은 "유선" 네트워크 기술들(112)(예를 들어, 섬유(fiber), 전선 및 케이블)에 의해 지원된다. 예를 들어, 셋탑 박스(114)는 일반적으로 텔레비전 프로그램을 수신하고, 케이블 공급자로부터의 컨텐츠를 선택하고 볼 수 있기 위한 사용자 인터페이스(예를 들어, 상호 작용 프로그램 가이드)를 제공한다. (도시되지 않은) 디지털 비디오 녹화기는 다음에 보기 위한 프로그램 설정을 저장할 수 있다. 비디오 컨텐츠는 텔레비전 모니터(116)에서 보여질 수도 있다. 몇몇의 경우에 있어, 휴대용 컴퓨터(118)는 무선으로 혹은 유선 네트워크(112)를 통하여 웹 기반 서비스에 액세스한다. (도시되지 않은) 홈 게이트웨이, 키오스크(kiosk), 디지털 사인 또는 미디어 리스트리밍(media-restreaming) 장치가 다른 가능한 엔드-유저 장치들이 될 수 있다.

(미디어 리스트리밍 장치는 이종 네트워크 사이에 컨텐츠를 전송한다. 예를 들어, 이 장치는 케이블 시스템(112)으로부터 컨텐츠를 수신하고 그 다음 컨텐츠를 WiFi와 같은 근거리 무선 링크를 통해 휴대전화(110)에 전송한다. 미디어 리스트리밍 장치는 보통 네트워크들 사이에 메시지를 전달하기 위해 양방향으로 작동한다. 몇몇의 실시예에서, 본 발명의 태양들은 미디어 리스트리밍 장치에 의해 실시될 수 있다.)

무선 그리고 유선 네트워크 기술은 일반적으로 양방향 트래픽을 지원한다: 미디어 컨텐츠와 관련된 정보는 엔드-유저 장치(110, 114, 116, 118)에 전달되고, 다운로드 요청은 서버들(104, 106, 108)에게 "상향" 전송된다.

도 2는 대표적인 서버(104, 106, 108) 또는 엔드-유저 장치(110, 114, 118)의 주요한 구성요소를 도시한다. 네트워크 인터페이스(200)는 미디어 프리젠테이션, 관련된 정보 및 다운로드 요청들을 송수신한다. 프로세서(202)는 장치의 작동을 제어하며, 특히, 아래에서 서술된 도 3에서 도 5에 걸쳐 도시된 바와 같은 본 발명의 태양들을 지원한다. 사용자 인터페이스(204)는 사용자와 (또는 관리자와) 장치의 상호작용을 지원한다. 구체적인 장치에 의한 이러한 요소들의 구체적인 용도는 아래에 적절히 서술된다.

도 3a 및 3b의 방법은 도 1의 휴대전화(110)와 같은 엔드-유저 장치에 구현된 본 발명의 태양들을 도시한다. 이러한 도면의 방법은 휴대전화(110)에 제한되지 않고, 적절히 임의의 구현을 수정하면 모든 엔드-유저 장치들에 적용 가능하다.

(모든 흐름도들은 주로 다음 논의를 지지하기 위하여 의도되었음을 주목하여야 한다. 흐름도에서 "단계들"은 몇몇의 구현 및 몇몇의 상황에서 선택적이며 수행된다 하더라도 다른 순서에 의해 수행될 수도 있다.)

도 3a의 단계(300)에서, 엔드-유저 장치(110)는 미디어 프리젠테이션의 청크에 대한 "중요성" 정보를 수신한다. 많은 유형의 정보가 포괄적 용어인 "중요성(importance)" 하에 수집된다. 중요성 정보의 첫 번째 종류는 주어진 청크가 어느 정도까지 볼 가치가 있는지 여부를 나타낸다. 예를 들어, 편집자가 축구 경기 비디오를 검토하고, 편집자 생각에 다른 부분에 비하여 더 흥미로운 경기의 부분에 태그를 달 수 있다. 시간에 쫓긴 시청자들은 경기 전체를 보기 원하지 않을 수도 있으나 오직 중요하다고 태그된 청크들만을 보는 것에 관심이 있을 수도 있다.

얼마나 많은 사람들이 실제로 미디어 프리젠테이션의 어떤 부분을 보는지에 대한 통계를 모을 수 있다. 예를 들어, 만약에 많은 퍼센트의 사용자들이 첫 몇 초 이후 뮤직 비디오의 청크들을 요청하기를 멈춘다면, 적어도 뮤직 비디오의 나머지(그리고 어쩌면 전체)가 "중요하지 않은"이라 태그되어야 할 것이라고 추론될 수 있다. 물론, 다른 태그들은 중요성 태그가 의미하는 바를 아주 상세히 정확하게 명시할 수 있다. 이러한 시나리오에서, 태그는 시청자의 인구 통계를 제공할 수 있고, 임의의 통계학적 집단으로부터의 시청자가 그 청크에 관심이 있어 할지 및 그 청크를 볼 것인지와 같은 예측된 또는 조건부의 확률이 각각의 청크에 태그될 수 있다.

"중요성"은 넓게 정의되도록 의도되었고 (단계(308)에서, 이하 논의된) 이 청크를 다운로드할지 여부를 결정하기 위해 또는 (도 3b의 단계(312)부터 단계(316)까지, 이하 논의된) 청크를 어떻게 다루거나 렌더링할지를(render) 결정하기 위해, 엔드-유저 장치(110)가 사용할 수 있는 임의의 정보를 거의 다 포함할 수 있다. 따라서, "중요성"의 또 다른 유형은 평가 정보이다: 청크는 잠재적으로 공격적인 컨텐츠의 다양한 유형에 대해 태그될 수 있다.

중요성 정보의 다른 유형들이 가능하며 고려될 수 있다. (특히, 단계(302)부터 단계(306)까지 수반하는 본 논의 참조.)

비록 본 논의에서, "중요성" 정보가 보통 주어진 청크와 관련된다 할지라도, 그것은 항상 절대적으로 참일 필요가 없다는 것을 주의해야 한다. 청크는 10초간의 비디오를 포함할 수도 있고, 평가 태그는 청크 내에 오직 몇 초에만 적용될 수도 있다. 태그는 유저에게 중요성 정보의 정확한 범위를 알릴 수 있다.

엔드-유저 장치(110)는 수많은 소스들로부터 중요성 정보를 수신할 수 있다. 하나의 실시예에서, 엔드-유저 장치(110)는 다운로드 서버(104)로부터 "재생목록"을 수신한다. (재생목록은 또한 "적하목록(manifest)" 또는 "미디어-프리젠테이션 설명(media-presentation description)"이라 불릴 수도 있다.) 재생목록은 미디어 프리젠테이션에 대한 (청크의 수, 각 청크의 재생 지속 시간(playing time duration), 지원되는 해상도 등과 같은) 정보를 포함한다. 재생목록은 중요성 정보를 포함할 수 있으며 또는 중요성 정보를 위한 다른 소스로의 링크들을 포함할 수 있다. 재생목록 대신, 또는 그에 더하여, 엔드-유저 장치(110)는 제3자 서버(106)로부터 중요성 정보를 받을 수도 있다. (여기에서, 다운로드 서버(104) 또는 엣지 서버(108)가 아닌 경우는 항상 서버(106)는 "제3자"이다.) 예를 들어, 사용자들은 임의의 "아이에게-친숙한(kid-friendly)" 소스에 의하여 제공되는 평가 정보만을 신뢰할 수도 있다.

상기의 "아이에게-친숙한" 평가 소스의 예를 확장하여 보다 일반적인 주제를 생각해 보기로 한다: 모든 사용자들이 주어진 미디어 프리젠테이션에 있어 같은 중요성 정보를 수신하는 것은 아니다. 다운로드 서버(104)에 의해 송신된 재생목록은 특정 사용자 또는 특정 장치를 위해 커스터마이즈될(customized) 수 있다. 이와 같이, 통계 정보는 미디어 프리젠테이션이 실제로 어떻게 보여지는가에 대하여 모을 수 있다. 만약 가능하다면, 정보는 (예를 들어, 엔드-유저 장치(110)에 저장된 프로파일에 근거하여) 특정 사용자에 대해 알려진 것과 신중히 비교될 수 있고, 중요성 정보는 적절히 맞출 수도 있다. 만약에 청크를 요청하는 엔드-유저 장치(110)가 오직 낮은 해상도 화면만을 가지고 있다면, 재생목록은 미디어 프리젠테이션을 위한 더 낮은 해상도 버전들로 맞추어질 수 있다. (본 논의에서, "해상도(resolution)"는 프리젠테이션의 품질에 대한 임의의 척도를 위한 약어로써 사용됨을 유의해야 한다.) 만약 사용자 프로파일이 평가 제한(rating limit)을 나타내고 있다면, 상기 제한 범위 이내로 포함되지 않는 청크들은 검열된 형태 또는 부적절한 컨텐츠를 제거하는 교체 형태로 송신될 수 있다. 몇몇의 실시예에서, 중요성 정보는 해당 중요성 정보가 적절하게 속하는 그룹을 명시하는 정보를 수반한다. 엔드-유저 장치(110)는 그러면 이러한 특정 중요성 정보가 그에게 흥미로운지 여부를 결정할 수 있다.

도 3a의 단계(302)부터 단계(306)까지는 엔드-유저 장치(110)의 로컬 사용자들에게 매우 특별히 커스터마이즈된 중요성 정보를 모으는 방법을 나타낸다. 단계(302)에서, 엔드-유저 장치(110)는 (그 사용자 인터페이스(204)를 통해) 미디어 프리젠테이션을 다운로드할 때 그 사용자가 어떻게 행동할지를 관찰할 수 있다. 예를 들어, 시간이 흐르면, 엔드-유저 장치(110)는 그 사용자가 녹화된 야구 경기는 통상 전체를 시청하지만 축구 경기는 오직 골(goal) 장면만을 시청한다는 것을 알 수도 있다. 사용자가 또 다른 경기를 보기 시작하기로 선택할 때, 단계(304)에서, 엔드-유저 장치(110)는 경기의 유형을 확인할 수 있고 과거 관찰을 기초로 경기 전체가 중요한지(야구) 또는 오직 하이라이트만 중요한지를(축구) 추론할 수 있다.

로컬 행동의 많은 기타 유형들이 관찰될 수 있고, 실시간으로 기억되거나 사용될 수 있다. 빨리감기 되거나 스킵되는 미디어 프리젠테이션의 부분은 이 사용자에게 거의 중요하지 않은 것으로 여겨질 수 있다. 반대로, 되감기와 슬로우모션(slow-motion) 재생은 특별히 중요한 부분임을 나타낸다. 만약 사용자가 어떤 장면을 강조하거나(highlight) 저장한다면, 사용자가 그 장면을 중요한 것으로 여긴다는 것이 더욱 분명해진다. 사용자 인터페이스(204)와의 기타 상호 작용들은 중요성을 추론하기 위해 사용될 수 있다. 예를 들어, 만약 사용자가 재생 제어 메뉴를 띄운다면, 이는 현재 시청되고 있는 미디어 프리젠테이션의 부분이 더 중요한 혹은 덜 중요한 것임을 나타낼 수 있다. 이에 응하여, 현재 부분이 자체(local)에 캐시될(cached) 것으로 표시될 수도 있고 향후 부분이 낮은 해상도로 다운로드될 수도 있다. 다시, 만약 사용자가 재생 볼륨을 키운다면, 이는 현재 부분이 사용자에게 훨씬 더 중요하다는 것을 나타낼 수도 있다. 이러한 유형의 행동 관찰의 "실시간" 사용을 위한 가능성은 도 3a의 단계(308)부터 도 3b의 단계(316)까지를 참고하여 아래에서 논의된다.

단계(306)에서, 엔드-유저 장치(110)는 장치 사용자의 허락이 있으면, 장치의 행동 관찰을 다운로드 서버(104) 혹은 제3자 서버(106)에게 보고할 수 있다. 엔드-유저 장치(110)에 의해 생성된 이러한 관찰들은 주어진 청크 내의 어떤 부분들이 중요하게 여겨지고 어떤 부분이 그렇지 않은지를 보여줄 수 있기 때문에 특히 중요하다. (서버(104, 106) 자체가 모은 관찰들은 일반적으로 청크 대 청크 기반으로 이루어진 것이고 청크 "내부"를 볼 수 없는 것이다. 아래, 도 4a의 단계(406)를 수반하는 논의 참조.) 서버(104, 106)는 관찰을 인구 통계의 모음에 추가할 수 있다. 서버는 또한 관찰들과 연관된 특정 사용자들을 기억하고, 그에 따라 (전술된 바와 같이, 커스터마이즈된 재생목록을 생성하는 것과 같이) 향후의 중요성 정보를 조정할 수 있다.

단계(308)에서, 엔드-유저 장치(110)는 청크를 다운로드할지 여부를 결정하기 위해 중요성 정보를 사용한다. 예를 들어, 서버(104, 106, 108)로부터 수신한 통계학적 정보 또는 로컬 사용자의 관찰에 근거하여, 엔드-유저 장치(110)는 그가 청크를 안전하게 스킵하고 그 다음 다운로드하는 것을 멈추거나 대체 가능한 청크를 요청할 수 있을지를 결정할 수 있다. (몇몇의 실시예에서, 엔드-유저 장치(110)는 로컬 사용자에게 청크를 스킵한다는 결정을 표현한다. 로컬 사용자는 엔드-유저 장치(110)에 의해 이루어진 결정을 받아들이거나 무시할 수 있는 선택권을 가진다.) 만약에 청크가 원하여지면, 엔드-유저 장치(110)는 서버(104, 108)에 청크를 요청하고, 서버(104, 108)는 요청된 청크를 보낸다. 중요성과 다른 기준이 단계(308)의 결정에 사용될 수 있음을 주의해야 한다. 예를 들어, 엔드-유저 장치(110)는 그의 캐시가 부족한 것을 주목할 수 있고, 따라서 비디오 정지를 피하기 위해 비록 청크가 중요한 것으로 태그되었고 일반적으로 높은 해상도로 요청된다 할지라도 (빨리 더 많은 청크를 얻기 위해) 이어진 청크를 낮은 해상도로 요청할 수 있다. 또 다른 예로, 비디오 정지를 야기함이 없이 높은 중요성을 가진 두 번째 청크를 높은 해상도로 다운로드하는데 충분한 시간을 가지도록 엔드-유저 장치(110)는 중요성 정보를 사용해 낮은 중요성을 가진 첫 번째 청크를 낮은 해상도로 다운로드할 수 있다.

(주의: 여기에서 본 논의에 관련된 "청크"의 의미에 대해 해당 기술에서 약간의 혼란이 있을 수 있다. 때때로, "청크"는 시간 세그먼트의 코딩 해상도와 관련 없이 비디오 프리젠테이션의 주어진 시간 세그먼트와 동일시된다. 다시 말해서, 첫 번째 2초 세그먼트는 다른 해상도들에서 인코딩될 수 있는 "청크"이다. 다른 경우에 있어, 첫 번째 2초 세그먼트의 각각 해상도는 다른 "청크"들로 여겨진다. 본 논의는 두 가지 의미 모두를 사용하지만, 정확성이 요구될 때 후자가 사용된다(상기 의미는 항상 문맥상 분명함). 그러므로, 단계(308)에서 결정은 "청크"를 다운로드하지 않고, 그 대신에 미디어 프리젠테이션의 같은 세그먼트의 다른 해상도 버전을 다운로드하는 것이 될 수 있다.)

몇몇의 실시예에서, 엔드-유저 장치(110)는 단계(308)에서 그의 로컬 사용자와 직접적으로 작동할 수 있다. 만약 로컬 사용자가 오직 미디어 프리젠테이션의 하이라이트만을 원한다면, 엔드-유저 장치(110)는 전체 프리젠테이션의 중요성 정보를 검토하고, 중요성 임계점을 정하고, 중요성 정보가 임계점을 초과하는 청크만을 포함하는 하이라이트 비디오를 만들고, 그의 로컬 사용자에게 하이라이트 비디오를 제공할 수 있다. 주어진 중요성 임계점에서는, 하이라이트 비디오는, 말하자면 10분 동안 실행된다. 로컬 사용자는 (아마 임계점이 사용되고 있는 것을 모르고) 원하는 길이로 하이라이트 비디오를 설정하도록 임계점을 조정할 수 있다. 따라서, 간단히 중요성 정보를 적용함으로써, 각각의 사용자는 그 자신의 사양에 따라 하이라이트 비디오를 만들 수 있다. 유사 서비스는 다운로드 서버(104)에 의해 제공될 수 있다.

도 3b의 단계(312)는 로컬 행동에 관한 관찰들의 실시간 사용의 예를 나타낸다. 만약 엔드-유저 장치(110)가, 장치의 사용자가 일시동안 빨리감기를 해왔다는 것을 주목한다면, 엔드-유저 장치(110)는 그 사용자가 빨리감기를 계속할 것이라 추측할 수 있다. 따라서, 엔드-유저 장치(110)는 그 다음 청크를 낮은 해상도로 요청할 수 있다. (반대로, 만약 로컬 사용자가 슬로우모션으로 보고 있다면, 매우 높은 해상도 청크가 요청될 수 있다.) 만약 로컬 사용자가 앞으로 스킵한다면, 엔드-유저 장치(110)는 또한 앞으로 스킵할 수 있고 그 바로 다음 청크을 요청하기보다 더 향후의 청크를 요청할 수 있다.

만약 엔드-유저 장치(110)가 그의 사용자가 항상 오직 축구 경기의 골에만 관심있는 것을 안다면, 엔드-유저 장치(110)는 단계(314)에서 골 장면으로 태그된 청크를 요청할 수 있고, 심지어 다른 청크들(예를 들어, 사용자가 빨리감기를 한 골이 없는 장면)에 대해 비순차적으로 높은 해상도로 요청할 수 있다. 엔드-유저 장치(110)는 또한 청크를 요청하는 것을 지연시키면서 해당 청크가 요청되어야만 하는지 여부를 엔드-유저 장치(110)가 알도록 도울 수 있는 더 많은 행동에 관한 정보가 사용자로부터 오기를 기다릴 수 있다. 예를 들어, 만약 서버(104, 106, 108)로부터 받은 통계학적 정보가, 프리젠테이션의 마지막 N 청크를 일반적으로 보지 않는다(즉, 시청자가 항상 마지막 N 청크를 보기 전에 프리젠테이션을 중단한다)는 것을 나타내면, 엔드-유저 장치(110)는 그 사용자의 행동을 관찰하는 동안 청크들의 다운로드 요청을 연기할 수 있다. 만약 사용자가 프리젠테이션을 중단하지 않고, 특정 부분을 넘어 계속하여 시청한다면, 엔드-유저 장치(110)는 남아있는 청크들을 요청할 수 있다. 대안적으로, 로컬 사용자가 N-번째 청크의 특정 부분 이후를 보기 시작하거나 계속하여 볼 때까지 혹은 그러한 경우, 엔드-유저 장치(110)는 N-번째 청크를 가능한 가장 낮은 해상도로 다운로드할 수 있고, 부분 이후 청크들의 다운로드를 미룰 수 있다.

종종, 엔드-유저 장치(110)는 제한된 메모리를 가질 것이며, 미디어 프리젠테이션 전체를 저장할 수 없다. 이와 같은 경우, 그 사용자가 되돌아와 청크들(예를 들어, 골들)을 다시 볼 수 있으므로 어떤 청크가 저장되어야 하는지 및 어떤 청크들(예를 들어, 경기의 나머지 부분)이 시청 후 즉시 버려질 수 있는지를 알 수 있도록 중요성 정보는 엔드-유저 장치(110)에 의해 사용될 수 있다.

단계(316)에서, 엔드-유저 장치(110)는 사용자 인터페이스(204)를 통해 그 사용자에게 청크를 렌더링한다. (셋탑 박스(114)가 텔레비전 모니터(116)에 렌더링하는 경우와 같이 몇몇의 경우에 사용자 인터페이스(204)는 또 다른 장치상에 청크를 실제로 렌더링하는데 사용된다.) 여기에서, 청크를 어떻게 렌더링할 것인지를 결정할 때, 엔드-유저 장치(110)는 (종종 로컬 유저-인터페이스 세팅에 따라) 중요성 정보를 사용할 수 있다. 예를 들어, 엔드-유저 장치(110)는 시각적으로 폭력적이라고 태그된 장면들을 검열하기 위해 "픽셀레이팅 처리(pixelate)"(디지털 이미지를 흐릿하게 하는 방법)를 할 수 있고 또는 공격적인 언어를 이해할 수 없게 하기 위해 오디오를 흐릿하게 할 수 있다. 아니면 엔드-유저 장치(110)는 일반적으로 흐릿한 장면을 분명하게 할 수 있다. (예를 들어 청크는 로컬 사용자가 따를 필요가 없는 기준인 FCC 방송 기준을 만족하도록 인코딩될 수 있는데, 그러면 엔드-유저 장치(110)는 아마도 추가적인 정보를 얻기 위해 제3자 서버(106)에게 물어봄으로써 그 흐릿함을 제거할 수 있다.) 엔드-유저 장치(110)는 또한 그 사용자에게 흥미있다고 추정되는 장면으로 빨리감기하거나 스킵함으로써 그 사용자의 기대를 예측하는 것을 선택할 수도 있다.

단일 미디어 프리젠테이션이 다운로드되는 동안 도 3a 및 3b의 단계들이 종종 반복되며 때때로 순서가 바뀜을 주의하여야 한다. 도 3a의 단계(302)에서 모인 행동의 관찰들은 사용자가 미디어 프리젠테이션을 계속하여 봄에 따라 더 정확해지고 따라서 더 가치 있어 질 수 있다. 언제라도 서버(104, 106, 108)는 단계(300)에서 업데이트된 중요성 정보(예를 들어, 새롭고 가능한 커스터마이즈 된 재생목록)를 보낼 수 있다.

도 3a 및 3b의 방법은 단순히 모든 것을 다운로드하기 시작하는 이전의 방법들에 비해 로컬 사용자에게 가치 있는 것만이 실제로 다운로드되는 가능성을 향상시킨다. 따라서, 방법은 대역폭 및 엔드-유저 장치(110)를 위한 배터리 파워 모두를 절약할 수 있다.

본 발명의 몇몇의 실시예는, 서버(104, 106, 108)가 공지 기술에 비해 조금도 향상되지 않은 경우에도 이득을 제공할 수 있다. (즉, 엔드 유저 장치(110)는 도 3a의 단계(302)에서 그 사용자의 행동을 관찰한 것으로부터 추론할 수 있는 중요성 정보에만 액세스할 수 있다.) 그러나, 서버(104, 106, 108)가 더 많은 중요성 정보를 제공하도록 개선된 실시예들이 분명한 이점들을 제공한다.

도 4a 및 4b는 그러한 개선된 서버(104)의 예를 제공한다. 도 4a의 단계(400)에서, 서버(104)는 중요성 정보를 수집하고 정보를 미디어 프리젠테이션의 청크들과 연관 짓는다. 도 3a에 대해 전술된 본문과 같이 정보는 (인간 또는 전자) 편집자에 의해 제공될 수도 있고(단계(402)), 인구 통계를 포함할 수 있고, 엔드-유저 장치(110) 그 자체로부터 받을 수 있고(단계(404)), 그리고 다운로드 서버(104) 그 자체에 저장되거나 제3자 서버(108)에 저장될 수 있다. 게다가, 다운로드 서버(104)는 그 자체를 관찰할 수 있고(단계(406)), 어떤 청크가 요청되며, 얼마나 자주인지 등을 알 수 있고, 중요성에 대한 서버 스스로의 추정치를 추론할 수 있다. (상기의 관찰들은 인구 통계에서 모인 다른 것과 유사한 경향의 것들이다.)

단계(408)의 몇몇의 실시예에서, 서버(104)는 최소한 어느 정도의 중요성 정보를 클라이언트 장치에 송신한다(또는 다른 어딘가에 저장된 중요성 정보와 연결한다). (엔드-유저 장치(110)는 클라이언트 장치의 하나의 유형이며, 아래에 논의된 바와 같이 다른 것들도 있다.) 중요성 정보는 전술된 바와 같이 포괄적이거나 커스터마이즈된 재생목록에 포함될 수 있다. 단계(408)의 다른 실시예들에서, 서버(104)는 실제로 중요성 정보를 송신하지 않으나 그 대신에 중요성 정보에 근거하여 커스터마이즈된 재생목록을 생성하거나 송신한다. 커스터마이즈된 재생목록은 엔드-유저 장치(110)에 저장된 사용자 프로파일의 타당성 기준을 충족하는 청크들만을 포함하거나 부적절하다고 여겨지는 청크들을 대체하는 부적절하지 않은(non-objectionable) 청크들을 포함할 수도 있다. 단계(408)는 업데이트된 중요성 정보가 이용 가능하게 됨에 따라, 미디어 프리젠테이션의 다운로드 동안 반복될 수 있음에 주의해야 한다.

몇몇의 실시예에서, 대체 가능한 단계(408)는 레거시(legacy) 엔드-유저 장치(110)와 함께 사용될 수 있다. 레거시 엔드-유저 장치(110)는 중요성 정보를 알지 못하는 장치들이다. 특정 엔드-유저 장치(110)의 제한을 알고 있는 서버(104)는 간단히 무시될 수 있는 중요성 정보를 전송하는 대신에 특정 엔드-유저 장치에 대한 재생목록의 버전을 조정하는데 중요성 정보를 사용한다. 엔드-유저 장치(110)의 사용자에 의해 인지된 결과는, 중요성 정보를 완전히 인식하는 엔드-유저 장치(110)에 의해 얻어질 수 있는 결과와 대략 비슷하다.

단계(410)와 단계(412) 사이에, 서버(104)는 클라이언트 장치로부터 청크에 대한 요청을 받고 요청된 청크를 다운로드함으로써 요청을 수행한다. 오늘날의 대부분 시스템은 시스템 내에서 클라이언트 장치가 실제로 무엇을 다운로드할지 결정하는 (도 3a의 단계(308)에서) "풀(pull)" 시스템이고, 서버(104)는 단지 요청된 대로 한다. 그러나, "푸시(push)" 시스템은, 시스템 내에서 어떤 청크가 다운로드될지에 대해 서버(104)가 더 많은 제어를 하는 것이 가능하다. 본 발명의 태양들은 바람직한 경우 푸시 시스템에 적용하기 위해 당업자에 의해 쉽게 수정될 수 있다.

어떤 경우에 있어 수집된 중요성 정보는 서버(104)로 하여금 해당 청킹이 가장 효율적인 것은 아닌 것으로 결정하도록 한다. 예를 들어, 10초 청크의 반은 매우 중요하지만 나머지 반은 거의 시청되지 않는다는 것이 알려질 수 있다. 대부분의 (그러나 전부는 아닌) 현재 시스템들이 오직 청크 대 청크 기반으로 다운로드할 수 있고 청크의 부분만을 전달할 수 없기 때문에 이것은 비효율을 초래한다. 이러한 비효율을 완화하기 위하여, 도 4b의 단계(414)에서 서버(104)는 각각의 새로운 청크가 청크 전반에 걸쳐 상대적으로 일정한 수준의 중요성을 가지도록 미디어 프리젠테이션을 "리청킹할(rechunk)" 수 있다. (물론, 이는 하나의 고려사항일 뿐이고, 리청킹이 그 장점보다 더 큰 그 스스로의 비효율을 초래할 시점이 온다.) 다른 예에서, 몇몇의 다운로드 프로토콜은 미디어 프리젠테이션이 시작될 때 특정 수의 청크가 항상 다운로드될 것을 권장한다. 인구통계에 근거할 때, 서버(104)는 필요로 되는 수의 청크가 사용자가 항상 보는 것과 일치하도록 프리젠테이션의 시작을 리청킹할 수 있다. 중요성 정보가 서버(104)에 의해 수집되고 따라서 청크 대 청크 기반으로 모은 관찰에 근거할 때, 서버(104)는 점진적 접근방법에 의해 프리젠테이션의 청킹을 향상시킬 수 있는데, 이 방법에서 서버(104)는 여러 경우의 다른 청킹 대안들을 시도하고 가장 효율적인 청킹 대안을 선택한다. 일례로서, 서버(104)는 더 짧은 청크를 포함하는 청킹 대안으로 시작해서 그 다음 상대적인 중요성의 특정 기준을 충족할 때까지 청크들을 수집한다.

단계(414)와 유사하게, 단계(416)에서 서버(104)는 미디어 프리젠테이션(또는 미디어 프리젠테이션의 부분)의 완전히 새로운 버전이 새로운 해상도로 제공되는 것을 결정할 수 있다. 즉, 빈번히 보여지는 장면은 높은 해상도로 제공될 수 있는 반면, 흔히 대규모로 빨리감기 또는 스킵되는 장면은 낮은 해상도로 이용 가능하도록 녹화될 수 있다.

도 3a 및 3b의 방법에 따라, 몇 단계가 순서가 바뀌거나 스킵되면서, 도 4a 및 4b의 방법은 흔히 반복된다.

명료성을 위해, 도 4a 및 4b의 방법의 상기 논의는 다운로드 서버(104)에 중점을 두고 있다. 방법의 많은 부분은 또한 제3자 서버(106)에 적용될 수 있다. 제3자 서버(106)는 중요성 정보를 수집할 수 있고(단계(400, 402, 및 404)), (비록 제3자 서버(106)가 미디어 컨텐츠보다는 중요성 정보를 다운로드하지만) 제3자 서버(106) 자체 다운로드부터 중요성을 추론할 수 있으며(단계(406)), 클라이언트 장치들에 (가능한 업데이트되거나 커스터마이즈 된) 중요성 정보를 송신한다(단계(408)).

도 4a의 단계(408)를 참고하면, 서버(104)가 엔드-유저 장치(110) 외의 클라이언트 장치에 다운로드할 수 있음이 언급되어 있다. 특히, 서버(104)는 미디어 컨텐츠 및 중요성 정보를 "엣지" 서버(108)(또는 "엣지 프록시(edge proxy)" 서버라고 불림)에 다운로드할 수 있다. 엣지 서버(108)는 서버(104)로부터의 다운로드 혼잡을 덜어주기 위해 흔히 제공된다. 서버(104)는 엣지 서버(108)에 인기있는 미디어 컨텐츠를 송신하는데, 엣지 서버(108)는 엔드-유저 장치(110)의 다운로드 요청에 대해 직접적으로 순차적으로 응답한다(도 3a의 단계(310)). 엣지 서버(108)에 현재 캐시되지 않은 컨텐츠에 대한 요청이 이루어지면, 요청이 다운로드 서버(104)로 전달되거나 엣지 서버(108)가 다운로드 서버(104)로부터 컨텐츠를 검색하고 요청을 이행한다.

본 발명의 태양들에 따르면, 도 5는 엣지 서버(108)에 의해 사용 가능한 간소화된 방법을 나타낸다. 본 발명의 몇몇 실시예가 이미 공지 기술로 알려진 엣지 서버(108)와 완벽하게 잘 작동함을 주목해야 한다. 한편으로, 단계(500)는 엔드-유저 장치(110)에 대한 엣지 서버(108)의 역할을 요약하고 있다. 즉, 엣지 서버(108)는 엔드-유저 장치(110)에 컨텐츠를 제공하기 위해 다운로드 서버(104)처럼 (그리고 심지어 몇몇의 실시예에서, 제3자 서버(106)처럼) 행동한다. 따라서, 엣지 서버(108)는 도 4a 및 4b에 도시된 바와 같은 서버 방법의 단계들을 수행할 수 있다.

다른 한편으로, 단계(502)는 다운로드 서버(104)에 대한 (그리고, 몇몇의 실시예에서, 제3자 서버(106)에 대한) 엣지 서버(108)의 역할을 요약한다. 즉, 엣지 서버(108)는, 도 3a 및 도 3b에 도시된 바와 같이 엔드-유저 장치 방법의 단계들을 수행할 수 있다. (일반적으로, 엣지 서버(108)는 직접적으로 로컬 사용자를 지원하지 않고, 따라서 엣지 서버(108)가 도 3b의 단계(316)를 수행할 가능성은 희박하다).

엣지 서버(108)가 서버(104, 106), 엔드-유저 장치(110)에 완전히 의존하여 수행하지는 않는다. 단계(504)에서, 엣지 서버(108)는 어떤 청크가 "미리 캐시될 지(pre-cache)" 즉, 어떤 청크들이 다운로드 서버(104)로부터 요청되고 심지어 엔드-유저 장치(110)에 의해 요청되기 전에 저장될지를 결정하기 위해, (엣지 서버(108)에 주어지거나 엣지 서버(108)에 의해 추론될 수 있는) 중요성 정보를 사용할 수 있다. 예를 들어, 챔피언전 경기의 하이라이트가 매우 인기 있는 다운로드 대상이 될 것이라는 것이 앞서 결정될 것이다. 그러면, 엔드-유저 장치(110)로부터 들어오는 첫 번째 요청을 기다리기보다 엣지 서버(108)는 하이라이트들을 즉시 저장할 수 있고, 따라서 만약 첫 번째 요청이 있을 때만 하이라이트를 검색했어야 하는 것보다 첫 번째 요청에 대한 응답을 더 빨리 할 것이다.

유사하게, 단계(506)에서 엣지 서버(108)는 중요성 정보를 사용할 수 있고, 보고 있는 다운로드 행동을 또한 관찰할 수 있고, 어떤 청크가 다소 제한적인 캐시를 유지하도록 충분히 인기 있는지를 (또, 반대로, 어떤 청크가 다른 청크를 위한 여유를 만들기 위해 삭제되어야 할지를) 결정할 수 있다. 상기 결정이 다운로드 서버(104) 및 제3자 서버(106)가 모은 인구 통계와 독립적으로, 심지어 반대로 이루어질 수 있음을 주목해야 한다. 이는 엣지 서버(108)가 더 로컬화된 집단을 보고 있기 때문인데, 더 로컬화된 집단의 취향은 서버(104 및 106)에 의해 보여지는 보다 더 일반적인 집단의 취향과 다를 수 있다.

본 발명의 몇몇의 실시예에서, 다운로드의 효율을 증가시키는 중요성 정보에 더하여 혹은 중요성 정보를 대신하여 청크 크기 정보를 사용한다. 미디어 프리젠테이션을 구성하는 청크들은 일반적으로 모두 같은 재생 길이이기 때문에(예를 들어, 각각 청크는 프리젠테이션의 2 초를 나타낸다), 누군가는 모든 청크들이 (물론, 주어진 해상도에 대해) 같은 수의 바이트를 포함한다고 생각할 수도 있다. 그러나 보여지는 장면의 복잡도 변화 및 장면이 얼마나 빨리 변하는지에 따라 인코딩 효율이 프리젠테이션 전체에 걸쳐 다양할 수 있으므로 이와 같은 가정은 종종 사실이 아니다. 도 6은 실제 비디오 클립(video clip)으로부터 가져온 통계를 이용하여 인코딩 효율의 이러한 변화를 도시한다. "기어(Gear) 5"(도 6에 도시된 가장 높은 해상도)에만 주목하면, 해당 도면은 비디오 클립의 같은 시간의 양을 인코딩하기 위해 청크 7이 청크 6보다 45% 더 많은 바이트를 실제로 필요로 한다는 것을 보여준다.

인코딩 효율에 있어 상기와 같은 변화는 해당 분야 기술에서 오랫동안 알려져 있었지만, 엔드-유저 장치는 변화를 지능적으로 다룰 수 없었다. 공지 기술 엔드-유저 장치는 하나의 미디어 프리젠테이션의 모든 청크들이 (주어진 해상도에 대해) 같은 크기라고 가정하였어야 했다. 다가오는 청크가 가정된 크기에 비해 훨씬 큰 경우(예를 들어, 도 6의 청크 7) 청크가 완전히 로드되기 전에 엔드-유저 장치의 입력 버퍼는 "고갈(dry)"되어 버리고 비디오 정지를 초래하게 되는 것이 상당히 가능하다.

도 7은 적어도 비디오 정지 상황의 일부라도 피하기 위한 방법을 나타낸다. 단계(700)에서, 서버(104, 106, 108)는 엔드 유저 장치(110)에 청크 크기 정보를 송신한다. 예를 들어, 청크 크기 정보는 재생목록에 인코딩되거나 미디어 프리젠테이션과 관련된 초기 메타데이터(metadata)와 함께 포함될 수 있고, 주어진 청크의 크기가 이전에 다운로드된 청크와 함께 포함될 수 있다. 몇몇의 경우에 있어, 서버(104, 106, 108)는 엔드-유저 장치(110)에 의해 수신된 청크 크기 정보에 대한 명시적 요청의 응답에 대응하여 동작할 수 있다. 예를 들어, 엔드-유저 장치(110)는 다음 청크에 대해, 또는 주어진 해상도에서 미디어 프리젠테이션의 다양한 청크에 대해, 또는 다양한 해상도에서 다양한 청크에 대해 크기 정보를 요청하는 HTTP HEAD 명령을 보낼 수 있다. 대역폭을 절약하기 위해, 몇몇의 실시예에서, 청크의 실제 크기를 전송하기보다는 해당 크기의 근사치 혹은 상대적 크기를 송신한다. 몇몇의 실시예에서, 서버(104, 106, 108)는 미디어 프리젠테이션에 대한 (주어진 해상도에서) "기준" 값(예를 들어, 최대 비트 레이트(bit rate))을 발행하고 그 다음, 각각의 청크에 대해 기준 값에 대하여 크기(혹은 백분율)를 부여한다.

단계(702)에서, 엔드-유저 장치(110)는 청크 크기 정보를 검토한다. 예를 들어, 엔드-유저 장치(110)는 그 네트워크 링크(network link)의 퍼포먼스를 계속하여 분석할 수 있다. 분석을 기초로, 엔드-유저 장치(110)는 청크 크기를 고려하여 그 다음 청크를 다운로드하는데 얼마나 시간이 걸려야만 하는지를 예측할 수 있다. 엔드-유저 장치(110)는 다음 청크가 시간에 맞춰 다운로드될 수 없을 것 같다는 것을 결정할 수 있다. 그러면, 비디오 정지의 가능성을 피하기 위해, 엔드-유저 장치(110)는 단계(704)에서 낮은 해상도에서(즉, 더 작은 청크 크기를 가지는) 다음 청크를 요청할 수 있다. 몇몇의 경우에 있어, 엔드-유저 장치(110)는 완전히 다른 청크를 요청하거나 전혀 어떠한 청크도 요청하지 않기로 결정할 수도 있다.

몇몇의 경우에 있어, 청크 크기 정보와 중요성 정보 둘 다는 엔드-유저 장치(110)가 이용할 수 있는데, 엔드-유저 장치(110)가 단계(702)에서 무엇을 할지를 결정하기 위해 두 유형의 정보 모두를 사용할 수 있다.

만약 단계(704)에서, 엔드-유저 장치(110)가 청크를 요청한다면 서버(104, 106, 108)는 단계(706)에서 청크를 제공한다.

도 8a 및 8b는 실험의 결과를 나타낸다. 도 8a에서 공지 기술 엔드-유저 장치는 실제 청크 크기 정보에 액세스할 수 없고, 결과적으로 비디오 정지 비율 0.02를 유지한다. 도 8b에서 본 발명의 태양들에 따라 작동하는 엔드-유저 장치(110)는 제공된 청크 크기 정보를 사용하였고 그 결과 비디오 정지 비율은 단지 0.01로 감소하였다.

본 발명의 원칙들이 적용될 수 있는 수많은 가능한 실시예를 고려하여, 도면에 대하여 여기에 서술된 실시예들은 오직 예시적인 것으로 의도되었음이 인식되어야 할 것이고 본 발명의 범위를 제한하는 것으로 취급되어서는 안 된다. 예를 들어, 본 발명의 태양들은 어댑티브-스트리밍(adaptive-streaming) 환경에서 특히 실용적일 수 있으나, 본 발명은 이러한 환경에 제한되지 않는다. 본 발명의 태양들은 어떤 특정 구현 데이터-네트워킹 프로토콜 혹은 특정 서버와 엔드-유저 장치 배치에 제한되지 않는다. 그러므로 여기에 서술된 바와 같이 본 발명은 다음 청구항 및 이와 동등한 것들의 범위 내에서 도출될 수 있는 모든 실시예들을 고려한다.

Claims

엔드-유저(end-user) 장치(110)가 미디어 컨텐츠(media content)를 수신하는 방법으로서,
미디어 프리젠테이션(media presentation)의 청크(chunk)에 대한 크기 정보를 상기 엔드-유저 장치(110)가 수신하는 단계(700);
상기 미디어 프리젠테이션의 청크를 요청할지 여부를 상기 엔드-유저 장치(110)가 결정하는 단계(702) - 상기 결정하는 단계는 상기 미디어 프리젠테이션의 청크에 대한 상기 크기 정보에 기초하여 결정함 - ; 및
상기 미디어 프리젠테이션의 청크를 요청하기로 결정된 경우:
상기 미디어 프리젠테이션의 청크에 대한 요청을 상기 엔드-유저 장치(110)가 송신하는 단계(704); 및
상기 미디어 프리젠테이션의 상기 요청된 청크를 상기 엔드-유저 장치(110)가 수신하는 단계(708)
를 포함하는 미디어 컨텐츠 수신 방법.
제1항에 있어서,
상기 미디어 프리젠테이션의 청크를 요청하지 않기로 결정된 경우:
상기 미디어 프리젠테이션의 대체 청크에 대한 요청을 상기 엔드-유저 장치가 송신하는 단계 - 상기 대체 청크는 원래의 청크의 레이트(rate)와 다른 레이트로 인코딩됨(encoded) - ; 및
상기 미디어 프리젠테이션의 요청된 대체 청크를 상기 엔드-유저 장치가 수신하는 단계
를 더 포함하는 미디어 컨텐츠 수신 방법.
제1항에 있어서,
상기 미디어 프리젠테이션의 청크를 요청하기로 결정된 경우,
상기 청크를 상기 엔드-유저 장치가 렌더링하는(rendering) 단계를 더 포함하고,
상기 렌더링하는 단계는, 상기 청크의 적어도 일부를 픽셀레이팅 처리하고(pixelating), 상기 청크의 적어도 일부를 흐릿하게 하고(obfuscating), 상기 청크의 적어도 일부를 분명하게 하고(unobfuscating), 상기 청크의 적어도 일부를 빨리감기하고(fast-forwarding), 상기 청크의 적어도 일부를 스킵하고(skipping), 상기 청크의 적어도 일부에 대한 대체 오디오 트랙을 재생하며, 상기 청크의 적어도 일부에 대한 대체 비디오 트랙을 재생하는 것으로 구성된 그룹으로부터 선택된 동작을 포함하는, 미디어 컨텐츠 수신 방법.
미디어 컨텐츠를 수신하도록 구성된 엔드-유저 장치(110)로서,
미디어 프리젠테이션의 청크에 대한 크기 정보를 수신하도록(700) 구성되는 네트워크 인터페이스(network interface; 200) 및
상기 네트워크 인터페이스(200)에 연동 접속되는(operatively connected) 프로세서(202)를 포함하고,
상기 프로세서(202)는,
상기 미디어 프리젠테이션의 청크를 요청할지 여부를 결정하고(702) - 상기 결정은 상기 미디어 프리젠테이션의 청크에 대한 상기 크기 정보에 기초함 - ,
상기 미디어 프리젠테이션의 청크를 요청하기로 결정된 경우:
상기 네트워크 인터페이스(200)를 통해, 상기 미디어 프리젠테이션의 청크에 대한 요청을 송신하고(704),
상기 네트워크 인터페이스(200)를 통해, 상기 미디어 프리젠테이션의 상기 요청된 청크를 수신하도록(708) 구성되는, 엔드-유저 장치(110).
서버(104)가 미디어 컨텐츠를 전송하기 위한 방법으로서,
미디어 프리젠테이션의 청크에 대한 크기 정보를 상기 서버(104)가 클라이언트 장치(110)로 송신하는 단계(700);
상기 미디어 프리젠테이션의 청크에 대한 요청을 상기 서버(104)가 상기 클라이언트 장치(110)로부터 수신하는 단계(704); 및
상기 미디어 프리젠테이션의 상기 요청된 청크를 상기 서버(104)가 상기 클라이언트 장치(110)로 송신하는 단계(706)
를 포함하는 미디어 컨텐츠 전송 방법.
미디어 컨텐츠를 전송하도록 구성된 서버(104)로서,
미디어 프리젠테이션의 청크에 대한 크기 정보를 송신하도록(700) 구성된 네트워크 인터페이스(200); 및
상기 네트워크 인터페이스(200)와 연동 접속되는 프로세서(202)
를 포함하고
상기 프로세서는,
상기 네트워크 인터페이스(200)를 통해, 상기 미디어 프리젠테이션의 청크에 대한 요청을 수신하고(704),
상기 네트워크 인터페이스(200)를 통해, 상기 미디어 프리젠테이션의 상기 요청된 청크를 송신하도록(706) 구성되는, 서버.
서버(104)가 청크 크기 정보를 전송하기 위한 방법으로서,
미디어 프리젠테이션의 청크에 대한 크기 정보를 상기 서버(104)가 클라이언트 장치(110)로 송신하는 단계(700)를 포함하고,
상기 청크에 대한 크기 정보는 상기 미디어 프리젠테이션의 복수의 청크에 공통된 기준 값에 대해 상기 청크가 가지는 차이 값을 포함하는 것인, 청크 크기 정보 전송 방법.
제7항에 있어서,
상기 기준 값은 최대 비트 레이트(maximum bit rate)를 포함하고,
상기 차이 값은 양자화된 근사치 및 양자화된 근사치에 대한 인덱스 값으로 구성된 그룹으로부터 선택되는, 청크 크기 정보 전송 방법.