KR20160135811A - Http 스트리밍을 사용하는 dash 스트리밍을 위한 방법 및 장치 - Google Patents

Http 스트리밍을 사용하는 dash 스트리밍을 위한 방법 및 장치 Download PDF

Info

Publication number
KR20160135811A
KR20160135811A KR1020167029356A KR20167029356A KR20160135811A KR 20160135811 A KR20160135811 A KR 20160135811A KR 1020167029356 A KR1020167029356 A KR 1020167029356A KR 20167029356 A KR20167029356 A KR 20167029356A KR 20160135811 A KR20160135811 A KR 20160135811A
Authority
KR
South Korea
Prior art keywords
server
client device
streaming
http
request
Prior art date
Application number
KR1020167029356A
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
Priority claimed from US14/661,668 external-priority patent/US20150271233A1/en
Application filed by 삼성전자주식회사 filed Critical 삼성전자주식회사
Publication of KR20160135811A publication Critical patent/KR20160135811A/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H04L65/4084—
    • 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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • 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

Landscapes

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

Abstract

클라이언트 장치는 미디어 스트리밍을 수신하기 위해 서버와 통신한다. 클라이언트 장치는 서버가 웹소켓을 통해 적응 하이퍼텍스트 전송 프로토콜(HTTP) 스트리밍을 지원하는지 여부를 결정할 수 있다. 예를 들어, 서버는 웹소켓을 통해 적응 HTTP 스트리밍이 지원된다는 표시를 적어도 하나의 클라이언트 장치에 전송할 수 있다. 클라이언트 장치는 HTTP 스트리밍 시 속도 적응 작업들을 수행하기 위해 서버에 명령을 전송한다. 응답으로, 서버는 HTTP 스트리밍 시 속도 적응 작업들을 수행하기 위해 클라이언트 장치로부터 수신된 명령에 응답하여 클라이언트 장치와 수신 웹소켓 연결을 확립하는 단계를 포함한다. 클라이언트 장치는 트리거 이벤트가 발생할 때까지 미디어 세그먼트들을 계속 수신한다.

Description

