KR101704619B1 - 네트워크 스트리밍에 대한 가변 미디어 데이터 결정 - Google Patents

네트워크 스트리밍에 대한 가변 미디어 데이터 결정 Download PDF

Info

Publication number
KR101704619B1
KR101704619B1 KR1020157023984A KR20157023984A KR101704619B1 KR 101704619 B1 KR101704619 B1 KR 101704619B1 KR 1020157023984 A KR1020157023984 A KR 1020157023984A KR 20157023984 A KR20157023984 A KR 20157023984A KR 101704619 B1 KR101704619 B1 KR 101704619B1
Authority
KR
South Korea
Prior art keywords
segment
segments
media data
requests
probe requests
Prior art date
Application number
KR1020157023984A
Other languages
English (en)
Other versions
KR20150114997A (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
Application filed by 퀄컴 인코포레이티드 filed Critical 퀄컴 인코포레이티드
Publication of KR20150114997A publication Critical patent/KR20150114997A/ko
Application granted granted Critical
Publication of KR101704619B1 publication Critical patent/KR101704619B1/ko

Links

Images

Classifications

    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • 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/602—
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L27/00—Modulated-carrier systems
    • H04L27/0012—Modulated-carrier systems arrangements for identifying the type of modulation
    • 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/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H04L65/4076—
    • H04L65/4084—
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • 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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • 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/762—Media network packet handling at the source 
    • 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
    • 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/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4305—Synchronising client clock from received content stream, e.g. locking decoder clock with encoder clock, extraction of the PCR packets
    • 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/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

클라이언트 디바이스는 미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하도록 구성된 하나 또는 그 초과의 프로세서들을 포함하고, 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 미디어 데이터를 제공하고, 세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 복수의 프로브 요청들에 대한 응답들을 분석하고, 그리고 라이브 스트리밍 서비스에 따라 세그먼트 이용 가능성 윈도우의 결정된 좌측 에지 및 결정된 우측 에지에 기초하여 세그먼트 이용 가능성 윈도우 내의 세그먼트에 대한 요청을 전송한다.

Description

네트워크 스트리밍에 대한 가변 미디어 데이터 결정{DETERMINING AVAILABLE MEDIA DATA FOR NETWORK STREAMING}
[0001] 본 출원은 2013년 2월 4일 출원된 미국 예비 출원 일련 번호 61/760,382의 우선권을 주장하고, 상기 미국 예비 출원의 전체 내용들은 이로써 인용에 의해 포함된다.
[0002] 본 개시는 인코딩된 비디오 데이터의 운송(transport)에 관한 것이다.
[0003] 디지털 비디오 능력들은 디지털 텔레비전들, 디지털 다이렉트 브로드캐스트 시스템(digital direct broadcast system)들, 무선 브로드캐스트 시스템들, PDA(personal digital assistant)들, 랩톱 또는 데스크톱 컴퓨터들, 디지털 카메라들, 디지털 레코딩 디바이스들, 디지털 미디어 플레이어들, 비디오 게이밍 디바이스들, 비디오 게임 콘솔들, 셀룰러 또는 위상 라디오 전화들, 비디오 원격회의 디바이스들 등을 포함하는 다양한 디바이스들에 포함될 수 있다. 디지털 비디오 디바이스들은 디지털 비디오 정보를 보다 효과적으로 전송 및 수신하기 위하여, MPEG-2, MPEG-4, ITU-T H.263 또는 ITU-T H.264/MPEG-4, 파트 10, AV(Advanced Video Coding), 및 그런 표준들의 확장들에 의해 정의된 표준들에 설명된 것들 같은 비디오 압축 기술들을 구현한다.
[0004] 비디오 압축 기술들은 비디오 시퀀스들에 내재하는 리던던시(redundancy)를 감소 또는 제거하기 위하여 공간 예측 및/또는 시간 예측을 수행한다. 블록 기반 비디오 코딩에 대해, 비디오 프레임 또는 슬라이스는 매크로블록들로 분할될 수 있다. 각각의 매크로블록은 추가로 분할될 수 있다. 인트라-코딩(I) 프레임 또는 슬라이스에서 매크로블록들은 이웃하는 매크로블록들에 관하여 공간 예측을 사용하여 인코딩된다. 인터-코딩(P 또는 B) 프레임 또는 슬라이스에서 매크로블록들은 동일한 프레임 또는 슬라이스에서 이웃하는 매크로블록들에 관하여 공간 예측을 사용하거나 다른 기준 프레임들에 관하여 시간 예측을 사용할 수 있다.
[0005] 비디오 데이터가 인코딩된 후, 비디오 데이터는 송신 또는 스토리지를 위하여 패킷화될 수 있다. 비디오 데이터는 ISO(International Organization for Standardization) 기반 미디어 파일 포맷 및 이의 확장들, 이를테면 AVC 같은 다양한 표준들 중 임의의 표준을 따르는 비디오 파일로 어셈블리될 수 있다.
[0006] 일반적으로, 본 개시는 표현의 라이브 네트워크 스트리밍 동안 미디어 콘텐츠의 표현의 이용 가능한 세그먼트들을 결정하기 위한 기술들을 설명한다. 클라이언트 디바이스는 HTTP HEAD 요청들 같은, 표현의 세그먼트들의 시퀀스에 대한 복수의 프로브(probe) 요청들을 전송하고, 이용 가능한 세그먼트들과 이용 가능하지 않은 세그먼트들 사이의 경계를 결정하기 위하여 이들 요청들에 대한 응답들을 분석할 수 있다. 이 경계는 세그먼트 이용 가능성 윈도우의 "에지(edge)"로 지칭될 수 있다. 몇몇 예들에서, 클라이언트 디바이스는 이전 요청들에 대한 HTTP 404 에러들을 포함하는 다수의 응답들에 응답하여 프로브 요청들의 이런 시퀀스를 전송할 수 있다. HTTP 에러들은, 클라이언트 디바이스의 클럭이 세그먼트들의 광고된 이용 가능성에 관하여(예를 들어, 서버 디바이스의 클럭에 관하여) 드리프트되는 것을 가리킬 수 있다. 프로브 요청들은 클라이언트 디바이스로 하여금, 미디어 데이터의 하나 또는 그 초과의 세그먼트들이 리트리벌(retrieval)을 위해 이용 가능한지를 결정하게 할 수 있다.
[0007] 일 예에서, 미디어 데이터를 리트리빙하는 방법은 미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하는 단계 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 미디어 데이터를 제공함 ―, 세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 복수의 프로브 요청들에 대한 응답들을 분석하는 단계, 및 라이브 스트리밍 서비스에 따라, 세그먼트 이용 가능성 윈도우의 결정된 좌측 에지 및 결정된 우측 에지에 기초하여 세그먼트 이용 가능성 윈도우 내의 세그먼트에 대한 요청을 전송하는 단계를 포함한다.
[0008] 다른 예에서, 미디어 데이터를 리트리빙하기 위한 디바이스는 미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하고 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 미디어 데이터를 제공함 ―, 세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 복수의 프로브 요청들에 대한 응답들을 분석하고, 그리고 라이브 스트리밍 서비스에 따라, 세그먼트 이용 가능성 윈도우의 결정된 좌측 에지 및 결정된 우측 에지에 기초하여 세그먼트 이용 가능성 윈도우 내의 세그먼트에 대한 요청을 전송하도록 구성된 하나 또는 그 초과의 프로세서들을 포함한다.
[0009] 다른 예에서, 미디어 데이터를 리트리빙하기 위한 디바이스는 미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하기 위한 수단 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 미디어 데이터를 제공함 ―, 세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 복수의 프로브 요청들에 대한 응답들을 분석하기 위한 수단, 및 라이브 스트리밍 서비스에 따라, 세그먼트 이용 가능성 윈도우의 결정된 좌측 에지 및 결정된 우측 에지에 기초하여 세그먼트 이용 가능성 윈도우 내의 세그먼트에 대한 요청을 전송하기 위한 수단을 포함한다.
[0010] 다른 예에서, 컴퓨터-판독가능 스토리지 매체는 실행될 때, 프로세서로 하여금, 미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하고 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 미디어 데이터를 제공함 ―, 세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 복수의 프로브 요청들에 대한 응답들을 분석하고, 그리고 라이브 스트리밍 서비스에 따라, 세그먼트 이용 가능성 윈도우의 결정된 좌측 에지 및 결정된 우측 에지에 기초하여 세그먼트 이용 가능성 윈도우 내의 세그먼트에 대한 요청을 전송하게 하는 명령들이 저장되어 있다.
[0011] 하나 또는 그 초과의 예들의 상세(detail)들은 첨부 도면들 및 하기 설명에 설명된다. 다른 피처들, 목적들, 및 장점들은 설명 및 도면들, 및 청구항들로부터 명백할 것이다.
[0012] 도 1은 네트워크를 통해 미디어 데이터를 스트리밍하기 위한 기술들을 구현하는 예시적 시스템을 예시하는 블록도이다.
[0013] 도 2는 예시적인 멀티미디어 콘텐츠의 엘리먼트들을 예시하는 개념도이다.
[0014] 도 3은 세그먼트들의 세트에 대한 예시적 세그먼트 이용 가능성 윈도우를 예시하는 개념도이다.
[0015] 도 4는 프로빙 요청들이 세그먼트 이용 가능성 윈도우를 결정하기 위하여 전송될 수 있는 세그먼트들을 예시하는 개념도이다.
[0016] 도 5-도 9는 도 4의 프로빙 요청들에 대한 다양한 가능한 응답 패턴들을 예시하는 개념도들이다.
[0017] 도 10은 비-균일하게 이격된 프로빙 시퀀스의 예를 예시하는 개념도이다.
[0018] 도 11은 본 개시의 기술들에 따라 세그먼트 이용 가능성 윈도우의 하나 또는 그 초과의 에지들을 결정하기 위한 예시적 방법을 예시하는 흐름도이다.
[0019] 일반적으로, 본 개시는 DASH(dynamic adaptive streaming over HTTP) 환경 같은, 미디어 데이터를 스트리밍하기 위한 환경에서 이용 가능한 미디어 데이터를 결정하기 위한 기술들을 설명한다. 이들 기술들은 HLS(HTTP Live Streaming) 또는 다른 라이브 스트리밍 서비스들을 지원하기 위하여 사용될 수 있다. 비록 DASH 및 HLS에 관하여 일반적으로 논의되지만, 본 개시의 기술들은 다른 네트워크 스트리밍 프로토콜들에 적용 가능할 수 있다. DASH는 http://standards.iso.org/ittf/PubliclyAvailableStandards/c057623_ISO_IEC_23009-1_2012.zip에서 이용 가능한 2012년 4월 1일 ISO/IEC 23009-1:2012, "Information technology ― DASH(Dynamic adaptive streaming over HTTP) - Part 1: Media presentation description and segment formats"에서 특정된다.
[0020] 본 개시의 기술들은 일반적으로 미디어 데이터가 리트리벌을 위해 이용 가능한지를 결정하는 것에 관한 것이다. 몇몇 예들에서, 미디어 데이터는 특정 시간에서 이용 가능한 것으로 광고될 수 있지만, 클라이어언트 디바이스의 클럭은, 미디어 데이터가 이용 가능하게 된 시간을 광고하는 클럭과 동기화되지 않을 수 있다. 예를 들어, 클라이언트 디바이스의 클럭은, 미디어 데이터가 이용 가능할 때를 가리키기 위하여 사용된 클럭(예를 들어, 서버 디바이스의 클럭 또는 콘텐츠 준비 엔티티의 클럭) 앞뒤로 드리프트될 수 있다.
[0021] 클라이언트 디바이스는 미디어 데이터가 이용 가능할 때를 나타내는 클럭 시간에 관하여 클라이언트 디바이스의 클럭이 드리프트되는지를 결정할 뿐 아니라, 어떤 미디어 데이터가 현재 이용 가능한지를 결정하기 위하여 본 개시의 기술들을 구현하도록 구성될 수 있다. 본 개시의 기술들에 따라, 클라이언트 디바이스는 복수의 요청들을 서버 디바이스에 전송하도록 구성될 수 있고, 여기서 요청들 각각은 미디어 데이터의 세그먼트들의 시퀀스 내의 개별 세그먼트에 대응한다. 요청들은 세그먼트들에 대해 작은 양의 데이터만 리트리브하거나, 아무런 데이터도 리트리브하지 않도록 형식화(formulate)될 수 있다. 예를 들어, 요청들은 HTTP HEAD 요청들, 또는 대응하는 세그먼트들의 비교적 작은 부분들에 대한 부분 GET 요청들(예를 들어, 100 바이트들)을 포함할 수 있다. 즉, 요청들은 세그먼트에 대한 전체 데이터 양보다 상당히 작은 세그먼트의 데이터의 양에 대한 요청들을 포함할 수 있다. 그 다음 서버 디바이스는 요청된 데이터 또는 HTTP 404 에러 중 어느 하나를 사용하여 이들 요청들에 응답할 수 있다. 응답들을 분석함으로써, 클라이언트 디바이스는 세그먼트들의 시퀀스 중 어느 시퀀스가 이용 가능하고 세그먼트들의 시퀀스 중 어느 것이 이용 가능하지 않은지를 결정할 수 있다.
[0022] 클라이언트 디바이스의 내부 클럭 및 세그먼트들에 대한 이용 가능성의 광고된 시간에 기초하여 복수의 요청들을 구성함으로써, 클라이언트 디바이스는, 클라이언트 디바이스의 내부 클럭이 서버 디바이스의 내부 클럭에 관하여 드리프트되었는지를 결정할 수 있다. 이런 방식으로, 클라이언트 디바이스는, 클라이언트 디바이스의 클럭과 서버 디바이스의 클럭 사이의 드리프트에 기초하여, 세그먼트들이 이용 가능하게 될 때 세그먼트들을 요청할 수 있다.
[0023] 다른 말로, 라이브 스트리밍(예를 들어, DASH에 따라)에서, 클라이언트 디바이스와 서버 디바이스는 거의 동기화될 수 있다. 그러나, 클라이언트 디바이스의 클럭과 서버 디바이스의 클럭 사이에 플러스 또는 마이너스 몇초의 시간 델타(delta)가 있을 수 있다. 이것은 클라이언트가 세그먼트들을 리트리브할 수 없게 할 수 있다. 비록 TSBD(time shift buffer depth: 시간 시프트 버퍼 깊이)가 도움을 줄 수 있지만, 이런 도움은 제한된 조건들 하에서만 제공될 수 있다. 또한 현재, 클라이언트 디바이스와 서버 디바이스 사이에는 어떠한 밀리초-정확 시간 동기화 프로토콜도 없다. 그런 프로토콜은 달성하기 어렵고, DASH에 대한 범위를 벗어날 수 있다.
[0024] 본 개시의 기술들에 의해 제공된 하나의 현실적 솔루션은 클라이언트 디바이스가 클라이언트 디바이스의 거동에만 기초하여 시간 델타를 추정하고, 그 다음 추후 요청들을 고려하여 시간 델타를 취하는 것을 포함한다. 그런 알고리즘은, 초기 세그먼트 요청들이 실패할 때, 또는 새로운 라이브 스트리밍 세션이 시작할 때마다 트리거될 수 있다. 클라이언트 디바이스는 하기 더 상세히 설명된 바와 같이, 정규 세그먼트 요청들을 사용하여 세그먼트 이용 가능성 윈도우의 에지들(예를 들어, 각각 TSBD의 트레일링 에지(trailing edge) 및 리딩 에지(leading edge)라 또한 지칭되는 TSBD의 좌측 에지 또는 우측 에지)를 탐색함으로써 그렇게 수행할 수 있다.
[0025] HTTP 스트리밍에서, 빈번하게 사용된 동작들은 HEAD, GET 및 부분 GET를 포함한다. HEAD 동작은 URL(uniform resource locator) 또는 URN(uniform resource name)과 연관된 페이로드(payload)를 리트리빙함이 없이, 주어진 URL 또는 URN과 연관된 파일의 헤더를 리트리브한다. GET 동작은 주어진 URL 또는 URN과 연관된 전체 파일을 리트리브한다. 부분 GET 동작은 입력 파라미터로서 바이트 범위를 수신하고 파일의 바이트들의 연속적인 번호를 리트리브하고, 여기서 바이트들의 번호는 수신된 바이트 범위에 대응한다. 따라서, 영화 프레그먼트(fragment)들은, 부분 GET 동작이 하나 또는 그 초과의 개별 영화 프레그먼트들을 얻을 수 있기 때문에, HTTP 스트리밍을 위해 제공될 수 있다. 영화 프레그먼트에서, 상이한 트랙들의 몇몇 트랙 프레그먼트들이 있을 수 있다. HTTP 스트리밍에서, 미디어 표현은 클라이언트에 액세스 가능한 데이터의 구조화된 콜렉션(collection)일 수 있다. 클라이언트는 스트리밍 서비스를 사용자에게 제시하기 위하여 미디어 데이터 정보를 요청하고 다운로드할 수 있다.
[0026] HTTP 스트리밍을 사용하는 3GPP 데이터를 스트리밍하는 것의 예에서, 멀티미디어 콘텐츠의 비디오 및/또는 오디오 데이터에 대한 다수의 표현들이 있을 수 있다. 하기 설명된 바와 같이, 상이한 표현들은 상이한 코딩 특성들(예를 들어, 비디오 코딩 표준의 상이한 프로파일들 또는 레벨들), 코딩 표준들의 상이한 코딩 표준들 또는 확장들(멀티뷰 및/또는 스케일러블 확장(scalable extension)들 같은), 또는 상이한 비트레이트들에 대응할 수 있다. 그런 표현들의 매니페스트(manifest)는 MPD(Media Presentation Description: 미디어 표현 설명) 데이터 구조에서 정의될 수 있다. 미디어 표현은 HTTP 스트리밍 클라이언트 디바이스에 액세스 가능한 데이터의 구조화된 콜렉션에 대응할 수 있다. HTTP 스트리밍 클라이언트 디바이스는 스트리밍 서비스를 클라이언트 디바이스의 사용자에게 제시하기 위하여 미디어 데이터 정보를 요청하고 다운로드할 수 있다. 미디어 표현은 MPD의 업데이트들을 포함할 수 있는 MPD 데이터 구조에서 설명될 수 있다.
[0027] 미디어 표현은 하나 또는 그 초과의 기간들의 시퀀스들을 포함할 수 있다. 기간들은 MPD에서 기간 엘리먼트에 의해 정의될 수 있다. 각각의 기간은 MPD에서 속성 start(시작)을 가질 수 있다. MPD는 각각의 기간에 대한 시작 속성 및 availableStartTime(이용가능시작시간) 속성을 포함할 수 있다. 라이브 서비스들에 대해, 기간의 start 속성과 MPD 속성 availableStartTime의 합은 UTC 포맷으로, 특히 대응하는 기간에서 각각의 표현의 제 1 미디어 세그먼트로 기간의 이용 가능성 시간을 특정할 수 있다. 온-디맨드(on-demand) 서비스들에 대해, 제 1 기간의 start 속성은 0일 수 있다. 임의의 다른 기간에 대해, start 속성은 제 1 기간의 시작 시작에 관하여 대응하는 기간의 시작 시간 사이의 시간 오프셋을 특정할 수 있다. 각각의 기간은 다음 기간의 시작까지, 또는 최종 기간의 경우 미디어 표현의 종료까지 확장할 수 있다. 기간 시작 시간들은 정밀할 수 있다. 기간 시작 시간들은 모든 이전 기간들의 미디어 재생으로부터 발생한 실제 타이밍을 반영할 수 있다.
[0028] 각각의 기간은 동일한 미디어 콘텐츠에 대한 하나 또는 그 초과의 표현들을 포함할 수 있다. 표현은 오디오 또는 비디오 데이터의 다수의 대안적인 인코딩된 버전들 중 하나일 수 있다. 표현들은 코딩 타입들, 예를 들어 비트레이트, 해상도, 및/또는 비디오 데이터 및 비트레이트에 대한 코덱, 언어, 및/또는 오디오 데이터에 대한 코덱에 의해 상이할 수 있다. 용어 표현은 멀티미디어 콘텐츠의 특정 기간에 대응하고 특정 방식으로 인코딩된, 인코딩된 오디오 또는 비디오 데이터의 섹션을 지칭하기 위하여 사용될 수 있다.
[0029] 특정 기간의 표현들은 표현들이 속하는 적응 세트를 가리키는 MPD의 속성에 의해 표시된 그룹에 할당될 수 있다. 동일한 적응 세트에서 표현들은 일반적으로, 클라이언트 디바이스가 예를 들어 대역폭 적응을 수행하기 위하여 이들 표현들 사이에서 동적으로 그리고 끊김 없이(seamlessly) 스위칭할 수 있다는 점에서 서로에 대한 대안들로 고려된다. 예를 들어, 특정 기간에 대한 비디오 데이터의 각각의 표현은 동일한 적응 세트에 할당될 수 있어서, 표현들 중 임의의 표현은 대응하는 기간에 대한 멀티미디어 콘텐츠의 미디어 데이터, 이를테면 비디오 데이터 또는 오디오 데이터를 제시하도록 디코딩하기 위해 선택될 수 있다. 하나의 기간 내의 미디어 콘텐츠는 몇몇 예들에서, 만약 존재하면 그룹(0)으로부터의 하나의 표현, 또는 각각의 영이 아닌 그룹으로부터 기껏 하나의 표현의 결합 중 어느 하나에 의해 표현될 수 있다. 기간의 각각의 표현에 대한 타이밍 데이터는 기간의 시작 시간에 관하여 나타내질 수 있다(express).
[0030] 표현은 하나 또는 그 초과의 세그먼트들을 포함할 수 있다. 각각의 표현은 초기화 세그먼트를 포함할 수 있거나, 표현의 각각의 세그먼트는 자체-초기화일 수 있다. 존재할 때, 초기화 세그먼트는 표현에 액세싱하기 위한 초기화 정보를 포함할 수 있다. 일반적으로, 초기화 세그먼트는 미디어 데이터를 포함하지 않는다. 세그먼트는 유일하게 식별자, 이를테면 URL(uniform resource locator), URN(uniform resource name), 또는 URI(uniform resource identifier)에 의해 참조될 수 있다. MPD는 각각의 세그먼트에 대한 식별자들을 제공할 수 있다. 몇몇 예들에서, MPD는 또한, URL, URN, 또는 URI에 의해 액세스 가능한 파일 내의 세그먼트에 대한 데이터에 대응할 수 있는 range(범위) 속성의 형태의 바이트 범위들을 제공할 수 있다.
[0031] 각각의 표현은 또한 하나 또는 그 초과의 미디어 컴포넌트들을 포함할 수 있고, 여기서 각각의 미디어 컴포넌트는 오디오, 비디오, 또는 시간 텍스트(timed text)(예를 들어, 클로스드 캡셔닝(closed captioning)에 대해) 같은 하나의 개별 미디어 타입의 인코딩된 버전에 대응할 수 있다. 미디어 컴포넌트들은 하나의 표현 내의 연이은 미디어 세그먼트들의 경계들에 걸쳐 시간-연속적일 수 있다.
[0032] 일반적으로, DASH 클라이언트 디바이스는 DASH 서버 디바이스로부터 MPD에 액세스하고 다운로드할 수 있다. 즉, DASH 클라이언트 디바이스는 라이브 세션을 개시할 때 사용하기 위한 MPD를 리트리브할 수 있다. 이런 MPD에 기초하고, 그리고 각각의 선택된 표현에 대해, DASH 클라이언트 디바이스는 서버 디바이스 상에서 이용 가능한 최신 세그먼트가 무엇인지를 결정하는 것, 다음 세그먼트 및 아마도 미래 세그먼트들의 세그먼트 이용 가능성 시작 시간을 결정하는 것, 세그먼트의 플레이아웃(playout)을 시작할 때 및 세그먼트에서 어느 타임라인(timeline)으로부터 인지를 결정하는 것, 및 새로운 MPD를 얻고/인출할 때를 결정하는 것을 포함하는 여러 판정들을 할 수 있다. 일단 서비스가 플레이 아웃되면, 클라이언트 디바이스는 검출되고 보상될 필요가 있는 라이브 서비스와 라이브 서비스 자신의 플레이아웃 사이의 드리프트를 계속 알고 있을 수 있다.
[0033] HLS(HTTP Live Streaming)는 다음과 같이 이들 문제들을 해결하려고 시도한다. 이용 가능해진 각각의 세그먼트에 대해, 서버 디바이스는 새로운 MPD를 공표한다. 클라이언트 디바이스는, 서비스에 조인(join)한 후, 최신 MPD를 리트리브하고, 플레이리스트(playlist)를 분석하고, 그 다음 최신의 세그먼트에 액세스할 수 있다. 그 다음 클라이언트 디바이스는, 세그먼트를 플레이 아웃하기 시작하고, 시작으로부터 세그먼트를 플레이할 때, 시간적으로 다음 세그먼트에 계속하여 액세스할 수 있다는 예상 하에서 구성된다. 새로운 세그먼트를 인출하기 전에(또는 새로운 세그먼트를 인출하기 위하여 요구하기 전에), 클라이언트 디바이스는 최신 세그먼트를 얻을 위치를 제공하는 새로운 MPD를 인출한다.
[0034] SmoothStreaming(스무스스트리밍)은 다음과 같이 이들 문제들을 해결하려고 시도한다. 이용 가능하게 된 각각의 세그먼트에 대해, 서버 디바이스는 새로운 MPD를 공표한다. 클라이언트는, 서비스에 조인한 후, 최신 MPD를 리트리브하고, 최신 S 엘리먼트의 SegmentTimeLine(세그먼트타임라인)의 "@r" 속성을 얻음으로써 이용 가능한 최신 세그먼트를 분석한다. 이것은 최신 세그먼트를 얻을 장소를 가리키는 정보를 제공한다. 그 다음 클라이언트 디바이스는, 세그먼트를 플레이 아웃하기 시작하고, 시작으로부터 세그먼트를 플레이할 때, 세그먼트 지속시간을 최종 요청 시간에 부가함으로써 발생하는 시간 이전에 다음 요청이 존재하지 않는 한 시간적으로 다음 세그먼트에 계속하여 액세스할 수 있다는 예상 하에서 구성된다. 그러므로 클라이언트는 현재 MPD가 더 이상 이용 가능하지 않다는 것을 가리키는 대역내 신호를 얻을 때까지 새로운 MPD를 인출함이 없이 최신 SegmentTimeline.S(세그먼트타임라인.에스) 엘리먼트에 기초하여 세그먼트들을 계속 구성한다. 이런 시점에서(즉, 현재 MPD가 더 이상 이용 가능하지 않은 신호에 응답하여), 클라이언트 디바이스는 새로운 MPD를 요청한다.
[0035] MPEG-DASH는 라이브 미디어 표현을 셋업하는 MPD에서 도큐먼팅된(document) 월-클럭(wall-clock) 시간을 사용한다. MPEG-DASH는, MPD 생성 프로세스가 정확한 클럭에 액세스하도록 MPD가 생성되는 것을 가정한다. 이것은 임의의 수단에 의해 월-클럭 시간에 동기화되는 클라이언트 디바이스들이 라이브 에지(또한 리딩 에지로 지칭됨)에 더 근접하게 동작하게 한다. 특히, 다음 정보는 숫자-템플릿(template) 기반 표현들 및 @지속시간 속성을 사용할 때 MPD에서 이용 가능하다:
● MPD@availabilityStartTime(이용가능성시작시간): 시작 시간은 월-클럭 시간에서 MPD에 대한 앵커(anchor)이다. 값은 AST로서 표시된다.
● MPD@minimumUpdatePeriod(최소업데이트기간): MPD의 최소 업데이트 기간. 값은 MPU로서 표시된다.
● MPD@suggestedPresentationDelay(제안된표현지연): 세그먼트 이용 가능성 시작 시간에 대한 델타로서 제안된 표현 지연. 값은 SPD로서 표시된다.
● MPD@minBufferTime(최소버퍼시간): 각각의 표현의 @bandwidth(대역폭) 속성과 함께 사용된 최소 버퍼 시간. 값은 MBT로서 표시된다.
● MPD@timeShiftBufferDepth(시간시프트버퍼깊이): 미디어 표현의 시간 시프트 버퍼 깊이. 값은 TSB로서 표시된다.
● Period@start(기간@시작): MPD 이용 가능성 시작 시간에 관하여 기간의 시작 시간. 값은 PS로서 표시된다.
● SegmentTemplate@startNumber(세그먼트템플릿@시작번호): 기간의 제 1 세그먼트의 번호. 값은 SSN으로서 표시된다.
● SegmentTemplate@duration(세그먼트템플릿@지속시간): 시간 유닛에서 세그먼트의 지속시간. @timescale(타임스케일)의 값에 의해 나누어진 값은 d로서 표시된다.
[0036] 클라이언트 디바이스가 인출 시간(FT)에서 MPD를 인출하였다는 것이 가정된다.
[0037] 이제 클라이언트에 있는 월-클럭 시간이 WT로 나타내지는 것을 가정하면, 클라이언트 디바이스는 다음 정보를 유도할 수 있다:
● LSN으로서 표시된 최신 세그먼트 번호를 요구하는 서버상에서 이용 가능한 최신 세그먼트의 어드레스.
● SAST(SN)로서 표시된 임의의 다른 세그먼트(SN) 및 번호(LSN+1)를 가진 다음 세그먼트의 세그먼트 이용 가능성 시작 시간. SN은 1에서 시작하는 것이 주의된다.
● 라이브 에지에 가장 근접하여 동기화하는 세그먼트 내의 미디어 표현 시간(MPTL).
● 다른 클라이언트들에 동기화하는 세그먼트 내의 미디어 표현 시간(MPTS).
● 현재 표현 시간에 기초하여 새로운 MPD를 인출할 시간.
[0038] MPEG-DASH의 기술들의 예는 하기에 설명된다. 이 예에서, MPD가 다음 정보를 포함하게 한다:
Figure 112015085493717-pct00001
Figure 112015085493717-pct00002
[0039] 클라이언트 디바이스가 MPD를 인출하고 월-클럭 시간이 NTP="2011-12-25T12:30:27"임을 추가로 가정한다. 이 값은 이 예에서 FT로서 표시된다.
[0040] 그 다음 클라이언트 디바이스는 최신의 세그먼트 번호를 유도한다. 즉, 클라이언트 디바이스는 AST+PS <= NTP인 기간으로서 최신 기간을 얻는다. 만약 NTP >= AST + PS + d이면, 이 기간 내의 적어도 하나의 세그먼트는 이용 가능하고, 클라이언트 디바이스는 다음과 같이 클라이언트 상에 이용 가능한 최신 세그먼트 번호(LSN)를 유도한다:
LSN = floor(플로어)( NTP - ( AST + PS ) - d )/ d ) + SSN = floor(15/2) + 22 = 29 (1)
[0041] 그러므로 결과적인 URL은 이 예에서 http://www.example.com/audio/fr/29.mp4로서 유도된다.
[0042] 그 다음 클라이언트 디바이스는 다음과 같이 번호 SN을 가진 세그먼트에 대한 세그먼트 이용 가능성 시작 시간(SAST)을 유도한다:
SAST(SN) = AST + PST + ( SN - SSN + 1 )*d (2)
[0043] 이것은, 이 예에서 SN=30에 대해, SAST(SN=30) = 2011-12-25T12:30:28임을 의미한다.
[0044] 그 다음 클라이언트 디바이스는 MPD에서 이용 가능한 정보에 기초하여 플레이아웃을 스케줄한다. 클라이언트 디바이스는 미디어 세그먼트들의 표현 시간 값 마이너스 만약 존재하면, 각각의 표현에 대해 @presentationTimeOffset의 값으로서, 각각의 표현에 대한 기간에서의 미디어 표현 시간을 결정한다. 세그먼트 번호(SN)를 가진 각각의 세그먼트는 EPT(SN)에 의해 표시된 가장 이른 표현 시간을 포함한다.
[0045] MPEG-DASH에서 MPD를 제공함으로써, 하기가 보장된다:
1. 이 기간에서 각각의 세그먼트가 자신의 가장 이른 표현 시간 이전에 이용 가능하다, 즉 모든 SN에 대해, EPT(SN) >= SAST(SN) - (AST + PST).
2. 세그먼트 번호(SN)를 가진 각각의 세그먼트가 @bandwidth attribute의 값과 동일한 비트레이트를 가지고 일정한 비트레이트 채널을 통해 SAST(SN)에서 시작하게 전달되면, 각각의 표현 시간(PT)은 가장 최신의 시간 PT + (AST + PST) + MBT에서 클라이언트에서 이용 가능하다.
3. 다른 클라이언트들과 동기화하여 동작할 때 표현 시간에 대한 추천된 플레이아웃-시간 MPTS(PT)는 MPTS(PT) = (AST + PST) + PT + SPD이다.
4. 이 기간에서 각각의 세그먼트는 적어도 SAST(SN) + TSB + d까지 이용 가능하다.
[0046] 이 정보를 사용하여, 클라이언트 디바이스는 MPD의 정보뿐 아니라 다운로드 속도를 고려하여, 스케줄링 플레이아웃을 시작할 수 있다. 적당한 플레이아웃 시간은 attribute@suggestedPresentationDelay이 존재하면, POT(PT) = MPTS(PT)이다. 만약 attribute@suggestedPresentationDelay이 존재하지 않으면, 적당한 플레이아웃 시간은 상기 제 1, 제 2, 및 제 4 제약들, 즉 서버에서의 세그먼트 이용 가능성 시간들 뿐 아니라 미디어 스트림의 비트레이트 가변성을 고려한다.
[0047] 클라이언트 디바이스는, MPD가 유효한 동안 세그먼트들을 구성하기 위하여 MPD를 사용한다. 특히, 클라이언트 디바이스는 미디어 시간 FT + MUP까지 세그먼트들을 구성하기 위하여 MPD를 사용한다. 즉, 구성될 수 있는 가장 큰 세그먼트 번호(GSN)는 다음과 같다:
GSN = ceil ( FT + MUP - ( AST + PS ) - d )/ d ) + SSN = ceil (45/2) + 22 = 45 (3)
[0048] 최신의 세그먼트가 다른 세그먼트들보다 짧을 수 있다는 것이 이해되어야 한다. 상기 예에서 세그먼트 번호(45)를 넘는 임의의 데이터를 인출하기 전에, 클라이언트 디바이스는 MPEG-DASH에 따라 새로운 MPD를 인출할 필요가 있다.
[0049] 보다 일반적으로, DASH에서 상이한 타이밍 및 어드레싱 방식들과 함께 동일한 개념을 사용하기 위하여, 다음 값들은 ISO/IEC 23009-1에 따라 유도된다:
● k=1,2,...를 가진 k로서 표시된 기간에서 세그먼트의 포지션.
● MST(k)로서 지칭된 포지션(k)에서 세그먼트의 MPD 시작 시간.
● MD(k)로서 지칭된 포지션(k)에서 세그먼트의 MPD 지속시간.
[0050] 이제 클라이언트 디바이스에 있는 월-클럭 시간이 WT로서 표시되는 것을 가정하면, 클라이언트 디바이스는 다음 정보를 유도할 수 있다:
1. 자신의 기간 시작 시간(PST*)에 의해 표시된 서버상의 최신 이용 가능한 기간.
2. SAST(k)로서 표시된 기간 내의 포지션(k)에서 임의의 세그먼트의 세그먼트 이용 가능성 시작 시간.
3. k*로서 지칭된 기간 내에서 서버상에서 이용 가능한 최신 세그먼트의 포지션.
4. 서버상에서 이용 가능한 최신 세그먼트의 어드레스.
5. 현재 표현 시간, 또는 보다 구체적으로 MPD에 의해 구성될 수 있는 이 기간 내의 가장 큰 세그먼트 포지션(k')에 기초하여 새로운 MPD를 인출할 시간.
6. 라이브 에지에 가장 근접하여 동기화하는 표현 내의 미디어 표현 시간(MPTL).
7. 다른 클라이언트들에 동기화하는 표현 내의 미디어 표현 시간(MPTS).
[0051] 이들 시간들을 사용하여, 클라이언트 디바이스는 상기로부터 다음과 같이 값들을 유도할 수 있다:
1. 최신의 기간은 PST <= NTP인 기간으로서 얻어진다.
2. 세그먼트 이용 가능성 시작 시간은 다음과 같이 얻어진다.
SAST(k) = AST + PST + MST(k) + MD(k) (4)
3. 이 기간 내에서 클라이언트 디바이스 상에서 이용 가능한 최신 세그먼트는 SAST(k*)에 대해 가장 큰 값을 초래하고 동시에 NTP보다 작은 포지션(k*)의 세그먼트이다.
4. 최신 세그먼트의 어드레스는 포지션 정보(k*)를 사용함으로써 얻어지고 그 다음 세그먼트 어드레스가 유도될 수 있다. 세그먼트 어드레스는 어드레싱 방법에 따른다.
5. 이 기간 내에서 이 MPD에 의해 구성될 수 있는 가장 큰 세그먼트 포지션(k')은 SAST(k')에 대해 가장 큰 값을 초래하고 동시에 FT + MUP보다 작은 세그먼트 포지션이다.
[0052] 클라이언트 디바이스는 이 데이터를 사용하여 MPD 시간들을 유도할 수 있다. 예를 들어, @duration(지속시간) 속성이 존재하고 @timescale(타임스케일)의 값에 의해 나누어진 값이 d로서 표시되면, 클라이언트 디바이스는 종래의 DASH 기술들을 사용하여 다음과 같이 MPD 시간들을 유도한다:
● MD(k) = d
● MST(k) = (k-1)*d
[0053] 세그먼트 베이스 정보가 NS를 가진 SegmentTimeline(세그먼트타임라인) 엘리먼트를 포함하는 경우, S 개의 엘리먼트들은 s=1, ..., NS로 인덱스된다(ISO/IEC 23009-1에 따른 DASH에서).
● t[s]는 @timescale 속성의 값으로 나누어진 s번째 S 엘리먼트의 @t의 값이다,
● d[s]는 @timescale 속성의 값으로 나누어진 s번째 S 엘리먼트의 @d 의 값이다,
● r[s]는 s번째 S 엘리먼트의 @r의 값이다(@r 값이 -1이 아닌 경우, 이는 값이 알려지지 않았고 업데이트된 정보가 이용 가능할 때까지 @d가 사용될 수 있다는 것을 의미함).
[0054] 따라서, 클라이언트 디바이스는 다음과 같이 MPD 지속시간 및 시작 시간들을 유도할 수 있다:
● k=0
● s=1에 대해, ... NS
o k = k + 1
o MST(k) = t[s]
o MD(k) = d[s]
o j = 1에 대해, ..., r[s]
■ k = k + 1
■ MST(k) = MST(k-1) + d[s]
■ MD(k) = d[s]
[0055] ISO/IEC 23009-1에 따른 DASH에서, 어드레싱 방법은 타임라인 생성의 용법과 무관하다. @startNumber(시작번호)의 해석은 어드레싱 방법에 따른다. 표현이 미디어 세그먼트들에 대한 명시적 URL(들)의 세트를 제공하는 하나 또는 그 초과의 세그먼트리스트(SegmentList) 엘리먼트들을 포함하거나 물려받으면, 클라이언트 디바이스는 @startNumber를 사용하여 세그먼트 리스트 내 제 1 세그먼트의 포지션을 결정한다. 그 다음 세그먼트 리스트는 명시적 URL들을 제공한다. 표현이 $Number(번호)$를 가진 세그먼트템플릿(SegmentTemplate) 엘리먼트를 포함하거나 물려받으면, 포지션(k)에서 미디어 세그먼트의 URL은 $Number$ 식별자를 SegmentTemplate@media(세그먼트템플릿@미디어) 문자열 내의 (k-1) + @startNumber에 의해 대체함으로써 얻어진다. 표현이 $Time(시간)$을 가진 세그먼트템플릿 엘리먼트를 포함하거나 물려받으면, 클라이언트 디바이스는 $Time$ 식별자를 SegmentTemplate@media 문자열 내의 MST(k)(만약 @timescale 속성이면 값이 비정규화됨)에 의해 대체함으로써 포지션(k)에서 미디어 세그먼트의 URL을 얻는다.
[0056] 게다가, ISO/IEC 23009-1에 따른 DASH에서, 클라이언트 디바이스는 MPD의 이용 가능한 정보에 기초하여 플레이아웃을 스케줄한다. 클라이언트 디바이스는 미디어 세그먼트들의 표현 시간 값 마이너스 만약 존재하면 각각의 표현에 대해 @presentationTimeOffset(표현시간오프셋)의 값으로서, 각각의 표현에 대한 기간에서 미디어 표현 시간을 결정한다. 포지션(k)에서 각각의 세그먼트에는 가장 이른 미디어 표현 시간(EPT(k))이 할당된다.
[0057] MPD를 제공함으로써, ISO/IEC 23009-1에 따른 DASH는 다음을 보장한다:
1. 이 기간에서 각각의 세그먼트는 자신의 가장 이른 표현 시간 및 자신의 지속시간 이전에 이용 가능하고, 즉 모든 k에 대해,
SAST(k) <= EPT(k) + (AST + PST) + MD(k) (5)
2. 세그먼트 번호(k)를 가진 각각의 세그먼트가 전달되어 @bandwidth(대역폭) 속성의 값과 동일한 비트레이트를 가진 일정한 비트레이트 채널을 통해 SAST(k)를 시작하면, 각각의 표현 시간(PT)은 가장 최신의 시간 PT + (AST + PST) + MBT + MD(k)에서 클라이언트에서 이용 가능하다.
3. 다른 클라이언트들과 동기하여 동작할 때 표현 시간에 대해 추천된 플레이아웃-시간(MPTS(PT)는 MPTS(PT) = (AST + PST) + PT + SPD.
4. 이 기간에서 각각의 세그먼트는 적어도 SAST(k) + TSB + MD(k)까지 이용 가능하다.
[0058] 이 정보를 사용하여, 클라이언트 디바이스는 MPD의 정보뿐 아니라 다운로드 속도를 고려하여, 플레이아웃을 스케줄링하기 시작할 수 있다. 적당한 플레이아웃 시간은, 속성 @suggestedPresentationDelay이 존재하면, POT(PT) = MPTS(PT)이다. 만약 속성 @suggestedPresentationDelay이 존재하지 않으면, 적당한 플레이아웃 시간은 제 1, 제 2, 및 제 4 제약, 즉 서버에서의 세그먼트 이용 가능성 시간들뿐 아니라 미디어 스트림의 비트레이트 가변성을 고려한다.
[0059] ISO/IEC 23009-1에 따른 DASH 하에서, 클라이언트 디바이스는 미디어 시간 FT + MUP까지 세그먼트들을 구성 및 요청하기 위해 MPD를 사용할 수 있고 이 MPD에 의해 구성될 수 있는 가장 큰 세그먼트 포지션(k')은 SAST(k')에 대해 가장 큰 값을 초래하고 동시에 FT + MUP보다 작은 세그먼트 포지션이다. 최신의 세그먼트는 다른 세그먼트들보다 짧을 수 있다.
[0060] @duration 또는 SegmentTimeline.S@r="-1"을 가진 템플릿 구성이 사용되는 경우에, ISO/IEC 23009-1에 따른 DASH 접근법은 아래와 같은 HLS 및 SmoothStreaming(평활화스트리밍) 접근법에 비해 몇몇 장점들을 제공할 수 있다:
1. MPD는 세그먼트 구성이 계속될 수 있는 한 반드시 서버 디바이스 상에서 업데이트되지 않는다. 클라이언트 디바이스가 MPD의 인출 시간을 레코딩하는 한, 클라이언트 디바이스는 몇몇 상이한 서비스들에 대해 먼저 MPD를 다운로드할 수 있다(또는 이를 버퍼에 유지할 수 있음).
2. 또한, 멀티캐스트 환경에서, MPD는 단지 1회 또는 적어도 매 초보다 매우 작은 빈도로 분배될 수 있다.
3. 클라이언트 디바이스는, 다음 세그먼트가 서버 디바이스 상에서 이용 가능하고/공표되는 시간을 정확히 가리키는 정보를 가진다. 이것은 세그먼트가 이용 가능하자마자 클라이언트 디바이스가 세그먼트를 요청하기 때문에 라이브 에지에 보다 근접한 동작을 허용한다.
4. 클라이언트 디바이스는 클라이언트 디바이스가 다운로드하는 제 1 세그먼트의 플레이아웃을 정확하게 배치할 수 있다. 클라이언트 디바이스는 심지어 라이브 에지에 보다 근접한 동작을 가능하게 하기 위하여 세그먼트의 중간에서 플레이아웃을 시작할 수 있다.
5. 클라이언트 디바이스는 다른 클라이언트 디바이스들과 자신의 플레이아웃을 동기화할 수 있다.
6. 서버 디바이스 동작은 간단하고, 즉 어떤 전용 서버 디바이스도 요구되지 않는다.
[0061] DASH 라이브 스트리밍은, 비록 현재 사양이 시간 동기화 문제를 배제하지만 클라이언트 및 서버가 시간적으로 동기화되는 것을 가정하고 NTP(network time protocol: 네트워크 시간 프로토콜) 같은 그런 프로토콜에 의해 다루어질 것이라는 것을 가정한다. 그러나, 랩(lab) 테스트들에서, 클라이언트와 서버가 처음에 동기화될 때에도, 그들의 클럭들이 몇십 밀리 초 내지 몇 초 상이할 수 있다는 것이 관찰되었다. 이것에 대해 두 개의 이유들이 있다. 제 1 이유는 NTP가 밀리초 정확성을 달성하도록 설계된 프로토콜이 아니라는 것이다. 제 2 이유는 클라이언트와 서버상의 클럭이 초기 동기화 후 사이가 멀어질 수 있다는 것이다. NTP 동기화 후 24 시간 지속시간에서 20초까지의 클라이언트 및 서버 시간 델타들이 휴리스틱(heuristic) 테스트에서 관찰되었다.
[0062] 클라이언트-서버 시간 델타의 하나의 잠재적인 단점은, 미디어 세그먼트들에 대한 세그먼트 이용 가능성 시간 윈도우의 클라이언트의 뷰가 서버의 뷰로부터 왜곡될 수 있다는 것이다. 클라이언트의 뷰가 실질적으로 왜곡되는 경우, 클라이언트는 미디어 세그먼트가 이용 가능하게 되기 전에, 또는 미디어 세그먼트가 이용 가능성 시간 윈도우 밖으로 나온 후에 미디어 세그먼트 요청을 전송할 수 있다. 양쪽 경우들에서, 서버는 HTTP 404 에러 코드로 응답할 것이고 클라이언트는 세그먼트를 성공적으로 리트리브할 수 없다. 그런 에러들은 시작 실패 또는 재생 중단을 유발할 수 있다. 또한 DASH 라이브 스트리밍 시스템에서 또한 제 3 디바이스, 즉 인코딩된 비디오 세그먼트들을 생성하고, 이들을 웹 서버상에 저장하고, 그리고 이들을 후에 제거하는 인코딩 시스템이 있다. 클라이언트와 웹-서버 사이의 빈번한 재동기화에도 불구하고, 클럭 드리프는 클라이언트와 인코딩 시스템 사이에서 발생할 수 있고, 이는 세그먼트들이 인출될 때 HTTP 404 에러들을 초래할 수 있다.
[0063] 본 개시는 클라이언트 디바이스의 클럭과, 서버 디바이스의 클럭 및 인코딩 시스템의 클럭 중 어느 하나 또는 둘 다 사이에서 시간 델타를 추정하기 위한 클라이언트-기반 방법을 설명한다. 추정된 시간 델타는 추후 미디어 세그먼트 요청들을 전송하기 위한 시간을 조절하도록 클라이언트 디바이스에 의해 사용될 수 있다. 따라서, 본 개시에 의해 설명된 기술들을 구현하는 것은 보다 강건한 플레이아웃 경험을 유도할 수 있다.
[0064] 일 예에서, 클라이언트 디바이스는 시간 델타 추정 알고리즘에 기초하여 클라이언트 디바이스의 내부 클럭과 서버 디바이스의 내부 클럭 사이의 시간 차이(또한 드리프트 또는 시간 델타로서 지칭됨)를 추정하도록 구성될 수 있다. 시간 델타는 또한(부가적으로 또는 대안적으로) 클라이언트 디바이스의 클럭과 특정 세그먼트가 이용 가능하게 되는 시간 사이의 차이(그리고 따라서, 반드시 서버 디바이스의 클럭에 의해 표시된 시간에 관련하지 않음)를 나타낼 수 있다. 특정 세그먼트(또는 데이터의 다른 유닛)가 이용 가능하게 되는 시간은 본원에서 이용 가능성 시간으로서 지칭될 수 있다. 본 개시의 동일한 시간 델타 추정 알고리즘은 어느 하나의 시나리오 또는 양쪽 시나리오들에 적용될 수 있다.
[0065] 본 개시의 시간 델타 추정 알고리즘은 다음 가정들하에서 사용될 수 있다. 제 1 가정은, 클라이언트와 서버(또는 세그먼트 이용 가능성 시간) 사이의 시간 델타가 B 초들 내에 의해 한정되는 것이다. 만약 실제 시간 델타가 가정된 값(B)보다 크면, 이 알고리즘은, 몇몇 경우들에서 시간 델타를 추정하기 위하여 사용할 수 없다. 제 2 가정은, 웹 서버 디바이스가 파이프라인 요청들을 지원하는 것이다. 그렇지 않으면, 추정 절차는 지정된 정확성을 달성하기 위하여 수정될 필요가 있을 수 있다. 제 3 가정은, 클라이언트와 서버 사이의 이용 가능한 대역폭이 대략 다이얼 접속 속도인 예를 들어 50 kbps의 최소 임계치를 초과하는 것이다. 매우 느린 네트워크 속도는 추정 부정확성을 증가시킬 수 있다. 제 4 가정은, 웹 서버 디바이스가 무시 가능한 시간(예를 들어, 1초의 몇 분의 1) 내에서 클라이언트 디바이스로부터 수십의 HTTP HEAD 요청들까지를 다룰 수 있다는 것이다.
[0066] 게다가, 본 개시의 기술들을 구현하기 위하여, 클라이언트 디바이스는 하나의 세그먼트 지속기간의 입도(예를 들어, 1초)에서 클라이언트 디바이스와 서버 디바이스 사이의 시간 델타를 추정할 수 있도록 구성될 수 있다. 추정은 또한, 어느 쪽이 더 크든 5초 또는 10초의 왕복 시간(RTT)들 내에서 생성되어야 한다. 이는, 실제 시간 델타가 지정된 시간 델타 제한을 초과할 때, 시간 델타 추정 알고리즘이 감소된 정확성 또는 연장된 추정 시간의 비용으로, 추정치를 얻을 수 있도록 내부 파라미터들을 자동으로 조절할 수 있다면 유리할 수 있다.
[0067] 클라이언트 디바이스는 또한 처음에 서버 디바이스와 거의 근사한 동기화를 달성하도록 구성될 수 있다. 이것은 네트워크 시간 프로토콜(NTP) 같은 다수의 시간 동기화 프로토콜들 중 하나를 통해 행해질 수 있다. 그러나, 클라이언트 디바이스가 서버 디바이스와 초기 시간 동기화를 정확하게 달성하는 방법에 대한 제약은 없다. 본 개시에서 도입된 시간 델타 추정의 입도는 세그먼트 지속시간 및 웹 서버 디바이스에 의한 모든 프로빙 요청들의 프로세싱 지연에 의해 한정될 수 있다. 다른 말로, 입도는 어느 족이 더 크든, 하나의 세그먼트 지속시간보다 미세하거나, 어그리게이트 프로세싱 지연보다 더 미세할 필요가 없다. 일반적으로, 프로세싱 지연은 매우 작도록 가정되고 하나의 세그먼트 시간에 비해 무시 가능하다.
[0068] 도 1은 네트워크를 통해 미디어 데이터를 스트리밍하기 위한 기술들을 구현하는 예시적 시스템(10)을 예시하는 블록도이다. 이 예에서, 시스템(10)은 콘텐츠 준비 디바이스(20), 서버 디바이스(60), 및 클라이언트 디바이스(40)를 포함한다. 클라이언트 디바이스(40) 및 서버 디바이스(60)는 인터넷을 포함할 수 있는 네트워크(74)에 의해 통신 가능하게 커플링된다. 몇몇 예들에서, 콘텐츠 준비 디바이스(20) 및 서버 디바이스(60)는 또한 네트워크(74)에 의해 또는 다른 네트워크에 의해 커플링될 수 있거나 직접 통신 가능하게 커플링될 수 있다. 몇몇 예들에서, 콘텐츠 준비 디바이스(20) 및 서버 디바이스(60)는 동일하 디바이스를 포함할 수 있다.
[0069] 콘텐츠 준비 디바이스(20)는, 스토리지, 오디오 소스(22) 및 비디오 소스(24)를 포함한다. 오디오 소스(22)는 예를 들어, 오디오 인코더(26)에 의해 인코딩될 캡처된 오디오 데이터를 나타내는 전기 신호들을 생성하는 마이크로폰을 포함할 수 있다. 대안적으로, 오디오 소스(22)는 이전에 레코딩된 오디오 데이터를 저장하는 스토리지 매체, 컴퓨터화된 합성기 같은 오디오 데이터 생성기, 또는 오디오 데이터의 임의의 다른 소스를 포함할 수 있다. 비디오 소스(24)는 비디오 인코더(28)에 의해 인코딩될 비디오 데이터를 생성하는 비디오 카메라, 이전에 레코딩된 비디오 데이터가 인코딩된 스토리지 매체, 컴퓨터 그래픽 소스 같은 비디오 데이터 생성 유닛, 또는 비디오 데이터의 임의의 다른 소스를 포함할 수 있다. 콘텐츠 준비 디바이스(20)는 모든 예들에서 서버 디바이스(60)에 반드시 통신 가능하게 커플링되는 것이 아니라, 서버 디바이스(60)에 의해 판독된 멀티미디어 콘텐츠를 별개의 매체에 저장할 수 있다.
[0070] 로우(raw) 오디오 및 비디오 데이터는 아날로그 또는 디지털 데이터를 포함할 수 있다. 아날로그 데이터는 오디오 인코더(26) 및/또는 비디오 인코더(28)에 의해 인코딩되기 전에 디지털화될 수 있다. 오디오 소스(22)는 스피킹 참가자가 말하는 동안 스피킹 참가자로부터 오디오 데이터를 얻을 수 있고, 비디오 소스(24)는 스피킹 참가자의 비디오 데이터를 동시에 얻을 수 있다. 다른 예들에서, 오디오 소스(22)는 저장된 오디오 데이터를 포함하는 컴퓨터-판독가능 스토리지 매체를 포함할 수 있고, 비디오 소스(24)는 저장된 비디오 데이터를 포함하는 컴퓨터-판독가능 스토리지 매체를 포함할 수 있다. 이런 방식으로, 본 개시에 설명된 기술들은 라이브, 스트리밍, 실시간 오디오 및 비디오 데이터 또는 보관된 사전 레코딩된 오디오 및 비디오 데이터에 적용될 수 있다.
[0071] 비디오 프레임들에 대응하는 오디오 프레임들은 일반적으로 비디오 프레임들 내에 포함된 비디오 소스(24)에 의해 캡처(또는 생성)된 비디오 데이터와 동시에 오디오 소스(22)에 의해 캡처(또는 생성)된 오디오 데이터를 포함하는 오디오 프레임들이다. 예를 들어, 스피킹 참가자가 일반적으로 스피킹에 의해 오디오 데이터를 생성하는 동안, 오디오 소스(22)는 오디오 데이터를 캡처하고, 그리고 비디오 소스(24)는 동시에, 즉 오디오 소스(22)가 오디오 데이터를 캡처하는 동안 스피킹 참가자의 비디오 데이터를 캡처한다. 따라서, 오디오 프레임은 일시적으로 하나 또는 그 초과의 특정 비디오 프레임들에 대응한다. 따라서, 비디오 프레임에 대응하는 오디오 프레임은 일반적으로, 오디오 데이터 및 비디오 데이터가 동시에 캡처되고 오디오 프레임 및 비디오 프레임이 각각 동시에 캡처되는 오디오 데이터 및 비디오 데이터를 포함하는 상황에 대응한다.
[0072] 몇몇 예들에서, 오디오 인코더(26)는 인코딩된 오디오 프레임에 대한 오디오 데이터가 기록된 시간을 나타내는 각각의 인코딩된 오디오 프레임의 타임스탬프(timestamp)를 인코딩할 수 있고, 그리고 유사하게, 비디오 인코더(28)는 인코딩된 비디오 프레임에 대한 비디오 데이터가 레코딩된 시간을 나타내는 각각의 인코딩된 비디오 프레임의 타임스탬프를 인코딩할 수 있다. 그런 예들에서, 비디오 프레임에 대응하는 오디오 프레임은 타임스탬프를 포함하는 오디오 프레임 및 동일한 타임스탬프를 포함하는 비디오 프레임을 포함할 수 있다. 콘텐츠 준비 디바이스(20)는 오디오 인코더(26) 및/또는 비디오 인코더(28)가 타임스탬프들을 생성하거나, 오디오 소스(22) 및 비디오 소스(24)가 오디오 및 비디오 데이터를 각각 타임스탬프와 연관시키기 위하여 사용할 수 있는 내부 클럭을 포함할 수 있다.
[0073] 몇몇 예들에서, 오디오 소스(22)는 오디오 데이터가 레코딩된 시간에 대응하는 데이터를 오디오 인코더(26)에 전송할 수 있고, 비디오 소스(24)는 비디오 데이터가 레코딩된 시간에 대응하는 데이터를 비디오 인코더(28)에 전송할 수 있다. 몇몇 예들에서, 오디오 인코더(26)는 인코딩된 오디오 데이터의 상대적 시간 순서를 가리키지만, 반드시 오디오 데이터가 레코딩된 절대 시간을 가리키지 않는 인코딩된 오디오 데이터의 시퀀스 식별자를 인코딩할 수 있고, 유사하게 비디오 인코더(28)는 또한 인코딩된 비디오 데이터의 상대적 시간 순서를 가리키기 위하여 시퀀스 식별자들을 사용할 수 있다. 유사하게, 몇몇 예들에서, 시퀀스 식별자는 타임스탬프와 맵핑될 수 있거나 그렇지 않으면 타임스탬프와 상관될 수 있다.
[0074] 오디오 인코더(26)는 일반적으로 인코딩된 오디오 데이터의 스트림을 생성하는 반면, 비디오 인코더(28)는 인코딩된 비디오 데이터의 스트림을 생성한다. 데이터(오디오이든 비디오이든)의 각각의 개별 스트림은 엘리먼터리 스트림(elementary stream)으로 지칭될 수 있다. 엘리먼터리 스트림은 표현의 단일, 디지털적으로 코딩된(아마도 압축된) 성분이다. 예를 들어, 표현의 코딩된 비디오 또는 오디오 부분은 엘리먼터리 스트림일 수 있다. 엘리먼터리 스트림은 비디오 파일 내에 캡슐화되기 전에 패킷화된 엘리먼터리 스트림(PES)로 변환될 수 있다. 동일한 표현 내에서, 스트림 ID는 다른 엘리멘터리 스트림으로부터, 하나의 엘리먼터리 스트림에 속하는 PES-패킷들을 구별하기 위하여 사용될 수 있다. 엘리멘터리 스트림의 데이터의 기본 유닛은 패킷화된 엘리먼터리 스트림(PES) 패킷이다. 따라서, 코딩된 비디오 데이터는 일반적으로 엘리멘터리 비디오 스트림들에 대응한다. 유사하게, 오디오 데이터는 하나 또는 그 초과의 개별 엘리멘터리 스트림들에 대응한다.
[0075] ITU-T H.264/AVC 및 다가오는 HEVC(High Efficiency Video Coding: 고효율성 비디오 코딩) 표준 같은 많은 비디오 코딩 표준들은 신택스(syntax), 시맨틱(semantic)들, 및 에러 없는 비트스트림들을 위한 디코딩 프로세스를 정의하고, 이중 임의의 것은 특정 프로파일 또는 레벨에 따른다. 비디오 코딩 표준들은 통상적으로 인코더를 특정하는 것이 아니고, 인코더는 생성된 비트스트림들이 디코더에 순응하는 표준인 것을 보장하는 역할을 한다. 비디오 코딩 표준들의 환경에서, "프로파일"은 알고리즘, 피처들, 툴들 및 이들에 적용하는 제약들의 서브세트에 대응한다. 예를 들어 H.264 표준에 의해 정의된 바와 같이, "프로파일"은 H.264 표준에 의해 특정된 전체 비트스트림 신택스의 서브세트이다. "레벨"은 픽처(picture)들의 해상도, 비트 레이트, 및 블록 프로세싱 레이트에 관련된 예를 들어, 디코더 메모리 및 계산 같은 디코더 자원 소비의 제한들에 대응한다. 프로파일은 프로파일_idc(프로파일 표시자) 값으로 표시될 수 있는 반면, 레벨은 레벨_idc(레벨 표시자) 값으로 표시될 수 있다.
[0076] 예를 들어 H.264 표준은 주어진 프로파일의 신택스에 의해 부과된 한계들 내에서, 디코딩된 픽처들의 특정 사이즈 같은 비트스트림 내 신택스 엘리먼트들에 의해 취해진 값들에 따라 인코더들 및 디코더들의 성능의 큰 변동을 요구하는 것이 여전히 가능하다는 것을 인식한다. H.264 표준은, 많은 애플리케이션들에서, 특정 프로파일 내의 신택스의 모든 가상적인 용도들을 다룰 수 있는 디코더를 구현하기에 현실적이지도 경제적이지도 않다는 것을 추가로 인식한다. 따라서, H.264 표준은 비트스트림 내 신택스 엘리먼트들의 값들에 부과된 특정 제약들의 세트로서 "레벨"을 정의한다. 이들 제약들은 값들에 대한 간단한 제한들일 수 있다. 대안적으로, 이들 제약들은 값들의 산술 결합들에 대한 제약들의 형태(예를 들어, 초당 디코딩된 픽처들의 수에 의해 곱셈된 픽처 높이에 의해 곱셈된 픽처 폭)를 취할 수 있다. H.264 표준은, 개별 구현들이 각각의 지원된 프로파일에 대해 상이한 레벨을 지원할 수 있다는 것을 추가로 제공한다.
[0077] 프로파일에 따른 디코더는 보통 프로파일에 정의된 모든 피처들을 지원한다. 예를 들어, 코딩 피처로서, B-픽처 코딩은 H.264/AVC의 베이스라인(baseline) 프로파일에서 지원되는 것이 아니라 H.264/AVC의 다른 프로파일들에서 지원된다. 레벨에 따른 디코더는 레벨에서 정의된 제한들을 넘는 자원들을 요구하지 않는 임의의 비트스트림을 디코딩할 수 있어야 한다. 프로파일들 및 레벨들의 정의들은 해석능력에 도움이 될 수 있다. 예를 들어, 비디오 송신 동안, 한 쌍의 프로파일 및 레벨 정의들은 전체 송신 세션에 대해 협상 및 합의될 수 있다. 보다 구체적으로, H.264/AVC에서, 레벨은 프로세싱될 필요가 있는 매크로블록들의 수, 디코딩된 픽처 버퍼(DPB) 사이즈, 코딩된 픽처 버퍼(CPB) 사이즈, 수직 움직임 벡터 범위, 두 개의 연속적인 MB들당 움직임 벡터들의 최대 수, 및 B-블록이 8×8 픽셀들 미만의 서브-매크로블록 분할(partition)들을 가질 수 있는지에 대한 제한들을 정의할 수 있다. 이런 방식으로, 디코더는, 디코더가 비트스트림을 적당하게 디코딩할 수 있는지를 결정할 수 있다.
[0078] 스토리지, 콘텐츠 준비 디바이스(20)의 캡슐화 유닛(30)은 비디오 인코더(28)로부터 코딩된 비디오 데이터를 포함하는 엘리멘터리 스트림들 및 오디오 인코더(26)로부터 코딩된 오디오 데이터를 포함하는 엘리멘터리 스트림들을 수신한다. 몇몇 예들에서, 비디오 인코더(28) 및 오디오 인코더(26)는 각각 인코딩된 데이터로부터 PES 패킷들을 형성하기 위한 패킷화기들을 포함할 수 있다. 다른 예들에서, 비디오 인코더(28) 및 오디오 인코더(26)는 인코딩된 데이터로부터 PES 패킷들을 형성하기 위한 개별 패킷화기들과 각각 인터페이스할 수 있다. 또 다른 예들에서, 캡슐화 유닛(30)은 인코딩된 오디오 및 비디오 데이터로부터 PES 패킷들을 형성하기 위한 패킷화기들을 포함할 수 있다.
[0079] 비디오 인코더(28)는 다양한 비트레이트들에서 그리고 다양한 특성들, 이를테면 픽셀 해상도들, 프레임 레이트들, 다양한 코딩 표준들에 대한 순응, 다양한 프로파일들 및/또는 다양한 코딩 표준들에 대한 프로파일들의 레벨들에 대한 순응, 하나 또는 다수의 뷰들(예를 들어, 2차원 또는 3차원 재생에 대해)을 가진 표현들, 또는 다른 그런 특성들을 사용하여 멀티미디어 콘텐츠의 상이한 표현들을 생성하기 위하여, 다양한 방식으로 멀티미디어 콘텐츠의 비디오 데이터를 인코딩할 수 있다. 본 개시에 사용된 바와 같은 표현은 오디오 데이터 및 비디오 데이터, 예를 들어 하나 또는 그 초과의 오디오 엘리멘터리 스트림 및 하나 또는 그 초과의 비디오 엘리멘터리 스트림들의 결합을 포함할 수 있다. 각각의 PES 패킷은 PES 패킷이 속하는 엘리먼터리 스트림을 식별하는 스트림_id를 포함할 수 있다. 캡슐화 유닛(30)은 엘리멘터리 스트림들을 다양한 표현들의 비디오 파일들로 어셈블링하는 것을 담당한다.
[0080] 캡슐화 유닛(30)은 오디오 인코더(26) 및 비디오 인코더(28)로부터의 표현의 엘리멘터리 스트림들에 대한 PES 패킷들을 수신하고 PES 패킷들로부터 대응하는 네트워크 추상 계층(NAL) 유닛들을 형성한다. H.264/AVC(Advanced Video Coding: 어드밴스드 비디오 코딩)의 예에서, 코딩된 비디오 세그먼트들은 NAL 유닛들로 구조화되고, NAL 유닛들은 비디오 전화, 스토리지, 브로드캐스트, 또는 스트리밍 같은 애플리케이션들을 어드레싱하는 "네트워크-친화" 비디오 표현을 제공한다. NAL 유닛들은 비디오 코딩 계층(VCL) NAL 유닛들 및 비-VCL NAL 유닛들로 카테고리화될 수 있다. ACL 유닛들은 코어 압축 엔진을 포함할 수 있고 블록, 매크로블록, 및/또는 슬라이스 레벨 데이터를 포함할 수 있다. 다른 NAL 유닛들은 비-VCL NAL 유닛들일 수 있다. 몇몇 예들에서, 주 코딩된 픽처로서 보통 제시된 하나의 시간 인스턴스에서 코딩된 픽처는 하나 또는 그 초과의 NAL 유닛들을 포함할 수 있는 액세스 유닛에 포함될 수 있다.
[0081] 비-VCL NAL 유닛들은 여러가지 들 중에서 파라미터 세트 NAL 유닛들 및 SEI NAL 유닛들을 포함할 수 있다. 파라미터 세트들은 시퀀스-레벨 헤더 정보(시퀀스 파라미터 세트들(SPS)에서) 및 덜 빈번하게 변화하는 픽처-레벨 헤더 정보(픽처 파라미터 세트들(PPS)에서)를 포함할 수 있다. 파라미터 세트들(예를 들어, PPS 및 SPS)을 사용하여, 덜 빈번하게 변화하는 정보는 각각의 시퀀스 또는 픽처에 대해 반복될 필요가 없고, 따라서 코딩 효율성이 개선될 수 있다. 게다가, 파라미터 세트들의 사용은 중요한 헤더 정보의 대역외 송신을 가능하게 할 수 있고, 에러 회복력을 위한 리던던트 송신들에 대한 필요가 회피된다. 대역외 송신 예들에서, 파라미터 세트 NAL은 SEI NAL 유닛들 같은 다른 NAL 유닛들과 상이한 채널 상에서 전송될 수 있다.
[0082] 보충 강화 정보(SEI: Supplemental Enhancement Information)는 VCL NAL 유닛들로부터 코딩된 픽처 샘플들을 디코딩하기 위하여 필요하지 않지만, 디코딩, 디스플레이, 에러 회복력, 및 다른 목적들에 관련된 프로세스들에 도움을 줄 수 있는 정보를 포함할 수 있다. SEI 메시지들은 비-VCL NAL 유닛들에 포함될 수 있다. SEI 메시지들은 몇몇 표준 사양들의 규범적인 부분이고, 따라서 표준 순응 디코더 구현을 위하여 항상 의무적이지 않다. SEI 메시지들은 시퀀스 레벨 SEI 메시지들 또는 픽처 레벨 SEI 메시지들일 수 있다. 몇몇 시퀀스 레벨 정보는 SVC의 예에서 스케일러빌러티(scalability) 정보 SEI 메시지들 및 MVC에서 뷰 스케일러빌러티 정보 SEI 메시지들 같은 SEI 메시지들에 포함될 수 있다. 이들 예시적인 SEI 메시지들은 예를 들어 동작 포인트들의 추출 및 동작 포인트들의 특성들에 대한 정보를 전달할 수 있다. 게다가, 캡슐화 유닛(30)은 표현들의 특성들을 설명하는 미디어 표현 기술자(MPD: media presentation descriptor) 같은 매니페스트 파일을 형성할 수 있다. 캡슐화 유닛(30)은 XML(extensible markup language)에 따라 MPD를 포맷화할 수 있다.
[0083] 캡슐화 유닛(30)은 매니페스트 파일(예를 들어, MPD)과 함께 멀티미디어 콘텐츠의 하나 또는 그 초과의 표현들에 대한 데이터를 출력 인터페이스(32)에 제공할 수 있다. 출력 인터페이스(32)는 네트워크 인터페이스 또는 스토리지 매체에 기록하기 위한 인터페이스, 이를테면 USB(universal serial bus) 인터페이스, CD 또는 DVD 기록기 또는 버너(burner), 자기 또는 플래시 스토리지 미디어에 대한 인터페이스, 또는 미디어 데이터를 저장하거나 전송하기 위한 다른 인터페이스들을 포함할 수 있다. 캡슐화 유닛(30)은 네트워크 송신 또는 스토리지 미디어를 통해 데이터를 서버 디바이스(60)에 전송할 수 있는 출력 인터페이스(32)에, 멀티미디어 콘텐츠의 표현들 각각의 데이터를 제공할 수 있다. 도 1의 예에서, 서버 디바이스(60)는 다양한 멀티미디어 콘텐츠(64)를 저장하는 스토리지 매체(62)를 포함하고, 다양한 멀티미디어 콘텐츠(64) 각각은 개별 매니페스트 파일(66) 및 하나 또는 그 초과의 표현들(68A-68N)(표현들(68))을 포함한다. 몇몇 예들에서, 출력 인터페이스(32)는 또한 데이터를 직접 네트워크(74)에 전송할 수 있다.
[0084] 몇몇 예들에서, 표현들(68)은 적응 세트들로 분리될 수 있다. 즉, 표현들(68)의 다양한 서브세트들은 특성들의 개별 공통 세트들, 이를테면 코덱, 프로파일 및 레벨, 해상도, 뷰들의 수, 세그먼트들에 대한 파일 포맷, 언어 또는 표현과 함께 디스플레이될 텍스트의 다른 특성들을 식별할 수 있는 텍스트 타입 정보 및/또는 예를 들어 스피커들에 의해 디코딩되고 제시될 오디오 데이터, 적응 세트에서 표현들에 대한 장면의 카메라 각도 또는 실세계 카메라 관점을 설명할 수 있는 카메라 각도 정보, 특정 청중들에 대한 콘텐츠 적합을 설명하는 레이팅 정보 등을 포함할 수 있다.
[0085] 매니페스트 파일(66)은 특정 적응 세트들에 대응하는 표현들(68)의 서브세트들뿐 아니라, 적응 세트들에 대한 공통 특성들을 가리키는 데이터를 포함할 수 있다. 매니페스트 파일(66)은 또한, 적응 세트들의 개별 표현들에 대한 개별 특성들, 이를테면 비트레이트들을 나타내는 데이터를 포함할 수 있다. 이런 방식으로, 적응 세트는 간략화된 네트워크 대역폭 적응을 위해 제공할 수 있다. 적응 세트의 표현들은 매니페스트 파일(66)의 적응 세트 엘리먼트의 차일드(child) 엘리먼트들을 사용하여 가리켜질 수 있다.
[0086] 서버 디바이스(60)는 요청 프로세싱 유닛(70) 및 네트워크 인터페이스(72)를 포함한다. 몇몇 예들에서, 서버 디바이스(60)는 복수의 네트워크 인터페이스들을 포함할 수 있다. 게다가, 서버 디바이스(60)의 피처들 중 임의의 피처 또는 모든 피처는 콘텐츠 전달 네트워크의 다른 디바이스들, 이를테면 라우터들, 브리지(bridge)들, 프록시 디바이스들, 스위치들, 또는 다른 디바이스들 상에 구현될 수 있다. 몇몇 예들에서, 콘텐츠 전달 네트워크의 중간 디바이스들은 멀티미디어 콘텐츠(64)의 데이터를 캐시할 수 있고, 실질적으로 서버 디바이스(60)의 컴포넌트들에 따른 컴포넌트들을 포함할 수 있다. 일반적으로, 네트워크 인터페이스(72)는 네트워크(74)를 통해 데이터를 전송하거나 수신하도록 구성된다.
[0087] 요청 프로세싱 유닛(70)은 스토리지 매체(62)의 데이터에 대한 네트워크 요청들을 클라이언트 디바이스들, 이를테면 클라이언트 디바이스(40)로부터 수신하도록 구성된다. 예를 들어, 요청 프로세싱 유닛(70)은, 1999년 6월, Network Group, IETF, R. Fielding 등에 의한 "Hypertext Transfer Protocol - HTTP/1.1" RFC 2616에서 설명된 바와 같이, HTTP(hypertext transfer protocol) 버전 1.1을 구현할 수 있다. 즉, 요청 프로세싱 유닛(70)은 HTTP GET 또는 부분 GET 요청들을 수신하고 요청들에 응답하여 멀티미디어 콘텐츠(64)의 데이터를 제공하도록 구성될 수 있다. 요청들은 예를 들어 세그먼트의 URL을 사용하여 표현들(68) 중 하나의 세그먼트를 특정할 수 있다. 몇몇 예들에서, 요청들은 또한 세그먼트의 하나 또는 그 초과의 바이트 범위들을 특정할 수 있어서, 부분 GET 요청들이 포함된다. 요청 프로세싱 유닛(70)은 표현들(68) 중 하나의 세그먼트의 헤더 데이터를 제공하기 위하여 HTTP HEAD 요청들을 서비스하도록 추가로 구성될 수 있다. 임의의 경우, 요청 프로세싱 유닛(70)은 클라이언트 디바이스(40) 같은 요청 디바이스에, 요청된 데이터를 제공하기 위한 요청들을 프로세싱하도록 구성될 수 있다.
[0088] 부가적으로 또는 대안적으로, 요청 프로세싱 유닛(70)은 eMBMS 같은 멀티캐스트 프로토콜 또는 브로드캐스트를 통해 미디어 데이터를 전달하도록 구성될 수 있다. 콘텐츠 준비 디바이스(20)는 설명된 것과 실질적으로 동일한 방식으로 DASH 세그먼트들 및/또는 서브-세그먼트들을 생성할 수 있지만, 서버 디바이스(60)는 eMBMS 또는 다른 브로드캐스트 또는 멀티캐스트 네트워크 전송 프로토콜을 사용하여 이들 세그먼트들 또는 서브-세그먼트들을 전달할 수 있다. 예를 들어, 요청 프로세싱 유닛(70)은 클라이언트 디바이스(40)로부터 멀티캐스트 그룹 조인 요청을 수신하도록 구성될 수 있다. 즉, 서버 디바이스(60)는 특정 미디어 콘텐츠(예를 들어, 라이브 이벤트의 브로드캐스트)와 연관된 멀티캐스트 그룹과 연관된 인터넷 프로토콜(IP) 어드레스를, 클라이언트 디바이스(40)를 포함하는 클라이언트 디바이스들에 광고할 수 있다. 차례로 클라이언트 디바이스(40)는 멀티캐스트 그룹을 조인하기 위한 요청을 제출할 수 있다. 이 요청은 네트워크(74), 예를 들어 네트워크(74)를 구성하는 라우터들을 통해 전파될 수 있어서, 라우터들에 의해 멀티캐스트 그룹과 연관된 IP 어드레스에 대해 예정된 트래픽이 클라이언트 디바이스(40) 같은 가입 클라이언트 디바이스들에 지향하게 된다.
[0089] 도 1의 예에 예시된 바와 같이, 멀티미디어 콘텐츠(64)는 MPD(media presentation description)에 대응할 수 있는 매니페스트 파일(66)을 포함한다. 매니페스트 파일(66)은 상이한 대안적인 표현들(68)(예를 들어, 상이한 품질들을 가진 비디오 서비스들)의 설명들을 포함할 수 있고 설명은 예를 들어, 코덱 정보, 프로파일 값, 레벨 값, 비트레이트, 및 표현들(68)의 다른 설명 특성들을 포함할 수 있다. 클라이언트 디바이스(40)는 표현(68)들의 세그먼트들에 액세스하는 방법을 결정하기 위하여 미디어 표현의 MPD를 리트리브할 수 있다.
[0090] 특히, 리트리벌 유닛(52)은 비디오 디코더(48)의 디코딩 능력들을 및 비디오 출력(44)의 렌더링 능력들을 결정하기 위하여 클라이언트 디바이스(40)의 구성 데이터(도시되지 않음)를 리트리브할 수 있다. 구성 데이터는 클라이언트 디바이스(40)의 사용자에 의해 선택된 언어 선호도, 클라이언트 디바이스(40)의 사용자에 의해 설정된 깊이 선호도들에 대응하는 하나 또는 그 초과의 카메라 관점들, 및/또는 클라이언트 디바이스(40)의 사용자에 의해 선택된 레이팅 선호도 중 임의의 또는 모두를 포함할 수 있다. 리트리벌 유닛(52)은 예를 들어, HTTP GET 및 부분 GET 요청들을 제출하도록 구성된 웹 브라우저 또는 미디어 클라이언트를 포함할 수 있다. 리트리벌 유닛(52)은 클라이언트 디바이스(40)의 하나 또는 그 초과의 프로세서들 또는 프로세싱 유닛들(도시되지 않음)에 의해 실행된 소프트웨어 명령들에 대응할 수 있다. 몇몇 예들에서, 리트리벌 유닛(52)에 관하여 설명된 기능성의 모두 또는 일부들은 하드웨어, 또는 하드웨어, 소프트웨어의 결합, 및/또는 펌웨어로 구현될 수 있고, 여기서 필요한 하드웨어는 소프트웨어 또는 펌웨어에 대한 명령들을 실행하기 위하여 제공될 수 있다.
[0091] 리트리벌 유닛(52)은 클라이언트 디바이스(40)의 디코딩 및 렌더링 능력들을 매니페스트 파일(66)의 정보에 의해 표시된 표현들(68)의 특성들에 비교할 수 있다. 리트리벌 유닛(52)은 처음에 표현들(68)의 특성들을 결정하기 위하여 매니페스트 프로파일(66)의 적어도 일부를 리트리브할 수 있다. 예를 들어, 리트리벌 유닛(52)은 본 개시의 기술들에 따라, 하나 또는 그 초과의 적응 세트들의 특성들을 설명하는 매니페스트 파일(66)의 일부를 요청할 수 있다. 리트리벌 유닛(52)은 클라이언트 디바이스(40)의 코딩 및 렌더링 능력들에 의해 만족될 수 있는 특성들을 가진 표현들(68)(예를 들어, 적응 세트)의 서브세트를 선택할 수 있다. 그 다음 리트리벌 유닛(52)은 적응 세트의 표현들에 대한 비트레이트들을 결정하고, 네트워크 대역폭의 현재 이용 가능한 양을 결정하고, 그리고 네트워크 대역폭에 의해 만족될 수 있는 비트레이트를 가진 표현들 중 하나로부터 세그먼트들을 리트리브할 수 있다.
[0092] 일반적으로, 보다 높은 비트레이트 표현들은 보다 높은 품질 비디오 재생을 생성할 수 있는 반면, 보다 낮은 비트레이트 표현들은 이용 가능한 네트워크 대역폭이 감소할 때 충분한 품질 비디오 재생을 제공할 수 있다. 따라서, 이용 가능한 네트워크 대역폭이 비교적 높을 때, 리트리벌 유닛(52)은 비교적 높은 비트레이트 표현들로부터 데이터를 리트리브할 수 있는 반면, 이용 가능한 네트워크 대역폭이 낮을 때, 리트리벌 유닛(52)은 비교적 낮은 비트레이트 표현들로부터 데이터를 리트리브할 수 있다. 이런 방식으로, 클라이언트 디바이스(40)는 또한 네트워크(74)의 변화하는 네트워크 대역폭 이용 가능성에 적응하면서 네트워크(74)를 통해 멀티미디어 데이터를 스트리밍할 수 있다.
[0093] 부가적으로 또는 대안적으로, 리트리벌 유닛(52)은 eMBMS 또는 IP 멀티캐스트 같은 브로드캐스트 또는 멀티캐스트 네트워크 프로토콜에 따라, 데이터를 수신하도록 구성될 수 있다. 그런 예들에서, 리트리벌 유닛(52)은 특정 미디어 콘텐츠와 연관된 멀티캐스트 네트워크 그룹을 조인하기 위한 요청을 제출할 수 있다. 멀티캐스트 그룹을 조인한 후, 리트리벌 유닛(52)은 추가 요청들이 서버 디바이스(60) 또는 콘텐츠 준비 디바이스(20)에 발행됨이 없이 멀티캐스트 그룹의 데이터를 수신할 수 있다. 리트리벌 유닛(52)은 예를 들어 재생을 멈추거나 채널들을 상이한 멀티캐스트 그룹으로 변경하기 위하여, 멀티캐스트 그룹의 데이터가 더 이상 필요하지 않을 때 멀티캐스트 그룹을 떠나기 위한 요청을 제출할 수 있다.
[0094] 네트워크 인터페이스(54)는 선택된 표현의 세그먼트들의 데이터를 수신하여 리트리벌 유닛(52)에 제공할 수 있고, 리트리벌 유닛(52)은 차례로 세그먼트들을 캡슐화 해제(decapsulation) 유닛(50)에 제공할 수 있다. 캡슐화 해제 유닛(50)은, 비디오 파일의 엘리먼트들을 구성성분(constituent) PES 스트림들로 캡슐화 해제하고, 인코딩된 데이터를 리트리브하기 위하여 PES 스트림들을 패킷화 해제하고, 그리고 예를 들어 스트림의 PES 패킷 헤더들에 의해 표시된 바와 같이, 인코딩된 데이터가 오디오 스트림의 일부인지 비디오 스트림의 일부인지에 따라, 인코딩된 데이터를 오디오 디코더(46) 또는 비디오 디코더(48)에 전송할 수 있다. 오디오 디코더(46)는 인코딩된 오디오 데이터를 디코딩하고 디코딩된 오디오 데이터를 오디오 출력(42)에 전송하고, 비디오 디코더(48)는 인코딩된 비디오 데이터를 디코딩하고 스트림의 복수의 뷰들을 포함할 수 있는 디코딩된 비디오 데이터를 비디오 출력(44)에 전송한다.
[0095] 비디오 인코더(28), 비디오 디코더(48), 오디오 인코더(26), 오디오 디코더(46), 캡슐화 유닛(30), 리트리벌 유닛(52), 및 캡슐화 해제 유닛(50) 각각은 적용할 수 있는 바와 같은 다양한 적당한 프로세싱 회로 중 임의의 회로, 이를테면 하나 또는 그 초과의 마이크로프로세서들, 디지털 신호 프로세서(DSP)들, 주문형 집적 회로(ASIC)들, 필드 프로그램 가능 게이트 어레이(FPGA)들, 이산 로직 회로, 소프트웨어, 하드웨어, 펌웨어 또는 이들의 임의의 결합들로서 구현될 수 있다. 비디오 인코더(28) 및 비디오 디코더(48)의 각각은 하나 또는 그 초과의 인코더들 또는 디코더들에 포함될 수 있고, 이중 어느 하나는 결합된 비디오 인코더/디코더(CODEC)의 부분으로서 통합될 수 있다. 마찬가지로, 오디오 인코더(26) 및 오디오 디코더(46)의 각각은 하나 또는 그 초과의 인코더들에 포함될 수 있고, 이중 어느 하나는 결합된 CODEC의 부분으로서 통합될 수 있다. 비디오 인코더(28), 비디오 디코더(48), 오디오 인코더(26), 오디오 디코더(46), 캡슐화 유닛(30), 리트리벌 유닛(52), 및/또는 캡슐화 해제 유닛(50)을 포함하는 장치는 집적 회로, 마이크로프로세서, 및/또는 무선 통신 디바이스, 이를테면 셀룰러 전화를 포함할 수 있다.
[0096] 클라이언트 디바이스(40), 서버 디바이스(60), 및/또는 콘텐츠 준비 디바이스(20)는 본 개시의 기술들에 따라 동작하도록 구성될 수 있다. 예의 목적들을 위해, 본 개시는 클라이언트 디바이스(40) 및 서버 디바이스(60)에 관하여 이들 기술들을 설명한다. 그러나, 콘텐츠 준비 디바이스(20)가 서버 디바이스(60) 대신 이들 기술들을 수행하도록 구성될 수 있다는 것이 이해되어야 한다.
[0097] 캡슐화 유닛(30)은 NAL 유닛이 속하는 프로그램을 식별하는 헤더뿐 아니라, 페이로드, 예를 들어 오디오 데이터, 비디오 데이터, 또는 NAL 유닛이 대응하는 전송 또는 프로그램 스트림을 설명하는 데이터를 포함하는 NAL 유닛들을 형성할 수 있다. 예를 들어, H.264/AVC에서, NAL 유닛은 1-바이트 헤더 및 가변 사이즈의 페이로드를 포함한다. 자신의 페이로드에 비디오 데이터를 포함하는 NAL 유닛은 비디오 데이터의 다양한 입도 레벨들을 포함할 수 있다. 예를 들어, NAL 유닛은 비디오 데이터의 블록, 복수의 블록들, 비디오 데이터의 슬라이스, 또는 비디오 데이터의 전체 픽처를 포함할 수 있다. 캡슐화 유닛(30)은 엘리멘터리 스트림들의 PES 패킷들 형태의 인코딩된 비디오 데이터를 비디오 인코더(28)로부터 수신할 수 있다. 캡슐화 유닛(30)은 각각의 엘리먼터리 스트림을 대응하는 프로그램과 연관시킬 수 있다.
[0098] 캡슐화 유닛(30)은 또한 복수의 NAL 유닛들로부터 액세스 유닛들을 어셈블링할 수 있다. 일반적으로, 액세스 유닛은 비디오 데이터의 프레임뿐 아니라, 오디오 데이터가 이용 가능할 때 프레임에 대응하는 그런 오디오 데이터를 표현하기 위한 하나 또는 그 초과의 NAL 유닛들을 포함할 수 있다. 액세스 유닛은 일반적으로 하나의 출력 시간 인스턴스에 대해 모든 NAL 유닛들, 예를 들어 하나의 시간 인스턴스에 대해 모든 오디오 및 비디오 데이터를 포함한다. 예를 들어, 각각의 뷰가 초당 20 프레임들(fps)의 프레임 레이트를 가지면, 각각의 시간 인스턴스는 0.05 초의 시간 간격에 대응할 수 있다. 이런 시간 간격 동안, 동일한 액세스 유닛(동일한 시간 인스턴스)의 모든 뷰들에 대한 특정 프레임들은 동시에 렌더링될 수 있다. 일 예에서, 액세스 유닛은 주 코딩된 픽처로서 제시될 수 있는 하나의 시간 인스턴스에서 코딩된 픽처를 포함할 수 있다. 따라서, 액세스 유닛은 공통 시간 인스턴스의 모든 오디오 및 비디오 프레임들, 예를 들어 시간(X)에 대응하는 모든 뷰들을 포함할 수 있다. 본 개시는 또한 "뷰 컴포넌트"로서 특정 뷰의 인코딩된 픽처를 참조한다. 즉, 뷰 컴포넌트는 특정 시간에서 특정 뷰에 대한 인코딩된 픽처(또는 프레임)를 포함할 수 있다. 따라서, 액세스 유닛은 공통 시간 인스턴스의 모든 뷰 컴포넌트들을 포함하는 것으로 정의될 수 있다. 액세스 유닛들의 디코딩 순서는 반드시 출력 또는 디스플레이순서와 동일할 필요가 없다.
[0099] 미디어 표현은 상이한 대안적인 표현들(예를 들어, 상이한 품질들을 가진 비디오 서비스들)의 설명들을 포함할 수 있는 MPD(media presentation description)를 포함할 수 있고 설명은 예를 들어 코덱 정보, 프로파일 값, 및 레벨 값을 포함할 수 있다. MPD는 매니페스트 파일(66) 같은 매니페스트 파일의 하나의 예이다. 클라이언트 디바이스(40)는 다양한 표현들의 영화 프레그먼트들에 액세스하는 방법을 결정하기 위하여 미디어 표현의 MPD를 리트리브할 수 있다. 영화 프레그먼트들은 비디오 파일들의 영화 프레그먼트 박스들(moof 박스들)에 위치될 수 있다.
[0100] 매니페스트 파일(66)(예를 들어, MPD를 포함할 수 있음)은 표현들(68)의 세그먼트들의 이용 가능성을 광고할 수 있다. 즉, MPD는 표현들(68) 중 하나의 제 1 세그먼트가 이용 가능하게 되는 월-클럭 시간을 가리키는 정보뿐 아니라, 표현들(68) 내의 세그먼트들의 지속시간들을 가리키는 정보를 포함할 수 있다. 이런 방식으로, 클라이언트 디바이스(40)의 리트리벌 유닛(52)은 시작 시간뿐 아니라 특정 세그먼트를 선행하는 세그먼트들의 지속시간들에 기초하여, 각각의 세그먼트가 이용 가능할 때를 결정할 수 있다. 리트리벌 유닛(52)은 처음에 클라이언트 디바이스(40)의 내부 클럭을 서버 디바이스(60)(또는 콘텐츠 준비 디바이스(20))의 클럭에 동기화할 수 있고, 그 다음 세그먼트들이 이용 가능하게 되자마자 표현들(68) 중 하나 또는 그 초과로 부터 세그먼트들을 요청할 수 있다(예를 들어, 적응으로 인해).
[0101] 그러나, 몇몇 경우들에서, 클라이언트 디바이스(40)의 내부 클럭은 서버 디바이스(60)의 클럭에 관하여 드리프트할 수 있다. 리트리벌 유닛(52)은 그런 드리프트를 처리하기 위하여 클라이언트 디바이스(40)의 클럭을 동기화하기 위해 본 개시의 기술들을 활용하도록 구성될 수 있다. 이런 방식으로, 리트리벌 유닛(52)은 표현들(68) 중 하나 또는 그 초과의 특정 파일들이 리트리벌을 위하여 이용가능 한지를 결정하기 위하여 클라이언트 디바이스(40)의 재동기화된 클럭 및 매니페스트 파일(66)의 데이터를 사용할 수 있다.
[0102] 일반적으로, 본 개시의 기술들은, 클라이언트 디바이스(40)가 세그먼트 이용 가능성 윈도우의 "에지들" 중 어느 하나 또는 양쪽을 검출하기 위하여 다수의 프로빙 요청들(예를 들어, 미디어 세그먼트들에 대한 HTTP HEAD 요청들)을 전송하는 것을 포함한다. 세그먼트 이용 가능성 윈도우는 리트리벌을 위해 현재 이용 가능한 세그먼트들의 세트에 대응할 수 있다. "가장 오래된" 에지(또한 때때로 "좌측" 에지로 지칭됨)는 세그먼트 이용 가능성 윈도우의 가장 이른 세그먼트의 시작에 대응할 수 있고, "가장 새로운" 에지(또한 때때로 "우측 에지"로 지칭됨)는 세그먼트 이용 가능성 윈도우의 가장 최큰 세그먼트의 엔드(end)에 대응할 수 있다. 이들 에지들에 기초하여, 클라이언트 디바이스(40)의 리트리벌 유닛(52)은 클라이언트 디바이스(40)의 클럭과 서버 디바이스(60)의 클럭 사이의 시간 델타를 추론할 수 있다. 다른 말로, 리트리벌 유닛(52)은 서버 디바이스(60)에 의해 제공된 프로빙 요청들에 대한 응답들에 기초하여, 세그먼트 이용 가능성 윈도우의 좌측 및 우측 에지들을 결정할 수 있다. 프로빙 요청들에 대한 이들 응답들은 서버 디바이스(60)의 세그먼트 이용 가능성 윈도우의 이해에 기초할 수 있다.
[0103] 일반적으로, 세그먼트 이용 가능성 윈도우의 우측 에지는, 우측 에지가 실시간 비디오 제작 지연에 의해 제한되기 때문에, 보다 유용하다고 생각될 수 있다. 우측 에지를 추정하는 것은 세그먼트들의 성공적인 리트리벌 사이의 우수한 트레이드오프(tradeoff), 및 불필요한 엔드-투-엔드 레이턴시의 최소화 달성을 도울 수 있다. 세그먼트 이용 가능성 윈도우의 좌측 에지는 이용 가능성 시작 시간 및 TSBD(time shift buffer depth) 양쪽에 의해 제어된다. TSBD는 MPD(예를 들어, 매니페스트 파일(66))의 선택적 속성이다. "동적" MPD 타입에 대해, TSBD는 MPD로부터 미싱될 때 "무한"으로서 해석되어야 한다. TSBD가 무한일 때, 세그먼트 이용 가능성 시작 시간 이후에 세그먼트 요청 시간이 존재하자, 세그먼트는 항상 이용 가능해야 한다.
[0104] 시간 델타 추정 알고리즘은 다수의 실패들이 시작 시간에서 세그먼트 리트리벌 동안 발생할 때 백워드 프로빙 방법을 트리거할 수 있는 시작 트리거 로직 같은 몇몇 부분들을 포함할 수 있다. 백워드 프로빙 방법은 세그먼트 이용 가능성 윈도우의 우측 에지를 검출하도록 설계된다. 다른 방법은 백워드 프로빙이 결론을 못 낸 응답을 얻을 때, 또는 세그먼트 이용 가능성 윈도우의 우측 에지가 검출될 때 그리고 클라이언트 디바이스(40)의 리트리벌 유닛(52)이 시간에 걸쳐 우측 에지의 트랙을 유지하기를 원할 때 사용될 수 있는 포워드 프로빙 방법이라 불린다.
[0105] 세그먼트 이용 가능성 윈도우에 관련된 몇몇 개념들은 본 개시의 기술들을 보다 잘 이해하기 위하여 도움을 줄 수 있다. DASH 라이브 스트리밍에서, 세그먼트들은 주어진 세그먼트에 대한 미디어 제작(예를 들어, 콘텐츠 준비 디바이스(20)에 의해)이 완료되고 미디어 세그먼트가 서버 디바이스(60) 상에 저장될 대 이용 가능해 진다. MPD(도 1의 예에서 매니페스트 파일(66))로부터의 정보를 사용한 세그먼트 타임라인 계산을 통하여, 클라이언트 디바이스(40)의 리트리벌 유닛(52)은 세그먼트가 이용 가능하게 된 가장 이른 시간을 계산할 수 있다. 이것은 세그먼트 이용 가능성 시작 시간이라 불린다. 게다가, 시간 시프트 버퍼를 통해, 리트리벌 유닛(52)은 세그먼트가 이용 가능성 시작 시간으로부터 얼마나 오래 이용 가능할지를 결정할 수 있다. 스트리밍 애플리케이션의 요건에 기초하여, 리트리벌 유닛(52)은, 세그먼트가 이용 가능하게 되자마자 세그먼트를 리트리브하거나 최신 이용 가능한 세그먼트로부터 시간적으로 다소 뒤의 세그먼트를 리트리브하도록 구성될 수 있다.
[0106] 이들 두 개의 전략들은 각각 장점들 및 단점들을 가질 수 있다. 전자 전략은, 특히 비디오 제작 및 전달 프로세스에서 타이밍 지터(jitter)들을 마주할 때, 비디오 전달에서 잠재적으로 안정성을 희생하면서, 가능한 한 많이 마지막 순간까지(up-to-last) 콘텐츠를 뷰어에게 제시하도록 노력한다. 후자 전략은 통상적으로 가능한 보다 높은 엔드-투-엔드 레이턴시를 희생하여, 전체적으로 보다 나은 사용자 경험을 달성할 수 있다. 세그먼트 타임라인 및 TSBD를 사용하여, 리트리벌 유닛(52)은 임의의 주어진 월-클럭 시간에서, 어느 세그먼트들이 이용 가능한지를 결정할 수 있다. 세그먼트 이용 가능성 윈도우의 예는 하기 도 3에 관하여 설명된다.
[0107] 리트리벌 유닛(52)은 다양한 이유들 때문에 세그먼트 이용 가능성 윈도우(또는 세그먼트 이용 가능성 윈도우의 적어도 하나의 에지)를 결정하도록 구성될 수 있다. 예를 들어, 리트리벌 유닛(52)은 처음에 특정 라이브 스트림을 시작하기 위하여 세그먼트 이용 가능성 윈도우를 결정하도록 구성될 수 있다. 부가적으로 또는 대안적으로, 리트리벌 유닛(52)은 서버 디바이스(60)로부터 특정 수(또는 퍼센티지)의 에러 메시지들, 예를 들어 HTTP 404 에러 메시지들을 수신한 후 세그먼트 이용 가능성 윈도우를 결정하도록 구성될 수 있다.
[0108] 그런 에러들은, 클라이언트 디바이스(40)의 클럭이 서버 디바이스(60)의 클럭(또는 이용 가능성의 광고된 시간)으로부터 벗어날 때 발생할 수 있다. 즉, 그런 클럭 드리프트에 응답하여, 클라이언트 디바이스(40)는 세그먼트 이용 가능성 타임라인을 정확하게 결정하지 못할 것이다. 일 경우에서, 클라이언트 디바이스(40)의 클럭은 서버 디바이스(60)의 클럭을 앞설 수 있다. 클라이언트 디바이스(40)의 클럭이 서버 디바이스(60)의 클럭을 앞설 때 세그먼트들이 이용 가능하다는 것을(클라이언트 디바이스(40)의 클럭 및 세그먼트 이용 가능성 시작 시간을 사용하여) 리트리벌 유닛(52)이 결정하자마자 리트리벌 유닛(52)이 미디어 세그먼트들을 리트리브하도록 시도하면, 클라이언트는 미디어 세그먼트 요청들에 응답하여 HTTP 404 이용 불가능 에러 메시지들을 수신할 것이다. 리트리벌 유닛(52)이 보수적 시작 전략을 사용하면, 리트리벌 유닛(52)은 TSBD(즉, 세그먼트 이용 가능성 윈도우)의 좌측 에지로부터 미디어 세그먼트들을 요청할 수 있고, 따라서, 세그먼트 리트리벌은 성공할 수 있다. 그러나 그 경우에도, 클럭 델타는 리트리벌 유닛(52)이 예상된 양의 미디어 버퍼를 만드는 것을 방지할 수 있다.
[0109] 세그먼트 요청 실패 트리거 메커니즘은 세그먼트 이용 가능성 윈도우 결정 프로세스를 개시하기 위하여 사용될 수 있다. 세그먼트 요청 실패 트리거는 비디오 재생이 시작된 후 활성화할 수 있고 클라이언트 디바이스(40)는 미디어 세그먼트 요청들에 대한 404 에러 메시지들을 반복해서 수신한다. 클라이언트 디바이스(40)는 전송된 연이은 미디어 세그먼트 요청들의 수 및 이들 요청들에 대해 얻어진 404 에러 메시지 응답들의 수에 대한 런닝 카운트(running count)를 유지할 수 있다. 만약 클라이언트가 최종 Nr 미디어 세그먼트 요청들에 대해 Nf 또는 그 초과의 404 응답 코드를 수신하면, 프로빙 방법은 트리거되고, 여기서 Nf는 404 에러 코드를 가진 응답들의 수를 정의하는 구성 가능 파라미터이고, Nr은 전송된 연속적인 미디어 세그먼트 요청들의 수를 정의하는 구성 가능 파라미터이다. 몇몇 예들에서, Nr은 5의 값을 가질 수 있고, Nf는 2의 값을 가질 수 있다.
[0110] 부가적인 제어 파라미터, 최소 시간 간격(MTI: minimum time interval)은, 빈번한 프로빙 테스트들이 어떻게 수행되는지를 제어하기 위하여 사용될 수 있다. MTI는 프로브 요청들의 세트들 사이의 최소 시간 간격을 설명할 수 있다. 이 파라미터는, 프로빙이 높은 오버헤드를 발생시키도록 너무 빈번하게 수행되지 않는 것을 보장하기 위하여 사용될 수 있다. MTI의 하나의 예시적 시작 값은 1 분이다. MTI의 다른 값들은 예를 들어 수신된 에러들의 빈도에 기초하여 초기 값들 또는 동적으로 조절된 값들로서 사용될 수 있다.
[0111] 리트리벌 유닛(52)이 프로빙 결과를 얻은 후, 리트리벌 유닛(52)은 추정된 클럭 차이에 기초하여 리트리벌 거동을 조절할 수 있다. 다양한 동작들은 수행될 수 있고, 이들 동작들은 본래의 프로빙을 유발한 트리거에 기초할 수 있다.
[0112] 몇몇 인스턴스들에서, 시작 재생에 대한 실패는 프로빙을 유발할 수 있다. 프로빙이 제 1 장소에서 비디오 데이터의 재생을 시작하는 것을 실패에 앞서거나, 프로빙 알고리즘이 종료하기 전에 클라이언트 디바이스(40)가 이미 멈추어지면, 클라이언트 디바이스(40)의 DASH 클라이언트(리트리벌 유닛(52)에 대응할 수 있음)는 공전 상태로 고려될 수 있다. 이 경우, 리트리벌 유닛(52)은 조절된 서버 시간을 결정하기 위하여 클라이언트 디바이스(40)의 로컬 클럭에 시간 델타를 적용할 수 있다. 조절된 서버 시간을 사용하여, 리트리벌 유닛(52)은 결정된 시점으로부터 다운로딩을 시작할 수 있다. 이것은, 리트리벌 유닛(52)이 최신 이용 가능한 세그먼트 이후 몇 초의 세그먼트들을 요청하기 위하여(합리적인 버퍼를 만들기 위하여) 시간적으로 되돌아가는 것을 포함할 수 있다.
[0113] 다른 예로서, 부정확한 클라이언트 클럭을 사용한 성공적인 재생은 프로빙을 프롬프트할 수 있다. 클라이언트 디바이스(40)가 비디오 스트림을 이미 재생하고 있을 때, 시간 델타 추정 알고리즘을 사용함으로써, 클라이언트 디바이스(40)는 클라이언트 디바이스(40)의 로컬 클럭과 서버 디바이스(60)의 클럭 사이의 시간 델타가 있다는 것을 결정할 수 있다. 이 경우, 클라이언트 디바이스(40)는 다음 3개의 방식들 중 하나로 동작할 수 있다. 이들 클라이언트 동작들은 다음 예에 따라 설명된다. 클라이언트 디바이스(40)는 10초 버퍼를 만들고 10초 레이턴시를 가지기 위하여, 최신 이용 가능한 세그먼트로부터 다시 미디어 콘텐츠 10초를 요청함으로써, 미디어 버퍼와 엔드-투-엔드 레이턴시 사이의 최적 트레이드오프를 달성하도록 시도하는 것을 가정한다. 그러나, 제 1 경우에, 클라이언트 디바이스(40)의 로컬 클럭은 서버 디바이스(60) 클럭을 5초만큼 앞서있다. 결과적으로, 클라이언트 디바이스(40)는 최대 5초 미디어 버퍼만을 만들 수 있고, 최대 5초 레이턴시만을 가질 수 있다. 제 2 경우에서, 클라이언트 디바이스(40)의 로컬 클럭은 서버 디바이스(60)의 클럭을 5초만큼 뒤진다. 결과적으로, 클라이언트 디바이스(40)는 15초 레이턴시를 갖는 대가로, 15초 버퍼를 만들 수 있을 것이다.
[0114] 일 예에서, 클라이언트 디바이스(40)는 특정 동작을 취하지 않음으로써 성공적인 재생에 응답할 수 있다. 클라이언트 디바이스(40)는, 클라이언트 디바이스(40)의 실제 미디어 버퍼 및 레이턴시가 최적 트레이드오프로부터 5초 벗어나기 때문에, 시간 델타를 검출하는 것에 응답하여 임의의 추가 동작들을 수행하지 않도록 결정할 수 있다. 몇몇 인스턴스들에서, 클라이언트 디바이스(40) 내의 상이한 미디어 버퍼는 레이트 선택 알고리즘에서 상이한 레벨들의 침해성(aggressiveness)을 초래할 수 있다. 그러므로, 시간 델타(클라이언트 디바이스(40)의 로컬 클럭이 서버 디바이스(60)의 클럭을 앞서거나 뒤짐), 및 올바른 정보가 레이트 스위칭 알고리즘에 제공되면, 레이트 스위칭 알고리즘은 자연히 레이트 판정 침해성에 대한 내부 파라미터들을 조절할 수 있다.
[0115] 다른 예에서, 클라이언트 디바이스(40)는 미디어 데이터의 재생의 강제 조절을 수행할 수 있다. 예를 들어, 10초 미디어 버퍼 및 10초 레이턴시의 보다 최적 트레이드오프를 달성하기 위하여, 클라이언트 디바이스(40)는 뷰잉 경험의 품질을 일시적으로 떨어뜨리는 대가로 극단적으로 동작할 수 있다. 제 1 경우에서, 클라이언트 디바이스(40)의 로컬 클럭이 앞설 때, 클라이언트 디바이스(40)는 5초 동안 비디오 재생을 멈출 수 있고 목표된 10초 버퍼를 만들 수 있다. 일단 버퍼 레벨이 10초에 도달하면, 클라이언트 디바이스(40)는, 버퍼 레벨 및 레이턴시가 목표된 값에 있도록 재생을 재개할 수 있다. 클라이언트 디바이스(40)의 로컬 클럭이 뒤지는 경우, 클라이언트 디바이스(40)는 비디오 콘텐츠의 5초를 스킵할 수 있고 목표된 표현 시간(t-10)에 도달하기 위하여 4초만큼 표현을 점프할 수 있다. 이런 방식으로, 클라이언트 디바이스(40)는 보다 낮은 레이턴시를 달성할 수 있다. 일반적으로, 멈추지도 스킵하지도 않는 것은 우수한 사용자 경험을 초래할 것이다. 그러나 그런 동작이 추가 멈춤들을 감소시키거나 거의 실시간 뷰잉 경험을 제공하는 목적을 위해 단지 1회 수행되면, 극단적인 동작들은 정당화될 수 있다.
[0116] 이런 방식으로, 클라이언트 디바이스(40)의 로컬 클럭과 서버 디바이스(60)의 클럭 사이의 시간 차이가, 로컬 클럭이 서버 디바이스(60)의 클럭을 앞서는 것을 가리킬 때, 클라이언트 디바이스(40)는 시간 차와 동일한 시간 기간 동안 미디어 재생을 멈출 수 있다. 다른 한편, 클라이언트 디바이스(40)의 로컬 클럭과 서버 디바이스(60)의 클럭 사이의 시간 차이가, 로컬 클럭이 서버 디바이스(60)의 클럭 뒤에 있다는 것을 가리킬 때, 클라이언트 디바이스(40)는 시간 차이와 동일한 시간 기간 동안 미디어 재생을 스킵할 수 있다.
[0117] 또 다른 예에서, 클라이언트 디바이스(40)는 미디어 데이터의 재생의 비-강제적 조절을 수행할 수 있다. 예를 들어, 상기 논의된 바와 같이 멈춤 또는 스킵을 유도하는 것과 같은 강제적 동작들 대신, 보다 정교한 클라이언트는 동일한 목표를 달성하기 위하여 비-강제적 동작들을 사용할 수 있다. 클라이언트 디바이스(40)의 로컬 클럭이 시간적으로 앞설 때, 클라이언트 디바이스(40)는, 인코딩된 미디어의 매 1초가 (1+α) 초로 재생되도록 약간 재생 레이트를 느리게 할 수 있고, 여기서 α는 0.03 같은 작은 값이다. 재생 레이트를 느리게 함으로써, 클라이언트 디바이스(40)는 서서히 더 많은 미디어 버퍼를 만들 수 있고 레이턴시를 증가시킬 수 있다. 유사하게, 클라이언트 디바이스(40)의 로컬 클럭이 시간적으로 서버 디바이스(60)의 클럭 뒤에 있을 때, 클라이언트 디바이스(40)는 재생 레이트를 약간 가속시킬 수 있다. 그렇게 함으로써, 클라이언트는 서서히 미디어 버퍼를 소모할 수 있고 레이턴시를 감소시킬 수 있다. 일단 클라이언트 디바이스(40)가 목표된 미디어 버퍼 및 레이턴시 레벨에 도달하면, 클라이언트 디바이스(40)는 버퍼 레벨 및 레이턴시를 유지하기 위하여 정상 재생 레이트로 되돌아갈 수 있다. 이 예는, 뷰어가 클라이언트가 취하는 조절을 심지어 인식하지 못하는 이익을 가진다. 그러므로, 보다 우수한 사용자 경험은, 클라이언트 디바이스(40)가 그런 복잡한 동작들을 지원하자 마자 제공될 수 있다.
[0118] 이런 방식으로, 시간 차이가, 클라이언트 디바이스(40)의 로컬 클럭이 서버 디바이스(60)의 클럭을 앞서는 것을 가리킬 때, 클라이언트 디바이스(40)는 시간 차이가 영일때까지 정상 재생 레이트를 약간 초과하는 레이트로 미디어 데이터를 재생할 수 있다. 다른 한편, 시간 차이가, 클라이언트 디바이스(40)의 로컬 클럭이 서버 디바이스(60)의 클럭에 뒤지는 것을 가리킬 때, 클라이언트 디바이스(40)는 시간 차이가 영일때까지 정상 재생 레이트 약간 미만의 레이트로 미디어 데이터를 재생할 수 있다.
[0119] 비디오 인코더(28), 비디오 디코더(48), 오디오 인코더(26), 오디오 디코더(46), 캡슐화 유닛(30), 및 캡슐화 해제 유닛(50)은 각각, 적용 가능할 때 다양한 적당한 프로세싱 회로 중 임의의 회로, 이를테면 하나 또는 그 초과의 마이크로프로세서들, 디지털 신호 프로세서(DSP)들, 주문형 집적 회로(ASIC)들, 필드 프로그램 가능 게이트 어레이(FPGA)들, 이산 로직 회로, 소프트웨어, 하드웨어, 펌웨어 또는 이들의 임의의 결합들로서 구현될 수 있다. 비디오 인코더(28) 및 비디오 디코더(48) 각각은 하나 또는 그 초과의 인코더들 또는 디코더들에 포함될 수 있고, 이중 어느 하나는 결합된 비디오 인코더/디코더(CODEC)의 부분으로서 통합될 수 있다. 마찬가지로, 오디오 인코더(26) 및 오디오 디코더(46)의 각각은 하나 또는 그 초과의 인코더들 또는 디코더들에 포함될 수 있고, 이중 어느 하나는 결합된 CODEC의 부분으로서 통합될 수 있다. 비디오 인코더(28), 비디오 디코더(48), 오디오 인코더(26), 오디오 디코더(46), 및/또는 캡슐화 유닛(30), 및/또는 캡슐화 해제 유닛(50)을 포함하는 장치는 집적 회로, 마이크로프로세서, 및/또는 무선 통신 디바이스, 이를테면 셀룰러 전화를 포함할 수 있다.
[0120] 캡슐화 유닛(30)이 NAL 유닛들 및/또는 액세스 유닛들을 수신된 데이터에 기초하여 비디오 파일로 어셈블리한 후, 캡슐화 유닛(30)은 비디오 파일을 출력에 대한 출력 인터페이스(32)에 전달한다. 몇몇 예들에서, 캡슐화 유닛(30)은, 비디오 파일을 클라이언트 디바이스(40)에 직접 전송하기보다, 비디오 파일을 로컬적으로 저장하거나 비디오 파일을 출력 인터페이스(32)를 통해 원격 서버로 전송할 수 있다. 출력 인터페이스(32)는 예를 들어, 송신기, 트랜시버, 데이터를 컴퓨터 판독가능 매체에 기록하기 위한 디바이스 이를테면, 예를 들어, 광학 드라이브, 자기 미디어 드라이브(예를 들어, 플로피 드라이브), USB(universal serial bus) 포트, 네트워크 인터페이스, 또는 다른 출력 인터페이스를 포함할 수 있다. 출력 인터페이스(32)는 컴퓨터-판독가능 매체(34), 이를테면, 예를 들어, 송신 신호, 자기 매체, 광학 매체, 메모리, 플래시 드라이브, 또는 다른 컴퓨터-판독가능 매체에 비디오 파일을 출력한다.
[0121] 네트워크 인터페이스(54)는 네트워크(74)를 통해 NAL 유닛 또는 액세스 유닛을 수신할 수 있고 NAL 유닛 또는 액세스 유닛을 리트리벌 유닛(52)을 통해, 캡슐화 해제 유닛(50)에 제공할 수 있다. 캡슐화 해제 유닛(50)은 비디오 파일의 엘리먼트들을 구성성분 PES 스트림들로 캡슐화 해제하고, 인코딩된 데이터를 리트리브하기 위하여 PES 스트림들을 패킷화 해제하고, 그리고 예를 들어 스트림의 PES 패킷 헤더들에 의해 표시된 바와 같이, 인코딩된 데이터가 오디오 스트림의 부분인지 비디오 스트림의 부분인지에 따라, 인코딩된 데이터를 오디오 디코더(46) 또는 비디오 디코더(48)에 전송할 수 있다. 오디오 디코더(46)는 인코딩된 오디오 데이터를 디코딩하고 디코딩된 오디오 데이터를 오디오 출력(42)에 전송하는 반면, 비디오 디코더(48)는 인코딩된 비디오 데이터를 디코딩하고 스트림의 복수의 뷰들을 포함할 수 있는 디코딩된 비디오 데이터를 비디오 출력(44)에 전송한다.
[0122] 이런 방식으로, 클라이언트 디바이스(40)는 미디어 데이터를 리트리빙하기 위한 디바이스의 예를 나타내고, 디바이스는 미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하도록 구성된 하나 또는 그 초과의 프로세서들을 포함하고, 서버 디바이스는, 라이브 스트리밍 서비스를 사용하여 미디어 데이터를 제공하고, 세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 복수의 프로브 요청들에 대한 응답들을 분석하고, 그리고 라이브 스트리밍 서비스에 따라, 세그먼트 이용 가능성 윈도우의 결정된 좌측 에지 및 결정된 우측 에지에 기초하여 세그먼트 이용 가능성 윈도우 내의 세그먼트에 대한 요청을 전송한다.
[0123] 도 2는 예시적인 멀티미디어 콘텐츠(102)의 엘리먼트들을 예시하는 개념도이다. 멀티미디어 콘텐츠(102)는 멀티미디어 콘텐츠(64)(도 1), 또는 스토리지 매체(62)에 저장된 다른 멀티미디어 콘텐츠에 대응할 수 있다. 도 2의 예에서, 멀티미디어 콘텐츠(102)는 MPD(media presentation description)(104) 및 복수의 표현들(110-120)을 포함한다. 표현(110)은 선택적 헤더 데이터(112) 및 세그먼트들(114A-114N)(세그먼트들(114))을 포함하는 반면, 표현(120)은 선택적 헤더 데이터(122) 및 세그먼트들(124A-124N)(세그먼트들(124))을 포함한다. 문자 N은 편의성의 문제로서 표현들(110, 120)의 각각에서 최종 영화 프레그먼트를 표기하기 위하여 사용된다. 몇몇 예들에서, 표현들(110, 120) 사이에 상이한 수의 영화 프레그먼트들이 있을 수 있다.
[0124] MPD(104)는 표현들(110-120)과 별개의 데이터 구조를 포함할 수 있다. MPD(104)는 도 1의 매니페스트 파일(66)에 대응할 수 있다. 마찬가지로, 표현들(110-120)은 도 1의 표현들(68)에 대응할 수 있다. 일반적으로, MPD(104)는 코딩 및 렌더링 특성들, 적응 세트들, MPD(104)가 대응하는 프로파일, 텍스트 타입 정보, 카메라 앵글 정보, 레이팅 정보, 트릭 모드 정보(예를 들어, 시간 서브-시퀀스들을 포함하는 표현들을 가리키는 정보), 및/또는 원격 기간들을 리트리빙하기 위한 정보(예를 들어, 재생 동안 미디어 콘텐츠에 목표된 광고 삽입을 위해) 같은, 일반적으로 표현들(110-120)의 특성들을 설명하는 데이터를 포함할 수 있다. 본 개시의 기술들에 따라, MPD(104)는 도 1에 관하여 상기 논의된 바와 같은, UTCTiming 정보를 포함할 수 있다.
[0125] 존재할 때 헤더 데이터(112)는, 세그먼트들(114)의 특성들, 예를 들어, 랜덤 액세스 포인트들의 시간적 위치들(스트림 액세스 포인트(SAP)들로서 또한 지칭된 RAP들), 세그먼트들(114) 중 어느 것이 랜덤 액세스 포인트들을 포함하는지, 세그먼트들(114) 내의 랜덤 액세스 포인트들에 대한 바이트 오프셋들, 세그먼트들(114)의 URL(uniform resource locators), 또는 세그먼트들(114)의 다른 양상들을 설명할 수 있다. 존재할 때, 헤더 데이터(122)는 세그먼트들(124)에 대한 유사한 특성들을 설명할 수 있다. 부가적으로 또는 대안적으로, 그런 특성들은 MPD(104) 내에 완전히 포함될 수 있다.
[0126] 세그먼트들(114, 124)은 하나 또는 그 초과의 코딩된 비디오 샘플들을 포함하고, 상기 샘플들 각각은 비디오 데이터의 프레임들 또는 슬라이스들을 포함할 수 있다. 세그먼트들(114)의 코딩된 비디오 샘플들 각각은 유사한 특성들, 예를 들어, 높이, 폭, 및 대역폭 요건들을 가질 수 있다. 그런 특성들은, 그런 데이터가 도 2의 예에 예시되지 않지만, MPD(104)의 데이터에 의해 설명될 수 있다. MPD(104)는 3GPP 사양에 의해 설명된 바와 같은 특성들을 포함할 수 있고, 신호된 정보의 임의의 또는 모든 것의 부가는 본 개시에 설명된다.
[0127] 세그먼트들(114, 124)의 각각은 URL(unique uniform resource locator)과 연관될 수 있다. 따라서, 세그먼트들(114, 124)의 각각은 DASH 같은 스트리밍 네트워크 프로토콜을 사용하여 독립적으로 리트리브 가능할 수 있다. 이런 방식으로, 클라이언트 디바이스(40) 같은 목적지 디바이스는 세그먼트들(114 또는 124)을 리트리브하기 위하여 HTTP GET 요청을 사용할 수 있다. 몇몇 예들에서, 클라이언트 디바이스(40)는 세그먼트들(114 또는 124)의 특정 바이트 범위들을 리트리브하기 위하여 HTTP 부분 GET 요청들을 사용할 수 있다.
[0128] 상기 설명된 바와 같이, MPD(104)는, 표현들(110, 120)의 제 1 세그먼트가 이용 가능할 때를 광고하는 정보를 더 포함할 수 있다. 이 예에서, MPD(104)는, 세그먼트들(114A, 124A)가 먼저 이용 가능하게 될 때를 가리키는 정보를 포함할 수 있다. 따라서, 클라이언트 디바이스(40) 같은 클라이언트 디바이스는 표시된 시간에서 세그먼트들(114A, 124A) 중 어느 하나를 리트리브할 수 있다. 게다가, MPD(104)는 재생 시간 측면에서, 세그먼트들(114, 124)의 지속시간을 가리키는 정보를 포함할 수 있다. 따라서, 클라이언트 디바이스(40)는, 세그먼트들(114A, 124A)이 이용 가능하게 되는 시간(MPD(104)에 의해 표시된 바와 같이) 및 세그먼트들(114A, 124A)의 지속기간(또한 MPD(104)에 의해 표시된 바와 같이)에 기초하여 세그먼트들(114B, 124B)이 이용 가능하게 되는 시간을 결정할 수 있다. 세그먼트들(114, 124)은, 동일한 지속시간들(재생 시간 측면에서)을 가질 수 있고, 상기 경우 MPD(104)는 단일 지속시간 값, 또는 상이한 지속시간들을 가리킬 수 있고, 상기 경우 MPD(104)는 세그먼트들(114, 124)의 각각에 대해 별개의 지속시간 값들을 가리킬 수 있다. 대안적으로, 세그먼트들(114, 124)이 일시적으로 정렬되고 상이한 지속시간들을 가지는 것을 가정하면, MPD(104)는 대응하는 세그먼트들에 대한 개별 지속시간 값들(예를 들어, 세그먼트들(114A, 114B)에 적용 가능한 지속시간 값, 세그먼트들(114B, 124B)에 적용 가능한 다른 지속시간 값, 등)을 신호할 수 있다.
[0129] 게다가, 멀티미디어 콘텐츠(102)가 라이브 스트리밍되는 것을 가정하면, 세그먼트들(114, 124) 중 특정 세그먼트들은, 특정 시간 양 후, 특히 레코딩, 인코딩, 및 데이터의 캡슐화 후에만 이용 가능하게 될 수 있다. 클라이언트 디바이스(40)는 다양한 예들에서, 세그먼트들(114, 124)의 임의의 시퀀스를 포함할 수 있는, 세그먼트 이용 가능성 윈도우를 결정하기 위하여 본 개시의 기술들을 사용할 수 있다. 즉, 세그먼트 이용 가능성 윈도우는, 엄격하게 이용 가능성의 광고된 시간들 및 클럭 동기성에 기초하기보다, 세그먼트들에 대한 요청들에 대한 응답들에 의해 표시된 바와 같이, 세그먼트들이 실제 이용 가능할 때에 기초하여 결정될 수 있다. 이들 기술들은 도 3-도 9에 관하여 하기에 더 상세히 설명된다.
[0130] 도 3은 세그먼트들(150)의 세트에 대한 예시적인 세그먼트 이용 가능성 윈도우(152)를 예시하는 개념도이다. 세그먼트들은 도 3에서 삼각형들로서 표현된다. 이 예에서, TSBD(time shift buffer depth)가 W 세그먼트들의 폭을 가진다고 한다. 게다가, 월-클럭 시간(t)에 기초하여, 최신 이용 가능한 세그먼트가 도 3에서 "i"로 라벨링된 세그먼트에 대응한다는 것을 클라이언트 디바이스(40)가 결정한다고 가정한다. 이들 가정들에 기초하여, 도 3은 이용 가능한 세그먼트들, 즉 세그먼트 이용 가능성 윈도우(152)의 스냅샷을 묘사한다. 특히, 세그먼트 이용 가능성 윈도우는 포지션((i-W+1(i-(W-1)))의 세그먼트에서 시작하는 좌측 에지(154), 및 현재 세그먼트(i)에서 종료하는 우측 에지(156)를 포함한다. 좌측 에지(154)를 정의하는 세그먼트(즉, 포지션(i-W+1)에서의 세그먼트)는 도 3의 파선 윤곽을 사용하여 도시된다.
[0131] 다른 말로, 클라이언트 디바이스(40)는 미디어 세그먼트들에 대한 프로빙 요청들, 이를테면 HTTP HEAD 요청들을 전송할 수 있다. 특히, 클라이언트 디바이스(40)는 시간적으로 뒤의 최신 이용 가능한 세그먼트(클라이언트 디바이스(40)의 클럭에 따라 결정된 바와 같이)로부터 시작하여 실질적으로 동시에 W 프로빙 요청들을 전송할 수 있다. 이들 프로빙 요청들에 의해 커버된 시간 기간은 W*D이고, 여기서 D는, 세그먼트들이 동일한 지속시간(재생 시간 측면에서)을 가진다는 것을 가정하여 세그먼트들의 지속시간이다. 본 개시는, DASH에서 대부분의 HTTP 404 에러들이 서버 디바이스의 클럭을 앞서는 클라이언트 디바이스 클럭에 의해 유발되는 것을 인식한다. 이런 방식으로 시간적으로 후인 프로빙은 TSBD 윈도우의 우측 에지를 발견하기 위하여 사용될 수 있다.
[0132] 대안으로서, 클라이언트 디바이스(40)는 시간적으로 앞서서만 프로빙할 수 있다. 이것은 백워드 프로빙과 유사하지만, 클라이언트 디바이스(40)의 클럭이 TSBD 지속시간보다 많은 만큼, 서버 디바이스(60)의 클럭 뒤에 있는 문제를 다루기 위하여 사용될 수 있다. TSBD의 좌측 에지는 예를 들어 하기 도 6 및 도 7에 도시된 바와 같이, 특정 패턴들에 의해 발견될 수 있다. 또 다른 예로서, 포워드 및 후방 프로브 요청들 둘 다는, 하기에 보다 상세히 논의되는, 도 4에 도시된 바와 같이 전송될 수 있다.
[0133] 도 4는 프로빙 요청들이 세그먼트 이용 가능성 윈도우를 결정하기 위하여 전송될 수 있는 세그먼트들을 예시하는 개념도이다. 상기 주의된 바와 같이, 클라이언트 디바이스(40)의 리트리벌 유닛(52)은 서버 디바이스(60)로부터 특정 수의 404 에러 메시지들을 수신하거나 스트림 시작시 같은 다양한 기준들에 기초하여 세그먼트 이용 가능성 윈도우를 결정하기 위한 프로세스를 개시하도록 구성될 수 있다. 임의의 경우, 리트리벌 유닛(52)은, 본 개시의 기술들에 따라, 프로브 요청들의 시퀀스를 다수의 연속적인 세그먼트들에 지향되게 전송할 수 있다. 도 4의 예에서, 리트리벌 유닛(52)은, 클라이언트 디바이스(40)의 클럭에 따라, 최신 이용 가능한 세그먼트인 대략 세그먼트(i)가 중심인 세그먼트들에 대한 프로브 요청들(예를 들어, HTTP HEAD 요청들)을 전송한다. 이 예에서, 프로브 요청들의 시퀀스는 i-N 내지 i+N의 세그먼트들의 각각에 대한 개별 요청들을 포함하고, 여기서 N은 정수 값이다. 그러나, 다른 예들에서, 프로브 요청들의 시퀀스는 세그먼트들(i-M 내지 i+N)에 대한 개별 요청들을 포함할 수 있고, 여기서 M 및 N은 동일하거나 동일하지 않을 수 있고, M 또는 N 중 어느 하나는 영일 수 있다.
[0134] 다른 말로, 일단 프로빙 방법이 개시되면, 클라이언트 디바이스(40)는 미디어 세그먼트들에 대한 다수의 프로빙 요청들을 연이어(back-to-back)(즉, 파이프라이닝됨) 전송할 수 있다. 몇몇 예들에서, 프로빙 요청은 세그먼트의 이용 가능성을 검출하는 것을 목표로 하는 주어진 미디어 세그먼트에 대한 HTTP HEAD 요청이다. 다른 예들에서, 비교적 작은 양의 데이터(예를 들어, 100 바이트들)에 대한 HTTP 부분 GET 요청들 같은 다른 타입들의 요청들은 사용될 수 있다. 시간(t)에서, 클라이언트 디바이스(40)의 리트리벌 유닛(52)은 클라이언트 디바이스(40)의 클럭에 기초하여 최신 이용 가능한 세그먼트 번호(i)를 계산할 수 있다. 프로빙 요청 방법이 시작 트리거에 의해 개시되는 경우들에서, 클라이언트 디바이스(40)는 세그먼트(i)에 대한 요청이 실패할 것 같다는 것을 예상할 수 있다. 따라서 리트리벌 유닛(52)은 세그먼트(i) 및 자신의 인접한 세그먼트들에 대한 (2N+1) 프로빙 요청들을 전송할 수 있고, 이는 세그먼트(i-N) 내지 세그먼트(i+N) 범위이다. 이들은 응답 메시지 바디에 데이터가 작은 상태부터 어떤 데이터도 없는 상태까지 매우 작은 HTTP 요청들이기 때문에, 모든 요청들이 비교적 짧은 시간 양, 예를 들어 1초 간격 내에서 서버에 의해 수신될 것이 예상될 수 있고, 모든 응답들은 비교적 짧은 시간 양, 예를 들어 1초 간격 내에서 클라이언트 디바이스(40)에 의해 수신되도록 예상될 수 있다. 다른 말로, 응답들의 집합은 세그먼트 이용 가능성 윈도우의 서버 디바이스(60)의 뷰의 스냅샷으로서 보여질 수 있다.
[0135] 클라이언트 디바이스(40)의 리트리벌 유닛(52)은 세그먼트 이용 가능성 윈도우의 좌측 및/또는 우측 에지들을 결정하기 위하여 프로브 요청들에 대한 응답들을 사용할 수 있다. 부가적으로 또는 대안적으로, 리트리벌 유닛(52)은 클라이언트 디바이스(40)의 클럭과 서버 디바이스(60)의 클럭 사이의 차이(또한 시간 델타로서 지칭됨)를 결정할 수 있다. 특히, 클라이언트 디바이스(40)와 서버 디바이스(60) 사이의 시간 델타는 프로빙 요청들에 대한 서버 디바이스(60)로부터의 응답 패턴에 기초하여 추론될 수 있다.
[0136] 도 5-도 9는 리트리벌 유닛(52)에 의해 전송된 도 4의 프로빙 요청들에 대한 다양한 가능한 응답 패턴들을 예시하는 개념도이다. 도 5-도 9에서, 어둡게 음영된 삼각형들은 이용 가능한 세그먼트들, 즉 프로빙 요청들이 에러 없는 응답들(예를 들어, HTTP(200) 응답들)을 갖는 세그먼트들을 나타낸다. 도 5-도 9에서, 음영이 없는 삼각형들은 이용 가능하지 않은 세그먼트들, 즉 프로빙 요청들이 에러 응답들(예를 들어, HTTP 404 응답들)을 가진 세그먼트들을 나타낸다.
[0137] 도 5는 클라이언트 디바이스(40)의 클럭이 서버 디바이스(60)의 클럭(또는, 보다 일반적으로, 세그먼트(i)의 이용 가능성에 대한 광고된 시간)에 앞서게 드리프트될 때 예시적 에러 패턴을 나타낸다. 이 예에서, 클라이언트 디바이스(40)의 클럭은, 세그먼트(i)가 이용 가능하다는 것을 가리킨다. 즉, 클라이언트 디바이스(40)의 클럭은 세그먼트(i)에 대한 광고된 이용 가능 시간, 예를 들어 매니페스트 파일(66) 같은 MPD에서 광고된 바와 같은 시간과 동일하거나 초과한다. 그러나, 응답 패턴은, 세그먼트(i-k-1)까지의 세그먼트들만이 이용 가능하다는 것을 가리킨다. 즉, 세그먼트들((i-k) 내지 i)에 대한 요청들에 대한 응답들은 HTTP 404 에러들을 가리킨다. 그러므로, 세그먼트(i-k-1)은 세그먼트 이용 가능성 윈도우의 우측 에지를 나타낸다. 성공과 실패 응답들 사이의 경계에 기초하여, 클라이언트 디바이스(40)의 리트리벌 유닛(52)은 클라이언트 디바이스(40)의 클럭 사이의 시간 델타를 추정할 수 있다. 세그먼트들(i 내지 (i-k))에 대해, 응답들이 404 에러 코드들이지만, (i-k-1) 내지 (i-N)에서 응답들은 200 코드들이면, 리트리벌 유닛(52)은 아래와 같은 식(6)에 따라 시간 델타를 추정할 수 있다:
시간_델타
Figure 112015085493717-pct00003
, D(j): 세그먼트(j)의 지속시간 (6)
[0138] 세그먼트들이 동일한 지속시간(D)을 가질 때, 추정된 시간 델타는 간단히 (k+1)*D일 수 있다.
[0139] 도 6은 클라이언트 디바이스(40)의 클럭이 서버 디바이스(60)의 클럭(또는, 보다 일반적으로, 세그먼트(i)의 이용 가능성에 대한 광고된 시간)에 뒤질 때 예시적인 에러 패턴을 나타낸다. 클라이언트 디바이스(40)의 클럭이 세그먼트(i)에 대한 이용 가능성의 광고된 시간에 뒤질 때(예를 들어, 서버 디바이스(60)의 클럭에 뒤짐) 그리고 이 시간 차이가 세그먼트 요청 실패들을 유발할 때, 통상적으로, 클라이언트 디바이스(40)의 클럭이 서버 디바이스(60)의 클럭에 너무 뒤지기 때문에, 세그먼트 요청 시간이 TSBD(즉, 세그먼트 이용 가능성 윈도우)의 좌측 에지를 벗어난다. 이 예에서, 클라이언트 디바이스(40)의 클럭은, 세그먼트(i)가 이용 가능하다는 것을 가리킨다. 즉, 클라이언트 디바이스(40)의 클럭은, 세그먼트(i)의 이용 가능성에 대한 광고된 시간보다 크거나 같지만, 세그먼트(i)가 세그먼트 이용 가능성 윈도우로부터 제거되도록 광고된 시간보다 작은 시간을 가리킬 수 있다. 그러나, 도 6의 응답 패턴은, 다음 세그먼트(i+k)만이 이용 가능하다는 것을 가리킨다.
[0140] 응답 패턴이 세그먼트(i) 내지 세그먼트(i+k)의 404 에러 코드들, 및 세그먼트(i+k+1) 및 그 앞의 세그먼트에서 성공 코드를 도시할 때, 성공과 실패 응답 코드들 사이의 경계(즉, (i+k) 및 (i+k+1) 사이)는 TSBD(즉, 세그먼트 이용 가능성 윈도우)의 좌측 에지로 고려된다. 클라이언트 디바이스(40)의 리트리벌 유닛(52)은 하기 식(7)에 따라 클라이언트 디바이스(40)의 클럭과 서버 디바이스(60)의 클럭 사이의 델타를 추론할 수 있다.
시간_델타
Figure 112015085493717-pct00004
, D(j): 세그먼트(j)의 지속시간 (7)
[0141] 도 7은 클라이언트 디바이스(40)의 클럭이 세그먼트 이용 가능성 윈도우 내에 있지만, 서버 디바이스(60)와 완전히 동기화되지 않을 때(또는 보다 일반적으로, 세그먼트(i)의 이용 가능성에 대한 광고된 시간) 예시적인 에러 패턴을 나타낸다. 상기 주의된 바와 같이, 프로브 요청 프로세스를 개시하기 위한 트리거는 선택적이다. 따라서, 리트리벌 유닛(52)은 실패된 응답 트리거 없이 프로브 요청 프로세스를 개시할 수 있다. 리트리벌 유닛(52)은 초기 실패 세그먼트 요청들로부터의 트리거 없이 시간 델타 추정을 추가로 수행할 수 있다. 이것은 클라이언트 디바이스(40)가 미디어 세그먼트들을 성공적으로 리트리브할 수 있을 때를 가리킨다. 그런 경우는 클라이언트의 요청된 미디어 세그먼트가 TSBD(즉, 세그먼트 이용 가능성 윈도우) 내에 속할 때 발생할 수 있지만, 클라이언트 디바이스(40)의 클럭과, 세그먼트가 실제로 이용 가능하게 되는 시간(예를 들어, 서버 디바이스(60)의 클럭에 의해 표시된 바와 같이) 사이에 여전히 시간 델타가 있을 수 있다.
[0142] 클라이언트가 도 7에 도시된 바와 같이 프로빙 요청들에 대한 응답들을 수신하는 것을 가정한다. 세그먼트(i-g)와 세그먼트(i+k) 사이에서, 응답 코드들은 성공이다(예를 들어, HTTP 코드(200)). 이 범위 외에서, 응답 코드들은 "이용 가능하지 않은" HTTP 404이다. 이 경우, 클라이언트 디바이스(40)의 리트리벌 유닛(52)은, 세그먼트(i-g) 내지 세그먼트(i+k)의 범위 내 세그먼트들이 TSBD(즉, 이용 가능성 윈도우)에 대응하는 것을 결론을 내릴 수 있다. 리트리벌 유닛(52)은, 클라이언트 디바이스(40)의 클럭이 서버 디바이스(60)의 클럭에 뒤지는 것을 결정할 수 있고, 하기 식(8)에 따라 시간 델타를 추정할 수 있다.
시간_델타
Figure 112015085493717-pct00005
, D(j): 세그먼트(j)의 지속시간 (8)
[0143] 도 8 및 도 9는 시간 델타를 추정하기 위한 결론을 못 낸 에러 패터들의 예들을 나타낸다. 도 8 및 도 9에 도시된 것들과 같은 다양한 응답 파라미터들은 결론을 못 낸 것으로 고려되고, 전송될 부가적인 프로브 요청들을 요구할 수 있거나 클라이언트 디바이스(40)와 서버 디바이스(60) 사이의 동기화되지 않은 클럭들 외의 에러들을 가리킬 수 있다.
[0144] 특히, 도 8은 혼합된 성공 및 실패 응답들의 예를 나타낸다. 이 경우, 응답 패턴은 함께 인터리빙된 성공들 및 실패들을 가진다. 이것은, 실패 응답들에 대한 이유가 완전히 클럭 동기화 및 세그먼트 요청 시간에 기초하지 않는 것을 가리킨다. 예를 들어, 실패 응답들의 적어도 몇몇은 인코더 또는 서버, 또는 서버와 클라이언트 사이의 네트워크 경로를 따른 디바이스들에서의 에러들로 인할 수 있다. 그런 패턴이 발생할 때, 클라이언트는 반드시 응답들에만 기초하여 시간 델타를 추정하지 않을 수 있다. 클라이언트는, 충분한 세그먼트들이 리트리빙될 수 있으면 라이브 비디오의 스트리밍을 여전히 유지할 수 있다.
[0145] 도 9는 프로빙 요청들에 대한 모든 응답들이 404 에러들인 예를 나타낸다. 이 경우, TSBD(즉, 세그먼트 이용 가능성 윈도우)의 좌측 에지도 우측 에지도 발견될 수 없다. 따라서, 리트리벌 유닛(52)은 이들 프로브 요청들만을 기초로 시간 델타를 추정할 수 없다. 이 응답 패턴은 클라이언트의 클럭이 서버의 클럭으로부터의 큰 오프셋에 의해 동기화를 벗어남으로써 유발될 수 있다. 모두-404 응답 패턴이 단말 실패가 아니다. 이는 단순히, 프로빙 요청들의 세트에 의해 커버된 시간 기간이 TSBD의 에지를 발견하기에 충분히 크지 않다는 것을 의미한다. 그런 응답 패턴이 발생할 때, 리트리벌 유닛(52)은 인접한 프로빙 요청들의 간격을 조절할 수 있어서, 프로빙 요청들의 세트는 보다 성긴 입도를 가진 큰 시간 기간을 커버할 것이다. 계층 탐색 방법은, 구현 복잡성이 베이스 추정 방식보다 높을 것이지만, 하기 설명된다.
[0146] 이 예에서, 세그먼트 지속시간(D)이 모든 세그먼트들에 대해 고정되는 것을 가정한다. 계층 탐색은 D와 동일한 프로빙 세그먼트 간격으로 시작할 수 있다. 하기 유사코드는 계층 탐색의 일 예를 설명한다.
초기화: 프로빙 간격 PI=D, 최대 프로빙 간격=M*D(M=2k 및 M*D<TSBD)
주 절차:
(PI <M*D) 동안
{
현재 클라이언트 시간(t) 및 프로빙 간격(D)에 기초하여 프로빙 요청들 형성
TSBD 에지가 루프에서 벗어나 발견되면 프로빙 요청들의 세트를 사용하여 베이스 델타 추정 방식 실행; 그렇지 않으면 PI=PI*2
}
(만약 TSBD 에지가 발견되면){
(PI > D) 동안{
클라이언트의 클럭을 새롭게 추정된 TSBD 에지의 중심으로 조절
보다 정확한 TSBD 에지 추정을 얻기 위하여 시간 델타 추정 재실행
PI = PI/2
}
}
그렇지 않으면 {
탐색 실패 선언
}
[0147] 일단 리트리벌 유닛(52)이 시간 델타를 추정하면, 리트리벌 유닛(52)은 미디어 세그먼트 요청을 전송하기 위한 조절된 시간을 사용하기 위하여 시간 델타 값을 레코딩할 수 있다. 다음 예는 그런 프로세스를 개요한다. 기간 시작 시간이 15:30:00이고 라이브 미디어 세그먼트가 1초 길이(재생 지속시간의 측면에서)인 각각의 미디어 세그먼트를 가진 세그먼트 수-기반 템플릿을 사용하는 것을 가정한다. MPD에 기초하여, 제 1 미디어 세그먼트의 이용 가능성 시작 시간은 15:30:01이다. 그러나, DASH 클라이언트(예를 들어, 리트리벌 유닛(52))는 자신의 로컬 클럭에 기초하여 시작 시간에서 미디어 세그먼트들을 성공적으로 리트리브할 수 없다. 그 다음, DASH 클라이언트는 시간 델타 추정 알고리즘을 실행하고 자신의 클럭이 서버의 클럭(또는, 요청된 세그먼트가 실제로 이용 가능한 시간)에 3초 앞서는 것을 추정한다. 현재 클라이언트 클럭이 15:30:35인 것을 고려한다. 클라이언트는 먼저 15:30:32인 서버 클럭의 추정치를 계산하기 위하여 추정된 시간 델타를 사용한다. 그 다음, 세그먼트 이용 가능성 타임라인에 기초하여, 클라이언트는 최신 이용 가능한 세그먼트 번호를 세그먼트#32(클라이언트의 로컬 클럭에 기초한 #35 대신)로서 계산한다. 그 후, 클라이언트는 미디어 세그먼트#32에 대한 요청을 전송할 것이고 서버는 세그먼트 데이터를 사용하여 200 코드를 리턴한다.
[0148] 시간 델타 추정치를 얻은 후, 리트리벌 유닛(52)은 TSBD(즉, 세그먼트 이용 가능성 윈도우)의 우측 에지의 추적을 유지할 수 있고 미래 클럭 드리프트를 회피할 수 있다. 리트리벌 유닛(52)은 TSBD의 우측 에지의 추적을 유지하기 위하여 다양한 기술들을 구현할 수 있다. 일 예에서, 리트리벌 유닛(52)은 상기 설명된 바와 같이, 프로빙 요청들을 주기적으로(예를 들어, 매 분에) 전송할 수 있고 시간 델타 추정을 수행할 수 있다. 초기 시간 델타 추정 후, 클라이언트는 TSBD의 우측 에지의 우수한 근사치를 가진다. 추후 프로빙 요청들은 TSBD 우측 에지의 이전 추정치에 중심을 둘 수 있다. 이것은 추후 시간 델타 추정들의 성공을 거의 보장하고 전송되는 프로빙 요청들의 수를 감소시킬 것이다. 대부분의 경우들에서, 추후 시간 델타 추정은 이전 추정을 재확인하거나 작은 값만큼 이전 추정을 조절할 것이다. 이 방법은, DASH 클라이언트(예를 들어, 리트리벌 유닛(52))에 의해 유지되도록 최소 양 상태(이전 시간 델타)를 요구하기 때문에 비교적 구현하기 쉽다. 그러나 이 방법은, 입도가 여전히 세그먼트 지속시간에 의해 제한되기 때문에, 시간 델타 추정의 정확도를 반드시 개선하지 않는다.
[0149] 다른 접근법은 TSBD의 정확한 에지(예를 들어, TSBD의 정확한 우측 에지)를 테스팅하는 측면에서 리트리벌 유닛(52)이 경계를 푸싱하는 것이다. 클라이언트 디바이스(40)의 클럭이 월-클럭 시간(t)을 가리키고, 초기 시간 델타 추정 결과가 델타 값(d)인 것을 가정한다. 경계를 푸싱하기 위하여, 클라이언트는 추정된 서버 시간에 작은 시간 오프셋인 새로운 상태 변수(p)를 도입할 수 있다. 서버 시간의 추정으로서 서버 시간(t+d)을 사용하는 대신, 클라이언트는 추정된 서버 시간(t+d+p)을 사용할 수 있다. 경계를 푸싱하는 방법은 하기 설명된 바와 같이, 몇몇 단계들에서 진행할 수 있다.
[0150] 경계 푸싱 방법의 초기화 단계에서, 리트리벌 유닛(52)은 초기 시간 델타 추정으로부터의 d를 사용하고, p를 0과 동일하게 서정하고, u를 100 밀리초와 동일하게 설정하고(여기서 u는 각각의 단계에서 p에 대해 고정된 증분 값임), 그리고 D를 세그먼트 지속시간 값으로서 설정한다. p 단계의 부가적인 증가 오프셋(각각의 성공적인 미디어 세그먼트 요청으로 개시됨)에서, 리트리벌 유닛(52)은 p=p+u를 설정하고 서버 디바이스(60)에 대해 추정된 시간이 t + d + p인 것을 결정한다. 지수적 감소 오프셋 p 단계(각각 실패된 미디어 세그먼트 요청으로 개시됨)에서, 리트리벌 유닛(52)은 p<u까지 p=p/2를 설정하고, 상기 시간에서 리트리벌 유닛(52)은 d를 재추정할 수 있다. 시간 델타(d)를 재추정하기 위하여(예를 들어, 재추정이 지수적 감소 오프셋 p 단계 동안 트리거될 때), 리트리벌 유닛(52)은 상기 설명된 바와 같이(프로빙 요청들을 사용하여), 전체 시간 델타 추정 절차를 수행할 수 있다. 프로빙 요청들은 TSBD 우측 에지의 이전 추정치에 중심을 둘 수 있다. 이것은 성공적인 추정의 생성을 거의 보장할 것이다. 새롭게 추정된 시간 델타(d')는 이전 시간 델타 값(d)을 대체한다. 이 방법은 증가된 클라이언트 측 복잡성을 비용으로 치루고, 훨씬 높은 정확도로 시간 델타 추정을 미세 조정할 잠재성을 가진다. 특히, 클라이언트 디바이스(40)는 이 예에서 많은 상태 정보를 유지한다.
[0151] 리트리벌 유닛(52)은 단독으로 또는 임의의 결합으로 이들 기술들에 대한 하나 또는 그 초과의 최적화들을 구현할 수 있다. 예를 들어, 리트리벌 유닛(52)은 서버 디바이스(60)에 전송되는 프로빙 요청들의 특정 순서를 유지할 수 있다. 클라이언트가 순차적 방식으로 연이어 프로빙 요청들을 전송하기 때문에, 클라이언트 디바이스(40)의 클럭이 서버 디바이스(60)의 클럭을 앞서게(또는 세그먼트가 이용 가능한 시간을 앞섬) 됨으로써 대부분의 미디어 리트리벌 실패들이 유발되는 것을 주의하는 것이 중요하다. 그러므로, 클라이언트 디바이스(40)는 예를 들어 세그먼트((i-N) 내지 (i+N))에 대한 프로빙 요청으로부터 시작하여, 시간적으로 뒤짐으로부터 시간적으로 앞섬으로 프로빙 요청들을 전송할 수 있다. 그런 요청 순서는, 시간 델타 추정의 가정이 TSBD(즉, 세그먼트 이용 가능성 윈도우)의 에지에 인접한 프로빙 요청들의 거의 동시 프로세싱에 기초하기 때문에, 서버가 적절한 방식으로 제한된 수의 프로빙 요청들만을 다룰 수 있을지라도, 성공적 추정 가능성을 개선할 수 있다.
[0152] 다른 예로서, 리트리벌 유닛(52)은 응답 패턴들을 특징으로 할 수 있다. 프로빙 요청들에 대한 응답 패턴들을 특성화하기 위한 하나의 실제적 방법은 대부분의 뒤짐 요청에 대한 응답으로부터 시작하고 응답 메시지 타입이 변화되는 횟수를 카운트하는 것이다. 예를 들어, 도 5, 도 6 및 도 7에서, 응답 코드 변화들의 수는 각각 1, 1, 및 2이다. 그러나, 도 8 및 도 9에서, 응답 코드 변화들의 수는 각각 6 및 0이다. 응답 코드 변화들의 수가 1 또는 2일때만, 응답 패턴이 TSBD의 에지를 추론하기 위하여 사용될 수 있다는 것을 알 수 있다.
[0153] 다른 예로서, 리트리벌 유닛(52)은 "하나의-세그먼트 프라이어(prior)" 규칙에 따라 구성될 수 있다. 즉, 시간 델타 추정이 하나의 세그먼트 지속시간의 입도를 가지기 때문에, 시간 델타를 사용하여 클라이언트 디바이스(40)의 클럭을 조절한 후, 가장 진보된 미디어 세그먼트 리트리벌 유닛(52)이 요청해야 하는 것이 최신 이용 가능한 미디어 세그먼트 이전에 이용 가능했던 미디어 세그먼트인 것이 권고된다. 다른 말로, 리트리벌 유닛(52)은 TSBD의 우측 에지를 추적하는 것이 아니라, 대신 시간 델타 추정의 임의의 부정확성을 수용하도록 하나의 세그먼트만큼 뒤지게 하도록 구성될 수 있다.
[0154] 상기 논의된 변수(N)는 구성을 통해 수정될 수 있다. 몇몇 예들에서, N은 리트리벌 유닛(52)이 결정하는 각각의 방향(후방 및 전방)으로 최신 이용 가능한 세그먼트(i)를 전송하기 위한 프로빙 요청들의 수에 대응한다. 경험적 테스팅은, 클라이언트 디바이스와 서버 디바이스 사이의 NTP 동기화 후, 클라이언트 디바이스의 클럭이 서버 디바이스의 클럭으로부터 한 시간 내에 몇 초까지, 그리고 24시간 기간 내에서 20초까지 드리프트 오프(drift off)할 수 있다는 것을 도시하였다. 그러므로, 파라미터(N)는, 클라이언트 디바이스가 네트워크 시간 소스와 최종 동기화한 이래 경과된 시간에 따를 수 있다. 예를 들어, 리트리벌 유닛(52)은 서버 디바이스(60)와 최종 동기화 이래 경과된 시간에 기초하여 N의 값을 결정하기 위하여 하기 표 1에 따른 데이터를 사용하도록 구성될 수 있다. 클라이언트 디바이스(40)는 주기적으로 및/또는 특정 정의된 시간들, 예를 들어 하루 당 한번(또는 24시간 기간), 스트리밍 세션의 시작시, 및/또는 스트리밍 세션 동안 주기적으로(예를 들어, 매 몇 분들)서버 디바이스(60)와 재동기화할 수 있다.
최종 동기화 이래 시간 N에 대한 값
≤1분 10
>1분 그러나≤10분 15
>10분 그러나 ≤1시간 20
>1시간 25
[0155] 도 10은 비균일하게 이격된 프로빙 시퀀스의 예를 예시하는 개념도이다. 프로빙 시퀀스는, 표현 시간의 측면에서 세그먼트들의 간격이 TSBD(즉, 세그먼트 이용 가능성 윈도우)보다 작은 한, 균일하게 이격(인접한 프로빙 패킷들이 고정된 수의 세그먼트들만큼 떨어진 두 개의 세그먼트들을 목표로 함)될 수 있거나, 또는 비균일하게 이격(인접한 프로빙 패킷들이 그들 사이에 가변하는 수의 세그먼트들을 가진 두 개의 세그먼트들을 목표로 할 수 있음)될 수 있다. 비균일하게 이격된 프로빙 시퀀스의 하나의 패턴은 도 10의 예에 예시된다. 프로빙 시퀀스의 중심에서, 프로빙 패킷들만큼 목표된 세그먼트들 사이의 간격은 작다. 프로빙 패킷들이 중심으로부터 더 멀리 이동할 때, 목표된 세그먼트들 사이의 간격은 증가한다. 그런 설계는, 프로빙 시퀀스의 중심 주위에서 우수한 시간 입도를 유지하면서, 프로빙 시퀀스에 의해 큰 시간 커버리지를 달성하도록 도울 수 있다.
[0156] 도 11은 본 개시의 기술들에 따른 세그먼트 이용 가능성 윈도우의 하나 또는 그 초과의 에지들을 결정하기 위한 예시적인 방법을 예시하는 흐름도이다. 도 11의 방법은 클라이언트 디바이스(예를 들어, 클라이언트 디바이스(40)) 및 서버 디바이스(예를 들어, 서버 디바이스(60))에 의해 수행되는 것으로 도시된다. 도 1의 클라이언트 디바이스(40) 및 서버 디바이스(60)에 관하여 설명되었지만, 다른 디바이스들이 도 11의 방법과 실질적으로 유사한 방법을 수행하도록 구성될 수 있다는 것이 이해되어야 한다. 게다가, 부가적인 또는 대안적인 단계들이 도 11의 방법과 일치하는 방법으로 수행될 수 있다는 것이 이해되어야 한다.
[0157] 클라이언트 디바이스(40)가 특정 미디어 콘텐츠에 대해 서버 디바이스(60)로부터 MPD 또는 다른 매니페스트 파일을 수신한 후 도 11의 방법이 수행되는 것이 가정된다. 게다가, MPD는 미디어 콘텐츠의 세그먼트들이 리트리벌을 위해 이용 가능할 시간들을 정의하는 데이터를 포함할 수 있다. 이들 시간들은 서버 디바이스(60)의 클럭에 관하여 또는 다른 디바이스 또는 엔티티, 이를테면 콘텐츠 준비 디바이스(20)의 클럭에 관하여 광고될 수 있다. 따라서, 클라이언트 디바이스(40)는, 미디어 콘텐츠의 세그먼트들이 이용 가능한 시간들뿐 아니라, 세그먼트들이 리트리벌을 위하여 더 이상 이용 가능하지 않은 시간들을 결정할 수 있다.
[0158] MPD는 적응 세트들 내의 표현들 및 적응 세트들 내의 표현들의 대역폭들 같은 다양한 표현들의 특성들을 정의하는 정보를 더 포함할 수 있다. 클라이언트 디바이스(40)는, 예를 들어 적응 세트들의 특성들, 이용 가능한 표현들의 비트레이트들, 및 현재 추정된 이용 가능한 대역폭에 기초하여 표현들 중 하나를 선택(200)할 수 있다. 클라이언트 디바이스(40)는 또한 로컬 클럭, 즉 클라이언트 디바이스(40)의 클럭으로부터 현재 시간을 결정(202)할 수 있다. 예를 들어, 클라이언트 디바이스(40)는 로컬 클럭에 의해 표시된 현재 시간을, 세그먼트들이 이용 가능하게 광고된 시간들에 비교할 수 있다. 그 다음 클라이언트 디바이스(40)는 최신 이용 가능한 시간, 즉 로컬 클럭에 의해 표시된 현재 시간보다 작거나 같지만, 선택된 표현의 모든 다른 세그먼트들보다 큰 이용 가능성 시간을 가진 세그먼트(i)를 결정할 수 있다. 이 세그먼트(i)는 클라이언트 디바이스(40)의 로컬 클럭에 의해 표시된 바와 같이, 최신 이용 가능 세그먼트로서 지칭될 수 있다.
[0159] 이 결정에 기초하여, 클라이언트 디바이스(40)는 서버 디바이스(60)로부터 최신 이용 가능한 세그먼트(예를 들어, 세그먼트(i))에 대한 요청을 전송(204)할 수 있다. 이 요청은 예를 들어 HTTP Get 또는 부분 GET 요청에 대응할 수 있다. 서버 디바이스(60)는 클라이언트 디바이스(40)로부터 이 세그먼트 요청을 수신(206)할 수 있다. 그러나, 클라이언트 디바이스(40)의 로컬 클럭이, 세그먼트가 이용 가능하게 되는 실제 시간에 관련하여(예를 들어, 서버 디바이스(60), 콘텐츠 준비 디바이스(20), 또는 다른 그런 디바이스의 클럭에 관련하여) 드리프트되는 것을 가정하면, 세그먼트(i)는 실제로 아직 이용 가능하지 않을 수 있다. 도 11의 예에서, 서버 디바이스(60)가 요청을 수신하는 시간에서 세그먼트(i)가 이용 가능하지 않는 것이 가정되고, 따라서, 서버 디바이스(60)는 요청된 세그먼트가 이용 가능하지 않다는 것을 결정(208)하고 HTTP 404 에러 같은 에러를 클라이언트 디바이스(40)에 전송(210)한다.
[0160] 클라이언트 디바이스(40)는 에러(212)를 수신할 수 있고, 에러에 기초하여, 클라이언트 디바이스(40)의 로컬 클럭이, 세그먼트(i)가 이용 가능하게 되는(또는 이용 가능하게 된) 실제 시간에 관련하여 드리프트되었다는 것을 결정한다. 따라서, 클라이언트 디바이스(40)는, 본 개시의 기술들에 따라, 프로브 요청들을 서버 디바이스(60)에 전송(214)할 수 있다. 프로브 요청들은 매우 작은 데이터 양에 대해, 예를 들어 100 바이트들의 데이터까지 HTTP HEAD 요청들 또는 부분 GET 요청들에 대응할 수 있다. 클라이언트 디바이스(40)는 도 4에 관하여 상기 논의된 바와 같이 프로브 요청들을 전송할 수 있다. 예를 들어, 클라이언트 디바이스(40)는, 하나 또는 그 초과의 프로브 요청들이 세그먼트(i)보다 이른 세그먼트들에 지향되고, 하나 또는 그 초과의 프로브 요청들이 세그먼트(i)보다 늦은 세그먼트들로 지향되도록, 프로브 요청들을 전송할 수 있다.
[0161] 그 다음 서버 디바이스(60)는 요청들을 수신(216)할 수 있고 요청들에 대한 응답들을 전송(218)할 수 있다. 프로브 요청들이 HTTP HEAD 요청들인 것을 가정하면, 서버 디바이스(60)는 현재 이용 가능한(이하에 "성공" 프로브 응답들로서 지칭됨) 이들 세그먼트들에 대한 헤더 정보, 및 현재 이용 가능하지 않은 이들 세그먼트들에 대한 에러 메시지들(예를 들어, HTTP 404 에러들)을 전송할 수 있다.
[0162] 클라이언트 디바이스(40)는 응답들을 수신(220)할 수 있고 세그먼트 이용 가능성 윈도우의 하나 또는 그 초과의 에지들을 결정하기 위하여 응답들을 분석(222)할 수 있다. 예를 들어, 성공적 프로브 응답들의 패턴 및 에러 메시지들이 상기 논의된 바와 같이, 도 5에 예시된 패턴과 유사하면, 클라이언트 디바이스(40)는 성공적 프로브 응답을 가진 최신 세그먼트(예를 들어, 세그먼트(i-k-1))를 세그먼트 이용 가능성 윈도우의 우측 에지로서 식별할 수 있다. 게다가, 클라이언트 디바이스(40)는, 세그먼트들에 대한 추후 요청들에 대한 에러 응답들을 회피하기 위하여, 로컬 클럭에 적용될 오프셋을 결정하도록 세그먼트(i)와 세그먼트 이용 가능성 윈도우(이 경우, k+1)의 우측 에지 사이의 시간 델타를 결정할 수 있다. 클라이언트 디바이스(40)는, 이 예에서 상기 논의된 바와 같이 식(6)을 사용하여 시간 델타를 결정할 수 있다.
[0163] 다른 예로서, 성공적 프로브 응답들 및 에러 메시지들의 패턴이 도 6에 예시된 패턴과 유사하면, 클라이언트 디바이스(40)는 세그먼트 이용 가능성 윈도우의 좌측 에지를 결정할 수 있다. 이 예에서, 클라이언트 디바이스(40)는 또한 예를 들어 상기 논의된 바와 같이 식(7)을 사용하여 시간 델타를 계산할 수 있다. 또 다른 예로서, 성공적 프로브 응답들 및 에러 메시지들의 패턴이 도 7에 예시된 패턴과 유사하면, 클라이언트 디바이스(40)는 세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지 둘 다를 결정할 수 있다. 이 예에서, 클라이언트 디바이스(40)는 또한 예를 들어 상기 논의된 바와 같이 식(8)을 사용하여 시간 델타를 계산할 수 있다. 성공적 프로브 응답들 및 에러 메시지들이 도 9에 예시된 패턴과 유사한 경우, 클라이언트 디바이스(40)는 세그먼트 이용 가능성 윈도우의 좌측 및/또는 우측 에지들을 식별하기 위하여 계층 탐색 방법을 수행할 수 있다. 게다가, 좌측 또는 우측 에지들 중 단지 하나만이 발견되면, 클라이언트 디바이스(40)는 세그먼트 이용 가능성 윈도우(도 11에 도시되지 않은 것을 통해)의 다른 에지를 발견하기 위하여 부가적인 프로브 패킷들을 전송할 수 있다.
[0164] 임의의 경우, 세그먼트 이용 가능성 윈도우의 적어도 하나의 에지를 결정한 후, 클라이언트 디바이스(40)는 세그먼트 이용 가능성 윈도우 내의 세그먼트에 대한 요청을 전송(224)할 수 있다. 예를 들어, 상기 논의된 예에서, 클라이언트 디바이스(40)는 세그먼트(i-k-1)에 대한 요청을 전송할 수 있다. 그 다음 서버 디바이스(60)는 요청을 수신(226)할 수 있고 요청된 세그먼트를 클라이언트 디바이스(40)에 전송(228)할 수 있다.
[0165] 클라이언트 디바이스(40)가 다양한 트리거들, 이를테면 세그먼트들에 대한 하나 또는 그 초과의 에러들이 수신된 때(예를 들어, 연속하여), 처음에 스트리밍 세션을 시작하는 것에 응답하여, 프로브 패킷들의 최종 세트가 전송된 이래 경과된 시간 양(이는 또한 전송될 프로브 패킷들의 수에 영향을 미칠 수 있음), 이들 트리거들의 임의의 결합, 및 다른 부가적인 또는 대안적인 트리거들에 응답하여 도 11에 설명된 프로브 패킷 방법을 수행할 수 있다는 것이 이해되어야 한다.
[0166] 이런 방식으로, 도 11의 방법은 미디어 데이터를 리트리빙하는 방법의 예를 나타내고, 방법은 미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하는 단계 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 미디어 데이터를 제공함 ―, 세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 복수의 프로브 요청들에 대한 응답들을 분석하는 단계, 및 라이브 스트리밍 서비스에 따라, 세그먼트 이용 가능성 윈도우의 결정된 좌측 에지 및 결정된 우측 에지에 기초하여 세그먼트 이용 가능성 윈도우 내의 세그먼트에 대한 요청을 전송하는 단계를 포함한다.
[0167] 하나 또는 그 초과의 예들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 결합으로 구현될 수 있다. 만약 소프트웨어로 구현되면, 기능들은 하나 또는 그 초과의 명령들 또는 코드로서 컴퓨터-판독가능 매체 상에 저장되거나 전송되고 하드웨어-기반 프로세싱 유닛에 의해 실행될 수 있다. 컴퓨터-판독가능 미디어는 데이터 스토리지 미디어 같은 유형의 매체에 대응하는 컴퓨터-판독가능 스토리지 미디어, 또는 예를 들어 통신 프로토콜에 따라, 하나의 장소로부터 다른 장소로 컴퓨터 프로그램의 전달을 가능하게 하는 임의의 매체를 포함하는 통신 미디어를 포함할 수 있다. 이런 방식으로, 컴퓨터-판독가능 미디어는 일반적으로 (1) 비-일시적인 유형의 컴퓨터-판독가능 스토리지 미디어 또는 (2) 신호 또는 반송파 같은 통신 매체에 대응할 수 있다. 데이터 스토리지 미디어는 본 개시에 설명된 기술들의 구현을 위해 명령들, 코드 및/또는 데이터 구조들을 리트리브하기 위하여 하나 또는 그 초과의 컴퓨터 또는 하나 또는 그 초과의 프로세서들에 의해 액세스될 수 있는 임의의 이용 가능한 미디어일 수 있다. 컴퓨터 프로그램 물건은 컴퓨터-판독가능 매체를 포함할 수 있다.
[0168] 제한이 아닌 예로서, 이러한 컴퓨터-판독가능 미디어는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학 디스크 스토리지, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스들, 플래시 메모리, 또는 명령들 또는 데이터 구조들의 형태로 원하는 프로그램 코드를 저장하는데 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 또한, 임의의 연결수단(connection)이 컴퓨터-판독가능 매체로 적절히 지칭된다. 예를 들어, 명령들이 동축 케이블, 광섬유 케이블, 트위스티드 페어(twisted pair), DSL(digital subscriber line), 또는 (적외선, 라디오, 및 마이크로파와 같은) 무선 기술들을 이용하여 웹사이트, 서버, 또는 다른 원격 소스로부터 전송되는 경우, 동축 케이블, 광섬유 케이블, 트위스티드 페어, DSL, 또는 (적외선, 라디오, 및 마이크로파와 같은) 무선 기술들은 이러한 매체의 정의에 포함된다. 그러나, 컴퓨터-판독가능 스토리지 미디어 및 데이터 스토리지 미디어가 연결 수단들, 반송파들, 신호들, 또는 다른 일시적 미디어를 포함하는 것이 아니라, 대신 비-일시적, 유형의 스토리지 미디어에 관련되는 것이 이해되어야 한다. 본원에 사용되는 바와 같은 디스크(disk) 및 디스크(disc)는 CD(compact disc), 레이저 디스크(laser disc), 광학 디스크(optical disc), DVD(digital versatile disc), 플로피 디스크(floppy disk) 및 블루-레이 디스크(blu-ray disc)를 포함하며, 여기서 디스크(disk)들은 일반적으로 데이터를 자기적으로 재생하는 한편, 디스크(disc)들은 레이저들을 이용하여 광학적으로 데이터를 재생한다. 앞서의 것들의 결합들이 또한 컴퓨터-판독가능 매체들의 범주 내에 포함되어야 한다.
[0169] 명령들은 DSP(digital signal processor)들, 범용 마이크로프로세서들, ASIC(application specific integrated circuit)들, FPGA(field programmable gate array)들 또는 다른 동등한 집적된 또는 이산 로직 회로 같은 하나 또는 그 초과의 프로세서들에 의해 실행될 수 있다. 따라서, 본원에 사용된 바와 같은 용어 "프로세서"는 본원에 설명된 기술들의 구현을 위해 적당한 상기 구조 중 임의의 것 또는 임의의 다른 구조를 지칭할 수 있다. 게다가, 몇몇 양상들에서, 본원에 설명된 기능성은 인코딩 및 디코딩을 위해 구성되거나, 결합된 코덱에 통합된 전용 하드웨어 및/또는 소프트웨어 모듈들 내에 제공될 수 있다. 또한, 기술들은 하나 또는 그 초과의 회로들 또는 로직 엘리먼트들로 완전히 구현될 수 있다.
[0170] 본 개시의 기술들은 무선 핸드셋, 집적 회로(IC) 또는 IC들의 세트(예를 들어, 칩 세트)를 포함하는 매우 다양한 디바이스들 또는 장치들로 구현될 수 있다. 다양한 컴포넌트들, 모듈들, 또는 유닛들은 개시된 기술들을 수행하도록 구성된 디바이스들의 기능 양상들을 강조하기 위하여 본 개시에 설명되지만, 반드시 상이한 하드웨어 유닛들에 의한 실현을 요구하지 않는다. 오히려, 상기 설명된 바와 같이, 다양한 유닛들은, 적당한 소프트웨어 및/또는 펌웨어와 함께, 상기 설명된 바와 같은 하나 또는 그 초과의 프로세서들을 포함하는 상호동작 하드웨어 유닛들의 콜렉션에 의해 제공되거나 코덱 하드웨어 유닛으로 결합될 수 있다.
[0171] 다양한 예들이 설명되었다. 이들 및 다른 예들은 다음 청구항들의 범위 내에 있다.

Claims (55)

  1. 미디어 데이터를 리트리빙(retrieving)하는 방법으로서,
    미디어 데이터의 세그먼트(segment)들에 대한 복수의 프로브 요청(probe request)들을 서버 디바이스에 전송하는 단계 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 상기 미디어 데이터를 제공함 ―;
    세그먼트 이용 가능성 윈도우(segment availability window)의 좌측 에지 및 우측 에지를 결정하기 위하여 상기 복수의 프로브 요청들에 대한 응답들을 분석하는 단계;
    결정된 좌측 에지 또는 결정된 우측 에지에 적어도 부분적으로 기초하여 클라이언트 디바이스의 로컬 클럭과 서버 디바이스의 클럭 사이의 시간 차이를 결정하는 단계; 및
    상기 라이브 스트리밍 서비스에 따라, 상기 결정된 좌측 에지 또는 상기 결정된 우측 에지에 적어도 부분적으로 기초하는 결정된 시간 차이에 적어도 부분적으로 기초하여 세그먼트에 대한 요청을 전송하는 단계
    를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  2. 제 1 항에 있어서,
    상기 프로브 요청들은 상기 세그먼트들에 대한 전체 데이터 양보다 더 작은 세그먼트들의 데이터 양에 대한 요청들을 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  3. 제 1 항에 있어서,
    상기 프로브 요청들은 HTTP HEAD 요청들을 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  4. 제 1 항에 있어서,
    상기 프로브 요청들은 HTTP 부분 GET 요청들을 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  5. 제 1 항에 있어서,
    상기 세그먼트 이용 가능성 윈도우는 업데이트된 세그먼트 이용 가능성 윈도우를 포함하고,
    상기 방법은, 상기 복수의 프로브 요청들을 전송하기 전에:
    원래(originally) 결정된 세그먼트 이용 가능성 윈도우 내에서 세그먼트들에 대한 복수의 요청들을 전송하는 단계; 및
    상기 원래 결정된 세그먼트 이용 가능성 윈도우 내에서의 상기 세그먼트들에 대한 요청들에 대한 응답들이 다수의 HTTP 404 에러들을 포함한다는 것을 결정하는 단계
    를 더 포함하고,
    상기 복수의 프로브 요청들을 전송하는 단계는, 상기 원래 결정된 세그먼트 이용 가능성 윈도우 내에서의 상기 세그먼트들에 대한 요청들에 대한 응답들 내의 상기 다수의 HTTP 404 에러들에 기초하여 상기 복수의 프로브 요청들을 전송하는 단계를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  6. 제 1 항에 있어서,
    상기 복수의 프로브 요청들을 전송하는 단계는, 상기 미디어 데이터를 리트리빙하기 위하여 HTTP 스트리밍 세션을 개시할 때 상기 복수의 프로브 요청들을 전송하는 단계를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  7. 제 1 항에 있어서,
    상기 응답들을 분석하는 단계는,
    보다 이른(earlier) 세그먼트들에 대한 요청들에 대한 응답들이 성공들을 나타냈고, 보다 늦은(later) 세그먼트들에 대한 요청들에 대한 응답들이 실패들을 나타냈다는 것을 결정하는 단계; 및
    상기 보다 이른 세그먼트들에 대한 요청들에 대한 응답들이 성공들을 나타냈고, 상기 보다 늦은 세그먼트들에 대한 요청들에 대한 응답들이 실패들을 나타냈다는 상기 결정에 기초하여, 상기 세그먼트 이용 가능성 윈도우의 상기 우측 에지가, 상기 응답들이 성공들을 나타냈던 세그먼트들과 상기 응답들이 실패들을 나타냈던 세그먼트들 사이에 있다는 것을 결정하는 단계
    를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  8. 제 7 항에 있어서,
    시간_델타
    Figure 112016101900888-pct00023
    에 따라 시간 델타(delta) 값을 계산하는 단계를 더 포함하고, D(j)는 세그먼트 j의 지속시간을 정의하고, i는 클라이언트 디바이스의 클럭에 기초하여 추정된 이용 가능한 세그먼트를 나타내고, 그리고 k는 세그먼트 i와 상기 응답들이 성공을 나타냈던 가장 늦은 세그먼트 사이의 세그먼트들의 수를 나타내는,
    미디어 데이터를 리트리빙하는 방법.
  9. 제 1 항에 있어서,
    상기 응답들을 분석하는 단계는,
    보다 늦은 세그먼트들에 대한 요청들에 대한 응답들이 성공들을 나타냈고, 보다 이른 세그먼트들에 대한 요청들에 대한 응답들이 실패들을 나타냈다는 것을 결정하는 단계; 및
    상기 결정에 기초하여, 상기 세그먼트 이용 가능성 윈도우의 상기 좌측 에지가, 상기 응답들이 성공들을 나타냈던 세그먼트들과 상기 응답들이 실패들을 나타냈던 세그먼트들 사이에 있다는 것을 결정하는 단계
    를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  10. 제 9 항에 있어서,
    시간_델타
    Figure 112016101900888-pct00024
    에 따라 시간 델타 값을 계산하는 단계를 더 포함하고, D(j)는 세그먼트 j의 지속시간을 정의하고, i는 클라이언트 디바이스의 클럭에 기초하여 추정된 이용 가능한 세그먼트를 나타내고, TSBD는 시간 시프트 버퍼 깊이(time shift buffer depth)를 나타내고, 그리고 k는 세그먼트 i와 상기 응답들이 성공을 나타냈던 가장 이른 세그먼트 사이의 세그먼트들의 수를 나타내는,
    미디어 데이터를 리트리빙하는 방법.
  11. 제 1 항에 있어서,
    상기 응답들을 분석하는 단계는,
    보다 이른 세그먼트들에 대한 요청들에 대한 응답들이 실패들을 나타냈고, 보다 늦은 세그먼트들에 대한 요청들에 대한 응답들이 실패들을 나타냈고, 그리고 보다 이른 세그먼트들과 보다 늦은 세그먼트들 사이의 중간 세그먼트들에 대한 요청들에 대한 응답들이 성공들을 나타냈다는 것을 결정하는 단계; 및
    상기 결정에 기초하여, 상기 세그먼트 이용 가능성 윈도우의 상기 좌측 에지가 상기 보다 이른 세그먼트들과 상기 중간 세그먼트들 사이에 있고, 그리고 상기 세그먼트 이용 가능성 윈도우의 상기 우측 에지가 상기 중간 세그먼트들과 상기 보다 늦은 세그먼트들 사이에 있다는 것을 결정하는 단계
    를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  12. 제 11 항에 있어서,
    시간_델타
    Figure 112016101900888-pct00025
    에 따라 시간 델타 값을 계산하는 단계를 더 포함하고, D(j)는 세그먼트 j의 지속시간을 정의하고, i는 클라이언트 디바이스의 클럭에 기초하여 추정된 이용 가능한 세그먼트를 나타내고, 그리고 k는 세그먼트 i와 상기 응답들이 성공을 나타냈던 가장 늦은 세그먼트 사이의 세그먼트들의 수를 나타내는,
    미디어 데이터를 리트리빙하는 방법.
  13. 제 1 항에 있어서,
    상기 복수의 프로브 요청들은 제 2 복수의 프로브 요청들을 포함하고,
    상기 방법은, 상기 제 2 복수의 프로브 요청들을 전송하기 전에, 제 1 재생 시간 양을 커버하는 제 1 복수의 프로브 요청들을 전송하는 단계를 더 포함하고,
    상기 제 2 복수의 프로브 요청들을 전송하는 것은, 상기 제 1 복수의 프로브 요청들에 대한 응답들이 실패들을 나타냈다는 것을 결정한 후 상기 제 2 복수의 프로브 요청들을 전송하는 것을 포함하고, 그리고 상기 제 2 복수의 프로브 요청들은 상기 제 1 재생 시간 양보다 더 큰 제 2 재생 시간 양을 커버하는,
    미디어 데이터를 리트리빙하는 방법.
  14. 제 13 항에 있어서,
    계층 탐색 방법을 사용하여 상기 제 2 복수의 프로브 요청들에 포함될 프로브들의 수를 결정하는 단계를 더 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  15. 제 1 항에 있어서,
    상기 복수의 프로브 요청들을 전송하는 단계는, 보다 이른 프로브 요청들이 보다 이른 세그먼트들에 대응하고, 보다 늦은 프로브 요청들이 보다 늦은 세그먼트들에 대응하도록, 상기 복수의 프로브 요청들을 전송하는 단계를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  16. 제 1 항에 있어서,
    상기 응답들을 분석하는 단계는, 응답들의 타입들 사이의 변화들의 수를 계산하는 단계를 포함하고,
    제 1 타입의 응답은 대응하는 세그먼트가 이용 가능하다는 것을 나타내고, 그리고 제 2 타입의 응답은 상기 대응하는 세그먼트가 이용 가능하지 않다는 것을 나타내는,
    미디어 데이터를 리트리빙하는 방법.
  17. 제 16 항에 있어서,
    상기 응답들의 타입들 사이의 변화들의 계산된 수가 1 또는 2와 동일하다는 것을 결정한 후에만, 상기 세그먼트 이용 가능성 윈도우의 상기 좌측 에지 및 상기 우측 에지를 결정하는 단계를 더 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  18. 제 1 항에 있어서,
    상기 세그먼트에 대한 요청을 전송하는 단계는, 상기 우측 에지에 하나의 세그먼트 만큼 뒤진 세그먼트에 대한 요청을 전송하는 단계를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  19. 제 1 항에 있어서,
    상기 서버 디바이스와의 최종 시간 동기화 이후 경과된 시간 양에 기초하여 상기 복수의 프로브 요청들에 포함시킬 프로브 요청들의 수를 결정하는 단계를 더 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  20. 제 19 항에 있어서,
    상기 프로브 요청들의 수를 결정하는 단계는,
    상기 경과된 시간 양이 1분보다 작거나 같을 때 상기 프로브 요청들의 수가 10과 동일하고, 상기 경과된 시간 양이 1분보다 크고 10분 보다 작거나 같을 때 상기 프로브 요청들의 수가 15와 동일하고, 상기 경과된 시간 양이 10분보다 크지만 1시간보다 작거나 같을 때 상기 프로브 요청들의 수가 20과 동일하고, 상기 경과된 시간 양이 1시간보다 클 때 상기 프로브 요청들의 수가 25와 동일하다고 결정하는 단계를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  21. 제 1 항에 있어서,
    상기 미디어 데이터를 요청하기 위하여 스트리밍 세션을 개시하기 전에 클라이언트 디바이스의 클럭을 상기 서버 디바이스와 동기화하는 단계를 더 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  22. 제 21 항에 있어서,
    상기 동기화하는 단계는, 네트워크 시간 프로토콜(NTP: network time protocol)을 사용하여 동기화하는 단계를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  23. 제 1 항에 있어서,
    클라이언트 디바이스의 클럭을 상기 서버 디바이스와 주기적으로 동기화하는 단계를 더 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  24. 제 23 항에 있어서,
    상기 주기적으로 동기화하는 단계는, 매 N 분마다 상기 클라이언트 디바이스의 클럭을 상기 서버 디바이스와 동기화하는 단계를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  25. 제 1 항에 있어서,
    상기 요청을 전송하는 단계는, 라이브 DASH(dynamic adaptive streaming over HTTP)에 따라 상기 요청을 전송하는 단계를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  26. 제 1 항에 있어서,
    상기 복수의 프로브 요청들을 전송하는 단계는, 상기 미디어 데이터에 대한 요청을 전송한 후 상기 미디어 데이터 재생에 대한 실패에 응답하여 상기 복수의 프로브 요청들을 전송하는 단계를 포함하고,
    상기 방법은,
    상기 결정된 좌측 에지 및 상기 결정된 우측 에지에 적어도 부분적으로 기초하여 클라이언트 디바이스의 로컬 클럭과 서버 디바이스의 클럭 사이의 시간 차이를 결정하는 단계; 및
    결정된 시간 차이에 기초하여 상기 로컬 클럭을 조정하는 단계
    를 더 포함하고,
    상기 요청을 전송하는 단계는, 조정된 로컬 클럭에 기초하여 상기 요청을 전송하는 단계를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  27. 제 1 항에 있어서,
    상기 시간 차이는, 상기 로컬 클럭이 상기 서버 디바이스의 클럭을 앞서는 것을 나타내고, 상기 방법은 상기 시간 차이와 동일한 시간 기간 동안 미디어 재생을 멈추는 단계를 더 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  28. 제 1 항에 있어서,
    상기 시간 차이는, 상기 로컬 클럭이 상기 서버 디바이스의 클럭에 뒤지는 것을 나타내고, 상기 방법은, 상기 시간 차이와 동일한 시간 기간 동안 미디어 재생을 스킵(skip)하는 단계를 더 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  29. 제 1 항에 있어서,
    상기 시간 차이는, 상기 로컬 클럭이 상기 서버 디바이스의 클럭을 앞서는 것을 나타내고, 상기 방법은, 상기 시간 차이가 영(zero)일 때까지 정상 재생 레이트를 약간 초과하는 레이트로 상기 미디어 데이터를 재생(play)하는 단계를 더 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  30. 제 1 항에 있어서,
    상기 시간 차이는, 상기 로컬 클럭이 상기 서버 디바이스의 클럭에 뒤지는 것을 나타내고, 상기 방법은, 상기 시간 차이가 영(zero)일 때까지 정상 재생 레이트에 약간 아래인 레이트로 상기 미디어 데이터를 재생하는 단계를 더 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  31. 미디어 데이터를 리트리빙하는 방법으로서,
    미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하는 단계 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 상기 미디어 데이터를 제공함 ―;
    세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 상기 복수의 프로브 요청들에 대한 응답들을 분석하는 단계;
    세그먼트가 실제로 이용 가능한 시간과 클라이언트 디바이스의 클럭이 상기 세그먼트가 이용 가능하다고 나타내는 시간 사이의 차이를 나타내는 시간 델타를 결정하는 단계; 및
    상기 시간 델타에 기초하여 상기 세그먼트들 중 하나 또는 그 초과의 세그먼트들을 요청하는 단계
    를 포함하고,
    상기 요청하는 단계는, 상기 라이브 스트리밍 서비스에 따라, 상기 세그먼트 이용 가능성 윈도우의 결정된 좌측 에지 또는 결정된 우측 에지에 기초하여 세그먼트에 대한 요청을 전송하는 단계를 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  32. 제 31 항에 있어서,
    후속하는 복수의 프로브 패킷들을 사용하여 상기 시간 델타를 주기적으로 업데이트하는 단계를 더 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  33. 제 31 항에 있어서,
    상기 세그먼트 이용 가능성 윈도우의 정확한 우측 에지를 결정하도록 시도하기 위하여 하나 또는 그 초과의 작은 증분들만큼 상기 시간 델타를 증가시키는 단계를 더 포함하는,
    미디어 데이터를 리트리빙하는 방법.
  34. 미디어 데이터를 리트리빙하기 위한 디바이스로서,
    미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하고 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 상기 미디어 데이터를 제공함 ―,
    세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 상기 복수의 프로브 요청들에 대한 응답들을 분석하고,
    결정된 좌측 에지 또는 결정된 우측 에지에 적어도 부분적으로 기초하여 클라이언트 디바이스의 로컬 클럭과 서버 디바이스의 클럭 사이의 시간 차이를 결정하고, 그리고
    상기 라이브 스트리밍 서비스에 따라, 결정된 좌측 에지 또는 결정된 우측 에지에 적어도 부분적으로 기초하는 결정된 시간 차이에 적어도 부분적으로 기초하여 세그먼트에 대한 요청을 전송하도록 구성되는
    하나 또는 그 초과의 프로세서들을 포함하는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  35. 제 34 항에 있어서,
    상기 프로브 요청들은 HTTP HEAD 요청들 및 HTTP 부분 GET 요청들 중 하나를 포함하는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  36. 제 34 항에 있어서,
    상기 하나 또는 그 초과의 프로세서들은, 이전 요청들에 대한 응답들이 다수의 HTTP 404 에러들을 포함했다는 결정 및 HTTP 스트리밍 세션의 개시 중 적어도 하나에 기초하여 상기 복수의 프로브 요청들을 전송하도록 구성되는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  37. 제 34 항에 있어서,
    상기 응답들을 분석하기 위하여, 상기 하나 또는 그 초과의 프로세서들은,
    보다 이른 세그먼트들에 대한 요청들에 대한 응답들이 실패들을 나타냈고, 보다 늦은 세그먼트들에 대한 요청들에 대한 응답들이 실패들을 나타냈고, 그리고 상기 보다 이른 세그먼트들과 상기 보다 늦은 세그먼트들 사이의 중간 세그먼트들에 대한 요청들에 대한 응답들이 성공들을 나타냈다는 것을 결정하고, 그리고
    상기 결정에 기초하여, 상기 세그먼트 이용 가능성 윈도우의 상기 좌측 에지가 상기 보다 이른 세그먼트들과 상기 중간 세그먼트들 사이에 있고 상기 세그먼트 이용 가능성 윈도우의 상기 우측 에지가 상기 중간 세그먼트들과 상기 보다 늦은 세그먼트들 사이에 있다는 것을 결정하도록 구성되는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  38. 제 37 항에 있어서,
    상기 하나 또는 그 초과의 프로세서들은, 시간_델타
    Figure 112016101900888-pct00026
    에 따라 시간 델타 값을 계산하도록 구성되고, D(j)는 세그먼트 j의 지속시간을 정의하고, i는 클라이언트 디바이스의 클럭에 기초하여 추정된 이용 가능한 세그먼트를 나타내고, 그리고 k는 세그먼트i와 상기 응답들이 성공을 나타냈던 가장 늦은 세그먼트 사이의 세그먼트들의 수를 나타내는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  39. 제 34 항에 있어서,
    상기 복수의 프로브 요청들은 제 2 복수의 프로브 요청들을 포함하고,
    상기 하나 또는 그 초과의 프로세서들은, 상기 제 2 복수의 프로브 요청들을 전송하기 전에, 상기 제 2 복수의 프로브 요청들보다 더 적은 프로브 요청들을 포함하는 제 1 복수의 프로브 요청들을 전송하고, 그리고 상기 제 1 복수의 프로브 요청들에 대한 응답들이 실패들을 나타냈다고 결정한 후 상기 제 2 복수의 프로브 요청들을 전송하도록 구성되는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  40. 미디어 데이터를 리트리빙하기 위한 디바이스로서,
    미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하고 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 상기 미디어 데이터를 제공함 ―,
    세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 상기 복수의 프로브 요청들에 대한 응답들을 분석하고,
    세그먼트가 실제로 이용 가능한 시간과 클라이언트 디바이스의 클럭이 상기 세그먼트가 이용 가능하다고 나타내는 시간 사이의 차이를 나타내는 시간 델타를 결정하고, 그리고
    상기 시간 델타에 기초하여 상기 세그먼트들 중 하나 또는 그 초과의 세그먼트들을 요청하도록 구성되는
    하나 또는 그 초과의 프로세서들을 포함하고,
    상기 하나 또는 그 초과의 세그먼트들을 요청하기 위하여, 상기 하나 또는 그 초과의 프로세서들은, 상기 라이브 스트리밍 서비스에 따라, 상기 세그먼트 이용 가능성 윈도우의 결정된 좌측 에지 또는 결정된 우측 에지에 기초하여 세그먼트에 대한 요청을 전송하도록 구성되는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  41. 미디어 데이터를 리트리빙하기 위한 디바이스로서,
    미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하기 위한 수단 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 상기 미디어 데이터를 제공함 ―;
    세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 상기 복수의 프로브 요청들에 대한 응답들을 분석하기 위한 수단;
    결정된 좌측 에지 또는 결정된 우측 에지에 적어도 부분적으로 기초하여 클라이언트 디바이스의 로컬 클럭과 서버 디바이스의 클럭 사이의 시간 차이를 결정하기 위한 수단; 및
    상기 라이브 스트리밍 서비스에 따라, 상기 결정된 좌측 에지 또는 상기 결정된 우측 에지에 적어도 부분적으로 기초하는 결정된 시간 차이에 적어도 부분적으로 기초하여 세그먼트에 대한 요청을 전송하기 위한 수단
    을 포함하는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  42. 제 41 항에 있어서,
    상기 프로브 요청들은 HTTP HEAD 요청들 및 HTTP 부분 GET 요청들 중 하나를 포함하는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  43. 제 41 항에 있어서,
    상기 복수의 프로브 요청들을 전송하기 위한 수단은, 이전 요청들에 응답하여 수신된 다수의 HTTP 404 에러들에 기초하여 상기 복수의 프로브 요청들을 전송하기 위한 수단 및 HTTP 스트리밍 세션의 개시에 기초하여 상기 복수의 프로브 요청들을 전송하기 위한 수단 중 적어도 하나를 포함하는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  44. 제 41 항에 있어서,
    상기 응답들을 분석하기 위한 수단은,
    보다 이른 세그먼트들에 대한 요청들에 대한 응답들이 실패들을 나타냈고, 보다 늦은 세그먼트들에 대한 요청들에 대한 응답들이 실패들을 나타냈고, 그리고 상기 보다 이른 세그먼트들과 상기 보다 늦은 세그먼트들 사이의 중간 세그먼트들에 대한 요청들에 대한 응답들이 성공들을 나타냈다는 것을 결정하기 위한 수단; 및
    상기 결정에 기초하여, 상기 세그먼트 이용 가능성 윈도우의 상기 좌측 에지가 상기 보다 이른 세그먼트들과 상기 중간 세그먼트들 사이에 있고 상기 세그먼트 이용 가능성 윈도우의 상기 우측 에지가 상기 중간 세그먼트들과 상기 보다 늦은 세그먼트들 사이에 있다는 것을 결정하기 위한 수단
    을 포함하는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  45. 제 44 항에 있어서,
    시간_델타
    Figure 112016101900888-pct00027
    에 따라 시간 델타 값을 계산하기 위한 수단을 더 포함하고, D(j)는 세그먼트 j의 지속시간을 정의하고, i는 클라이언트 디바이스의 클럭에 기초하여 추정된 이용 가능한 세그먼트를 나타내고, 그리고 k는 세그먼트 i와 상기 응답들이 성공을 나타냈던 가장 늦은 세그먼트 사이의 세그먼트들의 수를 나타내는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  46. 제 41 항에 있어서,
    상기 복수의 프로브 요청들은 제 2 복수의 프로브 요청들을 포함하고,
    상기 디바이스는, 상기 제 2 복수의 프로브 요청들을 전송하기 전에, 상기 제 2 복수의 프로브 요청들보다 더 적은 프로브 요청들을 포함하는 제 1 복수의 프로브 요청들을 전송하기 위한 수단을 더 포함하고,
    상기 제 2 복수의 프로브 요청들을 전송하기 위한 수단은 상기 제 1 복수의 프로브 요청들에 대한 응답들이 실패들을 나타냈다고 결정한 후 상기 제 2 복수의 프로브 요청들을 전송하기 위한 수단을 포함하는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  47. 미디어 데이터를 리트리빙하기 위한 디바이스로서,
    미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하기 위한 수단 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 상기 미디어 데이터를 제공함 ―;
    세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 상기 복수의 프로브 요청들에 대한 응답들을 분석하기 위한 수단;
    세그먼트가 실제로 이용 가능한 시간과 클라이언트 디바이스의 클럭이 상기 세그먼트가 이용 가능하다고 나타내는 시간 사이의 차이를 나타내는 시간 델타를 결정하기 위한 수단; 및
    상기 시간 델타에 기초하여 상기 세그먼트들 중 하나 또는 그 초과의 세그먼트들을 요청하기 위한 수단
    를 포함하고,
    상기 상기 세그먼트들 중 하나 또는 그 초과의 세그먼트들을 요청하기 위한 수단은, 상기 라이브 스트리밍 서비스에 따라, 상기 세그먼트 이용 가능성 윈도우의 결정된 좌측 에지 또는 결정된 우측 에지에 기초하여 세그먼트에 대한 요청을 전송하기 위한 수단을 포함하는,
    미디어 데이터를 리트리빙하기 위한 디바이스.
  48. 컴퓨터-판독가능 스토리지(storage) 매체로서,
    실행될 때, 프로세서로 하여금,
    미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하게 하고 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 상기 미디어 데이터를 제공함 ―;
    세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 상기 복수의 프로브 요청들에 대한 응답들을 분석하게 하고;
    결정된 좌측 에지 또는 결정된 우측 에지에 적어도 부분적으로 기초하여 클라이언트 디바이스의 로컬 클럭과 서버 디바이스의 클럭 사이의 시간 차이를 결정하게 하고; 그리고
    상기 라이브 스트리밍 서비스에 따라, 상기 결정된 좌측 에지 또는 상기 결정된 우측 에지에 적어도 부분적으로 기초하는 결정된 시간 차이에 적어도 부분적으로 기초하여 상기 세그먼트 이용 가능성 윈도우 내의 세그먼트에 대한 요청을 전송하게 하는,
    저장된 명령들을 갖는,
    컴퓨터-판독가능 스토리지 매체.
  49. 제 48 항에 있어서,
    상기 프로브 요청들은 HTTP HEAD 요청들 및 HTTP 부분 GET 요청들 중 하나를 포함하는,
    컴퓨터-판독가능 스토리지 매체.
  50. 제 48 항에 있어서,
    상기 프로세서로 하여금 상기 복수의 프로브 요청들을 전송하게 하는 명령들은, 상기 프로세서로 하여금 이전 요청들에 응답하여 수신된 다수의 HTTP 404 에러들 및 HTTP 스트리밍 세션의 개시 중 적어도 하나에 기초하여 상기 복수의 프로브 요청들을 전송하게 하는 명령들을 포함하는,
    컴퓨터-판독가능 스토리지 매체.
  51. 제 48 항에 있어서,
    상기 프로세서로 하여금, 상기 응답들을 분석하게 하는 명령들은,
    상기 프로세서로 하여금,
    보다 이른 세그먼트들에 대한 요청들에 대한 응답들이 실패들을 나타냈고, 보다 늦은 세그먼트들에 대한 요청들에 대한 응답들이 실패들을 나타냈고, 그리고 상기 보다 이른 세그먼트들과 상기 보다 늦은 세그먼트들 사이의 중간 세그먼트들에 대한 요청들에 대한 응답들이 성공들을 나타냈다는 것을 결정하게 하고; 그리고
    상기 결정에 기초하여, 상기 세그먼트 이용 가능성 윈도우의 상기 좌측 에지가 상기 보다 이른 세그먼트들과 상기 중간 세그먼트들 사이에 있고 상기 세그먼트 이용 가능성 윈도우의 상기 우측 에지가 상기 중간 세그먼트들과 상기 보다 늦은 세그먼트들 사이에 있다는 것을 결정하게 하는
    명령들을 포함하는,
    컴퓨터-판독가능 스토리지 매체.
  52. 제 51 항에 있어서,
    상기 프로세서로 하여금, 시간_델타
    Figure 112016101900888-pct00028
    에 따라 시간 델타 값을 계산하게 하는 명령들을 더 포함하고, D(j)는 세그먼트 j의 지속시간을 정의하고, i는 클라이언트 디바이스의 클럭에 기초하여 추정된 이용 가능한 세그먼트를 나타내고, 그리고 k는 세그먼트 i와 상기 응답들이 성공을 나타냈던 가장 늦은 세그먼트 사이의 세그먼트들의 수를 나타내는,
    컴퓨터-판독가능 스토리지 매체.
  53. 제 48 항에 있어서,
    상기 복수의 프로브 요청들은 제 2 복수의 프로브 요청들을 포함하고,
    상기 컴퓨터-판독가능 스토리지 매체는, 상기 프로세서로 하여금, 상기 제 2 복수의 프로브 요청들을 전송하기 전에, 상기 제 2 복수의 프로브 요청들보다 더 적은 프로브 요청들을 포함하는 제 1 복수의 프로브 요청들을 전송하게 하는 명령들을 더 포함하고,
    상기 프로세서로 하여금, 제 2 복수의 프로브 요청들을 전송하게 하는 명령들은, 상기 프로세서로 하여금, 상기 제 1 복수의 프로브 요청들에 대한 응답들이 실패들을 나타냈다고 결정한 후 상기 제 2 복수의 프로브 요청들을 전송하게 하는 명령들을 포함하는,
    컴퓨터-판독가능 스토리지 매체.
  54. 컴퓨터-판독가능 스토리지 매체로서,
    실행될 때, 프로세서로 하여금,
    미디어 데이터의 세그먼트들에 대한 복수의 프로브 요청들을 서버 디바이스에 전송하게 하고 ― 상기 서버 디바이스는 라이브 스트리밍 서비스를 사용하여 상기 미디어 데이터를 제공함 ―;
    세그먼트 이용 가능성 윈도우의 좌측 에지 및 우측 에지를 결정하기 위하여 상기 복수의 프로브 요청들에 대한 응답들을 분석하게 하고;
    세그먼트가 실제로 이용 가능한 시간과 클라이언트 디바이스의 클럭이 상기 세그먼트가 이용 가능하다고 나타내는 시간 사이의 차이를 나타내는 시간 델타를 결정하게 하고; 그리고
    상기 시간 델타에 기초하여 상기 세그먼트들 중 하나 또는 그 초과의 세그먼트들을 요청하게 하는
    저장된 명령들을 갖고,
    상기 프로세서로 하여금, 상기 세그먼트들 중 하나 또는 그 초과의 세그먼트들을 요청하게 하는 명령들은, 상기 프로세서로 하여금, 상기 라이브 스트리밍 서비스에 따라, 상기 세그먼트 이용 가능성 윈도우의 결정된 좌측 에지 또는 결정된 우측 에지에 기초하여 세그먼트에 대한 요청을 전송하게 하는 명령들을 포함하는,
    컴퓨터-판독가능 스토리지 매체.
  55. 삭제
KR1020157023984A 2013-02-04 2013-12-31 네트워크 스트리밍에 대한 가변 미디어 데이터 결정 KR101704619B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201361760382P 2013-02-04 2013-02-04
US61/760,382 2013-02-04
US14/041,724 US9432426B2 (en) 2013-02-04 2013-09-30 Determining available media data for network streaming
US14/041,724 2013-09-30
PCT/US2013/078471 WO2014120377A1 (en) 2013-02-04 2013-12-31 Determining available media data for network streaming

Publications (2)

Publication Number Publication Date
KR20150114997A KR20150114997A (ko) 2015-10-13
KR101704619B1 true KR101704619B1 (ko) 2017-02-08

Family

ID=51260260

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020157023984A KR101704619B1 (ko) 2013-02-04 2013-12-31 네트워크 스트리밍에 대한 가변 미디어 데이터 결정

Country Status (6)

Country Link
US (1) US9432426B2 (ko)
EP (1) EP2952006B1 (ko)
JP (1) JP6240224B2 (ko)
KR (1) KR101704619B1 (ko)
CN (1) CN104969560B (ko)
WO (1) WO2014120377A1 (ko)

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6033541B2 (ja) * 2011-11-24 2016-11-30 シャープ株式会社 再生装置、再生方法、制御プログラム、および記録媒体
WO2014108207A1 (en) * 2013-01-11 2014-07-17 Telefonaktiebolaget L M Ericsson (Publ) Technique for operating client and server devices in a broadcast communication network
EP2954653B1 (en) * 2013-02-06 2018-11-28 Telefonaktiebolaget LM Ericsson (publ) Technique for detecting an encoder functionality issue
US9734194B1 (en) * 2013-03-14 2017-08-15 Google Inc. Encoding time interval information
US9215569B2 (en) * 2013-03-15 2015-12-15 Cellco Partnership Broadcast media content to subscriber group
US9438654B2 (en) * 2013-04-18 2016-09-06 Futurewei Technologies, Inc. Fragment interface into dynamic adaptive streaming over hypertext transfer protocol presentations
US9705955B2 (en) * 2013-04-18 2017-07-11 Futurewei Technologies, Inc. Period labeling in dynamic adaptive streaming over hypertext transfer protocol
US9973559B2 (en) 2013-05-29 2018-05-15 Avago Technologies General Ip (Singapore) Pte. Ltd. Systems and methods for presenting content streams to a client device
US20150095964A1 (en) * 2013-10-01 2015-04-02 Opentv, Inc. Bumper video carousel for digital video delivery
KR20150065289A (ko) * 2013-12-05 2015-06-15 삼성전자주식회사 데이터 재사용 방법 및 전자장치
KR102154800B1 (ko) * 2014-01-10 2020-09-10 삼성전자주식회사 전자 장치의 데이터 스트리밍 방법 및 그 전자 장치
JP2015136057A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
US20150256600A1 (en) * 2014-03-05 2015-09-10 Citrix Systems, Inc. Systems and methods for media format substitution
EP2924595A1 (en) * 2014-03-28 2015-09-30 Acast AB Method for associating media files with additional content
US9973345B2 (en) 2014-09-10 2018-05-15 Qualcomm Incorporated Calculating and signaling segment availability times for segments of media data
WO2016099354A1 (en) * 2014-12-18 2016-06-23 Telefonaktiebolaget Lm Ericsson (Publ) Request scheduling for streamed media
CN106572062B (zh) * 2015-10-10 2019-08-09 上海交通大学 一种异构媒体传输网络下的资源动态请求方法
WO2016124130A1 (zh) * 2015-02-06 2016-08-11 上海交通大学 一种异构网络传输下的动态时间窗口及缓存机制
CN106330751B (zh) * 2015-06-18 2019-07-26 上海交通大学 异构网络传输下的资源动态请求时间窗口及终端缓存方法
CN105991469B (zh) * 2015-02-06 2018-01-19 上海交通大学 一种异构网络传输下的动态时间窗口及缓存机制
CN106612453B (zh) * 2015-10-23 2019-11-15 上海交通大学 一种异构媒体网络传输下动态提供资源可获取时间的方法
DE102015001622A1 (de) * 2015-02-09 2016-08-11 Unify Gmbh & Co. Kg Verfahren zur Übertragung von Daten in einem Multimedia-System, sowie Softwareprodukt und Vorrichtung zur Steuerung der Übertragung von Daten in einem Multimedia-System
CN107810625B (zh) * 2015-06-30 2020-12-08 英国电讯有限公司 通过客户端从服务器流传输媒体序列的方法和装置
WO2017010720A1 (ko) * 2015-07-10 2017-01-19 (주) 프람트 데이터 구조화를 통한 직관적인 동영상콘텐츠 재생산 방법 및 이를 위한 사용자 인터페이스 장치
WO2017063189A1 (en) * 2015-10-16 2017-04-20 Qualcomm Incorporated Deadline signaling for streaming of media data
EP3384674A1 (en) * 2015-12-04 2018-10-10 Telefonaktiebolaget LM Ericsson (publ) Technique for adaptive streaming of temporally scaling media segment levels
KR20170093637A (ko) * 2016-02-05 2017-08-16 한국전자통신연구원 이종 네트워크 환경에서 미디어 전송 스트림 버퍼링 방법 및 이를 이용한 영상 수신 장치
US10382511B2 (en) * 2016-02-25 2019-08-13 Amp Me Inc. Synchronizing playback of digital media content
JP6247782B1 (ja) * 2017-02-15 2017-12-13 パナソニック株式会社 端末装置、映像配信システムおよび映像配信方法
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
EP3410728A1 (en) * 2017-05-30 2018-12-05 Vestel Elektronik Sanayi ve Ticaret A.S. Methods and apparatus for streaming data
US10972515B2 (en) * 2017-07-31 2021-04-06 Verizon Digital Media Services Inc. Server assisted live stream failover
US10715880B2 (en) * 2017-08-24 2020-07-14 Skitter, Inc. Method for creation and distribution of segmented video over distributed multicast-aware sparse networks with low latency
US10986001B2 (en) * 2018-01-25 2021-04-20 Nokia Solutions And Networks Oy System and method for quality of service detection of encrypted packet flows
US11039206B2 (en) 2018-04-09 2021-06-15 Hulu, LLC Differential media presentation descriptions for video streaming
CN110545492B (zh) * 2018-09-05 2020-07-31 北京开广信息技术有限公司 媒体流的实时递送方法及服务器
CN110958681B (zh) * 2018-09-27 2023-09-05 中兴通讯股份有限公司 业务传输方法及装置
US11379355B2 (en) * 2018-10-30 2022-07-05 Micron Technology, Inc. Power-on-time based data relocation
US20200204621A1 (en) * 2018-12-21 2020-06-25 York Telecom Corporation Management of live media connections
US11349764B2 (en) 2019-02-15 2022-05-31 Qualcomm Incorporated Methods and apparatus for signaling offset in a wireless communication system
US11172501B2 (en) 2019-09-05 2021-11-09 Qualcomm Incorporated Methods and apparatus for signaling offset in a wireless communication system
US11564018B2 (en) 2019-10-02 2023-01-24 Qualcomm Incorporated Random access at resync points of dash segments
KR20210065604A (ko) * 2019-11-27 2021-06-04 한국전자통신연구원 분산 네트워크 기반 멀티미디어 스트리밍 서비스에서 스트림을 선택하여 수신하는 방법 및 장치
US11570509B2 (en) * 2020-01-06 2023-01-31 Tencent America LLC Session-based information for dynamic adaptive streaming over HTTP
CN111221572B (zh) * 2020-01-13 2023-09-01 北京字节跳动网络技术有限公司 一种自动适配运行环境的方法、装置、介质和设备
US20210306703A1 (en) * 2020-03-25 2021-09-30 Qualcomm Incorporated Determination of availability of chunks of data for network streaming media data
US11546406B2 (en) * 2020-04-13 2023-01-03 Tencent America LLC Media systems and methods including mixed event message tracks
US11570246B1 (en) 2021-11-17 2023-01-31 Saudi Arabian Oil Company Layer 7 health check automated execution framework

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100049863A1 (en) 2006-10-31 2010-02-25 Heuer Joerg Method for synchronising scene data files and media data flows in an unidirectional broadcast system
US20140019587A1 (en) 2012-07-11 2014-01-16 Futurewei Technologies, Inc. Dynamic Adaptive Streaming over Hypertext Transfer Protocol as Hybrid Multirate Media Description, Delivery, and Storage Format

Family Cites Families (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7363361B2 (en) 2000-08-18 2008-04-22 Akamai Technologies, Inc. Secure content delivery system
US7720983B2 (en) 2004-05-03 2010-05-18 Microsoft Corporation Fast startup for streaming media
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US10007668B2 (en) * 2008-08-01 2018-06-26 Vantrix Corporation Method and system for triggering ingestion of remote content by a streaming server using uniform resource locator folder mapping
US8909806B2 (en) * 2009-03-16 2014-12-09 Microsoft Corporation Delivering cacheable streaming media presentations
US8621044B2 (en) * 2009-03-16 2013-12-31 Microsoft Corporation Smooth, stateless client media streaming
US8914835B2 (en) * 2009-10-28 2014-12-16 Qualcomm Incorporated Streaming encoded video data
US8849950B2 (en) 2011-04-07 2014-09-30 Qualcomm Incorporated Network streaming of video data using byte range requests
US8478890B2 (en) * 2011-07-15 2013-07-02 Damaka, Inc. System and method for reliable virtual bi-directional data stream communications with single socket point-to-multipoint capability
US9357275B2 (en) 2011-09-06 2016-05-31 Qualcomm Incorporated Network streaming of coded video data

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20100049863A1 (en) 2006-10-31 2010-02-25 Heuer Joerg Method for synchronising scene data files and media data flows in an unidirectional broadcast system
US20140019587A1 (en) 2012-07-11 2014-01-16 Futurewei Technologies, Inc. Dynamic Adaptive Streaming over Hypertext Transfer Protocol as Hybrid Multirate Media Description, Delivery, and Storage Format

Also Published As

Publication number Publication date
CN104969560A (zh) 2015-10-07
JP6240224B2 (ja) 2017-11-29
US20140222962A1 (en) 2014-08-07
CN104969560B (zh) 2018-07-17
EP2952006A1 (en) 2015-12-09
EP2952006B1 (en) 2017-08-23
WO2014120377A1 (en) 2014-08-07
US9432426B2 (en) 2016-08-30
KR20150114997A (ko) 2015-10-13
JP2016511575A (ja) 2016-04-14

Similar Documents

Publication Publication Date Title
KR101704619B1 (ko) 네트워크 스트리밍에 대한 가변 미디어 데이터 결정
KR102060851B1 (ko) Http 를 통한 동적 적응형 스트리밍 (dash) 을 위한 라이브 타이밍
US10666961B2 (en) Determining media delivery event locations for media transport
KR102469676B1 (ko) Lct에 기초한 dash 포맷들을 이용하는 파일 포맷 기반 스트리밍
US9973345B2 (en) Calculating and signaling segment availability times for segments of media data
TWI668982B (zh) 用於多媒體和檔案傳輸的傳輸介面的方法及伺服器設備、及用於記錄相關指令於其上的電腦可讀取儲存媒體
EP3095247B1 (en) Robust live operation of dash
KR20170116027A (ko) 저 레이턴시 비디오 스트리밍
JP2022551436A (ja) Ｄａｓｈセグメントの再同期点におけるランダムアクセス

Legal Events

Date Code Title Description
A201 Request for examination
A302 Request for accelerated examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant