KR101540878B1 - 파일 전달 방법들을 이용한 ｉｐ 브로드캐스트 스트리밍 서비스 배포 - Google Patents

Abstract

하나의 예에서, 디바이스는, 네트워크를 통해, HTTP를 통한 동적 적응적 스트리밍 (DASH) 에 부합하는 미디어 콘텐츠의 적어도 일 부분을 취출하기 위한 요청으로서, 적어도 일부가 파일 전달 서비스에 따라 전달되게 하는 요구를 포함하는 요청을 전송하고, 그 요청에 응답하여, 상기 네트워크로 상기 파일 전달 서비스에 따라 미디어 콘텐츠의 적어도 일부에 대한 스트리밍 데이터를 수신하도록 구성된 하나 이상의 프로세싱 유닛들을 구비한다. 그 디바이스는 브라우저가 파일 전달 서비스를 이용하여 데이터를 사실상 스트리밍할 수 있도록 수신된 데이터로 브라우저 캐시를 채울 수도 있다. 그 디바이스는 파일 전달 서비스를 통해 수신된 데이터의 스위치 포인트가 도달되기까지 유니캐스트를 이용하여 미디어 콘텐츠의 데이터를 초기에 취출할 수도 있다.

Description

파일 전달 방법들을 이용한 ＩＰ 브로드캐스트 스트리밍 서비스 배포{IP BROADCAST STREAMING SERVICES DISTRIBUTION USING FILE DELIVERY METHODS}

본 출원은 2011년 4월 5일자로 출원된 미국 가출원 제61/472,116호를 우선권 주장하며, 본 명세서에 전부가 참조로 통합된다.

기술 분야

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

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

비디오 데이터가 인코딩된 후, 비디오 데이터는 송신 또는 저장을 위해 패킷화될 수도 있다. 비디오 데이터는 다양한 표준들, 이를테면 국제표준화기구 (ISO) 기반 미디어 파일 포맷 및 그 확장들 중 임의의 것, 이를테면 ITU-T H.264/AVC에 부합하는 비디오 파일로 어셈블리될 수도 있다. 그런 패킷화된 비디오 데이터는 다양한 방법들로, 이를테면 네트워크 스트리밍을 이용한 컴퓨터 네트워크를 통한 송신으로 전송될 수도 있다.

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

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

처음에 "프로그래시브 다운로드 (progressive download)" 방법이 대부분의 비디오들의 다운로드를 위해 사용되었다. 이 메커니즘에서, 단일 HTTP 접속 및 전송이 전체 비디오 파일을 다운로드하기 위해 이용된다. 사용자는 다운로드가 발생함을 감시하고, 전체 스트림-뷰잉 경험을 지원하기에 충분한 데이터가 버퍼링된 경우, 플레이어 또는 사용자 중 어느 하나가 "플레이 (PLAY)"를 치고 비디오 플레이백이 시작한다. 그러나, 이 방법은, 사용자가 특히 저용량 링크들을 통해 비디오를 즉시 감시하기를 원하는 경우, 문제들을 갖는다. 다른 문제는, 무선 환경을 변경할 시, 적응적 다운로드가 느린 속도로 급격히 다운쉬프트 (downshift) 할 수 있어, 비디오의 중간에 스톨 (stalls) 을 유발한다는 것이다.

이들 문제들을 다룰 것을 시도하는 HTTP를 통한 적응적 스트리밍을 구현하기 위한 작업은 진행되고 있다. 적응적 스트리밍 프로토콜들의 예들은 마이크로소프트 스무스 스트리밍 (MSS), 애플 HTTP 라이브 스트리밍 (HLS), 아도비 HTTP 다이나믹 스트리밍 (AHDS), 및 3GPP 표준, HTTP를 통한 동적 적응적 스트리밍 (DASH) 을 포함한다. 2011 년에 비디오 패킷들을 고객 집들로 전달하는 넷플릭스 비디오 스트리밍 서비스 (MSS에 기초함) 는 저녁, 피크 시간들에 북미 인터넷 백홀 (backhaul) 의 30%를 소비했다.

적응적 스트리밍 방법들은 일반적으로 HTML 웹 페이지에 아주 많이 유사하게 비디오 데이터를 편성한다. 예를 들어, DASH에서, 비디오 데이터에 대응하는 "프래그먼트들" (하위-파일들) 의 모두를 참조하기 위해 "비디오 웹 페이지"가 정의된다. 프래그먼트가 통상 2 초의 실시간 비디오 또는 오디오이고, 그것은 보통 비디오의 경우 MPEG I-프레임 (근본적으로 완전 JPEG-인코딩된 화상) 으로 시작한다. DASH에서 "비디오 웹 페이지"는 "미디어 프레젠테이션 디스크립션" (MPD) 이라고 지칭된다. 2-시간 비디오에 대한 MPD는 3600 개의 비디오 URL들 (uniform resource loactors), 및 3600 개의 오디오 URL들을 참조할 것이며, 그것들의 각각은 재생되는 경우에 2 초의 미디어에 대응할 수도 있다. 그리고 3600 개 비디오 URL들이 비디오가 인코딩되는 각각의 비트-레이트를 위해 제공될 수도 있다는 점에 주의한다.

DASH의 하나의 개선점은 동일한 비디오가 여러 상이한 비트-레이트들로 서술될 수도 있고, 플레이어가 비트-레이트들을 (예를 들어, 2 초마다) 스위칭할 수 있다는 것이다. MPD는 일반적으로 표현 (representation) 들이라고 지칭되는 동일한 비디오의 3-8 개의 상이한 랜더링들을 서술한다. 인터넷이 혼잡한 경우, 또는 초기 기동 동안, 또는 단말이 저용량 링크 상에 있는 경우, 낮은 비트 레이트 프래그먼트가 페치될 수도 있다. 인터넷이 혼잡하지 않고 단말이 고용량 링크를 가지는 경우, 높은 비트 레이트 프래그먼트가 페치될 수도 있다.

대체로, 본 개시물은 파일 전달 서비스에 따라 네트워크를 통해 비디오 데이터를 스트리밍하는 기법들을 설명한다. 비디오 데이터는 HTTP를 통한 동적 적응적 스트리밍 (DASH) 에 따라 포맷팅될 수도 있다. 다시 말하면, 미디어 콘텐츠는, 이를테면 미디어 콘텐츠의 하나 이상의 표현들의 특성들을 서술하는 미디어 프레젠테이션 디스크립션 (MPD) 과 같은 매니패스트 (manifest) 파일을 포함할 수도 있다. 그러나, 미디어 콘텐츠의 데이터에 대한 요청들을 기다리기 보다는, 본 개시물의 기법들은 데이터가 파일 전달 프로토콜을 통해 하나 이상의 클라이언트 디바이스들로 브로드캐스트 (또는 멀티캐스트) 되는 것을 허용한다. 예를 들어, 데이터는 단방향 전송을 통한 파일 전달 (FLUTE) 프로토콜을 이용하여 브로드캐스트 (또는 멀티캐스트) 될 수도 있다. 일부 예들에서, 브로드캐스트 중인 데이터 내의 스위치 포인트 (다시 말하면, 랜덤 액세스 포인트) 가 수신완료 되기까지, 클라이언트 디바이스가 유니캐스트 프로토콜을 이용하여 미디어 데이터의 일부를 취출할 수도 있다. DASH 의 기법들 및 FLUTE 와 같은 파일 전달 서비스를 이런 방식으로 이용하는 것은 브로드캐스트 또는 멀티캐스트 프로토콜을 통한 비디오 데이터의 리얼 타임 스트리밍을 개선시킬 수도 있다.

하나의 예에서, 방법은 유니캐스트 프로토콜에 따라, 미디어 콘텐츠가 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는, 미디어 콘텐츠의 제 1 부분을 취출하는 단계, 및 파일 전달 서비스를 통해 멀티캐스트 프로토콜에 따라 미디어 콘텐츠의 제 2 부분을 취출하는 단계를 포함하며, 제 1 부분 및 제 2 부분은 미디어 콘텐츠에서 시간적으로 연속적이다.

다른 예에서, 디바이스는 유니캐스트 프로토콜에 따라, 미디어 콘텐츠가 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는, 미디어 콘텐츠의 제 1 부분을 취출하고, 파일 전달 서비스를 통해 멀티캐스트 프로토콜에 따라 미디어 콘텐츠의 제 2 부분을 취출하도록 구성된 하나 이상의 프로세서들을 포함하며, 제 1 부분 및 제 2 부분은 미디어 콘텐츠에서 시간적으로 연속적이다.

다른 예에서, 디바이스는 유니캐스트 프로토콜에 따라, 미디어 콘텐츠가 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는, 미디어 콘텐츠의 제 1 부분을 취출하는 수단, 및 파일 전달 서비스를 통해 멀티캐스트 프로토콜에 따라 미디어 콘텐츠의 제 2 부분을 취출하는 수단을 포함하며, 제 1 부분 및 제 2 부분은 미디어 콘텐츠에서 시간적으로 연속적이다.

다른 예에서, 컴퓨터 판독가능 저장 매체는, 실행될 때, 유니캐스트 프로토콜에 따라, 미디어 콘텐츠가 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는, 미디어 콘텐츠의 제 1 부분을 취출하게 하고, 파일 전달 서비스를 통해 멀티캐스트 프로토콜에 따라 미디어 콘텐츠의 제 2 부분을 취출하게 하는 명령들을 저장하고 있으며, 제 1 부분 및 제 2 부분은 미디어 콘텐츠에서 시간적으로 연속적이다.

다른 예에서, 방법은 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는 미디어 콘텐츠를 획득하는 단계, 유니캐스트 프로토콜에 따라 미디어 콘텐츠의 제 1 부분을 출력하는 단계, 및 파일 전달 서비스에 따라 미디어 콘텐츠의 제 2 부분을 출력하는 단계를 포함하며, 제 1 부분 및 제 2 부분은 미디어 콘텐츠에서 시간적으로 연속적이다.

다른 예에서, 디바이스는 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는 미디어 콘텐츠를 획득하며, 유니캐스트 프로토콜에 따라 미디어 콘텐츠의 제 1 부분을 출력하고, 파일 전달 서비스에 따라 미디어 콘텐츠의 제 2 부분을 출력하도록 구성된 하나 이상의 프로세서들을 포함하며, 제 1 부분 및 제 2 부분은 상기 미디어 콘텐츠에서 시간적으로 연속적이다.

다른 예에서, 디바이스는 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는 미디어 콘텐츠를 획득하는 수단, 유니캐스트 프로토콜에 따라 미디어 콘텐츠의 제 1 부분을 출력하는 수단, 및 파일 전달 서비스에 따라 미디어 콘텐츠의 제 2 부분을 출력하는 수단을 포함하며, 제 1 부분 및 제 2 부분은 미디어 콘텐츠에서 시간적으로 연속적이다.

다른 예에서, 컴퓨터 판독가능 저장 매체는, 실행될 때, 하나 이상의 프로세서로 하여금, 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는 미디어 콘텐츠를 획득하게 하며, 유니캐스트 프로토콜에 따라 미디어 콘텐츠의 제 1 부분을 출력하게 하고, 파일 전달 서비스에 따라 미디어 콘텐츠의 제 2 부분을 출력하게 하는 명령들을 저장하고 있으며, 제 1 부분 및 제 2 부분은 미디어 콘텐츠에서 시간적으로 연속적이다.

하나 이상의 예들의 세부사항들은 첨부 도면들 및 다음의 설명에서 언급된다. 다른 특징들, 목적들, 및 이점들은 상세한 설명 및 도면들로부터, 그리고 청구항들로부터 명확하게 될 것이다.

도 1은 네트워크를 통해 미디어 데이터를 스트리밍하는 기법들을 구현하는 일 예의 시스템을 도시하는 블록도이다.
도 2는 도 1의 네트워크의 부분을 형성하는 디바이스들의 예시적인 세트를 예시하는 블록도이다.
도 3은 2 개의 서버 디바이스들이 미디어 콘텐츠의 데이터를 클라이언트 디바이스에 제공하는 일 예를 도시하는 블록도이다.
도 4는 예시적인 미디어 콘텐츠의 엘리먼트들을 예시하는 개념도이다.
도 5는 미디어 콘텐츠의 표현의 세그먼트에 대응할 수도 있는 예시적인 비디오 파일의 엘리먼트들을 예시하는 블록도이다.
도 6은 2 개의 표현들을 포함하는 예시적인 미디어 콘텐츠를 도시하는 개념도이다.
도 7은 유니캐스트 및 멀티캐스트에 대한 네트워크 스택들의 예들을 도시하는 블록도이다.
도 8은 다른 예의 클라이언트 디바이스를 도시하는 블록도이다.
도 9는 본 개시물의 기법들에 따라, 유니캐스트 또는 브로드캐스트 또는 멀티캐스트 중 어느 하나로 미디어 데이터를 수신하는 예시적인 방법을 도시하는 흐름도이다.
도 10은 파일 전달 서비스를 이용하여 미디어 콘텐츠를 출력하는 예시적인 방법을 도시하는 흐름도이다.

대체로, 본 개시물은 네트워크를 통한 멀티미디어 데이터, 이를테면 오디오 및 비디오 데이터의 스트리밍에 관련된 기법들을 설명한다. 본 개시물의 기법들은 HTTP를 통한 동적 적응적 스트리밍 (DASH) 에 연계하여 사용될 수도 있다. 아래에서 더 상세히 논의될 바와 같이, 본 개시물의 기법들의 특정한 예들은, 파일 전달 서비스를 통한 멀티캐스트 또는 브로드캐스트 프로토콜, 이를테면 단방향 전송을 통한 파일 전달 (FLUTE) 프로토콜을 이용하여, DASH에 따라 캡슐화된 비디오 데이터를 스트리밍하는 것을 포함한다. FLUTE는 신뢰성있는 전송을 제공하는 비동기 계층식 코딩 (ALC) 프로토콜을 기반으로 하고, 이에 따라, FLUTE는 또한 FLUTE/ALC라고 지칭될 수도 있다. 본 개시물은, 네트워크 스트리밍과 연계하여 수행될 수도 있는 다양한 기법들을 개시하며, 그 기법들 중 임의의 것 또는 모두가 단독으로 또는 임의의 다양한 조합들로 구현될 수도 있다. 아래에서 더욱 상세히 설명되는 바와 같이, 네트워크 스트리밍을 수행하는 다양한 디바이스들이 본 개시물의 기법들을 구현하도록 구성될 수도 있다.

본 개시물에서 설명된 바와 같은 FLUTE 대신 사용될 수도 있는 부가적인 파일 전달 프로토콜들은, FCAST 및 원시 ALC/LCT (예컨대, 파일 유형, 인코딩, 및 압축 속성들과 같은 파일 속성들을 전달하기 위해 ALC 및 LCT 헤더들을 이용함) 를 포함한다. FCAST는 Roca의 "FCAST: Scalable Object Delivery for the ALC and NORM protocols", IETF RMT 워킹 그룹, 2011년 10월에 기재되어 있다. ALC는 Luby 등의 "Asynchronous Layered Coding (ALC) Protocol Instantiation" RFC 5775, 2010년 4월에 기재되어 있다. LCT는 Luby 등의 "Layered Coding Transport (LCT) Building Block" RFC 5651, 2009년 10월에 기재되어 있다. 대규모 파일 브로드캐스트 다운로드를 위한 다른 프로토콜들은 MAC 계층에서 파일들을 브로드캐스트하는 IEEE 802.1E 시스템 로드 프로토콜을 포함한다. 시스템 부하 프로토콜은 2011년 8월 9일자로 출원된 미국 특허 출원 제13/206,418호인 Luby 등의 "BROADCAST MULTIMEDIA STORAGE AND ACCESS USING PAGE MAPS WHEN ASYMMETRIC MEMORY IS USED"에 기재되어 있다.

IP 기반 모바일 브로드캐스트 TV 시스템들 (이를테면 DVB-H, ATSC-M/H, 3GPP MBMS (multimedia broadcast multicast services), 3GPP2 BCMCS (broadcast and multicast service)) 에서, 스트리밍 및 파일 전달 서비스들 (때때로 또한 리얼 타임 (Real Time; RT) 및 비 리얼 타임 (Non Real Time; NRT) 서비스들이라고 각각 지칭됨) 은, 상이한 전송 프로토콜들을 이용하여 전달된다. 스트리밍 서비스 전달은 RTP (RFC 3550을 따름) 를 채용하는 반면, 파일 전달 서비스들 (또한 일부 시스템들에서 다운로드 전달 서비스들이라 불림) 은 FLUTE/ALC (RFC 3926 및 RFC 5775를 각각 따름) 를 포함한다. 유니캐스트 기반의 적응적 HTTP 스트리밍 서비스들은 비디오 전달용 현재 인터넷에서 우세한 기술이고, 일반적으로 DASH (Dynamic Adaptive Streaming over HTTP) 라고 지칭되는 3GPP [TS 26.247] 및 MPEG [ISO/IEC FCD 23001-6]에서 표준화되어 있다.

그러나, 본 개시물의 기법들은 LTE 기술에 기반하는 향상된 멀티미디어 브로드캐스트 멀티캐스트 서비스 (enhanced Multimedia Broadcast Multicast Service; eMBMS) 와 같은 신흥 모바일 브로드캐스트 시스템들에 대한 특정한 이점들을 제공할 수도 있다. 특히, 본 개시물의 기법들에 따라, 별도의 스트리밍 및 파일 전달 메커니즘들을 전개하는 것이 필요하지 않은데, 네트워크를 통한 비디오 데이터의 스트리밍 전달이 파일 전달 서비스, 이를테면 FLUTE 를 통해 수행될 수도 있기 때문이다. 스트리밍 서비스들의 브로드캐스트로부터 유니캐스트 전달로의 심리스 (seamless) 서비스 연속성을 유지하는 것은 모바일 오퍼레이터들에게 중요한 능력이다. 이에 대해, 유니캐스트 스트리밍을 지원하기 위해 RTP를 채용하지 않는 것은, 특히 스트리밍의 광범위하고 증가하는 사용 및 연계된 생태계 (ecosystem) 를 고려할 때, 매우 바람직하다. 그 생태계는 HTTP 스트리밍 전달, 콘텐츠 전달 네트워크들 (CDNs) 및 연관된 HTTP 전달 인프라 구조, 이를테면 에지 서버들 및 캐시들을 지원하는 콘텐츠 제공자들, 그리고 HTTP 스트리밍 기술 벤더들을 포함한다.

따라서, 일부 예들에서, 본 개시물은 브로드캐스트 스트리밍 전달을 위해 파일 전달 서비스, 이를테면 FLUTE 프로토콜을 대체하는 기법들을 제공한다. 파일 전달 서비스는 브로드캐스트 매체 액세스 제어 (MAC) 프로토콜, 이를테면 eMBMS, 또는 멀티캐스트 프로토콜, 이를테면 IP 멀티캐스트를 통해 운영할 수도 있다. 이는, 이들 기법들이 스트리밍 및 파일 콘텐츠들 양쪽 모두를 운반하기 위한 단일 애플리케이션 전송 프로토콜 (예컨대, FLUTE) 을 채용할 수도 있다는 점에서 네트워크 및 사용자 디바이스 측들 양쪽 모두에서 단순성을 개선할 수도 있다. 더욱이, FLUTE/ALC 패킷들에서 스트리밍 콘텐츠들을 운반하기 위해 DASH를 연속 미디어 "파일" 구조로서 채용함으로써, 브로드캐스트로부터 유니캐스트 전달로의 서비스 연속성은 단순히 FLUTE/브로드캐스트를 통해 DASH 세그먼트들을 전송하는 것에서 HTTP/유니캐스트로의 스위칭을 수반한다. 결과로서, RTP 기반 유니캐스트 스트리밍 솔루션들, 이를테면 3GPP의 PSS (Packet-switched Streaming Service) (TS 26.234에 기재됨) 는 더 이상 필요하지 않게 되며, 서비스 제공자/네트워크 오퍼레이터가 미디어 콘텐츠들의 유니캐스트 전달을 위해 인기있는 신흥 HTTP 스트리밍을 이용하는 것을 허용한다.

특히, 비디오 데이터를 파일 전달 서비스, 이를테면 FLUTE 프로토콜로 스트리밍하기 위해, 클라이언트 디바이스는 파일 전달 서비스를 통해 수신된 데이터로 캐시를 미리 채울 수도 있다. 아래에서 더 상세히 설명되는 바와 같이, 클라이언트 디바이스는, 유니캐스트를 통해 데이터를 요청하기 전에 요청된 데이터가 로컬 메모리 내에 존재하는지의 여부를 결정하도록 구성될 수도 있다. 유니캐스트를 통해 데이터를 수신한 후에만 캐시를 채우는 대신에, 본 개시물의 기법들은 파일 전달 서비스, 이를테면 FLUTE 프로토콜에 따라 브로드캐스트 또는 멀티캐스트를 통해 데이터를 수신하는 것과, 브로드캐스트 또는 멀티캐스트를 통해 수신된 데이터로 캐시를 미리 채우는 것을 포함한다. 이런 방식으로, 클라이언트 디바이스는 유니캐스트를 통해 데이터를 수신하는 일 없이 데이터가 캐싱되는 것을 결정할 수도 있다. 적절한 캐시 관리 소프트웨어로, 이는 브로드캐스트 및 유니캐스트 송신 사이 및 그 반대로의 심리스 핸드오버를 허용한다. 이 단순화된 핸드오프 기법은 임의의 이전의 스트리밍 프로토콜들에서는 실현되지 않았다.

