KR20230002784A - 오디오 및/또는 비디오 콘텐츠 전송을 위한 방법 및 서버 - Google Patents

오디오 및/또는 비디오 콘텐츠 전송을 위한 방법 및 서버 Download PDF

Info

Publication number
KR20230002784A
KR20230002784A KR1020227040021A KR20227040021A KR20230002784A KR 20230002784 A KR20230002784 A KR 20230002784A KR 1020227040021 A KR1020227040021 A KR 1020227040021A KR 20227040021 A KR20227040021 A KR 20227040021A KR 20230002784 A KR20230002784 A KR 20230002784A
Authority
KR
South Korea
Prior art keywords
audio
video content
client device
cache server
chunks
Prior art date
Application number
KR1020227040021A
Other languages
English (en)
Inventor
기욤 비쇼
피에르-쟝 게리
뱅상 리샤르
스쿠아흐넥 니콜라스 르
Original Assignee
브로드피크
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 브로드피크 filed Critical 브로드피크
Publication of KR20230002784A publication Critical patent/KR20230002784A/ko

Links

Images

Classifications

    • 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/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64723—Monitoring of network processes or resources, e.g. monitoring of network load
    • H04N21/64738—Monitoring network characteristics, e.g. bandwidth, congestion level
    • 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/637—Control signals issued by the client directed to the server or network components
    • H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0864—Round trip delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/2183—Cache memory
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2368—Multiplexing of audio and video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26208—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints
    • H04N21/26233—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists the scheduling operation being performed under constraints involving content or additional data duration or size, e.g. length of a movie, size of an executable file
    • 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/637—Control signals issued by the client directed to the server or network components
    • 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/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64746—Control signals issued by the network directed to the server or the client
    • H04N21/64761—Control signals issued by the network directed to the server or the client directed to the server
    • H04N21/64769—Control signals issued by the network directed to the server or the client directed to the server for rate control
    • 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/647—Control signaling between network components and server or clients; Network processes for video distribution between server and clients, e.g. controlling the quality of the video stream, by dropping packets, protecting content from unauthorised alteration within the network, monitoring of network load, bridging between two different networks, e.g. between IP and wireless
    • H04N21/64746—Control signals issued by the network directed to the server or the client
    • H04N21/64761—Control signals issued by the network directed to the server or the client directed to the server
    • H04N21/64776—Control signals issued by the network directed to the server or the client directed to the server for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • 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
    • 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)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Databases & Information Systems (AREA)
  • Environmental & Geological Engineering (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)
  • Reverberation, Karaoke And Other Acoustics (AREA)

Abstract

적응형 스트리밍을 사용하여 캐시 서버로부터 클라이언트 디바이스로 오디오 및/또는 비디오 콘텐츠를 전송하기 위해, 오디오 및/또는 비디오 콘텐츠는 제각기의 오디오 및/또는 비디오 품질을 갖는 다양한 표현으로 이용 가능한 데이터 세그먼트들로 분할되고, 이들 표현들은 세그먼트마다 시간 정렬되며, 세그먼트들은 청크들로 추가로 분할되며, 방법은, 캐시 서버와 클라이언트 디바이스 사이에 적용 가능한 왕복 시간 값을 획득하는 단계; 오디오 및/또는 비디오 콘텐츠의 다양한 표현의 최대 평균 비트레이트와 획득된 왕복 시간 값으로부터 최소 벌크 전송 크기를 계산하는 단계; 오디오 및/또는 비디오 콘텐츠에 대해, 클라이언트 디바이스에 전송될 표현에 대한 최소 벌크 지속시간을 계산하는 단계; 및 오디오 및/또는 비디오 콘텐츠를, 계산된 최소 벌크 지속시간에 따라 각각의 세그먼트마다 집성된 연속적인 청크들의 벌크의 형태로 버스트 전송에 의해 전송하는 단계를 포함한다.

Description