HTTP 스트리밍을 사용하는 DASH 스트리밍을 위한 방법 및 장치{METHOD AND APPARATUS FOR DASH STREAMING USING HTTP STREAMING}
본 발명은 일반적으로 전송 시스템에서의 미디어 데이터 전송, 보다 구체적으로, 푸시 기반 적응 하이퍼텍스트 전송 프로토콜(HTTP) 스트리밍에 관한 것이다.
전통적으로, 전송 제어 프로토콜(TCP)은 오디오 및 비디오 컨텐트와 같은 실시간 미디어의 전송에 적합하지 않은 것으로 간주되어왔다. 이것은 주로 TCP를 구현하는 재전송 절차 및 공격적인 혼잡 제어 알고리즘 때문이다. TCP에서, 송신기는 일반적으로 패킷 손실 또는 과도한 전송 지연을 통해 인식되는 혼잡 이벤트의 검출 시 전송 속도를 크게(일반적으로, 반으로) 감소시킨다. 결과적으로, TCP의 전송 처리량은 일반적으로 잘 알려진 톱니 형상을 특징으로 한다. TCP는 신뢰할 수 있는 혼잡 인식 전송을 위해 전송 지연을 희생시키는 반면에, 스트리밍 어플리케이션들은 지연에 민감하지만 상대적으로 손실을 허용하기 때문에 이러한 거동은 스트리밍 어플리케이션에 해롭다.
최근에, 인터넷을 통해 멀티미디어 컨텐트를 전송하기 위한 바람직한 프로토콜로서 하이퍼텍스트 전송 프로토콜(HTTP)을 사용하는 방향으로 추세가 변하고 있다. HTTP는 TCP 위에서 실행되는 텍스트 프로토콜이다. 이러한 변화의 원인은 프로토콜의 사용 용이성 때문이다. 컨텐트를 전송하는 전용 서버를 사용할 필요가 없다. 또한, HTTP는 일반적으로 방화벽 및 NAT를 통해 액세스할 수 있는 권한이 부여되고, 이는 사용을 크게 간소화한다.
제1 실시예에서, 장치가 제공된다. 장치는 서버와의 통신 연결을 확립하도록 구성된 안테나를 포함한다. 또한, 장치는 웹소켓을 통해 적응 하이퍼텍스트 전송 프로토콜(HTTP) 스트리밍을 지원하는 서버의 능력을 결정하고, HTTP 스트리밍 시 속도 적응 작업들을 수행하는 서버에 명령을 전송하고, HTTP 스트리밍에서 서버로부터의 정보를 수신하도록 구성된 처리 회로를 포함한다.
제2 실시예에서, 서버가 제공된다. 서버는 적어도 하나의 클라이언트 장치에 결합하도록 구성된 인터페이스를 포함한다. 또한 서버는 웹소켓을 통해 적응 하이퍼텍스트 전송 프로토콜(HTTP)이 지원된다는 표시를 적어도 하나의 클라이언트 장치에 전송하고, 업그레이드에 대한 요청을 수신하고, 업그레이드를 수락할지 거부할지 여부를 결정하고, HTTP 스트리밍 시 스트리밍 작업들에 대한 적어도 하나의 클라이언트 장치로부터 수신된 명령에 응답하여 적어도 하나의 클라이언트 장치와 수신 웹소켓 연결을 확립하도록 구성된 처리 회로를 포함한다.
제3 실시예에서, 클라이언트 장치를 위한 방법이 제공된다. 방법은 서버와의 통신 연결을 확립하는 단계를 포함한다. 또한, 방법은 웹소켓을 통해 적응 하이퍼텍스트 전송 프로토콜(HTTP) 스트리밍을 지원하는 서버의 능력을 결정하는 단계를 포함한다. 또한, 방법은 HTTP 스트리밍 시 스트리밍 작업들을 수행하는 서버에 명령을 전송하는 단계를 포함한다.
다른 기술적 특징들은 다음의 도면, 설명, 및 청구 범위들로부터 당업자에게 명백해질 수 있다.
아래의 상세 설명을 착수하기 전에, 본 특허 문서 전반에 걸쳐서 사용되는 특정 단어 및 구문들의 정의를 규정하는 것이 유리할 수 있다. 용어 "커플" 및 그의 파생어들은 서로 물리적으로 접촉하든 아니든 두 개 이상의 요소 간의 직접 또는 간접 통신을 의미한다. 용어 "전송하다", "수신하다", "통신하다" 및 이들의 파생어는 직접 및 간접 통신 모두를 포함한다. 용어 "포함하다(include)", "포함하다(comprise)" 및 이들의 파생어는 제한 없는 포함을 의미한다. 용어 "또는"은 "및/또는"을 의미하는 포함이다. 구분 "~와 관련된" 및 이의 파생어들은 포함하다, ~내에 포함되다, ~와 상호 연결하다, 포함하다, ~ 내에 포함되다, ~와 또는 ~에 연결하다, ~와 또는 ~에 결합하다, ~와 통신할 수 있다, ~와 협력하다, 인터리브하다, 나란히 놓다, ~에 인접하다, ~에 또는 ~와 바인딩하다, 갖다, ~의 속성이 있다, ~에 또는 ~와 관계가 있다 등을 의미한다. 용어 "제어기"는 적어도 하나의 동작을 제어하는 모든 장치, 시스템 또는 이들의 일부를 의미한다. 이러한 제어기는 하드웨어, 또는 하드웨어와 소프트웨어 및/또는 펌웨어의 조합에서 구현될 수 있다. 모든 특정 제어기와 관련된 기능은 국부적으로든 원격으로든 중앙 집중화되거나 분산될 수 있다. 항목들의 목록과 함께 사용될 때 "~의 적어도 하나"라는 구문은 나열된 항목들 중 하나 이상의 상이한 조합들이 사용될 수도 있고, 목록에서 단지 하나의 항목만이 요구될 수도 있다는 것을 의미한다. 예를 들어, "A, B 및 C 중 적어도 하나"는 다음의 조합, 즉 A, B, C, A와 B, A와 C, B와 C, 및 A와 B와 C 중 어느 하나를 포함한다.
또한, 후술되는 다양한 기능들은 컴퓨터 판독 가능한 프로그램 코드로부터 형성되고 컴퓨터 판독 가능한 매체에 내장되는 하나 이상의 컴퓨터 프로그램에 의해 구현되거나 지원될 수 있다. 용어 "어플리케이션" 및 "프로그램"은 적합한 컴퓨터 판독 가능한 프로그램 코드로 구현을 위해 구성된 하나 이상의 컴퓨터 프로그램, 소프트웨어 구성 요소, 지시들의 집합, 절차, 함수, 오브젝트, 클래스, 인스턴스, 관련 데이터, 또는 이들의 일부를 의미한다. 구문 "컴퓨터 판독 가능한 프로그램 코드"는 소스 코드, 오브젝트 코드 및 실행 가능한 코드를 포함하여 모든 유형의 컴퓨터 코드를 포함한다. 구문 "컴퓨터 판독 가능한 매체"는 읽기 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 하드 디스크 드라이브, 콤팩트 디스크(CD), 디지털 비디오 디스크(DVD), 또는 다른 유형의 메모리와 같이 컴퓨터에 의해 액세스될 수 있는 모든 유형의 매체를 포함한다. "비-일시적인" 컴퓨터 판독 가능한 매체는 유선, 무선, 광, 또는 일시적인 전기 또는 다른 신호들을 전송하는 다른 무선 링크들을 제외한다. 비-일시적인 컴퓨터 판독 가능한 매체는 데이터가 영구적으로 저장될 수 있는 매체 및 재기록이 가능한 광 디스크 또는 소거 가능한 메모리 장치와 같이 데이터가 저장되고 나중에 덮어쓰기 할 수 있는 매체를 포함한다.
다른 특정 단어 및 구문들에 대한 정의는 본 특허 문서 전반에 걸쳐서 제공된다. 당업자들은 대부분은 아니지만 많은 경우에 이러한 정의들이 이러한 정의된 단어 및 구문들의 이전뿐만 아니라 미래의 사용에도 적용됨을 이해해야 한다.
본 발명 및 그 장점들의 보다 완전한 이해를 위해, 이제 참조가 유사 도면 부호들은 유사 부품들을 나타내는 첨부 도면들과 함께 주어진 다음의 설명에 이루어진다.
도 1은 본 발명에 따른 예시적인 컴퓨팅 시스템을 도시한다.
도 2 및 도 3은 본 발명에 따른 컴퓨팅 시스템의 예시적인 장치들을 도시한다.
도 4는 본 발명의 실시예들에 따른 적응 HTTP 스트리밍 아키텍처를 도시한다.
도 5는 본 발명의 실시예들에 따른 MPD 구조를 도시한다.
도 6 및 도 7은 본 발명에 따른 HTTP 1.0과 HTTP 1.1의 차이점들을 도시한다.
도 8은 본 발명의 실시예들에 따른 웹소켓 지원 네트워크를 도시한다.
도 9는 본 발명의 실시예들에 따른 클라이언트 장치에 웹소켓을 사용하는 적응 HTTP 스트리밍 프로세스를 도시한다.
도 10은 본 발명의 실시예들에 따른 서버에 웹소켓을 사용하는 적응 HTTP 스트리밍 프로세스를 도시한다.
후술되는 도 1 내지 도 10, 및 본 특허 문서에서 본 발명의 원리들을 설명하기 위해 사용된 다양한 실시예들은 단지 예시를 위한 것으로 본 발명의 범위를 한정하는 방식으로 해석되어서는 안된다. 당업자들은 본 발명의 원리들이 모든 적합하게 배치된 장치 또는 시스템에서 구현될 수 있음을 이해할 것이다.
도 1은 본 발명에 따른 예시적인 컴퓨팅 시스템(100)을 도시한다. 도 1에 도시된 컴퓨팅 시스템(100)의 실시예는 단지 예시를 위한 것이다. 본 발명의 범위에서 벗어나지 않고 컴퓨팅 시스템(100)의 다른 실시예들이 사용될 수 있다.
도 1에 도시된 바와 같이, 시스템(100)은 시스템(100)의 다양한 구성 요소들 간의 통신을 용이하게 하는 네트워크(102)를 포함한다. 예를 들어, 네트워크(102)는 네트워크 주소 사이에서 인터넷 프로토콜(IP) 패킷, 프레임 중계 프레임, 비동기식 전송 모드(ATM) 셀, 또는 다른 정보를 통신할 수 있다. 네트워크(102)는 하나 이상의 근거리 네트워크(LAN), 대도시 네트워크(MAN), 광역 네트워크(WAN), 인터넷과 같은 글로벌 네트워크의 전부 또는 일부, 또는 하나 이상의 위치에 있는 모든 다른 통신 시스템이나 시스템들을 포함할 수 있다.
네트워크(102)는 적어도 하나의 서버(104)와 다양한 클라이언트 장치들(106 내지 114) 간의 통신을 용이하게 한다. 각각의 서버(104)는 하나 이상의 클라이언트 장치에 컴퓨팅 서비스를 제공할 수 있는 모든 적합한 컴퓨팅 또는 처리 장치를 포함한다. 각각의 서버(104)는 예를 들어, 하나 이상의 처리 장치, 지시 및 데이터를 저장하는 하나 이상의 메모리, 및 네트워크(102)를 통해 통신을 용이하게 하는 하나 이상의 네트워크 인터페이스를 포함할 수 있다.
각각의 클라이언트 장치(106 내지 114)는 네트워크(102)를 통해 적어도 하나의 서버 또는 다른 컴퓨팅 장치(들)과 인터렉트하는 모든 적합한 컴퓨팅 또는 처리 장치를 나타낸다. 본 예에서, 클라이언트 장치들(106 내지 114)은 데스크톱 컴퓨터(106), 휴대 전화 또는 스마트 폰(108), 개인 휴대용 정보 단말기(PDA)(110), 랩톱 컴퓨터(112), 및 태블릿 컴퓨터(114)를 포함한다. 그러나, 모든 다른 또는 추가 클라이언트 장치들이 컴퓨팅 시스템(100)에서 사용될 수 있다.
본 예에서, 일부 클라이언트 장치들(108 내지 114)은 네트워크(102)와 간접적으로 통신한다. 예를 들어, 클라이언트 장치들(108 내지 110)은 셀룰러 기지국 또는 eNodeB와 같은 하나 이상의 기지국(116)을 통해 통신한다. 또한, 클라이언트 장치들(112 내지 114)은 IEEE 802.11 무선 액세스 지점과 같은 하나 이상의 무선 액세스 지점(118)을 통해 통신한다. 이들은 단지 예시를 위한 것으로 각각의 클라이언트 장치는 네트워크(102)와 직접적으로 또는 모든 적합한 중간 장치(들)이나 네트워크(들)을 통해 네트워크(102)와 간접적으로 통신할 수 있음을 유의해야 한다.
보다 상세히 후술되는 바와 같이, 네트워크(102)는 HTTP를 통해 효율적인 푸시 기반 미디어 스트리밍을 용이하게 한다. 하나 이상의 서버(104)는 웹소켓을 통해 미디어 스트리밍을 지원한다. 하나 이상의 클라이언트 장치(106 내지 114)는 서버(104)가 웹소켓을 통해 미디어 스트리밍을 지원할 때 감지할 수 있다. 서버(104)가 웹소켓을 통해 미디어 스트리밍을 지원할 때, 하나 이상의 클라이언트 장치(106 내지 114)는 서버에 웹소켓 연결을 확립하고 스트림에서의 위치 및 선택된 리프레젠테이션을 표시하는 초기 요청을 제출할 수 있다. 이후, 각각의 클라이언트 장치(106 내지 114)는 서버(104)에 의해 푸시되는 미디어 세그먼트들을 순차적으로 수신한다.
도 1은 컴퓨팅 시스템(100)의 일 예를 도시하지만, 다양한 변경이 도 1에 이루어질 수 있다. 예를 들어, 시스템(100)은 모든 적합한 배치에서 각각의 구성 요소를 얼마든지 포함할 수 있다. 일반적으로, 컴퓨팅 및 통신 시스템은 다양한 구성으로 제공되고, 도 1은 임의의 특정 구성으로 본 발명의 범위를 한정하지 않는다. 도 1은 본 특허 문서에 개시된 다양한 특징들이 사용될 수 있는 하나의 운영 환경을 도시하지만, 이들 특징은 모든 다른 적합한 시스템에서 사용될 수 있다.
도 2 및 도 3은 본 발명에 따른 컴퓨팅 시스템의 예시적인 장치들을 도시한다. 특히, 도 2는 예시적인 서버(200)를 도시하고, 도 3은 예시적인 클라이언트 장치(300)를 도시한다. 서버(200)는 도 1의 서버(104)를 나타낼 수 있고, 클라이언트 장치(300)는 도 1의 클라이언트 장치들(106 내지 114) 중 하나 이상을 나타낼 수 있다.
도 2에 도시된 바와 같이, 서버(200)는 적어도 하나의 처리 장치(210), 적어도 하나의 저장 장치(215), 적어도 하나의 통신 유닛(220), 및 적어도 하나의 입력/출력(I/O) 유닛(225) 간의 통신을 지원하는 버스 시스템(205)을 포함한다. 서버(104)는 서버(200)와 동일하거나 유사하도록 구성될 수 있다. 서버(200)는 웹소켓을 통해 미디어 스트리밍을 지원할 수 있다.
처리 장치(210)는 메모리(230)에 로딩될 수 있는 지시들을 실행한다. 처리 장치(210)는 모든 적합한 배치에서 모든 적합한 개수(들) 및 유형(들)의 프로세서 또는 다른 장치들을 포함할 수 있다. 예시적인 유형의 처리 장치(210)들은 마이크로프로세서, 마이크로제어기, 디지털 신호 프로세서, 필드 프로그래밍 가능 게이트 어레이, 주문형 집적 회로, 및 이산 회로를 포함한다.
메모리(230) 및 영구 저장 장치(235)는 (데이터, 프로그램 코드, 및/또는 일시적이거나 영구적인 다른 적합한 정보와 같은) 정보를 저장하고 정보의 검색을 용이하게 할 수 있는 구조(들)을 나타내는 저장 장치(215)의 예이다. 메모리(230)는 랜덤 액세스 메모리 또는 모든 다른 적합한 휘발성 또는 비휘발성 저장 장치(들)을 나타낼 수 있다. 영구 저장 장치(235)는 읽기 전용 메모리, 하드 드라이브, 플래시 메모리, 또는 광 디스크와 같이 데이터의 장기 저장을 지원하는 하나 이상의 구성 요소 또는 장치들을 포함할 수 있다.
통신 유닛(220)은 다른 시스템 또는 장치들과의 통신을 지원한다. 예를 들어, 통신 유닛(220)은 처리 회로, 네트워크 인터페이스 카드 또는 네트워크(102)를 통해 통신을 용이하게 하는 무선 송수신기를 포함할 수 있다. 통신 유닛(220)은 모든 적합한 물리적 또는 무선 통신 링크(들)을 통해 통신을 지원할 수 있다. 통신 유닛(220)은 하나 이상의 클라이언트 장치에 연결할 수 있다. 즉, 통신 유닛(220)은 적어도 하나의 클라이언트 장치에 결합하도록 구성된 인터페이스를 제공한다.
I/O 유닛(225)은 데이터의 입력 및 출력을 허용한다. 예를 들어, I/O 유닛(225)은 키보드, 마우스, 키패드, 터치스크린, 또는 다른 적합한 입력 장치를 통해 사용자 입력을 위한 연결을 제공할 수 있다. 또한, I/O 유닛(225)은 디스플레이, 프린터, 또는 다른 적합한 출력 장치에 출력을 전송할 수 있다.
도 2는 도 1의 서버(104)를 나타내는 것으로 설명되지만, 동일하거나 유사한 구조가 클라이언트 장치들(106 내지 114) 중 하나 이상에서 사용될 수 있다는 것을 유의해야 한다. 예를 들어, 랩톱 또는 데스크톱 컴퓨터가 도 2에 도시된 구조와 동일하거나 유사한 구조를 가질 수 있다.
도 3은 본 발명에 따른 예시적인 STA(300)를 도시한다. 도 2에 도시된 STA(300)의 실시예는 단지 예시를 위한 것이고, 도 1의 STA(104 내지 112)는 동일하거나 유사한 구성을 가질 수 있다. 그러나, STA는 다양한 구성으로 제공되고, 도 3은 STA의 어떤 특정 구현으로 본 발명의 범위를 한정하지 않는다.
STA(300)는 복수의 안테나(305a 내지 305n), 복수의 무선 주파수(RF) 송수신기(310a 내지 310n), 송신(TX) 처리 회로(315), 마이크로폰(320), 및 수신(RX) 처리 회로(325)를 포함한다. TX 처리 회로(315) 및 RX 처리 회로(325)는 RF 송수신기(310a 내지 310n)의 각각에 예를 들어, 안테나(305a), 안테나(305b) 내지 N 번째 안테나(305n)에 각각 결합되는 RF 송수신기(310a), RF 송수신기(310b) 내지 N 번째 RF 송수신기(310n)에 각각 결합된다. 특정 실시예들에서, STA(104)는 하나의 안테나(305a) 및 하나의 RF 송수신기(310a)를 포함한다. 또한, STA(300)는 스피커(330), 메인 프로세서(340), 입력/출력(I/O) 인터페이스(IF)(345), 키패드(350), 디스플레이(355), 및 메모리(360)를 포함한다. 메모리(260)는 기본 운영 체계(OS) 프로그램(261) 및 하나 이상의 어플리케이션(262)을 포함한다.
RF 송수신기(310a 내지 310n)는 네트워크(100)의 AP(102)에 의해 전송된 입력 RF 신호를 각각의 안테나(305a 내지 305n)로부터 수신한다. RF 송수신기(310a 내지 310n)는 중간 주파수(IF) 또는 기저대 신호를 생성하기 위해 입력 RF 신호를 다운컨버팅한다. IF 또는 기저대 신호는 기저대 또는 IF 신호를 필터링, 디코딩, 및/또는 디지털화함으로써 처리된 기저대 신호를 생성하는 RF 처리 회로(325)에 전송된다. RF 처리 회로(325)는 (웹 브라우징 데이터 등에 대한) 추가 처리를 위해 메인 프로세서(340)에 또는 (음성 데이터 등을 위해) 스피커(330)에 처리된 기저대 신호를 전송한다.
TX 처리 회로(315)는 마이크로폰(320)으로부터 아날로그 또는 디지털 음성 데이터를 수신하거나, 메인 프로세서(340)로부터 (웹 데이터, 이메일, 또는 인터랙티브 비디오 게임 데이터와 같은) 다른 출력 기저대 데이터를 수신한다. TX 처리 회로(315)는 처리된 기저대 또는 IF 신호를 생성하기 위해 출력 기저대 데이터를 인코딩, 멀티플렉싱, 및/또는 디지털화한다. RF 송수신기(310a 내지 310n)는 TX 처리 회로(315)로부터 출력 처리된 기저대 또는 IF 신호를 수신하고, 안테나(305a 내지 305n) 중 하나 이상을 통해 전송되는 RF 신호로 기저대 또는 IF 신호를 업컨버팅한다.
메인 프로세서(340)는 하나 이상의 프로세서 또는 다른 처리 장치들을 포함할 수 있고, STA(300)의 전체 작업을 제어하기 위해 메모리(360)에 저장된 기본 OS 프로그램(361)을 실행할 수 있다. 예를 들어, 메인 프로세서(340)는 잘 알려진 원리들에 따라 RF 송수신기(310a 내지 310n), RX 처리 회로(325) 및 TX 처리 회로(315)에 의해 순방향 채널 신호들의 수신 및 역방향 채널 신호들의 전송을 제어할 수 있다. 일부 실시예들에서, 메인 프로세서(340)는 적어도 하나의 마이크로프로세서 또는 마이크로제어기를 포함한다.
또한, 메인 프로세서(340)는 웹소켓을 통해 미디어를 스트리밍하기 위한 작업들과 같이 메모리(360)에 상주하는 다른 프로세스 및 프로그램들을 실행할 수 있다. 메인 프로세서(340)는 실행하는 프로세스에 의해 필요에 따라 메모리(360)의 안으로 또는 밖으로 데이터를 이동시킬 수 있다. 일부 실시예에서, 메인 프로세서(340)는 작업자 또는 AP(102)로부터 수신된 신호들에 응답하여, 또는 OS 프로그램(361)을 기반으로 하여 어플리케이션(362)들을 실행하도록 구성된다. 또한, 메인 프로세서(340)는 STA(300)에 랩톱 컴퓨터 및 핸드헬드 컴퓨터와 같은 다른 장치들에 연결하는 능력을 제공하는 I/O 인터페이스(345)와 결합된다. I/O 인터페이스(345)는 메인 제어기(340)와 이들 부속 장치 간의 통신 경로이다.
또한, 메인 프로세서(340)는 키패드(350) 및 디스플레이 유닛(355)에 결합된다. STA(300)의 작업자는 STA(300)에 데이터를 입력하기 위해 키패드(350)를 사용할 수 있다. 디스플레이(355)는 웹 사이트로부터와 같이 텍스트 및/또는 적어도 제한된 그래픽들을 랜더링할 수 있는 액정 디스플레이 또는 다른 디스플레이일 수 있다.
메모리(360)는 메인 프로세서(340)에 결합된다. 메모리(360)의 일부는 랜덤 액세스 메모리(RAM)를 포함할 수 있고, 메모리(360)의 또 다른 일부는 플래시 메모리 또는 다른 읽기 전용 메모리(ROM)를 포함할 수 있다.
도 2 및 도 3은 컴퓨팅 시스템 내에 있는 장치들의 예를 도시하지만, 다양한 변경들이 도 2 및 도 3에 대해 이루어질 수 있다. 예를 들어, 도 2 및 도 3의 다양한 구성 요소들은 결합되거나, 더 세분화되거나, 생략될 수 있고, 추가 구성 요소들이 특정 요구에 따라 추가될 수 있다. 특정 예로서, 메인 프로세서(340)는 하나 이상의 중앙 처리 유닛(CPU) 및 하나 이상의 그래픽 처리 유닛(GPU)과 같이 복수의 프로세서로 나뉠 수 있다. 또한, 도 3은 이동 전화 또는 스마트폰으로서 구성된 클라이언트 장치(300)를 도시하지만, 클라이언트 장치들은 다른 유형의 이동 장치 또는 고정 장치들로서 동작하도록 구성될 수 있다. 또한, 컴퓨팅 및 통신 네트워크에 대해 말하자면, 클라이언트 장치 및 서버들은 다양한 구성으로 제공될 수 있고, 도 2 및 도 3은 어떤 특정 클라이언트 장치 또는 서버로 본 발명을 한정하지 않는다.
HTTP를 통한 동적 적응 스트리밍(DASH)은 최근에 3GPP 및 MPEG에 의해 표준화되었다. MICROSOFT®에 의한 부드러운 스트리밍 및 APPLE®에 의한 HTTP 라이브 스트리밍(HLS)과 같은 적응 HTTP 스트리밍에 대한 여러 가지 다른 독점적인 솔루션들이 현재 시중에서 효율적으로 사용되고 있다. 반면에, DASH는 상이한 구현들 간의 상호 운용성을 구동하는 완전 개방 및 표준화된 미디어 스트리밍 솔루션이다.
도 4는 본 발명의 실시예들에 따른 적응 HTTP 스트리밍 아키텍처를 도시한다. 도 4에 도시된 HTTP 스트리밍 아키텍처(400)의 실시예는 단지 예시를 위한 것이다. 본 발명의 범위에서 벗어나지 않고 다른 실시예들이 사용될 수 있다.
HTTP 스트리밍 아키텍처(400)에서, 컨텐트는 컨텐트 준비(405) 단계에서 준비된다. 컨텐트는 HTTP 스트리밍 서버(410)에 의해 전달된다. HTTP 스트리밍 서버(410)는 서버(104)와 동일하거나 유사하게 구성될 수 있다. 스트리밍에서, 컨텐트는 캐시되거나, HTTP 캐시(415)에서 버퍼링되어 HTTP 스트리밍 클라이언트(420)로 추가 스트리밍된다. HTTP 스트리밍 클라이언트(420)는 클라이언트(106 내지 114) 중 하나일 수 있다.
DASH에서, 컨텐트가 복수의 세그먼트로 분할되는 컨텐트 준비(405) 단계가 수행되어야 한다. 초기화 세그먼트는 미디어 플레이어를 구성하는 데 필요한 정보를 전달하기 위해 생성된다. 그때서야 미디어 세그먼트들이 소비될 수 있다. 컨텐트는 일반적으로 복수의 변형, 일반적으로 여러 비트 전송률로 인코딩된다. 각각의 변형은 컨텐트의 리프레젠테이션에 대응한다. 컨텐트 리프레젠테이션들은 서로 대안적일 수 있거나, 서로를 보완할 수 있다. 전자의 경우, 클라이언트는 대안적인 리프레젠테이션들의 그룹 중에서 단지 하나의 대안을 선택한다. 대안적인 리프레젠테이션들은 적응 집합으로서 함께 그룹화된다. 클라이언트는 추가적인 미디어 구성 요소들을 포함하는 보완 리프레젠테이션들을 계속 추가할 수 있다.
DASH 스트리밍을 위해 제공된 컨텐트를 클라이언트(420)에 설명할 필요가 있다. 이것은 미디어 프레젠테이션 설명(MPD) 파일을 사용하여 수행된다. MPD는 컨텐트의 설명, 컨텐트의 기간, 적응 집합, 컨텐트의 리프레젠테이션, 및 가장 중요하게, 컨텐트의 각 피스에 액세스하는 방법을 포함하는 XML 파일이다. MPD 요소는 MPD 파일의 메인 요소이다. MPD 요소는 컨텐트의 유형 및 컨텐트가 사용할 수 있는 시간 창과 같은 컨텐트에 대한 일반적인 정보를 포함한다. MPD는 하나 이상의 기간을 포함하고, 각각의 기간은 컨텐트의 시간 세그먼트를 설명한다. 각각의 기간은 하나 이상의 적응 집합으로 그룹화된 하나 이상의 컨텐트의 리프레젠테이션들을 포함할 수 있다. 각각의 리프레젠테이션은 하나 이상의 컨텐트 구성 요소들의 인코딩이고, 특정 구성을 갖는다. 리프레젠테이션들은 주로 그들의 대역폭 요건, 그들이 포함하는 미디어 구성 요소, 사용하고 있는 코덱, 언어 등이 상이하다.
도 5는 본 발명의 실시예들에 따른 MPD 구조를 도시한다. 도 5에 도시된 MPD 구조(500)의 실시예는 단지 예시를 위한 것이다. 본 발명의 범위에서 벗어나지 않고 다른 실시예들이 사용될 수 있다.
도 5에 도시된 예에서, MPD 구조(500)는 다수의 기간(510)을 갖는 미디어 프레젠테이션(505)을 포함한다. 각각의 기간(510)은 다수의 적응 집합(515)을 포함한다. 각각의 적응 집합(515)은 다수의 리프레젠테이션(520)을 포함한다. 각각의 리프레젠테이션(520)은 세그먼트 정보(525)를 포함한다. 세그먼트 정보(525)는 초기 세그먼트(530) 및 다수의 미디어 세그먼트(535)를 포함한다.
DASH의 하나의 구현 시나리오에서, ISO-기반 파일 형식 및 그 파생 형식(MP4 및 3GP 파일 형식)이 사용된다. 컨텐트는 소위 무비 프래그먼트에 저장된다. 각각의 무비 프래그먼트는 미디어 데이터 및 해당 메타 데이터를 포함한다. 미디어 데이터는 일반적으로 리프레젠테이션의 모든 미디어 구성 요소들로부터의 미디어 샘플들의 수집이다. 각각의 미디어 구성 요소는 파일의 트랙으로 설명된다.
HTTP 스트리밍
HTTP는 요청/응답 기반 프로토콜이다. 클라이언트 장치(300)는 그의 HTTP 요청들을 전송하기 위해 서버(200)에 대한 연결을 확립한다. 서버(200)는 HTTP 요청들을 수신하고 클라이언트 장치(300)에 응답들을 다시 전송하기 위해 클라이언트 장치(300)로부터의 연결을 수락한다. 표준 HTTP 모델에서, 서버(200)는 클라이언트에 대한 연결을 개시할 수도 요청되지 않은 HTTP 응답을 전송할 수도 없다. HTTP를 통해 미디어 스트리밍을 수행하기 위해, 클라이언트 장치(300)는 세그먼트(505)에 의해 미디어 데이터 세그먼트(505)를 요청해야 한다. 이것은 추가적인 종단 간(end-to-end) 지연뿐만 아니라 요청에 대한 상당한 업스트림 트래픽을 생성한다.
웹 어플리케이션에 대한 상황을 개선하기 위해, 여러 가지의 소위 HTTP 스트리밍 메커니즘들이 커뮤니티에 의해 개발되었다. 이러한 메커니즘들은 클라이언트 장치(300)로부터의 폴(poll) 요청을 기다리지 않고 웹 서버(200)가 데이터를 클라이언트 장치(300)에 전송할 수 있도록 한다. (일반적으로 COMET로 표시되는) HTTP 스트리밍에 대한 주요 접근 방법들은 데이터를 사용할 수 있게 될 때까지 요청을 보류 상태로 유지하거나 응답을 무기한 오픈 상태로 유지하는 것이다. 첫 번째의 경우, 응답이 수신된 후에 새로운 요청이 여전히 전송될 필요가 있을 것이다. HTTP 스트리밍에서, 요청은 종료되지 않고 연결은 닫히지 않는다. 이때, 데이터는 데이터를 사용할 수 있을 때마다 클라이언트 장치(300)에 푸시된다.
HTTP 롱 폴링(long pooling)
전통적인 요청들과 함께, 클라이언트는 서버(200)에 일반적인 요청을 전송하고, 각각의 요청은 모든 사용 가능한 데이터를 가져오려고 시도한다. 사용 가능한 데이터가 없다면, 서버(200)는 빈 응답 또는 오류 메시지들을 돌려준다. 클라이언트 장치(300)는 나중에 폴(poll)을 수행한다. 폴링 빈도는 어플리케이션에 의존한다. DASH에서, 이것은 세그먼트 가용성 시작 시간에 의해 결정되지만, 클라이언트와 서버 간 클록(clock) 동기화를 필요로 한다.
롱 폴링에서, 서버(200)는 요청한 리소스를 사용할 수 있을 때까지 요청을 보류 상태로 유지함으로써 대기 시간 및 폴링 빈도를 최소화하려고 시도한다. DASH에 적용된 경우, 요청한 DASH 세그먼트를 사용할 수 있을 때까지 어떠한 응답도 전송되지 않을 것이다. 반면에, 현재의 디폴트 동작은 사용할 수 없는 세그먼트에 대한 요청이 "404 오류" 응답이 될 것이라는 것이다.
그러나, 클라이언트 장치(300)가 모든 세그먼트에 대한 HTTP 요청을 여전히 전송해야 하기 때문에, 롱 폴링은 DASH에 대해 최적이 아닐 수도 있다. 또한, 세그먼트 URL은 선험적으로 알려져 있지 않을 가능성이 크기 때문에, 클라이언트 장치(300)는 우선 MPD를 얻고, 이를 구문 분석하여 추가적인 지연을 초래하는 현재의 세그먼트의 위치를 발견해야 할 것이다.
HTTP 스트리밍
HTTP 스트리밍 메커니즘은 요청을 무기한 오픈 상태로 유지한다. 메커니즘은 일부 데이터가 클라이언트에 전송된 후에도 요청을 종료하거나 연결을 닫지 않는다. 클라이언트 및 서버가 연결을 열고 닫을 필요가 없기 때문에 이 메커니즘은 대기 시간을 상당히 감소시킨다. 절차는 초기 요청을 만드는 클라이언트 장치(300)에 의해 시작된다. 이후, 클라이언트 장치(300)는 응답을 기다린다. 서버(200)는 데이터를 사용할 수 있을 때까지 응답을 미룬다. 데이터가 사용 가능할 때마다 서버는 부분 응답으로 클라이언트 장치(300)에 데이터를 다시 전송할 것이다. 이것은 HTTP/1.1과 HTTP/1.0 둘 다에 의해 지원되는 능력이다. 이 경우, 컨텐트-길이 헤더 필드는 선험적으로 알려져 있지 않기 때문에 응답으로 제공되지 않는다. 대신에, 응답 길이는 연결의 닫힘을 통해 결정될 것이다. 이러한 HTTP 스트리밍 접근 방법의 주요 문제는 이러한 연결들에 대한 중간 노드의 동작을 보장할 수 없다는 것이다. 예를 들어, 중간 노드는 즉시 부분 응답을 전송할 수 없다. 중간 노드는 응답을 버퍼링하기로 결정하고 나중에 이를 전송할 수 있다.
도 6 및 도 7은 본 발명에 따른 HTTP 1.0과 HTTP 1.1의 차이점들을 도시한다. 흐름도는 순차적인 일련의 단계들을 도시하지만, 명시적으로 언급하지 않는 한, 성능의 특정 순서, 중복 방식으로 또는 동시에 보다는 순차적으로 단계들 또는 그의 부분들의 성능, 또는 개입 또는 중간 단계들의 발생 없이 독점적으로 도시되는 단계들의 성능에 관한 시퀀스로부터 어떠한 추론도 도출되어서는 안된다. 도시된 예에 도시된 프로세스는 예를 들어 서버 또는 클라이언트 장치에서 처리 회로에 의해 구현된다.
HTTP/2 및 웹소켓
HTTP 프로토콜에 더 많은 유연성이 필요하다는 것이 조기에 확인되었지만, 커뮤니티는 가장 인기 있고 많이 사용되는 프로토콜 중 하나를 변경하기를 꺼려하고 있다. 도 6에 도시된 예는 HTTP 1.0(600)이 연결 당 하나의 요청만 허용함으로써 TCP 연결을 증가시키거나 감소시키기 위해 지연을 초래할 수 있음을 보여준다. 클라이언트 장치(300)에 의한 각각의 "get" 요청에 대해, 연속적인 응답이 서버(200)에 의해 전송된다. 즉, 클라이언트 장치(300)에 의한 제1 "get" 요청(605a)에 대해, 연속적인 응답(610a)이 서버(200)에 의해 전송된다. 클라이언트 장치(300)에 의한 제2 "get" 요청(605b)에 대해, 연속적인 응답(610b)이 서버(200)에 의해 전송된다. 도 7에 도시된 예는 HTTP 1.1(700)이 영구적인 연결 및 요청 파이프라이닝을 도입한다는 것을 보여준다. 클라이언트 장치(300)에 의한 복수의 "get" 요청에는 서버(200)에 의해 전송되는 복수의 각각의 응답이 이어진다. 즉, 제1 "get" 요청(705a), 제2 "get" 요청(705b), 및 제3 "get" 요청(705c)이 클라이언트 장치(300)에 의해 전송된다. 응답으로, 각각의 제1 응답(710a), 제2 응답(710b), 및 제3 응답(710c)이 서버(200)에 의해 전송된다. 영구적인 연결들과 함께, 동일한 TCP 연결이 복수의 요청을 전송하고 이들의 응답을 수신하기 위해 사용될 수 있다. 이것은 TCP의 연결 설정 및 느린 시작 단계를 거치지 않도록 한다. 요청 파이프라이닝은 클라이언트가 이전 요청들에 대한 응답을 수신하기 전에 복수의 요청을 전송할 수 있도록 한다. 도 6 및 도 7에 도시된 예들은 지연 및 링크 이용의 측면에서 잠재적인 이득을 보여주는 HTTP 1.0 및 HTTP 1.1에 대한 상이한 메시지 교환 시퀀스들을 도시한다.
그러나, HTTP 1.1(700)은 파이프라이닝 및 영구적인 연결의 도입으로 모든 어플리케이션 요구를 충족시키지 않는다. 예를 들어, 파이프라이닝을 사용하는 경우에도, 서버(200)로부터의 응답들은 클라이언트 장치(300)가 요청하는 것과 동일한 순서이어야 하고, 하나의 요청이 차단되면, 다음 요청들 또한 차단될 것이다. 즉, 제1 "get" 요청(705a)이 차단되면, 제2 "get" 요청(705b) 및 제3 "get" 요청(705c)도 또한 차단된다. HTTP 1.1(700)은 서버(200)에서 클라이언트 장치(300)로의 컨텐트의 푸싱을 지원하지 않는다. 따라서, 클라이언트 장치(300)는 클라이언트 장치(300)가 실제로 요청한 리소스들만 얻을 것이다. 일반적인 웹 사이트들의 경우, 링크된 리소스들의 집합은 그들 모두를 링크하는 주요 HTML 문서를 요청한 후에 요청될 가능성이 매우 높다. 결과적으로, 클라이언트 장치(300)는 웹 사이트를 렌더링하는 과정에서 상당한 지연을 초래할 수 있는 링크된 리소스를 요청하기 전에 수신되어 구문 분석될 주요 파일을 기다려야 한다.
다음의 실시예들에서, HTTP/2 및 웹소켓에 의해 제공되는 새로운 특징들이 개시된다. 본 발명의 특정 실시예들은 HTTP/2 및 웹소켓을 통해 DASH를 가능하게 한다.
HTTP 2.0
본 명세서에서 "HTTP/2"로도 지칭되는 HTTP 2.0은 동시에 모든 기능을 변경하지 않고 유지하면서 HTTP 1.1의 이전 제한 사항들을 해결하고자 한 국제 인터넷 기술 위원회(IETF)의 작업 초안이다.
HTTP/2는 클라이언트 장치(300) 및 서버(200)에 의해 독립적으로 처리되는 스트림들의 개념을 도입한다. 스트림은 요청을 전달하고 해당 요청에 대한 응답을 수신하기 위해 사용된 후 닫힌다. 메시지 교환은 프레임들에서 수행되고, 프레임은 프레임의 페이로드가 무엇인지에 따라 HEADERS 또는 DATA 유형일 수 있다. 또한, 제어 프레임들의 집합이 또한 정의된다. 이들 프레임은 진행중인 스트림을 취소하고(RST_STREAM), 다른 스트림들과 비교한 스트림 우선 순위를 표시하고(PRIORITY), 스트림 설정을 통신하고(SETTINGS), 현재의 TCP 연결에서 스트림이 더 이상 생성될 수 없음을 표시하고(GOAWAY), 핑/퐁 작업을 수행하고(PING 및 PONG), 서버에서 클라이언트로 데이터를 푸시한다는 약속(PUSH_PROMISE), 또는 이전 프레임의 계속(CONTINUATION)을 제공하기 위해 사용된다. 특정 실시예들에서, 프레임의 길이는 최대 16383 바이트이다.
또한, HTTP/2는 헤더 압축을 통해 와이어 효율을 개선하려고 시도한다. 사용될 때, 헤더 압축은 헤더 필드 이름들의 색인을 만들고, 어떤 헤더 필드가 사용되는 지를 표시하기 위해 수치 식별자를 사용한다. 대부분의 헤더 필드는 정적 id 값이 할당되지만, 헤더 압축은 동적으로 다른 헤더 필드들에 값들을 할당할 수 있다.
웹소켓
HTTP/2와 마찬가지로, 특정 실시예들에서 양 말단이 웹소켓에 대한 연결의 업그레이드에 동의하는 핸드쉐이크 절차로 시작하는 완벽한 준수 HTTP 프로토콜 업그레이드로 웹소켓이 또한 구현된다. 웹소켓 연결에 대한 연결의 성공적인 업그레이드 후, 데이터는 양 방향으로 동시에 흐를 수 있고, 이는 완전한 이중 연결을 초래한다. 서버(200)는 클라이언트 요청 없이 클라이언트 장치(300)에 데이터를 전송하기로 결정할 수 있다. 또한, 클라이언트 장치(300)는 서버 응답을 기다릴 필요 없이 복수의 요청을 전송할 수 있다.
사실, HTTP/2는 (데이터, 계속, 핑 및 퐁과 같은) 여러 가지 프레임 유형을 포함하여, 핸드쉐이크 절차 및 프레임 절차와 같은 많은 개념들을 웹소켓으로부터 차용한다. 웹소켓은 어플리케이션 데이터의 형식에 대한 추가적인 세부 사항들을 정의하지 않고 어플리케이션에 그것을 위임한다. 실제 형식은 핸드쉐이크 단계 동안 협상되고, 양쪽 엔드포인트는 Sec-웹소켓-프로토콜(Sec-WebSorket-Protocol) 헤더 필드를 교환함으로써 사용할 하위 프로토콜에 동의한다.
본 발명의 특정 실시예들에 따르면:
클라이언트 장치(300)는 지속적으로 데이터를 가져오는 것을 방지하고;
클라이언트 장치(300)는 동기화 문제 및 리소스 페치 오류를 방지하고;
클라이언트 장치(300)는 여전히 세션을 제어하고 있고;
서버(200)는 세션을 어느 정도 제어한다.
결과로서, 본 발명의 특정 실시예들은 경험 지연 및 네트워크 트래픽을 감소시킨다.
특정 실시예들에서, HTTP 스트리밍 솔루션을 통해 푸시 기반 적응 HTTP 스트리밍을 가능하게 하는 프레임 프로토콜이 정의된다. 프레임 프로토콜은 클라이언트 장치들(300)이 서버에 명령을 전송하여 스트리밍 세션 동안 속도 적응 작업들을 수행하도록 할 수 있다.
도 8은 본 발명의 실시예들에 따른 웹소켓 지원 네트워크를 도시한다. 도 8에 도시된 웹소켓 지원 네트워크(800)의 실시예는 단지 예시를 위한 것이다. 본 발명의 범위에서 벗어나지 않고 다른 실시예들이 사용될 수 있다.
웹소켓 지원 네트워크(800)는 원 서버(origin server)(805), 하나 이상의 컨텐트 전송 네트워크(CDN) 프록시 서버(810), 및 다수의 클라이언트 장치(815)를 포함한다. 원 서버(805)는 서버(200)와 동일하거나 유사하게 구성될 수 있다. 하나 이상의 CDN 프록시 서버(810)는 서버(200)와 동일하거나 유사하게 구성될 수 있다. 클라이언트 장치들(815) 중 하나 이상은 클라이언트 장치(300)와 동일하거나 유사하게 구성될 수 있다. CDN 프록시 서버(810)는 인터넷(820)을 통해 원 서버(805)와 통신한다. 인터넷(820)은 네트워크(102)와 동일하거나 유사할 수 있다. 클라이언트 장치(815a)는 클라이언트 장치(815a)가 원 서버(805)로부터 컨텐트를 수신할 수 있는 CDN 프록시 서버(810a)와의 통신 연결을 확립한다. 클라이언트 장치(815b)는 클라이언트 장치(815b)가 원 서버(805)로부터 컨텐트를 수신할 수 있는 CDN 프록시 서버(810b)와의 통신 연결을 확립한다. 클라이언트 장치(815c)는 클라이언트 장치(815c)가 원 서버(805)로부터 컨텐트를 수신할 수 있는 CDN 프록시 서버(810b)와의 통신 연결을 확립한다. 도 8에 도시된 예에서, 웹소켓은 CDN으로부터 클라이언트에 컨텐트를 스트리밍하는 마지막 홉에서 사용된다. 즉, 클라이언트 장치(815b) 또는 클라이언트 장치(815c), 또는 둘 다는 원 서버(805)에 CDN 프록시 서버(815b)를 통한 각각의 연결을 통해 웹소켓(825)을 통한 적응 HTTP를 확립한다.
특정 실시예들에서, 클라이언트 장치(815b)는 우선 원 서버(805) 또는 CDN 프록시 서버(810b)가 웹소켓을 통해 미디어 스트리밍을 지원하는지 여부를 검출한다. 실시예들은 클라이언트 장치(815b)에 대하여, 또는 추가적으로 클라이언트 장치(815b)를 포함하여 도시했지만, 클라이언트 장치(815c) 또는 클라이언트 장치(815a)에 대한 스트리밍에 상응하는 실시예들이 본 발명의 범위에서 벗어나지 않고 사용될 수 있다. 제1 장치가 원 서버(805) 또는 CDN 프록시 서버(810b)를 결정하면, 클라이언트 장치(815b)는 CDN 프록시 서버(810b)를 통해 원 서버(805)에 대해 웹 소켓 연결을 확립하고 스트림에서의 위치 및 선택된 리프레젠테이션을 표시하는 초기 요청을 제출한다. 이후, 클라이언트 장치(815b)는 원 서버(805)에 의해 푸시되는 미디어 세그먼트들을 순차적으로 수신한다. 이 프로세스는 클라이언트 장치(815b)가
대안적인 리프레젠테이션을 선택하거나 대안적인 리프레젠테이션으로 전환하기로 결정하고;
트릭 모드 작업들을 수행하기로 결정하고;
매니페스트 파일 업데이트 또는 클라이언트 작업을 필요로 하는 그것의 표시를 수신하고;
스트림의 종료 또는 서비스 표시의 종료를 수신하고;
다음 세그먼트에 대한 요청을 전송하기 위해 서버로부터 요청을 수신할 때까지 계속된다.
클라이언트 장치(815b) 결정 또는 수신을 기반으로 하여, 클라이언트(815b)는 어떤 명령을 생성하여 원 서버(805)에 제출할 지 결정한다.
도 9는 본 발명의 실시예들에 따른 클라이언트 장치에 웹소켓을 이용하는 적응 HTTP 스트리밍 프로세스(900)를 도시한다. 흐름도는 순차적인 일련의 단계들을 도시하지만, 명시적으로 언급하지 않는 한, 성능의 특정 순서, 중복 방식으로 또는 동시에 보다는 순차적으로 단계들 또는 그의 부분들의 성능, 또는 개입 또는 중간 단계들의 발생 없이 독점적으로 도시되는 단계들의 성능에 관한 시퀀스로부터 어떠한 추론도 도출되어서는 안된다. 도시된 예에 도시된 프로세스는 예를 들어 클라이언트 장치의 처리 회로에 의해 구현된다.
블록 905에서, 클라이언트 장치(300)는 서버(200)가 웹소켓을 지원한다는 표시를 수신한다. 서버(200)는 서버(200)가 클라이언트 장치(300)에 미디어 스트리밍 세션을 제공하기 위해 웹소켓으로 업그레이드하고자 한다는 것을 클라이언트 장치(300)에 표시한다. 클라이언트 장치(300)에 대한 연결을 확립한 후에, 서버(200)는 블록 910에서 세그먼트에 대한 초기 요청을 수신한다. 클라이언트 장치(300)는 리프레젠테이션 및 위치를 선택하기 위해 서버(200)에 명령 또는 요청을 전송한다. 서버(200)는 프레임에서 세그먼트를 캡슐화하고 이를 전송한다. 블록 915에서, 클라이언트 장치(300)는 서버(200)로부터 세그먼트들을 수신한다. 서버(200)는 클라이언트 장치(300)에 의해 결정이 요구되거나 새로운 명령이 수신될 때까지, 예를 들어 세그먼트 수를 하나씩 증가시킴으로써, 다음의 세그먼트들을 지속적으로 전송한다. 즉, 블록 920에서, MPD 파일 업데이트를 사용할 수 있을 때와 같이, 작업이 요구되는 것으로 표시되거나 명령이 전송된다. 블록 920에서 필요로 하는 작업이 없다면, 클라이언트 장치(300)는 예를 들어, 블록 915로 돌아감으로써 세그먼트들을 계속 수신한다. 블록 910에서 작업이 필요하다면, 클라이언트 장치(300)는 블록 925에서 세션을 종료할지 여부를 결정한다. 클라이언트 장치(300)가 블록 925에서 세션을 종료하지 않기로 결정하는 경우, 클라이언트 장치(300)는 블록 910에서 서버에 또 다른 명령을 전송하여 리프레젠테이션 및 위치를 선택한다. 대안적으로, 클라이언트 장치(300)가 블록 925에서 세션을 종료하기로 결정하는 경우, 클라이언트 장치(300)는 블록 930에서 세션을 종료하거나 또 다른 서버로 전환한다.
도 10은 본 발명의 실시예들에 따른 서버에 대해 웹소켓을 이용하는 적응 HTTP 스트리밍 프로세스(1000)를 도시한다. 흐름도는 순차적인 일련의 단계들을 도시하지만, 명시적으로 언급하지 않는 한, 성능의 특정 순서, 중복 방식으로 또는 동시에 보다는 순차적으로 단계들 또는 그의 부분들의 성능, 또는 개입 또는 중간 단계들의 발생 없이 독점적으로 도시되는 단계들의 성능에 관한 시퀀스로부터 어떠한 추론도 도출되어서는 안된다. 도시된 예에 도시된 프로세스는 예를 들어 서버의 처리 회로에 의해 구현된다.
블록 1005에서, 서버(200)는 서버(200)가 클라이언트 장치(300)에 미디어 스트리밍 세션을 제공하기 위해 웹소켓으로 업그레이드하고자 한다는 것을 클라이언트(300)에 표시한다. 클라이언트 장치(300)가 서버(200)가 웹소켓들을 지원한다는 표시를 수신한 후에, 서버(200)는 블록 1010에서 클라이언트 장치(300)와 수신 웹소켓 연결을 확립한다. 클라이언트 장치(300)에 대한 연결을 확립한 후에, 서버(200)는 블록 1015에서 세그먼트에 대한 요청, 또는 초기 명령을 수신한다. 즉, 리프레젠테이션 및 위치를 선택하기 위해 서버(200)에 명령 또는 요청을 전송하는 클라이언트 장치(300)에 응답하여, 서버(200)는 프레임에서 세그먼트를 캡슐화하여 클라이언트 장치(300)에 세그먼트를 전송함으로써 스트리밍 명령을 처리한다. 블록 1020에서, 서버(200)는 클라이언트 장치(300)에 다음 세그먼트를 전송한다. 서버(200)는 클라이언트 장치(300)에 의해 결정이 요구되거나 새로운 명령이 수신될 때까지, 세그먼트 수를 하나씩 증가시키는 것과 같이, 다음의 세그먼트들을 전송한다. 즉, 블록 1025에서, 서버(200)는 MPD 파일 업데이트를 사용할 수 있을 때와 같이, 클라이언트 작업이 필요한지 여부를 결정한다. 블록 1025에서 필요한 작업이 없다면, 서버(200)는 예를 들어, 블록 1020으로 돌아감으로써 세그먼트들을 계속 전송한다. 블록 1025에서 클라이언트 장치 작업이 필요하다면, 블록 1030에서 서버(200)는 MPD 파일 업데이트를 사용할 수 있을 때와 같이, 각각의 작업을 표시하는 명령(200)을 클라이언트 장치(300)에 전송한다.
특정 실시예들에서, 웹소켓을 통한 적응 HTTP 스트리밍은 웹소켓 프로토콜의 하위 프로토콜로서 구현된다. 명령들은 웹소켓 프레임 헤더에서 확장 데이터로 정의된다. 다음은 클라이언트 장치(300)에서 서버(200)로의 가능한 명령들이다:
아마도 초기(init) 세그먼트 및 특정 세그먼트 수로부터 시작하는 특정 리프레젠테이션에서의 데이터 스트리밍 요청. 요청은 제1 세그먼트의 URL(uniform resource locator)이거나 프레젠테이션 식별자, 리프레젠테이션 식별자, 및 시작 세그먼트 수일 수 있다;
서버로부터의 스트리밍 중지 요청.
다음은 서버(200)에서 클라이언트 장치(300)로의 가능한 명령들이다:
MPD 업데이트에 대한 정보;
클라이언트에 전송되는 세그먼트의 식별자; 각 세그먼트는 별도로 프레임화되고, 그의 URL 또는 다른 식별 다음에 나온다;
새로운 기간 등으로 인한, 클라이언트 선택을 위한 요청. 이 명령은 클라이언트 선택이 왜 요청되는지에 대한 다른 정보뿐만 아니라 타임라인에서의 현재 위치를 포함한다; 및
너무 이른 세션 종료 또는 스트리밍 세션 종료에 대한 정보.
세그먼트 및 MPD 업데이트는 클라이언트 장치들이 각각의 세그먼트를 별도로 식별할 수 있도록 프레임화된다. 세그먼트들은 각각의 무비 프래그먼트가 고유 프래그먼트로서 전송되도록 프래그먼트화될 수 있다.
HTTP/2 및 웹소켓을 통한 DASH
새로운 프로토콜 HTTP/2 및 웹소켓의 완전한 잠재력을 이용하기 위해서, DASH 어플리케이션들은 업그레이드된 연결 위에서 사용할 새로운 하위 프로토콜을 정의해야 한다. 이 경우의 하위 프로토콜은 HTTP 1.1 기능과 동등함을 의미하기 때문에 HTTP/2는 웹소켓보다 더 많은 기능을 정의하므로, HTTP/2의 경우에서는 더 적은 작업이 수행될 필요가 있다.
본 발명의 특정 실시예들은 DASH 어플리케이션에 사용할 수 있도록 하는 기능을 도시한다:
DASH 클라이언트 장치는 서버에 대한 요청의 양을 최소화할 수 있다;
DASH 클라이언트 장치는 프롬프트 속도 적응을 할 수 있다;
DASH 클라이언트 장치는 컨텐트가 즉각적으로 생성되고 있는 라이브 스트리밍의 경우에서와 같이 지연을 최소화할 수 있다;
DASH/웹 서버는 플레이백에 대한 그들의 중요성을 기반으로 하여 상이한 리프레젠테이션으로부터의 데이터를 우선 순위화할 수 있다.
이러한 타겟들을 기반으로 하여, HTTP/2 및 웹 소켓에 대한 새로운 하위 프로토콜들이 정의된다.
웹소켓에 대한 DASH 하위 프로토콜
하위 프로토콜은 "dash"라는 이름에 의해 식별된다. DASH 스트리밍을 위해 웹소켓을 사용하길 바라는 클라이언트 장치는 프로토콜 업그레이드 요청과 함께 Sec-웹소켓-프로토콜 헤더 필드의 일부로서 키워드 "dash"를 포함한다.
웹소켓에 대한 프로토콜의 성공적인 업그레이드 후에, 클라이언트 및 서버는 DASH 데이터 프레임(연산 코드 '텍스트' 또는 '이진수' 또는 이들의 모든 '계속' 프레임)을 교환한다. DASH 프레임 형식은 다음과 같이 정의된다:
Figure pct00001
STREAM_ID: 8 비트는 동일한 웹소켓 연결을 통해 다중 요청/응답을 다중 처리할 수 있는 현재 스트림의 식별자이다.
CMD_CODE: 8 비트는 이러한 요청/응답에 의해 전송되는 DASH 명령을 표시한다. 다음의 명령들이 현재 정의된다:
CMD_CODE 설명 필요한 매개변수
0 표시된 URL에 의해 식별되는 MPD를 얻음. 웹소켓 세션을 통해 현재의 DASH의 기초로 페치되고 사용될 MPD의 URL.
jason 매개변수는 "url"이다.
1 MPD 또는 MPD 업데이트(MPD 요청에 대한 응답으로서 전송되거나 푸시됨). MPD 리소스에 대한 모든 HTTP 엔티티 헤더.
2 하나의 세그먼트를 얻음. json 매개변수 "url"에 의해 식별된, 요청되는 세그먼트의 URL.
3 초기 세그먼트로 시작하는 특정 리프레젠테이션의 모든 세그먼트를 얻은 후 주어진 세그먼트 또는 타임스탬프로부터 시작하는 미디어 세그먼트를 얻음. - 매개변수 "repid"로서의 리프레젠테이션의 식별자.
- 매개변수 "segnum"에 의해 식별된, 스트리밍을 시작하는 세그먼트 수.
- 대안적으로, "타임스탬프"에 의해 식별된, 스트리밍을 시작하는 타임 스탬프.