본 개시물은, 일부 예들에서, 그렇지 않으면 상당한 플레이아웃 지연을 초래할 것인 명목상 애플리케이션 레벨 FEC 프로세스들로 인해 브로드캐스트 스트리밍 서비스들의 FLUTE 전달을 사용하는 경우에 기동 (startup) 및 채널 변경 시간들을 감소시키는 기법들을 추가로 제공한다. 더욱이, 일부 예들에서, 본 개시물은, 클라이언트 디바이스가 적절한 양의 저렴한 비휘발성 로컬 스토리지, 이를테면 플래시 메모리를 구비한다고 가정하여, 예를 들어 동일한 콘텐츠가 유니캐스트 전달을 이용하여 페치하기 위해 소망되는 경우, 잠재적인 미래의 사용을 위해 다운로드된 미디어 콘텐츠들을 캐싱하는 기법들을 제공한다.

본 개시물은 임의의 조합으로 사용될 수도 있는 다양한 기법들을 설명한다. 하나의 예로서, 본 개시물은 브로드캐스트 콘텐츠 전달을 단순화하는 기법들을 설명한다. 이들 기법들에서, FLUTE 프로토콜은 스트리밍 미디어 콘텐츠를 전달하는데 이용될 수도 있다. 미디어 콘텐츠들은 (ISO/IEC 14496-12에 따른) ISO 기반 미디어 파일 포맷으로, 특히 (예컨대, TS 27.247에 따른) DASH 세그먼트들의 형태로, 명목상 캡슐화되고 DASH 미디어 프레젠테이션 디스크립션 (MPD) 에 의해 주어진 연관된 매니패스트 정보가 수반된다고 가정된다. 올바른 미디어 스트림 플레이아웃을 보장하기 위한 시간적 시맨틱 (semantic) 이 MPD에 포함된 벽시간 (wall clock time) 지시자들와 함께, DASH 세그먼트 포맷 내에 포함된 메타데이터에 의해 제공될 수도 있다. 조합하여, 이것들은 RTP의 부가적인 패킷 캡슐화 프로세스를 요구하는 일 없이, RTP (시퀀스 번호, 타임스탬프 및 RTCP 송신기 리포트들을 통한 실제 벽시계 시간) 와 유사한 기능을 제공한다. 스트리밍 미디어 콘텐츠들을 운반하기 위한, FLUTE에 의한 RTP의 사용에 대한 대체물을 도시하는 프로토콜 모델 도면이 도 7에 도시되며, 그것은 아래에서 더 상세히 설명된다.

다른 예로서, 본 개시물은 플레이아웃 대기시간을 감소시키기 위해 유니캐스트 HTTP 스트리밍의 일시적인 사용을 레버리징 (leveraging) 하는 기법들을 설명한다. 유니캐스트 HTTP 스트리밍은 기동 (선택된 콘텐츠에 대한 초기 "튜닝 (tune-in)") 동안, 뿐만 아니라 채널 변경들 (일명 '재핑 (zapping)') 동안에, 최종 사용자가 보는 플레이아웃 대기시간을 감소시키기 위해 FLUTE 브로드캐스트 대신 일시적으로 사용될 수 있다. 이들 기법들은 개선된 사용 경험 및 전체적인 서비스 품질을 위해 서비스 공자들 및 최종 사용자들에게 중요할 수도 있다. 비교적 긴, 예를 들어, 20-30 초의 엔드 대 엔드 대기시간 (라이브 이벤트의 실제 시작 시간부터 그것이 사용자 디바이스 스크린 상에 제시되는 시점 사이의 간격으로서 정의됨) 이 서비스 제공자에게 용인가능하다고 가정된다. 그런 지연은 애플리케이션 레벨 FEC (AL FEC), 이를테면 (RFC 5053을 따르는) 랩터 코드 (Raptor code) 의 효과적인 운영을 위해 소망된 시간 다이버시티를 허용한다.

명목상 브로드캐스트 전달에 대해, 일부 예들은 (SegType_10s의) 10 초 길이 DASH 세그먼트들이 브로드캐스트/FLUTE를 통해 전달된다고 가정한다. 기동 동안, 다시 말하면, 사용자가 (클라이언트 디바이스를 사용하여) 보려고 하는 소망의 라이브 프로그램을 (어쩌면 전자 서비스 가이드에 포함된 서비스 공지 (service announcement) 정보를 이용하여) 선택하는 경우, 직접 전달 브로드캐스트 DASH 세그먼트들은 콘텐츠가 FEC 디코딩되고 스크린 상에 재생될 수 있기 전에 대략 10 초+ 지연이 있게 할 것이다. 기동 지연을 감소시키기 위해, 클라이언트 디바이스는, 본 개시물의 기법들의 일부 예들에 따라, DASH 세그먼트들이 1-2 초 정도의 지속기간으로 비교적 짧은, 유니캐스트 HTTP 스트리밍 모드로 동작할 수 있다.

1 초 길이의 DASH 세그먼트들 (이들을 SegType_1s라 부름) 이 프로그램 기동 동안에 유니캐스트/HTTP로 전달된다고 가정하면, 사용자가 프로그램을 선택하는 경우, 클라이언트 디바이스는 먼저 유니캐스트 HTTP 스트리밍 모드로 동작하여, SegType_1s의 처음 10 개의 세그먼트들을 유니캐스트를 통해 페치하고, 그것들을 랜더링을 위해 미디어 플레이어로 전달한다. 한편, FLUTE 클라이언트 (또한 클라이언트 디바이스 상에서 실행중임) 는 2번째 SegType_10s (1번째 SegType_10s이 아닌데, 그것이 유니캐스트 전달에 의해 서빙 중이기 때문이다) 를 다운로드한다. 클라이언트 디바이스는 그 다음에 유니캐스트로부터 브로드캐스트 수신으로 스위칭될 수도 있고 플레이아웃이 10번째 SegType_1s 및 2번째 SegType_10s 사이에서 추종될 것이며, 그것에 의존하여 라이브 이벤트의 명목상 브로드캐스팅이 계속되고, 유니캐스트 HTTP 스트리밍은 비활성화될 수 있다. 이들 기법들의 일 예가 아래에서 도 6에 관해 더 상세히 설명된다.

유사한 동작 (초기 유니캐스트 대 정상 상태 (steady-state) 브로드캐스트 동작) 이 사용자가 채널 변경을 수행하는 것에 응답하여 클라이언트 디바이스에 의해 수행될 수 있다. 다르게 말하면, '재핑(zapping)' 지연은 채널 변경 동안에 선택된 타겟 채널의 유니캐스트 HTTP 스트리밍 전달을 채용함으로써 10 초 내지 1 초 정도로 감소될 수 있다. 아래에서 더 상세히 설명되는 도 10은, 본 개시물의 기법들에 따라 초기 튜닝 (tune-in) 및/또는 채널 변경 동작들을 수행하기 위한 예시적인 방법을 설명한다.

다른 예로서, 본 개시물은 클라이언트 디바이스에 의해 브로드캐스트된 스트리밍을 통해 수신된 데이터를 캐싱하는 기법들을 설명한다. FLUTE-브로드캐스트 콘텐츠들이 클라이언트 디바이스에 의해 수신됨에 따라, 클라이언트 디바이스는 콘텐츠들을 FLASH 기반 비휘발성 메모리 (NVM) 내에 단일 데이터 파일로서 지속적으로 전달하고 기록할 수도 있어서, 수신된 데이터의 큰 블록은 각각의 기록 동안에 데이터 파일 내의 연속적인 포지션들에 기록될 수도 있고, 데이터는 FLASH NVM의 각각의 페이지가 단일 서브블록에 연관된 데이터를 포함하는 방식으로 기록된다. 더욱이, 도 8은, 아래에서 더욱 상세히 설명되는 바와 같이, 캐싱된 콘텐츠가, HTTP 스트리밍 전달을 이용하는 최종 사용자에 의해 액세스를 위해 나중에 선택된다면, 유니캐스트 네트워크를 통한 불필요한 콘텐츠 획득을 피하기 위해 취출되고 디코딩되고 HTTP 스트리밍 클라이언트에 제공될 수 있다는 것을 도시한다. 플래시 메모리에서 데이터를 저장하고 취출하는 세부사항들은 2011년 8월 9일자로 출원된 미국 특허 출원 제13/206,418호인 Luby 등의 "BROADCAST MULTIMEDIA STORAGE AND ACCESS USING PAGE MAPS WHEN ASYMMETRIC MEMORY IS USED"에 기재되어 있다.

본 개시물의 기법들은, 일부 예들에서, 하나 이상의 이점들을 제공할 수도 있다. 예를 들어, 이들 기법들은 서버 디바이스들 및 클라이언트 디바이스들이 더 적은 전달 방법들을 지원하는 것을 허용할 수도 있다. 다시 말하면, 서버 디바이스들 및 클라이언트 디바이스들은, 파일 전달을 위한 FLUTE 프로토콜 및 스트리밍 전달을 위한 RTP 양쪽 모두를 구현하기보다는, FLUTE 프로토콜에 따라서만 비디오 데이터를 전달하도록 구성될 수도 있다. 더욱이, 이들 기법들은 브로드캐스트로부터 유니캐스트 전달로의 서비스 연속성 또는 핸드오프를 지원하기 위해 RTP 기반 유니캐스트 스트리밍 구현예의 사용의 배제를 허용할 수도 있다. 예를 들어, 3GPP MBMS는 유니캐스트 상의 MBMS 스트리밍 서비스 전달을 지원하기 위해 PSS의 사용을 정의한다. RTP는, 유니캐스트가, 예컨대, 오버-더-탑 (Over-the-Top) 비디오 전달을 위해 인터넷에서 소망되는 경우, 유니캐스트 HTTP 스트리밍에 의해 완전히 대체될 수도 있다. 이 경우, 핸드오프는, 브라우저가 "캐시 누락 (cache miss)"을 야기할 것인 비디오 세그먼트를 요구하는 (그리고 FLUTE 또는 브로드캐스트 다운로드 프로토콜이 캐시를 더 이상 채우지 않을 수 있는) 경우에 그 브라우저 자체에 의해 달성될 것이고, 누락 비디오 세그먼트를 페치하기 위해 HTTP를 호출할 것이다.

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

일부 예들에서, 콘텐츠 준비 디바이스는 표현들의 세트가 공통 특성들의 세트를 가짐을 나타낼 수도 있다. 콘텐츠 준비 디바이스는 그 다음에, 세트에서의 표현들이 적응 세트를 형성하여서, 적응 세트에서의 표현들이 대역폭 적응을 위해 사용될 수 있다는 것을 나타낼 수도 있다. 다시 말하면, 세트에서의 표현들은 비트레이트에 있서 상이할 수도 있지만, 실질적으로 동일한 특성들을 공유할 수도 있다. 이런 방식으로, 클라이언트 디바이스는 멀티미디어 콘텐츠의 적응 세트들에 대해 공통 특성들의 다양한 세트들을 결정하고, 클라이언트 디바이스의 코딩 및 랜더링 능력들에 기초하여 적응 세트를 선택할 수도 있다. 그러면, 클라이언트 디바이스는 대역폭 가용성에 기초하여 선택된 적응 세트 내의 표현들 사이에서 적응적으로 스위칭할 수도 있다. 대안으로, 본 개시물의 기법들에 따라, 클라이언트 디바이스는 유니캐스트 동안에 표현들 중 하나로부터 데이터를 요청한 다음, 브로드캐스트를 위해 상이한 표현으로 스위칭할 수도 있다.

더구나, 브로드캐스트를 제공하는 서버 디바이스는 네트워크에서의 대역폭 가용성 변경들에 응답하여 표현들 사이를 스위칭함으로써 서버 측 대역폭 적응을 수행할 수도 있다. 예를 들어, 서버 디바이스는 미디어 콘텐츠의 브로드캐스트 또는 멀티캐스트를 수신하고 있는 뷰어들의 수를 나타내는 정보를 수신할 수도 있다. eMBMS와 같은 일부 브로드캐스트 시스템들은 각각의 브로드캐스트 프레젠테이션에 대한 뷰어들의 수를 카운트하기 위해 시그널링한다. 뷰어들의 수가 증가함에 따라, 서버 디바이스는 많은 뷰어들이 콘텐츠를 보고 있어서, 더 큰 대역폭이 비디오에 전용될 수 있다고 결정할 수도 있다 (섹터에서의 사용자들이 적을 수록 그 섹터에서 다른 활동들을 할 가능성이 있기 때문이다). 이 경우, 서비스 제공자는 매우 인기있는 미디어 브로드캐스트의 많은 뷰어들에게 더 많은 만족을 주기 위해 비디오 품질을 업그레이드할 수도 있다. 마찬가지로, 많은 사람들이 미디어 브로드캐스트를 관람하기를 중단하였다고 브로드캐스트 시스템이 결정하면, 그 시스템은 그 섹터에서의 유니캐스트 사용자들에게 더 큰 만족을 주기 위해 비디오 품질 및 비트레이트를 다운그레이드할 수도 있다.

표현들을 위한 데이터는 개개의 파일들로 분리될 수도 있다. 파일들의 각각은 특정 URL (uniform resource locator) 또는 URI (uniform resource identifier) 에 의해 어드레스가능할 수도 있다. 클라이언트 디바이스가 유니캐스트를 이용하여 파일을 취출하기 위해 특정 URL에서 파일에 대한 HTTP GET 요청을 제출할 수도 있다. 대안으로 또는 부가적으로, 클라이언트 디바이스는 브로드캐스트 또는 멀티캐스트 네트워크 그룹에, 대응하는 브로드캐스트 또는 멀티캐스트의 데이터를 취출하기 위해 가입할 수도 있다. 예를 들어, 클라이언트 디바이스는 유니캐스트 취출을 수행하기 위해 HTTP GET 요청들을 이용하여 하나의 표현으로부터 일련의 파일들을 요청할 수도 있는 반면, 상이한 표현으로부터 파일들을 취출하기 위해 브로드캐스트 또는 멀티캐스트 그룹에 동시에 또는 그 뒤에 가입할 수도 있다. 클라이언트 디바이스는 미디어 데이터의 심리스 플레이아웃을 허용하기 위해 브로드캐스트 또는 멀티캐스트의 시간적 로케이션에 인접하지만 그것에 선행하는 시간적 로케이션에 대응하는 유니캐스트를 이용하여 파일들을 취출할 수도 있다. 다시 말하면, 클라이언트 디바이스는 플레이아웃 동안에 유니캐스트 데이터로부터 브로드캐스트 또는 멀티캐스트 데이터로 심리스 스위칭할 수도 있다.

비디오 파일들, 이를테면 미디어 콘텐츠의 표현들의 세그먼트들은, ISO 기반 미디어 파일 포맷, 스케일러블 비디오 코딩 (Scalable Video Coding; SVC) 파일 포맷, 고급 비디오 코딩 (Advanced Video Coding; AVC) 파일 포맷, 3 세대 파트너십 프로젝트 (3GPP) 파일 포맷, 및/또는 멀티뷰 비디오 코딩 (Multiview Video Coding; MVC) 파일 포맷, 또는 다른 유사한 비디오 파일 포맷들 중 임의의 것에 따라 캡슐화된 비디오 데이터에 부합할 수도 있다. 설명 및 예시의 목적을 위해, ISO 기반 미디어 파일 포맷이 아래에서 설명되지만, 다른 포맷들에 부합하는 파일들이 또한 본 개시물의 기법들을 수행하기 위해 사용될 수도 있다는 것이 이해되어야 한다.

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

ISO 기반 미디어 파일 포맷 (및 그 확장물들) 에 부합하는 파일들은 "박스들 (boxes)"이라고 불리는 일련의 객체들인, 고유 유형 식별자 및 길이에 의해 정의된 객체지향 구축 블록들로서 형성될 수도 있다. ISO 기반 미디어 파일 포맷에서의 데이터는 박스들에 포함될 수도 있어서, 다른 데이터가 그 파일 내에 포함될 필요가 없고 박스들 외부의 데이터가 파일 내에 있을 필요가 없다. 이는 특정 파일 포맷에 의해 요구된 임의의 초기 시그너처를 포함한다. 통상적으로, 프레젠테이션은 하나의 파일 내에 포함되고, 미디어 프레젠테이션은 자체 포함된다. 무비 컨테이너 (무비 박스) 는 미디어의 메타데이터를 포함할 수도 있고 비디오 및 오디오 프레임들은 미디어 데이터 컨테이너에 포함될 수도 있고 다른 파일들 내에 있을 수 있다.

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

HTTP 스트리밍에서, 미디어 프레젠테이션은 클라이언트에 액세스가능한 데이터의 구조화된 수집물일 수도 있다. 클라이언트는 스트리밍 서비스를 사용자에게 제시하기 위해 미디어 데이터 정보를 요청하고 다운로드할 수도 있다. HTTP를 이용하는 유니캐스트 스트리밍 전달에서, 빈번하게 이용되는 동작들은 GET 및 부분적 GET을 포함한다. GET 동작은 주어진 URL (uniform resource locator) 에 연관된 전체 파일을 취출한다. 부분적 GET 동작은 입력 파라미터로서 바이트 범위를 포함하고 특정된 바이트 범위에 대응하는 파일의 연속하는 다수의 바이트들을 취출한다. 따라서, 무비 프래그먼트들이 HTTP 스트리밍을 위해 제공될 수도 있는데, 부분적 GET 동작이 하나 이상의 개개의 무비 프래그먼트들을 취출할 수 있기 때문이다. 무비 프래그먼트에서는, 상이한 트랙들의 여러 트랙 프래그먼트들이 있을 수 있다는 점에 주의한다.

DASH의 예에서, 멀티미디어 콘텐츠 (또한 미디어 콘텐츠라고 지칭됨) 의 비디오 및/또는 오디오 데이터에 대해 다수의 표현들이 있을 수도 있다. 그런 표현들의 매니패스트는 미디어 프레젠테이션 디스크립션 (MPD) 데이터 구조에서 정의된다. 미디어 프레젠테이션은 HTTP 스트리밍 클라이언트 디바이스에 액세스가능한 데이터의 구조화된 수집물에 대응할 수도 있다. HTTP 스트리밍 클라이언트 디바이스는 스트리밍 서비스를 클라이언트 디바이스의 사용자에게 제시하기 위해 미디어 데이터 정보를 요청하고 다운로드할 수도 있다. MPD 데이터 구조는 미디어 콘텐츠의 각각의 표현의 코딩 및 랜더링 특성들을 서술한다. 덧붙여서, 본 개시물의 기법들에 따라, 서버 디바이스는, 예컨대, 브로드캐스트 또는 멀티캐스트를 수신하기 위한 충분한 정보를 클라이언트 디바이스에 제공하기 위해, 브로드캐스트 또는 멀티캐스트의 특성들을 서술하는 데이터를 제공할 수도 있다. 예를 들어, 데이터는 클라이언트 디바이스들이 멀티캐스트에 참가하기 위해 사용할 수도 있는 멀티캐스트 어드레스를 포함할 수도 있다.

미디어 프레젠테이션은 하나 이상의 기간들의 시퀀스를 포함할 수도 있다. 각각의 기간은 동일한 미디어 콘텐츠에 대해 하나 이상의 표현들을 포함할 수도 있다. 표현은 오디오 또는 비디오 데이터의 다수의 대안적 인코딩된 버전들 중 하나일 수도 있다. 그 표현들은 인코딩 유형들에 의해, 예컨대, 비디오 데이터에 대한 비트레이트, 해상도, 및/또는 코덱과, 오디오 데이터에 대한 비트레이트, 언어, 및/또는 코덱에 의해 상이할 수도 있다. 용어 표현 (representation) 은 멀티미디어 콘텐츠의 특정 기간에 대응하고 특정 방법으로 인코딩되는 인코딩된 오디오 또는 비디오 데이터의 섹션을 말하는데 이용될 수도 있다.

특정 기간의 표현들은 (적응 세트를 식별할 수도 있는) MPD에서의 그룹 속성에 의해 나타내어진 그룹에 할당될 수도 있다. 동일한 그룹 (또는 적응 세트) 내의 표현들은 일반적으로 서로 대체물들로서 간주된다. 예를 들어, 특정 기간 동안의 비디오 데이터의 각각의 표현은 동일한 그룹에 할당될 수도 있어서, 그 표현들 중 임의의 것은 대응하는 기간 동안의 멀티미디어 콘텐츠의 비디오 데이터를 디스플레이하기 위해 디코딩을 위해 선택될 수도 있다. 하나의 기간 내의 미디어 콘텐츠는, 일부 예들에서, 그룹 0이 존재한다면 그 그룹 0으로부터의 하나의 표현, 또는 각각의 영 아닌 그룹으로부터의 많아야 하나의 표현의 조합 중 어느 하나에 의해 표현될 수도 있다. 기간의 각각의 표현에 대한 타이밍 데이터는 기간의 시작 시간을 기준으로 표현될 수도 있다.

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

각각의 표현은 또한 하나 이상의 미디어 컴포넌트들을 포함할 수도 있으며, 여기서 각각의 미디어 컴포넌트는 오디오, 비디오, 또는 (예컨대, 폐쇄형 자막화 (closed captioning) 를 위한) 타이밍된 (timed) 텍스트와 같은 하나의 개개의 미디어 유형의 인코딩된 버전일 수도 있다. 미디어 컴포넌트들은 하나의 표현 내에서 연속적인 미디어 세그먼트들의 경계들에 걸쳐서 시간 연속적일 수도 있다.