오디오 및/또는 비디오 콘텐츠 전송을 위한 방법 및 서버
본 발명은 일반적으로 적응형 스트리밍이라고 지칭되기도 하는 적응형 비트레이트를 사용하여 서버 장비로부터 클라이언트 디바이스로 오디오 및/또는 비디오 콘텐츠를 전송하는 것에 관한 것이다.
HTTP("Hypertext Transfer Protocol") 적응형 스트리밍에서, 클라이언트 디바이스는 재생할 오디오 및/또는 비디오 스트림(라이브 콘텐츠) 또는 파일(주문형 비디오 콘텐츠)의 일부(이는 세그먼트로 지칭됨)를 요청하기 위해 서버 장비와 상호작용한다. 오디오 및/또는 비디오 스트림 또는 파일은 표현(representation)이라고 지칭되는 여러 가지의 품질로 인코딩된다. 그 표현들 각각은 오디오 및/또는 비디오 콘텐츠와 관련하여 동일한 지속시간의 연속적인 세그먼트들로 구성된다. 따라서, 그 표현들은 세그먼트마다 시간 정렬되고, 동일한 오디오 및/또는 비디오 참조 프레임으로 시작하여, 클라이언트 디바이스가, 더 구체적으로는 클라이언트 디바이스에 포함된 오디오 및/또는 비디오 플레이어가, 세그먼트 경계 상에서 한 표현에서 다른 표현으로 전환할 수 있게 한다.
HLS(HTTP에 기반한 것이며 Apple Inc.에 의해 개발된 라이브 스트리밍 통신 프로토콜인"HTTP 라이브 스트리밍"을 나타냄) 또는 DASH(동영상 전문가 그룹(MPEG: Moving Picture Experts Group)에 의해 개발된 멀티미디어 스트리밍 기술인 "HTTP를 통한 동적 적응형 스트리밍"을 나타냄)와 같은 적응형 스트리밍 기술에서는, 하나의 표현에서 다른 표현으로의 전환은 클라이언트 디바이스에 의해 구동되는데, 이는 클라이언트 디바이스가 서버 장비에 상기 다른 표현으로 전환하도록 요청한다는 것을 의미한다. 일반적으로, 클라이언트 디바이스는 서버 장비에서 클라이언트 디바이스까지의 이용 가능한 대역폭의 평가와 가능성이 있는 기타 기준, 예컨대, 버퍼 점유도, 스크린 해상도, 디코더 기능 등에 기반하여 적절한 표현을 선택한다.
MPEG 공통 미디어 애플리케이션 포맷(CMAF: Common Media Application Format) 또는 저지연 HLS(LL HLS: Low Latency HLS)를 이용한 청크 전송 인코딩(CTE: Chunked Transfer Encoding)과 같은 라이브 스트리밍을 위한 새로운 저지연 기술을 사용하면, 재생을 시작하기 전에 전체 세그먼트를 이용할 필요가 없는 특정 청크 관리(particular chunks management)를 통해 오디오 및/또는 비디오 콘텐츠를 조기에 재생할 수 있다.
따라서, 적응형 스트리밍을 위한 콘텐츠 전송 네트워크(CDN: Content Delivery Network) 구축 시, 패키저 장비(packager equipment) 역할을 하는 발신 서버(오리진 서버라고도 함)는 캐시 서버가 관련 세그먼트를 요청할 때마다 전송할 준비가 된 청크들로 분할된 세그먼트들의 형태로 표현을 제공한다. 그 청크들은 오디오 및/또는 비디오 콘텐츠의 미리 한정된 지속시간에 대응하며, 따라서 세그먼트보다 작게 인코딩된 단위가 된다. 캐시 서버는 클라이언트 디바이스로부터 세그먼트 요청을 수신하면, 청크들을 버스트 전송으로 전송함으로써 클라이언트 디바이스에 서비스를 제공한다.
이러한 저지연 기술은 데이터 전송 속도를 높이지만, 이용 가능한 대역폭 추정 시 방해물을 생성한다. 결과적으로 부적절한 오디오 및/또는 비디오 콘텐츠 표현(품질)이 선택되어 QoE가 낮아질 수 있다.
캐시 서버로부터 클라이언트 디바이스로의 처리량은 캐시 서버로부터 클라이언트 디바이스로의 링크 용량이나 캐시 서버와 클라이언트 디바이스 사이의 왕복 시간(RTT: Round Trip Time)에 의해 제한될 수 있다.
다음과 같은 예시적인 예를 고려해보자. 비디오 콘텐츠가 3 Mbps, 2 Mbps, 및 1 Mbps의 해당 비트레이트를 갖는 세 가지 표현으로 이용 가능하게 만들어진다. 비디오 컨텐츠는 그 비디오 컨텐츠에 대해 2초의 지속시간을 갖는 세그먼트들로 분할되고, 그 비디오 컨텐츠에 대해 지속시간이 200밀리초인 청크들(세그먼트당 10개의 청크)로 더 분할된다. RTT가 100밀리초이고 최대 병목 대역폭이 8 Mbps라고 고려해보자. 클라이언트 디바이스(플레이어)가 청크 단위로 전송되는 1 Mbps 비디오 세그먼트를 요청하면, 이 세그먼트의 대역폭은 2 Mbps로 추정되지만 유효 용량은 8 Mbps가 된다.
이는, 한 청크의 전송에 해당하는 버스트 기간 동안 전송된 비트의 양을 분석하여 최대 이용 가능 대역폭을 평가하려는 클라이언트 디바이스 또는 캐시 서버가 실제 이용 가능 대역폭보다 훨씬 낮은 2 Mbps의 이용 가능 대역폭으로 잘못 추정하게 되어 (보다 높은 비트레이트를 갖는) 보다 높은 품질의 표현을 사용하지 못하게 한다는 것을 의미한다. 이 상황은 앞의 예에 나타난 것보다 확실히 더 나쁜데, 그 이유는 오디오 및/비디오 콘텐츠와 관련하여 한 세그먼트를 동일한 지속시간의 청크들로 분할하는 것은 동일한 크기(즉, 비트의 양)를 갖는 청크들을 이끌어내지 못하기 때문이다. 실제로, 비디오 콘텐츠를 고려할 때, (기존 IPB 압축 방식에 따른) I 픽처 데이터를 포함하는 청크는 이용 가능한 대역폭을 추정하기 위한 앞의 예에서 사용된 200 kbit의 평균 크기보다 확실히 큰 크기를 갖는 반면, 동일한 비디오 프레임의 다른 데이터를 포함하는 다른 청크는 보다 작은 크기를 갖는다. 이용 가능한 대역폭을 추정하기 위한 혼잡 시간 윈도우에서 어떤 청크가 고려되는지에 따라, 훨씬 더 축소된 이용 가능한 대역폭 추정치로 이어질 수 있으며, 이는 캐시 서버와 클라이언트 디바이스 사이에 네트워크 버퍼링이 있는 경우 증폭될 수도 있다.
추가로 주목될 수 있는 것은, RTT가 다를 경우, 결과적인 이용 가능한 대역폭 추정치가 다르게 되는데, 예를 들어, RTT가 10밀리초가 되는 경우, 이론상 대역폭 추정치는 20 Mbps가 되었을 것이며, 이는 실제로 8 Mbps의 최대 병목 대역폭(링크 용량)에 의해 제한된다는 것이다.
따라서, 선행 기술의 전술한 단점들을 극복하고, 적응형 비트레이트를 사용하여 서버 장비로부터 클라이언트 디바이스로 오디오 및/또는 비디오 콘텐츠를 전송할 때의 QoE를 개선하는 것이 특히 바람직하다. 또한, 구현이 간단하고 비용 효율적인 해결책을 제공하는 것도 특히 바람직하다.
이를 위해, 적응형 스트리밍을 사용하여 캐시 서버로부터 클라이언트 디바이스로 오디오 및/또는 비디오 콘텐츠를 전송하는 방법이 본원에 개시되는 바, 상기 오디오 및/또는 비디오 콘텐츠는 제각기의 오디오 및/또는 비디오 품질을 갖는 다양한 표현들로 이용 가능한 데이터 세그먼트들로 분할되고, 상기 표현들은 세그먼트마다 시간 정렬되며, 상기 세그먼트들은 청크들로 추가로 분할되며, 상기 방법은 상기 캐시 서버와 상기 클라이언트 디바이스 사이에 적용 가능한 왕복 시간 값을 획득하는 단계; 상기 오디오 및/또는 비디오 콘텐츠의 다양한 표현의 최대 평균 비트레이트와 상기 획득된 왕복 시간 값으로부터 최소 벌크 전송 크기 mTBS를 계산하는 단계; 상기 오디오 및/또는 비디오 콘텐츠에 대해, 상기 클라이언트 디바이스에 전송되어야 하는 오디오 및/또는 비디오 콘텐츠의 표현 i에 대한 최소 벌크 지속시간 mTBDi를 계산하는 단계; 및 상기 오디오 및/또는 비디오 콘텐츠를, 각각의 세그먼트마다 적어도 하나의 청크 또는 집성된 연속적인 청크들의 L개의 벌크의 형태로 버스트 전송에 의해 전송하는 단계 - 상기 L개의 벌크는 상기 세그먼트에 대응하는 오디오 및/또는 비디오 콘텐츠 데이터를 공동으로 포함함 - 를 포함하고, 각각의 세그먼트마다, 적어도 L-1개의 벌크 또는 벌크들이 각각 M개의 청크 또는 청크들로 형성되되,
Figure pct00001
및
Figure pct00002
가 되도록 형성되고,
여기서 CH j (j = 1,..,M)는 상기 오디오 및/또는 비디오 콘텐츠에 대한 청크 j의 시간 지속시간을 나타낸다. 따라서, 캐시 서버와 클라이언트 디바이스 사이에 적용 가능한 왕복 시간 값을 고려하여 한정된 벌크 지속시간을 이용하여 버스트 전송을 수행함으로써 유효 대역폭 추정이 수행될 수 있다. 결과적으로, 오디오 및/또는 비디오 콘텐츠의 표현의 적절한 선택이 이루어질 수 있고, 이는 QoE를 향상시킨다.
특정 실시형태에 따르면, 왕복 시간 값은 캐시 서버에 의해 디폴트 구성 파라미터로서 저장되고, 캐시 서버가 오디오 및/또는 비디오 콘텐츠 데이터를 임의의 클라이언트 디바이스에 전송할 때 처리해야 하는 최대 가능한 왕복 시간에 대응한다.
특정 실시형태에 따르면, 왕복 시간 값은 오디오 및/또는 비디오 콘텐츠를 클라이언트 디바이스로 전송하기 위한 세션들을 분석함으로써 시간 경과에 따라 캐시 서버에 의해 계산된 평균 왕복 시간 값이다.
특정 실시형태에 따르면, 이러한 왕복 시간 값은 최소 벌크 전송 크기 mTBS 및 최소 벌크 지속시간 mTBDi에 대한 초기 구성 및 한정으로서 사용되고, 그 후에는, 캐시 서버와 클라이언트 디바이스 사이의 왕복 시간의 측정에 따라, 최소 벌크 전송 크기 mTBS 및 최소 벌크 지속시간 mTBDi로서 동적으로 업데이트도 된다.
특정 실시형태에 따르면, 오디오 및/또는 비디오 콘텐츠를 전송하는 전체 세션에 걸쳐 동일한 왕복 시간 값이 사용된다.
특정 실시형태에 따르면, 캐시 서버가, 오디오 및/또는 비디오 콘텐츠와 관련된 재생목록 또는 매니페스트 파일(manifest file)을 획득하기 위한 요청을 클라이언트 디바이스로부터 수신할 때, 왕복 시간 값을 획득하기 위해, 캐시 서버는 클라이언트 디바이스가 해당 요청을 재전송하도록 클라이언트 디바이스를 리디렉션하고, 캐시 서버가 클라이언트 디바이스를 리디렉션한 시점부터 캐시 서버가 클라이언트 디바이스로부터 해당 요청을 다시 수신하는 시점까지의 시간 차이로서 왕복 시간 값을 계산한다.
특정 실시형태에 따르면, 캐시 서버는, 일부 세그먼트들의 지속시간이 왕복 시간 값의 함수로 정의된 바와 같은 청크들의 벌크의 지속시간과 같다는 것을 재생목록 또는 매니페스트 파일에 표시한다.
특정 실시형태에 따르면, 오디오 및/또는 비디오 콘텐츠와 관련된 매니페스트 파일은 청크가 이론적으로 이용 가능하게 되자마자 세그먼트 요청이 수행될 수 있다는 것을 표시하며, 캐시 서버는 클라이언트 디바이스로부터 수신된 세그먼트 요청의 처리를, 응답 시 전송할 벌크를 구축하기에 충분한, 요청된 세그먼트의 청크들을 캐시에서 이용 가능할 때까지, 차단한다.
프로그래머블 디바이스에 의해 실행될 때 본원의 실시형태들 중 어느 하나에서 전술한 방법을 구현하도록 프로그래머블 디바이스에 로딩될 수 있는 프로그램 코드 인스트럭션을 포함하는 컴퓨터 프로그램 제품이 본원에 추가로 개시된다. 이러한 컴퓨터 프로그램을 저장하는 정보 저장 매체가 본원에 추가로 개시된다.
적응형 스트리밍을 사용하여 오디오 및/또는 비디오 콘텐츠를 클라이언트 디바이스로 전송하도록 구성된 캐시 서버가 본원에 추가로 개시되는 바, 상기 오디오 및/또는 비디오 콘텐츠는 제각기의 오디오 및/또는 비디오 품질을 갖는 다양한 표현으로 이용 가능한 데이터 세그먼트들로 분할되고, 상기 표현들은 세그먼트마다 시간 정렬되며, 상기 세그먼트들은 청크들로 추가로 분할되며, 상기 캐시 서버는, 전자 회로부로서, 상기 캐시 서버와 상기 클라이언트 디바이스 사이에 적용 가능한 왕복 시간 값을 획득하고; 상기 오디오 및/또는 비디오 콘텐츠의 다양한 표현의 최대 평균 비트레이트와 상기 획득된 왕복 시간 값으로부터 최소 벌크 전송 크기 mTBS를 계산하고; 상기 오디오 및/또는 비디오 콘텐츠에 대해, 상기 클라이언트 디바이스에 전송되어야 하는 오디오 및/또는 비디오 콘텐츠의 표현 i에 대한 최소 벌크 지속시간 mTBDi를 계산하고; 그리고 상기 오디오 및/또는 비디오 콘텐츠를, 각각의 세그먼트마다 적어도 하나의 청크 또는 집성된 연속적인 청크들의 L개의 벌크의 형태로 버스트 전송에 의해 전송하도록 구성된, 전자 회로부를 포함하고, 상기 L개의 벌크는 상기 세그먼트에 대응하는 오디오 및/또는 비디오 콘텐츠 데이터를 공동으로 포함하고, 각각의 세그먼트마다, 적어도 L-1개의 벌크 또는 벌크들이 M개의 청크 또는 청크들로 제각기 형성되되,
Figure pct00003
및
Figure pct00004
가 되도록 형성되고,
여기서 CH j (j = 1,..,M)는 상기 오디오 및/또는 비디오 콘텐츠에 대한 청크 j의 시간 지속시간을 나타낸다.
전술한 캐시 서버를 포함하는 콘텐츠 전송 네트워크가 본원에 추가로 개시된다.
본 발명의 특징은 적어도 하나의 실시형태의 다음의 설명을 읽음으로써 보다 명확하게 나타날 것이며, 이 설명은 첨부 도면을 참조하여 제공된다.
- 도 1은 본 발명이 구현될 수 있는 오디오 및/또는 비디오 콘텐츠 전송 시스템을 개략적으로 나타낸 것이다.
- 도 2는 다양한 표현의 시간 정렬된 세그먼트를 개략적으로 나타낸 것이다.
- 도 3은 세그먼트, 청크, 및 벌크를 시간에 대해 개략적으로 나타낸 것이다.
- 도 4는 오디오 및/또는 비디오 콘텐츠 전송 시스템의 영역에서 사용 가능한 디바이스의 예시적인 하드웨어 아키텍처를 개략적으로 나타낸 것이다.
- 도 5는 특정 실시형태에서 오디오 및/또는 비디오 콘텐츠 데이터를 버스트 전송에 의해 청크들의 벌크의 형태로 전송하기 위한 알고리즘을 개략적으로 나타낸 것이다.
- 도 6은 특정 실시형태에서 세그먼트 요청을 관리하기 위한 알고리즘을 개략적으로 나타낸 것이다.
- 도 7은 다른 특정 실시형태에서 오디오 및/또는 비디오 콘텐츠 데이터를 버스트 전송에 의해 청크들의 벌크의 형태로 전송하기 위한 알고리즘을 개략적으로 나타낸 것이다.
도 1은 캐시 서버(CSERV)(130) 및 적어도 하나의 클라이언트 디바이스(CL)(140)를 포함하는 오디오 및/또는 비디오 콘텐츠 전송 시스템(100)을 개략적으로 나타낸 것이다. 오디오 및/또는 비디오 콘텐츠 전송 시스템(100)은 발신 서버(OSERV)(150)를 더 포함한다.
캐시 서버(CSERV)(130)는 통신 링크(120)를 통해 적어도 하나의 클라이언트 디바이스(CL)(140)에 적어도 하나의 오디오 및/또는 비디오 콘텐츠의 세그먼트를 전송하는 것을 담당하는 장비이다. 캐시 서버(CSERV)(130)는 단일 서버 또는 서버 클러스터일 수 있다. 캐시 서버(CSERV)(130)는 적어도 하나의 그러한 서버 장비를 포함하는 콘텐츠 전송 네트워크의 일부일 수 있다.
통신 링크(120)는 케이블 또는 일련의 케이블과 같은 물리적 링크, 또는 무선 링크일 수 있다. 통신 링크(120)는 인터넷을 통한 통신 경로와 같은 논리적 링크일 수 있다.
하나의 클라이언트 디바이스(CL)(140)가 도 1에 나타나 있지만, 오디오 및/또는 비디오 콘텐츠 전송 시스템은 일반적으로 수많은 클라이언트 디바이스를 포함한다.
발신 서버(OSERV)(150)는 청크들로 분할되는 세그먼트의 형태로 적어도 하나의 오디오 및/또는 비디오 콘텐츠를 패키징하는 것을 담당한다. 발신 서버(OSERV)(150)는 제각기의 비트레이트를 갖는 복수의 표현(품질)으로 오디오 및/또는 비디오 콘텐츠를 제공한다. 발신 서버 장비(OSERV)(150)는 단일 서버 또는 서버 클러스터일 수 있다. 캐시 서버(CSERV)(130)는 통신 링크(121)를 통해 발신 서버 장비(OSERV)(150)로부터 적어도 하나의 오디오 및/또는 비디오 콘텐츠를 획득한다.
통신 링크(121)는 케이블 또는 일련의 케이블과 같은 물리적 링크, 또는 무선 링크일 수 있다. 통신 링크(121)는 인터넷을 통한 통신 경로와 같은 논리적 링크일 수 있다.
도 2와 관련하여 이후에 개시되는 바와 같이, 표현의 품질이 높을수록 해당 비트레이트는 높아진다. 세그먼트는 임의의 하나의 오디오 및/또는 비디오 콘텐츠의 모든 표현들 사이에서 시간 정렬되어 있으므로, 가능한 최고의 QoE를 달성하기 위해 이용 가능한 대역폭 추정에 더 적합한 표현 비트레이트에 따라 한 표현에서 다른 표현으로 전환할 수 있다.
청크들은 오디오 및/또는 비디오 콘텐츠에 대해 동일한 지속시간을 갖는다. 이 청크 지속시간은 발신 서버(OSERV)(150)와 캐시 서버(CSERV)(130) 사이, 그리고 더 중요하게는 캐시 서버(CSERV)(130)와 적어도 하나의 클라이언트 디바이스(CL)(140) 사이의 최소 벌크 전송 시간 단위를 한정한다. 발신 서버(OSERV)(150)는 오디오 및/또는 비디오 콘텐츠 전송 시스템(100)이 처리할 것으로 예상되는 최소 RTT의 청크 지속시간 함수로 청크들을 생성하도록 구성된다. 예를 들어, 이 청크 지속시간은 50밀리초가 될 수 있다.
캐시 서버(CSERV)(130)가 이러한 캐시 서버가 여러 개 있는 CDN에 속할 때, 이 청크 지속시간(이는 이후의 상세한 설명에서 명백한 바와 같이 최소 벌크 전송 단위임)은 복수의 캐시 서버 또는 모든 캐시 서버에 대해 동일할 수 있거나, 캐시 서버마다 다를 수 있다.
오디오 및/또는 비디오 콘텐츠는 일반적으로 제각기의 매니페스트 파일과 함께 제공된다. 각 매니페스트 파일은 오디오 및/또는 비디오 콘텐츠와 관련되며, 오디오 및/또는 비디오 콘텐츠의 세그먼트가 이용 가능하게 만들어지는 방식, 특히 해당 오디오 및/또는 비디오 콘텐츠의 어떤 표현(품질)이 이용 가능한지를 기술한다. 주목해야 하는 것은 사용 중인 적응형 비트레이트 기술에 따라 매니페스트 파일이 재생목록 파일로 지칭될 수 있다는 것이다. 따라서, 발신 서버(OSERV)(150)는 캐시 서버(CSERV)(130)에 적용되는 이 청크 지속시간(또는 최소 벌크 전송 단위)에 따라 캐시 서버(CSERV)(130)에 첨부된 각 매니페스트 파일을 적응시킨다. 예를 들어, 저지연 MPEG DASH에서, 세그먼트 요청을 제출하기에 적절한 시점을 계산하기 위해 클라이언트 디바이스(CL)(140)에 의해 사용되는 availabilityTimeOffset이라고 지칭되는 필드에 시간 오프셋이 표시되어 있다. 클라이언트 디바이스(CL)(140)는 캐시 서버(CSERV)(130)에 의한 세그먼트 요청 제출에 해당하는 이론적 시점에서 availabilityTimeOffset의 값을 공제할 것으로 예상된다. 이 값은 전체 세션 동안 유효하며, 청크 지속시간의 함수로서 계산된다. 매니페스트 파일의 원본 소스가 무엇이든, 확실한 것은 availabilityTimeOffset 값이 캐시 서버(CSERV)(130)와 연관된 청크 지속시간(최소 벌크 전송 시간 단위)의 함수로 계산되었다는 것이다.
캐시 서버(CSERV)(130)는 적어도 하나의 클라이언트 디바이스(CL)(140)로부터 세그먼트 요청을 수신하면, 버스트 전송으로 청크들의 벌크를 전송함으로써 그 클라이언트 디바이스에 서비스를 제공한다. 이하에서 개시되는 바와 같이, 캐시 서버(CSERV)(130)는 캐시 서버(CSERV)(130)와 관련 적어도 하나의 클라이언트 디바이스(CL)(140) 사이에 적용 가능한 RTT 값에 따라 청크들을 집성함으로써 청크들의 벌크를 형성한다.
각 클라이언트 디바이스(CL)(140)는 플레이어 및 디코더를 포함한다. 디코더는 유효하게 사용 중인 인코딩 포맷 및 품질(즉, 표현)에 따라 플레이어에 의해 구성(초기화 또는 재초기화)되고, 플레이어가 수신한 오디오 및/또는 비디오 데이터에 따라 디코딩을 담당한다. 플레이어는 캐시 서버(CSERV)(130)로부터 인코딩된 오디오 및/또는 비디오 데이터를 수신하기 위해 캐시 서버 장비(CSERV)(130)와 교환을 수행하는 것을 담당한다. 플레이어는 적어도 하나의 오디오 및/또는 비디오 콘텐츠의 세그먼트를 요청하고, 캐시 서버(CSERV)(130)는 응답 시에 요청된 세그먼트를 버스트 전송으로 청크들의 벌크의 형태로 전송한다.
캐시 서버(CSERV)(130)로부터 하나의 클라이언트 디바이스(CL)(140)로 오디오 및/또는 비디오 콘텐츠를 전송하기 위한 세션을 고려하면, 이용 가능한 대역폭 평가는 캐시 서버(CSERV)(130) 및/또는 클라이언트 디바이스(CL)(140)에 의해 수행된다. 이용 가능한 대역폭 평가를 통해, 이용 가능한 대역폭 추정에 더 적합한 표현 비트레이트에 따른 오디오 및/또는 비디오 콘텐츠의 표현을 선택하여, 가능한 한 최상의 QoE를 달성할 수 있다. 예를 들어, 이용 가능한 대역폭 추정은 병목 대역폭 및 왕복 전파 시간(BBR: Bottleneck Bandwidth and Round-trip propagation time) 정보를 사용하여 수행된다. BBR 접근 방식은, 특히 무선 통신에 매우 적합하고, TCP 프로토콜 또는 다른 전송 프로토콜(예컨대, 사용자 데이터그램 프로토콜(UDP: User Datagram Protocol)을 통한 QUIC)과 관련하여 사용될 수 있는 최근의 혼잡 제어 알고리즘(congestion control algorithm)이다. 이용 가능한 대역폭 추정이 TCP CUBIC, VEGAS, RENO에서 또는 QUIC, 스트림 제어 전송 프로토콜(SCTP: Stream Control Transmission Protocol) 등과 같은 다른 전송 프로토콜에서와 같은 다른 혼잡 제어 알고리즘을 사용하여 수행되는 대안의 실시형태가 가능하다. 대안적으로, 이용 가능한 대역폭 추정은 청크들을 해당 클라이언트 디바이스(CL)(140)에 전송하는 데 사용되는 적어도 하나의 전송 접속(예컨대, TCP 접속)의 전송 프로토콜 트래픽 형태(데이터 패킷 및 확인응답 패킷)를 분석함으로써 직접 수행된다.
도 2에 도시된 바와 같이, 각 오디오 및/또는 비디오 콘텐츠는 제각기의 오디오 및/또는 비디오 품질과 함께 다양한 표현 R1, R2, R3으로 이용 가능하게 만들어진다. 오디오 및/또는 비디오 콘텐츠의 임의의 모든 표현(예컨대, R1)의 한 세그먼트는 오디오 및/또는 비디오 콘텐츠의 다른 임의의 모든 표현(예컨대, 제각기의 R2, R3)의 동일한 세그먼트와 동일한 콘텐츠 부분을 포함한다. 다시 말해서, 다양한 표현 R1, R2, R3의 세그먼트는 시간 정렬된다. 각 세그먼트는 참조 프레임 RF로 시작된다. 도 2에서, 오디오 및/또는 비디오 콘텐츠의 동일한 세그먼트를 고려하면, 표현 R1에 대한 참조 프레임 RF는 RF1로 라벨링되고, 표현 R2에 대한 참조 프레임 RF는 RF2로 라벨링되고, 표현 R3에 대한 참조 프레임 RF는 RF3으로 라벨링된다. 더욱이, 참조 프레임 RF 다음에는 세그먼트에서 적어도 하나의 후속 프레임 SF가 후속된다. 도 2에서, 표현 R1에 대한 적어도 하나의 후속 프레임 SF는 SF1로 라벨링되고, 표현 R2에 대한 적어도 하나의 후속 프레임 SF는 SF2로 라벨링되고, 표현 R3에 대한 적어도 하나의 후속 프레임 SF는 SF3으로 라벨링된다.
표현 R1, R2, R3은 서로 다른 품질에 대응하기 때문에, 임의의 모든 표현(예컨대, R1)의 한 세그먼트의 크기는 일반적으로 다른 임의의 모든 표현(예컨대, 제각기의 R2, R3)의 동일한 세그먼트의 크기와는 다르다. 실제로, 세그먼트 크기는 도 2에 도시된 바와 같이 품질에 따라 증가하며, 여기서, 표현 R1, R2, R3의 동일한 세그먼트는 개략적으로 표시되고, 표현 R3은 표현 R2보다 나은 품질에 해당하고, 표현 R2는 표현 R1보다 나은 품질에 해당하는 것으로 간주된다. 결과적으로 표현 R3 내의 참조 프레임 RF3의 크기는 표현 R2 내의 참조 프레임 RF2의 크기보다 크고, 표현 R2 내의 참조 프레임 RF2의 크기는 표현 R1 내의 참조 프레임 RF1의 크기보다 크다. 또한, 표현 R3 내의 후속 프레임 SF3의 크기는 표현 R2 내의 후속 프레임 SF2의 크기보다 크고, 표현 R2 내의 후속 프레임 SF2의 크기는 표현 R1 내의 후속 프레임 SF1의 크기보다 크다. 결과적으로, 오디오 및/또는 비디오 품질에 따라 대역폭 요건도 또한 증가한다.
도 3에 도시된 바와 같이, 오디오 및/또는 비디오 콘텐츠의 세그먼트 S를 고려하면, 해당 세그먼트 S는 오디오 및/또는 비디오 콘텐츠의 지속시간 tS를 커버한다. 세그먼트 S는 청크들로 분할된다. 세그먼트 S의 청크들 C는 더 짧은 오디오 및/또는 비디오 콘텐츠 지속시간 tC를 가지며, 이 지속 시간은 최소 벌크 전송 시간 단위를 한정한다. 따라서, 청크들 C의 벌크 B는 캐시 서버(CSERV)(130)에 의해 해당 청크들 C의 집성체로 형성되고, 따라서 오디오 및/또는 비디오 콘텐츠의 지속시간 tB에 해당한다(또한 오디오 및/또는 비디오 콘텐츠에 대한 세그먼트 S의 지속시간 tS보다 짧다). 캐시 서버(CSERV)(130)로부터 관련 클라이언트 디바이스(CL)(140)로 버스트 전송으로 전송될 벌크 B를 형성하는 집성체 내 청크들 C의 수는 캐시 서버(CSERV)(130)와 해당 클라이언트 디바이스(CL)(140) 간에 고려될 RTT 값에 따라 한정된다.
도 4는 오디오 및/또는 비디오 콘텐츠 전송 시스템(100)의 영역에서 사용될 수 있는 예시적인 하드웨어 아키텍처(400)를 개략적으로 나타낸 것이다. 하드웨어 아키텍처는 캐시 서버 장비(CSERV)(130)의 일부일 수 있다. 하드웨어 아키텍처는 발신 서버 장비(OSERV)(150)의 일부일 수 있다. 하드웨어 아키텍처는 클라이언트 디바이스(CL)(140)의 일부일 수 있다.
하드웨어 아키텍처(400)는 통신 버스(410)에 의해 상호접속된 다음의 컴포넌트, 즉 프로세서, 마이크로프로세서, 마이크로컨트롤러 또는 중앙 처리 유닛(CPU)(401); 랜덤 액세스 메모리(RAM)(402); 전기적으로 소거가능한 프로그래머블 ROM(EEPROM)과 같은 판독 전용 메모리(ROM)(403), 예를 들어, 플래시 메모리; 하드디스크 드라이브(HDD)(404), 또는 저장 매체 상에 저장된 정보를 판독하도록 적응된 임의의 다른 디바이스, 예컨대, 보안 디지털(SD) 카드 판독기; 적어도 하나의 통신 인터페이스(COM)(405)를 포함한다.
CPU(401)는 ROM(403)으로부터 또는 HDD(404) 또는 SD 카드와 같은 외부 메모리로부터 RAM(402)으로 로딩된 인스트럭션을 실행할 수 있다. 하드웨어 아키텍처(400)의 전원이 켜진 후, CPU(401)는 RAM(402)으로부터 인스트럭션을 판독하여 이들 인스트럭션을 실행할 수 있다. 인스트럭션은 CPU(401)로 하여금 캐시 서버 장비(CSERV)(130) 또는 발신 서버 장비(OSERV)(150) 또는 클라이언트 디바이스(CL)(140)에 대해 본원에 개시된 단계를 실행하게 하는 하나의 컴퓨터 프로그램을 형성한다.
따라서, 본원에 기술된 단계 및 알고리즘은, PC, 디지털 신호 프로세서(DSP), 또는 프로세서와 같은 프로그래머블 컴퓨팅 머신에 의한 인스트럭션 세트 또는 프로그램의 실행에 의해 소프트웨어 형태로 구현될 수 있거나; 또는 필드 프로그래머블 게이트 어레이(FPGA) 또는 주문형 집적 회로(ASIC)와 같은, 머신 또는 전용 컴포넌트, 칩 또는 칩셋에 의해 하드웨어 형태로 구현될 수 있다. 보다 일반적으로, 캐시 서버 장비(CSERV)(130), 발신 서버 장비(OSERV)(150), 및 클라이언트 디바이스(CL)(140)는 해당 디바이스 또는 서버에 대해 본원에 기술된 단계 및 알고리즘을 수행하도록 구성된 전자 회로부를 포함한다.
도 5는 특정 실시형태에서 오디오 및/또는 비디오 콘텐츠 데이터를 버스트 전송에 의해 청크들의 벌크의 형태로 전송하기 위한 알고리즘을 개략적으로 나타낸 것이다.
단계 501에서, 캐시 서버(CSERV)(130)는 해당 캐시 서버(CSERV)(130)와 오디오 및/또는 비디오 콘텐츠 데이터가 전송되어야 하는 클라이언트 디바이스(CL)(140) 사이에 적용 가능한 RTT 정보를 획득한다. 제1 예에 따르면, RTT는 클라이언트 디바이스(CL)(140)와 교환하는 동안 캐시 서버(CSERV)(130)에 의해 측정된다. 대안적으로, 이러한 교환 동안, RTT는 클라이언트 디바이스(CL)(140)에 의해 측정된 다음, 클라이언트 디바이스(CL)(140)에 의해 캐시 서버(CSERV)(130)에 제공될 수 있다. RTT는 캐시 서버(CSERV)(130)로부터 클라이언트 디바이스(CL)(140)로 오디오 및/또는 비디오 콘텐츠를 전송하는 전체 세션 동안 한 번 측정될 수 있다. 대안적으로, RTT는 정기적으로 측정된다. 다른 접근 방식에서, RTT는 디폴트 구성 파라미터로서 저장되고, 캐시 서버(CSERV)(130)가 임의의 클라이언트 디바이스에 오디오 및/또는 비디오 콘텐츠 데이터를 전송할 때 처리해야 하는 최대 가능한 RTT에 대응한다. 주목할 것은 모바일 네트워크 인프라구조 위에 CDN을 설정하는 경우 캐시 서버는 모바일 네트워크 인프라구조의 (기지국 내의, 또는 게이트웨이 내 등의) 다양한 위치에 구축될 수 있다는 것이다. 이 경우, 최대 가능한 RTT를 한정하는 디폴트 구성 파라미터는 모바일 네트워크 인프라구조에서 캐시 서버마다 제각기의 위치에 따라 다를 수 있다. 다른 실시형태는 평균 RTT 값을 사용하는 것이다. 평균 RTT 값은 캐시 서버(CSERV)(130)에 의해 시간 경과에 따라 오디오 및/또는 비디오 콘텐츠를 클라이언트 디바이스에 전송하기 위한 세션을 분석함으로써 계산된다. 이 접근 방식은 벌크 지속시간 한정에 사용되는 RTT 값의 동적 업데이트 시 최적의 벌크 전송 크기에 보다 빠르게 도달할 수 있게 하며, 모바일 네트워크 인프라구조 위에 CDN을 설정하는 데 특히 효율적이다. 위에 열거된 적용 가능한 RTT 값의 실시형태는 오디오 및/또는 비디오 콘텐츠를 전송하는 전체 세션에 걸쳐 사용될 수 있거나, 초기 구성으로서 사용된 다음, RTT 측정에 따라 동적으로 업데이트될 수 있다.
단계 502에서, 캐시 서버(CSERV)(130)는 최소 벌크 전송 크기 mTBS를 계산한다. 오디오 및/또는 비디오 콘텐츠의 N개의 표현(i = 1,..,N)을 가정하면, 각 표현은 평균 비트레이트 Bi를 가지며, 최소 벌크 전송 크기 mTBS는 다음과 같이 계산된다:
mTBS = C0*max (B1..Bn)*RTT
여기서 C0 > 1은, RTT 추정에서 잠재적인 오차를 보상하고 평균 비트레이트 표시도수(bitrate indication)인 Bi를 추가로 보상하는(이는 유효 비트레이트가 이 평균 비트레이트 표시도수 주위에서 변할 수 있다는 것을 의미함) 미리 한정된 마진을 추가하는 상수가 된다.
단계 503에서, 캐시 서버(CSERV)(130)는 오디오 및/또는 비디오 콘텐츠에 대해, 클라이언트 디바이스(CL)(140)에 전송되어야 하는 표현 i에 대한 최소 벌크 지속시간 mTBDi를 다음과 같이 계산한다:
mTBDi = mTBS / Bi
도 3을 참조하면, 최소 벌크 지속시간 mTBDi (i = 1,..,N)는 바람직하게는 초 단위로 표시되는 tB의 최소값에 해당한다.
캐시 서버(CSERV)(130)는 (전체 세션에 대한 것일 수 있는) 새로운 RTT 값이 획득될 때마다 임의의 표현 i (i = 1,..,N)에 대한 최소 벌크 지속시간 mTBDi를 계산할 수 있다. 대안적으로, 캐시 서버(CSERV)(130)는, (전체 세션에 대한 것일 수 있는) 새로운 RTT 값이 획득될 때마다, 클라이언트 디바이스(CL)(140)로 전송될 필요가 있는 표현 i (i = 1,..,N)에 대한 최소 벌크 지속시간 mTBDi만을 계산한다.
단계 504에서, 캐시 서버(CSERV)(130)는, 예를 들어, 발신 서버(OSERV)(150)로부터 또는 중간 업스트림 서버로부터 수신되는, 연속적인 청크들의 벌크의 형태로 오디오 및/또는 비디오 콘텐츠 데이터를 전송한다. 캐시 서버(CSERV)(130)는 각 벌크를 하나의 데이터 버스트로서 전송한다.
캐시 서버(CSERV)(130)는 오디오 및/또는 비디오 콘텐츠를, 각 세그먼트마다 적어도 하나의 청크 또는 집성된 연속적인 청크들의 L개의 벌크의 형태로 버스트 전송에 의해 전송하며, L개(L > 1)의 벌크는 상기 세그먼트에 대응하는 오디오 및/또는 비디오 콘텐츠 데이터를 공동으로 포함하고,
각 세그먼트마다, 다음 조건을 확인하여, M개의 청크 또는 청크들로 적어도 L-1개의 벌크 또는 벌크들을 제각기 형성하며:
Figure pct00005
및
Figure pct00006
여기서 i는 클라이언트(CL)(140)에 전송될 표현을 나타내며, 따라서 세션 동안 시간이 지남에 따라 변경될 수 있고,
여기서 CH j (j = 1,..,M)는 상기 오디오 및/또는 비디오 콘텐츠에 대한 청크 j의 시간 지속시간을 나타낸다.
다시 말해서, 세그먼트 지속시간은 위의 조건과 모두 매칭되는 청크들의 L개의 벌크와 정확히 대응하지 않을 수 있다. 이 경우, L-1개의 벌크는 위의 조건과 매칭되고, 하나의 벌크는 지속시간이 더 짧다. 바람직하게는, 지속시간이 더 짧은 이 벌크는 해당 세그먼트에 대해 전송될 마지막 벌크이다.
주목할 것은 모든 청크는 디폴트에 의해 동일한 지속시간을 갖지만 어떤 이유로 청크 지속시간은 변경될 수 있다는 것이다.
바람직한 실시형태에서, M개의 연속적인 청크들은 고려된 벌크의 맨 처음 청크(j=1)가 클라이언트 디바이스(CL)(140)에 아직 전송되지 않은 순서상 다음 청크가 되도록 선택된다.
따라서, 클라이언트 디바이스(CL)(140)가 오디오 및/또는 비디오 콘텐츠의 세그먼트를 요청할 때, 캐시 서버(CSERV)(130)는 버스트 전송에 의해, 위에서 정의된 바와 같이 벌크를 형성하는 집성된 청크들을 전송한다. 청크들이 벌크를 형성하도록 집성되는 방식은 RTT 값에 의존하기 때문에, 대역폭 추정이 신뢰될 수 있고, 결과적으로 오디오 및/또는 비디오 콘텐츠의 적절한 표현이 클라이언트 디바이스(CL)(140)에 의해 또는 캐시 서버(CSERV)(130)에 의해 선택되어 전송될 수 있으며, 따라서 QoE를 향상시킬 수 있다.
정제된 RTT 값이나 모니터링된 RTT 값의 진화로 인해, 세션 동안 벌크 지속시간이 동적으로 조정되는 경우, 정확한 이용 가능한 대역폭 값을 신속하게 얻기 위해 오디오 및/또는 비디오 콘텐츠의 최고 품질 표현으로 시작하는 것이 흥미로울 수 있다. 이것은 특히 오디오 및/또는 비디오 콘텐츠 표현 선택이 캐시 서버(CSERV)(130)에 의해 수행되는 경우이다.
도 6은 특정 실시형태에서 세그먼트 요청을 관리하기 위한 알고리즘을 개략적으로 나타낸 것이다. 세그먼트 요청에 앞서, 클라이언트 디바이스(CL)(140)는 매니페스트 파일을 요청해야 한다. 캐시 서버(CSERV)(130)는 발신 서버(OSERV)(150)로부터 매니페스트 파일을 획득하고, 이를 요청 시에 클라이언트 디바이스(CL)(140)에 포워딩한다.
클라이언트 디바이스(CL)(140)가 세그먼트를 요청하는 적절한 시간은 일반적으로 (예컨대, MPEG DASH에 따라) 매니페스트 파일 정보를 사용하여 저지연 적응형 비트레이트로 결정된다. 매니페스트 파일 정보 내에는 세그먼트를 요청하기 위한 적절한 타이밍을 나타내는 정보가 표시되어 있다. 예를 들어, MPEG DASH에서, 이 정보는 availabilityTimeOffset이라고 지칭되는 필드에 간접적으로 표시되며, 이 availabilityTimeOffset는 이미 언급된 바와 같이, 전체 세그먼트 이용 가능성에 해당하는 이론적 시점에서 클라이언트 디바이스(CL)(140)가 공제해야 하는 최소 시간 오프셋에 해당한다. 일반적으로, 저지연이 아닌 경우, 클라이언트 디바이스(CL)(140)는 세그먼트 요청을 제출하기 전에 (세그먼트가 캐시 서버에 의해 완전히 수신되었음을 확신하기 위해) 전체 세그먼트에 해당하는 지속시간(예컨대, 2초) 동안 대기해야 하며, 따라서 availabilityTimeOffset 값은 0이거나 매니페스트 파일에 존재하지 않는다. 저지연의 경우, 클라이언트 디바이스는 캐시 서버에 의해 적어도 하나의 청크가 수신되자마자 세그먼트 요청을 제출할 수 있고, 따라서 availabilityTimeOffset 값은 세그먼트의 지속시간에서 청크의 지속시간을 뺀 값에 해당한다. 예를 들어, 세그먼트 지속시간이 오디오 및/또는 비디오 콘텐츠의 2초에 해당하고 청크 지속시간이 오디오 및/또는 비디오 콘텐츠의 40밀리초에 해당하는 경우, availabilityTimeOffset 값은 1.860밀리초로 고정된다. 따라서, 일반적으로 매니페스트 파일은 청크가 이론적으로 이용 가능하게 되자마자 세그먼트 요청이 수행될 수 있다는 것을 표시한다.
RTT 값에 따라, 벌크 지속시간이 세션들 전반에 걸쳐 상이할 수 있거나 동적으로 업데이트될 수 있고, 세그먼트 요청에 적절한 타이밍을 나타내는 정보(예컨대, MPEG DASH에 따른 availabilityTimeOffset)가 매니페스트 파일에서 정적이기 때문에, 클라이언트 디바이스(CL)(140)는, 적절한 벌크를 형성하고 응답 전송을 시작하기에 충분한 청크 데이터를 아직은 이용할 수 없는 세그먼트를 요청할 수 있다.
이러한 상황에서 클라이언트 디바이스(CL)(140)에 오류 코드를 리턴하는 것을 피하기 위해, 캐시 서버(CSERV)(130)는, 응답의 초기 부분(순서상 첫 번째 벌크)을 클라이언트 디바이스(CL)(140)로 전송하기 전, 도 6과 관련하여 본원에 개시된 바와 같이, 클라이언트 디바이스(CL)(140)로 전송할 적절한 제1 벌크를 형성하기에 충분한 청크들이 이용 가능할 때까지 대기하는 것이 제안되었다. 그 후에, 캐시 서버(CSERV)(130)는 나머지 세그먼트 응답에 대해서도 마찬가지인데, 도 6과 관련하여 본원에 개시된 바와 같이, 클라이언트 디바이스(CL)(140)로 전송할 적절한 벌크를 형성하기에 충분한 청크들이 이용 가능할 때까지 대기하고, 그리고 전체 세그먼트 응답이 전송될 때까지 계속된다.
캐시 서버(CSERV)(130)는, 단계 601에서, 클라이언트 디바이스(CL)(140)로부터 세그먼트 요청을 수신한다. 캐시 서버(CSERV)(130)는 해당 세그먼트에 대응하는 청크들의 버스트를 전송함으로써 상기 요청에 응답해야 한다.
단계 602에서, 캐시 서버(CSERV)(130)는, 본원에 정의된 바와 같이, 클라이언트 디바이스(CL)(140)에 전송할 벌크를 구축하기에 충분한 청크들이 캐시에서 이용 가능한지 여부를 체크한다. 캐시에서 충분한 청크들이 이용 가능한 경우, 단계 603에서 캐시 서버(CSERV)(130)가 수행되고, 이 단계 동안, 캐시 서버(CSERV)(130)는 클라이언트 디바이스(CL)(140)로의 청크들의 벌크의 전송을 개시하고; 그렇지 않으면, 단계 604에서, 캐시 서버(CSERV)(130)는 세그먼트 요청의 처리를 차단한다. 벌크의 구축 및 전송은, 본원에 정의된 바와 같이, 클라이언트 디바이스(CL)(140)로 전송될 상기 벌크를 구축하기에 충분한 상기 청크들이 캐시에서 이용 가능할 때까지 차단되고, 이어서 단계 604가 수행된다. 단계 605에서, 캐시 서버(CSERV)(130)는 이 벌크가 전송될 데이터의 마지막 벌크인지 여부를 체크한다. 그렇지 않은 경우, 단계 601로 다시 순환을 계속한다. 그렇지 않으면, 단계 606에서, 세그먼트 전송이 종료된다. 주목할 것은, 이미 언급했듯이, 위에서 계산된 바와 같이 세그먼트의 총 청크 수를 M(벌크를 형성하는 최적의 청크 수)으로 나눈 것이 정수가 되지 않을 수 있기 때문에, 데이터의 마지막 벌크는 이전의 벌크 또는 벌크들보다 지속시간이 더 짧을 수 있다는 것이다.
도 7은 다른 특정 실시형태에서 오디오 및/또는 비디오 콘텐츠 데이터를 버스트 전송에 의해 청크들의 벌크의 형태로 전송하기 위한 알고리즘을 개략적으로 나타낸 것이다. HTTP는 도 7의 영역에서 바람직하게 사용된다.
저지연 접근 방식의 HLS에 의하면, MPEG DASH와 마찬가지로, 본원에서 재생목록이라고 지칭되는 매니페스트 파일은 소위 PART-TARGET 속성을 통해 재생목록에 표시된 청크 지속시간 정보(청크들은 HLS 용어에 따라 일부 세그먼트들이라고 지칭됨)를 수집한다. MPEG DASH와 다른 점은, 클라이언트 디바이스(CL)(140)가 통상적으로는 바이트 범위 정보를 사용하여 일부 세그먼트들을 명시적으로 요청하는 반면, MPEG DASH에서 클라이언트 디바이스(CL)(140)는 경계가 클라이언트 디바이스(CL)(140)에 미리 알려지지 않아도 청크들의 버스트에 의해 전송되는 특정 세그먼트를 요청한다는 것이다.
저지연 접근 방식의 HLS는 클라이언트 디바이스(CL)(140)가 일부 세그먼트들(청크들)을 명시적으로 요청하는 것으로 정의하기 때문에, 벌크 지속시간은 세션 동안 동적으로 변경될 수 없다. 그러나, 재생목록에 표시된 일부 세그먼트 지속시간은 세션마다 벌크 크기와 동일하게 조정될 수 있다. 그렇게 하려면, 캐시 서버(CSERV)(130)는 RTT 값을 알아야만 한다. 캐시 서버(CSERV)(130)가, 이후에 상세히 설명되는 바와 같이, 사용될 RTT 값을 획득할 수 있도록 하기 위해, 특정 리디렉션 기능이 구현된다.
단계 701에서, 캐시 서버(CSERV)(130)는 클라이언트 디바이스(CL)(140)로부터 재생목록(또는 매니페스트 파일) 요청을 수신한다. 요청된 재생목록은 클라이언트 디바이스(CL)(140)에 전송될 오디오 및/또는 비디오 콘텐츠에 해당한다. 단계 702에서, 캐시 서버(CSERV)(130)는 위 요청에 응답하는 대신에 요청된 재생목록(또는 매니페스트 파일)을 전송함으로써, 요청된 재생목록이 나타내는 오디오 및/또는 비디오 콘텐츠를 지시하는 것으로부터 시작해서 단계 701에서 수신된 재생목록 요청에 사용된 것과 동일한 URL로 클라이언트 디바이스(CL)(140)를 리디렉션한다. 이를 위해, 캐시 서버(CSERV)(130)는 리디렉션 메시지를 클라이언트 디바이스(CL)(140)로 전송한다(HTTP 리디렉션이라 함). 캐시 서버(CSERV)(130)는 이렇게 함으로써 클라이언트 디바이스(CL)(140)에게 재생목록(또는 매니페스트 파일) 요청을 재전송하게 한다.
따라서, 단계 703에서, 캐시 서버(CSERV)(130)는 클라이언트 디바이스(CL)(140)로부터 재생목록(또는 매니페스트 파일) 요청을 다시 수신한다.
그 후, 단계 704에서, 캐시 서버(CSERV)(130)는 RTT 값을 계산하는데, 이 RTT 값은 캐시 서버(CSERV)(130)가 클라이언트 디바이스(CL)(140)를 리디렉션한 시점부터 캐시 서버(CSERV)(130)가 클라이언트 디바이스(CL)(140)로부터 재생목록(또는 매니페스트 파일) 요청을 다시 수신한 시점까지의 시간 차이로 산정된다.
단계 705에서, 캐시 서버(CSERV)(130)는 도 5와 관련하여 이미 설명된 바와 같이 최소 벌크 전송 크기 mTBS를 계산한다.
단계 706에서, 캐시 서버(CSERV)(130)는 오디오 및/또는 비디오 콘텐츠에 대해, 도 5와 관련하여 이미 설명된 방식으로, 클라이언트 디바이스(CL)(140)로 어떻게든지 해서 전송되어야 하는 각 표현 i (i = 1,..,N)에 대한 최소 벌크 지속시간 mTBDi를 계산한다. 최소 벌크 지속시간 mTBDi (i = 1,..,N)는 모두 전체 세션에 걸쳐 적용 가능하다.
단계 707에서, 캐시 서버(CSERV)(130)는 클라이언트 디바이스(CL)(140)로 전송될 재생목록을 구축한다. 재생목록(또는 매니페스트 파일)은 RTT 값의 함수로 정의된 바와 같은 청크들의 벌크의 지속시간과 동일한 일부 세그먼트들의 지속시간을 표시한다. 특정 실시형태에서, 캐시 서버(CSERV)(130)는 재생목록이 RTT 값의 함수로 정의된 바와 같은 청크들의 벌크의 지속시간과 동일한 일부 세그먼트들의 지속시간을 나타내도록 발신 서버(OSERV)(150)로부터 획득된 재생목록 정보(또는 매니페스트 파일 정보)를 조정한다. 따라서 캐시 서버(CSERV)(130)는 구축되거나 조정된 재생목록(또는 매니페스트 파일)을 클라이언트 디바이스(CL)(140)로 전송한다.
단계 708에서, 캐시 서버(CSERV)(130)는 오디오 및/또는 비디오 콘텐츠 데이터를 버스트 전송에 의해 연속적인 청크들의 벌크의 형태로 전송한다. 각각의 벌크는 도 5와 관련하여 이미 설명된 바와 같이, 적어도 하나의 청크 및 최대 M개의 연속적인 청크들에 대응하는 크기를 갖는다.
따라서, 클라이언트 디바이스(CL)(140)가 오디오 및/또는 비디오 콘텐츠의 일부 세그먼트를 요청할 때마다, 캐시 서버(CSERV)(130)는 버스트 전송에 의해, 재생목록에 게시되는 일부 세그먼트 지속기간에 해당하는, 위에서 정의된 바와 같은, 하나의 벌크를 형성하는 집성된 청크들을 전송한다. 클라이언트 디바이스(CL)(140)는 재생목록에 표시된 일부 세그먼트들의 지속시간이 RTT 값의 함수로 정의된 바와 같은 청크들의 벌크의 지속시간과 매칭되기 때문에 캐시 서버(CSERV)(130)가 응답하는 방식을 일관되게 찾는다.

