KR20190075137A - 전달 성능을 개선시키는 리소스 세그먼테이션 - Google Patents

전달 성능을 개선시키는 리소스 세그먼테이션 Download PDF

Info

Publication number
KR20190075137A
KR20190075137A KR1020197016532A KR20197016532A KR20190075137A KR 20190075137 A KR20190075137 A KR 20190075137A KR 1020197016532 A KR1020197016532 A KR 1020197016532A KR 20197016532 A KR20197016532 A KR 20197016532A KR 20190075137 A KR20190075137 A KR 20190075137A
Authority
KR
South Korea
Prior art keywords
fragment
client
media
media segment
fragments
Prior art date
Application number
KR1020197016532A
Other languages
English (en)
Other versions
KR102220188B1 (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 KR20190075137A publication Critical patent/KR20190075137A/ko
Application granted granted Critical
Publication of KR102220188B1 publication Critical patent/KR102220188B1/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/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H04L65/602—
    • 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
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B34/00—Computer-aided surgery; Manipulators or robots specially adapted for use in surgery
    • A61B34/70—Manipulators specially adapted for use in surgery
    • A61B34/76—Manipulators having means for providing feel, e.g. force or tactile feedback
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B90/00—Instruments, implements or accessories specially adapted for surgery or diagnosis and not covered by any of the groups A61B1/00 - A61B50/00, e.g. for luxation treatment or for protecting wound edges
    • A61B90/36—Image-producing devices or illumination devices not otherwise provided for
    • A61B90/37—Surgical systems with images on a monitor during operation
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
    • G16H20/40—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to mechanical, radiation or invasive therapies, e.g. surgery, laser therapy, dialysis or acupuncture
    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
    • G16H40/63—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices for local operation
    • 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/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
    • 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/80—Responding to QoS
    • 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/835—Generation of protective data, e.g. certificates
    • H04N21/8352—Generation of protective data, e.g. certificates involving content or source identification data, e.g. Unique Material Identifier [UMID]
    • 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/84—Generation or processing of descriptive data, e.g. content descriptors
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B17/00—Surgical instruments, devices or methods, e.g. tourniquets
    • A61B2017/00017—Electrical control of surgical instruments
    • A61B2017/00022—Sensing or detecting at the treatment site
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B17/00—Surgical instruments, devices or methods, e.g. tourniquets
    • A61B2017/00017—Electrical control of surgical instruments
    • A61B2017/00115—Electrical control of surgical instruments with audible or visual output
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B90/00—Instruments, implements or accessories specially adapted for surgery or diagnosis and not covered by any of the groups A61B1/00 - A61B50/00, e.g. for luxation treatment or for protecting wound edges
    • A61B90/06—Measuring instruments not otherwise provided for
    • A61B2090/064—Measuring instruments not otherwise provided for for measuring force, pressure or mechanical tension
    • A61B2090/065—Measuring instruments not otherwise provided for for measuring force, pressure or mechanical tension for measuring contact or contact pressure
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B90/00—Instruments, implements or accessories specially adapted for surgery or diagnosis and not covered by any of the groups A61B1/00 - A61B50/00, e.g. for luxation treatment or for protecting wound edges
    • A61B90/36—Image-producing devices or illumination devices not otherwise provided for
    • A61B2090/364—Correlation of different images or relation of image positions in respect to the body
    • A61B2090/365—Correlation of different images or relation of image positions in respect to the body augmented reality, i.e. correlating a live optical image with another image
    • A—HUMAN NECESSITIES
    • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
    • A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
    • A61B34/00—Computer-aided surgery; Manipulators or robots specially adapted for use in surgery
    • A61B34/30—Surgical robots
    • A61B34/37—Master-slave robots

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Surgery (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
  • Public Health (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Molecular Biology (AREA)
  • Veterinary Medicine (AREA)
  • Animal Behavior & Ethology (AREA)
  • Heart & Thoracic Surgery (AREA)
  • Primary Health Care (AREA)
  • Epidemiology (AREA)
  • Computer Security & Cryptography (AREA)
  • Oral & Maxillofacial Surgery (AREA)
  • Pathology (AREA)
  • Radiology & Medical Imaging (AREA)
  • Gynecology & Obstetrics (AREA)
  • Robotics (AREA)
  • General Business, Economics & Management (AREA)
  • Urology & Nephrology (AREA)
  • Business, Economics & Management (AREA)
  • Information Transfer Between Computers (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Endoscopes (AREA)

Abstract

리소스(예를 들어, 미디어 세그먼트와 같은 미디어 리소스, 또는 HTTP와 같은 일반적인 파일 트랜스퍼 프로토콜들을 사용하여 정상적으로 페치 또는 푸시된 리소스와 같은 다른 리소스)를 복수의 프래그먼트들로 세그먼트하는 신축성있는 방식. 이러한 방식을 채용함으로써, 리소스가 클라이언트 측에서 이용될 수 있을 때까지의 지연이 감소된다. 라이브 DASH 스트리밍으로 사용되는 것과 같이, 비디오 스트리밍을 위한 ISOBMFF 미디어 세그먼트들에 신축성있는 세그먼테이션 방식을 적용한 소정의 실시예들이 제공된다.

Description

전달 성능을 개선시키는 리소스 세그먼테이션
라이브 스트리밍에서 사용되는 미디어 세그먼트들과 같은, 리소스들을 세그먼트하는 실시예들이 개시된다.
현재의 스트리밍 방식들
라이브 및 비디오-온-디맨드 적응형 비트-레이트 스트리밍을 위한 현재의 방식들은 하이퍼텍스트 트랜스퍼 프로토콜(HTTP)(예를 들어, [HTTP] 참조)에 주로 의존한다. 이들 방식에서, 클라이언트(사용자 에이전트 또는 UA라고도 함)는 그 각각이 미디어 샘플들(즉, 오디오 샘플들 및/또는 비디오 샘플들)을 포함하는, 다수의 미디어 세그먼트를 검색하기 위해 HTTP를 사용할 수 있다. 이들 미디어 세그먼트는 클라이언트가 미디어 세그먼트를 파싱하고, 미디어 샘플들을 디코딩하고, 궁극적으로 클라이언트의 사용자에게 미디어를 플레이할 수 있게 하는 소정의 포맷들(예를 들어, ISOBMFF)에 따른다. 즉, 미디어 세그먼트를 검색한 후에, 클라이언트는 미디어 세그먼트의 콘텐트들을 파싱하고 사용자에게 렌더링할 수 있다.
이들 현재의 방식 하에서, 이러한 미디어 세그먼트들에 대한 상이한 표현들(상이한 품질들의 인코딩을 갖는 상이한 표현들)을 잠재적으로 포함하는, 개별적인 미디어 세그먼트들의 위치에 관한 정보를 제공하는 상위 계층이 있다. 2개의 주요한 해결책이 사용된다: (1) HTTP 라이브 스트리밍(HLS)(예들 들어, [HLS] 참조) 및 (2) HTTP를 통한 동적 적응형 스트리밍(DASH)(예를 들어, [DASH] 참조). 이들 해결책 모두는 스트리밍 클라이언트가 어떤 미디어 세그먼트를 검색할지를 결정할 수 있도록 상이한 미디어 세그먼트들 및 그들의 비트-레이트들을 디스크라이브하는 매니페스트 파일을 사용한다. 몇가지 상이한 미디어 세그먼트 포맷들이 있지만, HLS와 DASH 둘 다는 ISO 베이스 미디어 파일 포맷(ISOBMFF)(예를 들어, [ISOBMFF] 참조)을 지원한다.
미디어 세그먼트 포맷들
ISOBMFF는 신축성있는 미디어 컨테이너 파일 포맷이다. 그것은 박스들이라고 하는 구조들로 구성된다. 박스는 식별자 및 길이 필드를 포함할 수 있고 박스가 어떤 것을 포함하는지를 정의하는 메타데이터를 포함할 수 있다. 박스는 다른 유형들의 하나 이상의 박스를 포함할 수 있다. 소정의 유형들의 미디어 또는 사용 경우들에 대한 것과 같은, 특정한 포맷들은 포괄적인 ISOBMFF 구조에 추가적인 제한들을 가할 수 있다(예를 들어, 미디어 파일에 대한 요건들을 정의하고, 파일이 포함하여야 하는 박스들의 유형들을 특정할 수 있다). DASH는 초기화 세그먼트들 및 미디어 세그먼트들과 같은, ISOBMFF 파일 포맷을 사용하여 여러 유형들의 세그먼트들을 정의한다. 초기화 세그먼트는 미디어 세그먼트들을 디코딩하기 위해 필요한 정보를 포함할 수 있다. 그러나 단지 미디어 세그먼트들은 미디어 샘플들을 포함한다. 각각의 미디어 세그먼트는 moof 박스 및 mdat 박스를 포함한다.
MOOF 박스는 트랙 런 박스(trun)를 포함하는 트랙 프래그먼트(traf) 박스를 포함한다. trun 박스는 mdat 박스 내부에 저장된 미디어 샘플들의 연속하는 세트를 도큐먼트한다. 그래서 각각의 미디어 샘플에 대해 적어도 그것의 데이터 크기, 및 미디어 샘플의 기간이 제공된다. 이것은 미디어 샘플들이 mdat 박스 내부에 서로 다음에 연속하여 저장될 수 있게 한다. moof 박스는 mdat 박스 전에 저장된다.
워크 로드의 분배
HTTP를 위한 아웃-오브-밴드(OOB) 콘텐트 인코딩 메커니즘(예를 들어, [OOB] 참조)에 대한 계속 진행 중인 워크가 있다. 이 OOB 메커니즘은 서버가 HTTP 응답 바디의 서빙을 또 하나의 신뢰 도메인으로 리다이렉트할 수 있게 한다. 이것은 예를 들어, 동일한 근원 정책들을 위배하지 않고, 양호한 프라이버시 특성들을 갖고, 모든 개별적인 HTTP 요청들이 트랜스포트 계층 보안(TLS) 접속들의 맥락에서 이루어질 때 콘텐트 분배에서 더 많은 신축성을 가능하게 하는 콘텐트 분배 네트워크(CDN) 노드들, 에지 서버들 또는 제3자 캐시들/프록시들로 안전하게 리다이렉트하기 위해 사용될 수 있다.
HTTP 대안적 서비스들(예를 들어, [alt-services] 참조)은 다른 네트워크 위치 및 가능하게는 다른 전달 프로토콜들로 요청에 대한 응답들을 리다이렉트하는 또 하나의 방법이다. HTTP 대안적 서비스들을 사용하여, 리소스 아이덴티티는 리소스의 위치로부터 분리된다. 그러나, 이 리다이렉트는 전체 근원에 적용하고, 개별적인 리소스 레벨 상에서 수행될 수 없다.
리소스 검증
HTTP 맥락에서 요청된 리소스(예를 들어, 요청된 미디어 세그먼트)의 바디의 무결성을 보호하기 검증하기 위해 개발되고 있는 여러 상이한 메커니즘들이 있다. 하나의 제안은 응답 바디를 위한 서명이다(예를 들어, [CONTENTSIG] 참조). 또 하나의 방식은 콘텐트 인코딩으로서 메시지 바디들의 비밀성 및 무결성 검증을 위해 허용하는 진보된 암호화 표준(AES) 갈로이스 카운터 모드(GCM), 또는 AES GCM의 응용이다(예를 들어, [aesgcm] 참조). 또 하나의 제안은 고정된 크기 기록들을 사용하여 무결성 검증을 제공하는 머클(Merkle) 무결성 콘텐트 인코딩, 또는 MICE이다(예를 들어, [MICE] 참조). MICE로, 각각의 기록은 그것이 도달하는 대로 검증될 수 있어서, 이전의 기록이 검증되었거나, 그 기록에 대한 올바른 해시가 검증을 수행하는 엔티티에 대해 알려진 경우에, 수신기 측 상의 점진적 검증을 가능하게 한다.
참고 문헌들
[CONTENTSIG] Thomson, M., "Content-Signature Header Field for HTTP", draft-thomson-http-content-signature-00 (work in progress), July 2015.
[MICE] Thomson, M., “Merkle Integrity Content Encoding”, draft-thomson-http-mice-01 (work in progress), June 2016.
[OOB] J. Reschke, and S. Loreto, “‘Out-Of-Band’ Content Coding for HTTP”, draft-reschke-http-oob-encoding-08 (work in progress), September 2016.
[RFC6454], A. Barth, “The Web Origin Concept”, RFC 6454, December 2011.
[HLS] R. Pantos, and W. May, “HTTP Live Streaming”, draft-pantos-http-live-streaming-20 (work in progress), September 2016.
[DASH] “Information technology -- Dynamic adaptive streaming over HTTP (DASH) -- Part 1: Media presentation description and segment formats”, ISO/IEC 23009-1:2014, May 2014.
[HTTP] R. Fielding, J. Reschke, “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, IETF RFC 7230, June 2014.
[ISOBMFF] “Information technology - Coding of audio-visual objects - Part 12: ISO base media file format”, ISO/IEC 14496-12, July 2012.
[aesgcm] M. Thomson, “Encrypted Content-Encoding for HTTP”, IETF draft-ietf-httpbis-encryption-encoding-03 (work in progress), October 2016.
[alt-services] M. Nottingham, et al, “HTTP Alternative Services”, IETF RFC 7838, April 2016.
[S4-141201] 3GPP TSG-SA4 #81, “MI-EMO: Guidelines for out of order sending of movie fragments”, http://www.3gpp.org/ftp/tsg_sa/wg4_codec/TSGS4_81/Docs/S4-141201.zip, August 2014.
기존의 해결책들이 갖는 문제점들
라이브 스트리밍을 전달하는 하나의 일반적인 방식은 ISO 베이스 미디어 파일 포맷(ISO BMFF)으로 DASH를 사용하는 것이다. ISO BMFF 미디어 세그먼트 포맷은 moof 박스(즉, moof의 대응하는 mdat 박스 내에 포함된 미디어 샘플들에 대한 메타데이터(예를 들어, 길이 및 위치)를 포함하는 박스)가 mdat 박스를 선행하는 것을 특정한다. 이 요건은 인코더가 대응하는 미디어 샘플들의 인코딩을 완료하기 전에 전체 moof를 인코더가 발생시키는 것을 방지한다. 이것은 그러므로 지연을 도입시킨다. 지연은 Tsource_to_playback(인코더가 미디어 세그먼트들에 대한 미디어 샘플들을 발생시키기 시작할 때부터 클라이언트가 플레이백을 시작할 수 있을 때까지의 지연)으로서 측정될 수 있다. 이 지연은 사용자에게 중요한데, 왜냐하면 그것은 시청되기 위해 미디어 세그먼트가 얼마나 빨리 이용가능하냐는 것에 영향을 주기 때문이다. Tsource_to_playback은 Tsource_to_reception(인코더가 미디어 세그먼트를 인코딩하기 시작할 때부터 인코더가 수신 엔티티에 미디어 세그먼트를 제공할 수 있을 때까지의 지연)과 Treception_to_playback(수신 엔티티가 미디어 세그먼트를 먼저 수신하기 시작할 때부터 플에이백이 시작할 수 있을 때까지의 지연)의 합으로서 측정될 수 있다. 미디어 샘플들의 길이 및 위치가 파일 포맷으로 데이터 부분 전에 기입되기를 요구하는 것(예를 들어, moof는 모든 미디어 샘플들이 발생될 때까지 완료될 수 없다)은 그러므로 Tsource_to_playback을 증가시키는데 왜냐하면 그것은 Tsource_to_reception을 증가시키기 때문이다. 이 지연은 미디어 세그먼트의 길이에 따라 증가한다(전형적으로 약 2-10초).
이 지연을 다루는, 즉, 위에 언급된 지연을 최소화하는 하나의 공지된 방식은 특정한 미디어 세그먼트에 대한 다수의 ISOBMFF "영화 프래그먼트들"을 생성하는 것이다. 즉, moof/mdat 박스 쌍들의 시퀀스를 포함하는 미디어 세그먼트를 생성하는 것이다. 예를 들어, 미디어 세그먼트는 제1 영화 프래그먼트(즉, 제1 moof 박스 이후의 제1 mdat 박스) 및 제2 영화 프래그먼트(즉, 제2 moof 박스 이후의 제2 mdat 박스)를 포함할 수 있다. 이것은 영화 프래그먼트가 생성되자마자 영화 프래그먼트의 송신을 가능하게 한다. 이것은 지연을 감소시킬 수 있는데, 왜냐하면 지연은 프래그먼트의 길이에 의존하고, 이 방식은 더 작은 길이를 각각 갖는 보다 많은 프래그먼트들을 생성하기 때문이다. 그러나, 지연을 감소시키는 것 외에, 이 방식은 또한 오버헤드를 증가시킨다. 또한, 이 방식은 (디코딩 및 연속하는 플레이백이 세그먼트 내의 임의의 이전의 데이터에 의존하지 않고 시작할 수 있는 점들로서 표준에 따라 정의된) 추가의 랜덤 액세스 점들을 생성한다. 이 방식은 또한 랜덤 액세스 점들의 빈도가 인코딩의 효율에 부정적으로 영향을 주므로(예를 들어, 비디오 인코딩을 위해, 그것은 최적하지 않은 수의 I-프레임들을 야기할 수 있다), 비디오 인코딩에 영향을 줄 수 있다.
위에 설명된 방식은 또한 추가의 문제들을 겪는다. 예를 들어, 방식은 리소스(예를 들어, 미디어 세그먼트) 무결성의 검증이 요구될 때 랜덤 액세스를 허용하지 않는 것을 추가로 겪는다. 무결성 메커니즘의 특성들로 인해, 제한되지 않은 랜덤 액세스가 가능하지 않다. 그럼에도 불구하고, 위에 설명된 방식은 리소스의 시작을 제외하고, 리소스 내에서 어떤 랜덤 액세스 점들을 허용하지 않는다. 추가의 랜덤 액세스 점들을 제공하는 것은 라이브 스트림들에의 늦은 결합자들을 가능하게 하거나, 더 큰 비디오 시퀀스 내에서 찾거나, 미디어 세그먼트 내에서 특정한 랜덤 액세스 점들에 액세스하는 것과 같은 이득들을 제공할 것이다.
위에 설명된 방식을 아웃-오브-밴드(OOB) 인코딩으로, 특히 HTTP 리소스 검색으로 채용할 때 추가의 문제들이 생긴다. 예를 들어, 위에 설명된 방식은, 검증을 위해 AES GCM을 사용하는 경우에, 전체 리소스들이 리소스의 무결성을 검증하기 위해 검색되는 것을 요구한다. 이것은 수신 클라이언트가 콘텐트를 플레이 아웃할 때까지 콘텐트 수집 간의 가장 짧은 시간, 즉, 인코딩과 클라이언트 플레이 백 간의 시간(즉, Tsource_to_playback)에 영향을 준다. 수집(인코딩) 측에서, 콘텐트는 무결성 검증 해시들이 계산될 수 있기 전에 완전히 수집될 필요가 있다. 이것은 이러한 해시들이 전체 리소스에 걸쳐 계산되기 때문이다. 다음에, 수신(디코딩) 측에서, 송신되기로 의도된 것으로 그것이 어떤 것을 수신하였는지를 검증하는 클라이언트는 무결성 해시가 계산된 모든 콘텐트, 즉, 전체 리소스를 먼저 수신하여야 한다.
AES GCM 이외의, 또 하나의 공지된 방식은 머클 무결성 콘텐트 인코딩(MICE)이다. 그러나, 이것이 사용되는 경우에도, 여전히 단점들이 있다. MICE는 AES GCM이 갖는 일부 문제들을 부분적으로 다루는데, 왜냐하면 각각의 블록이 전달을 완료했을 때(블록이 리소스보다 작은 경우), 그것은 수신기가 블록마다에 기초하여 리소스의 점진적 검증을 수행하게 하기 때문이다. 그러므로, 위에 언급된 클라이언트 측 지연은 전체 리소스의 크기라기보다는, 사용된 블록 크기 및 기본 콘텐트 구조들과의 그것의 협력에 의존한다. 그러나, 방식은 무결성 보호를 계산하고 콘텐트에 해시 체인을 부가할 때 인코더가 리소스의 적어도 일부를 갖는 것을 여전히 요구하므로, MICE는 위에 언급된 서버 측 지연을 다루지 못한다.
공지된 무결성 검증 메커니즘들은 동적으로 발생되는 콘텐트와 효과적으로 동작하지 않는다. 이것은 이러한 메커니즘들이 인코더가 검증될 전체 리소스를 알 것을 요구하는 경향이 있기 때문이다. TLS 및 SSL이 청킹된 트랜스퍼 인코딩으로 사용될 수 있고, 데이터가 단일 서버 또는 신뢰 도메인에 의해 송신될 때, 트랜스포트-레벨에서 데이터를 검증하는 것이 가능할 수 있지만, 그 해결책은 다수의 도메인들이 아웃 오브 밴드 서버들로부터의 리소스들의 무결성 검증에 의존하는 OOB와 같은 전달 모델들과 같이, 정보를 밖으로 송신할 때 실행 가능하지 않다.
예시적인 제안된 실시예들의 간단한 요약
본원은 리소스(예를 들어, 미디어 세그먼트와 같은 미디어 리소스, 또는 HTTP와 같은 일반적인 파일 트랜스퍼 프로토콜들을 사용하여 정상적으로 페치 또는 푸시되는 리소스와 같은, 다른 리소스)를 복수의 프래그먼트로 세그먼트하는 신축성있는 방식을 설명한다. 이러한 방식을 채용함으로써, 리소스가 클라이언트 측에서 이용될 수 있을 때까지의 지연이 감소된다. 라이브 DASH 스트리밍으로 사용되는 것과 같이, 비디오 스트리밍을 위한 ISOBMFF 미디어 세그먼트들에 신축성있는 세그먼테이션 방식을 특별히 적용한 소정의 실시예들이 제공된다. 이들 실시예는 설명된 신축성있는 세그먼테이션을 사용함으로써, 클라이언트 측 플레이백이 시작할 수 있을 때까지 서버 측 상에서 이용가능하게 되는 미디어 샘플들 간의 지연(즉, Tsource_to_playback)을 상당히 감소시킬 수 있다. 한 실시예에서, 이것은 리소스의 부분들이 안에서 검색되는 순서(예를 들어, 논리적 순서와 상이할 수 있는 검색 순서)를 변경할 수 있을 뿐만 아니라, 그들이 수집된 미디어 샘플들에 의해 생성됨에 따라 리소스의 부분들의 점진적 페치 또는 푸시를 가능하게 할 수 있는, 여기에 제안된 파일 세그먼테이션 메커니즘을 사용함으로써 달성된다. 제안된 리소스 세그먼테이션 메커니즘은 또한 수신기(클라이언트 측)가 공지된 해결책들이 허용하는 것보다 앞선 스테이지에서 리소스 프래그먼트들을 이용할 수 있게 하기 위해 메타데이터를 제공한다.
본원의 또 하나의 양태는 신축성있는 세그먼테이션에 의해 제공되는 특성들 및 이득들을 유지하면서, 완전한 리소스뿐만 아니라, 리소스 프래그먼트들의 무결성을 보장하는 것에 관한 것이다. 예를 들어, 설명된 방식은 리소스 프래그먼트의 개별적인 청크들의 점진적 무결성 검증을 가능하게 한다. 점진적으로 발생될 리소스들에 대해, 청크들의 개별 또는 그룹들(무결성 블록)에 걸친 해시들이 점진적 검증을 가능하게 한다. 각각의 무결성 블록에 대한 개별적인 해시들에 걸친 서명들을 사용하는 것은 해시들이 신뢰될 수 있는 것, 즉, 그들이 신뢰된 엔티티에 의해 발생된 것을 보장한다. 적절한 무결성 보호를 포함하는 세그먼테이션 해결책은 또한 예를 들어 아웃-오브-밴드 인코딩 또는 HTTP에서의 대안적 서비스들을 사용할 때 생성되는 것과 같은, 상이한 신뢰 도메인들로부터의 리소스 세그먼트들의 검색을 다룰 수 있다. 이 해결책은 또한 다수의 신뢰 및 보안 맥락들의 사용을 완전히 지원하기 위해서, 개별적인 리소스 세그먼트들의 비밀 보호를 위해, 독립적인 또는 상이한 키들, 또는 심지어 독립적인 또는 상이한 보호 메커니즘들을 지원한다.
한 양태에서, 클라이언트에 동적으로 발생된 미디어 스트림을 전달하는 방법이 제공되고, 미디어 스트림은 제1 미디어 세그먼트 및 제2 미디어 세그먼트를 포함하는 복수의 미디어 세그먼트들을 포함한다. 상기 방법은 상기 클라이언트에 매니페스트 파일을 송신하라는 표시를 수신하는 단계를 포함하고, 상기 매니페스트 파일은 상기 미디어 세그먼트들을 디스크라이브하는 정보를 포함한다. 상기 방법은 또한 상기 매니페스트 파일을 상기 클라이언트에 송신하라는 상기 표시를 수신한 것에 응답하여, 상기 클라이언트에, 상기 매니페스트 파일을 송신하는 단계를 포함한다. 상기 방법은 또한 상기 클라이언트에 상기 매니페스트 파일을 송신한 후에, 상기 클라이언트에 상기 제1 미디어 세그먼트를 송신하라는 표시를 수신하는 단계를 포함한다. 그리고 상기 방법은 상기 클라이언트에 상기 제1 미디어 세그먼트를 송신하라는 상기 표시에 응답하여, 상기 클라이언트에, 상기 제1 미디어 세그먼트에 대한 세그먼테이션 맵을 송신하는 단계를 추가로 포함한다. 상기 제1 미디어 세그먼트는 제1 프래그먼트 및 제2 프래그먼트를 포함하는 프래그먼트들의 정렬된 세트를 포함하고, 상기 세그먼테이션 맵은 서버로부터 상기 제1 프래그먼트에 액세스하는 데 사용하기 위한 제1 프래그먼트 식별자를 포함하는 제1 프래그먼트 메타데이터, 서버로부터 상기 제2 프래그먼트에 액세스하는 데 사용하기 위한 제2 프래그먼트 식별자를 포함하는 제2 프래그먼트 메타데이터, 및 상기 제1 프래그먼트가 상기 제2 프래그먼트 전에 정렬된다는 것을 표시하는 정보를 포함하는, 프래그먼트들의 상기 세트 내의 상기 프래그먼트들의 상기 정렬을 식별하는 정렬 정보를 포함한다.
일부 실시예들에서 상기 방법은 또한 상기 클라이언트에 상기 제1 프래그먼트를 송신하라는 표시를 수신하는 단계, 및 상기 클라이언트에 상기 제1 프래그먼트를 송신하라는 상기 표시를 수신한 것에 응답하여, 상기 클라이언트에, 상기 제1 프래그먼트를 송신하는 단계를 포함한다. 일부 실시예들에서, 상기 클라이언트에 상기 매니페스트 파일을 송신하라는 상기 표시, 상기 클라이언트에 상기 제1 미디어 세그먼트를 송신하라는 상기 표시, 및 상기 클라이언트에 상기 제1 프래그먼트를 송신하라는 상기 표시 중 하나 이상은 클라이언트 입력 없이 상기 서버에 의해 발생된다. 일부 실시예들에서, 상기 방법은 또한 상기 표시들 중 하나 이상을 발생시키기 전에, 상기 미디어 스트림을 수신할 상기 클라이언트를 등록하라는 요청을 수신하는 단계를 포함한다.
일부 실시예들에서, 상기 클라이언트에 상기 제1 미디어 세그먼트를 송신하라는 상기 표시는 상기 클라이언트에 의해 송신된 요청이고, 상기 요청은 상기 제1 미디어 세그먼트를 식별하는 정보를 포함하고, 상기 요청은 상기 클라이언트가 세그먼트된 모드를 지원한다는 것을 표시하는 표시자를 추가로 포함한다. 일부 실시예들에서 상기 방법은 또한 상기 미디어 세그먼트를 전달하기 위해 상기 세그먼트된 모드를 사용하기를 결정하는 단계를 포함하고, 상기 결정은 상기 표시자에 적어도 부분적으로 기초한다. 일부 실시예들에서 상기 제1 미디어 세그먼트를 전달하기 위해 상기 세그먼트된 모드를 사용하기를 결정하는 단계는 상기 제1 미디어 세그먼트가 완전히 발생되었는지에 적어도 부분적으로 추가로 기초한다. 일부 실시예들에서 상기 매니페스트 파일의 콘텐트는 상기 클라이언트가 상기 세그먼트된 모드를 지원한다는 상기 표시자에 기초하고, 상기 표시자에 기초한 상기 매니페스트 파일의 상기 콘텐트는 상기 복수의 미디어 세그먼트들에 대한 리소스 이용가능성의 시간에 관한 힌트를 포함한다.
일부 실시예들에서, 상기 제1 프래그먼트 메타데이터는 상기 제1 프래그먼트에 대한 제1 의존성 정보 - 상기 제1 의존성 정보는 상기 서버로부터 전달될 상기 제1 프래그먼트의 상기 이용가능성이 상기 세트 중 하나 이상의 다른 프래그먼트에 의존한다는 것을 표시함 - , 상기 제1 프래그먼트의 길이, 상기 미디어 세그먼트 내의 상기 제1 프래그먼트의 시작 위치, 및 상기 미디어 세그먼트 내의 상기 제1 프래그먼트의 종료 위치 중 하나 이상을 포함하는 제1 위치 정보, 및 상기 제1 프래그먼트의 무결성을 검증하는 데 사용하기 위한 제1 프래그먼트-레벨 보안 정보 중 하나 이상을 추가로 포함한다.
일부 실시예들에서 상기 방법은 또한 상기 미디어 스트림을 동적으로 발생시키는 소스로부터 상기 제1 미디어 세그먼트의 부분을 수신하는 단계 - 상기 제1 미디어 세그먼트의 상기 부분은 미디어 샘플 및 미디어 애플리케이션 데이터 단위 중 적어도 하나에 대응함 - ; 및 포맷에 따라 상기 제1 미디어 세그먼트의 상기 부분을 패킷타이징하는 단계 - 상기 포맷은 ISO 베이스 미디어 파일 포맷임 - 포함한다. 일부 실시예들에서 상기 제1 프래그먼트는 미디어 샘플들을 포함하고, 상기 제2 프래그먼트는 상기 미디어 샘플들과 연관된 메타데이터를 포함한다.
또 하나의 양태에서 동적으로 발생된 미디어 스트림을 수신하는, 클라이언트에 의해 수행되는 방법이 제공되고, 상기 미디어 스트림은 제1 미디어 세그먼트 및 제2 미디어 세그먼트를 포함하는 복수의 미디어 세그먼트들을 포함한다. 상기 방법은 매니페스트 파일을 수신하는 단계를 포함하고, 상기 매니페스트 파일은 상기 클라이언트가 상기 미디어 세그먼트들에 대한 요청들을 발생시킬 수 있게 하는 정보를 포함한다. 상기 방법은 또한 상기 수신된 매니페스트 파일을 처리하는 단계, 및 상기 매니페스트 파일을 처리한 후에, 상기 제1 미디어 세그먼트에 대한 세그먼테이션 맵을 수신하는 단계를 포함한다. 상기 제1 미디어 세그먼트는 제1 프래그먼트 및 제2 프래그먼트를 포함하는 프래그먼트들의 정렬된 세트를 포함하고, 상기 세그먼테이션 맵은 제1 서버로부터 상기 제1 프래그먼트에 액세스하는 데 사용하기 위한 제1 프래그먼트 식별자를 포함하는 제1 프래그먼트 메타데이터, 서버로부터 상기 제2 프래그먼트에 액세스하는 데 사용하기 위한 제2 프래그먼트 식별자를 포함하는 제2 프래그먼트 메타데이터, 및 상기 제1 프래그먼트가 상기 제2 프래그먼트 전에 정렬된다는 것을 표시하는 정보를 포함하는, 프래그먼트들의 상기 세트 내의 상기 프래그먼트들의 상기 정렬을 식별하는 정렬 정보를 포함한다. 상기 방법은 상기 제1 프래그먼트를 수신하는 단계를 추가로 포함한다.
일부 실시예들에서 상기 방법은 또한 상기 매니페스트 파일을 수신하기 전에, 매니페스트 파일에 대한 요청을 송신하는 단계, 및 상기 매니페스트 파일을 처리한 후에 그리고 상기 세그먼테이션 맵을 수신하기 전에, 상기 제1 미디어 세그먼트를 식별하는 요청을 송신하는 단계를 포함한다. 일부 실시예들에서, 상기 제1 미디어 세그먼트를 식별하는 상기 요청은 상기 클라이언트가 세그먼트된 모드를 지원한다는 것을 표시하는 표시자를 포함한다.
일부 실시예들에서 상기 매니페스트 파일 및 제1 프래그먼트 중 하나 이상은 상기 클라이언트가 요청을 송신하지 않고 상기 클라이언트에 의해 수신된다. 일부 실시예들에서, 상기 클라이언트의 애플리케이션 계층은 상기 클라이언트의 로컬 브라우저에 상기 매니페스트 파일 및 상기 제1 프래그먼트 중 하나 이상에 대한 요청을 송신하여, 상기 애플리케이션 계층이 상기 매니페스트 파일 및 상기 제1 프래그먼트 중 하나 이상에의 액세스를 획득하게 한다.
일부 실시예들에서 상기 제1 미디어 세그먼트에 대한 복수의 프래그먼트들은 상기 클라이언트가 요청을 송신하지 않고 상기 클라이언트에 의해 수신된다. 일부 실시예들에서 상기 클라이언트의 애플리케이션 계층은 상기 프래그먼트들의 상기 아이덴티티, 상기 파일 내의 그들의 제공된 오프셋, 또는 프래그먼트들의 상기 시퀀스를 포함하는 상기 세그먼테이션 맵 내의 상기 정보에 기초하여 상기 제1 미디어 세그먼트를 어셈블한다.
일부 실시예들에서 상기 방법은 상기 제1 프래그먼트를 검증하는 단계; 상기 제1 미디어 세그먼트를 검증하는 단계; 및 상기 제1 프래그먼트를 디코딩하고 플레이하는 단계를 추가로 포함한다. 일부 실시예들에서, 상기 제1 프래그먼트를 디코딩하고 플레이하는 단계는 제1 프래그먼트를 검증한 후에 그리고 상기 제1 미디어 세그먼트를 검증하기 전에 발생한다.
일부 실시예들에서 상기 방법은 또한 상기 제1 프래그먼트를 플레이하는 단계를 포함하고, 상기 제1 프래그먼트를 플레이하는 단계는 상기 미디어 세그먼트의 다른 프래그먼트들을 수신하기 전에 발생한다.
또 하나의 양태에서 클라이언트에 미디어 스트림을 송신하는 방법이 제공되고, 상기 미디어 스트림은 제1 미디어 세그먼트 및 제2 미디어 세그먼트를 포함하는 복수의 미디어 세그먼트들을 포함하고, 상기 제1 미디어 세그먼트는 복수의 미디어 샘플들(예를 들어, 오디오 및/또는 비디오 샘플들과 같은 mdat 데이터) 및 미디어 샘플 메타데이터(예를 들어, moof 데이터)을 포함한다. 일부 실시예들에서, 상기 방법은 상기 클라이언트에 상기 제1 미디어 세그먼트에 속하는 상기 복수의 미디어 샘플들 중 하나 이상을 송신하는 단계; 및 상기 클라이언트에 상기 제1 미디어 세그먼트에 속하는 상기 미디어 샘플 메타데이터의 적어도 일부를 송신하는 단계를 포함한다. 상기 제1 미디어 세그먼트에 속하는 상기 복수의 미디어 샘플들 중 상기 하나 이상은 상기 데이터에 상기 제1 미디어 세그먼트에 속하는 상기 미디어 샘플 메타데이터의 상기 적어도 일부가 송신되기 전에 상기 클라이언트에 송신된다. 일부 실시예들에서, 상기 제1 미디어 프래그먼트는 미디어 프래그먼트 유형 정보(예를 들어, STYP 박스)를 추가로 포함하고, 상기 방법은 상기 제1 미디어 세그먼트에 속하는 상기 복수의 미디어 샘플들 중 상기 하나 이상을 송신하기 전에 상기 제1 미디어 세그먼트에 속하는 상기 미디어 세그먼트 유형 정보를 송신하는 단계를 추가로 포함한다.
다른 실시예들 및 양태들이 아래에 설명된다.
장점들
신축성있는 세그먼테이션 메커니즘은 전달을 여러 방식들로 개선시키기 위해 사용될 수 있다. 예를 들어, 리소스의 관련된 프래그먼트들이 수신 클라이언트에 의해 소비될 수 있을 때까지의 지연이 감소될 수 있다. 또 하나의 예는 방식이 수신 클라이언트에 가까운 사용 에지 서버들 또는 캐시들을 완전히 지원하는 것으로, 리소스 프래그먼트들이 이러한 에지 서버들 또는 캐시들에서 이용가능하게 하고, 다른 프래그먼트들이 그들이 이용가능한 다른 인스턴스들로부터 검색될 수 있으면서, 사용자가 더 가깝거나 또는 그렇지 않으면 최적 제공자로부터 어떤 프래그먼트를 취득하게 한다. 이것은 개선된 전달 성능을 가져다 준다. 또 다른 예는 사용자에게 리소스 프래그먼트 저장에서의 용장성을 제공하고, 표시하는 능력이다. 또 다른 장점은 잠재적으로 상이한 소스들로부터 동시에 다수의 프래그먼트들을 검색 또는 수신하는 능력으로서, 이는 개선된 전달 성능을 가져다 줄 수 있어서, 인코딩 처리를 더 빠르게 한다.
또한, 본원에서 설명된 세그먼테이션 메커니즘은 미디어 세그먼트들의 지능적 세그먼테이션에 의해, 콘텐트 수집으로부터 DASH 및 HLS와 같은 라이브 스트리밍 메커니즘들을 위한 플레이아웃까지의 지연(Tsource_to_playback)을 상당히 개선시키기 위해 사용될 수 있다. 이 지능적 세그먼테이션은 인코딩된 미디어 샘플들이 패킷타이저에 의해 세그먼트에 부가될 때 개별적인 프래그먼트들의 클라이언트에의 점진적 전달을 가능하게 한다. 이것은 또한 송신을 시작할 수 있기 전에 ISOBMFF 파일들 내의 영화 프래그먼트들을 완료하는 데 있어서의 지연을 제거 또는 적어도 감소시킨다.
또한, 본원에서 설명된 세그먼테이션 메커니즘은 보안 모델, 예를 들어, 리소스 검증 및/또는 비밀성을 개선시키기 위해 사용될 수 있다. 예를 들어, 설명된 보안 모델은 그들 프래그먼트가 다수의 제공자들로부터 검색되는 경우에, 리소스를 다수의 프래그먼트들로 세그먼트할 때 특히 유리하다. 본원에서 설명된 보안 모델은 리소스를 다수의 프래그먼트들로 세그먼트할 때 애플리케이션의 필요에 적합한 상이한 무결성 메커니즘들의 신축성있는 사용을 가능하게 한다. 라이브 비디오 스트리밍 경우에 대해, 예를 들어, 신축성있는 기록 크기들을 취급하는 키 잠금 또는 서명 기반 무결성 메커니즘이 유리하다. 이러한 메커니즘은 개별적인 청크들이 무결성 보호되게 하고, 전달된 데이터가 올바른 것으로 즉각 검증되고 추가의 지연 없이 소비되게 한다.
도 1은 예시적인 실시예들에 따른 시스템을 도시한다.
도 2는 실시예에 따른 방법을 도시한다.
도 3은 실시예에 따른 방법을 도시한다.
도 4는 실시예에 따른 방법을 도시한다.
도 5는 실시예에 따른 방법을 도시한다.
도 6은 실시예에 따른 방법을 도시한다.
도 7은 실시예에 따른 방법을 도시한다.
도 8은 실시예에 따른 방법을 도시한다.
도 9는 본 발명의 예시적인 실시예들에 따른 클라이언트-서버 상호작용을 도시한다.
도 10은 본 발명의 예시적인 실시예들에 따른 클라이언트-서버 상호작용을 도시한다.
도 11은 본 발명의 예시적인 실시예들에 따른 예시적인 시퀀스를 도시한다.
도 12는 본 발명의 예시적인 실시예들에 따른 ISOBMFF 미디어 세그먼트의 예시적인 프래그먼테이션을 도시한다.
도 13은 일부 실시예들에 따른 장치의 블록도를 도시한다.
여기에 사용된 것과 같이 단수 표현("a")은 달리 표시되지 않는다면 "하나 이상"을 의미하는 것으로 해석되어야 한다.
본원은 리소스(예를 들어, HTTP, FLUTE, 또는 FCAST와 같은 파일 전달 프로토콜을 사용하여 서버로부터 클라이언트에 전달되는 것으로 의도된 리소스)를 세그먼트하는 예시적인 실시예들을 설명한다. 실시예들은 세그먼트된 리소스의 포맷, 리소스 세그먼테이션을 수행하는 방법들 및 디바이스들, 및/또는 세그먼트된 리소스를 수신/송신하는 방법들 및 디바이스들에 관한 것이다.
세그먼테이션을 위한 예시적인 해결책은 주어진 리소스에 대한 세그먼테이션 맵을 클라이언트에 제공하는 것에 기초한다. 일부 실시예들에서, 클라이언트는 서버로부터 세그먼테이션 맵 또는 주어진 리소스를 구체적으로 요청할 수 있다. 도 1에 도시된 것과 같이, 클라이언트(102)는 서버(104)와 통신하고 있다. 일부 실시예들에서, 서버(104)는 전통적인 서버일 수 있고; 다른 실시예들에서 그것은 피어-투-피어 네트워크 내의 피어 클라이언트일 수 있다.
주어진 리소스는 전달 또는 애플리케이션의 필요들에 맞게, 임의 수의 프래그먼트들로 세그먼트될 수 있다. 세그먼테이션 맵은 개별적인 프래그먼트들에 관한 더 많은 정보가 결정됨에 따라 주어진 리소스에 대해 업데이트될 수 있다. 즉, 세그먼테이션 맵은 리소스의 개별적인 프래그먼트들에 관한 완전한 정보를 갖기 전에(즉, 리소스가 완전 특정되기 전에) 생성될 수 있다.
예시적인 실시예들에 따르면, 세그먼테이션 맵은 다음의 설명된 특징들의 일부 조합을 갖는다.
세그먼테이션 맵은 개별적인 프래그먼트들을 어셈블하는 순서를, 명시적으로(예를 들어, 인덱스 또는 시퀀스 식별자에 의해), 또는 암시적으로(예를 들어, 세그먼테이션 맵의 모두 또는 일부를 구현하는 데이터 구조에 의해 부과된 순서에 의해) 표시할 수 있다.
각각의 프래그먼트는 (세그먼테이션 맵에 대해 이루어진 어떤 업데이트들을 포함하는) 세그먼테이션 맵 생성의 시간에 알려진 또는 알려지지 않은 길이를 갖는다. 그러므로, 세그먼테이션 맵은 각각의 프래그먼트에 대해, 길이가 맵이 생성되는 시간에 알려지면 프래그먼트의 길이를 (예를 들어, 비트들로) 표시할 수 있다. 길이가 알려지지 않으면, 파일 전달 프로토콜은 예를 들어 HTTP 청킹을 사용함으로써 또는 프래그먼트가 서버에 의해 클라이언트에 완전히 전달되었을 때 접속을 폐쇄함으로써, 프래그먼트의 최종 길이를 표시할 수 있어야 한다.
각각의 프래그먼트는 세그먼테이션 맵 생성의 시간에 완전한 리소스에 대한 알려진 또는 알려지지 않은 위치(예를 들어, 오프셋)을 갖는다. 그러므로, 각각의 프래그먼트에 대해, 세그먼테이션 맵은 프래그먼트의 오프셋을 표시할 수 있다. 위치가 알려지지 않으면, 클라이언트 또는 디코더는 세그먼테이션 맵을 수신한 후에(예를 들어, 이전의 프래그먼트의 종료의 위치가 결정되었을 때, 또는 주어진 프래그먼트의 위치를 포함하는 업데이트된 세그먼테이션 맵을 수신함으로써) 위치를 결정할 수 있다. 프래그먼트의 위치를 알지 않는 하나의 단점은 (나중에 설명되는 것과 같이, 메모리-제한된 클라이언트가 세그먼테이션 맵 내에 제공된 의존성 정보에 기초하여, 이러한 이동들 또는 복사들을 최소화하기 위해 프래그먼트들의 검색을 정렬할 수 있을지라도) 그것이 추가적인 이동 또는 복사 동작에 이르게 할 수 있다는 것이다.
각각의 프래그먼트는 파일 검색 프로토콜, 예를 들어 HTTP URL 또는 URL과 그 URL 내로의 오프셋의 조합에 의해 사용될 그 자신의 식별자(예를 들어, 로케이터, 이름 등)를 갖는다. 그러므로, 각각의 프래그먼트에 대해, 세그먼테이션 맵은 프래그먼트의 식별자를 표시할 수 있다. 이것은 그 자신의 리소스로서 개별적인 프래그먼트를 검색하기 위해 OOB와 같은 매커니즘들을 사용하고 또는 다양한 이유들로 다수의 상이한 서버들을 사용하는 신축성을 가능하게 한다. 검색 도메인 내의 또는 콘텐트 처리 이유들로 인한 로드 밸런싱은 로드 확산으로 인해 성능 개선들에 이르게 할 수 있다. 각각의 프래그먼트에 대한 로케이터의 사용은 URL 레벨에서 또는 대안적 서비스들(예를 들어, [alt-services])과 같은 메커니즘들을 사용하여 또 하나의 전달 또는 검색 프로토콜로 리다이렉트하는 것을 또한 가능하게 한다.
각각의 프래그먼트는 비밀성 및 무결성 검증을 위한 개별적인 보안 메커니즘을 가질 수 있다. 그러므로, 각각의 프래그먼트에 대해, 세그먼테이션 맵은 프래그먼트와 연관된 보안 동작들을 수행하는 데 필요한 정보를 포함할 수 있다. 이것은 프래그먼트의 데이터에 걸친 해시일 수 있거나, 어떤 증명 또는 키가 해시 또는 서명을 발생시키기 위해 사용되었는지를 표시할 수 있다.
각각의 프래그먼트에 대해, 세그먼테이션 맵은 어떤 순서로 그것이 최적한 성능을 위해 프래그먼트들을 검색하여야 하는지를 클라이언트에게 표시하는 검색 힌트들 또는 의존성 정보를 포함할 수 있다. 한 이러한 최적화는 전달이 완료할 때까지의 지연을 최소화하는 것이다. 또 하나의 힌트는 특정한 프래그먼트가 하나 또는 여러 개의 다른 프래그먼트들이 이미 성공적으로 전달된 후에 전달되어야 한다는 것을 표시할 수 있다.
각각의 프래그먼트에 대해, 세그먼테이션 맵은 수신 클라이언트가 완전한 리소스라기보다는, 완전한 전달 전에 또는 혼자 힘으로 프래그먼트를 이용할 수 있게 하는 리소스 미디어 유형과 연관된 애플리케이션-레벨 힌트들을 포함할 수 있다.
세그먼테이션 맵은 또한 리소스-레벨 특성들을 가질 수 있다. 예를 들어, 세그먼테이션 맵의 업데이트들이 적절한 점들에서 이루어지는 것을 보장하기 위해, 세그먼테이션 맵은 전달 및 리어셈블리 과정에서의 특정한 단계들이 도달되었을 때 업데이트된 세그먼테이션 맵이 요청될 수 있다는 힌트들을 포함할 수 있다.
이제 도 1을 참조하면, 클라이언트(102)는 서버(104)와 통신할 수 있다. 여기서 사용된 것과 같이 "서버"는 서비스를 제공하는 단일 컴퓨터 또는 서비스를 제공하는 컴퓨터들의 세트일 수 있고, 여기서 컴퓨터들의 세트는 공동 배치될 수 있거나(예를 들어, 컴퓨터들의 클러스터) 지리적으로 분산될 수 있다. 클라이언트(102)는 수신기(202) 및 디코더(204)를 포함할 수 있다. 수신기(202)는 클라이언트(102)가 서버(104)로부터 데이터를 수신할 수 있게 하는 회로를 포함한다(예를 들어, RF 수신기 또는 이더넷 인터페이스와 같은, 유선 또는 무선 링크). 디코더(204)는 다양한 미디어 파일 포맷들을 디코딩하도록 동작가능하다. 서버(104)는 소스 피드(302), 인코더(304), 패킷타이저(306), 및 세그먼터(308)를 포함할 수 있다. 소스 피드(302)는 (예를 들어, 케이블 피드, 위성 피드, 또는 다른 소스로부터) 발생되는 대로 라이브 데이터, 또는 이미 발생되고 서버(104) 또는 다른 장소에 저장된 데이터와 같은 미디어 데이터를 서버(104)에 제공할 수 있다. 인코더(304)는 소스 피드(302)로부터 수신된 미디어 데이터를 예를 들어 H.264 또는 MPEG-4 어드밴스트 비디오 코딩(AVC)을 사용하여 다양한 미디어 샘플들로 인코딩하도록 동작가능하다. 패킷타이저(306)는 미디어 샘플들을 취하고 그들을 HTTP와 같은 패킷-기반 프로토콜을 통해 송신하기에 적합한 패킷타이징된 포맷으로 놓도록 동작가능하다(예를 들어, 패킷타이저(306)는 예를 들어, 미디어 샘플들을 포함하는 mdat 박스를 갖는 미디어 세그먼트를 생성함으로써, 미디어 샘플들을 ISO 베이스 미디어 파일 포맷으로 놓을 수 있다). 세그먼터(308)는 패킷타이징된 미디어를 취하고 그것을 세그먼트된 포맷으로 놓고 그것을 세그먼트된 포맷으로 전달하도록(예를 들어, 세그먼테이션 맵에 따라 그것을 전달하도록) 동작가능하다.
도 2는 세그먼테이션 맵을 발생시키고 수신하는 예시적인 실시예에 따른 방법을 도시한다. 일부 실시예들에서, 방법은 제1 프래그먼트 및 제2 프래그먼트를 포함하는 프래그먼트들의 정렬된 세트를 포함하는 미디어 세그먼트에 대한 세그먼테이션 맵을 발생시키는 단계를 포함한다(단계 202a). 실시예에서, 서버(104)는 세그먼테이션 맵을 발생시키는 단계를 수행한다. 일부 실시예들에서, 방법은 제1 프래그먼트 및 제2 프래그먼트를 포함하는 프래그먼트들의 정렬된 세트를 포함하는 미디어 세그먼트에 대한 세그먼테이션 맵을 수신하는 단계를 포함한다(단계 202b). 실시예에서, 클라이언트(102)는 세그먼테이션 맵을 수신하는 단계를 수행한다.
도 3은 동적으로 발생된 미디어 스트림을 전달(또는 수신)하는 예시적인 실시예들을 도시한다. 예를 들어, 일부 실시예들에서, 동적으로 발생된 미디어 스트림은 라이브 텔레비전 피드와 같은, 데이터의 라이브 소스를 나타낸다. 일부 실시예들에서, 방법들은 HTTP를 사용하는, 인터넷을 통해 이루어질 수 있고, 클라이언트(102)와 서버(104) 둘 다는 인터넷 가능 디바이스들일 수 있다. 한 실시예에 따르면, 동적으로 발생된 미디어 스트림을 클라이언트에 전달하는 방법 - 미디어 스트림은 제1 미디어 세그먼트 및 제2 미디어 세그먼트를 포함하는 복수의 미디어 세그먼트들을 포함함 - 이 제공된다. 방법은 클라이언트로부터, 매니페스트 파일에 대한 요청을 수신하는 단계를 포함한다(단계 302). 일부 실시예들에서, 매니페스트 파일은 클라이언트가 미디어 세그먼트들에 대한 요청들을 발생시킬 수 있게 하는 정보를 포함한다. 방법은 미디어 파일에 대한 요청을 수신한 것에 응답하여, 클라이언트에, 매니페스트 파일을 송신하는 단계를 추가로 포함한다(단계 304). 방법은 클라이언트에 매니페스트 파일을 송신한 후에, 클라이언트로부터, 제1 미디어 세그먼트를 식별하는 요청을 수신하는 단계를 추가로 포함한다(단계 306). 일부 실시예들에서, 제1 미디어 세그먼트를 식별하는 요청이 클라이언트가 매니페스트 파일을 처리한 결과로서 클라이언트에 의해 송신되었다. 일부 실시예들에서, 요청은 서버가 완전한 미디어 세그먼트를 클라이언트에 제공할 수 있기 전에(예를 들어, 서버는 moof 및 mdat 박스들을 발생시키는 것을 완료하지 않음) 클라이언트에 의해 송신된다.
방법은 제1 미디어 세그먼트를 식별하는 요청에 응답하여, 제1 미디어 세그먼트에 대한 세그먼테이션 맵을 클라이언트에 송신하는 단계를 추가로 포함한다(단계 308). 일부 실시예들에서, 제1 미디어 세그먼트는 제1 프래그먼트(예를 들어, moof 박스) 및 제2 프래그먼트(예를 들어, mdat 박스)를 포함하는 프래그먼트들의 정렬된 세트을 포함하고 세그먼테이션 맵은 서버로부터 제1 프래그먼트를 검색하는 데 사용하기 위한 제1 프래그먼트 식별자를 포함하는 제1 프래그먼트 메타데이터, 서버로부터 제2 프래그먼트를 검색하는 데 사용하기 위한 제2 프래그먼트 식별자를 포함하는 제2 프래그먼트 메타데이터, 및 제1 세그먼트가 제2 세그먼트 전에 정렬된다는 것을 표시하는 정보를 포함하는, 프래그먼트들의 세트 내의 프래그먼트들의 정렬을 식별하는 정렬 정보를 포함한다.
도 4는 동적으로 발생된 미디어 스트림을 수신하는 예시적인 실시예들을 도시하고, 제1 미디어 세그먼트 및 제2 미디어 세그먼트를 포함하는 복수의 미디어 세그먼트들을 포함하는 미디어 스트림이 제공된다. 방법은 서버에, 매니페스트 파일에 대한 요청을 송신하는 단계를 포함한다(단계 402). 일부 실시예들에서, 매니페스트 파일은 클라이언트가 미디어 세그먼트들에 대한 요청들을 발생시킬 수 있게 하는 정보를 포함한다. 방법은 매니페스트 파일을 수신하는 단계를 추가로 포함한다(단계 404). 방법은 수신된 매니페스트 파일을 처리하는 단계를 추가로 포함한다(단계 406). 방법은 매니페스트 파일을 처리한 후에, 서버에, 제1 미디어 세그먼트를 식별하는 요청을 송신하는 단계를 추가로 포함한다(단계 408). 방법은 제1 미디어 세그먼트를 식별하는 요청을 송신한 것에 응답하여 제1 미디어 세그먼트에 대한 세그먼테이션 맵을 수신하는 단계를 추가로 포함한다(단계 410). 일부 실시예들에서, 제1 미디어 세그먼트는 제1 프래그먼트 및 제2 프래그먼트를 포함하는 프래그먼트들의 정렬된 세트을 포함하고 세그먼테이션 맵은 제1 서버로부터 제1 프래그먼트를 검색하는 데 사용하기 위한 제1 프래그먼트 식별자를 포함하는 제1 프래그먼트 메타데이터, 서버로부터 제2 프래그먼트를 검색하는 데 사용하기 위한 제2 프래그먼트 식별자를 포함하는 제2 프래그먼트 메타데이터, 및 제1 세그먼트가 제2 세그먼트 전에 정렬된다는 것을 표시하는 정보를 포함하는, 프래그먼트들의 세트 내의 프래그먼트들의 정렬을 식별하는 정렬 정보를 포함한다. 방법은 서버에, 제1 프래그먼트에 대한 요청을 송신하는 단계를 추가로 포함한다(단계 412). 방법은 제1 프래그먼트를 수신하는 단계를 추가로 포함한다(단계 414).
도 5는 동적으로 발생된 미디어 스트림을 전달하는 추가의 예시적인 실시예들을 도시한다. 예를 들어, 일부 실시예들에서, 클라이언트(102)는 제1 미디어 세그먼트에 대한 요청(또는 기타 요청) 내에 클라이언트가 세그먼트된 모드를 지원한다는 표시자를 포함할 수 있다. 일부 실시예들에서, 동적으로 발생된 미디어 스트림을 클라이언트에 전달하는 방법은 표시자에 적어도 부분적으로 기초하여, 미디어 세그먼트를 전달하기 위해 세그먼트된 모드를 사용하기를 결정하는 단계를 추가로 포함한다(단계 502). 예를 들어, 클라이언트가 세그먼트된 모드를 지원하지 않으면, 서버(104)는 세그먼트된 모드를 사용하지 않을 수 있으므로, 클라이언트에 세그먼테이션 맵을 송신하지 않을 것이다. 일부 실시예들에서, 미디어 세그먼트를 전달하기 위해 세그먼트된 모드를 사용하기로 한 결정은 제1 미디어 세그먼트가 완전히 발생되었는지에 추가로 의존한다. 예를 들어, 제1 미디어 세그먼트가 완전히 발생되었다면, 서버(104)는 제1 미디어 세그먼트를 전달하기 위해 통상적인 파일 스트리밍 기술들을 사용할 수 있다. 반대로, 제1 미디어 세그먼트가 완전히 발생되지 않았다면, 서버(104)는 제1 미디어 세그먼트를 전달하기 위해 세그먼트된 모드를 사용하기를 결정할 수 있다.
본 발명의 실시예들은 그것이 전달 준비가 되도록 소스로부터 수신된 미디어를 처리 또는 준비하는 많은 방식들을 지원한다. 예를 들어, 일부 실시예들에서, 방법은 미디어 스트림을 동적으로 발생하는 소스로부터 제1 미디어 세그먼트의 부분을 수신하는 단계를 추가로 포함할 수 있다(단계 504). 실시예에서, 제1 미디어 세그먼트의 부분이 소스 피드(302)를 통해 수신된다. 일부 실시예들에서, 제1 미디어 세그먼트의 부분은 미디어 샘플 및 미디어 애플리케이션 데이터 단위(ADU) 중 적어도 하나에 대응한다(예를 들어, 제1 미디어 세그먼트의 부분은 미디어 프레임들(즉, 오디오 프레임들 및/또는 비디오 프레임들)을 포함할 수 있다). 일부 실시예들에서, 수신된 제1 미디어 세그먼트의 부분이 예를 들어, H.264 또는 MPEG-4 어드밴스트 비디오 코딩(AVC)과 같은 오디오 또는 비디오 포맷으로 인코딩된다. 다른 실시예들에서, 방법은 제1 미디어 세그먼트를 인코딩하는 단계를 추가로 포함할 수 있다(단계 506). 예를 들어, 인코딩은 제1 미디어 세그먼트의 부분을 H.264 또는 MPEG-4 어드밴스트 비디오 코딩(AVC)과 같은 오디오 또는 비디오 포맷으로 변환할 수 있다. 실시예에서, 인코더(304)는 이 단계를 수행한다. 방법은 포맷에 따라 제1 미디어 세그먼트의 부분을 패킷타이징하는 단계를 추가로 포함할 수 있다(단계 508). 예를 들어, 포맷은 ISO 베이스 미디어 파일 포맷(ISOBMFF)일 수 있다. 실시예에서, 패킷타이저(306)는 이 단계를 수행한다. 방법은 제1 미디어 세그먼트를 세그먼트하고 제1 미디어 세그먼트에 대한 세그먼테이션 맵을 발생시키는 단계를 추가로 포함할 수 있다(단계 510). 예를 들어, 세그먼테이션 맵은 본원에서 개시된 예시적인 세그먼테이션 맵들의 하나 이상의 특성을 가질 수 있다. 실시예에서, 세그먼터(308)는 이 단계를 수행한다. 일부 실시예들에서, 제1 미디어 세그먼트에 대한 세그먼테이션 맵을 발생시키는 단계는 포맷 내의 제1 미디어 세그먼트의 패킷타이징된 부분에 기초한다.
일부 실시예들에서, 방법은 새로운 정보에 기초하여 세그먼테이션 맵을 업데이트하고 업데이트된 맵을 클라이언트에 송신하는 단계를 추가로 포함한다(단계 512). 예를 들어, 세그먼테이션 맵을 초기에 생성하는 시간에, (미디어 세그먼트 내의 개별적인 프래그먼트들의 길이 또는 위치 정보와 같은) 소정의 정보가 알려지지 않을 수 있다. 미디어 데이터의, 또는 미디어 세그먼트 내의 특정한 프래그먼트의 인코딩 및 패킷타이징을 완료할 시에, 서버(104)는 그 시간에 새로운 정보(예를 들어, 길이 또는 위치 정보)로 세그먼테이션 맵을 업데이트할 수 있다. 방법은 클라이언트로부터, 제1 프래그먼트를 식별하는 요청을 수신하는 단계(단계 514); 및 제1 프래그먼트를 식별하는 요청을 수신한 것에 응답하여, 클라이언트에, 제1 프래그먼트를 송신하는 단계(예를 들어, 제1 프래그먼트는 HTTP 청킹을 사용하여 클라이언트에 송신될 수 있다)(단계 516)를 추가로 포함할 수 있다.
도 6은 동적으로 발생된 미디어 스트림을 수신하는 추가의 예시적인 실시예들을 도시한다. 일부 실시예들에서, 동적으로 발생된 미디어 스트림을 수신하는 방법은 서버에, 제2 프래그먼트에 대한 요청을 송신하는 단계를 추가로 포함할 수 있다(단계 602). 방법은 클라이언트에 의해, 제1 프래그먼트와 동시에 제2 프래그먼트를 수신하는 단계를 추가로 포함할 수 있다(단계 604). 일부 실시예들에서, 클라이언트는 클라이언트가 미디어 세그먼트에 대한 프래그먼트들의 모두를 수신할 때까지, 계속 프래그먼트들에 대한 요청들을 송신하고, 대응하는 프래그먼트들을 수신할 수 있다. 방법은 제1 프래그먼트를 디코딩하고 플레이하는 단계를 추가로 포함할 수 있다(단계 606). 일부 실시예들에서, 제1 프래그먼트를 디코딩하고 플레이하는 단계는 클라이언트가 제1 미디어 세그먼트의 제3 프래그먼트를 수신하기 전에 발생한다. 방법은 제1 프래그먼트를 검증하는 단계를 추가로 포함할 수 있다(단계 608). 방법은 제1 미디어 세그먼트를 검증하는 단계를 추가로 포함할 수 있다(단계 610). 일부 실시예들에서, 제1 세그먼트를 디코딩하고 플레이하는 단계는 제1 프래그먼트를 검증한 후에 그리고 제1 미디어 세그먼트를 검증하기 전에 발생한다.
본 발명의 실시예들은 많은 상이한 전달 메커니즘들에 적용가능하다. 예를 들어, 일부 실시예들에서 클라이언트는 (예를 들어, 미디어 세그먼트들의 프래그먼트들을 포함하는) 서버로부터 데이터를 활동적으로 요청, 또는 풀할 수 있다. 다른 실시예들에서, 클라이언트는 수동일 수 있고, 일부 다른 엔티티는 (예를 들어, 미디어 세그먼트들의 프래그먼트들을 포함하는) 클라이언트에 데이터를 푸시할 수 있다.
도 7은 미디어 스트림을 전달하는 예시적인 실시예들을 도시한다. 한 실시예에 따르면, 클라이언트에 미디어 세그먼트를 전달하는 방법이 제공된다. 방법은 프래그먼트들의 시퀀스로 세그먼트된 미디어 세그먼트에 대한 세그먼테이션 맵을 발생시키는 단계를 포함한다(단계 708). 방법은 클라이언트에 세그먼테이션 맵을 송신하는 단계를 추가로 포함한다(단계 710). 일부 실시예들에서, 방법은 서버에 의해, 미디어 세그먼트를 수신하는 단계를 추가로 포함할 수 있다(단계 702). 예를 들어, 서버는 소스 피드(302)를 통해 미디어 세그먼트를 수신하고, 인코더(304), 패킷타이저(306), 및 세그먼터(308) 중 하나 이상을 통해 세그먼트를 통과시킬 수 있다. 방법은 미디어 세그먼트를 제1 프래그먼트 및 제2 프래그먼트를 포함하는 프래그먼트들의 시퀀스로 세그먼트하는 단계를 추가로 포함할 수 있다(단계 704). 예를 들어, 이러한 세그먼팅은 세그먼트(308)에 의해 행해질 수 있다. 방법은 클라이언트로부터, 미디어 세그먼트에 대한 제1 요청을 수신하는 단계를 추가로 포함할 수 있다(단계 706). 방법은 클라이언트로부터, 제1 프래그먼트에 대한 제2 요청을 수신하는 단계를 추가로 포함할 수 있다(단계 712). 방법은 클라이언트에, 제1 프래그먼트를 송신하는 단계를 추가로 포함할 수 있다(단계 714). 방법은 새로운 정보에 기초하여 세그먼테이션 맵을 업데이트하고 업데이트된 맵을 클라이언트에 송신하는 단계를 추가로 포함할 수 있다(단계 716). 예를 들어, 일부 실시예들에서 새로운 정보는 복수의 프래그먼트들 중 하나의 프래그먼트의 길이, 미디어 세그먼트 내의 그 프래그먼트의 시작 위치, 및 미디어 세그먼트 내의 그 프래그먼트의 종료 위치 중 하나 이상을 포함한다. 일부 실시예들에서, 세그먼테이션 맵을 업데이트하는 것과 업데이트된 맵을 클라이언트에 송신하는 것 중 하나 또는 둘 다는 클라이언트가 업데이트된 세그먼테이션 맵을 요청한 것에 응답하여 수행될 수 있다. 일부 실시예들에서, 서버는 클라이언트에 보조 서버(예를 들어, 상이한 신뢰 도메인 내의 아웃-오브-밴드 서버)로부터 프래그먼트를 요청하라고 지시할 수 있다. 일부 실시예들에서, 세그먼테이션 맵은 클라이언트를 특정한 프래그먼트에 대한 보조 서버로 다이렉트하는 정보를 포함할 것이다.
도 8은 미디어 세그먼트를 디코딩하는, 예시적인 실시예에 따른 방법을 도시한다. 방법은 클라이언트에 의해, 미디어 세그먼트에 대한 요청을 송신하는 단계를 포함한다(단계 802). 방법은 클라이언트에 의해, 프래그먼트들의 시퀀스로 세그먼트된 미디어 세그먼트에 대한 세그먼테이션 맵을 수신하는 단계를 추가로 포함한다(단계 804). 일부 실시예들에서, 방법은 클라이언트에 의해, 제1 프래그먼트를 요청하는 단계를 추가로 포함할 수 있다(단계 806). 방법은 클라이언트에 의해, 제1 프래그먼트를 수신하는 단계를 추가로 포함할 수 있다(단계 808). 방법은 클라이언트에 의해, 제1 프래그먼트를 플레이하는 단계를 추가로 포함할 수 있다(단계 810). 방법은 제1 프래그먼트의 무결성을 검증하는 단계를 추가로 포함할 수 있다(단계 812). 방법은 미디어 세그먼트의 무결성을 검증하는 단계를 추가로 포함할 수 있다(단계 814). 방법은 업데이트된 세그먼테이션 맵을 수신하는 단계를 추가로 포함할 수 있다(단계 816). 일부 실시예들에서, 복수의 프래그먼트들 중 다른 것 각각에 대해, 방법은 이러한 프래그먼트를 요청, 수신, 및 플레이하는 단계를 추가로 포함할 수 있다. 일부 실시예들에서, 미디어 세그먼트의 어떤 프레그먼트를 플레이하기 전에, 클라이언트는 이러한 프래그먼트의 무결성을 먼저 검증하고 클라이언트가 이러한 프래그먼트의 무결성을 긍정적으로 검증하면 이러한 프래그먼트만 플레이한다. 일부 실시예들에서, 클라이언트는 프래그먼트들의 시퀀스에 대응하는 논리적 순서와 상이한 순서로 프래그먼트들에 대한 요청들을 정렬할 수 있다. 일부 실시예들에서, 프래그먼트들에 대한 요청들이 그 안에서 이루어지는 순서는 프래그먼트들 각각에 관한 크기 의존성 및 콘텐트 의존성 정보와 같은, 의존성 정보에 적어도 부분적으로 의존한다. 일부 실시예들에서, 클라이언트는 상이한 프래그먼트들에 대한 요청들을 동시에 할 수 있다. 일부 실시예들에서, 프래그먼트들은 상이한 서버들로부터 수신될 수 있고, 일부 실시예들에서 프래그먼트들에 대한 요청들이 상이한 서버들에 송신될 수 있다.
이제 도 9를 참조하면, 클라이언트(102)는 또한 요청 중재기(902)와 통신할 수 있다. 요청 중재기(902)는 클라이언트(102)의 일부일 수 있고(예를 들어, 클라이언트(102)는 클라이언트(102)의 요청 중재기 소자와 통신하는 비디오 플레이어와 같은, 앱을 실행할 수 있고), 또는 요청 중재기(902)는 클라이언트(102) 가까이에 위치할 수 있고, 또는 그것은 서버(104)의 일부일 수 있고, 또는 서버(104) 가까이에 위치할 수 있고, 또는 그것은 클라이언트(102) 또는 서버(104)와 분리되고 독립일 수 있다. 서버(104)로부터 세그먼테이션 맵을 수신한 후에, 클라이언트(102)(예를 들어, 앱)는 다양한 미디어 프래그먼트들에 대한 일련의 요청들을 송신할 수 있다. 세그먼테이션 맵은 일부 프래그먼트들이 다른 것들에 의존성을 갖는다는 것을 표시할 수 있다. 이것은 예를 들어, 하나의 프래그먼트가 검색될 수 있기 전에, 또 하나의 프래그먼트가 먼저 검색되어야 한다는 것을 의미할 수 있다. 요청 중재기(902)의 역할은 이 의존성 정보를 처리하는 것이다. 그러므로, 클라이언트(102)(예를 들어, 앱)는 중재기(902)에 프래그먼트 요청들을 송신할 수 있고, 중재기(902)는 다음에 세그먼테이션 맵 내에 포함된 의존성 정보에 기초하여 적절한 시간에 서버(104)에 요청을 전송할 수 있다. 그것은 예를 들어, (예를 들어, 의존성이 없으면) 중재기(902)가 서버(104)에 요청들을 즉각 전송하는 것을 의미할 수 있고, 또는 그것은 중재기(902)가 조건이 만족될 때까지 요청을 늦추거나 차단하게 한다는 것(예를 들어, 어떤 의존성이 해결된다는 것)을 의미할 수 있다. 요청 중재기(902)는 그것이 프래그먼트 우선순위, 또는 다른 프래그먼트 메타데이터에 기초하여 요청들을 중재하게 하는 논리를 또한 포함할 수 있다.
이제 도 10을 참조하면, 클라이언트(102)는 또한 많은 보조 서버들(1002)과 통신할 수 있다. 그러므로, 서버(104)로부터 모든 미디어 프래그먼트들을 수신하기보다는, 클라이언트(102)는 상이한 보조 서버들(1002) 중 하나 이상으로부터 하나 이상의 프래그먼트를 수신할 수 있다. 일부 실시예들에 따르면, 클라이언트(102)는 서버(104)로부터 프래그먼트들을 초기에 요청할 것이지만, 요청들은 다음에 보조 서버들(1002) 중 하나로 리다이렉트될 것이다. 일부 실시예들에 따르면, 클라이언트(102)는 예를 들어, 세그먼테이션 맵 내에 포함된 정보에 기초하여, 보조 서버들(1002) 중 하나로부터 직접 프래그먼트들을 초기에 요청할 것이다(예를 들어, 프래그먼트 로케이터는 보조 서버를 지정할 수 있다). 일부 실시예들에 따르면, 요청 중재기(902)는 보조 서버들 중 하나로 요청들을 다이렉트할 것이다. 예를 들어, 요청 중재기(902)는 로드 밸런서로서 기능할 수 있고, 다른 서버들에 송신된 요청들의 볼륨 및 이용가능한 대역폭과 같은 많은 인자들에 기초하여, 또는 지리적 고려들에 기초하여, 보조 서버로 요청을 다이렉트하는 결정을 할 수 있다.
서버(104), 및 보조 서버들(1002) 중 하나 이상이 상이한 신뢰 도메인(예를 들어, 도 10에 도시한 3개의 신뢰 도메인(1004, 1006, 1008) 중 하나)에 상주하는 것이 가능하다. 이것은 동일한 근원 정책을 함축할 수 있고, 그 리소스에 액세스하기 전에 리소스의 무결성을 검증하기를 원하는 클라이언트에 대한 함축들을 갖는다. 본 발명의 실시예들은 아래에 보다 완전히 설명되는 것과 같이, 이것을 완전히 지원하고, 클라이언트가 많은 상이한 신뢰 도메인들에 걸쳐 무결성을 검증할 수 있게 한다.
(간소화를 위해) 도면에 완전히 도시하지 않았지만, 일부 실시예들에서 클라이언트(102), 서버(104), 요청 중재기(902), 및 보조 서버들(1002) 각각은 각각 서로 통신할 수 있다(예를 들어, 서버(104)는 보조 서버들(1002) 각각과 통신할 수 있고, 그 반대도 가능하다). 서버(104)의 책임들은 하나 이상의 보조 서버(1002) 간에 분배될 수 있다는 점에 또한 주목한다. 이것은 예를 들어, 미디어 리소스를 인코딩하는 서버, 세그먼테이션 맵을 발생시키는 서버, 클라이언트 요청들을 중재하는 서버, 및 미디어 리소스 프래그먼트들을 클라이언트에 서브하는 서버 또는 서버들은 각각 상이한 서버들일 수 있다는 것을 의미한다.
비밀성 및 무결성 해결책들
세그먼테이션 맵은 비밀성 및 무결성 메커니즘들이 채용되든지 간에 장점들을 제공한다. 그러나, 이러한 메커니즘들이 채용되는 경우에, 세그먼테이션 맵은 현재 기술 수준보다 추가적인 장점들을 제공한다.
전형적으로, 완전한 리소스의 무결성은 다수의 방식들로 결정될 수 있다. 가장 기본적인 것은 리소스가 클라이언트에서 완전히 수신되었을 때 리소스를 검증하는 것이다. 이러한 해결책들의 가장 기본은 완전한 리소스에 걸쳐 해시 값을 간단히 계산하고 리소스에 대한 믿을 만한 도메인으로부터 안전한 전달을 가정한 세그먼테이션 맵 내에 그것을 포함한다는 것이다. HTTP에 대한 콘텐트-서명 헤더 필드(예를 들어, [CONTENTSIG] 참조) 또는 머클 무결성 콘텐트 인코딩(예를 들어, [MICE] 참조)과 같은 몇가지 해결책들이 이것에 대해 존재한다. 그러나, 클라이언트가 점진적으로 소비하기를 원할 수 있는 리소스의 세그먼테이션에 대한 이들 방식을 사용하는 데 있어서 분명히 불리한 면이 있다. 클라이언트 또는 애플리케이션은 이러한 방식들을 위해, 비검증된 데이터를 사용하는 것을 피하기를 원한다면 완전한 리소스가 전달될 때까지 대기하여야 한다. 물론, 비검증된 데이터를 사용하는 것이 허용되었더라면, 대안이 데이터를 소비하고 다음에 사용자에게 경고하고 또는 그렇지 않으면 리소스가 나중에 검증을 실패하는 경우 처리했었을 것이다. 그것은 비검증된 그리고 나아가 비신뢰된 데이터를 사용하는 것에 의존하므로, 이 방식은 위험할 수 있고, 상책이 아니다.
검증을 위해 이러한 방식들이 갖는 또 하나의 문제는 완전한 리소스 검증이 리소스가 올바르게 검증하지 않는다는 것을 표시하면, 클라이언트는 어떤 프래그먼트가 검증에 실패하였는지를 결정할 수 없다는 것이다. 이 문제를 해결하기 위해, 개별적인 리소스 프래그먼트들이 그들 자신의 무결성 검증 정보를 필요로 한다. 이것은 각각의 프래그먼트를 전달-프로토콜 레벨 상의 그 자신의 리소스로서 취급하고, 세그먼테이션 맵이 무결성 검증 메커니즘과 연관된 임의의 파라미터들과 함께, 각각의 프래그먼트를 위해 사용된 무결성 검증 메커니즘을 표시하게 함으로써 달성될 수 있다.
리소스 프래그먼트를 점진적으로 소비할 때 검증을 가능하게 하기 위해서, 무결성 해결책은 그들이 전달되는 대로 리소스 프래그먼트의 적합한 청크들에 걸쳐 제공될 필요가 있다. 이러한 해결책은 바람직하게는 각각의 청크 내에 제공된 데이터의 양이 고정된 기록 크기들과 맞추어 조정하지 않을 때 차단 문제들을 피하기 위해 기록 크기들에 관해 신축성이 있어야 한다. 비디오와 같은 미디어 스트림들에 대해, 단일 미디어 샘플(예를 들어, 인코딩된 비디오 프레임)이 보호하기에 적합한 청크이다. MICE는 준비된 데이터에 대해 사용가능할 수 있었고 여기서 완전한 DASH 세그먼트들은 리소스 세그먼트의 전달을 시작하기 전에 이용가능하다(즉, 여기서 미디어 스트림이 동적으로 발생되지 않는다). (MICE에 의해 부과된) 고정된 기록 크기는 그 세팅에서 각각의 전달 청크로 완전한 기록들을 전달함으로써 주위에서 동작될 수 있다.
그러나, 라이브 또는 동적으로 발생된 콘텐트에 대해, 다음의 미디어 샘플이 특정한 청크의 송신을 준비하는 시간에 이용가능하지 않은 경우에, 상기 방식은 잘 되지 않는다. 대신에, 또 하나의 방식은 (완전한 미디어 세그먼트 대신에) 개별적인 청크들을 해시하고 각각의 기록을 갖는 결과적인 해시를 포함하는 것이다. 해시에 걸친 서명, 또는 키 잠금된 해시를 사용하는 것 둘 다는 세그먼테이션 맵의 제공자에 의해 신뢰된 소스로부터 나온 것과 같이 클라이언트에서 해시를 검증가능하게 하기 위해 사용될 수 있다. 이 해결책은 무결성 메커니즘 및 데이터를 보호하기 위한 그것의 구조로 인한 어떤 상당한 지연을 부가하는 것을 피한다.
데이터 무결성(데이터가 신뢰할만 하다는 것)은 보안의 한 중요한 양태이다. 또 하나의 양태는 비밀성이다(데이터를 허가되지 않은 당사자들로부터 숨기게 유지하는 것).
본 발명의 실시예들은 리소스의 전달이 다수의 엔티티들(예를 들어, 사용자에 가까운 에지 서버들 또는 캐시들)에 걸쳐 분산되게 한다. 그러나 주어진 미디어 리소스의 상이한 프래그먼트들을 잠재적으로 발생하고 전달할 수 있는 다수의 엔티티들을 갖는 것은 비밀성에 관한 일부 문제들을 제시한다. 보안 이유들로, 상이한 엔티티들은 보안 맥락을 공유하지 않을 수 있다. 그러므로, 세그먼테이션 맵은 키들과 같은, 리소스-프래그먼트-특정 보안-맥락 정보를 표시할 필요가 있을 수 있다.
점진적으로 소비되는 리소스 프래그먼트들에 대한 비밀성의 또 하나의 양태는 프래그먼트가 그것의 시작 점으로부터 복호화될 수 있기도 하고, 청크-레벨 상의 데이터가 복호화될 수 있다는 것을 보장하는 것이다. 이것은 일부 경우들에서 암호화-계층 패딩에게 암호화 알고리즘이 청크 경계에서 복호화를 수행할 수 있는 것을 보장하라고 요구할 수 있다.
상이한 신뢰 도메인들을 이용하는 것
개별적인 리소스 프래그먼트들에 대한 일반적인 로케이터들을 이용함으로써, 특정한 리소스 프래그먼트는 임의의 위치로부터 잠재적으로 검색될 수 있다. 즉, 하나의 프래그먼트의 검색 점은 또 하나의 프래그먼트의 검색 점에 의존하지 않을 수 있다. 그러므로, 상이한 프래그먼트들은 상이한 신뢰 도메인들(예를 들어, 아마도 상이한 도메인 이름 시스템(DNS) 이름들을 갖는 상이한 호스트들)로부터 검색될 수 있다. 리소스 세그먼트는 또한 리소스 프래그먼트에 대한 주 도메인이 결국에는 프래그먼트에 대한 콘텐트가 검색될 수 있는 하나 또는 다수의 보조 리소스들을 겨눌 수 있게 하는, OOB 콘텐트-인코딩을 사용하여 제공될 수 있었다.
이들 2가지 해결책은 다수의 OOB 보조 리소스들을 갖는 조합된 세그먼테이션 맵으로 잠재적으로 통합될 수 있고, 또는 2가지 해결책은 적합한 조합들에서 서로 다음에 적용될 수 있다.
임의의 리소스 위치를 겨누기 위한 OOB 인코딩 해결책뿐만 아니라 세그먼테이션 맵에 의해 생성되는 가능성은 다양한 함축들을 갖는다. 예를 들어, HTTP에서, 이것은 완전한 리소스의 도메인(주 도메인)의 제어 밖에 있는 리소스들의 로딩을 가능하게 하는, 동일한 근원 정책(예를 들어, [RFC6454] 참조)에 영향을 줄 수 있다. 이 결과를 피하기 위해, 적절한 보안 모델들이 적용될 수 있다. 하나의 가능성은 주 도메인(즉, 세그먼테이션 맵을 제공하는 것)이 보조 도메인으로부터 검색된 세그먼트의 무결성을 검증하는 방식을 제공하는 것, 즉, 보조 도메인으로부터 검색된 것은 주 도메인에 따라 의도된 것과 일치한다는 것이다. 이것은 세그먼테이션 맵 내에 프래그먼트에 대한 해시를 포함시킴으로써 가장 쉽게 실현된다. (보조 도메인을 신뢰하는 주 도메인에 기초하여) 또 하나의 가능성은 주 도메인이 보조 도메인에게 갖는 신뢰를 표시하기 위해 주 도메인에 대해 일부 방식을 갖는다는 것이다. 예를 들어, 주 도메인은 보조 도메인이 리소스 프래그먼트의 무결성을 증명하기 위해 어떤 키 또는 증명을 사용할 것인지를 세그먼테이션 맵 내에 표시함으로써 그렇게 할 수 있다.
세그먼테이션 맵의 예시적인 실시예
위에 설명된 특성들의 대부분 또는 모두를 이행하는 세그먼테이션 맵에 대한 많은 상이한 형태들 및 포맷들이 있다. HTTP 1.1로 사용될 수 있는 세그먼테이션 맵의 하나의 가능한 실시예가 아래에 제공된다.
이 예에서 클라이언트는 HTTP 1.1을 사용하여 로케이터(예를 들어, URL) "https://example.org/xyz/seg-2-14.mp4"에서 (이 예에서 프래그먼트된 MPEG-4(mp4) 미디어 세그먼트)인 리소스를 요청한다. 클라이언트는 그것이 세그먼테이션 메커니즘에 대한 그것의 지원을 표시하기 위해 "세그먼트된"이라고 하는 콘텐트 인코딩을 지원한다는 것을 표시한다. 서버는 또한 응답에서 세그먼테이션 메커니즘을 지원하고 이용한다. 응답은 세그먼트된 콘텐트 인코딩의 사용의 표시를 포함하고, 바디는 프래그먼트들을 디스크라이브하는 JSON 인코딩된 세그먼테이션 맵을 포함한다. 이 경우에, 제1 요청은 완전한 리소스가 구성되기 전에 도달한다.
HTTP 요청은 다음과 같다:
Figure pct00001
예시적인 세그먼테이션 맵을 포함하는, HTTP 요청에 대한 응답은 다음과 같다:
Figure pct00002
Figure pct00003
Figure pct00004
세그먼테이션 맵은 리소스 레벨 특성들로 시작된다. 이것은 세그먼테이션 맵에 의해 디스크라이브되는 리소스의 실제 미디어 유형("Content-Type")을 포함한다. 이것은 또한 하나가 완전한 리소스에 걸친 해시와 같이, 리소스 레벨 무결성 메커니즘들을 포함할 수 있는 장소이다. 그러나, 리소스가 아직 완전히 구성되지 않음에 따라, 그것은 이 예에서 가능하지 않다. 그러나, 상이한 리소스 프래그먼트들을 암호화하기 위해 사용되는 암호 키는 "Crypto-Key" 파라미터 내에 포함된다. 완전한 리소스 URL은 HTTP 요청의 맥락 밖에서 세그먼테이션 맵을 처리하는 것을 가능하게 하기 위해서만 포함된다.
세그먼테이션 맵은 또한 "Update-Hint" 속성들을 포함할 수 있다. 이것은 보다 완전한 정보를 위해 세그먼테이션 맵을 업데이트하는 것이 권장될 때를 표시한다. 이 경우에, 업데이트가 "4"로서 식별된 프래그먼트의 콘텐트 이용가능성에 의존한다는 의미를 갖는, 콘텐트-의존 속성이 있다. 나중에 설명되는 것과 같이, 이것은 리소스 콘텐트가 서버 측 상에서 알려질 때, 이 세그먼테이션 맵은 개방된 범위들 없이(즉, 시작 및 종료 위치들에 대한 알려진 값들로) 구성될 수 있다는 것을 표시한다. 그러나, 콘텐트-의존 속성은 하나에 세그먼테이션 맵이 언제 업데이트될 수 있는지를 결정하기 위해 데이터를 요청하기를 요구한다. 이 방식은 업데이트된 맵을 요청하기 전에 프래그먼트가 처리되는 것을 요구함에 따라, 또 하나의 보완적 방식은 더 많은 시간 기반 힌트를 사용하는 것이다. 이 예는 서버가 세그먼테이션 맵을 발생한 후 3초 내에, 세그먼테이션 맵이 업데이트되어야 한다는 것을 표시하기 위해, HTTP 만료 헤더를 포함한다. 이 경우에, 3초가 이 시간까지 완전한 리소스가 구성되었다는 것을 알았다는 것에 기초하여 표시된다. 만료 헤더는 또한 "Update-Hint" 속성 내에 파라미터로서 포함된다.
리소스 레벨 속성 다음에, 프래그먼트들의 정렬된 시퀀스를 디스크라이브하는 어레이가 따른다. 이 예에서, 리소스(미디어 세그먼트)는 4개의 세그먼트: 미디어 세그먼트의 styp 박스에 대응하는 제1 프래그먼트; 미디어 세그먼트의 moof 박스에 대응하는 제2 프래그먼트; mdat 박스의 헤더 부분에 대응하는 제3 프래그먼트; 및 mdat 박스의 페이로드 부분에 대응하는 제4 프래그먼트(즉, 미디어 샘플들)로 논리적으로 세그먼트된다.
용어에 관한 노트: 세그먼테이션 맵은 실제 리소스 데이터를 포함하는 의미에서 "프래그먼트들"을 포함하지 않고; 대신에, 세그먼테이션 맵은 실제 리소스 데이터를 어떻게 획득할 것인지에 관한 정보를 포함하는, 각각의 리소스 프래그먼트와 연관된 메타데이터를 포함한다. 그러므로, 세그먼테이션 맵 내에 "제1 프래그먼트"를 디스크라이브할 때, 의미하는 것은 제1 프래그먼트의 메타데이터, 또는 세그먼테이션 맵 내에 저장된 제1 프래그먼트와 연관된 정보이다.
어레이 내의 제1 프래그먼트(즉, 제1 프래그먼트의 메타데이터)가 이제 설명된다. 제1 프래그먼트 내의 제1 메타데이터 정보는 "Fragment" 파라미터 내에 주어지고 "1"의 값을 갖는, 프래그먼트에 대한 식별자이다. 이것 다음에 이 프래그먼트에 대한 프래그먼트 위치들의 세트를 제공하는 "FL" 파라미터, 즉, 프래그먼트가 그 자신의 리소스로서 요청될 수 있는 하나 이상의 URL이 따른다. "Offset" 파라미터는 알려진다면, 완전한 리소스 내로의 프래그먼트의 오프셋(또는 그 안의 위치), 및 프래그먼트의 길이를 제공한다. 포맷은 "시작-종료/길이"이다. 오프셋 파라미터의 3개의 값들 부분의 어느 것, 즉, 시작 위치, 종료 위치, 또는 길이는 알려지지 않을 수 있다(그리고 그러므로 제공되지 않는다). 이 제1 프래그먼트는 완전한 리소스의 시작(시작=0)에 있고 알려진 길이(길이=494)를 갖는다. 예에서, 값들 "0-493/494"는 시작 바이트, 종료 바이트, 및 바이트들의 길이를 제공한다.
제1 프래그먼트에 대한 다음 파라미터들은 "Size-Dependency" 및 "Content-Dependency"이다. 이들 파라미터는 프래그먼트들의 식별자들을 열거함으로써, 다른 프래그먼트들에 존재하는 어떤 의존성들을 표현할 수 있다. 크기 의존성 파라미터는 주어진 프래그먼트들의 시작 위치를 결정하기 위해 클라이언트가 필요로 하는 다른 프래그먼트들의 크기 정보(시작 및 종료 위치들, 길이)가 어떤 것인지를 식별하는 프래그먼트 식별자들의 세트이다. 콘텐트 의존성 파라미터는 주어진 프래그먼트를 수신하기 위해 클라이언트가 필요로 하는 다른 프래그먼트들이 어떤 것인지를 식별하는 프래그먼트 식별자들의 세트이다. 이 경우에, 이들 의존성 파라미터 모두는 비어있는 세트를 포함한다. 파라미터들은 그러므로 HTTP 응답에서 배제될 수 있지만, 설명을 위해 여기에 포함된다. 우선순위 파라미터는 다른 프래그먼트들과 관련하여 이 프래그먼트를 요청하는 데 있어서 상대적 우선순위를 표시하는데; 이 예에서, 더 낮은 수는 더 중요하거나 더 큰 우선순위이다. 이 정보의 잠재적 사용들이 아래에 더 설명된다.
제1 프래그먼트의 메타데이터를 계속 고려하면, 우선순위 파라미터 다음에, 그 자신의 리소스로서 프래그먼트와 관련된 속성들의 세트가 따른다. 즉, 파라미터들은 프래그먼트를 취득할 때 사용될 수 있다. 이 경우에, "aesgcm"의 콘텐트 인코딩이 표시된다. AES GCM(예를 들어, [aesgcm] 참조)은 전체 프래그먼트에 걸친 암호화 및 무결성 보호 메커니즘이다. 이 콘텐트 인코딩을 채용하는 프래그먼트들은 프래그먼트 시작으로부터 끝까지의 암호-블록에 기초하여 연속적으로 복호화될 수 있지만, 무결성 검증은 완전한 프래그먼트가 전달되었을 때 단지 수행될 수 있다. 이 메커니즘은 키 잠금되고 솔트되는데; 키는 비밀 보호의 잠금을 푸는 방식이고, 또한 무결성이 프래그먼트에 대해 보존된다는 것을 확실하게 하는 방식이다. 본 예에서, 실제 키-id는 모든 리소스 프래그먼트들에 걸쳐 공통이다(그리고 암호-키 파라미터 내에 포함된 리소스 레벨 키-id 값과 동일하다). 그러나, 이 예에서의 각각의 프래그먼트는 2개의 프래그먼트에 대해 동일한 암호를 사용하는 것을 방지하기 위해 개별 솔트된 값을 갖는다. 이것은 "암호화" 파라미터에 의해 제공된다. 이것은 제1 프래그먼트의 메타데이터를 종결한다,
제2 프래그먼트는 유사하지만, 그것의 파라미터들의 일부 차이들 및 추가의 파라미터들이 설명될 것이다. 첫째, 프래그먼트 id는 "2"이고, 이 프래그먼트에 대한 URL들은 또한 제2 프래그먼트를 지정한다(즉, URL들은 제1 프래그먼트에 대한 것들과 상이하다). 프래그먼트의 오프셋은 시작 위치를 제공하지만, 알려지지 않은 길이를 갖고 그러므로 알려지지 않은 종료 위치를 갖는다. 우선순위는 1로 설정되고, 이 완전한 리소스에서 가장 높은 우선순위의 프래그먼트이다. 속성들은 "Transfer-Encoding":"chunked"를 포함한다. 이것은 이 프래그먼트가 HTTP 청킹 메커니즘을 사용하여 전달될 수 있다는 것을 표시한다. 이것은 예를 들어, 그들이 서버 측 상에서 발생되는 대로 (예를 들어, 미디어 샘플들 및 그들의 메타데이터가 발생되는 대로) 프래그먼트에 대해 점진적으로 데이터를 전달하기 위해 사용될 수 있다. "Type-Specific": "moof" 파라미터 및 데이터는 완전한 리소스 미디어 유형 "video/mp4"의 맥락에서 해석될 것이다. 예를 들어, "moof"는 이 프래그먼트가 moof 박스를 포함하고 있다는 것을 표시할 수 있었다.
제3 프래그먼트(id="3")는 이 예에서, 알려진 길이(길이=12바이트)를 갖지만 (클라이언트가 제2 프래그먼트를 완전히 구성하거나, 업데이트된 세그먼테이션 맵을 수신할 때까지) 알려지지 않은 길이를 갖는 제2 프래그먼트 다음에 오므로, 시작 또는 종료 오프셋은 알려지지 않는다. 다른 프래그먼트들에의 이 프래그먼트의 의존성은 "Size-Dependency": {["1", "2"]} 및 "Content-Dependency":{["4"]}를 사용하여 표현된다. 크기 의존성은 여기서 프래그먼트들 1 및 2의 크기가 알려질 때 이 프래그먼트의 크기 및 위치가 주어진다는(즉, 클라이언트에 의해 알려질 것이라는) 것을 의미한다. 콘텐트-의존성은 여기서 이 프래그먼트의 콘텐트가 프래그먼트 4 내의 것에의 의존성을 갖는다는 것을 표시한다. 이 경우에, 이것은 프래그먼트 3은 프래그먼트 4 내에 있는 데이터에 대한 길이 필드를 포함하는 헤더를 나타내기 때문이다. 그래서 프래그먼트 3은 프래그먼트 4가 완전히 발생되었을 때까지 검색될 수 없는데, 왜냐하면 프래그먼트 3은 그 시간까지 스스로 발생될 수 없기 때문이다. 표시된 것과 같이, 이 프래그먼트는 최고 우선순위, 즉 우선순위 1을 갖는다.
제4 프래그먼트(id="4")는 제2 프래그먼트와 유사한 특성들을 갖는다. 그러나, 알려지지 않은 크기를 갖는 앞선 프래그먼트들로 인해, 이 프래그먼트의 실제 오프셋은 세그먼테이션 맵을 발생시키는 시간에 알려지지 않는다. 이 프래그먼트의 우선순위는 "1"이고, 그것은 다른 프래그먼트들에 콘텐트 의존성을 갖지 않는다. 그러나, 그것의 크기 및 오프셋은 프래그먼트 3에 의존한다. 콘텐트-유형 특정 힌트 "Type-Specific": "mdat-samples"는 이 프래그먼트가 mdat 박스의 샘플들의 시작에서 시작된다는 것을 표시한다. 이 힌트는 미디어-유형을 알고 있는 클라이언트가 청킹된 HTTP 트랜스퍼에 의해 전달되는 대로 데이터를 소비하기 시작할 수 있게 한다.
위에 표시된 것과 같이, 이 예에서, 각각의 프래그먼트의 메타데이터는 시퀀스로 그것의 순서(즉, 식별자들 1, 2, 3, 및 4)를 표시하는 프래그먼트 식별자를 포함한다. 부가적으로, 프래그먼트들(즉, 복수의 프래그먼트 메타데이터들)은 이 예에서, 정렬된 데이터 구조인 어레이 내에 저장되는데, 어레이는 프래그먼트들에 순서를 부과할 수 있다. 이 예에서, 2개의 순서(데이터 구조에 의해 함축된 것과 프래그먼트 식별자들에 의해 표시된 것)는 일치한다.
위에 설명된 세그먼테이션 맵이 주어지는 경우에, 클라이언트는 프래그먼트들을 요청하기 위한 적합한 순서를 결정할 수 있다. 예를 들어, 저장 제한들을 갖지 않고 추가적인 복사들이 갖는 문제들이 없는 클라이언트(예를 들어, 클라이언트는 프래그먼트들의 중간 검색 및 다음에 프래그먼트들의 어셈블리를 수행하려고 한다)에 대해, 하나의 가능한 검색 전략은 (콘텐트 의존성을 갖지 않고 우선순위 1인) 프래그먼트 2를 요청하고, 동시에 (또한 의존성을 갖지 않고 우선순위 1인) 프래그먼트 4를 요청하고, 동시에 (또한 의존성을 갖지 않지만, 더 낮은 우선순위 3인) 프래그먼트 1을 요청하는 것일 것이다. 그것은 프래그먼트 3을 남겨 놓는다. 프래그먼트 3은 (프래그먼트 4에) 콘텐트 의존성을 갖지만, 지연을 최소로 유지하기 위해서 클라이언트는 이 프래그먼트에 대한 또 하나의 동시 요청을 앞서 할 수 있어서, 이 요청은 프래그먼트 4가 완전히 발생될 때까지 늦쳐질 것이라는 것이 예상된다.
이제 도 11을 참조하면, 상기 요청들의 완료를 위한 가능한 시나리오가 도시된다. T0의 시간에, 세그먼테이션 맵은 클라이언트에 의해 처리되었고, 클라이언트는 위에 설명된 것과 같이 요청들을 한다. (각각 콘텐트 의존성을 갖지 않는) 프래그먼트들 1, 2, 및 4의 전달은 개별적인 요청들이 적절한 서버에 의해 처리되자마자 시작된다. 프래그먼트 1이 더 낮은 우선순위를 갖더라도, 이 예에서 그것은 그것의 제한된 크기로 인해 (시간 T1에서) 먼저 완료할 것이다. (그들의 트랜스퍼-인코딩 값마다) 프래그먼트들 2 및 4는 청킹된 전달을 사용하고 있다. 이 경우에, 메타데이터 및 미디어 샘플들의 청크들은 막대들로 표시된 것과 같이 주기적으로 트랜스포트될 것이다. 시간 T2에서, 서버(또는 서버들)는 프래그먼트들 2 및 4에 대해서 데이터의 발생을 완료하였고, T2 약간 뒤에 그들의 전달은 완료될 것이고 청킹된 트랜스포트 메커니즘은 그들의 전달의 완료를 표시할 것이다. 프래그먼트 3에 대한 요청은 이 예에 따라, 그것의 콘텐트 의존성으로 인해, T0 이후 T2까지 늦쳐졌다. 시간 T2에서, (이 예에서 mdat 박스의 길이를 식별하는 길이 정보인) 프래그먼트 3에 대한 데이터가 발생되었고 그것의 전달이 시작될 수 있다. 프래그먼트 3의 전달은 시간 T3에서 완료된다. 시간 T3에서, 클라이언트는 프래그먼트들을 ISO BMFF 미디어 세그먼트로 어셈블할 수 있다.
위에 표시된 것과 같이, 요청의 순서들은 저장 제한들을 갖지 않고 추가적인 복사들이 갖는 문제들이 없는 클라이언트에 대응한다. 그러나, 제한된 수신기에 대해, 예를 들어 복사들을 피하고 저장 요건들을 최소화하기를 원하는 수신기에 대해, 수신기는 그들의 위치가 알려지도록 그것이 프래그먼트를 어떤 순서로 요청할 수 있는지를 결정하기 위해 크기 의존성 메타데이터를 사용할 수 있었다. 이 경우에, 클라이언트는 단지 프래그먼트들 1 및 2를 초기에 요청할 것이다. 이것은 프래그먼트들 1 및 2가 크기 의존성을 갖지 않기 때문에; 즉, 프래그먼트 1은 알려진 크기를 갖고 리소스 파일의 개시에서 시작되기 때문이다. 프래그먼트 2는 프래그먼트 1 바로 후에 시작하지만, 그것의 길이는 초기에 알려지지 않는다. 그러므로, 수신기는 그것이 공통의 연속적인 파일 내로 수신되는 대로 데이터를 기입할 수 있을 것이다. 프래그먼트 2가 전달되었을 때, 프래그먼트들 3 및 4는 알려진 크기들을 가질 것이다. 그러므로, 클라이언트는 다음에 프래그먼트들 3과 4 둘 다를 동시에 요청할 수 있다. 알려진 크기들 및 연속적인 파일 내로의 오프셋으로, 데이터는 수신 시 직접 올바른 위치 내로 기입될 수 있다.
DASH 라이브 미디어 세그먼트를 위해 사용되는 또 하나의 예시적인 실시예
본원에서 설명된 세그먼테이션 해결책의 실시예들은 미디어 전달 서버에서의 콘텐트 수집 시작으로부터 플레이아웃이 클라이언트에서 시작될 때까지의 지연(Tsource_to_playback)을 감소시키기 위해 사용될 수 있다. 초기에, 인코더는 전달을 스트리밍하기에 적합한 포맷(예를 들어, H.264)으로, 모든 화상 집합(GOP)에 대해서와 같은, 개별-프레임 레벨 상에 또는 일부 약간 더 대략적인 레벨 상에, 인코딩된 미디어 콘텐트를 발생한다. 여기서부터, 인코딩된 미디어는 패킷타이저 또는 파일 포맷 구성기를 통해 패킷타이징되고, 또는 통과되어, 인코딩된 미디어를 HTTP와 같은 패킷 기반 프로토콜을 통해 전달하기 위한 포맷으로 놓는다(예를 들어, 인코딩된 미디어는 mp4 또는 ISOBMFF 포맷으로 놓여진다).
예가 이제 ISOBMFF 파일들로 하는 DASH 라이브 미디어 스트리밍을 사용하여 설명될 것이다.
이 예에서의 각각의 미디어 세그먼트에 대해, 세그먼트는 3초의 길이를 갖고 ISOBMFF 포맷으로 제공된다고 가정한다. 파일 구성기는 이 경우에 세그먼트 유형 박스(styp)로 시작하는, 초기 구조를 생성한다. 이것은 미디어 세그먼트의 브랜드 및 미디어 초기화 세그먼트에서 사용된 파일 유형에 기초하여 구성될 수 있다. DASH에 따라 세그먼트되는 ISOBMFF 파일들에 대해, 개별적인 세그먼트는 샘플들의 위치에 관한 정보를 제공하기 위해 영화 프래그먼트(moof) 박스를 사용할 것이다. 여기서의 문제는 moof 박스 내의 정보의 일부가 개별적인 샘플들에 의존한다는 것이다. 이러한 의존성의 한 예는 moof 박스의 일부인, 트랙 프래그먼트 박스(traf)의 일부인, 트랙 프래그먼트 런 박스(trun)이다. trun은 mdat 내부에 저장된 각각의 샘플에 대해, 이 샘플이 위치하는 오프셋을 포함한다. 그러므로, 오프셋은 단지 대응하는 샘플들이 mdat 내로 추가된 후에(즉, 오프셋이 먼저 알려질 때) trun 내의 샘플 엔트리들 내로 기입될 수 있다. 의존성의 또 하나의 예로서, 주어진 박스의 완전한 길이가 모든 박스들 또는 샘플들이 그 박스 내로 기입될 때까지 알려지지 않을 때, 박스들의 길이 필드들이 문제일 수 있다. 박스가 파일의 종료까지 런하면, 길이에 대해 0의 값을 특정하는 것이 가능한데, 이는 파일의 종료까지 박스의 길이가 지속된다는 것을 의미한다. 그러나, mdat 박스가 일반적으로 moof를 따라야 하므로, moof의 길이는 전형적으로 0으로서 특정될 수 없다.
본원에서 개시된 리소스 세그먼테이션의 실시예들은 ISOBMFF의 DASH 규격의 사용에 따라 포맷된 미디어 세그먼트에 적용될 수 있다. 그렇게 하는 것은 지연을 감소시키고 미디어 샘플 데이터가 이용가능할 때 HTTP 청킹된 전달 또는 다른 푸시 전달을 가능하게 할 수 있다.
이제 도 12를 참조하면, DASH 미디어 세그먼트 리소스의 세그먼테이션은 다음과 같이 진행할 수 있다. 제1 리소스 프래그먼트(1210)는 초기에 발생될 수 있는 정보로, 파일의 시작을 포함할 수 있다. 이 프래그먼트(1210)는 모든 샘플들이 발생되기 전에 알려진 모든 초기 박스들(1204)을 포함한다. 다음의 리소스 프래그먼트(1212)는 moof 박스(1206)를 포함할 수 있다. [S4-141201]에서 설명된 것과 같이, 모든 샘플들이 발생되기 전에, 얼마나 많은 룸 공간을 moof 박스(1206)가 (moof 박스 내에 포함된 박스들과 함께) 차지할 것인지를 평가하는 것이 가능하다. 이러한 평가는 일부 확보 공간을 포함할 수 있다. 그러므로, 완전한 길이가 평가될 수 있고, 필요한 샘플들이 추가된 후에 어떤 남아 있는 공간이 있으면, 이 공간은 자유로운 박스를 사용하는 자유로운 것으로 마크될 수 있다(자유로운 박스는 이 경우에 ISOBMFF 규격에 따르기 위해 필요하다). 크기는 여기서 빈약하거나 불완전하게 포맷된 세그먼트를 야기할 것이라고 과소평가하고; 크기가 낭비된 공간을 야기할 것이라고 과대평가한다는 점에 주목한다. 그러므로 과대평가하는 것이 바람직하다. 평가는 예를 들어, 알려지거나 평가된 수의 샘플들에 이르게 하는, 알려지거나 평가된 프레임 레이트 및 기간에 기초할 수 있다. 제3 리소스 프래그먼트(1214)는 mdat 박스(1208)를 포함할 수 있다. 이 박스(1208)의 크기는 모든 샘플들을 발생시키기 전에 알려지지 않지만, 박스는 파일의 종료까지 런할 것이다. 그러므로, 0의 길이 필드 값이 사용하는 것이 가능하다. 제3 리소스 프래그먼트(1214)는 대부분 mdat 박스(1208)의 데이터 부분, 즉, 미디어 샘플들을 위한 데이터를 포함한다. 여기서, 리소스 세그먼트의 초기 오프셋은 알려지지만(프래그먼트 3 오프셋=1562), 박스의 종료에 대응하는 오프셋은 알려지지 않는다. 그러므로, 종료 오프셋은 개방 종료된 것으로 표시된다.
클라이언트는 이제 제1 리소스 프래그먼트를 먼저 검색하는 것으로 시작할 수 있다. 그 다음에, 클라이언트는 (trun 박스들의 콘텐트를 갖는) 제2 프래그먼트 및 (mdat 박스들의 콘텐트를 갖는) 제3 프래그먼트을 검색할 수 있고; 이들 2개의 프래그먼트는 개별적인 리소스 프래그먼트들에 대한 HTTP 청킹으로 2개의 독립하는 HTTP 리소스 요청들을 사용하여 전달되기 시작할 수 있다. HTTP 청킹은 그들이 인코딩을 끝낼 때, 데이터, 예를 들어, 개별적인 미디어 샘플들의 적절한 청크들을 전달하기 위해 사용되고, 대응하는 샘플은 그들이 끝날 때 trun 박스에서 런한다. 미디어 세그먼트에 속하는 모든 샘플들이 mdat 박스 내로 기입되었을 때, 프래그먼트는 청킹된 전달의 종료를 표시하기 위해 HTTP 청킹을 사용함으로써 폐쇄된다. moof 프래그먼트는 또한 trun 박스의 마지막 부분을 기입함으로써 완료되고, 나머지 공간은 있다면 자유로운 박스에 의해 소비되고(그럼으로써 프래그먼트의 바이트 카운트를 미리 결정된 길이로 올려준다). 이것은 미디어 세그먼트의 전달을 완료한다.
세그먼트 맵은 리소스 프래그먼트의 시작이 어느 것인지를 수신 클라이언트에 표시하기 위해 필요한 경우 힌트들을 또한 포함할 수 있다. 예를 들어, 세그먼테이션 맵은 하나의 프래그먼트가 mdat 박스의 시작(여기서, 프래그먼트 3)이라는 것을 표시하여, 클라이언트가 그들이 http 청킹에 의해 전달될 때 미디어 샘플들을 소비할 수 있게 할 것이다.
상기 예들은 moof 박스의 콘텐트가 기입될 리소스 세그먼트에 대한 평가되고 미리 할당된 공간, 및 특히 trun 박스들을 사용한다. 대안적 실시예는 이 박스가 얼마나 많은 공간을 필요로 하는지를 평가하지 않고, 대신에 리소스 세그먼트가 시작에서 알려지지 않은 길이라는 것을 표시하고 다음에 완전한 리소스 세그먼트가 언제 전달되었는지, 즉, ISOBMFF 세그먼트 파일 내에 포함되는 것으로 의도된 모든 샘플들이 언제 포함되었는지를 표시하기 위해 HTTP 청킹을 사용하고, 모든 데이터의 최종 위치가 알려진다. 그것이 발생할 때, 최종 trun이 기입되고 moof 박스의 끝이 결정될 때, HTTP 청킹은 이것이 끝인지를 표시하기 위해 비어있는 청크를 전달한다. 그러나, 이 경우에 moof 박스의 길이를 올바르게 표시하기 위해, (길이 필드를 포함하는) moof 박스의 시작은 분리된 프래그먼트 내로 놓여질 필요가 있으므로, 이 분리된 프래그먼트는 moof 박스의 길이가 결정된 후에 전달될 수 있다.
이 방식(즉, moof 박스가 얼마나 많은 공간을 필요로 하는지를 평가하지 않는 방식)은 필요한 공간을 잘못 평가하는 위험을 피하고, 또한 어떤 미사용 공간을 낭비하는 것을 피한다는 장점을 갖는다. 그러나, 최종 리소스가 미래의 사용을 위해 저장된다면, 추가적인 복사 동작들이 최종 어셈블된 리소스에 대한 하나의 연속하는 바이트 스트림으로서 리소스 프래그먼트들을 어셈블하기 위해 정상적으로 요구될 것이다. 하지만, 일부 사용 경우들에서 이것은 주요한 사용이 아니고, 대신에 ISOBMFF의 라이브 프로필이 주 사용이라는 것을 따르는 것으로서 여전히 포맷되면서, 데이터에의 가장 빠른 가능한 액세스이다.
비교 예
비교 예가 이제 제공된다. (서버(104)와 같은) 서버는 서브하는 2개의 클라이언트, (클라이언트(102)와 같은) 현재 개시된 실시예들에 따라 세그먼테이션 맵을 수신하고 처리할 수 있는 제1 클라이언트(소위 "스마트 클라이언트"), 현재 개시된 실시예들에 따라 세그먼테이션 맵을 수신하고 처리할 수 없는 제2의 통상적인 클라이언트(소위 "덤 클라이언트" 또는 "통상적인 클라이언트")이다.
서버는 라이브 스트리밍 미디어 이벤트(예를 들어, 저녁 TV 뉴스 프로그램)에의 액세스를 제공한다. 서버는 이벤트가 계속 진행 중일 때, 소스 피드를 계속 수신한다. 서버는 총 기간, 소스 피드의 품질, 예상된 시청률 등과 같은, 소스 피드에 관해 거의 알지 못하고; 대안적으로, 이러한 정보는 완전히 미리 결정될 수 있거나, 서버는 이러한 것들(예를 들어, 프로그램의 전형적인 시작 및 중지 시간, 및 입력 피드의 전형적인 품질)의 평가를 형성할 어떤 것에 관한 일부 정보를 가질 수 있다. 임의의 이벤트에서, 서버는 라이브 스트리밍 미디어 이벤트를 위한 매니페스트 파일을 준비한다. 이 파일은 이벤트를 다수의 세그먼트들, 또는 미디어 리소스들로, 전형적으로 2초 내지 10초 기간 내에 개별적으로 나눈다. 매니페스트 파일은 클라이언트가 특정한 세그먼트들, 또는 미디어 리소스들에 언제 액세스하여야 하는지에 관한 힌트들을 포함할 수 있다. 예를 들어, 서버는 그것이 시간 t0에서 제1 리소스를 수신하기 시작하고 리소스를 처리하는 데 (예를 들어, 그것이 클라이언트에 전달 준비되도록 리소스를 인코딩 및 패킷타이징하는 데) A초가 걸릴 것이라는 것을 알거나 평가할 수 있다.
통상적인 클라이언트는 매니페스트 파일을 따를 것인데, 왜냐하면 서버가 그것을 처리하고, 전달을 위해 그것을 준비할 때까지 개별적인 미디어 리소스를 수신하기 시작할 수 없기 때문이다. 그러므로, 통상적인 클라이언트는 시간 t1(t1 = t0 + A)에 또는 그 후에 제1 미디어 리소스를 요청할 것이다. 그러므로, 통상적인 클라이언트에 대한 지연 Tsource_to_reception은 A이다. A의 전형적인 값들은 2초 내지 10초일 수 있다.
또한, 통상적인 클라이언트는 B초가 걸릴, 플레이백을 시작하기 전에 전체 리소스를 수신하고 처리하여야 할 것이다. 그러므로, 통상적인 클라이언트는 시간 t2(t2 = t1 + B = t0 + A + B)까지 플레이백을 시작할 수 없고, 그래서 통상적인 클라이언트에 대한 지연 Tsource_to_reception은 B이다. 이것은 지연 Tsource_to_playback = A+B를 야기한다.
반대로, 스마트 클라이언트, 즉 세그먼테이션 맵을 수신하고 처리할 수 있는 클라이언트는 서버가 그것을 완전히 처리하기 전에 제1 미디어 리소스를 요청할 수 있을 것이다. 서버가 세그먼테이션 맵을 발생시키고, 클라이언트에 미디어 리소스의 부분들을 제공하기 시작하는 데 단지 C초 걸릴 수 있다. 그러므로, 스마트 클라이언트는 시간 t1'(t1' = t0 + C)에 또는 그 후에 제1 미디어 리소스를 요청할 것이다. 그러므로, 스마트 클라이언트에 대한 지연 Tsource_to_reception은 C이다. C의 전형적인 값들은 약 200㎳일 수 있다. 이 시간은 세그먼테이션 맵을 형성하는 시간, 및 세그먼테이션 맵을 전달하고 다음에 클라이언트가 프래그먼트를 요청하고 다음에 프래그먼트를 전달하기 시작할 수 있는 여분의 라운드 트립으로 구성된다.
또한, 스마트 클라이언트는 전체 세그먼트를 수신하기 전에 플레이백을 시작할 수 있다. 예를 들어, 위에 설명된 것과 같이, 애플리케이션-레벨 힌트는 클라이언트가 예를 들어, 수신의 D초 내에 그렇게 하는 것이 가능하게 할 수 있다. 그러므로, 스마트 클라이언트는 t2'(t2' = t1' + C = t0 + C + D)에서 플레이백을 시작할 수 있고, 그래서 스마트 클라이언트에 대한 지연 Tsource_to_reception은 D이다. 이것은 지연 Tsource_to_playback = C+D를 야기한다. 본 예에서, MOOF는 비교적 작기(수 kb) 때문에, 차이 B-D는 이 예에서, 수 밀리초 정도이다.
이 예에 따르면, 지연 Tsource_to_reception은 약 2-10초로부터 약 200밀리초로, 또는 약 90%-98% 감소될 수 있다. 지연 Treception_to_playback은 수 밀리초만큼 감소될 수 있다. 종합적으로, 이것은 소스 수집으로부터 플레이백까지의 지연의 상당한 감소를 가져다 준다.
이 예로부터 분명한 것과 같이, 리소스 세그먼트가 클라이언트에 의해 소비하기 위해 이용가능한 시간은 클라이언트가 세그먼트된 모드를 지원하는지에 따라 상당히 상이할 것이다. 일부 실시예들에서, 세그먼트된 모드를 지원하는 스마트 클라이언트는 매니페스트 파일 내에 제공된 이용가능성 힌트들을 무시 또는 적절히 수정하기를 결정할 수 있다. 일부 실시예들에서, 서버는 통상적인 클라이언트에 하나의 매니페스트 파일을, 그리고 스마트 클라이언트에 (수정된 이용가능성 힌트들을 갖는) 상이한 매니페스트 파일을 제공할 수 있다.
도 13은 클라이언트(102) 또는 서버(104)를 구현하기 위해 사용될 수 있는, 일부 실시예들에 따른, 장치(1300)의 블록도이다. 도 13에 도시한 것과 같이, 장치는 하나 이상의 프로세서(1355)(예를 들어, 범용 마이크로프로세서 및/또는 주문형 집적 회로(ASIC), 필드-프로그램가능한 게이트 어레이들(FPGA들) 등과 같은 하나 이상의 다른 프로세서)를 포함할 수 있는 데이터 처리 시스템(DPS)(1302); 다른 장치들과 통신하는 데 사용하기 위해, 안테나 또는 통신 포트에 결합될 수 있는, 송신기(1305) 및 수신기(1306); 및 하나 이상의 비휘발성 저장 디바이스(예를 들어, 플래시 메모리, 하드 디스크, 또는 광학 디스크 등) 및/또는 하나 이상의 휘발성 저장 디바이스(예를 들어, 휘발성 랜덤 액세스 메모리(RAM))를 포함할 수 있는 로컬 저장 유닛("데이터 저장 시스템"이라고도 알려짐)(1312)을 포함할 수 있다. DPS(1302)가 프로그램가능한 마이크로프로세서를 포함하는 실시예들에서, 컴퓨터 프로그램 제품(CPP)(1341)이 제공될 수 있다. CPP(1341)는 컴퓨터 판독가능 명령어들(CRI)(1344)을 포함하는 컴퓨터 프로그램(CP)(1343)을 저장하는 컴퓨터 판독가능 매체(CRM)(1342)를 포함한다. CRM(1342)은 자기 매체(예를 들어, 하드 디스크), 광학 매체(예를 들어, DVD), 메모리 디바이스들(예를 들어, 플래시 메모리, 휘발성 RAM) 등과 같지만, 이들로 제한되지 않는 비일시적 컴퓨터 판독가능 매체일 수 있다. 일부 실시예들에서, 컴퓨터 프로그램(1343)의 CRI(1344)는 데이터 처리 시스템(1302)에 의해 실행될 때, CRI가 장치로 하여금 여기에 설명된 단계들(예를 들어, 플로우 차트들을 참조하여 위에 설명된 단계들)을 수행하게 하도록 구성된다. 다른 실시예들에서, 장치는 코드가 필요없이 여기에 설명된 단계들을 수행하도록 구성될 수 있다. 즉, 예를 들어, 데이터 처리 시스템(1302)은 단지 하나 이상의 ASIC로 구성될 수 있다. 그러므로, 여기에 설명된 실시예들의 특징들은 하드웨어 및/또는 소프트웨어에서 구현될 수 있다.
본 개시내용의 다양한 실시예들이 (부록을 포함하여) 여기에 설명되었지만, 그들은 단지 예로서, 제한 없이 제시되었다는 것을 이해하여야 한다. 그러므로, 본 개시내용의 폭 및 범위는 위에 설명된 예시적인 실시예들 중 어느 것에 의해서도 제한되지 않아야 한다. 또한, 그 모든 가능한 변화들 내의 위에 설명된 요소들의 임의의 조합은 여기에 달리 표시되지 않거나 맥락에 의해 분명히 달리 모순되지 않는다면 본 개시내용에 의해 포괄된다.
부가적으로, 위에 설명되고 도면에 도시된 과정들이 단계들의 순차로서 도시되지만, 이것은 단지 예시의 목적을 위해 행해졌다. 따라서, 일부 단계들이 추가될 수 있고, 일부 단계들이 생략될 수 있고, 단계들의 순서가 재정렬될 수 있고, 일부 단계들이 동시에 수행될 수 있다는 것이 숙고된다.

Claims (28)

  1. 동적으로 발생된 미디어 스트림을 클라이언트(102)에 전달하는 방법으로서, 상기 미디어 스트림은 제1 미디어 세그먼트 및 제2 미디어 세그먼트를 포함하는 복수의 미디어 세그먼트들을 포함하고, 상기 방법은
    상기 클라이언트(102)에 매니페스트 파일을 송신하라는 표시를 수신하는 단계 - 상기 매니페스트 파일은 상기 미디어 세그먼트들을 디스크라이브하는 정보를 포함함 - ;
    상기 매니페스트 파일을 상기 클라이언트(102)에 송신하라는 상기 표시를 수신한 것에 응답하여, 상기 클라이언트(102)에, 상기 매니페스트 파일을 송신하는 단계;
    상기 클라이언트(102)에 상기 매니페스트 파일을 송신한 후에, 상기 클라이언트(102)에 상기 제1 미디어 세그먼트를 송신하라는 표시를 수신하는 단계; 및
    상기 클라이언트(102)에 상기 제1 미디어 세그먼트를 송신하라는 상기 표시에 응답하여, 상기 클라이언트(102)에, 상기 제1 미디어 세그먼트에 대한 세그먼테이션 맵을 송신하는 단계를 포함하고,
    상기 제1 미디어 세그먼트는 제1 프래그먼트(1210) 및 제2 프래그먼트(1212)를 포함하는 프래그먼트들의 정렬된 세트(1210, 1212, 1214)를 포함하고,
    상기 세그먼테이션 맵은 서버(104)로부터 상기 제1 프래그먼트(1210)에 액세스하는 데 사용하기 위한 제1 프래그먼트 식별자를 포함하는 제1 프래그먼트 메타데이터, 서버(104)로부터 상기 제2 프래그먼트(1212)에 액세스하는 데 사용하기 위한 제2 프래그먼트 식별자를 포함하는 제2 프래그먼트 메타데이터, 및 상기 제1 프래그먼트(1210)가 상기 제2 프래그먼트(1212) 전에 정렬된다는 것을 표시하는 정보를 포함하는, 프래그먼트들의 상기 세트(1210, 1212, 1214) 내의 상기 프래그먼트들의 상기 정렬을 식별하는 정렬 정보를 포함하는 방법.
  2. 제1항에 있어서,
    상기 클라이언트(102)에 상기 제1 프래그먼트(1210)를 송신하라는 표시를 수신하는 단계; 및
    상기 클라이언트(102)에 상기 제1 프래그먼트(1210)를 송신하라는 상기 표시를 수신한 것에 응답하여, 상기 클라이언트(102)에, 상기 제1 프래그먼트(1210)를 송신하는 단계를 추가로 포함하는 방법.
  3. 제2항에 있어서, 상기 클라이언트(102)에 상기 매니페스트 파일을 송신하라는 상기 표시, 상기 클라이언트(102)에 상기 제1 미디어 세그먼트를 송신하라는 상기 표시, 및 상기 클라이언트(102)에 상기 제1 프래그먼트(1210)를 송신하라는 상기 표시 중 하나 이상은 클라이언트(102) 입력 없이 상기 서버(104)에 의해 발생되는 방법.
  4. 제3항에 있어서, 상기 표시들 중 하나 이상을 발생시키기 전에, 상기 미디어 스트림을 수신할 상기 클라이언트(102)를 등록하라는 요청을 수신하는 단계를 추가로 포함하는 방법.
  5. 제1항 내지 제4항 중 어느 한 항에 있어서,
    상기 클라이언트(102)에 상기 제1 미디어 세그먼트를 송신하라는 상기 표시는 상기 클라이언트(102)에 의해 송신된 요청이고,
    상기 요청은 상기 제1 미디어 세그먼트를 식별하는 정보를 포함하고,
    상기 요청은 상기 클라이언트(102)가 세그먼트된 모드를 지원한다는 것을 표시하는 표시자를 추가로 포함하는 방법.
  6. 제5항에 있어서, 상기 미디어 세그먼트를 전달하기 위해 상기 세그먼트된 모드를 사용하기를 결정하는 단계를 추가로 포함하고, 상기 결정은 상기 표시자에 적어도 부분적으로 기초하는 방법.
  7. 제6항에 있어서, 상기 제1 미디어 세그먼트를 전달하기 위해 상기 세그먼트된 모드를 사용하기를 결정하는 단계는 상기 제1 미디어 세그먼트가 완전히 발생되었는지에 적어도 부분적으로 추가로 기초하는 방법.
  8. 제5항 내지 제7항 중 어느 한 항에 있어서,
    상기 매니페스트 파일의 콘텐트는 상기 클라이언트(102)가 상기 세그먼트된 모드를 지원한다는 상기 표시자에 기초하고,
    상기 표시자에 기초한 상기 매니페스트 파일의 상기 콘텐트는 상기 복수의 미디어 세그먼트들에 대한 리소스 이용가능성의 시간에 관한 힌트를 포함하는 방법.
  9. 제1항 내지 제8항 중 어느 한 항에 있어서, 상기 제1 프래그먼트 메타데이터는
    상기 제1 프래그먼트(1210)에 대한 제1 의존성 정보 - 상기 제1 의존성 정보는 상기 서버(104)로부터 전달될 상기 제1 프래그먼트(1210)의 상기 이용가능성이 상기 세트(1210, 1212, 1214) 중 하나 이상의 다른 프래그먼트에 의존한다는 것을 표시함 - ,
    상기 제1 프래그먼트(1210)의 길이, 상기 미디어 세그먼트 내의 상기 제1 프래그먼트(1210)의 시작 위치, 및 상기 미디어 세그먼트 내의 상기 제1 프래그먼트(1210)의 종료 위치 중 하나 이상을 포함하는 제1 위치 정보, 및
    상기 제1 프래그먼트(1210)의 무결성을 검증하는 데 사용하기 위한 제1 프래그먼트-레벨 보안 정보 중 하나 이상을 추가로 포함하는 방법.
  10. 제1항 내지 제9항 중 어느 한 항에 있어서,
    상기 미디어 스트림을 동적으로 발생시키는 소스로부터 상기 제1 미디어 세그먼트의 부분을 수신하는 단계 - 상기 제1 미디어 세그먼트의 상기 부분은 미디어 샘플 및 미디어 애플리케이션 데이터 단위 중 적어도 하나에 대응함 - ; 및
    포맷에 따라 상기 제1 미디어 세그먼트의 상기 부분을 패킷타이징하는 단계 - 상기 포맷은 ISO 베이스 미디어 파일 포맷임 - 를 추가로 포함하는 방법.
  11. 제1항 내지 제10항 중 어느 한 항에 있어서,
    상기 제1 프래그먼트(1210)는 미디어 샘플들을 포함하고,
    상기 제2 프래그먼트(1212)는 상기 미디어 샘플들과 연관된 메타데이터를 포함하는 방법.
  12. 서버(104)로서, 제1항 내지 제11항 중 어느 한 항의 방법을 수행하도록 구성되는 서버(104).
  13. 서버(104)로서, 상기 서버(104)는
    메모리를 포함하는 데이터 저장 시스템(1312); 및
    프로세서(1355)를 포함하는 데이터 처리 시스템(1302)을 포함하고, 상기 서버(104)는 제1항 내지 제11항 중 어느 한 항의 방법을 수행하도록 구성되는 서버(104).
  14. 동적으로 발생된 미디어 스트림을 수신하는, 클라이언트(102)에 의해 수행되는 방법으로서, 상기 미디어 스트림은 제1 미디어 세그먼트 및 제2 미디어 세그먼트를 포함하는 복수의 미디어 세그먼트들을 포함하고, 상기 방법은
    매니페스트 파일을 수신하는 단계 - 상기 매니페스트 파일은 상기 클라이언트(102)가 상기 미디어 세그먼트들에 대한 요청들을 발생시킬 수 있게 하는 정보를 포함함 - ;
    상기 수신된 매니페스트 파일을 처리하는 단계;
    상기 매니페스트 파일을 처리한 후에, 상기 제1 미디어 세그먼트에 대한 세그먼테이션 맵을 수신하는 단계 - 상기 제1 미디어 세그먼트는 제1 프래그먼트(1210) 및 제2 프래그먼트(1212)를 포함하는 프래그먼트들의 정렬된 세트(1210, 1212, 1214)를 포함하고, 상기 세그먼테이션 맵은 제1 서버(104)로부터 상기 제1 프래그먼트(1210)에 액세스하는 데 사용하기 위한 제1 프래그먼트 식별자를 포함하는 제1 프래그먼트 메타데이터, 서버(104)로부터 상기 제2 프래그먼트(1212)에 액세스하는 데 사용하기 위한 제2 프래그먼트 식별자를 포함하는 제2 프래그먼트 메타데이터, 및 상기 제1 프래그먼트(1210)가 상기 제2 프래그먼트(1212) 전에 정렬된다는 것을 표시하는 정보를 포함하는, 프래그먼트들의 상기 세트(1210, 1212, 1214) 내의 상기 프래그먼트들의 상기 정렬을 식별하는 정렬 정보를 포함함 - ; 및
    상기 제1 프래그먼트(1210)를 수신하는 단계
    를 포함하는 방법.
  15. 제14항에 있어서,
    상기 매니페스트 파일을 수신하기 전에, 매니페스트 파일에 대한 요청을 송신하는 단계;
    상기 매니페스트 파일을 처리한 후에 그리고 상기 세그먼테이션 맵을 수신하기 전에, 상기 제1 미디어 세그먼트를 식별하는 요청을 송신하는 단계를 추가로 포함하는 방법.
  16. 제15항에 있어서, 상기 제1 미디어 세그먼트를 식별하는 상기 요청은 상기 클라이언트(102)가 세그먼트된 모드를 지원한다는 것을 표시하는 표시자를 포함하는 방법.
  17. 제14항에 있어서, 상기 매니페스트 파일 및 제1 프래그먼트(1210) 중 하나 이상은 상기 클라이언트(102)가 요청을 송신하지 않고 상기 클라이언트(102)에 의해 수신되는 방법.
  18. 제17항에 있어서, 상기 클라이언트(102)의 애플리케이션 계층은 상기 클라이언트(102)의 로컬 브라우저에 상기 매니페스트 파일 및 상기 제1 프래그먼트(1210) 중 하나 이상에 대한 요청을 송신하여, 상기 애플리케이션 계층이 상기 매니페스트 파일 및 상기 제1 프래그먼트(1210) 중 하나 이상에의 액세스를 획득하게 하는 방법.
  19. 제17항 또는 제18항에 있어서, 상기 제1 미디어 세그먼트에 대한 복수의 프래그먼트들은 상기 클라이언트(102)가 요청을 송신하지 않고 상기 클라이언트(102)에 의해 수신되는 방법.
  20. 제19항에 있어서, 상기 클라이언트(102)의 애플리케이션 계층은 상기 프래그먼트들의 아이덴티티, 상기 파일 내의 그들의 제공된 오프셋, 또는 프래그먼트들의 시퀀스를 포함하는 상기 세그먼테이션 맵 내의 정보에 기초하여 상기 제1 미디어 세그먼트를 어셈블하는 방법.
  21. 제14항 내지 제20항 중 어느 한 항에 있어서,
    상기 제1 프래그먼트(1210)를 검증하는 단계;
    상기 제1 미디어 세그먼트를 검증하는 단계; 및
    상기 제1 프래그먼트(1210)를 디코딩하고 플레이하는 단계를 추가로 포함하고, 상기 제1 프래그먼트(1210)를 디코딩하고 플레이하는 단계는 상기 제1 프래그먼트(1210)를 검증한 후에 그리고 상기 제1 미디어 세그먼트를 검증하기 전에 발생하는 방법.
  22. 제14항 내지 제21항 중 어느 한 항에 있어서, 상기 제1 프래그먼트(1210)를 플레이하는 단계를 추가로 포함하고, 상기 제1 프래그먼트(1210)를 플레이하는 단계는 상기 미디어 세그먼트의 다른 프래그먼트들을 수신하기 전에 발생하는 방법.
  23. 클라이언트(102)로서, 제14항 내지 제22항 중 어느 한 항의 방법을 수행하도록 구성되는 클라이언트(102).
  24. 클라이언트(102)로서, 상기 클라이언트(102)는
    메모리를 포함하는 데이터 저장 시스템(1312); 및
    프로세서(1355)를 포함하는 데이터 처리 시스템(1302)을 포함하고, 상기 클라이언트(102)는 제14항 내지 제22항 중 어느 한 항의 방법을 수행하도록 구성되는 클라이언트(102).
  25. 컴퓨터 프로그램(1343)으로서,
    데이터 처리 시스템(1302)에 의해 실행될 때, 상기 데이터 처리 시스템(1302)으로 하여금 제1항 내지 13항 및 제14항 내지 제22항 중 어느 한 항의 방법을 수행하게 하는 명령어들(1344)을 포함하는 컴퓨터 프로그램(1343).
  26. 컴퓨터 프로그램 제품(1341)으로서,
    제25항의 컴퓨터 프로그램(1343)을 포함하는 비일시적 컴퓨터 판독가능 매체(1342)를 포함하는 컴퓨터 프로그램 제품(1341).
  27. 클라이언트(102)에 미디어 스트림을 송신하는 방법으로서 - 상기 미디어 스트림은 제1 미디어 세그먼트 및 제2 미디어 세그먼트를 포함하는 복수의 미디어 세그먼트들을 포함하고, 상기 제1 미디어 세그먼트는 복수의 미디어 샘플들(예를 들어, 오디오 및/또는 비디오 샘플들과 같은 mdat 데이터) 및 미디어 샘플 메타데이터(예를 들어, moof 데이터)를 포함함 - , 상기 방법은
    상기 클라이언트(102)에 상기 제1 미디어 세그먼트에 속하는 상기 복수의 미디어 샘플들 중 하나 이상을 송신하는 단계; 및
    상기 클라이언트(102)에 상기 제1 미디어 세그먼트에 속하는 상기 미디어 샘플 메타데이터의 적어도 일부를 송신하는 단계를 포함하고,
    상기 제1 미디어 세그먼트에 속하는 상기 복수의 미디어 샘플들 중 상기 하나 이상은 상기 데이터에 상기 제1 미디어 세그먼트에 속하는 상기 미디어 샘플 메타데이터의 상기 적어도 일부가 송신되기 전에 상기 클라이언트(102)에 송신되는 방법.
  28. 제27항에 있어서, 상기 제1 미디어 프래그먼트는 미디어 세그먼트 유형 정보(예를 들어, STYP 박스(1204))를 추가로 포함하고, 상기 방법은
    상기 제1 미디어 세그먼트에 속하는 상기 복수의 미디어 샘플들 중 상기 하나 이상을 송신하기 전에 상기 제1 미디어 세그먼트에 속하는 상기 미디어 세그먼트 유형 정보를 송신하는 단계를 추가로 포함하는 방법.
KR1020197016532A 2016-11-10 2017-11-10 전달 성능을 개선시키는 리소스 세그먼테이션 KR102220188B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201662420120P 2016-11-10 2016-11-10
US62/420,120 2016-11-10
PCT/EP2017/078926 WO2018087309A1 (en) 2016-11-10 2017-11-10 Resource segmentation to improve delivery performance

Publications (2)

Publication Number Publication Date
KR20190075137A true KR20190075137A (ko) 2019-06-28
KR102220188B1 KR102220188B1 (ko) 2021-02-25

Family

ID=60320886

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020197016532A KR102220188B1 (ko) 2016-11-10 2017-11-10 전달 성능을 개선시키는 리소스 세그먼테이션

Country Status (8)

Country Link
US (3) US11722752B2 (ko)
EP (2) EP3539270B1 (ko)
JP (2) JP7178998B2 (ko)
KR (1) KR102220188B1 (ko)
CN (1) CN110140335B (ko)
AU (2) AU2017358996A1 (ko)
MX (1) MX2019005456A (ko)
WO (2) WO2018087311A1 (ko)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10924781B2 (en) * 2014-06-27 2021-02-16 Satellite Investors, Llc Method and system for real-time transcoding of MPEG-DASH on-demand media segments while in transit from content host to dash client
CN108848060B (zh) * 2018-05-17 2021-08-24 上海哔哩哔哩科技有限公司 一种多媒体文件处理方法、处理系统及计算机可读存储介质
US20200330034A1 (en) * 2019-04-18 2020-10-22 Vanderbilt University Method and apparatus for intraoperative nerve visualization using polarized diffuse reflectance spectroscopy and applications of same
US11323778B2 (en) * 2020-09-23 2022-05-03 Sony Group Corporation Unified programming guide for content associated with broadcaster and VOD applications
US20220334787A1 (en) * 2021-04-14 2022-10-20 Cilag Gmbh International Customization of overlaid data and configuration
CN113687846B (zh) * 2021-06-30 2023-07-18 北京百度网讯科技有限公司 用于处理数据的方法、装置、设备和可读存储介质
US20230318982A1 (en) * 2022-03-29 2023-10-05 Qualcomm Incorporated Application data unit architecture and signaling
CN117955959A (zh) * 2022-10-20 2024-04-30 腾讯科技（深圳）有限公司 多媒体内容的协同传输方法、装置、设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130246643A1 (en) * 2011-08-31 2013-09-19 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive http streaming
US20140032777A1 (en) * 2011-04-07 2014-01-30 Huawei Technologies Co., Ltd. Method, apparatus, and system for transmitting and processing media content

Family Cites Families (57)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6602185B1 (en) * 1999-02-18 2003-08-05 Olympus Optical Co., Ltd. Remote surgery support system
US20020150966A1 (en) * 2001-02-09 2002-10-17 Muraca Patrick J. Specimen-linked database
US8095200B2 (en) * 2002-03-06 2012-01-10 Mako Surgical Corp. System and method for using a haptic device as an input device
US10751509B2 (en) * 2007-11-26 2020-08-25 C. R. Bard, Inc. Iconic representations for guidance of an indwelling medical device
JP5231625B2 (ja) * 2008-03-18 2013-07-10 ノヴァダク テクノロジーズ インコーポレイテッド Ｎｉｒ画像およびフルカラー画像を獲得するための画像化システムおよびその作動方法
US20090254933A1 (en) * 2008-03-27 2009-10-08 Vishwa Nath Gupta Media detection using acoustic recognition
US20110224574A1 (en) * 2008-11-13 2011-09-15 Sadler John W Methods and systems for tissue processing and imaging
US8594841B2 (en) * 2008-12-31 2013-11-26 Intuitive Surgical Operations, Inc. Visual force feedback in a minimally invasive surgical procedure
US8909806B2 (en) * 2009-03-16 2014-12-09 Microsoft Corporation Delivering cacheable streaming media presentations
CN105388205B (zh) * 2009-05-27 2019-07-23 英国质谱有限公司 用于鉴定生物组织的系统和方法
US8166191B1 (en) * 2009-08-17 2012-04-24 Adobe Systems Incorporated Hint based media content streaming
DE102010013308A1 (de) * 2010-03-29 2011-09-29 Karl Storz Gmbh & Co. Kg Vorrichtung zur Bereitstellung von weißem Beleuchtungslicht
CN103747365B (zh) * 2010-09-17 2017-04-26 华为技术有限公司 基于http流的媒体内容动态插播方法、装置及系统
CN102137089B (zh) 2010-11-01 2013-09-11 华为技术有限公司 验证流媒体内容完整性的方法、设备以及系统
US9301020B2 (en) 2010-11-30 2016-03-29 Google Technology Holdings LLC Method of targeted ad insertion using HTTP live streaming protocol
US9088835B2 (en) * 2010-12-17 2015-07-21 Thomson Licensing Method for adjusting depth or view of three-dimensional streaming video
US9827002B2 (en) * 2011-02-15 2017-11-28 Dextera Surgical Tissue removal and closure device
US11025962B2 (en) 2011-02-28 2021-06-01 Adobe Inc. System and method for low-latency content streaming
US8830233B2 (en) * 2011-04-28 2014-09-09 Howmedica Osteonics Corp. Surgical case planning platform
CN103583050B (zh) * 2011-06-08 2018-09-14 皇家Kpn公司 空间分段的内容的递送
US9445136B2 (en) 2011-09-21 2016-09-13 Qualcomm Incorporated Signaling characteristics of segments for network streaming of media data
JP6023213B2 (ja) * 2011-12-29 2016-11-09 コニンクリーケ・ケイピーエヌ・ナムローゼ・フェンノートシャップ セグメント化されたコンテンツについての制御されたストリーミング
US9344606B2 (en) 2012-01-24 2016-05-17 Radical Switchcam Llc System and method for compiling and playing a multi-channel video
US9846696B2 (en) 2012-02-29 2017-12-19 Telefonaktiebolaget Lm Ericsson (Publ) Apparatus and methods for indexing multimedia content
US9375282B2 (en) * 2012-03-26 2016-06-28 Covidien Lp Light energy sealing, cutting and sensing surgical device
US9724118B2 (en) * 2012-04-09 2017-08-08 Ethicon Endo-Surgery, Llc Techniques for cutting and coagulating tissue for ultrasonic surgical instruments
WO2013163477A1 (en) 2012-04-25 2013-10-31 Huawei Technologies Co., Ltd. Systems and methods for segment integrity and authenticity for adaptive streaming
CA2869311C (en) 2012-04-26 2018-02-13 Michael G. Luby Enhanced block-request streaming system for handling low-latency streaming
JP5612028B2 (ja) * 2012-07-02 2014-10-22 富士フイルム株式会社 光源装置及び内視鏡システム
US20140081659A1 (en) * 2012-09-17 2014-03-20 Depuy Orthopaedics, Inc. Systems and methods for surgical and interventional planning, support, post-operative follow-up, and functional recovery tracking
EP2908535A4 (en) * 2012-10-09 2016-07-06 Sharp Kk Content transfer device, content playback device, content distribution system, method for controlling a content transfer device, method for controlling a content playback device, control program and recording medium
US9572529B2 (en) * 2012-10-31 2017-02-21 Covidien Lp Surgical devices and methods utilizing optical coherence tomography (OCT) to monitor and control tissue sealing
US9497231B2 (en) 2013-06-04 2016-11-15 Echostar Technologies L.L.C. Real-time placeshifting of media content to paired devices
US9743991B2 (en) * 2013-10-21 2017-08-29 Biosense Webster (Israel) Ltd. Real-time estimation of tissue perforation risk during minimally invasive medical procedure
EP3055805B1 (en) * 2013-10-28 2018-12-12 Huawei Technologies Co., Ltd. System and method for signaling and verifying url signatures for both url authentication and url-based content access authorization in adaptive streaming
CN105659623B (zh) * 2013-10-30 2019-04-26 索尼公司 发送装置、发送方法、接收装置以及接收方法
US20150256600A1 (en) * 2014-03-05 2015-09-10 Citrix Systems, Inc. Systems and methods for media format substitution
EP3119325B2 (en) * 2014-03-17 2022-04-13 Intuitive Surgical Operations, Inc. Systems and methods for control of imaging instrument orientation
US9723300B2 (en) * 2014-03-17 2017-08-01 Spatial Intelligence Llc Stereoscopic display
JP2015192407A (ja) 2014-03-28 2015-11-02 ソニー株式会社 送信装置、送信方法、受信装置、受信方法、及び、プログラム
US9547940B1 (en) * 2014-09-12 2017-01-17 University Of South Florida Systems and methods for providing augmented reality in minimally invasive surgery
US10226180B2 (en) * 2014-12-23 2019-03-12 Imam Abdulrahman Bin Faisal University System, method, and apparatus for performing histopathology
US11275757B2 (en) * 2015-02-13 2022-03-15 Cerner Innovation, Inc. Systems and methods for capturing data, creating billable information and outputting billable information
MX2017011316A (es) * 2015-03-01 2019-01-21 Aris Md Inc Procedimiento morfológico de realidad aumentada.
US10454985B2 (en) * 2015-03-04 2019-10-22 Qualcomm Incorporated File format based streaming with dash formats based on LCT
CN106034242A (zh) * 2015-03-09 2016-10-19 杭州施强网络科技有限公司 一种p2p系统中音视频直播流媒体数据传输方法
EP3628264B1 (en) * 2015-03-17 2024-10-16 Intuitive Surgical Operations, Inc. Systems and methods for rendering onscreen identification of instruments in a teleoperational medical system
CN107530130B (zh) * 2015-03-17 2020-11-24 直观外科手术操作公司 用于在远程操作医疗系统中的器械的屏幕识别的系统和方法
US9641578B2 (en) 2015-04-02 2017-05-02 Arris Enterprises, Inc. Minimizing unicast bandwidth in an adaptive bit rate system
US9961350B2 (en) 2015-04-09 2018-05-01 Arris Enterprises Llc Method and apparatus for automatic discovery of elements in a system of encoders
US20160337424A1 (en) * 2015-05-13 2016-11-17 Qualcomm Incorporated Transferring media data using a websocket subprotocol
US11057446B2 (en) * 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
CN108472084B (zh) * 2015-11-12 2021-08-27 直观外科手术操作公司 具有训练或辅助功能的外科手术系统
US10057654B2 (en) * 2016-01-29 2018-08-21 Roku, Inc. Selection and alignment of video segments for adaptive streaming
EP3496646A4 (en) * 2016-08-12 2020-04-01 Intuitive Surgical Operations Inc. IDENTIFICATION OF INSTRUMENTS ON A SCREEN IN A TELEOPERATIONAL MEDICAL SYSTEM.
US10448062B2 (en) * 2016-10-26 2019-10-15 International Business Machines Corporation Pre-fetching media content to reduce peak loads
US20190341149A1 (en) * 2018-05-07 2019-11-07 Medtronic Minimed, Inc. Augmented reality guidance for medical devices

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140032777A1 (en) * 2011-04-07 2014-01-30 Huawei Technologies Co., Ltd. Method, apparatus, and system for transmitting and processing media content
US20130246643A1 (en) * 2011-08-31 2013-09-19 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive http streaming

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
Ingo Kofler et al., "Implications of the ISO base media file format on adaptive HTTP streaming of H.264/SVC." 2012 IEEE Consumer Communications and Networking Conference(CCNC) (2012.01.)* *

Also Published As

Publication number Publication date
KR102220188B1 (ko) 2021-02-25
WO2018087311A1 (en) 2018-05-17
EP3539270B1 (en) 2022-07-20
US11722752B2 (en) 2023-08-08
MX2019005456A (es) 2019-08-12
JP7061121B2 (ja) 2022-04-27
WO2018087309A1 (en) 2018-05-17
EP3539270A1 (en) 2019-09-18
JP2019537897A (ja) 2019-12-26
US20200186896A1 (en) 2020-06-11
EP3539271B1 (en) 2024-09-04
US11558677B2 (en) 2023-01-17
AU2021200397A1 (en) 2021-03-18
US20190281367A1 (en) 2019-09-12
AU2017358996A1 (en) 2019-05-30
AU2021200397B2 (en) 2022-05-12
JP7178998B2 (ja) 2022-11-28
EP3539271A1 (en) 2019-09-18
CN110140335B (zh) 2022-08-12
CN110140335A (zh) 2019-08-16
JP2019536354A (ja) 2019-12-12
US20210307861A1 (en) 2021-10-07

Similar Documents

Publication Publication Date Title
KR102220188B1 (ko) 전달 성능을 개선시키는 리소스 세그먼테이션
US10057277B2 (en) System and method for partial URL signing with applications to dynamic adaptive streaming
US10425427B2 (en) Template uniform resource locator signing
US11902261B2 (en) Efficient common storage of partially encrypted content
US10033787B2 (en) Dynamic virtual chunking of streaming media content
KR101593771B1 (ko) 실시간 또는 준 실시간 스트리밍을 위한 재생 리스트
KR101535366B1 (ko) 실시간 또는 준 실시간 스트리밍을 위한 재생 리스트
US9129092B1 (en) Detecting supported digital rights management configurations on a client device
US8949592B2 (en) System and methods for providing live streaming content using digital rights management-based key management
US20160105403A1 (en) Authenticated Encryption Support in ISO/IEC 23009-4
US20140068693A1 (en) Method, system, or user device for adaptive bandwidth control of proxy multimedia server
US20140075582A1 (en) Method for playing digital contents protected with a drm (digital rights management) scheme and corresponding system
EP2695355A1 (en) Network streaming of video data using byte range requests
US20150095483A1 (en) Communications terminal, transfer terminal, and content publication method
US20220417313A1 (en) Digital media data management system comprising software-defined data storage and an adaptive bitrate media streaming protocol
OA19292A (en) Resource segmentation to improve delivery performance.

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right