본 개시물의 기법들 중 임의의 것 또는 모두는 다양한 시나리오들에서 사용될 수도 있다. 예를 들어, 유니캐스트로부터 멀티캐스트 또는 브로드캐스트로 스위칭하는 기법들은, 예컨대, 비디오 스트리밍의 초기 시작에 의존하여 또는 채널 변경에 응답하여, 브로드캐스트 또는 멀티캐스트에서 후속 스위치 포인트 (또는 IDR 화상) 를 "잡아내기 (catch up)" 위해 사용될 수도 있다. 이들 기법들은 또한 다양한 채널들이 이용가능한 경우에 이용될 수도 있다. 예를 들어, 클라이언트 디바이스가 유니캐스트를 통해 복수의 상이한 미디어 콘텐츠들의 처음 몇 초에 대응하는 데이터를 취출할 수도 있다. 그러면, 사용자가 복수의 미디어 콘텐츠들 중 하나를 선택한 후, 클라이언트 디바이스는 유니캐스트를 통해 수신된 선택된 미디어 콘텐츠에 대한 데이터를 디스플레이하면서 미디어 콘텐츠의 브로드캐스트 또는 멀티캐스트에 가입할 수도 있다. 일부 예들에서, 클라이언트 디바이스는, 비디오 기반 선택 메뉴를 사용자에게 제공하기 위해, 복수의 미디어 콘텐츠들의 각각을 위한 취출된 유니캐스트 데이터에 대응하는, 복수의 미디어 콘텐츠들의 각각을 위한 비디오 클립들을 갖는 메뉴를 제시할 수도 있다.

다른 예로서, 이들 기법들은 네트워크 백홀의 기지국들 사이에서의 핸드오버 또는 핸드오프 동안에 적용될 수도 있다. 일부 기지국들은 멀티캐스트 또는 브로드캐스트를 제공할 수도 있는 반면, 다른 기지국들은 유니캐스트만을 제공할 수도 있다. 본 개시물의 기법들에 따라, 클라이언트 디바이스는 핸드오버 또는 핸드오프가 기지국들 사이에서 발생하였거나 또는 이제 막 발생하려고 한다고 결정하고, 이 결정에 응답하여 브로드캐스트 및 유니캐스트 사이를 심리스 스위칭할 수도 있다. 예를 들어, 브로드캐스트 또는 멀티캐스트 전송을 제공하는 기지국으로부터 유니캐스트 전송만을 제공하는 기지국으로 스위칭하는 경우, 클라이언트 디바이스는 미디어 콘텐츠의 유니캐스트 스트리밍을 시작할 수도 있다. 다른 예로서, 유니캐스트 전송만을 제공하는 기지국으로부터 브로드캐스트 또는 멀티캐스트 전송을 제공하는 기지국으로 스위칭하는 경우, 클라이언트 디바이스는 그에 따라, 브로드캐스트 또는 멀티캐스트를 통해 미디어 데이터를 수신하는 것을 시작할 수도 있다.

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

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

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

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

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

많은 비디오 코딩 표준들에서와 같이, H.264/AVC는 에러 없는 비트스트림들을 위한 신택스, 시맨틱스, 및 디코딩 프로세스를 그것들 중의 임의의 것이 특정 프로파일 또는 레벨을 따르게끔 정의한다. H.264/AVC는 인코더를 특정하지 않지만, 인코더에는 생성된 비트스트림들이 디코더에 부합하는 표준들이라는 것을 보장하는 임무가 주어진다. 비디오 코딩 표준의 측면에서, "프로파일"은 알고리즘들, 특징들 (features), 또는 도구들 및 그것들에 적용되는 제약들의 서브세트에 해당한다. H.264 표준에 의해 정의된 바와 같이, 예를 들어, "프로파일"은 H.264 표준에 의해 특정되는 전체 비트스트림 신택스의 서브세트이다. "레벨"은 예를 들어, 디코더 메모리 및 컴퓨테이션과 같은 디코더 자원 소비의 한계들에 대응하며, 이 한계들은 화상들의 해상도, 비트 레이트, 및 매크로블록 (MB) 프로세싱 레이트에 관련된다. 프로파일은 profile_idc (프로파일 표시자) 값으로 시그널링될 수도 있는 반면, 레벨은 level_idc (레벨 표시자) 값으로 시그널링될 수도 있다.

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

프로파일에 부합하는 디코더는 보통은 프로파일에서 정의된 모든 특징들을 지지한다. 예를 들어, 코딩 특징으로서, 양방향 예측 코딩은 H.264/AVC의 베이스라인 프로파일에서 지원되지 않지만 H.264/AVC의 다른 프로파일들에서 지원된다. 특정 레벨에 부합하는 디코더는 그 레벨에서 정의된 한계들을 넘어서게 자원들을 요청하지 않는 임의의 비트스트림을 디코딩하는 것이 가능해야 한다. 프로파일들 및 레벨들의 정의들은 해석능력 (interpretability) 에 도움이 될 수도 있다. 예를 들어, 비디오 송신 동안, 한 쌍의 프로파일 및 레벨 정의들은 전체 송신 세션 동안에 협상되고 합의될 수도 있다. 더 구체적으로는, H.264/AVC에서, 레벨은 예를 들어, 처리될 것이 필요한 블록들의 수, 디코딩된 화상 버퍼 (decoded picture buffer; DPB) 사이즈, 코딩된 화상 버퍼 (coded picture buffer; CPB) 사이즈, 수직 움직임 벡터 범위, 2 개의 연속적인 MB들 당 움직임 벡터들의 최대 수, 및 양방향 예측된 블록이 8x8 화소들 미만의 서브-블록 파티션들을 가질 수 있는지의 여부에 관한 한계들을 정의할 수도 있다. 이런 방식으로, 디코더는 디코더가 비트스트림을 적절히 디코딩하는 것이 가능한지의 여부를 결정할 수도 있다.

ITU-T H.261, H.262, H.263, MPEG-1, MPEG-2, H.264/MPEG-4 파트 10, 및 다가오는 고 효율 비디오 코딩 (HEVC) 과 같은 비디오 압축 표준들은 시간적 리던던시를 줄이기 위해 움직임 보상된 시간적 예측을 이용한다. 인코더, 이를테면 비디오 인코더 (28) 는 움직임 벡터들에 따라 현재 코딩된 화상들을 예측하기 위해 일부의 이전에 인코딩된 화상들 (본원에서는 프레임들이라고도 지칭됨) 로부터의 움직임 보상된 예측을 이용할 수도 있다. 전형적인 비디오 코딩에는 3 가지 주요 화상 유형들이 존재한다. 그것들은 인트라 코딩된 화상 ("I-화상들" 또는 "I-프레임들"), 예측된 화상들 ("P-화상들" 또는 "P-프레임들") 및 양방향 예측된 화상들 ("B-화상들" 또는 "B-프레임들") 이다. P-화상들은 시간적 순서에서 현재 화상 앞의 참조 화상만을 사용할 수도 있다. B-화상에서, B-화상의 각각의 블록은 하나 이상의 참조 화상들로부터 예측될 수도 있다. 이들 참조 화상들은 시간적 순서에서 현재 화상 앞 또는 뒤에 위치될 수 있다.

파라미터 세트들은 일반적으로 시퀀스-계층 헤더 정보를 시퀀스 파라미터 세트들 (sequence parameter sets; SPS) 내에 그리고 드물게 변경되는 화상-계층 헤더 정보를 화상 파라미터 세트들 (picture parameter sets; PPS) 내에 포함한다. 파라미터 세트들로, 이 드물게 변경되는 정보는 각각의 시퀀스 또는 화상에 대해 반복될 필요는 없고; 그래서, 코딩 효율이 개선될 수도 있다. 더욱이, 파라미터 세트들의 이용은 헤더 정보의 대역 외 송신을 가능할 수도 있게 함으로써, 불필요한 송신들이 필요 없게 하여 에러 내성을 달성할 수도 있다. 대역 외 송신에서, 파라미터 세트 네트워크 추상화 계층 (network abstraction layer; NAL) 단위들은 다른 NAL 단위들과는 상이한 채널로 송신된다.

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

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

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

캡슐화 유닛 (30) 은 매니패스트 파일 (예컨대, MPD) 과 함께, 멀티미디어 콘텐츠의 하나 이상의 표현들을 위한 데이터를 출력 인터페이스 (32) 로 제공할 수도 있다. 출력 인터페이스 (32) 는 네트워크 인터페이스 또는 저장 매체에 기록하기 위한 인터페이스, 이를테면 범용 직렬 버스 (USB) 인터페이스, CD 또는 DVD 라이터 또는 버너, 자기적 또는 플래시 저장 매체들에 대한 인터페이스, 또는 미디어 데이터를 저장하고 송신하기 위한 다른 인터페이스들을 포함할 수도 있다. 캡슐화 유닛 (30) 은 멀티미디어 콘텐츠의 표현들의 각각의 데이터를 출력 인터페이스 (32) 로 제공할 수도 있으며, 그 출력 인터페이스는 그 데이터를 네트워크 송신 또는 저장 매체들을 통해 서버 디바이스 (60) 로 전송할 수도 있다.

도 1의 예에서, 서버 디바이스 (60) 는, 각각이 개별 매니패스트 파일 (66) 및 하나 이상의 표현들 (68A-68N) (표현들 (68)) 을 포함하는, 다양한 멀티미디어 콘텐츠들 (64) 을 저장하는 저장 매체 (62) 를 구비한다. 본 개시물의 기법들에 따라, 매니패스트 파일 (66) 의 부분들은 별개의 로케이션들, 예컨대, 잠재적으로는 프록시 디바이스와 같은 네트워크 (74) 의 다른 디바이스의 저장 매체 (62) 또는 다른 저장 매체의 로케이션들에 저장될 수도 있다.

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

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

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

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

요청 프로세싱 유닛 (70) 은 표현들 (68) 중 하나의 표현의 세그먼트의 헤더 데이터를 제공하기 위해 HTTP HEAD 요청들을 서비스하도록 추가로 구성될 수도 있다. 어쨌든, 요청 프로세싱 유닛 (70) 은 요청된 데이터를 요청하는 디바이스, 이를테면 클라이언트 디바이스 (40) 에 제공하기 위해 요청들을 처리하도록 구성될 수도 있다.

본 개시물의 기법들에 따라, 서버 디바이스 (60) 는 또한 브로드캐스트 또는 멀티캐스트 서버로서 역할을 할 수도 있다. 대안으로, 별개의 디바이스가, 예컨대, 아래에서 도 3을 참조하여 설명되는 바와 같이, 브로드캐스트 또는 멀티캐스트 서버로서 역할을 할 수도 있다. 어떤 경우에는, 서버 디바이스, 이를테면 서버 디바이스 (60) 는, 하나 이상의 표현들의 데이터를 브로드캐스트 또는 멀티캐스트하기 위해 하나 이상의 브로드캐스트 또는 멀티캐스트 프로토콜들을 구현할 수도 있다.

예를 들어, 클라이언트 디바이스 (40) 는 멀티캐스트 그룹에 참가할 수도 있고, 서버 디바이스 (60) 는 표현들 (68) 중 하나의 표현의 데이터를 멀티캐스트 그룹으로 전송할 수도 있다. 네트워크 (74) 의 네트워크 디바이스, 이를테면 라우터는, 멀티캐스트 그룹으로 전송되는 데이터를 멀티캐스트 그룹에 가입한 디바이스들로 향하게 할 수도 있다. 따라서, 클라이언트 디바이스 (40) 가 멀티캐스트 그룹에 참가하고, 서버 디바이스 (60) 가 표현들 (68) 중 하나의 표현의 데이터를 멀티캐스트 그룹에 (예컨대, 그 데이터를 그 멀티캐스트 그룹의 IP 주소로 어드레싱함으로써) 전송하는 경우, 네트워크 (74) 의 라우터들은 별개의 네트워크 루트들을 따라 놓여 있어, 궁극적으로는 클라이언트 디바이스 (40) 에 다다르고 있는 멀티캐스트 그룹의 맴버들을 위해 데이터를 복제할 수도 있다.

서버 디바이스 (60), 클라이언트 디바이스 (40), 및 네트워크 (74) 의 디바이스들 (이를테면 라우터들) 은, IPv4 네트워크들을 통한 멀티캐스트를 수행하기 위해, 예컨대, Cain 등의 "Internet Group Management Protocol, Version 3", Internet Engineering Task Force, Network Working Group, RFC 3376, 2002년 10월에 기재된 바와 같이 인터넷 그룹 관리 프로토콜 (IGMP) 을, 그리고/또는 IPv6 네트워크들을 통한 멀티캐스트를 수행하기 위해, 예컨대, Vida 등.의 "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Internet Engineering Task Force, Network Working Group, RFC 2710, 1999년 10월에 기재된 바와 같이 멀티캐스트 청자 디스커버리 (MLD) 를 구현할 수도 있다. IGMP 및 MLD를 사용하는 멀티캐스트의 부가적인 세부사항들은 Holbrook 등의 "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source-Specific Multicast", Internet Engineering Task Force, Network Working Group, RFC 4604, 2006년 8월에 기재되어 있다.

다른 예로서, 서버 디바이스 (60), 또는 별개의 서버 디바이스는, 표현들 (68) 중 하나의 표현의 데이터를 브로드캐스트 도메인으로 전송할 수도 있어서, 브로드캐스트 도메인의 모든 맴버들 (예컨대, 클라이언트 디바이스 (40)) 은 브로드캐스트 데이터를 수신한다. 네트워크 (74) 내의 라우터들은 네트워크 (74) 를 브로드캐스트 도메인들로 분할할 수도 있다. 일부 예들에서, 서버 디바이스 (60) 는 가상 로컬 영역 네트워크 (VLAN) 를 제공할 수도 있고, 클라이언트 디바이스 (40) 와 같은 클라이언트 디바이스들은 네트워크 브로드캐스트 데이터를 수신하기 위하여 VLAN에 참가할 수도 있다.

도 1의 예에서 도시된 바와 같이, 멀티미디어 콘텐츠 (64) 는, 미디어 프레젠테이션 디스크립션 (MPD) 에 대응할 수도 있는 매니패스트 파일 (66) 을 포함한다. 매니패스트 파일 (66) 은 상이한 대안적 표현들 (68) (예컨대, 상이한 품질들을 갖는 비디오 서비스들) 의 서술들을 포함할 수도 있고, 그 서술은, 예컨대, 코덱 정보, 프로파일 값, 레벨 값, 비트레이트, 및 표현들 (68) 의 다른 서술적 특성들을 포함할 수도 있다. 클라이언트 디바이스 (40) 는 미디어 프레젠테이션의 MPD를 취출하여 프레젠테이션들 (68) 의 세그먼트들에 액세스하는 방법을 결정할 수도 있다.

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

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

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

본 개시물의 기법들에 따라, 웹 애플리케이션 (52) 은 서버 디바이스 (60) (또는 다른 서버 디바이스) 에 의해 송신된 브로드캐스트 또는 멀티캐스트 데이터를 수신할 것을 요청하도록 구성될 수도 있다. 예를 들어, 웹 애플리케이션 (52) 은, 멀티캐스트 그룹에 참가하기 위한 데이터 (이를테면 멀티캐스트 그룹 IP 주소) 또는 브로드캐스트를 수신하기 위한 데이터 (예컨대, 브로드캐스트 도메인 또는 VLAN에 참가하기 위한 데이터) 를 포함할 수도 있는, 매니패스트 파일 (66) 을 위한 데이터를 처음에 취출하도록 구성될 수도 있다. 더구나, 웹 애플리케이션 (52), 또는 클라이언트 디바이스 (40) 의 다른 애플리케이션 또는 시스템 소프트웨어는, 파일 전달 프로토콜, 이를테면 FLUTE 프로토콜을 구현하도록 구성될 수도 있다. 이런 방식으로, 클라이언트 디바이스 (40) 는 FLUTE 프로토콜을 통해 브로드캐스트 또는 멀티캐스트를 이용하여 멀티미디어 콘텐츠 (64) 의 데이터를 취출하도록 구성될 수도 있다. FLUTE를 파일 전달 서비스로서 활용하기 위해, 서버 디바이스 (60) 는 미디어 콘텐츠 (62) 에 대한 하나 이상의 유니캐스트 URL들 (uniform resource locators) 을 나타내는 속성들을 포함하는 파일 전달 테이블 (File Delivery Table; FDT) 을 클라이언트 디바이스 (40) 로 제공할 수도 있다.

본 개시물의 기법들에 따라서, 표현들 (68) 중 상이한 것들은 (랜덤 액세스 포인트들 (RAPs) 이라고도 지칭되며, 순간 디코더 리프레시 (IDR), 개방 디코더 리프레시 (ODR), 및/또는 청정 랜덤 액세스 (CRA) 화상들을 포함할 수도 있는) 스위치 포인트들의 상이한 시간적 빈도수들을 가질 수도 있다. 예를 들어, 표현 (68A) 은 플레이백 시간의 측면에서 대략 1 초 간격들로 발생하는 스위치 포인트들을 포함할 수도 있는 반면, 표현 (68N) 은 다시 플레이백 시간의 측면에서 대략 10 초의 간격들로 발생하는 스위치 포인트들을 포함할 수도 있다. 서버 디바이스 (60) 는 예컨대, 플레이백 시간의 측면에서 10 초마다 스위치 포인트들의 비교적 낮은 빈도수를 갖는 표현들 (68) 중 하나로부터 데이터를 브로드캐스트할 수도 있다.

본 개시물의 기법들에 따라, 클라이언트 디바이스 (40) 는 충분한 양의 데이터가 버퍼링되기까지 높은 빈도수의 스위치 포인트들을 갖는 표현들 (68) 중 하나로부터 데이터를 요청한 다음, 브로드캐스트 또는 멀티캐스트로 스위칭할 수도 있다. 비록 높은 빈도수의 스위치 포인트들을 갖는 표현의 데이터가 비교적 낮은 품질을 가질 수도 있지만, 클라이언트 디바이스 (40) 가 비교적 높은 품질 표현의 스위치 포인트가 도래하기까지 기다리는 동안에 블랭크 스크린을 보는 것보다는, 비교적 낮은 품질이라 하더라도, 사용자 경험은 적어도 일부 비디오 데이터를 봄으로써 개선될 수도 있다. 물론, (FLUTE 프로토콜에 따라 브로드캐스트 또는 멀티캐스트를 통해 수신될 수도 있는) 비교적 높은 품질 표현의 스위치 포인트를 수신한 후, 클라이언트 디바이스 (40) 는 그 표현으로 스위칭할 수도 있다.

가끔은, 클라이언트 디바이스 (40) 의 사용자는 멀티미디어 콘텐츠, 이를테면 멀티미디어 콘텐츠 (64) 를 요청하기 위해, 클라이언트 디바이스 (40) 의 사용자 인터페이스들, 이를테면 키보드, 마우스, 스타일러스, 터치스크린 인터페이스, 버튼들, 또는 다른 인터페이스들을 이용하여 웹 애플리케이션 (52) 과 상호작용할 수도 있다. 사용자로부터의 그런 요청들에 응답하여, 웹 애플리케이션 (52) 은, 예컨대, 클라이언트 디바이스 (40) 의 디코딩 및 랜더링 능력들에 기초하여 표현들 (68) 중 하나를 선택할 수도 있다. 표현들 (68) 중 선택된 하나의 표현의 데이터를 취출하기 위해, 웹 애플리케이션 (52) 은 표현들 (68) 중 선택된 하나의 표현의 특정 바이트 범위들을 순차적으로 요청할 수도 있다. 이런 방식으로, 하나의 요청을 통해 완전한 파일을 수신하기 보다는, 웹 애플리케이션 (52) 은 다수의 요청들을 통해 파일의 부분들을 순차적으로 수신할 수도 있다.

위에서 지적했듯이, 표현들 (68) 은 다양한 코딩 및 랜더링 특성들의 비디오 데이터를 포함할 수도 있다. 적응 세트의 표현들은 대역폭 적응을 허용할 수도 있는 가변하는 비트레이트들을 가질 수도 있다. 기존의 DASH 기법들에서, 이는 클라이언트 디바이스가 이용가능한 대역폭의 현재의 양에 의해 최상으로 수용될 수 있는 비트레이트를 갖는 표현으로부터 데이터를 취출함으로써 대역폭 가용성을 변경시키는 것에 적응하는 것을 허용한다. 본 개시물의 기법들에 따라, 서버 디바이스 (60) 는 대역폭 적응을 수행하도록 구성될 수도 있다. 예를 들어, 서버 디바이스 (60) 는 네트워크 대역폭의 현재의 양을 나타내는 정보를 수신하고, 그에 따라 표현들 (68) 중 하나를 선택할 수도 있다. 따라서, 이용가능한 대역폭이 증가한다면, 서버 디바이스 (60) 는 비교적 높은 비트레이트를 갖는 표현들 (68) 중 하나의 표현의 데이터를 브로드캐스트 또는 멀티캐스트하기 시작할 수도 있는 반면, 이용가능한 대역폭이 감소한다면, 서버 디바이스 (60) 는 비교적 낮은 비트레이트를 갖는 표현들 (68) 중 하나의 표현의 데이터를 브로드캐스트 또는 멀티캐스트하기 시작할 수도 있다.

네트워크 인터페이스 (54) 는, 브로드캐스트이든, 멀티캐스트이든, 또는 유니캐스트이든, 서버 디바이스 (60) (또는 다른 서버 디바이스) 로부터 전송된 데이터를 수신할 수도 있다. 특히, 네트워크 인터페이스 (54) 는 표현들 (68) 의 수신된 세그먼트들의 데이터를 수신하고 웹 애플리케이션 (52) 에 제공할 수도 있다. 웹 애플리케이션 (52) 은 다음에는 그 세그먼트들을 역캡슐화 유닛 (50) 으로 제공할 수도 있다. 역캡슐화 유닛 (50) 은 비디오 파일의 엘리먼트들을 구성성분인 PES 스트림들로 역캡슐화하며, PES 스트림들을 패킷해제하여 인코딩된 데이터를 취출하고, 예컨대, 스트림의 PES 패킷 헤더들에 의해 나타내어진 바와 같이, 인코딩된 데이터가 오디오 스트림의 부분인지 또는 비디오 스트림의 부분인지에 따라, 오디오 디코더 (46) 또는 비디오 디코더 (48) 중 어느 하나에 인코딩된 데이터를 전송할 수도 있다. 오디오 디코더 (46) 는 인코딩된 오디오 데이터를 디코딩하고 디코딩된 오디오 데이터를 오디오 출력부 (42) 에 전송하는 한편, 비디오 디코더 (48) 는 인코딩된 비디오 데이터를 디코딩하고 스트림의 복수의 뷰들을 포함할 수도 있는 디코딩된 비디오 데이터를 비디오 출력부 (44) 에 전송한다.