Claims (12)

  1. 적응형 스트리밍을 사용하여 캐시 서버로부터 클라이언트 디바이스로 오디오 및/또는 비디오 콘텐츠를 전송하는 방법으로서,
    상기 오디오 및/또는 비디오 콘텐츠는 제각기의 오디오 및/또는 비디오 품질을 갖는 다양한 표현으로 이용 가능한 데이터 세그먼트들로 분할되고, 상기 표현들은 세그먼트마다 시간 정렬되며, 상기 세그먼트들은 청크들로 추가로 분할되며,
    상기 방법은,
    - 상기 캐시 서버와 상기 클라이언트 디바이스 사이에 적용 가능한 왕복 시간 값을 획득하는 단계;
    - 상기 오디오 및/또는 비디오 콘텐츠의 다양한 표현의 최대 평균 비트레이트와 상기 획득된 왕복 시간 값으로부터 최소 벌크 전송 크기 mTBS를 계산하는 단계;
    - 상기 오디오 및/또는 비디오 콘텐츠에 대해, 상기 클라이언트 디바이스에 전송되어야 하는 상기 오디오 및/또는 비디오 콘텐츠의 표현 i에 대한 최소 벌크 지속시간 mTBDi를 계산하는 단계; 및
    - 상기 오디오 및/또는 비디오 콘텐츠를, 각각의 세그먼트마다 적어도 하나의 청크 또는 집성된 연속적인 청크들의 L개의 벌크의 형태로 버스트 전송에 의해 전송하는 단계 - 상기 L개의 벌크는 상기 세그먼트에 대응하는 오디오 및/또는 비디오 콘텐츠 데이터를 공동으로 포함함 - 를 포함하고,
    각각의 세그먼트마다, 적어도 L-1개의 벌크 또는 벌크들이 각각 M개의 청크 또는 청크들로 형성되되,
    Figure pct00007

    및
    Figure pct00008
    가 되도록 형성되고,
    여기서 CH j (j = 1,..,M)는 상기 오디오 및/또는 비디오 콘텐츠에 대한 청크 j의 시간 지속시간을 나타내는, 오디오 및/또는 비디오 콘텐츠를 전송하는 방법.
  2. 제1항에 있어서, 상기 왕복 시간 값은 상기 캐시 서버에 의해 디폴트 구성 파라미터로서 저장되고, 상기 캐시 서버가 오디오 및/또는 비디오 콘텐츠 데이터를 임의의 클라이언트 디바이스에 전송할 때 처리해야 하는 최대 가능한 왕복 시간에 대응하는, 오디오 및/또는 비디오 콘텐츠를 전송하는 방법.
  3. 제1항에 있어서, 상기 왕복 시간 값은 오디오 및/또는 비디오 콘텐츠를 클라이언트 디바이스로 전송하기 위한 세션들을 분석함으로써 시간 경과에 따라 상기 캐시 서버에 의해 계산된 평균 왕복 시간 값인, 오디오 및/또는 비디오 콘텐츠를 전송하는 방법.
  4. 제2항 또는 제3항에 있어서, 상기 왕복 시간 값은 상기 최소 벌크 전송 크기 mTBS 및 상기 최소 벌크 지속시간 mTBDi에 대한 초기 구성 및 한정으로서 사용되고, 그 후에는, 상기 캐시 서버와 상기 클라이언트 디바이스 사이의 왕복 시간의 측정에 따라, 상기 최소 벌크 전송 크기 mTBS 및 상기 최소 벌크 지속시간 mTBDi로서 동적으로 업데이트도 되는, 오디오 및/또는 비디오 콘텐츠를 전송하는 방법.
  5. 제1항 내지 제3항 중 어느 한 항에 있어서, 상기 동일한 왕복 시간 값은 오디오 및/또는 비디오 콘텐츠를 전송하는 전체 세션에 걸쳐 사용되는, 오디오 및/또는 비디오 콘텐츠를 전송하는 방법.
  6. 제5항에 있어서, 상기 캐시 서버는, 상기 오디오 및/또는 비디오 콘텐츠와 관련된 재생목록 또는 매니페스트 파일을 획득하기 위한 요청을 상기 클라이언트 디바이스로부터 수신할 때, 상기 왕복 시간 값을 획득하기 위해, 상기 클라이언트 디바이스가 해당 요청을 재전송하도록 상기 클라이언트 디바이스를 리디렉션하고, 상기 캐시 서버가 상기 클라이언트 디바이스를 리디렉션한 시점부터 상기 캐시 서버가 상기 클라이언트 디바이스로부터 해당 요청을 다시 수신하는 시점까지의 시간 차이로서 상기 왕복 시간 값을 계산하는, 오디오 및/또는 비디오 콘텐츠를 전송하는 방법.
  7. 제6항에 있어서, 상기 캐시 서버는, 일부 세그먼트들의 지속시간이 상기 왕복 시간 값의 함수로서 정의된 바와 같은 청크들의 벌크의 지속시간과 같다는 것을 상기 재생목록 또는 매니페스트 파일 내에 표시하는, 오디오 및/또는 비디오 콘텐츠를 전송하는 방법.
  8. 제1항 내지 제5항 중 어느 한 항에 있어서, 상기 오디오 및/또는 비디오 콘텐츠와 관련된 매니페스트 파일은 청크가 이론적으로 이용 가능하게 되자마자 세그먼트 요청이 수행될 수 있다는 것을 표시하며, 상기 캐시 서버는 상기 클라이언트 디바이스로부터 수신된 세그먼트 요청의 처리를, 응답 시 전송할 벌크를 구축기에 충분한, 요청된 세그먼트의 청크들을 캐시에서 이용 가능할 때까지 차단하는, 오디오 및/또는 비디오 콘텐츠를 전송하는 방법.
  9. 프로그래머블 디바이스에 로딩될 수 있는 프로그램 코드 인스트럭션을 포함하는 컴퓨터 프로그램 제품으로서,
    상기 프로그램 코드 인스트럭션은 상기 프로그래머블 디바이스에 의해 실행될 때 제1항 내지 제8항 중 어느 한 항에 따른 방법을 구현하는, 컴퓨터 프로그램 제품.
  10. 프로그래머블 디바이스에 로딩될 수 있는 프로그램 코드 인스트럭션을 포함하는 컴퓨터 프로그램을 저장하는 정보 저장 매체로서,
    상기 프로그램 코드 인스트럭션은 상기 정보 저장 매체로부터 판독되어 상기 프로그래머블 디바이스에 의해 실행될 때 제1항 내지 제8항 중 어느 한 항에 따른 방법을 구현하는, 정보 저장 매체.
  11. 적응형 스트리밍을 사용하여 클라이언트 디바이스로 오디오 및/또는 비디오 콘텐츠를 전송하도록 구성된 캐시 서버로서,
    상기 오디오 및/또는 비디오 콘텐츠는 제각기의 오디오 및/또는 비디오 품질을 갖는 다양한 표현으로 이용 가능한 데이터 세그먼트들로 분할되고, 상기 표현들은 세그먼트마다 시간 정렬되며, 상기 세그먼트들은 청크들로 추가로 분할되며,
    상기 캐시 서버는 전자 회로부를 포함하되, 상기 전자 회로부는,
    - 상기 캐시 서버와 상기 클라이언트 디바이스 사이에 적용 가능한 왕복 시간 값을 획득하고;
    - 상기 오디오 및/또는 비디오 콘텐츠의 다양한 표현의 최대 평균 비트레이트와 상기 획득된 왕복 시간 값으로부터 최소 벌크 전송 크기 mTBS를 계산하고;
    - 상기 오디오 및/또는 비디오 콘텐츠에 대해, 상기 클라이언트 디바이스에 전송되어야 하는 상기 오디오 및/또는 비디오 콘텐츠의 표현 i에 대한 최소 벌크 지속시간 mTBDi를 계산하고; 그리고
    - 상기 오디오 및/또는 비디오 콘텐츠를, 각각의 세그먼트마다 적어도 하나의 청크 또는 집성된 연속적인 청크들의 L개의 벌크의 형태로 버스트 전송에 의해 전송하도록 구성되고, 상기 L개의 벌크는 상기 세그먼트에 대응하는 오디오 및/또는 비디오 콘텐츠 데이터를 공동으로 포함하고,
    각각의 세그먼트마다, 적어도 L-1개의 벌크 또는 벌크들이 각각 M개의 청크 또는 청크들로 형성되되,
    Figure pct00009

    및
    Figure pct00010
    가 되도록 형성되고,
    여기서 CH j (j = 1,..,M)는 상기 오디오 및/또는 비디오 콘텐츠에 대한 청크 j의 시간 지속시간을 나타내는, 오디오 및/또는 비디오 콘텐츠를 전송하도록 구성된 캐시 서버.
  12. 제11항에 따른 캐시 서버를 포함하는 콘텐츠 전송 네트워크.