대안적으로:
- 하나의 탬플릿 매개변수인 세그먼트 수를 포함하는 세그먼트 URL 탬플릿.
json 매개변수는 "탬플릿"이다.
- "segnum"에 의해 식별된, 스트리밍이 시작하는 시작 세그먼트 수.
4 세그먼트 요청에 대한 응답.
여기서, 헤더는 제1 프레임의 모든 HTTP 헤더들을 포함한 후 세그먼트로부터의 페이로드를 포함한다. 플래그 F 필드가 "1xx"로 설정되면, 응답의 데이터는 낮은 지연의 경우를 지원하기 위해 순서가 뒤바뀔 수 있다. 다른 2비트는 프레임이 순서가 뒤바뀐 데이터를 포함한다는 것을 표시하기 위해 사용될 수 있다.		 - json에서 인코딩된 엔티티 본체 매개변수.
5 현재의 리소스 전송 취소. 이것은 서버가 STREAM_ID에 의해 식별된 스트림에서 현재의 리소스 전송을 중지하도록 한다. 미디어 세그먼트에 대해, 서버는 타당한 지점 예를 들어, 무비 프래그먼트의 끝에서 전송을 중지할 수 있다. 필요한 매개변수 없음.
6 결정하기 위한 요청. 서버가 클라이언트를 대신하여 결정할 수 없을 때 서버가 스트리밍을 계속할 수 없음을 클라이언트에 통지하기 위해 이 요청이 클라이언트에 서버에 의해 전송된다. 서버에 의한 자율 스트리밍이 중지될 시간 인스턴스 또는 세그먼트 수.
F: 3 비트 - - 이 필드는 명령을 기반으로 하여 설정되고 해석되는 플래그들의 집합을 제공한다.
EXT_LENGTH: 13 비트 - - 어플리케이션 데이터 앞에 있는 확장 데이터의 길이를 바이트 단위로 제공한다.
HTTP/2에 대한 DASH 하위 프로토톨
전술한 바와 같이, HTTP/2는 HTTP 1.1 프로토콜과 등등한 하위 프로토콜을 제공하는 웹 소켓의 상위 집합으로 간주될 수 있다. 웹 소켓 DASH 하위 프로토콜에 대해 제안되는 기능의 몇 가지는 PUSH_PROMISE 프레임들을 사용하여 클라이언트에 데이터를 푸시하고 특정 스트림에서 현재의 전송을 취소하는 복수의 스트림에 대한 지원과 같이 이미 HTTP/2 프로토콜에 의해 제공되고 있다.
HTTP/2의 이전 버전과의 호환성을 유지하기 위해, DASH 하위 프로토콜은 DASH 관련 정보 및 명령들을 전달하는 HEADERS 프레임들을 사용한다. 이 목적을 위해, 쉼표로 분리된 이름=값 쌍의 집합을 전달하는 새로운 헤더 필드가 정의된다. DASH 헤더 필드는 "Dash"라고 불린다. 다음의 명령들이 소개된다:
(a) DASH 하위 프로토콜의 지원 협상;
(b) 특정 리프레젠테이션의 지속적인 스트리밍 요청;
(c) 클라이언트 결정 요청; 및
(d) MPD 업데이트 통보.
본 발명은 예시적인 실시예로 설명하였지만, 다양한 변경예 및 수정예들이 당업자에게 제안될 수 있다. 본 발명은 첨부된 청구 범위 내에 이러한 변경예 및 수정예들을 포함하도록 의도된다.

