KR102012528B1 - 수신 비트율 및 연관된 수신기의 동적 적응 방법 - Google Patents

수신 비트율 및 연관된 수신기의 동적 적응 방법 Download PDF

Info

Publication number
KR102012528B1
KR102012528B1 KR1020137030154A KR20137030154A KR102012528B1 KR 102012528 B1 KR102012528 B1 KR 102012528B1 KR 1020137030154 A KR1020137030154 A KR 1020137030154A KR 20137030154 A KR20137030154 A KR 20137030154A KR 102012528 B1 KR102012528 B1 KR 102012528B1
Authority
KR
South Korea
Prior art keywords
server
transmission rate
request
coding bit
bit rate
Prior art date
Application number
KR1020137030154A
Other languages
English (en)
Other versions
KR20140023983A (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 KR20140023983A publication Critical patent/KR20140023983A/ko
Application granted granted Critical
Publication of KR102012528B1 publication Critical patent/KR102012528B1/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/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5051—Service on demand, e.g. definition and deployment of services in real time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/302—Route determination based on requested QoS
    • H04L45/306—Route determination based on the nature of the carried application
    • H04L45/3065—Route determination based on the nature of the carried application for real time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/801—Real time traffic
    • 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/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/613—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for the control of the source by the destination
    • 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/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • H04N21/47202—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content for requesting content on demand, e.g. video on demand
    • 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
    • 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/6377—Control signals issued by the client directed to the server or network components directed to server
    • H04N21/6379—Control signals issued by the client directed to the server or network components directed to server directed to encoder, e.g. for requesting a lower encoding rate

Abstract

부분들을 통해 송신된 시청각 프로그램을 네트워크를 통해 수신하는 방법이 기술되며, 본 방법은 서버 및 수신기 간의 실시간 전송 프로토콜 및 실시간 제어 프로토콜을 사용하고, 시청각 프로그램은 상이한 해상도들로 코딩된 프로그램에 대응하고 수신기의 요청들에 따라 상이한 비트율들로의 송신을 가능케 하는 복수의 버전들로 서버에서 가용하다. 본 방법은 네트워크의 상태에 따라 송신 비트율을 조정하기 위해 수신기에 의한 네트워크의 대역폭의 규칙적인 측정을 포함한다.

Description

수신 비트율 및 연관된 수신기의 동적 적응 방법{METHOD FOR DYNAMIC ADAPTATION OF THE RECEPTION BITRATE AND ASSOCIATED RECEIVER}
본 발명은 시청각 프로그램 수신기들의 분야에 관한 것으로, 특히, 스트리밍 송신을 위해 실시간 전송 프로토콜 및 실시간 전송 프로토콜과 연관된 실시간 서버 제어 프로토콜을 사용해서 프로그램의 송신 중에 네트워크에서 가용 대역폭에 따른 프로그램의 동적 적응에 관한 것이다.
디스플레이를 위한 프로그램의 다운로딩은 복구(recovery) 전에 수신기로의 시청각 프로그램의 완전한 전송을 강요한다. 다운로딩의 종료를 대기하거나 또는 전체 프로그램을 위한 충분한 저장 공간을 가질 필요가 있다는 요구 사항 등의 연관된 제약들을 방지하기 위해, 스트리밍(시청 중의 프로그램의 연속 송신)의 사용이 널리 만연되어 있다.
공지된 스트리밍 프로토콜은 서버 제어 프로토콜(RFC2326) 및 MPEG TS/UDP(Motion Picture Expert Group Transport Stream/User Datagram Protocol)와 연관된, RTP(RFC3550 및 전송 데이터의 포맷에 따른 연관된 RFC)를 포함하며, 다운로드는 일반적으로 HTTP(Hyper Text Transfer Protocol) 프로토콜을 사용한다.
현대의 통신 네트워크들은 시청각 프로그램들의 송신을 스트리밍으로 가능케 하는 대역폭 용량들을 제공한다. 송신은, 서버 및 클라이언트 간에, 인터넷 등의 네트워크들을 통해 수행될 수 있다. 스트리밍은 송신되는 시청각 프로그램이 송신 및 복구에 걸쳐 네트워크에서 연속해서 송신되는 시간적인 부분들(순차적으로 렌더링되는 연속 부분들)로 나누어지는 송신 방법이다. 송신 및 복구는 동시이며, 수신기에서의 버퍼 메모리의 사용으로 인한 경미한 지연이 추가된다.
표준 3GPP(3GPP, TSGS-SA, 투과적 엔드-투-엔드 패킷 스위치 스트리밍 서비스(PSS), 3GPP 파일 포맷(3GP), TS26.244, V6.3.0, 2005-03))는 상이한 비트율들에 대응하여 동일한 프로그램의 수개의 버전들을 포함하는 데이터의 구성 및 저장을 위한 포맷을 정의한다. 프로그램 서버의 제어 로직과 연관된 이 포맷은, 네트워크 사용과 관련된 조건들 및 특히 대역폭의 변화들에 대한 적응을 가능케 한다. 그러나, 서버에서 구현된 이 제어 로직은 3GPP 표준에 명시되어 있지 않다.
3GPP 포맷에서, 데이터는 고정 비트율에 대한 송신 링크 상의 비트율 제약에 순응하도록 코딩된다: 데이터가 이미지들일 때, 코딩은 더 큰 또는 더 작은 대역폭으로 링크에서의 수송을 가능케 하도록 이미지들의 해상도를 적응시키는 것으로 구성된다. 그러나, 3GPP는 대역폭의 변화들에 대해 데이터의 수신을 조정하기 위해 송신 이미지들의 해상도가 변경될 수 있게 하는 스위칭 수단을 정의하지 않는다. 이 문제를 해결하기 위한 일부 방법들이 공지되어 있다: 이는 RTCP(Real-Time Control Protocol) 프로토콜에서 정의된 RR들(Receiver Reports) 등의, 클라이언트로부터 서버로 송신된 데이터에 좌우되며, 송신이 다른 비트율로 수행되어야만 하는 지를 정의하기 위해 서버에 의한 처리 및 해석 단계들을 요구한다.
HTTP 스트리밍 기술은 최근에 아이폰(iPhone)의 애플사(Apple) 및 스무드스트리밍(Smoothstreaming)의 마이크로소프트사(Microsoft)를 통해 일반 대중의 주목을 받았다. HTTP 스트리밍 기술은 기능이 RTP 및 RTSP 프로토콜들에 의존하는 IPTV 수신기들에서만 사용된다.
현재 IPTV에서 사용되는 송신 방법들은 특정 서버를 사용하지 않고 네트워크에서 가용 대역폭에 따른 비트율의 동적 적응을 허용하지 않는다. 또한, 서버에 대한 액세스 조건들이 악화될 때, 서비스에 대한 인터럽션(interruption) 위험이 수신기에서 발생한다.
실시간 전송 프로토콜(RTP)은, 예를 들어, 시청각 프로그램을 코딩한 데이터의 캡슐화 및 실시간 송신을 위해 사용되는 프로토콜이다. 데이터에 사용되는 코딩은 일반적으로 MPEG-TS 타입 또는 그와 동등한 포맷이다.
RTSP는 원격 매체 서버의 제어를 가능케 하는 통신 프로토콜의 일례이다. 이 프로토콜은 "PLAY" 및 "PAUSE" 등의 비디오 플레이어의 전형적인 기능들을 제공하며, 프로그램에서의 프로그램 부분의 시간적인 위치(예를 들어, 시간 인덱스 또는 파일에서의 대응 위치)로부터 시청각 프로그램의 일부분의 재생을 가능케 한다.
RTP 및 RTSP 등의 프로토콜들을 사용해서 스트리밍으로 시청각 프로그램들을 송신하는 중에, 예를 들어, 네트워크 가용성의 상당한 변경들은 프로그램들의 복구에 매우 상당한 부담을 준다. 비트율이 송신의 시작 및 종료 사이에서 동적으로 조정되지 않을 때, 인터럽션이 발생하며, 이는 사용자에게 상당히 불편하다.
RTP 전송 프로토콜은 UDP 프로토콜에 좌우되고 HTTP 프로토콜은 연결된 TCP 프로토콜에 좌우된다.
TCP는 신뢰성 제약에 대응하는 "연결(connected)" 프로토콜로서 공지되어 있으며, 서버로부터 수신기로 패킷 오류들 없이 데이터가 송신될 수 있게 한다. 이를 위해, 수신기는 데이터가 수신되는 곳으로 나타나는 서버와 통신한다. 손실된 및 재송신된 데이터에 좌우되는 것 외에, 평균 비트율은 애크놀리지먼트(acknowledgement)의 라우팅에 관련된다. 라우팅 시간이 더 빠를수록 최대 비트율이 더 많이 감소된다.
UDP는 동일한 신뢰성 제약에 대응하지 않는 프로토콜이다. 이는 "신뢰할 수 없음(non-reliable)" 및 "연결 없음(without connection)"이라고 한다. 애크놀리지먼트 시스템이 없으며 평균 비트율이 서버 및 수신기 간의 거리에 관련되지 않는다. 이것이 UDP 프로토콜이 IPTV 애플리케이션들에서 RTP와 함께 사용되는 이유이다.
2010년 6월 24일에 공개된 Kajos George W.(미국) 등의 특허 US2010/161716A1은 네트워크를 통해 클라이언트 장치로 콘텐츠를 전달하는 방법을 개시하며, 클라이언트 렌더링 용량을 나타내는 메시지는, 클라이언트의 렌더링 용량에 따라 클라이언트에 의해 완전히 디코딩될 수 있는 형태로 콘텐츠를 송신하는 서버에 의해 수신된다.
본 발명의 목적들 중 하나는 비트율을 네트워크 조건들에 동적으로 적응시킬 수 있으면서 UDP의 장점들을 조합하는 것이다.
본 발명의 목적은 종래 기술의 단점들 중 적어도 하나를 극복하는 것이며, 특히, 일부 실시간 전송/제어 프로토콜, 예를 들어, RTP 및 RTSP 프로토콜들을 사용해서 표준 IPTV 기반 구조들의 시청각 프로그램들의 송신 중에 사용되는 대역폭의 동적 제어를 가능케 하는 것이다.
본 발명에 따라 적응된 실시간 서버 제어 프로토콜의 사용은, 수신기가 연속 부분들의 시청각 프로그램의 송신을 서버로부터 요청할 수 있게 한다. 수신기는, 송신된 부분들 각각에 대해, 네트워크의 송신 조건들을 정기적으로 측정하고, 결과로서 송신 비트율을 조정한다. 송신 비트율의 조정은, 서버로부터 연속해서 요청된 프로그램의 각각의 부분에 대해, 상이한 비트율들로 코딩되고 서버에서 가용한 수개의 버전들 중에서 프로그램 버전을 수신기가 선택함으로써 수행된다. 수신기에 의한 버전의 선택은 선행 부분의 송신 중에 측정된 송신 비트율에 따라 이루어진다. 이러한 방법으로, 비트율의 조정은 프로그램 서버의 변경을 요구하지 않는다.
본 발명은 수신기에 연결된 디스플레이 장치에서의 재생을 위해 서버에 저장된 시청각 프로그램을 수신하는 방법에 관한 것으로, 시청각 프로그램은 적어도 두 버전들로 서버에서 가용하고, 버전들 각각은 프로그램의 부분들을 코딩한 데이터의 시간적인 연속 블록들을 포함하며 (따라서, 데이터의 연속 블록은 순차적으로 렌더링되고), 버전들은 동일한 수의 블록들을 각각 포함하고, 블록들은 이전 이미지를 참조하지 않고 코딩된 이미지로 각각 시작한다. 본 발명에 따라, 본 방법은, 수신기의 레벨에서, 실시간 전송 프로토콜에 따라, 제1 비트율로 서버에 의해 송신된 버전들 중 제1 버전으로부터 데이터의 적어도 한 블록을 포함하는 시청각 프로그램의 제1 부분을 수신하는 단계, 제1 비트율로 상기 서버에 의해 송신된 시청각 프로그램의 제1 부분의 수신 후에 대역폭을 결정하는 단계, 실시간 서버 제어 프로토콜에 따라, 서버에 요청을 송신하는 단계를 포함하고, 요청은 서버 및 수신기 간의 대역폭의 결정된 값에 따라 프로그램의 버전들 중 한 버전의 시청각 프로그램의 제2 부분의 식별 정보 및 송신 속도 파라미터를 포함하며, 식별 정보는 제2 부분의 시작과 끝의 시간적인 표시자들(temporal markers)을 포함한다.
본 발명의 일 실시예에에 따라, 수신 단계, 대역폭 결정 단계 및 수신기에 의한 요청 송신 단계는 시청각 프로그램의 수신 중에 반복해서 재현된다.
본 발명의 일 실시예에에 따라, 시청각 프로그램의 버전들은 서버에 저장된 단일 파일로 구성된다.
본 발명의 일 실시예에에 따라, 시청각 프로그램은 동일한 파일의 시청각 프로그램의 버전들의 로컬리제이션(localisation)과 관련된 정보를 포함하는 기술 파일(descriptive file)과 서버에서 연관된다.
본 발명의 일 실시예에에 따라, 서버 및 수신기 간의 가용 대역폭의 결정은 제1 비트율로 수신된 시청각 프로그램의 부분들의 적어도 하나의 특성의 분석을 포함한다.
본 발명의 일 실시예에에 따라, 부분들의 적어도 하나의 특성은 송신된 비트들의 수이다.
본 발명의 일 실시예에에 따라, 요청의 송신 단계는 RSTP 프로토콜의 커맨드 PLAY를 사용한다.
본 발명은 또한 서버에 의해 배포되는(diffused) 시청각 프로그램의 수신 장치에 관한 것이며, 프로그램은 적어도 두 버전들로 서버에서 가용하고, 버전들 각각은 시청각 프로그램의 이미지 해상도에 대응하며 연속 부분들을 포함하고, 버전들은 동일한 수의 부분들을 각각 포함하며, 부분들은 인트라 이미지로 각각 시작한다. 본 발명에 따라, 본 장치는, 실시간 전송 프로토콜에 따라, 제1 비트율로 상기 서버에 의해 송신된 버전들 중 제1 버전으로 시청각 프로그램의 제1 부분을 수신하는 수단, 제1 비트율로 상기 서버에 의해 송신된 상기 시청각 프로그램의 제1 부분의 수신 후에 대역폭을 결정하는 수단, 실시간 제어 프로토콜에 따라, 서버에 요청을 송신하는 수단을 포함하고, 요청은 서버 및 수신기 간의 대역폭의 결정된 값에 따라 프로그램의 버전들 중 한 버전의 시청각 프로그램의 제2 부분의 식별 정보 및 송신 속도 파라미터를 포함하며, 식별 정보는 제2 부분의 시작과 끝의 시간적인 표시자들을 포함한다.
따라서, 송신 비트율은, 더 낮은 품질 레벨로 프로그램을 복구하는 것을 의미하더라도, 네트워크에서 가용 대역폭에 적응하도록 또한 시청각 프로그램의 복구 중에 인터럽션들을 방지하도록 조정된다.
분명히, 본 발명은 RTP 및 RTSP 프로토콜들의 사용에 제한되지 않으며, 각각 RTP 및 RTSP와 유사한 특징들을 가지며, 특히 재생(렌더링)될 시청각 프로그램의 부분에 대한 버전, 시작 시간 및 길이(또는 정지 시간)를 선택할 수 있게 해주는 파라미터들과 함께 PLAY 커맨드 등의 제어 커맨드들을 제공하는 임의의 실시간 전송 프로토콜 및 대응 서버 제어 프로토콜과 관련된다.
이하의 설명을 읽을 때 본 발명은 더 잘 이해될 것이며, 다른 특정 특징들 및 장점들이 드러날 것이고, 설명은 첨부 도면들을 참조한다.
- 도 1은 본 발명의 일 실시예에 따른 수신기/디코더에 의해 시청각 프로그램들을 수신하기 위한 시스템을 도시한다.
- 도 2는 동일한 프로그램의 수개의 버전들을 포함하는 파일의 생성을 가능케 하는 코딩 방법을 도시한다.
- 도 3은 본 발명의 일 실시예에 따라 상이한 비트율들로 배포되는 코딩된 동일한 시청각 프로그램의 수개의 버전들을 포함하는 서버의 파일을 도시한다.
- 도 4는 RTP 송신 프로토콜에 따른 스트림 송신을 위한 수신기 및 서버 간의 일련의 초기화 메시지들을 도식으로 도시한다.
- 도 5는 본 발명의 일 실시예에 따른 스트림의 송신을 위한 수신기 및 서버 간의 일련의 초기화 메시지들을 도시한다.
- 도 6은 네트워크의 대역폭의 규칙적인 평가 및 네트워크의 상태에 적응된 비트율 파라미터 및 송신 속도 파라미터를 포함하는 요청들의 송신을 포함하는, 수신기에서 구현되는 방법을 도시한 도면이다.
- 도 7은 본 발명의 일 실시예에 따른 수신기의 기능도이다.
- 도 8은 도 7에 도시된 수신기의 제어 유닛을 도시한 기능도이다.
일반적으로, 그러나 제한되지 않은 방식으로, 본 발명은 대역폭의 규칙적인 측정에 의해 결정된 네트워크의 혼잡도(congestion)에 따라 프로그램의 송신에 사용된 비트율의 동적 적응을 가능케 하는, 시청각 프로그램을 스트리밍으로 수신하는 방법에 관한 것이다.
도 1은 네트워크(3)를 통해 수신기(2)에 의해 시청각 프로그램들을 수신하기 위한 시스템을 도시한다. 수신 중에, 수신기는 시청각 프로그램을 처리하고 디스플레이를 위해 디스플레이 장치(4)에 신호들을 송신한다. 프로그램들은 코딩되고 프로그램 서버(1)에서 가용하다. 프로그램들은 디지털 파일들의 형태로 저장된다. 복구 중에 가변 비트율들로 프로그램들의 송신을 허가하는 송신 기술들은 프로그램을 코딩한 데이터의 송신 중에 상이한 비트율들에 대응하는 상이한 버전들로 시청각 프로그램을 서버에서 가용하게 하기 위해 특정 코딩을 요구한다. 동일한 시청각 프로그램의 상이한 버전들은 프로그램 서버(1)에 저장된다. 상이한 버전들은 개별 파일들에 저장되거나 또는 단일 파일에 함께 있을 수 있으며, 파일의 각각의 위치들에 의해 식별될 수 있다. 프로그램들 각각과 연관된 기술 파일(description file)은 상이한 버전들, 그 각각의 비트율들 및 그 위치들과 관련된 정보를 포함한다. 이 정보는 서버로부터 수신기로의 프로그램 송신의 초기화 단계 중에 수신기에 송신된다.
도 2는 네트워크에서의 송신 조건들에 따라 비트율을 조정해서 송신되게 하기 위한 시청각 프로그램의 코딩을 도시한다. 시청각 프로그램은 수개의 버전들로 코딩된다. 버전들 각각은 이미지 해상도 및 따라서 송신 비트율에 대응한다. 버전들 각각에서, 프로그램은 연속 블록들 또는 이미지 그룹들로 구성된다. 모든 블록들은 프로그램의 기본(elementary) 복구(또는 재생) 지속 기간, 예를 들어, 2초에 대응한다. 이 기본 블록들은, 예를 들어, HTTP 적응 스트리밍 기술의 경우, 통상 청크들이라고 한다. 블록들 각각의 제1 이미지는 인트라 이미지이다. 인트라 이미지는 선행 이미지를 참조하지 않고 코딩되는 것으로 정의된다. 블록의 시작에서 인트라 이미지들의 위치는 버전들 각각에서 동일하다. 따라서, 수신기가 시청 콘텐츠와 관련하여 프로그램의 연속성으로, 그러나 다른 버전으로 따라서 다른 송신 비트율로 다음 블록을 전달할 것을 서버에 요청하면, 수신기에 통합된 디코더는 이전 이미지들에 대한 문제점들을 참조하지 않고 블록의 디코딩을 수행할 수 있다. 도 2는 500 Kbit/s, 1 Mbit/s, 1.5 Mbit/s 및 2 Mbit/s의 수신(및 따라서 송신) 비트율들에 각각 대응하는 버전들로의 프로그램의 코딩을 기술한다.
도 3은, 예를 들어, 도 2에 도시된 코딩 방법에서와 같이, 동일한 시청각 프로그램의 수개의 버전들(31, 32, 33, 34)을 포함하는 파일(30)을 도시한다. 상이한 버전들은 상이한 인덱스들로 동일한 파일에 배치된다. 프로그램의 송신 중의 한 버전으로부터 다른 버전으로의 패스는 따라서 재생 포인터에 대한 인덱스의 추가에 대응한다. 시청각 프로그램의 버전은 포인터에 추가된 가능한 인덱스 값들 각각에 대응한다. 포인터는 복구될 프로그램의 부분의 시간적인 위치를 식별한다.
도 4는 RTP 송신 표준을 사용하는 본 발명의 일 실시예에 따른 수신기 및 배포 서버(diffusion server) 간의 통신의 설정을 도시한다. RTP 프로토콜을 사용하는 배포의 초기화 중에, 수신기는 수신기에 연결된 디스플레이 장치에서 시청될 프로그램과 관련된 정보를 서버로부터 획득하기 위해 서버에 대한 url을 포함하는 RTSP DESCRIBE 라는 제목의 제1 메시지를 어드레싱한다. 용어 url(uniform resource locator)은 본 명세서에서는 시청될 프로그램을 포인팅하는 네트워크 어드레스를 기술한다. 이 어드레스는, 예를 들어, 구문 "multimedia.exemple.com"을 가진다. 서버는 RTSP DESCRIBE RESPONSE 라는 제목의 응답 메시지로 수신기에 정보를 어드레싱한다. 메시지 RTSP DESCRIBE RESPONSE는 프로그램 버전들이 별개의 파일들로 서버에 저장되어 있는지 또는 단일 파일로 결부되어 있는 지를 수신기에 나타낸다. 다음으로, RTSP SETUP이라는 제목의 제2 요청이 프로그램의 스트리밍 세션을 준비하기 위해 수신기를 통해 서버에 어드레싱된다. 프로그램의 상이한 버전들이 서버에서 별개의 파일들로 저장되면, 수신기는 가용한 버전들이 있는 만큼 다수의 송신 세션들로 서버와 함께 초기화할 것이다. 상이한 버전들이 서버에서 동일한 파일에 결부되면, 수신기는 단일 송신 세션을 개시한다. 프로그램의 상이한 버전들이 동일한 파일에 결부된 경우에, 수신기는 프로그램의 한 버전으로부터 다른 버전으로 이동하기 위해 재생 포인터에 인덱스를 추가해서, 재생 프로그램 부분의 송신 비트율을 조정할 것이다. 수신기에 의한 세션의 각각의 초기화 요청에 대해, 서버는 RTSP SETUP RESPONSE 라는 제목의 메시지로 응답한다. 수신기에 의해 송신된 RTSP PLAY라는 제목의 제3 메시지는 서버에 의해 프로그램의 송신을 시작한다. 메시지 RTSP PLAY는 여전히 요청이라고 불리며 복구를 목적으로 송신될 프로그램의 부분의 시간적인 표시자 파라미터를 포함한다. PLAY 메시지는 송신될 프로그램 부분에 대응하는 데이터를 송신하는 속도를 서버에게 나타내는 속도 파라미터를 또한 포함한다.
본 발명의 일 실시예에 따라, 시청각 프로그램의 콘텐츠는 비디오의 H.264 코덱들 및 오디오의 AAC 코덱들에 따라 코딩되고, 인트라 이미지로 시작하는 기본 데이터의 블록의 크기는 복구시 2초 지속 기간에 대응하며, 데이터의 캡슐화는 MPEG 전송 스트림 포맷에 따라 실행되고, 상이한 버전들과 연관된 비트율들은 500 Kbit/s, 1 Mbit/s, 1.5 Mbit/s 및 2 Mbit/s이다. 서버에서 시청각 프로그램 콘텐츠 파일과 연관되고 프로그램의 상이한 버전들 및 상이한 연관된 비트율들에 대한 정보를 포함하는 기술 파일은, 예를 들어, 이하의 형태를 가진 SDP 포맷 파일이다:
Figure 112013103481117-pct00001
Figure 112013103481117-pct00002
이 SDP 파일 일례에서, 4개의 스트림들(MPEG 전송 스트림들)이 주목되고, Mbit/s로 표현된 비트율에 대응하는 파라미터 b=TIAS를 사용해서 각각의 비트율들과 연관된다.
도 5는 본 발명의 일 실시예에 따른 및 시청될 프로그램의 상이한 버전들이 서버에 개별 파일들로 저장될 때의 수신기 및 배포 서버 간의 통신의 설정을 도시한다. 수신기는 상이한 스트림들로부터 복구될 시청각 프로그램 부분의 수신을 초기화한다. 복구(restitution) 중에, 연속해서 요청된 각각의 프로그램 부분에 대해, 수신기는 네트워크에서의 대역폭 조건에 적응된 버전을 서버에 나타내고 대응 스트림의 데이터를 수신한다. 각각의 스트림은 동일한 버전으로부터의 데이터의 송신에 대응한다. 일 실시예에 따라, 수신기는, 송신 전에, 가용 버전들이 있는 만큼 다수의 초기화 메시지들을 어드레싱한다.
초기화 단계(SETUP)가 버전들 각각에 대해 완료되었으면, 수신기는, 송신 속도뿐만 아니라, 요구된 블록에 대응하는 버전 및 시간적인 인터벌을 (시간적인 표시자들을 사용해서) 명시하는 PLAY 요청을 송신함으로써 한 버전으로부터 다른 버전으로 패스할 수 있다. 다른 실시예들에 따라, 수신기는, 송신 중에, 한 버전에 대한 제1 액세스 전에 SETUP 초기화 요청들을 어드레싱할 수 있다.
도 6은, 본 발명의 일 실시예에 따른, 수신기에 의해 사용된 방법을 도시한 블록도이다. 단계 S1은 수신기가 스트리밍으로 프로그램의 수신을 초기화하지 않은 초기 단계이다. 이 단계에서, 수신기는 수신기를 제어하는 사용자로부터의 커맨드에 대한 대기 상태(on standby)이다. 단계 S2에서, 수신기는 스트리밍 배포 세션을 초기화한다. 복구를 위해 서버로부터 수신될 시청각 프로그램의 목표 url 어드레스를 명시하는 제1 RTSP DESCRIBE 메시지를 송신한다. 이 url 어드레스는, 예를 들면, rtsp://exemple.com/movie/일 수 있다. 이 목표 어드레스는 배포의 제어에 대한 참조로서 작용한다. 서버는, 상이한 비트율들로 배포되도록 코딩된, 시청각 프로그램의 상이한 버전들에 대응하는 송신 스트림 속성들을 수신기에게 나타내는 RTSP DESCRIBE RESPONSE 타입 메시지를 어드레싱한다. 이 정보는 버전들의 수, 그 각각의 식별자들, 코딩 비트율들 및 데이터의 블록들의 크기를 포함한다. 이하의 메시지 교환, 즉, 수신기로부터 송신된 RTSP SETUP 및 서버로부터 송신된 RTSP SETUP RESPONSE는 스트리밍 배포 세션을 준비한다. 수신기는 초기화 단계 S2에서 수신된 정보를 저장하고, 시청각 프로그램의 부분들(데이터의 하나의 또는 수개의 블록들을 포함함)의 배포 및 수신을 위해 연속 RTSP PLAY 요청들을 어드레싱할 수 있다. 단계 S3에서, 수신기는 수신될(따라서 서버에 의해 배포될) 프로그램들의 부분의 배포에 특정한 파라미터들을 포함하는 RTSP PLAY 요청을 송신한다.
본 발명의 일 실시예에 따른 RTSP PLAY 요청의 구조는 다음과 같다:
Figure 112013103481117-pct00003
여기서, PLAY는 요청이 복구를 목적으로 데이터의 블록의 배포를 요청하는 메시지임을 나타낸다.
Cseq는 초기화 단계 S2에서 서버에 의해 표시된 시퀀스 번호를 나타내고, Range는 배포의 시작으로부터 0 내지 2초의 시간적인 위치에 대응하는 프로그램 부분을 나타내며, Speed는 배포 속도를 나타낸다.
시청각 프로그램의 복구 중에 인터럽션들을 방지하기 위해, 수신기는 수신 버퍼에서 충분한 양의 데이터를 유지하기 위해 다음 프로그램 부분에 대한 RTSP PLAY 요청들을 예상하여(in anticipation) 어드레싱한다. 우선적으로, 수신 버퍼는 디코딩 전에 수신되고 가용한 2초의 프로그램을 포함한다. 유익하게, 네트워크에서의 가용 대역폭의 변동들을 흡수하기 위해, 수신 버퍼는 송신된 시청각 프로그램의 수초의 복구에 대응하는 데이터의 항목들의 수를 포함할 수 있다.
본 발명의 일 실시예에 따라, 또한, 간소화를 위해, 상이한 버전들로부터의 데이터 블록들의 배포는 단일 RTSP 세션 중에 실행된다. 따라서, 코딩된 프로그램의 상이한 버전들을 서버에서 단일 파일로 결부시키는 것이 유익하다.
지속 기간 d의 시청각 프로그램이 비트율 B0 = 500 Kbps, B1 = 1 Mbps, B2 = 1.5 Mbps 및 B3 = 2 Mbps로 코딩되었다고 생각하면, 코딩된 프로그램의 i번째 버전에 대한 액세스가 시간적인 위치 t로부터 비트율 Bi로 코딩되었으면, 대응 RTSP PLAY 요청의 Range 파라미터는 이하의 방법으로 정의될 것이다:
Figure 112013103481117-pct00004
단계 S4에서, 수신기는 서버에서 목표한 프로그램의 부분을 코딩한 데이터 블록을 수신한다. 수신기는 이 데이터의 블록을 수신 버퍼에 저장하고, 여기서 이 데이터 블록이 수신기의 오디오/비디오 디코딩 모듈에 의해 판독될 것이다.
단계 S5는, 이것이 배포가 종료하는 경우이면, S4에서 이전에 수신된 부분이 프로그램의 마지막인 지를 정의한다.
단계 S6에서, 시간적인 위치의 견지에서, S4에서 수신된 데이터의 부분이 시청각 프로그램의 마지막이 아닌 경우에, 수신기는 네트워크에서 가용 대역폭의 추정을 수행한다.
대역폭의 추정은, 본 발명의 일 실시예에 따라, 서버로부터 가능한 배포 비트율의 정의를 위한 단계들 및 미리 정의된 기간 동안의 비트율의 측정을 위한 단계들을 포함한다. 유익하게, 대역폭의 추정은 가중화 단계를 포함할 수 있다. 본 발명의 일 실시예에 따라, 가중화 단계는 이 값 주변의 대역폭의 신속한 변화들을 극복하는 평균 값이 획득될 수 있게 하는 평활화 또는 통합 단계를 포함한다. 수신기는 네트워크 대역폭의 신속한 변화들을 흡수할 수 있는 버퍼 메모리(수신 버퍼)를 포함한다.
본 발명에 따라, 대역폭의 추정은 데이터의 기본 블록들 각각에 대해 또는 데이터의 미리 정의된 수의 기본 블록들을 포함하는 프로그램의 부분에 대해 반복될 수 있다.
본 발명의 일 실시예에 따라, 수신기는 대역폭 추정을 수행하기 위해 RTSP PLAY 요청에 응답해서 서버에 의해 송신된 정보를 사용한다.
RTSP PLAY 요청에 대해 서버에 의해 송신된 응답은 이하의 형태를 가진다:
Figure 112013103481117-pct00005
여기서, rtptime은 인터벌 npt에 의해 표시된 프로그램의 부분의 시작을 나타내는 시간적인 표시자이다.
예를 들어, 클럭 프로그램(clock programme)이 송신 세션의 초기화 단계에서 수신기에 전달된, 9000의 값을 가진 MPEG-2 TS 포맷으로 코딩된 스트림으로 생각되면, 수신기는 데이터의 블록의 수신 시간에 대응하는 시간 인터벌 rangeduration을 계산할 수 있다:
Figure 112013103481117-pct00006
여기서, rtptime start는 서버 응답의 정보 필드 RTP-Info에 표시된 파라미터 rtptime의 값이고,
rtptime end = 필드 RTP-Info의 rtptime + 90000
여기서, 90000은 배포 세션의 초기화 단계 중에 표시된 클럭 RTP이다.
다음으로, 데이터의 블록의 수신 기간 동안의 순간 비트율은 시간 인터벌 동안 수신된 데이터의 바이트들(RTP 프로토콜에 따른 배포의 데이터의 패킷들을 구성하는 바이트들)의 수를 더하고, 바이트들의 수를 8로 곱해서 비트들(바이너리 요소들)의 수를 획득하고, 곱셈의 결과를 수신 지속 기간으로 나눔으로써 계산된다.
즉, 순간 비트율의 표현은:
Figure 112013103481117-pct00007
따라서, 본 발명의 일 실시예에 따라, 계산된 순간 비트율의 값은 더 정확한 비트율 값을 정의하기 위해 평활화 알고리즘에서 사용된다.
알고리즘은 이전 반복들에서 계산된 순간 비트율들의 값들을 고려하여 획득될 수 있는 비트율을 결정하기 위해 반복 프로세스를 사용한다:
i는 수신된 데이터의 송신 중에 유용한 비트율 및 그 분산의 계산의 i번째 반복을 나타내는 인덱스이다.
따라서, 다음 반복에서 차후 비트율의 추정은 다음과 같이 계산된다:
Figure 112013103481117-pct00008
여기서, Bi는 측정된 비트율이고,
avgi는 현재 반복에서 계산된 평균이며,
α는 순간 비트율의 측정된 값에 기인한 가중화 인자(weighting factor)이다.
우선적으로, α의 값은 1/16과 동일하다.
가중 평균 값 외에, 본 발명에 의해 사용된 알고리즘은 비트율에 대한 분산을 추정한다. 분산은 비트율과 동일한 방법으로 평활화된다:
Figure 112013103481117-pct00009
여기서, △i는 측정된 비트율 및 계산의 현재 반복의 평균 비트율 간의 차이이고,
vari는 현재 반복에서 계산된 분산이며,
β는 현재 추정의 분산 값에 대한 가중화 인자이다.
우선적으로, β의 값은 1/8과 동일하다.
알고리즘의 반복들 각각에 대해, 시청각 프로그램의 배포에 대해 달성될 수 있는 비트율의 추정은 다음과 같이 계산된다:
Figure 112013103481117-pct00010
따라서, 분산이 크면, 이는 수신기가 평균보다 더 작은 가용 대역폭을 사용함을 의미한다. 더욱이, 대역폭이 안정적이고 분산이 작으면, 수신기는 서버 및 수신기 간에 가용한 모든 대역폭을 사용한다.
유익하게, 수신기가 모든 가용 대역폭을 사용하는 경우에, 매우 규칙적인 요청들로 서버를 오버로딩함을 방지하기 위해, 수신된 프로그램의 수개의 기본 부분들을 함께 그룹화하는 것을 목적으로 RTSP PLAY 요청들을 서버에 어드레싱한다. 수신기는, 예를 들어, 데이터의 2개의 또는 4개의 기본 블록들을 서버에 대한 동일한 요청으로 요청할 수 있다.
본 발명의 일 실시예에 따라, 분산이 너무 클 때, 예를 들어, 그 값이 비트율의 값의 1/2보다 더 크면, 비트율 및 분산의 추정들은 다음과 같이 계산된다:
Figure 112013103481117-pct00011
및
Figure 112013103481117-pct00012
본 발명의 일 변형에 따라, 수신기는 네트워크가 시청각 프로그램의 동일한 버전을 포인팅하고 RTSP 제어 프로토콜에서 정의된 속도 파라미터를 변경함으로써 현재 비트율보다 더 큰 비트율로 배포를 허용하는 지를 결정한다. 현재 비트율이, 예를 들어, 1.5 Mbit/s이면, 수신기는 값 Speed = 1.34인 "Speed" 파라미터를 명시하는 요청을 서버에 송신함으로써 2 Mbit/s로 송신하기 위해 네트워크의 용량을 평가한다.
현재 배포 비트율이 1.5 Mbit/초이면서, url "multimedia.exemple.com/stream"을 통해 로케이팅된 시청각 프로그램의 제2 초 및 제4 초 사이의 시간 인터벌에 대응하는 데이터의 블록을 수신하기 위해 송신된 RTSP 요청이 2 Mbit/s의 비트율을 가지면, 예를 들어, 이하의 형태를 가진다:
Figure 112013103481117-pct00013
단계 S7에서, 수신기는 가용 대역폭 및 대역폭 변화의 계산의 결과를 고려해서 서버에 어드레싱할 요청의 파라미터들을 정의한다. 본 발명의 일 실시예에 따라, 수신기는 대역폭 및 분산의 계산된 값들의 조합들에 따라 RTSP 요청의 속도 파라미터를 변경한다. 예를 들어, 본 발명의 일 변형에 따라, 송신 속도의 감소뿐만 아니라, 데이터의 손실을 야기할 수 있는 네트워크의 혼잡의 경우에, 수신기는 더 낮은 비트율로 또한 증가된 송신 속도로 대응 버전에서 손실된 데이터를 수신하기 위해 새로운 요청을 수행한다. 더 낮은 비트율 및 증가된 송신 속도의 사용은, 한편, 서버 및 수신기 간에 이동하는 데이터의 양을 감소시킬 수 있지만, 또한 서버에 의해 이전에 송신된 데이터의 손실로부터 야기된 시간의 손실을 신속하게 보상한다. 본 발명의 일 실시예에 따라, 수신기는 프로그램의 부분의 송신 중에 데이터의 손실을 검출하기 위해 데이터를 전송하는 RTP 패킷의 헤더의 시퀀스 번호를 사용한다. 데이터의 손실 및 데이터를 재송신할 의무는 수신 버퍼의 채움율(filling rate)을 감소시키고 프로그램의 복구 중에 버퍼에서의 데이터의 손실에 연결된 아티팩트들(artefacts)로부터의 위험을 증가시키는 결과를 갖는다. 유익하게, 그 후, 수신기는 미리 기술된 알고리즘을 재구현하기 전에 더 낮은 비트율 및 1보다 더 큰 속도 파라미터를 나타내는 RTSP PLAY 요청을 어드레싱한다.
도 7은 본 발명의 일 실시예에 따른 시청각 프로그램의 수신 및 디스플레이에 적응된 수신 장치(2)를 도시한다. 양방향 네트워크 인터페이스(201)는 복구될 시청각 프로그램을 코딩한 데이터의 수신을 가능케 한다. 인터페이스(201)는 또한 배포 서버와의 제어 메시지들의 송신 및 수신을 가능케 한다. 디멀티플렉서(202)는 제어 메시지들뿐만 아니라 수신 플럭스로부터의 프로그램의 수신과 관련된 데이터를 필터링하고 수신 버퍼(203)에 이들을 저장한다. 시청각 프로그램을 코딩한 데이터는 이들을 디코딩하여 대응 신호들을 출력 인터페이스(205)에 송신하는 오디오/비디오 디코더(204)에 의해 판독된다. 출력 인터페이스(205)에 연결된 디스플레이 장치(도시되지 않음)는 사용자를 위한 프로그램의 디스플레이를 가능케 한다. 소자들(201, 202, 203, 204 및 205)의 집합은 본 발명의 일 실시예에 따라 데이터의 처리뿐만 아니라 소프트웨어 루틴들의 실행을 가능케 하는 마이크로-컨트롤러 및 연관된 메모리들을 포함하는 제어 유닛(200)에 의해 제어된다. 제어 유닛(200)은 또한 서버로부터 수신시 제어 메시지들을 분석하고 서버에 송신되는 제어 메시지들을 생성한다.
도 8은 본 발명의 일 실시예에 따른 제어 유닛(200)을 도시한다. 제어 유닛은 소프트웨어 애플리케이션들의 실행의 책임이 있는 마이크로컨트롤러(210)를 포함한다. 애플리케이션들의 실행 가능한 코드는 수신기(2)의 스타트업시 비휘발성 메모리(211)에 저장되고, 수신기(2)가 동작할 때 작업 메모리(212)에 복사될 수 있다. 작업 메모리(212)는 소프트웨어 애플리케이션들의 실행에 특정한 데이터의 저장 및 수신된 데이터의 저장을 위한 랜덤 액세스 메모리를 포함한다. 제어 유닛(200)은 또한 대역폭의 추정을 위한 모듈(213)을 포함한다. 대역폭 추정 모듈(213)은 수신 버퍼로부터 판독된 데이터를 사용해서 서버 및 수신기(2) 간의 링크에서 가용 대역폭을 계산한다. RTSP 제어 모듈(214)은 추정 모듈(213)에서 계산되고 가용한 대역폭의 값에 따라 RTSP 요청을 구성한다. RTSP 제어 모듈은 수신 버퍼에서 RTSP PLAY 요청에 대한 응답을 구성하는 데이터를 판독하고 추정 모듈(213)에 시간적인 표시자 rtptime을 전달한다. 제어 유닛(200)의 상이한 모듈들 간에 교환되는 데이터는 내부 버스(216)를 통해 이동한다. 수신기의 다른 기능 모듈들과의 데이터 집합의 교환들은 인터페이스 모듈(215)을 통해 수행된다.
본 발명은 RTP 및 RTSP 프로토콜들에 기초하여 일 실시예로 본 명세서에 기술되지만, 본 발명은 명백히 RTP 및 RTSP 프로토콜들의 사용에 제한되지 않는다. 본 발명은 또한 각각 RTP 및 RTSP와 유사한 특징들을 가지며 특히 재생(렌더링)될 시청각 프로그램의 부분에 대한 버전, 시작 시간 및 길이(또는 정지 시간)를 정의(선택)할 수 있게 해주는 파라미터들과 함께 PLAY 커맨드 등의 제어 커맨드들을 제공하는 임의의 실시간 전송 프로토콜 및 대응 서버 제어 프로토콜과 관련된다.