더구나, 본 개시물의 기법들에 따라, 웹 애플리케이션 (52) 은 FLUTE를 통해 멀티캐스트 또는 브로드캐스트에 따라 수신된 데이터를, 예컨대, 클라이언트 디바이스 (40) 의 플래시 메모리 (미도시) 에 캐싱할 수도 있다. 클라이언트 디바이스 (40) 는 기간 동안 브로드캐스트 또는 멀티캐스트를 통해 수신된 데이터를 저장하기 위한 하나 이상의 컴퓨터-판독가능 저장 매체들, 이를테면 플래시 메모리를 구비할 수도 있다. 이런 방식으로, 사용자는 서버 디바이스 (60) (또는 다른 서버 디바이스) 에 의해 브로드캐스트 또는 멀티캐스트되고 있는 데이터를 보기 위해 초기에 요청할 수도 있다. 클라이언트 디바이스 (40) 는 그 다음에 수신된 데이터를 캐싱할 수도 있다. 따라서, 사용자가 그 뒤에 데이터를 보기 위해 요청한다면, 클라이언트 디바이스 (40) 는 다시 데이터를 취출하도록 요청하기 보다는, 클라이언트 디바이스 (40) 내부의 저장 매체들, 예컨대, 플래시 메모리로부터 데이터를 취출할 수도 있다.

서버 디바이스 (60) 는 FLUTE 프로토콜을 통해 비디오 데이터를 브로드캐스트 또는 멀티캐스트하는 경우에 캐싱 프리미티브들 (primitives) 을 제공할 수도 있다. 캐싱 프리미티브들은 그 데이터를 저장하기 위한 시간의 길이, 데이터가 만료될 때의 표시 (예컨대, "만료" 프리미티브), 데이터의 생성 날짜, 데이터의 송신 날짜, 미디어 콘텐츠의 특정 버전을 식별하는 엔티티 태그 (ETag), 미디어 콘텐츠의 데이터가 캐시가능함을 나타내는 캐시-제어 헤더, 또는 다른 그러한 정보 중 하나 이상을 나타내는 값들을 포함할 수도 있다. 따라서, 클라이언트 디바이스 (40) 는 데이터를 캐싱하는 방법, 및 기간을 결정하기 위해 캐싱 프리미티브들을 이용할 수도 있다. 비슷하게, 네트워크 (74) 의 중간 네트워크 디바이스들, 이를테면 라우터들, 프록시 디바이스들, 캐싱 디바이스들, 또는 다른 그런 네트워크 디바이스들이, 또한 데이터를 캐싱하기 위해 캐싱 프리미티브들을 이용할 수도 있다. 따라서, 클라이언트 디바이스가, 예컨대, 유니캐스트를 이용하여 데이터를 요청했었다면, 그 데이터를 캐싱했던 중간 네트워크 디바이스들은 서버 디바이스 (60) 에 요청을 포워딩하기 보다는, 데이터를 클라이언트 디바이스로 전달할 수 있다.

비디오 인코더 (28), 비디오 디코더 (48), 오디오 인코더 (26), 오디오 디코더 (46), 캡슐화 유닛 (30), 웹 애플리케이션 (52), 및 역캡슐화 유닛 (50) 각각은, 적용가능한 대로 다양한 적합한 프로세싱 회로 (circuitry) 중 임의의 것, 이를테면 하나 이상의 마이크로프로세서들, 디지털 신호 프로세서들 (DSP들), 주문형 집적회로들 (ASIC들), 필드 프로그램가능 게이트 어레이들 (FPGA들), 개별 로직 회로, 소프트웨어, 하드웨어, 펌웨어 또는 그것들의 임의의 조합들로서 구현될 수도 있다. 비디오 인코더 (28) 및 비디오 디코더 (48) 의 각각은 하나 이상의 인코더들 또는 디코더들 내에 구비될 수도 있고, 그것들 중 어느 하나는 결합형 비디오 인코더/디코더 (CODEC) 의 부분으로서 통합될 수도 있다. 비슷하게, 오디오 인코더 (26) 및 오디오 디코더 (46) 의 각각은 하나 이상의 인코더들 또는 디코더들 내에 구비될 수 있고, 그것들 중 어느 하나는 결합형 CODEC의 부분으로서 통합될 수도 있다. 비디오 인코더 (28), 비디오 디코더 (48), 오디오 인코더 (26), 오디오 디코더 (46), 캡슐화 유닛 (30), 웹 애플리케이션 (52), 및/또는 역캡슐화 유닛 (50) 을 구비한 장치는 집적회로, 마이크로프로세서, 및/또는 무선 통신 디바이스, 이를테면 셀룰러 전화기를 포함할 수도 있다.

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

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

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

프록시 캐시 디바이스 (82) 는 프록시 캐싱 기능들을 수행할 수도 있다. HTTP 프록시 캐싱은 인터넷이 동작하게 하는데 중요하다. HTTP 프록시 캐시 디바이스들, 이를테면 프록시 캐시 디바이스 (82) 는, 임의의 또는 모든 HTTP 프로토콜 버전들 (예컨대, HTTP 0.9, HTTP 1.0, 및/또는 HTTP 1.1) 을 구현할 수도 있다. 본 개시물의 기법들에 따라, 프록시 캐시 디바이스 (82) 는 유니캐스트, 브로드캐스트, 또는 멀티캐스트를 통해 수신된 미디어 콘텐츠의 데이터를 캐싱할 수도 있다. 예를 들어, 프록시 캐시 디바이스 (82) 는 FLUTE 프로토콜에 따라 교환되는 데이터를 캐싱하도록 구성될 수도 있다. 이런 방식으로, 프록시 캐시 디바이스 (82) 는 HTTP에 따라 교환되는 유니캐스트 데이터 및 FLUTE에 따라 교환되는 멀티캐스트 또는 브로드캐스트 데이터 양쪽 모두를 캐싱할 수도 있다.

더구나, 본 개시물의 기법들에 따라, 라우팅 디바이스들, 이를테면 라우팅 디바이스 (80B) 는, 멀티캐스트 또는 브로드캐스트 데이터를 수신하기 위한, 클라이언트 디바이스들, 이를테면 클라이언트 디바이스 (40) 에 의한 요청들을 수락하도록 구성될 수도 있다. 예를 들어, 라우팅 디바이스 (80B) 는 클라이언트 디바이스들, 이를테면 클라이언트 디바이스 (40) 로부터 멀티캐스트 그룹에 대한 IGMP 참가 요청들을 수신하도록 구성될 수도 있다. 라우팅 디바이스 (80B) 는 또한 서버 디바이스 (60) 로부터 멀티캐스트 그룹의 데이터를 수신하도록 구성될 수도 있다. 그런 데이터를 수신하는 것에 응답하여, 라우팅 디바이스 (80B) 는 멀티캐스트 그룹에 참가할 것을 요청한 각각의 클라이언트 디바이스에 수신된 데이터를 복사하여 포워딩할 수도 있다. 따라서, 부가적인 클라이언트 디바이스들이 (직접 또는 간접적으로) 라우팅 디바이스 (80B) 에 통신적으로 연결된다고 가정하면, 라우팅 디바이스 (80B) 는 대응하는 멀티캐스트 그룹에 참가한 클라이언트 디바이스들의 각각에 멀티캐스트 데이터를 복사하고 포워딩할 것이다. 라우팅 디바이스 (80A) 는 또한, 예컨대, 멀티캐스트 지원을 위한 IGMP을 구현하기 위해 라우팅 디바이스 (80B) 와 유사하게 구성될 수도 있다. 더욱이, 다른 클라이언트 디바이스들은 (직접 또는 간접적으로) 라우팅 디바이스 (80A) 에 통신적으로 연결될 수도 있다.

도 3은 2 개의 서버 디바이스들이 미디어 콘텐츠의 데이터를 클라이언트 디바이스 (40) 에 제공하는 일 예를 도시하는 블록도이다. 특히, 도 3의 예는 브로드캐스트 서버 디바이스 (90) 및 유니캐스트 서버 디바이스 (92) 를 예시한다. 일부 예들에서, 브로드캐스트 서버 디바이스 (90) 와 유니캐스트 서버 디바이스 (92) 는 동일한 콘텐츠 전달 네트워크의 부분을 형성한다. 브로드캐스트 서버 디바이스 (90) 및 유니캐스트 서버 디바이스 (92) 양쪽 모두는 도 1 및 도 2의 서버 디바이스 (60) 와 유사하게 구성될 수도 있다. 대안으로, 브로드캐스트 서버 디바이스 (90) 는 오직 네트워크 브로드캐스트 또는 멀티캐스트의 형태로 미디어 데이터를 출력하도록 구성되는 반면, 유니캐스트 서버 디바이스 (92) 는, 예컨대, 클라이언트 디바이스 (40) 로부터의 요청들에 응답하여, 오직 유니캐스트의 형태로 미디어 데이터를 출력하도록 구성될 수도 있다.

도 3의 예에서, 브로드캐스트 서버 디바이스 (90) 및 유니캐스트 서버 디바이스 (92) 양쪽 모두는 콘텐츠 준비 디바이스 (20) 로부터 미디어 데이터를 수신한다. 브로드캐스트 서버 디바이스 (90) 및 유니캐스트 서버 디바이스 (92) 는 동일한 미디어 데이터, 또는 미디어 데이터의 상이한 표현들을 수신할 수도 있다. 브로드캐스트 서버 디바이스라고 지칭되지만, 브로드캐스트 서버 디바이스 (90) 는, 부가적으로 또는 대안으로, 멀티캐스트에 따라 데이터를 출력하도록 구성될 수도 있다. 더욱이, 브로드캐스트 서버 디바이스 (90) 는 FLUTE 프로토콜에 따라 미디어 데이터를 멀티캐스트 또는 브로드캐스트하도록 구성될 수도 있다.

본 개시물의 기법들에 따라, 클라이언트 디바이스 (40) 는 MPD 파일 (예컨대, 도 1의 매니패스트 파일 (66) 에 대응하는 파일) 을 취출하기 위해 웹 페이지 또는 다른 네트워크 로케이션에 액세스할 수도 있다. 웹 페이지는 유니캐스트 서버 디바이스 (92) 에 의해 호스팅될 수도 있다. 클라이언트 디바이스는 유니캐스트 서버 디바이스 (92) 로부터 미디어 콘텐츠의 데이터를 취출하기 위해 그리고/또는 브로드캐스트 서버 디바이스 (90) 로부터 미디어 콘텐츠의 데이터를 수신하기 위해 MPD로부터 정보를 추출할 수도 있다. 예를 들어, MPD는 브로드캐스트 서버 디바이스 (90) 에 의해 서빙되는 멀티캐스트 그룹에 대한 멀티캐스트 그룹 어드레스를 포함할 수도 있다. 그 MPD는 또한 유니캐스트에 따라 유니캐스트 서버 디바이스 (92) 에 의해 호스팅되는 미디어 콘텐츠의 표현들의 데이터를 액세스하기 위한 URL들을 포함할 수도 있다. 더구나, MPD는 미디어 콘텐츠의 표현들의 코딩 및 랜더링 특성들을 서술할 수도 있다. 일부 예들에서, MPD는 브로드캐스트 또는 멀티캐스트를 위한 그리고 유니캐스트를 위한 적응 세트들을 나타내는 정보를 제공할 수도 있다. 다시 말하면, MPD는 적응 세트의 표현들이 브로드캐스트 또는 멀티캐스트, 유니캐스트, 또는 양쪽 모두에 이용가능한지를 나타낼 수도 있다.

더욱이, MPD는 미디어 콘텐츠의 표현들에 대한 타이밍 정보를 나타내는 정보를 제공할 수도 있다. 일부 예들에서, 브로드캐스트 서버 디바이스 (90) 에 의해 제공된 브로드캐스트 또는 멀티캐스트 표현들은, 유니캐스트 서버 디바이스 (92) 에 의해 제공된 다른 표현들보다 덜 빈번한 스위치 포인트들을 가진다. 그런 예들에서, 클라이언트 디바이스 (40) 는 스위치 포인트들 (플레이백 시간의 측면에서) 사이의 기간에 대응하는 데이터의 양을 결정하고, 그 양의 데이터를 유니캐스트 서버 디바이스 (92) 로부터 취출하도록 요청할 수도 있다. 클라이언트 디바이스 (40) 는 브로드캐스트 서버 디바이스 (90) 로부터 브로드캐스트 또는 멀티캐스트의 데이터를 수신하기 전에 또는 그 수신이 시작하는 동안에도, 유니캐스트 서버 디바이스 (92) 로부터 수신된 이 데이터를 버퍼링할 수도 있다. 이런 방식으로, 클라이언트 디바이스 (40) 는 멀티캐스트 또는 브로드캐스트를 통해 수신된 표현의 스위치 포인트가 수신되기까지 미디어 콘텐츠의 데이터를 디코딩 및 재생하는 것을 시작하기 위한, 유니캐스트를 통해 수신된 충분한 양의 데이터를 버퍼링할 수도 있다. 클라이언트 디바이스는 스위치 포인트에서 멀티캐스트 또는 브로드캐스트를 통해 수신된 표현을 디코딩하기 시작할 수도 있고, 추가로, 이 표현으로 스위칭한 후의 미디어 데이터를 위해 유니캐스트를 통해 데이터를 요청하는 것을 중단할 수도 있다.

다시, 일부 예들에서, 동일한 서버 디바이스는 (HTTP GET 또는 부분적 GET 요청들에 응답하여) 유니캐스트를 이용하는 것 및 멀티캐스트 또는 브로드캐스트를 이용하는 것 양쪽 모두로 데이터를 출력할 수도 있다는 것이 이해되어야 한다. 도 3은 별개의 디바이스들이 미디어 데이터의 유니캐스트 및 브로드캐스트 또는 멀티캐스트 출력을 담당하는 대안적 일 예를 도시한다.

도 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) 는, 코딩 및 랜더링 특성들과 같은 표현들 (110-120) 의 특성들, 적응 세트들, MPD (102) 가 대응하는 프로파일, 텍스트 유형 정보, 카메라 각도 정보, 등급(rating) 정보, 트릭 모드 정보 (예컨대, 시간적 서브-시퀀스들을 포함하는 표현들을 나타내는 정보), 및/또는 (예컨대, 플레이백 동안에 미디어 콘텐츠 속으로의 목표로 한 광고 삽입을 위한) 원격 기간들을 취출하기 위한 정보를 일반적으로 서술하는 데이터를 포함할 수도 있다. 원격 기간들은 또한 외부 기간들이라고 지칭될 수도 있다. 아래에서 더 상세히 논의되는 도 4 내지 도 7은, 다양한 엘리먼트들이 MPD 및/또는 표현들 중 어느 하나 또는 양쪽 모두에 (이를테면 표현들의 세그먼트들 또는 표현들의 헤더 데이터 내에) 포함되는 멀티미디어 콘텐츠의 다양한 예들을 도시한다. 도 4 내지 도 7의 MPD들 중 임의의 것 또는 모두는 실질적으로 도 4의 MPD (102) 에 대응할 수도 있다.

본 개시물의 기법들에 따라, 도 4의 MPD (102) 는, 예를 들어, 멀티캐스트될 수 있는 표현들 (110-120) 중 임의의 표현의 데이터를 취출하기 위해 멀티캐스트 그룹에 참가하기 위한 유니캐스트 및 멀티캐스트 그룹 어드레스 (104) 일 수 있는, 세그먼트들 (114 및/또는 124) 의 URL들과 같은 정보를 특정할 수도 있다. 대안으로, MPD (102) 는 네트워크 브로드캐스트 데이터를 취출하기 위한 데이터를 포함할 수도 있다.

하나의 예에서, 표현 (110) 의 데이터는 유니캐스트를 이용하여 출력될 수도 있는 반면, 표현 (120) 의 데이터는 멀티캐스트 또는 브로드캐스트를 이용하여 출력될 수도 있다. 물론, 멀티미디어 콘텐츠 (100) 의 다른 표현들의 데이터 (도시되지 않고 생략부분 (ellipses) 으로 표시됨) 는 또한 멀티캐스트, 브로드캐스트, 또는 유니캐스트 중 임의의 것 또는 모두를 이용하여 출력될 수도 있다.

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

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

세그먼트들 (114, 124) 의 각각은 고유한 URI (uniform resource identifier), 예컨대, URL (uniform resource locator) 와 연관될 수도 있다. 따라서, 세그먼트들 (114, 124) 의 각각은 스트리밍 네트워크 프로토콜, 이를테면 DASH를 이용하여 독립적으로 취출가능할 수도 있다. 이런 방식으로, 목적지 디바이스, 이를테면 클라이언트 디바이스 (40) 는, 세그먼트들 (114 또는 124) 을 취출하기 위해 HTTP GET 요청을 이용할 수도 있다. 일부 예들에서, 클라이언트 디바이스 (40) 는 세그먼트들 (114 또는 124) 의 특정 바이트 범위들을 취출하기 위해 HTTP 부분적 GET 요청들을 이용할 수도 있다. 대안으로, 본 개시물의 기법들에 따라, 일 예로서, 세그먼트들 (114) 은 HTTP GET 요청들에 응답하여, 유니캐스트를 이용하여 전송될 수도 있는 반면, 세그먼트들 (124) 은 브로드캐스트 또는 멀티캐스트될 수도 있다.

위에서 지적했듯이, MPD (102) 는 특정 MPD 프로파일에 부합할 수도 있다. MPD (102) 는 MPD (102) 및/또는 멀티미디어 콘텐츠 (100) 에 대한 다목적 인터넷 메일 확장 (Multipurpose Internet Mail Extension; MIME) 유형을 나타내는 정보를 포함할 수도 있다. 그러나 MIME 유형들은 일반적으로 무슨 코덱이 멀티미디어 콘텐츠를 제공하는데 필요한지를 나타내지 못한다. 대체로, 디바이스가 멀티미디어 콘텐츠에 대한 MPD, 이를테면 MPD (102) 를 취출할 수 있다면, 그 디바이스는 MPD에 대응하는 멀티미디어 콘텐츠의 데이터를 재생할 수 있다고 가정된다. 그러나, 이 가정은 항상 안전하지 않을 수도 있다. 그러므로, 일부 예들에서, MPD (102) 는 MPD (102) 가 대응하는 프로파일을 나타내는 정보를 포함할 수도 있다.

MPD들이 대응할 수도 있는 비교적 적은 수의 프로파일들이 있을 수도 있다. 프로파일들은 H.264/AVC가 비디오 코딩을 위한 프로파일들 및 레벨들을 포함하는 방식과 유사하게, 능력들을 다루는 레벨들에 의해 지원될 수도 있다. MPD 프로파일들은, 상위 프로파일이 모든 하위 프로파일들의 모든 특징들을 포함할 수도 있다는 점에서 양파껍질식일 수도 있다. 등록 프로세스에는 다양한 프로파일들을 등록하기 위한 등록 권한이 있을 수도 있다. 일부 예들에서, 클라이언트 디바이스, 이를테면 클라이언트 디바이스 (40) 는, MPD의 다른 데이터, 이를테면 MPD (102) 에 의해 시그널링된 표현들 (110-120) 의 특성들을 취출하기 전에, MPD, 이를테면 MPD (102) 에 대한 프로파일을 나타내는 정보를 취출하도록 구성될 수도 있다. 이런 방식으로, MPD (102) 에 대한 프로파일은 MPD (102) 에 대한 액세스가 제공되기 전에 시그널링될 수도 있다.

프로파일 식별자가 일반 텍스트로 (예컨대, 일반 이름으로서), 또는 역순형 (reversed) 도메인 이름으로 제공될 수도 있다. 일반 이름들은 등록 기관, 이를테면 3GPP 또는 다른 등록 기관에 의해 유보될 수도 있다. 프로파일은, 대응하는 멀티미디어 콘텐츠가 그 프로파일에 부합하고, MPD를 읽기 위해 그 프로파일을 구현하며, 자신이 인식하는 것이 무엇인지를 해석하고, 및 자신이 이해하지 못하는 자료를 무시하는 판독기 (예컨대, 클라이언트 디바이스) 를 허가하는 것을 그 프로파일이 요구 (claim) 할 수도 있다는 점에서, 요구 및 허가라고 간주될 수도 있다.

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

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

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

비디오 파일 (150) 은 표현들 (110-120) (도 4) 중 하나에 포함될 수도 있는, 멀티미디어 콘텐츠의 세그먼트의 일 예를 일반적으로 나타낸다. 이런 방식으로, 비디오 파일 (150) 은 세그먼트들 (114) 중 하나, 세그먼트들 (124) 중 하나, 또는 다른 표현의 세그먼트에 대응할 수도 있다. 본 개시물의 기법들에 따라, 비디오 파일 (150) 에 유사한 방식으로 포맷팅된 세그먼트들은, 유니캐스트이든, 멀티캐스트이든, 또는 브로드캐스트이든 FLUTE를 이용하여 전송될 수도 있다.