Claims (16)

  1. 장치로서,
    서버와의 통신 연결을 확립하도록 구성된 인터페이스; 및
    웹소켓을 통해 적응 하이퍼텍스트 전송 프로토콜(HTTP) 스트리밍을 지원하는 상기 서버의 능력을 결정하고;
    상기 HTTP 스트리밍 시 스트리밍 작업들을 수행하도록 상기 서버에 명령을 전송하고; 및
    상기 스트리밍 세션에서 상기 서버로부터의 정보를 수신하도록 구성된 처리 회로를 포함하는 장치.
  2. 제1항에 있어서,
    상기 처리 회로는 트리거 이벤트가 발생할 때까지 미디어 세그먼트들을 수신하도록 구성되는 장치.
  3. 제2항에 있어서,
    상기 트리거 이벤트는 대역폭 측정에서의 변화, 매니페스트(manifest) 파일의 업데이트를 사용할 수 있다는 상기 서버에 의한 표시, 하나 이상의 리프레젠테이션에 대한 상기 서버에 의한 추천 중 하나를 포함하고, 상기 처리 회로는 상기 처리 회로에 의해 요구되는 작업에 대한 표시를 수신하고, 상기 처리 회로는 스트림 종료 또는 서비스 종료를 수신하는 장치.
  4. 제2항에 있어서,
    스트림 종료 또는 서비스 종료 중 하나를 수신하는 단계에 응답하여, 상기 처리 회로는 상기 HTTP 스트리밍의 종료 또는 또 다른 서버로의 전환 중 적어도 하나를 수행하도록 구성되는 장치.
  5. 제2 항에 있어서,
    상기 트리거 이벤트에 응답하여, 상기 처리 회로는 상기 서버에 명령을 전송하도록 구성되는 장치.
  6. 제2항에 있어서,
    상기 트리거 이벤트에 응답하여, 상기 처리 회로는,
    대안적인 리프레젠테이션을 선택하거나 트릭 모드 작업들을 수행하도록 구성되는 장치.
  7. 서버로서,
    적어도 하나의 클라이언트 장치에 결합하도록 구성된 인터페이스; 및
    웹소켓을 통해 적응 하이퍼텍스트 전송 프로토콜(HTTP) 스트리밍이 지원된다는 표시를 상기 적어도 하나의 클라이언트 장치에 전송하고;
    상기 HTTP 스트리밍 시 스트리밍 작업들을 수행하기 위해 상기 적어도 하나의 클라이언트 장치로부터 수신된 명령에 응답하여 상기 적어도 하나의 클라이언트 장치와 수신 웹소켓의 연결을 확립하도록 구성된 처리 회로를 포함하는 서버.
  8. 제7항에 있어서,
    상기 처리 회로는,
    상기 HTTP 스트리밍 시 스트리밍 작업들을 수행하기 위해 명령들을 수신하여 처리하고;
    상기 적어도 하나의 클라이언트 장치에 미디어 세그먼트를 전송하도록 구성되는 서버.
  9. 제7항에 있어서,
    상기 처리 회로는,
    트리거 이벤트가 발생할 때까지 미디어 세그먼트들을 계속 전송하도록 구성되는 서버.
  10. 제9항에 있어서,
    상기 트리거 이벤트는,
    대역폭 측정에서의 변화;
    매니페스트 파일의 업데이트를 사용할 수 있다는 결정; 또는
    상기 적어도 하나의 클라이언트 장치로부터 수신된 명령, 및 하나 이상의 리프레젠테이션에 대한 상기 서버에 의한 추천을 상기 적어도 하나의 클라이언트 장치에 전송하기 위한 결정 중 하나를 포함하는 서버.
  11. 제10항에 있어서,
    상기 처리 회로는,
    추가 작업이 상기 적어도 하나의 클라이언트 장치에 의해 요구될 때를 결정하도록 구성되고, 상기 트리거 이벤트는 추가 작업이 상기 적어도 하나의 클라이언트 장치에 의해 요구된다는 결정을 포함하는 서버.
  12. 제10항에 있어서,
    상기 처리 회로는,
    스트림 종료 또는 서비스 종료 중 하나를 전송하도록 구성되는 서버.
  13. 제7항에 있어서,
    상기 처리 회로는,
    또 다른 세그먼트에 대한 요청을 전송하기 위해 상기 적어도 하나의 클라이언트 장치에 요청을 전송하도록 구성되는 서버.
  14. 클라이언트 장치를 위한 방법으로서,
    상기 방법은,
    서버와의 통신 연결을 확립하는 단계;
    웹소켓을 통해 적응 하이퍼텍스트 전송 프로토콜(HTTP) 스트리밍을 지원하는 상기 서버의 능력을 결정하는 단계;
    HTTP 스트리밍 시 스트리밍 작업들을 수행하기 위해 상기 서버에 명령을 전송하는 단계; 및
    상기 스트리밍 세션에서 상기 서버로부터의 정보를 수신하는 단계;를 포함하는 방법.
  15. 제14항에 있어서,
    트리거 이벤트가 발생할 때까지 미디어 세그먼트들을 수신하는 단계를 더 포함하고,
    상기 트리거 이벤트는,
    대역폭 측정에서의 변화;
    매니페스트 파일의 업데이트를 사용할 수 있다는 상기 서버에 의한 표시;
    하나 이상의 리프레젠테이션에 대한 상기 서버에 의한 추천;
    다음 세그먼트에 대한 요청을 전송하기 위해 상기 서버로부터 수신된 요청을 수신하는 단계;
    상기 클라이언트 장치에 의해 요구되는 작업에 대한 표시를 수신하는 단계;
    스트림 종료 또는 서비스 종료를 수신하는 단계; 또는
    다음 세그먼트에 대한 요청을 전송하기 위해 상기 서버로부터 요청을 수신하는 단계 중 하나를 포함하는 방법.
  16. 제15항에 있어서,
    상기 방법은,
    스트림 종료 또는 서비스 종료 중 하나를 수신하는 단계에 응답하여, 상기 HTTP 스트리밍을 종료하는 단계 또는 또 다른 서버로 전환하는 단계 중 적어도 하나; 또는
    상기 트리거 이벤트에 응답하여, 상기 서버에 명령을 전송하는 단계, 대안적인 리프레젠테이션을 상기 클라이언트 장치에 의해 선택하는 단계, 또는 트릭 모드 작업들을 상기 클라이언트 장치에 의해 수행하는 단계 중 적어도 하나를 더 포함하는 방법.
