KR20170089863A - 멀티미디어 및 파일 전송을 위한 전송 인터페이스 - Google Patents

멀티미디어 및 파일 전송을 위한 전송 인터페이스 Download PDF

Info

Publication number
KR20170089863A
KR20170089863A KR1020177014794A KR20177014794A KR20170089863A KR 20170089863 A KR20170089863 A KR 20170089863A KR 1020177014794 A KR1020177014794 A KR 1020177014794A KR 20177014794 A KR20177014794 A KR 20177014794A KR 20170089863 A KR20170089863 A KR 20170089863A
Authority
KR
South Korea
Prior art keywords
segment
data
media data
media
unit
Prior art date
Application number
KR1020177014794A
Other languages
English (en)
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 KR20170089863A publication Critical patent/KR20170089863A/ko

Links

Images

Classifications

    • H04L65/602—
    • H04L65/607—
    • H04L65/608—
    • 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/70—Media network packetisation
    • 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
    • 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/752—Media network packet handling adapting media to network capabilities
    • 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • 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/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/326—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the transport layer [OSI layer 4]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26216—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving the channel capacity, e.g. network bandwidth
    • 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/643—Communication protocols
    • H04N21/64322—IP
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • 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/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Landscapes

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

Abstract

미디어 데이터를 송신하기 위한 서버 디바이스는 제 1 유닛 및 제 2 유닛을 포함한다. 제 1 유닛은, 미디어 데이터에 대한 설명 정보를 서버 디바이스의 제 2 유닛에 전송하고 ―설명 정보는 미디어 데이터의 세그먼트 또는 세그먼트의 바이트 범위, 그리고 세그먼트 또는 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간을 표시함―, 미디어 데이터를 제 2 유닛에 전송하도록 구성된 하나 또는 그 초과의 프로세싱 유닛들을 포함한다. 이로써, 제 2 유닛은 설명 정보에 따라(예컨대, 가장 이른 시간 후에, 그리고/또는 가장 늦은 시간 전에) 세그먼트 또는 세그먼트의 바이트 범위를 전달한다.

Description