도 5의 일 예에서, 비디오 파일 (150) 은 SIDX 박스 (162) 를 포함한다. 일부 예들에서, 비디오 파일 (150) 은, 예컨대, 무비 프래그먼트들 (164) 사이에 부가적인 SIDX 박스들을 포함할 수도 있다. 대체로, SIDX 박스들, 이를테면 SIDX 박스 (162) 는, 무비 프래그먼트들 (164) 중 하나 이상에 대한 바이트 범위들을 서술하는 정보를 포함한다. 다른 예들에서, SIDX 박스 (162) 및/또는 다른 SIDX 박스들은 MOOV 박스 (154) 내에, MOOV 박스 (154) 앞에, MFRA 박스 (166) 앞 또는 뒤에, 또는 비디오 파일 (150) 내의 다른 곳에 제공될 수도 있다.

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

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) 는 코딩된 비디오 화상들을 포함하는 반면, 다른 예들에서, 트랙의 코딩된 비디오 화상들은 TRAK 박스 (158) 의 데이터에 의해 참조될 수도 있는 무비 프래그먼트들 (164) 내에 포함될 수도 있다.

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

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

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

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

무비 프래그먼트들 (164) 은 하나 이상의 코딩된 비디오 화상들을 포함할 수도 있다. 일부 예들에서, 무비 프래그먼트들 (164) 은 화상들의 하나 이상의 그룹들 (GOPs) 을 포함할 수도 있으며, 그 GOP들의 각각은 다수의 코딩된 비디오 화상들, 예컨대, 프레임들 또는 화상들을 포함할 수도 있다. 덧붙여서, 위에서 설명된 바와 같이, 무비 프래그먼트들 (164) 은 일부 예들에서 시퀀스 데이터 세트들을 포함할 수도 있다. 무비 프래그먼트들 (164) 의 각각은 무비 프래그먼트 헤더 박스 (MFHD, 도 5에는 도시되지 않음) 를 포함할 수도 있다. MVHD 박스는 대응하는 무비 프래그먼트의 특성들, 이를테면 무비 프래그먼트에 대한 시퀀스 번호 (sequence number) 를 서술할 수도 있다. 무비 프래그먼트들 (164) 은 비디오 파일 (150) 내에 시퀀스 번호의 순서로 포함될 수도 있다.

MFRA 박스 (166) 는 비디오 파일 (150) 의 무비 프래그먼트들 (164) 내에서 랜덤 액세스 포인트들을 서술할 수도 있다. 이는 비디오 파일 (150) 내에서 특정한 시간적 로케이션들에 대한 탐색들을 수행하는 것과 같은, 트릭 모드들을 수행하는 것을 지원할 수도 있다. MFRA 박스 (166) 는 일반적으로 옵션적이고 일부 예들에서, 비디오 파일들에 포함될 필요가 없다. 비슷하게, 클라이언트 디바이스, 이를테면 클라이언트 디바이스 (40) 는, 비디오 파일 (150) 의 비디오 데이터를 정확히 디코딩하고 디스플레이하기 위해 MFRA 박스 (166) 를 반드시 참조할 필요가 없다. MFRA 박스 (166) 는 비디오 파일 (150) 의 트랙들의 수와 동일한, 또는 일부 예들에서는, 비디오 파일 (150) 의 미디어 트랙들 (예컨대, 비-힌트 트랙들) 의 수와 동일한 수의 트랙 프래그먼트 랜덤 액세스 (track fragment random access; TFRA) 박스들 (미도시) 을 포함할 수도 있다.

본 개시물의 기법들에 따라, 클라이언트 디바이스, 이를테면 클라이언트 디바이스 (40) 는, 무비 프래그먼트들 (164) 중에서 스위치 포인트들 (다시 말하면, 랜덤 액세스 포인트들) 의 로케이션들을 결정하기 위해, MFRA 박스 (166) 및/또는 SIDX 박스 (162) 의 데이터를 이용할 수도 있다. 이런 방식으로, 클라이언트 디바이스가 브로드캐스트 또는 멀티캐스트로 FLUTE를 통해 랜덤 액세스 포인트 또는 스위치 포인트를 포함하는 비디오 파일을 수신하는 경우, 클라이언트 디바이스는 랜덤 액세스 포인트로부터 디코딩을 시작할 수도 있다. 따라서, 클라이언트 디바이스는 비디오 파일이 수신되었던 표현으로부터 브로드캐스트 또는 멀티캐스트에 따라 표현을 스위칭하고, 스위치 포인트 뒤에서, 유니캐스트를 이용한 취출을 위해 추가의 데이터를 요청하지 않을 수도 있다. 스위치 포인트가 취출되었다는 것을 보장하는 것을 시도하기 위해, 클라이언트 디바이스는 최소한 브로드캐스트 또는 멀티캐스트를 통해 수신된 (또는 수신하려는) 표현의 스위치 포인트들을 사이의 비디오 데이터의 시간적 섹션에 대응하는 것만큼의 유니캐스트를 통해 수신된 표현으로부터의 데이터를 요청하고 버퍼링할 수도 있다.

MFRA 박스 (166) 및/또는 SIDX 박스 (162) 는, 예를 들어, 스위치 포인트의 (재생의 측면에서의) 시간적 포지션, 스위치 포인트에 도달하는 바이트 오프셋 (예컨대, 비디오 파일 (150) 의 시작부분부터 스위치 포인트를 포함하는 무비 프래그먼트들 (164) 중 하나의 무비 프래그먼트의 시작부분까지의 바이트 오프셋), 또는 비디오 파일 (150) 에서의 스위치 포인트들의 다른 특성과 같은 정보를 제공할 수도 있다.

일부 예들에서, 비디오 파일 (150) 의 데이터는 비디오 파일 (150) 의 데이터가 캐싱되어야 하는 방법을 나타내는 캐싱 정보, 이를테면 캐싱 프리미티브들을 포함할 수도 있다. 이런 방식으로, 데이터를 캐싱하도록 구성된 디바이스들, 이를테면 프록시 캐싱 디바이스 (예컨대, 도 2의 프록시 캐싱 디바이스 (82)) 또는 클라이언트 디바이스 (예컨대, 클라이언트 디바이스 (40)) 는 요청에 응답하여 캐싱된 데이터를 취출할 수도 있다. 다시 말하면, 미디어 콘텐츠의 데이터에 대한 요청을 서버로 포워딩하기 보다는, 클라이언트 디바이스 또는 프록시 캐시 디바이스는, 캐싱된 데이터가 만료되었다고 가정하여, 캐싱된 데이터를 이용하여 그 요청을 서비스할 수도 있다.

도 6은 2 개의 표현들 (182, 186) 을 포함하는 예시적인 미디어 콘텐츠 (180) 를 도시하는 개념도이다. 이 예에서, 표현 (182) 은 세그먼트들 (184A-184H) (세그먼트들 (184)) 을 포함하는 반면, 표현 (186) 은 세그먼트들 (188A 및 188B) (세그먼트들 (188)) 을 포함한다. 세그먼트들의 제한된 수가 도 6에서 도시되지만, 표현들의 각각은 생략부분에 의해 나타내어진 바와 같이, 부가적인 세그먼트들을 포함할 수도 있다. 도 6의 예에서, 세그먼트들의 시간적 지속기간은 일반적으로 세그먼트들의 폭에 의해 도시된다. 따라서, 표현 (182) 의 세그먼트들 (184) 은 일반적으로 표현 (186) 의 세그먼트들 (188) 보다 짧은 시간적 지속기간을 가진다. 예를 목적으로, 세그먼트들 (184, 188) 의 각각이 스위치 포인트 (다시 말하면, 랜덤 액세스 포인트) 로 시작한다고 가정한다.

본 개시물의 기법들에 따라, 클라이언트 디바이스 (40) 는 미디어 콘텐츠 (180) 를 액세스하기 위한 요청을 수신할 수도 있다. 클라이언트 디바이스 (40) 가 미디어 콘텐츠 (180) 의 데이터를 아직 캐싱하지 못했다고 가정하면, 클라이언트 디바이스 (40) 는 미디어 콘텐츠 (180) 의 데이터를 취출하도록 요청할 수도 있다. 예를 들어, 브로드캐스트 서버 디바이스 (90) 가 세그먼트 (188A) 를 통해 데이터 대략 절반만 브로드캐스팅하고 있는 시간에 클라이언트 디바이스 (40) 가 사용자로부터 미디어 콘텐츠 (180) 의 데이터를 액세스하기 위한 요청을 수신한다고 가정한다. 기존에는, 클라이언트 디바이스 (40) 는 미디어 콘텐츠 (180) 의 데이터를 표시하기 전에 세그먼트 (188B) 의 데이터가 수신되기까지 기다릴 필요가 있을 것인데, 표현 (186) 의 다음의 스위치 포인트가 세그먼트 (188B) 의 시작부분에서 발생할 것이기 때문이다.

그러나, 본 개시물의 기법들에 따라, 클라이언트 디바이스 (40) 는 멀티캐스트 또는 브로드캐스트를 통해 수신된 데이터를 버퍼링하지만 또한 유니캐스트 데이터를 요청할 수도 있다. 이 예에서, 클라이언트 디바이스 (40) 는 세그먼트들 (184) 중 하나 이상을 유니캐스트를 통한 수신을 위해 요청할 수도 있다. 예를 들어, 클라이언트 디바이스 (40) 는 세그먼트들 (184A-184D) 의 각각을 요청하고, 이들 세그먼트들에 대한 데이터를 유니캐스트를 통해 취출할 수도 있다. 이런 방식으로, 클라이언트 디바이스 (40) 는 표현 (186) 의 다음의 스위치 포인트가 도착하기를 기다리면서도 표현 (182) 으로부터 세그먼트들 (184A-184D) 의 데이터를 디코딩하고 디스플레이할 수도 있다. 따라서, 클라이언트 디바이스 (40) 는 세그먼트 (188B) 를 수신하기까지 표현 (182) 에 대응하는 데이터를 사용자에게 제시할 수도 있다. 세그먼트 (188B) 의 데이터를 수신한 후, 클라이언트 디바이스 (40) 는 세그먼트들 (184) 을 요청하는 것을 중단하고 표현 (186) 으로부터의 세그먼트들 (188), 예컨대, 세그먼트 (188B) 및 그 이후의 데이터만을 수신할 수도 있다.

따라서, 하나의 예에서, 클라이언트 디바이스 (40) 는 세그먼트들 (184A-184D) 중 임의의 것 또는 모두를 유니캐스트를 통해, 그리고 세그먼트 (188B) 및 표현 (186) 의 후속 세그먼트들을 브로드캐스트 또는 멀티캐스트를 통해, 예컨대, FLUTE에 따라 취출할 수도 있다. 더욱이, 클라이언트 디바이스 (40) 는 표현 (186) 의 세그먼트 (188B) 및 후속 세그먼트들의 데이터를 기간 동안 캐싱할 수도 있다. 이런 방식으로, 클라이언트 디바이스 (40) 의 사용자는 나중 시간에, 데이터의 재송신을 필요로 하지 않고서도, 미디어 콘텐츠 (180) 의 데이터를 신속하게 액세스할 수도 있다. 더구나, 세그먼트들 (188) 의 데이터를 캐싱함으로써, 클라이언트 디바이스 (40) 브라우저 캐시를 브로드캐스트 또는 멀티캐스트를 통해 수신된 세그먼트들 (188) 의 데이터로 미리 채울 수도 있다. 이런 방식으로, 클라이언트 디바이스 (40) 는 데이터가 브라우저 캐시에서 이용가능하다고 결정할 수도 있어서, 클라이언트 디바이스 (40) 는 유니캐스트를 이용하여 데이터를 취출할 필요가 없다.

도 7은 유니캐스트 및 멀티캐스트에 대한 네트워크 스택들의 예들을 도시하는 블록도이다. 도 7은 유니캐스트 네트워크 스택 (200A) 의 일 예 및 멀티캐스트 네트워크 스택 (200B) 의 일 예를 도시한다. 양쪽 모두의 예의 네트워크 스택들에서, 애플리케이션(들) 데이터 (202) 는, 예컨대, 클라이언트 디바이스 상의 DASH 클라이언트를 위해 전송된다. 대체로, 네트워크 스택들 (200A, 200B) 의 상단부터 하단까지의 다양한 계층들은 개방형 시스템 상호접속 (OSI) 네트워크 모델에서 정의된 바와 같은 네트워크 계층들에 대응한다.

네트워크 스택 (200A) 의 예는 서비스 공지사항 및 메타데이터 (204), 연관된 전달 프로시저들 (206), 및 MBMS 보안 (212) 을 포함한다. 서비스 공지사항 및 메타데이터 (204) 는 MBMS의 가용성을 무선 고객들, 이를테면 클라이언트 디바이스 (40) 를 소유하는 사용자에게 나타내는, 서비스 제공자 (예컨대, 무선 오퍼레이터) 에 의해 제공된 데이터를 포함한다. 연관된 전달 프로시저들 (206) 은 데이터의 전달, 이를테면 PTP (point-to-point) 파일 복구 (208) 및 수신 리포팅 (210) 에 연관되고, 그것에 보조적인 프로시저들을 위한 데이터를 표현한다. PTP 파일 복구 (208) 는 MBMS를 통해 전달된 파일의 에러 없는 수신을 보장하기 위한 데이터를 표현한다. 수신 리포팅 (210) 은 수신 통계에 대한 데이터를 표현하며, 그것은 브로드캐스트/멀티캐스트 서비스 센터, 이를테면 브로드캐스트 또는 멀티캐스트 서버에 제공될 수도 있다.

네트워크 스택 (200A) 은 또한 MBMS 보안 (212) 을 포함하며, 그것은 디지털 저작권 관리 (DRM) 보호된 미디어 콘텐츠를 배포하기 위한 보호 레벨을 제공하는 서비스 액세스 보호를 제공한다. 특히, MBMS 서비스 키들 (MSK) (216) 은 전송되며, 그것은 클라이언트 디바이스 (40) 가 MBMS 사용자 키를 사용하여 암호해독한다. MSK (216) 는 멀티미디어 인터넷 키잉 (KEYing) (MIKEY) 메시지들 (222) 로 사용자 마다 개별적으로 전송된다. MSK (216) 는 MBMS 트래픽 키들 (MTK) (234) 을 암호해독하는데 사용된다. 클라이언트 디바이스 (40) 는 클라이언트 디바이스 (40) 에 의해 수신된 미디어 콘텐츠의 표현들의 세그먼트들을 암호해독하기 위해 MTK (234) 를 사용한다. 클라이언트 디바이스 (40) 는 또한 클라이언트 디바이스 (40) 가 미디어 콘텐츠를 수신하도록 등록된다는 것을 나타내기 위해 등록 (214) 에 대한 데이터를 전송한다.

이 예에서, MKS (216) 와 MIKEY (222) 는 사용자 데이터그램 프로토콜 (UDP) (226) 로 전송된다. 연관된 전달 프로시저들 (206) 및 등록 (214) 에 대한 데이터는, 이 예에서, HTTP (218) 에 따라 전송된다. 더구나, HTTP 다이제스트 (220) 는 HTTP (218) 로 전송되는 데이터를 안전화하기 위해 사용된다. 덧붙여서, HTTP (218) 로 전송된 데이터는 송신 제어 프로토콜 (224) 로 전송된다. TCP (224) 및 UDP (226) 로 전송된 양쪽 모두의 데이터는 인터넷 프로토콜 (IP) (228) 내에서 캡슐화되며, 그것은 네트워크 스택 (200A) 의 경우 유니캐스트를 통해 전송된다. 더구나, IP (Unicast) (228) 에 대한 데이터는 PTP (point-to-point) 베어러 (230) 로 전송된다. 이 예에서, 베어러는 MBMS를 위한 무선 (radio) 채널일 수도 있다.

네트워크 스택 (200B) 은 MBMS 보안 (232) 을 포함하며, 그것은, MBMS 보안 (232) 이 MTK (234) 와, MIKEY (222) 에 유사한 MIKEY (236) 에 대응한다는 점에서, MBMS 보안 (212) 과 유사하다. 이 예에서, 순방향 오류 정정 (FEC) (238) 은, 예컨대, MBMS 보안 (232), MTK (234), MIKEY (236) 의 보안 관련 데이터를 재송신 없이 에러들을 정정하기 위한 데이터를 제공한다.

네트워크 스택 (200B) 은 또한 코덱들 (240) 을 스트리밍하기 위한 데이터를 포함하며, 그 데이터는 오디오 데이터, 비디오 데이터, 음성 데이터, 텍스트 데이터 등과 같은 코덱들에 대한 데이터를 포함할 수도 있다. 본 개시물의 기법들에 따라, 이 데이터는, 예컨대, 도 4 및 도 5에 관해 위에서 설명된 바와 같이, DASH 파일 포맷 (242) 에 따라 포맷팅된다. 네트워크 스택 (200B) 은 또한 3GPP 파일 포맷 (244) 에 따라 포맷팅된 데이터를 포함하며, 그 데이터는 이진수 데이터, 정지 이미지들, 텍스트, 및 다른 그런 데이터를 포함할 수도 있다. 연관된 전달 프로시저들 (246) 은 연관된 전달 프로시저들 (206) 에 실질적으로 대응하고, PTM (point-to-multipoint) 파일 복구 (248) 를 위한 데이터를 포함한다. PTM 파일 복구 (248) 의 데이터는 실제 MBMS 데이터 전송 후에 서버 디바이스가 부가적인 MBMS 데이터를 전송하는 것을 허용한다. 비슷하게, 서비스 공지사항 및 메타데이터 (250) 는 서비스 공지사항 및 메타데이터 (204) 에 실질적으로 대응한다.

네트워크 스택 (200B) 의 예에서, 본 개시물의 기법들에 따라, DASH 데이터 (스트리밍 코덱 (240) 의 DASH 파일 포맷 (242) 캡슐화된 코덱 데이터), 3GPP 파일 포맷 (244) 의 데이터, 및 연관된 전달 프로시저들 (246) 의 데이터 이를테면 PTM 파일 복구 (248) 의 데이터가 FLUTE (252) 로 전송되며, 그것은 ALC (254) 로 전송된다. 덧붙여서, 데이터는 계층식 코딩 전송 (LCT) (256), 혼잡 제어 (CC) (258), 및 FEC (260) 를 위해 제공될 수도 있다. 네트워크 스택 (200B) 의 예에서, 이 데이터는 IP 멀티캐스트 또는 IP 유니캐스트 (262) 중 어느 하나로 전송되며, 그것은 MBMS 또는 PTP 베어러들 (264) 을 통해 전송된다.

이런 방식으로, 네트워크 스택 (200B) 은 DASH-포맷화된 미디어 데이터가, 본 개시물의 기법들에 따라 FLUTE 프로토콜로 전송될 수 있는 일 예를 표현한다. 따라서, 네트워크 스택 (200B) 은 FLUTE는 스트리밍 전달을 위한 RTP에 대안적인 전송으로서 역할을 할 수도 있다. 이는 DASH를 통한 브로드캐스트 (또는 멀티캐스트) 및 유니캐스트 수렴을 가능하게 한다. 덧붙여서, 타이밍 및 동기화가 DASH 포맷에 알맞기 때문에, RTP에서 제공된 바와 같은 타이밍 및 동기화는 필요하지 않다. 본 개시물의 기법들은 그러므로 파일 및 스트리밍 서비스들 양쪽 모두에 대해 단일 브로드캐스트 전송 패러다임을 허용할 수도 있다. MBMS 서비스 영역 외부에 위치된 클라이언트 디바이스에게 MBMS 스트리밍 서비스 전달의 연속성을 제공하기 위한 패킷 교환식 스트리밍 (PSS) 이 또한 더 이상 필요하지 않는데, HTTP 스트리밍이 충분할 것이라서이다.

도 8은 다른 예의 클라이언트 디바이스 (280) 를 도시하는 블록도이다. 대체로, 클라이언트 디바이스 (280) 는 클라이언트 디바이스 (40) 에 대응할 수도 있다. 도 8의 예는 클라이언트 디바이스의 컴포넌트들을 더 상세히 도시한다. 이 예에서, 클라이언트 디바이스 (280) 는, 제어 유닛 (282) 에 기인한 기능을 수행하기 위한 하드웨어, 소프트웨어, 및/또는 펌웨어를 나타낼 수도 있는 제어 유닛 (282) 을 구비한다. 소프트웨어 또는 펌웨어로 구현되는 경우, 제어 유닛 (282) 이 필수 하드웨어, 이를테면 하나 이상의 프로세싱 유닛들 및/또는 소프트웨어 또는 펌웨어 명령들을 저장하기 위한 하나 이상의 하드웨어 기반 컴퓨터 판독가능 매체들을 구비한다고 가정된다.

이 예에서, 제어 유닛 (282) 은 DASH 애플리케이션 (284), 요청 핸들러 (286), HTTP 액세스 클라이언트 (288), FLUTE 클라이언트 (292), 미디어 캐시 (290), 및 FLUTE 캐시 (294) 를 구비한다. 일부 예들에서, FLUTE 캐시 (294) 를 위한 별도의 캐시가 필요하지 않는 단일 캐시만 (예컨대, 미디어 캐시 (290)) 이 제공된다. DASH 애플리케이션 (284) 은 DASH의 기법들을 수행하기 위한 웹 브라우저 또는 웹 브라우저 플러그 인에 대응할 수도 있다. 일부 예들에서, DASH 애플리케이션 (284) 은 미디어 플레이어를 포함하는 반면, 다른 예들에서, 제어 유닛 (282) 은 별개의 미디어 플레이어 애플리케이션을 포함한다. 도 8에 보이진 않았지만, 제어 유닛 (282) 은, 예컨대, 도 1에 도시된 바와 같이, 오디오, 비디오, 및 다른 미디어 데이터를 디코딩하는 필수 디코더들을 구비한다고 또한 가정된다.