Claims (15)

  1. 통신 네트워크의 수신기 장치에서 수행되어, 상기 통신 네트워크의 서버에 저장된 시청각 프로그램을 적어도 두 개의 버전으로 수신하기 위한 방법으로서,
    상기 버전들 각각은 상이한 코딩 비트 레이트를 가지며 연속해서 렌더링될 상기 시청각 프로그램의 부분들을 각각 나타내는 데이터의 연속 블록들을 포함하고, 상기 방법은,
    제1 송신 속도로 수신된 상기 시청각 프로그램의 제1 버전의 제1 부분을 수신한 후에 상기 서버와 상기 수신기 장치 사이의 가용 대역폭을 결정하는 단계 - 상기 제1 버전은 제1 코딩 비트 레이트에 대응함 - , 및
    상기 시청각 프로그램의 제2 부분을 수신하기 위한 실시간 스트리밍 프로토콜 요청을 송신하는 단계
    를 포함하고,
    상기 제2 부분을 수신하기 위한 요청은 상기 버전들 중 제2 버전 및 제2 송신 속도를 지정하는 제2 코딩 비트 레이트를 포함하고, 상기 요청된 제2 코딩 비트 레이트 및 상기 요청된 제2 송신 속도는 상기 가용 대역폭의 값을 고려하고,
    혼잡 또는 패킷 손실의 경우에, 상기 제2 송신 속도는 상기 제1 송신 속도에 비해 증가된 송신 속도인 방법.
  2. 제1항에 있어서,
    상기 서버와 상기 수신기 장치 사이의 가용 대역폭을 결정하는 단계는 상기 제1 부분에 이전에 수신된 상기 시청각 프로그램의 상기 부분들 중 적어도 한 부분에 대한 가용 대역폭을 고려하는 방법.
  3. 제1항 또는 제2항에 있어서,
    상기 결정하는 단계는 상기 제1 부분의 수신 지속 기간 및 상기 제1 부분의 비트들의 수를 고려하는 방법.
  4. 제1항 또는 제2항에 있어서,
    요청을 송신하는 것은 RTSP 프로토콜의 PLAY 커맨드를 사용하는 방법.
  5. 제1항 또는 제2항에 있어서,
    상기 대역폭을 결정하는 단계는 RTSP 프로토콜의 PLAY 커맨드에 대한 상기 서버의 응답을 사용하는 방법.
  6. 제1항 또는 제2항에 있어서,
    상기 요청된 제2 코딩 비트 레이트가 상기 제1 코딩 비트 레이트보다 클 때, 상기 제2 부분을 수신하기 위한 상기 요청을 송신하는 단계 전에 상기 시청각 프로그램의 제3 부분을 수신하기 위한 요청을 송신하는 단계를 포함하고,
    상기 제3 부분을 수신하기 위한 상기 요청은 상기 제1 부분에 대해 상기 수신기 장치에 의해 요청되었던 제1 송신 속도보다 큰 제3 송신 속도 및 상기 제1 버전을 지정하는 상기 제1 코딩 비트 레이트를 포함하고,
    상기 제2 부분을 수신하기 위한 상기 요청을 송신하는 단계는 상기 요청된 제2 송신 속도로 상기 제3 부분을 송신하기 위한 상기 통신 네트워크의 용량에 따라 수행되고,
    상기 제2 부분을 수신하기 위한 상기 요청을 송신하는 단계는 상기 제3 송신 속도로 상기 제1 버전의 상기 제3 부분을 송신하기 위한 상기 네트워크의 능력에 따라 수행되는 방법.
  7. 통신 네트워크의 서버에 저장된 시청각 프로그램을 적어도 두 개의 버전으로 수신하기 위한 통신 네트워크 장치로서,
    상기 버전들 각각은 상이한 코딩 비트 레이트를 가지며 연속해서 렌더링될 상기 시청각 프로그램의 부분들을 각각 나타내는 데이터의 연속 블록들을 포함하고, 상기 통신 네트워크 장치는,
    제1 송신 속도로 수신된 상기 시청각 프로그램의 제1 버전의 제1 부분을 상기 통신 네트워크 장치의 네트워크 인터페이스에 의해 수신한 후에 상기 서버와 상기 통신 네트워크 장치 사이의 가용 대역폭을 결정하는 제어 유닛 - 상기 제1 버전은 제1 코딩 비트 레이트에 대응함 - ,
    상기 시청각 프로그램의 제2 부분을 수신하기 위한 실시간 스트리밍 프로토콜 요청을 송신하는 제1 네트워크 인터페이스
    를 포함하고,
    상기 제2 부분을 수신하기 위한 요청은 상기 버전들 중 제2 버전 및 제2 송신 속도를 지정하는 제2 코딩 비트 레이트를 포함하고, 상기 요청된 제2 코딩 비트 레이트 및 상기 요청된 제2 송신 속도는 상기 결정된 가용 대역폭의 값을 고려하고,
    혼잡 또는 패킷 손실의 경우에, 상기 제2 송신 속도는 상기 제1 송신 속도에 비해 증가된 송신 속도인 통신 네트워크 장치.
  8. 제7항에 있어서, 상기 서버와 수신기 장치 사이의 가용 대역폭을 결정하는 것은 상기 제1 부분에 이전에 수신된 상기 시청각 프로그램의 상기 부분들 중 적어도 한 부분에 대한 가용 대역폭을 고려하는 통신 네트워크 장치.
  9. 제7항 또는 제8항에 있어서,
    상기 결정은 상기 제1 부분의 수신 기간 및 상기 제1 부분의 비트 수를 고려하는 통신 네트워크 장치.
  10. 제7항 또는 제8항에 있어서,
    요청을 송신하는 것은 RTSP 프로토콜의 PLAY 커맨드를 사용하는 통신 네트워크 장치.
  11. 제7항 또는 제8항에 있어서,
    상기 요청된 제1 코딩 비트 레이트는 상기 제1 버전을 지정하는 코딩 비트 레이트보다 낮고 상기 요청된 제1 송신 속도는 상기 제1 부분에 대해 요청된 송신 속도보다 큰 통신 네트워크 장치.
  12. 제7항 또는 제8항에 있어서,
    상기 제1 네트워크 인터페이스는,
    상기 요청된 제2 코딩 비트 레이트가 상기 제1 코딩 비트 레이트보다 클 때, 상기 제2 부분을 수신하기 위한 상기 요청을 송신하기 전에 상기 시청각 프로그램의 제3 부분을 수신하기 위한 요청을 송신하도록 구성되고,
    상기 제3 부분을 수신하기 위한 상기 요청은 상기 제1 부분에 대해 요청되었던 제1 송신 속도보다 큰 제3 송신 속도 및 상기 제1 버전을 지정하는 상기 제1 코딩 비트 레이트를 포함하고,
    상기 제2 부분을 수신하기 위한 상기 요청을 송신하는 것은 상기 제3 송신 속도로 상기 제1 버전의 상기 제3 부분을 송신하기 위한 상기 통신 네트워크의 용량에 따라 수행되는 통신 네트워크 장치.
  13. 서버에 저장된 시청각 프로그램을 적어도 두 개의 버전으로 통신 네트워크에서 배포하기(diffusing) 위한 서버로서,
    상기 버전들 각각은 상이한 코딩 비트 레이트를 가지며 연속해서 렌더링될 상기 시청각 프로그램의 부분들을 각각 나타내는 데이터의 연속 블록들을 포함하고, 상기 서버는 적어도,
    제1 송신 속도로 수신된 상기 시청각 프로그램의 제1 버전의 제1 부분을 수신 장치에 송신하는 송신기 - 상기 제1 버전은 제1 코딩 비트 레이트에 대응함 - , 및
    상기 시청각 프로그램의 제2 부분을 수신하기 위한 실시간 스트리밍 프로토콜 요청을 수신하는 수신기
    를 포함하고,
    상기 제2 부분을 수신하기 위한 상기 요청은 상기 버전들 중 제2 버전 및 제2 송신 속도를 지정하는 제2 코딩 비트 레이트를 포함하고, 상기 요청된 제2 코딩 비트 레이트 및 상기 요청된 제2 송신 속도는 상기 서버와 상기 수신 장치 사이의 가용 대역폭의 값을 고려하며, 상기 가용 대역폭은 상기 시청각 프로그램의 상기 제1 부분의 상기 수신 장치로의 전달에 의해 결정되고,
    혼잡 또는 패킷 손실의 경우에, 상기 제2 송신 속도는 상기 제1 송신 속도에 비해 증가된 송신 속도인 서버.
  14. 제13항에 있어서,
    상기 송신기는 상기 버전들의 특성들을 나타내는 메시지를 상기 수신 장치로 어드레싱하고, 상기 메시지는 상기 버전들의 코딩 비트 레이트들을 포함하는 서버.
  15. 제13항 또는 제14항에 있어서,
    상기 제1 부분 및/또는 상기 제2 부분은 몇몇 데이터 블록들을 함께 그룹화하는 서버.
