KR101233582B1 - 비-스트리밍 프로토콜을 통해 멀티미디어 데이터를 스트리밍하기 위한 방법 - Google Patents

비-스트리밍 프로토콜을 통해 멀티미디어 데이터를 스트리밍하기 위한 방법 Download PDF

Info

Publication number
KR101233582B1
KR101233582B1 KR1020117018907A KR20117018907A KR101233582B1 KR 101233582 B1 KR101233582 B1 KR 101233582B1 KR 1020117018907 A KR1020117018907 A KR 1020117018907A KR 20117018907 A KR20117018907 A KR 20117018907A KR 101233582 B1 KR101233582 B1 KR 101233582B1
Authority
KR
South Korea
Prior art keywords
media files
playlist file
updated
playlist
file
Prior art date
Application number
KR1020117018907A
Other languages
English (en)
Other versions
KR20110098864A (ko
Inventor
데이비드 비더맨
윌리암 주니어 메이
알랜 쳉
로거 팬토스
제임스 데이비드 뱃슨
Original Assignee
애플 인크.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US12/479,690 external-priority patent/US20100169458A1/en
Application filed by 애플 인크. filed Critical 애플 인크.
Publication of KR20110098864A publication Critical patent/KR20110098864A/ko
Application granted granted Critical
Publication of KR101233582B1 publication Critical patent/KR101233582B1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/95—Retrieval from the web
    • G06F16/954—Navigation, e.g. using categorised browsing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/34—Flow control; Congestion control ensuring sequence integrity, e.g. using sequence numbers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/756—Media network packet handling adapting media to device capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234327—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by decomposing into layers, e.g. base layer and one or more enhancement layers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234363—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the spatial resolution, e.g. for clients with a lower screen resolution
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/439—Processing of audio elementary streams
    • H04N21/4394—Processing of audio elementary streams involving operations for analysing the audio stream, e.g. detecting features or characteristics in audio streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44016—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for substituting a video clip
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/173—Analogue secrecy systems; Analogue subscription systems with two-way working, e.g. subscriber sending a programme selection signal
    • H04N7/17309—Transmission or handling of upstream communications
    • H04N7/17318—Direct or substantially direct transmission and handling of requests

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Remote Sensing (AREA)
  • Radar, Positioning & Navigation (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Communication Control (AREA)

Abstract

기계 구현 방법으로서, 서버 디바이스에서, 데이터 스트림을 다중 미디어 파일로 분할하는 단계 - 상기 다중 미디어 파일 각각은 전송 프로토콜 순응 포맷(transfer protocol compliant format)으로 메모리에 개별 파일들로서 저장됨 - ; 복수의 유니버설 리소스 표시자(URI) 및 복수의 태그를 가지는 재생 리스트 파일(play list file)을 생성하는 단계 - 상기 복수의 URI는 상기 데이터 스트림을 재생성하기 위한 상기 다중 미디어 파일의 순서(ordering)를 표시함 - ; 및 상기 다중 미디어 파일에 대한 변경들에 대응하는 업데이트된 재생 리스트 파일을 생성하는 단계 - 상기 업데이트된 재생 리스트 파일은 상기 데이터 스트림의 레프리젠테이션(representation)을 재생성하기 위한 업데이트된 다중 미디어 파일의 순서를 표시하는 복수의 업데이트된 URI를 포함함 - 를 포함하는 기계 구현 방법이 제공된다.

Description

비-스트리밍 프로토콜을 통해 멀티미디어 데이터를 스트리밍하기 위한 방법{METHOD FOR STREAMING MULTIMEDIA DATA OVER A NON-STREAMING PROTOCOL}
관련 출원들
본 출원은 후속하는 해당 출원일자의 미국 가출원들의 이익을 주장한다:
(1) 2008년 12월 31일자로 출원된 출원 제61/142,110호(명세 번호: P7437Z);
(2) 2009년 3월 16일자로 출원된 출원 제61/160,693호(명세 번호: P7437Z2);
(3) 2009년 3월 17일자로 출원된 출원 제61/161,036호(명세 번호: P7437Z3);
(4) 2009년 4월 7일자로 출원된 출원 제61/167,524호(명세 번호: P7437Z4);
(5) 2009년 9월 8일자로 출원된 출원 제61/240,648호(명세 번호: P7437Z5); 및
(6) 2009년 12월 21일자로 출원된 출원 제61/288,828호(명세 번호: P7437Z6). 이들 미국 가출원들 모두는 이들이 본 개시내용과 일치하는 범위에 대한 참조로써 본 명세서에 포함된다.
본 미국 특허 출원은 각각이 본 명세서에 참조로 포함되는 후속하는 미국 특허 출원들에 관련된다:
(1) 2009년 6월 5일자로 출원되었고 발명의 명칭이 "REAL-TIME OR NEAR REAL-TIME STREAMING"인 출원 제12/479,690호(명세 번호: P7437US1)
(2) 2009년 6월 5일자로 출원되었고 발명의 명칭이 "VARIANT STREAMS FOR REAL-TIME OR NEAR REAL-TIME STREAMING"인 출원 제12/479,698호(명세 번호: P7437US2)
(3) 2009년 6월 5일자로 출원되었고 발명의 명칭이 "UPDATABLE REAL-TIME OR NEAR REAL-TIME STREAMING"인 출원 제12/479,732호(명세 번호: P7437US3); 및
(4) 2009년 6월 5일자로 출원되었고 발명의 명칭이 "PLAYLISTS FOR REAL-TIME OR NEAR REAL-TIME STREAMING"인 출원 제12/479,735호(명세 번호: P7437US4).
기술 분야
본 발명의 실시예들은 데이터 전송 기술들에 관련된 것이다. 더 구체적으로, 본 발명의 실시예들은 예를 들어, 하이퍼텍스트 전송(HTTP)과 같은 비-스트리밍 프로토콜들을 사용하여 데이터의 스트리밍을 허용하는 기술들에 관한것이다.
콘텐츠의 스트리밍은 일반적으로 서버 디바이스로부터 일정하게 전송되고 클라이언트 디바이스에 의해 수신되는 멀티미디어 콘텐츠를 지칭한다. 콘텐츠는 일반적으로 그것이 스트리밍 서버에 의해 전달되는 한편으로 보통은 최종 사용자에게 표시된다. 스트리밍이라는 명칭은 미디어 그 자체라기보다는 미디어의 전달 방법을 지칭한다.
현재 스트리밍 서비스들은 일반적으로 "라이브" 콘텐츠를 최종 사용자들에게 분배하기 위한 특수화된 서버들을 필요로 한다. 임의의 큰 스케일의 배치에서, 이는 엄청난 비용을 초래할 수 있으며, 셋업 및 실행을 위해 전문 기술들을 필요로 한다. 이는 스트리밍을 위해 이용가능한 덜 바람직한 콘텐츠 라이브러리를 초래한다.
일 실시예에서, 서버 디바이스는 스트리밍될 콘텐츠의 적어도 일부분을 저장한다. 콘텐츠는 통상적으로는 이미지 또는 오디오(예를 들어, 소리 또는 음악) 또는 이들 모두의 시간 기반 스트림이고, 시간 기반 스트림의 예는 이미지들의 순서 또는 프레젠테이션이 시간에 기반하므로 시간 기반 스트림으로 간주될 수 있는 영화이다. 서버는 스트리밍될 콘텐츠를 세그먼트들로 분해(decompose)하여 네트워크 프로토콜에 따라 패킷들의 형태로 전송되도록 하기 위한 세그먼터 에이전트, 및 세그먼트화된 사용자 데이터를 제시할 시에 클라이언트가 쉽게 취급할 수 있게 하는 용이하게 할 수 있는 하나 이상의 재생 리스트 파일들을 생성하기 위한 인덱서 에이전트를 포함한다. 클라이언트 디바이스는 네트워크를 통해 서버 디바이스(또는 세그먼트들 및 재생 리스트들을 저장하고 전송하지만 이들을 생성하지는 않는 또다른 서버)와 결합된다. 클라이언트 디바이스는 하나 이상의 재생 리스트 파일들을 수신하고 상기 하나 이상의 재생 리스트 파일들에 따라 세그먼트화된 미디어 파일들의 콘텐츠로의 회수를 용이하게 하기 위한 어셈블러 에이전트(assembler agent)를 가진다. 클라이언트 디바이스는 또한 자신의 하나 이상의 출력 컴포넌트들을 통해 콘텐츠를 출력하기 위한 출력 생성기 에이전트를 가질 수 있다.
일 실시예에서, 서버 디바이스는 클라이언트 디바이스로 전송될 데이터를 획득한다. 서버 디바이스는 세그먼터 에이전트를 이용하여 전송될 데이터를 다중 미디어 파일로 분할한다. 서버 디바이스는 또한 상기 다중 미디어 파일을 메모리에 개별 미디어 파일들로서 저장한다. 서버 디바이스는 다중 미디어 파일에 대한 레퍼런스들을 가지는 하나 이상의 재생 리스트 파일들을 더 생성한다. 클라이언트 디바이스로부터의 데이터에 대한 요청들에 응답하여, 서버 디바이스(또는 또다른 서버 디바이스)는 하나 이상의 재생 리스트 파일들 및 적어도 다중 미디어 파일의 서브세트를 네트워크를 통해 클라이언트 디바이스에 전송한다. 다중 미디어 파일은 클라이언트 디바이스로부터의 요청들에 응답하여 비-스트리밍 전송 프로토콜을 사용하여 전송될 수 있으며, 이 프로토콜은, 예컨대 HTTP일 수 있다.
일 실시예에서, 클라이언트 디바이스는 하나 이상의 재생 리스트 파일들을 수신 및 저장할 수 있다. 이후 클라이언트는 재생 리스트 파일(들)에서 식별된 세그먼트화된 미디어 파일들을 요청하고 링크된 미디어 파일들을 다운로드할 수 있다. 클라이언트 디바이스(또는 또다른 디바이스)는 이후 콘텐츠의 스트림을 나타내는 오디오 및/또는 비디오 출력을 생성할 수 있다.
일 실시예에서, 업데이트된 재생 리스트는 서버에 의해 동적으로 생성되고 이후 클라이언트에 의해 검색된다. 업데이트된 재생 리스트는 오리지널 재생 리스트 내의 프로그램 뿐만 아니라 보여지는 보조물(예를 들어, 사이드바 사용자 인터페이스의 광고들, 관련 콘텐츠, 대안 버전들 등)을 포함할 수 있거나 또는 프로그램의 추가 부분들(예를 들어, 오리지널 재생 리스트에서 식별되는 제1 절반 너머의 프로그램의 제2 절반)을 포함할 수 있다. 일 구현에서, 서버는 업데이트된 재생 리스트로서 클라이언트에 의해 검색될 재생 리스트를 업데이트 하기 위해, 여기서 설명된 바와 같이, 롤링(rolling) 방법을 사용할 수 있다.
일 구현에서, 재생 리스트는 동일한 콘텐츠를 나타내는 복수의 대안적인 스트림들을 특정할 수 있는데, 이들 대안적인 스트림들은 상이한 시각적 해상도로 전송되는(따라서, 상이한 비트 레이트로 전송되는) 또는 다른 상이한 속성들을 가지고 전송되는 동일한 프로그램일 수 있다. 서버는 각각이 대안적인 스트림들 중 하나에 대한 것인 다중 재생 리스트들을 생성할 수 있으며, 대안적인 스트림들을 지칭하거나 특정하는 변경 재생 리스트를 생성할 수 있다. 서버(또는 또다른 서버)는 이후 상기 변경 재생 리스트를 클라이언트 디바이스에 전송할 수 있고, 클라이언트 디바이스는 현재 네트워크 조건들(예를 들어, 미디어 파일들을 전송하는데 사용되는 네트워크 상에서의 현재 스루풋 레이트)에 기초하여 어느 재생 리스트가 상기 변경 재생 리스트로부터 선택될지를 결정할 수 있고, 클라이언트 디바이스는 선택된 재생 리스트를 다운로드 할 수 있다(그리고 상기 선택된 재생 리스트에 의해 특정된 미디어 파일들을 추가적으로 다운로드할 수 있다).
일 실시예에서, 클라이언트 디바이스는 콘텐츠를 수신하고 표시하는 한편으로 변경 재생 리스트의 제1 재생 리스트로부터 상기 변경 재생 리스트의 제2 재생 리스트로 스위칭할 수 있다. 예를 들어, 클라이언트 디바이스는 제1 재생 리스트 및 제1 비트 레이트를 사용하여 프로그램을 수신할 수 있고, 네트워크의 스루풋 레이트의 측정들을 통해 자신이 더 높은 제2 비트 레이트로 동일한 프로그램의 콘텐츠를 수신할 수 있다고 결정할 수 있으며, 상기 콘텐츠는 제2 재생 리스트에 의해 특정된다. 이 경우, 클라이언트 디바이스는 제2 재생 리스트를 요청하고, 제2 재생 리스트를 수신하고 제1 재생 리스트에 의해 특정된 콘텐츠를 계속 표시하면서 제2 재생 리스트에 특정된 미디어 파일들을 검색하기를 시작할 수 있다. 클라이언트 디바이스는 미디어 파일들 및 결과적인 압축해제된 콘텐츠를 두 재생 리스트들 모두에 대한 버퍼들에 저장할 수 있고, 클라이언트 디바이스는 콘텐츠의 두 버전들 사이의 스위칭 또는 이행(transition) 시기 및 방법을 결정하기 위해 자동 동작을 수행할 수 있다. 예를 들어, 클라이언트 디바이스는 두 버전들에서 매칭 포인트를 찾기 위해 콘텐츠의 두 버전들에서 오디오 콘텐츠의 패턴 매칭을 사용하고, 그 후, 제2 재생 리스트로부터 새로운 콘텐츠로의 이행을 식별한 이후 스위칭을 야기한다.
일 실시예에서, 방법은 대안적인 스트림들을 사용하여 클라이언트 디바이스들에 미디어 콘텐츠를 제공하는 다중 리던던트 위치들을 제공하는 단계를 포함한다. 장애 극복(failover) 보호를 구현하기 위해, 제1 서버 디바이스 또는 제1 콘텐츠 분배 서비스는 스트림, 또는 다중의 대안적인(alternate) 대역폭 스트림들을 생성하고 재생 리스트 파일(들)을 생성한다. 제2 서버 디바이스 또는 제2 콘텐츠 서비스는 병렬 스트림, 또는 스트림들의 세트를 생성한다. 클라이언트는 제1 서버 디바이스 또는 제1 콘텐츠 분배 서비스와 연관된 제1 스트림을 사용하여 제1 URL(uniform resource locator)로부터 재생 리스트 파일(들)을 다운받으려 시도한다. 클라이언트가 제1 URL로부터 재생 리스트 파일(들)을 다운받을 수 없는 경우, 클라이언트는 또다른 URL과 연관된 대안적인 스트림들로 스위칭하려 시도한다.
일 실시예에서, 방법은 재생 리스트에 대한 요청을 제공하는 단계와 재생 리스트가 압축될 수 있다는 것을 요청내에 특정하는 단계, 및 요청에 응답하여 서버가 압축된 형태로 재생 리스트를 제공할 수 있다면(그렇지 않으면, 재생 리스트는 압축해제된 포맷으로 서버에 의해 제공될 수 있음) 압축된 형태로 재생 리스트를 수신하는 단계를 포함한다. 재생 리스트는 디플레이트(deflate) 또는 gzip과 같은 기존의 HTTP 표준 압축 기술에 의해 지원되는 압축 기술 또는 포맷을 사용하여 압축될 수 있다(또한 인코딩된다라고 지칭된다). 압축된 포맷으로 재생 리스트를 송신하고 수신하는 것은, 특히 재생 리스트가 시간 경과에 따라 커지는 경우(예를 들어, 재생 리스트가 장시간의 야구 경기에 대한 것인 경우), 전송되고 수신되는 데이터의 사이즈를 현저하게 감소시킬 수 있다. 일 실시예에서, 재생 리스트에 대한 압축의 사용은 클라이언트(재생 리스트를 요청하는 시스템) 및 서버(재생 리스트를 송신함으로써 요청에 응답하는 시스템) 모두에 대해 선택적일 수 있다. HTTP 표준의 일부분인 압축 기술 또는 포맷의 사용은 임의의 표준 준수 웹 서버로 하여금 압축된 재생 리스트를 공급할 수 있게 허용 하며, 임의의 표준 준수 클라이언트는 또한 재생 리스트를 압축해제하고 사용할 수 있을 것이다.
본 발명은 유사한 참조 번호가 유사한 엘리먼트들을 가리키는 첨부도면들의 그림들에서 예를 드는 방식으로 또한 제한적이 아닌 방식으로 도해된다.
도 1은 실시간, 또는 거의 실시간으로 콘텐츠를 송신 및 수신할 수 있는 서버 및 클라이언트들의 일 실시예의 블럭 다이어그램이다.
도 2a는 비-스트리밍 프로토콜들을 사용하여 미디어 콘텐츠를 지원하기 위한 하나 이상의 서버 디바이스들에 대한 기술의 일 실시예의 흐름도이다.
도 2b는 하나 이상의 클라이언트 디바이스들에 동적으로 업데이트된 재생 리스트들을 제공하기 위한 하나 이상의 서버 디바이스들에 대한 기술의 일 실시예의 흐름도이다.
도 2c는 다수의 비트 레이트들을 사용하여 클라이언트 디바이스들에 미디어 콘텐츠를 제공하기 위한 하나 이상의 서버 디바이스들에 대한 기술의 일 실시예의 흐름도이다.
도 3b는 비-스트리밍 프로토콜들을 사용하여 콘텐츠의 스트리밍을 지원하기 위한 클라이언트 디바이스에 대한 기술의 일 실시예의 흐름도이다.
도 3b는 다수의 비트 레이트들을 사용하여 콘텐츠의 스트리밍을 지원하기 위한 클라이언트 디바이스에 대한 기술의 일 실시예의 흐름도이다.
도 4는 서버 스트림 에이전트의 일 실시예의 블럭 다이어그램이다.
도 5는 클라이언트 스트림 에이전트의 일 실시예의 블럭 다이어그램이다.
도 6은 다수의 태그들을 가지는 재생 리스트 파일의 일 실시예를 예시한다.
도 7은 본 명세서에 설명된 바와 같은 어셈블링된 스트림들에 대한 재생 기술의 일 실시예의 흐름도이다.
도 8은 전자 시스템의 일 실시예의 블럭 다이어그램이다.
도 9a는 클라이언트 디바이스가 변경 재생 리스트의 대안적인 콘텐츠 사이에서 스위칭하는 방법의 일 예를 도시하는 플로우차트이다.
도 9b는 클라이언트 디바이스가 2개의 재생 리스트들의 콘텐츠 사이에서 스위칭하는 방법을 보여주는 추가적인 플로우차트이다.
도 9c는 클라이언트 디바이스가 오디오 패턴 매칭을 사용하여 콘텐츠 사이에서 스위칭하는 방법의 예를 보여주는 추가적인 플로우차트이다.
도 9d는 도 9c의 방법이 오디오 패턴 매칭을 가지고 어떻게 구현되는지를 다이어그램으로 도시한다.
도 10은 대안적인 스트림들을 사용하여 클라이언트 디바이스들로 미디어 콘텐츠를 제공하는 다수의 리던던트 위치들을 제공하기 위한 기술의 일 실시예의 흐름도이다.
도 11은 일 실시예에 따라 클라이언트(1102)가 하나 이상의 URL들과 쌍방향으로 통신하는 네트워크를 예시한다.
후속하는 설명에서, 다수의 특정 상세 내용들이 설명된다. 그러나, 본 발명의 실시예들은 이들 특정 상세 내용들 없이 구현될 수 있다. 다른 경우들에서, 공지된 회로들 구조들 및 기술들은 본원 발명의 설명의 이해를 모호하게 하지 않기 위해 상세히 도시되지 않았다.
본 발명은 저작권, 예를 들어, 그래픽 사용자 인터페이스 이미지들의 일러스트레이션에 의해 보호되는 유형물(material)을 포함한다. 본 발명의 양수인을 포함한, 저작권의 소유자들은, 따라서, 이들 유형물들의, 저작권을 포함한, 권한들을 보유한다. 저작권 소유자는 특허 문헌 또는 특허 개시 내용이 특허 및 상표청 파일 또는 기록에 나타나는 대로, 누군가에 의해 이런 내용들이 팩시밀리 복사되는 것에 대해 이의를 제기하지 않지만, 그 이외의 경우들에는 어느 것이든 모든 저작권들을 보유한다. 2009년 애플사 저작권.
일 실시예에서, 본 명세서에 설명된 기술들 및 컴포넌트들은 비-스트리밍 프로토콜들(예를 들어, HTTP) 및 다른 기술들[예를 들어, MPEG(Motion Picture Expert Group) 스트림들]을 사용하여 스트리밍 경험(experience)을 전달하기 위한 메커니즘을 포함할 수 있다. 예를 들어, 거의 실시간 스트리밍 경험은 "라이브" 뮤지컬 또는 스포츠 이벤트, 라이브 뉴스, 웹 카메라 피드 등을 방송하기 위해 HTTP를 사용하여 제공될 수 있다. 일 실시예에서, 프로토콜은 들어오는 미디어 데이터를 다중 미디어 파일로 세그먼트화하고 이들 세그먼트화된 미디어 파일들을 서버에 저장할 수 있다. 프로토콜은 또한 클라이언트를 서버에 저장된 세그먼트화된 미디어 파일들에 인도(direct)하는 URI(Uniform Resource Identifier)들을 포함하는 재생 리스트 파일을 구축할 수 있다. 세그먼트화된 미디어 파일들이 재생 리스트 파일(들)에 따라 재생되는 경우, 클라이언트는 사용자에게 "라이브" 이벤트의 거의 실시간 방송을 제공할 수 있다. 사전-기록된 콘텐츠가 유사한 방식으로 제공될 수 있다.
일 실시예에서, 서버는 보충적인 또는 대안적인 미디어 콘텐츠(예를 들어, 광고, 스포츠 이벤트와 관련된 통계치들, 메인 프레젠테이션에 대한 추가적인 미디어 콘텐츠)를 방송 이벤트내에 동적으로 도입할 수 있다. 예를 들어, 미디어 이벤트의 클라이언트 재생동안, 서버는 재생 리스트 파일에 추가적인 URI들을 추가할 수 있고, URI들은 클라이언트가 보충 미디어 파일을 그로부터 다운로드할 수 있는 위치를 식별할 것이다. 클라이언트는 서버가 도입한 임의의 보충적인 또는 추가적인 (또는 둘 모두의) 미디어 콘텐츠에 액세스하기 위해 하나 이상의 업데이트된 재생 리스트 파일(들)을 서버로부터 주기적으로 검색하도록 명령받을 수 있다.
일 실시예에서, 서버는 누적(cumulative) 모드 또는 롤링(rolling) 모드로 동작할 수 있다. 누적 모드에서, 서버는 재생 리스트 파일을 생성하고, 상기 재생 리스트 파일의 종단에 미디어 파일 식별자들을 첨부할 수 있다. 클라이언트는 이후 다운로드될 때 단일 재생 리스트 파일로부터 스트림의 모든 부분들에 대한 액세스를 가질 수 있다(예를 들어, 사용자는 쇼의 중간에서 시작할 수 있다). 롤링 모드에서, 서버는 롤링 기반으로 재생 리스트 파일의 시작으로부터 미디어 파일 식별자들을 제거(remove)함으로써 미디어 파일들의 가용성을 제한할 수 있는데, 이에 의해 클라이언트 디바이스에 대해 액세스 가능한 미디어 콘텐츠의 슬라이딩 윈도우를 제공한다. 서버는 또한 재생 리스트에 미디어 파일 식별자들을 추가할 수 있고, 롤링 모드에서, 서버는 미디어 파일들의 가용성을 가장 최근에 재생 리스트에 추가된 미디어 파일들로 제한할 수 있다. 클라이언트는 이후 시청을 계속하기 위해 재생 리스트 파일의 업데이트된 카피들을 반복적으로 다운로드 한다. 재생 리스트 다운로드에 대한 롤링 기반은 콘텐츠가 시간상 잠재적으로 제한되지 않을 때(unbounded)(예를 들어, 계속 동작하는 웹 캠으로부터의 콘텐츠) 유용할 수 있다. 클라이언트는 재생 리스트에서 종단 태그를 발견할 때까지 롤링 모드에서 재생 리스트를 반복적으로 요청하는 것을 계속할 수 있다.
일 실시예에서, 메커니즘은 동일한 프레젠테이션의 변경(variant) 스트림들을 제공함으로써 비트 레이트 스위칭을 지원한다. 예를 들어, 서빙될 프레젠테이션의 몇몇 버전들은 서버에 저장될 수 있다. 각각의 버전은 실질적으로 동일한 콘텐츠를 가질 수 있지만 상이한 비트 레이트들로 인코딩될 수 있다. 이는 클라이언트 디바이스가, 재생의 연속성을 양보하지 않고, 예컨대, 가용 대역폭의 검출에 좌우되어 비트 레이트들 사이에서 스위칭하게 할 수 있다.
일 실시예에서, 보호 피처(protection feature)들은 허가되지 않은 사용에 대해 콘텐츠를 보호하기 위해 제공될 수 있다. 예를 들어, 비-순차적인 미디어 파일의 넘버링이 예측을 방지하기 위해 사용될 수 있다. 미디어 파일들의 암호화가 사용될 수 있다. 부분적인 미디어 파일 리스트들이 사용될 수 있다. 추가적인 그리고/또는 상이한 보호 피처들 또한 제공될 수 있다.
도 1은 실시간, 또는 거의 실시간으로 콘텐츠를 송신 및 수신할 수 있는 서버와 클라이언트들의 일 실시예의 블럭 다이어그램이다. 도 1의 예는 네트워크를 통해 서버와 결합되는 두 클라이언트가 있는 단순한 서버-클라이언트 접속을 제공한다. 임의의 수의 클라이언트들이 본 명세서에서 설명되는 기술들 및 메커니즘들을 이용하여 지원될 수 있다. 또한, 다수의 서버들은 본 명세서에서 설명되는 기술들 및 메커니즘들에 따라 콘텐츠를 제공할 수 있고 그리고/또는 콘텐츠를 제공하기 위해 함께 동작할 수 있다. 예를 들어, 하나의 서버는 콘텐츠를 생성할 수 있고, 재생 리스트들을 생성할 수 있고, 다수의 미디어(예를 들어, 파일들)를 생성할 수 있고, 다른 서버들은 생성된 콘텐츠를 저장 및 전송한다.
네트워크(110)는 유선, 무선(예를 들어, IEEE 802.11, 802.16) 또는 이들의 임의의 조합인 임의의 타입의 네트워크일 수 있다. 예를 들어, 네트워크(100)는 인터넷 또는 인트라넷일 수 있다. 또다른 예로서, 네트워크(110)는 셀룰러 네트워크(예를 들어, 3G, CDMA)일 수 있다. 일 실시예에서, 클라이언트 디바이스들(150 및 180)은 다수의 네트워크 타입들을 통해 통신가능할 수 있다(예를 들어, 각각의 디바이스는 WiFi 무선 LAN을 통해 무선 셀룰러 전화 네트워크를 통해 통신가능할 수 있다). 예를 들어, 클라이언트 디바이스들(150 및 180)은 데이터 네트워크들 및 셀룰러 무선 전화 네트워크들을 통해 통신할 수 있는 스마트 폰들 또는 셀룰러 방식이 가능한 개인 디지털 정보 단말(PDA)들일 수 있다. 이들 디바이스들은 필요한 경우 네트워크의 타입 또는 심지어 네트워크들 간의 스위칭을 통해 본 명세서에서 설명되는 스트리밍 메커니즘을 이용할 수 있다.
서버(120)는 당해 기술 분야에 공지된 임의의 방식으로 HTTP 서버로서 동작할 수 있다. 상기 서버(120)는 HTTP 프로토콜들을 사용하여 콘텐츠를 제공하는 HTTP 서버 에이전트(145)를 포함한다. 도 1의 예가 HTTP의 견지에서 설명되지만, 다른 프로토콜들이 유사한 방식으로 이용될 수 있다. 세그먼터(130) 및 인덱서(135)는 본 명세서에 설명된 바와 같이 재생 리스트 파일을 구비한 미디어 파일들의 콘텐츠를 제공하기 위해 서버(120)(또는 다수의 서버들) 상에 상주하는 에이전트들이다. 이들 미디어 파일들 및 재생 리스트 파일들은 HTTP 프로토콜들을 사용하여 HTTP 서버 에이전트(145)를 통해 네트워크(110)을 통해 제공될 수 있다. 여기서 논의된 바와 같은 에이전트들은 하드웨어, 소프트웨어, 펌웨어 또는 이들의 결합으로 구현될 수 있다.
세그먼터(130)는 미디어 데이터의 스트림을 HTTP 프로토콜을 통해 전송될 수 있는 다중의 미디어 파일로 분할하도록 기능할 수 있다. 인덱서(135)는, 클라이언트 디바이스들이 서버(120)에 의해 제공되는 콘텐츠의 실시간 또는 거의 실시간 전송을 제공하기 위해 미디어 파일들을 리어셈블링(reassembling)할 수 있도록, 세그먼트화된 미디어 파일들에 대응하는 재생 리스트 파일을 생성하는 기능을 할 수 있다. 클라이언트 디바이스로부터의 하나 이상의 요청들에 응답하여, 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 등)를 포함할 수 있고; 상기 버퍼는 현재 콘텐츠가 표시되는 시간을 넘어서 수초의 표시할만한 가치가 있는 콘텐츠를 제공할 수 있어서, 새로운 콘텐츠가 다운로드 되는 한편으로 버퍼링된 콘텐츠가 추후 디스플레이될 수 있도록 한다. 이 버퍼는 클라이언트 디바이스가 간헐적으로 느린 네트워크 접속을 통해 콘텐츠를 검색하려고 시도하는 동안 표시가능한 콘텐츠를 제공할 수 있고, 따라서, 상기 버퍼는 네트워크 레이턴시(latency) 또는 접속 문제들을 숨길 수 있다.
클라이언트 디바이스들(150 및 180)은 본 명세서에서 논의되는 보안 기능들 중 하나 이상을 제공하는 선택적 보안 에이전트들(170 및 185)을 각각 더 포함할 수 있다. 클라이언트 디바이스들(150 및 180)은 또한 도 1에 예시되지 않은 추가적인 컴포넌트들을 포함할 수 있다.
일 실시예에서, 본 명세서에 설명된 기술들은 비-스트리밍 프로토콜(예를 들어, HTTP)을 통해 멀티미디어 데이터의 비제한된 스트림을 전송하는데 사용될 수 있다. 또한 실시예들은 미디어 데이터의 암호화 및/또는 스트림의 대안적 버전들의 프로비전(예를 들어, 대안적 비트 레이트들을 제공하는 것)을 포함할 수 있다. 미디어 데이터가 생성 이후에 바로 전송될 수 있으므로, 데이터는 거의 실시간으로 수신될 수 있다. 파일들에 대한 예시적인 데이터 포맷들 및 멀티미디어 데이터의 스트림의 서버(송신자) 및 클라이언트(수신자)에 의해 취해질 동작들이 제공되지만, 다른 포맷들 역시 지원될 수 있다.
시뮬레이션된 실시간 스트림(또는 거의 실시간 스트림)으로서 전송될 수 있는 미디어 프레젠테이션은 재생 리스트 파일을 표시하는 URI(Universal Resource Indicator)에 의해 특정된다. 일 실시예에서, 재생 리스트 파일은 추가적인 URI들의 정렬된 리스트이다. 재생 리스트 파일의 각각의 URI는 스트림의 세그먼트인 미디어 파일을 지칭하는데, 이는 특정 프로그램에 대한 미디어 데이터의 단일의 연속(contiguous) 스트림일 수 있다.
미디어 데이터의 스트림을 재생하기 위해, 클라이언트 디바이스는 서버로부터 재생 리스트 파일을 획득한다. 클라이언트는 또한 재생 리스트 파일에 의해 표시되는 각각의 미디어 데이터 파일을 획득 및 재생한다. 일 실시예에서, 클라이언트는 추가적인 그리고/또는 상이한 미디어 세그먼트들을 발견하기 위해 재생 리스트 파일을 동적으로 또는 반복적으로 리로딩(reload)할 수 있다.
재생 리스트 파일들은, 예를 들어, 확장된 M3U 재생 리스트 파일들일 수 있다. 일 실시예에서, M3U 포맷을 실효적으로(effectively) 확장하는 추가적인 태그들이 사용된다. 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비트 유니코드 변환 포맷)은 가변-길이 캐릭터 인코딩 포맷이다. 대안적인 실시예들에서, 다른 캐릭터 인코딩 포맷들이 사용될 수 있다.
후속하는 예들에서, 2개의 태그들인 EXTM3U 및 EXTINF를 포함하는 확장된 M3U 포맷이 이용된다. 확장된 M3U 파일은 "#EXTM3U"를 포함하는 제1 라인에 의해 기본 M3U 파일과 구별될 수 있다.
EXTINF는 태그에 후속하는 URI에 의해 식별되는 미디어 파일을 설명하는 레코드 마커이다. 일 실시예에서, 각각의 미디어 파일 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-TARGETDURATION 태그는 프레젠테이션에 추가될 다음 미디어 파일의 대략적인 지속기간을 표시할 수 있다. 이는 재생 파일에 포함될 수 있으며, 그 포맷은:
#EXT-X-TARGETDURATION:<seconds>
일 수 있고, 여기서 "seconds"는 미디어 파일의 지속기간을 표시한다. 일 실시예에서, 실제 지속기간은 태그에 의해 표시되는 타겟 지속기간과는 약간 상이할 수 있다. 일 실시예에서, 세그먼트를 표시하는 모든 URI는 세그먼트의 대략적인 지속기간과 연관될 것인데, 예를 들면, 세그먼트에 대한 URI에는 해당 세그먼트의 대략적인 지속기간을 표시하는 태그가 프리픽스(prefix)될 수 있다.
재생 리스트 파일 내의 각각의 미디어 파일 URI는 고유한 시퀀스 번호를 가질 수 있다. 만약 존재하는 경우, URI의 시퀀스 번호는, 일 실시예에서, 그것에 선행한 URI의 시퀀스 번호 더하기 일(1)과 동일하다. EXT-X-MEDIA-SEQUENCE 태그는 재생 리스트에 나타나는 제1 URI의 시퀀스 번호를 표시할 수 있으며, 그 포맷은:
#EXT-X-MEDIA-SEQUENCE:<number>
일 수 있는데, 여기서 "number"는 URI의 시퀀스 번호이다. 재생 리스트 파일이 #EXT-X-MEDIA-SEQUENCE 태그를 포함하지 않는 경우, 재생 리스트 내의 제1 URI의 시퀀스 번호는 1로 간주될 수 있다. 일 실시예에서, 시퀀스 넘버링은 비-순차적일 수 있는데, 예를 들어, 1, 5, 7, 17등과 같은 비-순차적 시퀀스 넘버링은 시퀀스의 다음 번호를 예상하기 어렵게 만들 수 있으며, 이는 콘텐츠가 저작권 침해(pirating)되는 것으로부터 보호하는 것을 보조할 수 있다. 콘텐츠를 보호하는 것을 보조하기 위한 또다른 옵션은 임의의 주어진 시간에 재생 리스트의 오직 일부만을 노출하는 것이다.
일부 미디어 파일들은 암호화될 수 있다. EXT-X-KEY 태그는 그에 후속하는 미디어 파일들을 암호해독하는데 사용될 수 있는 정보를 제공하며, 그 포맷은
#EXT-X-KEY:METHOD=<method>[,URI="<URI>"]
이다. METHOD 파라미터는 암호화 방법을 특정하고, 만약 존재하는 경우, URI 파라미터는 키를 획득하는 방법을 특정한다.
NONE의 암호화 방법은 암호화가 없음을 표시한다. 다양한 암호화 방법들이 사용될 수 있는데, 예를 들어, 128 비트 키 및 PKCS7 패딩을 갖는 AES(Advance Encryption Standard) 암호화를 사용하는 암호화를 표시하는 AES- 128이 사용될 수 있다[RFC3852 참조]. 새로운 EXT-X-KEY 태그는 임의의 이전 EXT-X-KEY 태그들을 대체한다.
URI 파라미터를 가지는 EXT-X-KEY 키 태그는 키 파일을 식별한다. 키 파일은 재생 리스트 파일에 나열된 후속적인 미디어 파일들을 암호해독하는데 사용될 암호 키를 포함한다. 예를 들어, AES-128 암호화 방법은 16-옥텟 키들을 사용한다. 키 파일의 포맷은 바이너리 포맷으로 16 옥텟의 패킹된 어레이일 수 있다.
AES-128의 사용은 일반적으로 암호화 및 암호해독시에 동일한 16-옥텟의 초기화 벡터(IV)가 공급되는 것을 요구한다. IV의 변경은 암호의 강도를 증가시키기 위해 사용될 수 있다. AES-128 암호화의 사용시, 미디어 파일의 시퀀스 번호가 미디어 파일의 암호화 또는 암호해독시의 IV로서 사용될 수 있다.
EXT-X-PROGRAM-DATE-TIME 태그는 다음 미디어 파일의 시작을 절대적 날짜 및/또는 시간과 연관시킬 수 있으며 시간 영역을 포함 또는 표시할 수 있다. 일 실시예에서, 날짜/시간 표시는 ISO/IEC 8601:2004이다. 태그 포맷은:
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>
일 수 있는데, 여기서 다음 속성들이 사용될 수 있다. 속성 BANDWIDTH=<n>은 초당 비트 수로서 표현되는 스트림 비트 레이트의 대략적인 상한이다. 속성 PROGRAM-ID=<i>은 재생 리스트 파일의 범위 내의 특정 프레젠테이션을 고유하게 식별하는 수이다. 재생 리스트 파일은 동일한 프레젠테이션의 변경 스트림들을 설명하기 위해 동일한 PROGRAM-ID를 가지는 다수의 EXT-X-STREAM-INF URI들을 포함할 수 있다. 변경 스트림들 및 변경 재생 리스트들은 본 개시물에 추가적으로 설명된다(예를 들어, 도 9a-9d 참조).
전술된 태그들 및 속성들은 오리지널 미디어 콘텐츠를 표현하는 미디어 파일들을 구성, 전송 및 프로세싱하기 위해 서버 디바이스에 의해 사용될 수 있다. 클라이언트 디바이스는 클라이언트 디바이스의 사용자에게 실시간 또는 거의 실시간의 스트리밍 경험(예를 들어, 음악 또는 스포츠 이벤트와 같은 라이브 방송의 시청)을 제공하는 방식으로 미디어 파일들을 리어셈블링 또는 표시하기 위해 이 정보를 사용한다.
재생 리스트 파일의 각각의 미디어 파일 URI는 오리지널 프레젠테이션의 세그먼트인 미디어 파일(즉, 오리지널 미디어 콘텐츠)을 식별한다. 일 실시예에서, 각각의 미디어 파일은 MPEG-2 전송 스트림, MPEG-2 프로그램 스트림, 또는 MPEG-2 오디오 기본 스트림으로서 포맷된다. 상기 포맷은 CODEC을 특정함으로써 특정될 수 있으며, 재생 리스트는 CODEC을 특정함으로써 포맷을 특정할 수 있다. 일 실시예에서, 프레젠테이션 내의 모든 미디어 파일들은 동일한 포맷을 가지지만, 다수의 포맷들이 다른 실시예들에서 지원될 수 있다. 전송 스트림 파일은, 일 실시예에서, 단일 MPEG-2 프로그램을 포함해야 하고, 각각의 파일의 시작에 프로그램 연관 테이블 및 프로그램 맵 테이블이 존재해야 한다. 비디오를 포함하는 파일은 비디오 디코더를 완전히 초기화하기에 충분한 정보 및 적어도 하나의 키 프레임을 가져야 한다. 클라이언트들은 적절한 서브세트를 선택함으로써 특정 타입(예를 들어, 오디오 또는 비디오)의 다수의 트랙들을 핸들링할 준비가 되어야 한다. 클라이언트들은, 일 실시예에서, 그들이 인지하지 못한 전송 스트림 내의 개인(private) 스트림들을 무시해야 한다. 미디어 파일 내에 있는 샘플 내의, 그리고 다수의 미디어 파일에 걸친 대응하는 스트림들 사이의 샘플들에 대한 인코딩 파라미터들은 일정하게 유지되어야 한다. 그러나, 클라이언트들은, 예를 들어, 해상도 변경을 수용하기 위해 비디오 콘텐츠를 스케일링 함으로써 이들이 당면하는 인코딩 변경을 처리해야 한다.
도 2a는 하나 이상의 서버 디바이스들이 비-스트리밍 프로토콜들을 사용하여 미디어 콘텐츠를 지원하기 위한 기술의 일 실시예의 흐름도이다. 도 2a의 예가 HTTP의 견지에서 제공되지만, 다른 비-스트리밍 프로토콜들이 유사한 방식으로 이용될 수 있다. 도 2a의 예는 특정 작업들을 수행하는 단일 서버의 견지에서 제공된다. 그러나, 임의의 개수의 서버들이 이용될 수 있다. 예를 들어, 클라이언트 디바이스들에 미디어 파일들을 제공하는 서버는 콘텐츠를 다수의 미디어 파일로 세그먼트화하는 서버와는 상이한 디바이스일 수 있다.
서버 디바이스는 동작(200)에서 제공될 콘텐츠를 수신한다. 콘텐츠는 라이브 오디오 및/또는 비디오(예를 들어, 스포츠 이벤트, 라이브 뉴스, 웹 카메라 피드)를 나타낼 수 있다. 콘텐츠는 또한 사전-레코딩된 콘텐츠(예를 들어, 레코딩된 콘서트, 트레이닝 세미나 등)를 나타낼 수 있다. 콘텐츠는 스트리밍되든 되지 않았든 간에, 당해 기술분야에 공지된 임의의 포맷 및 프로토콜에 따라 서버에 의해 수신될 수 있다. 일 실시예에서, 콘텐츠는 MPEG-2 스트림의 형태로 서버에 의해 수신되지만, 다른 포맷들 역시 지원될 수 있다.
서버는 이후 동작(210)에서 콘텐츠의 적어도 일부분을 임시로 저장할 수 있다. 콘텐츠 또는 콘텐츠의 적어도 일부분들은, 예를 들어, 저장 디바이스(예를 들어, 스토리지 영역 네트워크 내의 하드 디스크)에 또는 메모리에 일시적으로 저장될 수 있다. 대안적으로, 콘텐츠는 콘텐츠를 저장 디바이스 또는 메모리에 전송할 수 있는 저장 매체를 통해 수신될 수 있다. 일 실시예에서, 서버는, 필요한 경우, 콘텐츠를 하나 이상의 스트림들(예를 들어, MPEG-2)로 변환하는 인코더를 가진다. 이러한 변환은 수신된 콘텐츠를 영구적으로 저장하지 않고 발생할 수 있으며, 일부 실시예들에서, 저장 동작(210)이 생략될 수 있거나, 또는 다른 실시예들에서는 더 긴 기간(term)의 저장일 수 있다(예를 들어, 아카이브 저장).
제공될 콘텐츠는 동작(220)에서 다수의 미디어 파일로 세그먼트화된다. 일 실시예에서, 서버는 스트림을 표준 웹서버를 사용하여 분배될 수 있는 별개의 그리고 상이한 미디어 파일들(즉, 세그먼트들)로 변환한다. 일 실시예에서, 서버는 개별 미디어 파일들의 효과적인 디코딩을 지원하는 포인트들에서(예를 들어, PES 패킷 경계들 및 i-프레임 경계들과 같은 패킷 및 키 프레임 경계들에서) 미디어 스트림을 세그먼트화한다. 미디어 파일들은 거의 동일한 지속기간을 가지는 오리지널 스트림의 일부분들일 수 있다. 서버는 또한 각각의 미디어 파일에 대한 URI를 생성한다. 이들 URI들은 클라이언트 디바이스들이 미디어 파일들에 액세스하게 한다.
세그먼트들은 내재적으로 전체 파일들을 전달하는 HTTP 서버들을 사용하여 서빙되므로, 서버는 클라이언트들에게 서빙될 수 있기 전에 사용가능한 완전한 세그먼트화된 미디어 파일을 가져야 한다. 따라서, 클라이언트는 적어도 하나의 미디어 파일 길이만큼 방송을 (시간상으로) 지연(lag)시킬 수 있다. 일 실시예에서, 미디어 파일 사이즈는 지연 시간 및 너무 많은 파일들을 가지는 것 사이의 균형에 기초한다.
일 실시예에서, 2가지 세션 타입들(라이브 세션 및 이벤트 세션)이 지원된다. 라이브 세션에 대해, 오직 고정된 사이즈의 스트림 부분만이 보존된다. 일 실시예에서, 기한이 지난 콘텐츠 미디어 파일들이 프로그램 재생 리스트 파일로부터 삭제되고, 서버로부터 삭제될 수 있다. 세션의 제2 타입은 이벤트 세션인데, 여기서 클라이언트는 방송의 임의의 포인트로 튜닝할 수 있다(예를 들어, 처음부터 시작하고, 중간 포인트로부터 시작한다). 이러한 타입의 세션은, 예컨대 재방송을 위해 사용될 수 있다.
미디어 파일들은 동작(230)에서 서버 메모리에 저장된다. 미디어 파일들은 동작(230)에서 파일들을 저장하기 이전에, 암호화와 같은 보안 피처에 의해 보호될 수 있다. 미디어 파일들은 서버 디바이스 상의 웹 서버 애플리케이션에 의해 지원되는(또는 전송을 수행하는 또다른 디바이스에 의해 지원되는) 새로운 프로토콜(예를 들어, HTTP 또는 HTTPS)을 사용하여 전송할 준비가 된 파일들로서 저장된다.
하나 이상의 재생 리스트 파일들은 동작(240)에서 미디어 파일들이 오리지널 콘텐츠를 재생성하기 위해 어셈블링되어야 하는 순서를 표시하기 위해 생성된다. 재생 리스트 파일(들)은 클라이언트 디바이스 상에서의 스트리밍 경험을 제공하도록 클라이언트 디바이스가 미디어 파일들에 액세스하고 이들을 리어셈블링할 정보를 제공하기 위해 확장된 M3U 태그들 및 본 명세서에 설명된 태그들을 이용할 수 있다. 각각의 미디어 파일에 대한 URI는 미디어 파일들이 재생될 순서로 재생 리스트 파일(들) 내에 포함된다. 서버는 또한 클라이언트 디바이스들로 하여금 재생 리스트 파일(들)에 액세스하게 하기 위해 재생 리스트 파일(들)에 대한 하나 이상의 URI들을 생성할 수 있다.
재생 리스트 파일(들)은 동작(250)에서 서버 상에 저장될 수 있다. 미디어 파일들 및 재생 리스트 파일(들)의 생성 및 저장이 도 2a에서 특정 순서로 제시되지만, 또한 상이한 순서가 사용될 수 있다. 예를 들어, 재생 리스트 파일(들)은 미디어 파일들이 생성되거나 저장되기 전에 생성될 수 있다. 또다른 예로서, 재생 리스트 파일(들) 및 미디어 파일들은 어느 하나가 저장되기 이전에 생성될 수 있다.
미디어 파일들이 암호화되어야 하는 경우, 재생 리스트 파일(들)은 허가된 클라이언트 디바이스들로 하여금 미디어 파일들을 암호해독하기 위한 암호화 키를 포함하는 키 파일을 획득하게 하는 URI를 정의할 수 있다. 암호화 키는 보안 접속(예를 들어, HTTPS)을 사용하여 전송될 수 있다. 또다른 예로서, 재생 리스트 파일(들)은 HTTPS를 사용하여 전송될 수 있다. 추가적인 예로서, 미디어 파일들은 클라이언트가 재생 리스트 파일(들) 없이는 스트림을 재생성할 수 없도록 예측불가능한 순서로 정렬될 수 있다.
암호화 방법이 AES-128인 경우, AES-128 CBC 암호화는, 예를 들어, 개별 미디어 파일들에 적용될 수 있다. 일 실시예에서, 전체 파일이 암호화된다. 암호화 블럭 체인은 일반적으로, 일 실시예에서, 미디어 파일들에 걸쳐 적용되지 않는다. 미디어 파일들의 시퀀스는 전술된 바와 같이 IV로서 사용된다. 일 실시예에서, 서버는 키 URI를 가지는 EXT-X-KEY 태그를 재생 리스트 파일의 종단에 추가한다. 서버는 이후 암호화 구성의 변경이 이루어질 때까지 해당 키를 이용하여 모든 후속적인 미디어 파일들을 암호화한다.
새로운 암호화 키로 스위칭하기 위해, 서버는 프레젠테이션에서 사용된 모든 이전 키 URI들과는 다른 새로운 URI를 통해 사용가능한 새로운 키를 만들 수 있다. 서버는 또한 새로운 키 URI를 가지는 EXT-X-KEY 태그를 재생 리스트 파일의 종단에 추가하고, 새로운 키를 이용하여 모든 후속적인 미디어 파일들을 암호화한다.
암호화를 종료하기 위해, 서버는 재생 리스트 파일의 종단에 암호화 방법 NONE을 가지는 EXT-X-KEY 태그를 추가할 수 있다. (방법으로서 "NONE"을 가지는) 태그는 일 실시예에서 URI 파라미터를 포함하지 않는다. 모든 후속적인 미디어 파일들은 전술된 바와 같이 암호화 구성의 변경이 이루어질 때까지 암호화되지 않는다. 서버는 재생 리스트 파일이 해당 키를 가지고 암호화된 미디어 파일에 대한 URI를 포함하는 경우 재생 리스트 파일로부터 EXT- X-KEY 태그를 삭제하지 않는다. 도 3b에 대해 보다 상세하게 설명되는 바와 같이, 서버는 동작(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)에서 서버 상에 저장될 수 있다. 미디어 파일들 및 재생 리스트 파일(들)의 생성 및 저장이 도 2b에서 특정 순서로 제시되지만, 또한 상이한 순서가 사용될 수 있다.
도 3b-3b에 대해 보다 상세하게 설명되는 바와 같이, 서버는 동작(275)에서, 클라이언트 요청들에 응답하여 네트워크를 통해 재생 리스트 파일(들) 및 미디어 파일들을 전송할 수 있다.
재생 리스트 파일(들)은 다양한 이유들로 서버에 의해 업데이트될 수 있다. 서버는 동작(285)에서 클라이언트 디바이스들에 제공될 추가적인 데이터를 수신할 수 있다. 추가적인 데이터는 동작(255)에서 재생 리스트 파일(들)이 저장된 이후 수신될 수 있다. 추가적인 데이터는, 예를 들어, 라이브 프레젠테이션의 추가적인 부분들, 또는 기존의 프레젠테이션에 대한 추가적인 정보일 수 있다. 추가적인 데이터는 광고들 또는 통계치들(예를 들어, 스포츠 이벤트에 관련된 스코어 및 데이터)를 포함할 수 있다. 추가적인 데이터는 프레젠테이션 상에 (반투명으로) 중첩될 수 있거나 사이드바 사용자 인터페이스에 표시될 수 있다. 추가적인 데이터는 원래 수신된 데이터와 동일한 방식으로 세그먼트화될 수 있다. 추가적인 데이터가 광고, 또는 재생 리스트에 의해 나타나는 프로그램에 삽입될 다른 콘텐츠로 구성되는 경우, 추가적인 데이터는 동작(215)에서 (적어도 일시적으로) 저장되고, 동작(225)에서 세그먼트화되고, 동작 (235)에서 저장되될 수 있으며, 세그먼트화된 추가적인 데이터의 저장 이전에, 추가적인 데이터의 세그먼트들이 암호화될 수 있다. 이후 동작(245)에서, 프로그램 및 추가적인 데이터를 포함하는 업데이트된 재생 리스트가 생성될 것이다. 재생 리스트는 추가적인 데이터에 기초하여 업데이트되며 동작(255)에서 다시 저장된다. 재생 리스트(들)에 대한 변경들은 클라이언트 디바이스의 관점에서 원자적으로(atomically) 이루어져야 한다. 일 실시예에서, 업데이트된 재생 리스트는 이전 재생 리스트를 대체한다. 아래에 더 상세하게 논의될 바와 같이, 클라이언트 디바이스들은 재생 리스트를 여러번 요청할 수 있다. 이들 요청들은 클라이언트 디바이스들이 가장 최근의 재생 리스트를 이용하도록 할 수 있다. 일 실시예에서, 추가적인 데이터는 메타데이터일 수 있는데, 이 경우, 재생 리스트는 업데이트될 필요는 없지만, 세그먼트들은 메타데이터를 포함하도록 업데이트될 수 있다. 예를 들어, 메타데이터는 세그먼트들 내의 타임스탬프들과 매칭될 수 있는 타임스탬프들을 포함할 수 있고, 메타데이터는 매칭하는 타임스탬프를 가지는 세그먼트들에 추가될 수 있다.
또한 업데이트된 재생 리스트는 미디어 파일들의 삭제를 초래할 수 있다. 일 실시예에서, 서버는, 미디어 파일들에 대해, 이들이 재생 리스트에 추가된 순서로 재생 리스트로부터 미디어 파일들에 대한 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)에서 서버는 요청들에 응답하여 클라이언트 디바이스로 미디어 파일들을 제공한다.
도 3b는 클라이언트 디바이스가 비-스트리밍 프로토콜들을 사용하여 콘텐츠의 스트리밍을 지원하기 위한 기술의 일 실시예의 흐름도이다. 도 3b의 예가 HTTP의 견지에서 제공되지만, 다른 비-스트리밍 프로토콜들이 유사한 방식으로 이용될 수 있다. 도 3b-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 태그가 존재하지 않는 경우, 마지막 및 마지막에서 두번째의 미디어 파일들을 제외한 임의의 미디어 파일이 먼저 재생될 수 있다. 재생할 제1 미디어 파일이 선택되면, 재생 리스트 파일 내의 후속적인 미디어 파일들이, 일 실시예에서, 재생 리스트 파일에 나타나는 순서로 로딩된다(그렇지 않은 경우, 콘텐츠는 비순차적으로 나타난다). 일 실시예에서, 클라이언트 디바이스는 인터럽트되지 않은 재생을 제공하기 위해, 그리고 네트워크 레이턴시 및 스루풋에서의 시간상의 변경들을 보상하기 위해 미디어 파일들이 요구되기 전에 미디어 파일들을 로딩하려고 시도한다(그리고 이들을 버퍼에 저장한다).
다운로드된 미디어 파일(들)은 동작(340)에서 클라이언트 디바이스 상의 메모리에 저장될 수 있다. 콘텐츠가 저장될 수 있는 메모리는 클라이언트 디바이스 상의 임의의 타입의 메모리, 예를 들어, 랜덤-액세스 메모리, 하드 디스크, 또는 비디오 버퍼일 수 있다. 저장은 재생을 위해 일시적일 수 있거나 또는 영구적일 수 있다. 재생 리스트 파일이 EXT-X-ALLOW-CACHE 태그를 포함하고, 그 값이 NO인 경우, 클라이언트는 다운로드된 미디어 파일들이 재생된 후 상기 다운로드된 미디어 파일들을 저장하지 않는다. 재생 리스트가 EXT-X-ALLOW-CACHE 태그를 포함하고, 그 값이 YES인 경우, 클라이언트 디바이스는 추후 반복재생을 위해 미디어 파일들을 무기한으로 저장할 수 있다. 클라이언트 디바이스는 사용자에게 프로그램 시작(origination) 시간을 디스플레이 하기 위해 EXT-X-PROGRAM-DATE-TIME 태그의 값을 사용할 수 있다. 일 실시예에서, 클라이언트는 보다 양호한 사용자 경험을 제공하기 위해, 네트워크 지터에 덜 영향을 받도록 다수의 미디어 파일을 버퍼링할 수 있다.
일 실시예에서, 암호해독 방법이 AES-128인 경우, AES-128 CBC 암호해독이 개별 미디어 파일들에 적용된다. 전체 파일이 암호해독된다. 일 실시예에서, 암호 블럭 체인은 미디어 파일들에 걸쳐 적용되지 않는다. 미디어 파일의 시퀀스 번호는 전술된 바와 같이 초기화 벡터로서 사용될 수 있다.
메모리로부터, 동작(350)에서 콘텐츠가 클라이언트로부터 출력될 수 있다. 출력 또는 프레젠테이션은, 예를 들어, 내장형 스피커들 또는 헤드폰들을 통한 오디오 출력일 수 있다. 출력은 스크린을 통해 출력되거나 클라이언트 디바이스로부터 영사되는 비디오를 포함할 수 있다. 당해 기술분야에 알려진 임의의 타입의 출력이 이용될 수 있다. 동작(351)에서, 클라이언트 디바이스는 재생되지 않거나 표시되지 않은 저장된 현재의 재생 리스트에 미디어 파일들이 더 존재하는지의 여부를 결정한다. 이러한 미디어 파일들이 존재하는 경우(그리고, 상기 미디어 파일들이 요청되지 않은 경우), 프로세싱은 하나 이상의 미디어 파일들이 요청되는 동작(330)으로 리턴하고 프로세스가 반복된다. 이러한 미디어 파일들이 존재하지 않는 경우(즉, 현재 재생 리스트 내의 모든 미디어 파일들이 재생된 경우), 프로세싱은 재생 리스트 파일이 종료 태그를 포함하는지의 여부를 결정하는 동작(352)으로 진행한다.
재생 리스트가 동작(352)에서 종료 태그(예를 들어, EXT-X-ENDLIST)를 포함하는 경우, 재생 리스트 파일에 의해 표시되는 미디어 파일들이 재생되었을때 재생이 중단된다. 종료 태그가 재생 리스트에 없는 경우, 클라이언트 디바이스는 서버로부터 다시 재생 리스트를 요청하고 프로그램에 대한 추가의 또는 업데이트된 재생 리스트를 획득하기 위해 동작(300)으로 다시 돌아간다.
도 2b에 대해 보다 상세하게 논의된 바와 같이, 서버는 보조 콘텐츠(예를 들어, 라이브 방송에서 추가적인 미디어 콘텐츠에 대응하는 추가적인 미디어 파일 식별자들) 또는 추가적인 콘텐츠(예를 들어, 스트림의 더 하위의 콘텐츠)를 도입하기 위해 재생 리스트 파일을 업데이트할 수 있다. 보조 콘텐츠 또는 추가적인 콘텐츠에 액세스하기 위해, 클라이언트는 서버로부터 업데이트된 재생 리스트를 리로딩할 수 있다. 이는, 심지어 재생 리스트 파일과 연관된 미디어 콘텐츠의 재생동안이라 할지라도, 재생 리스트 파일들이 동적으로 업데이트될 수 있게 하는 메커니즘을 제공할 수 있다. 클라이언트는 트리거들의 수에 기초하여 재생 리스트 파일의 리로딩을 요청할 수 있다.
일 실시예에서, 클라이언트 디바이스는 재생 리스트 파일이 EXT-X-ENDLIST 태그를 포함하지 않는 경우 재생 리스트 파일(들)을 주기적으로 리로딩한다. 클라이언트 디바이스가 재생 리스트 파일을 최초로 로딩할 때 또는 재생 리스트 파일을 리로딩하고 재생 리스트 파일이 로딩된 마지막 시간 이후 재생 리스트 파일이 변경되었음을 발견할 때, 클라이언트는 재생 리스트 파일을 다시 리로딩하려고 시도하기 이전의 시간 기간동안 대기할 수 있다. 이 기간은 초기 최소 리로딩 지연이라 지칭된다. 그것은 클라이언트가 재생 리스트 파일을 로딩하기 시작하는 시간으로부터 측정된다.
일 실시예에서, 초기 최소 리로딩 지연은, 어느 것이 더 적든 간에, 재생 리스트 파일의 마지막 미디어 파일의 지속기간 또는 타겟 지속기간의 3배이다. 미디어 파일 지속기간은 EXTINF 태그에 의해 특정된다. 클라이언트가 재생 리스트 파일을 리로딩하고 그것이 변경되지 않았음을 발견하는 경우, 클라이언트는 재시도 이전의 시간 기간동안 대기할 수 있다. 일 실시예에서 최소 지연은, 어느 것이 더 적든 간에, 타겟 지속기간의 3배 또는 초기 최소 리로딩 지연의 배수일 수 있다. 일 실시예에서, 이러한 배수는 제1 시도에 대해 0.5, 제2 시도에 대해 1.5 및 후속 시도들에 대해 3.0이지만, 다른 배수들이 사용될 수도 있다.
재생 리스트 파일이 로딩되거나 리로딩될 때마다, 클라이언트 디바이스는 로딩할 다음 미디어 파일을 결정하기 위해 재생 리스트 파일을 검사한다. 로딩할 제1 파일은 전술된 바와 같이 먼저 재생하도록 선택된 미디어 파일이다. 재생될 제1 미디어 파일이 로징되고 재생 리스트 파일이 EXT-X-MEDIA-SEQUENCE 태그를 포함하지 않는 경우, 클라이언트는, 현재 재생 리스트 파일이 그것이 원래 발견되었던 오프셋에서 마지막으로 로딩된 미디어 파일의 URI를 포함하는 것을 증명하고, 파일이 발견되지 않은 경우 재생을 중지할 수 있다. 로딩할 다음 미디어 파일은 재생 리스트 파일에서 마지막으로 로딩된 URI에 후속하는 제1 미디어 파일 URI일 수 있다.
재생될 제1 미디어 파일이 로딩되고 재생 리스트 파일이 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)에서 미디어 파일들을 이용하여 클라이언트 디바이스에 의해 제공되며, 클라이언트 디바이스는 비트 레이트를 변경할지의 여부를 결정한다.
일 실시예에서, 클라이언트 디바이스는 초기에 최저의 사용가능한 비트 레이트를 선택한다. 미디어를 재생하는 동안, 클라이언트 디바이스는 사용가능한 대역폭이 재생을 위해 더 높은 비트 레이트의 사용을 지원할 수 있는지의 여부를 결정하기 위해 사용가능한 대역폭(예를 들어, 현재 네트워크 접속 비트 레이트들)을 모니터링할 수 있다. 만약 지원한다면, 클라이언트 디바이스는 더 높은 비트 레이트를 선택하고, 더 높은 비트 레이트 미디어 재생 리스트 파일에 의해 표시되는 미디어 파일들에 액세스할 수 있다. 그 역 또한 지원될 수 있다. 재생으로 너무 많은 대역폭이 소모되는 경우, 클라이언트 디바이스는 더 낮은 비트 레이트를 선택하고, 더 낮은 비트 레이트 미디어 재생 리스트 파일에 의해 표시되는 미디어 파일들에 액세스할 수 있다.
클라이언트 디바이스가 동작(394)에서 비트 레이트를 변경하는 경우, 사용가능한 대역폭의 변경에 대한 응답으로 또는 사용자 입력에 대한 응답으로, 클라이언트 디바이스는 동작(385)에서 상이한 비트 레이트를 선택할 수 있다. 일 실시예에서, 상이한 비트 레이트를 선택하기 위해, 클라이언트 디바이스는 새롭게 선택된 비트 레이트에 대응하는 재생 리스트 파일에 포함된 URI들의 상이한 리스트를 이용할 수 있다. 일 실시예에서, 클라이언트 디바이스는 재생 리스트 내의 미디어 파일들의 액세스 동안 비트 레이트들을 변경할 수 있다.
비트 레이트가 동작(394)에서 변경하지 않는 경우, 클라이언트 디바이스는 검색되거나 존재하지 않는 현재 재생 리스트 내의 재생되지 않은 미디어 파일들이 더 존재하는지의 여부를 결정한다. 이러한 미디어 파일들이 존재하는 경우, 프로세싱은 동작(390)으로 리턴하고, 하나 이상의 미디어 파일들은 재생 리스트 내의 해당 파일들에 대한 URI들을 사용하여 검색된다. 이러한 미디어 파일들이 존재하지 않는 경우(즉, 현재 재생 리스트 내의 모든 미디어 파일들이 재생된 경우), 프로세싱은 재생 리스트가 종료 태그를 포함하는지의 여부가 결정되는 동작(396)으로 진행한다. 만약 종료 태그를 포함하는 경우, 프로그램의 재생은 종료하고 프로세스가 완료되며; 만약 종료 태그를 포함하지 않는 경우, 프로세싱은 동작(370)으로 되돌아가고 클라이언트 디바이스는 프로그램에 대한 재생 리스트를 리로딩할 것을 요구하며, 도 3b에 도시된 방법을 통해 프로세스가 반복된다.
도 4는 서버 스트림 에이전트의 일 실시예의 블럭 다이어그램이다. 서버 스트림 에이전트(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 클라이언트 디바이스에 암호해독된 미디어 파일들의 스트림을 제공할 수 있다. 또다른 예에서, 프라이머리 클라이언트 디바이스는 재생 리스트들을 검색하여 이들을 세컨더리 클라이언트 디바이스에 제공할 수 있으며, 상기 세컨더리 디바이스는 재생 리스트 내에 특정된 미디어 파일들을 검색하고 이들 미디어 파일들을 표시하기 위한 출력을 생성한다. 클라이언트 스트림 에이전트(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 태그이다.
후속하는 섹션은 일 실시예에 따른 몇몇 예시적인 재생 리스트 파일들을 포함한다.
단순 재생 리스트 파일
Figure 112011062599265-pat00001
HTTPS를 사용하는, 슬라이딩 윈도우 재생 리스트
Figure 112011062599265-pat00002
암호화된 미디어 파일들을 가지는 재생 리스트 파일
Figure 112011062599265-pat00003
변경 재생 리스트 파일
Figure 112011062599265-pat00004
Figure 112011062599265-pat00005
도 7은 본 명세서에서 설명된 바와 같은 어셈블링된 스트림들에 대한 재생 기술의 일 실시예의 흐름도이다. 일 실시예에서, 수신된 미디어 파일들의 재생은 사용자에 의해 시작, 중지, 되감기 등을 수행하도록 제어될 수 있다. 재생 리스트 파일은 동작(700)에서 클라이언트 디바이스에 의해 수신된다. 재생 리스트 파일에 의해 표시되는 미디어 파일들이 동작(710)에서 검출된다. 동작(720)에서 수신된 미디어 파일들에 기초하여 출력이 생성된다. 미디어 파일들에 기초한 수신 및 출력의 생성은 전술된 바와 같이 수행될 수 있다.
동작(730)에서 제어 입력이 검출되면, 클라이언트 디바이스는 동작(740)에서 상기 입력이 중지를 표시하는지의 여부를 결정할 수 있다. 입력이 중지인 경우, 프로세스는 종료하고 재생이 중지된다. 입력이 동작(750)에서 되감기 또는 빨리감기 요청을 표시하는 경우, 클라이언트 디바이스는 동작(760)에서 메모리에 여전히 저장된 이전에 재생된 미디어 파일들에 기초하여 출력을 생성할 수 있다. 이들 파일들이 캐시에 더 이상 존재하지 않는 경우, 프로세싱은 미디어 파일들을 검색하기 위해 동작(710)으로 되돌아가고, 프로세스가 반복된다. 대안적인 실시예에서, 재생은 중지 입력으로서 재생을 종료하지 않고 재생을 중지하는 일시정지 피처를 지원할 수 있다.
하나의 스트림에서 또다른 스트림으로 트랜지션하기 위한 방법이 도 9a-9d에 대해 추가적으로 설명된다. 하나의 클라이언트 디바이스는 이들 방법들 각각을 수행할 수 있거나 또는 이들 방법들 각각의 동작들이 여기서 설명된 바와 같이 다수의 클라이언트 디바이스들에 걸쳐 분배될 수 있는데, 예를 들어, 분배된 경우, 하나의 클라이언트 디바이스는 변경 재생 리스트 및 2개의 미디어 재생 리스트들을 검색하고, 이들을, 2개의 미디어 재생 리스트들에 의해 특정되는 미디어 파일들을 검색하고 검색된 미디어 파일들에 의해 제공되는 2개의 스트림들 사이에서 스위칭하는 또다른 클라이언트 디바이스에 제공할 수 있다. 또한, 대안적인 실시예들에서, 도시된 동작들의 순서가 수정될 수 있거나 이들 도면들에 도시된 것보다 더 많거나 더 적은 동작들이 존재할 수 있다는 점이 이해될 것이다. 방법들은 상이한 스트림들을 선택하기 위해 변경 재생 리스트를 사용할 수 있다. 변경 재생 리스트는 프로그램(예를 들어, 스포츠 이벤트)에 대해 사용가능한 스트림들을 결정하기 위해 동작(901)에서 검색 및 프로세싱될 수 있다. 동작(901)은 클라이언트 디바이스에 의해 수행될 수 있다. 제1 스트림은 동작(903)에서 변경 재생 리스트로부터 선택될 수 있으며, 클라이언트 디바이스는 이후 제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 스트림)를 검색, 저장 및 표시하고, 동작(925)에서 제1 재생 리스트에 의해 특정되는 콘텐츠가 표시되는 동안 제2 미디어 재생 리스트에 의해 특정되는 콘텐츠(예를 들어, 제2 스트림)를 검색 및 저장하는 것을 도시한다. 제1 미디어 재생 리스트로부터 획득되는 콘텐츠를 표시하는 동안 제2 미디어 재생 리스트에 의해 특정되는 콘텐츠의 검색 및 (예를 들어, 임시 버퍼에서의) 저장은 클라이언트 디바이스로 하여금 프로그램의 실질적 인터럽트 없이 프로그램의 버전들 사이에서 스위칭하게 하는 (도 9d에 도시된) 프로그램의 콘텐츠의 시간상의 오버랩(955)을 생성한다. 이러한 방식으로, 프로그램의 버전들 사이의 스위칭은 (비록 사용자가 일부 경우들에서 스위칭 이후 더 높은 해상도의 이미지를 인지할 수 있을지라도) 스위칭이 발생했음을 사용자가 인지하지 않고, 또는 프로그램의 프레젠테이션의 실질적 인터럽트 없이, 많은 경우들에서 달성될 수 있다. 동작(927)에서, 클라이언트 디바이스는 제1 미디어 재생 리스트에 의해 특정되는 콘텐츠로부터 제2 미디어 재생 리스트에 의해 특정되는 콘텐츠로 스위칭할 트랜지션 포인트를 결정하는데, 트랜지션 포인트의 예(트랜지션 포인트(959))가 도 9d에 도시된다. 제2 미디어 재생 리스트에 의해 특정된 콘텐츠는 이후 스위칭 이후 동작(931)에서 표시된다.
도 9c 및 9d에 도시된 방법은 트랜지션 포인트를 결정하기 위한 일 실시예를 나타내는데, 이 실시예는 트랜지션 포인트를 결정하기 위해 2개의 스트림들(951 및 953)로부터의 오디오 샘플들에 대한 패턴 매칭에 따른다. 대안적인 실시예들이, 트랜지션 포인트를 결정하기 위해, 비디오 샘플들에 대한 패턴 매칭을 사용할 수 있거나, 2개의 스트림들에서 타임 스탬프들을 사용할 수 있는 것 등이 이해될 것이다. 방법은, 동작(941)에서, 버퍼 내의 제1 미디어 재생 리스트에 의해 특정되는 콘텐츠(예를 들어, 스트림(951))를 저장하는 단계를 포함할 수 있으며, 버퍼는 콘텐츠의 프레젠테이션을 위해, 그리고 또한 패턴 매칭 동작을 위해 사용될 수 있다. 스트림(951)은 오디오 샘플들(951A) 및 비디오 샘플들(951B) 모두를 포함한다. 비디오 샘플들은 단일 비디오 프레임을 디스플레이하기 위해 필요한 모든 콘텐츠를 가지는 키 프레임들 또는 i-프레임들에 따르는 압축 기술을 사용할 수 있다. 스트림(951) 내의 콘텐츠는 시간(예를 들어, 프로그램의 시작 이후로 경과한 시간)을 특정하는 타임스탬프들을 포함할 수 있으며, 이들 타임스탬프들은 샘플들 각각의 시작(예를 들어, 오디오 샘플들(951A) 각각의 시작 및 비디오 샘플들(951B) 각각의 시작)을 마킹할 수 있다. 일부 경우들에서, 2개의 스트림들 사이의 타임스탬프들의 비교는 트랜지션 포인트를 결정하는데 유용하지 않을 수 있는데, 왜냐하면 이들이 충분히 정확하지 않거나 2개의 스트림들 내의 샘플들의 경계들의 차이 때문이다; 그러나, 타임스탬프 범위들의 비교는 2개의 스트림들 사이에서 시간상의 오버랩(955)이 존재함을 증명하는데 사용될 수 있다. 동작(943)에서, 클라이언트 디바이스는 제2 미디어 재생 리스트에 의해 특정되는 버퍼 콘텐츠에 저장하는데, 이 콘텐츠는 제1 미디어 재생 리스트로부터 획득되는 콘텐츠와 동일한 프로그램에 대한 것이며, 이는 또한 타임스탬프들을 포함할 수 있다. 일 실시예에서, 타임스탬프들은, 스트림 내에 존재하지 않는 경우, 스트림에 대한 재생 리스트에 추가될 수 있는데, 예를 들어, 일 실시예에서, 하나 이상의 타임스탬프들을 포함하는 ID3 태그는 변경 재생 리스트 또는 미디어 재생 리스트와 같은 재생 리스트의 엔트리에 추가될 수 있다. 엔트리는, 예를 들어, 오디오 스트림의 제1 샘플에 대한 URI 내에 존재할 수 있다. 도 9d는 제2 미디어 재생 리스트로부터 획득된 콘텐츠 (953)의 예를 도시하며, 이는 오디오 샘플들(953b) 및 비디오 샘플들(953b)을 포함한다. 동작(945)에서, 클라이언트 디바이스는, 일 실시예에서, 매칭된 오디오 세그먼트들(세그먼트들(957)) 이후의 다음 자체 포함된 비디오 프레임(i-프레임(961))일 수 있는 트랜지션 포인트(959)를 오버랩(955)으로부터 선택하기 위해 2개의 스트림들(951 및 953)의 오디오 샘플들에 대해 패턴 매칭을 수행할 수 있다. i-프레임(961)(및 연관된 오디오 샘플)으로 시작하여, 프로그램의 프레젠테이션은 제2 미디어 재생 리스트로부터 획득되는 제2 스트림을 사용한다. 전술된 방법은 더 느린 비트 레이트로부터 더 빠른 비트레이트로의 변경 및 더 빠른 비트 레이트로부터 더 느린 비트 레이트로의 변경 모두에 대한 일 실시예에서 사용될 수 있지만, 또다른 실시예에서, 상기 방법은 오직 더 느린 비트 레이트로부터 더 빠른 비트 레이트로의 변경에 대해서만 사용될 수 있고, (예를 들어, 트랜지션 포인트를 위치시키려고 하지는 않으나 가능한 빨리 더 느린 비트 레이트 스트림으로부터의 콘텐츠를 저장하고 표시하려고 하는) 또다른 방법은 더 빠른 비트로부터 더 느린 비트로의 변경에 대해 사용될 수 있다.
도 10은 대안적인 스트림들을 사용하여 클라이언트 디바이스들에 재생 리스트들 또는 미디어 콘텐츠를 제공하는 다수의 리던던트 위치들을 제공하기 위한 기술의 일 실시예의 흐름도이다. 재생 리스트가 전술된 대안적인 스트림들을 포함하는 경우, 대안적인 스트림들은 대역폭 또는 디바이스 대안물들로서 동작할 수 있을 뿐만 아니라 실패 대비책으로서도 동작할 수 있다. 예를 들어, 클라이언트가 (예를 들어, 404 에러 또는 네트워크 접속 에러로 인해) 스트림에 대한 재생 리스트 파일을 리로딩할 수 없는 경우, 클라이언트는 대안적인 스트림으로 스위칭하려 할 수 있다. 도 10을 참조하면, 시스템 장애극복(failover) 보호를 구현하기 위해, 제1 서버 디바이스 또는 제1 콘텐츠 분배 서비스는 도 2c의 설명과 관련하여 논의된 바와 같이 동작(1002)에서 스트림 또는 다수의 대안적인 대역폭 스트림들을 생성하도록 구성된다. 동작(1004)에서, 제1 서버 디바이스 또는 제1 콘텐츠 분배 서비스는 동작(1002)에서 생성된 스트림(들)으로부터 재생 리스트 파일(들)을 생성한다. 제2 서버 디바이스 또는 제2 콘텐츠 분배 디바이스는 동작(1006)에서 병렬 스트림 또는 스트림들의 세트를 생성할 수 있고, 또한 재생 리스트를 생성한다. 이들 병렬 스트림(들)은 백업 스트림들로 간주될 수 있다. 다음으로, 백업 스트림들의 리스트가 동작(1008)에서 재생 리스트 파일(들)에 추가되어, 각각의 대역폭에서의 백업 스트림(들)은 프라이머리 스트림 다음에 나열된다. 예를 들어, 프라이머리 스트림이 서버 ALPHA로부터 오고, 백업 스트림이 서버 BETA 상에 존재하는 경우, 재생 리스트 파일은 다음과 같을 수 있다:
Figure 112011062599265-pat00006
백업 스트림들이 재생 리스트 내의 프라이머리 스트림들과 섞이며, 각각의 대역폭에서의 백업은 해당 대역폭에 대한 프라이머리 다음에 나열된다는 점에 유의한다. 클라이언트는 단일의 백업 스트림 세트에 제한되지 않는다. 위의 예에서, 예를 들어, ALPHA 및 BETA는 GAMMA에 선행할 수 있다. 유사하게, 스트림의 완전한 병렬 세트를 제공하는 것이 필요하지 않다. 단일의 저대역 스트림이 예를 들어 백업 서버에 제공될 수 있다.
동작(1010)에서, 클라이언트는 제1 서버 디바이스 또는 제1 콘텐츠 분배 서비스와 연관된 제1 스트림을 사용하여 제1 URL로부터 재생 리스트 파일(들)을 다운로드하려 한다. 도 11은, 일 실시예에 따라, 클라이언트(1102)가 하나 이상의 URL들, 서버 디바이스들 또는 콘텐츠 분배 서비스들과 쌍방향으로 통신하는 네트워크를 예시한다. 재생 리스트 파일(들)은 동작(1012)에서 제1 URL, 서버 디바이스 또는 콘텐츠 분배 서비스로부터 클라이언트(1102)로 전송될 수 있다. 클라이언트가 (예를 들어, 스트림에 대한 인덱스 파일의 리로딩 시의 에러로 인해) 제1 URL, 서버 디바이스, 또는 콘텐츠 분배 서비스로부터 재생 리스트 파일(들)을 다운로드 받을 수 없는 경우, 클라이언트는 대안적인 스트림으로 스위칭하려 한다. 하나의 스트림에 대한(예를 들어, 동작(1010)) 실패(예를 들어, 인덱스 로딩 실패)의 경우, 클라이언트는 동작(1014)에서 네트워크 접속이 지원하는 가장 높은 대역폭의 대안적인 스트림을 선택한다. 동일한 대역폭에서 다수의 대안물들이 존재하는 경우, 클라이언트는 이들 중에서 재생 리스트에 나열된 순서로 선택한다. 예를 들어, 클라이언트(1102)가 URL 1로부터 성공적으로 다운로드할 수 없는 경우, 클라이언트(1102)는 재생 리스트 파일(들)이 대안적인 URL로부터 클라이언트로 전송되는 경우 URL 2 또는 또다른 URL로부터 다운로드할 수 있다. 이러한 피처는 심지어 심각한 로컬 실패들, 예를 들어, 서버 붕괴 또는 콘텐츠 분배자 노드 고장의 경우라도 미디어가 클라이언트에게 도달하게 할 리던던트 스트림들을 제공한다.
장애극복 보호는 클라이언트가 재생 리스트들 및 미디어 파일들을 검색할 수 있는 다수의 리던던트 위치들을 제공하는 능력을 제공한다. 따라서, 클라이언트가 제1 위치로부터 스트림을 검색하지 못하는 경우, 클라이언트는 제2, 제3 등의 위치로부터 스트림에 액세스하려 할 수 있다.
일 실시예에서, 클라이언트가 재생 리스트를 검색할 수 있는 추가적인 위치들을 표시하기 위해, 동일한 변경 재생 리스트 태그에는 동일한 대역폭이, 그러나 리던던트 위치의 새로운 URI가 제공될 것이다. 클라이언트는 초기에는 원하는 대역폭과 연관된 제1 URL에 액세스하려 할 수 있다. 클라이언트는, 제1 URL로부터 재생 리스트를 다운로드할 수 없는 경우, 모든 확률이 소진될 때까지 그 대역폭에 대해 제시되는 새로운 URL에 액세스하는 것 등을 시도할 수 있다.
아래의 예는 2560000 대역폭에 대한 1개의 리던던트 위치 및 7680000 대역폭에 대한 2개의 리던던트 위치들을 포함한다.
Figure 112011062599265-pat00007
이 예에서, 파일명들(예를 들어, mid-redundant2.m3u8) 및 실제 URL (예를 들어, http://example2.com <http://example2.com/>, http://example3.com <http://example3.com/>) 모두가 변경된다는 점에 유의한다. 그러나, 일 실시예에서, 리던던트 위치는 오직 파일명에 대한 또는 오직 웹사이트에 대한 변경일 수 있다.
일 실시예에서, 재생 리스트는 서버 디바이스에 의해 압축되어 압축된 형태로 클라이언트 디바이스에 송신될 수 있다. 압축된 재생 리스트는 일반적으로 압축되지 않은 재생 리스트보다 재생 리스트를 나타내기 위해 더 적은 비트들을 필요로 하고, 따라서, 압축된 재생 리스트는 전송 또는 수신될 때, 네트워크, 예를 들어, 무선 셀룰러 전화 네트워크의 더 적은 사용가능한 대역폭을 사용한다. 일 실시예에서, 재생 리스트는 HTTP 1.1 표준 프로토콜과 같은 전송 프로토콜에 순응하거나 이와 호환가능한 웹 서버에 의해 사용되는 내장형 압축 기술 또는 설비에 따라 웹 서버에 의해 압축될 수 있는데, 이러한 압축 기술 또는 설비의 예는 HTTP 1.1의 디플레이트 또는 gzip 압축 설비이다. 표준 기반 전송 프로토콜의 일부인 다른 표준 기반 압축 설비들이 다른 실시예들에서 사용될 수 있다. 압축된 재생 리스트들의 사용은, 일 실시예에서, 서버 디바이스들 또는 클라이언트 디바이스들의 선택적 피처일 수 있다. 일 실시예에서, 재생 리스트는 텍스트 콘텐츠(예를 들어, 텍스트 파일)일 수 있고, 표준 기반 웹 서버에 의해 디플레이트 또는 gzip을 사용하여 효율적으로 압축될 수 있고, 이후 클라이언트 디바이스에 의해 자동으로 압축해제될 수 있다. gzip 압축 설비의 버전의 설명은 www.ietf.org/rfc/rfc1952.txt에서 찾을 수 있고, 디플레이트 압축 설비의 버전은 www.ietf.org/rfc/rfc1951.txt에서 찾을 수 있다. 클라이언트 디바이스 상에서의 많은 웹 서버들 및 많은 웹 브라우저들은 디플레이트 또는 gzip 설비들을 자동으로 지원할 수 있다.
일 실시예에서, 클라이언트 디바이스는 업데이트된 재생 리스트를 주기적으로 요청할 수 있는데, 예를 들어, 클라이언트 디바이스는 수 초마다(예를 들어, 매 10, 20, 또는 30초마다 또는 일부 다른 시간 기간마다) 업데이트된 재생 리스트를 서버로부터 요청할 수 있다. 더 커지는 재생 리스트, 예를 들어, 클라이언트로 하여금 라이브 게임동안 임의의 시간에서 라이브 게임의 시작부터 시청하게 하는 라이브 진행 야구 게임에 대한 재생 리스트는, 더 커지는 재생 리스트가 네트워크를 통해 반복적으로 송신됨에 따라 압축의 사용이 네트워크의 대역폭의 사용을 제한할 수 있을 만큼 충분히 커질 수 있다.
일 실시예에서, 클라이언트 디바이스는, 자신이 언제 재생 리스트(예를 들어, 업데이트된 재생 리스트)를 요청하는지, 자신이 어떤 압축 기술들(예를 들어, 디플레이트 또는 gzip)을 지원할 수 있는지를 선택적으로 특정할 수 있으며, 이들 기술들에 대한 지원은 클라이언트 디바이스가 압축된 또는 인코딩된 콘텐츠를 압축해제 또는 디코딩할 수 있다는 것을 의미한다. 압축 기술의 선택적 규격을 가지는, 재생 리스트에 대한 클라이언트 디바이스의 요청은, 일 실시예에서 재생 리스트에 대한 압축 기술을 지원하도록 요구되지는 않지만 압축되지 않은 재생 리스트를 송신할 수 있는 웹 서버에 의해 수신된다. 웹 서버는 재생 리스트에 대한 클라이언트 디바이스의 요청에 특정된 압축 기술들 중 하나를 사용하여 압축된 재생 리스트 또는 압축되지 않은 재생 리스트를 클라이언트 디바이스에 송신함으로써 클라이언트 디바이스의 요청에 응답할 수 있다. 클라이언트 디바이스는 상기 재생 리스트를 수신하여 이를 여기에 설명된 바와 같이 사용하는데, 만약 재생 리스트가 압축된 경우, 상기 재생 리스트는 클라이언트 디바이스 상의 웹 브라우저에서의 디코더와 같은 클라이언트 디바이스 상의 디코더를 사용하여 디코딩된다.
도 8은 전자 시스템의 일 실시예의 블럭 다이어그램이다. 도 8에 예시된 전자 시스템은, 예를 들어, 데스크톱 컴퓨터 시스템, 랩톱 컴퓨터 시스템, 셀룰러 전화, 셀룰러-인에이블 PDA를 포함하는 PDA(personal digital assistant), 셋톱 박스, 엔터테인먼트 시스템 또는 다른 가전 디바이스를 포함하는, 광범위한 전자 시스템들(유선 또는 무선)을 나타내도록 의도된다. 대안적인 전자 시스템들은 더 많은, 더 적은 그리고/또는 상이한 컴포넌트들일 수 있다. 도 8의 전자 시스템은 클라이언트 디바이스 및/또는 서버 디바이스를 제공하는데 사용될 수 있다.
전자 시스템(800)은 버스(805) 또는 정보를 전달하기 위한 다른 통신 디바이스, 및 정보를 프로세싱할 수 있으며 버스(805)에 커플링된 프로세서(810)를 포함한다. 전자 시스템(800)이 단일 프로세서를 가지는 것으로 예시되지만, 전자 시스템(800)은 다수의 프로세서들 및/또는 코프로세서들을 포함할 수 있다. 전자 시스템(800)은 버스(805)에 커플링된 랜덤 액세스 메모리(RAM) 또는 다른 동적 저장 디바이스(820)(주 메모리라고 지칭됨)를 더 포함할 수 있으며, 프로세서(810)에 의해 실행될 수 있는 정보 및 명령들을 저장할 수 있다. 주 메모리(820)는 또한 프로세서(810)에 의한 명령들의 실행 동안 임시 변수들 또는 다른 중간 정보를 저장하는데 사용될 수 있다.
전자 시스템(800)은 또한 프로세서(810)에 대한 정적 정보 및 명령들을 저장할 수 있으며 버스(805)에 커플링되는 판독 전용 메모리(ROM) 및/또는 다른 정적 저장 디바이스(830)를 포함할 수 있다. 데이터 저장 디바이스(840)는 정보 및 명령들을 저장하기 위해 버스(805)에 커플링될 수 있다. 플래시 메모리 또는 자기 디스크 또는 광학 디스크 및 상응하는 드라이브와 같은 데이터 저장 디바이스(840)가 전자 시스템(800)에 커플링될 수 있다.
전자 시스템(800)은 또한, 사용자에게 정보를 디스플레이하기 위해, 디스플레이 디바이스(850), 예를 들어, 음극선관(CRT) 또는 액정 디스플레이(LCD)에 버스(805)를 통해 커플링될 수 있다. 전자 시스템(800)은 또한 프로세서(810)에 정보 및 명령 선택을 전달하기 위해 버스(805)에 커플링될 수 있는, 알파벳 및 다른 키들을 포함하는, 알파벳 입력 디바이스(860)를 포함할 수 있다. 또다른 타입의 사용자 입력 디바이스는 커서 제어(870), 예를 들어, 터치 패드, 마우스, 트랙볼, 또는 프로세서(810)에 지시 정보 및 명령 선택들을 전달하고 디스플레이(850) 상에서 커서 움직임을 제어하기 위한 커서 지시 키들이다.
전자 시스템(800)은 로컬 영역 네트워크와 같은 네트워크에 대한 액세스를 제공하기 위한 하나 이상의 네트워크 인터페이스(들)(880)를 더 포함할 수 있다. 네트워크 인터페이스(들)(880)은, 예를 들어, 하나 이상의 안테나(들)를 나타낼 수 있는 안테나(885)를 가지는 무선 네트워크 인터페이스를 포함할 수 있다. 전자 시스템(800)은 WiFi, 블루투스 및 셀룰러 텔레포니 인터페이스의 결합과 같은 다수의 무선 네트워크 인터페이스들을 포함할 수 있다. 네트워크 인터페이스(들)(880)은 또한, 예를 들어, 네트워크 케이블(887)을 통해 원격 디바이스들과 통신하기 위한 유선 네트워크 인터페이스를 포함할 수 있는데, 이는 예를 들어, 이더넷 케이블, 동축 케이블, 광섬유 케이블, 직렬 케이블 또는 병렬 케이블일 수 있다.
일 실시예에서, 네트워크 인터페이스(들)(880)은, 예를 들어, IEEE 802.11b 및/또는 IEEE 802.11g 표준에 따름으로써 로컬 영역 네트워크에 대한 액세스를 제공할 수 있고, 그리고/또는 무선 네트워크 인터페이스는, 예를 들어, 블루투스 표준들에 따름으로써, 개인 영역 네트워크에 대한 액세스를 제공할 수 있다. 다른 무선 네트워크 인터페이스들 및/또는 프로토콜들 역시 지원될 수 있다.
무선 LAN 표준들을 통한 통신에 추가하여, 또는 무선 LAN 표준들을 통한 통신 대신, 네트워크 인터페이스(들)(880)는, 예를 들어, 시분할 다중 액세스(TDMA) 프로토콜, 모바일 통신용 글로벌 시스템(GSM) 프로토콜, 코드분할 다중 액세스(CDMA) 프로토콜, 및/또는 임의의 다른 타입의 무선 통신 프로토콜을 사용하여 무선 통신을 제공할 수 있다.
본 명세서에서 "일 실시예" 또는 "실시예"에 대한 참조는 실시예와 관련하여 설명된 특정 피처, 구조 또는 특성이 본 발명의 적어도 하나의 실시예에 포함된다는 것을 의미한다. 본 명세서의 여러 부분에서 나타난 구문 "일 실시예에서"는 반드시 모두가 동일한 실시예를 지칭하는 것은 아니다.
전술된 명세서에서, 본 발명은 본 발명의 특정 실시예들에 관련하여 설명되었다. 그러나, 본 발명의 더 광범위한 사상 및 범위에서 벗어남이 없이 본 발명에 대한 다양한 수정들 및 변경들이 이루어질 수 있다는 점이 명백할 것이다. 명세서 및 도면들은, 그에 따라, 제한적인 의미라기보다는 예시적인 것으로 간주되어야 한다.
부록
후속하는 부록은 본 발명의 특정 실시예에 따른 프로토콜의 드래프트 규격이다. 이 부록에서의 특정 키워드들(예를 들어, 해야 한다, 하지 않아야 한다, 일 것이다, 이지 않을 것이다 등)의 사용이 이러한 특정 실시예에 적용되며, 본 개시내용에서 설명된 다른 실시예들에는 적용되지 않을 것이라는 점이 이해될 것이다.
요약
이 문헌은 HTTP를 통해 제한되지 않은 멀티미디어 데이터의 스트림들을 전송하기 위한 프로토콜을 설명한다. 이는 스트림들의 서버(송신자) 및 클라이언트들(수신자들)에 의해 취해질 동작들 및 파일들의 데이터 포맷을 특정한다. 이는 이러한 프로토콜의 버전 1.0을 설명한다.
콘텐츠 테이블
1. 개요
2. 요약
3. 재생 리스트 파일
3.1. 새로운 태그들
3.1.1. EXT-X-TARGETDURATION
3.1.2. EXT-X-MEDIA-SEQUENCE
3.1.3. EXT-X-KEY
3.1.4. EXT-X-PROGRAM-DATE-TIME
3.1.5. EXT-X-ALLOW-CACHE
3.1.6. EXT-X-ENDLIST
3.1.7. EXT-X-STREAM-INF
3.1.8. EXT-X-DISCONTINUITY
4. 미디어 파일들
5. 키 파일들
5.1. AES-128에 대한 IV
6. 클라이언트/서버 동작들
6.1. 서버 프로세스
6.1.1. 슬라이딩 윈도우 재생 리스트들
6.1.2. 암호화 미디어 파일들
6.1.3. 변경 스트림들의 제공
6.2. 클라이언트 프로세스
6.2.1. 재생 리스트 파일의 로딩
6.2.2. 재생 리스트 파일의 재생
6.2.3. 재생 리스트 파일의 리로딩
6.2.4. 로딩할 다음 파일의 결정
6.2.5. 암호화된 미디어 파일들의 재생
7. 예
7.1. 단순한 재생 리스트 파일
7.2. HTTPS를 사용하는, 슬라이딩 윈도우 재생 리스트
7.3. 암호화된 미디어 파일들을 가지는 재생 리스트 파일
7.4. 변경 재생 리스트 파일
8. 보안 고려
9. 레퍼런스
규범적 레퍼런스
정보적 레퍼런스
1. 개요
이 문헌은 HTTP [RFC2616]를 통해 제한되지 않은 멀티미디어 데이터의 스트림들을 전송하기 위한 프로토콜을 설명한다. 프로토콜은 미디어 데이터의 암호화 및 스트림의 대안적인 버전들(예를 들어, 비트레이트)의 제공을 지원한다. 미디어 데이터는 그것이 생성된 후 즉시 전송될 수 있으며, 이는 미디어 데이터가 거의 실시간으로 수신되는 것을 허용한다.
HTTP와 같은 관련 표준을 설명하는 외부 기준은 섹션 9에 나열된다.
2. 요약
멀티미디어 프레젠테이션은 추가적인 URI들의 순서화된 리스트인 재생 리스트 파일에 대한 URI[RFC3986]에 의해 특정된다. 재생 리스트 파일 내의 각각의 URI는 단일의 인접한 스트림의 세그먼트인 미디어 파일을 지칭한다.
스트림을 재생하기 위해, 클라이언트는 먼저 재생 리스트 파일을 획득하고, 이후, 재생 리스트 내의 각각의 미디어 파일을 재생한다. 그것은 추가적인 세그먼트들을 발견하기 위해 이 문헌에서 설명된 바와 같이 재생 리스트 파일을 리로딩한다.
본 문헌의 키워드들 "해야 한다","하지 않아야 한다", "요구되는", "일 것이다","이지 않을 것이다","해야 한다","하지 않아야 한다","추천되는","일 수 있다" 및 "선택적인"은 RFC 2119 [RFC2119]에 설명된 것과 같이 해석되어야 한다.
3. 재생 리스트 파일
재생 리스트들은 확장된 M3U 재생 리스트 파일들[M3U]임에 틀림없다. 이 문헌은 추가적인 태그들을 정의함으로써 M3U 파일 포맷을 확장한다.
M3U 재생 리스트는 개별 라인들로 구성된 텍스트 파일이다. 라인들은 LF 문자에 선행하는 단일 LF 문자 또는 CR 문자에 의해 종료된다. 각각의 라인은 URI, 블랭크이거나, 코멘트 문자 '#'으로 시작한다. URI들은 재생될 미디어 파일들을 식별한다. 블랭크 라인은 무시된다.
코멘트 문자 '#'으로 시작하는 라인들은 코멘트들 또는 태그들이다. 태그들은 #EXT로 시작한다. '#'로 시작하는 모든 다른 라인들은 코멘트들이며, 무시되어야 한다.
그 명칭이 .m3u8로 끝나고 그리고/또는 M3U 재생 리스트 파일들은 HTTP 콘텐츠 타입 "application/vnd.apple.mpegurl"을 가지는 M3U 재생 리스트 파일들은 UTF-8 [RFC3629]로 인코딩된다. 그 명칭이 .m3u로 끝나고 그리고/또는 HTTP 콘텐츠 타입 "RFC2616 audio/mpegurl"를 가지는 파일들은 US-ASCII [US_ASCII]로 인코딩된다.
구현예들은 그 명칭이 .m3u8인 재생 리스트 파일들을 생성해야 하거나, 또는 HTTP를 통해 전송되는 경우, 콘텐츠 타입 "application/vnd.apple.mpegurl"를 가져야 한다. 호환성을 위해, 구현예들은 그 명칭이 .m3u로 끝나고 그리고/또는 HTTP 콘텐츠 타입 RFC2616 "audio/mpegurl"를 가지는 재생 리스트 파일들을 생성할 수 있다.
확장된 M3U 파일 포맷은 2개의 태그들, 즉 EXTM3U 및 EXTINF를 정의한다. 확장된 M3U 파일은 #EXTM3U임에 틀림없는 제1 라인에 의해 기본 M3U 파일과 구별된다.
EXTINF는 후속하는 URI에 의해 식별되는 미디어 파일을 설명하는 레코드 마커이다. 각각의 미디어 파일 URI는 EXTINF 태그에 후속되어야 한다. 그 포맷은:
#EXTINF: <duration>,<title>
이며, "duration"은 미디어 파일의 지속기간을 초 단위로 특정하는 정수이다. 지속기간은 가장 가까운 정수로 반올림된다. 쉼표 다음의 라인의 나머지는 미디어 파일의 제목이다.
3.1. 새로운 태그들
이 문헌은 7개의 새로운 태그들, 즉, 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를 정의한다.
3.1.1. EXT-X-TARGETDURATION
EXT-X-TARGETDURATION 태그는 메인 프레젠테이션에 추가될 다음 미디어 파일의 대략적인 지속기간을 표시한다. 이는 재생 리스트 파일에 나타나야 한다. 그 포맷은:
#EXT-X-TARGETDURATION:<seconds>
이다. 미디어 파일의 실제 지속기간은 타겟 지속기간과는 약간 상이하다.
3.1.2. EXT-X-MEDIA-SEQUENCE
재생 리스트 내의 각각의 미디어 파일 URI는 고유한 시퀀스 번호를 가진다. URI의 시퀀스 번호는 그에 선행하는 URI의 시퀀스 번호 더하기 일(1)과 같다. EXT-X-MEDIA-SEQUENCE 태그는 재생 리스트 파일에 나타나는 제1 URI의 시퀀스 번호를 표시한다. 그 포맷은:
#EXT-X-MEDIA-SEQUENCE:<number>
이다. 만약 재생 리스트 파일이 EXT-X-MEDIA-SEQUENCE 태그를 포함하지 않는다면, 재생 리스트 내의 제1 URI의 시퀀스 번호는 1로 간주될 것이다.
EXT-X-MEDIA-SEQUENCE 태그의 핸들링에 대한 정보에 대해서는 섹션 6.2.1 및 섹션 6.2.4를 참조하라.
3.1.3. EXT-X-KEY
미디어 파일들은 암호화될 수 있다. EXT-X-KEY 태그는 후속하는 미디어 파일들을 암호해독하는데 필요한 정보를 제공한다. 그 포맷은:
#EXT-X-KEY: METHOD=<method>[,URI=" <URI>"]
이다. METHOD 파라미터는 암호화 방법을 특정한다. URI 파라미터는, 만약 존재한다면, 키를 획득하는 방법을 특정한다.
프로토콜의 버전 1.0은 2개의 암호화 방법들, 즉, NONE 및 AES-128을 정의한다. NONE의 암호화 방법은 미디어 파일들이 암호화되지 않음을 의미한다.
AES-128의 암호화 방법은 128 비트 키 및 PKCS7 패딩[RFC3852]를 가지고 어드밴스드 암호화 표준[AES_128]을 사용하여 암호화된다.
새로운 EXT-X-KEY는 임의의 이전 EXT-X-KEY를 대체한다.
만약 EXT-X-KEY 태그가 존재하지 않는다면, 미디어 파일들은 암호화되지 않는다.
키 파일의 포맷에 대해서는 섹션 5를, 그리고 미디어 일 암호화에 대한 추가적인 정보에 대해서는 섹션 5.1, 섹션 6.1.2 및 섹션 6.2.5를 참조하라.
3.1.4. EXT-X-PROGRAM-DATE-TIME
EXT-X-PROGRAM-DATE-TIME 태그는 다음 미디어 파일의 시작을 절대적인 날짜 및/또는 시간과 연관시킨다. 날짜/시간 표현은 ISO/IEC 8601:2004[ISO_8601] 이며, 시간 영역을 표시해야 한다. 예를 들면:
#EXT-X-PROGRAM-DATE-TIME:<YYYY-MM-DDThh:mm:ssZ>
3.1.5. EXT-X-ALLOW-CACHE
EXT-X-ALLOW-CACHE 태그는 클라이언트가 추후 반복 재생을 위해 다운로드된 미디어 파일들을 캐싱할 수 있는지의 여부를 표시한다. 그 포맷은:
#EXT-X- ALLOW-CACHE: <YES|NO>
3.1.6. EXT-X-ENDLIST
EXT-X-ENDLIST 태그는 더 이상의 미디어 파일들이 재생 리스트 파일에 추가되지 않을 것임을 표시한다. 그 포맷은:
#EXT-X-ENDLIST
3.1.7. EXT-X-STREAM-INF
EXT-X-STREAM-INF 태그는 재생 리스트 파일 내의 또다른 URI가 또다른 재생 리스트 파일을 식별하는 것을 표시한다. 그 포맷은:
#EXT-X-STREAM-INF: [attribute=value] [,attribute=value] *
<URI>
후속하는 속성들이 EXT-X-STREAM-INF 태그에 대해 정의된다:
BANDWIDTH=<n>
여기서 n은 스트림 비트 레이트의 대략적인 상한이며, 초당 비트수로 표현된다.
PROGRAM-ID=<i>
여기서, i는 재생 리스트 파일의 범위 내에서의 특정 프레젠테이션을 고유하게 식별하는 수이다.
재생 리스트 파일은 동일한 프레젠테이션의 변경 스트림들을 설명하기 위해 동일한 PROGRAM-ID를 가지는 다수의 EXT-X-STREAM-INF URI들을 포함할 수 있다.
CODECS="[format] [,format]*"
여기서 각각의 포맷은 재생 리스트 파일 내의 미디어 파일에 존재하는 미디어 샘플 타입을 특정한다.
유효 포맷 식별자들은 RFC 4281[RFC4281]에 의해 정의되는 ISO 파일 포맷 명칭 공간의 식별자들이다.
3.1.8. EXT-X-DISCONTINUITY
EXT-X-DISCONTINUITY 태그는 그것에 후속하는 미디어 파일이 그것에 선행하는 미디어 파일과는 상이한 특성들을 가짐을 표시한다. 변경될 수 있는 특정들의 세트는:
o 파일 포맷
o 트랙들의 수 및 타입
o 인코딩 파라미터들
o 인코딩 시퀀스
o 타임스탬프 시퀀스
이다. 그 포맷은:
#EXT-X-DISCONTINUITY
4. 미디어 파일들
재생 리스트 파일 내의 각각의 미디어 파일 URI는 전체 프레젠테이션의 세그먼트인 미디어 파일을 식별해야 한다. 각각의 미디어 파일은 MPEG-2 전송 스트림, MPEG-2 프로그램 스트림, 또는 MPEG-2 오디오 기본 스트림[ISO_13818]로서 포맷되어야 한다. 프레젠테이션 내의 모든 미디어 파일들은 동일한 포맷을 가져야 한다.
전송 스트림 파일들은 단일 MPEG-2 프로그램을 포함해야 한다. 각각의 파일의 시작에는 프로그램 연관 테이블 및 프로그램 맵 테이블이 있어야 한다. 비디오를 포함하는 파일은 비디오 디코더를 완전히 초기화하기 위해 충분한 정보 및 적어도 하나의 키 프레임을 가져야 한다.
클라이언트들은 적절한 서브세트를 선택함으로써 특정 타입(예를 들어, 오디오 또는 비디오)의 다수의 트랙들을 핸들링하도록 준비되어야 한다. 클라이언트들은 인지하지 못한 전송 스트림들 내의 개인 스트림들을 무시해야 한다.
미디어 파일 내부의 스트림 내의 샘플들에 대한, 그리고 다수의 미디어 파일에 대한 대응하는 스트림들 사이의 인코딩 파라미터들은 일정하게 유지되어야 한다. 그러나, 클라이언트들은 예를 들어, 해상도 변경을 수용하기 위해 비디오 콘텐츠를 스케일링함으로써 당면하게 되는 인코딩 변경들을 처리해야 한다.
5. 키 파일들
URI 파라미터를 가지는 EXT-X-KEY 태그는 키 파일을 식별한다. 키 파일은 재생 리스트 내의 후속적인 미디어 파일들을 암호해독하는데 사용되어야 하는 암호 키를 포함한다.
AES-128 암호화 방법은 16-옥텟 키들을 사용한다. 키 파일의 포맷은 바이너리 포맷인 이들 16 옥텟의 단순히 패킹된 어레이이다.
5.1. AES-128에 대한 IV
128 비트 AES는 암호화 및 암호해독시에 공급될 동일한 16-옥텟의 초기화 벡터(IV)를 요구한다. 이러한 IV를 변경하는 것은 암호화 강도를 증가시킨다.
암호화 방법 AES-128를 사용하는 경우, 구현예들은 미디어 파일들의 암호화 또는 암호해독시에 IV로서 미디어 파일의 시퀀스 번호를 사용할 것이다. 시퀀스 번호의 빅엔디안(big-endian) 바이너리 표현은 16 옥텟의 버퍼에 위치되어 영으로 (좌측에서) 패딩될 것이다.
6. 클라이언트/서버 동작들
이 섹션은 서버가 재생 리스트 및 미디어 파일들을 어떻게 생성하는지, 그리고 클라이언트가 이들을 어떻게 다운로드하고 재생해야 하는지를 설명한다.
6.1. 서버 프로세스
MPEG-2 스트림의 생성(production)은 이 문헌의 범위 밖이며, 이는 단순히 메인 프레젠테이션을 포함하는 인접 스트림의 소스를 추정한다.
서버는 스트림을 그 지속기간이 거의 동일한 개별 미디어 파일들로 분할해야 한다. 서버는 개별 미디어 파일들의 효과적 디코딩을 지원하는 포인트들에서, 예를 들어, 패킷 및 키 프레임 경계들 상에서, 스트림을 분할하려 해야 한다.
서버는 자신의 클라이언트들이 파일을 획득하게 할 각각의 미디어 파일에 대한 URI를 생성해야 한다.
서버는 재생 리스트 파일을 생성해야 한다. 재생 리스트 팡리은 섹션 3에서 설명된 바와 같은 포맷에 따라야 한다. 서버가 사용가능해지기를 바라는 각각의 미디어 파일에 대한 URI는 재생될 순서로 재생 리스트에 나타나야 한다. 전체 미디어 파일은 그것의 URI가 재생 리스트 파일에 있는 경우 클라이언트들에게 사용가능해야 한다.
재생 리스트 파일은 EXT-X-TARGETDURATION 태그를 포함해야 한다. 이는 메인 프레젠테이션에 추가될 다음 미디어 파일의 대략적인 지속기간을 표시해야 한다. 이 값은 전체 프레젠테이션에 대해 일정하게 유지되어야 한다. 통상적인 타겟 지속기간은 10초이다.
서버는 자신의 클라이언트들이 파일을 획득하게 할 재생 리스트 파일에 대한 URI를 생성해야 한다.
재생 리스트 파일에 대한 변경들은 클라이언트들의 관점으로부터 자동적으로 이루어져야 한다.
재생 리스트 내의 모든 미디어 파일 URI는 미디어 파일의 대략적인 지속기간을 표시하는 EXTINF 태그를 가지고 프리픽스되어야 한다.
서버는 자신의 URI를 EXT-X-PROGRAM-DATE-TIME 태그를 가지고 프리픽스함으로써 절대적인 날짜 및 시간을 미디어 파일과 연관시킨다. 날짜 및 시간의 값은 임의적이다.
재생 리스트가 프레젠테이션의 최종 미디어 파일을 포함하는 경우, 재생 리스트 파일은 EXT-X-ENDLIST 태그를 포함해야 한다.
서버가 전체 프레젠테이션을 삭제하기를 원하는 경우, 상기 서버는 재생 리스트 파일이 클라이언트들에 대해 사용가능하지 않게 해야 한다. 이는 재생 리스트 내의 모든 미디어 파일들이 삭제 시점에서 적어도 재생 리스트 파일의 지속기간 동안 클라이언트들에 대해 사용가능하게 유지된다는 점을 보장해야 한다.
6.1.1. 슬라이딩 윈도우 재생 리스트들
서버는 미디어 파일들의 가용성을 재생 리스트에 가장 최근에 추가된 미디어 파일들로 제한할 수 있다. 이렇게 하기 위해, 재생 리스트 파일은 항상 정확히 하나의 EXT-X-MEDIA-SEQUENCE 태그를 포함해야 한다. 그 값은 재생 리스트 파일로부터 삭제된 매 미디어 파일 URI에 대해 1씩 증분되어야 한다.
미디어 파일 URI들은 이들이 추가된 순서로 재생 리스트 파일로부터 삭제되어야 한다.
서버가 재생 리스트로부터 미디어 파일 URI를 삭제할 때, 미디어 파일은 미디어 파일의 지속기간 더하기 미디어 파일이 나타난 가장 긴 재생 리스트 파일의 지속기간과 동일한 시간 기간동안 클라이언트들에 대해 사용가능하게 유지되어야 한다. 재생 리스트 파일의 지속기간은 그것의 내에 있는 미디어 파일들의 지속기간들의 합이다.
서버가 미디어 파일을 삭제하려고 계획하는 경우, 이는 그것이 클라이언트들에 전달될 때 HTTP 만료 헤더가 계획된 타임-투-리브(time-to-live)를 반영함을 보장해야 한다.
서버는 EXT-X-ENDLIST 태그가 존재하지 않는 한 항상 재생 리스트 내에 적어도 3개의 메인 프레젠테이션 미디어 파일들을 포함해야 한다.
6.1.2. 미디어 파일들의 암호화
미디어 파일들이 암호화될 예정인 경우, 서버는 암호해독 키를 포함하는 허가된 클라이언트들로 하여금 키 파일을 획득하게 할 URI를 정의해야 한다. 키 파일은 섹션 5에 설명된 포맷에 따라야 한다.
서버는 키가 캐싱될 수 있음을 표시하기 위해 키 응답에 만료 헤더를 설정할 수 있다.
암호화 방법이 AES-128인 경우, AES-128 CBC 암호화가 개별 미디어 파일들에 적용될 것이다. 전체 파일이 암호화되어야 한다. 암호화 블럭 체인화는 미디어 파일들에 대해서는 적용되지 않아야 한다. 미디어 파일의 시퀀스 번호는 섹션 5.1에 설명된 바와 같은 IV로서 사용되어야 한다.
서버는 재생 리스트 파일 내의 자신의 URI에 가장 가깝게 선행하는 EXT-X-KEY 태그에 특정되는 방법을 사용하여 재생 리스트 내의 모든 미디어 파일을 암호화해야 한다. 그 방법이 NONE인 EXT-X-KEY 태그에 후속하는, 또는 EXT-X-KEY 태그에 후속하지 않는 미디어 파일들은 암호화되지 않아야 한다.
모든 EXT-X-KEY 태그의 URI는, 그 방법이 NONE이 아닌 한, 재생 리스트 파일에 나타나거나 나타났던 모든 다른 EXT-X-KEY 태그의 URI와는 구별되어야 한다. NONE의 방법을 가지는 EXT-X-KEY 태그는 URI 파라미터를 포함하지 않아야 한다.
재생 리스트 파일이 해당 키를 가지고 암호화된 미디어 파일에 대한 URI를 포함하는 경우, 서버는 재생 리스트 파일로부터 EXT-X-KEY 태그를 삭제하지 않아야 한다.
6.1.3. 변경 스트림들의 제공
서버는 동일한 프레젠테이션의 상이한 인코딩들을 제공하기 위해 다수의 재생 리스트 파일들을 공급할 수 있다. 서버가 이를 수행하는 경우, 서버는 클라이언트들로 하여금 인코딩들 사이에서 동적으로 스위칭하게 하기 위해 각각의 변경 스트림을 나열하는 변경 재생 리스트 파일을 제공해야 한다.
변경 재생 리스트들은 각각의 변경 스트림에 대해 EXT-X-STREAM-INF 태그를 포함해야 한다. 동일한 프레젠테이션에 대한 각각의 EXT-X-STREAM-INF 태그는 동일한 PROGRAM-ID 속성값을 가져야 한다. 각각의 프레젠테이션에 대한 PROGRAM-ID 값은 변경 재생 리스트 내에서 고유해야 한다.
EXT-X-STREAM-INF 태그가 CODECS 속성을 포함하는 경우, 그 속성값은 재생 리스트 파일에 나타나거나 나타날 임의의 미디어 파일에 존재하는 [RFC4281]에 의해 정의되는 모든 포맷을 포함해야 한다.
서버는 변경 스트림들을 생성할때 후속하는 제약들을 만족시켜야 한다:
각각의 변경 스트림은, 메인 프레젠테이션의 일부분이 아닌 콘텐츠를 포함하는, 동일한 콘텐츠로 구성되어야 한다.
서버는, 스트림들의 최소의 타겟 지속기간의 정확도 내에서, 모든 변경 스트림들에 대해 동일한 기간의 콘텐츠가 사용가능해지게 해야 한다.
변경 스트림들 내의 매칭 콘텐츠는 매칭 타임스탬프들을 가져야 한다. 이는 클라이언트들로 하여금 스트림들을 동기화하게 한다.
기본 오디오 스트림 파일들은 "com.apple.streaming.transportStreamTimestamp"의 소유자 식별자를 가지고 ID3 PRIV 태그[ID3]를 프리펜딩(prepend)함으로써 파일 내의 제1 샘플의 타임스탬프를 시그널링해야 한다. 바이너리 데이터는 빅에디안 8-옥텟 수로서 표현된 33-비트 MPEG-2 프로그램 기본 스트림 타임스탬프이어야 한다.
또한, 모든 변경 스트림들은 동일한 인코딩된 오디오 비트스트림을 포함해야 한다. 이는 클라이언트들로 하여금 가청 이상(audible glitching) 없이 스트림들 사이에서 스위칭하게 한다.
6.2. 클라이언트 프로세스
클라이언트가 재생 리스트 파일에 대한 URI를 획득하는 방법은 이 문헌의 범위 밖이며, 이렇게 수행되었다고 추정된다.
클라이언트는 URI로부터 재생 리스트 파일을 획득해야 한다. 이렇게 획득된 재생 리스트 파일이 변경 재생 리스트인 경우, 클라이언트는 변경 재생 리스트로부터 재생 리스트 파일을 획득해야 한다.
이 문헌은 클라이언트에 의한 변경 스트림들의 취급을 특정하지는 않는다.
6.2.1. 재생 리스트 파일의 로딩
재생 리스트 파일이 재생 리스트 URI로부터 로딩되거나 리로딩될 때마다:
클라이언트는 재생 리스트 파일이 #EXTM3U로 시작하는 것을 체크해야 하고, 만약 그렇지 않은 경우 계속하는 것을 거절해야 한다. 클라이언트는 자신이 인지하지 못하는 임의의 태그들을 무시해야 한다.
클라이언트는 섹션 6.2.4에 설명된 바와 같이 로딩할 다음 미디어 파일을 결정해야 한다.
재생 리스트 파일이 EXT-X-MEDIA-SEQUENCE 태그를 포함하는 경우, 클라이언트는 재생 리스트 파일 내의 각각의 미디어 파일이 재생 리스트 파일이 로딩된 시간 더하기 재생 리스트 파일의 지속기간에서 사용가능해지지 않을 것임을 가정해야 한다. 재생 리스트 파일의 지속기간은 재생 리스트 파일 내의 미디어 파일들의 지속기간들의 합이다.
6.2.2. 재생 리스트 파일의 재생
클라이언트는 재생이 시작될 때 재생 리스트로부터 어느 미디어 파일을 먼저 재생할 것인지를 선택할 것이다. 재생 리스트 파일이 EXT-X-ENDLIST 태그를 포함하는 경우, 재생 리스트 내의 임의의 파일이 먼저 재생될 수 있다. EXT-X-ENDLIST 태그가 존재하지 않는 경우, 재생 리스트 내의 마지막 및 마지막에서 두번째 파일들에 대해서를 제외한 임의의 파일이 먼저 재생될 수 있다.
재생할 제1 미디어 파일이 선택되면, 재생 리스트 내의 후속하는 미디어 파일들은 그들이 나타나는 순서로 로딩되고 로딩되는 순서로 재생되어야 한다.
클라이언트는 미디어 파일들이 레이턴시 및 스루풋에서의 임시 변경을 보상하기 위해 인터럽트되지 않은 재생을 요구받기에 앞서 미디어 파일들을 로딩하려고 시도해야 한다.
재생 리스트 파일이 EXT-X-ALLOW-CACHE 태그를 포함하고 그 값이 NO인 경우, 클라이언트는 다운로드된 미디어 파일들이 재생된 이후 다운로드된 미디어 파일들을 캐싱하지 않아야 한다. 그렇지 않은 경우, 클라이언트는 추후 반복 재생을 위해 다운로드된 미디어 파일들을 무기한으로 캐싱할 수 있다.
클라이언트는 프로그램 발신(origination) 시간을 사용자에게 디스플레이 하기 위해 EXT-X-PROGRAM-DATE-TIME 태그의 값을 사용할 수 있다. 그 값이 시간 영역 정보를 포함하는 경우, 클라이언트는 그것을 고려할 것이지만, 그 값이 시간 영역 정보를 포함하지 않는 경우, 클라이언트는 발신 시간 영역을 추론하지 않아야 한다.
클라이언트는 EXT-X-PROGRAM-DATE-TIME 태그의 값의 정확성 또는 일관성에 의존하지 않아야 한다.
6.2.3. 재생 리스트 파일의 리로딩
클라이언트는 재생 리스트 파일이 EXT-X-ENDLIST 태그를 포함하지 않는 한 재생 리스트 파일을 주기적으로 리로딩해야 한다.
그러나, 클라이언트는 이 섹션에 의해 특정되는 것보다 더 자주 재생 리스트 파일을 리로딩하려 시도하지 않아야 한다.
클라이언트가 최초로 재생 리스트 파일을 로딩하거나 또는 재생 리스트 파일을 리로딩하고 그것이 마지막으로 로딩되었던 이후 변경되었음을 발견하는 경우, 클라리언트는 재생 리스트 파일을 다시 리로딩하려 시도하기 전에 소정 시간 기간 동안 대기해야 한다. 이 기간은 초기 최소 리로딩 지연이라 지칭된다. 이는 클라이언트가 재생 리스트 파일을 로딩하기 시작하는 시간으로부터 측정된다.
초기 최소 리로딩 지연은, 어느 것이 더 적든, 재생 리스트 내의 마지막 미디어 파일의 지속기간 또는 타겟 지속기간의 3배이다. 미디어 파일 지속기간은 EXTINF 태그에 의해 특정된다.
클라이언트가 재생 리스트 파일을 리로딩하고 그것이 변경되지 않았음을 발견하는 경우, 클라이언트는 재시도 이전의 소정 시간 기간동안 대기해야 한다. 최소 지연은, 어느 것이 더 적든, 타겟 지속기간의 3배 또는 초기 최소 리로딩 지연의 배수이다. 이러한 배수는 제1 시도에 대해서는 0.5, 제2 시도에 대해서는 1.5, 그 다음에 대해서는 3.0이다.
6.2.4. 로딩할 다음 파일의 결정
클라이언트는 로딩할 다음 미디어 파일을 결정하기 위해 재생 리스트 파일이 로딩되거나 리로딩될 때마다 재생 리스트 파일을 검사해야 한다.
로딩할 제1 파일은, 섹션 6.2.2에서 설명된 바와 같이, 클라이언트가 처음 재생하기 위해 선택한 파일이어야 한다.
재생될 제1 파일이 로딩되고 재생 리스트 파일이 EXT-X-MEDIA-SEQUENCE 태그를 포함하지 않는 경우, 클라이언트는 현재 재생 리스트 파일이 그것이 원래 발견된 오프셋에서 마지막으로 로딩된 미디어 파일의 URI를 포함하는 것을 증명하고, 만약 포함하지 않는 경우 재생을 중지해야 한다. 로딩할 다음 미디어 파일은 재생 리스트에서 마지막으로 로딩된 URI에 후속하는 제1 미디어 파일 URI이어야 한다.
재생될 제1 파일 및 재생 리스트 파일이 EXT-X-MEDIA-SEQUENCE 태그를 포함하는 경우, 로딩할 다음 미디어 파일은 로딩된 마지막 미디어 파일의 시퀀스 번호보다 훨씬 더 큰 최저의 시퀀스 번호를 가지는 미디어 파일일 것이다.
6.2.5. 암호화된 미디어 파일들의 재생
재생 리스트 파일이 키 파일 URI를 특정하는 EXT-X-KEY 태그를 포함하는 경우, 클라이언트는 해당 키 파일을 획득하고 또다른 EXT-X-KEY 태그에 당면할 때까지 EXT-X-KEY 태그에 후속하는 모든 미디어 파일들을 암호해독하기 위해 키 파일 내의 키를 사용해야 한다.
암호화 방법이 AES-128인 경우, AES-128 CBC 암호해독은 개별 미디어 파일들에 적용될 것이다. 전체 파일은 암호해독되어야 한다. 암호 블럭 체인은 미디어 파일들에 대해 적용되지 않아야 한다. 미디어 파일의 시퀀스 번호는 섹션 5.1에 설명된 바와 같이 IV로서 사용되어야 한다.
암호화 방법이 NONE인 경우, 클라이언트는 또다른 EXT-X-KEY 태그에 당면할 때까지 EXT-X-KEY 태그에 후속하는 모든 미디어 파일들을 (암호화되지 않은) 평문(cleartext)으로서 취급해야 한다.
7. 예들
이 섹션은 몇몇 예시적인 재생 리스트 파일들을 포함한다.
7.1. 단순 재생 리스트 파일
Figure 112011062599265-pat00008
7.2. HTTPS를 사용하는, 슬라이딩 윈도우 재생 리스트
Figure 112011062599265-pat00009
7.3. 암호화된 미디어 파일들을 가지는 재생 리스트 파일
Figure 112011062599265-pat00010
Figure 112011062599265-pat00011

7.4. 변경 재생 리스트 파일
Figure 112011062599265-pat00012
8. 보안 고려
프로토콜이 일반적으로 데이터를 전송하기 위해 HTTP를 사용하므로, 대부분 동일한 보안 고려를 적용한다. RFC 2616의 섹션 15[RFC2616]를 참조하라.
미디어 파일 파서(parser)들은 통상적으로 "퍼징" 공격들을 받기 쉽다. 클라이언트들은 언제 서버로부터 수신된 파일들이 파싱되어 비-순응 파일들이 거절되는지를 살펴야 한다.
재생 리스트 파일들은 클라이언트가 임의의 엔티티들의 네트워크 요청들을 만들기 위해 사용할 URI들을 포함한다. 클라이언트들은 버퍼 오버플로우를 방지하기 위한 응답들을 범위-체크해야 한다. 또한, RFC 3986의 보안 고려 섹션을 참조하라[RFC3986].
클라이언트들은 서비스 거부 공격들에 기여하는 것을 회피하기 위해 URI에 의해 느리게(lazily) 식별되는 리소스들을 로딩해야 한다.
HTTP 요청들은 개인 사용자 데이터를 포함할 수 있는 세션 상태("쿠키들")을 종종 포함한다. 구현예들은 RFC 2965에 의해 특정되는 종료 규칙[RFC2965] 및 쿠키 제한에 따라야 한다. 또한 RFC 2965의 보안 고려 섹션 및 RFC 2964 [RFC2964]를 참조하라.
암호화 키들은 URI에 의해 특정된다. 이들 키들의 전달은 보안 영역 또는 세션 쿠키와 함께 TLS [RFC5246]를 통한 HTTP(이전에 SSL)과 같은 메커니즘에 의해 보안되어야 한다.
9. 레퍼런스
규범적 레퍼런스
Figure 112011062599265-pat00013
Figure 112011062599265-pat00014
Figure 112011062599265-pat00015
정보적 레퍼런스
Figure 112011062599265-pat00016

Claims (26)

  1. 데이터를 스트리밍하기 위하여 컴퓨터에 의해 수행되는 방법으로서,
    서버 디바이스에서, 데이터 스트림을 다중 미디어 파일들로 분할하는 단계 - 상기 다중 미디어 파일들 각각은 전송 프로토콜 순응 포맷(transfer protocol compliant format)으로 메모리에 개별 파일들로서 저장됨 - ;
    복수의 유니버설 리소스 표시자(URI) 및 복수의 태그를 가지는 재생 리스트 파일(play list file)을 생성하는 단계 - 상기 복수의 URI는 상기 데이터 스트림을 재생성하기 위한 상기 다중 미디어 파일들의 순서(ordering)를 표시함 - ; 및
    상기 다중 미디어 파일들에 대한 변경들에 대응하는 업데이트된 재생 리스트 파일을 생성하는 단계 - 상기 업데이트된 재생 리스트 파일은 업데이트된 데이터 스트림을 재생성하기 위한 업데이트된 다중 미디어 파일들의 순서를 표시하는 복수의 업데이트된 URI를 포함함 -
    를 포함하는 컴퓨터에 의해 수행되는 방법.
  2. 실행가능한 명령어들을 저장한 컴퓨터-판독가능 매체로서, 상기 명령어들은 실행될 때 하나 이상의 프로세서들로 하여금:
    서버 디바이스에서, 데이터 스트림을 다중 미디어 파일들로 분할하는 단계와 - 상기 다중 미디어 파일들 각각은 전송 프로토콜 순응 포맷으로 메모리에 개별 파일들로서 저장됨 -;
    복수의 유니버설 리소스 표시자(URI) 및 복수의 태그를 가지는 재생 리스트 파일을 생성하는 단계와 - 상기 복수의 URI는 상기 데이터 스트림을 재생성하기 위한 상기 다중 미디어 파일들의 순서를 표시함 - ; 및
    상기 다중 미디어 파일들에 대한 변경들에 대응하는 업데이트된 재생 리스트 파일을 생성하는 단계 - 상기 업데이트된 재생 리스트 파일은 업데이트된 데이터 스트림을 재생성하기 위한 업데이트된 다중 미디어 파일들의 순서를 표시하는 복수의 업데이트된 URI를 포함함 -
    를 포함하는 방법을 수행하도록 야기하는 컴퓨터-판독가능 매체.
  3. 제2항에 있어서,
    상기 다중 미디어 파일들에 대한 변경들은 하나 이상의 미디어 파일들의 추가를 포함하고, 상기 업데이트된 재생 리스트 파일은 상기 다중 미디어 파일들 및 상기 추가된 하나 이상의 미디어 파일들에 대한 URI들을 포함하는 컴퓨터-판독가능 매체.
  4. 제2항에 있어서,
    상기 다중 미디어 파일들에 대한 변경들은 하나 이상의 미디어 파일들에 대한 수정들을 포함하고, 상기 업데이트된 재생 리스트 파일은 상기 다중 미디어 파일들에 대한 URI들을 포함하고, 상기 복수의 태그 중의 태그들 중 하나 이상은 상기 하나 이상의 미디어 파일들에 대한 수정들을 반영하도록 업데이트되는 컴퓨터-판독가능 매체.
  5. 제2항에 있어서,
    상기 다중 미디어 파일들에 대한 변경들은 하나 이상의 나머지 미디어 파일들을 초래하는 상기 다중 미디어 파일들로부터의 하나 이상의 선택된 미디어 파일들의 삭제 및 하나 이상의 추가적인 미디어 파일들의 추가를 포함하고, 상기 업데이트된 재생 리스트 파일은 상기 나머지 미디어 파일들에 대한 URI들을 포함하고, 상기 업데이트된 데이터 스트림은 단일 프로그램에 대한 연속적인(contiguous) 시간 기반의 컨텐츠 스트림이고, 상기 전송 프로토콜은 HTTP 순응 프로토콜인 컴퓨터-판독가능 매체.
  6. 제2항에 있어서,
    상기 업데이트된 재생 리스트는 선택된 시간 기간의 만료시 생성되는 컴퓨터-판독가능 매체.
  7. 제6항에 있어서,
    상기 선택된 시간 기간은 상기 재생 리스트 파일 내의 태그들 중 하나의 속성에 기반하는 컴퓨터-판독가능 매체.
  8. 제2항에 있어서,
    상기 방법은,
    상기 재생 리스트 파일에 추가될 다음 차례의 미디어 파일의 지속기간을 결정하는 단계;
    상기 재생 리스트 파일이 상기 지속기간을 표시하는 태그를 포함하도록 하는 단계를 더 포함하는
    컴퓨터-판독가능 매체.
  9. 제8항에 있어서,
    상기 태그는 EXT-X-TARGETDURATION 태그를 포함하는 컴퓨터-판독가능 매체.
  10. 제2항에 있어서,
    상기 방법은,
    상기 재생 리스트 파일 내의 URI들 중 하나 이상에 대한 시퀀스 번호들을 결정하는 단계; 및
    상기 재생 리스트 파일이 상기 시퀀스 번호들 중 하나 이상을 표시하는 하나 이상의 태그들을 포함하게 하는 단계를 더 포함하는
    컴퓨터-판독가능 매체.
  11. 제10항에 있어서,
    상기 하나 이상의 태그들은 하나 이상의 EXT-X-MEDIA-SEQUENCE 태그들을 포함하는 컴퓨터-판독가능 매체.
  12. 제2항에 있어서,
    상기 방법은,
    상기 미디어 파일들을 수신할 클라이언트 디바이스가 재생 이후 상기 미디어 파일들을 저장하도록 허가(authorize)되는지의 여부를 결정하는 단계, 및
    상기 재생 리스트로 하여금 상기 클라이언트 디바이스가 재생 이후 상기 미디어 파일들을 저장하도록 허가되는지의 여부를 표시하는 태그를 포함하도록 야기하는 단계를 더 포함하는
    컴퓨터-판독가능 매체.
  13. 서버 디바이스에서, 데이터 스트림을 다중 미디어 파일들로 분할하기 위한 수단 - 상기 다중 미디어 파일들 각각은 전송 프로토콜 순응 포맷으로 메모리에 개별 파일들로서 저장됨 - ;
    복수의 유니버설 리소스 표시자(URI) 및 복수의 태그를 가지는 재생 리스트 파일을 생성하기 위한 수단 - 상기 복수의 URI는 상기 데이터 스트림을 재생성하기 위한 상기 다중 미디어 파일들의 순서를 표시함 - ; 및
    상기 다중 미디어 파일들에 대한 변경들에 대응하는 업데이트된 재생 리스트 파일을 생성하기 위한 수단 - 상기 업데이트된 재생 리스트 파일은 업데이트된 데이터 스트림을 재생성하기 위한 업데이트된 다중 미디어 파일들의 순서를 표시하는 복수의 업데이트된 URI를 포함함 -
    을 포함하는 장치.
  14. 제13항에 있어서,
    상기 다중 미디어 파일들에 대한 변경들은 하나 이상의 미디어 파일들의 추가를 포함하고, 상기 업데이트된 재생 리스트 파일은 상기 다중 미디어 파일들 및 상기 추가된 하나 이상의 미디어 파일들에 대한 URI들을 포함하는 장치.
  15. 제13항에 있어서,
    상기 다중 미디어 파일들에 대한 변경들은 상기 다중 미디어 파일들 중 하나 이상에 대한 수정들을 포함하고, 상기 업데이트된 재생 리스트 파일은 상기 다중 미디어 파일들에 대한 URI들을 포함하고, 상기 복수의 태그 중의 태그들 중 하나 이상은 상기 다중 미디어 파일들 중 하나 이상에 대한 수정들을 반영하도록 업데이트되는 장치.
  16. 제13항에 있어서,
    상기 다중 미디어 파일들에 대한 변경들은 하나 이상의 나머지 미디어 파일들을 초래하는 상기 다중 미디어 파일들로부터의 하나 이상의 선택된 미디어 파일들의 삭제 및 하나 이상의 추가적인 미디어 파일들의 추가를 포함하고, 상기 업데이트된 재생 리스트 파일은 상기 나머지 미디어 파일들에 대한 URI들을 포함하고, 상기 업데이트된 데이터 스트림은 단일 프로그램에 대한 연속적인 시간 기반의 컨텐츠 스트림이고, 상기 전송 프로토콜은 HTTP 순응 프로토콜이고, 상기 업데이트된 재생 리스트는 선택된 시간 기간의 만료시 생성되고, 상기 선택된 시간 기간은 상기 재생 리스트 파일 내의 태그들 중 하나의 속성에 기반하는 장치.
  17. 데이터를 스트리밍하기 위하여 컴퓨터에 의해 수행되는 방법으로서,
    전송 프로토콜 순응 포맷으로 메모리에 다중 미디어 파일들을 개별 파일들로서 저장하는 단계 - 상기 다중 미디어 파일들은 연속적인 시간 기반 데이터 스트림으로부터 분할된 것임 -;
    상기 전송 프로토콜을 사용하여 클라이언트 디바이스에게 재생 리스트 파일을 전송하는 단계 - 상기 재생 리스트 파일은 복수의 유니버설 리소스 표시자(URI) 및 복수의 태그를 가지고, 상기 복수의 URI는 상기 데이터 스트림을 재생성하기 위한 상기 다중 미디어 파일들의 순서를 표시함 - ;
    상기 복수의 URI 중 하나 이상을 이용하는 상기 클라이언트 디바이스로부터의 하나 이상의 요청들에 응답하여 상기 전송 프로토콜을 사용하여 상기 클라이언트 디바이스에게 상기 다중 미디어 파일들 중 하나 이상을 전송하는 단계;
    상기 클라이언트 디바이스에게 업데이트된 재생 리스트 파일을 전송하는 단계 - 상기 업데이트된 재생 리스트 파일은 상기 다중 미디어 파일들에 대한 변경들에 대응하고, 상기 업데이트된 재생 리스트 파일은 업데이트된 데이터 스트림을 재생성하기 위한 업데이트된 다중 미디어 파일들의 순서를 표시하는 복수의 업데이트된 URI를 포함함 -
    를 포함하는 컴퓨터에 의해 수행되는 방법.
  18. 실행가능한 명령어들을 저장한 컴퓨터 판독가능 매체로서, 상기 명령어들은 실행될 때 하나 이상의 프로세서들로 하여금:
    전송 프로토콜 순응 포맷으로 메모리에 다중 미디어 파일들을 개별 파일들로서 저장하는 단계와 - 상기 다중 미디어 파일들은 연속하는 시간 기반 데이터 스트림으로부터 분할된 것임 -;
    비-스트리밍 전송 프로토콜(non-streaming transfer protocol)을 사용하여 클라이언트 디바이스에게 재생 리스트 파일을 전송하는 단계와 - 상기 재생 리스트 파일은 복수의 유니버설 리소스 표시자(URI) 및 복수의 태그를 가지고, 상기 복수의 URI는 상기 데이터 스트림을 재생성하기 위한 상기 다중 미디어 파일들의 순서를 표시함 - ;
    상기 복수의 URI 중 하나 이상을 이용하는 상기 클라이언트 디바이스로부터의 하나 이상의 요청들에 응답하여 상기 전송 프로토콜을 사용하여 상기 클라이언트 디바이스에게 상기 다중 미디어 파일들 중 하나 이상을 전송하는 단계와;
    상기 클라이언트 디바이스에게 업데이트된 재생 리스트 파일을 전송하는 단계 - 상기 업데이트된 재생 리스트 파일은 상기 다중 미디어 파일들에 대한 변경들에 대응하고, 상기 업데이트된 재생 리스트 파일은 업데이트된 데이터 스트림을 재생성하기 위한 업데이트된 다중 미디어 파일들의 순서를 표시하는 복수의 업데이트된 URI를 포함함 -
    를 포함하는 방법을 수행하도록 야기하는 컴퓨터-판독가능 매체.
  19. 제18항에 있어서,
    상기 다중 미디어 파일들에 대한 변경들은: (a) 하나 이상의 미디어 파일들의 추가 - 상기 업데이트된 재생 리스트 파일은 상기 다중 미디어 파일들 및 상기 추가된 하나 이상의 미디어 파일들에 대한 URI들을 포함함 - ; (b) 상기 하나 이상의 미디어 파일들에 대한 수정들 - 상기 업데이트된 재생 리스트 파일은 상기 다중 미디어 파일들에 대한 URI를 포함하고, 상기 복수의 태그 중의 태그들 중 하나 이상은 상기 하나 이상의 미디어 파일들에 대한 수정들을 반영하도록 업데이트됨 - ; 또는 (c) 하나 이상의 나머지 미디어 파일들을 초래하는 상기 다중 미디어 파일들로부터의 하나 이상의 선택된 미디어 파일들의 삭제 및 하나 이상의 추가적인 미디어 파일들의 추가 - 상기 업데이트된 재생 리스트 파일은 상기 나머지 미디어 파일들에 대한 URI들을 포함함 - 중 적어도 하나를 포함하고, 상기 업데이트된 데이터 스트림은 단일 프로그램에 대한 연속적인 시간 기반 컨텐츠 스트림이고, 상기 전송 프로토콜은 HTTP 순응 프로토콜인 컴퓨터-판독가능 매체.
  20. 제18항에 있어서,
    상기 업데이트된 재생 리스트는 선택된 시간 기간의 만료시 생성되고, 상기 선택된 시간 기간은 상기 재생 리스트 파일 내의 태그들 중 하나의 속성에 기반하며, 상기 전송 프로토콜은 HTTP 순응 프로토콜인 컴퓨터-판독가능 매체.
  21. 전송 프로토콜 순응 포맷으로 메모리에 다중 미디어 파일들을 개별 파일들로서 저장하기 위한 수단 - 상기 다중 미디어 파일들은 연속하는 시간 기반 데이터 스트림으로부터 분할된 것임 -;
    상기 전송 프로토콜을 사용하여 클라이언트 디바이스에게 재생 리스트 파일을 전송하기 위한 수단 - 상기 재생 리스트 파일은 복수의 유니버설 리소스 표시자(URI) 및 복수의 태그를 가지고, 상기 복수의 URI는 상기 데이터 스트림을 재생성하기 위한 상기 다중 미디어 파일들의 순서를 표시함 - ;
    상기 복수의 URI 중 하나 이상을 이용하는 상기 클라이언트 디바이스로부터의 하나 이상의 요청들에 응답하여 상기 전송 프로토콜을 사용하여 상기 클라이언트 디바이스에게 상기 다중 미디어 파일들 중 하나 이상을 전송하기 위한 수단;
    상기 클라이언트 디바이스에게 업데이트된 재생 리스트 파일을 전송하기 위한 수단 - 상기 업데이트된 재생 리스트 파일은 상기 다중 미디어 파일들에 대한 변경들에 대응하고, 상기 업데이트된 재생 리스트 파일은 업데이트된 데이터 스트림을 재생성하기 위한 업데이트된 다중 미디어 파일들의 순서를 표시하는 복수의 업데이트된 URI를 포함함 -
    을 포함하는 장치.
  22. 데이터를 스트리밍하기 위하여 컴퓨터에 의해 수행되는 방법으로서,
    클라이언트 디바이스에 의해, 전송 프로토콜을 사용하여 재생 리스트 파일을 요청하는 단계;
    상기 요청하는 단계에 응답하여, (1) 프로그램의 연속하는 시간 기반 데이터 스트림에 대한 복수의 미디어 파일을 표시하는 유니버설 리소스 표시자(URI)들 및 (2) 상기 복수의 미디어 파일에 관련된 파라미터들을 가지는 복수의 태그를 가지는 상기 재생 리스트 파일을 수신하는 단계;
    상기 재생 리스트에 표시된 순서로 상기 미디어 파일들 중 하나 이상을 요청하고 수신하는 단계;
    상기 미디어 파일들에 대한 변경들에 대응하는 업데이트된 재생 리스트 파일을 수신하는 단계 - 상기 업데이트된 재생 리스트 파일은 업데이트된 복수의 미디어 파일의 순서를 표시하는 복수의 업데이트된 URI를 포함함 -
    를 포함하는 컴퓨터에 의해 수행되는 방법.
  23. 실행가능한 명령어들을 저장한 기계 판독가능 저장 매체로서, 상기 명령어들은 실행될 때 하나 이상의 프로세서들로 하여금:
    클라이언트 디바이스에 의해, 전송 프로토콜을 사용하여 재생 리스트 파일을 요청하는 단계;
    상기 요청하는 단계에 응답하여, 프로그램의 연속하는 시간 기반 데이터 스트림에 대한 복수의 미디어 파일을 표시하는 유니버설 리소스 표시자(URI)들 및 상기 복수의 미디어 파일에 관련된 파라미터들을 가지는 복수의 태그를 구비한 상기 재생 리스트 파일을 수신하는 단계;
    상기 재생 리스트에 표시된 순서로 상기 미디어 파일들 중 하나 이상을 요청하고 수신하는 단계;
    상기 미디어 파일들에 대한 변경들에 대응하는 업데이트된 재생 리스트 파일을 수신하는 단계 - 상기 업데이트된 재생 리스트 파일은 업데이트된 복수의 미디어 파일의 순서를 표시하는 복수의 업데이트된 URI를 포함함 -
    를 포함하는 방법을 수행하도록 야기하는 기계 판독가능 저장 매체.
  24. 제23항에 있어서,
    상기 방법은:
    상기 업데이트된 재생 리스트로부터 상기 프로그램의 프리젠테이션을 생성하는 단계를 더 포함하는
    기계 판독가능 저장 매체.
  25. 제24항에 있어서,
    상기 미디어 파일들에 대한 변경들은: (a) 하나 이상의 미디어 파일들의 추가 - 상기 업데이트된 재생 리스트 파일은 상기 업데이트된 복수의 미디어 파일에 대한 URI를 포함함 - ; (b) 상기 복수의 미디어 파일 중 하나 이상에 대한 수정들; 또는 (c) 상기 재생 리스트 파일로부터의 미디어 파일들의 제1 세트의 삭제 및 상기 재생 리스트 파일에의 하나 이상의 추가적인 미디어 파일들의 추가 중 적어도 하나를 포함하고, 상기 전송 프로토콜은 HTTP 순응 프로토콜이고, 상기 업데이트된 재생 리스트는 상기 재생 리스트 파일 내의 태그들 중 하나의 속성에 기초하는 시간의 만료시에 상기 클라이언트 장치에 의해 요청되는 기계 판독가능 저장 매체.
  26. 데이터 프로세싱 시스템으로서,
    클라이언트 디바이스에 의해, 전송 프로토콜을 사용하여 재생 리스트 파일을 요청하기 위한 수단;
    상기 요청에 응답하여, 프로그램의 연속하는 시간 기반 데이터 스트림에 대한 복수의 미디어 파일을 표시하는 유니버설 리소스 표시자(URI)들 및 상기 복수의 미디어 파일에 관련된 파라미터들을 가지는 복수의 태그를 구비한 상기 재생 리스트 파일을 수신하기 위한 수단;
    상기 재생 리스트에 표시된 순서로 상기 미디어 파일들 중 하나 이상을 요청하고 수신하기 위한 수단;
    상기 미디어 파일들에 대한 변경들에 대응하는 업데이트된 재생 리스트 파일을 수신하기 위한 수단 - 상기 업데이트된 재생 리스트 파일은 업데이트된 복수의 미디어 파일의 순서를 표시하는 복수의 업데이트된 URI를 포함함 -
    을 포함하는 데이터 프로세싱 시스템.
KR1020117018907A 2008-12-31 2009-12-28 비-스트리밍 프로토콜을 통해 멀티미디어 데이터를 스트리밍하기 위한 방법 KR101233582B1 (ko)

Applications Claiming Priority (21)

Application Number Priority Date Filing Date Title
US14211008P 2008-12-31 2008-12-31
US61/142,110 2008-12-31
US16069309P 2009-03-16 2009-03-16
US61/160,693 2009-03-16
US16103609P 2009-03-17 2009-03-17
US61/161,036 2009-03-17
US16752409P 2009-04-07 2009-04-07
US61/167,524 2009-04-07
US12/479,732 2009-06-05
US12/479,690 US20100169458A1 (en) 2008-12-31 2009-06-05 Real-Time or Near Real-Time Streaming
US12/479,732 US8099476B2 (en) 2008-12-31 2009-06-05 Updatable real-time or near real-time streaming
US12/479,690 2009-06-05
US12/479,698 2009-06-05
US12/479,698 US8099473B2 (en) 2008-12-31 2009-06-05 Variant streams for real-time or near real-time streaming
US12/479,735 US20100169303A1 (en) 2008-12-31 2009-06-05 Playlists for real-time or near real-time streaming
US12/479,735 2009-06-05
US24064809P 2009-09-08 2009-09-08
US61/240,648 2009-09-08
US28882809P 2009-12-21 2009-12-21
US61/288,828 2009-12-21
PCT/US2009/069624 WO2010078281A2 (en) 2008-12-31 2009-12-28 Real-time or near real-time streaming

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
KR1020117018058A Division KR101215232B1 (ko) 2008-12-31 2009-12-28 비-스트리밍 프로토콜을 통해 멀티미디어 데이터를 스트리밍하기 위한 방법

Publications (2)

Publication Number Publication Date
KR20110098864A KR20110098864A (ko) 2011-09-01
KR101233582B1 true KR101233582B1 (ko) 2013-02-15

Family

ID=41800575

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020117018907A KR101233582B1 (ko) 2008-12-31 2009-12-28 비-스트리밍 프로토콜을 통해 멀티미디어 데이터를 스트리밍하기 위한 방법
KR1020117018058A KR101215232B1 (ko) 2008-12-31 2009-12-28 비-스트리밍 프로토콜을 통해 멀티미디어 데이터를 스트리밍하기 위한 방법

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020117018058A KR101215232B1 (ko) 2008-12-31 2009-12-28 비-스트리밍 프로토콜을 통해 멀티미디어 데이터를 스트리밍하기 위한 방법

Country Status (11)

Country Link
EP (2) EP3300372B1 (ko)
JP (2) JP5384664B2 (ko)
KR (2) KR101233582B1 (ko)
CN (2) CN102308547B (ko)
AU (1) AU2009335146B2 (ko)
BR (1) BRPI0923917B1 (ko)
CA (1) CA2748548C (ko)
MX (1) MX2011006973A (ko)
RU (1) RU2481720C2 (ko)
SG (1) SG172820A1 (ko)
WO (1) WO2010078281A2 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20200002771A (ko) * 2019-12-31 2020-01-08 네이버 주식회사 지연 생중계를 위한 방법 및 시스템
KR102063624B1 (ko) * 2017-12-07 2020-01-09 네이버 주식회사 지연 생중계를 위한 방법 및 시스템

Families Citing this family (94)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US8099473B2 (en) 2008-12-31 2012-01-17 Apple Inc. Variant streams for real-time or near real-time streaming
US8578272B2 (en) 2008-12-31 2013-11-05 Apple Inc. Real-time or near real-time streaming
US8260877B2 (en) 2008-12-31 2012-09-04 Apple Inc. Variant streams for real-time or near real-time streaming to provide failover protection
US8156089B2 (en) 2008-12-31 2012-04-10 Apple, Inc. Real-time or near real-time streaming with compressed playlists
EP2417743B1 (en) * 2009-04-09 2019-06-05 Telefonaktiebolaget LM Ericsson (publ) Methods and arrangements for creating and handling media files
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
US8805963B2 (en) 2010-04-01 2014-08-12 Apple Inc. Real-time or near real-time streaming
US8560642B2 (en) 2010-04-01 2013-10-15 Apple Inc. Real-time or near real-time streaming
GB201105502D0 (en) * 2010-04-01 2011-05-18 Apple Inc Real time or near real time streaming
CN102882845B (zh) 2010-04-07 2016-07-13 苹果公司 实时或准实时流传输
US9721254B2 (en) 2010-06-28 2017-08-01 Hulu, LLC Method and apparatus for providing streaming media programs and targeted advertisements using multiple advertisement version segments
EP2586197B1 (en) * 2010-06-28 2018-02-07 Hulu LLC Method and apparatus for providing streaming media programs and targeted advertisements compatibly with http live streaming
US9448723B2 (en) 2010-06-28 2016-09-20 Hulu, LLC Method and apparatus for intuitive navigation of a media program
US8954597B2 (en) 2010-06-28 2015-02-10 Hulu, LLC Method and apparatus for synchronizing paused playback across platforms
US9131033B2 (en) * 2010-07-20 2015-09-08 Qualcomm Incoporated Providing sequence data sets for streaming video data
US9456015B2 (en) * 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
ES2654333T3 (es) 2010-08-10 2018-02-13 Telefonaktiebolaget Lm Ericsson (Publ) Control de sesión para la transmisión de flujos de medios
US9313084B2 (en) 2010-09-01 2016-04-12 Vuclip (Singapore) Pte. Ltd. Systems and methods for client-side media chunking
KR101754414B1 (ko) * 2010-09-06 2017-07-07 한국전자통신연구원 스트리밍 컨텐츠 제공 장치 및 방법
US8589583B2 (en) * 2010-09-08 2013-11-19 Hulu, Inc. Method and apparatus for adaptive bit rate switching
CN102404646A (zh) * 2010-09-08 2012-04-04 苏州尚嘉信息技术有限公司 一种无线电视直播系统及其直播方法
US8468262B2 (en) * 2010-11-01 2013-06-18 Research In Motion Limited Method and apparatus for updating http content descriptions
EP2646936B1 (en) * 2011-01-11 2018-11-07 Apple Inc. Real-time or near real-time streaming
US9049494B2 (en) * 2011-01-31 2015-06-02 Cbs Interactive, Inc. Media playback control
US8583818B2 (en) * 2011-01-31 2013-11-12 Cbs Interactive Inc. System and method for custom segmentation for streaming video
US20120198492A1 (en) * 2011-01-31 2012-08-02 Cbs Interactive, Inc. Stitching Advertisements Into A Manifest File For Streaming Video
US20120213404A1 (en) 2011-02-18 2012-08-23 Google Inc. Automatic event recognition and cross-user photo clustering
GB2483125B (en) * 2011-02-25 2012-09-26 British Sky Broadcasting Ltd Media system
CN102130958A (zh) * 2011-03-22 2011-07-20 宋健 一种基于http协议的小文件切片模式的视频直播方法与系统
US8856283B2 (en) 2011-06-03 2014-10-07 Apple Inc. Playlists for real-time or near real-time streaming
US8843586B2 (en) * 2011-06-03 2014-09-23 Apple Inc. Playlists for real-time or near real-time streaming
JP5905957B2 (ja) 2011-06-08 2016-04-20 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ 空間的にセグメント化されたコンテンツの配信
CN102843335B (zh) * 2011-06-20 2015-09-09 华为技术有限公司 流媒体内容的处理方法和设备
EP2566172A1 (en) * 2011-09-02 2013-03-06 Thomson Licensing Method and apparatus for adaptive transcoding of multimedia stream
US9357275B2 (en) * 2011-09-06 2016-05-31 Qualcomm Incorporated Network streaming of coded video data
EP2764700A4 (en) 2011-10-04 2015-07-29 Google Inc SYSTEM AND METHOD FOR THE RECEIVING OF VIDEO STREAMS
GB201205761D0 (en) * 2012-03-30 2012-05-16 Sony Corp A method and device
US20130262693A1 (en) * 2012-04-02 2013-10-03 Chris Phillips Methods and apparatus for segmenting, distributing, and resegmenting adaptive rate content streams
CN102857797B (zh) * 2012-04-12 2014-03-19 天脉聚源(北京)传媒科技有限公司 一种视频播放的后台控制方法及系统
US9015468B2 (en) 2012-04-26 2015-04-21 Futurewei Technologies, Inc. System and method for signaling segment encryption and key derivation for adaptive streaming
EP2834984B1 (en) 2012-04-27 2016-03-30 Huawei Technologies Co., Ltd. Support for short cryptoperiods in template mode
WO2014004907A2 (en) * 2012-06-27 2014-01-03 Google Inc. System and method for determining appropriate content for an event content stream
US9391792B2 (en) 2012-06-27 2016-07-12 Google Inc. System and method for event content stream
WO2014008637A1 (en) * 2012-07-11 2014-01-16 Nokia Corporation Method and apparatus for interacting with a media presentation description that describes a summary media presentation and an original media presentation
US8495675B1 (en) * 2012-07-30 2013-07-23 Mdialog Corporation Method and system for dynamically inserting content into streaming media
US20140052824A1 (en) * 2012-08-20 2014-02-20 Qualcomm Incorporated Conveying state information for streaming media
US9418370B2 (en) 2012-10-23 2016-08-16 Google Inc. Obtaining event reviews
US10028123B2 (en) 2012-11-05 2018-07-17 Nokia Technologies Oy Method and apparatus for network-controlled proximity device to device discovery and communication
JP6161260B2 (ja) * 2012-11-14 2017-07-12 キヤノン株式会社 送信装置、受信装置、送信方法、受信方法、及び、プログラム
US9537917B2 (en) * 2012-11-20 2017-01-03 Google Technology Holdings LLC Method and apparatus for streaming media content to client devices
JP6139872B2 (ja) * 2012-12-10 2017-05-31 キヤノン株式会社 情報処理装置及びその制御方法、プログラム、記憶媒体、並びに、映像処理システム
JP6116240B2 (ja) 2012-12-28 2017-04-19 キヤノン株式会社 送信装置、送信方法、及びプログラム
JP6218379B2 (ja) * 2012-12-28 2017-10-25 キヤノン株式会社 送信装置、受信装置、送信方法、受信方法、及び、プログラム
JP5984707B2 (ja) * 2013-02-13 2016-09-06 三菱電機ビルテクノサービス株式会社 映像データ配信装置、映像データ配信システム及びプログラム
CN104113790B (zh) * 2013-04-16 2017-09-15 优视科技有限公司 一种基于安卓操作系统的视频播放方法及装置
US20140351871A1 (en) * 2013-05-22 2014-11-27 Microsoft Corporation Live media processing and streaming service
JP6257197B2 (ja) * 2013-07-18 2018-01-10 キヤノン株式会社 情報処理装置及びその制御方法、プログラム、並びに記憶媒体
JP6173085B2 (ja) * 2013-07-18 2017-08-02 キヤノン株式会社 情報処理装置及びその制御方法、プログラム、並びに記憶媒体
CN104346338A (zh) * 2013-07-24 2015-02-11 腾讯科技（深圳）有限公司 应用于终端的多媒体信息显示方法和装置
JP6289076B2 (ja) * 2013-12-18 2018-03-07 キヤノン株式会社 情報処理装置、情報処理方法及びプログラム
AU2014382177B2 (en) * 2014-02-06 2017-03-16 Lg Electronics Inc. Method for performing Wi-Fi display service and device for same
US9635077B2 (en) * 2014-03-14 2017-04-25 Adobe Systems Incorporated Low latency live video streaming
CN103945283B (zh) * 2014-04-02 2017-10-10 网易（杭州）网络有限公司 一种数字内容保护方法和设备
KR102004837B1 (ko) 2014-04-09 2019-07-29 엘지전자 주식회사 방송 전송 장치, 방송 수신 장치, 방송 전송 장치의 동작 방법 및 방송 수신 장치의 동작 방법
JP6541309B2 (ja) 2014-06-23 2019-07-10 キヤノン株式会社 送信装置、送信方法、及びプログラム
JP2016091436A (ja) 2014-11-08 2016-05-23 キヤノン株式会社 通信装置、通信方法、及び、プログラム
US9954795B2 (en) * 2015-01-12 2018-04-24 Cisco Technology, Inc. Resource allocation using CCN manifests
US9813477B2 (en) * 2015-01-26 2017-11-07 T-Mobile Usa, Inc. Adjusting quality level of media streaming
EP3057266A1 (en) 2015-02-11 2016-08-17 Thomson Licensing Distribution of bandwidth in a network
JP6482413B2 (ja) * 2015-07-01 2019-03-13 テレフオンアクチーボラゲット エルエム エリクソン（パブル） メディアストリーム伝送のためのセッション制御
US9866923B2 (en) * 2015-08-28 2018-01-09 Cbs Interactive Inc. Digital channel integration system
JP6750227B2 (ja) * 2015-09-08 2020-09-02 船井電機株式会社 情報機器および配信装置
WO2017058826A1 (en) 2015-09-28 2017-04-06 Google Inc. Sharing images and image albums over a communication network
CN105451079A (zh) * 2015-11-23 2016-03-30 深圳市芯智科技有限公司 一种在广告机上实现多个视频节目源无缝播放的方法
US10261963B2 (en) * 2016-01-04 2019-04-16 Gracenote, Inc. Generating and distributing playlists with related music and stories
US10666961B2 (en) * 2016-01-08 2020-05-26 Qualcomm Incorporated Determining media delivery event locations for media transport
KR101743228B1 (ko) * 2016-01-22 2017-06-05 네이버 주식회사 스트리밍 장치 및 그 방법, 이를 이용한 스트리밍 서비스 시스템 및 컴퓨터로 판독 가능한 기록매체
CN105704504B (zh) * 2016-01-28 2021-02-12 腾讯科技（深圳）有限公司 视频直播中插入推送信息的方法、装置、设备及存储介质
RU2610681C1 (ru) * 2016-02-18 2017-02-14 Акционерное общество "Научно-исследовательский институт вычислительных комплексов им. М.А. Карцева" (АО "НИИВК им. М.А. Карцева") Способ сохранения информации в аварийных регистраторах
KR102491247B1 (ko) * 2016-04-22 2023-01-25 에스케이텔레콤 주식회사 네트워크 상에서 실시간 멀티미디어 서비스의 품질을 제어하는 방법 및 이를 위한 장치
CN105872599A (zh) * 2016-04-26 2016-08-17 乐视控股（北京）有限公司 一种提供、下载视频的方法及设备
WO2018212815A1 (en) 2017-05-17 2018-11-22 Google Llc Automatic image sharing with designated users over a communication network
US10484726B2 (en) * 2017-06-02 2019-11-19 Apple Inc. Playlist error tags for delivery and rendering of streamed media
JP6422546B2 (ja) * 2017-09-26 2018-11-14 キヤノン株式会社 送信装置、送信方法、及び、プログラム
JP6612313B2 (ja) * 2017-12-20 2019-11-27 テレフオンアクチーボラゲット エルエム エリクソン（パブル） メディアストリーム伝送のためのセッション制御
US11240280B2 (en) * 2019-02-19 2022-02-01 Apple Inc. Low latency streaming media
US20200296462A1 (en) 2019-03-11 2020-09-17 Wci One, Llc Media content presentation
US11197052B2 (en) * 2019-07-12 2021-12-07 Apple Inc. Low latency streaming media
US11509949B2 (en) * 2019-09-13 2022-11-22 Disney Enterprises, Inc. Packager for segmenter fluidity
US20220272394A1 (en) * 2021-02-19 2022-08-25 Rovi Guides, Inc. Systems and methods for improved adaptive video streaming

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20040231004A1 (en) 2003-05-13 2004-11-18 Lg Electronics Inc. HTTP based video streaming apparatus and method in mobile communication system
US20080059532A1 (en) 2001-01-18 2008-03-06 Kazmi Syed N Method and system for managing digital content, including streaming media

Family Cites Families (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020002039A1 (en) * 1998-06-12 2002-01-03 Safi Qureshey Network-enabled audio device
EP0984584A1 (en) * 1998-09-04 2000-03-08 America Online, Inc. Internet multimedia broadcast system
RU2272318C2 (ru) * 1999-08-03 2006-03-20 Вижионартс Инк. Считываемый компьютером носитель записи, на котором записан файл изображения, устройство для изготовления носителя записи, носитель, на котором записана программа для создания файла изображения, устройство для передачи файла изображения, устройство для обработки файла изображения и носитель, на котором записана программа обработки файла изображения
WO2001038993A1 (en) * 1999-11-29 2001-05-31 Binary Broadcasting Corporation Secure digital music distribution
EP1113642A3 (en) * 1999-12-16 2004-04-14 Actv, Inc. Enhanced video programming system and method using a local host for network communication
US7260564B1 (en) * 2000-04-07 2007-08-21 Virage, Inc. Network video guide and spidering
US6925495B2 (en) * 2000-07-13 2005-08-02 Vendaria Media, Inc. Method and system for delivering and monitoring an on-demand playlist over a network using a template
AU2001283004A1 (en) * 2000-07-24 2002-02-05 Vivcom, Inc. System and method for indexing, searching, identifying, and editing portions of electronic multimedia files
US7640320B2 (en) * 2001-01-18 2009-12-29 Yahoo! Inc. Method and system for managing digital content, including streaming media
US20020147634A1 (en) * 2001-01-31 2002-10-10 Ronald Jacoby System for dynamic generation of online streaming media advertisements
US7356838B2 (en) * 2001-06-06 2008-04-08 Yahoo! Inc. System and method for controlling access to digital content, including streaming media
US7076478B2 (en) * 2001-06-26 2006-07-11 Microsoft Corporation Wrapper playlists on streaming media services
JP2004013283A (ja) * 2002-06-04 2004-01-15 Hitachi Ltd コンテンツ配信方法及びコンテンツ配信装置
US6812994B2 (en) * 2002-12-04 2004-11-02 Eastman Kodak Company Streamlined methods and systems for scheduling and handling digital cinema content in a multi-theatre environment
KR100520115B1 (ko) * 2002-12-27 2005-10-10 삼성전자주식회사 플레이리스트 관리 장치 및 방법
US7349663B1 (en) * 2003-04-24 2008-03-25 Leave A Little Room Foundation Internet radio station and disc jockey system
US20040260835A1 (en) * 2003-06-23 2004-12-23 Welk Douglas L. Automotive internet radio system
US20050005025A1 (en) * 2003-07-04 2005-01-06 Michael Harville Method for managing a streaming media service
US7912218B2 (en) * 2003-07-04 2011-03-22 Nxp B.V. Method of broadcasting multimedia content via distribution network
JP4513328B2 (ja) * 2003-07-17 2010-07-28 株式会社日立製作所 コンテンツの配信方法、コンテンツの受信方法、および、ｉｄ検出方法
JP2007528140A (ja) * 2003-10-10 2007-10-04 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 配信ネットワークを介したマルチメディアコンテンツの配信方法
JP2005195836A (ja) * 2004-01-07 2005-07-21 Matsushita Electric Ind Co Ltd 車載装置および配信システム
CN1813251A (zh) * 2004-03-22 2006-08-02 网飞亚技术公司 基于流的内容分发网络系统、以及用于分割、合并和检索文件的方法
JP2005275593A (ja) * 2004-03-23 2005-10-06 Equos Research Co Ltd 情報処理装置
US7818444B2 (en) * 2004-04-30 2010-10-19 Move Networks, Inc. Apparatus, system, and method for multi-bitrate content streaming
WO2006007651A1 (en) * 2004-07-23 2006-01-26 Commonwealth Scientific And Industrial Research Organisation Method and system for integrating browsing histories with media playlists
JP4751611B2 (ja) * 2004-12-28 2011-08-17 株式会社ドワンゴ コンテンツ配信システム、配信サーバ、視聴情報管理サーバ、視聴情報管理方法、ログ生成方法、及び、コンピュータプログラム
JP2006237663A (ja) * 2005-02-21 2006-09-07 Dowango:Kk ストリーミング配信システム、ストリーミング配信方法およびプログラム
US9130799B2 (en) * 2005-03-23 2015-09-08 Alcatel Lucent System and method for effectuating playlist seeking with respect to digital multimedia content from a network node
JP4731214B2 (ja) * 2005-06-17 2011-07-20 ソニー エリクソン モバイル コミュニケーションズ， エービー 携帯端末装置、コンテンツ配信装置、コンテンツ配信システム、及び通信プログラム
JP2007004896A (ja) * 2005-06-23 2007-01-11 Toshiba Corp 情報記憶媒体、情報転送方法、情報再生方法、及び情報記録方法
JP5058998B2 (ja) * 2005-07-18 2012-10-24 ウェスト ファーマシューティカル サービシズ インコーポレイテッド 通気手段を有する自動注入シリンジ
US20070055743A1 (en) * 2005-09-02 2007-03-08 Pirtle Ross M Remote control media player
US20070174147A1 (en) * 2005-12-30 2007-07-26 Realnetworks System and method for updating a playlist based upon ratings
JP2007158414A (ja) * 2005-11-30 2007-06-21 Matsushita Electric Ind Co Ltd コンテンツ配信システム及びコンテンツ仲介サーバ
JPWO2007111312A1 (ja) * 2006-03-28 2009-08-13 パイオニア株式会社 コンテンツ配信システム、サーバ装置、コンテンツ配信方法およびプログラム
US20070255846A1 (en) * 2006-04-28 2007-11-01 Wee Susie J Distributed storage of media data
JP4821499B2 (ja) * 2006-08-21 2011-11-24 ブラザー工業株式会社 コンテンツ分散保存システム、フレーム取得方法、及びノード装置等
KR100928090B1 (ko) * 2006-10-30 2009-11-23 주식회사 한랭크닷컴 웹상의 텍스트를 음악으로 재생하는 저작 시스템 및 방법
WO2008058259A2 (en) * 2006-11-08 2008-05-15 Mywaves, Inc. An apparatus and method for dynamically providing web-based multimedia to a mobile phone
WO2008081415A2 (en) * 2006-12-28 2008-07-10 France Telecom Media file server
US20080209066A1 (en) * 2007-01-24 2008-08-28 Spio Mary A Method and apparatus for providing continuous playback of media programs at a remote end user computer
JP4389179B2 (ja) * 2007-02-27 2009-12-24 ブラザー工業株式会社 メディア接続装置、メディア接続システム、メディア接続システムの操作方法
CN101083628B (zh) * 2007-07-20 2010-08-18 中兴通讯股份有限公司 一种动态转发媒体源的方法
DE102007041143B4 (de) * 2007-08-30 2010-04-08 Siemens Enterprise Communications Gmbh & Co. Kg Verfahren zum Analysieren von gleichzeitig übertragenen, verschlüsselten Datenströmen in IP-Netzwerken
WO2009046435A1 (en) * 2007-10-05 2009-04-09 Aharon Mizrahi System and method for enabling search of content
CN101448009B (zh) * 2007-11-27 2013-02-20 鸿富锦精密工业（深圳）有限公司 音乐同步播放系统、方法及音乐播放器
CN100583699C (zh) * 2007-12-19 2010-01-20 北京创毅视讯科技有限公司 一种前端处理系统及其业务的调度方法

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080059532A1 (en) 2001-01-18 2008-03-06 Kazmi Syed N Method and system for managing digital content, including streaming media
US20040231004A1 (en) 2003-05-13 2004-11-18 Lg Electronics Inc. HTTP based video streaming apparatus and method in mobile communication system

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102063624B1 (ko) * 2017-12-07 2020-01-09 네이버 주식회사 지연 생중계를 위한 방법 및 시스템
KR20200002771A (ko) * 2019-12-31 2020-01-08 네이버 주식회사 지연 생중계를 위한 방법 및 시스템
KR102085072B1 (ko) 2019-12-31 2020-03-05 네이버 주식회사 지연 생중계를 위한 방법 및 시스템

Also Published As

Publication number Publication date
AU2009335146B2 (en) 2012-12-20
RU2481720C2 (ru) 2013-05-10
CA2748548C (en) 2015-02-24
JP5384664B2 (ja) 2014-01-08
SG172820A1 (en) 2011-08-29
AU2009335146A1 (en) 2011-07-21
CN102611701A (zh) 2012-07-25
CN102308547A (zh) 2012-01-04
WO2010078281A3 (en) 2011-01-13
EP3300372A2 (en) 2018-03-28
BRPI0923917A2 (pt) 2016-02-16
RU2011132008A (ru) 2013-02-10
EP3300372B1 (en) 2022-01-26
KR20110098864A (ko) 2011-09-01
CN102308547B (zh) 2014-11-19
MX2011006973A (es) 2011-12-06
AU2009335146A8 (en) 2011-12-01
KR101215232B1 (ko) 2012-12-24
EP2392112A2 (en) 2011-12-07
JP2012138083A (ja) 2012-07-19
EP3300372A3 (en) 2018-05-02
JP5296859B2 (ja) 2013-09-25
JP2012514276A (ja) 2012-06-21
BRPI0923917B1 (pt) 2021-05-25
CA2748548A1 (en) 2010-07-08
WO2010078281A2 (en) 2010-07-08
KR20110102495A (ko) 2011-09-16
CN102611701B (zh) 2015-07-15

Similar Documents

Publication Publication Date Title
KR101233582B1 (ko) 비-스트리밍 프로토콜을 통해 멀티미디어 데이터를 스트리밍하기 위한 방법
US8762351B2 (en) Real-time or near real-time streaming with compressed playlists
US8260877B2 (en) Variant streams for real-time or near real-time streaming to provide failover protection
US9558282B2 (en) Playlists for real-time or near real-time streaming
KR20130118944A (ko) 실시간 또는 준 실시간 스트리밍
AU2016202709B2 (en) Real-time or near real-time streaming
AU2011203178B2 (en) Real-time or near real-time streaming
AU2013201691B2 (en) Method for streaming multimedia data over a non-streaming protocol

Legal Events

Date Code Title Description
A107 Divisional application of patent
A201 Request for examination
E902 Notification of reason for refusal
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20160119

Year of fee payment: 4

FPAY Annual fee payment

Payment date: 20170119

Year of fee payment: 5

FPAY Annual fee payment

Payment date: 20180118

Year of fee payment: 6

FPAY Annual fee payment

Payment date: 20190116

Year of fee payment: 7