사용자는 미디어 콘텐츠, 예컨대, 인터넷 상에서 이용가능한 특정 무비를 선택하기 위해 DASH 애플리케이션 (284) 과 상호작용할 수도 있다. DASH 애플리케이션 (284) 은 HTTP 요청을 요청 핸들러 (286) 로 발행할 수도 있다. 요청 핸들러 (286) 는 미디어 캐시 (290) 로부터 요청된 콘텐츠를 취출함으로써 (예컨대, 요청된 미디어 콘텐츠가 이전에 액세스되고 미디어 캐시 (290) 내에 캐싱된 경우임) 또는 유니캐스트 네트워크로, 예컨대, HTTP 액세스 클라이언트 (288) 를 통해 스트리밍 요청을 개시함으로써 요청을 서비스할 수도 있다. 이런 방식으로, 미디어 캐시 (290) 와 FLUTE 캐시 (294) 는 파일 전달 서비스, 이를테면 FLUTE를 통해 수신된 미디어 데이터가 캐싱될 수도 있는 로컬 메모리의 예들을 나타낸다. 더구나, 요청 핸들러 (286) 는 DASH 애플리케이션 (284) 으로부터의 DASH 요청에 응답하여 로컬 메모리에 의해 구현된 캐시에 쿼리할 수도 있다. 데이터가 캐시 내에 있는 경우, 캐시 "히트"가 발생할 수도 있고, 요청 핸들러 (286) 는 캐시로부터의 데이터를 이용하여 요청을 서비스할 수도 있다. 다른 한편으로는, 데이터가 캐시 내에 없는 경우, 캐시 "미스"가 발생하여, 요청 핸들러 (286) 가 HTTP 액세스 클라이언트 (286) 를 통해 데이터에 대한 유니캐스트 요청을 전송하게 할 수도 있다.

대체로, DASH 애플리케이션 (284) 은 특정 미디어 콘텐츠에 대한 복수의 표현들 중에서 표현을 선택하도록 구성될 수도 있다. 복수의 표현들이 적응 세트에 대응한다거나, 또는 복수의 표현들이 그렇지 않고 클라이언트 디바이스 (280) 의 코딩 및 랜더링 능력들을 충족한다고 가정하면, DASH 애플리케이션 (284) 은 표현들에 대한 네트워크 대역폭 및 비트레이트들의 양에 기초하여 복수의 표현들 중에서 표현을 선택할 수도 있다. 예를 들어, DASH 애플리케이션 (284) 은 이용가능한 표현들의 각각에 대한 전달 지연을 계산하는 레이트-추정 알고리즘을 구현할 수도 있다.

미디어 콘텐츠를 위한 미디어 데이터가 로컬 메모리 내에 캐싱된 경우, 레이트-추정 알고리즘은 대응하는 표현에 대한 전달 지연이 가상적으로 영이라고 나타낼 수도 있다. 그러므로, 미디어 콘텐츠의 표현을 위한 미디어 데이터가 로컬 메모리 (이를테면 미디어 캐시 (290) 또는 FLUTE 캐시 (294)) 내에 캐싱된 경우, 레이트-추정 알고리즘은 캐싱된 데이터에 대응하는 표현이 최상이라고 결정할 수도 있다. 그러므로, DASH 애플리케이션 (284) 이 사용자에 대한 상이한, 명시적인 요청을 수신하지 않는 한, DASH 애플리케이션 (284) 은, 복수의 표현들 중 하나를 선택하는 경우, 로컬 메모리 내의 캐싱된 데이터에 대응하는 표현을 자연스럽게 선택할 수도 있다. 이런 방식으로, 브로드캐스트 또는 멀티캐스트를 통해 수신된 미디어 콘텐츠로 캐시를 (예컨대, FLUTE 클라이언트 (292) 에 의해) 미래 채움으로써, DASH 애플리케이션 (284) 은, 가상적으로 영인 계산된 전달 지연을 갖는 표현에 대한 캐싱된 데이터에 기초하여, 서버 디바이스에 의해 브로드캐스트되거나 또는 멀티캐스트되는 표현을 자동으로 선택할 수도 있다.

미디어 캐시 (290) 가 요청된 미디어 콘텐츠에 대한 캐싱된 데이터를 포함하지 않는 경우들에서, 제어 유닛 (282) 은 FLUTE 클라이언트 (292) 가 미디어 데이터를 브로드캐스트 또는 멀티캐스트의 형태로 수신하기 위해 멀티캐스트 그룹에 가입하게 할 수도 있다. FLUTE 클라이언트 (292) 는 MBMS 베어러로 브로드캐스트 또는 멀티캐스트를 수신할 수도 있다. 더욱이, FLUTE 클라이언트 (292) 가 브로드캐스트 또는 멀티캐스트를 수신함에 따라, FLUTE 클라이언트 (292) 는 수신된 데이터를 미디어 캐시 (290) 에 저장한다. 이런 방식으로, DASH 애플리케이션 (284) 이 그 뒤에 요청 핸들러 (286) 에 후속 세그먼트의 데이터를 요청하는 경우, 요청 핸들러 (286) 는 미디어 데이터가 미디어 캐시 (290) 내에 저장된다고 결정할 수도 있다. 따라서, 충분한 양의 데이터가 브로드캐스트 또는 멀티캐스트를 통해 수신된 후 (예컨대, 스위치 포인트를 포함하는 세그먼트가 수신된 후), 요청 핸들러 (286) 는 미디어 데이터에 대한 추가의 요청들을 HTTP 액세스 클라이언트 (288) 로 발행할 필요는 없지만, 대신 미디어 캐시 (290) 로부터 미디어 콘텐츠를 취출할 수도 있다.

특히, DASH의 기법들에 따라, DASH 애플리케이션 (284) 은 미디어 콘텐츠를 순차적으로 요청하도록 구성될 수도 있다. 그러므로, 미디어 콘텐츠에 대한 제 1 요청에 응답하여, 미디어 콘텐츠가 미디어 캐시 (290) 내에 존재하지 않는다면, 요청 핸들러 (286) 는 유니캐스트를 통해 미디어 콘텐츠의 세그먼트들을 취출하기 위해 HTTP 액세스 클라이언트 (288) 가 하나 이상의 GET 또는 부분적 GET 요청들을 발행하게 하면서, 또한 FLUTE 클라이언트 (292) 가 미디어 콘텐츠를 위해 멀티캐스트 그룹에 참가할 것을 요청하게 할 수도 있다. 미디어 콘텐츠 (다시 말하면, 미디어 콘텐츠의 순서상 나중 부분) 에 대한 DASH 애플리케이션 (284) 으로부터의 후속하는 요청들에 응답하여, 요청 핸들러 (286) 는 요청된 미디어 콘텐츠가 미디어 캐시 (290) 내에서 이용가능한지의 여부를 다시 결정하고, 아니라면, HTTP 액세스 클라이언트 (288) 가 미디어 콘텐츠를 위한 하나 이상의 후속 GET 또는 부분적 GET 요청들을 발행하게 할 수도 있다. 요청 핸들러 (286) 는, (예컨대, 표현의 스위치 포인트가 미디어 캐시 (290) 내에 저장된 후) 멀티캐스트 또는 브로드캐스트의 데이터가 미디어 캐시 (290) 에서 이용가능하기까지 HTTP 액세스 클라이언트 (288) 가 유니캐스트 데이터를 취출하게 하는 것을 계속할 수도 있다. 더욱이, 제어 유닛 (282) 은, DASH 애플리케이션 (284) 에 의한 재생 후에 즉시 또는 머지않아 데이터를 삭제하기보다는, 연장된 기간 동안 미디어 캐시 (290) 내에 저장된 데이터를 유지할 수도 있다.

이런 방식으로, 클라이언트 디바이스 (280) 는, 미디어 콘텐츠가 HTTP를 통한 동적 적응적 스트리밍 (DASH) 에 부합하는 상기 미디어 콘텐츠의 적어도 일 부분을 취출하기 위한 요청으로서, 단방향 전송을 통한 파일 전달 (FLUTE) 프로토콜에 따라 적어도 일 부분이 전달되는 요청을 포함하는 상기 요청을 네트워크를 통해 전송하고, 상기 요청에 응답하여, 네트워크를 통해 FLUTE 프로토콜에 따라 미디어 콘텐츠의 적어도 일부에 대한 스트리밍 데이터를 수신하도록 구성된 하나 이상의 프로세싱 유닛들을 포함하는, 비디오 데이터에 대한 정보를 취출하기 위한 디바이스의 일 예를 나타낸다.

도 9는 본 개시물의 기법들에 따라, 유니캐스트 또는 브로드캐스트 또는 멀티캐스트 중 어느 하나로 미디어 데이터를 수신하는 예시적인 방법을 도시하는 흐름도이다. 예를 목적으로 도 8의 클라이언트 디바이스 (280) 의 예에 대해 설명되지만, 다른 디바이스들이 유사한 기법들을 수행하도록 구성될 수도 있다는 것이 이해되어야 한다. 예를 들어, 도 1 내지 도 3의 클라이언트 디바이스 (40) 는 도 9의 방법을 수행하도록 구성될 수도 있다. 도 9의 방법은 일반적으로, 브로드캐스트 또는 멀티캐스트를 통한 스트리밍을 행하기 위해, 파일 전달 서비스, 이를테면 FLUTE 프로토콜에 따라 브로드캐스트 또는 멀티캐스트를 통해 수신된 데이터를 이용하여 캐시 (이를테면 미디어 캐시 (290)) 를 미래 채우는 것을 포함한다.

이 예에서, 클라이언트 디바이스 (280) 는 처음에는 미디어 데이터에 액세스하기 위한 요청을 수신한다 (300). 예를 들어, DASH 애플리케이션 (284) 은 클라이언트 디바이스 (280) 의 사용자로부터 미디어 콘텐츠에 액세스하기 위한 요청을 수신할 수도 있다. 도 8에 관해 설명된 바와 같이, DASH 애플리케이션 (284) 은 미디어 데이터를 위한 요청을 요청 핸들러 (286) 에 전송할 수도 있다. 요청 핸들러 (286) 는, 결국, 요청된 미디어 데이터가 미디어 캐시 (290) 내에 현재 캐싱되어 있는지의 여부를 결정할 수도 있다 (302). 미디어 데이터가 캐시에 존재하지 않는다면 (302의 "아니오" 분기), 요청 핸들러 (286) 는 FLUTE 클라이언트 (292) 가 FLUTE를 이용하여 미디어 데이터를 취출하도록 요청하게 할 수도 있다 (304). 예를 들어, FLUTE 클라이언트 (292) 는 FLUTE에 따라 멀티캐스트 또는 브로드캐스트를 통해 미디어 콘텐츠의 데이터를 수신하는 것을 시작하기 위해 멀티캐스트 그룹에 가입할 수도 있다. FLUTE 클라이언트 (292) 가 FLUTE를 통해 미디어 데이터를 수신함에 따라, FLUTE 클라이언트 (292) 는 수신된 미디어 데이터를 FLUTE 캐시 (294) 및/또는 미디어 캐시 (290) 내에 캐싱할 수도 있다 (306).

덧붙여서, 요청 핸들러 (286) 는 HTTP 액세스 클라이언트 (288) 가 HTTP 유니캐스트를 이용하여 이전의 미디어 데이터를 취출하도록 요청하게 할 수도 있다 (308). HTTP 유니캐스트를 통해 요청된 데이터는 브로드캐스트 또는 멀티캐스트의 현재 시간적 로케이션보다 이전일 필요는 없지만, 많은 경우들에서 스위치 포인트가 수신되는 브로드캐스트 또는 멀티캐스트의 포인트보다 이전일 것이고, 그러므로 이런 의미에서 이전이다. 클라이언트 디바이스 (280) 는 유니캐스트를 통해 수신된 미디어 데이터를 디코딩하고 디스플레이할 수도 있다 (310). 다시 말하면, 브로드캐스트 또는 멀티캐스트를 통한 스위치 포인트의 도착을 기다리는 동안, 클라이언트 디바이스 (280) 는 유니캐스트를 통해 수신된 데이터를 디코딩하고 디스플레이할 수도 있다. 특히, HTTP 액세스 클라이언트 (288) 가 요청된 데이터를 유니캐스트를 통해 수신한 후, HTTP 액세스 클라이언트 (288) 는 그 데이터를 요청 핸들러 (286) 로 전송할 수도 있으며, 그 요청 핸들러는 그 데이터를 미디어 캐시 (290) 에 저장하고 데이터를 DASH 애플리케이션 (284) 으로 전송할 수도 있다. DASH 애플리케이션 (284) 은, 결국, 데이터를 디코딩을 위한 적절한 코덱들 (도 8에는 미도시) 로 전송하고, 디코딩된 데이터를 사용자 인터페이스들 (도 8에는 미도시), 이를테면 디코딩된 비디오 (뿐만 아니라 만약 있다면, 텍스트 오버레이들) 를 위한 디스플레이 및 디코딩된 오디오를 위한 스피커들로 향하게 할 수도 있다. 프로세스는 그 다음에 DASH 애플리케이션 (284) 이 미디어 캐시 (290) 내에 캐싱되었거나 또는 아직 캐싱되지 않았을 수도 있는 미디어 콘텐츠의 후속 세그먼트를 요청하는 것을 반복할 수도 있다.

스위치 포인트 (와 어쩌면 미디어 콘텐츠의 표현의 스위치 포인트를 뒤따르는 특정한 최소 양의 부가적인 데이터) 가 브로드캐스트 또는 멀티캐스트를 통해 수신되고 미디어 캐시 (290) 내에 저장된 후, 요청 핸들러 (286) 는 DASH 애플리케이션 (284) 에 의해 요청된 미디어 데이터가 미디어 캐시 (290) 내에 있다고 결정할 수도 있다 ("예" 분기 302). 응답하여, 요청 핸들러 (286) 는 미디어 캐시 (290) 로부터 요청된 미디어 데이터를 취출하고 (312), 요청된 미디어 데이터를 DASH 애플리케이션 (284) 으로 전송할 수도 있다. 비슷하게, DASH 애플리케이션 (284) 은 미디어 캐시 (290) 로부터 취출된 미디어 데이터를 디코딩하고 디스플레이할 수도 있다 (314). 도 9의 방법에서 명시적으로 도시되지 않았지만, FLUTE 클라이언트 (292) 는 FLUTE를 통해 미디어 콘텐츠의 데이터를 계속 수신할 것이고 수신된 데이터를 미디어 캐시 (290) 에 저장하는 것을 계속한다고 가정된다. 따라서, 요청 핸들러 (286) 는 후속 요청들의 미디어 데이터가 미디어 캐시 (290) 의 데이터를 이용하여 만족될 수 있다고 결정해야 한다. 물론, 사용자가 상이한 미디어 콘텐츠로 변경하거나, 또는 브로드캐스트 또는 멀티캐스트의 네트워크 인터럽션들이 있다면, 클라이언트 디바이스 (280) 는 미디어 콘텐츠의 충분한 데이터가 미디어 캐시 (290) 내에 버퍼링되기까지 일시적으로 유니캐스트로 되 스위칭하기 위해 또는 채널 변경을 행하기 위해 본 개시물의 기법들을 수행할 수도 있다.

DASH의 전송을 위해 유니캐스트와 브로드캐스트 또는 멀티캐스트 양쪽 모두를 허용하는 본 개시물의 기법들은 다양한 시나리오들에서 이점들을 제공할 수도 있다. 예를 들어, 위에서 논의된 바와 같이, 이들 기법들은 클라이언트 디바이스가 브로드캐스트 또는 멀티캐스트를 통해 수신될 스위치 포인트를 단순히 기다리는 것보다 일찍 미디어 콘텐츠의 (특히, 유니캐스트를 통해 수신된 데이터의) 플레이아웃을 시작하는 것을 허용할 수도 있는데, 클라이언트 디바이스가, 유니캐스트를 통해, 더 빈번한 스위치 포인트들을 갖는 표현의 데이터를 취출할 수도 있기 때문이다. 다른 시나리오로서, 브로드캐스트 또는 멀티캐스트되고 있는 표현의 품질은 특정 사용자에 대해 충분히 높지 않을 수도 있다. 이러한 사용자는 상이한 품질 레벨에서 데이터를 취출하기 위해 유니캐스트를 통해 미디어 콘텐츠의 특정 시간적 섹션에 대한 데이터의 재송신을 요청할 수도 있다. 예를 들어, 브로드캐스트 또는 멀티캐스트 중인 표현의 플레이아웃 시에 보기에 흐릿하거나 또는 어렵게 여겨지는 미세한 세부사항들이 있을 수도 있고, 이에 따라, 사용자는 대응하는 시간적 섹션에 대해 상위 품질 표현으로부터 데이터를 요청할 수도 있다. 클라이언트 디바이스는 계속, 브로드캐스트 또는 멀티캐스트의 데이터를 버퍼링하지만, 또한 유니캐스트를 이용하여 상위 품질 표현의 데이터를 요청할 수도 있다.

이런 방식으로, 도 9의 방법은 미디어 콘텐츠가 HTTP를 통한 동적 적응적 스트리밍 (DASH) 에 부합하는 미디어 콘텐츠의 적어도 일 부분을 취출하기 위한 요청으로서 적어도 일 부분이 단방향 전송을 통한 파일 전달 (FLUTE) 프로토콜에 따라 전달되는 요청을 포함하는 요청을 네트워크를 통해 전송하는 단계, 및 그 요청에 응답하여, 네트워크로 FLUTE 프로토콜에 따라 미디어 콘텐츠의 적어도 일부를 위한 스트리밍 데이터를 수신하는 단계를 포함하는 방법의 일 예를 나타낸다. 더구나, 도 9의 예의 방법은 유니캐스트 프로토콜에 따라 미디어 콘텐츠의 제 1 부분을 취출하는 단계를 더 포함한다. 또한, 도 9의 예의 방법에서, 적어도 일부를 취출하기 위한 요청을 전송하는 단계는, 미디어 콘텐츠의 제 2 부분을 취출하기 위한 요청을 전송하는 단계를 포함할 수도 있으며, 여기서 제 1 부분은 미디어 콘텐츠 내에서 제 2 부분보다 시간적으로 이전이고, 제 1 부분은 적어도 제 2 부분 내의 스위치 포인트들 사이의 시간적 기간만큼인 시간적 길이를 가진다.

도 10은 파일 전달 서비스, 이를테면 FLUTE를 이용하여 DASH 미디어 콘텐츠를 출력하는 예시적인 방법을 도시하는 흐름도이다. 도 1 및 도 2의 서버 디바이스 (60) 의 예에 관해 설명되었지만, 다른 디바이스들이 도 10의 방법을 수행하도록 구성될 수도 있다는 것이 이해되어야 한다. 예를 들어, 도 3의 브로드캐스트 서버 디바이스 (90) 는 이것 또는 유사한 방법을 수행하도록 구성될 수도 있다.

이 예에서, 서버 디바이스 (60) 는, 예컨대, 콘텐츠 준비 디바이스 (20) (도 1) 로부터 미디어 콘텐츠를 수신할 수도 있다 (350). 미디어 콘텐츠는 DASH에 따라 포맷팅될 수도 있다. 다시 말하면, 미디어 콘텐츠는 공통 코딩 및 랜더링 특성들을 갖는 적응 세트들로 분류될 수도 있는 다양한 상이한 표현들을 포함할 수도 있다. 상이한 적응 세트들의 표현들은 상이한 코딩 및/또는 랜더링 특성들을 가질 수도 있다. 서버 디바이스 (60) 는 멀티캐스트 그룹에 대한 어드레스를 결정할 수도 있다 (352). 서버 디바이스 (60) 는 또한 미디어 콘텐츠에 대한 MPD 파일로 멀티캐스트 그룹에 대한 어드레스를 광고할 수도 있다 (354). 서버 디바이스 (60) 는 또한 MPD 파일을 출력할 수도 있다 (356).

이 예에서, 서버 디바이스 (60) 는 또한 미디어 콘텐츠의 표현들 중 하나를 선택한다 (358). 예를 들어, 서버 디바이스 (60) 는 사용자, 이를테면 관리자로부터 표현의 선택을 수신할 수도 있다. 대안으로, 서버 디바이스 (60) 는 네트워크 상황, 이를테면 이용가능한 네트워크 대역폭의 결정된 양 및/또는 멀티캐스트 그룹에 가입된 사용자들의 수에 기초하여 표현을 선택할 수도 있다. 어쨌든, 서버 디바이스 (60) 는 그 다음에 선택된 표현의 데이터를 멀티캐스트 그룹으로 출력할 수도 있다 (360). 다시 말하면, 서버 디바이스 (60) 는 출력의 목적지 어드레스로서 멀티캐스트 그룹의 인터넷 프로토콜 (IP) 주소를 설정할 수도 있다. 더구나, 서버 디바이스 (60) 는 파일 전달 서비스, 이를테면 FLUTE 프로토콜에 따라 데이터를 출력할 수도 있다. 멀티캐스트 그룹의 어드레스로 데이터를 전송하는 것은 네트워크 내의 라우터들이 멀티캐스트 그룹에 가입한 디바이스들, 이를테면 클라이언트 디바이스들, 예컨대, 클라이언트 디바이스 (40) 로 멀티캐스트의 데이터를 복제하고 포워딩하게 할 수도 있다.

서버 디바이스 (60) 는 또한 네트워크 상황에서의 변경 (예컨대, 이용가능한 네트워크 대역폭의 변경) 및/또는 멀티캐스트 그룹에 가입한 사용자들의 수에서의 변경이 있는지의 여부를 결정할 수도 있다 (362). 그런 변경이 없다면 (362의 "아니오" 분기), 서버 디바이스 (60) 는 선택된 표현의 데이터를 멀티캐스트 그룹으로 계속 출력할 수도 있다 (360). 대안으로, 변경이 있다면 (362의 "예" 분기), 서버 디바이스 (60) 는 상이한 표현을 선택할 수도 있다 (364). 예를 들어, 사용자들의 수가 증가된다면, 서버 디바이스 (60) 는 낮은 비트레이트를 갖는 표현을 선택할 수도 있는 반면, 사용자들의 수가 감소된다면, 서버 디바이스 (60) 는 높은 비트레이트를 갖는 표현을 선택할 수도 있다.