멀티미디어 및 파일 전송을 위한 전송 인터페이스{TRANSPORT INTERFACE FOR MULTIMEDIA AND FILE TRANSPORT}
[0001] 본 출원은, 2014년 12월 5일자로 출원된 미국 가출원 제 62/088,351호, 2015년 1월 13일자로 출원된 미국 가출원 제 62/102,930호, 및 2015년 8월 25일자로 출원된 미국 가출원 번호 제 62/209,620호에 대한 우선권을 주장하며, 이들 각각의 전체 내용들은 이로써 인용에 의해 통합된다.
[0002] 본 개시 내용은 미디어 데이터의 전송에 관한 것이다.
[0003] 디지털 비디오 능력들은 디지털 텔레비전들, 디지털 다이렉트 브로드캐스트 시스템들, 무선 브로드캐스트 시스템들, PDA(personal digital assistant)들, 랩톱 또는 데스크톱 컴퓨터들, 디지털 카메라들, 디지털 레코딩 디바이스들, 디지털 미디어 플레이어들, 비디오 게이밍 디바이스들, 비디오 게임 콘솔들, 셀룰러 또는 위성 라디오 텔레폰들, 비디오 텔레컨퍼런싱 디바이스들 등을 포함하는 넓은 범위의 디바이스들에 통합될 수 있다. 디지털 비디오 디바이스들은, 디지털 비디오 정보를 더욱 효율적으로 송신 및 수신하기 위해, 비디오 압축 기술들, 이를테면, MPEG-2, MPEG-4, ITU-T H.263 또는 ITU-T H.264/MPEG-4 파트 10, AVC(Advanced Video Coding), HEVC(High Efficiency Video Coding)/ITU-T H.265에 의해 정의되는 표준들 및 그러한 표준들의 확장들에서 설명되는 비디오 압축 기술들을 구현한다.
[0004] 비디오 압축 기술들은 비디오 시퀀스들에 내재하는 리던던시를 감소시키거나 또는 제거하기 위해 공간 예측 및/또는 시간 예측을 수행한다. 블록-기반 비디오 코딩의 경우, 비디오 프레임 또는 슬라이스는 매크로블록들로 파티셔닝될 수 있다. 각각의 매크로블록은 추가로 파티셔닝될 수 있다. 인트라-코딩되는(intra-coded)(I) 프레임 또는 슬라이스의 매크로블록들은, 이웃 매크로블록들에 대한 공간 예측을 사용하여 인코딩될 수 있다. 인터-코딩되는(inter-coded)(P 또는 B) 프레임 또는 슬라이스의 매크로블록들은, 동일한 프레임 또는 슬라이스의 이웃 매크로블록들에 대한 공간 예측 또는 다른 레퍼런스 프레임들에 대한 시간 예측을 사용할 수 있다. 프레임들 또는 프레임들의 그룹들 사이의 계층적 레퍼런스들이 사용될 수 있다.
[0005] 비디오 데이터가 인코딩된 후에, 이 비디오 데이터는 송신 또는 저장을 위해 패킷화될 수 있다. 미디어 데이터는 ISO(International Organization for Standardization) BMFF(base media file format) 및 그 확장들, 이를테면, AVC와 같은 다양한 표준들 중 임의의 표준에 따르는 파일로 어셈블링될 수 있다.
[0006] 일반적으로, 본 개시내용은 예컨대 네트워크를 통한 미디어 데이터의 전달에 관련된 기술들을 설명한다. 서버 디바이스는 통상적으로, 미디어 데이터의 전달에 수반되는 다양한 유닛들을 포함한다. 예컨대, 유닛들은 미디어 데이터를 패키징하기 위한 제 1 유닛, 및 패키징된 미디어 데이터를 전송하기 위한 제 2 유닛을 포함할 수 있다. 본 개시내용의 기술들은 더욱 구체적으로, 제 1 유닛이 미디어 데이터가 전달되어야 할 때를 표시하는 정보를 제 2 유닛에 제공하는 것에 관한 것이다.
[0007] 일 예에서, 미디어 데이터를 전송하는 방법은, 서버 디바이스의 제 1 유닛이, 미디어 데이터에 대한 설명(descriptive) 정보를 서버 디바이스의 제 2 유닛에 전송하는 단계 ―설명 정보는 미디어 데이터의 세그먼트 또는 세그먼트의 바이트 범위 중 적어도 하나, 그리고 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간 중 적어도 하나를 표시함―, 및 미디어 데이터를 제 2 유닛에 전송하는 단계를 포함한다.
[0008] 다른 예에서, 미디어 데이터를 전송하기 위한 서버 디바이스는 제 1 유닛 및 제 2 유닛을 포함한다. 제 1 유닛은, 미디어 데이터에 대한 설명 정보를 서버 디바이스의 제 2 유닛에 전송하고 ―설명 정보는 미디어 데이터의 세그먼트 또는 세그먼트의 바이트 범위, 그리고 세그먼트 또는 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간을 표시함―, 미디어 데이터를 제 2 유닛에 전송하도록 구성된 하나 또는 그 초과의 프로세싱 유닛들을 포함한다.
[0009] 다른 예에서, 미디어 데이터를 전송하기 위한 서버 디바이스는 제 1 유닛 및 제 2 유닛을 포함한다. 제 1 유닛은, 미디어 데이터에 대한 설명 정보를 서버 디바이스의 제 2 유닛에 전송하기 위한 수단 ―설명 정보는 미디어 데이터의 세그먼트 또는 세그먼트의 바이트 범위, 그리고 세그먼트 또는 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간을 표시함―; 및 미디어 데이터를 제 2 유닛에 전송하기 위한 수단을 포함한다.
[0010] 다른 예에서, 컴퓨터-판독가능 저장 매체는, 실행될 때, 서버 디바이스의 제 1 유닛의 프로세서로 하여금, 미디어 데이터에 대한 설명 정보를 서버 디바이스의 제 2 유닛에 전송하게 하고 ―설명 정보는 미디어 데이터의 세그먼트 또는 세그먼트의 바이트 범위 중 적어도 하나, 그리고 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간 중 적어도 하나를 표시함―; 그리고 미디어 데이터를 제 2 유닛에 전송하게 하는 명령들을 그 상에 저장한다.
[0011] 하나 또는 그 초과의 예들의 세부사항들은 첨부된 도면들 및 아래의 설명에서 제시된다. 다른 특징들, 목적들, 및 장점들은 설명 및 도면들로부터, 그리고 청구항들로부터 명백할 것이다.
[0012] 도 1은 네트워크를 통해 미디어 데이터를 스트리밍하기 위한 기술들을 구현하는 예시적 시스템을 예시하는 블록 다이어그램이다.
[0013] 도 2는 예시적 멀티미디어 콘텐츠의 엘리먼트들을 예시하는 개념적 다이어그램이다.
[0014] 도 3은 서버 디바이스(이를테면, 도 1의 서버 디바이스) 및 클라이언트 디바이스(이를테면, 도 1의 클라이언트 디바이스)의 예시적 컴포넌트들을 예시하는 블록 다이어그램이다.
[0015] 도 4는 데이터가 (도 3의 클라이언트 디바이스의) MAC(media access control)/PHY 계층에 수신되는 시간들과, 미디어 플레이어가 이 수신 데이터로부터 도출되는 미디어 데이터를 출력하는 시간들 사이의 차이들의 예들을 예시하는 개념적 다이어그램이다.
[0016] 도 5는 데이터가 (도 3의 클라이언트 디바이스의) MAC/Phy 계층에 수신되는 시간들, (도 3의 클라이언트 디바이스의) DASH 플레이어가 입력을 수신하는 시간들, 그리고 DASH 플레이어가 출력을 전달하는 시간들 사이의 차이들의 예들을 예시하는 개념적 다이어그램이다.
[0017] 도 6은 데이터 전달 이벤트(Data Delivery Event)들과 미디어 전달 이벤트(Media Delivery Event)들 사이의 대응의 예들을 예시하는 개념적 다이어그램이다.
[0018] 도 7은 MAC/PHY 데이터 전달 블록들을 예시하는 개념적 다이어그램이다.
[0019] 도 8은 송신 프로세스 및 수신 프로세스의 예를 예시하는 개념적 다이어그램이다.
[0020] 도 9a 및 도 9b는 본 개시내용의 기술들에 따라 미디어 데이터에 적용되는 FEC(forward error correction)의 예들을 예시한다.
[0021] 도 10은 다양한 세그먼트 전달 스타일들(A-D)을 예시하는 개념적 다이어그램이다.
[0022] 도 11은 실제 전송 버퍼 모델을 예시하는 개념적 다이어그램이다.
[0023] 도 12a 및 도 12b는 본 개시내용의 기술들을 MPEG-2 TS 모델과 대조하는 개념적 다이어그램들이다.
[0024] 도 13은 클라이언트 디바이스, 이를테면, 도 3의 클라이언트 디바이스 및/또는 도 1의 클라이언트 디바이스에 의해 구현될 수 있는 예시적 수신기 IP 스택의 블록 다이어그램이다.
[0025] 도 14는 일정한 지연 가정 및 블록 전달 기반 phy에 따라 구현되는 예시적 송신 시스템을 예시하는 개념적 다이어그램이다.
[0026] 도 15는 예시적 송신기 구성을 예시하는 블록 다이어그램이다.
[0027] 도 16은 스케줄링된 패킷 전달을 이용하는 시스템에서의 데이터에 대한 예시적 전달 모델을 예시하는 개념적 다이어그램이다.
[0028] 도 17은 송신 시스템에 대한 더 많은 세부사항들을 예시하는 개념적 다이어그램이다.
[0029] 도 18은 세그먼트 시간들의 스태거링(staggering)을 예시하는 개념적 다이어그램이다.
[0030] 도 19는 스트림이 선택적일 수 있는 미디어 데이터 및 필수인 미디어를 포함할 때 타겟 시간들과 가장 이른 시간들 사이의 차이들을 예시하는 개념적 다이어그램이다.
[0031] 도 20은 프레임들의 잠재적으로 드롭가능한(droppable) 그룹들을 갖는 비디오 시퀀스의 개념적 다이어그램이다.
[0032] 도 21은 본 개시내용의 기술들에 따른 다른 예시적 시스템을 예시하는 블록 다이어그램이다.
[0033] 도 22는 미디어 전달 이벤트들의 획득을 위한 예시적 기술을 예시하는 흐름도이다.
[0034] 도 23은 본 개시내용의 기술들에 따라 미디어 데이터를 전송하기 위한 예시적 방법을 예시하는 흐름도이다.
[0035] 일반적으로, 본 개시내용은 멀티미디어 및 파일 전달을 위한 전송 인터페이스 설계의 양상들에 관련된 기술들을 설명한다. 이들 기술들은 특히, 타이밍된(timed) 미디어 및/또는 파일 전달을 갖는 시스템들과 관련된다. 이는, 예컨대, 일정한 단대단(end-to-end) 지연을 통상적으로 가정했던 MPEG-2 시스템들의 MPEG-2 TS(Transport Stream)에 기반하는 시스템들에 대해 활용되는 역사적인 방법들로부터의 이탈이며, 이 일정한 단대단 지연은, 최첨단 기술(state-of-the-art) 전송 시스템들 및 그들의 관련된 PHY(physical) 계층/MAC(media access control)을 고려할 때 이번에는 훨씬 덜 관련된다.
[0036] 본 개시내용의 기술들은 ISO 베이스 미디어 파일 포맷, SVC(Scalable Video Coding) 파일 포맷, AVC(Advanced Video Coding) 파일 포맷, 3GPP(Third Generation Partnership Project) 파일 포맷, 및/또는 MVC(Multiview Video Coding) 파일 포맷, 또는 다른 유사한 비디오 파일 포맷들 중 임의의 파일 포맷에 따라 캡슐화된 비디오 데이터에 따르는 비디오 또는 다른 멀티미디어 및 메타데이터 파일들에 적용될 수 있다.
[0037] HTTP 스트리밍에서, 빈번히 사용되는 동작들은 HEAD, GET, 및 부분적 GET을 포함한다. HEAD 동작은, 주어진 URL(uniform resource locator) 또는 URN(uniform resource name)과 연관된 페이로드를 리트리빙(retrieving)하지 않고, 이 URL 또는 URN과 연관된 파일의 헤더를 리트리빙한다. GET 동작은 주어진 URL 또는 URN과 연관된 전체 파일을 리트리빙한다. 부분적 GET 동작은 바이트 범위를 입력 파라미터로서 수신하고, 파일의 연속적인 바이트들의 개수를 리트리빙하며, 여기서 바이트들의 개수는 수신된 바이트 범위에 대응한다. 따라서, HTTP 스트리밍의 경우 영화 프래그먼트(fragment)들이 제공될 수 있는데, 그 이유는 부분적 GET 동작이 하나 또는 그 초과의 개별 영화 프래그먼트들을 얻을 수 있기 때문이다. 영화 프래그먼트에서는, 상이한 트랙들의 몇몇 트랙 프래그먼트들이 있을 수 있다. HTTP 스트리밍에서, 미디어 프리젠테이션은 클라이언트가 액세싱할 수 있는 데이터의 구조화된 집합일 수 있다. 클라이언트는 스트리밍 서비스를 사용자에게 제시하기 위해 미디어 데이터 정보를 요청 및 다운로딩할 수 있다.
[0038] HTTP 스트리밍을 사용하여 3GPP 데이터를 스트리밍하는 예에서는, 멀티미디어 콘텐츠의 비디오 및/또는 오디오 데이터에 대한 다수의 표현들이 있을 수 있다. 아래에서 설명되는 바와 같이, 상이한 표현들은 상이한 코딩 특성들(예컨대, 비디오 코딩 표준의 상이한 프로파일들 또는 레벨들), 상이한 코딩 표준들 또는 코딩 표준들의 확장들(이를테면, 멀티뷰 및/또는 스케일러블(scalable) 확장들), 또는 상이한 비트레이트들에 대응할 수 있다. 그러한 표현들의 매니페스트는 DASH(Dynamic Adaptive Streaming over HTTP)의 MPD(Media Presentation Description) 데이터 구조에서 정의될 수 있다. 미디어 프리젠테이션은 HTTP 스트리밍 클라이언트 디바이스가 액세싱할 수 있는 데이터의 구조화된 집합에 대응할 수 있다. HTTP 스트리밍 클라이언트 디바이스는 스트리밍 서비스를 클라이언트 디바이스의 사용자에게 제시하기 위해 미디어 데이터 정보를 요청 및 다운로딩할 수 있다. 미디어 프리젠테이션은 MPD 데이터 구조에서 설명될 수 있으며, 이 MPD 데이터 구조는 MPD의 업데이트들을 포함할 수 있다.
[0039] 미디어 프리젠테이션은 하나 또는 그 초과의 기간들의 시퀀스를 포함할 수 있다. 기간들은 MPD의 기간 엘리먼트에 의해 정의될 수 있다. 각각의 기간은 MPD에서 속성 시작을 가질 수 있다. MPD는 각각의 기간에 대해 시작 속성 및 availabilityStartTime 속성을 포함할 수 있다. 라이브 서비스들의 경우, 기간의 시작 속성과 MPD 속성 availabilityStartTime의 합은, 특히, 대응하는 기간의 각각의 표현의 제 1 미디어 세그먼트에 대해, NTP(network time protocol) 64 포맷으로 기간의 가용성 시간을 특정할 수 있다. 온-디맨드 서비스들의 경우, 제 1 기간의 시작 속성은 0일 수 있다. 임의의 다른 기간의 경우, 시작 속성은 제 1 기간의 시작 시간에 관련하여 대응하는 기간의 시작 시간 사이의 시간 오프셋을 특정할 수 있다. 각각의 기간은 다음 차례의 기간의 시작 때까지, 또는 마지막 기간의 경우, 미디어 프리젠테이션의 종료 때까지 연장될 수 있다. 기간 시작 시간들은 정밀할 수 있다. 그들은 모든 이전 기간들의 미디어를 플레잉하는 것으로부터 도출되는 실제 타이밍을 반영할 수 있다.
[0040] 각각의 기간은 동일한 미디어 콘텐츠에 대한 하나 또는 그 초과의 표현들을 포함할 수 있다. 표현은 오디오 또는 비디오 데이터의 다수의 대안적인 인코딩된 버전들 중 하나일 수 있다. 표현들은 인코딩 타입들에 의해, 예컨대, 비트레이트, 분해능, 및/또는 비디오 데이터에 대한 코덱 및 비트레이트, 언어, 및/또는 오디오 데이터에 대한 코덱에 의해 상이할 수 있다. 표현이란 용어는, 멀티미디어 콘텐츠의 특정 기간에 대응하는 인코딩된 오디오 또는 비디오 데이터의 섹션을 지칭하기 위해 사용되며, 특정 방식으로 인코딩될 수 있다.
[0041] 특정 기간의 표현들은 이 표현들이 속하는 적응 세트를 표시하는 MPD의 속성에 의해 표시되는 그룹에 할당될 수 있다. 동일한 적응 세트의 표현들은 일반적으로, 예컨대 대역폭 적응을 수행하기 위해, 클라이언트 디바이스가 이들 표현들 사이에서 동적으로 그리고 매끄럽게(seamlessly) 스위칭할 수 있다는 점에서, 서로에 대한 대안들로 간주된다. 예컨대, 특정 기간에 대한 비디오 데이터의 각각의 표현은 동일한 적응 세트에 할당될 수 있으며, 따라서 표현들 중 임의의 표현이, 대응하는 기간에 대한 멀티미디어 콘텐츠의 미디어 데이터, 이를테면, 비디오 데이터 또는 오디오 데이터를 제시하기 위한 디코딩을 위해 선택될 수 있다. 하나의 기간 내의 미디어 콘텐츠는, 존재한다면 그룹 0으로부터의 하나의 표현, 또는 일부 예들에서 각각의 넌-제로(non-zero) 그룹으로부터의 기껏해야 하나의 표현의 조합에 의해 표현될 수 있다. 기간의 각각의 표현에 대한 타이밍 데이터는 이 기간의 시작 시간에 관련하여 표현될 수 있다.
[0042] 표현은 하나 또는 그 초과의 세그먼트들을 포함할 수 있다. 각각의 표현은 초기화 세그먼트를 포함할 수 있거나, 또는 표현의 각각의 세그먼트는 자체-초기화일 수 있다. 존재하는 경우, 초기화 세그먼트는 표현에 액세싱하기 위한 초기화 정보를 포함할 수 있다. 일반적으로, 초기화 세그먼트는 미디어 데이터를 포함하지 않는다. 세그먼트는 식별자, 이를테면, URL(uniform resource locator), URN(uniform resource name), 또는 URI(uniform resource identifier)에 의해 고유하게 레퍼런싱될 수 있다. MPD는 각각의 세그먼트에 대한 식별자들을 제공할 수 있다. 일부 예들에서, MPD는 또한, 바이트 범위들을 범위 속성의 형태로 제공할 수 있으며, 이 범위 속성은 URL, URN, 또는 URI가 액세싱할 수 있는 파일 내의 세그먼트에 대한 데이터에 대응할 수 있다.
[0043] 상이한 타입들의 미디어 데이터에 대한 실질적으로 동시적인 리트리벌(retrieval)을 위해, 상이한 표현들이 선택될 수 있다. 예컨대, 클라이언트 디바이스는 세그먼트들을 리트리빙하기 위한 오디오 표현, 비디오 표현, 및 타이밍된 텍스트 표현을 선택할 수 있다. 일부 예들에서, 클라이언트 디바이스는 대역폭 적응을 수행하기 위해 특정 적응 세트들을 선택할 수 있다. 즉, 클라이언트 디바이스는 비디오 표현들을 포함하는 적응 세트, 오디오 표현들을 포함하는 적응 세트, 및/또는 타이밍된 텍스트를 포함하는 적응 세트를 선택할 수 있다. 대안적으로, 클라이언트 디바이스는 특정 타입들의 미디어(예컨대, 비디오)에 대한 적응 세트들을 선택하며, 다른 타입들의 미디어(예컨대, 오디오 및/또는 타이밍된 텍스트)에 대한 표현들을 직접적으로 선택할 수 있다.
[0044] 도 1은 네트워크를 통해 미디어 데이터를 스트리밍하기 위한 기술들을 구현하는 예시적 시스템(10)을 예시하는 블록 다이어그램이다. 이 예에서, 시스템(10)은 콘텐츠 준비 디바이스(20), 서버 디바이스(60), 및 클라이언트 디바이스(40)를 포함한다. 클라이언트 디바이스(40) 및 서버 디바이스(60)는 네트워크(74)에 의해 통신가능하게 커플링되며, 이 네트워크(74)는 인터넷을 포함할 수 있다. 일부 예들에서, 콘텐츠 준비 디바이스(20) 및 서버 디바이스(60)는 또한, 네트워크(74) 또는 다른 네트워크에 의해 커플링될 수 있거나, 또는 직접적으로 통신가능하게 커플링될 수 있다. 일부 예들에서, 콘텐츠 준비 디바이스(20) 및 서버 디바이스(60)는 동일한 디바이스를 포함할 수 있다.
[0045] 도 1의 예에서, 콘텐츠 준비 디바이스(20)는 오디오 소스(22) 및 비디오 소스(24)를 포함한다. 오디오 소스(22)는 예컨대 마이크로폰을 포함할 수 있으며, 이 마이크로폰은 오디오 인코더(26)에 의해 인코딩될, 캡처링된 오디오 데이터를 표현하는 전기 신호들을 생성한다. 대안적으로, 오디오 소스(22)는 앞서 레코딩된 오디오 데이터를 저장하는 저장 매체, 컴퓨터 신시사이저와 같은 오디오 데이터 생성기, 또는 오디오 데이터의 임의의 다른 소스를 포함할 수 있다. 비디오 소스(24)는 비디오 인코더(28)에 의해 인코딩될 비디오 데이터를 생성하는 비디오 카메라, 앞서 레코딩된 비디오 데이터로 인코딩된 저장 매체, 컴퓨터 그래픽스 소스와 같은 비디오 데이터 생성 유닛, 또는 비디오 데이터의 임의의 다른 소스를 포함할 수 있다. 콘텐츠 준비 디바이스(20)가 반드시 모든 예들에서 서버 디바이스(60)에 통신가능하게 커플링되는 것이 아니라, 서버 디바이스(60)가 판독하는 별개의 매체에 멀티미디어 콘텐츠를 저장할 수 있다.
[0046] 미가공 오디오 및 비디오 데이터는 아날로그 또는 디지털 데이터를 포함할 수 있다. 아날로그 데이터는, 오디오 인코더(26) 및/또는 비디오 인코더(28)에 의해 인코딩되기 전에 디지털화될 수 있다. 오디오 소스(22)는 말하기 참가자가 말하고 있는 동안 말하기 참가자로부터 오디오 데이터를 획득할 수 있으며, 비디오 소스(24)는 말하기 참가자의 비디오 데이터를 동시에 획득할 수 있다. 다른 예들에서, 오디오 소스(22)는 저장된 오디오 데이터를 포함하는 컴퓨터-판독가능 저장 매체를 포함할 수 있으며, 비디오 소스(24)는 저장된 비디오 데이터를 포함하는 컴퓨터-판독가능 저장 매체를 포함할 수 있다. 이러한 방식으로, 본 개시내용에서 설명되는 기술들은 라이브, 스트리밍, 실시간 오디오 및 비디오 데이터에, 또는 아카이빙된, 미리 레코딩된 오디오 및 비디오 데이터에 적용될 수 있다.
[0047] 비디오 프레임들에 대응하는 오디오 프레임들은 일반적으로, 이 비디오 프레임들 내에 포함되는, 비디오 소스(24)에 의해 캡처링(또는 생성)된 비디오 데이터와 동시에 오디오 소스(22)에 의해 캡처링(또는 생성)된 오디오 데이터를 포함하는 오디오 프레임들이다. 예컨대, 말하기 참가자가 일반적으로 말함으로써 오디오 데이터를 생성하는 동안, 오디오 소스(22)는 오디오 데이터를 캡처링하며, 동시에, 즉, 오디오 소스(22)가 오디오 데이터를 캡처링하고 있는 동안, 비디오 소스(24)는 말하기 참가자의 비디오 데이터를 캡처링한다. 따라서, 오디오 프레임은 하나 또는 그 초과의 특정 비디오 프레임들에 시간적으로 대응할 수 있다. 이에 따라, 비디오 프레임에 대응하는 오디오 프레임은 일반적으로, 오디오 데이터 및 비디오 데이터가 동시에 캡처링되었으며 오디오 프레임 및 비디오 프레임이 동시에 캡처링된 오디오 데이터 및 비디오 데이터를 각각 포함하는 상황에 대응한다.
[0048] 일부 예들에서, 오디오 인코더(26)는 인코딩되는 오디오 프레임에 대한 오디오 데이터가 레코딩된 시간을 표현하는 타임스탬프를 각각의 인코딩되는 오디오 프레임에 인코딩할 수 있으며, 유사하게, 비디오 인코더(28)는 인코딩되는 비디오 프레임에 대한 비디오 데이터가 레코딩된 시간을 표현하는 타임스탬프를 각각의 인코딩되는 비디오 프레임에 인코딩할 수 있다. 그러한 예들에서, 비디오 프레임에 대응하는 오디오 프레임은 타임스탬프를 포함하는 오디오 프레임 및 동일한 타임스탬프를 포함하는 비디오 프레임을 포함할 수 있다. 콘텐츠 준비 디바이스(20)는 내부 클록을 포함할 수 있으며, 오디오 인코더(26) 및/또는 비디오 인코더(28)가 이 내부 클록으로부터 타임스탬프들을 생성할 수 있거나, 또는 오디오 소스(22) 및 비디오 소스(24)가 이 내부 클록을 사용하여 오디오 및 비디오 데이터를 타임스탬프와 각각 연관시킬 수 있다.
[0049] 일부 예들에서, 오디오 소스(22)는 오디오 데이터가 레코딩된 시간에 대응하는 데이터를 오디오 인코더(26)에 전송할 수 있으며, 비디오 소스(24)는 비디오 데이터가 레코딩된 시간에 대응하는 데이터를 비디오 인코더(28)에 전송할 수 있다. 일부 예들에서, 오디오 인코더(26)는 인코딩되는 오디오 데이터의 상대적 시간 순서화를 표시하기 위한 시퀀스 식별자(그러나, 반드시 오디오 데이터가 레코딩된 절대 시간을 표시하는 것은 아님)를 인코딩되는 오디오 프레임에 인코딩할 수 있으며, 유사하게, 비디오 인코더(28)는 또한, 인코딩되는 비디오 데이터의 상대적 시간 순서화를 표시하기 위한 시퀀스 식별자들을 사용할 수 있다. 유사하게, 일부 예들에서, 시퀀스 식별자는 타임스탬프에 맵핑되거나 또는 다른 방식으로 타임스탬프와 상관될 수 있다.
[0050] 오디오 인코더(26)가 일반적으로, 인코딩된 오디오 데이터의 스트림을 생성하는 반면에, 비디오 인코더(28)는 인코딩된 비디오 데이터의 스트림을 생성한다. 데이터(오디오이든 또는 비디오이든)의 각각의 개별 스트림은 기본 스트림, 또는 전달되고 있는 다수의 오브젝트들로부터의 프래그먼트들의 집합으로 지칭될 수 있다. 기본 스트림은 표현의 디지털식으로 코딩된(어쩌면, 압축된) 단일 컴포넌트이다. 예컨대, 표현의 코딩된 비디오 또는 오디오 파트는 기본 스트림일 수 있다. 기본 스트림은, 비디오 파일 내에 캡슐화되기 전에, PES(Packetized Elementary Stream)로 변환될 수 있다. 동일한 표현 내에서, 하나의 기본 스트림에 속하는 PES-패킷들을 다른 기본 스트림으로부터 구별하기 위해 스트림 ID가 사용될 수 있다. 기본 스트림의 데이터의 기본 단위는 PES(packetized elementary stream) 패킷이다. 따라서, 코딩된 비디오 데이터는 일반적으로, 기본 비디오 스트림들에 대응한다. 유사하게, 오디오 데이터는 하나 또는 그 초과의 개개의 기본 스트림들에 대응한다. 일부 예들에서, 예컨대, ROUTE(Real-Time Object Delivery over Unidirectional Transport) 프로토콜에 따라, 미디어 오브젝트들은 기본 스트림과 기능에 있어서 유사한 방식으로 스트리밍될 수 있다. 이는 또한, 점진적 다운로드 및 재생을 닮는다. ROUTE 세션은 하나 또는 그 초과의 LCT(Layered Coding Transport) 세션들을 포함할 수 있다. LCT는 Luby 등에 의한 "Layered Coding Transport (LCT) Building Block"(RFC 5651, October 2009)에서 설명된다.
[0051] 많은 비디오 코딩 표준들, 이를테면, ITU-T H.264/AVC 및 HEVC(High Efficiency Video Coding) 표준(ITU-T H.265로 또한 지칭됨)은 구문, 의미론, 및 무-오류 비트스트림들을 위한 디코딩 프로세스를 정의하며, 이들 중 어떤 것은 특정 프로파일 또는 레벨에 따른다. 비디오 코딩 표준들은 통상적으로, 인코더를 특정하지 않지만, 인코더는 생성되는 비트스트림들이 디코더에 대한 표준을 준수한다는 것을 보장하는 임무를 갖는다. 비디오 코딩 표준들의 맥락에서, "프로파일"은 이 비디오 코딩 표준들에 적용되는 알고리즘들, 특징들, 또는 도구들 및 제약들의 서브세트에 대응한다. 예컨대, H.264 표준에 의해 정의된 바와 같이, "프로파일"은 H.264 표준에 의해 특정되는 전체 비트스트림 구문의 서브세트이다. "레벨"은 디코더 자원 소비, 이를테면, 예컨대, 픽처들의 분해능, 비트 레이트, 및 블록 프로세싱 레이트에 관련되는 디코더 메모리 및 계산의 제한들에 대응한다. 프로파일이 profile_idc(프로파일 표시자) 값으로 시그널링될 수 있는 반면에, 레벨은 level_idc(레벨 표시자) 값으로 시그널링될 수 있다.
[0052] 예컨대, H.264 표준은, 주어진 프로파일의 구문에 의해 부과되는 바운드들 내에서, 비트스트림의 구문 엘리먼트들에 의해 취해진 값들, 이를테면, 디코딩된 픽처들의 특정된 사이즈에 따라 인코더들 및 디코더들의 성능에서 큰 변동을 요구하는 것이 여전히 가능하다는 것을 인식한다. H.264 표준은, 많은 애플리케이션들에서, 특정 프로파일 내의 구문의 모든 가설 용도들을 다룰 수 있는 디코더를 구현하는 것은 현실적이지도 경제적이지도 않다는 것을 추가로 인식한다. 이에 따라, H.264 표준은 "레벨"을 비트스트림의 구문 엘리먼트들의 값들에 부과되는 제약들의 특정된 세트로서 정의한다. 이들 제약들은 값들에 대한 단순한 제한치들일 수 있다. 대안적으로, 이들 제약들은 값들의 산술 조합들(예컨대, 픽처 폭 × 픽처 높이 × 초당 디코딩되는 픽처들의 개수)에 대한 제약들의 형태를 취할 수 있다. H.264 표준은, 개별 구현들이 각각의 지원되는 프로파일에 대해 상이한 레벨을 지원할 수 있다는 것을 추가로 제공한다.
[0053] 프로파일에 따르는 디코더는 대개는, 프로파일에서 정의된 특징들 전부를 지원한다. 예컨대, 코딩 특징으로서, B-픽처 코딩은 H.264/AVC의 베이스라인 프로파일에서 지원되지 않지만, H.264/AVC의 다른 프로파일들에서 지원된다. 일 레벨에 따르는 디코더는, 이 레벨에서 정의된 제한들을 넘어서 자원들을 요구하지 않는 임의의 비트스트림을 디코딩할 수 있어야 한다. 프로파일들 및 레벨들의 정의들은 영상해석능력(interpretability)에 도움이 될 수 있다. 예컨대, 비디오 송신 동안, 전체 송신 세션에 대해 한 쌍의 프로파일 및 레벨 정의들이 협상 및 합의될 수 있다. 더욱 구체적으로, H.264/AVC에서, 레벨은, 프로세싱될 필요가 있는 매크로블록들의 개수, DPB(Decoded Picture Buffer) 사이즈, CPB(Coded Picture Buffer) 사이즈, 수직 모션 벡터 범위, 두 개의 연속적인 MB들마다의 모션 벡터들의 최대 개수, 그리고 B-블록이 8x8 픽셀들 미만의 서브-매크로블록 파티션들을 가질 수 있는지의 여부에 대한 제한들을 정의할 수 있다. 이러한 방식으로, 디코더는, 이 디코더가 비트스트림을 적절하게 디코딩할 수 있는지의 여부를 결정할 수 있다.
[0054] 도 1의 예에서, 콘텐츠 준비 디바이스(20)의 캡슐화 유닛(30)은 비디오 인코더(28)로부터의 코딩된 비디오 데이터를 포함하는 기본 스트림들, 및 오디오 인코더(26)로부터의 코딩된 오디오 데이터를 포함하는 기본 스트림들을 수신한다. 일부 예들에서, 비디오 인코더(28) 및 오디오 인코더(26)는 각각, 인코딩된 데이터로부터 PES 패킷들을 형성하기 위한 패킷화기(packetizer)들을 포함할 수 있다. 다른 예들에서, 비디오 인코더(28) 및 오디오 인코더(26)는 각각, 인코딩된 데이터로부터 PES 패킷들을 형성하기 위한 개개의 패킷화기들과 인터페이싱할 수 있다. 또 다른 예들에서, 캡슐화 유닛(30)은 인코딩된 오디오 및 비디오 데이터로부터 PES 패킷들을 형성하기 위한 패킷화기들을 포함할 수 있다.
[0055] 비디오 인코더(28)는, 다양한 비트레이트들로, 그리고 다양한 특성들, 이를테면, 픽셀 분해능들, 프레임 레이트들, 다양한 코딩 표준들에 대한 일치(conformance), 다양한 코딩 표준들에 대한 다양한 프로파일들 및/또는 프로파일들의 레벨들에 대한 일치, 하나의 또는 다수(예컨대, 이차원 또는 삼차원 재생의 경우)의 뷰들을 갖는 표현들, 또는 다른 그러한 특성들을 갖게 멀티미디어 콘텐츠의 상이한 표현들을 생성하기 위해, 다양한 방식들로 멀티미디어 콘텐츠의 비디오 데이터를 인코딩할 수 있다. 본 개시내용에서 사용되는 표현은, 오디오 데이터, 비디오 데이터, 텍스트 데이터(예컨대, 폐쇄 자막들의 경우), 또는 다른 그러한 데이터 중 하나를 포함할 수 있다. 표현은 기본 스트림, 이를테면, 오디오 기본 스트림 또는 비디오 기본 스트림을 포함할 수 있다. 각각의 PES 패킷은, PES 패킷이 속하는 기본 스트림을 식별하는 stream_id를 포함할 수 있다. 캡슐화 유닛(30)은 기본 스트림들을 다양한 표현들의 비디오 파일들(예컨대, 세그먼트들)로 어셈블링하는 것을 책임진다.
[0056] 캡슐화 유닛(30)은 오디오 인코더(26) 및 비디오 인코더(28)로부터 표현의 기본 스트림들에 대한 PES 패킷들을 수신하며, 이 PES 패킷들로부터 대응하는 NAL(Network Abstraction Layer) 유닛들을 형성한다. H.264/AVC(Advanced Video Coding)의 예에서, 코딩된 비디오 세그먼트들은 NAL 유닛들로 조직화되며, 이 NAL 유닛들은 "네트워크-친화적"인 비디오 표현 어드레싱 애플리케이션들, 이를테면, 비디오 텔레포니, 저장, 브로드캐스트, 또는 스트리밍을 제공한다. NAL 유닛들은 VCL(Video Coding Layer) NAL 유닛들 및 비-VCL NAL 유닛들로 카테고리화될 수 있다. VCL 유닛들은 코어 압축 엔진을 포함할 수 있으며, 블록, 매크로블록, 및/또는 슬라이스 레벨 데이터를 포함할 수 있다. 다른 NAL 유닛들은 비-VCL NAL 유닛들일 수 있다. 일부 예들에서, 일차 코딩된 픽처로서 보통 제시되는, 하나의 시간 인스턴스(one time instance)에서의 코딩된 픽처는 액세스 유닛에 포함될 수 있으며, 이 액세스 유닛은 하나 또는 그 초과의 NAL 유닛들을 포함할 수 있다.
[0057] 비-VCL NAL 유닛들은 그 중에서도 파라미터 세트 NAL 유닛들 및 SEI(Supplemental Enhancement Information) NAL 유닛들을 포함할 수 있다. 파라미터 세트들은 시퀀스-레벨 헤더 정보(SPS(Sequence Parameter Set)들 내에 있음) 및 드물게 변하는 픽처-레벨 헤더 정보(PPS(Picture Parameter Set)들 내에 있음)를 포함할 수 있다. 파라미터 세트들(예컨대, PPS 및 SPS)에 대해, 드물게 변하는 정보는 각각의 시퀀스 또는 픽처에 대해 반복될 필요가 없으며, 따라서 코딩 효율성이 개선될 수 있다. 또한, 파라미터 세트들의 사용은 중요한 헤더 정보의 대역외(out-of-band) 송신을 가능하게 하며, 이는 오류 탄력성을 위한 중복적 송신들에 대한 필요를 회피할 수 있다. 대역외 송신 예들에서, 파라미터 세트 NAL 유닛들은 다른 NAL유닛들, 이를테면, SEI NAL 유닛들과는 상이한 채널 상에서 송신될 수 있다.
[0058] SEI NAL 유닛들은 VCL NAL 유닛들로부터의 코딩된 픽처 샘플들을 디코딩하기 위해 필요하지 않은 정보를 포함할 수 있지만, 디코딩, 디스플레이, 오류 탄력성, 및 다른 목적들에 관련된 프로세스들을 보조할 수 있다. SEI 메시지들은 비-VCL NAL 유닛들에 포함될 수 있다. SEI 메시지들은 일부 표준 사양들의 규범적 파트이며, 따라서 표준 준수 디코더 구현을 위해 항상 필수인 것은 아니다. SEI 메시지들은 시퀀스 레벨 SEI 메시지들 또는 픽처 레벨 SEI 메시지들일 수 있다. 어떤 시퀀스 레벨 정보는 SEI 메시지들, 이를테면, SVC의 예에서 확장성 정보 SEI 메시지들 및 MVC에서 뷰 확장성 정보 SEI 메시지들에 포함될 수 있다. 이들 예시적 SEI 메시지들은 예컨대 동작 지점들 및 이 동작 지점들의 특성들의 추출에 관한 정보를 운반할 수 있다. 부가하여, 캡슐화 유닛(30)은 매니페스트 파일, 이를테면, 표현들의 특성들을 설명하는 MPD(media presentation description)를 형성할 수 있다. 캡슐화 유닛(30)은 XML(Extensible Markup Language)에 따라 MPD를 포맷팅할 수 있다.
[0059] 캡슐화 유닛(30)은 매니페스트 파일(예컨대, MPD)과 함께 멀티미디어 콘텐츠의 하나 또는 그 초과의 표현들에 대한 데이터를 출력 인터페이스(32)에 제공할 수 있다. 출력 인터페이스(32)는 네트워크 인터페이스 또는 저장 매체에 기록하기 위한 인터페이스, 이를테면, USB(Universal Serial Bus) 인터페이스, CD, DVD, 블루레이 라이터(Blu-Ray writer), 버너 또는 스탬퍼, 자기 또는 플래시 저장 매체에 대한 인터페이스, 또는 미디어 데이터를 저장하거나 또는 송신하기 위한 다른 인터페이스들을 포함할 수 있다. 캡슐화 유닛(30)은 멀티미디어 콘텐츠의 표현들 각각의 데이터를 출력 인터페이스(32)에 제공할 수 있으며, 이 출력 인터페이스(32)는 데이터를 네트워크 송신 또는 저장 매체를 통해 서버 디바이스(60)에 전송할 수 있다. 도 1의 예에서, 서버 디바이스(60)는 다양한 멀티미디어 콘텐츠들(64)을 저장하는 저장 매체(62)를 포함하며, 이 멀티미디어 콘텐츠들(64) 각각은 개개의 매니페스트 파일(66) 및 하나 또는 그 초과의 표현들(68A-68N)(표현들(68))을 포함한다. 일부 예들에서, 출력 인터페이스(32)는 또한, 데이터를 네트워크(74)에 직접적으로 전송할 수 있다.
[0060] 일부 예들에서, 표현들(68)은 적응 세트들로 분리될 수 있다. 즉, 표현들(68)의 다양한 서브세트들은 특성들, 이를테면, 코덱, 프로파일 및 레벨, 분해능, 뷰들의 개수, 세그먼트들에 대한 파일 포맷, 언어를 식별할 수 있는 텍스트 타입 정보 또는 예컨대 스피커들에 의해 디코딩 및 제시될 표현 및/또는 오디오 데이터와 함께 디스플레잉될 텍스트의 다른 특성들, 적응 세트의 표현들에 대한 장면(scene)의 카메라 각도 또는 실세계 카메라 관점을 설명할 수 있는 카메라 각도 정보, 특정 청중들에 대한 콘텐츠 적합성을 설명하는 등급 정보 등의 개개의 공통 세트들을 포함할 수 있다.
[0061] 매니페스트 파일(66)은 특정 적응 세트들, 뿐만 아니라 이 적응 세트들의 공통 특성들에 대응하는 표현들(68)의 서브세트들을 표시하는 데이터를 포함할 수 있다. 매니페스트 파일(66)은 또한, 적응 세트들의 개별 표현들에 대해, 개별 특성들, 이를테면, 비트레이트들을 표현하는 데이터를 포함할 수 있다. 이러한 방식으로, 적응 세트는 단순화된 네트워크 대역폭 적응을 제공할 수 있다. 적응 세트의 표현들은, 매니페스트 파일(66)의 적응 세트 엘리먼트의 자식 엘리먼트들을 사용하여 표시될 수 있다.
[0062] 서버 디바이스(60)는 요청 프로세싱 유닛(70) 및 네트워크 인터페이스(72)를 포함한다. 일부 예들에서, 서버 디바이스(60)는 복수의 네트워크 인터페이스들을 포함할 수 있다. 또한, 서버 디바이스(60)의 특징들 중 임의의 특징 또는 특징들 전부는 콘텐츠 전달 네트워크의 다른 디바이스들, 이를테면, 라우터들, 브릿지들, 프록시 디바이스들, 스위치들, 또는 다른 디바이스들 상에 구현될 수 있다. 일부 예들에서, 콘텐츠 전달 네트워크의 중간 디바이스들은 멀티미디어 콘텐츠(64)의 데이터를 캐싱(caching)하며, 서버 디바이스(60)의 컴포넌트들에 실질적으로 따르는 컴포넌트들을 포함할 수 있다. 일반적으로, 네트워크 인터페이스(72)는 네트워크(74)를 통해 데이터를 전송 및 수신하도록 구성된다.
[0063] 요청 프로세싱 유닛(70)은, 저장 매체(62)의 데이터에 대해, 클라이언트 디바이스들, 이를테면, 클라이언트 디바이스(40)로부터 네트워크 요청들을 수신하도록 구성된다. 예컨대, 요청 프로세싱 유닛(70)은 R. Fielding 등에 의해 RFC 2616 "Hypertext Transfer Protocol - HTTP/1.1"(Network Working Group, IETF, June 1999)에서 설명된 HTTP(hypertext transfer protocol) 버전 1.1을 구현할 수 있다. 즉, 요청 프로세싱 유닛(70)은, HTTP GET 또는 부분적 GET 요청들을 수신하고, 요청들에 대한 응답으로, 멀티미디어 콘텐츠(64)의 데이터를 제공하도록 구성될 수 있다. 요청들은 예컨대, 세그먼트의 URL을 사용하여 표현들(68) 중 하나의 표현의 세그먼트를 특정할 수 있다. 일부 예들에서, 요청들은 또한, 세그먼트의 하나 또는 그 초과의 바이트 범위들을 특정하며, 따라서 부분적 GET 요청들을 포함할 수 있다. 요청 프로세싱 유닛(70)은, 표현들(68) 중 하나의 표현의 세그먼트의 헤더 데이터를 제공하기 위해 HTTP HEAD 요청들에 서비싱하도록 추가로 구성될 수 있다. 어느 경우이든, 요청 프로세싱 유닛(70)은, 요청된 데이터를 요청 디바이스, 이를테면, 클라이언트 디바이스(40)에 제공하기 위해 요청들을 프로세싱하도록 구성될 수 있다.
[0064] 부가적으로 또는 대안적으로, 요청 프로세싱 유닛(70)은, 브로드캐스트 또는 멀티캐스트 프로토콜, 이를테면, eMBMS를 통해 미디어 데이터를 전달하도록 구성될 수 있다. 콘텐츠 준비 디바이스(20)는 설명된 것과 실질적으로 동일한 방식으로 DASH 세그먼트들 및/또는 서브-세그먼트들을 생성할 수 있지만, 서버 디바이스(60)는 eMBMS 또는 다른 브로드캐스트 또는 멀티캐스트 네트워크 전송 프로토콜을 사용하여 이들 세그먼트들 또는 서브-세그먼트들을 전달할 수 있다. 예컨대, 요청 프로세싱 유닛(70)은 클라이언트 디바이스(40)로부터 멀티캐스트 그룹 가입 요청을 수신하도록 구성될 수 있다. 즉, 서버 디바이스(60)는 멀티캐스트 그룹과 연관된 IP(Internet protocol) 어드레스를, 특정 미디어 콘텐츠(예컨대, 라이브 이벤트의 브로드캐스트)와 연관된 클라이언트 디바이스(40)를 비롯한 클라이언트 디바이스들에 광고할 수 있다. 이번에는, 클라이언트 디바이스(40)는 멀티캐스트 그룹에 가입하기 위한 요청을 제출할 수 있다. 이 요청은 네트워크(74), 예컨대, 네트워크(74)를 형성하는 라우터들 전체에 걸쳐 전파될 수 있으며, 따라서 라우터들은, 멀티캐스트 그룹과 연관된 IP 어드레스를 목적지로 하는 트래픽을 가입 클라이언트 디바이스들, 이를테면, 클라이언트 디바이스(40)에 지향시키게 된다. DASH는 예컨대, INTERNATIONAL STANDARD ISO/IEC 23009-1 Second edition 2014-05-01 Information Technology - Dynamic Adaptive Streaming Over HTTP (DASH) Part 1: Media Presentation Description and Segment Formats에서 정의된 바와 같은 DASH(Dynamic Adaptive Streaming Over HTTP)를 지칭한다.
[0065] 도 1의 예에서 예시된 바와 같이, 멀티미디어 콘텐츠(64)는 매니페스트 파일(66)을 포함하며, 이 매니페스트 파일(66)은 MPD(media presentation description)에 대응할 수 있다. 매니페스트 파일(66)은 상이한 대안적 표현들(68)(예컨대, 상이한 품질들을 갖는 비디오 서비스들)의 디스크립션(description)들을 포함할 수 있으며, 디스크립션은 예컨대, 코덱 정보, 프로파일 값, 레벨 값, 비트 레이트, 및 표현들(68)의 다른 설명(descriptive) 특성들을 포함할 수 있다. 클라이언트 디바이스(40)는 표현들(68)의 세그먼트들에 액세싱하는 방법을 결정하기 위해 미디어 프리젠테이션의 MPD를 리트리빙할 수 있다.
[0066] 특히, 리트리벌 유닛(52)은, 비디오 디코더(48)의 디코딩 능력들 및 비디오 출력(44)의 렌더링 능력들을 결정하기 위해, 클라이언트 디바이스(40)의 구성 데이터(미도시)를 리트리빙할 수 있다. 구성 데이터는 또한, 클라이언트 디바이스(40)의 사용자에 의해 선택된 언어 선호도, 클라이언트 디바이스(40)의 사용자에 의해 셋팅된 깊이 선호도들에 대응하는 하나 또는 그 초과의 카메라 관점들, 및/또는 클라이언트 디바이스(40)의 사용자에 의해 선택된 등급 선호도 중 임의의 것 또는 전부를 포함할 수 있다. 리트리벌 유닛(52)은 예컨대, HTTP GET 및 부분적 GET 요청들을 제출하도록 구성된 미디어 클라이언트 또는 웹 브라우저를 포함할 수 있다. 리트리벌 유닛(52)은 클라이언트 디바이스(40)의 하나 또는 그 초과의 프로세서들 또는 프로세싱 유닛들(미도시)에 의해 실행되는 소프트웨어 명령들에 대응할 수 있다. 일부 예들에서, 리트리벌 유닛(52)에 대해 설명된 기능성의 부분들 또는 전부는 하드웨어, 또는 하드웨어, 소프트웨어, 및/또는 펌웨어의 조합으로 구현될 수 있으며, 여기서 소프트웨어 또는 펌웨어에 대한 명령들을 실행하기 위해 필수 하드웨어가 제공될 수 있다.
[0067] 리트리벌 유닛(52)은 클라이언트 디바이스(40)의 디코딩 및 렌더링 능력들을, 매니페스트 파일(66)의 정보에 의해 표시된 표현들(68)의 특성들과 비교할 수 있다. 리트리벌 유닛(52)은 초기에, 표현들(68)의 특성들을 결정하기 위해 매니페스트 파일(66)의 적어도 일부를 리트리빙할 수 있다. 예컨대, 리트리벌 유닛(52)은 하나 또는 그 초과의 적응 세트들의 특성들을 설명하는 매니페스트 파일(66)의 부분을 요청할 수 있다. 리트리벌 유닛(52)은, 클라이언트 디바이스(40)의 코딩 및 렌더링 능력들에 의해 충족될 수 있는 특성들을 갖는 표현들(68)(예컨대, 적응 세트)의 서브세트를 선택할 수 있다. 이후, 리트리벌 유닛(52)은 적응 세트의 표현들에 대한 비트레이트들을 결정하고, 네트워크 대역폭의 현재 가용한 양을 결정하며, 네트워크 대역폭에 의해 충족될 수 있는 비트레이트를 갖는 표현들 중 하나의 표현으로부터 세그먼트들을 리트리빙할 수 있다.
[0068] 일반적으로, 더 높은 비트레이트 표현들이 더 높은 품질의 비디오 재생을 산출할 수 있는 반면에, 가용 네트워크 대역폭이 감소할 때, 더 낮은 비트레이트 표현들은 충분한 품질의 비디오 재생을 제공할 수 있다. 이에 따라, 가용 네트워크 대역폭이 비교적 높을 때, 리트리벌 유닛(52)이 비교적 높은 비트레이트 표현들로부터 데이터를 리트리빙할 수 있는 반면에, 가용 네트워크 대역폭이 낮을 때, 리트리벌 유닛(52)은 비교적 낮은 비트레이트 표현들로부터 데이터를 리트리빙할 수 있다. 이러한 방식으로, 클라이언트 디바이스(40)는 네트워크(74)를 통해 멀티미디어 데이터를 스트리밍하면서, 네트워크(74)의 변하는 네트워크 대역폭 가용성에 또한 적응할 수 있다.
[0069] 부가적으로 또는 대안적으로, 리트리벌 유닛(52)은, 브로드캐스트 또는 멀티캐스트 네트워크 프로토콜, 이를테면, eMBMS 또는 IP 멀티캐스트에 따라 데이터를 수신하도록 구성될 수 있다. 그러한 예들에서, 리트리벌 유닛(52)은 특정 미디어 콘텐츠와 연관된 멀티캐스트 네트워크 그룹에 가입하기 위한 요청을 제출할 수 있다. 멀티캐스트 그룹에 가입한 후에, 리트리벌 유닛(52)은, 서버 디바이스(60) 또는 콘텐츠 준비 디바이스(20)로 발행되는 추가적인 요청들 없이, 멀티캐스트 그룹의 데이터를 수신할 수 있다. 리트리벌 유닛(52)은, 멀티캐스트 그룹의 데이터가 더 이상 요구되지 않을 때, 예컨대, 재생을 중지시키기 위해 또는 상이한 멀티캐스트 그룹으로 채널들을 변경하기 위해, 멀티캐스트 그룹을 떠나기 위한 요청을 제출할 수 있다.
[0070] 네트워크 인터페이스(54)는 선택된 표현의 세그먼트들의 데이터를 수신하여 리트리벌 유닛(52)에 제공할 수 있으며, 이번에는, 이 리트리벌 유닛(52)은 세그먼트들을 디캡슐화 유닛(50)에 제공할 수 있다. 디캡슐화 유닛(50)은 비디오 파일의 엘리먼트들을 구성 PES 스트림들로 디캡슐화하고, PES 스트림들을 디패킷화하여 인코딩된 데이터를 리트리빙하며, 그리고 인코딩된 데이터가 예컨대 스트림의 PES 패킷 헤더들에 의해 표시된 바와 같이 오디오 스트림의 일부인지 또는 비디오 스트림의 일부인지의 여부에 따라, 인코딩된 데이터를 오디오 디코더(46) 또는 비디오 디코더(48)에 전송할 수 있다. 오디오 디코더(46)가 인코딩된 오디오 데이터를 디코딩하고, 디코딩된 오디오 데이터를 오디오 출력(42)에 전송하는 반면에, 비디오 디코더(48)는 인코딩된 비디오 데이터를 디코딩하고, 스트림의 복수의 뷰들을 포함할 수 있는 디코딩된 비디오 데이터를 비디오 출력(44)에 전송한다.
[0071] 비디오 인코더(28), 비디오 디코더(48), 오디오 인코더(26), 오디오 디코더(46), 캡슐화 유닛(30), 리트리벌 유닛(52), 및 디캡슐화 유닛(50) 각각은, 적용가능한 대로, 다양한 적절한 프로세싱 회로소자, 이를테면, 하나 또는 그 초과의 마이크로프로세서들, DSP(digital signal processor)들, ASIC(application specific integrated circuit)들, FPGA(field programmable gate array)들, 이산 로직 회로소자, 소프트웨어, 하드웨어, 펌웨어 또는 이들의 임의의 조합들 중 임의의 것으로서 구현될 수 있다. 비디오 인코더(28) 및 비디오 디코더(48) 각각은 하나 또는 그 초과의 인코더들 또는 디코더들에 포함될 수 있으며, 이들 중 어느 한 쪽이 결합된 비디오 인코더/디코더(CODEC)의 일부로서 통합될 수 있다. 마찬가지로, 오디오 인코더(26) 및 오디오 디코더(46) 각각은 하나 또는 그 초과의 인코더들 또는 디코더들에 포함될 수 있으며, 이들 중 어느 한 쪽이 결합된 CODEC의 일부로서 통합될 수 있다. 비디오 인코더(28), 비디오 디코더(48), 오디오 인코더(26), 오디오 디코더(46), 캡슐화 유닛(30), 리트리벌 유닛(52), 및/또는 디캡슐화 유닛(50)을 포함하는 장치는 집적 회로, 마이크로프로세서, 및/또는 무선 통신 디바이스, 이를테면, 셀룰러 텔레폰을 포함할 수 있다.
[0072] 클라이언트 디바이스(40), 서버 디바이스(60), 및/또는 콘텐츠 준비 디바이스(20)는 본 개시내용의 기술들에 따라 동작하도록 구성될 수 있다. 예의 목적들을 위해, 본 개시내용은 클라이언트 디바이스(40) 및 서버 디바이스(60)에 대하여 이들 기술들을 설명한다. 그러나, 서버 디바이스(60) 대신에(또는 이 서버 디바이스(60)에 부가하여) 콘텐츠 준비 디바이스(20)가 이들 기술들을 수행하도록 구성될 수 있다는 것이 이해되어야 한다.
[0073] 캡슐화 유닛(30)은 NAL 유닛들을 형성할 수 있으며, 이 NAL 유닛들은, NAL 유닛이 속하는 프로그램을 식별하는 헤더, 뿐만 아니라 페이로드, 예컨대, 오디오 데이터, 비디오 데이터, 또는 NAL 유닛에 대응하는 스트림을 설명하는 데이터를 포함한다. 예컨대, H.264/AVC에서, NAL 유닛은 1-바이트 헤더 및 가변 사이즈의 페이로드를 포함한다. 자신의 페이로드에 비디오 데이터를 포함하는 NAL 유닛은, 비디오 데이터의 다양한 입상도(granularity) 레벨들을 포함할 수 있다. 예컨대, NAL 유닛은 비디오 데이터의 블록, 복수의 블록들, 비디오 데이터의 슬라이스, 또는 비디오 데이터의 전체 픽처를 포함할 수 있다. 캡슐화 유닛(30)은 비디오 인코더(28)로부터 기본 스트림들의 PES 패킷들의 형태로, 인코딩된 비디오 데이터를 수신할 수 있다. 캡슐화 유닛(30)은 각각의 기본 스트림을 대응하는 프로그램과 연관시킬 수 있다.
[0074] 캡슐화 유닛(30)은 또한, 복수의 NAL 유닛들로부터의 액세스 유닛들을 어셈블링할 수 있다. 일반적으로, 액세스 유닛은, 비디오 데이터의 프레임, 뿐만 아니라 이 프레임에 대응하는 오디오 데이터(그러한 오디오 데이터가 가용한 경우)를 표현하기 위한 하나 또는 그 초과의 NAL 유닛들을 포함할 수 있다. 액세스 유닛은 일반적으로, 하나의 출력 시간 인스턴스에 대한 모든 NAL 유닛들, 예컨대, 하나의 시간 인스턴스에 대한 모든 오디오 및 비디오 데이터를 포함한다. 예컨대, 각각의 뷰가 초당 20개의 프레임들의 프레임 레이트(fps)를 갖는다면, 각각의 시간 인스턴스는 0.05초의 시간 인터벌에 대응할 수 있다. 이 시간 인터벌 동안, 동일한 액세스 유닛(동일한 시간 인스턴스)의 모든 뷰들에 대한 특정 프레임들이 동시에 렌더링될 수 있다. 일 예에서, 액세스 유닛은 하나의 시간 인스턴스의 코딩된 픽처를 포함할 수 있으며, 이 코딩된 픽처는 일차 코딩된 픽처로서 제시될 수 있다.
[0075] 이에 따라, 액세스 유닛은 공통 시간적 인스턴스의 모든 오디오 및 비디오 프레임들, 예컨대, 시간(X)에 대응하는 모든 뷰들을 포함할 수 있다. 본 개시내용은 또한, 특정 뷰의 인코딩된 픽처를 "뷰 컴포넌트"로 지칭한다. 즉, 뷰 컴포넌트는 특정 시간에 특정 뷰에 대한 인코딩된 픽처(또는 프레임)를 포함할 수 있다. 이에 따라, 액세스 유닛은 공통 시간적 인스턴스의 모든 뷰 컴포넌트들을 포함하는 것으로서 정의될 수 있다. 액세스 유닛들의 디코딩 순서가 반드시 출력 또는 디스플레이 순서와 동일할 필요는 없다.
[0076] 미디어 프리젠테이션은 MPD(media presentation description)를 포함할 수 있고, 이 MPD(media presentation description)는 상이한 대안적 표현들(예컨대, 상이한 품질들을 갖는 비디오 서비스들)의 디스크립션들을 포함할 수 있으며, 디스크립션은 예컨대, 코덱 정보, 프로파일 값, 및 레벨 값을 포함할 수 있다. MPD는 매니페스트 파일, 이를테면, 매니페스트 파일(66)의 일 예이다. 클라이언트 디바이스(40)는 다양한 프리젠테이션들의 영화 프래그먼트들에 액세싱하는 방법을 결정하기 위해 미디어 프리젠테이션의 MPD를 리트리빙할 수 있다. 영화 프래그먼트들은 비디오 파일들의 영화 프래그먼트 박스들(moof 박스들)에 위치될 수 있다.
[0077] 매니페스트 파일(66)(예컨대, MPD를 포함할 수 있음)은 표현들(68)의 세그먼트들의 가용성을 광고할 수 있다. 즉, MPD는, 표현들(68) 중 하나의 표현의 제 1 세그먼트가 가용해지는 벽시계 시간을 표시하는 정보, 뿐만 아니라 표현들(68) 내의 세그먼트들의 지속기간들을 표시하는 정보를 포함할 수 있다. 이러한 방식으로, 클라이언트 디바이스(40)의 리트리벌 유닛(52)은, 특정 세그먼트에 선행하는 세그먼트들의 시작 시간 뿐만 아니라 지속기간들에 기반하여, 각각의 세그먼트가 가용할 때를 결정할 수 있다.
[0078] 캡슐화 유닛(30)이 수신 데이터에 기반하여 NAL 유닛들 및/또는 액세스 유닛들을 비디오 파일로 어셈블링한 후에, 캡슐화 유닛(30)은 비디오 파일을 출력을 위해 출력 인터페이스(32)에 전달한다. 일부 예들에서, 캡슐화 유닛(30)은 비디오 파일을 로컬로 저장하거나, 또는 비디오 파일을 클라이언트 디바이스(40)에 직접적으로 전송하는 것이 아니라, 비디오 파일을 출력 인터페이스(32)를 통해 원격 서버에 전송할 수 있다. 출력 인터페이스(32)는, 예컨대, 송신기, 트랜시버, 예컨대 광학 드라이브, 자기 매체 드라이브(예컨대, 플로피 드라이브)와 같은 컴퓨터-판독가능 매체에 데이터를 기록하기 위한 디바이스, USB(universal serial bus) 포트, 네트워크 인터페이스, 또는 다른 출력 인터페이스를 포함할 수 있다. 출력 인터페이스(32)는 컴퓨터-판독가능 매체(34), 이를테면, 예컨대, 송신 신호, 자기 매체, 광학 매체, 메모리, 플래시 드라이브, 또는 다른 컴퓨터-판독가능 매체에 비디오 파일을 출력한다.
[0079] 네트워크 인터페이스(54)는 네트워크(74)를 통해 NAL 유닛 또는 액세스 유닛을 수신하며, 리트리벌 유닛(52)을 통해 이 NAL 유닛 또는 액세스 유닛을 디캡슐화 유닛(50)에 제공할 수 있다. 디캡슐화 유닛(50)은 비디오 파일의 엘리먼트들을 구성 PES 스트림들로 디캡슐화하고, PES 스트림들을 디패킷화하여 인코딩된 데이터를 리트리빙하며, 그리고 인코딩된 데이터가 예컨대 스트림의 PES 패킷 헤더들에 의해 표시된 바와 같이 오디오 스트림의 일부인지 또는 비디오 스트림의 일부인지의 여부에 따라, 인코딩된 데이터를 오디오 디코더(46) 또는 비디오 디코더(48)에 전송할 수 있다. 오디오 디코더(46)가 인코딩된 오디오 데이터를 디코딩하고, 디코딩된 오디오 데이터를 오디오 출력(42)에 전송하는 반면에, 비디오 디코더(48)는 인코딩된 비디오 데이터를 디코딩하고, 스트림의 복수의 뷰들을 포함할 수 있는 디코딩된 비디오 데이터를 비디오 출력(44)에 전송한다.
[0080] 본 개시내용의 기술들의 목적들을 위해, 클라이언트 디바이스(40)(또는 다른 수신 디바이스) 및 서버 디바이스(60)(또는 콘텐츠 준비 디바이스(20) 또는 다른 송신 디바이스)가 협정세계시(UTC:Coordinated Universal Time)에 따라 정확한 클록들을 갖는다는 것이 가정된다. 시간은 GPS(global positioning system) 또는 송신기(예컨대, 서버 디바이스(60))의 유사한 기술들을 통해 설정될 수 있다. 시간은, 예컨대, 클라이언트 디바이스(40)의 물리 계층에서 (예컨대, 네트워크 인터페이스(54) 내에서) ATSC(Advanced Television Systems Committee) 3.0 기술들을 통해 설정될 수 있다. DASH 프로토콜이 이 요건을 지시하지만, 동기화된 시간을 달성하기 위한 실제 방법은 현재, DASH 표준에 의해 정의되지 않는다. 물론, 클라이언트 디바이스(40)에서의 ATSC 3.0 시간은 명목상, 서버 디바이스(60)의 시간을 넘어서는 비행 시간이다. 그러나, 본 개시내용의 기술들의 경우, 이것이 원하는 결과이다. 즉, 클라이언트 디바이스(40)의 로컬 시간은 물리 계층에서 데이터 블록들의 위치를 정확하게 설명할 것이다. 본 개시내용의 기술들은 아래에서 더욱 상세히 설명된다.
[0081] 일부 예들에서, 서버 디바이스(60) 및 클라이언트 디바이스(40)는 패킷들의 헤더 데이터를 압축/압축해제하기 위해 ROHC(robust header compression)를 사용하도록 구성된다. ROHC 기술들은 압축을 수행하기 위해 콘텍스트 정보의 사용을 포함한다. 따라서, 서버 디바이스(60)가 패킷의 헤더 정보를 압축하기 위해 특정 콘텍스트를 사용할 때, 클라이언트 디바이스(40)가 이 패킷의 헤더 정보를 압축해제하기 위해 동일한 콘텍스트를 사용하는 것이 중요하다. 따라서, 클라이언트 디바이스(40)가 RAP(random access point)에서 랜덤 액세스를 수행할 때, RAP를 비롯하여 하나 또는 그 초과의 패킷들에 대한 헤더 정보를 압축해제하기 위한 콘텍스트를 결정하기 위한 정보가 제공되어야 한다. 이에 따라, 본 개시내용의 기술들은 RAP와 함께 ROHC 콘텍스트 정보를 제공하는 것을 포함한다.
[0082] 예컨대, MPD(media presentation description)(또는 다른 매니페스트 파일) 및 IS(initialization segment)를 전송할 때, 서버 디바이스(60)는 MPD/매니페스트 파일에 바로 선행하여 ROHC 콘텍스트 초기화 데이터를 전송할 수 있다. 마찬가지로, 클라이언트 디바이스(40)는 MPD/매니페스트 파일 및 IS 직전에 ROHC 콘텍스트 초기화 데이터를 수신할 수 있다. "직전"은, ROHC 콘텍스트 초기화에 대한 데이터가 MPD/매니페스트 파일 및 IS보다 일찍, 그리고 이 MPD/매니페스트 파일 및 IS에 연속적으로 수신된다는 것을 의미할 수 있다.
[0083] 도 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) 사이에 상이한 개수들의 영화 프래그먼트들이 있을 수 있다.
[0084] MPD(104)는 표현들(110-120)과는 별개의 데이터 구조를 포함할 수 있다. MPD(104)는 도 1의 매니페스트 파일(66)에 대응할 수 있다. 마찬가지로, 표현들(110-120)은 도 1의 표현들(68)에 대응할 수 있다. 일반적으로, MPD(104)는, 표현들(110-120)의 특성들, 이를테면, 코딩 및 렌더링 특성들, 적응 세트들, MPD(104)에 대응하는 프로파일, 텍스트 타입 정보, 카메라 각도 정보, 등급 정보, 트릭 모드 정보(예컨대, 시간적 서브-시퀀스들을 포함하는 표현들을 표시하는 정보), 및/또는 원격 기간들을 리트리빙하기 위한(예컨대, 재생 동안 미디어 콘텐츠 안으로의 타겟 광고 삽입을 위한) 정보를 일반적으로 설명하는 데이터를 포함할 수 있다.
[0085] 헤더 데이터(112)는, 존재하는 경우, 세그먼트들(114)의 특성들, 예컨대, RAP(random access point)들(SAP(stream access point)들)로 또한 지칭됨)의 시간적 위치들을 설명할 수 있으며, 그 중에, 세그먼트들(114)은 랜덤 액세스 포인트들, 세그먼트들(114) 내의 랜덤 액세스 포인트들에 대한 바이트 오프셋들, 세그먼트들(114)의 URL(uniform resource locator)들, 또는 세그먼트들(114)의 다른 양상들을 포함한다. 헤더 데이터(122)는, 존재하는 경우, 세그먼트들(124)에 대한 유사한 특성들을 설명할 수 있다. 부가적으로 또는 대안적으로, 그러한 특성들은 MPD(104) 내에 완전히 포함될 수 있다.
[0086] 세그먼트들(114, 124)은 하나 또는 그 초과의 코딩된 비디오 샘플들을 포함하며, 이 코딩된 비디오 샘플들 각각은 비디오 데이터의 프레임들 또는 슬라이스들을 포함할 수 있다. 세그먼트들(114)의 코딩된 비디오 샘플들 각각은 유사한 특성들, 예컨대, 높이, 폭, 및 대역폭 요건들을 가질 수 있다. 그러한 특성들은 MPD(104)의 데이터에 의해(그러한 데이터가 도 2의 예에서 예시되지 않지만) 설명될 수 있다. MPD(104)는 3GPP 사양에 의해 설명된 바와 같은 특성들을 포함할 수 있으며, 시그널링되는 정보 중 임의의 정보 또는 전부의 추가는 본 개시내용에서 설명된다.
[0087] 세그먼트들(114, 124) 각각은 고유한 URL(uniform resource locator)과 연관될 수 있다. 따라서, 세그먼트들(114, 124) 각각은, 스트리밍 네트워크 프로토콜, 이를테면, DASH를 사용하여 독립적으로 리트리빙가능할 수 있다. 이러한 방식으로, 목적지 디바이스, 이를테면, 클라이언트 디바이스(40)는 세그먼트들(114 또는 124)을 리트리빙하기 위해 HTTP GET 요청을 사용할 수 있다. 일부 예들에서, 클라이언트 디바이스(40)는 세그먼트들(114 또는 124)의 특정 바이트 범위들을 리트리빙하기 위해 HTTP 부분적 GET 요청들을 사용할 수 있다.
[0088] 도 3은 서버 디바이스(이를테면, 도 1의 서버 디바이스(60)) 및 클라이언트 디바이스(이를테면, 도 1의 클라이언트 디바이스(40))의 예시적 컴포넌트들을 예시하는 블록 다이어그램이다. 이 예에서, 서버 디바이스는 미디어 인코더, 세그먼터(segmenter), 전송기(이 예에서, ROUTE 송신 프로토콜을 활용함), MAC/PHY 스케줄러, 및 익사이터(exciter)/증폭기를 포함한다. 이 예에서, 클라이언트 디바이스는 MAC/PHY 수신기, 전송 수신기(transport receiver)(이 예에서, ROUTE 프로토콜을 활용함), 미디어 플레이어(이 예에서, DASH 클라이언트임), 및 코덱을 포함한다.
[0089] 서버 디바이스의 다양한 엘리먼트들(예컨대, 미디어 인코더, 세그먼터, 전송기, 및 MAC/Phy 스케줄러) 중 임의의 엘리먼트 또는 엘리먼트들 전부는 하드웨어로, 또는 하드웨어 및 소프트웨어의 조합으로 구현될 수 있다. 예컨대, 이들 유닛들은 하나 또는 그 초과의 마이크로프로세서들, DSP(digital signal processor)들, ASIC(application specific integrated circuit)들, FPGA(field programmable gate array)들, 및/또는 이산 로직 회로소자, 또는 이들의 조합들로 구현될 수 있다. 부가적으로 또는 대안적으로, 이들 유닛들은 하드웨어에 의해 실행되는 소프트웨어로 구현될 수 있다. 소프트웨어용 명령들은 컴퓨터-판독가능 저장 매체 상에 저장되며, 하나 또는 그 초과의 프로세싱 유닛들(위에서 논의된 것과 같은 하드웨어를 포함할 수 있음)에 의해 실행될 수 있다.
[0090] 미디어 인코더는 재생 시간 정보를 갖는 압축 미디어를 만든다. 세그먼터는 이것을, ISO BMFF(Base Media File Format)일 공산이 있는 파일들로 패키징한다. 세그먼터는 파일들을 바이트 범위들로서 전송기에 전달한다. 전송기는 IP/UDP/ROUTE에서의 전달을 위해 바이트 범위들로서 파일들을 래핑(wrapping)한다. MAC/PHY는 IP 패킷들을 취하며, 이 IP 패킷들을 RF를 통해 수신기에 송신한다. 점선들로 연결하는 것은 단대단(end to end)으로 동작한다. 이는 블록 이름들을 제공하는 목적을 위한 간략한 논의이다.
[0091] 본 개시내용의 기술들에 따라, 서버 디바이스는 제 1 유닛, 및 미디어 데이터의 전달에 관련된 제 2 유닛을 포함한다. 제 1 유닛은 미디어 데이터에 대한 설명 정보를 제 2 유닛에 전송한다. 이 예에서, 제 1 유닛 및 제 2 유닛은 세그먼터 및 전송기, 또는 전송기 및 MAC/PHY 스케줄러에 각각 대응할 수 있다. 설명 정보는 미디어 데이터의 세그먼트 또는 세그먼트의 바이트 범위 중 적어도 하나, 그리고 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간 중 적어도 하나를 표시한다. 제 1 유닛은 또한, 미디어 데이터를 제 2 유닛에 전송한다.
[0092] 네트워크 전송을 위해 서버 디바이스가 미디어 세그먼트들 또는 이들의 부분들, 이를테면, 특정 바이트 범위들을 추가로 캡슐화할 수 있다는 것이 이해되어야 한다. 예컨대, 서버 디바이스는 미디어 세그먼트들의 데이터를 하나 또는 그 초과의 패킷들의 형태로 캡슐화할 수 있다. 일반적으로, 네트워크 스택의 다양한 레벨들에서의 하나 또는 그 초과의 프로토콜들에 따라, 예컨대, OSI(Open Systems Interconnection) 모델에 따라 데이터를 갖는 페이로드를 캡슐화함으로써, 패킷들이 형성된다. 예컨대, 페이로드(예컨대, ISO BMFF 파일의 일부 또는 전부)는 TCP(Transmission Control Protocol) 헤더 및 IP(Internet protocol) 헤더에 의해 캡슐화될 수 있다. 설명 정보가 또한, 페이로드를 캡슐화하기 위해 사용되는 데이터에 적용된다는 것이 이해되어야 한다. 예컨대, 설명 정보가, 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 이른 시간을 표시할 때, 이 가장 이른 시간은 또한, 세그먼트 또는 바이트 범위(예컨대, 하나 또는 그 초과의 네트워크 프로토콜들에 따른 데이터)를 캡슐화하기 위해 사용되는 임의의 데이터에 적용된다. 마찬가지로, 설명 정보가, 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간을 표시할 때, 이 가장 늦은 시간은 또한, 세그먼트 또는 바이트 범위를 캡슐화하기 위해 사용되는 임의의 데이터에 적용된다.
[0093] 이러한 방식으로, 제 2 유닛은, 설명 정보에 따라 미디어 데이터를 클라이언트 디바이스에 전달하도록 구성될 수 있다. 예컨대, 제 2 유닛은, 세그먼트 또는 세그먼트의 바이트 범위가 가장 이른 시간보다 더 일찍 전달되지 않는다는 것을 보장하며, 그리고/또는 가장 늦은 시간 전에 세그먼트 또는 바이트 범위가 전달된다는 것을 보장할 수 있다.
[0094] 설명 정보에 따라(예컨대, 가장 이른 시간 후에, 그리고/또는 가장 늦은 시간 전에) 데이터를 전송함으로써, 서버 디바이스는, 클라이언트가 미디어 데이터를 사용할 수 있는 시간에 미디어 데이터가 클라이언트 디바이스에 도달한다는 것을 보장할 수 있다. 미디어 데이터가 가장 이른 시간보다 일찍 또는 가장 늦은 시간보다 늦게 도달했다면, 클라이언트 디바이스는 이 미디어 데이터를 폐기할 수 있는데, 그 이유는 그것이 사용할 수 없을 수 있기 때문이다. 게다가, 미디어 데이터가 가장 늦은 시간 후에 도달하면(또는 폐기되면), 미디어 데이터는 후속 미디어 데이터의 디코딩을 위한 레퍼런스 미디어 데이터로서의 사용에 가용하지 않을 수 있다. 예컨대, 미디어 데이터가 하나 또는 그 초과의 레퍼런스 픽처들을 포함했다면, 후속 픽처들은 정확하게 디코딩될 수 없을 수 있는데, 그 이유는 레퍼런스 픽처들이 레퍼런스를 위해 가용하지 않을 것이기 때문이다. 이러한 방식으로, 본 개시내용의 기술들은 낭비되는 대역폭을 회피하며, 사용자의 경험을 개선시킬 수 있다.
[0095] 설명 정보는 특정 미디어 인코더의 대상이 되는 세그먼트 또는 바이트 범위의 부분, 타겟 시간 ―세그먼트 또는 바이트 범위는 이 타겟 시간에, 또는 이 타겟 시간 직후에 전달되어야 함―, 세그먼트 또는 바이트 범위가 전달될 수 있는 가장 늦은 시간, 세그먼트 또는 바이트 범위 내의 데이터에 대한 프리젠테이션 타임 스탬프, 미디어 스트림들의 데이터에 대한 타겟 전달 시간들에 대하여 다른 미디어 스트림들에 관련한, 세그먼트를 포함하는 미디어 스트림의 우선순위, 및/또는 세그먼트 또는 바이트 범위 내의 데이터에 대한 디코드 타임 스탬프 중 임의의 것 또는 전부를 더 포함할 수 있다. 따라서, 제 2 유닛은, 이 추가 정보 중 임의의 것 또는 전부에 따라 미디어 데이터를 전달할 수 있다. 예컨대, 제 2 유닛은, 미디어 데이터가 가능한 한 타겟 시간에 가깝게, 그리고/또는 프리젠테이션 시간 및/또는 디코드 시간 전에 전달된다는 것을 보장할 수 있다. 마찬가지로, 제 2 유닛은 우선순위 정보에 따라 미디어 데이터를 전달할 수 있다. 예컨대, 미디어 데이터의 복수의 이산 유닛들 중 단 한 개의 이산 유닛이 정각에 전달될 수 있다면, 제 2 유닛은 이산 유닛들 중 어느 이산 유닛이 최고 우선순위를 갖는지를 결정하며, 그 이산 유닛을 다른 이산 유닛들 전에 전달할 수 있다. 여기서, 미디어 데이터의 "이산 유닛"이란 용어는 예컨대 세그먼트 또는 세그먼트의 바이트 범위를 지칭할 수 있다.
[0096] 도 4는 데이터가 (도 3의 클라이언트 디바이스의) MAC/PHY 계층에 수신되는 시간들과, 미디어 플레이어가 이 수신 데이터로부터 도출되는 미디어 데이터를 출력하는 시간들 사이의 차이들의 예들을 예시하는 개념적 다이어그램이다. MAC/Phy 계층 및 미디어 플레이어는 전송 버퍼 모델을 구현하기 위해 상호작용할 수 있으며, 이 전송 버퍼 모델은, 두 개의 준-독립적인 타임라인들을 동작하는 시스템에 따르게 할 수 있다. 이들 두 개의 타임라인들은 이산 시간 미디어 출력 이벤트들을 나타내는 미디어 전달 및 소비 타임라인(도 4의 하단), 및 이산 시간 데이터 전달 이벤트들을 나타내는 MAC/PHY 계층 데이터 전달 타임라인(도 4의 상단)을 포함한다.
[0097] 도 4는 수신기 관점(예컨대, 도 1의 클라이언트 디바이스(40)에 대응할 수 있는 도 3의 클라이언트 디바이스의 관점)을 예시한다. MAC/Phy 타임라인은, 특정 시간들에 데이터의 버스트들을 갖는, 수신기의 MAC의 출력에서의 물리 계층의 임펄스 응답으로서 생각될 수 있다. 미디어 플레이어 출력 타임라인은 특정 시간들에서의 비디오 프레임들 또는 오디오 샘플들일 수 있다. 도 4의 상부의 화살표들은 (MAC/Phy 타임라인에서의) 데이터 전달 이벤트들, 또는 예컨대 미디어 플레이어 출력 타임라인에서의 비디오 프레임들을 표현한다. 도 4의 하부의 화살표들은 미디어 플레이어 출력 이벤트들, 예컨대, 특정 시간들에서의 미디어 데이터의 프리젠테이션들을 표현한다.
[0098] 도 5는 데이터가 (도 3의 클라이언트 디바이스의) MAC/Phy 계층에 수신되는 시간들(즉, 도 5의 상부의 MAC/PHY 타임라인에서, 이산 시간 데이터 전달 이벤트들), (도 3의 클라이언트 디바이스의) DASH 플레이어가 입력을 수신하는 시간들(즉, 도 5의 수직적으로 중간 부분의 DASH 플레이어 입력 타임라인에서, 이산 시간 미디어 데이터 이벤트들), 그리고 DASH 플레이어가 출력을 전달하는 시간들(즉, 도 5의 하부의 DASH 플레이어 출력 타임라인에서, 이산 시간 미디어 출력 이벤트들) 사이의 차이들의 예들을 예시하는 개념적 다이어그램이다. 미디어 출력은 일반적으로, MAC/Phy 계층의 데이터 전달 이벤트들에 직접적으로 따를 수 없다. 그 이유는, 출력 이산 시간 미디어 이벤트들이 많은 입력 미디어 샘플들을 가질 수 있기 때문이다. 예컨대, 오디오는 오디오 프레임마다 수천 개의 샘플들을 가질 수 있다. 다른 예로서, 출력 비디오 프레임은 이 출력 비디오 프레임을 설명하기 위해 요구되는 N개의 입력 비디오 프레임들을 가질 수 있다. 전송 버퍼 모델은 MAC/Phy 이산 시간 데이터 전달 이벤트들과 DASH 플레이어 이산 시간 미디어 전달 이벤트들 사이의 일치를 허용한다.
[0099] 도 6은 데이터 전달 이벤트(Data Delivery Event)들과 미디어 전달 이벤트(Media Delivery Event)들 사이의 대응의 예들을 예시하는 개념적 다이어그램이다. 이벤트들을 만드는(drive) 데이터의 특정 집합들, 이를테면, 시작 및 플레잉 미디어 그리고 다음 차례의 미디어 프레임 또는 프레임들의 그룹이 있다. ROUTE 전송기/수신기 인터페이스들의 바이트 범위 전송 메커니즘은 세그먼터(도 3)로 하여금 DASH 플레이어에 의미 있는 미디어의 이산 유닛들을 정의하도록 허용한다. 의미 있는 이산 유닛(미디어 데이터 이벤트들)의 예는, MPD, IS, 영화 박스(Moof), 및 HEVC의 경우 압축 비디오의 최대 6개의 프레임들을 포함할 수 있는, 비디오 재생을 시작시키기 위해 사용되는 유닛이다. 도 6은 수신기 뷰 및 다양한 계층들 사이의 시간 관계들/대응을 예시한다. 특히, 도 6은 MAC/PHY 타임라인에서의 이산 시간 데이터 전달 이벤트들, DASH 플레이어 입력 타임라인에서의 이산 시간 미디어 데이터 이벤트들, 및 DASH 플레이어 출력 타임라인에서의 이산 시간 미디어 출력 이벤트들을 도시한다.
[0100] 도 7은 MAC/Phy 데이터 전달 블록들을 예시하는 개념적 다이어그램이다. 본 개시내용의 기술들에 따라, 이들 블록들은 개별 MPEG-2 TS(Transport Stream) 패킷들이 더 이상 아니다(ATSC 1.0에서는, 그들이 개별 MPEG-2 TS(Transport Stream) 패킷들이었지만). 도 7은 MAC 어드레스에 의해 정의된 바와 같이 입력 포트로부터 출력 포트로의 데이터의 최신 물리 계층 전송 블록들을 예시한다. 이들 데이터 블록들의 사이즈는 2KB 내지 8KB의 범위에 있지만, 어느 경우이든, MPEG-2 TS 패킷들보다 훨씬 더 클 수 있다. 데이터의 이들 블록들은 IP 패킷들을 포함할 수 있다. MAC 어드레스는 IP 어드레스 및 포트 번호에 맵핑될 수 있다. 블록의 콘텐츠의 전달 시간은 MAC/Phy 입력에 대한 지연의 면에서 MAC/Phy 출력에 알려진다. 도 7은 데이터 전달 블록들의 추상화된 모델을 표현한다. 알려진 전달 시간들을 갖는 IP 패킷들이 되는 데이터의 이산 유닛들이 수신기에 전달된다.
[0101] 도 8은 송신 프로세스 및 수신 프로세스의 예를 예시하는 개념적 다이어그램이다. (예컨대, 도 3의) 서버 디바이스에 의해 수행되는 송신 프로세스에서, 세그먼터는 압축 미디어의 데이터 구조를 정의하는 데이터 및 정의된 미디어 이벤트들의 시간 전달 요건들을 이용하여 구성되는데, 예컨대, 특정 오디오 프레임이 특정 시간에 코덱의 입력에서 요구된다. 특별 이벤트들, 이를테면, 예컨대, 미디어 계층에서의 RAP(random access point)는 추가로 요구되는 데이터를 갖지만, 세그먼터는 RAP의 존재를 검출할 수 있으며, 추가로 요구되는 데이터, 예컨대, MPD, IS, Moof 등을 덧붙일 수 있다. MAC/Phy 스케줄러는 특정 데이터를 특정 시간들에서의 특정 블록들에 할당한다. 데이터의 이들 블록들은 Phy/MAC의 출력에서 알려진 수신 시간들을 갖는다.
[0102] (예컨대, 도 3의) 클라이언트 디바이스에 의해 수행되는 수신 프로세스에서, Phy/MAC 계층은 데이터 블록들을 수신하며, 이 데이터 블록들을 (스케줄에 따라) 즉시, 즉, 데이터 블록들을 전송 유닛에 제공함으로써 포스팅(posting)한다. 이들 IP/UDP/ROUTE 패킷들은 바로 ROUTE 전송 버퍼로 간다. 미디어 전달 이벤트는 스케줄에 따라 DASH 플레이어에 가용하다. 플레이어는 스케줄에 따라 미디어를 코덱에 전달한다. 이후, 코덱은 스케줄에 따라 디코딩한다.
[0103] 송신 및 수신 프로세스들에 대한 특정 경계 조건들이 있다. 기간 경계들의 경우, (예컨대, 표현들 사이의) 미디어의 임의의 스위칭은 기간 경계에 있어야 하며, 예컨대, ad 삽입의 경우, 이 스위칭이 매끄럽도록 하기 위해 기간의 제 1 바이트는 일찍 전달될 수 없다. 제 1 바이트가 일찍 전달되면, ad는 정확하게 시작할 수 없을 수 있다. 종단점은 덜 민감한데, 그 이유는 다음 차례의 기간(ad이든 또는 프로그램으로 되돌아가든 간에)의 시작 T-RAP(Transport RAP)가 디코더를 정확하게 시작시킬 것이지만, 정확한 타겟 기간 동안 마지막 바이트가 수신되는 것이 더욱 나을 것이기 때문이다. 또한, IP 프래그먼트 및 디프래그먼트(defragment)의 경우, IP 캡슐화 및 디캡슐화는 ROUTE 전송기 및 ROUTE 수신기에서 각각 핸들링된다. ROUTE 전송기는 IP 패킷들을 조직화하며, 따라서 T-RAP들 및 기간 경계들은 정확하다. 전송 수신기(Transport receiver)는 다음 차례의 MDE(media delivery event) 미디어 이벤트의 프래그먼트를 일찍 알지만, 결코 기간 경계에서 아는 것이 아닐 수 있다.
[0104] 안전한 시작(Safe Start): 미디어 이벤트 타임라인 및 물리 계층 스케줄링의 정의는, 정확한 시간에 미디어가 도달하기 시작할 필요가 있었다는 것을 보장할 수 있다. 따라서, 이 지점까지, 클라이언트 디바이스가 데이터를 갖는다면, 클라이언트 디바이스는 데이터를 즉시 플레잉할 수 있다. 이 지점까지 설명된 시스템은 이른 시간 및 늦은 시간의 강제에 의해 이것을 가설적으로 달성할 수 있지만, 이는 물리 계층에 대한 비현실적인 요구들을 할 수 있으며, 이는 너무 지나친 미디어 압축(이는, 인코딩된 미디어가 요구되는 프리젠테이션 스케줄에 따르게 하기 위한 물리 계층/MAC 스케줄러 수단임)을 야기할 수 있다.
[0105] 완화된 스케줄링: 물리 계층이 데이터 전부를 스케줄링할 수 있는 최선의 기회를 갖도록 하기 위하여, 전달 시간에서 어떤 유연성이 있는 것이 좋을 것이다. 모든 각각의 바이트가 수신기에 동시에 전달될 수 있는 것은 아니다. 예컨대, phy 전달 레이트가 20 Mbs/sec이고, 서비스가 3 Mbs/sec 걸리면, 전달은 평균하여 7X 실제 시간에 실행될 수 있다. 이 예시적인 사용의 경우에서, 0.5초의 시간 마진은 0.5초 세그먼트에 대해 매우 넉넉할 것이다.
[0106] 도 9a 및 도 9b는 본 개시내용의 기술들에 따라 미디어 데이터에 적용되는 FEC(forward error correction)의 예들을 예시한다. 안전한 시작을 수행할 때의 예시적 시나리오들이 아래에서 설명된다. 일 예에서, 이른 시작이 있다. 즉, 클라이언트 디바이스는 T-RAP로 시작하는 미디어 전달 이벤트를 수신하자마자 즉시 미디어 데이터를 플레잉하려고 시도할 수 있다. 최악의 경우, 이는 짧은 스톨(stall)을 야기한다. 이 스톨의 최대 지속기간은 시간 마진에 따라 좌우된다. 스톨 지속기간은 실제 시작 지점과 기능적으로 요구되는 장기 시작 시간 사이의 차이로서 정의될 수 있다. 물리 계층 스케줄러가, 엄격하게 일치되는 미디어 사이즈 대 미디어 프리젠테이션 타임 라인에 대한 안전한 시작을 보장하는 것이 가능하지만, 그것은 최선의 가능한 비디오 품질을 야기하지 않을 수 있다. 여기서, 관심사의 핵심 양상은, 이른/늦은 메커니즘이 원하는 결과(들)가 발생하도록 허용하기에 충분히 유연하다는 것이다. 결과의 복수의 양상은, 상이한 목표들이 있을 수 있으며 전부가 이들 메커니즘들에 의해 효과적으로 제공될 수 있다는 사실에 관련된다.
[0107] 안전한 시작에서, 클라이언트 디바이스는 마지막 바이트의 스케줄링된 전달 후에 미디어 데이터를 플레잉한다. 미디어 전달 이벤트의 마지막 바이트의 수신이 보장될 수 있다. 전달 인도 지속기간은 동적일 수 있다. 늦은 시간은, 어쩌면 기간 종료들을 제외한 시간의 대부분이 고정된 스케줄에 따를 공산이 있다. 유사하게, 이른 시간은, 기간 시작시를 제외하고, 유연할 수 있다. 말하자면, 유연성이 가능하지만, 어쩌면 기간 경계들에서 제약된다. 도 9a는 A/V 오브젝트가 A/V 번들에 걸친 FEC와 정렬된다면 FEC가 어떻게 영향을 미치지 않는지를 도시한다. 도 9b는 최대 5개의 A/V 오브젝트들이 A/V 번들(이는 용량을 증가시킬 수 있으며, 이는 레코딩에 좋은 것임)에 걸친 FEC와 정렬된다면 FEC가 어떻게 0 내지 4초의 지연을 야기할 수 있는지를 도시한다.
[0108] 도 10은 다양한 세그먼트 전달 스타일들을 예시하는 개념적 다이어그램이다. 스타트업 지연을 회피하기 위하여, MPD 및 IS는 RAP에 바로 선행해야 한다. 따라서, 도 10은 MPD 및 IS가 RAP에 선행하는 두 개의 예들을 예시한다. ROHC(Robust Header Compression)가 활용되면, 둘 모두의 예들에서, ROHC 콘텍스트 초기화 데이터는 MPD 직전에 삽입될 수 있다. 이러한 방식으로, ROHC 압축해제기(또는 디코더)는 ROHC 콘텍스트 초기화 데이터를 수신하며, 헤더를 적절하게 압축해제하기 위해 이 초기화 데이터를 사용할 수 있다. 콘텍스트 정보는 ROUTE 세션에, 또는 LCT 세션마다 특정할 수 있으며, 여기서 ROUTE 세션은 하나 또는 그 초과의 LCT 세션들을 포함할 수 있다. 따라서, 콘텍스트 정보는 단일 ROUTE 세션에 대해, 그리고/또는 ROUTE 세션의 하나 또는 그 초과의 LCT 세션들 각각에 대해 MPD 전에 전달될 수 있다.
[0109] 도 11은 실제 전송 버퍼 모델을 예시하는 개념적 다이어그램이다. 이는 본 개시내용의 기술들을 통해 간단하게 만들어진다. 스타트-업까지 단 한 개의 버퍼만이 있고, 오버플로우가 관심사이며, 그것은 전송 버퍼이다. MAC/phy 스케줄링은, 어떠한 버퍼 모델 수반도 없이, 스타트 업을 보장한다. 문제가 되는 단 한 개의 바운드만이 있다. 미디어는 스케줄링된 전달 시간에 버퍼에 들어가며, 그것이 파일로서 출력 영역에 포스팅될 때, 삭제된다. 서비스가 시작되는데, 즉, T-RAP로 시작하는 MDE가 버퍼를 비운다. 버퍼 모델은, 데이터가 전송 버퍼에 전달 또는 포스팅될 모든 각각의 시간(t)마다 업데이팅된다. 레지스터 값은 수신기 디바이스(클라이언트 디바이스)에서의 시간(t)에 대한 바이트 단위의 버퍼 모델 풀니스(fullness)이다. 버퍼는, 각각의 현재 활성 전달에 대한 모든 관련 AL-FEC를 비롯하여, 현재 전달 및 이 세션에서의 모든 다른 현재 미해결(unresolved) 전달들에 관련되는 IP/UDP/ROUTE 패킷들 전부를 포함한다. 버퍼 모델은, 포스팅된 오브젝트 또는 오브젝트들에 대한 관련 패킷들 전부의 사이즈만큼, 그들의 상태가 해결될 때 감소된다. 이 사용에서, ROUTE 전송 수신기가 상태를 결정했고 그에 따라 동작했을 때, 즉, 오브젝트(들)를 포스팅하거나 또는 버렸을 때, 그것은 "해결"된다. 대응하는 관련 전송 데이터는 삭제되며, 버퍼 모델 레지스터는 그에 따라 감소된다.
[0110] 이러한 방식으로, 사용되고 있는 MAC/Phy에 대해 정확한, 물리 계층에 대한 MAC/Phy 스케줄링을 설정함으로써, 버퍼 모델에 관한 한, 어떠한 스타트 업 조건들도 없다. 버퍼 풀니스는 직접적으로 계산될 수 있는데, 그 이유는 타임 라인 이벤트들이 보장되기 때문이다. 알려진 사이즈 미디어 이벤트가 알려진 시간들에 들어간다. 미디어는 알려진 시간들에, 즉, 세그먼트가 출력 영역에 포스팅될 때 삭제된다.
[0111] 도 12a 및 도 12b는 본 개시내용의 기술들을 MPEG-2 TS 모델과 대조하는 개념적 다이어그램들이다. 도 12a에서, 전송되고 있는 패킷과 수신되고 있는 패킷 사이의 고정된 지연이 있다. 이는 MPEG-2 TS에 대한 완벽하게 괜찮은 모델이며, 그것은 산업에도 또한 서빙했다. 그러나, 도 12b에 도시된 바와 같이, 그것을 ATSC 3.0에 적응시키려고 시도하는 것은 일부 바람직하지 않은 결과들을 가질 수 있다. 도 12b는 FEC(forward error correction) 디코딩 버퍼, 디-지터(de-jitter) 버퍼, 및 MMTP(MPEG Media Transport Protocol) 디캡슐화 버퍼를 포함한다. ATSC 3.0 물리 계층의 내재적으로 버스티(bursty)한 양상들은, MPEG-2 TS 모델을 유효하게 만들기 위하여 저역 통과 필터에 의해 평탄화되어야 한다. 이 물리 계층 평탄화는 궁극적으로, 플레이어로의 미디어의 전달을 지연시킨다.
[0112] 도 13은 클라이언트 디바이스, 이를테면, 도 3의 클라이언트 디바이스 및/또는 도 1의 클라이언트 디바이스(40)에 의해 구현될 수 있는 예시적 수신기 IP 스택의 블록 다이어그램이다. 도 13은 데이터의 블록들을 UDP IP 스택에 제공하는 물리 계층을 예시하고, 이 UDP IP 스택은 패킷들을 AL-FEC 및 파일 전달 프로토콜 계층에 제공하며, 이 AL-FEC 및 파일 전달 프로토콜 계층은 파일들 또는 파일들의 바이트 범위들을 DASH 클라이언트/ISO-BMFF/MMT/파일 핸들러 계층에 제공하며, 이 DASH 클라이언트/ISO-BMFF/MMT/파일 핸들러 계층은 미디어 스트림을 코덱 디코더에 제공한다. 파일 전달 프로토콜 계층과 파일 핸들러 계층 사이의 인터페이스가 파일들 및/또는 파일들의 부분들(예컨대, 파일들의 바이트 범위들)의 전달을 허용할 수 있을 가능성이 있다. 추가로, 이들 파일들 또는 파일들의 부분들은 수신기에서의 수신을 위한 시간상 데드라인, 그리고 또한 선호하는 수신 순서를 가질 수 있다. 파일들은 예컨대, DASH에 따라 미디어 콘텐츠의 표현들의 세그먼트들을 표현할 수 있다.
[0113] 이 종류의 시스템에 대한 역사적 접근법은, 도 12a에서 묘사된 바와 같이, 고정된 지연 및 대역폭 파이프를 통해 물리 계층을 가로질러 일정한 지연을 가정한 버퍼 모델이었다. 이들 시스템들은 RF에서 MPEG-2 TS 패킷(들)을 표현했으며, 전체 입력 스트림을 MPEG2 전송 스트림 패킷들의 단일 시리즈로서 종종 취급했다. 이들 MPEG 2 전송 스트림들은 어쩌면, 몇몇 상이한 고유 패킷 ID들 또는 소위 PID들을 갖는 패킷들을 포함했다.
[0114] 일반적으로, 최신 물리 계층들은 MPEG-2 TS를 RF에서의 특징으로서 표현하지 않는다. 그들이 전혀 운반되지 않으면, 그것은 어떤 더 큰 컨테이너, 예컨대, 2K 바이트들 또는 8K 바이트들의 내부에 있으며, 이 더 큰 컨테이너가 대신에 IP 패킷들을 포함할 수 있다. 특정 어드레스들로의 직접 액세스를 달성하려고 시도할 때, 그렇게 하지 않는 것이 더욱 배터리 효율적이지만, RF 데이터의 이들 블록들은 프래그먼팅될 수 있다.
[0115] 도 14는 일정한 지연 가정 및 블록 전달 기반 물리 계층에 따라 구현되는 예시적 송신 시스템을 예시하는 개념적 다이어그램이다. 도 14는 전송기 디바이스의 Phy/MAC 버퍼, 뿐만 아니라 Phy/MAC 버퍼 및 전송 버퍼를 포함하는 수신기 디바이스의 두 개의 버퍼들을 나타낸다. 아래에서 설명되는 도 15에 도시된 바와 같이, 도 14의 시스템의 전송 측에 대한 대체로 대칭적인 송신 스택이 있다. 이들 최신 물리 계층들은, 알려진 사이즈 및 입력으로부터 출력까지의 알려질 수 있는 지연을 갖는 데이터의 블록들의 전송으로서 그들이 보일 수 있는 방식으로 진화했다. 베어링(bearing) 데이터 채널들의 이 구성은 대체로, MAC/phy의 정의된 특성들로부터의 알려진 이탈 및 전달 시간을 갖는 용량의 할당들이다. 이들 종류들의 시스템들은 일정한 지연의 단일 전달 파이프로서 또는 심지어 다수의 전달 파이프들로서 보일 필요가 없다. 또한, 그들은 실제로, 일정한 지연을 달성하기 위하여 입력 및/또는 출력 버퍼들을 구현해야 할 수 있으며, 이는 전체 레이턴시(latency)를 증가시키고 채널 변경을 느리게 할 수 있다. 그러한 시스템의 추상화된 수신기 모델이 도 14에서 도시된다.
[0116] 도 15는 소스 디바이스의 예시적 송신기 구성을 예시하는 블록 다이어그램이다. 이 예에서, 소스 디바이스(전송기 디바이스 또는 서버 디바이스로 본원에서 또한 지칭됨)는 미디어 인코더, 하나 또는 그 초과의 세그먼터들, ROUTE 전송기, 및 MAC/phy 유닛을 포함한다. 도 14의 시스템의 구성에 반해서, 데이터를, 이 데이터가 목적지에서 요구될 때에 관한 정보와 함께 MAC/phy 인터페이스에 제공하고, MAC/phy 스케줄러가 정의된 가상 전달 파이프들의 알려진 것을 (어쩌면, 동적 구성에 의해) 최적화하게 두는 것이 더욱 효과적이다. 이들은 IP 어드레스 및 포트 번호에 의해 종종 맵핑된다.
[0117] 도 16은 스케줄링된 패킷 전달을 이용하는 시스템에서의 데이터에 대한 예시적 전달 모델을 예시하는 개념적 다이어그램이다. 이 특정 구성은, 블록 전송 물리 계층을 통해 오브젝트들(파일들)을 송신하는 목적들에 적절한 ROUTE 송신 프로토콜의 사용을 나타내지만, 이 프로토콜은 또한 FLUTE(File Delivery over Unidirectional Transport)(IETF RFC 6726에서 정의됨)일 수 있으며, 이 FLUTE는, 다소 더 적은 특징들에 갖지만, 유사한 기능을 가진다. 그러한 시스템의 개정 모델이 도 16에서 도시된다. 도 16에 도시된 바와 같이, 송신기 및 수신기 둘 모두는 수신기 물리 계층 평탄화 버퍼를 포함할 필요가 없다. 스케줄링된 패킷들은, 바로 또는 최소의 지연으로, 수신기의 전송 버퍼에 전달된다. 결과적 설계는 둘 모두가 더 간단하며, 더 신속한 스타트 업을 야기할 수 있는데, 그 이유는 미디어가 실제 필요 시간에 더 가깝게 전달되기 때문이다.
[0118] 다시 도 15를 참조하면, ROUTE, FLUTE, 또는 다른 파일 전달 프로토콜이 수신기에 전달될 오브젝트들(파일들)을 핸들링할 수 있다. FLUTE의 경우, 이것은 통상적으로 한 번에 하나의 파일이며, 선택적으로 FEC를 갖는 전체 오브젝트이다. ROUTE, 그리고 어쩌면 다른 프로토콜들은 또한, 오브젝트들을 일련의 바이트 범위들로서 전달할 수 있다. 이들 바이트 범위들은 예컨대 불투명한 방식으로 ROUTE 전송기에 전달될 수 있다. ROUTE 전송기는, 바이트 범위를 핸들링하기 위하여 파일 타입을 알 필요가 없다. 이 ROUTE 전송기는 단지, 오브젝트의 바이트 범위를 링크의 다른 단부에 전달한다. 추가로, 어쩌면 확장 헤더에서 표현되는 것으로 위에서 논의된 바와 같이, 오브젝트 및/또는 바이트 범위는, 수신기 전송 버퍼 인터페이스에서, 요구되거나 또는 원하는 전달 시간을 가질 수 있다. 말하자면, 전체 오브젝트가 특정 시간(이는 어쩌면 availabilityStartTime에 따름)까지는, 또는 오브젝트의 일부가 특정 시간(이는 어쩌면 확장 헤더에 따름)까지는, 수신기 전송 버퍼 인터페이스에 전달되어야 할 수 있다. 그것은, 다수의 오브젝트들이 수신기에 대해 동시적인 전달 프로세스에 있을 수 있는 경우이다.
[0119] 이러한 현재 논의는 하나의 전송 버퍼로의 하나의 전달에 대한 것이다. 전달되고 있는 오브젝트들은 DASH 세그먼트들(INTERNATIONAL STANDARD ISO/IEC 23009-1 Second edition 2014-05-01 Information Technology - Dynamic Adaptive Streaming Over HTTP (DASH) Part 1: Media Presentation Description and Segment Formats)일 수 있으며, 파일 타입은 배타적으로, ISO/IEC 14496-12:2012(E), INTERNATIONAL STANDARD ISO/IEC 14496-12 Fourth edition, 2012-07-15 Corrected version 2012-09-15, Information Technology - Coding of Audio-Visual Objects Part 12: ISO Base Media File Format에서 설명된 바와 같이, 스트리밍 미디어에 대한 ISO BMFF일 수 있다.
[0120] "전달될" 오브젝트(들)(예컨대, 파일들)의 파일 타입(들)은 ROUTE 또는 다른 전송기에 의해 알려질 필요가 없지만, 전달되고 있는 파일 타입은 수신기에 대해 중요한 특정 부분들을 가질 수 있다. 도 15에서 "세그먼터"로서 도시된 블록은 전달되고 있는 미디어(바이트 범위들)의 부분들의 중요성을 결정할 수 있으며, 추가로, 단말에서 파일 또는 파일의 부분의 요구되는 전달 시간을 결정할 수 있다. 통상적으로, 클라이언트가 파일을 점진적인 방식으로 소비하도록 하기 위하여, 파일의 프리픽스들은 특정 전달 시간을 갖는다. 따라서, 예에서, 파일의 특정 프리픽스(P1)는 포함된 미디어를 시간(T1)까지 제시하도록 요구받을 수 있다. 제 2 프리픽스(P2 > P1)는 포함된 미디어를 시간(T2 > T1)까지 제시하도록 요구받을 수 있다. 그러한 사용의 경우에 대한 예는, 특정 시간적 지속기간의 ISO BMFF 파일들의 시리즈로서 전송되고 있는 비디오 또는 오디오와 같은 스트리밍 미디어를 활용하여 구성될 수 있다. 이들 소위 세그먼트 파일들 내에서, 특정 바이트 범위가 미디어 플레이어, 이를테면, DASH에 대해 시간적 중요성을 가질 수 있다. 그러한 예는 비디오 프레임 또는 프레임들의 그룹(이는 어쩌면, 앞서 설명된 MDE임)일 수 있다. 일부 코덱 타입들은, 특정 시점에 또는 어쩌면 특정 시점 전에, 단일 출력 비디오 프레임을 생성하기 위하여, 인코더 이미지들의 N개의 프레임들을 요구할 수 있다.
[0121] 세그먼터 또는 유사한 미디어 또는 파일 타입 인지 포맷터(formatter)는 요구되는 전달 시간으로 바이트 범위를 ROUTE 전송 전송기(transport Sender)에 제공할 수 있다. 요구되는 전달 시간은, 세그먼트 또는 세그먼트의 바이트 범위가 전달될 가장 이른 시간 및/또는 가장 늦은 시간 중 어느 한 쪽 또는 둘 모두로서 표현될 수 있다. 이 전달 시간은 특정 바이트 범위에 대해 특정할 필요가 없다. 예컨대, 요건은 "이 바이트 범위가 시간(X) 후에 그리고 시간(Y) 전에 전송 버퍼에 수신되도록, 이 바이트 범위가 전달되어야 한다"는 것을 특정할 수 있으며, 여기서 X는 가장 이른 시간을 표현하고, Y는 가장 늦은 시간을 표현한다. 시간(X) 후의 전송 버퍼로의 전달은, 스트림에 가입할 때 관련될 수 있다. 데이터가 너무 일찍 수신되면, 기간 경계 상에서의 스위치와 같은 가입 이벤트에서, 이 데이터는 잃어버려질 수 있다. 기간 시작을 잃어버림으로써, 수신기는 서비스에 가입할 수 없으며, 이는 나쁜 사용자 경험을 야기한다. 다른 바운드(Y)는 예컨대, 다수의 디바이스들에 걸친 동기적 플레이에 관련될 수 있다. 가설 모델 수신기는 이 전달 바운드에 의해 지시된 것보다 이후에는 미디어를 플레잉하지 않을 수 있다. 가설 수신기는 ROUTE (수신기 전송) 버퍼 사이즈를 가지며, 이는 과소 실행되지도 과잉 실행되지도 않도록 보장된다. 요구되는 버퍼의 실제 사이즈는 예컨대 ROUTE 프로토콜에서 설명된다. 물론, 그것은, 수신기가 재생 시간을 추가로 지연시키기를 원한다면 이 수신기가 더 많은 메모리를 할당할 수 있는 경우이다.
[0122] 이들 시간들(X 및 Y)은 절대적이거나 또는 상대적일 수 있다. 인터페이스에 포스팅된 순간에 대한 상대적 시간이 바람직한 솔루션인 듯하다. 서비스가 불가능한 요청들을 요구하지 않기 위하여, 전송기가 MAC/Phy에 걸친 실제 지연을 결정할 것임이 이해되어야 한다. 일반적인 용어들로, 물리 계층 스케줄러에 대한 임무는 실제 송신 시간보다 상당히 앞서 전송기가 미디어를 포스팅하는 것으로 단순화될 수 있다. MAC/phy 스케줄러가 미디어 데이터를 맵핑해야 하는 시간이 많을수록, 이 MAC/phy 스케줄러는 더 나은 작업을 할 수 있다.
[0123] 세그먼터는, 전달 시간이 Z에 가까워야 한다는 것을 표시할 수 있다. 세그먼터는 또한, 이 시간에 대한 우선순위를 제공할 수 있다. 예컨대, 동일한 ROUTE 전달에서 운반될 두 개의 바이트 범위들이 있을 수 있지만, 이들 중 하나는 시간(Z)에 가깝게 있는 것에 대한 우선순위를 가지며, 이 우선순위가 ROUTE 전송기에, 그리고 후속하여 MAC/phy 인터페이스에 제공되어, MAC/phy 인터페이스가 물리 계층에서의 최적의 전달 순서화를 결정할 수 있다. 우선순위들은 예컨대, 신속하고 일관된 채널 변경 경험을 충족시키기 위하여 도출될 수 있다. 일부 예들에서, ROUTE 세션에 대한 전달 순서는 강제될 수 있는데, 즉, 스케줄러에 전달되는 바이트 범위들/MDE들의 순서는 수신기의 ROUTE 수신기의 입력에서 보존되어야 한다. 예컨대, 구문 엘리먼트(예컨대, 플래그)는, ROUTE 세션의 데이터가 전달 순서로 제공되는지의 여부, 그리고 그러한 전달 순서가 유지되어야 하는지를 표시할 수 있다.
[0124] 따라서, 특정 바이트 범위들이 반-겹쳐진 전달 시간들을 가질 수 있지만, 구문 엘리먼트가, 데이터가 이미 순서대로 있으며 순서가 유지(즉, 보존)되어야 한다는 것을 표시하면, 심지어 비순서적인 전달(out-of-order delivery)이, 전달 시간들을 광고된 바와 같이 여전히 충족시킬 것이라도, 전달 순서는 유지/보존될 필요가 있다. 스케줄러에 선행하는 기능들은, 순서대로 전달이 표시되었다면, 순서대로 전달을 허용하는 이른 전달 시간 및 늦은 전달 시간을 제공할 것으로 예상된다. 이러한 방식으로, 구문 엘리먼트(예컨대, 플래그)는, 예컨대 MAC/phy 인터페이스로부터 클라이언트 디바이스로 미디어 데이터를 전송할 때, 미디어 데이터의 전달 순서가 보존되어야 하는지의 여부를 표시하는 구문 엘리먼트의 예를 표현한다.
[0125] 묘사된 바와 같은 도 15는, 미디어 인코더들, 세그먼터들, ROUTE 전송기, 및 MAC/phy의 캐스케이드(cascade) 주위에서 폐쇄 루프에 기능적인 레이트 제어 메커니즘이 있을 수 있거나 또는 있을 공산이 있음을 도시한다. 이는 공통 구성이며, 다수의 미디어 스트림들은 공통 또는 공유 물리 계층을 통해 동시에 전송된다. 이러한 일반적인 방법은 통계적 멀티플렉싱으로 종종 지칭된다. 일반적인 용어들로 통계적 멀티플렉서는, 더 많은 서비스들을 단일 전달 시스템에 맞추기 위해, 다양한 미디어 스트림들의 통계적 독립을 활용한다. 일반적으로, 미디어 인코더는 정의된 인코딩 구문을 출력한다. 즉, 구문 데이터가 후속하여, 컨테이너 파일들, 이를테면, ISO BMFF에 배치된다. 이들 파일들은 후속하여, ROUTE 또는 FLUTE와 같은 전송 프로토콜에 캡슐화된다. 세그먼터 및 전송기 기능들 둘 모두에 추가되는 증분 데이터, 예컨대, 메타데이터 및 헤더 정보가 있다. MAC/phy에 전달되는 데이터가 세 개의 타입들 전부로 구성되며, 어떤 파일 및/또는 바이트 범위들이, 미디어 인코더들의 제어 하에 있는 어떠한 데이터도 포함하지 않을 수 있지만, 레이트 제어 시스템은 미디어의 사이즈만을 직접적으로 관리할 수 있으며, 일반적으로 신호의 헤더 부분들 또는 메타데이터를 관리하지 않는다.
[0126] 도 17은 송신 시스템에 대한 더 많은 세부사항들을 예시하는 개념적 다이어그램이다. MAC/Phy의 기능들의 현실적인 구현이 도 17에서 도시된다. 물리 계층 스케줄러는 물리 계층의 전달 스케줄링을 푸는데, 즉, 스케줄러는 물리 계층이 전달 면에서 실제로 무엇을 달성할 수 있는지를 결정할 수 있으며, 기저대역에서의 RF 신호의 디스크립션을 정의한다. 이 기저대역 파형은 다수의 송신기들에 분산될 수 있으며, 이 다수의 송신기들은 SFN(single frequency network)을 생성하기 위해 동일한 파형을 동시에 생성할 것이다. 동일한 파형을 동시에 생성하는 이 방법은, FLO 또는 MediaFLO 및 LTE Broadcast/eMBMS와 같은 시스템들에 의해 사용되었다.
[0127] 도 18은 세그먼트 시간들의 스태거링(staggering)을 예시하는 개념적 다이어그램이다. 세그먼트 시간들을 스태거링하는 것은 피크 비트 레이트 요건들을 최소화시킬 수 있다. 피크 대역폭 요구의 가능한 충돌을 최소화시키는 방식으로, 다양한 서비스들의 세그먼트 시간들을 조직화할 필요가 있을 수 있다. 이것은 인터페이스(들)의 설계에는 어떠한 영향도 없으며, 그보다는 개별 스트림들의 조직화에 영향을 끼친다. 세그먼트 경계 시간들의 이러한 조직화는, 도 18에 묘사된 바와 같이 물리 계층에 대한 특정 관계를 가질 수 있다.
[0128] 도 18에서, 물리 계층에 대한 액세스와 같이 세그먼트들은 시간상 선형으로서 묘사된다. 서비스들의 이러한 페이징(phasing)은 RAP들 또는 SAP들의 최소 배치로 평균 데이터 레이트를 평탄화하는 경향이 있다. 인트라(intra) 세그먼트 데이터 레이트들은 프리젠테이션 시간들에 비해 균일하지 않다. 이는, 물리 계층 상의 스케줄링이 실제 스타트 업 지연에 대해 확정적임을 예시하기 위해 제공되는 단 한 개의 예시적 방법이다. 전송은 단지, 마지막 적절한 순간에 또는 마지막 적절한 순간 전에, 스택 위로 미디어를 전달하는 것이다.
[0129] 시스템의 다양한 컴포넌트들 사이의 인터페이스들의 예들이 아래에서 설명된다. 미디어 인코더는 자신과 세그먼터 사이에 노출 인터페이스를 가질 수 있거나 또는 갖지 않을 수 있다. 그러나, 시스템이 그러한 인터페이스를 포함해야 한다면, 세그먼터에 대해 중요한 바이트 범위들은 이산적으로 그리고 직접적으로 세그먼터에 전달될 수 있다. 중요한 양상들은, 전송 버퍼에 곧 전달하기 위한 가장 늦은 전달 시간, 그리고 바이트 범위 또는 오브젝트를 전송 버퍼에 너무 일찍 전달하지 않기 위한 가장 이른 타겟 전달 시간을 포함할 수 있다. 이들 양상들은 세그먼터에 의해 분석적으로 결정될 수 있으며, 이 세그먼터는 인코딩된 미디어를 세그먼트들, 이를테면, ISO BMFF 파일들로 변환한다. 이들 ISO BMFF 파일들은 수신기의 미디어 디코더로의 미디어 프레임들의 전달의 세부사항들을 포함한다. 미디어 인코더 자체의 구문 밖의 이 인터페이스는 연관된 미디어 프레임과 같은 전달되는 특정 미디어 특징의 사이즈, 프리젠테이션 타임 스탬프, 및/또는 디코드 타임 스탬프를 전달할 수 있다.
[0130] 세그먼터와 ROUTE 전송기 사이의 인터페이스는 아래의 정보를 제공할 수 있다:
· 중요한 특징에 대한 적용가능한 바이트 범위 또는 프리픽스
· 특정 미디어 인코더의 대상이 되는, 전달되는 데이터의 부분
· 파일마다 단일 타입의 미디어의 경우, 이는 일 대 일 맵핑이다
· 소위 멀티플렉싱된 세그먼트의 경우, 세그먼트에 미디어를 갖는 미디어 인코더들 각각에 대한 비율의 디스크립션
· 타입 및 어쩌면 어드레스(IP 어드레스 및 포트일 공산이 있음)에 관하여, 소스(들)인 특정 미디어 인코더(들)가 알려지도록 허용하는 식별자들.
· 바이트 범위가 수신기의 전송 버퍼에 가장 이른 특정 시간 이전에는 수신되지 않도록, 이 바이트 범위가 전달될 수 있는 가장 이른 시간.
· 미디어가 전달되어야 하는 타겟 시간 ―이 타겟 시간에 또는 이 타겟 시간 직후에, 미디어가 전달되어야 하며, 따라서 미디어는 전송 버퍼에 정확한 시간에 수신됨―.
· 정확한 타겟 전달 시간에 대하여 이 전달의 다른 미디어 스트림들과 비교할 때 이 미디어 스트림의 상대적 우선순위.
· 바이트 범위가 전달될 수 있는 가장 늦은 시간.
[0131] 전송기와 MAC/phy 사이의 인터페이스는 아래의 정보를 제공할 수 있다:
· 현재 전달에 대한 적용가능한 바이트 범위, 어쩌면 전체 IP 패킷들
· 특정 미디어 인코더의 대상이 되는, 전달되는 미디어의 부분
· 특정 미디어 인코더들의 아이덴티티(들)가 알려지도록 허용하는 식별자(들)
· 전체 바이트 범위가 전달될 수 있는 가장 이른 시간.
· 미디어가 전달되어야 하는 타겟 시간 ―이 타겟 시간에 또는 이 타겟 시간 직후에, 미디어가 전달되어야 하며, 따라서 미디어는 수신기 전송 버퍼에 적절한 시간에 수신됨―.
· 정확한 전달 시간에 대하여 이 전달의 다른 미디어 스트림들과 비교할 때 이 미디어 스트림의 상대적 우선순위.
· 바이트 범위 또는 프리픽스가 수신기의 전송 버퍼에 제때 수신되도록, 이 바이트 범위 또는 프리픽스가 전달될 수 있는 가장 늦은 시간.
[0132] 인터페이스들의 정의된 캐스케이드는 MAC/phy 스케줄러로 하여금 전달될 미디어의 전체 픽처를 갖도록 허용하며, 이는 물리 계층의 스케줄링을 허용할 수 있다. phy/MAC 스케줄러는, 관련 시간 기간(time span)에서 전달되고 있는 미디어 전부를 알 수 있다. 이른 시간이 제공되지 않으면, 타겟은 가장 이른 또는 이른 시간일 수 있으며, 타겟은 동일한 값으로서 셋팅될 수 있다.
[0133] MAC/Phy 계층에 의해 수행되는 예시적 스케줄러 기능성이 아래에서 설명된다. 스케줄러는 유용한 것으로 여겨지는 한 미리 맵핑할 수 있다. 이는 전체 레이턴시를 증가시킬 수 있으며, 이는 일반적으로, 전체 레이턴시가 합리적인 제한치로 유지되는 한, 문제가 아니다. 그러나, 미리 플래닝하는 것은 또한, 증가된 효율성, 그리고 특히, 최적화된 채널 변경을 야기할 수 있다. 가장 늦은 전달에 대한 요구들은, 현재 전송되는 미디어에 대하여 phy 계층에 대한 선택들을 제약한다. phy 계층은 또한, 전달을 위한 분해능 면에서 이산 제한치들을 가질 수 있다. 이는 개별 물리 계층의 특성이며, 주어진 물리 계층에 대해 MAC/phy 스케줄러에 의해 알려진다.
[0134] 도 19는 스트림이 선택적일 수 있는 미디어 데이터 및 필수인 미디어를 포함할 때 타겟 시간과 가장 이른 시간 사이의 차이들을 예시하는 개념적 다이어그램이다. 일반적으로, 스트리밍 미디어의 전달은 타임라인을 갖는다. 미디어가 소비되는 순서가 있다. 어떤 미디어는 선택적일 수 있다. 스트림이 계속해서 수신되고 있다면, 드롭되는 미디어가 잠재적으로 짧고, 스타트 업 때에만 있더라도, 미디어를 드롭하는 것은 바람직하지 않다. 이 특징의 사용은 잠재적으로, 소위 공통 인크립션을 방해할 수 있으며, 따라서 사용은, 일찍 전달되는 데이터가 DRM 또는 파일 CRC(cyclic redundancy code)(잃어버린 미디어로 인해 실패할 수 있음)와 같은 메커니즘들을 방해하지 않는 경우들로 제한되어야 한다. 이른 또는 매우 이른 전달에 대한 가장 개연성 있는 애플리케이션은, 가장 늦은 전달 시간이 물리 계층 스케줄러의 분석의 포워드 시간 깊이를 훨씬 지나서 있는, 즉, 명목 전달 스케줄에 따라 이루어질 수 있는 미디어 및 비-실시간 파일들을 스트리밍하기 위해 물리 계층 용량이 완전히 활용되지 않으며 전달마다 N개의 바이트들이 더 많은 물리 계층 용량을 기회주의적으로 점유할 수 있는 대형 파일 전달이다. 미디어는 타겟 시간 및 가장 늦은 시간을 준수하여 실행되는 것으로 예상될 것이다. 이들 경우들에서의 타겟 시간 및 이른 시간은 동일한 값을 가질 것이다.
[0135] 도 20은 프레임들의 잠재적으로 드롭가능한(droppable) 그룹들을 갖는 비디오 시퀀스의 개념적 다이어그램이다. 이 예에서, 화살표들은 프레임들 사이의 잠재적인 예측을 표현한다. 또한, 번호들의 두 개의 행들이 도 20에 도시된다. 상단 행은 그러한 번호들 위의 프레임들의 상대적 디스플레이 순서들을 표시한다. 번호들의 하단 행은 디스플레이 순서로 식별되는 프레임들의 디코딩 순서를 표시한다. 즉, 제 1 프레임(I-프레임)이 1번째로 디스플레잉 및 디코딩 둘 모두가 이루어지며, 제 1 P-프레임이 8번째로 디스플레잉 및 2번째로 디코딩되며, 제 1 B-프레임이 2번째로 디스플레잉 및 5번째로 디코딩되는 식이다.
[0136] 특정 미디어 엘리먼트들은 선택적인 것으로서 취급될 수 있다. 예컨대, 프레임들의 그룹에서, 비-RAP 프레임들은 선택적인 것으로 간주될 수 있다. 그러나, 도 20에 도시된 바와 같이, 프레임들 사이의 의존성들로 인해, 일부 프레임들이 드롭될 때, 드롭되는 프레임들에 따라 좌우되는 다른 프레임들이 적절하게 디코딩가능하지 않을 것이며, 그러므로 또한 드롭될 수 있다. 도 20에서, 그룹으로서 드롭될 프레임들은 번호들의 하단 행에서 개설된다. 예컨대, 프레임(8)이 드롭되면, (디코딩 순서로) 모든 후속 프레임들이 또한 드롭된다. 다른 한편으로, 프레임(4)이 드롭되면, 프레임들(2, 1, 3, 6, 5, 및 7)이 드롭된다. 마찬가지로, 프레임(2)이 드롭되면, 프레임들(1 및 3)이 또한 드롭된다. 이러한 방식으로, 특정 미디어 엘리먼트들은 선택적인 것으로서 취급될 수 있다.
[0137] 데이터의 블록 전달을 갖는 물리 계층들의 가용성은, MPEG-2 전송을 위해 구현되는 것보다 미디어 전달의 더욱 특정한 맵핑을 가능하게 할 수 있다. 이는, 이번에는, 전달이 phy/MAC 수신기 인터페이스에서 실제 요구되는 시간에 맵핑되도록 허용할 수 있다. 이 특정성은 버퍼링 요건들을 감소시킬 수 있으며, 시작 시간이 통상적인 MPEG-2 TS 버퍼 모델에 따라 좌우되지 않도록 허용할 수 있다. 이는, 이번에는, 채널 변경 시간에서의 전체적인 개선을 야기할 수 있으며, 버퍼 모델을 단순화할 수 있다. 본원에 설명된 인핸스먼트들은 이 방식이 시스템의 네트워크 측에 구현되도록 허용할 수 있다.
[0138] 도 21은 본 개시내용의 기술들에 따른 다른 예시적 시스템을 예시하는 블록 다이어그램이다. 도 21의 예시적 시스템은 도 3, 도 15, 및 도 17과 유사하다. 즉, 도 21의 예는 미디어 인코더, 세그먼터, 전송기, MAC/Phy 스케줄러, 및 익사이터/증폭기를 포함하는 전송기 디바이스, 뿐만 아니라 MAC/Phy 수신기, 트랜스포터, 미디어 플레이어(이를테면, DASH 미디어 플레이어) 및 코덱(예컨대, 디코더)을 포함하는 수신기 디바이스를 포함한다. 도 21은 이들 다양한 컴포넌트들에 대한 전송 버퍼 모델의 예에 관한 더욱 세부적인 사항들을 예시한다.
[0139] 본 개시내용은 다수의 인터페이스들에 걸쳐 있는 바이트 범위들 및 오브젝트들을 설명하기 위한 특정 기술들을 설명한다. 구현의 특정 아키텍처는 인터페이스들 전부를 노출시킬 수 있거나 또는 노출시키지 않을 수 있다. 도출될 수 있는 이득들은, MAC/phy로 하여금 더욱 효율적인 방식으로 스케줄링하도록 허용하는 능력을 포함한다. 추가로, 이들 기술들은 MAC/phy로 하여금, 드롭되는 미디어 없이, 이것이 원하는 능력인 한, 플레잉할 방식으로 스케줄링하도록 허용할 수 있다.
[0140] 이러한 방식으로, 본 개시내용의 기술들은, 적용가능한 대로, 오브젝트들 또는 바이트 범위들에 대해 요구되는 전달 시간들(예컨대, 가장 이른 시간 및/또는 가장 늦은 시간)을 설명하는 정보를 제공하도록 인터페이스들을 구성하는 것을 포함한다. 오브젝트들은 세그먼트들(즉, DASH에 따라 독립적으로 리트리빙가능한 파일들)에 대응할 수 있으며, 바이트 범위들은 세그먼트들의 바이트 범위들에 대응할 수 있다. 오브젝트 또는 바이트 범위에 대한 원하는 전달 시간을 설명하는 정보는, 전달의 다른 미디어 스트림들에 대한, 그리고/또는 이 MAC/phy 자원 상의 다른 서비스들에 대한 오브젝트/바이트 범위의 상대적 우선순위를 포함할 수 있다. 다른 미디어 스트림들에 대한 상대적 우선순위는 예컨대, 동일한 미디어 콘텐츠의 오디오 및/또는 타이밍된 텍스트 스트림들에 대한 비디오 데이터의 우선순위를 설명할 수 있다. 정보는 또한, 가장 늦은 전달 시간을 설명할 수 있다. 정보는 가장 이른 전달 시간을 추가로 설명할 수 있으며, 이 가장 이른 전달 시간은, 오브젝트/바이트 범위 및 다른 오브젝트/바이트 범위들을 인코딩한 인코더의 경우, 다른 바이트 범위들에 대한 상대적 우선순위를 포함할 수 있다. 정보는 또한, 특정 인코더(인코더에 대한 타입 및/또는 인코더의 어드레스를 포함할 수 있음)의 대상이 되는 바이트 범위 또는 오브젝트의 부분을 설명할 수 있다.
[0141] 본 개시내용의 기술들은 인코더와 세그먼터/패키저(packager), 세그먼터들와 전송기들(예컨대, ROUTE 및/또는 FLUTE 프로토콜들을 구현하는 전송기들), 그리고 MAC/phy 계층 디바이스들 사이의 인터페이스들을 더 포함할 수 있다.
[0142] 도 22는 미디어 전달 이벤트들의 획득을 위한 예시적 기술을 예시하는 흐름도이다. 즉, 도 22는 스트리밍 미디어 서비스를 달성하기 위한 예시적 데이터 및 연관된 이벤트들을 도시한다. 도 22의 기술들은 예컨대, 수신기 디바이스, 이를테면, 도 3의 MAC/Phy 수신기 또는 ROUTE 수신기에 의해 수행될 수 있다. 이 예에서, 이벤트들의 두 개의 시퀀스들이 있다. 제 1 그룹핑은 물리 계층에 관련된다. 스케줄러는, 예컨대, SLT(service list table), 그리고 부트스트랩 및 프리앰블 후에 매우 시간적으로 근접하게 발생할 필요가 있는 시간을 포함하는 패킷들을 결정하도록 구성될 수 있다. 이는, 관련 패킷(들)을 "프리앰블 직후에 FEC 프레임(들)에서 전송하기"로서 식별함으로써 지원될 것이다. 부트스트랩 및 프리앰블의 순환적인 시간적 위치는, 대기 상태들을 최소화시키기 위하여, 미디어 T-RAP 타임라인에 정렬될 공산이 있다. 다수의 스태거링된 미디어 시작 시간들 및 T-RAP들은, 채널 변경 시간을 최소화시키기 위해 다수의 부트스트랩들 및 연관된 시그널링이 요구될 것을 요구할 수 있다. ROHC-U(robust header compression in unidirectional mode) 헤더 압축이 활용되고 있다면, T-RAP를 기능적으로 식별하기 위해 콘텍스트 리프레시를 동기화할 필요가 있을 수 있다. 이는 도 22에 도시된 바와 같이 선택적으로 지원되어야 한다.
[0143] 부가하여, T-RAP의 존재를 시그널링하는 데이터가 존재할 수 있다. 즉, 제 1 유닛, 이를테면, 위의 예들에서 도시된 세그먼터 또는 전송기는, 세그먼트 또는 세그먼트의 바이트 범위가 T-RAP를 포함한다는 것을 시그널링할 수 있다. 이 데이터는 세그먼트 자체와는 별개일 수 있는데, 예컨대, 세그먼트와는 별개인 메타데이터일 수 있다. 따라서, 제 2 유닛, 이를테면, 전송기 또는 MAC/Phy 유닛은, 세그먼트 또는 세그먼트 자체의 바이트 범위를 검사할 필요성 없이, 세그먼트 또는 세그먼트의 바이트 범위가 T-RAP를 포함한다고 결정할 수 있다. 대안적으로, 제 2 유닛은, 기존 구문 엘리먼트들로부터 T-RAP가 존재한다고 결정할 수 있다.
[0144] 도 22에 도시된 바와 같이, 예컨대, 도 1, 도 3, 도 8, 도 14, 도 15, 도 17, 및 도 21에 대하여 위에서 논의된 바와 같이 전송기 디바이스에 의해 수행될 수 있는 미디어 전달 이벤트들의 획득을 위한 예시적 기술은, 부트스트랩 검출, 프리앰블 수신, 선택적인 ROHC-U와 함께 SLT 및 시간 PLP(들)의 획득, 그리고 서비스 PLP들의 획득을 포함할 수 있으며, 이들 전부는 대기 상태들을 최소화시키기 위해 시간적으로 그룹 전달을 활용할 수 있다. PLP(들)는 BS/프리앰블 후의 1번째 PLP(들)일 수 있다. 부가하여, 기술은 MPD 수신, IS 수신, 미디어 세그먼트 수신, 및 미디어 재생을 포함할 수 있다. T-RAP를 통한 그룹 전달이, 대기 상태들을 최소화시키기 위해 사용될 수 있다.
[0145] 도 23은 본 개시내용의 기술들에 따라 미디어 데이터를 전송하기 위한 예시적 방법을 예시하는 흐름도이다. 특히, 이 예는 일반적으로, 미디어 데이터에 대한 설명 정보와 함께, 서버 미디어 데이터의 제 1 유닛으로부터 서버의 제 2 유닛으로 미디어 데이터를 전송하는 단계를 포함하는 방법에 관한 것이다. 설명 정보는 일반적으로, 미디어 데이터가 제 2 유닛에 의해 클라이언트 디바이스에 전달될 수 있을 때를 표시한다. 제 1 유닛은 예컨대 세그먼터(이를테면, 도 3, 도 8, 도 15, 도 17, 및 도 21의 세그먼터들) 또는 전송기(이를테면, 도 3, 도 8, 도 15, 도 17, 및 도 21의 전송기)에 대응할 수 있다. 대안적으로, 제 1 유닛은 전송기(이를테면, 도 3, 도 8, 도 15, 도 17, 및 도 21의 전송기들)에 대응할 수 있으며, 제 2 유닛은 MAC/phy 유닛(이를테면, 도 3, 도 8, 도 15, 및 도 21의 MAC/phy 유닛들, 또는 도 17의 물리 계층 스케줄러)에 대응할 수 있다.
[0146] 도 23의 예에서, 초기에, 제 1 유닛은 RAP(random access point)들 및 이 RAP들 중 적어도 하나에 바로 선행하는 매니페스트 파일을 갖는 세그먼트들을 포함하는 비트스트림을 생성한다(150). 매니페스트 파일은 예컨대 MPD(media presentation description)를 포함할 수 있다. 이 예에서, 제 1 유닛이 비트스트림을 생성하지만, 다른 예들에서는, 제 1 유닛이 단순히, 생성된 비트스트림을 예컨대 콘텐츠 준비 디바이스(20)(도 1)로부터 수신할 수 있다는 것이 이해되어야 한다. 일부 예들에서, 제 1 유닛은 비트스트림을 수신하며, 이후, 예컨대 도 10에 도시된 바와 같이, 예컨대 RAP들 중 적어도 하나의 RAP 직전에 매니페스트 파일을 삽입하기 위해, 비트스트림을 조작할 수 있다.
[0147] 이후, 제 1 유닛은 비트스트림의 미디어 데이터에 대한 설명 정보를 서버 디바이스의 제 2 유닛에 전송한다. 설명 정보는 미디어 데이터의 세그먼트들 중 하나의 세그먼트 또는 세그먼트들 중 적어도 하나의 세그먼트의 바이트 범위 중 적어도 하나, 그리고 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 세그먼트 또는 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간 중 적어도 하나를 표시한다(152). 설명 정보는 위의 설명들에 따를 수 있다. 예컨대, 설명 정보는 특정 미디어 인코더의 대상이 되는 세그먼트 또는 바이트 범위의 부분, 타겟 시간 ―세그먼트 또는 바이트 범위는 이 타겟 시간에, 또는 이 타겟 시간 직후에 전달되어야 함―, 세그먼트 또는 바이트 범위가 전달될 수 있는 가장 늦은 시간, 세그먼트 또는 바이트 범위 내의 데이터에 대한 프리젠테이션 타임 스탬프, 미디어 스트림들의 데이터에 대한 타겟 전달 시간들에 대하여 다른 미디어 스트림들에 관련한, 세그먼트를 포함하는 미디어 스트림의 우선순위, 및/또는 세그먼트 또는 바이트 범위 내의 데이터에 대한 디코드 타임 스탬프 중 임의의 것 또는 전부를 포함할 수 있다. 부가하여, 설명 정보(관련 메타데이터)는, 세그먼트 또는 세그먼트의 바이트 범위가 T-RAP를 포함한다는 표시를 포함할 수 있다. 대안적으로, 제 1 유닛은 T-RAP의 존재를 시그널링하는, 설명 정보와는 별개의 데이터를 전송할 수 있다. 제 1 유닛은 또한, 미디어 데이터(예컨대, 비트스트림 또는 하나 또는 그 초과의 세그먼트들, 또는 세그먼트들의 부분들)를 제 2 유닛에 전송한다(154).
[0148] 제 1 유닛은 또한, 제 2 유닛으로부터 클라이언트 디바이스로 미디어 데이터를 전송할 때, 미디어 데이터의 전달 순서가 보존되어야 하는지의 여부를 표시하는 구문 엘리먼트를 제 2 유닛에 전송할 수 있다(156). 예컨대, 구문 엘리먼트는, 위에서 논의된 바와 같이, ROUTE 세션의 데이터가 전달 순서로 제공되는지의 여부, 그리고 전달 순서가 유지/보존되어야 하는지를 표시하는 1-비트 플래그일 수 있다.
[0149] 이후, 제 2 유닛은 세그먼트 또는 세그먼트의 바이트 범위를 클라이언트 디바이스에 전송할 수 있고, 여기서 클라이언트 디바이스는 서버 디바이스와는 별개이며, 따라서 설명 정보에 의해 표시된 바와 같이, 세그먼트 또는 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 세그먼트 또는 바이트 범위가 전달될 수 있는 가장 늦은 시간에 기반하여 특정 시간부터, 클라이언트 디바이스는 미디어 데이터(즉, 세그먼트 또는 세그먼트의 바이트 범위)를 수신한다(158). 예컨대, 제 2 유닛은, 가장 이른 시간 후에 세그먼트 또는 세그먼트의 바이트 범위가 전달되며, 그리고/또는 가장 늦은 시간 전에 세그먼트 또는 바이트 범위가 전달될 수 있다는 것을 보장할 수 있다. 따라서, 제 2 유닛은, 클라이언트가 세그먼트 또는 바이트 범위를 사용할 수 있는 시간에 세그먼트 또는 바이트 범위가 전달된다는 것을 보장할 수 있다.
[0150] 하나 또는 그 초과의 예들에서, 설명된 기능들은 하드웨어, 소프트웨어, 펌웨어, 또는 이들의 임의의 조합으로 구현될 수 있다. 소프트웨어로 구현된다면, 기능들은 하나 또는 그 초과의 명령들 또는 코드로서 컴퓨터-판독가능 매체 상에 저장되거나 또는 송신되며, 하드웨어-기반 프로세싱 유닛에 의해 실행될 수 있다. 컴퓨터-판독가능 매체는 데이터 저장 매체와 같은 유형의 매체에 대응하는 컴퓨터-판독가능 저장 매체, 또는 예컨대 통신 프로토콜에 따라 한 장소로부터 다른 장소로의 컴퓨터 프로그램의 전송을 용이하게 하는 임의의 매체를 포함하는 통신 매체를 포함할 수 있다. 이러한 방식으로, 컴퓨터-판독가능 매체는 일반적으로, (1) 비-일시적인 유형의 컴퓨터-판독가능 저장 매체, 또는 (2) 신호 또는 반송파와 같은 통신 매체에 대응할 수 있다. 데이터 저장 매체는, 본 개시내용에 설명된 기술들의 구현을 위한 명령들, 코드, 및/또는 데이터 구조들을 리트리빙하기 위해 하나 또는 그 초과의 컴퓨터들 또는 하나 또는 그 초과의 프로세서들이 액세싱할 수 있는 임의의 가용 매체일 수 있다. 컴퓨터 프로그램 제품은 컴퓨터-판독가능 매체를 포함할 수 있다.
[0151] 제한이 아닌 예로서, 그러한 컴퓨터-판독가능 저장 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광학 디스크 스토리지, 자기 디스크 스토리지, 또는 다른 자기 저장 디바이스들, 플래시 메모리, 또는 원하는 프로그램 코드를 명령들 또는 데이터 구조들의 형태로 저장하기 위해 사용될 수 있으며 컴퓨터가 액세싱할 수 있는 임의의 다른 매체를 포함할 수 있다. 또한, 임의의 연결이 적절하게 컴퓨터-판독가능 매체로 불린다. 예컨대, 명령들이 웹사이트, 서버, 또는 다른 원격 소스로부터 동축 케이블, 광섬유 케이블, 연선, DSL(digital subscriber line), 또는 적외선, 라디오, 및 마이크로파와 같은 무선 기술들을 사용하여 송신되면, 동축 케이블, 광섬유 케이블, 연선, DSL, 또는 적외선, 라디오, 및 마이크로파와 같은 무선 기술들이 매체의 정의에 포함된다. 그러나, 컴퓨터-판독가능 저장 매체 및 데이터 저장 매체가 연결들, 반송파들, 신호들, 또는 다른 일시적 매체를 포함하는 것이 아니라, 대신에 비-일시적인 유형의 저장 매체에 관한 것임이 이해되어야 한다. 본원에서 사용되는 디스크(disk) 및 디스크(disc)는 콤팩트 디스크(CD;compact disc), 레이저 디스크(disc), 광학 디스크(disc), 디지털 다기능 디스크(DVD;digital versatile disc), 플로피 디스크(disk) 및 블루-레이 디스크(disc)를 포함하며, 여기서 디스크(disk)들은 대개 자기적으로 데이터를 재생하는 반면에 디스크(disc)들은 레이저들을 이용하여 광학적으로 데이터를 재생한다. 이들의 조합들이 또한, 컴퓨터-판독가능 매체의 범위 내에 포함되어야 한다.
[0152] 명령들은 하나 또는 그 초과의 프로세서들, 이를테면, 하나 또는 그 초과의 DSP(digital signal processor)들, 범용 마이크로프로세서들, ASIC(application specific integrated circuit)들, FPGA(field programmable logic array)들, 또는 다른 등가의 집적된 또는 이산의 로직 회로소자에 의해 실행될 수 있다. 이에 따라, 본원에 사용된 "프로세서"란 용어는, 전술된 구조 또는 본원에 설명된 기술들의 구현에 적절한 임의의 다른 구조 중 임의의 구조를 지칭할 수 있다. 부가하여, 일부 양상들에서, 본원에 설명된 기능성은, 인코딩 및 디코딩을 위해 구성된 전용 하드웨어 및/또는 소프트웨어 모듈들 내에 제공되거나, 또는 결합된 코덱에 통합될 수 있다. 또한, 기술들은 하나 또는 그 초과의 회로들 또는 로직 엘리먼트들로 완전히 구현될 수 있다.
[0153] 본 개시내용의 기술들은 무선 핸드세트, IC(integrated circuit) 또는 IC들의 세트(예컨대, 칩셋)를 포함하여 매우 다양한 디바이스들 또는 장치들에서 구현될 수 있다. 본 개시내용에서, 다양한 컴포넌트들, 모듈들, 또는 유닛들은 개시된 기술들을 수행하도록 구성된 디바이스들의 기능적 양상들을 강조하도록 설명되지만, 반드시 상이한 하드웨어 유닛들에 의한 구현을 요구하는 것은 아니다. 그보다는, 위에서 설명된 바와 같이, 다양한 유닛들은 적절한 소프트웨어 및/또는 펌웨어와 함께, 위에서 설명된 하나 또는 그 초과의 프로세서들을 비롯하여 상호작용적인 하드웨어 유닛들의 집합에 의해 제공되거나 또는 코덱 하드웨어 유닛에 결합될 수 있다.
[0154] 다양한 예들이 설명되었다. 이들 및 다른 예들은 아래의 청구항들의 범위 내에 있다.