KR1020137030154A 2011-05-18 2012-05-04 수신 비트율 및 연관된 수신기의 동적 적응 방법 KR102012528B1 (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
FR1154334 2011-05-18
FR1154334A FR2975555A1 (fr) 2011-05-18 2011-05-18 Methode d'adaptation dynamique du debit de reception et recepteur associe
PCT/EP2012/058187 WO2012156211A1 (en) 2011-05-18 2012-05-04 Method for dynamic adaptation of the reception bitrate and associated receiver

Publications (2)

Publication Number Publication Date
KR20140023983A KR20140023983A (ko) 2014-02-27
KR102012528B1 true KR102012528B1 (ko) 2019-08-20

Family

ID=46025738

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020137030154A KR102012528B1 (ko) 2011-05-18 2012-05-04 수신 비트율 및 연관된 수신기의 동적 적응 방법

Country Status (14)

Country Link
US (1) US10015225B2 (ko)
EP (1) EP2710778B1 (ko)
JP (1) JP6436772B2 (ko)
KR (1) KR102012528B1 (ko)
CN (1) CN103548318B (ko)
CA (1) CA2835384A1 (ko)
FR (1) FR2975555A1 (ko)
HK (1) HK1194882A1 (ko)
HU (1) HUE026744T2 (ko)
MX (1) MX2013013373A (ko)
MY (1) MY168875A (ko)
RU (1) RU2598805C2 (ko)
TW (1) TWI573450B (ko)
WO (1) WO2012156211A1 (ko)

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2015139726A1 (en) * 2014-03-17 2015-09-24 Telefonaktiebolaget L M Ericsson (Publ) Congestion level configuration for radio access network congestion handling
GB2519391B (en) * 2014-04-02 2015-10-21 Imagination Tech Ltd Enhanced media quality management
US9767101B2 (en) * 2014-06-20 2017-09-19 Google Inc. Media store with a canonical layer for content
EP3035628A1 (en) * 2014-12-18 2016-06-22 Alcatel Lucent Method for analyzing a bitrate of user traffic of a data communication over a data communications line, and related devices
KR102313485B1 (ko) 2015-04-22 2021-10-15 삼성전자주식회사 가상현실 스트리밍 서비스를 위한 영상 데이터를 송수신하는 방법 및 장치
CN104934049B (zh) * 2015-06-24 2018-03-16 深圳市九洲电器有限公司 一种变比特率mp3播放时间获取方法及系统
EP3863296B1 (en) * 2017-09-11 2023-11-22 Tiledmedia B.V. Streaming frames of spatial elements to a client device
US10484730B1 (en) * 2018-01-24 2019-11-19 Twitch Interactive, Inc. Chunked transfer mode bandwidth estimation
US11875478B2 (en) * 2020-08-28 2024-01-16 Nvidia Corporation Dynamic image smoothing based on network conditions

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090089445A1 (en) * 2007-09-28 2009-04-02 Deshpande Sachin G Client-Controlled Adaptive Streaming
US20100235472A1 (en) * 2009-03-16 2010-09-16 Microsoft Corporation Smooth, stateless client media streaming
US20110082945A1 (en) * 2009-08-10 2011-04-07 Seawell Networks Inc. Methods and systems for scalable video chunking
JP2011087103A (ja) * 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供

Family Cites Families (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1022884A1 (en) * 1999-01-25 2000-07-26 CANAL+ Société Anonyme Address assignment in a digital transmission system
US6763392B1 (en) * 2000-09-29 2004-07-13 Microsoft Corporation Media streaming methods and arrangements
TWI256250B (en) * 2001-05-10 2006-06-01 Ibm System and method for enhancing recorded radio or television programs with information on the world wide web
FI116498B (fi) 2002-09-23 2005-11-30 Nokia Corp Kaistanleveyden mukauttaminen
WO2004072764A2 (en) * 2003-02-13 2004-08-26 Nokia Corporation Method for signaling client rate capacity in multimedia streaming
EP1463309A1 (fr) * 2003-03-26 2004-09-29 THOMSON Licensing S.A. Traitement d'un format de flux de données pour la réception audiovisuelle mobile
US8868772B2 (en) 2004-04-30 2014-10-21 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
JP2007036666A (ja) * 2005-07-27 2007-02-08 Onkyo Corp コンテンツ配信システム、クライアント及びクライアントプログラム
EP1879346A1 (en) 2006-07-14 2008-01-16 Sony Service Centre (Europe) N.V. System and method of audio/video streaming
US8773494B2 (en) 2006-08-29 2014-07-08 Microsoft Corporation Techniques for managing visual compositions for a multimedia conference call
US8873932B2 (en) * 2007-12-11 2014-10-28 Cisco Technology, Inc. Inferential processing to ascertain plural levels of picture interdependencies
US20090259756A1 (en) * 2008-04-11 2009-10-15 Mobitv, Inc. Transmitting media stream bursts
US7921222B2 (en) * 2008-05-06 2011-04-05 Vantrix Corporation Method and system for fast channel switching using standard RTSP messages
JP5322518B2 (ja) 2008-07-08 2013-10-23 キヤノン株式会社 通信方法
US20100121974A1 (en) 2008-11-11 2010-05-13 Einarsson Torbjoem Stepwise probing for adaptive streaming in a packet communication network
US20100161716A1 (en) * 2008-12-22 2010-06-24 General Instrument Corporation Method and apparatus for streaming multiple scalable coded video content to client devices at different encoding rates
US8527647B2 (en) * 2009-10-06 2013-09-03 Unwired Planet, Inc. Managing network traffic using intermediate flow control
EP2510669A4 (en) * 2009-12-11 2013-09-18 Nokia Corp DEVICE AND METHODS FOR DESCRIBING SYNCHRONIZATION REPRESENTATIONS IN CONTINUOUSLY TRANSMITTED MULTIMEDIA FILES
CN101848205A (zh) * 2010-03-16 2010-09-29 深圳市同洲电子股份有限公司 一种基于rtsp的移动终端播放流媒体的方法及系统
US8914534B2 (en) * 2011-01-05 2014-12-16 Sonic Ip, Inc. Systems and methods for adaptive bitrate streaming of media stored in matroska container files using hypertext transfer protocol
CN106209192B (zh) * 2011-04-01 2020-06-30 英特尔公司 跨层优化的自适应http流送

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090089445A1 (en) * 2007-09-28 2009-04-02 Deshpande Sachin G Client-Controlled Adaptive Streaming
US20100235472A1 (en) * 2009-03-16 2010-09-16 Microsoft Corporation Smooth, stateless client media streaming
US20110082945A1 (en) * 2009-08-10 2011-04-07 Seawell Networks Inc. Methods and systems for scalable video chunking
JP2011087103A (ja) * 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供

Also Published As

Publication number Publication date
CN103548318A (zh) 2014-01-29
MX2013013373A (es) 2014-07-30
HK1194882A1 (zh) 2014-10-24
CA2835384A1 (en) 2012-11-22
CN103548318B (zh) 2019-01-08
WO2012156211A1 (en) 2012-11-22
EP2710778B1 (en) 2016-01-06
HUE026744T2 (en) 2016-07-28
RU2013156038A (ru) 2015-06-27
TWI573450B (zh) 2017-03-01
RU2598805C2 (ru) 2016-09-27
FR2975555A1 (fr) 2012-11-23
TW201249185A (en) 2012-12-01
KR20140023983A (ko) 2014-02-27
US20140189142A1 (en) 2014-07-03
JP2014520422A (ja) 2014-08-21
JP6436772B2 (ja) 2018-12-12
MY168875A (en) 2018-12-04
EP2710778A1 (en) 2014-03-26
US10015225B2 (en) 2018-07-03

Similar Documents

Publication Publication Date Title
KR102012528B1 (ko) 수신 비트율 및 연관된 수신기의 동적 적응 방법
KR102119287B1 (ko) 이용가능한 대역폭에 따라 전송 프로토콜을 선택함으로써 콘텐츠를 획득하는 장치
US7640358B2 (en) Methods and systems for HTTP streaming using an intelligent HTTP client
EP2360924A1 (en) A digital multimedia data transmission device and method
CN102752669B (zh) 多通道实时流媒体文件的传送处理方法与系统、接收装置
EP2383999A1 (en) Controlling an adaptive streaming of digital content
US8843983B2 (en) Video decomposition and recomposition
US20170238040A1 (en) Method, computer program product and server for streaming media content from a server to a client
JP7307211B2 (ja) クライアント、サーバ、受信方法及び送信方法
EP2993911A1 (en) Method and client terminal for receiving a multimedia content split into at least two successive segments, and corresponding computer program product and computer-readable medium
CN111886875B (zh) 一种通过网络传送媒体内容的方法及服务器
JP2014090419A (ja) 通信パラメータに従ってコンテンツをダウンロードするための方法、および、関連するコンテンツ受信機
KR20230002784A (ko) 오디오 및/또는 비디오 콘텐츠 전송을 위한 방법 및 서버
CN110881018B (zh) 媒体流的实时接收方法及客户端
CN111193686B (zh) 媒体流的递送方法及服务器
GB2572357A (en) Congestion response for timely media delivery
EP3316531A1 (en) Method to transmit an audio/video stream of to a destination device
US20230199267A1 (en) Method and apparatus for processing adaptive multi-view streaming
WO2018021950A1 (en) Device and method for controlling media streaming from a server to a client
WO2009106683A1 (en) An apparatus, a method, a computer program product and a system for encoding video stream

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
GRNT Written decision to grant