덧붙여서, 도 10의 예에서 도시되지 않았지만, 서버 디바이스 (60), 또는 상이한 서버 디바이스는, 미디어 콘텐츠의 데이터에 대한 유니캐스트 요청을 수신할 수도 있다. 그런 요청은 언제라도 수신될 수도 있다. 본 개시물의 기법들에 따라, 요청은 서버 디바이스 (60) 에 의해 선택된 것과는 상이한 표현, 예컨대, 비교적 더 빈번한 스위치 포인트들을 갖는 표현으로부터의 데이터를 위한 것일 수도 있다. 응답하여, 서버 디바이스 (60), 또는 다른 서버 디바이스는, 요청된 데이터를 요청하는 디바이스로 전송할 수도 있다.

이런 방식으로, 도 10의 방법은 HTTP를 통한 동적 적응적 스트리밍 (DASH) 에 부합하는 미디어 콘텐츠를 획득하는 단계, 및 네트워크를 통한 파일 전달 서비스에 따라 미디어 콘텐츠의 데이터를 출력하는 단계를 포함하는 방법의 일 예를 나타낸다. 그 방법은, 클라이언트 디바이스로부터 미디어 콘텐츠의 제 1 부분에 대한 요청을 수신하는 단계로서, 그 요청이 유니캐스트 프로토콜에 따른 미디어 콘텐츠의 제 1 부분에 대한 요청을 포함하는, 요청을 수신하는 단계; 및 유니캐스트 프로토콜에 따라 제 1 부분에 대한 데이터를 출력하는 단계를 더 포함할 수도 있다. 파일 전달 서비스에 따라 미디어 콘텐츠의 데이터를 출력하는 단계는, 파일 전달 서비스에 따라 미디어 콘텐츠의 제 2 부분을 출력하는 단계를 포함할 수도 있고, 제 1 부분은 미디어 콘텐츠 내에서 제 2 부분보다는 시간적으로 이전일 수도 있다.

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

비제한적인 예로, 그런 컴퓨터 판독가능 저장 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광 디스크 스토리지, 자기 디스크 스토리지, 또는 다른 자기 저장 디바이스들, 플래시 메모리, 또는 소망의 프로그램 코드를 컴퓨터에 의해 액세스될 수 있는 명령들 또는 데이터 구조들의 형태로 저장하는데 사용될 수 있는 임의의 다른 매체를 포함할 수 있다. 또한, 임의의 접속이 컴퓨터 판독가능 매체로 적절히 칭해진다. 예를 들어, 명령들이 웹사이트, 서버, 또는 다른 원격 자원으로부터 동축 케이블, 광섬유 케이블, 연선 (twisted pair), 디지털 가입자 회선 (DSL), 또는 무선 기술들 이를테면 적외선, 라디오, 및/또는 마이크로파를 이용하여 송신된다면, 동축 케이블, 광섬유 케이블, 연선, DSL, 또는 적외선, 라디오, 및 마이크로파와 같은 무선 기술은 매체의 정의에 포함된다. 그러나, 컴퓨터-판독가능 저장 매체들 및 데이터 저장 매체들은 커넥션들, 반송파들, 신호들, 또는 다른 일시적 매체들을 포함하지 않지만, 대신 비-일시적 (non-transitory), 유형의 저장 매체들을 지향하고 있음이 이해되어야 한다. 디스크 (Disk 및 disc) 는 본원에서 사용되는 바와 같이, 콤팩트 디스크 (compact disc, CD), 레이저 디스크, 광 디스크, 디지털 다용도 디스크 (DVD), 플로피 디스크 (floppy disk) 및 블루레이 디스크를 포함하는데, disk들은 보통 데이터를 자기적으로 재생하지만, disc들은 레이저들로써 광적으로 데이터를 재생한다. 상기한 것들의 조합들은 또한 컴퓨터 판독가능 매체들의 범위 내에 포함되어야 한다.

명령들은 하나 이상의 프로세서들, 이를테면 하나 이상의 디지털 신호 프로세서들 (DSPs), 범용 마이크로프로세서들, 주문형 집적회로들 (ASICs), 필드 프로그램가능 로직 어레이들 (FPGAs), 또는 다른 동등한 집적 또는 개별 로직 회로에 의해 실행될 수도 있다. 따라서, 본원에서 사용되는 바와 같은 용어 "프로세서"는 앞서의 구조 또는 본원에서 설명된 기법들의 구현에 적합한 임의의 다른 구조 중의 어느 것을 나타낼 수도 있다. 덧붙여서, 일부 양태들에서, 본원에서 설명된 기능성은 인코딩 및 디코딩을 위해 구성되는, 또는 결합형 코덱 (codec) 으로 통합되는 전용 하드웨어 및/또는 소프트웨어 모듈들 내에 제공될 수도 있다. 또한, 본 기법들은 하나 이상의 회로들 또는 로직 엘리먼트들 내에 완전히 구현될 수 있다.

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

다양한 예들이 설명되어 있다. 이들 및 다른 예들은 다음의 청구항들의 범위 내에 있다.

Claims (59)

1. 비디오 데이터에 대한 정보를 취출하는 방법으로서,
   유니캐스트 프로토콜에 따라 미디어 콘텐츠의 제 1 부분을 취출 (retrive) 하는 단계로서, 상기 미디어 콘텐츠는 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하고, 상기 미디어 콘텐츠의 상기 제 1 부분은 제 1 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하는, 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하는 단계; 및
   파일 전달 서비스를 통해 멀티캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 제 2 부분을 취출하는 단계로서, 상기 제 1 부분 및 상기 제 2 부분은 상기 미디어 콘텐츠에서 시간적으로 연속적이고, 상기 제 2 부분은 제 2 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하고, 상기 제 2 시간적 지속기간은 상기 제 1 시간적 지속기간보다 긴, 상기 미디어 콘텐츠의 제 2 부분을 취출하는 단계를 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
2. 제 1 항에 있어서,
   상기 멀티캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 2 부분을 취출하는 단계는, 인터넷 프로토콜 (IP) 멀티캐스트 그룹에 참가하도록 요청하는 단계 또는 브로드캐스트 파일 전달을 수신하도록 등록하는 단계를 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
3. 제 2 항에 있어서,
   상기 미디어 콘텐츠의 상기 제 2 부분을 취출하는 단계는, 상기 IP 멀티캐스트 그룹에 참가하도록 요청하는 단계를 포함하며,
   상기 비디오 데이터에 대한 정보를 취출하는 방법은, 상기 IP 멀티캐스트 그룹에 대한 IP 주소를 수신하는 단계를 더 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
4. 제 1 항에 있어서,
   상기 제 1 부분은 상기 제 2 부분과는 상이한 코딩 특성들을 가지는, 비디오 데이터에 대한 정보를 취출하는 방법.
5. 제 1 항에 있어서,
   상기 파일 전달 서비스는 단방향 전송을 통한 파일 전달 (FLUTE) 을 포함하며,
   상기 비디오 데이터에 대한 정보를 취출하는 방법은, 상기 미디어 콘텐츠에 대한 하나 이상의 유니캐스트 URL들 (uniform resource locators) 을 나타내는 파일 전달 테이블 (FDT) 속성들을 수신하는 단계를 더 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
6. 제 1 항에 있어서,
   상기 미디어 콘텐츠의 상기 제 2 부분을 취출하는 단계는, 브로드캐스트 매체 액세스 제어 (MAC) 프로토콜을 통해 파일 브로드캐스트 서비스를 경유하여 상기 제 2 부분을 수신하는 단계를 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
7. 제 6 항에 있어서,
   상기 브로드캐스트 MAC 프로토콜은 향상된 멀티미디어 브로드캐스트 멀티캐스트 서비스 (eMBMS) 를 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
8. 제 1 항에 있어서,
   로컬 메모리에, 상기 파일 전달 서비스에 따라 수신된, 상기 미디어 콘텐츠의 상기 제 2 부분에 대한 데이터를 캐싱하는 단계를 더 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
9. 제 8 항에 있어서,
   미디어 데이터의 적어도 일부에 대한 후속 요청에 응답하여, 상기 로컬 메모리로부터 상기 캐싱된 데이터를 취출하는 단계를 더 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
10. 제 8 항에 있어서,
    상기 캐싱하는 단계는,
    상기 파일 전달 서비스에 따라 하나 이상의 캐싱 프리미티브들에 대한 값들을 수신하는 단계; 및
    상기 하나 이상의 캐싱 프리미티브들에 대한 상기 값들에 따라 상기 적어도 일부에 대한 데이터를 캐싱하는 단계를 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
11. 제 10 항에 있어서,
    상기 하나 이상의 캐싱 프리미티브들은, 미디어 콘텐츠의 적어도 일부가 전송되었던 날짜를 나타내는 날짜 프리미티브, 상기 미디어 콘텐츠의 상기 적어도 일부가 만료된 때를 나타내는 만료 프리미티브, 상기 미디어 콘텐츠의 특정 버전을 식별하는 엔티티 태그 (ETag), 및 상기 미디어 콘텐츠의 데이터가 캐싱가능함을 나타내는 캐시-제어 (Cache-Control) 헤더 중 하나 이상을 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
12. 제 8 항에 있어서,
    상기 미디어 콘텐츠의 상기 제 1 부분을 취출하는 단계는,
    상기 미디어 콘텐츠의 상기 제 1 부분이 캐시에 현재 저장되어있는지의 여부를 결정하는 단계; 및
    상기 미디어 콘텐츠의 상기 제 1 부분이 상기 캐시에 현재 저장되어있지 않은 경우에 상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하는 단계를 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
13. 제 1 항에 있어서,
    상기 미디어 콘텐츠의 상기 제 2 부분은 상기 미디어 콘텐츠의 상기 제 1 부분을 시간적으로 연속하여 뒤따르며,
    상기 미디어 콘텐츠의 상기 제 1 부분을 취출하는 단계는,
    상기 미디어 콘텐츠의 상기 제 1 부분이 캐시에 존재하는지의 여부를 결정하기 위해 상기 캐시에 쿼리하는 단계; 및
    상기 미디어 콘텐츠가 존재하지 않는 경우, 핸드오버가 브로드캐스트 전송과 유니캐스트 전송 사이에서 발생하였음을 암묵적으로 결정하는 단계를 포함하며,
    상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하는 단계는, 상기 미디어 콘텐츠의 상기 제 1 부분이 상기 캐시에 존재하지 않음을 상기 캐시에의 쿼리가 나타내는 경우에 및 상기 핸드오버가 발생하였다는 결정에 기초하여,
    상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하기 위한 파일 다운로드 요청을 제출하는 단계; 및
    상기 미디어 콘텐츠의 상기 제 1 부분을 상기 캐시에 저장하는 단계를 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
14. 제 13 항에 있어서,
    상기 파일 다운로드 요청은 하이퍼텍스트 전송 프로토콜 (HTTP) 요청을 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
15. 제 1 항에 있어서,
    상기 미디어 콘텐츠의 상기 제 1 부분은 상기 미디어 콘텐츠의 상기 제 2 부분을 시간적으로 연속하여 뒤따르고,
    상기 미디어 콘텐츠의 상기 제 2 부분을 취출하는 단계는,
    핸드오버가 유니캐스트 전송과 브로드캐스트 전송 사이에서 발생하였음을 결정하는 단계;
    상기 핸드오버가 발생하였다는 결정에 응답하여, 상기 미디어 콘텐츠의 상기 제 2 부분을 취출하기 위해 파일 전달 서비스에 가입하는 단계; 및
    상기 미디어 콘텐츠의 상기 제 2 부분을 캐시에 저장하는 단계를 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
16. 제 1 항에 있어서,
    상기 미디어 콘텐츠는 복수의 상이한 미디어 콘텐츠들 중 하나의 미디어 콘텐츠를 포함하며, 상기 복수의 상이한 미디어 콘텐츠들의 각각의 미디어 콘텐츠는 개별 비디오 채널에 대응하며,
    상기 비디오 데이터에 대한 정보를 취출하는 방법은,
    상기 복수의 상이한 미디어 콘텐츠들의 제 1 부분들을 취출하고 캐싱하는 단계;
    상기 복수의 상이한 미디어 콘텐츠들 중 상기 하나의 미디어 콘텐츠의 사용자 선택을 수신하는 단계; 및
    상기 미디어 콘텐츠의 상기 제 1 부분을 페치하기 위한 요청 후에 캐시 히트 (cache hit) 를 통해 제 1 미디어 콘텐츠들을 즉시 플레이하는 단계를 더 포함하며,
    상기 복수의 상이한 미디어 콘텐츠들 중 상기 하나의 미디어 콘텐츠의 제 2 부분을 취출하는 단계는, 상기 사용자 선택에 응답하여 상기 복수의 상이한 미디어 콘텐츠들 중 상기 하나의 미디어 콘텐츠의 상기 제 2 부분을 취출하는 단계를 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
17. 제 16 항에 있어서,
    상기 복수의 상이한 미디어 콘텐츠들의 각각의 미디어 콘텐츠의 제 1 부분들로부터 데이터를 출력하는 단계를 더 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
18. 제 17 항에 있어서,
    상기 복수의 상이한 미디어 콘텐츠들의 각각의 미디어 콘텐츠의 상기 제 1 부분들의 각각으로부터의 비디오 데이터를 실질적으로 동시에 디스플레이하는 단계를 더 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
19. 제 1 항에 있어서,
    상기 미디어 콘텐츠는 복수의 상이한 미디어 콘텐츠들 중 제 2 미디어 콘텐츠를 포함하며, 상기 복수의 상이한 미디어 콘텐츠들의 각각의 미디어 콘텐츠는 개별 비디오 채널에 대응하며,
    상기 복수의 상이한 미디어 콘텐츠들 중 제 1 미디어 콘텐츠의 데이터를 취출하는 단계; 및
    상기 제 1 미디어 콘텐츠의 상기 데이터를 취출한 후 상기 제 2 미디어 콘텐츠로 변경하기 위한 요청을 수신하는 단계를 더 포함하며,
    상기 제 2 미디어 콘텐츠의 제 1 부분 및 상기 제 2 미디어 콘텐츠의 제 2 부분을 취출하는 단계는, 상기 제 2 미디어 콘텐츠로 변경하기 위한 요청에 응답하여, 유니캐스트를 통해 상기 제 2 미디어 콘텐츠의 상기 제 1 부분 및 멀티캐스트 파일 다운로드를 통해 상기 제 2 미디어 콘텐츠의 상기 제 2 부분을 취출하는 단계를 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
20. 제 1 항에 있어서,
    상기 적응적 비디오 스트리밍 네트워크 프로토콜은 HTTP를 통한 동적 적응적 스트리밍 (DASH) 을 포함하는, 비디오 데이터에 대한 정보를 취출하는 방법.
21. 비디오 데이터에 대한 정보를 취출하는 디바이스로서,
    하나 이상의 프로세서를 포함하고,
    상기 하나 이상의 프로세서는,
    유니캐스트 프로토콜에 따라 미디어 콘텐츠의 제 1 부분을 취출하되, 상기 미디어 콘텐츠는 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하고, 상기 미디어 콘텐츠의 상기 제 1 부분은 제 1 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하고;
    파일 전달 서비스를 통해 멀티캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 제 2 부분을 취출하되, 상기 제 1 부분 및 상기 제 2 부분은 상기 미디어 콘텐츠에서 시간적으로 연속적이고, 상기 제 2 부분은 제 2 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하고, 상기 제 2 시간적 지속기간은 상기 제 1 시간적 지속기간보다 길도록 구성되는, 비디오 데이터에 대한 정보를 취출하는 디바이스.
22. 제 21 항에 있어서,
    메모리를 더 포함하며,
    상기 하나 이상의 프로세서들은, 상기 메모리에, 상기 파일 전달 서비스에 따라 수신된, 상기 미디어 콘텐츠의 상기 제 2 부분에 대한 데이터를 캐싱하도록 추가로 구성되는, 비디오 데이터에 대한 정보를 취출하는 디바이스.
23. 제 22 항에 있어서,
    상기 미디어 콘텐츠의 상기 제 1 부분을 취출하기 위해, 상기 하나 이상의 프로세서들은, 상기 미디어 콘텐츠의 상기 제 1 부분이 상기 메모리에 현재 저장되어 있는지의 여부를 결정하고, 상기 미디어 콘텐츠의 상기 제 1 부분이 상기 메모리에 현재 저장되어 있지 않은 경우에 상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하도록 구성되는, 비디오 데이터에 대한 정보를 취출하는 디바이스.
24. 제 21 항에 있어서,
    캐시를 구현하기 위한 메모리를 더 포함하며,
    상기 미디어 콘텐츠의 상기 제 2 부분은 상기 미디어 콘텐츠의 상기 제 1 부분을 시간적으로 연속하여 뒤따르고,
    상기 미디어 콘텐츠의 상기 제 1 부분을 취출하기 위해, 상기 하나 이상의 프로세서들은, 상기 미디어 콘텐츠의 상기 제 1 부분이 캐시에 존재하는지의 여부를 결정하기 위해 상기 캐시에 쿼리하고, 상기 미디어 콘텐츠가 존재하지 않는 경우, 핸드오버가 브로드캐스트 전송과 유니캐스트 전송 사이에서 발생하였음을 암묵적으로 결정하도록 구성되며,
    상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하기 위해, 상기 하나 이상의 프로세서들은, 상기 미디어 콘텐츠의 상기 제 1 부분이 상기 캐시에 존재하지 않음을 상기 캐시에의 쿼리가 나타내는 경우에 및 상기 핸드오버가 발생하였다는 결정에 기초하여, 상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하기 위한 파일 다운로드 요청을 제출하고, 상기 미디어 콘텐츠의 상기 제 1 부분을 상기 캐시에 저장하도록 구성되는, 비디오 데이터에 대한 정보를 취출하는 디바이스.
25. 제 21 항에 있어서,
    캐시를 구현하기 위한 메모리를 더 포함하며,
    상기 미디어 콘텐츠의 상기 제 1 부분은 상기 미디어 콘텐츠의 상기 제 2 부분을 시간적으로 연속하여 뒤따르고,
    상기 미디어 콘텐츠의 상기 제 2 부분을 취출하기 위해, 상기 하나 이상의 프로세서들은, 핸드오버가 유니캐스트 전송과 브로드캐스트 전송 사이에서 발생하였음을 결정하며, 상기 핸드오버가 발생하였다는 결정에 응답하여 상기 미디어 콘텐츠의 상기 제 2 부분을 취출하기 위해 파일 전달 서비스에 가입하고, 상기 미디어 콘텐츠의 상기 제 2 부분을 캐시에 저장하도록 구성되는, 비디오 데이터에 대한 정보를 취출하는 디바이스.
26. 비디오 데이터에 대한 정보를 취출하는 디바이스로서,
    유니캐스트 프로토콜에 따라 미디어 콘텐츠의 제 1 부분을 취출하는 수단으로서, 상기 미디어 콘텐츠는 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하고, 상기 미디어 콘텐츠의 상기 제 1 부분은 제 1 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하는, 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하는 수단; 및
    파일 전달 서비스를 통해 멀티캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 제 2 부분을 취출하는 수단으로서, 상기 제 1 부분 및 상기 제 2 부분은 상기 미디어 콘텐츠에서 시간적으로 연속적이고, 상기 제 2 부분은 제 2 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하고, 상기 제 2 시간적 지속기간은 상기 제 1 시간적 지속기간보다 긴, 상기 미디어 콘텐츠의 상기 제 2 부분을 취출하는 수단을 포함하는, 비디오 데이터에 대한 정보를 취출하는 디바이스.
27. 제 26 항에 있어서,
    상기 파일 전달 서비스에 따라 수신된 상기 미디어 콘텐츠의 상기 제 2 부분에 대한 데이터를 캐싱하는 수단을 더 포함하는, 비디오 데이터에 대한 정보를 취출하는 디바이스.
28. 제 27 항에 있어서,
    상기 미디어 콘텐츠의 상기 제 1 부분을 취출하는 수단은,
    상기 미디어 콘텐츠의 상기 제 1 부분이 상기 캐싱하는 수단에 현재 저장되어 있는지의 여부를 결정하는 수단; 및
    상기 미디어 콘텐츠의 상기 제 1 부분이 상기 캐싱하는 수단에 현재 저장되어있지 않은 경우에 상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하는 수단을 포함하는, 비디오 데이터에 대한 정보를 취출하는 디바이스.
29. 제 26 항에 있어서,
    상기 미디어 콘텐츠의 상기 제 2 부분은 상기 미디어 콘텐츠의 상기 제 1 부분을 시간적으로 연속하여 뒤따르며,
    상기 미디어 콘텐츠의 상기 제 1 부분을 취출하는 수단은,
    상기 미디어 콘텐츠의 상기 제 1 부분이 캐시에 존재하는지의 여부를 결정하기 위해 상기 캐시에 쿼리하는 수단; 및
    상기 미디어 콘텐츠가 존재하는 않는 경우, 핸드오버가 브로드캐스트 전송과 유니캐스트 전송 사이에서 발생하였음을 암묵적으로 결정하는 수단을 포함하며,
    상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하는 수단은,
    상기 미디어 콘텐츠의 상기 제 1 부분이 상기 캐시에 존재하지 않음을 상기 캐시에의 쿼리가 나타내는 경우에 및 상기 핸드오버가 발생하였다는 결정에 기초하여,
    상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하기 위한 파일 다운로드 요청을 제출하는 수단; 및
    상기 미디어 콘텐츠의 상기 제 1 부분이 상기 캐시에 존재하지 않음을 상기 캐시에의 쿼리가 나타내는 경우에 및 상기 핸드오버가 발생하였다는 결정에 기초하여, 상기 미디어 콘텐츠의 상기 제 1 부분을 상기 캐시에 저장하는 수단을 포함하는, 비디오 데이터에 대한 정보를 취출하는 디바이스.