KR1020227040021A 2020-04-27 2021-04-26 오디오 및/또는 비디오 콘텐츠 전송을 위한 방법 및 서버 KR20230002784A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP20315225.1 2020-04-27
EP20315225.1A EP3905708B1 (en) 2020-04-27 2020-04-27 Method and server for audio and/or video content delivery
PCT/EP2021/060862 WO2021219563A1 (en) 2020-04-27 2021-04-26 Method and server for audio and/or video content delivery

Publications (1)

Publication Number Publication Date
KR20230002784A true KR20230002784A (ko) 2023-01-05

Family

ID=70977898

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020227040021A KR20230002784A (ko) 2020-04-27 2021-04-26 오디오 및/또는 비디오 콘텐츠 전송을 위한 방법 및 서버

Country Status (9)

Country Link
US (1) US11812114B2 (ko)
EP (1) EP3905708B1 (ko)
JP (1) JP2023522895A (ko)
KR (1) KR20230002784A (ko)
CA (1) CA3176231A1 (ko)
ES (1) ES2940452T3 (ko)
IL (1) IL297561A (ko)
MX (1) MX2022013136A (ko)
WO (1) WO2021219563A1 (ko)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP4158848A4 (en) * 2020-05-29 2023-07-26 Telefonaktiebolaget LM Ericsson (PUBL) METHODS AND ARRANGEMENTS TO SUPPORT THE ESTIMATION OF LATENCY ACROSS A COMMUNICATION PATH IN A COMMUNICATION NETWORK
ES2968442T3 (es) * 2020-11-13 2024-05-09 Broadpeak Procedimiento y controlador para la distribución de contenido de audio y/o vídeo
US11606277B2 (en) * 2021-02-10 2023-03-14 Cohesity, Inc. Reducing the impact of network latency during a restore operation

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2362651A1 (en) * 2010-02-19 2011-08-31 Thomson Licensing Multipath delivery for adaptive streaming
EP2375680A1 (en) * 2010-04-01 2011-10-12 Thomson Licensing A method for recovering content streamed into chunk
JPWO2014057896A1 (ja) * 2012-10-09 2016-09-05 シャープ株式会社 コンテンツ再生装置
MX362448B (es) * 2015-01-08 2019-01-18 Arris Entpr Llc Control de velocidad de bits adaptativo del lado del servidor para clientes de transmision dlna http.
US10771833B2 (en) * 2016-05-31 2020-09-08 The Trustees Of Princeton University System and method for improving streaming video via better buffer management
US10567461B2 (en) * 2016-08-04 2020-02-18 Twitter, Inc. Low-latency HTTP live streaming
GB201812862D0 (en) * 2018-08-08 2018-09-19 British Telecomm Improved congestion response