Claims (38)

  1. 미디어 데이터를 전송하는 방법으로서,
    상기 방법은,
    서버 디바이스의 제 1 유닛이,
    미디어 데이터에 대한 설명(descriptive) 정보를 상기 서버 디바이스의 제 2 유닛에 전송하는 단계 ―상기 설명 정보는 상기 미디어 데이터의 세그먼트 또는 상기 세그먼트의 바이트 범위 중 적어도 하나, 그리고 상기 세그먼트 또는 상기 세그먼트의 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 상기 세그먼트 또는 상기 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간 중 적어도 하나를 표시함―; 및
    상기 미디어 데이터를 상기 제 2 유닛에 전송하는 단계
    를 포함하는,
    미디어 데이터를 전송하는 방법.
  2. 제 1 항에 있어서,
    상기 제 2 유닛으로부터 클라이언트 디바이스로 상기 미디어 데이터를 전송할 때, 상기 미디어 데이터의 전달 순서가 보존되어야 하는지의 여부를 표시하는 구문 엘리먼트를 상기 제 2 유닛에 전송하는 단계
    를 더 포함하는,
    미디어 데이터를 전송하는 방법.
  3. 제 1 항에 있어서,
    상기 설명 정보는 특정 미디어 인코더의 대상이 되는 상기 세그먼트 또는 상기 바이트 범위의 부분(fraction)을 추가로 표시하는,
    미디어 데이터를 전송하는 방법.
  4. 제 1 항에 있어서,
    상기 설명 정보는 타겟 시간을 추가로 표시하며, 상기 세그먼트 또는 상기 바이트 범위는 상기 타겟 시간에, 또는 상기 타겟 시간 직후에 전달되어야 하는,
    미디어 데이터를 전송하는 방법.
  5. 제 1 항에 있어서,
    상기 설명 정보는, 미디어 스트림들의 데이터에 대한 타겟 전달 시간들에 대하여 다른 미디어 스트림들에 관련한, 상기 세그먼트를 포함하는 미디어 스트림의 우선순위를 추가로 표시하는,
    미디어 데이터를 전송하는 방법.
  6. 제 5 항에 있어서,
    상기 미디어 스트림은 비디오 스트림을 포함하며, 상기 다른 미디어 스트림들은 상기 비디오 스트림에 관련된 오디오 스트림을 포함하는,
    미디어 데이터를 전송하는 방법.
  7. 제 5 항에 있어서,
    상기 미디어 스트림은 오디오 스트림을 포함하며, 상기 다른 미디어 스트림들은 상기 오디오 스트림에 관련된 비디오 스트림을 포함하는,
    미디어 데이터를 전송하는 방법.
  8. 제 5 항에 있어서,
    상기 미디어 스트림은 상기 다른 미디어 스트림들을 비롯하여 복수의 스트림들 중 하나를 포함하며, 상기 복수의 스트림들 각각은 동일한 미디어 콘텐츠에 관련되며, 상기 복수의 스트림들은 하나 또는 그 초과의 비디오 스트림들 및 하나 또는 그 초과의 오디오 스트림들을 포함하는,
    미디어 데이터를 전송하는 방법.
  9. 제 8 항에 있어서,
    상기 복수의 스트림들은 하나 또는 그 초과의 타이밍된(timed) 텍스트 스트림들을 더 포함하는,
    미디어 데이터를 전송하는 방법.
  10. 제 1 항에 있어서,
    상기 설명 정보는 상기 세그먼트 또는 상기 바이트 범위가 전달될 수 있는 가장 늦은 시간, 상기 세그먼트 또는 상기 바이트 범위 내의 데이터에 대한 프리젠테이션 타임 스탬프, 또는 상기 세그먼트 또는 상기 바이트 범위 내의 데이터에 대한 디코드 타임 스탬프 중 적어도 하나를 추가로 표시하는,
    미디어 데이터를 전송하는 방법.
  11. 제 1 항에 있어서,
    상기 제 1 유닛은 세그먼터(segmenter)를 포함하며, 상기 제 2 유닛은 전송기를 포함하는,
    미디어 데이터를 전송하는 방법.
  12. 제 1 항에 있어서,
    상기 제 1 유닛은 전송기를 포함하며, 상기 제 2 유닛은 MAC/phy 유닛을 포함하는,
    미디어 데이터를 전송하는 방법.
  13. 제 1 항에 있어서,
    상기 서버 디바이스와는 별개인 클라이언트 디바이스가 단지 상기 설명 정보에 의해 표시된 상기 가장 이른 시간 또는 상기 가장 늦은 시간에 기반하여 특정 시간부터 미디어 데이터를 수신하도록, 상기 제 2 유닛이 상기 세그먼트 또는 상기 세그먼트의 바이트 범위를 상기 클라이언트 디바이스에 전송하는 단계
    를 더 포함하는,
    미디어 데이터를 전송하는 방법.
  14. 제 13 항에 있어서,
    상기 서버 디바이스와 상기 클라이언트 디바이스 사이의 지연을 결정하는 단계
    를 더 포함하며,
    상기 전송하는 단계는 상기 가장 이른 시간 또는 상기 가장 늦은 시간, 및 결정된 지연에 기반하여 상기 세그먼트 또는 상기 바이트 범위를 전송하는 단계를 포함하는,
    미디어 데이터를 전송하는 방법.
  15. 제 1 항에 있어서,
    상기 미디어 데이터를 설명하는 매니페스트 파일이 상기 미디어 데이터의 RAP(random access point)에 바로 선행하도록, 상기 매니페스트 파일을 포함하는 비트스트림을 생성하는 단계
    를 더 포함하는,
    미디어 데이터를 전송하는 방법.
  16. 제 15 항에 있어서,
    상기 비트스트림을 생성하는 단계는 상기 매니페스트 파일에 바로 선행하는 ROHC(robust header compression) 콘텍스트 초기화 데이터를 포함하는 비트스트림을 생성하는 단계를 포함하는,
    미디어 데이터를 전송하는 방법.
  17. 제 16 항에 있어서,
    상기 ROHC 콘텍스트 초기화 데이터는 상기 비트스트림을 전송하기 위해 사용되는 ROUTE(Real-Time Object Delivery over Unidirectional Transport) 세션에 대한 것인,
    미디어 데이터를 전송하는 방법.
  18. 제 17 항에 있어서,
    상기 ROUTE 세션에 포함된 하나 또는 그 초과의 LCT(layered coding transport) 세션들에 대한 ROHC 콘텍스트 초기화 데이터를 생성하는 단계
    를 더 포함하는,
    미디어 데이터를 전송하는 방법.
  19. 제 16 항에 있어서,
    상기 ROHC 콘텍스트 초기화 데이터는 상기 비트스트림을 전송하기 위해 사용되는 하나 또는 그 초과의 LCT(layered coding transport) 세션들에 대한 것인,
    미디어 데이터를 전송하는 방법.
  20. 제 16 항에 있어서,
    ROHC-U(ROHC in unidirectional mode) 압축이 사용될 때 콘텍스트 리프레시를 동기화하는 단계
    를 더 포함하는,
    미디어 데이터를 전송하는 방법.
  21. 제 15 항에 있어서,
    상기 매니페스트 파일은 DASH(Dynamic Adaptive Streaming over HTTP)에 따른 MPD(media presentation description)를 포함하는,
    미디어 데이터를 전송하는 방법.
  22. 제 1 항에 있어서,
    하나 또는 그 초과의 네트워크 프로토콜들에 따른 데이터와 함께 세그먼트 또는 바이트 범위를 캡슐화하는 단계
    를 더 포함하며,
    상기 가장 이른 시간 또는 상기 가장 늦은 시간을 표시하는 상기 설명 정보는 상기 하나 또는 그 초과의 네트워크 프로토콜들에 따른 데이터에 또한 적용되는,
    미디어 데이터를 전송하는 방법.
  23. 미디어 데이터를 송신하기 위한 서버 디바이스로서,
    상기 디바이스는,
    제 1 유닛, 및
    제 2 유닛
    을 포함하며,
    상기 제 1 유닛은,
    미디어 데이터에 대한 설명 정보를 상기 서버 디바이스의 상기 제 2 유닛에 전송하고 ―상기 설명 정보는 상기 미디어 데이터의 세그먼트 또는 상기 세그먼트의 바이트 범위, 그리고 상기 세그먼트 또는 상기 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 상기 세그먼트 또는 상기 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간을 표시함―; 그리고
    상기 미디어 데이터를 상기 제 2 유닛에 전송하도록
    구성된 하나 또는 그 초과의 프로세싱 유닛들을 포함하는,
    미디어 데이터를 송신하기 위한 서버 디바이스.
  24. 제 23 항에 있어서,
    상기 제 1 유닛은 세그먼터를 포함하며, 상기 제 2 유닛은 전송기를 포함하는,
    미디어 데이터를 송신하기 위한 서버 디바이스.
  25. 제 23 항에 있어서,
    상기 제 1 유닛은 전송기를 포함하며, 상기 제 2 유닛은 MAC/phy 유닛을 포함하는,
    미디어 데이터를 송신하기 위한 서버 디바이스.
  26. 제 23 항에 있어서,
    상기 설명 정보는 특정 미디어 인코더의 대상이 되는 상기 세그먼트 또는 상기 바이트 범위의 부분, 타겟 시간 ―상기 세그먼트 또는 상기 바이트 범위는 상기 타겟 시간에, 또는 상기 타겟 시간 직후에 전달되어야 함―, 상기 세그먼트 또는 상기 바이트 범위가 전달될 수 있는 가장 늦은 시간, 상기 세그먼트 또는 상기 바이트 범위 내의 데이터에 대한 프리젠테이션 타임 스탬프, 또는 상기 세그먼트 또는 상기 바이트 범위 내의 데이터에 대한 디코드 타임 스탬프 중 적어도 하나를 추가로 표시하는,
    미디어 데이터를 송신하기 위한 서버 디바이스.
  27. 제 23 항에 있어서,
    상기 설명 정보는, 미디어 스트림들의 데이터에 대한 타겟 전달 시간들에 대하여 다른 미디어 스트림들에 관련한, 상기 세그먼트를 포함하는 미디어 스트림의 우선순위를 추가로 표시하는,
    미디어 데이터를 송신하기 위한 서버 디바이스.
  28. 제 23 항에 있어서,
    상기 제 1 유닛의 하나 또는 그 초과의 프로세서들은, 상기 미디어 데이터를 설명하는 매니페스트 파일이 상기 미디어 데이터의 RAP(random access point)에 바로 선행하고 ROHC(robust header compression) 콘텍스트 초기화 데이터가 상기 매니페스트 파일에 바로 선행하도록, 상기 매니페스트 파일을 포함하는 비트스트림을 생성하도록 추가로 구성되는,
    미디어 데이터를 송신하기 위한 서버 디바이스.
  29. 미디어 데이터를 송신하기 위한 서버 디바이스로서,
    상기 디바이스는,
    제 1 유닛, 및
    제 2 유닛
    을 포함하며,
    상기 제 1 유닛은,
    미디어 데이터에 대한 설명 정보를 상기 서버 디바이스의 상기 제 2 유닛에 전송하기 위한 수단 ―상기 설명 정보는 상기 미디어 데이터의 세그먼트 또는 상기 세그먼트의 바이트 범위, 그리고 상기 세그먼트 또는 상기 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 상기 세그먼트 또는 상기 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간을 표시함―; 및
    상기 미디어 데이터를 상기 제 2 유닛에 전송하기 위한 수단
    을 포함하는,
    미디어 데이터를 송신하기 위한 서버 디바이스.
  30. 제 29 항에 있어서,
    상기 설명 정보는 특정 미디어 인코더의 대상이 되는 상기 세그먼트 또는 상기 바이트 범위의 부분, 타겟 시간 ―상기 세그먼트 또는 상기 바이트 범위는 상기 타겟 시간에, 또는 상기 타겟 시간 직후에 전달되어야 함―, 상기 세그먼트 또는 상기 바이트 범위가 전달될 수 있는 가장 늦은 시간, 상기 세그먼트 또는 상기 바이트 범위 내의 데이터에 대한 프리젠테이션 타임 스탬프, 또는 상기 세그먼트 또는 상기 바이트 범위 내의 데이터에 대한 디코드 타임 스탬프 중 적어도 하나를 추가로 표시하는,
    미디어 데이터를 송신하기 위한 서버 디바이스.
  31. 제 29 항에 있어서,
    상기 설명 정보는, 미디어 스트림들의 데이터에 대한 타겟 전달 시간들에 대하여 다른 미디어 스트림들에 관련한, 상기 세그먼트를 포함하는 미디어 스트림의 우선순위를 추가로 표시하는,
    미디어 데이터를 송신하기 위한 서버 디바이스.
  32. 제 29 항에 있어서,
    상기 제 1 유닛은,
    상기 미디어 데이터를 설명하는 매니페스트 파일이 상기 미디어 데이터의 RAP(random access point)에 바로 선행하도록, 상기 매니페스트 파일을 포함하는 비트스트림을 생성하기 위한 수단; 및
    상기 매니페스트 파일에 바로 선행하는 ROHC(robust header compression) 콘텍스트 초기화 데이터를 생성하기 위한 수단
    을 더 포함하는,
    미디어 데이터를 송신하기 위한 서버 디바이스.
  33. 명령들이 저장된 컴퓨터-판독가능 저장 매체로서,
    상기 명령들은, 실행될 때, 서버 디바이스의 제 1 유닛의 프로세서로 하여금,
    미디어 데이터에 대한 설명 정보를 상기 서버 디바이스의 제 2 유닛에 전송하게 하고 ―상기 설명 정보는 상기 미디어 데이터의 세그먼트 또는 상기 세그먼트의 바이트 범위 중 적어도 하나, 그리고 상기 세그먼트 또는 상기 세그먼트의 바이트 범위가 전달될 수 있는 가장 이른 시간 또는 상기 세그먼트 또는 상기 세그먼트의 바이트 범위가 전달될 수 있는 가장 늦은 시간 중 적어도 하나를 표시함―; 그리고
    상기 미디어 데이터를 상기 제 2 유닛에 전송하게 하는,
    컴퓨터-판독가능 저장 매체.
  34. 제 33 항에 있어서,
    상기 설명 정보는 특정 미디어 인코더의 대상이 되는 상기 세그먼트 또는 상기 바이트 범위의 부분, 타겟 시간 ―상기 세그먼트 또는 상기 바이트 범위는 상기 타겟 시간에, 또는 상기 타겟 시간 직후에 전달되어야 함―, 상기 세그먼트 또는 상기 바이트 범위가 전달될 수 있는 가장 늦은 시간, 상기 세그먼트 또는 상기 바이트 범위 내의 데이터에 대한 프리젠테이션 타임 스탬프, 또는 상기 세그먼트 또는 상기 바이트 범위 내의 데이터에 대한 디코드 타임 스탬프 중 적어도 하나를 추가로 표시하는,
    컴퓨터-판독가능 저장 매체.
  35. 제 33 항에 있어서,
    상기 설명 정보는, 미디어 스트림들의 데이터에 대한 타겟 전달 시간들에 대하여 다른 미디어 스트림들에 관련한, 상기 세그먼트를 포함하는 미디어 스트림의 우선순위를 추가로 표시하는,
    컴퓨터-판독가능 저장 매체.
  36. 제 33 항에 있어서,
    상기 프로세서로 하여금,
    상기 미디어 데이터를 설명하는 매니페스트 파일이 상기 미디어 데이터의 RAP(random access point)에 바로 선행하도록, 상기 매니페스트 파일을 포함하는 비트스트림을 생성하게 하고; 그리고
    상기 매니페스트 파일에 바로 선행하는 ROHC(robust header compression) 콘텍스트 초기화 데이터를 생성하게 하는 명령들
    을 더 포함하는,
    컴퓨터-판독가능 저장 매체.
  37. 제 1 항에 있어서,
    상기 세그먼트 또는 상기 세그먼트의 바이트 범위가 T-RAP(Transport Random Access Point)를 포함하는 것을 표시하는 데이터를 시그널링하는 단계
    를 더 포함하는,
    미디어 데이터를 전송하는 방법.
  38. 제 1 항에 있어서,
    기존 구문 데이터로부터 상기 세그먼트 또는 상기 세그먼트의 바이트 범위가 T-RAP(Transport Random Access Point)를 포함한다고 결정하는 단계
    를 더 포함하는,
    미디어 데이터를 전송하는 방법.