30. 제 26 항에 있어서,
    상기 미디어 콘텐츠의 상기 제 1 부분은 상기 미디어 콘텐츠의 상기 제 2 부분을 시간적으로 연속하여 뒤따르고,
    상기 미디어 콘텐츠의 상기 제 2 부분을 취출하는 수단은,
    핸드오버가 유니캐스트 전송과 브로드캐스트 전송 사이에서 발생하였음을 결정하는 수단,
    상기 핸드오버가 발생하였다는 결정에 응답하여, 상기 미디어 콘텐츠의 상기 제 2 부분을 취출하기 위해 상기 파일 전달 서비스에 가입하는 수단; 및
    상기 미디어 콘텐츠의 상기 제 2 부분을 캐시에 저장하는 수단을 포함하는, 비디오 데이터에 대한 정보를 취출하는 디바이스.
31. 명령들을 저장하는 컴퓨터 판독가능 저장 매체로서,
    상기 명령들은, 실행될 경우, 하나 이상의 프로세서들로 하여금,
    유니캐스트 프로토콜에 따라 미디어 콘텐츠의 제 1 부분을 취출하게 하되, 상기 미디어 콘텐츠는 적응적 비디오 스트리밍 네트워크 프로토콜에 부합하고, 상기 미디어 콘텐츠의 상기 제 1 부분은 제 1 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하며;
    파일 전달 서비스를 통해 멀티캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 제 2 부분을 취출하게 하되, 상기 제 1 부분 및 상기 제 2 부분은 상기 미디어 콘텐츠에서 시간적으로 연속적이고, 상기 제 2 부분은 제 2 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하고, 상기 제 2 시간적 지속기간은 상기 제 1 시간적 지속기간보다 길게 하는, 명령들을 포함하는, 컴퓨터 판독가능 저장 매체.
32. 제 31 항에 있어서,
    상기 하나 이상의 프로세서들로 하여금, 로컬 메모리에, 상기 파일 전달 서비스에 따라 수신된 상기 미디어 콘텐츠의 상기 제 2 부분에 대한 데이터를 캐싱하게 하는 명령들을 더 포함하는, 컴퓨터 판독가능 저장 매체.
33. 제 32 항에 있어서,
    상기 하나 이상의 프로세서들로 하여금, 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하게 하는 명령들은,
    상기 하나 이상의 프로세서들로 하여금,
    상기 미디어 콘텐츠의 상기 제 1 부분이 캐시에 현재 저장되어있는지의 여부를 결정하게 하고; 그리고
    상기 미디어 콘텐츠의 상기 제 1 부분이 상기 캐시에 현재 저장되어있지 않은 경우에 상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하게 하는
    명령들을 포함하는, 컴퓨터 판독가능 저장 매체.
34. 제 31 항에 있어서,
    상기 미디어 콘텐츠의 상기 제 2 부분은 상기 미디어 콘텐츠의 상기 제 1 부분을 시간적으로 연속하여 뒤따르며,
    상기 하나 이상의 프로세서들로 하여금 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하게 하는 명령들은,
    상기 하나 이상의 프로세서들로 하여금,
    상기 미디어 콘텐츠의 상기 제 1 부분이 캐시에 존재하는지의 여부를 결정하기 위해 상기 캐시에 쿼리하게 하고; 그리고
    상기 미디어 콘텐츠가 존재하지 않는 경우, 핸드오버가 브로드캐스트 전송과 유니캐스트 전송 사이에서 발생하였음을 암묵적으로 결정하게 하는
    명령들을 포함하며, 그리고
    상기 하나 이상의 프로세서들로 하여금 상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하게 하는 명령들은,
    상기 하나 이상의 프로세서들로 하여금, 상기 미디어 콘텐츠의 상기 제 1 부분이 상기 캐시에 존재하지 않음을 상기 캐시에의 쿼리가 나타내는 경우에 및 상기 핸드오버가 발생하였다는 결정에 기초하여,
    상기 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 상기 제 1 부분을 취출하기 위한 파일 다운로드 요청을 제출하게 하고; 그리고
    상기 미디어 콘텐츠의 상기 제 1 부분을 상기 캐시에 저장하게 하는
    명령들을 포함하는, 컴퓨터 판독가능 저장 매체.
35. 제 31 항에 있어서,
    상기 미디어 콘텐츠의 상기 제 1 부분은 상기 미디어 콘텐츠의 상기 제 2 부분을 시간적으로 연속하여 뒤따르고,
    상기 하나 이상의 프로세서들로 하여금 상기 미디어 콘텐츠의 상기 제 2 부분을 취출하게 하는 명령들은,
    상기 하나 이상의 프로세서들로 하여금,
    핸드오버가 유니캐스트 전송과 브로드캐스트 전송 사이에서 발생하였음을 결정하게 하고,
    상기 핸드오버가 발생하였다는 결정에 응답하여, 상기 미디어 콘텐츠의 상기 제 2 부분을 취출하기 위해 상기 파일 전달 서비스에 가입하게 하고; 그리고
    상기 미디어 콘텐츠의 상기 제 2 부분을 캐시에 저장하게 하는 명령들을 포함하는, 컴퓨터 판독가능 저장 매체.
36. 비디오 데이터에 대한 정보를 출력하는 방법으로서,
    적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는 미디어 콘텐츠를 획득하는 단계;
    유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 제 1 부분을 출력하는 단계로서, 상기 미디어 콘텐츠의 상기 제 1 부분은 제 1 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하는, 상기 미디어 콘텐츠의 상기 제 1 부분을 출력하는 단계; 및
    파일 전달 서비스에 따라 상기 미디어 콘텐츠의 제 2 부분을 출력하는 단계로서, 상기 제 1 부분 및 상기 제 2 부분은 상기 미디어 콘텐츠에서 시간적으로 연속적이고, 상기 제 2 부분은 제 2 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하고, 상기 제 2 시간적 지속기간은 상기 제 1 시간적 지속기간보다 긴, 상기 미디어 콘텐츠의 상기 제 2 부분을 출력하는 단계를 포함하는, 비디오 데이터에 대한 정보를 출력하는 방법.
37. 제 36 항에 있어서,
    상기 파일 전달 서비스는 단방향 전송을 통한 파일 전달 (FLUTE) 프로토콜을 포함하는, 비디오 데이터에 대한 정보를 출력하는 방법.
38. 제 37 항에 있어서,
    상기 미디어 콘텐츠에 대한 하나 이상의 유니캐스트 URL들 (uniform resource locators) 을 나타내는 파일 전달 테이블 (FDT) 속성들을 출력하는 단계를 더 포함하는, 비디오 데이터에 대한 정보를 출력하는 방법.
39. 제 36 항에 있어서,
    상기 적응적 비디오 스트리밍 네트워크 프로토콜은 HTTP를 통한 동적 적응적 스트리밍 (DASH) 을 포함하는, 비디오 데이터에 대한 정보를 출력하는 방법.
40. 제 36 항에 있어서,
    클라이언트 디바이스로부터 상기 미디어 콘텐츠의 상기 제 1 부분에 대한 요청을 수신하는 단계로서, 상기 요청은 상기 유니캐스트 프로토콜에 따른 상기 미디어 콘텐츠의 상기 제 1 부분에 대한 요청을 포함하는, 상기 요청을 수신하는 단계; 및
    상기 유니캐스트 프로토콜에 따라 상기 제 1 부분에 대한 데이터를 출력하는 단계를 더 포함하는, 비디오 데이터에 대한 정보를 출력하는 방법.
41. 제 36 항에 있어서,
    상기 제 1 부분은 상기 미디어 콘텐츠의 제 1 표현의 제 1 부분을 포함하고,
    상기 제 2 부분은 상기 미디어 콘텐츠의 제 2 표현의 제 2 부분을 포함하며, 상기 제 2 표현은 상기 제 1 표현과는 상이한, 비디오 데이터에 대한 정보를 출력하는 방법.
42. 제 41 항에 있어서,
    상기 제 1 표현은 상기 제 2 표현과는 상이한 코딩 특성들 및 상기 제 2 표현과는 상이한 랜더링 특성들 중 적어도 하나를 가지는, 비디오 데이터에 대한 정보를 출력하는 방법.
43. 제 36 항에 있어서,
    상기 미디어 콘텐츠의 상기 제 2 부분을 출력하는 단계는, 인터넷 프로토콜 (IP) 멀티캐스트 및 향상된 멀티미디어 브로드캐스트 멀티캐스트 서비스 (eMBMS) 중 적어도 하나를 통해 상기 파일 전달 서비스로 상기 미디어 콘텐츠의 상기 제 2 부분을 출력하는 단계를 포함하는, 비디오 데이터에 대한 정보를 출력하는 방법.
44. 제 36 항에 있어서,
    클라이언트 디바이스로 하여금 상기 미디어 콘텐츠의 상기 제 1 부분 및 상기 미디어 콘텐츠의 상기 제 2 부분 중 적어도 하나를 캐싱하게 하기 위해 상기 파일 전달 서비스에 따라 하나 이상의 캐싱 프리미티브들을 출력하는 단계를 더 포함하는, 비디오 데이터에 대한 정보를 출력하는 방법.
45. 제 36 항에 있어서,
    네트워크 섹터에서 상기 파일 전달 서비스에 대한 가입자 단말들의 수를 결정하는 단계; 및
    상기 네트워크 섹터에서 상기 파일 전달 서비스에 대한 상기 결정된 가입자 단말들의 수 및 상기 미디어 콘텐츠의 표현들의 비트레이트들에 기초하여 상기 미디어 콘텐츠의 표현을 선택하는 단계를 더 포함하며,
    상기 미디어 콘텐츠의 데이터를 출력하는 단계는 상기 선택된 표현의 데이터를 출력하는 단계를 포함하고,
    상기 비디오 데이터에 대한 정보를 출력하는 방법은 상기 가입자 단말들로 하여금 상기 선택된 표현의 비트레이트로 선택된 미디어 세그먼트들을 다운로드하고 캐싱하게 하는 단계를 더 포함하는, 비디오 데이터에 대한 정보를 출력하는 방법.
46. 제 45 항에 있어서,
    상기 네트워크 섹터에서 상기 파일 전달 서비스에 대한 상기 가입자 단말들의 수를 모니터링하는 단계, 및
    상기 네트워크 섹터에서 상기 파일 전달 서비스에 대한 상기 결정된 가입자 단말들의 수 및 상기 미디어 콘텐츠의 표현들의 비트레이트들에 기초하여 상기 미디어 콘텐츠의 상기 표현을, 상기 가입자 단말들의 수가 증가하는 경우 더 높은 비트레이트로 또는 상기 가입자 단말들의 수가 감소하는 경우 더 낮은 비트레이트로 변경하는 단계를 더 포함하는, 비디오 데이터에 대한 정보를 출력하는 방법.
47. 제 45 항에 있어서,
    가입자들의 수에 기초하여, 상기 가입자들의 수에 의해 표현되는 상기 섹터에서의 총 사용자들의 백분율을 결정하는 단계;
    상기 섹터에 할당된 대역폭의 양을 결정하는 단계; 및
    상기 가입자들의 수에 의해 표현되는 상기 총 사용자들의 상기 백분율에 기초하여 상기 섹터에 할당된 상기 대역폭의 비례 량을 결정하는 단계를 더 포함하며,
    상기 미디어 콘텐츠의 표현을 선택하는 단계는, 상기 섹터에 할당된 상기 대역폭의 상기 결정된 비례 량에 의해 수용될 수 있는 비트레이트를 갖는 표현을 선택하는 단계를 포함하는, 비디오 데이터에 대한 정보를 출력하는 방법.
48. 비디오 데이터에 대한 정보를 출력하는 디바이스로서,
    적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는 미디어 콘텐츠를 획득하며, 유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 제 1 부분을 출력하되, 상기 미디어 콘텐츠의 상기 제 1 부분은 제 1 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하며, 그리고 파일 전달 서비스에 따라 상기 미디어 콘텐츠의 제 2 부분을 출력하되, 상기 제 1 부분 및 상기 제 2 부분은 상기 미디어 콘텐츠에서 시간적으로 연속적이고, 상기 제 2 부분은 제 2 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하고, 상기 제 2 시간적 지속기간은 상기 제 1 시간적 지속기간보다 길도록 구성되는, 하나 이상의 프로세서들을 포함하는, 비디오 데이터에 대한 정보를 출력하는 디바이스.
49. 제 48 항에 있어서,
    상기 하나 이상의 프로세서들은, 클라이언트 디바이스로 하여금 상기 미디어 콘텐츠의 상기 제 1 부분 및 상기 미디어 콘텐츠의 상기 제 2 부분 중 적어도 하나를 캐싱하게 하기 위해 상기 파일 전달 서비스에 따라 하나 이상의 캐싱 프리미티브들을 출력하도록 추가로 구성되는, 비디오 데이터에 대한 정보를 출력하는 디바이스.
50. 제 48 항에 있어서,
    상기 하나 이상의 프로세서들은, 네트워크 섹터에서 상기 파일 전달 서비스에 대한 가입자 단말들의 수를 결정하고, 상기 네트워크 섹터에서 상기 파일 전달 서비스에 대한 상기 결정된 가입자 단말들의 수 및 상기 미디어 콘텐츠의 표현들의 비트레이트들에 기초하여 상기 미디어 콘텐츠의 표현을 선택하도록 추가로 구성되며,
    상기 미디어 콘텐츠의 데이터를 출력하기 위해, 상기 하나 이상의 프로세서들은 상기 선택된 표현의 데이터를 출력하도록 구성되고,
    상기 하나 이상의 프로세서들은, 상기 가입자 단말들로 하여금 상기 선택된 표현의 비트레이트로 선택된 미디어 세그먼트들을 다운로드하고 캐싱하게 하도록 추가로 구성되는, 비디오 데이터에 대한 정보를 출력하는 디바이스.
51. 제 50 항에 있어서,
    상기 하나 이상의 프로세서들은, 가입자들의 수에 기초하여, 상기 가입자들의 수에 의해 표현되는 상기 섹터에서의 총 사용자들의 백분율을 결정하며, 상기 섹터에 할당된 대역폭의 양을 결정하고, 그리고 상기 가입자들의 수에 의해 표현되는 상기 총 사용자들의 상기 백분율에 기초하여 상기 섹터에 할당된 상기 대역폭의 비례 량을 결정하도록 구성되며,
    상기 미디어 콘텐츠의 표현을 선택하기 위해, 상기 하나 이상의 프로세서들은 상기 섹터에 할당된 상기 대역폭의 상기 결정된 비례 량에 의해 수용될 수 있는 비트레이트를 갖는 표현을 선택하도록 구성되는, 비디오 데이터에 대한 정보를 출력하는 디바이스.
52. 비디오 데이터에 대한 정보를 출력하는 디바이스로서,
    적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는 미디어 콘텐츠를 획득하는 수단;
    유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 제 1 부분을 출력하는 수단으로서, 상기 미디어 콘텐츠의 상기 제 1 부분은 제 1 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하는, 상기 미디어 콘텐츠의 상기 제 1 부분을 출력하는 수단; 및
    파일 전달 서비스에 따라 상기 미디어 콘텐츠의 제 2 부분을 출력하는 수단으로서, 상기 제 1 부분 및 상기 제 2 부분은 상기 미디어 콘텐츠에서 시간적으로 연속적이고, 상기 제 2 부분은 제 2 시간적 지속기간을 포함하는 하나 이상의 세그먼트들을 포함하고, 상기 제 2 시간적 지속기간은 상기 제 1 시간적 지속기간보다 긴, 상기 미디어 콘텐츠의 상기 제 2 부분을 출력하는 수단을 포함하는, 비디오 데이터에 대한 정보를 출력하는 디바이스.
53. 제 52 항에 있어서,
    클라이언트 디바이스로 하여금 상기 미디어 콘텐츠의 상기 제 1 부분 및 상기 미디어 콘텐츠의 상기 제 2 부분 중 적어도 하나를 캐싱하게 하기 위해, 상기 파일 전달 서비스에 따라 하나 이상의 캐싱 프리미티브들을 출력하는 수단을 더 포함하는, 비디오 데이터에 대한 정보를 출력하는 디바이스.
54. 제 52 항에 있어서,
    네트워크 섹터에서 상기 파일 전달 서비스에 대한 가입자 단말들의 수를 결정하는 수단; 및
    상기 네트워크 섹터에서 상기 파일 전달 서비스에 대한 상기 결정된 가입자 단말들의 수 및 상기 미디어 콘텐츠의 표현들의 비트레이트들에 기초하여 상기 미디어 콘텐츠의 표현을 선택하는 수단을 더 포함하며,
    상기 미디어 콘텐츠의 데이터를 출력하는 수단은 상기 선택된 표현의 데이터를 출력하는 수단을 포함하고,
    상기 비디오 데이터에 대한 정보를 출력하는 디바이스는, 상기 가입자 단말들로 하여금 상기 선택된 표현의 상기 비트레이트로 선택된 미디어 세그먼트들을 다운로드하고 캐싱하게 하는 수단을 더 포함하는, 비디오 데이터에 대한 정보를 출력하는 디바이스.
55. 제 54 항에 있어서,
    가입자들의 수에 기초하여, 상기 가입자들의 수에 의해 표현되는 상기 섹터에서의 총 사용자들의 백분율을 결정하는 수단;
    상기 섹터에 할당된 대역폭의 양을 결정하는 수단; 및
    상기 가입자들의 수에 의해 표현되는 상기 총 사용자들의 상기 백분율에 기초하여 상기 섹터에 할당된 상기 대역폭의 비례 량을 결정하는 수단을 더 포함하며,
    상기 미디어 콘텐츠의 표현을 선택하는 수단은, 상기 섹터에 할당된 상기 대역폭의 상기 결정된 비례 량에 의해 수용될 수 있는 비트레이트를 갖는 표현을 선택하는 수단을 포함하는, 비디오 데이터에 대한 정보를 출력하는 디바이스.
56. 명령들을 저장하는 컴퓨터 판독가능 저장 매체로서,
    상기 명령들은, 실행될 경우, 하나 이상의 프로세서들로 하여금,
    적응적 비디오 스트리밍 네트워크 프로토콜에 부합하는 미디어 콘텐츠를 획득하게 하고;
    유니캐스트 프로토콜에 따라 상기 미디어 콘텐츠의 제 1 부분을 출력하게 하되, 상기 미디어 콘텐츠의 상기 제 1 부분은 제 1 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하고; 그리고
    파일 전달 서비스에 따라 상기 미디어 콘텐츠의 제 2 부분을 출력하게 하되,상기 제 1 부분 및 상기 제 2 부분은 상기 미디어 콘텐츠에서 시간적으로 연속적이고, 상기 제 2 부분은 제 2 시간적 지속기간을 가지는 하나 이상의 세그먼트들을 포함하고, 상기 제 2 시간적 지속기간은 상기 제 1 시간적 지속기간보다 길게 하는, 컴퓨터 판독가능 저장 매체.
57. 제 56 항에 있어서,
    클라이언트 디바이스로 하여금 상기 미디어 콘텐츠의 상기 제 1 부분 및 상기 미디어 콘텐츠의 상기 제 2 부분 중 적어도 하나를 캐싱하게 하기 위해, 상기 하나 이상의 프로세서들로 하여금, 상기 파일 전달 서비스에 따라 하나 이상의 캐싱 프리미티브들을 출력하게 하는 명령들을 더 포함하는, 컴퓨터 판독가능 저장 매체.
58. 제 56 항에 있어서,
    상기 하나 이상의 프로세서들로 하여금,
    네트워크 섹터에서 상기 파일 전달 서비스에 대한 가입자 단말들의 수를 결정하게 하고; 그리고
    상기 네트워크 섹터에서 상기 파일 전달 서비스에 대한 상기 결정된 가입자 단말들의 수 및 상기 미디어 콘텐츠의 표현들의 비트레이트들에 기초하여 상기 미디어 콘텐츠의 표현을 선택하게 하는 명령들을 더 포함하며,
    상기 하나 이상의 프로세서들로 하여금 상기 미디어 콘텐츠의 데이터를 출력하게 하는 명령들은, 상기 하나 이상의 프로세서들로 하여금 상기 선택된 표현의 데이터를 출력하게 하는 명령들을 포함하고,
    상기 하나 이상의 프로세서들이 상기 가입자 단말들로 하여금 상기 선택된 표현의 상기 비트레이트로 선택된 미디어 세그먼트들을 다운로드하고 캐싱하게 하는 명령들을 더 포함하는, 컴퓨터 판독가능 저장 매체.
59. 제 58 항에 있어서,
    상기 하나 이상의 프로세서들로 하여금,
    가입자들의 수에 기초하여, 상기 가입자들의 수에 의해 표현되는 상기 섹터에서의 총 사용자들의 백분율을 결정하게 하고;
    상기 섹터에 할당된 대역폭의 양을 결정하게 하고; 그리고
    상기 가입자들의 수에 의해 표현되는 상기 총 사용자들의 상기 백분율에 기초하여 상기 섹터에 할당된 상기 대역폭의 비례 량을 결정하게 하는 명령들을 더 포함하며,
    상기 하나 이상의 프로세서들로 하여금 상기 미디어 콘텐츠의 표현들을 선택하게 하는 명령들은, 상기 하나 이상의 프로세서들로 하여금, 상기 섹터에 할당된 상기 대역폭의 상기 결정된 비례 량에 의해 수용될 수 있는 비트레이트를 갖는 표현을 선택하게 하는 명령들을 포함하는, 컴퓨터 판독가능 저장 매체.

Images