KR20130118944A - 실시간 또는 준 실시간 스트리밍 - Google Patents

Abstract

준 실시간 콘텐츠 스트리밍 시스템은, 한 실시예에서, 재생목록 파일에 의해 표시된 콘텐츠의 타입의 표시자를 포함하는 재생목록 파일을 이용할 수 있다. 이 타입은, 재생목록 파일의 타입을 명시하는, Video on Demand(VOD) 또는 라이브 또는 이벤트와 같은 파라미터로 표시될 수 있고, 클라이언트 장치는 이 파라미터에 의해 표시된 재생목록 파일의 타입에 기초하여 재생목록 파일을 처리할 수 있다. 예를 들어, 클라이언트 장치는, 재생목록 파일로부터 재생목록의 타입을 판정한 후에 재생목록 파일의 처리시 효율 최적화를 행할 수 있다. 예를 들어, 클라이언트는, 재생목록 파일이 VOD 재생목록임을 알면, 새로운 변종 재생목록으로 전환시에 이전에 이용된 변종 재생목록을 폐기하는 것이 아니라 이전에 이용된 변종 재생목록을 세이브할 수 있다.

Description

실시간 또는 준 실시간 스트리밍{REAL-TIME OR NEAR REAL-TIME STREAMING}

관련 출원

본 출원은, 2011년 1월 11일 출원된 미국 가출원 제61/431,813호(Docket No. P7437Z11)의 출원일의 혜택을 우선권 주장하며, 본 출원은 이 가출원을 참조로 본 명세서에 포함한다.

본 출원은 하기의 특허 출원에도 역시 관련되어 있다:

(1) 2008년 12월 31일 출원된 출원 번호 제61/142,110호 (Docket No. P7437Z);

(2) 2009년 3월 16일 출원된 출원 번호 제61/160,693호 (Docket No. P7437Z2);

(3) 2009년 3월 17일 출원된 출원 번호 제61/161,036호 (Docket No. P7437Z3);

(4) 2009년 4월 7일 출원된 출원 번호 제61/167,524호 (Docket No. P7437Z4);

(5) 2009년 9월 8일 출원된 출원 번호 제61/240,648호 (Docket No. P7437Z5);

(6) 2009년 12월 21일 출원된 출원 번호 제61/288,828호 (Docket No. P7437Z6);

(7) 2010년 4월 1일 출원된 출원 번호 제61/320,213호 (Docket No. P7437Z7);

(8) 2010년 4월 7일 출원된 출원 번호 제61/321,767호 (Docket No. P7437Z8);

(9) 2010년 6월 4일 출원된 출원 번호 제61/351,824호 (Docket No. P7437Z9); 및

(10) 2010년 8월 31일 출원된 출원 번호 제61/378,893호 (Docket No. P7437Z10).

이들 미국 가출원들 모두는 본 개시와 일치하는 범위까지 참조로 본 명세서에 포함된다.

본 미국 특허 출원은 이하의 미국 특허 출원들과 관련되며, 이들 각각은 본 개시와 일치하는 범위까지 참조로 본 명세서에 포함된다:

(1) 발명의 명칭이 "Real-Time or Near Real-Time Streaming"인 2009년 6월 5일 출원된 출원 번호 제12/479,690호 (Docket No. P7437US1);

(2) 발명의 명칭이 "Variant Streams for Real-Time or Near Real-Time Streaming"인 2009년 6월 5일 출원된 출원 번호 제12/479,698호 (Docket No. P7437US2);

(3) 발명의 명칭이"Updatable Real-Time or Near Real-Time Streaming"인 2009년 6월 5일 출원된 출원 번호 제12/479,732호 (Docket No. P7437US3);

(4) 발명의 명칭이 "Playlists for Real-Time or Near Real-Time Streaming"인 2009년 6월 5일 출원된 출원 번호 제12/479,735호 (Docket No. P7437US4);

(5) 발명의 명칭이 "Variant Streams for Real-Time or Near Real-Time Streaming to Provide Failover Protection"인 2010년 9월 8일 출원된 출원 번호 제12/878,002호(Docket No. P7437X); 및

(6) 발명의 명칭이 "Real-Time or Near Real-Time Streaming with Compressed Playlists"인 2010년 12월 14일 출원된 출원 번호 제12/968,202호 (Docket No. P7437X2).

기술 분야

본 발명의 실시예들은 데이터 전송 기술에 관한 것이다. 더 구체적으로는, 본 발명의 실시예들은, 예를 들어, 하이퍼텍스트 전송 프로토콜(HTTP; HyperText Transfer Protocol)과 같은 비-스트리밍 프로토콜을 이용한 데이터의 스트리밍을 허용하는 기술에 관한 것이다.

콘텐츠의 스트리밍이란, 일반적으로 끊임없이 서버 장치로부터 전송되고 클라이언트 장치에 의해 수신되는 멀티미디어 콘텐츠를 말한다. 콘텐츠는 대개 스트리밍 서버에 의해 전달 중인 동안 엔드-유저에게 프리젠팅된다. 명칭은 미디어 그 자체가 아니라 미디어의 전달 방법을 말한다.

현재의 스트리밍 서비스는 일반적으로 전문화된 서버가 "라이브" 콘텐츠를 엔드 유저에게 배포할 것을 요구한다. 임의의 큰 규모의 배치에서, 이것은 큰 비용을 초래할 수 있고, 전문화된 기술이 셋업되고 운영될 것을 요구한다. 이것은 바람직한 것보다 적은 콘텐츠 라이브러리가 스트리밍에 이용가능하게 되는 결과를 초래한다.

여기서 설명되는 한 실시예에서, 재생목록 파일은 재생목록 파일에 의해 제공되는 콘텐츠의 타입을 나타낼 수 있다. 콘텐츠의 타입은 재생목록 파일의 타입을 정의할 수 있고, 재생목록 파일의 타입은 재생목록 파일 내의 태그의 파라미터에서 명시될 수 있다. 한 실시예에서, 태그는 #EXT-X-PLAYLIST-TYPE:[VOD|LIVE|EVENT]의 형태를 취할 수 있고, 여기서 이 태그는 VOD 또는 Live 또는 Event 중 하나를 명시하고, 여기서 "VOD"는 재생목록 파일이 Video on Demand 콘텐츠임을 나타내고, "Live"는 재생목록 파일이, 비확정 시작 시간(indefinite start time)을 가질 수 있고, 클라이언트 장치에서 프리젠테이션을 위해(예를 들어, 비디오의 디스플레이를 통한 재생) 미디어 파일들이 수신되는 것과 거의 동시에 발생할 수 있는 라이브 콘텐츠임을 나타내며, "Event"는, 재생목록 파일이, 비확정 종료 시간을 가질 수 있으나 확정 고정된 시작 시간(definite, fixed starting time)을 가질 수 있고 클라이언트 장치에서의 프리젠테이션을 위해 미디어 파일들이 수신되는 것과 거의 동시에 발생할 수 있는 이벤트를 위한 것임을 나타낸다. 재생목록 파일은, 클라이언트 장치가 재생목록 파일을 수신한 후 클라이언트 장치에 의해 재생목록 파일에 의해 표시된 순서로 검색될 수 있는 복수의 미디어 파일들을 나타내는 URI(Universal Resource Indicators)를 포함할 수 있고, 재생목록 파일은 또한, 재생목록 파일 내의 복수의 미디어 파일의 재생에 관련된 ("VOD" 또는 "Live"와 같은) 파라미터들을 갖는 #EXT-X-PLAYLIST-TYPE 태그와 같은 복수의 태그를 포함할 수 있다.

재생목록 파일 내의 TYPE 태그(예를 들어, #EXT-X-PLAYLIST-TYPE)의 존재는, 재생목록이 콘텐츠의 타입과 일치하는 동작의 방식을 고수할 것임을 효과적으로 공표하고, 이것은 클라이언트 장치가 재생목록의 타입에 대해 최적화될 수 있는 방식으로 재생목록을 처리하는 것을 허용할 수 있다. 클라이언트 장치는 "VOD" 또는 "Live" 또는 "Event"와 같은 재생목록 타입 표시자의 존재를 검사할 수 있고, 그 재생목록 타입 표시자에 따라 최적의 방식으로 재생목록 파일을 처리할 수 있다. 예를 들어, 재생목록 타입 표시자가 "VOD"일 때, 클라이언트 장치는 그 재생목록 파일을 업데이트하지 않도록 구성될 수 있는데, 이것은 Video on Demand에 대한 재생목록은 바뀌지 않을 것이므로 업데이트를 요청할 필요가 없다고 가정될 수 있기 때문이다. 또한, 재생목록 타입 표시자가 "VOD"일 때, 클라이언트 장치는 ENDLIST 태그(또는 재생목록이 끝임을 나타내는 기타의 태그)를 찾기 위해 재생목록 파일을 검사하도록 구성되고, 만일 이러한 태그가 재생목록 파일에 없다면, 클라이언트 장치는 재생목록 파일이 에러를 갖는 것으로 표시할 수 있다.

재생목록 타입 표시자가 "Live"일 때, 클라이언트 장치는 업데이트된 재생목록 파일을 반복적으로 요청하도록 구성될 수 있다. 재생목록 타입 표시자가 "Event"일 때, 클라이언트 장치는 (a) 업데이트된 재생목록의 더 최근 부분만을 로딩(이로써 더 오래된 부분의 수신을 피함)하거나 (b) 업데이트된 재생목록의 더 최근 부분만을 파싱(이로써 업데이트된 재생목록의 더 오래된 부분의 재-파싱을 피함)하도록 구성될 수 있다.

한 실시예에서, 클라이언트 장치는 재생목록 파일에 명시된 미디어 파일들의 데이터 액세스나 미디어 파일을 수신할 때 발생하는 네트워크 에러에 관련된 통계를 저장하도록 구성될 수 있고, 이들 통계는 API(Application Program Interface)를 통해 클라이언트 애플리케이션에게 이용가능하게 되어, 네트워크 에러 또는 미디어 파일로의 액세스에 관한 정보(예를 들어, 디스플레이가 VOD 또는 라이브 쇼 등의 변종 스트림들 사이에서 얼마나 많이 전환되었는지)의 프리젠테이션을 허용한다.

일부 실시예들은, 호출 프로그램 코드가 하나 이상의 인터페이스를 통해 피호출중인 다른 프로그램 코드와 상호작용하는 환경에서 하나 이상의 애플리케이션 프로그래밍 인터페이스(API; application programming interface)를 포함한다. 다양한 함수 호출, 메시지 또는 다양한 타입의 파라미터를 더 포함할 수도 있는 기타 타입의 기동(invocation)이 호출 프로그램과 피호출 코드 사이의 API를 통해 전달될 수 있다. 또한, API는, API에서 정의되고 피호출 프로그램 코드에서 구현된 데이터 타입이나 클래스를 이용하는 능력을 호출 프로그램 코드에 제공할 수도 있다.

적어도 소정의 실시예들은, 호출 소프트웨어 컴포넌트가 API를 통해 피호출 소프트웨어 컴포넌트와 상호작용하는 환경을 포함한다. 이러한 환경에서 API를 통해 동작하기 위한 방법은, 하나 이상의 함수 호출, 메시지, API를 통한 기타 타입의 기동이나 파라미터를 전달하는 단계를 포함한다.

기타의 방법들이 여기서 설명되고 이들 방법들을 수행하기 위한 시스템들이 여기서 설명되며, 실행될 때 데이터 처리 시스템으로 하여금 이들 방법들 중 임의의 하나를 수행하게 할 수 있는 실행가능한 명령어를 저장하고 있는 머신-판독가능한 비일시적 저장 매체가 또한 여기서 설명된다.

본 발명은, 유사한 참조부호는 유사한 요소들을 가리키는 첨부된 도면들에서 제한이 아닌 예로서 설명된다.
도 1은 실시간 또는 준 실시간 콘텐츠(real-time, or near real-time, content)를 송수신할 수 있는 서버와 클라이언트의 한 실시예의 블록도이다.
도 2a는 하나 이상의 서버 장치가 비-스트리밍 프로토콜을 이용하여 미디어 콘텐츠를 지원하는 기술의 한 실시예의 흐름도이다.
도 2b는 하나 이상의 서버 장치가 하나 이상의 클라이언트 장치에 업데이트된 재생목록을 동적으로 제공하는 기술의 한 실시예의 흐름도이다.
도 2c는 하나 이상의 서버 장치가 복수의 비트 레이트를 이용하여 클라이언트 장치에 미디어 콘텐츠를 제공하는 기술의 한 실시예의 흐름도이다.
도 3a는 클라이언트 장치가 비-스트리밍 프로토콜을 이용한 콘텐츠의 스트리밍을 지원하는 기술의 한 실시예의 흐름도이다.
도 3b는 클라이언트 장치가 복수의 비트 레이트를 이용한 콘텐츠의 스트리밍을 지원하는 기술의 한 실시예의 흐름도이다.
도 4는 서버 스트림 에이전트(agent)의 한 실시예의 블록도이다.
도 5는 클라이언트 스트림 에이전트의 한 실시예의 블록도이다.
도 6은 복수의 태그를 갖는 재생목록 파일의 한 실시예를 나타낸다.
도 7은 여기서 설명되는 조립된 스트림들에 대한 재생 기술의 한 실시예의 흐름도이다.
도 8은 전자 시스템의 한 실시예의 블록도이다.
도 9a는 클라이언트 장치가 변종 재생목록 내의 대안적 콘텐츠들 사이에서 어떻게 전환할 수 있는지의 예를 나타내는 플로차트이다.
도 9b는 클라이언트 장치가 2개의 재생목록 내의 콘텐츠들 사이에서 어떻게 전환할 수 있는지를 나타내는 추가의 플로차트이다.
도 9c는 클라이언트 장치가 오디오 패턴 매칭을 이용하여 콘텐츠들 사이에서 어떻게 전환할 수 있는지의 예를 나타내는 추가의 플로차트이다.
도 9d는 도 9c의 방법이 오디오 패턴 매칭에 의해 어떻게 구현되는지를 도식적으로 나타낸다.
도 10은 대안적 스트림들을 이용하여 클라이언트 장치들에 미디어 콘텐츠를 제공하는 복수의 리던던트 위치를 제공하기 위한 기술의 한 실시예의 흐름도이다.
도 11은 한 실시예에 따라 클라이언트(1102)가 하나 이상의 URL들과 양방향으로 통신하는 네트워크를 나타낸다.
도 12a는 재생목록의 생성과 배포를 제어하기 위한 본 발명의 한 실시예에 따른 방법을 나타내는 플로차트이다.
도 12b는, 한 실시예에서, 예를 들어 도 12a에서와 같은 방법을 이용하여 재생목록이 어떻게 전송될 수 있는지 또는 그렇지 않으면 배포될 수 있는지의 타임라인을 도시한다.
도 13은 클라이언트 장치에서의 재생을 제어하기 위한 본 발명의 한 실시예에 따른 방법이다.
도 14a는, 한 실시예에서, 접속 속도 또는 접속 타입에 기초하여 최소 중첩량을 적응적으로 판정하기 위한 방법을 나타내는 흐름도를 도시한다. 도 14b, 도 14c, 및 도 14d는 스트림들간의 전환을 위해 중첩을 이용하는 실시예의 또 다른 양태를 도시한다.
도 15는 본 발명의 한 실시예에 따른 또 다른 방법을 나타내는 플로차트이다.
도 16a는 재생목록 파일을 생성하기 위해 타임스탬프 찍힌 태그(timestamped tag)를 이용하기 위한 한 실시예에 따른 방법을 나타내는 흐름도를 도시한다.
도 16b는 미디어 파일을 찾기 위해 재생목록 파일에서 타임스탬프 찍힌 태그를 이용하기 위한 한 실시예에 따른 방법을 나타내는 흐름도를 도시한다.
도 16c는 수신기에서 버퍼링된 스트리밍 콘텐츠로부터의 재생을 제어하기 위한 사용자 인터페이스의 실시예를 도시한다.
도 16d는 UI의 타임 라인 상의 표시자가 이동된 후에 도 16c의 실시예를 도시한다.
도 16e는 도 16c 및 도 16d에 도시된 사용자 인터페이스의 실시예를 이용하기 위한 방법을 도시하는 플로차트이다.
도 17은 미디어 서빙 데몬(media serving daemon)이 사용자 애플리케이션과 상호작용하는 것을 허용하는 소프트웨어 아키텍쳐의 예를 도시한다.
도 18은 본 발명의 일부 실시예에서 이용가능한 예시적 API 아키텍쳐의 블록도를 나타낸다.
도 19는 본 발명의 일부 실시예에서 이용가능한 소프트웨어 스택(software stack)의 예시적 실시예를 도시한다.
도 20은 한 실시예에 따라 재생목록 타입 표시자를 이용할 수 있는 방법의 예를 도시하는 플로차트이다.
도 21은 재생목록 타입 표시자를 이용할 수 있는 방법의 또 다른 예를 도시하는 플로차트이다.
도 22는 미디어 서버 애플리케이션으로부터 API를 통해 클라이언트 애플리케이션으로 통계가 제공될 수 있는 아키텍쳐의 예이다.

이하의 설명에서, 다양한 구체적인 세부사항이 개시된다. 그러나, 본 발명의 실시예들은 이들 구체적인 세부사항 없이도 실시될 수 있다. 다른 예들에서, 공지된 회로, 구조, 및 기술은 본 설명의 이해를 흐리게 하지 않기 위하여 상세히 도시되지 않았다.

본 설명에는, 그래픽 유저 인터페이스 이미지의 예시와 같은, 저작권에 의해 보호되는 자료가 포함된다. 본 발명의 양수인을 포함한, 저작권의 소유자는, 이들 자료들에서 저작권을 포함한 그들의 권리를 보유한다. 저작권 소유자는, 특허 문서나 특허 개시가 특허 및 상표청 파일이나 기록에 나타나는 경우라면, 그것의 타인에 의한 팩시밀리 복사에 이의가 없지만, 그렇지 않으면 모든 저작권을 보유한다. 저작권 Apple Inc. 2009-2010.

한 실시예에서, 여기서 설명되는 기술 및 컴포넌트들은 비-스트리밍 프로토콜(예를 들어, HTTP) 및 기타의 기술(예를 들어, MPEG(Motion Picture Expert Group) 스트림)을 이용하여 스트리밍 경험을 전달하는 메커니즘을 포함할 수 있다. 예를 들어, "라이브" 뮤지컬 또는 스포츠 이벤트, 라이브 뉴스, 웹 카메라 피드 등을 브로드캐스팅하기 위해 HTTP를 이용하여 준 실시간 스트리밍 경험이 제공될 수 있다. 한 실시예에서, 프로토콜은 인입 미디어 데이터를 복수의 미디어 파일들로 세그먼트화하고 이들 세그먼트화된 미디어 파일들을 서버에 저장할 수 있다. 프로토콜은 또한, 클라이언트를 서버에 저장된 세그먼트화된 미디어 파일들로 안내하는 URI(Uniform Resource Identifier)를 포함하는 재생목록 파일을 구축할 수 있다. 세그먼트화된 미디어 파일들이 재생목록 파일(들)에 따라 재생될 때, 클라이언트는 사용자에게 "라이브" 이벤트의 준 실시간 브로드캐스트를 제공할 수 있다. 사전-녹화된 콘텐츠가 유사한 방식으로 제공될 수 있다.

한 실시예에서, 서버는 보충적 또는 대안적 미디어 콘텐츠(예를 들어, 광고, 스포츠 이벤트에 관련된 통계, 메인 프리젠테이션에 대한 추가적 미디어 콘텐츠)를 브로드캐스트 이벤트 내에 동적으로 도입할 수 있다. 예를 들어, 미디어 이벤트의 클라이언트 재생 동안에, 서버는 추가 URI들을 재생목록 파일에 추가할 수 있고, 이 URI들은 클라이언트가 보충 미디어 파일을 다운로드할 수 있는 위치를 식별할 수 있다. 클라이언트는, 서버가 도입한 임의의 보충 또는 추가(또는 양쪽 모두) 미디어 콘텐츠에 액세스하기 위하여, 서버로부터 하나 이상의 업데이트된 재생목록 파일(들)을 주기적으로 검색하도록 지시받을 수 있다.

한 실시예에서, 서버는 누적 모드(cumulative mode) 또는 롤링 모드(rolling mode)로 동작할 수 있다. 누적 모드에서, 서버는 재생목록 파일을 생성하고 그 재생목록 파일의 끝에 미디어 파일 식별자들을 첨부할 수 있다. 그러면 클라이언트는 다운로드시에 단일의 재생목록 파일로부터 스트림의 모든 부분들에 액세스할 수 있다(예를 들어, 사용자는 쇼의 중간 부분에서 시작할 수 있다). 롤링 모드에서, 서버는 롤링 기반으로 재생목록 파일의 시작부로부터 미디어 파일 식별자들을 제거함으로써 미디어 파일들의 가용성을 제한할 수 있고, 이로써 클라이언트 장치에 액세스가능한 미디어 콘텐츠의 슬라이딩 윈도우를 제공한다. 서버는 또한 재생목록에 미디어 파일 식별자들을 추가할 수 있고, 롤링 모드에서, 서버는 미디어 파일들의 가용성을 재생목록에 가장 최근에 추가된 것들로 제한할 수 있다. 클라이언트는 시청을 계속하기 위해 재생목록 파일의 업데이트된 사본들을 반복적으로 다운로드한다. 재생목록 다운로딩에 대한 롤링 기반은, 콘텐츠가 잠재적으로 시간적으로 무제한일 때(예를 들어, 지속 동작하는 웹캠으로부터의 콘텐츠) 유용할 수 있다. 클라이언트는 재생목록에서 종료 태그를 발견할 때까지 롤링 모드에서 재생목록을 반복적으로 요청하는 것을 계속할 수 있다.

한 실시예에서, 이 메커니즘은 동일한 프리젠테이션의 변종 스트림들을 제공함으로써 비트 레이트 전환을 지원한다. 예를 들어, 수 개 버전의 서빙될 프리젠테이션이 서버에 저장될 수 있다. 각 버전은 실질적으로 동일한 콘텐츠를 갖지만 상이한 비트 레이트에서 인코딩될 수 있다. 이것은 클라이언트 장치가, 예를 들어, 재생의 연속성을 손상시키지 않고, 가용 대역폭의 검출에 따라 비트 레이트들 사이에서 전환하는 것을 허용할 수 있다.

한 실시예에서, 무허가 이용으로부터 콘텐츠를 보호하기 위해 보호 특징이 제공될 수 있다. 예를 들어, 예측을 방지하기 위해 비순차 미디어 파일 넘버링이 이용될 수 있다. 미디어 파일의 암호화가 이용될 수도 있다. 부분적 미디어 파일 목록이 이용될 수도 있다. 추가의 및/또는 상이한 보호 특징들도 역시 제공될 수 있다.

도 1은 실시간 또는 준 실시간 콘텐츠를 송수신할 수 있는 서버와 클라이언트의 한 실시예의 블록도이다. 도 1의 예는, 2개의 클라이언트가 네트워크를 통해 서버와 결합되어 있는 간단한 서버-클라이언트 접속을 제공한다. 여기서 설명되는 기술과 메커니즘을 이용하여 임의 개수의 클라이언트가 지원될 수 있다. 또한, 복수의 서버들이 콘텐츠를 제공할 수 있고 및/또는 여기서 설명되는 기술 및 메커니즘에 따라 콘텐츠를 제공하도록 함께 동작할 수 있다. 예를 들어, 하나의 서버는 콘텐츠를 생성하고, 재생목록을 생성하고 복수의 미디어(예를 들어, 파일)를 생성할 수 있으며, 다른 서버들은 생성된 콘텐츠를 저장 및 전송할 수 있다.

네트워크(110)는 유선, 무선(예를 들어, IEEE 802.11, 802.16)이든 이들의 임의의 조합이든 임의 타입의 네트워크일 수 있다. 예를 들어, 네트워크(100)는 인터넷 또는 인트라넷일 수 있다. 또 다른 예로서, 네트워크(110)는 셀룰러 네트워크(예를 들어, 3G, CDMA)일 수 있다. 한 실시예에서, 클라이언트 장치(150 및 180)는 복수의 네트워크 타입을 통해 통신할 수 있다(예를 들어, 각 장치는 WiFi 무선 LAN을 통해 및 무선 셀룰러 전화 네트워크를 통해 통신할 수 있다). 예를 들어, 클라이언트 장치(150 및 180)는, 데이터 네트워크 뿐만 아니라 셀룰러 무선 전화 네트워크를 통해 통신할 수 있는 스마트폰 또는 셀룰러 가능형 PDA(cellular-enabled personal digital assistants)일 수 있다. 이들 장치들은, 어느 한 타입의 네트워크를 통해 여기서 설명되는 스트리밍 메커니즘을 이용하거나, 필요하다면 심지어 네트워크들 사이에서 전환할 수 있다.

서버(120)는 본 기술에 공지된 임의의 방식으로 HTTP 서버로서 동작할 수 있다. 즉, 서버(120)는 HTTP 프로토콜을 이용하여 콘텐츠를 제공하는 HTTP 서버 에이전트(145)를 포함한다. 도 1의 예는 HTTP의 관점에서 기술되고 있지만, 다른 프로토콜들이 유사한 방식으로 이용될 수 있다. 세그먼트화기(130) 및 인덱스기(135)는 서버(120)(또는 복수의 서버)에 존재하는 에이전트로서, 여기서 설명되는 바와 같이 미디어 파일의 콘텐츠에 재생목록 파일을 제공한다. 이들 미디어 파일 및 재생목록 파일은 HTTP 프로토콜을 이용하여 HTTP 서버 에이전트(145)를 경유하여(또는 기타의 서버를 경유하여) 네트워크(110)를 통해 제공될 수 있다. 여기서 논의되는 에이전트는 하드웨어, 소프트웨어, 펌웨어 또는 이들의 조합으로서 구현될 수 있다.

세그먼트화기(130)는 미디어 데이터의 스트림을 HTTP 프로토콜을 통해 전송될 수 있는 복수의 미디어 파일로 분할하는 기능을 할 수 있다. 인덱스기(135)는 세그먼트화된 미디어 파일들에 대응하는 재생목록 파일을 생성하여 클라이언트 장치가 미디어 파일들을 재조립하여 서버(120)에 의해 제공되는 콘텐츠의 실시간, 또는 준 실시간 전송을 제공할 수 있게 하도록 기능할 수 있다. 클라이언트 장치로부터의 하나 이상의 요청에 응답하여, HTTP 서버 에이전트(145)(또는 기타의 서버들)는, 인덱스기(135)에 의해 생성된 하나 이상의 재생목록 파일과 세그먼트화기(130)에 의해 생성된 콘텐츠의 미디어 파일들을 전송할 수 있다. 서버(120)는 여기서 논의되는 보안 기능들 중 하나 이상(예를 들어, 암호화)을 제공하는 선택사항적 보안 에이전트(140)를 더 포함할 수 있다. 서버(120)는 도 1에 나타내지 않은 추가 컴포넌트를 역시 포함할 수 있다.

클라이언트 장치(150 및 180)는 네트워크(110)를 통해 서버(120)로부터 재생목록 파일 및 미디어 파일을 수신할 수 있다. 클라이언트 장치는 네트워크를 통해 전송된 데이터를 수신할 수 있고 네트워크를 통해 수신된 데이터를 이용하여 출력을 생성하는 임의 타입의 전자 장치, 예를 들어, 무선 모바일 장치, PDA, 오락 기기, 가전 제품 등일 수 있다. 출력은, 예를 들어, 오디오, 비디오 또는 이들의 임의의 조합을 포함한 미디어 타입들의 조합들 중 임의의 미디어 타입일 수 있다.

클라이언트 장치(150)는 어셈블러 에이전트(160) 및 출력 생성기 에이전트(165)를 포함할 수 있다. 마찬가지로, 클라이언트 장치(180)는 어셈블러 에이전트(190) 및 출력 생성기 에이전트(195)를 포함할 수 있다. 어셈블러 에이전트(160 및 180)는 서버(120)로부터 재생목록 파일들을 수신하고 재생목록 파일을 이용하여 서버(120)로부터의 미디어 파일들에 액세스하여 다운로드한다. 출력 생성기 에이전트(165 및 195)는 다운로드된 미디어 파일을 이용하여 각각 클라이언트 장치(150 및 160)로부터 출력을 생성한다. 출력은, 하나 이상의 스피커, 하나 이상의 디스플레이 스크린, 스피커 및 디스플레이 스크린의 조합 또는 기타 임의의 입력 또는 출력 장치에 의해 제공될 수 있다. 클라이언트 장치들은 또한, 미디어 파일들이 수신될 때 그 미디어 파일들(또는 압축된 미디어 파일이나 압축해제된 미디어 파일)을 저장하기 위한 버퍼로서 역할하는 메모리(예를 들어, 플래시 메모리 또는 DRAM 등)를 포함할 수 있고; 버퍼는, 새로운 콘텐츠가 다운로드되고 있는 동안 버퍼링된 콘텐츠가 나중에 디스플레이될 수 있도록, 콘텐츠가 현재 프리젠팅 중인 시간 이후의 수 초 가치(many seconds worth)의 프리젠팅가능한 콘텐츠를 제공할 수 있다. 이 버퍼는 간헐적으로 느린 네트워크 접속을 통해 클라이언트 장치가 콘텐츠의 검색을 시도하는 동안 프리젠팅가능한 콘텐츠를 제공할 수 있으므로, 버퍼는 네트워크 레이턴시나 접속 문제를 숨길 수 있다.

클라이언트 장치(150 및 180)는, 여기서 더 논의되는 보안 기능들 중 하나 이상을 제공하는 선택사항적인 보안 에이전트(170 및 185)를 각각 포함할 수 있다. 클라이언트 장치(150 및 180)는 도 1에 나타내지 않은 추가 컴포넌트를 역시 포함할 수 있다.

한 실시예에서, 본 출원에서 설명되는 기술들은 비-스트리밍 프로토콜(예를 들어, HTTP)을 통해 멀티미디어 데이터의 무제한 스트림을 전송하는데 이용될 수 있다. 실시예들은 또한, 미디어 데이터의 암호화 및/또는 대안적 버전의(예를 들어, 대안적 비트 레이트를 제공하는) 스트림의 제공을 포함할 수 있다. 미디어 데이터는 생성 후에 곧 전송될 수 있기 때문에, 데이터는 준 실시간으로 수신될 수 있다. 멀티미디어 데이터 스트림의 서버(전송기)와 클라이언트(수신기)에 의해 취해지는 동작 뿐만 아니라 파일들에 대한 예시적인 데이터 포맷이 제공되지만; 다른 포맷들도 역시 지원될 수 있다.

시뮬레이팅된 실시간 스트림(또는 준 실시간 스트림)으로서 전송될 수 있는 미디어 프리젠테이션은 재생목록 파일을 나타내는 URI(Universal Resource Indicator)에 의해 명시된다. 한 실시예에서, 재생목록 파일은 추가적 URI들의 순서화된 목록이다. 재생목록 파일 내의 각 URI는, 특정 프로그램에 대한 미디어 데이터의 단일의 연속 스트림일 수 있는, 스트림의 세그먼트에 해당하는 미디어 파일을 가리킨다.

미디어 데이터의 스트림을 재생하기 위하여, 클라이언트 장치는 서버로부터 재생목록 파일을 얻는다. 클라이언트는 또한 재생목록 파일에 의해 표시된 각각의 미디어 데이터 파일을 얻고 재생한다. 한 실시예에서, 클라이언트는 추가적인 및/또는 상이한 미디어 세그먼트들을 발견하기 위해 재생목록 파일을 동적으로 또는 반복적으로 리로드(reload)할 수 있다.

재생목록 파일은, 예를 들어, 확장된 M3U 재생목록 파일일 수 있다. 한 실시예에서, M3U 포맷을 효과적으로 확장시키는 추가 태그들이 이용된다. M3U는 MP3 URL(Moving Picture Experts Group Audio Layer 3 Uniform Resource Locator)을 지칭하며, 멀티미디어 재생목록을 저장하는데 이용되는 포맷이다. M3U 파일은 미디어 재생기가 재생하기 위한 하나 이상의 미디어 파일들의 위치를 포함하는 텍스트 파일이다.

재생목록 파일은, 한 실시예에서, 개개의 라인들로 구성된 확장된 M3U-포맷팅된 텍스트 파일이다. 라인들은, 단일 LF 캐릭터, 또는 LF 캐릭터가 뒤따라오는 CR 캐릭터에 의해 종료될 수 있다. 각 라인은 URI, 블랭크 라인일 수 있으며, 코멘트 캐릭터(예를 들어, '#')와 함께 시작할 수 있다. URI는 재생될 미디어 파일을 식별한다. 블랭크 라인은 무시될 수 있다.

코멘트 캐릭터와 함께 시작하는 라인은 코멘트이거나 태그일 수 있다. 태그는 #EXT로 시작하는 반면, 코멘트 라인은 #로 시작할 수 있다. 코멘트 라인은 통상 서버와 클라이언트에 의해 무시된다. 한 실시예에서, 재생목록 파일은 UTF-8 포맷으로 인코딩된다. UTF-8(8-bit Unicode Transformation Format)은 가변-길이 캐릭터 인코딩 포맷이다. 대안적 실시예에서, 다른 캐릭터 인코딩 포맷이 이용될 수 있다.

후속하는 예에서, 2개의 태그를 포함하는 확장된 M3U 포맷이 이용된다: EXTM3U 및 EXTINF. 확장된 M3U 파일은 "#EXTM3U"를 포함하는 첫 번째 라인에 의해 기본 M3U 파일과 구분될 수 있다.

EXTINF는 태그에 후속하는 URI에 의해 식별되는 미디어 파일을 기술하는 레코드 마커(record marker)이다. 한 실시예에서, 각 미디어 파일 URI 앞에는 EXTINF 태그가 선행되는데, 예를 들어:

#EXTINF: <duration>,<title>

여기서, "duration"은 미디어 파일의 지속기간을 나타내고, "title"은 타겟 미디어 파일의 타이틀이다.

한 실시예에서, 미디어 파일의 전송과 재생을 관리하기 위해 이하의 태그들이 이용될 수 있다:

EXT-X-TARGETDURATION

EXT-X-MEDIA-SEQUENCE

EXT-X-KEY

EXT-X-PROGRAM-DATE-TIME

EXT-X-ALLOW-CACHE

EXT-X-STREAM-INF

EXT-X-ENDLIST

EXT-X-DISCONTINUITY

EXT-X-VERSION

이들 태그들 각각은 이하에서 더 상세히 설명될 것이다. 각각의 새로운 태그에 관하여 특정의 포맷 및 속성들이 설명되지만, 대안적 실시예에서는 상이한 속성, 명칭, 포맷 등이 지원될 수 있다.

EXT-X-TARGETDURATION 태그는, 한 실시예에서, 프리젠테이션에 추가될 다음 미디어 파일의 근사적인 지속기간을 나타낼 수 있다. 이것은 재생 파일에 포함될 수 있고, 그 포맷은 다음과 같을 수 있다:

#EXT-X-TARGETDURATION :<seconds>

여기서, "seconds"는 미디어 파일의 지속기간을 나타낸다. 한 실시예에서, 실제 지속기간은 태그로 표시된 타겟 지속기간과는 약간 상이할 수 있다. 한 실시예에서, 세그먼트를 나타내는 모든 URI는 그 세그먼트의 근사적인 지속기간과 연관될 수 있는데; 예를 들어, 세그먼트에 대한 URI는 그 세그먼트의 근사적 지속기간을 나타내는 태그로 프레픽스(prefix)될 수 있다. 또 다른 실시예에서, EXT-X-TARGETDURATION 태그는 최대 미디어 파일 지속기간을 명시할 수 있는데; 재생목록 파일 내의 각 미디어 파일의 EXTINF 지속기간은 타겟 지속기간보다 작거나 같아야 하고, (최대 미디어 파일 지속기간을 명시하는) 이 태그는 재생목록 파일에서 단 한번만 명시될 수 있고 재생목록 파일 내의 모든 미디어 파일들에 적용되며, 그 포맷은 다음과 같을 수 있다:

#EXT-X-TARGETDURATION:<s>

여기서, "s"는 타겟 지속기간을 초단위로 나타내는 정수이다.

재생목록 파일 내의 각 미디어 파일 URI는 고유한 시퀀스 번호를 가질 수 있다. URI의 시퀀스 번호는, 존재하는 경우, 한 실시예에서는, 그에 선행한 URI의 시퀀스 번호 + 1과 같다. EXT-X-MEDIA-SEQUENCE 태그는 재생목록 파일에 나타나는 첫 번째 URI의 시퀀스 번호를 나타내며, 그 포맷은 다음과 같을 수 있다:

#EXT-X-MEDIA-SEQUENCE:<number>

여기서 "number"는 URI의 시퀀스 번호이다. 재생목록 파일이 #EXT-X-MEDIA-SEQUENCE 태그를 포함하지 않는다면, 재생목록 내의 첫 번째 URI의 시퀀스 번호는 1로서 간주될 수 있다. 미디어 파일의 시퀀스 번호는 한 실시예에서 그 URI에 나타나도록 요구되지 않고, 한 실시예에서, 재생목록은 단 하나의 EXT-X-MEDIA-SEQUENCE 태그를 포함할 수 있다. 한 실시예에서, 시퀀스 넘버링은 비-순차적일 수 있는데; 예를 들어, 1, 5, 7, 17 등과 같은 비-순차적 시퀀스 넘버링은 시퀀스에서 다음 번호의 예측을 어렵게 하며, 이것은 해적행위로부터 콘텐츠를 보호하는데 도움이 될 수 있다. 콘텐츠 보호에 도움이 되는 또 다른 옵션은 임의의 주어진 시간에서 재생목록의 일부만을 드러내는 것이다.

일부 미디어 파일은 암호화될 수도 있다. EXT-X-KEY 태그는, 그에 후속하는 미디어 파일을 암호해독하는데 이용될 수 있는 정보를 제공하며, 그 포맷은 다음과 같을 수 있다:

#EXT-X-KEY:METHOD=<method>[,URI="<URI>"][,IV=<IV>]

METHOD 파라미터는 암호화 방법을 명시하고, URI 파라미터는, 존재한다면, 키를 얻는 방법을 명시하며, IV(Initialization Vector)는, 존재한다면, (예를 들어, 키를 이용한) 암호화 방법에서 이용되는 초기화 벡터를 명시한다.

암호화 방법 NONE은 암호화가 없음을 나타내고, NONE이 표시된다면, 한 실시예에서, URI와 IV 파라미터는 존재하지 않아야 한다. 예를 들어, 128-비트 키와 PKCS7 패딩[RFC3852 참조]을 갖는 AES(Advance Encryption Standard) 암호화를 이용한 암호화를 나타내는 AES-128과 같은 다양한 암호화 방법이 이용될 수 있다. 새로운 EXT-X-KEY 태그는 임의의 종래의 EXT-X-KEY 태그를 대체한다.

URI 파라미터를 갖는 EXT-X-KEY 태그는 키 파일을 식별한다. 키 파일은 재생목록 파일에 열거된 후속하는 미디어 파일들을 암호해독하는데 이용되는 암호 키(cipher key)를 포함할 수 있다. 예를 들어, AES-128 암호화 방법은 16-옥테트 키들을 이용한다. 키 파일의 포맷은 2진 포맷의 16 옥테트들(octets)의 팩킹된 배열일 수 있다.

AES-128의 이용은 통상, 암호화 및 암호해독시에 동일한 16-옥테트 초기화 벡터(IV; initialization vector)가 공급될 것을 요구한다. IV를 변동시키는 것은 암호의 길이를 증가시키는데 이용될 수 있다. AES-128 암호화를 이용하는 경우, 미디어 파일의 시퀀스 번호는, 미디어 파일의 암호화 및 암호해독시에 IV로서 이용될 수 있다.

EXT-X-PROGRAM-DATE-TIME 태그는 다음 미디어 파일의 시작부를 절대 날짜 및/또는 시간과 연관시킬 수 있고 타임 존(time zone)을 포함하거나 표시할 수 있다. 한 실시예에서, 날짜/시간 표현은 ISO/IEC 8601:2004이다. 이 태그에서 날짜와 시간의 값은, 적절한 벽시간(wall-clock time)으로의 미디어의 타임라인의 유용한 맵핑을 제공할 수 있으며, 이것은, 디스플레이나 기타의 목적으로 날짜와 시간에 기초한 재생을 위해 콘텐츠를 탐색하기 위한 기초로서 이용될 수 있다. 한 실시예에서, 서버가 이 맵핑을 제공한다면, 이것은 재생목록 파일 내의 모든 EXT-X-DISCONTINUITY 태그 이후에 EXT-X-PROGRAM-DATE-TIME 태그를 두어야 한다. 태그 포맷은 다음과 같을 수 있다:

EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ>

EXT-X-ALLOW-CACHE 태그는 클라이언트가 나중의 재생을 위해 다운로딩된 미디어 파일을 캐싱할 수 있는지를 나타내는데 이용될 수 있다. 이 태그는 한 실시예에서 재생목록 파일 내에서 임의의 위치에 나타날 수 있지만, 한 실시예에서는 재생목록 파일에서 한 번만 나타나야 한다. 태그 포맷은 다음과 같을 수 있다:

EXT-X-ALLOW-CACHE:<YES|NO>

EXT-X-ENDLIST 태그는 한 실시예에서 재생목록 파일에 더 이상의 미디어 파일이 추가되지 않을 것임을 나타낸다. 태그 포맷은 다음과 같을 수 있다:

EXT-X-ENDLIST

한 실시예에서, 재생목록이 최종 세그먼트 또는 미디어 파일을 포함하면, 그 재생목록은 EXT-X-ENDLIST 태그를 가질 것이다. 이 태그는 한 실시예에서 재생목록 파일 내의 임의의 위치에 나타날 수 있고, 한 실시예에서, 재생목록 파일에서 한 번만 나타날 수 있다.

EXT-X-STREAM-INF 태그는, 재생목록 파일 내의 다음 URI가 또 다른 재생목록 파일을 식별한다는 것을 나타내는데 이용될 수 있다. 태그 포맷은, 한 실시예에서 다음과 같을 수 있다:

EXT-X-STREAM-INF: [attribute=value] [,attribute=value] *<URI>

여기서, 다음과 같은 속성들(attributes)이 이용될 수 있다. 이 태그의 한 실시예에서 동일한 타입의 속성은 동일한 태그에서 한 번보다 많이 나타나지 않아야 한다. 속성 BANDWIDTH=<n>은 초당 비트수로서 표현된 스트림 비트 레이트의 근사적 상한이다. 한 실시예에서, 속성 BANDWIDTH는, 재생목록에서 나타나거나 나타날 컨테이너 오버헤드를 포함하도록 계산된, 각 미디어 파일의 전체 비트레이트의 상한일 수 있다. 속성 PROGRAM-ID=<i>는 재생목록 파일의 범위 내에서의 특정한 프리젠테이션을 고유하게 식별하는 수이다. 재생목록 파일은 동일한 프리젠테이션의 변종 스트림을 기술하기 위해 동일한 PROGRAM-ID를 갖는 복수의 EXT-X-STREAM-INF URI를 포함하고, 이들 변종 재생목록들은 추가의 EXT-X-STREAM-INF 태그들을 포함할 수 있다. 변종 스트림들 및 변종 재생목록이 본 개시에서 추가로 설명된다(예를 들어, 도 9a 내지 도 9d를 참조). 속성 CODECS="[format][,format]*"은 재생목록 파일 내의 미디어 파일에 존재하는 미디어 샘플 타입을 명시하는데 이용될 수 있고, 여기서 각 포맷은 미디어 샘플 타입을 명시하는데; 한 실시예에서, 유효한 포맷 식별자는 RFC 4281에 의해 정의된 ISO File Format Name Space에 있는 것들일 수 있다. 속성 RESOLUTION = <N>x<M>은 스트림 내에의 비디오의 해상도를 명시할 수 있고, 여기서 N은 스트림 내의 비디오의 근사적인 인코딩된 수평 해상도로서, 화소수로서 표현될 수 있으며, M은 근사적인 인코딩된 수직 해상도이다.

EXT-X-DISCONTINUITY 태그는 후속하는 미디어 파일과 그 선행하는 미디어 파일 사이의 인코딩 불연속성을 나타낸다. 변할 수도 있는 특성 세트는:

o 파일 포맷

o 트랙의 개수 및 타입

o 인코딩 파라미터

o 인코딩 시퀀스

o 타임스탬프 시퀀스

그 포맷은:

#EXT-X-DISCONTINUITY

EXT-X-VERSION 태그는 재생목록 파일의 호환성 버전을 나타낸다. 재생목록 파일, 그 연관된 미디어, 및 그 서버는, 한 실시예에서, 태그 값에 의해 표시된 프로토콜 버전을 기술하는 본 문서의 가장 최신 버전의 모든 조항을 준수해야 한다.

그 포맷은:

#EXT-X-VERSION:<n>

여기서, "n"은 프로토콜 버전을 나타내는 정수이다.

재생목록 파일은, 한 실시예에서, 단 하나의 EXT-X-VERSION 태그를 포함할 수 있다. EXT-X-VERSION 태그를 포함하지 않는 재생목록 파일은, 한 실시예에서, 이 프로토콜의 버전 1을 준수해야 한다. 재생목록 파일이 이 태그를 가진다면, 그 값은, 한 실시예에서, 서버, 재생목록 파일 및 연관된 미디어 파일 모두가 준수해야 하는 가장 낮은 프로토콜 버전이어야 한다.

상기의 태그 및 속성들은 원래의 미디어 콘텐츠를 표현하는 미디어 파일들을 조직, 전송, 및 처리하기 위해 서버 장치에 의해 이용될 수 있다. 클라이언트 장치는, 클라이언트 장치의 사용자에게 실시간 또는 준 실시간 스트리밍 경험(예를 들어, 음악이나 스포츠 이벤트와 같은 라이브 브로드캐스트의 시청)을 제공하는 방식으로 미디어 파일들을 재조립 및 프리젠팅하기 위해 이 정보를 이용한다.

재생목록 파일 내의 각 미디어 파일 URI는 원래의 프리젠테이션(즉, 원래의 미디어 콘텐츠)의 세그먼트에 해당하는 미디어 파일을 식별한다. 한 실시예에서, 각 미디어 파일은 MPEG-2 트랜스포트 스트림, MPEG-2 프로그램 스트림, 또는 MPEG-2 오디오 엘리멘터리 스트림(elementary stream)으로서 포맷팅된다. 포맷은 CODEC을 명시함으로써 명시될 수 있고, 재생목록은 CODEC을 명시함으로써 포맷을 명시할 수 있다. 한 실시예에서, 프리젠테이션 내의 모든 미디어 파일들은 동일한 포맷을 갖지만; 다른 실시예들에서는 복수의 포맷들이 지원될 수 있다. 한 실시예에서, 트랜스포트 스트림 파일은 단일의 MPEG-2 프로그램을 포함해야 하고, 각 파일의 시작부에는 프로그램 연관 테이블(Program Association Table) 및 프로그램 맵 테이블(Program Map Table)이 있어야 한다. 비디오를 포함하는 파일은 적어도 하나의 키 프레임과 비디오 디코더를 완전히 초기화하기에 충분한 정보를 가져야 한다. 재생목록 내의 미디어 파일은, 재생목록 파일에 나타난 첫 번째 미디어 파일이거나 그 앞에 EXT-X-DISCONTINUITY 태그가 오지 않는 한, 반드시 이전 시퀀스 번호를 갖는 미디어 파일의 끝에서 인코딩된 스트림의 연속이어야 한다. 클라이언트들은 합리적인 서브셋을 선택함으로써 특정한 타입(예를 들어, 오디오 또는 비디오)의 복수의 트랙을 처리하도록 준비되어야 한다. 클라이언트들은, 한 실시예에서, 그들이 인식하지 않는 트랜스포트 스트림 내부의 사설 스트림을 무시해야 한다. 미디어 파일 내부의 스트림 내의 및 복수의 미디어 파일들에 걸친 대응하는 스트림들 사이의 샘플들에 대한 인코딩 파라미터들은 일관적으로 유지되어야 한다. 그러나, 클라이언트들은 그들이 만나는 인코딩 변경을, 예를 들어 해상도 변경을 수용하기 위해 비디오 콘텐츠를 스케일링함으로써, 처리해야 한다.

도 2a는 하나 이상의 서버 장치가 비-스트리밍 프로토콜을 이용하여 미디어 콘텐츠를 지원하는 기술의 한 실시예의 흐름도이다. 도 2a의 예는 HTTP의 관점에서 제공되지만; 다른 비-스트리밍 프로토콜들이 유사한 방식으로 이용될 수 있다. 도 2a의 예는 소정 태스크를 수행하는 단일 서버의 관점에서 제공된다. 그러나, 임의 개수의 서버가 이용될 수도 있다. 예를 들어, 클라이언트 장치들에 미디어 파일을 제공하는 서버는 콘텐츠를 복수의 미디어 파일들로 세그먼트화하는 서버와는 상이한 장치일 수 있다.

동작(200)에서 서버 장치는 제공될 콘텐츠를 수신한다. 콘텐츠는 라이브 오디오 및/또는 비디오(예를 들어, 스포츠 이벤트, 라이브 뉴스, 웹 카메라 피드)를 나타낼 수 있다. 콘텐츠는 또한 사전-녹화된 콘텐츠(예를 들어, 녹화된 콘서트, 교육 세미나 등)를 나타낼 수도 있다. 콘텐츠는, 스트리밍되든 아니든, 본 기술에 공지된 임의의 포맷 및 프로토콜에 따라 서버에 의해 수신될 수 있다. 한 실시예에서, 콘텐츠는 MPEG-2 스트림의 형태로 서버에 의해 수신되지만; 다른 포맷들도 역시 지원될 수 있다.

동작(210)에서 서버는 콘텐츠의 적어도 일부를 임시로 저장할 수 있다. 콘텐츠 또는 콘텐츠의 적어도 일부는, 예를 들어, 저장 장치(예를 들어, 저장 영역 네트워크(Storage Area Network) 내의 하드 디스크 등)에 또는 메모리에 임시로 저장될 수 있다. 대안으로서, 콘텐츠는, 그로부터 콘텐츠가 저장 장치나 메모리에 전송될 수 있는, 저장 매체(예를 들어, 컴팩트 디스크, 플래시 드라이브)를 통해 수신될 수도 있다. 한 실시예에서, 서버는, 필요하다면, 콘텐츠를 하나 이상의 스트림(예를 들어, MPEG-2)으로 변환하는 인코더를 가진다. 이 변환은 수신된 콘텐츠를 영구적으로 저장하지 않고 발생할 수 있으며, 일부 실시예에서는, 저장 동작(210)이 생략될 수 있고 또는 다른 실시예들에서는 더 긴 기간의 저장(예를 들어, 기록 보존적 저장)이 있을 수 있다.

동작(220)에서 제공될 콘텐츠는 복수의 미디어 파일들로 세그먼트화된다. 한 실시예에서, 서버는, 스트림을, 표준 웹 서버를 이용하여 배포될 수 있는 별개의 구분되는 미디어 파일들(즉, 세그먼트들)로 변환한다. 한 실시예에서, 서버는 개개의 미디어 파일들의 효과적인 디코드를 지원하는 포인트들(예를 들어, 패킷, 및 PES 패킷 경계 및 i-프레임 경계와 같은 키 프레임 경계 상)에서 미디어 스트림을 세그먼트화한다. 미디어 파일들은 근사적으로 동일한 지속기간을 갖는 원래의 스트림의 부분들일 수 있다. 서버는 또한 각 미디어 파일에 대한 URI를 생성한다. 이들 URI는 클라이언트 장치가 미디어 파일에 액세스하는 것을 허용한다.

세그먼트들은, 본질적으로 전체 파일을 전달하는, HTTP 서버들을 이용하여 서빙되기 때문에, 서버는, 클라이언트들에게 서빙될 수 있기 이전에 이용가능한 완전한 세그먼트화된 미디어 파일을 가져야 한다. 따라서, 클라이언트는 적어도 하나의 미디어 파일 길이만큼 브로드캐스트를 (시간적으로) 래깅(lag)할 수 있다. 한 실시예에서, 미디어 파일 크기는 래깅 시간과 너무 많은 파일들을 갖는 것 사이의 균형에 기초한다.

한 실시예에서, 2개의 세션 타입(라이브 세션 및 이벤트 세션)이 지원된다. 라이브 세션의 경우, 스트림의 고정 크기 부분만이 보존된다. 한 실시예에서, 기간이 지난 콘텐츠 미디어 파일들은 프로그램 재생목록 파일로부터 제거되고, 서버로부터 제거될 수 있다. 두 번째 타입의 세션은 이벤트 세션이며, 여기서, 클라이언트는 브로드캐스트의 임의 포인트 내로 튜닝(예를 들어, 시작부로부터 시작, 중간-포인트로부터 시작)될 수 있다. 이러한 타입의 세션은, 예를 들어, 재-브로드캐스트에 이용될 수 있다.

동작(230)에서 미디어 파일은 서버 메모리에 저장된다. 미디어 파일은, 동작(230)에서 파일들을 저장하기 전에, 암호화와 같은 보안 특징에 의해 보호될 수 있다. 미디어 파일은, 서버 장치 상의 웹 서버 애플리케이션에 의해 지원되는(또는 전송을 행하는 다른 장치에 의해 지원되는) 네트워크 프로토콜(예를 들어, HTTP 또는 HTTPS)을 이용하여 전송할 준비가 된 파일로서 저장된다.

동작(240)에서, 원래의 콘텐츠를 되살리도록 미디어 파일이 조립되어야 하는 순서를 나타내는 하나 이상의 재생파일 목록이 생성된다. 클라이언트 장치가 미디어 파일들에 액세스하고 미디어 파일들을 재조립하여 클라이언트 장치에 스트리밍 경험을 제공하기 위한 정보를 제공하기 위해, 재생목록 파일(들)은 확장된 M3U 태그들과 여기서 설명된 태그들을 이용할 수 있다. 각 미디어 파일에 대한 URI는 미디어 파일들이 재생되는 순서로 재생목록 파일(들)에 포함된다. 서버는 또한, 클라이언트 장치가 재생목록 파일(들)에 액세스하는 것을 허용하기 위해 재생목록 파일(들)에 대한 하나 이상의 URI를 생성할 수 있다.

동작(250)에서 재생목록 파일(들)은 서버에 저장될 수 있다. 미디어 파일 및 재생목록 파일(들)의 생성과 저장이 도 2b에서는 특정 순서로 제시되었지만, 상이한 순서도 역시 이용될 수 있다. 예를 들어, 재생목록 파일(들)은 미디어 파일들이 생성되거나 저장되기 이전에 생성될 수 있다. 또 다른 예로서, 재생목록 파일(들) 및 미디어 파일들은 어느 한 쪽이 저장되기 이전에 생성될 수도 있다.

미디어 파일을 암호화하려 한다면, 재생목록 파일(들)은, 허가된 클라이언트 장치가 암호화 키를 포함하는 키 파일을 얻어 미디어 파일을 암호해독하는 것을 허용하는 URI를 정의할 수 있다. 암호화 키는 보안 접속(예를 들어, HTTPS)을 이용하여 전송될 수 있다. 또 다른 예로서, 재생목록 파일(들)은 HTTPS를 이용하여 전송될 수 있다. 추가의 예로서, 미디어 파일들은 예측불가능한 순서로 배열되어, 클라이언트가 재생목록 파일(들)없이 스트림을 되살릴 수 없게 할 수 있다.

암호화 방법이 AES-128이면, 예를 들어, AES-128 CBC 암호화가 개개의 미디어 파일에 적용될 수 있다. 한 실시예에서, 전체 파일이 암호화된다. 한 실시예에서 암호 블록 체이닝(CBC; cipher block chaining)은 정상적으로는 미디어 파일들에 걸쳐 적용되지 않는다. 미디어 파일들의 시퀀스 번호는 IV로서 이용될 수 있거나 IV는 전술된 EXT-X-KEY 태그의 IV 속성의 값일 수 있다. 한 실시예에서, 서버는 키 URI를 갖는 EXT-X-KEY 태그를 재생목록 파일의 끝에 추가한다. 그 다음, 서버는 암호화 구성에서의 변경이 이루어질 때까지 모든 후속하는 미디어 파일들을 그 키로 암호화한다.

새로운 암호화 키로 전환하기 위해, 서버는 프리젠테이션에서 이용된 모든 이전의 키 URI들과는 구분되는 새로운 URI를 통해 새로운 키를 이용가능하게 할 수 있다. 서버는 또한, 새로운 키 URI를 갖는 EXT-X-KEY 태그를 재생목록 파일의 끝에 추가하고 모든 후속하는 미디어 파일들을 이 새로운 키로 암호화한다.

암호화를 종료하기 위해, 서버는 암호화 방법 NONE을 갖는 EXT-X-KEY 태그를 재생목록 파일의 끝에 추가할 수 있다. (방법으로서 "NONE"을 갖는) 태그는 한 실시예에서 URI 파라미터를 포함하지 않는다. 모든 후속하는 미디어 파일들은, 전술된 바와 같이, 암호화 구성에서의 변경이 이루어질 때까지 암호화되지 않는다. 서버는, 재생목록 파일이 그 키로 암호화된 미디어 파일에 대한 URI를 포함한다면 재생목록 파일로부터 EXT-X-KEY 태그를 제거하지 않는다. 서버는, 도 3a에 관하여 더 상세히 설명되는 바와 같이, 동작(270)에서 클라이언트 요청에 응답하여 네트워크를 통해 재생목록 파일(들)과 미디어 파일들을 전송할 수 있다.

한 실시예에서, 서버는 재생목록 파일에 대한 클라이언트 장치로부터의 요청의 수신에 응답하여 클라이언트 장치에 재생목록 파일을 전송한다. 클라이언트 장치는 클라이언트 장치에 제공된 URI를 이용하여 재생목록 파일에 액세스/요청할 수 있다. URI는 서버 상의 재생목록 파일의 위치를 나타낸다. 응답하여, 서버는 클라이언트 장치에 재생목록 파일을 제공할 수 있다. 클라이언트 장치는 복수의 미디어 파일에 액세스하기 위해 재생목록 파일 내의 태그 및 URI(또는 기타의 식별자)를 이용할 수 있다.

한 실시예에서, 서버는 미디어 파일들의 가용성을 재생목록 파일(들)에 가장 최근에 추가된 것들로 제한할 수 있다. 이를 행하기 위해, 각 재생목록 파일은 단 하나의 EXT-X-MEDIA-SEQUENCE 태그를 포함할 수 있고, 재생목록 파일로부터 제거되는 모든 미디어 파일 URI에 대해 1씩 그 값이 증가될 수 있다. 미디어 파일 URI들은 그들이 추가된 순서로 재생목록 파일(들)로부터 제거될 수 있다. 한 실시예에서, 서버가 재생목록 파일(들)로부터 미디어 파일 URI를 제거할 때, 미디어 파일은, 그 미디어 파일의 지속기간과 그 미디어 파일이 등장한 가장 긴 재생목록 파일의 지속기간의 합과 동일한 기간 동안에 클라이언트에 이용가능하게 남아 있다.

재생목록 파일의 지속기간은 그 재생목록 파일 내의 미디어 파일들의 지속기간의 합이다. 다른 지속기간도 역시 이용될 수 있다. 한 실시예에서, 서버는 EXT-X-ENDLIST 태그가 존재하지 않는 한, 적어도 3개의 메인 프리젠테이션 미디어 파일들을 재생목록에 항상 유지할 수 있다.

도 2b는 하나 이상의 서버 장치가 하나 이상의 클라이언트 장치에 업데이트된 재생목록을 동적으로 제공하는 기술의 한 실시예의 흐름도이다. 재생목록은 여기서 설명된 누적 모드 또는 롤링 모드 중 어느 하나를 이용하여 업데이트될 수 있다. 도 2b의 예는 HTTP의 관점에서 제공되고 있지만; 다른 비-스트리밍 프로토콜(예를 들어, HTTPS 등)들이 유사한 방식으로 이용될 수 있다. 도 2b의 예는 소정 태스크를 수행하는 서버의 관점에서 제공된다. 그러나, 임의 개수의 서버가 이용될 수도 있다. 예를 들어, 클라이언트 장치들에 미디어 파일을 제공하는 서버는 콘텐츠를 복수의 미디어 파일들로 세그먼트화하는 서버와는 상이한 장치일 수 있다.

동작(205)에서 서버 장치는 제공될 콘텐츠를 수신한다. 동작(215)에서 서버는 콘텐츠의 적어도 일부를 임시로 저장할 수 있다. 동작(215)은 도 2a의 동작(210)과 유사할 수 있다. 동작(225)에서, 제공될 콘텐츠는 복수의 미디어 파일들로 세그먼트화된다. 동작(235)에서 미디어 파일은 서버 메모리에 저장될 수 있다. 미디어 파일은, 동작(235)에서 파일들을 저장하기 전에, 암호화와 같은 보안 특징에 의해 보호될 수 있다.

동작(245)에서, 원래의 콘텐츠를 되살리도록 미디어 파일이 조립되어야 하는 순서를 나타내는 하나 이상의 재생파일 목록이 생성된다. 동작(255)에서 재생목록 파일(들)이 서버에 저장될 수 있다. 미디어 파일 및 재생목록 파일(들)의 생성과 저장이 도 2a에서는 특정 순서로 제시되었지만, 상이한 순서도 역시 이용될 수 있다.

서버(또는 또 다른 서버)는, 도 3a 및 도 3b에 관하여 더 상세히 설명되는 바와 같이, 동작(275)에서 클라이언트 요청에 응답하여 네트워크를 통해 재생목록 파일(들)과 미디어 파일들을 전송할 수 있다.

재생목록 파일(들)은 다양한 이유로 서버에 의해 업데이트될 수 있다. 동작(285)에서 서버는 클라이언트 장치에 제공될 추가 데이터를 수신할 수 있다. 동작(255)에서 재생목록 파일(들)이 저장된 후에 추가 데이터가 수신될 수 있다. 추가 데이터는, 예를 들어, 라이브 프리젠테이션의 추가 부분, 또는 기존 프리젠테이션에 대한 추가 정보일 수 있다. 추가 데이터는 광고 또는 통계(예를 들어, 스포츠 이벤트에 관련된 점수나 데이터)를 포함할 수 있다. 추가 데이터는 프리젠테이션 상에 (반투명으로) 오버레이되거나 사이드바 사용자 인터페이스에 프리젠팅될 수 있다. 추가 데이터는 원래 수신된 데이터와 동일한 방식으로 세그먼트화될 수 있다. 추가 데이터가 재생목록에 의해 나타낸 프로그램 내에 삽입될 광고나 기타의 콘텐츠를 구성한다면, 그 추가 데이터는 동작(215)에서 (적어도 임시로) 저장될 수 있고, 동작(225)에서 세그먼트화될 수 있고, 동작(235)에서 저장될 수 있는데; 세그먼트화된 추가 데이터의 저장 이전에, 추가 데이터의 세그먼트들은 암호화될 수 있다. 그 다음, 동작(245)에서, 프로그램과 추가 데이터를 포함하는 업데이트된 재생목록이 생성될 것이다. 재생목록은 추가 데이터에 기초하여 업데이트되고 동작(255)에서 다시 한번 저장된다. 재생목록 파일(들)에 대한 변경은 클라이언트 장치의 관점에서 미세하게(atomically) 이루어져야 한다. 업데이트된 재생목록은, 한 실시예에서, 이전의 재생목록을 대체한다. 이하에서 더 상세히 논의되는 바와 같이, 클라이언트 장치는 재생목록을 복수회 요청할 수 있다. 이들 요청은 클라이언트 장치가 가장 최근의 재생목록을 이용할 수 있게 한다. 한 실시예에서, 추가 데이터는 메타데이터일 수 있는데; 이 경우, 재생목록은 업데이트될 필요가 없지만, 세그먼트들은 메타데이터를 포함하도록 업데이트될 수 있다. 예를 들어, 메타데이터는 세그먼트들 내의 타임스탬프들과 매칭할 수 있는 타임스탬프들을 포함할 수 있고, 메타데이터는 매칭하는 타임스탬프를 갖는 세그먼트들에 추가될 수 있다.

업데이트된 재생목록은 또한 미디어 파일들의 제거를 야기할 수 있다. 한 실시예에서, 서버는, 재생목록에 URI들이 추가된 순서로 재생목록으로부터 미디어 파일들에 대한 URI들을 제거해야 한다. 한 실시예에서, 서버가 전체 프리젠테이션을 제거한다면, 그것은 재생목록 파일(들)을 클라이언트 장치에 이용불가능하게 한다. 한 실시예에서, 서버는 제거될 미디어 파일을 포함하는 가장 긴 재생목록 파일(들)의 지속기간 동안에 미디어 파일들 및 재생목록 파일(들)을 유지하여 현재의 클라이언트 장치가 프리젠테이션으로의 액세스를 완료하는 것을 허용한다. 따라서, 재생목록 파일 내의 모든 미디어 파일 URI는 EXT-X-STREAM-INF 태그로 프레픽스되어 재생목록 파일에 의해 표시된 미디어 파일들의 근사적 누적 지속기간을 나타낼 수 있다. 대안적 실시예에서, 미디어 파일들과 재생목록 파일(들)은 즉각 제거될 수 있다.

클라이언트 장치로부터의 재생목록에 대한 후속하는 요청은 동작(275)에서 서버가 업데이트된 재생목록을 제공하게 한다. 한 실시예에서, 재생목록은 정기적으로, 예를 들어, 타겟 지속기간에 관련된 기간에 업데이트된다. 재생목록 파일의 주기적 업데이트는 서버가 동적으로 변하는 프리젠테이션에 대한 서버로의 액세스를 제공하는 것을 허용한다.

도 2c는 하나 이상의 서버 장치가, 대안적 스트림의 이용의 한 형태인, 복수의 비트 레이트를 이용하여 클라이언트 장치에 미디어 콘텐츠를 제공하는 기술의 한 실시예의 흐름도이다. 도 2c의 예는 HTTP의 관점에서 제공되고 있지만; 다른 비-스트리밍 프로토콜들이 유사한 방식으로 이용될 수 있다. 도 2c의 예는 소정 태스크를 수행하는 서버의 관점에서 제공된다. 그러나, 임의 개수의 서버가 이용될 수도 있다. 예를 들어, 클라이언트 장치들에 미디어 파일을 제공하는 서버는 콘텐츠를 복수의 미디어 파일들로 세그먼트화하는 서버와는 상이한 장치일 수 있다.

한 실시예에서, 서버는 동일한 프리젠테이션의 상이한 인코딩을 제공하기 위해 단일의 재생목록 파일 내에 복수의 미디어 파일 목록을 갖는 단일의 재생목록 파일이나 복수의 재생목록 파일을 제공할 수 있다. 상이한 인코딩들이 제공된다면, 재생목록 파일(들)은 상이한 비트 레이트들을 제공하는 각각의 변종 스트림을 포함하여 클라이언트 장치들이 인코딩들간을 동적으로 전환하는 것을 허용할 수 있다(이것은 도 9a 내지 도 9d와 연계하여 추가로 설명된다). 변종 스트림들을 갖는 재생목록 파일들은 각각의 변종 스트림에 대한 EXT-X-STREAM-INF 태그를 포함할 수 있다. 동일한 프리젠테이션에 대한 각각의 EXT-X-STREAM-INF 태그는 동일한 PROGRAM-ID 속성 값을 가질 수 있다. 각각의 프리젠테이션에 대한 PROGRAM-ID 값은 변종 스트림들 내에서 고유하다.

한 실시예에서, 서버는 변종 스트림들을 생성할 때 다음과 같은 제약을 만족한다. 각각의 변종 스트림은 메인 프리젠테이션의 일부가 아닌 선택사항적 콘텐츠를 포함하는 동일한 콘텐츠로 구성될 수 있다. 서버는, 스트림들의 가장 작은 타겟 지속기간의 정확성 내에서, 모든 변종 스트림들에 대해 동일한 기간의 콘텐츠가 이용가능하게 할 수 있다. 변종 스트림들의 미디어 파일들은, 한 실시예에서, 모든 변종 스트림들 내의 대응하는 콘텐츠에 대해 매칭하는 샘플 타임스탬프를 갖는 MPEG-2 트랜스포트 스트림 또는 MPEG-2 프로그램 스트림이다. 또한, 모든 변종 스트림들은, 한 실시예에서, 동일한 오디오 인코딩을 포함해야 한다. 이것은 클라이언트 장치들이 콘텐츠를 잃지 않고 변종 스트림들 사이에서 전환하는 것을 허용한다.

도 2c를 참조하면, 동작(202)에서 서버 장치는 제공될 콘텐츠를 수신한다. 그러면, 동작(212)에서 서버는 콘텐츠를 적어도 임시로 저장할 수 있다. 동작(222)에서, 제공될 콘텐츠는 복수의 미디어 파일들로 세그먼트화된다. 동작(232)에서 각각의 미디어 파일이 선택된 비트 레이트(또는 다른 인코딩 파라미터들의 선택된 값)를 위해 인코딩되고 서버에 저장된다. 예를 들어, 미디어 파일은 고-, 중-, 및 저-대역폭 접속을 목표로 할 수 있다. 미디어 파일들은 저장 이전에 암호화될 수 있다. 타겟 대역폭 레벨에서의 스트리밍 경험을 제공하도록 다양한 타입의 접속을 목표로 하는 미디어 파일들의 인코딩이 선택될 수 있다.

한 실시예에서, 동작(242)에서 다양한 인코딩 레벨을 나타내는 여기서 설명된 태그들을 갖는 변종 재생목록이 생성된다. 태그들은, 대응하는 미디어 재생목록 파일에 대한 URI를 갖는 각각의 인코딩 레벨에 대해, 예를 들어, EXT-X-STREAM-INF 태그를 포함할 수 있다.

이 변종 재생목록은 다양한 인코딩 레벨을 위한 미디어 재생목록 파일들에 대한 URI를 포함할 수 있다. 따라서, 클라이언트 장치는 인코딩 레벨들을 나타내는 변종 재생목록에 제공된 대안들로부터 타겟 비트 레이트를 선택할 수 있고 대응하는 재생목록 파일을 검색할 수 있다. 한 실시예에서, (예를 들어, 도 9a 내지 도 9d에 관하여 설명된 바와 같이) 클라이언트 장치는 재생 동안에 비트 레이트들 사이에서 변경할 수 있다. 동작(252)에서 다양한 인코딩 레벨들을 나타내는 변종 재생목록이 서버에 저장된다. 동작(242)에서, 변종 재생목록에서 참조되는 재생목록들 각각이 또한 생성된 다음, 동작(252)에서 저장될 수 있다.

동작(272)에서, 클라이언트 장치로부터의 요청에 응답하여, 서버는 다양한 인코딩 레벨들을 나타내는 변종 재생목록을 전송할 수 있다. 동작(282)에서 서버는 선택된 비트레이트에 대응하는 변종 재생목록에 명시된 미디어 재생목록들 중 하나에 대한 요청을 수신할 수 있다. 동작(292)에서, 요청에 응답하여, 서버는 클라이언트 장치로부터의 요청에 대응하는 미디어 재생목록 파일을 전송한다. 그러면, 클라이언트 장치는 미디어 재생목록을 이용하여 서버에게 미디어 파일을 요청할 수 있다. 동작(297)에서 서버는 요청에 응답하여 클라이언트 장치에 미디어 파일들을 제공한다.

도 3a는 클라이언트 장치가 비-스트리밍 프로토콜을 이용한 콘텐츠의 스트리밍을 지원하는 기술의 한 실시예의 흐름도이다. 도 3a의 예는 HTTP의 관점에서 제공되지만; 다른 비-스트리밍 프로토콜들이 유사한 방식으로 이용될 수 있다. 도 3a 및 도 3b에 도시된 방법들은 하나의 클라이언트 장치에 의해 또는 수 개의 별개의 클라이언트 장치들에 의해 수행될 수 있다. 예를 들어, 이들 방법들 중 임의의 방법의 경우에, 단일의 클라이언트 장치가 동작들 모두를 수행하거나(예를 들어, 재생목록 파일을 요청, 재생목록 파일 내의 URI를 이용하여 미디어 파일을 요청, 미디어 파일들을 조립하여 프리젠테이션/출력을 생성 및 제공), 수 개의 별개의 클라이언트 장치들이 동작들 모두가 아닌 일부를 수행할 수 있다(예를 들어, 제1 클라이언트 장치는 재생목록 파일을 요청할 수 있고 재생목록 파일 내의 URI를 이용하여 미디어 파일을 요청할 수 있으며 미디어 파일을 처리하여 프리젠테이션/출력을 생성 및 제공할 수 있는 제2 클라이언트 장치에 의한 이용을 위해 이들 미디어 파일들을 저장할 수 있다).

동작(300)에서 클라이언트 장치는 서버에게 재생목록 파일을 요청할 수 있다. 한 실시예에서, 요청은 HTTP-호환 프로토콜에 따라 이루어진다. 요청은 서버에 저장된 초기 재생목록 파일에 대한 URI를 이용한다. 대안적 실시예에서, 다른 비-스트리밍 프로토콜이 지원될 수 있다. 요청에 응답하여, 서버는 대응하는 재생목록 파일을 네트워크를 통해 클라이언트에 전송할 것이다. 앞서 논의된 바와 같이, 네트워크는 유선 또는 무선일 수 있고, 유선 또는 무선 네트워크의 임의 조합일 수 있다. 또한, 네트워크는, 데이터 네트워크(예를 들어, IEEE 802.11, IEEE 802.16)이거나, 셀룰러 전화 네트워크(예를 들어, 3G)일 수 있다.

동작(310)에서 클라이언트 장치는 재생목록 파일을 수신할 수 있다. 동작(320)에서 재생목록 파일은 클라이언트 장치의 메모리에 저장될 수 있다. 메모리는, 예를 들어, 하드 디스크, 플래시 메모리, 랜덤 액세스 메모리일 수 있다. 한 실시예에서, 재생목록 파일이 재생목록 URI로부터 로딩 또는 리로딩될 때마다, 클라이언트는 그 재생목록 파일이 #EXTM3U 태그로 시작하는지를 판정하기 위해 검사하고 그 태그가 없다면 계속하지 않는다. 앞서 논의된 바와 같이, 재생목록 파일은 하나 이상의 태그뿐만 아니라 미디어 파일들에 대한 하나 이상의 URI를 포함한다.

동작(330)에서, 클라이언트 장치는, 재생목록 파일 내의 URI들로 표시된 미디어 파일들을 요청함으로써 원래의 콘텐츠를 재조립하기 위해 재생목록 파일을 이용하는 어셈블러 에이전트를 포함할 수 있다. 한 실시예에서, 어셈블러 에이전트는 표준 웹 브라우저 애플리케이션의 일부인 플러그-인 모듈이다. 또 다른 실시예에서, 어셈블러 에이전트는 재생목록 파일(들)을 이용하여 미디어 파일들을 수신하고 조립하기 위해 웹 브라우저와 상호작용하는 단독형 애플리케이션일 수 있다. 추가의 예로서, 어셈블러 에이전트는 클라이언트 장치에 임베딩되는 특별 목적 하드웨어 또는 펌웨어 컴포넌트일 수 있다.

어셈블러는 재생목록 파일로부터의 미디어 파일들이 URI들에 의해 표시된 서버로부터 다운로딩되게끔 한다. 재생목록 파일이 EXT-X-ENDLIST 태그를 포함한다면, 재생목록 파일에 의해 표시된 임의의 미디어 파일이 먼저 재생될 수 있다. EXT-X-ENDLIST 태그가 존재하지 않는다면, 마지막 및 마지막에서 두 번째 미디어 파일을 제외한 임의의 미디어 파일이 먼저 재생될 수 있다. 일단 재생할 첫 번째 미디어 파일이 선택되고 나면, 한 실시예에서, 재생목록 파일 내의 후속하는 미디어 파일들이, 그들이 재생목록 파일에서 등장하는 순서대로 로딩된다(그렇지 않은 경우, 콘텐츠는 순서가 어긋나 프리젠팅된다). 한 실시예에서, 클라이언트 장치는 미디어 파일들이 요구될 때 미리 미디어 파일들의 로딩을 시도(및 이들을 버퍼에 저장)하여 중단되지 않는 재생을 제공하여 네트워크 레이턴시 및 처리량에서 일시적인 변동을 보상한다.

동작(340)에서 다운로딩된 미디어 파일(들)이 클라이언트 장치의 메모리에 저장될 수 있다. 콘텐츠가 저장될 수 있는 메모리는 클라이언트 장치 상의 임의 타입의 메모리, 예를 들어, 랜덤 액세스 메모리, 하드 디스크, 또는 비디오 버퍼일 수 있다. 저장장치는 임시적으로 재생을 허용하거나 영구적일 수 있다. 재생목록 파일이 EXT-X-ALLOW-CACHE 태그를 포함하고 그 값이 NO이면, 클라이언트는 다운로드된 미디어 파일들이 재생된 후에 이들을 저장하지 않는다. 재생목록이 EXT-X-ALLOW-CACHE 태그를 포함하고 그 값이 YES이면, 클라이언트 장치는 나중의 다시보기를 위해 미디어 파일들을 무기한 저장할 수 있다. 클라이언트 장치는 프로그램 시작 시간(program origination time)을 사용자에게 디스플레이하기 위해 EXT-X-PROGRAM-DATE-TIME 태그의 값을 이용할 수 있다. 한 실시예에서, 클라이언트는, 더 나은 사용자 경험을 제공하기 위하여, 복수의 미디어 파일을 버퍼링하여 네트워크 지터(network jitter)에 덜 민감하게 할 수 있다.

한 실시예에서, 암호해독 방법이 AES-128이면, AES-128 CBC 암호해독이 개개의 미디어 파일에 적용된다. 전체 파일이 암호해독된다. 한 실시예에서, 미디어 파일들에 걸쳐 암호 블록 체이닝이 적용되지 않는다. 미디어 파일들의 시퀀스 번호가 전술된 바와 같이 초기화 벡터로서 이용될 수 있다.

동작(350)에서, 메모리로부터, 콘텐츠는 클라이언트 장치로부터 출력될 수 있다. 출력 또는 프리젠테이션은, 예를 들어, 내장된 스피커 또는 헤드폰을 통한 오디오 출력일 수 있다. 출력은 스크린을 통해 출력되거나 클라이언트 장치로부터 투사된 비디오를 포함할 수 있다. 본 기술에 공지된 임의의 타입의 출력이 이용될 수 있다. 동작(351)에서, 클라이언트 장치는, 저장된 현재의 재생목록 내에 재생되지 않았거나 그렇지 않으면 프리젠팅되지 않은 미디어 파일들이 더 있는지를 판정한다. 이러한 미디어 파일이 존재한다면(및 이들이 아직 요청되지 않았다면) 처리는 동작(330)으로 되돌아가고, 여기서 하나 이상의 미디어 파일들이 요청되고 프로세스는 반복된다. 이러한 미디어 파일이 없다면(즉, 현재의 재생목록 내의 모든 미디어 파일들이 재생되었다면), 처리는 동작(352)으로 진행하여, 재생목록 파일이 종료 태그를 포함하는지를 판정한다.

동작(352)에서 재생목록이 종료 태그(예를 들어, EXT-X-ENDLIST)를 포함한다면, 재생목록 파일에 의해 표시된 미디어 파일들이 재생완료되었을 때 재생은 멈춘다. 종료 태그가 재생목록 내에 있지 않다면, 클라이언트 장치는 서버로부터 다시 한번 재생목록을 요청하고 동작(300)으로 되돌아가서 프로그램에 대한 추가의 또는 업데이트된 재생목록을 얻는다.

도 2b를 참조하여 더 상세히 논의되는 바와 같이, 서버는 재생목록 파일을 업데이트하여 보충 콘텐츠(예를 들어, 라이브 브로드캐스트 내의 추가 미디어 콘텐츠에 대응하는 추가 미디어 파일 식별자) 또는 추가 콘텐츠(예를 들어, 그 스트림 이후의 추가 콘텐츠)를 도입할 수 있다. 보충 콘텐츠 또는 추가 콘텐츠에 액세스하기 위해, 클라이언트는 서버로부터 업데이트된 재생목록을 리로딩할 수 있다. 이것은, 재생목록 파일과 연관된 미디어 콘텐츠의 재생 동안에도, 재생목록 파일이 동적으로 업데이트될 수 있는 메커니즘을 제공할 수 있다. 클라이언트는 트리거의 개수에 기초하여 재생목록 파일의 리로딩을 요청할 수 있다. 종료 태그의 부족이 이러한 한 트리거이다.

한 실시예에서, 클라이언트 장치는 재생목록 파일이 EXT-X-ENDLIST 태그를 포함하지 않는 한, 재생목록 파일(들)을 주기적으로 리로딩한다. 클라이언트 장치가 재생목록 파일을 처음으로 로딩하거나 재생목록 파일을 리로딩하고 재생목록 파일이 마지막으로 로딩된 이후에 변경되었음을 발견하면, 클라이언트는 재생목록 파일을 다시 한 번 리로딩하려고 시도하기 이전에 소정 기간 동안 대기할 수 있다. 이 기간은 초기 최소 리로딩 지연(initial minimum reload delay)이라 불린다. 이것은 클라이언트가 재생목록 파일의 로딩을 시작한 시간으로부터 측정된다.

한 실시예에서, 초기 최소 리로딩 지연은 재생목록 파일 내의 마지막 미디어 파일의 지속기간 또는 타겟 지속기간의 3배 중 작은 쪽이다. 미디어 파일 지속기간은 EXTINF 태그에 의해 명시된다. 클라이언트가 재생목록 파일을 리로딩하고 이것이 변경되지 않았음을 발견하면, 클라이언트는 재시도 이전에 소정 기간 동안 대기할 수 있다. 한 실시예에서 최소 지연은 타겟 지속기간의 3배 또는 초기 최소 리로딩 지연의 배수 중 작은 쪽이다. 한 실시예에서, 이 배수는 첫 번째 시도의 경우 0.5이고, 두 번째 시도의 경우 1.5이며, 후속하는 시도들에 대해서는 3.0이지만; 다른 배수들도 이용될 수 있다.

재생목록 파일이 로딩되거나 리로딩될 때마다, 클라이언트 장치는 로딩할 다음 미디어 파일을 결정하기 위해 재생목록 파일을 검사한다. 로딩할 첫 파일은 전술된 바와 같이 먼저 재생하기 위해 선택되는 미디어 파일이다. 재생될 첫 미디어 파일이 로딩되었고 재생목록 파일이 EXT-X-MEDIA-SEQUENCE 태그를 포함하지 않는다면, 클라이언트는 현재의 재생목록 파일이 원래 발견된 오프셋에서 마지막 로딩된 미디어 파일의 URI를 포함한다고 확인할 수 있고, 파일이 발견되지 않으면 재생을 중지한다. 로딩할 다음 미디어 파일은 재생목록 파일 내의 마지막-로딩된 URI에 후속하는 첫 번째 미디어 파일 URI일 수 있다.

재생될 첫 번째 파일이 로딩되었고 재생목록 파일이 EXT-X-MEDIA-SEQUENCE 태그를 포함한다면, 로딩될 다음 미디어 파일은 로딩된 마지막 미디어 파일의 시퀀스 번호보다 큰 가장 낮은 시퀀스 번호를 갖는 것일 수 있다. 재생목록 파일이 키 파일 URI를 명시하는 EXT-X-KEY 태그를 포함한다면, 클라이언트 장치는 키 파일을 얻고 그 키 파일 내부의 키를 이용하여 또 다른 EXT-X-KEY 태그를 만날 때까지 그 EXT-X-KEY 태그에 후속하는 미디어 파일들을 암호해독한다.

한 실시예에서, 클라이언트 장치는 재생목록 파일을 다운로딩하기 위해 앞서 이용된 것과 동일한 URI를 이용한다. 따라서, 재생목록 파일에 변경이 이루어졌다면, 클라이언트 장치는 업데이트된 재생목록 파일을 이용하여 미디어 파일들을 검색하고 그 미디어 파일들에 기초하여 출력을 제공할 수 있다.

재생목록 파일에 대한 변경은, 예를 들어, 미디어 파일에 대한 URI의 삭제, 새로운 미디어 파일에 대한 URI의 추가, 대체 미디어 파일에 대한 URI의 대체를 포함할 수 있다. 재생목록 파일에 대해 변경이 이루어지면, 하나 이상의 태그는 업데이트되어 그 변경(들)을 반영할 수 있다. 예를 들어, 미디어 파일에 대한 변경이 재생목록 파일에 의해 표시된 미디어 파일의 재생의 지속기간에 대한 변경을 초래하면 지속기간 태그가 업데이트될 수 있다.

도 3b는 클라이언트 장치가 대안적 스트림의 한 형태인 복수의 비트 레이트를 이용한 콘텐츠의 스트리밍을 지원하는 기술의 한 실시예의 흐름도이다. 도 3b의 예는 HTTP의 관점에서 제공되지만; 다른 비-스트리밍 프로토콜들이 유사한 방식으로 이용될 수 있다.

동작(370)에서 클라이언트 장치는 재생목록 파일을 요청할 수 있다. 앞서 논의된 바와 같이, 재생목록 파일은 클라이언트 장치에 제공되는 URI를 이용하여 검색될 수 있다. 한 실시예에서, 재생목록 파일은 상이한 비트 레이트들에서 동일한 콘텐츠를 제공하기 위해 미디어 파일의 변종 스트림들의 목록을 포함하는데; 즉, 단일의 재생목록 파일은 변종 스트림들 각각의 미디어 파일들에 대한 URI를 포함한다. 도 3b에 도시된 예는 이 실시예를 이용한다. 또 다른 실시예에서, 변종 스트림들은 상이한 비트 레이트들에서 동일한 콘텐츠를 각각 제공하는 별개로 클라이언트에 제공되는 복수의 구분되는 재생목록 파일들에 의해 표현될 수 있고, 변종 재생목록은 구분되는 재생목록 파일들 각각에 대한 URI를 제공할 수 있다. 이것은 클라이언트 장치가 클라이언트 상태에 기초하여 비트 레이트를 선택하는 것을 허용한다.

동작(375)에서 재생목록 파일(들)은 클라이언트 장치에 의해 검색될 수 있다. 동작(380)에서 재생목록 파일(들)은 클라이언트 장치 메모리에 저장될 수 있다. 동작(385)에서 클라이언트 장치는 현재의 네트워크 접속 속도에 기초하여 이용될 비트 레이트를 선택할 수 있다. 동작(390)에서 선택된 비트 레이트에 대응하는 재생목록 파일에 포함된 URI를 이용하여 서버에게 미디어 파일들이 요청된다. 검색된 미디어 파일은 클라이언트 장치 메모리에 저장될 수 있다. 동작(394)에서 미디어 파일을 이용하는 클라이언트 장치에 의해 출력이 제공되고, 클라이언트 장치는 비트 레이트를 변경할지를 결정한다.

한 실시예에서, 클라이언트 장치는 처음에 가장 낮은 가용 비트 레이트를 선택한다. 미디어의 재생 동안에, 클라이언트 장치는 가용 대역폭이 재생을 위한 더 높은 비트 레이트의 이용을 지원할 수 있는지를 판정하기 위해 가용 대역폭(예를 들어, 현재의 네트워크 접속 비트 레이트)을 모니터링할 수 있다. 만일 그렇다면, 클라이언트 장치는 더 높은 비트 레이트를 선택하고 그 더 높은 비트 레이트의 미디어 재생목록 파일에 의해 표시된 미디어 파일들에 액세스할 수 있다. 그 역(reverse)도 역시 지원될 수 있다. 만일 재생이 너무 많은 대역폭을 소비한다면, 클라이언트 장치는 더 낮은 비트 레이트를 선택하고 그 더 낮은 비트 레이트의 미디어 재생목록 파일에 의해 표시된 미디어 파일들에 액세스할 수 있다.

동작(394)에서, 예를 들어, 가용 대역폭의 변경에 응답하여 또는 사용자 입력에 응답하여 클라이언트 장치가 비트 레이트를 변경하면, 동작(385)에서 클라이언트 장치는 상이한 비트 레이트를 선택할 수 있다. 한 실시예에서, 상이한 비트 레이트를 선택하기 위해 클라이언트 장치는 새로운 선택된 비트 레이트에 대응하는 재생목록 파일에 포함된 URI의 상이한 목록을 이용할 수 있다. 한 실시예에서, 클라이언트 장치는 재생목록 내의 미디어 파일들의 액세스 동안에 비트 레이트를 변경할 수도 있다.

동작(394)에서 비트 레이트가 변하지 않는다면, 클라이언트 장치는 현재의 재생목록에서 아직 검색되어 프리젠팅되지 않은 재생되지 않은 미디어 파일들이 더 있는지를 판정한다. 이러한 미디어 파일이 존재하면, 처리는 동작(390)으로 되돌아가서 재생목록 내의 이들 파일들에 대한 URI를 이용하여 하나 이상의 미디어 파일들이 검색된다. 이러한 미디어 파일이 없다면(즉, 현재의 재생목록 내의 모든 미디어 파일들이 재생되었다면), 처리는 동작(396)으로 진행하여, 재생목록이 종료 태그를 포함하는지가 판정된다. 만일 그렇다면, 프로그램의 재생이 종료하였고 프로세스가 완료하였고; 만일 그렇지 않다면, 처리는 동작(370)으로 되돌아가고, 클라이언트 장치는 프로그램에 대한 재생목록의 리로딩을 요청하고, 프로세스는 도 3b에 도시된 방법을 반복한다.

도 4는 서버 스트림 에이전트(agent)의 한 실시예의 블록도이다. 서버 스트림 에이전트(400)의 요소들은 수 개의 서버 장치에 걸쳐 분산될 수 있다는 것을 이해할 것이다. 예를 들어, 제1 서버 장치는 세그먼트화기(430), 인덱스기(440), 보안(450)을 포함할 수 있지만 파일 서버(460)를 포함하지 않고, 제2 서버 장치는 파일 서버(450)를 포함할 수 있지만, 세그먼트화기(430), 인덱스기(440) 및 보안(450)을 포함하지 않는다. 이 예에서, 제1 서버 장치는 재생목록과 미디어 파일을 준비하지만 이들을 클라이언트 장치에 전송하지는 않을 것인 반면, 하나 이상의 제2 서버 장치는 재생목록과 미디어 파일을 수신하여 선택사항으로서 저장하고, 재생목록과 미디어 파일을 클라이언트 장치에 전송할 것이다. 서버 스트림 에이전트(400)는, 서버 스트림 에이전트(400)의 동작을 지시하는 논리적 기능 제어를 구현하는 제어 로직(410)과, 서버 스트림 에이전트(400)의 동작을 지시하는 것과 연관된 하드웨어를 포함한다. 로직은 하드웨어 로직 회로 또는 소프트웨어 루틴 또는 펌웨어일 수 있다. 한 실시예에서, 서버 스트림 에이전트(400)는, 제어 로직(410)에 명령어를 제공하는 코드 시퀀스 및/또는 프로그램을 나타내는 하나 이상의 애플리케이션(412)을 포함한다.

서버 스트림 에이전트(400)는, 메모리 장치 또는 데이터나 명령어를 저장하기 위한 메모리 자원으로의 액세스를 나타내는, 메모리(414)를 포함한다. 메모리(414)는, 서버 스트림 에이전트(400)에 국한된 메모리, 또는 대안으로서, 서버 스트림 에이전트(400)가 존재하는 호스트 시스템의 메모리를 포함하는 메모리를 포함할 수 있다. 서버 스트림 에이전트(400)는 또한, 서버 스트림 에이전트(400) 외부의 (전자적 또는 인간) 엔티티에 관한 서버 스트림 에이전트(400)로의/로부터의 액세스 인터페이스(입력/출력 인터페이스)를 나타내는 하나 이상의 인터페이스(416)를 포함한다.

서버 스트림 에이전트(400)는 또한, 서버 스트림 에이전트(400)가 여기서 설명된 실시간 또는 준 실시간 스트리밍을 제공하는 것을 가능케 하는 하나 이상의 기능을 나타내는 서버 스트림 엔진(420)을 포함할 수 있다. 도 4의 예는 서버 스트림 엔진(420)에 포함될 수 있는 수 개의 컴포넌트들을 제공하지만; 상이하거나 추가적인 컴포넌트들도 역시 포함될 수 있다. 스트리밍 환경을 제공하는데 관여될 수 있는 예시적 컴포넌트들로는, 세그먼트화기(430), 인덱스기(440), 보안(450), 및 파일 서버(460)가 포함된다. 이들 컴포넌트들 각각은 다른 기능들을 제공하는 다른 컴포넌트들을 더 포함할 수 있다. 여기서 사용될 때, 컴포넌트란, 하드웨어, 소프트웨어, 펌웨어 또는 이들의 소정 조합으로 구현되는, 루틴, 서브시스템 등을 말한다.

세그먼트화기(430)는, 제공될 콘텐츠를, 웹 서버 프로토콜(예를 들어, HTTP)을 이용하여 파일로서 전송될 수 있는 미디어 파일들로 분할한다. 예를 들어, 세그먼트화기(430)는, 콘텐츠를, 미리결정된 파일 포맷의 미리결정된, 고정-크기의 데이터 블록들로 분할할 수 있다.

인덱스기(440)는 세그먼트화기(430)에 의해 생성된 미디어 파일들에 대한 주소 또는 URI를 제공하는 하나 이상의 재생목록 파일들을 제공할 수 있다. 인덱스기(440)는, 예를 들어, 세그먼트화기(430)에 의해 생성된 각 파일에 대응하는 식별자들에 대한 순서의 목록을 갖는 하나 이상의 파일들을 생성할 수 있다. 식별자들은 세그먼트화기(430) 또는 인덱스기(440)에 의해 생성되거나 할당될 수 있다. 인덱스기(440)는 또한, 미디어 파일들의 액세스 및/또는 이용을 지원하기 위해 재생목록 파일에 하나 이상의 태그를 포함할 수 있다.

보안(450)은 앞서 논의된 것들과 같은 보안 특징(예를 들어, 암호화)을 제공할 수 있다. 웹 서버(460)는 호스트 시스템에 저장된 파일들을 원격 클라이언트 장치에 제공하는 것과 관련된 웹 서버 기능을 제공할 수 있다. 웹 서버(460)는, 예를 들어, HTTP-호환 프로토콜을 지원할 수 있다.

도 5는 클라이언트 스트림 에이전트의 한 실시예의 블록도이다. 클라이언트 스트림 에이전트의 요소들은 수 개의 클라이언트 장치에 걸쳐 분산될 수 있다는 것을 이해할 것이다. 예를 들어, 제1 클라이언트 장치는 어셈블러(530) 및 보안(550)을 포함할 수 있고, 출력 생성기(540)를 포함하는(그러나, 어셈블러(530) 및 보안(550)을 포함하지 않는) 제2 클라이언트 장치에 미디어 파일들의 암호화된 스트림을 제공할 수 있다. 또 다른 예에서, 1차 클라이언트 장치는 재생목록을 검색하여 이들을 제2 클라이언트 장치에 제공할 수 있고, 제2 클라이언트 장치는 재생목록에 명시된 미디어 파일들을 검색하여 이들 미디어 파일들을 프리젠팅하는 출력을 생성한다. 클라이언트 스트림 에이전트(500)는, 클라이언트 스트림 에이전트(500)의 동작을 지시하는 논리적 기능 제어를 구현하는 제어 로직(510)과, 클라이언트 스트림 에이전트(500)의 동작을 지시하는 것과 연관된 하드웨어를 포함한다. 로직은 하드웨어 로직 회로 또는 소프트웨어 루틴 또는 펌웨어일 수 있다. 한 실시예에서, 클라이언트 스트림 에이전트(500)는, 제어 로직(510)에 명령어를 제공하는 코드 시퀀스 또는 프로그램을 나타내는 하나 이상의 애플리케이션(512)을 포함한다.

클라이언트 스트림 에이전트(500)는, 메모리 장치 또는 데이터 및/또는 명령어를 저장하기 위한 메모리 자원으로의 액세스를 나타내는, 메모리(514)를 포함한다. 메모리(514)는, 클라이언트 스트림 에이전트(500)에 국한된 메모리, 또는 대안으로서, 클라이언트 스트림 에이전트(500)가 존재하는 호스트 시스템의 메모리를 포함하는 메모리를 포함할 수 있다. 클라이언트 스트림 에이전트(500)는 또한, 클라이언트 스트림 에이전트(500) 외부의 (전자적 또는 인간) 엔티티에 관한 클라이언트 스트림 에이전트(500)로의/로부터의 액세스 인터페이스(입력/출력 인터페이스)를 나타내는 하나 이상의 인터페이스(516)를 포함한다.

클라이언트 스트림 에이전트(500)는 또한, 클라이언트 스트림 에이전트(500)가 여기서 설명된 실시간 또는 준 실시간 스트리밍을 제공하는 것을 가능케 하는 하나 이상의 기능을 나타내는 클라이언트 스트림 엔진(520)을 포함할 수 있다. 도 5의 예는 클라이언트 스트림 엔진(520)에 포함될 수 있는 수 개의 컴포넌트들을 제공하지만; 상이하거나 추가적인 컴포넌트들도 역시 포함될 수 있다. 스트리밍 환경을 제공하는데 관여될 수 있는 예시적 컴포넌트들로는, 어셈블러(530), 출력 생성기(540), 및 보안(550)이 포함된다. 이들 컴포넌트들 각각은 다른 기능들을 제공하는 다른 컴포넌트들을 더 포함할 수 있다. 여기서 사용될 때, 컴포넌트란, 하드웨어, 소프트웨어, 펌웨어 또는 이들의 소정 조합으로 구현되는, 루틴, 서브시스템 등을 말한다.

어셈블러(530)는 웹 서버 프로토콜(예를 들어, HTTP)를 통해 서버로부터의 미디어 파일들에 액세스하기 위해 서버로부터 수신된 재생목록 파일을 이용할 수 있다. 한 실시예에서, 어셈블러(530)는 재생목록 파일 내의 URI들에 의해 표시된 미디어 파일들이 다운로드되게 할 수 있다. 어셈블러(530)는 재생목록 파일에 포함된 태그에 응답할 수 있다.

출력 생성기(540)는, 수신된 미디어 파일들을, 호스트 시스템 상의 오디오 또는 비주얼 출력(또는 오디오 및 비주얼 양쪽 모두)으로서 제공할 수 있다. 출력 생성기(540)는, 예를 들어, 하나 이상의 스피커에 오디오가 출력되게 하고 디스플레이 장치에 비디오가 출력되게 할 수 있다. 보안(550)은 앞서 논의된 것들과 같은 보안 기능을 제공할 수 있다.

도 6은 복수의 태그를 갖는 재생목록 파일의 한 실시예를 나타낸다. 도 6의 예시적 재생목록은 특정 개수와 순서의 태그를 포함한다. 이것은 단지 설명을 목적을 위해 제공되는 것이다. 일부 재생목록 파일은 더 많거나, 더 적거나, 또는 상이한 조합의 태그들을 포함할 수 있고, 태그들은 도 6에 도시된 순서와는 상이한 순서로 배열될 수 있다.

시작 태그(610)는 재생목록 파일의 시작을 나타낼 수 있다. 한 실시예에서, 시작 태그(610)는 #EXTM3U 태그이다. 지속기간 태그(620)는 재생 목록의 지속기간을 나타낼 수 있다. 그것은, 재생 목록(600)으로 표시된 미디어 파일의 재생의 지속기간이다. 한 실시예에서, 지속기간 태그(620)는 EXT-X-TARGETDURATION 태그이지만; 다른 태그들도 역시 이용될 수 있다.

날짜/시간 태그(625)는 재생 목록(600)에 의해 표시된 미디어 파일들에 의해 제공되는 콘텐츠의 날짜와 시간에 관련된 정보를 제공할 수 있다. 한 실시예에서, 날짜/시간 태그(625)는 EXT-X-PROGRAM-DATE-TIME 태그이지만; 다른 태그들도 역시 이용될 수 있다. 시퀀스 태그(630)는 재생목록 파일(600)의 시퀀스를 재생목록의 시퀀스로 표시할 수 있다. 한 실시예에서, 시퀀스 태그(630)는 EXT-X-MEDIA-SEQUENCE 태그이지만; 다른 태그들도 역시 이용될 수 있다.

보안 태그(640)는 재생목록 파일(600)에 의해 표시된 미디어 파일들에 적용되는 보안 및/또는 암호화에 관련된 정보를 제공할 수 있다. 예를 들어, 보안 태그(640)는 미디어 파일 표시자에 의해 명시된 파일들을 암호해독하기 위한 암호해독 키를 명시할 수 있다. 한 실시예에서, 보안 태그(640)는 EXT-X-KEY 태그이지만; 다른 태그들도 역시 이용될 수 있다. 변종 목록 태그(645)는 변종 스트림이 재생목록(600)에 의해 제공되는지 뿐만 아니라 변종 스트림들에 관련된 정보(예를 들어, 얼마나 많은지, 비트 레이트)를 나타낼 수 있다. 한 실시예에서, 변종 목록 태그(645)는 EXT-X-STREAM-INF 태그이다.

미디어 파일 표시자(650)는 재생될 미디어 파일들에 관련된 정보를 제공할 수 있다. 한 실시예에서, 미디어 파일 표시자(650)는 재생될 복수의 미디어 파일들에 대한 URI를 포함한다. 한 실시예에서, 재생목록(600) 내의 URI들의 순서는 미디어 파일들이 액세스 및/또는 재생되어야 하는 순서에 대응한다. 후속하는 재생목록 표시자(660)는 재생 파일(600) 이후에 이용될 하나 이상의 재생 파일들에 관련된 정보를 제공할 수 있다. 한 실시예에서, 후속하는 재생목록 표시자(660)는 재생목록(600)의 미디어 파일이 재생된 후에 이용될 하나 이상의 재생목록 파일들에 대한 URI를 포함할 수 있다.

메모리 태그(670)는 미디어 파일 콘텐츠의 재생 이후에 클라이언트 장치가 미디어 파일을 저장할지의 여부 및/또는 얼마나 오래동안 저장할지를 나타낼 수 있다. 한 실시예에서, 메모리 태그(670)는 EXT-X-ALLOW-CACHE 태그이다. 종료 태그(680)는 재생목록 파일(600)이 프리젠테이션을 위한 마지막 재생목록 파일인지를 나타낸다. 한 실시예에서, 종료 태그(680)는 EXT-X-ENDLIST 태그이다.

이하의 섹션은 한 실시예에 따른 수 개의 예시적인 재생목록 파일을 포함한다.

단순한 재생목록 파일(Simple Playlist file)

HTTPS를 사용하는, 슬라이딩 윈도우 재생목록(Sliding Window Playlist, using HTTPS)

암호화된 미디어 파일을 갖는 재생목록 파일(Playlist file with encrypted media files)

변종 재생목록 파일(Variant Playlist file)

도 7은 여기서 설명되는 조립된 스트림들에 대한 재생 기술의 한 실시예의 흐름도이다. 한 실시예에서, 수신된 미디어 파일들의 재생은 시작, 정지, 되감기 등을 위해 사용자에 의해 제어될 수 있다. 재생목록 파일은 동작(700)에서 클라이언트 장치에 의해 수신된다. 동작(710)에서 재생목록 파일에 의해 표시된 미디어 파일들이 검색된다. 동작(720)에서 수신된 미디어 파일에 기초하여 출력이 생성된다. 미디어 파일을 수신하고 이에 기초하여 출력을 생성하는 것은 앞서 설명된 바와 같이 달성될 수 있다.

동작(730)에서 제어 입력이 검출되면, 동작(740)에서 클라이언트 장치는 입력이 중단을 나타내는지를 판정할 수 있다. 입력이 중단이면, 프로세스는 종결되고 재생은 중단된다. 동작(750)에서 입력이 되감기 또는 전진 요청이면, 동작(760)에서 클라이언트 장치는 메모리에 여전히 저장되어 있는 앞서 재생된 미디어 파일들에 기초하여 출력을 생성할 수 있다. 이들 파일들이 더 이상 캐쉬 내에 있지 않다면, 처리는 동작(710)으로 되돌아가서 미디어 파일들을 검색하고 프로세스를 반복한다. 대안적 실시예에서, 재생은, 중단 입력에서와 같이 재생을 종결하지 않고 재생을 일시적으로 멈추는 잠시멈춤 특징을 지원할 수 있다.

한 스트림으로부터 또 다른 스트림으로 천이하기 위한 방법이 도 9a 내지 도 9d를 참조하여 더 설명된다. 한 클라이언트 장치가 이들 방법들 각각을 수행할 수 있고 또는 이들 방법들 각각의 동작들이 여기서 설명된 바와 같이 복수의 클라이언트 장치에 걸쳐 분산될 수 있는데; 예를 들어, 분산된 경우, 하나의 클라이언트 장치는 변종 재생목록과 2개의 미디어 재생목록을 검색할 수 있고, 이들을 또 다른 클라이언트 장치에 제공하며, 또 다른 클라이언트 장치는 2개의 미디어 재생목록에 의해 명시된 미디어 파일들을 검색하여 검색된 미디어 파일들에 의해 제공되는 2개의 스트림들 사이에서 전환할 수 있다. 대안적 실시예에서, 도시된 동작의 순서가 수정되거나 이들 도면에 도시된 것보다 많거나 적은 수의 동작들이 존재할 수 있다는 것을 역시 이해할 것이다. 방법들은 상이한 스트림들을 선택하기 위해 변종 재생목록을 이용할 수 있다. 동작(901)에서 프로그램(예를 들어, 스포츠 이벤트)에 대한 가용 스트림을 판정하기 위해 변종 재생목록이 검색되고 처리될 수 있다. 동작(901)은 클라이언트 장치에 의해 이루어질 수 있다. 동작(903)에서 변종 재생목록으로부터 제1 스트림이 선택될 수 있고, 클라이언트 장치는 제1 스트림에 대한 미디어 재생목록을 검색할 수 있다. 동작(905)에서 클라이언트 장치는 제1 스트림에 대한 미디어 재생목록을 처리할 수 있고, 또한 동작(907)에서 제1 스트림에 대한 네트워크 접속의 비트 레이트를 측정하거나 그렇지 않으면 결정한다. 동작들의 시퀀스는 도 9a에 도시된 것과는 상이한 순서로 수행될 수 있다는 것을 이해할 것이고; 예를 들어, 동작(907)은 동작(903) 동안 등에 수행될 수도 있다. 동작(911)에서, 클라이언트 장치는 동작(907)으로부터 측정된 비트 레이트에 기초하여 변종 재생목록으로부터 대안적 미디어 재생목록을 선택하며; 이 대안적 미디어 재생목록은 제1 스트림의 기존 비트 레이트보다 높은 제2 비트 레이트일 수 있다. 이것은 통상 대안적 스트림은 제1 스트림보다 높은 해상도를 가질 것임을 의미한다. 대안적 미디어 재생목록은, 현재 상태(예를 들어, 동작(907)에서 측정된 비트 레이트)에 기초하여 제1 스트림에 대해 현재의 재생목록보다 나은 매칭일 경우 선택될 수 있다. 동작(913)에서, 대안적 스트림에 대한 대안적 미디어 재생목록이 검색되고 처리된다. 이것은 통상 클라이언트 장치는 제1 스트림 및 대안적 스트림 양쪽 모두를 수신 및 처리 중이어서 양쪽 모두가 프리젠테이션에 이용가능하다는 것을 의미하며; 하나가 프리젠팅되는 동안 다른 하나는 프리젠팅될 준비가 되어 있다. 그러면 동작(915)에서 클라이언트 장치는 스트림 버전들 사이에서 전환할 천이 포인트를 선택하고, 제1 스트림의 프리젠팅을 중단하고 대안적 스트림의 프리젠팅을 개시한다. 이러한 전환이 어떻게 달성되는지의 예가 도 9b 내지 도 9d와 연계하여 제공된다. 일부 실시예들에서, 클라이언트 장치는 전환을 행하기 이전에 제1 스트림의 수신을 중단할 수 있다.

도 9b는, 동작(921 및 923)에서 클라이언트 장치가 제1 미디어 재생목록에 의해 명시된 콘텐츠(예를 들어, 제1 스트림)을 검색, 저장 및 프리젠팅하고, 제1 재생목록에 의해 명시된 콘텐츠가 프리젠팅되는 동안 동작(925)에서 클라이언트 장치도 역시 제2 미디어 재생목록에 의해 명시된 콘텐츠(예를 들어, 제2 스트림)를 검색 및 저장한다는 것을 도시한다. 제1 미디어 재생목록으로부터 얻어진 콘텐츠를 프리젠팅하는 동안 제2 미디어 재생목록에 의해 명시된 콘텐츠의 검색 및 (예를 들어, 임시 버퍼에의) 저장은, 클라이언트 장치가 프로그램의 실질적인 중단없이 프로그램의 버전들 사이에서 전환하는 것을 허용하는 (도 9d에 도시된) 프로그램 콘텐츠의 시간에서의 중첩(955)을 생성한다. 이런 방식으로, 프로그램의 버전들간의 전환은 많은 경우에 있어서 전환이 발생했다는 사용자 통보없이(그러나, 사용자는 일부 경우에는 전환 이후의 더 높은 해상도의 화상을 주목할 수 있다) 또는 프로그램의 프리젠테이션의 실질적인 중단없이 달성될 수 있다. 동작(927)에서, 클라이언트 장치는 제1 미디어 재생목록에 의해 명시된 콘텐츠로부터 제2 미디어 재생목록에 의해 명시된 콘텐츠로 전환하는 천이 포인트를 결정하며; 천이 포인트의 예(천이 포인트(959))가 도 9d에 도시되어 있다. 그 다음 전환 후에 동작(931)에서 제2 미디어 재생목록에 명시된 콘텐츠가 프리젠팅된다.

도 9c 및 도 9d에 도시된 방법은 천이 포인트를 결정하기 위한 한 실시예를 나타내는데; 이 실시예는 천이 포인트를 결정하기 위해 2개 스트림(951 및 953)으로부터의 오디오 샘플들에 관한 패턴 매칭에 의존한다. 대안적 실시예는 천이 포인트를 결정하기 위해 비디오 샘플들에 관한 패턴 매칭을 이용하거나 2개 스트림들에서의 타임스탬프들을 이용할 수 있다는 것 등을 이해할 것이다. 이 방법은, 동작(941)에서, 제1 미디어 재생목록에 의해 명시된 콘텐츠(예를 들어, 스트림(951))를 버퍼에 저장하는 단계를 포함할 수 있으며; 버퍼는 콘텐츠의 프리젠테이션을 위해 및 패턴 매칭 동작을 위해서도 이용될 수 있다. 스트림(951)은 오디오 샘플(951A) 및 비디오 샘플(951B) 양쪽 모두를 포함한다. 비디오 샘플은, 단일 비디오 프레임을 디스플레이하는데 필요한 모든 콘텐츠를 갖는 i-프레임 또는 키 프레임에 의존하는 압축 기술을 이용할 수 있다. 스트림(951)의 콘텐츠는 시간을 명시하는 타임스탬프(예를 들어, 프로그램의 시작부 이후의 경과 시간)를 포함할 수 있고, 이들 타임스탬프들은 샘플들 각각의 시작부(예를 들어, 오디오 샘플(951A) 각각의 시작부 및 비디오 샘플(951B) 각각의 시작부)를 마킹할 수 있다. 일부 경우에, 2개 스트림들간의 타임스탬프들의 비교는 천이 포인트의 결정에 있어서 유용하지 못할 수도 있는데, 이것은 이들이 충분히 정확하지 않거나 2개 스트림들에서 샘플들의 경계에서의 차이 때문이지만; 2개 스트림들간에 시간에서의 중첩(955)이 있는지를 확인하기 위해 타임스탬프 범위의 비교가 이용될 수 있다. 동작(943)에서, 클라이언트 장치는 제2 미디어 재생목록에 의해 명시된 콘텐츠를 버퍼에 저장하며; 이 콘텐츠는 제1 미디어 재생목록으로부터 얻어진 콘텐츠와 동일한 프로그램에 대한 것이며 타임스탬프도 포함할 수 있다. 한 실시예에서, 타임스탬프는, 스트림에 존재하지 않는 경우, 스트림에 대한 재생목록에 추가될 수 있는데; 예를 들어, 한 실시예에서, 하나 이상의 타임스탬프를 포함하는 ID3 태그가, 변종 재생목록 또는 미디어 재생목록과 같은 재생목록 내의 엔트리에 추가될 수 있다. 이 엔트리는, 예를 들어, 오디오 스트림의 첫 번째 샘플에 대한 URI에 있을 수 있다. 도 9d는 제2 미디어 재생목록으로부터 얻어진 콘텐츠(953)의 예를 도시하며, 이것은 오디오 샘플(953A) 및 비디오 샘플(953B)을 포함한다. 동작(945)에서, 클라이언트 장치는 2개의 스트림(951 및 953) 내의 오디오 샘플들에 관해 패턴 매칭을 수행하여 중첩(955)으로부터, 한 실시예에서는, 매칭된 오디오 세그먼트들(예를 들어, 세그먼트(957)) 이후의 다음 자립형 비디오 프레임(예를 들어, i-프레임(961))일 수 있는, 천이 포인트(959)를 선택할 수 있다. i-프레임(961)(및 그 연관된 오디오 샘플)에서 시작하여, 프로그램의 프리젠테이션은 제2 미디어 재생목록으로부터 얻어진 제2 스트림을 이용한다. 전술된 방법은, 한 실시예에서, 더 느린 비트 레이트로부터 더 빠른 비트 레이트로의 변경, 및 더 빠른 비트 레이트로부터 더 느린 비트 레이트로의 변경 양쪽 모두에 이용될 수 있지만, 또 다른 실시예에서, 이 방법은 더 느린 비트 레이트로부터 더 빠른 비트 레이트로의 변경에만 이용될 수 있고, (예를 들어, 천이 포인트의 위치를 파악하는 것이 아니라 가능한 한 일찍 더 느린 비트 레이트 스트림으로부터의 콘텐츠를 저장하고 프리젠팅하는 것을 시도하는) 또 다른 방법은 더 빠른 비트 레이트로부터 더 느린 비트 레이트로의 변경에 이용될 수 있다.

도 10은 대안적 스트림들을 이용하여 클라이언트 장치들에 재생목록 또는 미디어 콘텐츠 또는 양쪽 모두를 제공하는 복수의 리던던트 위치를 제공하기 위한 기술의 한 실시예의 흐름도이다. 재생목록이 앞서 논의된 바와 같은 대안적 스트림들을 포함한다면, 대안적 스트림들은 대역폭 또는 장치 대안으로서 동작할 수 있을 뿐만 아니라, 고장 폴백(failure fallback)으로서도 동작할 수 있다. 예를 들어, 클라이언트가 (예를 들어, 404 에러 또는 네트워크 접속 에러로 인해) 스트림에 대한 재생목록 파일을 리로딩할 수 없다면, 클라이언트는 대안적 스트림으로의 전환을 시도할 수 있다. 도 10을 참조하면, 장애극복 보호책(failover protection)을 구현하기 위해, 제1 서버 장치 또는 제1 콘텐츠 배포 서비스는, 도 2c의 설명과 연계하여 논의된 바와 같이 동작(1002)에서 스트림 또는 복수의 대안적 대역폭 스트림들을 생성하도록 구성된다. 동작(1004)에서, 제1 서버 장치 또는 제1 콘텐츠 배포 서비스는 동작(1002)에서 생성된 스트림(들)으로부터 재생목록 파일(들)을 생성한다. 동작(1006)에서, 제2 서버 장치 또는 제2 콘텐츠 배포 서비스는 병렬 스트림, 또는 스트림 세트를 생성할 수 있으며, 재생목록도 생성할 수 있다. 이들 병렬 스트림(들)은 백업 스트림으로서 간주될 수 있다. 그 다음, 동작(1008)에서 백업 스트림들의 목록이 재생목록 파일(들)에 추가되어 1차 스트림 이후에 각 대역폭에서의 백업 스트림(들)이 열거된다. 예를 들어, 1차 스트림이 서버 ALPHA로부터 나오고 백업 스트림은 서버 BETA 상에 있다면, 재생목록 파일은 다음과 같을 수 있다:

백업 스트림들은 재생목록 내의 1차 스트림들과 혼합되고, 각 대역폭에서의 백업은 그 대역폭에 대한 1차 스트림 이후에 열거된다는 점에 유의한다. 클라이언트는 단일 백업 스트림 세트로 제한되지 않는다. 상기 예에서, ALPHA와 BETA 뒤에는 예를 들어 GAMMA가 올 수 있다. 마찬가지로, 완전한 병렬 세트의 스트림을 제공하는 것이 필요하지 않다. 예를 들어, 백업 서버 상에서 단일의 저-대역폭 스트림이 제공될 수 있다.

동작(1010)에서, 클라이언트는 제1 서버 장치 또는 제1 콘텐츠 배포 서비스와 연관된 제1 스트림을 이용하여 제1 URL로부터 재생목록 파일(들)의 다운로드를 시도한다. 도 11은 한 실시예에 따라 클라이언트(1102)가 하나 이상의 URL들, 서버 장치들 또는 콘텐츠 배포 서비스들과 양방향으로 통신하는 네트워크를 나타낸다. 동작(1012)에서 제1 URL, 서버 장치 또는 콘텐츠 배포 서비스로부터 클라이언트(1102)로 재생목록 파일(들)이 전송될 수 있다. 클라이언트가 (예를 들어, 스트림에 대한 인덱스 파일의 리로딩 에러로 인해) 제1 URL, 서버 장치 또는 콘텐츠 배포 서비스로부터 재생목록 파일(들)을 다운로드할 수 없다면, 클라이언트는 대안적 스트림으로의 전환을 시도한다. (예를 들어, 동작(1010)) 하나의 스트림 상에서의 실패의 경우(예를 들어, 인덱스 로딩 실패), 동작(1014)에서 클라이언트는 네트워크 접속이 지원하는 가장 높은 대역폭의 대안적 스트림을 선택한다. 동일한 대역폭의 복수의 대안적 스트림들이 존재한다면, 클라이언트는 재생목록에 열거된 순서에 따라 이들 중에서 선택한다. 예를 들어, 클라이언트(1102)가 URL 1로부터 성공적으로 다운로드할 수 없다면, URL 2 또는 또 다른 URL로부터 다운로드할 수 있고, 이 경우 재생목록 파일(들)은 대안적 URL로부터 클라이언트로 전송된다. 이 특징은, 서버 크래싱(sever crashing) 또는 콘텐츠 배포자 노드 중단(going down)과 같은 심각한 국지적 고장의 경우에도 미디어가 클라이언트에 도달하는 것을 허용하는 리던던트 스트림들을 제공한다.

장애극복 보호책은 클라이언트가 재생목록과 미디어 파일을 검색할 수 있는 복수의 리던던트 위치를 제공하는 능력을 제공한다. 따라서, 클라이언트가 제1 위치로부터 스트림을 검색할 수 없다면, 제2, 제3 등의 위치로부터 스트림으로의 액세스를 시도할 수 있다.

한 실시예에서, 클라이언트가 재생목록을 검색할 수 있는 추가 위치를 표시하기 위해, 동일한 변종 재생목록 태그에는, 동일한 대역폭이지만 리던던트 위치의 새로운 URI가 제공될 것이다. 클라이언트는 처음에, 원하는 대역폭과 연관된 첫 번째 URL로의 액세스를 시도할 수 있다. 클라이언트가 첫 번째 URL로부터 재생목록을 다운로드할 수 없다면, 모든 가능성을 소진할 때까지, 그 대역폭에 제시된 다음 URL로의 액세스 등을 시도할 수 있다.

이하의 예는 2560000 대역폭에 대한 1개 리던던트 위치와 7680000 대역폭에 대한 2개 리던던트 위치를 포함한다.

이 예에서는 파일명(예를 들어, mid-redundant2.m3u8)과 실제의 URL(예를 들어,

,

) 양쪽 모두가 변한다는 점에 유의한다. 그러나, 한 실시예에서, 리던던트 위치는 오직 파일명에 대한 변경이거나 오직 웹사이트에 대한 변경일 수 있다.

한 실시예에서, 재생목록은 서버 장치에 의해 압축되어 압축된 형태로 클라이언트 장치에 전송될 수 있다. 압축된 재생목록은 통상 재생목록을 표현하기 위해 압축되지 않은 재생목록보다 더 적은 수의 비트를 요구하므로, 압축된 재생목록은, 전송이나 수신시에, 무선 셀룰러 전화 네트워크와 같은, 네트워크의 가용 대역폭을 더 적게 이용한다. 한 실시예에서, 재생목록은, HTTP 1.1 표준 프로토콜과 같은 전송 프로토콜에 부합하거나 호환가능한 웹 서버에 의해 이용되는 내장된 압축 기술이나 설비에 따라 웹 서버에 의해 압축될 수 있으며; 이러한 압축 기술 또는 설비의 예는 HTTP 1.1의 deflate 또는 gzip 압축 설비이다. 다른 실시예들에서는 표준 기반의 전송 프로토콜의 일부에 해당하는 다른 표준 기반의 압축 설비들이 이용될 수 있다. 압축된 재생목록의 이용은, 한 실시예에서는, 서버 장치들과 클라이언트 장치들의 선택사항적 특징일 수 있다. 한 실시예에서, 재생목록은 텍스트 콘텐츠(예를 들어, 텍스트 파일)일 수 있고 표준 기반의 웹 서버에 의해 deflate 또는 gzip으로 효율적으로 압축된 다음 클라이언트 장치에 의해 자동으로 압축해제될 수 있다. gzip 압축 설비의 한 버전의 설명은 www.ietf.org/rfc/rfc1952.txt에서 찾아볼 수 있으며; deflate 압축 설비의 한 버전은 www.ietf.org/rfc/rfc1951.txt에서 찾아 볼 수 있다. 많은 웹 서버들과 클라이언트 장치 상의 많은 웹 브라우저들이 deflate 또는 gzip 설비들을 자동으로 지원할 수 있다.

한 실시예에서, 클라이언트 장치는 업데이트된 재생목록을 주기적으로 요청할 수 있는데; 예를 들어, 클라이언트 장치는 서버에게 업데이트된 재생목록을 수 초마다(예를 들어, 10, 20, 또는 30초마다, 또는 어떤 다른 기간마다) 요청할 수 있다. 클라이언트가 라이브 게임 동안의 임의의 시간에서 라이브 게임의 시작부로부터 시청을 개시하는 것을 허용하는 라이브 진행 야구 게임에 대한 재생목록과 같은 커져가는 재생목록(growing playlist)은, 그 커져가는 재생목록이 네트워크를 통해 반복적으로 전송되기 때문에, 압축의 이용이 네트워크의 대역폭의 소비를 제한할 수 있을 정도로 충분히 커질 수 있다.

한 실시예에서, 클라이언트 장치는, (업데이트된 재생목록과 같은) 재생목록을 요청할 때, 선택사항으로서 (deflate 또는 gzip과 같은) 어떤 압축 기술을 지원할 수 있는지를 명시할 수 있는데; 이러한 기술들에 대한 지원은 클라이언트 장치가 압축되거나 인코딩된 콘텐츠를 압축해제 또는 디코딩할 수 있다는 것을 의미한다. 압축 기술의 선택사항적 명시와 함께 재생목록에 대한 클라이언트 장치의 요청은, 한 실시예에서, 재생목록에 대해 압축 기술을 지원할 것을 요구받지 않고 압축되지 않은 재생목록을 전송할 수 있는 웹 서버에 의해 수신된다. 웹 서버는, 클라이언트 장치의 재생목록 요청에 명시된 압축 기술들 중 하나를 이용한 압축된 재생목록이나 압축되지 않은 재생목록을 클라이언트 장치에 전송함으로써, 클라이언트 장치의 요청에 응답할 수 있다. 클라이언트 장치는 재생목록을 수신하고 여기서 설명된 바와 같이 그것을 이용하며; 재생목록이 압축되어 있다면, 이것은 클라이언트 장치의 웹 브라우저 내의 디코더와 같은 클라이언트 장치 상의 디코더를 이용하여 디코딩된다.

도 12a 및 도 12b는 추가의 미디어 파일들이 추가될 때(예를 들어, 전송중인 현재의 재생목록이 EXT-X-ENDLIST 태그를 포함하지 않을 때) 이어지는 재생목록의 전송을 위한 서버 타이밍 모델의 한 실시예를 도시한다. 현재의 재생목록이 프리젠테이션의 마지막 미디어 파일을 포함하지 않는다면, 데이터 처리 시스템 또는 서버는 적어도 하나의 새로운 미디어 파일 URI를 포함하는 재생목록의 새로운 버전을 만들 수 있다. 도 12a 및 도 12b는, 새로운 미디어 파일 URI를 갖는 새로운 재생목록이 재생목록의 이전 버전과 연속된 방식으로 클라이언트 장치로의 전송에 이용가능할 것을 보장하기 위한 서버 타이밍 모델의 한 실시예를 도시한다. 이 모델은, 예를 들어, 재생목록에 명시된 미디어 파일들이 지속기간에서 짧게 되는 것이(예를 들어, 단 몇 초 길이) 허용될 때 이용될 수 있다. 한 실시예에서, 각 미디어 파일에 대한 최대 미디어 파일 지속기간을 설정함으로써 및 최대 미디어 파일 지속기간에 기초하여 재생목록 지속기간의 최소량을 설정함으로써, 서버 또는 기타의 데이터 처리 시스템은, 각 미디어 파일이 단 몇 초의 지속기간이더라도 클라이언트 장치로의 콘텐츠의 연속적 배포나 전송을 보장할 수 있다.

이제 도 12a를 참조하면, 동작(1201)은, 동작(1200)에서 결정된, 다음 재생목록 파일에 endlist 태그가 존재하지 않는다면 재생목록 내의 각 미디어 파일의 최대 미디어 파일 지속기간으로서 타겟 지속기간을 설정하는데 이용될 수 있다. 동작(1201)은 데이터의 스트림을 복수의 미디어 파일들로 분할하고 이들 복수의 미디어 파일들을 개개의 파일로서 저장하는 데이터 처리 시스템에 의해 수행될 수 있다. 스트림을 분할하는 프로세스는, 재생목록 파일에 명시된 각 미디어 파일이 타겟 지속기간보다 작을 것(또는 타겟 지속기간 ± 작은 기간보다 작을 것)을 보장하기 위해 타겟 지속기간(예를 들어, 현재의 재생목록 파일의 타겟 지속기간)을 이용할 수 있다. 재생목록을 생성하는 데이터 처리 시스템은 또한, 재생목록 파일의 지속기간이 동작(1203)에 도시된 바와 같이 타겟 지속기간의 적어도 배수가 될 수 있도록 보장할 수 있다. 한 실시예에서, 배수는 재생목록 지속기간의 최소치로서 이용되는 3 타겟 지속기간(또는 기타 배수의 타겟 지속기간)일 수 있으며, 재생목록의 지속기간은 재생목록 내에 명시된 미디어 파일들의 누적 지속기간에 의해 정의된다. 재생목록을 생성하는 시스템(예를 들어, 서버)는, 각 재생목록이 최소의 지속기간을 만족하기 위해 적어도 충분한 개수의 미디어 파일들을 명시하는 것을 보장함으로써 재생목록의 최소 지속기간을 준수할 수 있는데; 예를 들어, 최소 지속기간이 3 타겟 지속기간이면, 각 재생목록은 적어도 3 타겟 지속기간을 포함해야 한다.

동작(1205)은 또한, 일관적이고 연속된 스트림이 미디어 파일을 전송하고 있는 서버와 같은 데이터 처리 시스템으로부터 이용가능하게 되는 것을 보장하기 위한 추가의 메커니즘으로서 이용될 수 있다. 이 추가 메커니즘은, 재생목록에 대한 변경이 있는지를 판정하기 위한 클라이언트 장치에 의한 폴링(polling) 또는 풀링(pulling)의 양을 줄일 수 있다. 동작(1205)에서, 서버는, 서버가 다음 재생목록 파일을 전송하기 위한 가장 이른 시간 및 가장 늦은 시간이 있도록 셋업될 수 있다. 가장 이른 시간 및 가장 늦은 시간은, (새로운 재생목록 파일 직전의) 이전의 재생목록 파일이 이용가능하게 되었던 시간에 기초하거나 그 시간에 관련된 시간 윈도우로서 이용될 수 있다. 가장 이른 시간은, 예를 들어, 직전의 재생목록이 서버로부터의 전송에 처음으로 이용가능하게 되었던(그러나, 반드시 전송되었을 필요는 없음) 시간에 기초할 수 있다. 가장 늦은 시간도 역시, 예를 들어, 직전의 재생목록이 서버로부터의 전송에 처음으로 이용가능하게 되었던(그러나, 반드시 전송되었을 필요는 없음) 시간에 기초할 수 있다. 예를 들어, 한 실시예에서 가장 이른 시간은, 이전의 재생목록 파일이 전송에 처음으로 이용가능하게 되었을 때로부터 타겟 지속기간(예를 들어, 동작(1201)에서 설정된 타겟 지속기간)의 제1 미리결정된 퍼센트(예를 들어, 1/2)보다 이르지 않은 시간으로서 명시될 수 있고, 가장 늦은 시간은 직전의 재생목록 파일이 서버로부터의 전송에 처음으로 이용가능하게 되었을 때로부터 타겟 지속기간의 제2 미리결정된 퍼센트(예를 들어, 1배 반)보다 늦지 않게 설정될 수 있다. 재생목록 파일이 전송에 처음으로 이용가능하게 되었던 시간은, 한 실시예에서, 재생목록 파일의 생성 시간(이 시간은 서버 상의 파일 시스템에 의해 기록된다)이 될 수 있다. 이 예가 타임라인(1211)을 포함하는 도 12b에 도시되어 있다. 타겟 지속기간(1213)은, 이전 재생목록 파일이 전송에 처음으로 이용가능하게 되었던 시간인 시간(1209)에서 하나 이상의 서버에 의해 처음으로 이용가능하게 되었던 직전 재생목록의 지속기간을 나타내는 재생목록 지속기간(1215)의 일부이다. 그 재생목록에 명시된 미디어 파일들은 거의 시간(1209)에서 그들의 전송을 시작할 수 있다. 도 12b에 도시된 서버 타이밍 모델에 따르면, 서버는 시간(1209) 이후의 타겟 지속기간의 절반인 가장 이른 시간(1217)까지 다음 재생목록 파일을 전송하지 않아야 하고, 서버는 도 12b에 도시된 예에서 시간(1209) 이후의 1배 반의 타겟 지속기간이 되도록 명시된 시간(1219)보다 늦게 다음 재생목록 파일을 이용가능하게 하지 않아야 한다. 이 서버 타이밍 모델은, 재생목록 파일이 클라이언트 장치에 이용가능하게 되어 클라이언트 장치에게 재생목록에 명시된 미디어 파일들을 검색하기에 충분한 시간을 제공하고 재생 동안에 콘텐츠의 프리젠테이션에서 정체없이 일관적이고 지속적으로 이들 파일들을 프리젠팅하는 것을 보장하는데 이용될 수 있다. 한 실시예에서, 이들 서버 타이밍 모델은, 콘텐츠가 라이브 이벤트의 전송이고 그 라이브 이벤트로부터의 데이터의 스트림이 복수의 미디어 파일로 분할된 다음 이들 복수의 미디어 파일들이 라이브 이벤트에 대해 준 실시간으로 클라이언트 장치에 전송되며, 여기서 클라이언트 장치는 야구 게임 등과 같은 라이브 이벤트의 데이터 스트림으로부터 분할된 직후에 이 복수의 미디어 파일들을 수신하는 경우에 이용될 수 있다.

도 13은, 특히 클라이언트 장치가 라이브 이벤트를 준 실시간으로 프리젠팅하고 있고 클라이언트 장치가 라이브 이벤트의 (시간적으로 가장 최신이 되는) 현재의 끝 부근에 있는 콘텐츠를 프리젠팅하고 있을 때 클라이언트 장치에서의 재생시에 정체를 피하는데 이용될 수 있는 방법의 실시예를 도시한다. 예를 들어, 라이브 이벤트가 야구 게임이라면, 클라이언트 장치의 사용자는 게임의 시작부터 게임의 시청을 개시하기 보다는 게임에서 가장 최근의 이벤트만을 시청하기를 선호할 수도 있다. 사용자가 진행중인 게임의 가장 최근의 이벤트만을 시청하기를 원한다면, 사용자는 이용가능한 미디어 스트림의 끝으로부터 마지막 10초 또는 15초에서 시작하는 지점으로부터 시작하도록 재생을 설정하기를 원할 수 있다. 네트워크 문제 또는 지연은 데이터가 갑작스럽게 이용불가능하도록 할 수 있고, 새로운 데이터가 이용가능하게 되는 것을 방해할 수 있으므로, 매우 짧은 기간에, 클라이언트 장치는, 사용자가 클라이언트 장치를 이 모드에서 동작하도록 설정했을 때 프리젠팅될 콘텐츠를 소진할 수 있다. 현재의 재생목록 파일의 끝 이전의 적어도 소정 기간(예를 들어, 30초)에 해당하는 시작 포인트에서 재생이 시작할 것이 요구되도록 하는 규칙을 클라이언트 장치에 강제함으로써 이러한 사태의 가능성을 완화하기 위하여 도 13의 방법이 이용될 수 있다. 예를 들어, 재생목록 파일이 그 내부에 명시된 5개 미디어 파일을 가진다면(각 미디어 파일은 10초 길이), 이러한 규칙의 한 구현은, 재생목록에 명시된 5개 미디어 파일들의 시퀀스에서 3번째 미디어 파일보다 늦지 않도록 시작 포인트를 강제하는 것일 수 있다. 이제 도 13을 참조하면, 동작(1301)은 endlist 태그 또는 마커가 재생목록에 존재하는지의 여부를 판정하는데 이용될 수 있다. 이러한 endlist 태그가 존재한다면, 도 13의 방법은 어떠한 새로운 콘텐츠도 재생목록에 추가되지 않을 것이므로 정지할 수 있고, 따라서 한 실시예에서는 동작(1303)에 이 규칙을 강제할 필요가 없다. 반면, 재생목록에 어떠한 endlist 태그도 존재하지 않는다면, 시작 포인트가 재생목록 파일의 끝 이전의 적어도 소정 기간이 되도록 요구하는 규칙이 클라이언트 장치에 강제될 수 있다. 이 소정 기간은 미디어 파일들의 타겟 지속기간에 기초하여 명시될 수 있다. 예를 들어, 한 실시예에서, 클라이언트 장치는 재생목록 파일의 끝으로부터 3 타겟 지속기간보다 많이 미디어 파일로부터 시작할 것을 요구받을 수 있다.

본 발명의 또 다른 양태는, 2개의 재생목록으로부터의 스트림들(예를 들어, 2개의 변종 스트림)간의 전환시에 또는 2세트의 미디어 파일들간의 기타의 전환시에 이용될 수 있는 방법에 관한 것이다. 2개의 상이한 재생목록들로부터의 스트림들간의 전환을 위한 방법의 예가 도 9a, 9b, 9c, 및 9d와 연계하여 제공되었다. 이 방법에서, 스트림들간의 전환 또는 천이가 씸리스화(seamless)될 수 있도록 일관적이고 연속적인 재생을 보장하기 위해 2개 스트림들간의 시간적 중첩이 이용될 수 있다. 도 9d에 도시된 바와 같이, 중첩(955)은, 양쪽 스트림들로부터의 미디어 콘텐츠가 클라이언트 장치에 저장되고 클라이언트 장치에서 재생될 수 있음으로써 2개 스트림들간의 씸리스 전환을 허용할 수 있게 되는 기간을 나타낸다. 한 실시예에서, 이 중첩은 결코 변동하지 않는 최소수(minimum number)이며 클라이언트 장치 내에서 설정될 수 있다. 이 실시예는 잘 동작할 수 있지만, 중첩이 불필요하게 너무 길게 될 수 있는 때가 존재할 수 있다. 즉, 중첩은, 장치가 천이를 행할 준비가 되어 있더라도 전환이나 천이가 발생하지 못하게 할 수 있다. 예를 들어, 저해상도로부터 고해상도로의 전환시에, 불필요하게 긴 중첩은, 고해상 프리젠테이션이 이미 이용가능하고 프리젠팅될 준비가 되어 있는 때에 소정 기간 동안 사용자로 하여금 저해상도 프리젠테이션을 보게할 수 있다. 더 고속의 접속은, 예를 들어, 저속 접속이나 접속 타입에 요구되는 중첩보다 짧을 수 있는 중첩을 신속하게 전개하는 능력을 제공할 수 있다. 도 14a에 따른 실시예에서, 클라이언트 장치는 접속 속도나 접속 타입에 적응할 수 있고 접속 속도나 접속 타입에 기초하여 요구되는 최소 중첩을 수정할 수 있다. 예를 들어, 접속 속도나 타입이 빠르다면, 최소 중첩은 더 낮은 접속 속도나 접속 타입에 요구되는 최소 중첩에 비해 줄어들 수 있다. 상태가 변하면(예를 들어, 클라이언트 장치가 3G 접속을 잃고 2G 또는 더 느린 접속에 의존해야 한다면), 최소 중첩이 변경될 수 있다. 따라서, 클라이언트 장치는 접속 속도나 타입에 기초하여 최소 중첩에 적응할 수 있다. 이제 도 14a를 참조하면, 동작(1401)에서, 클라이언트 장치는 접속의 속도 또는 타입을 판정할 수 있다. 도 9d로 되돌아가면, 클라이언트 장치가 제1 재생목록으로부터 스트림을 역시 수신하는 동안 제2 재생목록으로부터의 제2 데이터 스트림은 수신되고 있는 데이터의 새로운 소스가 된다는 것을 알 수 있다. 이 때, 클라이언트 장치는 동작(1403)에서 현재의 접속 속도 또는 접속 타입에 기초하여 요구되는 중첩의 최소량을 결정하기 위하여 접속의 속도나 접속의 타입을 결정할 수 있다. 상태가 변함에 따라, 이 최소 중첩은, 셀룰러 전화 타워, WiFi 기지국 등으로의 무선 접속과 같은 변화하는 상태에 기초하여 적응될 수 있다. 이것은 클라이언트 장치가 무선 셀룰러 전화 네트워크 또는 기타의 데이터 네트워크를 통해 움직일 때 특히 유익할 수 있다. 현재의 조건에 대한 최소 중첩이 존재하도록 설정한 후에, 클라이언트 장치는 동작(1405)에서 제1 재생목록 또는 구 소스(old source)로부터의 스트림으로부터 제2 재생목록으로부터의 스트림일 수 있는 새로운 소스로 전환 또는 천이할 수 있다. 이러한 천이의 예가 도 9a 내지 도 9d와 연관된 설명과 연계하여 제공되었다.

도 14b, 도 14c, 및 도 14d는 (도 9a 내지 도 9d와 연계하여 설명되고 도시된 중첩 또는 도 14a와 연계하여 설명된 중첩과 같은) 2개의 스트림들 사이의 중첩이 어떠한지에 대한 또 다른 양태를 도시한다. 도 14b, 도 14c 및 도 14d에 도시된 방법은 (도 14a와 연계하여 설명된) 적응적으로 유도된 중첩에 의해 구현되거나 또는 이 방법은 변하지 않는 고정된 중첩과 함께 이용될 수도 있다. 도 14b 내지 도 14d에 도시된 방법은 (예를 들어, 새로운 스트림(1414)에 대한 추가의 다운로드의 제2 속도보다 비트 레이트에서 더 느린 제1 속도에서 다운로드되는 더 낮은 해상도의 비디오일 수 있는) "구 스트림(old stream)"(1410)으로부터의 미디어 파일의 다운로딩으로 시작할 수 있다. 구 스트림(1410)은 해쉬 마커(1411)로 표시된 바와 같이 다운로드되었고 클라이언트 장치에서 재생 포인트(예를 들어, 거기서 재생 헤드 위치)(1412)에서 사용자에게 현재 프리젠팅중이며; 현재의 재생 포인트(1412) 이후의 구 스트림(1410)에서 이미 다운로드된 콘텐츠는 접속이 고장나게 될 때 이용할 수 있는 버퍼링된 콘텐츠이다. 그러면 클라이언트 장치는 새로운 스트림(1414)에 대한 재생목록 파일을 판독하여 이들 블록들의 콘텐츠의 다운로딩 이전에도 그 재생목록 파일로부터 블록(1416 및 1415)과 같은 콘텐츠 "블록들"을 결정할 수 있는데; 예를 들어, 새로운 스트림에 대한 재생목록 파일은, 구 스트림(1410)에 대한 콘텐츠 블록(1416 및 1415)의 시간적 위치를 적어도 근사적으로 나타낼 수 있다. 이러한 결정은 블록(1415)에 대한 하나 이상의 미디어 파일을 요청하고 검색함으로써 클라이언트 장치가 새로운 스트림(1414)에 대한 첫 번째 블록(1415)을 다운로드하기로 보수적으로 결정하는 것을 허용할 수 있고, 도 14c는 그 다운로드의 결과를 도시한다(블록 1415A는 이 블록이 다운로드되었다는 것을 보여주기 위해 해쉬 마크를 가진다). 재생 위치는 시간적으로 새로운 위치로 진행하였다(여전히 구 스트림(1410)의 최좌측 블록 내). 이 경우 블록(1415)의 다운로딩은 재생 위치가 구 스트림(1410)의 그 최좌측 블록을 떠나지 않았을 정도로 충분히 빨랐다. 블록(1415)은, 다운로드가 더 오래 걸린 경우 재생이 적어도 블록(1415A) 부근에서 전환될 수 있도록 보수적으로 선택되었다. 도 14c에서 도시된 포인트에서, 클라이언트 장치는 블록(1415A)에 의해 제공된 중첩과 (도 14c에서 1412로 표시된) 재생의 현재 포인트 사이에 얼마나 많은 시간이 남아 있는지를 검사할 수 있다. 주어진 접속 속도에서 충분한 시간이 있다면, 클라이언트 장치는 현재의 중첩 이전의 블록인 블록 또는 세그먼트(1416)를 다운로드할 수 있고, 그 다음 클라이언트 장치는 (도 14d에서 다운로드된 이후에 해쉬 마크로 표시된 바와 같이 도시된) 방금 다운로드된 블록(1416A)에 의해 제공된 중첩과 (도 14d에서 1412로 표시된) 재생의 현재 포인트 사이에 얼마나 많은 시간이 남아 있는지를 판단하기 위해 반복적으로 검사할 수 있다. 만일 도 14d에 도시된 예의 경우에서와 같이, 1416A의 다운로드가 재빨리 발생하면, 클라이언트 장치는 중첩의 포인트를 시간적으로 뒤로 이동할 수 있어서, 스트림들간의 전환에 걸리는 시간을 줄이고(그에 따라 블록(1416A) 내에서의 전환을 허용한다); 반면, 전환이 블록(1416A) 내에서 발생하지 못할 정도로 1416A의 다운로딩에서 지연이 존재한다면, 클라이언트 장치는 전환이 블록(1415A) 내에서 발생하게끔하는데 이용될 수 있는 중첩으로서 블록(1415A)을 이용할 수 있다.

한 실시예에서, (도 9a 내지 도 9d와 도 14a 내지 도 14d에서 도시된 예들에서와 같은) 2개의 스트림들 사이의 전환시, 클라이언트 장치는, 새로운 스트림(예를 들어, 스트림(1414))으로의 전환이 완료되거나 전환이 새로운 스트림 상에서 최소 기간 동안 안정적으로 동작할 때까지 구 스트림(예를 들어, 스트림(1410))을 (폐기가 아니라) 계속 저장할 수 있다.

본 발명의 또 다른 양태는 화상의 해상도를 정의하는 속성을 이용할 수 있다. 이 속성은 클라이언트 장치가 이 속성에 기초하여 해상도를 전환해서는 안되는지 또는 그렇지 않으면 스트림을 전환해서는 안되는지를 결정하는 것을 허용할 수 있다. 예를 들어, 클라이언트 장치는 자신이 디스플레이할 수 있는 최대 해상도를 이미 재생하고 있고 데이터 네트워크를 통해 장치에 이용가능할 수 있는 더 높은 해상도를 다운로딩할 필요가 없다고 결정할 수 있다.

도 15는 이러한 속성을 이용하기 위한 한 실시예의 방법의 예를 도시한다. 동작(1501)에서, 재생목록 파일이 클라이언트 장치에 의해 수신될 수 있고, 클라이언트 장치는, 동작(1503)에서, 그 재생목록 파일로부터, 클라이언트 장치에 이용가능한 영상의 해상도를 정의하는 속성이 재생목록 파일 내에 존재하는지를 결정할 수 있다. 그 속성에 기초하여, 클라이언트 장치는, 동작(1505)에서, 또 다른 재생목록 파일을 검색할지 또는 그 속성과 연관된 미디어 파일을 검색할지를 결정할 수 있다. 해상도 속성을 제공함으로써, 클라이언트 장치는 재생목록 내의 데이터를 처리할 방법을 지능적으로 결정할 수 있다. 게다가, 클라이언트 장치는 불필요한 다운로드를 방지할 수 있는 데이터의 검색에 대한 결정을 내릴 수 있고, 이것은, 결국, 네트워크 상의 데이터 트래픽의 양을 최소화할 수 있다.

본 발명의 실시예는 시스템이 날짜와 시간에 기초하여 콘텐츠를 탐색하는 것을 허용할 수 있다. 예를 들어, 사용자는 2009년 4월 9일 약 오후 5시에 홈런 히트를 보기를 원하거나 해당 날짜의 근사한 시간에 또 다른 이벤트를 보기를 원할 수도 있다. 본 발명의 실시예는 대응하는 미디어 파일의 시작과 연관되는 EXT-X-PROGRAM-DATE-TIME 태그의 이용을 통해 타임스탬핑함으로써 이 능력을 제공할 수 있으며; 이 태그는 재생목록 파일 내의 그 미디어 파일 이전에 태그가 나타나게 함으로써 대응하는 미디어 파일과 연관될 수 있다. 서버와 같은 시스템은 클라이언트 장치에 의해 검색(예를 들어, 다운로드)되어 날짜 및 시간을 탐색하여 원하는 미디어 파일을 발견하는데 이용될 수 있는 하나 이상의 재생목록을 저장할 수 있고; 대안으로서, 클라이언트 장치는 그 날짜 및 시간 탐색 요청과 매칭하는 하나 이상의 미디어 파일을 식별하기 위해 하나 이상의 재생목록을 탐색할 것을 (예를 들어, 날짜 및 시간 탐색 요청을 통해) 서버에게 요청하고, 서버는 하나 이상의 미디어 파일을 식별함으로써 응답할 수 있다. 한 실시예에서, 태그는 미디어 파일들의 상당히 정확한 시작을 표시하고, 미디어 파일 내의 타임스탬프는 더 미세한 시간적 단위로 재생 포인트를 발견하는데 이용될 수 있다. 예를 들어, 태그의 타임스탬프는 미디어 파일이 2009년 4월 9일 오후 5:03에 시작되었음을 나타낼 수 있고 미디어 파일 내의 타임스탬프(또는 기타의 시간 표시자)는 오후 5:03 이후에 분 또는 초 등의 증분으로 시간을 명시할 수 있어서 장치가 (재생 시작 포인트의 선택을 통해) 예를 들어 오후 5:06 PM 또는 오후 5:05:30에 재생을 시작하는 것을 허용할 수 있다.

도 16a는 재생목록 파일을 생성하기 위해 타임스탬프 찍힌 태그를 이용하기 위한 한 실시예에 따른 방법을 나타내는 흐름도를 도시한다. 이 방법은, 소프트웨어, 하드웨어, 펌웨어, 또는 이들 중 임의의 것의 조합을 포함한 처리 로직을 이용하여 구현된 서버에 의해 수행될 수 있다. 일부 예에서, 서버는 MLB와 같은 미디어 제공자에 의해 제공된다.

박스(1610)에서, 처리 로직은 타임스탬프 찍힌 태그들을 생성하고 타임스탬프 찍힌 태그들 각각을 하나의 미디어 파일과 연관시킨다. 타임스탬프 찍힌 태그 내의 타임스탬프는 연관된 미디어 파일의 시작 날짜와 시간을 나타낸다. 타임스탬프 찍힌 태그의 일부 실시예의 상세사항이 위에서 논의되어 있다.

박스(1620)에서, 처리 로직은 하나 이상의 타임스탬프 찍힌 태그(예를 들어, EXT-X-PROGRAM-DATE-TIME 태그)를 갖는 재생목록 파일을 생성하고, 태그들 각각은 특정한 미디어 파일과 연관된다. 미디어 파일 그 자체도 역시 내부 타임스탬프를 가진다는 점에 유의한다. 박스(1630)에서, 처리 로직은, 타임스탬프 찍힌 태그들 내의 날짜 및 시간을 이용하여 날짜 및 시간별 탐색을 위해 재생목록 파일이 이용가능하도록 재생목록을 배포할 수 있다. 일부 실시예에서, 재생목록은 저위치(repository)에 저장되고, 이로부터 클라이언트 장치는 재생목록을 다운로드할 수 있다.

도 16b는 타임스탬프 찍힌 태그로 생성된 재생목록 파일을 이용하기 위한 한 실시예에 따른 방법을 나타내는 흐름도를 도시한다. 이 방법은, 소프트웨어, 하드웨어, 펌웨어, 또는 이들 중 임의의 것의 조합을 포함한 처리 로직을 이용하여 구현된 클라이언트 장치에 의해 수행될 수 있다. 클라이언트 장치는 미디어에 액세스하여 재생하기 위해 재생목록 파일과 연관된 미디어의 개개의 소비자, 가입자, 또는 시청자에 의해 이용될 수 있다.

박스(1650)에서, 처리 로직은 특정한 날짜 및 시간에 시작하는 프로그램의 세그먼트에 대한 사용자 요청을 수신한다. 예를 들어, 사용자는 전체 야구 게임 대신에 2010년 4월 6일 오후 8:15에 시작하는 야구 게임의 제4 이닝(fourth inning)을 요청할 수도 있다. 사용자 요청에 응답하여, 처리 로직은 블록(1652)에서 미디어 서버로부터 프로그램과 연관된 하나 이상의 재생목록 파일을 다운로드한다. 블록(1654)에서, 처리 로직은 요청된 세그먼트의 날짜 및 시간에 가장 가까운 날짜 및 시간 스탬프를 찾기 위해 재생목록 파일 내부의 타임스탬프 태그 내의 날짜 및 시간을 이용하여 다운로드된 재생목록 파일을 탐색한다. 처리 로직은 블록(1656)에서 요청된 세그먼트의 날짜 및 시간으로부터 그 날짜 및 시간을 감산한다. 이것은 지속기간을 생성한다. 그 다음 처리 로직은, 블록(1657)에서, 처리 로직이 날짜 스탬프 찍힌 미디어 파일 이후의 그 만큼의 지속기간에 대한 타겟 미디어 파일을 찾을 때까지 재생목록 파일에서 후속하는 미디어 파일 지속기간을 지나 앞으로 나간다. 그 다음 처리 로직은 블록(1658)에서, 어느 파일이 요청된 세그먼트를 포함하는지에 관한 최상의 추측으로서, 이 타겟 미디어 파일을 다운로드한다.

일부 실시예에서, 날짜 스탬프 찍힌 파일과 타겟 파일 사이의 모든 미디어 파일들은 단일 인코딩의 일부인데, 즉, 이들 사이에는 불연속 태그가 없다. 그들이 있는 경우, 처리 로직은 날짜 스탬프 찍힌 파일 내의 미디어 파일 타임스탬프를 타겟 파일 내의 것으로부터 감산하여 정확한 지속기간을 얻을 수 있고, 이것은 요청된 날짜 및 시간의 정확한 위치 파악을 허용한다.

재생목록 파일 내의 타임스탬프 찍힌 태그들 내의 날짜 및 시간을 이용하면, 처리 로직은 미디어 파일들을 탐색하여 요청된 세그먼트를 찾기 위하여 전체 프로그램의 모든 미디어 파일을 다운로드해야 할 필요가 없다. 클라이언트 장치는 사용자가 전체 프로그램을 요청하지 않을 때 전체 프로그램의 모든 미디어 파일을 다운로드해야할 필요가 없기 때문에, 대역폭에 있어서의 상당한 절감이 달성될 수 있다. 또한, 많은 전형적인 미디어 파일들은 종종 제로에서 시작하는 임의의 타임스탬프만을 포함한다. 따라서, 앞서 논의된 타임스탬프 찍힌 태그의 날짜 및 시간은 미디어 파일 내의 임의의 타임스탬프를 실제의 날짜 및/또는 시간과 연관시킬 수 있다. 타임스탬프 찍힌 태그를 이용하면, 클라이언트 장치는 각 미디어 파일을 철저히 스캐닝하는 것보다 더욱 효율적으로 특정한 날짜 및/또는 시간을 포함하는 재생목록 요소의 위치를 파악할 수 있다.

본 발명의 한 실시예는 ID3 포맷의 미디어 스트림 내로의 시간설정된 메타데이터(timed metadata)의 삽입을 허용한다. 이 미디어 스트림은 미리결정된 포맷으로 인코딩된 비디오 및/또는 오디오 데이터를 포함할 수 있다. 예를 들어, 미디어 스트림은 국제 표준 ISO/IEC 13818인 MPEG(Moving Pictures Expert Group)에 의해 개발된 MPEG-2로 인코딩된 비디오 및 오디오 데이터를 포함할 수 있다. 넓게 말하면, 메타데이터는 미디어 스트림 내의 데이터에 관한 정보와, 특정 시간(예를 들어, 득점된 시간)과 연관된 메타데이터를 참조하는 시간설정된 메타데이터를 포함한다. 시간설정된 메타데이터는 시간에 따라 변할 수도 있다는 점에 유의한다. 시간 설정된 메타데이터는 ID3 포맷과 같은 메타데이터를 저장하기 위한 미리결정된 포맷의 미디어 스트림 내에 삽입될 수 있다. 일부 실시예에서, 비디오 데이터는 프레임들의 시퀀스로 분할될 수도 있다. 비디오 데이터의 시간설정된 메타데이터도 역시 프레임들의 시퀀스와 연관된 컨테이너들로 분할될 수 있다. 각 컨테이너는, 대응하는 프레임의 시간설정된 메타데이터와, 대응하는 프레임과 연관된 시간, 양쪽 모두를 저장할 수 있다. 대안으로서, 각 컨테이너는, 대응하는 프레임의 시간설정된 메타데이터와, 대응하는 프레임의 프레임수, 양쪽 모두를 저장할 수 있다. 일부 실시예에서, 프레임의 시간설정된 메타데이터는 그 프레임의 미리결정된 정보 세트를 포함할 수 있다. 예를 들어, 시간설정된 메타데이터는 비디오 데이터의 대응하는 프레임이 기록되었던 위치의 위치 정보(예를 들어, GPS(global positioning system) 데이터)를 포함할 수 있다.

도 16c, 도 16d 및 도 16e는, 스트리밍 콘텐츠를 명시하는 URL(들)을 전송함으로써 스트리밍 콘텐츠를 요청한 클라이언트 장치와 같은 수신기에서 버퍼링된 스트리밍 콘텐츠의 재생을 제어하기 위해 시간설정된 메타데이터 또는 기타의 메커니즘을 이용할 수 있는 실시예의 예를 도시하고 있다. 이들 URL들은 여기서 설명된 하나 이상의 재생목록 파일 내에 포함될 수 있다.

도 16c는 디스플레이 장치(1660) 상에(또는 그 디스플레이 장치의 일부 상에) 프리젠팅될 수 있는 사용자 인터페이스(UI)를 도시한다. 라이브 스포츠 이벤트나 쇼 또는 시간에 기초하는 기타의 애니메이션된 콘텐츠와 같은 콘텐츠(1661)가, 한 실시예에서, 2개의 타임 라인(1662 및 1664)을 따라 프리젠팅된다. 타임 라인(1664)은 콘텐츠의 (90분 쇼와 같은 고정된 시간양이거나, 야구 게임과 같은 비확정된 시간양일 수 있는) 전체 시간 길이를 보여준다. 표시자(1667)는 전체 콘텐츠 내에서의 현재의 재생 위치를 보여주기 위해 프리젠팅될 수 있으며; 타임 라인의 길이에 대한 타임 라인(1666) 상의 표시자(1667)의 위치는 현재의 재생 위치를 나타낸다. 예를 들어, 표시자(1667)가 좌측 끝점과 우측 끝점 사이의 중간에 있다면, 현재의 재생 위치는 기존 콘텐츠를 통틀어 대략 중간이다. 타임 라인(1666)은 또한, 되감기 제어(1668), 잠시멈춤 제어(1669), 및 고속 전진 제어(1670)와 같은 기타의 UI 제어와 연관될 수 있다. 되감기 제어(1668)는, 선택시, 현재의 재생 위치를 시간적으로 뒤로 이동시킬 수 있다(예를 들어, 30초 뒤로 이동). 잠시멈춤 제어(1669)는, 선택시, 수신기에서의 재생을 정지할 수 있고, 고속 전진 제어(1670)는, 선택시, 현재 재생 위치를 가장 최근의 현재(예를 들어, 라이브 또는 준 라이브) 콘텐츠로 이동시킬 수 있다. 한 실시예에서, 타임라인(1666 및 1662) 양쪽 모두는 패널 아래에서 프리젠팅중인 스트리밍 콘텐츠를 오버레이하는 반투명(translucent) 또는 반-투명(semi-transparent) 패널에 동시에 프리젠팅될 수 있다.

타임 라인(1662)은, 한 실시예에서, 수신기에서 버퍼링된 콘텐츠의 양의 시간적 길이를 나타낸다. 수신기는, 데이터 통신 속도가 느려지거나 스트리밍 콘텐츠의 데이터 통신이 중단되더라도 재생할 얼마간의 스트리밍 콘텐츠가 항상 존재하도록 보장하기 위해, 여기서 설명된 바와 같이, 스트리밍 콘텐츠를 버퍼링할 수 있다. 도 16c에 도시된 예에서, 총 4분 30초의 스트리밍 콘텐츠가 수신기에서 수신되어 버퍼링되었으며; 이 총 시간은 마커(1663)(3분 51초)와 마커(1665)(39초)로부터 유도되고, 이들 마커는 또한, 현재의 재생 위치가 (여기서 설명된 바와 같이 라이브 또는 준 실시간 라이브일 수 있는) 가장 최근에 수신된 콘텐츠로부터 39초임을 보여준다. 한 실시예에서, 버퍼링된 콘텐츠 내에서의 현재의 재생 위치는, 예를 들어, 표시자(1664)를 선택하고 타임라인(1662)을 따라 이동시킴으로써 변경될 수 있다. 이것은, 예를 들어, 손가락으로 표시자(1662)를 터칭하거나 마우스를 통한 커서의 제어에 의해, 또는 기타의 공지된 사용자 인터페이스 기술을 통해 이루어질 수 있다. 도 16d는 (버퍼링된 콘텐츠에서의 중간 포인트까지) 표시자(1662)를 이동하여 콘텐츠의 프리젠테이션이 가장 최근에 수신되어 버퍼링된 콘텐츠 이전의 2분 15초의 재생 포인트에 현재 설정되어 있는 결과의 예를 도시한다.

도 16e는 도 16c 및 도 16d에 도시된 사용자 인터페이스를 이용하기 위한 한 실시예의 방법의 예를 도시한다. 수신기와 같은 데이터 처리 시스템은, 동작(1672)에서, 스트리밍 프로그램의 현재 길이를 나타내는 타임라인(1666)과 같은 타임라인을 디스플레이 또는 그렇지 않으면 프리젠팅하고, 또한 제어(1668, 1669, 및 1670)와 같은 UI 제어를 디스플레이할 수 있다. 추가하여, 이 시스템은 또한, 동작(1673)에서, 버퍼링된 콘텐츠 내에서의 현재 재생 위치를 나타내는 타임라인(1662)과 같은 또 다른 타임라인을 동시에 디스플레이할 수 있다. 한 실시예에서, 타임라인은 현재 버퍼링된 콘텐츠의 시간적 총 길이를 나타낼 수 있는 타임라인 상에 버퍼링된 콘텐츠에서의 현재의 재생 위치의 표시자를 보여줄 수 있다. 수신기는, 동작(1674)에서, 스트리밍 콘텐츠의 프리젠테이션을 변경하기 위하여 하나 이상의 UI 제어 상의 사용자 입력에 응답할 수 있다. 예를 들어, 사용자가 타임라인(1662)을 따라 표시자(1664)를 이동시키면, 사용자는 버퍼링된 콘텐츠 내에서의 현재 재생 위치를 변경할 수 있고; 도 16c 및 도 16d에 도시된 예는, 현재의 재생 위치가 (준 실시간 "라이브" 스트림일 수 있는) 가장 최근에 수신된 콘텐츠 이전의 수 초로부터 가장 최근 콘텐츠 이전의 수 분으로 변경될 수 있다. 도 16c 및 도 16d의 예에서, 사용자는, 사실상, 버퍼링된 콘텐츠 내의 초기 포인트로 재생을 되감았고 버퍼링된 콘텐츠를 다시보기할 수 있으며, 이러한 되감기는 콘텐츠의 타임라인(1666)과 같은 전체의 현재 타임라인과 별도의 타임라인 상에서 제어될 수 있다.

본 발명의 한 실시예에서, 미디어 파일들의 처리(예를 들어, 재생목록의 검색 및 재생목록에 명시된 미디어 파일의 검색 및 미디어 파일 내의 콘텐츠의 디코딩)는 미디어를 프리젠팅하고 제어하는 사용자 인터페이스로부터 프리젠팅되는 것과는 별개로 이루어질 수 있다. 예를 들어, (예를 들어, 야구 게임을 시청하기 위한 메이저 리그 베이스볼(MLB) 애플리케이션과 같은) 라이브 이벤트 또는 기타의 스트림을 시청할 수 있는 애플리케이션과 같은 사용자 애플리케이션은 프리젠테이션을 프리젠팅 및 제어(예를 들어, 미디어 파일의 선택을 수신)하기 위한 사용자 인터페이스를 제공하는 반면, 또 다른 소프트웨어 프로세스(예를 들어, "mediaserverd"라고도 불릴 수 있는, 미디어를 서빙하기 위한 데몬(daemon)과 같은 미디어를 서빙하는 소프트웨어 프로세스)는 재생목록을 검색하고 미디어 파일들을 검색 및 디코딩할 수 있다. 일부 경우에, 미디어 파일은 암호화될 수 있고, 암호화는 사용자 애플리케이션(예를 들어, MLB 애플리케이션)에 의해 제어될 수 있는데; 예를 들어, 사용자 애플리케이션은, 미디어 콘텐츠를 암호해독하는데 이용될 수 있는 키를 다운로드하기 위해 HTTP SSL(Secured Sockets Layer) 접속이 이루어질 때 서버 챌린지(server challenge)에 응답하는데 이용될 수 있는 클라이언트 인증서(예를 들어, 신뢰의 인증과 체인 및 폐기가능성을 제공하는 X.509 인증서)를 그들의 키체인 내에(영구적으로 또는 메모리에만) 설치할 수 있다. 다른 경우에, 재생목록은 사용자 애플리케이션과 상호작용하는 서버 또는 사용자 애플리케이션에 의해 이용되는 맞춤형 URL 스킴을 이용하는 하나 이상의 키에 대한 URL을 포함할 수 있는데; 이 경우, 사용자 애플리케이션은 (새로운 키와 같은) 키를 얻기 위해 기동될 수 있는 이들 맞춤형 URL 스킴에 대한 URL 프로토콜 핸들러를 등록할 수 있고, 이것은 사용자 애플리케이션이 키를 대역외로(예를 들어, 그들의 애플리케이션 바이너리에서 은닉된) 수송하는 것을 허용하거나 사설 프로토콜을 이용하여 서버로부터 키를 얻는 것을 허용할 수 있다.

도 17은 미디어 서빙 데몬(media serving daemon)이 사용자 애플리케이션과 상호작용하는 것을 허용하는 소프트웨어 아키텍쳐의 한 실시예를 도시한다. 이 아키텍쳐는 미디어 서빙 데몬("mediaserverd")(1710) 및 예시적 사용자 애플리케이션인, EMP(Event Media Provider) 애플리케이션(1720)을 포함하며, 양쪽 모두는, 예를 들어, 스마트폰, PDA(personal digital assistant), 데스크탑 컴퓨터, 랩탑 컴퓨터, 태블릿 장치 등과 같은 클라이언트 장치에서 실행 중인 프로세스에서 실행가능하다. 클라이언트 장치의 한 실시예는 도 8에 도시된 전자 시스템(800)을 이용하여 구현될 수도 있다. 일부 실시예에서, mediaserverd(1710) 및 EMP 애플리케이션(1720) 양쪽 모두는, 메모리 제어, 메모리 공간, 메모리 할당, 파일시스템 제어, 및 네트워크 제어에 관하여 동일한 특권을 공유한다. 이와 같이, mediaserverd(1710)는 EMP 애플리케이션(1720)이 액세스할 수 있는 데이터에 액세스할 수 있다. 마찬가지로, mediaserverd(1710)는 EMP 애플리케이션(1720)이 액세스할 수 없는 데이터에 액세스하는 것이 금지된다.

일부 실시예에서, EMP 애플리케이션(1720)은, URL 프로토콜 핸들러인 EMP 핸들러(1725)에 액세스하는 네트워킹된 스택(1723)에 액세스하기 위한 맞춤형 소프트웨어 스택인 코어 미디어 스택(1721)을 더 포함한다. EMP 애플리케이션(1720)은 하나 이상의 키를 얻기 위해 기동될 수 있는 맞춤형 URL 스킴에 대해 EMP 핸들러(1725)를 등록할 수 있다. 따라서, EMP 애플리케이션(1720)은 키를 대역외로(예를 들어, 애플리케이션 바이너리에서 은닉된) 수송할 수 있다.

일반적으로, mediaserverd(1720)와 EMP 애플리케이션(1720)은, 현재의 예에서는 EMP인 콘텐츠 제공자로부터의 라이브 스트리밍 콘텐츠를 위해 미디어 파일들을 다운로드하여 재생하도록 서로 상호작용할 수 있다. 재생은 클라이언트 장치 상에서 mediaserverd(1710)에서 이루어질 수 있다. 일부 실시예에서, mediaserverd(1710)는 미디어 파일들의 암호해독을 위한 키를 다운로드할 수 있고, 이것이 실패한다면, mediaserverd(1710)는 EMP 애플리케이션(1720)에게, 현재의 예에서 EMP 서버(1730)인 콘텐츠 제공자 서버로부터 키를 다운로드할 것을 요청할 수도 있다. 클라이언트 장치 상에서 실핼 중인 EMP 애플리케이션(1720)은 하나 이상의 키를 얻기 위해 서명(sign up)할 수 있다. 대개, EMP 애플리케이션(1720)은 미디어 파일의 다운로드 이전에 키를 서명하고 취득할 수 있다. 이 개념을 더 예시하기 위하여 이하에서는 mediaserverd(1710)와 EMP 애플리케이션(1720) 사이의 상호작용의 일부 실시예들의 상세사항이 논의된다.

도 17을 참조하면, EMP 애플리케이션(1720)은 적어도 URL과 키를 갖는 재생목록을 mediaserverd(1710)에 전송한다(1). 이 키를 이용하여, mediaserverd(1710)는 그 URL에서 EMP에 의해 제공된 미디어 소스에 액세스하여 그 미디어 소스로부터 재생목록에 명시된 미디어 파일들을 다운로드하는 것을 시도한다. 미디어 파일은 미디어 파일의 콘텐츠의 무허가 시청을 방지하기 위해 인코딩 또는 암호화될 수 있다. mediaserverd(1710)가 미디어 파일을 다운로드하는 것을 실패하거나, 다운로드된 미디어 파일을 디코딩 또는 암호해독하는 것을 실패한다면(2), mediaserverd(1710)는 그 실패를 EMP 애플리케이션(1720)에 보고한다(3).

mediaserverd(1710)로부터의 실패 보고에 응답하여, EMP 애플리케이션(1720)은, 새로운 키를 요청하기 위하여 그 코어 미디어 스택(1721)을 이용하여 네트워킹 스택(1723)에 액세스하고(4), 결국, 새로운 키를 위해 EMP 핸들러(1725)에 액세스한다(5). EMP 핸들러(1725)는 네트워크(예를 들어, 인터넷)를 통해 EMP 서버(1730)에 접속하여 EMP 서버(1730)에게 새로운 키를 요청한다(6). 요청에 응답하여, EMP 서버(1730)는 새로운 키를 EMP 핸들러에 전송한다(7). EMP 핸들러(1725)는 새로운 키를 코어 미디어 스택(1721)에 전달하고(8), 그 다음, 새로운 키를 mediaserverd(1710)에 전달한다(9).

mediaserverd(1710)가 코어 미디어 스택(1721)으로부터 새로운 키를 수신하면, mediaserverd(1710)는 새로운 키를 이용하여 다시 한번 미디어 파일의 다운로드를 시도하고 새로운 키를 이용하여 다운로드된 미디어 파일의 디코딩을 시도할 수 있다(10). 대안으로서, 미디어 파일이 이전에 성공적으로 다운로드되었지만, mediaserverd(1710)가 미디어 파일의 암호해독에 실패하였다면, mediaserverd(1710)는 앞서 다운로드된 미디어 파일을 새로운 키를 이용하여 암호해독하는 것을 시도할 수 있다. mediaserverd(1710)가 새로운 키를 이용하여 미디어 파일을 성공적으로 다운로드하여 디코딩하면, EMP 애플리케이션(1720)은 디코딩된 미디어 파일을 클라이언트 장치 상에 프리젠팅할 수 있다.

여기서 설명되는 한 실시예에서, 재생목록 파일은 재생목록 파일에 의해 제공되는 콘텐츠의 타입을 나타낼 수 있다. 콘텐츠의 타입은 재생목록 파일의 타입을 정의할 수 있고, 재생목록 파일의 타입은 재생목록 파일 내의 태그의 파라미터에서 명시될 수 있다. 한 실시예에서, 태그는 다음과 같은 형태를 취할 수 있다: #EXT-X-PLAYLIST-TYPE: [VOD|LIVE|EVENT]. 이 태그는 VOD 또는 LIVE 또는 EVENT 중 하나 또는 단 하나만을 명시할 수 있다. "VOD"는 재생목록 파일이 Video on Demand(VOD) 콘텐츠에 대한 것임을 나타낼 수 있고, "LIVE"는 재생목록 파일이, 미확정 종료 시간과 미확정 시작 시간을 가질 수 있고 클라이언트 장치에서 비디오의 디스플레이를 통한 재생과 같은 프리젠테이션을 위해 미디어 파일이 수신되는 것과 거의 동시에 발생할 수 있는 라이브 콘텐츠에 대한 것임을 나타낼 수 있다. "EVENT"는 재생목록 파일이 농구 게임이나 야구 게임과 같은 미확정 종료 시간을 가질 수 있지만 명확한 고정된 시작 시간을 가질 수 있고 클라이언트 장치에서의 프리젠테이션을 위해 미디어 파일이 수신되는 것과 거의 동시에 발생할 수 있는 이벤트에 대한 것임을 나타낸다. 이러한 타입의 태그를 갖는 재생목록 파일은 여기서 설명된 다른 재생목록 파일들과 유사할 수 있으며, 클라이언트 장치가 재생목록 파일을 수신한 이후에 재생목록 파일에 표시된 순서로 클라이언트 장치에 의해 검색될 수 있는 복수의 미디어 파일을 나타내는 URI(Universal Resource Indicator)를 포함한다. 재생목록 파일은 또한, 재생목록 파일 내의 복수의 미디어 파일의 재생에 관련된 (VOD 또는 LIVE와 같은) 파라미터들을 갖는, #EXT-X-PLAYLIST-TYPE 태그와 같은 복수의 태그를 포함할 수 있다. 재생목록의 타입을 명시하는 이러한 타입의 태그를 갖는 재생목록 파일은 본 개시에서 설명된 다른 재생목록 파일과 유사할 수 있다.

재생목록 파일 내의 #EXT-X-PLAYLIST-TYPE와 같은 타입의 태그의 존재는, 재생목록이 콘텐츠의 타입과 일치하는 동작의 방식을 고수할 것임을 효과적으로 공표하고, 이것은 클라이언트 장치가 재생목록 또는 콘텐츠의 타입에 대해 최적화될 수 있는 방식으로 재생목록을 처리하는 것을 허용할 수 있다. 클라이언트 장치는 VOD 또는 LIVE 또는 Event와 같은 재생목록-타입 표시자의 존재를 검사할 수 있고, 그 재생목록 타입 표시자에 따라 최적의 방식으로 재생목록을 처리할 수 있다.

예를 들어, 재생목록 타입 표시자가 "VOD"일 때, 그 재생목록은 클라이언트 장치가 그 재생목록 파일을 업데이트하지 않도록 구성되게 할 수 있는데, 이것은 Video on Demand 프리젠테이션에 대한 재생목록은 바뀌지 않을 것이므로 재생목록 파일의 업데이트를 요청할 필요가 없다고 가정될 수 있기 때문이다. 따라서, 이러한 상황에서, 클라이언트 장치는 재생목록 파일의 업데이트를 요청하지 않도록 구성될 것이다. 또한, 재생목록 파일이 재생목록 타입 표시자에 의해 명시된 바와 같은 "VOD" 타입일 때, 재생목록은 클라이언트 장치가, 동일한 Video on Demand 콘텐츠의 더 나은 품질의 프리젠테이션을 위한 재생목록과 같은, 제2 변종 재생목록을 수신하여 그의 사용으로 전환한 후에, Video on Demand의 더 낮은 품질의 프리젠테이션을 위한 재생목록과 같은 제1 변종 재생목록을 세이브(save)하도록 구성될 수 있는데, 이것은, 제1 변종 재생목록은 전환 후에 여전히 유효할 것이고, 네트워크 대역폭이 더 낮아지거나 제2 변종 재생목록의 이용을 더 이상 지원할 수 없을 때와 같이 제2 변종 재생목록의 이용이 문제가 생기는 경우에 이용될 수 있기 때문이다. 또한, 재생목록 타입 표시자가 "VOD"일 때, 클라이언트 장치는 ENDLIST 태그 또는 재생목록이 끝임을 나타내는 기타의 태그를 찾기 위해 재생목록 파일을 검사하도록 구성되고, 만일 이러한 태그가 재생목록 파일에 없다면, 클라이언트 장치는 그 재생목록이 에러를 갖는 것으로 표시할 수 있다.

재생목록 타입 표시자가 "LIVE"일 때, 클라이언트 장치는 업데이트된 재생목록 파일을 반복적으로 요청하도록 구성될 수 있다. 재생목록 타입 표시자가 "EVENT"일 때, 클라이언트 장치는 (a) 업데이트된 재생목록의 더 최근 부분만을 로딩(이로써 업데이트된 재생목록의 더 오래된 부분의 수신을 피함)하거나 (b) 업데이트된 재생목록의 더 최근 부분만을 파싱(이로써 업데이트된 재생목록의 더 오래된 부분의 재-파싱을 피함)하도록 구성될 수 있다.

도 20은 타입 표시자를 포함하는 능력을 갖는 재생목록이 처리될 수 있는 한 실시예에 따른 방법의 예를 도시한다. 동작(2001)에서, 재생목록은 클라이언트 장치에 의해 수신될 수 있고, 클라이언트 장치는 동작(2003)에서, 재생목록 파일이 "VOD" 또는 "LIVE" 또는 "EVENT" 등과 같은 타입 표시자를 포함하는지를 판정할 수 있다. 한 실시예에서는 이들 예시적 타입들의 부분집합이 이용될 수도 있고 일부 실시예에서는 여기서 설명되지 않은 다른 타입이 역시 이용될 수도 있다는 것을 이해할 것이다. 클라이언트 장치가 재생목록이 타입 표시자를 포함한다고 판정하면, 동작(2007)에서, 클라이언트 장치는, 여기서 설명되거나 후술되는 도 21에 도시된 방식 등으로, 그 타입 표시자를 이용하여 재생목록을 적절히 처리한다. 클라이언트 장치가 동작(2003)에서 재생목록 파일이 타입 표시자를 포함하지 않는다고 판정하면, 동작(2005)에서, 클라이언트 장치는 재생목록 타입 표시자를 이용하지 않고 재생목록을 처리한다(예를 들어, 도 21에 도시된 최적화가 수행되지 않는다).

도 21은 본 발명의 한 실시예에 따른 다양한 타입의 재생목록 타입 표시자들 중 하나 이상의 이용례를 도시한다. 도 21에 도시된 방법에서는 3개의 상이한 타입 표시자 존재가 가능하다고 가정하지만, 재생목록 파일에 대한 재생목록 타입을 명시하기 위해 더 적은 수의 타입 표시자가 이용되거나 더 많은 수의 타입 표시자가 이용될 수 있다는 것을 이해할 것이다. 대안적 실시예들은 더 적은 수의 동작 또는 더 많은 수의 동작 또는 도 21에 도시된 것과는 상이한 순서의 동작을 가질 수도 있다는 것을 역시 이해할 것이다. 동작(2101)에서, 클라이언트 장치는 재생목록 파일이 재생목록 타입 표시자를 포함하는지를 판정한다. 아무것도 존재하지 않으면, 클라이언트 장치는, 동작(2103)에서, 타입 표시자의 이용없이 동작하고, 본 개시의 나머지 부분에서 설명되는 바와 같이 재생목록 파일을 처리한다. 반면, 재생목록 타입 표시자가 존재하면, 동작(2105)에서, 클라이언트 장치는 타입 표시자가 "LIVE" 표시자인지를 판정하고, 그 경우, 클라이언트 장치는, 동작(2107)에서, 재생목록 파일을 반복적으로 업데이트하도록 설정된다. 클라이언트 장치가 동작(2105)에서 타입 표시자가 "LIVE" 표시자가 아니라고 판정하면, 동작(2109)에서 그 타입 표시자가 "VOD" 타입인지를 판정한다. 타입 표시자가 "VOD"이면, 클라이언트 장치는, 동작(2111)에서, 재생목록 파일을 업데이트하지 않도록 설정되고, 클라이언트 장치는 또한 동작(2113 및 2115)을 수행할 수 있다. 동작(2113)에서, 클라이언트 장치는, 이전에 이용된 재생목록으로 다시 전환해야 경우에, 이전에 이용된 변종 재생목록을 세이브하는 한편 또 다른 변종 재생목록을 이용할 수 있다. 예를 들어, 클라이언트는, 동일한 Video on Demand 콘텐츠에 대한 제2 변종 재생목록을 수신하여 그의 사용으로 전환한 후에, Video on Demand의 더 낮은 품질 또는 더 낮은 비트 레이트 프리젠테이션을 위한 재생목록일 수 있는 제1 변종 재생목록을 세이브할 수 있는데, 이것은, 전환 이후에 제1 변종 재생목록은 여전히 유효할 것이고 네트워크 대역폭이 더 낮아지는 등과 같은 제2 변종 재생목록의 이용이 문제가 될 경우에 이용될 수 있기 때문이다. 동작(2115)에서, 클라이언트 장치는 "ENDLIST" 태그 또는 유사한 태그가 있는지를 검사할 수 있고, 재생목록 파일 내에서 아무것도 발견되지 않으면, 한 실시예에서, 클라이언트 장치는, 동작(2117)에서, 그 재생목록 파일이 에러를 갖는 것으로 표시할 수 있다.

동작(2109)에서, 재생목록 파일이 "VOD" 타입 표시자를 포함하지 않는 것으로 판정되면, 클라이언트 장치는 동작(2119)에서 재생목록 파일이 "EVENT" 타입 표시자를 포함하는지를 판정하고, 포함한다면, 동작(2123)을 수행하고, 그렇지 않다면, 재생목록 파일이 타입 표시자의 이용없이 처리되거나 여기서 설명되지 않은 상이한 타입 표시자를 이용하여 처리되는 동작(2121)을 수행한다. 동작(2123)에서, 클라이언트 장치는, 업데이트된 재생목록을 요청할 때, 현재의 재생 위치 이후의 업데이트된 재생목록의 가장 최근 부분만을 리로딩하거나, 전체의 업데이트된 재생목록을 로딩하되 현재 재생 위치 이후의 업데이트된 재생목록의 가장 최근 부분만을 파싱할 수 있다. 이런 방식으로, 클라이언트 장치는, 클라이언트 장치에서 이미 프리젠팅되었던 재생목록의 부분들의 처리를 회피하거나 네트워크를 통해 업데이트된 재생목록의 더 오래된 부분의 수신을 회피함으로써, 업데이트된 재생목록을 지능적으로 처리할 수 있다.

한 실시예에서, 클라이언트 장치는, 재생목록 파일에 명시된 미디어 파일의 데이터 액세스에 관련된 통계, 또는 미디어 파일의 수신시 발생하는 네트워크 에러에 관련된 통계를 저장하도록 구성될 수 있다. 이들 통계는, API(Application Program Interface)를 통해 클라이언트 애플리케이션에 이용가능하게 되어 네트워크 에러에 관한 정보 또는 미디어 파일로의 액세스에 관한 정보의 프리젠테이션을 허용할 수 있다. 이 정보는, 예를 들어, VOD 또는 라이브 쇼 등의 변종 스트림들 사이에서 디스플레이가 얼마나 많이 전환하는지일 수 있다. 도 22는 미디어 서버 애플리케이션으로부터 API를 통해 클라이언트 애플리케이션으로 통계가 제공될 수 있는 아키텍쳐의 예를 도시한다. 이 아키텍쳐의 경우, 미디어 서버(2201)는 재생목록 파일을 요청 및 수신하고, 재생목록 파일을 처리하여 콘텐츠를 클라이언트 애플리케이션(2203)에 제공하는 것을 책임질 수 있다. 미디어 서버 애플리케이션(2201)은 통계(2205)를 하나 이상의 로그에 저장하는 하나 이상의 로그를 생성할 수 있다. 클라이언트 애플리케이션은, 자신이 원하거나 사용자가 요청할 때, API 인터페이스(2207)를 통해 호출을 행함으로써 통계에 관한 정보를 프리젠팅할 수 있고, 응답하여, 미디어 서버(2201)는 요청된 통계를 검색하여 이들 통계를 API 인터페이스(2207)를 통해 클라이언트 애플리케이션(2203)에 제공할 수 있다. 미디어 서버(2201)는 스트리밍 콘텐츠를 재생 또는 제공하면서 통계를 수집할 수 있고, 클라이언트 애플리케이션(2203)으로부터의 요구시에 API 인터페이스(2207)를 통해 클라이언트 애플리케이션(2203)에 통계를 제공할 수 있다. 클라이언트 애플리케이션(2203)은 집계 서비스(aggregation service)에 통계 로그를 제공하는 것을 책임질 수 있고, 로그로부터 정보의 보고의 타이밍 및 빈도를 제어할 수 있다. 시스템은 통계를 저장하는 하나 이상의 로그를 가질 수 있고, 한 실시예에서, 로그는 W3C 확장된 로그 파일 포맷을 따를 수 있다. 한 실시예에서, 2개 타입의 로그, 즉, 액세스 로그와 에러 로그가 제공될 수 있다.

액세스 로그에서는, 클라이언트가 변종을 전환하거나, 시크(seeking)하거나, 서버 IP 주소가 변할 때마다, 새로운 로그 엔트리(라인)가 생성될 수 있다. 마지막 라인은 현재의 변종에 대한 통계를 포함할 수 있다. 이하의 필드들이 액세스 로그(Access log)에 제공될 수 있다:

sc-count # 이 변종을 재생하는 동안 다운로드된 세그먼트의 개수, <integer>

date # 이 변종의 재생이 시작된 날짜, <date>

time # 이 변종의 재생이 시작된 시간(UTC), <time>

uri # 재생목록 파일의 URI, <uri>

s-ip # 미디어를 제공하는 서버의 IP 주소, <address>

cs-guid # 단일 재생 세션에 관한 모든 다운로드들에 의해 공유되는 (HTTP GET 요청의 일부로서 공급되는) GUID, <text>

c-start-time # 재생이 시작된 재생목록으로의 오프셋, <fixed> # 초

c-duration-downloaded # 다운로드된 미디어 지속기간, <fixed> # 초

c-duration-watched # 시청된 미디어 지속기간, <fixed> # 초

c-stalls # 리-버퍼링을 요구하는, 정체된 클라이언트 재생의 횟수, <integer>

c-frames-dropped # 재생 동안에 누락된 비디오 프레임수, <integer>

bytes # 전송된 바이트수, <integer>

c-observed-bitrate # 다운로딩 동안의 관찰된 대역폭, <fixed> 비트/초

sc-indicated-bitrate # 스트림을 재생하는데 요구되는 대역폭, <fixed> 비트/초

초기 재생 레이턴시에 관심있는 클라이언트들은 재생이 개시되었던 날의 시간을 독립적으로 보고할 수 있다. 이것은 기동 지속기간(startup duration)을 계산하기 위해 제1 변종의 날짜/시간과 조합하여 이용될 수 있다. 로그 서버 리디렉트(Log server redirects)도 역시 실시예에서 포함될 수 있다. 에러 로그에서, 네트워크 에러를 만날 때마다 새로운 로그 엔트리(라인)가 생성될 수 있다. 이하의 필드들이 에러 로그(Error logs)에서 제공될 수 있다:

date # 에러가 발생한 날짜, <date>

time # 에러가 발생한 시간(UTC), <time>

uri # 실패 액세스의 URI, <uri>

s-ip # URI에서 호스트를 찾아냄으로써 얻어지는 IP 주소, <address>. 선택사항.

cs-guid # A GUID (액세스 로그에서와 동일한 cs-guid)

status # 에러 상태 코드, <integer>.

comment # 상태 코드와 함께 반환된 코멘트, <text>. 선택사항.

도 8은 전자 시스템의 한 실시예의 블록도이다. 도 8에 도시된 전자 시스템은, 예를 들어, 데스크탑 컴퓨터 시스템, 랩탑 컴퓨터 시스템, 셀룰러 전화, 셀룰러-가능형 PDA를 포함한 PDA(personal digital assistant), 셋탑 박스, 오락 시스템 또는 기타의 전자 제품을 포함한 (유선 또는 무선 중 어느 하나) 다양한 전자 시스템을 나타내기 위한 것이다. 대안적 전자 시스템은 더 많거나, 더 적거나 및/또는 상이한 컴포넌트들을 포함할 수 있다. 도 8의 전자 시스템은 클라이언트 장치 및/또는 서버 장치를 제공하는데 이용될 수 있다.

전자 시스템(800)은, 정보를 전달하기 위한 버스(805) 또는 기타의 통신 장치, 및 버스(805)에 결합되어 정보를 처리할 수 있는 프로세서(810)를 포함한다. 전자 시스템(800)이 단일의 프로세서를 갖는 것으로 도시되어 있지만, 전자 시스템(800)은 복수의 프로세서 및/또는 코프로세서를 포함할 수도 있다. 전자 시스템(800)은 버스(805)에 결합된 랜덤 액세스 메모리(RAM) 또는 기타의 동적 저장 장치(820)를 포함할 수 있고, 프로세서(810)에 의해 실행될 수 있는 명령어와 정보를 저장할 수 있다. 메인 메모리(820)는 또한, 프로세서(810)에 의한 명령어의 실행 동안의 임시 변수들 또는 기타의 중간 정보를 저장하는데 이용될 수도 있다.

전자 시스템(800)은 또한, 버스(805)에 결합되어 프로세서(810)를 위한 정적인 정보와 명령어를 저장할 수 있는 판독 전용 메모리(ROM) 및/또는 기타의 정적 저장 장치(830)를 포함할 수 있다. 데이터 저장 장치(840)는 정보와 명령어를 저장하기 위해 버스(805)에 결합될 수 있다. 플래시 메모리 또는 자기 디스크 또는 광 디스크와 같은 데이터 저장 장치(840) 및 대응하는 드라이브가 전자 시스템(800)에 결합될 수 있다.

전자 시스템(800)은 또한 버스(805)를 통해, 음극선관(CRT) 또는 액정 디스플레이(LCD)와 같은 디스플레이 장치(850)에 결합되어 사용자에게 정보를 디스플레이할 수 있다. 전자 시스템(800)은 또한, 버스(805)에 결합될 수 있는 영숫자 및 기타의 키를 포함하는 영숫자 입력 장치(860)를 포함하여 정보와 명령 선택을 프로세서(810)에 전달할 수 있다. 또 다른 타입의 사용자 입력 장치는, 방향 정보와 명령 선택을 프로세서(810)에 전달하여 디스플레이(850) 상에서의 커서의 움직임을 제어하는 터치패드, 마우스, 트랙볼, 또는 커서 방향키와 같은 커서 제어(870)이다.

전자 시스템(800)은, 근거리 통신망과 같은 네트워크로의 액세스를 제공하는 하나 이상의 네트워크 인터페이스(들)(880)를 더 포함할 수 있다. 네트워크 인터페이스(들)(880)는, 예를 들어, 하나 이상의 안테나(들)를 나타낼 수 있는, 안테나(885)를 갖는 무선 네트워크 인터페이스를 포함할 수 있다. 전자 시스템(800)은, WiFi, Bluetooth, 및 셀룰러 전화 인터페이스의 조합과 같은 복수의 무선 네트워크 인터페이스를 포함할 수 있다. 네트워크 인터페이스(들)(880)는 또한, 예를 들어, 이더넷 케이블, 동축 케이블, 광 섬유 케이블, 직렬 케이블, 또는 병렬 케이블일 수도 있는 네트워크 케이블(887)을 통해 원격 장치와 통신하는, 예를 들어, 유선 네트워크 인터페이스를 포함할 수 있다.

한 실시예에서, 네트워크 인터페이스(들)(880)는, 예를 들어, IEEE 802.11b 및/또는 IEEE 802.11g 표준을 따름으로써 근거리 통신망으로의 액세스를 제공할 수 있고, 및/또는 무선 네트워크 인터페이스는, 예를 들어, Bluetooth 표준을 따름으로써 개인 영역 네트워크로의 액세스를 제공할 수 있다. 기타의 무선 네트워크 인터페이스 및/또는 프로토콜도 역시 지원될 수 있다.

무선 LAN 표준을 통한 통신에 추가하여, 또는 그 대신에, 네트워크 인터페이스(들)(880)는, 예를 들어, TDMA(Time Division Multiple Access) 프로토콜, GSM(Global System for Mobile Communications) 프로토콜, CDMA(Code Division Multiple Access) 프로토콜, 및/또는 기타 임의 타입의 무선 통신 프로토콜을 이용하여 무선 통신을 제공할 수 있다.

일부 실시예서는 하나 이상의 API(Application Programming Interface)가 이용될 수도 있다. API는, 프로그램 코드 컴포넌트 또는 하드웨어 컴포넌트(이하에서는 "API 구현 컴포넌트)에 의해 구현되는 인터페이스로서, 상이한 프로그램 코드 컴포넌트 또는 하드웨어 컴포넌트(이하에서는 "API 호출 컴포넌트")가, API 구현 컴포넌트에 의해 제공되는 하나 이상의 함수, 메소드, 프로시져, 데이터 구조, 클래스, 및/또는 기타의 서비스에 액세스하여 이용하는 것을 허용하는 인터페이스이다. API는 API 호출 컴포넌트와 API 구현 컴포넌트 사이에서 전달되는 하나 이상의 파라미터를 정의할 수 있다.

API는, (제3자 개발자일 수도 있는) API 호출 컴포넌트의 개발자가 API 구현 컴포넌트에 의해 제공된, 명시된 특징을 레버리지하는 것을 허용한다. 하나의 API 호출 컴포넌트가 있거나, 하나보다 많은 이러한 컴포넌트가 있을 수도 있다. API는, 애플리케이션으로부터의 서비스들에 대한 요청을 지원하기 위해 컴퓨터 시스템이나 프로그램 라이브러리가 제공하는 소스 코드 인터페이스일 수 있다. 운영 체제(OS)는 OS에서 실행중인 애플리케이션들이 이들 API들 중 하나 이상을 호출하는 것을 허용하기 위해 복수의 API를 가질 수 있고, (프로그램 라이브러리와 같은) 서비스는 그 서비스를 이용하는 애플리케이션이 이들 API들 중 하나 이상을 호출하는 것을 허용하기 위해 복수의 API를 가질 수 있다. API는 애플리케이션이 구축될 때 인터프리트되거나 컴파일될 수 있는 프로그래밍 언어의 관점에서 명시될 수 있다.

일부 실시예들에서, API 구현 컴포넌트는 하나 보다 많은 API를 제공할 수도 있고, 각각의 API는 API 구현 컴포넌트에 의해 구현되는 기능의 상이한 양태에 액세스하는 상이한 양태의 또는 상이한 양태를 갖는 상이한 뷰를 제공한다. 예를 들어, API 구현 컴포넌트의 한 API는 제1 세트의 함수를 제공할 수 있고, 제3자 개발자들에게 노출될 수 있으며, API 구현 컴포넌트의 또 다른 API는 은닉될 수 있고(노출되지 않음), 제1 세트의 함수들의 서브셋을 제공하며, 제1 세트의 함수들에 있지 않는 테스팅이나 디버깅 함수와 같은 또 다른 세트의 함수를 제공한다. 다른 실시예들에서, API 구현 컴포넌트는 그 자신이 기저 API를 통해 하나 이상의 다른 컴포넌트들을 호출할 수도 있으므로, API 호출 컴포넌트 및 API 구현 컴포넌트 양쪽 모두가 될 수 있다.

API는, API 구현 컴포넌트의 명시된 특징에 액세스하여 이용할 때 API 호출 컴포넌트가 이용하는 언어와 파라미터를 정의한다. 예를 들어, API 호출 컴포넌트는, API에 의해 노출된 (예를 들어 함수나 메소드 호출에 의해 구현되는) 하나 이상의 API 호출이나 기동을 통해 API 구현 컴포넌트의 명시된 특징에 액세스하고, API 호출이나 기동을 통해 파라미터를 이용하여 데이터와 제어 정보를 전달한다. API 구현 컴포넌트는, API 호출 컴포넌트로부터의 API 호출에 응답하여 API를 통해 값을 반환할 수도 있다. API가 API 호출의 구문론(syntax)과 결과(예를 들어, API 호출을 기동하는 방법과 API 호출이 무엇을 하는지)를 정의하지만, API는, API 호출이 API 호출에 의해 명시된 함수를 어떻게 달성하는지를 드러내지 않을 수도 있다. 호출측(API 호출 컴포넌트)과 API 구현 컴포넌트 사이의 하나 이상의 애플리케이션 프로그래밍 인터페이스를 통해 다양한 API 호출이 전달된다. API 호출을 전달하는 것은, 함수 호출이나 메시지를 발행, 개시, 기동, 호출, 수신, 반환, 또는 이에 응답하는 것을 포함할 수도 있는데; 즉, 전달하는 것은 API 호출 컴포넌트나 API 구현 컴포넌트 중 어느 하나에 의한 행위를 기술할 수 있다. API의 함수 호출이나 기타의 기동은, 파라미터 목록이나 기타의 구조를 통해 하나 이상의 파라미터를 전달 또는 수신할 수도 있다. 파라미터는, 상수, 키, 데이터 구조, 객체, 객체 클래스, 변수, 데이터 타입, 포인터, 어레이, 목록, 또는 API를 통해 전달되는 데이터나 기타의 항목을 참조하는 함수나 메소드나 기타의 방식에 대한 포인터일 수 있다.

또한, 데이터 타입이나 클래스는, API에 의해 제공되고 API 구현 컴포넌트에 의해 구현될 수도 있다. 따라서, API 호출 컴포넌트는 변수를 선언하고, 포인터를 이용하고, API에서 제공된 정의를 이용함으로써 이러한 타입이나 클래스의 상수값들을 이용하거나 인스턴스화(instantiate)할 수도 있다.

일반적으로, API는, API 구현 컴포넌트에 의해 제공된 서비스나 데이터에 액세스하거나 API 구현 컴포넌트에 의해 제공되는 동작이나 계산의 수행을 개시하기 위해 이용될 수 있다. 예로서, API 구현 컴포넌트 및 API 호출 컴포넌트 각각은, 운영 체제, 라이브러리, 장치 드라이버, API, 애플리케이션 프로그램, 또는 기타의 모듈 중 임의의 것일 수도 있다(API 구현 컴포넌트 및 API 호출 컴포넌트는 서로 동일하거나 상이한 타입의 모듈일 수도 있다는 점을 이해하여야 한다). API 구현 컴포넌트는 일부 경우에는 적어도 부분적으로 펌웨어, 마이크로코드, 또는 기타의 하드웨어 로직으로 구현될 수도 있다. 일부 실시예들에서, API는, 클라이언트 프로그램이 소프트웨어 개발 키트(SDK) 라이브러리에 의해 제공되는 서비스들을 이용하는 것을 허용할 수도 있다. 다른 실시예들에서, 애플리케이션 또는 기타의 클라이언트 프로그램은 애플리케이션 프레임워크에 의해 제공되는 API를 이용할 수도 있다. 이들 실시예들에서, 애플리케이션 또는 클라이언트 프로그램은, SDK에 의해 제공되고 API에 의해 제공되는 함수나 메소드에 대한 호출을 포함하거나, SDK에서 정의되고 API에 의해 제공되는 데이터 타입이나 객체를 이용할 수도 있다. 애플리케이션 프레임워크는 이들 실시예들에서 프레임워크에 의해 정의된 다양한 이벤트들에 응답하는 프로그램에 대한 메인 이벤트 루프(main event loop)를 제공한다. API는 애플리케이션이 애플리케이션 프레임워크를 이용하여 이벤트와 이벤트에 대한 응답을 명시하는 것을 허용한다. 일부 구현에서, API 호출은, 입력 능력 및 상태, 출력 능력 및 상태, 처리 능력, 전력 상태, 스토리지 용량 및 상태, 통신 능력 등과 같은 양태들에 관련된 것을 포함한 하드웨어 장치의 능력이나 상태를 애플리케이션에 보고할 수 있으며, API는 부분적으로, 펌웨어, 마이크로코드, 또는 부분적으로 하드웨어 컴포넌트에서 실행되는 기타의 하위 레벨 로직에 의해 구현될 수도 있다.

API 호출 컴포넌트는, 로컬 컴포넌트(즉, API 구현 컴포넌트와 동일한 데이터 처리 시스템 상)이거나, 네트워크를 거쳐 API를 통하여 API 구현 컴포넌트와 통신하는 (즉, API 구현 컴포넌트와 상이한 데이터 처리 시스템 상의) 원격 컴포넌트일 수도 있다. API 구현 컴포넌트는 API 호출 컴포넌트로서 동작할 수도 있고(즉, 상이한 API 구현 컴포넌트에 의해 노출된 API에 대한 API 호출을 행할 수 있다), API 호출 컴포넌트는 상이한 API 호출 컴포넌트에 노출되는 API를 구현함으로써 API 구현 컴포넌트로서 동작할 수도 있다는 점을 이해하여야 한다.

API는 상이한 프로그래밍 언어로 씌어진 복수의 API 호출 컴포넌트들이 API 구현 컴포넌트와 통신하는 것을 허용할 수도 있지만(따라서, API는 API 호출 컴포넌트와 API 구현 컴포넌트 사이에서 호출과 반환을 변환하기 위한 특징을 포함할 수도 있다); API는 특정의 프로그래밍 언어의 관점에서 구현될 수도 있다. API 호출 컴포넌트는, 한 실시예에서, OS 제공자로부터의 한 세트의 API, 플러그인 제공자로부터의 또 다른 세트의 API, 및 또 다른 제공자(예를 들어, 소프트웨어 라이브러리의 제공자)나 또 다른 세트의 API 생성자로부터의 또 다른 세트의 API와 같은 상이한 제공자들로부터의 API를 호출할 수 있다.

도 18은 본 발명의 일부 실시예들에서 이용될 수도 있는 예시적 API 아키텍쳐를 나타내는 블록도이다. 도 18에 도시된 바와 같이, API 아키텍쳐(1800)는, API(1820)를 구현하는 API-구현 컴포넌트(1810)(예를 들어, 운영 체제, 라이브러리, 장치 드라이버, API, 애플리케이션 프로그램, 소프트웨어나 기타의 모듈)를 포함한다. API(1820)는, API 호출 컴포넌트(1830)에 의해 이용될 수도 있는 하나 이상의 함수, 메소드, 클래스, 객체, 프로토콜, 데이터 구조, 포맷 및/또는 API 구현 컴포넌트의 다른 특징들을 명시한다. API(1820)는, API-구현 컴포넌트의 함수가 API 호출 컴포넌트로부터 파라미터들을 어떻게 수신하는지, 및 이 함수가 API-호출 컴포넌트에 결과를 어떻게 반환하는지를 명시하는 적어도 하나의 호출 규약(calling convention)을 명시할 수 있다. API 호출 컴포넌트(1830)(예를 들어, 운영 체제, 라이브러리, 장치 드라이버, API, 애플리케이션 프로그램, 소프트웨어 또는 기타의 모듈)는 API(1820)에 의해 명시되는 API-구현 컴포넌트(1810)의 특징들에 액세스하여 이용하기 위해 API(1820)를 통해 API 호출을 행한다. API-구현 컴포넌트(1810)는, API 호출에 응답하여 API(1820)를 통해 API-호출 컴포넌트(1830)에 값을 반환할 수도 있다.

API-구현 컴포넌트(1810)는, API(1820)를 통해 명시되지 않고 API 호출 컴포넌트(1830)에게 이용가능하지 않은 추가의 함수, 메소드, 클래스, 데이터 구조, 및/또는 기타의 특징들을 포함할 수도 있다는 것을 이해할 것이다. API-호출 컴포넌트(1830)는 API-구현 컴포넌트(1810)와 동일한 시스템에 있거나, API-구현 컴포넌트(1810)에 원격으로 위치하여 네트워크를 통해 API(1820)를 이용하여 액세스할 수도 있다는 것을 이해해야 한다. 도 18은 API(1820)와 상호작용하는 단일 API-호출 컴포넌트(1830)를 나타내지만, API-호출 컴포넌트(1830)와는 상이한 언어(또는 동일한 언어)로 씌어질 수도 있는 다른 API-호출 컴포넌트가 API(1820)를 이용할 수도 있다는 점을 이해하여야 한다.

API-구현 컴포넌트(1810), API(1820), 및 API-호출 컴포넌트(1830)는, 머신(예를 들어, 컴퓨터 또는 기타의 데이터 처리 시스템)에 의해 판독가능한 형태로 정보를 저장하기 위한 임의의 메커니즘을 포함하는 머신-판독가능한 비일시적 저장 매체에 저장될 수도 있다. 예를 들어, 머신-판독가능한 매체는, 자기 디스크, 광학 디스크, 랜덤 액세스 메모리; 판독 전용 메모리, 플래시 메모리 장치 등을 포함한다.

도 19("소프트웨어 스택")에서, 예시적 실시예, 애플리케이션은 수 개의 서비스 API를 이용하여 서비스 1 또는 2에 호출을 행하거나 수 개의 OS API를 이용하여 운영 체제(OS)에 호출을 행할 수 있다. 서비스 1 및 2는 수 개의 OS API를 이용하여 OS에 호출을 행할 수 있다.

서비스 2는 2개의 API를 가지며, 그 중 하나(서비스 2 API 1)는 애플리케이션 1로부터 호출을 수신하여 애플리케이션 1에 값들을 반환하고, 다른 하나(서비스 2 API 2)는 애플리케이션 2로부터 호출을 수신하여 애플리케이션 2에 값들을 반환한다는 점에 유의한다. (예를 들어, 소프트웨어 라이브러리일 수 있는) 서비스 1은 OS API 1에 호출을 행하고 이로부터 반환된 값들을 수신하며, (예를 들어, 소프트웨어 라이브러리일 수 있는) 서비스 2는 OS API 1 및 OS API 2 양쪽 모두에 호출을 행하고 이들로부터 반환된 값들을 수신한다. 애플리케이션 2는 OS API 2에 호출을 행하고 이로부터 반환된 값들을 수신한다.

본 명세서에서 "하나의 실시예" 또는 "실시예"라는 언급은, 그 실시예와 관련하여 기술되는 특정한 특징, 구조, 또는 특성이 본 발명의 적어도 하나의 실시예에 포함된다는 것을 의미한다. 명세서의 다양한 곳에서의 문구 "한 실시예에서"의 등장은 반드시 모두가 동일한 실시예를 지칭할 필요는 없다.

전술된 명세서에서, 본 발명이 그 특정한 실시예들을 참조하여 설명되었다. 그러나, 본 발명의 더 넓은 사상과 범위로부터 벗어나지 않고 다양한 수정 및 변경이 이루어질 수 있다는 것은 명백할 것이다. 따라서, 본 명세서 및 도면은 제한적 의미라기보다는 예시적인 의미로 간주되어야 한다.

부록

이하의 부록은 본 발명의 특정 실시예에 따른 프로토콜의 초안 명세(draft specification)이다. 이 부록 내의 소정 키워드(예를 들어, 반드시 ~해야 한다(MUST), ~해서는 안 된다(MUST NOT), ~한다(SHALL), ~하지 않는다(SHALL NOT) 등)의 사용은 이 특정 실시예에 적용되며, 본 개시에서 설명되는 다른 실시예들에는 적용되지 않는다는 점을 이해할 것이다.

HTTP 라이브 스트리밍

draft-pantos-http-live-streaming-06

요약

본 문서는 멀티미디어 데이터의 무제한 스트림을 전송하기 위한 프로토콜을 기술한다. 이것은 파일들의 데이터 포맷과 스트림의 서버(전송기)와 클라이언트(수신기)에 의해 취해지는 동작을 명시한다. 이것은 이 프로토콜의 버전 3을 기술한다.

목차

1. 머릿말

2. 요약

3. 재생목록 파일

3.1. 머릿말

3.2. 속성 목록

3.3. 새로운 태그들

3.3.1. EXT-X-TARGETDURATION

3.3.2. EXT-X-MEDIA-SEQUENCE

3.3.3. EXT-X-KEY

3.3.4. EXT-X-PROGRAM-DATE-TIME

3.3.5. EXT-X-ALLOW-CACHE

3.3.6. EXT-X-PLAYLIST-TYPE

3.3.7. EXT-X-ENDLIST

3.3.8. EXT-X-STREAM-INF

3.3.9. EXT-X-DISCONTINUITY

3.3.10. EXT-X-VERSION

4. 미디어 파일

5. 키 파일

5.1. 머릿말

5.2. AES-128에 대한 IV

6. 클라이언트/서버 동작

6.1. 머릿말

6.2. 서버 프로세스

6.2.1. 머릿말

6.2.2. 슬라이딩 윈도우 재생목록

6.2.3. 미디어 파일 암호화

6.2.4. 변종 스트림 제공

6.3. 클라이언트 프로세스

6.3.1. 머릿말

6.3.2. 재생목록 파일 로딩

6.3.3. 재생목록 파일 재생

6.3.4. 재생목록 파일 리로딩

6.3.5. 로딩할 다음 파일 결정

6.3.6. 암호화된 미디어 파일 암호해독

7. 프로토콜 버전 호환성

8. 예

8.1. 머릿말

8.2. 간단한 재생목록 파일

8.3 HTTP를 이용한 슬라이딩 윈도우 재생목록

8.4 암호화된 미디어 파일을 갖는 재생목록 파일

8.5. 변종 재생목록 파일

9. 보안 고려사항

10. 참고자료

10.1. 규범적 참고자료

10.2. 유익한 참고자료

1. 머릿말

본 문서는 멀티미디어 데이터의 무제한 스트림을 전송하기 위한 프로토콜을 기술한다. 이 프로토콜은 미디어 데이터의 암호화와 스트림의 대안적 버전(예를 들어, 비트레이트)의 제공을 지원한다. 미디어 데이터는 생성된 후에 곧 전송될 수 있어서, 준 실시간으로 재생되는 것을 허용한다. 데이터는 대개 HTTP[RFC2616]를 통해 운반된다.

HTTP와 같은 관련된 표준을 기술하는 외부 참고자료가 섹션 11에 열거되어 있다.

2. 요약

멀티미디어 프리젠테이션은, 미디어 URI들과 정보 태그들의 정렬된 목록인 재생목록 파일에 대한 URI [RFC3986]에 의해 명시된다. 각각의 미디어 URI는 단일의 연속적 스트림의 세그먼트에 해당하는 미디어 파일을 지칭한다.

스트림을 재생하기 위해, 클라이언트는 먼저 재생목록 파일을 얻은 다음, 재생목록 내의 각 미디어 파일을 재생한다. 클라이언트는 추가의 세그먼트를 발견하기 위해 본 문서에서 기술된 재생목록 파일을 리로딩한다.

본 문서에서 키워드 "반드시 ~해야 한다(MUST)", "~해서는 안 된다(MUST NOT)", "요구되는(REQUIRED)", "~한다(SHALL)", "~하지 않는다(SHALL NOT)", "~해야 한다(SHOULD)", "~하지 않아야 한다(SHOULD NOT)", "권고되는(RECOMMENDED)", "~할 수도 있다(MAY)" 및 "선택사항적(OPTIONAL)"은 RFC 2119[RFC2119]에 기술된 바와 같이 해석되어야 한다.

3. 재생목록 파일

3.1. 머릿말

재생목록은 반드시 확장된 M3U 재생목록 파일[M3U]이어야 한다. 본 문서는 추가의 태그들을 정의함으로써 M3U 파일 포맷을 확장시킨다.

M3U 재생목록은 개개 라인들로 구성된 텍스트 파일이다. 라인들은, 단일 LF 캐릭터, 또는 LF 캐릭터가 뒤따라오는 CR 캐릭터에 의해 종료된다. 각 라인은 URI, 블랭크이거나, 코멘트 캐릭터 '#'와 함께 시작한다. 블랭크 라인은 무시된다. 화이트 스페이스는, 화이트 스페이스가 명시적으로 지정되어 있는 요소들을 제외하고는, 존재해서는 안 된다.

URI 라인은 미디어 파일 또는 변종 재생목록 파일을 식별한다(섹션 3.3.8 참조).

URI는 상대적일 수도 있다. 상대적 URI는 반드시 상대적 URI를 포함하는 재생목록 파일의 URI와 대비하여 해결(resolve)되어야 한다.

코멘트 캐릭터 '#'와 함께 시작하는 라인은 코멘트이거나 태그이다. 태그는 #EXT로 시작한다. '#'로 시작하는 다른 모든 라인들은 코멘트이거나 무시되어야 한다.

재생목록 파일의 지속기간은 그 재생목록 파일 내의 미디어 파일들의 지속기간의 합이다.

명칭이 .m3u8로 끝나고 및/또는 HTTP 콘텐츠-타입 "application/vnd.apple.mpegurl"를 갖는 M3U 재생목록 파일은 UTF-8[RFC3629]로 인코딩된다. 명칭이 .m3u로 끝나고 및/또는 HTTP-콘텐츠 타입[RFC2616] "audio/mpegurl"을 갖는 파일들은 US-ASCII[US_ASCII]로 인코딩된다.

재생목록 파일은 반드시 .m3u8로 끝나는 명칭을 가져야 하고 및/또는 콘텐츠-타입 "application/vnd.apple.mpegurl"(HTTP를 통해 전송되는 경우)을 가져야 하며, 또는 반드시 .m3u로 끝나는 명칭을 가져야 하고 및/또는 HTTP 콘텐츠-타입 타입 "audio/mpegurl"을 가져야 한다(호환성을 위해).

확장된 M3U 파일 포맷은 2개의 태그: EXTM3U 및 EXTINF를 정의한다. 확장된 M3U 파일은, 반드시 #EXTM3U이어야 하는 그 첫 라인에 의해 기본 M3U 파일과 구분된다.

EXTINF는 후속하는 URI에 의해 식별되는 미디어 파일을 기술하는 레코드 마커(record marker)이다. 각 미디어 파일 URI는 반드시 EXTINF 태그가 선행되어야 한다. 그 포맷은:

#EXTINF: <duration>,<title>

"duration"은 미디어 파일의 지속기간을 초단위로 명시하는 정수 또는 부동 소수점 숫자이다. 정수 지속기간은 가장 가까운 정수로 라운딩되어야 한다. 재생목록 파일의 프로토콜 버전이 3보다 작다면 지속기간은 반드시 정수이어야 한다. 콤마 다음의 라인의 나머지는 미디어 파일의 타이틀로서, 미디어 세그먼트의 선택사항적인 인간이 판독할 수 있는 정보성 타이틀이다.

이 문서는 다음과 같은 새로운 태그들: EXT-X-TARGETDURATION, EXT-X-MEDIA-SEQUENCE, EXT-X-KEY, EXT-X-PROGRAM-DATE-TIME, EXT-X-ALLOW-CACHE, EXT-X-PLAYLIST-TYPE, EXT-X-STREAM-INF, EXT-X-ENDLIST, EXT-X-DISCONTINUITY, 및 EXT-X-VERSION을 정의한다.

3.2. 속성 목록(Attribute List)

소정의 확장된 M3U 태그는 속성 목록에 해당하는 값을 가진다. 속성 목록(Attribute List)은 화이트 스페이스를 갖지 않는 속성/값 쌍의 콤마-분리된 목록이다.

속성/값 쌍은 다음과 같은 구문론(syntax)을 가진다:

AttributeName=AttributeValue

AttributeName은 집합 [A-Z]로부터의 캐릭터를 포함하는 따옴표없는 스트링(unquoted string)이다.

AttributeValue는 다음 중 하나이다:

o 10진-정수: 정수를 10진수로 표현하는 집합 [0-9]로부터의 캐릭터들의 따옴표없는 스트링이다.

o 16진-정수: 접두사 0x 또는 0X가 붙고 정수를 16진수로 표현하는 집합 [0-9] 및 [A-F]로부터의 캐릭터들의 따옴표없는 스트링이다.

o 10진-부동 소수점: 부동 소수점 수를 10진수로 표현하는 '.' 및 집합 [0-9]로부터의 캐릭터들의 따옴표없는 스트링이다.

o 따옴표붙은-스트링: 한 쌍의 쌍따옴표(") 내부의 캐릭터들의 스트링. 스트링에서 허용되는 캐릭터들의 집합과 특별한 캐릭터를 확장(escaping)하기 위한 임의의 룰은 속성 정의에 의해 명시되지만, 임의의 쌍따옴표(") 캐릭터 및 임의의 캐리지-리턴 또는 라인피드는 항상 확장 코드(escape sequence)로 대체될 것이다.

o 열거형-스트링: 속성(Attribute)에 의해 명시적으로 정의되는 집합으로부터의 따옴표없는 캐릭터 스트링. 열거형-스트링은, 쌍따옴표("), 콤마(,), 또는 화이트 스페이스를 결코 포함하지 않을 것이다.

o 10진-해상도: 수평 및 수직 화소 크기(dimension)를 나타내는, "x" 캐릭터로 분리된 2개의 10진 정수.

주어진 AttributeName에 대한 AttributeValue의 타입은 속성(Attribute) 정의에 의해 명시된다.

주어진 AttributeName은 주어진 Attribute List에서 반드시 한 번보다 많이 나타나서는 안 된다.

인식되지 않은 AttributeName을 갖는 속성/값 쌍은 클라이언트에 의해 반드시 무시되어야 한다.

인식되지 않은 값을 포함하는 타입 열거형-스트링의 속성/값 쌍은 클라이언트에 의해 무시되어야 한다.

3.3. 새로운 태그들

3.3.1. EXT-X-TARGETDURATION

EXT-X-TARGETDURATION 태그는 최대 미디어 파일 지속기간을 명시한다.

재생목록 파일 내의 각 미디어 파일의 EXTINF 지속기간은 반드시 타겟 지속기간보다 작거나 같아야 한다. 이 태그는 재생목록 파일에서 반드시 한 번 나타나야 한다. 그 포맷은:

#EXT-X-TARGETDURATION:<s>

여기서, 초(s)는 타겟 지속기간을 초단위로 나타내는 정수이다.

3.3.2. EXT-X-MEDIA-SEQUENCE

재생목록 내의 각 미디어 파일 URI는 고유한 정수 시퀀스 번호를 가진다. URI의 시퀀스 번호는, 그에 선행한 URI의 시퀀스 번호 + 1과 같다. EXT-X-MEDIA-SEQUENCE 태그는 재생목록 파일에 나타나는 첫 번째 URI의 시퀀스 번호를 나타낸다. 그 포맷은:

#EXT-X-MEDIA-SEQUENCE:<number>

재생목록 파일은 하나보다 많은 EXT-X-MEDIA-SEQUENCE 태그를 포함해서는 안 된다. 재생목록 파일이 EXT-X-MEDIA-SEQUENCE 태그를 포함하지 않는다면, 재생목록 내의 첫 번째 URI의 시퀀스 번호는 0인 것으로 간주된다.

미디어 파일의 시퀀스 번호는 그 URI에서 나타날 것이 요구되지 않는다.

EXT-X-MEDIA-SEQUENCE 태그의 처리에 관한 정보를 위해 섹션 6.3.2 및 섹션 6.3.5를 참조한다.

3.3.3. EXT-X-KEY

미디어 파일은 암호화될 수도 있다. EXT-X-KEY 태그는 그에 후속하는 미디어 파일을 암호해독하는데 필요한 정보를 제공한다. 그 포맷은:

#EXT-X-KEY:<attribute-list>

다음과 같은 속성들이 정의된다:

METHOD 속성은 암호화 방법을 명시한다. 이것은 타입 열거형-스트링이다. 2개의 방법, 즉, NONE 및 AES-128이 정의된다.

암호화 방법 NONE은 미디어 파일이 암호화되지 않음을 의미한다. 암호화 방법이 NONE이면, URI 및 IV 속성은 존재해서는 안 된다.

암호화 방법 AES-128은 미디어 파일이 128-비트 키와 PKCS7 패딩[RFC5652]을 갖는 Advanced Encryption Standard [AES_128]을 이용하여 암호화됨을 의미한다. 암호화 방법이 AES-128이면, URI 속성은 반드시 존재해야 한다. IV 속성은 존재할 수도 있다; 섹션 5.2.을 참조.

URI 속성은 키를 얻는 방법을 명시한다. 그 값은 키에 대해 URI[RFC3986]를 포함하는 따옴표있는-스트링이다.

IV 속성은, 존재한다면, 키와 함께 이용될 초기화 벡터를 명시한다. 그 값은 16진-정수이다. IV 속성은 프로토콜 버전 2에서 등장했다.

새로운 EXT-X-KEY는 임의의 종래의 EXT-X-KEY를 대체한다.

재생목록 파일이 EXT-X-KEY 태그를 포함하지 않으면, 미디어 파일은 암호화되지 않는다.

키 파일의 포맷에 대해서는 섹션 5를 참조하고, 미디어 파일 암호화에 관한 추가 정보를 위해서는 섹션 5.2 및 섹션 6.2.3 및 섹션 6.3.6을 참조한다.

3.3.4. EXT-X-PROGRAM-DATE-TIME

EXT-X-PROGRAM-DATE-TIME 태그는 다음 미디어 파일의 시작을 절대 날짜 및/또는 시간과 연관시킨다. 날짜/시간 표현은 ISO/IEC 8601:2004 [ISO_8601]이고 타임 존(time zone)을 나타내어야 한다. 예를 들어:

#EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ>

EXT-X-PROGRAM-DATE-TIME 태그에 관한 더 많은 정보를 위해 섹션 6.2.1 및 섹션 6.3.3을 참조한다.

3.3.5. EXT-X-ALLOW-CACHE

EXT-X-ALLOW-CACHE 태그는 클라이언트가 나중의 다시보기를 위해 다운로딩된 미디어 파일을 캐싱할 수도 있는지 또는 캐쉬해서는 안 되는지를 나타낸다. 이것은 재생목록 파일 내의 임의의 위치에 발생할 수도 있는데; 이것은 한 번보다 많이 발생해서는 안 된다. EXT-X-ALLOW-CACHE 태그는 재생목록 내의 모든 세그먼트에 적용된다. 그 포맷은:

#EXT-X-ALLOW-CACHE: <YES|NO>

EXT-X-ALLOW-CACHE 태그에 관한 더 많은 정보를 위해 섹션 6.3.3을 참조한다.

3.3.6. EXT-X-PLAYLIST-TYPE

EXT-X-PLAYLIST-TYPE 태그는 재생목록 파일에 대한 이변성 정보(mutability information)를 제공한다. 이것은 선택사항이다. 그 포맷은:

#EXT-X-PLAYLIST-TYPE:<EVENT|VOD>

섹션 6.2.1은 EXT-X-PLAYLIST-TYPE 태그의 함축성(implication)을 정의한다.

3.3.7. EXT-X-ENDLIST

EXT-X-ENDLIST 태그는 재생목록 파일에 더 이상의 미디어 파일이 추가되지 않을 것임을 나타낸다. 이것은 재생목록 파일 내의 임의의 위치에 발생할 수도 있으며; 이것은 한 번보다 많이 발생해서는 안 된다. 그 포맷은:

#EXT-X-ENDLIST

3.3.8. EXT-X-STREAM-INF

EXT-X-STREAM-INF 태그는, 재생목록 파일 내의 다음 URI가 또 다른 재생목록 파일을 식별한다는 것을 나타낸다. 그 포맷은:

#EXT-X-STREAM-INF:<attribute-list><URI>

다음과 같은 속성들이 정의된다:

대역폭(BANDWIDTH)

값은 초당 비트들의 10진-정수이다.

이것은, 재생목록에서 나타나거나 나타날, 컨테이너 오버헤드를 포함하도록 계산된, 반드시 각 미디어 파일의 전체 비트레이트의 상한이어야 한다.

모든 EXT-X-STREAM-INF 태그는 반드시 대역폭(BANDWIDTH) 속성을 포함해야 한다.

프로그램-ID(PROGRAM-ID)

값은 재생목록 파일의 범위 내에서의 특정한 프리젠테이션을 고유하게 식별하는 10진-정수이다.

재생목록 파일은, 동일한 프리젠테이션의 상이한 인코딩들을 식별하기 위해 동일한 PROGRAM-ID를 갖는 복수의 EXT-X-STREAM-INF 태그를 포함할 수도 있다. 이들 변종 재생목록은 추가의 EXT-X-STREAM-INF 태그를 포함할 수도 있다.

코덱(CODECS)

값은 콤마-분리된 포맷들의 목록을 포함하는 따옴표있는-스트링이며, 여기서 각 포맷은 재생목록 파일 내의 미디어 파일에 존재하는 미디어 샘플 타입을 명시한다. 유효한 포맷 식별자들은 RFC 4281[RFC4281]에 의해 정의된 ISO 파일 포맷 명칭 공간(ISO File Format Name Space) 내의 식별자들이다.

모든 EXT-X-STREAM-INF 태그는 CODECS 속성을 포함해야 한다.

해상도(RESOLUTION)

값은 스트림 내의 비디오의 근사적인 인코딩된 수평 및 수직 해상도를 기술하는 10진-해상도이다.

3.3.9. EXT-X-DISCONTINUITY

EXT-X-DISCONTINUITY 태그는, 그에 후속하는 미디어 파일과 그 선행하는 미디어 파일 사이의 인코딩 불연속성을 나타낸다. 변할 수도 있는 특성 집합은:

o 파일 포맷

o 트랙의 개수 및 타입

o 인코딩 파라미터

o 인코딩 시퀀스

o 타임스탬프 시퀀스

그 포맷은:

#EXT-X-DISCONTINUITY

EXT-X-DISCONTINUITY 태그에 관한 더 많은 정보를 위해 섹션 4, 섹션 6.2.1 및 섹션 6.3.3을 참조한다.

3.3.10. EXT-X-VERSION

EXT-X-VERSION 태그는 재생목록 파일의 호환성 버전을 나타낸다. 재생목록 파일, 그 연관된 미디어, 및 그 서버는, 태그 값에 의해 표시된 프로토콜 버전을 기술하는 이 문서의 가장 최신 버전의 모든 조항을 반드시 준수해야 한다.

그 포맷은:

#EXT-X-VERSION:<n>

여기서, n은 프로토콜 버전을 나타내는 정수이다.

재생목록 파일은 하나보다 많은 EXT-X-VERSION 태그를 포함해서는 안 된다. EXT-X-VERSION 태그를 포함하지 않는 재생목록 파일은 이 프로토콜의 버전 1을 반드시 준수해야 한다.

4. 미디어 파일

재생목록 파일 내의 각 미디어 파일 URI는 전체 프리젠테이션의 세그먼트에 해당하는 미디어 파일을 반드시 식별해야 한다. 각 미디어 파일은 반드시 MPEG-2 트랜스포트 스트림(Transport Stream)으로서 또는 MPEG-2 오디오 엘리멘터리 스트림[ISO_13818]으로서 포맷되어야 한다.

트랜스포트 스트림 파일은 반드시 단일의 MPEG-2 프로그램을 포함해야 한다. 각 파일의 시작에서는 프로그램 연관 테이블 및 프로그램 맵 테이블이 있어야 한다. 비디오를 포함하는 파일은 적어도 하나의 키 프레임과 비디오 디코더를 완전히 초기화하기에 충분한 정보를 가져야 한다.

재생목록 내의 미디어 파일은 반드시, 재생목록 파일에 지금까지 나타난 첫 번째 미디어 파일이거나 EXT-X-DISCONTINUITY 태그에 의해 프레픽스(prefix)되지 않는 한, 반드시 이전 시퀀스 번호를 갖는 미디어 파일의 끝에서 인코딩된 스트림의 연속이어야 한다.

클라이언트는 특정한 타입(예를 들어, 오디오 또는 비디오)의 복수의 트랙을 처리하도록 준비되어야 한다. 어떠한 다른 선호사항도 갖지 않는 클라이언트는 자신이 재생할 수 있는 가장 낮은 수치 PID를 갖는 것을 선택해야 한다.

클라이언트들은 그들이 인식하지 않는 트랜스포트 스트림 내부의 사설 스트림을 반드시 무시해야 한다.

미디어 파일 내부의 스트림 내의 및 복수의 미디어 파일들에 걸친 대응하는 스트림들 사이의 샘플들에 대한 인코딩 파라미터들은 일관적으로 유지되어야 한다. 그러나, 클라이언트들은 그들이 만나는 인코딩 변경을, 예를 들어 해상도 변경을 수용하도록 비디오 콘텐츠를 스케일링함으로써 처리할 수 있어야 한다.

5. 키 파일

5.1. 머릿말

URI 속성을 갖는 EXT-X-KEY 태그는 키 파일을 식별한다. 키 파일은, 재생목록 내의 후속하는 미디어 파일들을 암호해독하는데 반드시 이용되어야 하는 암호 키(cipher key)를 포함한다.

AES-128 암호화 방법은 16-옥테트 키들을 이용한다. 키 파일의 포맷은 단순히 2진 포맷의 16 옥테트들의 팩킹된 배열이다.

5.2. AES-128에 대한 IV

128-비트 AES는, 암호화 및 암호해독시에 동일한 16-옥테트 초기화 벡터(IV; initialization vector)가 공급될 것을 요구한다. 이 IV를 변동시키는 것은 암호의 길이를 증가시킨다.

EXT-X-KEY 태그가 IV 속성을 가진다면, 구현시에, 그 키로 암호화 또는 암호해독할 때 IV로서 속성값이 반드시 이용되어야 한다. 값은 반드시 128-비트 16진수로서 해석되어야 하고, 반드시 0x 또는 0X로 프레픽스되어야 한다.

EXT-X-KEY 태그가 IV 속성을 갖지 않는다면, 구현시에, 그 미디어 파일을 암호화 또는 암호해독할 때 IV로서 미디어 파일의 시퀀스 번호가 반드시 이용되어야 한다. 시퀀스 번호의 빅 엔디언(big-endian) 2진 표현은 16-옥테트 버퍼에 배치되고 제로로 (좌측 상에서) 패딩된다.

6. 클라이언트/서버 동작

6.1. 머릿말

이 섹션은 서버가 어떻게 재생목록과 미디어 파일을 생성하고 클라이언트가 어떻게 이들을 다운로드하고 재생해야 하는지를 기술한다.

6.2. 서버 프로세스

6.2.1. 머릿말

MPEG-2 스트림의 생성은, 본 문서의 범위 밖이며, 간단히 프리젠테이션을 포함하는 연속 스트림의 소스를 가정한다.

서버는 반드시 스트림을 개개의 미디어 파일들로 분할해야 하고 이들의 지속기간은 일정한 타겟 지속기간보다 작거나 같다. 서버는 개개의 미디어 파일들의 효과적인 디코드를 지원하는 포인트들에서, 예를 들어, 패킷 및 키 프레임 경계들에서, 스트림의 분할을 시도해야 한다.

서버는 그 클라이언트들이 파일을 얻도록 허용하는 각 미디어 파일에 대한 URI를 반드시 생성해야 한다.

서버는 재생목록 파일을 반드시 생성해야 한다. 재생목록 파일은 섹션 3에서 기술된 포맷을 반드시 준수해야 한다. 서버가 이용가능하게 하고자하는 각 미디어 파일에 대한 URI는 반드시 재생될 순서로 재생목록에 나타나야 한다. 전체 미디어 파일은 그 URI가 재생목록 파일에 있다면 클라이언트에게 반드시 이용가능해야 한다.

재생목록 파일은 반드시 EXT-X-TARGETDURATION 태그를 포함해야 한다. 그 값은 재생목록 파일에서 나타나거나 나타날 임의의 미디어 파일의 EXTINF 값보다 반드시 같거나 커야 한다. 그 값은 변해서는 안 된다. 전형적인 타겟 지속기간은 10초이다.

재생목록 파일은 스트림의 호환성 버전을 나타내는 하나의 EXT-X-VERSION 태그를 포함해야 한다. 그 값은 반드시, 서버, 재생목록 파일, 및 연관된 미디어 파일들 모두와 호환되는 가장 낮은 프로토콜 버전이어야 한다.

서버는 그 클라이언트들이 파일을 얻는 것을 허용하는 재생목록 파일에 대한 URI를 반드시 생성해야 한다.

재생목록 파일이 HTTP에 의해 배포된다면, 서버는 "gzip" 콘텐츠-인코딩을 이용하기 위한 클라이언트 요청을 지원해야 한다.

재생목록 파일에 대한 변경은 반드시 클라이언트의 관점에서 초미세단위로(atomically) 이루어져야 한다.

서버는 재생목록 파일을 변경해서는 안 되지만, 예외는:

재생목록에 라인을 추가하는 것(섹션 6.2.1).

미디어 파일들이 나타나는 순서대로 재생목록으로부터 미디어 파일 URI를, 이들 미디어 파일들에만 적용되는 임의의 태그와 함께 제거하는 것(섹션 6.2.2).

EXT-X-MEDIA-SEQUENCE 태그의 값을 변경하는 것(섹션 6.2.2).

EXT-X-STREAM-INF 태그를 추가 또는 제거하는 것(섹션 6.2.4). 클라이언트는 변종 재생목록 파일을 리로딩하는 것이 요구되지 않아서, 이들을 변경하는 것은 즉각적인 효과를 갖지 않을 수도 있다는 점에 주목한다.

재생목록에 EXT-X-ENDLIST 태그를 추가하는 것이다(섹션 6.2.1)

또한, 재생목록 파일은 EVENT 또는 VOD의 값을 갖는 EXT-X-PLAYLIST-TYPE 태그를 포함할 수도 있다. 태그가 존재하고 EVENT의 값을 가진다면, 서버는 (재생목록 파일에 라인이 첨부될 수는 있지만) 재생목록 파일의 임의의 부분을 변경 또는 삭제해서는 안 된다. 태그가 존재하고 VOD의 값을 가진다면, 재생목록 파일은 변경되어서는 안 된다.

재생목록 내의 모든 미디어 파일 URI는 반드시 미디어 파일의 지속기간을 나타내는 EXTINF 태그로 프레픽스되어야 한다.

서버는, 그 URI를 EXT-X-PROGRAM-DATE-TIME 태그로 프레픽스함으로써 절대 날짜 및 시간을 미디어 파일과 연관시킬 수도 있다. 날짜와 시간의 값은, 적절한 벽시간으로의 미디어의 타임라인의 유용한 맵핑을 제공하고, 이것은, 시크(seeking), 디스플레이, 또는 기타의 목적을 위한 기초로서 이용될 수 있다. 서버가 이 맵핑을 제공한다면, 이것은 재생목록 파일 내의 모든 EXT-X-DISCONTINUITY 태그 이후에 EXT-X-PROGRAM-DATE-TIME 태그를 두어야 한다.

재생목록이 프리젠테이션의 최종 미디어 파일을 포함한다면, 재생목록 파일은 EXT-X-ENDLIST 태그를 반드시 포함해야 한다.

재생목록이 EXT-X-ENDLIST 태그를 포함하지 않는다면, 서버는 반드시 적어도 하나의 새로운 미디어 파일 URI를 포함하는 재생목록 파일의 새로운 버전을 이용가능하게 해야 한다. 이것은 반드시 재생목록 파일의 이전 버전이 이용가능하게 되었던 시간에 대해 이용가능하게 되어야 한다: 그 시간 이후의 타겟 지속기간의 1/2보다 이르지 않고, 그 시간 이후의 타겟 지속기간의 1.5배보다 늦지 않게.

서버가 전체 프리젠테이션을 제거하기를 원한다면, 서버는 반드시 재생목록 파일이 클라이언트에 이용가능하지 않게 해야 한다. 이것은 제거시에 재생목록 파일 내의 모든 미디어 파일이 재생목록 파일의 적어도 지속기간 동안에 클라이언트에 이용가능하게 남아 있을 것을 보장해야 한다.

6.2.2. 슬라이딩 윈도우 재생목록

서버는 미디어 파일의 가용성을 재생목록에 가장 최근에 추가된 것들로 제한할 수도 있다. 이렇게 하기 위해 재생목록 파일은 항상 반드시 정확히 하나의 EXT-X-MEDIA-SEQUENCE 태그를 포함해야 한다. 그 값은 재생목록 파일로부터 제거되는 매 미디어 파일 URI마다 반드시 1씩 증가되어야 한다

미디어 파일 URI들은 반드시 그들이 추가되었던 순서로 재생목록 파일로부터 제거되어야 한다.

서버는 재생목록 파일의 지속기간 - 미디어 파일의 지속기간이 타겟 지속기간의 3배보다 작다면 재생목록 파일로부터 미디어 파일 URI를 제거해서는 안 된다.

서버가 재생목록으로부터 미디어 파일 URI를 제거할 때, 미디어 파일은, 미디어 파일의 지속기간 + 미디어 파일이 나타난 가장 긴 재생목록 파일의 지속기간과 동일한 기간 동안에 클라이언트에 이용가능하게 남아 있어야 한다.

서버가 미디어 파일을 HTTP를 통해 클라이언트에 전달한 후에 그 미디어 파일을 제거할 것을 계획한다면, 서버는 HTTP 응답이 계획된 생존 기간을 반영하는 만료 헤더를 포함한다는 것을 보장해야 한다.

6.2.3. 미디어 파일 암호화

미디어 파일이 암호화될 예정이라면, 서버는 허가된 클라이언트들이 암호해독 키를 포함하는 키 파일을 얻는 것을 허용하는 URI를 반드시 정의해야 한다. 키 파일은 섹션 5에 기술된 포맷을 반드시 따라야 한다.

서버는 키가 캐싱될 수도 있다는 것을 나타내기 위해 키 응답 내에 HTTP 만료 헤더를 설정할 수도 있다.

암호화 방법(METHOD)이 AES-128이면, AES-128 CBC 암호화가 개개의 미디어 파일에 적용된다. 전체 파일은 반드시 암호화되어야 한다. 암호 블록 체이닝은 미디어 파일들에 걸쳐 적용되어서는 안 된다. 암호화에 이용되는 IV는 반드시, 섹션 5.2.에서 기술된 바와 같이, 미디어 파일의 시퀀스 번호 또는 EXT-X-KEY 태그의 IV 속성의 값이어야 한다.

서버는, 재생목록 파일에서 그 URI 직전의 EXT-X-KEY 태그에 의해 명시된 방법 및 기타의 속성을 이용하여 재생목록 내의 모든 미디어 파일을 반드시 암호화해야 한다. METHOD가 NONE인 EXT-X-KEY 태그를 앞에 두고 있거나 임의의 EXT-X-KEY 태그를 앞에 두지 않는 미디어 파일은 암호화되어서는 안 된다.

서버는, 재생목록 파일이 그 키로 암호화된 미디어 파일에 대한 URI를 포함한다면 재생목록 파일로부터 EXT-X-KEY 태그를 제거해서는 안 된다.

6.2.4. 변종 스트림 제공

서버는 동일한 프리젠테이션의 상이한 인코딩들을 제공하기 위해 복수의 재생목록 파일을 제공할 수도 있다. 이러한 경우, 서버는 클라이언트가 인코딩들 사이에서 동적으로 전환하는 것을 허용하기 위해 각 변종 스트림을 열거하는 변종 재생목록 파일을 제공해야 한다.

변종 재생목록은 각 변종 스트림에 대해 EXT-X-STREAM-INF 태그를 반드시 포함해야 한다. 동일한 프리젠테이션에 대한 각각의 EXT-X-STREAM-INF 태그는 반드시 동일한 PROGRAM-ID 속성 값을 가져야 한다. 각각의 프리젠테이션에 대한 PROGRAM-ID 값은 변종 재생목록 내에서 반드시 고유해야 한다.

EXT-X-STREAM-INF 태그가 CODECS 속성을 포함한다면, 속성값은 재생목록 파일 내에 나타나거나 나타날 임의의 미디어 파일에 존재하는 [RFC4281]에 의해 정의된 모든 포맷을 반드시 포함해야 한다.

서버는 변종 스트림들을 생성할 때에 다음과 같은 제약을 반드시 만족해야 한다:

각각의 변종 스트림은 반드시 스트림 불연속성을 포함한 동일한 콘텐츠를 프리젠팅해야 한다.

각각의 변종 재생목록 파일은 반드시 동일한 타겟 지속기간을 가져야 한다.

하나의 변종 재생목록 파일에는 나타나지만 또 다른 변종 재생목록 파일에는 나타나지 않는 콘텐츠는 반드시 그 재생목록 파일의 시작부나 끝에 나타나야 하며 타겟 지속기간보다 길어서는 안 된다.

변종 스트림 내의 매칭 콘텐츠는 반드시 매칭 타임스탬프를 가져야 한다.

이것은 클라이언트가 스트림들을 동기화하는 것을 허용한다.

엘리멘터리 오디오 스트림 파일은, ID3 PRIV 태그[ID3]에 "com.apple.streaming.transportStreamTimestamp"의 소유자 식별자를 첨부함으로써 파일 내의 첫 샘플의 타임스탬프를 반드시 시그널링해야 한다. 2진 데이터는 반드시, 상위 31비트가 제로로 설정된, 빅-엔디언 8-옥테트 수치로서 표현된 33-비트 MPEG-2 프로그램 엘리멘터리 스트림 타임스탬프이어야 한다.

또한, 모든 변종 스트림은 동일한 인코딩된 오디오 비트스트림을 포함해야 한다. 이것은 클라이언트가 가청 글리칭(glitching) 없이 스트림들 사이에서 전환하는 것을 허용한다.

6.3. 클라이언트 프로세스

6.3.1. 머릿말

클라이언트가 재생목록 파일에 대한 URI를 얻는 방법은 본 문서의 범위 밖이며; 이것은 이미 이루어진 것으로 가정한다.

클라이언트는 URI로부터 재생목록 파일을 반드시 얻어야 한다. 이렇게 얻어진 재생목록 파일이 변종 재생목록이라면, 클라이언트는 그 변종 재생목록으로부터 재생목록 파일을 반드시 얻어야 한다.

이 문서는 클라이언트에 의한 변종 스트림의 처리를 명시하지는 않는다.

6.3.2. 재생목록 파일 로딩

재생목록 URI로부터 재생목록 파일이 로딩되거나 리로딩될 때마다:

클라이언트는, 재생목록 파일이 EXTM3U 태그로 시작하고 EXT-X-VERSION 태그가, 존재하는 경우, 클라이언트에 의해 지원되는 프로토콜 버전을 명시한다는 것을 반드시 보장해야 하고; 그렇지 않다면, 클라이언트는 재생목록의 이용을 시도해서는 안 된다.

클라이언트는 자신이 인식하지 못하는 임의의 태그와 속성을 무시해야 한다.

클라이언트는 섹션 6.3.5.에 기술된 바와 같이 로딩할 다음 미디어 파일을 반드시 결정해야 한다.

재생목록이 EXT-X-MEDIA-SEQUENCE 태그를 포함한다면, 클라이언트는 재생목록 내의 각각의 미디어 파일은 재생목록 파일이 로딩된 시간 + 그 재생목록 파일의 지속기간에서 이용불가능하게 될 것이라고 추정해야 한다. 재생목록 파일의 지속기간은 그 재생목록 파일 내의 미디어 파일들의 지속기간의 합계이다.

6.3.3. 재생목록 파일 재생

클라이언트는 재생이 개시될 때 재생목록으로부터 먼저 재생할 미디어 파일을 선택한다. EXT-X-ENDLIST 태그가 존재하지 않고 클라이언트가 미디어를 규칙적으로(즉, 공칭 재생 속도에서 재생목록 순서로) 재생하려 한다면, 클라이언트는 재생목록 파일의 끝으로부터 3개보다 작은 타겟 지속기간에서 시작하는 파일을 선택하지 않아야 한다. 이렇게 하는 것은 재생이 정체되게 할 수 있다.

규칙적인 재생을 달성하기 위해, 미디어 파일은 반드시 재생목록 파일에서 나타나는 순서대로 재생되어야 한다. 클라이언트는, 규칙적인 재생, 무작위 액세스, 및 트릭 모드를 포함한, 자신이 원하는 임의의 방식으로 가용 미디어를 프리젠팅할 수도 있다.

클라이언트는 EXT-X-DISCONTINUITY 태그가 선행한 미디어 파일을 재생하기 전에 그 파서(들) 및 디코더(들)을 리셋하도록 반드시 준비되어야 한다.

클라이언트는 중단되지 않는 재생을 요구받을 때 미디어 파일을 미리 로딩하는 것을 시도하여 레이턴시 및 처리량에서의 일시적 변동을 보상해야 한다.

재생목록 파일이 EXT-X-ALLOW-CACHE 태그를 포함하고 그 값이 NO이면, 클라이언트는 다운로드된 미디어 파일들이 재생된 후에 이들을 저장해서는 안 된다. 그렇지 않다면, 클라이언트는 나중의 다시보기를 위해 미확정 다운로드된 미디어 파일을 캐싱할 수도 있다.

클라이언트는 프로그램 제작 시간(program origination time)을 사용자에게 디스플레이하기 위해 EXT-X-PROGRAM-DATE-TIME 태그의 값을 이용할 수도 있다. 그 값이 타임 존(time zone) 정보를 포함한다면, 클라이언트는 이것을 고려하지만, 포함하지 않는다면 클라이언트는 제작 타임 존을 유추해서는 안 된다.

클라이언트는 EXT-X-PROGRAM-DATE-TIME 태그의 값의 정확성 또는 일관성에 의존해서는 안 된다.

6.3.4. 재생목록 파일 리로딩

클라이언트는, 재생목록 파일이 EXT-X-ENDLIST 태그를 포함하지 않는 한, 재생목록 파일을 반드시 주기적으로 리로딩해야 한다.

그러나, 클라이언트는 이 섹션에 의해 명시된 것보다 빈번하게 재생목록 파일의 리로딩을 시도해서는 안 된다.

클라이언트가 재생목록 파일을 처음으로 로딩하거나 재생목록 파일을 리로딩하고 재생목록 파일이 마지막으로 로딩된 이후에 변경되었음을 발견하면, 클라이언트는 다시 한 번 재생목록 파일의 리로딩을 시도하기 이전에 반드시 소정 기간 동안 대기해야 한다. 이 기간은 초기 최소 리로딩 지연(initial minimum reload delay)이라 불린다. 이것은 클라이언트가 재생목록 파일의 로딩을 시작한 시간으로부터 측정된다.

초기 최소 리로드 지연은 재생목록 내의 마지막 미디어 파일의 지속기간이다. 미디어 파일 지속기간은 EXTINF 태그에 의해 명시된다.

클라이언트가 재생목록 파일을 리로딩하고 이것이 변경되지 않았음을 발견하면, 클라이언트는 재시도 이전에 반드시 소정 기간 동안 대기해야 한다. 최소 지연은 타겟 지속기간의 배수이다. 이 배수는 첫 번째 시도의 경우 0.5이고, 두 번째의 경우는 1.5이고, 그 이후에는 3.0이다.

서버 부하를 줄이기 위하여, 클라이언트는 현재 재생 중이지 않은 변종 스트림들의 재생목록 파일을 리로딩하지 않아야 한다. 클라이언트가 상이한 변종으로의 재생 전환을 결정하면, 클라이언트는 구 변종의 재생목록의 리로딩을 중단하고 새로운 변종의 재생목록의 로딩을 개시한다. 이것은 대응하는 미디어의 근사 위치를 결정하기 위해 섹션 6.2.4의 제약과 EXTINF 지속기간을 이용할 수 있다. 일단 새로운 변종으로부터의 미디어가 로딩되고 나면, 미디어 파일 내의 타임스탬프는 구 및 신 타임라인을 정확하게 동기화하는데 이용될 수 있다.

6.3.5. 로딩할 다음 파일 결정

클라이언트는 재생목록 파일이 로딩되거나 리로딩될 때마다 로딩할 다음 미디어 파일을 결정하기 위해 재생목록 파일을 반드시 검사해야 한다.

로딩할 첫 번째 파일은, 섹션 6.3.3에 기술된 바와 같이, 반드시 클라이언트가 첫 번째로 재생하기로 선택한 파일이어야 한다.

재생될 첫 파일이 로딩되었고 재생목록 파일이 EXT-X-MEDIA-SEQUENCE 태그를 포함하지 않는다면, 클라이언트는 현재의 재생목록 파일이 원래 발견된 오프셋에서 마지막 로딩된 미디어 파일의 URI를 포함하는지를 반드시 확인해야 하고, 그렇지 않으면 재생을 중지한다. 로딩할 다음 미디어 파일은 반드시 재생목록 내의 마지막-로딩된 URI에 후속하는 첫 번째 미디어 파일 URI이어야 한다.

재생될 첫 번째 파일이 로딩되었고 재생목록 파일이 EXT-X-MEDIA-SEQUENCE 태그를 포함한다면, 로딩될 다음 미디어 파일은 로딩된 마지막 미디어 파일의 시퀀스 번호보다 큰 가장 낮은 시퀀스 번호를 갖는 것이 된다.

6.3.6. 암호화된 미디어 파일 암호해독

재생목록 파일이 키 파일 URI를 명시하는 EXT-X-KEY 태그를 포함한다면, 클라이언트는 반드시 그 키 파일을 얻고 그 내의 키를 이용하여 또 다른 EXT-X-KEY 태그를 만날 때까지 그 EXT-X-KEY 태그에 후속하는 모든 미디어 파일들을 암호해독해야 한다.

암호화 METHOD가 AES-128이면, AES-128 CBC 암호해독이 개개의 미디어 파일에 적용된다. 전체 파일은 반드시 암호해독되어야 한다. 암호 블록 체이닝은 미디어 파일들에 걸쳐 적용되어서는 안 된다. 암호해독에 이용되는 IV는 반드시, 섹션 5.2.에서 기술된 바와 같이, 미디어 파일의 시퀀스 번호 또는 EXT-X-KEY 태그의 IV 속성의 값이어야 한다.

암호화 METHOD가 NONE이면, 클라이언트는 반드시, EXT-X-KEY 태그에 후속하는 모든 미디어 파일들을, 또 다른 EXT-X-KEY 태그를 만날 때까지, 반드시 평문(암호화되지 않은 것)으로서 취급해야 한다.

7. 프로토콜 버전 호환성

클라이언트와 서버는 하기를 이용하기 위해 반드시 프로토콜 버전 2 이상을 구현해야 한다:

o EXT-X-KEY 태그의 IV 속성.

클라이언트와 서버는 하기를 이용하기 위해 반드시 프로토콜 버전 3 이상을 구현해야 한다:

o 부동 소숫점 EXTINF 지속기간 값

8. 예

8.1. 머릿말

이 섹션은 수 개의 예시적 재생목록 파일을 포함한다.

8.2. 간단한 재생목록 파일

8.3 HTTP를 이용한 슬라이딩 윈도우 재생목록

8.4 암호화된 미디어 파일을 갖는 재생목록 파일

8.5. 변종 재생목록 파일

9. 보안 고려사항

프로토콜은 일반적으로 데이터를 전송하기 위해 HTTP를 이용하므로, 대부분 동일한 보안 고려사항이 적용된다. RFC 2616 [RFC2616]의 섹션 15를 참조한다.

미디어 파일 파서는 통상 "퍼징(fuzzing)" 공격을 받기 쉽다. 클라이언트는 비-호환 파일이 거부되도록 서버로부터 수신된 파일을 파싱할 때 유의해야 한다.

재생목록 파일은, 클라이언트가 임의의 엔티티들의 네트워크 요청을 행하기 위해 이용할 URI를 포함한다. 클라이언트는 버퍼 오버플로우를 방지하기 위해 응답을 범위-검사해야 한다. RFC 3986 [RFC3986]의 보안 고려사항 섹션을 역시 참조한다.

클라이언트는 서비스-거부 공격(denial-of-service attack)에 기여하는 것을 피하기 위해 URI에 의해 식별된 자원들을 천천히 로딩해야 한다.

HTTP 요청은 종종, 사설 사용자 데이터를 포함할 수도 있는 세션 상태("쿠키(cookies)")를 포함한다. 구현시에, RFC 2965 [RFC2965]에 의해 명시된 만료 룰과 쿠키 제약을 반드시 따라야 한다. RFC 2965 및 RFC 2964 [RFC2964]의 보안 고려사항 섹션을 역시 참조한다.

암호화 키들은 URI에 의해 명시된다. 이들 키들의 전달은, 보안 영역(secure realm) 또는 세션 쿠키와 연계하여 TLS[RFC5246] (이전에는 SSL)를 통한 HTTP와 같은 메커니즘에 의해 보안되어야 한다.

10. 참고자료

10.1. 규범적 참고자료

10.2. 유익한 참고자료

Claims (21)

1. 실행될 때, 데이터 처리 시스템으로 하여금 방법을 수행하게 하는 실행가능한 명령어를 저장한 머신 판독가능하고 비-일시적인 유형의 저장 매체(machine readable, tangible, non-transitory storage medium)로서, 상기 방법은,
   클라이언트 장치에 의해 재생목록 파일을 요청하는 단계;
   상기 요청에 응답하여 상기 클라이언트 장치에서, 서버 장치로부터의 상기 재생목록 파일을 수신하는 단계 - 상기 재생목록 파일은 복수의 미디어 파일을 나타내는 URI(Universal Resource Indicator)와 상기 복수의 미디어 파일의 재생에 관련된 파라미터를 갖는 복수의 태그를 가짐 - ;
   상기 재생목록 파일이 재생목록의 타입을 나타내는 타입 파라미터(type parameter)를 갖는지를 판정하는 단계; 및
   상기 재생목록 파일이 상기 타입 파라미터를 가질 때 상기 타입 파라미터에 따라 상기 재생목록을 처리하는 단계
   를 포함하는, 머신 판독가능하고 비-일시적인 유형의 저장 매체.
2. 제1항에 있어서, 상기 타입 파라미터는 (a) VOD(Video on Demand); (b) 라이브(live); 또는 (c) 이벤트(event) 중 하나이고, VOD 재생목록은 변경되지 않으며, 이벤트는 이벤트 재생목록에 대한 지정되고 고정된 시작 시간을 가지고, 상기 재생목록은 비-스트리밍 전송 프로토콜을 이용하여 네트워크를 통해 수신되며, 상기 방법은,
   상기 재생목록 파일에 의해 표시된 순서대로 상기 미디어 파일들 중 하나 이상을 요청하는 단계; 및
   상기 비-스트리밍 전송 프로토콜을 이용하여 상기 네트워크를 통해 상기 하나 이상의 요청된 미디어 파일을 수신하는 단계
   를 더 포함하는, 머신 판독가능하고 비-일시적인 유형의 저장 매체.
3. 제2항에 있어서, 상기 타입 파라미터가 VOD일 때, 상기 클라이언트 장치는 상기 재생목록을 업데이트하지 않도록 구성되고, 상기 클라이언트 장치는 상기 재생목록이 참조하는 콘텐츠에 대한 변종 재생목록으로 전환할 시에 미래의 이용을 위해 상기 재생목록을 세이브(save)하도록 구성된, 머신 판독가능하고 비-일시적인 유형의 저장 매체.
4. 제3항에 있어서, 상기 타입 파라미터가 VOD일 때, 상기 클라이언트 장치는 상기 재생목록에 ENDLIST 태그가 없을 시에 에러 신호를 생성하도록 구성된, 머신 판독가능하고 비-일시적인 유형의 저장 매체.
5. 제2항에 있어서, 상기 타입 파라미터가 라이브일 때, 상기 클라이언트 장치는 업데이트된 재생목록을 요청하도록 구성된, 머신 판독가능하고 비-일시적인 유형의 저장 매체.
6. 제2항에 있어서, 상기 타입 파라미터가 이벤트일 때, 상기 클라이언트 장치는 (a) 업데이트된 재생목록의 일부만을 로딩하거나 (b) 상기 업데이트된 재생목록의 일부만을 파싱(parsing)하도록 구성된, 머신 판독가능하고 비-일시적인 유형의 저장 매체.
7. 제2항에 있어서, 상기 방법은, 상기 재생목록 파일에 의해 표시된 순서대로 상기 클라이언트 장치로 상기 미디어 파일들을 재생함으로써 콘텐츠의 스트림을 나타내는 오디오 또는 비디오 또는 오디오/비디오 출력을 생성하는 단계를 더 포함하고,
   상기 비-스트리밍 전송 프로토콜은 HTTP(hypertext transfer protocol) 호환 프로토콜을 포함하는, 머신 판독가능하고 비-일시적인 유형의 저장 매체.
8. 제1항에 있어서, 상기 방법은,
   상기 미디어 파일의 데이터 액세스 또는 상기 미디어 파일의 수신시에 발생하는 네트워크 에러에 관련된 통계를 적어도 하나의 로그(log)에 저장하는 단계; 및
   상기 통계를 얻기 위해 API(Application Program Interface)를 통해 요청을 수신하는 단계
   를 더 포함하는, 머신 판독가능하고 비-일시적인 유형의 저장 매체.
9. 데이터 처리 시스템에 의해 수행되는 머신 구현된 방법으로서,
   클라이언트 장치에 의해 재생목록 파일을 요청하는 단계;
   상기 요청에 응답하여 상기 클라이언트 장치에서, 서버 장치로부터의 상기 재생목록 파일을 수신하는 단계 - 상기 재생목록 파일은 복수의 미디어 파일을 나타내는 URI와 상기 복수의 미디어 파일의 재생에 관련된 파라미터를 갖는 복수의 태그를 가짐 - ;
   상기 재생목록 파일이 재생목록의 타입을 나타내는 타입 파라미터를 갖는지를 판정하는 단계; 및
   상기 재생목록 파일이 상기 타입 파라미터를 가질 때 상기 타입 파라미터에 따라 상기 재생목록을 처리하는 단계
   를 포함하는, 머신 구현된 방법.
10. 제9항에 있어서, 상기 타입 파라미터는 (a) VOD; (b) 라이브; 또는 (c) 이벤트 중 하나이고, VOD 재생목록은 변경되지 않으며, 이벤트는 이벤트 재생목록에 대한 지정되고 고정된 시작 시간을 가지고, 상기 재생목록은 비-스트리밍 전송 프로토콜을 이용하여 네트워크를 통해 수신되며, 상기 방법은,
    상기 재생목록 파일에 의해 표시된 순서대로 상기 미디어 파일들 중 하나 이상을 요청하는 단계; 및
    상기 비-스트리밍 전송 프로토콜을 이용하여 상기 네트워크를 통해 상기 하나 이상의 요청된 미디어 파일을 수신하는 단계
    를 더 포함하는, 머신 구현된 방법.
11. 제10항에 있어서, 상기 타입 파라미터가 VOD일 때, 상기 클라이언트 장치는 상기 재생목록을 업데이트하지 않도록 구성되고, 상기 클라이언트 장치는 상기 재생목록이 참조하는 콘텐츠에 대한 변종 재생목록으로 전환할 시에 미래의 이용을 위해 상기 재생목록을 세이브하도록 구성된, 머신 구현된 방법.
12. 제11항에 있어서, 상기 타입 파라미터가 VOD일 때, 상기 클라이언트 장치는 상기 재생목록에 ENDLIST 태그가 없을 시에 에러 신호를 생성하도록 구성된, 머신 구현된 방법.
13. 제10항에 있어서, 상기 타입 파라미터가 라이브일 때, 상기 클라이언트 장치는 업데이트된 재생목록을 요청하도록 구성된, 머신 구현된 방법.
14. 제10항에 있어서, 상기 타입 파라미터가 이벤트일 때, 상기 클라이언트 장치는 (a) 업데이트된 재생목록의 일부만을 로딩하거나 (b) 상기 업데이트된 재생목록의 일부만을 파싱하도록 구성된, 머신 구현된 방법.
15. 제10항에 있어서, 상기 방법은, 상기 재생목록 파일에 의해 표시된 순서대로 상기 클라이언트 장치로 상기 미디어 파일들을 재생함으로써 콘텐츠의 스트림을 나타내는 오디오 또는 비디오 또는 오디오/비디오 출력을 생성하는 단계를 더 포함하고,
    상기 비-스트리밍 전송 프로토콜은 HTTP 호환 프로토콜을 포함하는, 머신 구현된 방법.
16. 데이터 처리 시스템으로서,
    클라이언트 장치에 의해 재생목록 파일을 요청하기 위한 수단;
    상기 요청에 응답하여 상기 클라이언트 장치에서, 서버 장치로부터의 상기 재생목록 파일을 수신하기 위한 수단 - 상기 재생목록 파일은 복수의 미디어 파일을 나타내는 URI와 상기 복수의 미디어 파일의 재생에 관련된 파라미터를 갖는 복수의 태그를 가짐 - ;
    상기 재생목록 파일이 재생목록의 타입을 나타내는 타입 파라미터를 갖는지를 판정하기 위한 수단; 및
    상기 재생목록 파일이 상기 타입 파라미터를 가질 때 상기 타입 파라미터에 따라 상기 재생목록을 처리하기 위한 수단
    을 포함하는, 데이터 처리 시스템.
17. 제16항에 있어서, 상기 타입 파라미터는 (a) VOD; (b) 라이브; 또는 (c) 이벤트 중 하나이고, VOD 재생목록은 변경되지 않으며, 이벤트는 이벤트 재생목록에 대한 지정되고 고정된 시작 시간을 가지고, 상기 재생목록은 비-스트리밍 전송 프로토콜을 이용하여 네트워크를 통해 수신되며, 상기 시스템은,
    상기 재생목록 파일에 의해 표시된 순서대로 상기 미디어 파일들 중 하나 이상을 요청하기 위한 수단; 및
    상기 비-스트리밍 전송 프로토콜을 이용하여 상기 네트워크를 통해 상기 하나 이상의 요청된 미디어 파일을 수신하기 위한 수단
    을 더 포함하는, 데이터 처리 시스템.
18. 제17항에 있어서, 상기 타입 파라미터가 VOD일 때, 상기 클라이언트 장치는 상기 재생목록을 업데이트하지 않도록 구성되고, 상기 클라이언트 장치는 상기 재생목록이 참조하는 콘텐츠에 대한 변종 재생목록으로 전환할 시에 미래의 이용을 위해 상기 재생목록을 세이브하도록 구성되고, 상기 타입 파라미터가 라이브일 때, 상기 클라이언트 장치는 업데이트된 재생목록을 요청하도록 구성되고, 상기 타입 파라미터가 이벤트일 때, 상기 클라이언트 장치는 (a) 업데이트된 재생목록의 일부만을 로딩하거나 (b) 상기 업데이트된 재생목록의 일부만을 파싱하도록 구성된, 데이터 처리 시스템.
19. 실행될 때, 데이터 처리 시스템으로 하여금 방법을 수행하게 하는 실행가능한 명령어를 저장한 머신 판독가능하고 비-일시적인 유형의 저장 매체로서, 상기 방법은,
    서버 장치에서 재생목록 파일에 대한 요청을 수신하는 단계;
    상기 요청에 응답하여 상기 서버 장치로부터, 상기 재생목록 파일을 전송하는 단계 - 상기 재생목록 파일은 복수의 미디어 파일을 나타내는 URI와 상기 복수의 미디어 파일의 재생에 관련된 파라미터를 갖는 복수의 태그를 가지며, 상기 재생목록 파일은 재생목록의 타입을 나타내는 타입 파라미터를 가짐 - ; 및
    상기 타입 파라미터에 따라 상기 재생목록을 처리 중인 클라이언트 장치로부터의 요청에 응답하는 단계
    를 포함하는, 머신 판독가능하고 비-일시적인 유형의 저장 매체.
20. 제19항에 있어서, 상기 타입 파라미터는 (a) VOD; (b) 라이브; 또는 (c) 이벤트 중 하나이고, VOD 재생목록은 변경되지 않으며, 이벤트는 이벤트 재생목록에 대한 지정되고 고정된 시작 시간을 가지고, 상기 재생목록은 비-스트리밍 전송 프로토콜을 이용하여 네트워크를 통해 전송되며, 상기 방법은,
    상기 재생목록 파일에 의해 표시된 순서대로 상기 미디어 파일들 중 하나 이상에 대한 요청을 수신하는 단계; 및
    상기 비-스트리밍 전송 프로토콜을 이용하여 상기 네트워크를 통해 상기 하나 이상의 요청된 미디어 파일을 전송하는 단계
    를 더 포함하는, 머신 판독가능하고 비-일시적인 유형의 저장 매체.
21. 제20항에 있어서, 상기 타입 파라미터가 VOD일 때, 상기 클라이언트 장치는 상기 재생목록을 업데이트하지 않도록 구성되고, 상기 클라이언트 장치는 상기 재생목록이 참조하는 콘텐츠에 대한 변종 재생목록으로 전환할 시에 미래의 이용을 위해 상기 재생목록을 세이브하도록 구성되고, 상기 타입 파라미터가 라이브일 때, 상기 클라이언트 장치는 업데이트된 재생목록을 요청하도록 구성되고, 상기 타입 파라미터가 이벤트일 때, 상기 클라이언트 장치는 (a) 업데이트된 재생목록의 일부만을 로딩하거나 (b) 상기 업데이트된 재생목록의 일부만을 파싱하도록 구성된, 머신 판독가능하고 비-일시적인 유형의 저장 매체.

Images