KR1020167029356A 2014-03-20 2015-03-20 Http 스트리밍을 사용하는 dash 스트리밍을 위한 방법 및 장치 KR20160135811A (ko)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201461968204P 2014-03-20 2014-03-20
US61/968,204 2014-03-20
US201462008904P 2014-06-06 2014-06-06
US62/008,904 2014-06-06
US14/661,668 2015-03-18
US14/661,668 US20150271233A1 (en) 2014-03-20 2015-03-18 Method and apparatus for dash streaming using http streaming
PCT/KR2015/002728 WO2015142102A1 (en) 2014-03-20 2015-03-20 Method and apparatus for dash streaming using http streaming

Publications (1)

Publication Number Publication Date
KR20160135811A true KR20160135811A (ko) 2016-11-28

Family

ID=54144976

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020167029356A KR20160135811A (ko) 2014-03-20 2015-03-20 Http 스트리밍을 사용하는 dash 스트리밍을 위한 방법 및 장치

Country Status (4)

Country Link
JP (1) JP2017517221A (ko)
KR (1) KR20160135811A (ko)
CN (1) CN106416198A (ko)
WO (1) WO2015142102A1 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190030039A (ko) * 2017-09-13 2019-03-21 한화테크윈 주식회사 웹소켓을 이용하여 중간 서버를 경유하는 미디어 스트리밍 방법
CN113938475A (zh) * 2021-12-16 2022-01-14 深圳市大头兄弟科技有限公司 一种数据传输方法
US20220174521A1 (en) * 2019-05-31 2022-06-02 Apple Inc. Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110830541B (zh) * 2018-08-14 2021-07-16 华为技术有限公司 一种消息处理方法、装置及系统
CN109413187A (zh) * 2018-11-01 2019-03-01 中国科学院计算机网络信息中心 一种通用的图数据在线交互式浏览分析方法
CN111447262A (zh) * 2020-03-23 2020-07-24 北京达佳互联信息技术有限公司 请求发送方法及客户端、存储介质

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6704790B1 (en) * 1998-09-16 2004-03-09 Microsoft Corporation Server-side stream switching
US7392316B2 (en) * 2003-06-30 2008-06-24 Microsoft Corporation Client to server streaming of multimedia content using HTTP
US8806050B2 (en) * 2010-08-10 2014-08-12 Qualcomm Incorporated Manifest file updates for network streaming of coded multimedia data
US20130294747A1 (en) * 2011-01-14 2013-11-07 Sharp Kabushiki Kaisha Content playing device, content playing method, distribution system, content playing program, recording medium, and data structure
US20120207088A1 (en) * 2011-02-11 2012-08-16 Interdigital Patent Holdings, Inc. Method and apparatus for updating metadata
EP2685742A4 (en) * 2011-04-07 2014-03-05 Huawei Tech Co Ltd METHOD, DEVICE AND SYSTEM FOR SENDING AND PROCESSING MEDIA CONTENT
WO2013098317A1 (en) * 2011-12-29 2013-07-04 Koninklijke Kpn N.V. Network-initiated content streaming control
CN104412601B (zh) * 2012-06-29 2018-04-27 阿沃森特亨茨维尔有限责任公司 容纳多种不同视频压缩技术的单个kvm客户端的系统和方法

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20190030039A (ko) * 2017-09-13 2019-03-21 한화테크윈 주식회사 웹소켓을 이용하여 중간 서버를 경유하는 미디어 스트리밍 방법
US20220174521A1 (en) * 2019-05-31 2022-06-02 Apple Inc. Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring
US12022306B2 (en) * 2019-05-31 2024-06-25 Apple Inc. Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring
CN113938475A (zh) * 2021-12-16 2022-01-14 深圳市大头兄弟科技有限公司 一种数据传输方法
CN113938475B (zh) * 2021-12-16 2022-03-29 深圳市大头兄弟科技有限公司 一种数据传输方法