Also Published As

Publication number Publication date
EP3905708A1 (en) 2021-11-03
JP2023522895A (ja) 2023-06-01
MX2022013136A (es) 2022-11-10
WO2021219563A1 (en) 2021-11-04
EP3905708B1 (en) 2022-12-21
US20230143627A1 (en) 2023-05-11
CA3176231A1 (en) 2021-11-04
IL297561A (en) 2022-12-01
ES2940452T3 (es) 2023-05-08
US11812114B2 (en) 2023-11-07

Similar Documents

Publication Publication Date Title
US8621061B2 (en) Adaptive bitrate management for streaming media over packet networks
EP1397899B1 (en) Real-time packetization and retransmission in streaming applications
CN113271316B (zh) 多媒体数据的传输控制方法和装置、存储介质及电子设备
US9473406B2 (en) On-demand adaptive bitrate management for streaming media over packet networks
KR101638223B1 (ko) 적응적 스트리밍 서비스를 제공하기 위한 방법
KR20230002784A (ko) 오디오 및/또는 비디오 콘텐츠 전송을 위한 방법 및 서버
CN110192394B (zh) 通过网络传送媒体内容的方法和服务器
RU2598805C2 (ru) Способ для динамической адаптации частоты следования битов при приеме и соответствующий приемник
JP2001274861A (ja) データ伝送方法および装置
US11140205B2 (en) Congestion response for timely media delivery
JP3871661B2 (ja) マルチメディアコンテンツ受信装置及びマルチメディアコンテンツ受信方法
KR100624854B1 (ko) 미디어 재전송 장치 및 방법
GB2572357A (en) Congestion response for timely media delivery
EP1947859A1 (en) Video transmission method and system
CN116980713A (zh) 一种带宽检测方法、装置、电子设备及存储介质
CN115767143A (zh) 播放卡顿的判断方法、装置、电子设备和可读存储介质
GB2588930A (en) Multimedia system & method