KR1020177014794A 2014-12-05 2015-12-04 멀티미디어 및 파일 전송을 위한 전송 인터페이스 KR20170089863A (ko)

Applications Claiming Priority (9)

Application Number Priority Date Filing Date Title
US201462088351P 2014-12-05 2014-12-05
US62/088,351 2014-12-05
US201562102930P 2015-01-13 2015-01-13
US62/102,930 2015-01-13
US201562209620P 2015-08-25 2015-08-25
US62/209,620 2015-08-25
US14/958,086 US20160164943A1 (en) 2014-12-05 2015-12-03 Transport interface for multimedia and file transport
US14/958,086 2015-12-03
PCT/US2015/064055 WO2016090280A1 (en) 2014-12-05 2015-12-04 Transport interface for multimedia and file transport

Publications (1)

Publication Number Publication Date
KR20170089863A true KR20170089863A (ko) 2017-08-04

Family

ID=55229794

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020177014794A KR20170089863A (ko) 2014-12-05 2015-12-04 멀티미디어 및 파일 전송을 위한 전송 인터페이스

Country Status (5)

Country Link
US (1) US20160164943A1 (ko)
KR (1) KR20170089863A (ko)
CN (1) CN107005729A (ko)
TW (1) TWI668982B (ko)
WO (1) WO2016090280A1 (ko)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101740451B1 (ko) * 2014-12-10 2017-05-26 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10667004B2 (en) * 2014-12-22 2020-05-26 Lg Electronics Inc. Broadcasting signal reception device, and broadcasting signal reception method based on pull mode
US10142233B2 (en) * 2015-01-21 2018-11-27 Lg Electronics Inc. Apparatus for transmitting broadcast signal, apparatus for receiving broadcast signal, method for transmitting broadcast signal and method for receiving broadcast signal
US10721505B2 (en) * 2015-01-21 2020-07-21 Lg Electronic Inc. Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
EP3255858A4 (en) * 2015-02-04 2018-07-11 LG Electronics Inc. Broadcast signal transmitting device, broadcast signal receiving device, broadcast signal transmitting method, and broadcast signal receiving method
CN106105150B (zh) 2015-03-01 2020-11-06 Lg 电子株式会社 用于发送广播信号的设备、用于接收广播信号的设备、发送广播信号的方法和接收广播信号的方法
WO2016153241A1 (ko) 2015-03-23 2016-09-29 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
US10469919B2 (en) * 2015-04-07 2019-11-05 Lg Electronics Inc. Broadcast signal transmission apparatus, broadcast signal reception apparatus, broadcast signal transmission method, and broadcast signal reception method
WO2017123044A1 (ko) * 2016-01-14 2017-07-20 엘지전자(주) 방송 신호 송수신 장치 및 방법
WO2017141701A1 (ja) * 2016-02-15 2017-08-24 ソニー株式会社 受信装置、送信装置、及び、データ処理方法
US10432690B1 (en) * 2016-06-03 2019-10-01 Amazon Technologies, Inc. Manifest partitioning
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
KR102391799B1 (ko) * 2017-10-19 2022-04-29 삼성전자주식회사 유니캐스트　기반 멀티미디어 서비스 방법 및 장치
US10963003B2 (en) 2017-10-20 2021-03-30 Graphcore Limited Synchronization in a multi-tile processing array
GB201717295D0 (en) 2017-10-20 2017-12-06 Graphcore Ltd Synchronization in a multi-tile processing array
GB2569276B (en) 2017-10-20 2020-10-14 Graphcore Ltd Compiler method
GB2569275B (en) 2017-10-20 2020-06-03 Graphcore Ltd Time deterministic exchange
GB201721847D0 (en) * 2017-12-22 2018-02-07 Telecom Paris Tech Priority map for media files
CN110545492B (zh) * 2018-09-05 2020-07-31 北京开广信息技术有限公司 媒体流的实时递送方法及服务器
US11582125B2 (en) * 2019-10-01 2023-02-14 Qualcomm Incorporated Repair mechanism for adaptive bit rate multicast
US11671635B2 (en) 2020-01-02 2023-06-06 Board Of Trustees Of Michigan State University Systems and methods for enhanced multimedia signal broadcast, reception, data delivery, and data collection
US11638044B1 (en) * 2022-03-01 2023-04-25 Amazon Technologies, Inc. Preparation of warm inputs for digital content streaming

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6988144B1 (en) * 1999-11-18 2006-01-17 International Business Machines Corporation Packet scheduling system and method for multimedia data
EP1170919A1 (en) * 2000-07-04 2002-01-09 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Method and device for improving the transmission efficiency in a communication system with a layered protocol stack
US7489706B2 (en) * 2004-06-28 2009-02-10 Spirent Communications, Inc. Method and apparatus for placing a timestamp in a frame
US9209934B2 (en) * 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
WO2009006593A2 (en) * 2007-07-05 2009-01-08 Coherent Logix Incorporated Mobile television broadcast system
CN101370175B (zh) * 2007-08-15 2011-12-28 华为技术有限公司 确定数据发送时间的方法、组播分组方法、装置和***
CN101971578B (zh) * 2007-12-28 2014-07-30 茨特里克斯***公司 Tcp分组间距
CN102484741B (zh) * 2009-08-21 2014-04-02 香港中文大学 用于规划媒体数据的传输时间的装置和方法
US9185445B2 (en) * 2009-09-24 2015-11-10 At&T Intellectual Property I, L.P. Transmitting a prioritized audio stream along with multimedia content
US8806050B2 (en) * 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
US8937920B2 (en) * 2011-12-30 2015-01-20 UV Networks, Inc. High capacity network communication link using multiple cellular devices
US20130271655A1 (en) * 2012-04-12 2013-10-17 Google Inc. System, apparatus and method to facilitate live video streaming
US9125073B2 (en) * 2012-08-03 2015-09-01 Intel Corporation Quality-aware adaptive streaming over hypertext transfer protocol using quality attributes in manifest file
EP2784996A1 (en) * 2013-03-27 2014-10-01 British Telecommunications public limited company Deadline driven content delivery

Also Published As

Publication number Publication date
WO2016090280A1 (en) 2016-06-09
CN107005729A (zh) 2017-08-01
US20160164943A1 (en) 2016-06-09
TW201633759A (zh) 2016-09-16
TWI668982B (zh) 2019-08-11

Similar Documents

Publication Publication Date Title
TWI668982B (zh) 用於多媒體和檔案傳輸的傳輸介面的方法及伺服器設備、及用於記錄相關指令於其上的電腦可讀取儲存媒體
CN107409234B (zh) 基于lct利用dash格式的基于文件格式的流式传输
US10666961B2 (en) Determining media delivery event locations for media transport
US9973345B2 (en) Calculating and signaling segment availability times for segments of media data
CN108141455B (zh) 用于媒体数据的流式发射的期限信令
EP2941892B1 (en) Live timing for dynamic adaptive streaming over http (dash)
US20160337424A1 (en) Transferring media data using a websocket subprotocol
EP3095247B1 (en) Robust live operation of dash