Also Published As

Publication number Publication date
WO2015142102A1 (en) 2015-09-24
CN106416198A (zh) 2017-02-15
JP2017517221A (ja) 2017-06-22

Similar Documents

Publication Publication Date Title
US20150271233A1 (en) Method and apparatus for dash streaming using http streaming
JP6918910B2 (ja) メディアデータの提供方法、メディアデータの受信方法、及びプログラム
US8732274B2 (en) Method and apparatus for generating and handling streaming media quality-of-experience metrics
KR20160135811A (ko) Http 스트리밍을 사용하는 dash 스트리밍을 위한 방법 및 장치
EP2962435B1 (en) Link-aware streaming adaptation
CN107743698B (zh) 用于多路径媒体传递的方法和装置
EP2805471B1 (en) Method and apparatus for enabling pre-fetching of media
US11477257B2 (en) Link-aware streaming adaptation
US20090125634A1 (en) Network media streaming with partial syncing
US20150271231A1 (en) Transport accelerator implementing enhanced signaling
WO2015134649A1 (en) Systems and methods for media format substitution
JP7307211B2 (ja) クライアント、サーバ、受信方法及び送信方法
US10044831B2 (en) Method and apparatus for transmitting messages to a dash client
CN117596232A (zh) 流媒体快速启动方法、装置和系统
WO2016018572A1 (en) Systems and methods for selective transport accelerator operation
US11082474B2 (en) Data buffering method and apparatus in adaptive streaming service
JP6059820B2 (ja) 低レイテンシ・ストリーミング
CN110881018B (zh) 媒体流的实时接收方法及客户端
KR102237900B1 (ko) 클라이언트 단말에 의해 멀티미디어 콘텐츠의 콘텐츠 부분을 검색하기 위한 방법