KR20230159533A - 클라우드 게이밍에서의 경험 품질 개선에 관한 방법, 장치 및 시스템 - Google Patents

클라우드 게이밍에서의 경험 품질 개선에 관한 방법, 장치 및 시스템 Download PDF

Info

Publication number
KR20230159533A
KR20230159533A KR1020237035840A KR20237035840A KR20230159533A KR 20230159533 A KR20230159533 A KR 20230159533A KR 1020237035840 A KR1020237035840 A KR 1020237035840A KR 20237035840 A KR20237035840 A KR 20237035840A KR 20230159533 A KR20230159533 A KR 20230159533A
Authority
KR
South Korea
Prior art keywords
latency value
client device
srt
server
latency
Prior art date
Application number
KR1020237035840A
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 KR20230159533A publication Critical patent/KR20230159533A/ko

Links

Images

Classifications

    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35Details of game servers
    • A63F13/355Performing operations on behalf of clients with restricted processing capabilities, e.g. servers transform changing game scene into an encoded video stream for transmitting to a mobile phone or a thin client
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/33Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections
    • A63F13/335Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers using wide area network [WAN] connections using Internet
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/30Interconnection arrangements between game servers and game devices; Interconnection arrangements between game devices; Interconnection arrangements between game servers
    • A63F13/35Details of game servers
    • A63F13/358Adapting the game course according to the network or server load, e.g. for reducing latency due to different connection speeds between clients
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F13/00Video games, i.e. games using an electronically generated display having two or more dimensions
    • A63F13/70Game security or game management aspects
    • A63F13/77Game security or game management aspects involving data related to game devices or game servers, e.g. configuration data, software version or amount of memory
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management 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/262Content 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/2625Content 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 for delaying content or additional data distribution, e.g. because of an extended sport event
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control 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/637Control signals issued by the client directed to the server or network components
    • H04N21/6375Control signals issued by the client directed to the server or network components for requesting retransmission, e.g. of data packets lost or corrupted during transmission from server
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/65Transmission of management data between client and server
    • H04N21/654Transmission by server directed to the client
    • H04N21/6547Transmission by server directed to the client comprising parameters, e.g. for client setup

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • General Business, Economics & Management (AREA)
  • Databases & Information Systems (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

클라우드 게이밍에서의 QoE 개선에 관한 방법, 장치, 시스템 등이 본 명세서에 개시되어 있다. 일 실시예에서, (예를 들어, 게임과 같은) 비디오 콘텐츠의 QoE를 개선하기 위한 방법이 클라이언트 디바이스에서 구현될 수 있다. 예를 들어, 클라이언트 디바이스는, 게임 서버로부터, 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 수신할 수 있다. 예를 들어, 클라이언트 디바이스는 디코딩 및 디스플레이 전에 초기 (예를 들어, 보안 신뢰성 전송(secure reliable transport; SRT)) 레이턴시 값을 수신된 패킷에 적용할 수 있다. 예를 들어, 클라이언트 디바이스는 디코딩 및 디스플레이 전에 수신된 후속 패킷에 적용될 프레임 페이스 변동에 기초하여 새로운 레이턴시 값을 표시하는 요청 메시지를 서버로 전송할 수 있다.

Description

클라우드 게이밍에서의 경험 품질 개선에 관한 방법, 장치 및 시스템
관련 출원에 대한 상호 참조
본 출원은 2021년 3월 22일자로 출원된 유럽 특허 출원 제21305349.9호의 이익을 주장하며, 이는 본 명세서에 참고로 포함된다.
기술분야
본 개시는 게임 스트리밍으로 또한 지칭될 수 있는 클라우드 게이밍 도메인에 관한 것으로, 보다 구체적으로는 클라우드 게이밍에서의 경험 품질(quality of experience, QoE)에 관한 것이다.
클라우드 게이밍에서, 최종 사용자 디바이스는 서버(예를 들어, 인스턴스) 상에서 실행될 수 있는 게임 실행가능 프로그램을 실행하지 않을 수 있다. 서버 인스턴스는 (예를 들어, 클라우드 제공자에 의해 또는 임의의 종류의 운영자에 의해 운영되는) 데이터 센터에 위치될 수 있다. 클라우드 게이밍에서, 게임의 사용자 경험은, 예를 들어, 네트워크 레이턴시, 서버 로드 및 게임 복잡성 중 임의의 것과 같은 상이한 요인에 따라 달라질 수 있다. 본 개시내용은 전술한 바를 염두에 두고 설계되었다.
클라우드 게이밍에서의 QoE 개선에 관한 방법, 장치, 시스템 등이 본 명세서에 개시되어 있다. 일 실시예에서, (예를 들어, 게임과 같은) 비디오 콘텐츠의 QoE를 개선하기 위한 방법이 클라이언트 디바이스에서 구현될 수 있다. 예를 들어, 클라이언트 디바이스는, 서버로부터, 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 수신할 수 있다. 예를 들어, 클라이언트 디바이스는 디코딩 및 디스플레이 전에 초기 (예를 들어, 보안 신뢰성 전송(secure reliable transport; SRT)) 레이턴시 값을 수신된 패킷에 적용할 수 있다. 예를 들어, 클라이언트 디바이스는 요청 메시지를 서버에 전송할 수 있다. 예를 들어, 요청 메시지는 프레임 페이스 변동에 기초하여 새로운 레이턴시 값을 표시하는 제1 정보를 포함할 수 있다. 예를 들어, 클라이언트 디바이스는 서버로부터 응답 메시지를 수신할 수 있고, 응답 메시지는 새로운 레이턴시 값을 표시하는 제2 정보를 포함한다. 예를 들어, 클라이언트 디바이스는 디코딩 및 디스플레이 전에 새로운 SRT 레이턴시 값을 수신된 후속 패킷(예를 들어, 후속 패킷)에 적용할 수 있다.
장치, 시스템, 디바이스 등 및/또는 이의 임의의 요소가 동작, 프로세스, 알고리즘, 기능 등 및/또는 이의 임의의 부분을 수행하도록 구성되는 다양한 실시예가 본 명세서에 기술되고/되거나 청구되지만, 본 명세서에 기술되고/되거나 청구된 임의의 실시예는, 임의의 장치, 시스템, 디바이스 등 및/또는 이의 임의의 요소가 임의의 동작, 프로세스, 알고리즘, 기능 등 및/또는 이의 임의의 부분을 수행한다고 가정한다는 것(그리고 그 반대도 성립된다는 것)이 이해되어야 한다.
첨부 도면과 관련하여 예로서 주어지는 다음의 설명으로부터 더 상세한 이해가 이루어질 수 있다. 그러한 도면에서의 도면은 상세한 설명과 같은 예이다. 그와 같이, 도면 및 상세한 설명은 제한하는 것으로 간주되지 않아야 하고, 다른 동일하게 효과적인 예가 가능하고 가능성이 있다. 또한, 도면에서의 유사한 참조 부호는 유사한 요소를 나타낸다.
- 도 1은 게임 스트리밍의 하이 레벨 아키텍처의 일 예를 예시하는 시스템도이다.
- 도 2는 클라우드 게이밍 아키텍처에서 비디오 스트리밍의 일 예를 예시하는 시스템도이다.
- 도 3은 SRT 레이턴시 버퍼에서의 레이턴시 윈도우 동작의 일 예를 예시하는 도면이다.
- 도 4는 SRT에서의 확인응답 동작의 일 예를 예시하는 도면이다.
- 도 5는 SRT 확장된 핸드쉐이크 절차 후의 수신기 및 전송자 버퍼 레이턴시의 일 예를 예시하는 도면이다.
- 도 6a도 6b는 프레임간 지연 변동 메트릭의 2개의 예를 예시하는 2개의 도면이다.
- 도 7은 SRT에 기초한 클라우드 게이밍 시스템의 일 예를 예시하는 시스템도이다.
- 도 8a는 확장된 핸드쉐이크 패킷 포맷의 2개의 예를 예시하는 도면이다.
- 도 8b는 핸드쉐이크 확장 메시지 플래그의 일 예를 예시하는 도면이다.
- 도 9a도 9b는 레이턴시 동적 변경을 지원하는 능력을 나타내기 위한 확장된 핸드쉐이크 메시지 교환의 2개의 예를 예시하는 2개의 도면이다.
- 도 10은 새로운 SRT 레이턴시 값을 요청하기 위한 SRT 메시지의 포맷의 일 예를 예시하는 도면이다.
- 도 11a도 11b는 클라이언트 디바이스 및 서버에 의해 각각 개시되는 동적 레이턴시 변경 절차에 대한 메시지 교환의 2개의 예를 예시하는 2개의 도면이다.
- 도 12a는 게임의 QoE를 개선하기 위한 클라이언트 프로세싱 디바이스(12A)의 일 예를 예시하는 도면이다.
- 도 12c는 게임의 QoE를 개선하기 위한 서버 프로세싱 디바이스(12C)의 일 예를 예시하는 도면이다.
- 도 12b는 도 12a 및 도 12c의 클라이언트 및 서버 프로세싱 디바이스 중 임의의 것의 아키텍처의 일 예를 나타낸다.
- 도 13은 게임의 QoE 개선 방법의 일 예를 예시하는 도면이다.
- 도 14는 예를 들어, 비디오 콘텐츠의 QoE를 개선하기 위해 클라이언트 디바이스에서 구현되는 방법의 제1 예를 예시하는 도면이다.
- 도 15는 예를 들어, 비디오 콘텐츠의 QoE를 개선하기 위해 서버에서 구현되는 방법의 제2 예를 예시하는 도면이다.
- 도 16은 예를 들어, 비디오 콘텐츠의 QoE를 개선하기 위해 클라이언트 디바이스에서 구현되는 방법의 제3 예를 예시하는 도면이다.
- 도 17은 예를 들어, 비디오 콘텐츠의 QoE를 개선하기 위해 서버에서 구현되는 방법의 제4 예를 예시하는 도면이다.
도면(들)은 본 개시내용의 개념을 예시하기 위한 목적을 위한 것이며, 반드시 본 개시내용을 예시하기 위한 유일한 가능한 구성이 아님을 이해해야 한다.
도면에 도시된 요소는 다양한 형태의 하드웨어, 소프트웨어 또는 이의 조합으로 구현될 수 있다는 것이 이해되어야 한다. 바람직하게는, 이 요소는 프로세서, 메모리, 및 입출력 인터페이스를 포함할 수 있는, 하나 이상의 적절하게 프로그래밍된 범용 디바이스 상에서 하드웨어와 소프트웨어의 조합으로 구현된다. 본 명세서에서, 용어 "상호접속된"은 하나 이상의 중간 컴포넌트에 직접 접속되거나 이를 통해 간접적으로 접속되는 것을 의미하도록 정의된다. 그러한 중간 컴포넌트는 하드웨어 및 소프트웨어 기반 컴포넌트 둘 모두를 포함할 수 있다. 용어 "상호접속된"은 유선 상호접속에 제한되지 않으며, 무선 상호접속을 또한 포함한다.
본 명세서에 언급된 모든 예 및 조건적 언어는 독자가 본 개시내용의 원리 및 본 발명자가 기술 발전에 기여한 개념을 이해하는 것을 돕기 위한 교육적 목적을 위해 의도된 것이며, 그러한 구체적으로 언급된 예 및 조건에 제한이 없는 것으로 해석되어야 한다.
게다가, 당업자는, 본 명세서에 제시된 블록도가 본 개시내용의 원리를 구현하는 예시적인 회로부의 개념도를 표현한다는 것을 이해할 것이다. 유사하게, 임의의 흐름 차트, 흐름도, 상태 전이 도면, 의사코드 등은, 컴퓨터 판독 가능 매체에 실질적으로 표현될 수 있으며, 그에 따라, 컴퓨터 또는 프로세서가 명시적으로 도시되어 있는지 여부에 관계없이, 그러한 컴퓨터 또는 프로세서에 의해 실행될 수 있는 다양한 프로세스를 표현하는 것임이 이해될 것이다.
도면에 도시된 다양한 요소의 기능은 적절한 소프트웨어와 연관하여 소프트웨어를 실행할 수 있는 하드웨어뿐만 아니라 전용 하드웨어를 사용하여 제공될 수 있다. 프로세서에 의해 제공될 때, 기능은 단일 전용 프로세서에 의해, 단일 공유 프로세서에 의해, 또는 복수의 개별의 프로세서에 의해 제공될 수 있으며, 이 중 일부는 공유될 수 있다. 게다가, 용어 "프로세서" 또는 "제어기"의 명시적 사용은 소프트웨어를 실행할 수 있는 하드웨어만을 배타적으로 지칭하는 것으로 해석되어서는 안 되며, 제한 없이, 디지털 신호 프로세서(digital signal processor; DSP) 하드웨어, 소프트웨어를 저장하기 위한 판독 전용 메모리(read only memory; ROM), 랜덤 액세스 메모리(random access memory; RAM), 및 비휘발성 저장소를 암시적으로 포함할 수 있다.
종래의 그리고/또는 맞춤형의, 다른 하드웨어가 또한 포함될 수 있다. 유사하게, 도면에 도시된 임의의 스위치는 단지 개념적인 것이다. 그의 기능은 프로그램 로직의 동작을 통해, 전용 로직을 통해, 프로그램 제어와 전용 로직의 상호작용을 통해, 또는 심지어 수동으로 수행될 수 있으며, 특정 기법은 문맥으로부터 더 구체적으로 이해되는 바와 같이 구현자에 의해 선택가능하다.
본 발명의 청구범위에서, 특정 기능을 수행하기 위한 수단으로서 표현되는 임의의 요소는, 예를 들어, a) 그러한 기능을 수행하는 회로 요소의 조합 또는 b) 임의의 형태의 소프트웨어(이에 따라, 기능을 수행하기 위해 그러한 소프트웨어를 실행하기 위한 적절한 회로부와 조합된 펌웨어, 마이크로코드 등을 포함함)를 포함하는 그러한 기능을 수행하는 임의의 방식을 포함하도록 의도된다. 이러한 청구범위에 의해 정의된 개시내용은 다양한 기재되는 수단에 의해 제공되는 기능성이 청구범위에서 요구하는 방식으로 조합되고 함께 모인다는 사실에 있다. 따라서, 그 기능성을 제공할 수 있는 임의의 수단은 본 명세서에 도시된 것과 동등하다고 간주된다.
예를 들어 다음의 "A/B", "A 및/또는 B" 및 "A 및 B 중 적어도 하나"의 경우에서 "/", "및/또는", 및 "적어도 하나" 중 임의의 것의 사용은 제1 열거된 옵션(A) 단독의 선택, 또는 제2 열거된 옵션(B) 단독의 선택, 또는 옵션(A 및 B) 둘 모두의 선택을 포함하도록 의도됨을 이해해야 한다. 또 다른 예로서, "A, B 및/또는 C" 및 "A, B 및 C 중 적어도 하나"의 경우에서, 그러한 어구는 제1 열거된 옵션(A) 단독의 선택, 또는 제2 열거된 옵션(B) 단독의 선택, 또는 제3 열거된 옵션(C) 단독의 선택, 또는 제1 및 제2 열거된 옵션(A 및 B) 단독의 선택, 또는 제1 및 제3 열거된 옵션(A 및 C) 단독의 선택, 또는 제2 및 제3 열거된 옵션(B 및 C) 단독의 선택, 또는 3개의 모든 옵션(A, B 및 C)의 선택을 포함하도록 의도된다. 이는, 본 명세서에 기술된 바와 같은 많은 항목에 대해, 본 명세서 및 관련 분야의 당업자에게 명백한 바와 같이 확장될 수 있다.
본 명세서에 기술된 실시예는 게임 스트리밍으로 또한 지칭될 수 있는 클라우드 게이밍과 관련이 있다. 클라우드 게이밍은, (본 명세서에서 "게임 서버" 및 "서버" 중 임의의 것, 총칭하여 "서버"로 지칭될 수 있는)(예를 들어, 원격) 서버 상에서 게임을 실행하고, 그 결과를 비디오 스트림으로서, 본 명세서에서 "클라우드 게이밍 클라이언트", "씬(thin) 클라이언트 디바이스", "클라이언트 게임 디바이스", 총칭하여 "클라이언트 디바이스" 중 임의의 것으로 지칭될 수 있는, 최종 사용자 디바이스로 전송하는 개념으로 볼 수 있다. 게임 서버 및 클라이언트 디바이스는 임의의 유형의 네트워크를 통해 상호접속될 수 있다. 예를 들어, 서버는 클라우드에 위치될 수 있고, 게임은 서버의 임의의 (예를 들어, 유형의) 인스턴스 상에서 실행될 수 있다.
단순화를 위해, 실시예는 비디오 콘텐츠(예를 들어, 스트리밍)의 일 예로서 게임(예를 들어, 스트리밍)을 지칭함으로써 본 명세서에서 설명된다. 본 명세서에 기술된 실시예는 게임 스트리밍에 제한되지 않고, 임의의 종류의 비디오 콘텐츠 스트리밍에 적용가능할 수 있다. 본 명세서에 기술된 실시예 전체에 걸쳐, 용어 "게임" 및 "비디오 콘텐츠"는 상호교환가능하게 사용될 수 있다.
단순화를 위해, 실시예는 보안 신뢰성 전송(SRT) 프로토콜 및 그것의 연관된 SRT 레이턴시를 참조함으로써 본 명세서에서 기술된다. SRT 프로토콜(예를 들어, 및 SRT 레이턴시)은 본 명세서에 기술된 실시예에 적용가능할 수 있는 프로토콜(예를 들어, 레이턴시)의 예일 뿐이다. 서버에서 생성되었을 수 있는 패킷(예를 들어, 데이터, 비디오 프레임)의 레이트(예를 들어, 시간 시퀀스)와 유사할 수 있는(예를 들어, 이를 나타낼 수 있는) 패킷(예를 들어, 데이터, 비디오 프레임)의 레이트(예를 들어, 시간 시퀀스)를 클라이언트 디바이스에서 재생할 수 있는 임의의 전송 프로토콜 및 임의의 종류의 레이턴시(예를 들어, 관리 시스템)가 본 명세서에 기술된 실시예에 적용가능할 수 있다. 용어 "SRT(예를 들어, 요청, 응답, 핸드쉐이크) 메시지" 및 "(예를 들어, 요청, 응답, 핸드쉐이크) 메시지"는 본 명세서에 기술된 실시예 전체에 걸쳐 상호교환가능하게 사용될 수 있다. 용어 "SRT 레이턴시" 및 "레이턴시"는 본 명세서에 기술된 실시예 전체에 걸쳐 상호교환가능하게 사용될 수 있다.
도 1은 게임 스트리밍의 하이 레벨 아키텍처의 일 예를 예시하는 시스템도이다. 클라이언트 디바이스(11)는 서버(12)(예를 들어, 서버의 전용 인스턴스)에서 실행되고 있을 수 있는 게임 실행파일(game executable)을 실행하지 않을 수 있다. 서버(예를 들어, 인스턴스)는, 예를 들어, (예를 들어, 클라우드 제공자 및 운영자 중 임의의 것에 의해 운영될 수 있는) 데이터 센터에 위치될 수 있다. 서버(12)는 예를 들어, 그래픽 처리장치(GPU)와 같은 (예를 들어, 성능 기준에 맞는(performant))하드웨어를 포함할 수 있다. 예를 들어, 서버(12)는 (예를 들어, 주어진 캡처) 레이트(예를 들어, 60 FPS(초당 프레임))로 GPU에 의해 렌더링(122)된 (예를 들어, 게임의 장면의) 이미지를 획득(예를 들어, 캡처)할 수 있다. 획득된(예를 들어, 캡처된) 이미지는 클라이언트 디바이스(11)에 전송(예를 들어, 송신)될 수 있는 (예를 들어, 라이브) 비디오 스트림으로 인코딩(121)될 수 있는 비디오 프레임의 흐름을 초래할 수 있다. 비디오 스트림은 게임의 (예를 들어, 인코딩된) 비디오 프레임을 운반하는 복수의 패킷을 포함할 수 있다. 클라이언트 디바이스(11) 상에서, 씬 게임 클라이언트 애플리케이션은 이 비디오 스트림을 수신(예를 들어, 청취)할 수 있고, 비디오 스트림이 수신될 수 있을 때 프레임을 디코딩할 수 있고, 이들을 클라이언트 디바이스(11) 스크린에 제시(예를 들어, 디스플레이)할 수 있다.
클라이언트 디바이스(11)는, (예를 들어, 단지) 이러한 몇 가지 동작을 수행함으로써 경량일 수 있다(제한된 프로세싱 리소스를 포함할 수 있다). 용어 "비디오 스트림"은 게임 서버에 의해 클라이언트 디바이스로 송신될 수 있는 게임의 비디오 (예를 들어, 인코딩된) 프레임의 세트를, 예를 들어, 전송 계층 오버헤드 및 (예를 들어, 대응하는) 메타데이터 중 임의의 것을 포함하는 복수의 패킷으로서 지정하기 위해 사용된다.
클라우드 게이밍에서, 경험 품질(QoE)은 객관적 및 주관적 인자 중 임의의 요인에 좌우될 수 있다. 예를 들어, QoE는 사용자 커맨드에 대한 응답성(예를 들어, 응답 시간, 레이턴시) 및 비디오 끊김(stuttering)의 존재 여부 중 임의의 것에 좌우될 수 있으며, 비디오 끊김은 비디오 평활도로도 지칭될 수 있다.
비디오 평활도는 QoE에 영향을 미치는 중요한 주관적 인자일 수 있으며, 이는 사용자가 관용할 수 있거나 적응할 수 있는 응답 시간 또는 시각적 품질만큼 중요할 수 있다. 비디오 끊김(예를 들어, 평활도의 결여)은, 예를 들어, 임의의 수의 프레임이 클라이언트 디바이스에서 임의의 드롭되고 복제되는 경우(클라이언트 스크린 상에 보일 수 있음)에 발생할 수 있다. 프레임 복제(예를 들어, 동일한 프레임을 2회 렌더링하는 것)는, 예를 들어, 디스플레이될 다음 프레임이 (예를 들어, 증가된 레이턴시로 인해) 제 시간에 수신, 디코딩 및 디스플레이될 수 없는 경우에 발생할 수 있다. 유사하게, 프레임 드롭(예를 들어, 프레임을 스킵하는 것, 디코딩하지 않는 것, 디스플레이하지 않는 것)은, 예를 들어, 클라이언트 디바이스의 수신 버퍼가 (예를 들어, 버스트 데이터의 도달로 인해) 가득 차서 일부 프레임이 삭제될 수 있는 경우에 발생할 수 있다. (예를 들어, 클라이언트 버퍼가 가득 찬 것으로 인해) 삭제될 수 있는 프레임은, 예를 들어, 해당 프레임에 대해 서버 재송신이 더 이상 가능하지 않은 경우에 더 이상 수신되지 않을 수 있다.
클라우드 게이밍에서, 게임의 비디오 프레임이 클라이언트 디바이스에 의해 수신(예를 들어, 전달)될 수 있는 레이트의 규칙성(예를 들어, 일정성)은, 예를 들어, 네트워크(예를 들어, 변경) 제약, 인코딩 가변성, 서버 리소스의 가용성(이는 예를 들어, 서버 인스턴스(예를 들어, 디스크 I/O 액세스, CPU, GPU 및 인코더 기능 공유 중 임의의 것) 상에서 실행될 수 있는 게임 실행파일의 수에 링크됨), 주어진 시간에서의 장면의 복잡성 등 중 임의의 것과 같은, 임의의 수의(예를 들어, 변경) 조건(예를 들어, 인자)에 의해 영향을(예를 들어, 임팩트를) 받을 수 있다. 예를 들어, 클라이언트 디바이스 스크린 상에서, 일부 비디오 끊김은, 예를 들어, 클라이언트 디바이스가 프레임 중 일부를 드롭(각각 복제)하도록 강제할 수 있는 (클라이언트 디바이스의 메모리 버퍼에서의) 프레임의 오버플로우(각각 언더플로우)로 인해 발생할 수 있으며, 이는 렌더링된 비디오의 페이스(예를 들어, 레이트 규칙성)를 변경(예를 들어, 저하)시킬 수 있다.
클라우드 게이밍에서, 클라이언트 디바이스는 비디오가 스크린 상에 렌더링될 수 있기 전에 예를 들어, 수백 밀리초 동안 수신 시에 비디오를 버퍼링하기 위한 메모리 버퍼를 포함할 수 있다. 전체 클라우드 게이밍 레이턴시를 증가시킬 수 있는 메모리 버퍼의 크기(예를 들어, 시간)를 증가시킴으로써 비디오 끊김 문제가 감소(예를 들어, 제거)될 수 있으며, 이는 QoE에 대한 중요한 인자로서 보여질 수 있다. 클라우드 게임 레이턴시의 낮은(예를 들어, 최소) 값 및 낮은 레벨의 비디오 끊김(예를 들어, 없음) 둘 모두를 유지함으로써 추정되는 절충(예를 들어, 균형)이 있을 수 있다.
(예를 들어, 라이브, 실제) 조건이 게임 세션 동안 지속적으로 진화할 수 있기 때문에, 클라이언트 디바이스에는 지터의 산발적이고 긴 지속시간 변동 중 임의의 것의 높은 값이 있을 수 있다. 본 명세서에 기술된 실시예는 서버와 클라이언트 디바이스가 (예를 들어, 적절하게) 동기화된 상태를 유지할 수 있게 하는 (예를 들어, 레이턴시를 증가시키는 것과 비디오 끊김을 감소시키는 것 사이의) 균형을 (예를 들어, 규칙적으로, 반복적으로) 조정하게 할 수 있다.
클라우드 게이밍 레이턴시의 예
클라우드 게이밍에서 높은 응답성은 스트리밍된 콘텐츠를 사용자의 작업에 맞게 (예를 들어, 신속하게) 조정할 수 있다. 용어 "클라우드 게이밍 레이턴시"는 게임에서의 사용자의 작업과 디스플레이에 미치는 그 효과 사이의 지연을 지칭하는 데 사용될 수 있다. 클라우드 게이밍 레이턴시는 다음을 포함할 수 있다:
- 패킷이 클라이언트 디바이스에 의해 전송될 수 있는 제1 시간과 응답 패킷이 서버로부터 수신될 수 있는 제2 시간 사이의 네트워크 전송 지연으로 볼 수 있는 왕복 시간 지연(round trip time delay; RTT). RTT는 예를 들어 현재 네트워크 조건, 혼잡 문제 등에 따라 시간이 지나면서 달라질 수 있다.
- 서버가 프레임을 인코딩하는 시간으로 볼 수 있는 프로세싱 지연. 이러한 시간은 서버 측의 리소스 관리에 좌우될 수 있다.
- 클라이언트 디바이스가 프레임을 디코딩하고 그것을 스크린 상에 제시(예를 들어, 디스플레이)하는 시간으로 볼 수 있는 재생 지연.
- 수신된 패킷이 재생을 위해 애플리케이션에 전달될 수 있기 전에 수신 프로토콜 스택 내부의 내부 버퍼에서 소비된 시간으로 볼 수 있는 큐잉 지연. 버퍼링의 치수화는 설정일 수 있으며, 이는 시작시 미리 구성되고 선택(예를 들어, 결정)되는 것 중 임의의 것일 수 있다. 예를 들어, 버퍼링의 치수화는 서버와 클라이언트 디바이스 사이에서 협상될 수 있다.
클라우드 게이밍 레이턴시는 게이밍에서 즐거운 사용자 경험을 가능하게 하기 위해 낮은 값으로 유지될 수 있다. 예를 들어, 100과 150 밀리초 사이에 유지될 수 있는 클라우드 게이밍 레이턴시는, 예를 들어, 1인칭 슈팅 게임에 즐거운 사용자 경험을 제공할 수 있게 한다.
클라우드 게이밍에서의 비디오 스트리밍의 예
도 2는 클라우드 게이밍 아키텍처에서 비디오 스트리밍의 일 예를 예시하는 시스템도이다. 서버(21) 상에서, 비디오 캡처 및 인코딩 프로세싱 모듈(211)은 게임에 의해 렌더링된 프레임(들)을 타겟 레이트(예를 들어, 60 ㎐)로 캡처하도록 구성될 수 있다. 새로운 인코딩된 프레임은 프로세싱 모듈(211)에 의해 인코딩될 수 있고, 동일한 타겟 레이트로 출력될 수 있다. (예를 들어, 각각의) 인코딩된 프레임은 사용자 데이터그램 프로토콜(UDP) 및 전송 제어 프로토콜(TCP) 중 임의의 것보다 높은 신뢰성 있는 스트리밍 프로토콜을 사용하여 클라이언트 디바이스(22)로 전송될 수 있다. 신뢰성 있는 스트리밍 프로토콜의 예는, 예를 들어, Stadia에 대한 웹 실시간 통신 프로토콜(WEBRTC) 및 예를 들어, GeForce Now에 대한 UDP를 통한 실시간 프로토콜(RTP) 중 임의의 것을 포함할 수 있다.
예를 들어, 라이브 비디오 시스템에서, 전송은 혼잡, 패킷 손실, 재정렬 및 지터 중 임의의 것에 의해 영향을 받을 수 있다. 패킷 늦은 도착 및 패킷 손실 중 임의의 것은 비디오 끊김, 비디오 정지 및 시각 장애 중 임의의 것을 생성할 수 있다. 프로토콜 스택(예를 들어, 네트워크 전달 시스템)은 다음의 기술 중 임의의 것에 의해 이러한 효과를 보상(예를 들어, 감쇠)하여 QoE를 개선할 수 있다:
- 예를 들어, 네트워크(예를 들어, 시간 전달) 변동을 흡수하기 위해 패킷의 버퍼(222)를 사용할 수 있고;
- FEC(Forward Error Correction)와 같은 정보의 중복성을 사용하여 송신 신뢰도를 향상시킬 수 있으며;
- 예를 들어, (보안 및 신뢰성 있는 전송 프로토콜(SRT)과 같은) 수신기에 의해 손상되거나 누락된 것으로 검출되었을 수 있는 패킷을 재송신하도록 서버에 요청함으로써 수리 메커니즘을 사용할 수 있다.
큐잉 지연 및 글로벌 클라우드 레이턴시를 급격하게 증가시킬 수 있는, 예를 들어, 초 단위로 측정된 중요한 버퍼링을 사용할 수 있는 비디오 스트리밍 기술이 있을 수 있다. 이러한 기술은 클라우드 게이밍 및 그에 대응하는(예를 들어, 초저) 레이턴시(< 150 ms) 기대치에 적용되지 않을 수 있으며, 이에 대해 비디오 버퍼링이 감소될 수 있다.
실시예에 따르면, 클라이언트 디바이스(22)는, 패킷이 디코딩(222) 및 프리젠테이션(예를 들어, 디스플레이)(223)을 위한 애플리케이션에 전달될 수 있기 전에, 버퍼링(예를 들어, 수신기 버퍼(221)에 저장)된 큐일 수 있는 패킷(예를 들어, 비디오 프레임을 운반함)을 (예를 들어, 네트워크 프로토콜 스택을 통해) 수신할 수 있다. 예를 들어, 패킷은 (예를 들어, 최대) 시간 제한 동안 버퍼(221)에 저장될 수 있다. 예를 들어, 디코딩 프로세싱 모듈(222)은 프레임(들)을 디코딩하기 위해 클라이언트 디바이스 상에서 이용가능한 (예를 들어, 임의의) HW 가속을 활용할 수 있다. 예로서, GeForce Now 및 Stadia는 DirectX 비디오 가속(DXVA2)을 사용할 수 있다. 디코딩된 비디오 프레임은, 예를 들어, 임의의 테어링 효과를 회피하기 위해, (예를 들어, 60 ㎐의) 주기적 비디오 동기화 신호(본 명세서에서 VSync로 지칭될 수도 있음)에 동기화되어, 스크린에 제시(예를 들어, 스크린 상에 디스플레이)될 수도 있다.
예를 들어, (예를 들어, 패킷 지터, 패킷 에러 및 복구 등 중 임의의 것과 같은) 임의의 이유로 인해, 비디오 프레임이 (예를 들어, 너무) 늦게 디코딩될 수도 있고, VSync 데드라인 시간 얼마(예를 들어, 수 밀리초) 후에 프리젠테이션 모듈(223)에 이용가능할 수도 있다. 이러한 경우에, 이전 비디오 프레임은 스크린 상에 2회의 VSync 주기 동안 제시(예를 들어, 디스플레이)될 수 있고, 마지막 디코딩된 것은 다음 VSync 주기로(예를 들어, 16.66 ms 더 늦게) 연기될 수 있다. 누락된(예를 들어, 늦은) 프레임의 (예를 들어, 여러 번의, 모든) 발생에 대해 이 프로세스가 반복되는 경우, 스크린 상에 제시된(예를 들어, 디스플레이된) 비디오 프레임과 서버에 의해 생성된(예를 들어, 인코딩된) 비디오 프레임 사이의 지연은 시간이 지남에 따라 누적될 수 있고 시프트될 수 있다. 예를 들어, (예를 들어, 일부 시점에서), 클라이언트 디바이스는 임의의 수의 (예를 들어, 너무) 늦은 디코딩된 비디오 프레임을 스킵하고 마지막으로 수신된 비디오 프레임을 제시(예를 들어, 디스플레이)함으로써 비디오 소스(예를 들어, 인코딩 레이트)와 재동기화할 수 있다. 예를 들어, 디스플레이된 비디오 프레임의 시퀀스는 캡처된 비디오 프레임의 시퀀스와 엄격하게 동일하지 않을 수 있는데, 그 이유는 반복된 프레임 및 스킵된 프레임 중 임의의 것을 포함할 수 있기 때문이며, 이는 비디오 끊김의 원인일 수 있다.
예를 들어, VSync의 비활성화(테어링의 위험을 발생시킬 수 있음)는 비디오 끊김의 발생을 방지할 수 없다. (예를 들어, 연속적인) 디코딩된 프레임 사이의 인터 지연이 일정하지 않은 경우, 비디오 프레임은 동일한 시간량 동안 디스플레이되지 않을 수 있으며, 이는 일부 비디오 끊김을 생성할 수 있다.
SRT 프로토콜 예
보안 신뢰성 전송 프로토콜(SRT)은 클라우드 게이밍에 사용될 수 있는 스트리밍 프로토콜의 일 예이다.
SRT는 초기에 비디오 스트리밍 애플리케이션을 다루기 위해 비디오 스트리밍 회사(Haivision)에 의해 내부적으로 개발되었다. SRT는 Haivision과 Wowza가 설립한 SRT 연합을 통해 지원받는다. SRT는 2020년 9월 9일에 발표된 IETF(Internet Engineering Task Force) 초안 "The SRT protocol draft-sharabayko-mops-srt-01"으로도 사용할 수 있다.
UDP 기반 데이터 전송(UDT) 프로토콜에 기초하여, SRT 패킷은 패킷 번호, 메시지 번호, 타임 스탬프, 목적지 소켓 식별자 등 중 임의의 것을 표시하는 정보를 포함할 수 있는 SRT 헤더를 포함할 수 있다. SRT 패킷은 예를 들어, (제어 패킷에 대한) 제어 유형 및 (데이터 패킷에 대한) 데이터 유형과 같은 상이한 유형의 것일 수 있다. 제어 패킷은 세션 관리, 확인응답 등 중 임의의 것을 위해 사용될 수 있다. 데이터 패킷은 스트림 데이터(예를 들어, 비디오/오디오 프레임을 운반하는 패킷)를 전달하기 위해 사용될 수 있다.
실시예에 따르면, SRT는 애플리케이션으로 패킷을 적시에 전달 가능하게 할 수 있다. 예를 들어, SRT는 패킷이 SRT에서 수집되었을 수 있는 타이밍에 대응하는 타이밍에서 패킷을 애플리케이션에 전송 가능하게 할 수 있다.
실시예에 따라, SRT는 늦은 패킷을 재송신하지 못하게 할 수 있다. 예를 들어, SRT는 애플리케이션에 성공적으로 그리고 적시에 전달되기에 너무 늦을 수 있는 패킷을 식별하고, 그것을 재송신하는 것을 중지할 수 있다.
실시예에 따르면, SRT는 ACK 및 ACKACK 메커니즘을 사용하여 RTT를 (예를 들어, 규칙적으로, 반복적으로) 추정 가능하게 할 수 있다.
SRT 버퍼 레이턴시 예
도 3은 SRT 레이턴시 버퍼에서의 레이턴시 윈도우 동작의 일 예를 나타내는 도면이다. 예를 들어, (예를 들어, 게임) 서버는 전송자 Tx 버퍼(31) 및 전송자 Rx 버퍼(33)를 포함할 수 있다. 예를 들어, 클라이언트 디바이스는 수신기 Rx 버퍼(32) 및 수신기 Tx 버퍼(34)를 포함할 수 있다. 서버 및 클라이언트 디바이스 버퍼(31, 32)의 크기는 버퍼(31, 32) 내부의 윈도우(310, 320)에 대응할 수 있고, 본 명세서에서 레이턴시 윈도우로 지칭될 수 있다. 예를 들어, 서버 전송자 Tx 버퍼(31) 및 클라이언트 디바이스 수신기 Rx 버퍼(32)에 대한 동일한 길이의 레이턴시 윈도우(310, 320)는 본 명세서에 기술된 바와 같이, SRT 확장된 핸드쉐이크 동안, 예를 들어, 세션 확립 동안 서버와 클라이언트 디바이스 사이에서 협상될 수 있다.
서버 측에서, (예를 들어, 원형) 레이턴시 버퍼(31)는 비디오 인코더로부터 획득된 인코딩된 비디오 프레임의 단편화로부터 획득된 SRT 패킷을 저장하기 위해 사용될 수 있다. 예를 들어, SRT 패킷은 SRT 레이턴시 값과 연관된 시간량 동안 재송신을 위해 (예를 들어, 원형) 레이턴시 버퍼(31)에 유지될 수 있다. 이 패킷은 예를 들어, SRT 세션의 생성 시간을 기준으로(예를 들어, SRT 세션이 확립되었을 수 있는 시간을 기준으로) 타임스탬프가 찍힐 수 있다. 예를 들어, 시간 값은 SRT 세션의 생성 시에 초기화될 수 있고 (예를 들어, 시스템) 클록에 기초하여 증분될 수 있다. (예를 들어, 시스템) 클록은 안정된 클록일 수 있으며, 이는 예를 들어, SRT 세션의 시작으로부터 경과된 CPU 사이클의 수의 측정에 기초할 수 있다. 예를 들어, (예를 들어, 각각의) 패킷에는 이 패킷이 서버 전송자 Tx 버퍼(31)에 저장되는 것과 연관된 시간을 표시하는 타임 스탬프 정보가 포함될 수 있다. 예를 들어, 타임 스탬프 정보는 패킷 전송 시간(예를 들어, 패킷이 클라이언트 디바이스로 (예를 들어, 처음으로) 송신되었을 때)을 표시할 수 있다. 다른 예에서, 타임 스탬프 정보는 패킷 기점 시간(예를 들어, 패킷이 생성되어 전송자 Tx 버퍼(31)에 저장(예를 들어, 삽입)된 때(예를 들어, (예를 들어, 제1) 송신 시간 이전, 이후 및 그 시점 중 임의의 것))를 표시할 수 있다. 상이한 패킷이 인코더로부터 획득(예를 들어, 및 서버 전송자 Tx 버퍼(31)에 저장)되었을 수 있는 시간 값에 대응하는 타임 스탬프 정보가 패킷에 삽입될 수 있다. (예를 들어, 타임스탬프 정보에 의해 표시된 상이한 시간을 갖는) 상이한 패킷은 (예를 들어, 제한된) 시간량 동안 버퍼에 남아 있을 수 있다. 예를 들어, 패킷은, 그 패킷에 대해 확인응답(ACK)이 수신되었을 수 있을 때까지 버퍼에 남아 있을 수 있다. 예를 들어, 패킷은 전송자 레이턴시 윈도우(sender latency window; SLW)의 종료(예를 들어, 종료에 대응하는 시간)까지 버퍼에 남아 있을 수 있다. 클라이언트 디바이스에 의해 패킷의 수신이 (예를 들어, 타임아웃 내에) 확인응답되지 않고, 패킷의 타임스탬프 정보가 표시하는 시간이 SLW에 남아 있는 경우, 패킷은 전송자에 의해 재송신될 수 있다. 그렇지 않으면(예를 들어, 패킷이 SLW 보다 오래 버퍼에 저장되어 있다고 패킷의 타임 스탬프 정보가 표시하면), 패킷은 드롭될 수 있고, 서버는 패킷의 재송신을 중지할 수 있다. 클라이언트 측의 수신기 레이턴시 윈도우(receiver latency window; RLW)에 더 이상 존재하지 않는 패킷은 디스플레이될 시간에 디코딩되지 않을 수 있기 때문에, 늦은 패킷의 재송신을 중지하면 쓸모없는 송신의 회피를 가능하게 할 수 있다.
클라이언트 디바이스 측에서, 수신기 레이턴시 버퍼(32)는, 예를 들어, 수신된 패킷을 (디코딩 및 렌더링을 위한) 애플리케이션에 전달할 시간이 발생할 때까지, 수신된 패킷을 저장(예를 들어, 홀딩)하는 데 사용될 수 있다. 예를 들어, 패킷은, 패킷에 포함된 타임 스탬프 정보가 표시하는 시간과 (예를 들어, 로컬, 시스템) 시간 사이의 비교에 기초하여, 디코딩되기 위해, 수신기 레이턴시 버퍼(32)로부터 추출될 수 있다. 예를 들어, 패킷이 서버의 전송자 레이턴시 버퍼(31)에 삽입(예를 들어, 처음으로 송신)되었을 수 있는 시간과 패킷이 클라이언트 디바이스에 의한 성공적인 수신 후에 클라이언트 디바이스의 수신기 레이턴시 버퍼(32)로부터 추출될 수 있는 시간 사이에 경과되었을 수 있는 (예를 들어, 일정한) 시간량 후에 패킷이 디코딩되기 위해 추출될 수 있다. (예를 들어, 일정한) 시간량은 적어도 연속적인(예를 들어, 연이은) 패킷의 세트에 대해 일정할 수 있다. (예를 들어, 일정한) 시간량은 SRT 레이턴시 값과 연관될 수 있다. 예를 들어, (예를 들어, 일정한) 시간량은 적어도 SRT 레이턴시 값과 (예를 들어, (예를 들어, SRT 핸드쉐이크 교환 동안 측정될 수 있는) 초기 RTT의 절반과 같은) RTT를 나타내는 초기 값의 합에 대응할 수 있다. 패킷 타임스탬프는, 전송자 측에서 (예를 들어, 인코더에 의해) 패킷이 생성되었을 수 있는 페이스(예를 들어, 타이밍)를 수신기 측에 반영하게 할 수 있다. 클라이언트 디바이스에서 전송자 페이스를 반영하면 애플리케이션에 대한 지터를 제거 가능하게 할 수 있다. 이는 애플리케이션이 작은(예를 들어, 제한된) 버퍼링을 갖게 할 수 있다. 예를 들어, SRT 수신기는 예를 들어, 패킷 넘버링에 기초하여 패킷을 재정렬할 수 있다. 예를 들어, SRT 수신기는 예를 들어, 패킷 번호의 시퀀스에서의 구멍(예를 들어, 불연속성)에 기초하여 누락 패킷을 검출할 수 있다. 예를 들어, 임의의 수의 누락 패킷은, 그의 재송신을 트리거할 수 있는 비-확인응답 패킷(본 명세서에서 NAK로 지칭될 수 있음)을 서버에 송신함으로써 보고될 수 있다. (예를 들어, 재정렬된) 패킷이 애플리케이션에 전달된 후에, 클라이언트 디바이스는 확인응답 패킷(본 명세서에서 ACK로 지칭될 수 있음)을 전송할 수 있다. 예를 들어, ACK 및 NAK 중 임의의 것은 정기적이고 구성가능한 간격 기반(예를 들어, 10 ms)으로 전송될 수 있다.
도 4는 SRT에서의 확인응답 동작의 일 예를 예시하는 도면이다. ACK 메시지(41)는 SRT 수신기에 의해 송신되어 SRT 전송자에 의한 ACKACK 메시지(42)의 송신을 트리거하여 SRT 수신기가 RTT(예를 들어, 및 임의의 RTT 분산 값)를 계산할 수 있게 할 수 있다. 예를 들어, 송신된 패킷의 수가 ACK 주기(40) 내에서 높은 경우, 예를 들어, 임의의 ACKACK 송신 및 RTT 측정을 트리거하지 않고, 패킷을 확인응답하기 위해 라이트 ACK(43) 메시지를 송신할 수 있다.
실시예에 따르면, 패킷을 애플리케이션에 전달하기 위한(예를 들어, 디코딩 및 디스플레이하기 위한) 시간 내에 패킷이 수신되지 않는 경우, 서버는 더 이상 패킷을 (재)송신하려는 시도를 동작하지 않을 수 있다. 예를 들어, (예를 들어, 타임 스탬프 정보에 표시된 시간 이후의 (예를 들어, 일정한) 시간량에 대응하는) 예상된 추출 시간 이후에 패킷이 수신되는 경우, 패킷은 제 시간에 수신되지 않은 것으로 간주될 수 있으며, (예를 들어, 일정한) 시간량은 SRT 레이턴시 값과 연관된다. 패킷이 제 시간에 수신되지 않은 경우, 클라이언트 디바이스(예를 들어, 수신기 스택)는 패킷이 수신된 것과 동일한 방식으로 그의 수신기 레이턴시 윈도우를 앞당길 수 있다. 유사하게, 서버는 패킷이 성공적으로 송신된 것처럼 그의 전송자 레이턴시 윈도우를 앞당길 수 있다.
실시예에 따르면, (예를 들어, 수신기, 전송자) 레이턴시 윈도우는 (예를 들어, 예측 가능하고) 제한된 레이턴시를 제공 가능하게 할 수 있다. 예를 들어, 네트워크 조건에 따라 더 많은 패킷을 손실할 위험이 있지만 감소된 레이턴시가 획득될 수 있다.
SRT 확장된 핸드쉐이크 예
SRT는 (본 명세서에서 HSv5로 지칭될 수 있는) SRT 확장된 핸드쉐이크 프로세스를 포함할 수 있다. SRT 확장된 핸드쉐이크 프로세스는 SRT 호출자-청취자 핸드쉐이크의 제2 부분에 포함될 수 있다. SRT 확장된 핸드쉐이크는 적어도 전송 방향에서의 SRT 레이턴시 값(본 명세서에서 전송자 SRT 레이턴시 및 SndTsbPdDelay 중 임의의 것으로 지칭될 수 있음) 및 수신 방향에서의 SRT 레이턴시 값(본 명세서에서 수신기 SRT 레이턴시 및 RcvTsbPdDelay 중 임의의 것으로 지칭될 수 있음)을 결정 가능하게 할 수 있다. 전송자 및 수신기 SRT 레이턴시 정보(예를 들어, 필드) 둘 모두는 레이턴시를 지칭할 수 있다. 통신이 양방향일 수 있기 때문에, 확장된 SRT 핸드쉐이크 메시지에 방향당 하나의 레이턴시 값이 있을 수 있다. 예를 들어, 확장된 핸드쉐이크 요청(HSREQ) 및 응답(HSRSP) 메시지 둘 모두는 전송자 및 수신기 SRT 레이턴시 정보(예를 들어, SndTsbPdDelay 및 RcvTsbPdDelay)를 포함할 수 있다.
예를 들어, 전송자 SRT 레이턴시는 SRT 수신기가 사용할 것으로 SRT 전송자가 예상할 수 있는 (예를 들어, 가장 낮은) 레이턴시에 대응할 수 있다. 예를 들어, 수신기 SRT 레이턴시는 수신기가 수신된 스트림에 적용할 수 있는 (예를 들어, 가장 낮은) 레이턴시 값에 대응할 수 있다.
예를 들어, 클라이언트 디바이스는 확장된 핸드쉐이크 요청(handshake request, HSREQ) 메시지를 서버로 전송할 수 있다. 확장된 HSREQ 메시지는 (예를 들어, 요청된) 수신기 SRT 레이턴시 값을 표시하는 수신기 SRT 레이턴시 정보를 포함할 수 있다. 예를 들어, 서버는 확장된 핸드쉐이크 응답(handshake response; HSRSP) 메시지를 클라이언트 디바이스로 전송할 수 있다. 확장된 HSRSP 메시지는 (예를 들어, 응답된) 전송자 SRT 레이턴시 값을 표시하는 전송자 SRT 레이턴시 정보를 포함할 수 있다. 실시예에 따르면, 서버 및 클라이언트 디바이스는 전송 버퍼 및 수신 버퍼 각각에서의 그들 각각의 SRT 레이턴시 값을 2개의 값(예를 들어, 요청된 수신기 레이턴시 값 및 응답된 전송자 레이턴시 값) 중 가장 높은 동일한 값으로 설정할 수 있다.
도 5는 확장된 SRT 핸드쉐이크 절차 후의 수신기 및 전송자 버퍼 레이턴시의 일 예를 예시한 도면이다. 확장된 SRT 핸드쉐이크는 양 방향(전송 및 수신 방향) 모두에서 전송자 및 수신기 SRT 레이턴시 값을 결정 가능하게 할 수 있다. 예를 들어, 호출자는 자신의 측에서 (예를 들어, Rx, Tx) SRT 레이턴시 값을 표시하는 제1 정보를 포함하는 확장된 HSREQ 메시지를 전송할 수 있다. 청취자는 수신된 확장된 HSREQ에 포함된 SRT 레이턴시 값과 자신의 값 사이의 가장 높은 값을 계산할 수 있다. 청취자는 (예를 들어, 양 측 모두에서) 사용될 SRT 레이턴시 값을 표시하는 제2 정보를 포함하는 확장된 HSRSP 메시지를 전송할 수 있다. 즉, SRT(예를 들어, 버퍼) 레이턴시는 개시자와 응답자(서버와 클라이언트 디바이스 중 임의의 것일 수 있음) 사이의 확장된 핸드쉐이크 프로세스 동안 레이턴시 정보의 교환을 통해 구성될 수 있다. 핸드쉐이크 확장 메시지는 SRT 수신기 및 전송자 둘 모두로부터의, 밀리초 단위의 SRT 레이턴시 값을 표시하는, 타임 스탬프-기반 패킷 전달(time stamp-based packet delivery; BPD) 지연 정보를 포함할 수 있다. 접속에 대한 SRT 레이턴시는 개시자 및 응답자에 의해 송신된 SRT 레이턴시 중 가장 높은 값으로서 확립(예를 들어, 가장 높은 값으로 설정)될 수 있다. 예를 들어, 상기 SRT 레이턴시 값은 접속의 지속시간 동안 설정될 수 있다.
프레임간 지연 변동의 예
실시예에 따르면, 클라우드 게이밍 상황에서, 비디오 끊김이 클라이언트 디바이스에서 발생하여, 사용자에게 불쾌한 사용자 경험을 초래할 수 있다. 예를 들어, 소프트웨어 프로브는 프로토콜 스택의 출력에서 비디오 프레임(예를 들어, 비디오 프레임을 운반하는 패킷)의 전달 시간을 모니터링하기 위해 (예를 들어, DXVA2 API와 같은) 클라이언트 디바이스의 디코딩 기능에 대한 호출을 추적하는 데 사용될 수 있다. 예를 들어, 초당 수신된 인코딩된 프레임의 수는 서버 상에서 초당 생성된 프레임의 수와 동일할 수 있다. 예를 들어, 수신 시 평균 초당 프레임 수(FPS)가 서버에서의 FPS와 동일할 수 있지만, 일부 분산이 예를 들어 프레임간 지연에 대해 측정될 수 있다.
실시예에 따르면, (예를 들어, 프레임간 지연의 변동과 같은) 프레임 페이스 변동의 측정(예를 들어, 메트릭)은 본 명세서에서 지터로컬로 지칭될 수 있다. 지터로컬은 지터 메트릭을 평균 주기로 나누어 획득될 수 있다. 예를 들어, 지터로컬은 다음과 같이 주어질 수 있다:
Figure pct00001
지터 메트릭은 연속적인 간격 지속시간 사이의 차이의 합으로서 정의될 수 있고, 간격 지속시간은 프레임 시간과 이전 프레임 시간 사이의 지속시간을 나타낼 수 있다. 예를 들어, 지터 메트릭은 다음과 같이 주어질 수 있다:
Figure pct00002
예를 들어, Ti는 i 번째 프레임과 연관된 제1 시간과 선행하는 (i-1) 번째 프레임과 연관된 제2 시간 사이의 i 번째 간격의 지속시간을 나타낼 수 있다. 예를 들어, 지속시간은 (예를 들어, 이상치를 제거하기 위해) 1 밀리초와 32 밀리초 사이에 포함된다는 조건 상에서 지터 메트릭에 포함될 수 있다.
도 6a 및 도 6b는 클라이언트 디바이스 상에서 측정된 프레임간 지연 변동 메트릭(지터로컬)의 2개의 예를 예시하는 2개의 도면이다. 도 6a는 광섬유 네트워크(예를 들어, 200 Mbps)를 사용하여 특정 게임(1인칭 슈팅 게임, 예를 들어, 데스티니 2)의 13분 게임 세션에 대해 획득된 프레임간 지연 변동 메트릭(지터로컬)을 예시한다. 도 6b는 동일한 게임에서 50초의 주기(61)에 대해 확대하여 획득된 프레임간 지연 변동 메트릭(지터로컬)을 예시한다.
프레임간 지연 변동의 높은 값의 예
예를 들어, 서비스 제공자는 그들이 가능한 한 작게 유지하려고 시도할 수 있는 공격적인 클라우드 게이밍 레이턴시(예를 들어, 약 120 ms)로 클라우드 게이밍 솔루션을 운영할 수 있다. 게이밍 세션 동안, 작은 레이턴시 값은 플레이어의 입력에 대한 반응성을 개선 가능하게 할 수 있다. (예를 들어, 글로벌) QoE(예를 들어, 레이턴시 및 비디오 평활도를 고려함)는 비디오 끊김 문제로 인해 축소될 수 있으며, 이는 예를 들어 사용자가 멀미를 겪게 할 수 있다.
도 6a 및 도 6b에 예시된 바와 같이, 측정된 지터로컬은 0.4보다 높은 여러 개의 위상으로 인해 높은 레벨의 프레임간 지연 변동을 나타낼 수 있으며, 평균 값은 0.2이다. 예를 들어, 도 6b는 4초 동안 (예를 들어, 프레임 #10500과 #10750 사이에서) 0.5보다 높은 지터로컬의 시퀀스를 보여준다. 지터로컬 값 0.5는 프레임간 평균 지연의 ±50%의 변동을 나타낼 수 있다. 예를 들어, 16.66 ms의 평균 지연(예를 들어, 초당 60 프레임에 대한 프레임간 지연을 나타낼 수 있음)에 대해, 지터 변동은 [8 ms - 24 ms]에 속할 수 있다. 예를 들어, 이러한 변동 및 예를 들어, 주어진 임계치(예를 들어, 이 예에서 0.2) 초과의 지터로컬 값은 비디오 끊김의 존재와 상관될 수 있다. 지터로컬 값은 비디오 끊김 발생의 빈도에 대응할 수 있는데, 예를 들어, 지터로컬 값이 높을수록, 비디오에서의 끊김 발생의 빈도가 높다.
프레임간 지연 변동(예를 들어, 지터로컬)은 다음의 이유 중 임의의 이유로 증가할 수 있다:
- 제1 이유는 네트워크 조건의 변동(예를 들어, RTT의 변동, 에러(예를 들어, 손실) 복구와 연관된 시간량만큼 비디오 프레임(들)의 이용가능성을 지연시킬 수 있는 혼잡 및 네트워크 에러 중 임의의 것의 발생)과 관련될 수 있다.
- 제2 이유는 캡처 레이트, 인코딩 레이트 및 비디오 프레임(예를 들어, 비디오 프레임을 운반하는 패킷)의 방출 중 임의의 것에 영향을 미칠 수 있는 서버 조건의 변동과 관련될 수 있다. 인코딩 파라미터(예를 들어, 관심 구역에 의한 압축), 이미지의 유형(예를 들어, I 대 P 대 인트라-리프레시 이미지), 및 이미지에서의 움직임의 양 중 임의의 것은 인코딩 지속시간, 인코딩된 이미지의 크기, 및 그 다음 송신(예를 들어, 전송) 시간 중 임의의 것에 영향을 미칠 수 있다. 예를 들어, 프레임 시간 도달 시에 관측될 수도 있는 지터는 인코딩의 지터에 상관될(예를 들어, 대응할) 수도 있다.
- 다른 이유는, 예를 들어, 실행중인 게임의 현재 상태(및 대응하는 이미지 복잡성), 서버 상의 동시 스트리밍 흐름의 존재 및 (예를 들어, 안정된) FPS로 프레임을 렌더링하기 위한 이용가능한 GPU 전력과 같은, 서버에서의 리소스 이용가능성과 관련될 수 있다.
산발적이고 긴 지속시간의 프레임간 지연 변동의 예
예를 들어, 지터를 흡수하고 더 매끄러운 디코딩된 프레임 레이트를 얻기 위해 클라이언트 디바이스 측에 영구적인 여분의 버퍼링이 포함될 수 있어서, 디코딩된 비디오 프레임이 그의 프리젠테이션 시간에 디스플레이를 위해 이용가능할 수 있다.
도 6a에 예시된 바와 같이, 프레임간 지연 변동은 시간이 지남에 따라 일정하지 않을 수 있고, 게이밍 세션 동안, 예를 들어 상이한 시간에서, 긴 기간 동안 산발적 높은 값으로 상당히 변할 수 있다. 이러한 상황(예를 들어, 도 6b에 예시된 프레임 #8000과 #11000 사이의 지터로컬 값)에서, 상당한 여분의 버퍼링은 끊김을 방지 가능하게 하고 모든 경우를 커버 가능하게 할 수 있으며, 이는 게임의 레이턴시를 상당히 증가시킬 수 있어 QoE를 감소시킬 수 있다. 예를 들어, 상당한 여분의 버퍼링을 추가하는 것은 이러한 종류의 파라미터가 세션의 지속시간 동안 (예를 들어, 세션의 시작에서) 설정될 수 있다는 사실로 인해 전체 게임 세션에 영향을 미칠 수 있다.
도 7은 SRT에 기초한 클라우드 게이밍 시스템의 일 예를 예시하는 시스템도이다. 실시예에 따르면, 클라우드 게이밍 시스템은 게임의 QoE 개선을 가능하게 할 수 있다. 게임은 서버 인스턴스(71) 상에서 실행될 수 있다. (예를 들어, 실행 중인) 게임의 이미지는 예를 들어, 주어진 인코딩 프레임 레이트로 인코더(711)에 의해 캡처되고 인코딩될 수 있다. 인코딩된 프레임은 캡슐화 프로세싱 모듈(712)에 의해 복수의 패킷로 캡슐화될 수도 있다. 패킷은 예를 들어 SRT 프로토콜에 기초하여 클라이언트 디바이스로 송신될 수 있다. 예를 들어, 송신 전에, 패킷은 수리 모듈(713)을 통해 (예를 들어, 확인응답되지 않은) 패킷을 재송신할 수 있도록 전송자 SRT 버퍼(714)에 저장될 수 있다. 패킷은 패킷이 전송자 SRT 버퍼에 생성되었을 수 있는 시간, 송신되었을 수 있는 시간 및 저장되었을 수 있는 시간 중 임의의 것과 연관된 타임 스탬프 정보가 있는 타임 스탬프가 찍힐 수 있다(예를 들어, 타임 스탬프를 포함할 수 있다). 서버 인스턴스(71)는 클라이언트 디바이스(72)와 SRT 메시지를 교환하는 것에 기초하여, 전송자 SRT 버퍼(714)의 크기를 조정하도록 구성될 수 있는 레이턴시 관리자 모듈(715)을 포함할 수 있다.
실시예에 따르면, 클라이언트 디바이스(72)는 예를 들어 SRT 프로토콜을 통해 게임의 비디오 프레임을 운반하는 복수의 패킷을 수신할 수 있다. 수신된 패킷은 수신기 SRT 버퍼(724)에 저장될 수 있고, 탈캡슐화 모듈(722)에 의해 탈캡슐화되고 디코딩 모듈(727)에 의해 디코딩되기 위해 패킷에 포함된 타임 스탬프 정보 및 SRT 버퍼 레이턴시에 기초하여 추출될 수 있다. 디코딩 모듈(727)은 디코딩된 프레임 큐(728)에 저장(예를 들어, 푸시)될 수 있는 비디오 프레임을 생성할 수 있다. 프리젠테이션 모듈(729)은 Vsync 신호에 기초하여 디스플레이되기 위한 비디오 프레임을 검색(예를 들어, 팝)할 수 있다.
실시예에 따르면, 클라이언트 디바이스(72)는 끊김의 레벨을 모니터링(예를 들어, 검출, 예측)하도록 구성될 수 있는 끊김 모니터링 모듈(726)을 포함할 수 있다. 클라이언트 디바이스(72)는, 서버와 SRT 메시지를 교환하는 것에 기초하여 수신기 SRT 버퍼(724)의 크기를 조정하도록 구성될 수 있는 레이턴시 관리자 모듈(725)을 포함할 수 있다.
실시예에 따르면, SRT 프로토콜 및 그 레이턴시 버퍼는 서버측의 프로덕션 출력(710)에서와 동일한 페이스로 클라이언트 디바이스 프로토콜 스택(720)의 출력에서 비디오 프레임을 이용가능하게 함으로써 비디오 끊김의 감소를 가능하게 할 수 있다.
본 명세서에 설명된 실시예는, 예를 들어, QoE를 개선하기 위해 SRT 버퍼 레이턴시를 동적으로 적응(예를 들어, 조정)하기 위해 (예를 들어, 게임 세션의 시작에 추가하여) 게임 세션 동안 클라이언트 디바이스와 서버 사이에서 레이턴시 정보를 (예를 들어, 동적으로) 교환 가능하게 할 수 있다.
예를 들어, 클라이언트 디바이스는 비디오 끊김의 발생(들)(예를 들어, 및 레벨(들))을 검출 및 예측하는 것 중 임의의 것에 대한 일부 메트릭을 (예를 들어, 규칙적으로) 모니터링할 수 있다.
실시예에 따르면, 클라이언트 디바이스 및 서버 중 임의의 것은, 예를 들어, (예를 들어, 모니터링된 끊김(예를 들어, 레벨, 예측된 레벨)과 같은) 프레임 페이스 변동에 기초하여, SRT 버퍼에 설정될 새로운 SRT 레이턴시 값을 결정할 수 있다.
실시예에 따르면, 클라이언트 디바이스는 클라이언트 디바이스(예를 들어, 클라이언트 디바이스의 레이턴시 관리자 모듈)에 의해 결정(예를 들어, 선택)될 수 있는 새로운 SRT 버퍼 레이턴시에 서버를 동기화하기 위해 SRT 제어 메시지를 교환할 수 있다. 서버는 클라이언트 디바이스와 상호작용하기 위한 레이턴시 관리자 모듈을 포함할 수 있다.
실시예에 따르면, 클라이언트 디바이스의 프리젠테이션 모듈(729)의 동기화는 비디오 프레임 스키핑을 감소시키기 위해 새로운 SRT 버퍼 레이턴시 값을 고려하도록 SRT 레이턴시 값 변경에 기초하여 (예를 들어, 동적으로) 조정될 수 있다.
끊김 검출의 예
예를 들어, 끊김 모니터링 모듈은 (예를 들어, 비디오 프레임을 운반하는 패킷이 수신기 SRT 버퍼(724)로부터 추출되었을 수 있는 시간에 대응하는) 프로토콜 스택의 출력 중 임의의 출력에서, 그리고 디코딩 모듈(723)의 출력(예를 들어, 디코딩 전 및 후 중 임의의 출력)에서 프레임의 시간 도달을 획득(예를 들어, 모니터링)할 수 있다.
예를 들어, 끊김 모니터링 모듈은 하나의 프레임을 운반하는 패킷의 세트의 첫 번째 패킷 및 마지막 패킷 중 임의의 패킷의 시간 도달을 모니터링할 수 있다. 예를 들어, 패킷은 패킷이 비디오 프레임의 첫 번째 패킷에 해당하는지 또는 마지막 패킷에 해당하는지 여부를 표시하는 시그널링 정보를 포함할 수 있다.
예를 들어, (예를 들어, 비디오 끊김 레벨 및 프레임 페이스 변동 중 임의의 것을 나타내는) 메트릭은 클라이언트 디바이스의 임의의 지점에서 임의의 모니터링된 시간 도달(예를 들어, 프레임, 패킷 중 임의의 것)에 분산 함수를 적용함으로써 획득될 수도 있다. 분산 함수는 (예를 들어, 슬라이딩) 윈도우, 평균, 중앙값, 표준 편차, 분산, 평균 절대 편차(MAD), 사분위수간(interquartile) 범위, 및 임의의 다른 유형의 범위 함수(예를 들어, [25% 내지 75%] 범위 초과)에 적용된 프레임간 지연 변동(지터로컬) 함수 중 임의의 것에 기초할 수도 있다.
예를 들어, 끊김 모니터링 모듈은 (예를 들어, 디코딩된 프레임 큐(728)의 오버플로우의 경우에) 초당 드롭된 프레임의 수 및 초당 지연된 프레임(예를 들어, VSync를 누락했을 수 있는 프레임)의 수 중 임의의 것을 획득(예를 들어, 모니터링)할 수 있다. 예를 들어, 끊김 모니터링 모듈은 (동일한 기간 동안) 프레임의 제1 수의 프레임의 제2 수에 대한 비를 획득할 수 있고, 여기서 제1 수는 (예를 들어, 프리젠테이션 시간에 따라) 제 시간에 디스플레이된 프레임에 대응할 수 있고, 프레임의 제2 수는 (예를 들어, 복제된 프레임을 포함하여) 디스플레이된 프레임의 총 수에 대응할 수 있다.
예를 들어, (예를 들어, 송신에서의 에러로 인해) 수신 레이트가 캡처 레이트보다 낮은 경우, 끊김 모니터링 모듈은 초당 수신된(예를 들어, 디코딩된) 프레임의 수, 디코딩 후의 프레임 에러의 수, 및 (예를 들어, 패킷 에러, 잘못 정렬된 패킷, 서버 및 클라이언트 측 중 임의의 것에서의 패킷 드롭과 같은) 프로토콜 스택으로부터의 임의의 통계 중 임의의 것을 획득(예를 들어, 모니터링)할 수 있다.
예를 들어, 본 명세서에 기술된 임의의 예에 따른 임의의 메트릭은 클라이언트 디바이스(72) 및 서버(71) 중 임의의 것 상에 위치될 수 있는 레이턴시 관리자 모듈(715, 725)에 의해 프로세싱될 수 있다. 레이턴시 관리자 모듈(715, 725)은 본 명세서에 기술된 임의의 모니터링된 메트릭에 적용된 것(예를 들어, 임의의 분산 함수)에 기초하여 예를 들어, 비디오 끊김의 레벨 및 프레임 페이스 변동 중 임의의 것을 나타내는 메트릭을 획득하도록 구성될 수 있다.
제1 예에서, 레이턴시 관리자 모듈(725)은 클라이언트 디바이스에 포함될 수 있고, 클라이언트 디바이스는 예를 들어 비디오 끊김의 레벨 및 프레임 페이스 변동 중 임의의 것을 나타내는 메트릭을 획득할 수 있다. 제2 예에서, 레이턴시 관리자 모듈(755)은 서버에 포함될 수 있고, 클라이언트 디바이스는 본 명세서에 기술된 바와 같은 임의의 모니터링된 메트릭을 서버에 송신할 수 있다. 제1 예 및 제2 예 중 임의의 예에서, 새로운 SRT 레이턴시 값은 본 명세서에 기술된 임의의 실시예에 따른 메트릭에 기초하여 결정(예를 들어, 요청)될 수 있다.
레이턴시 관리자 모듈(715, 725)에 의해 획득된, 비디오 끊김의 레벨을 나타내는 메트릭은 본 명세서에서 Y = StutteringValue(ti, 윈도우) 로 지칭될 수도 있고, 여기서 ti는 i번째 프레임의 수신(각각 디코딩) 시간을 나타낼 수도 있고, 윈도우는 메트릭이 프로세싱(조합, 계산)될 수 있는 시간 간격(예를 들어, ti-윈도우, ti])을 나타낼 수 있다. 메트릭 Y는, 예를 들어, (예를 들어, 각각의) 새로운 인입 프레임 Fi에 대해 획득될 수도 있다.
실시예에 따르면, 레이턴시 관리자 모듈(715, 725)은 과거 값의 이력에 기초하여 메트릭 Y의 (예를 들어, 예측된) 값(본 명세서에서 Y예측으로 지칭될 수 있음)을 획득할 수 있다. 예를 들어, 새로운 SRT 레이턴시 값(본 명세서에서 SRTBufferLatency타겟으로 지칭될 수 있음)은 예를 들어, Y(예를 들어, Y예측) 중 임의의 것의 이력 및 예를 들어, 상이한 선행 기간 동안의 프레임 페이스 변동에 기초하여 획득될 수 있다. 새로운 SRT 버퍼 레이턴시 값은 SRT 클라이언트에서 설정될 수 있고, (예를 들어, 예측된) 끊김 값을 감소시키기에 충분히 큰 (예를 들어, 가장 낮은) 레이턴시 값에 대응할 수 있다. 예를 들어, 새로운 SRT 레이턴시 값은 (예를 들어, 초기 SRT 레이턴시 값에 비해) 증가될 수 있지만, 나머지는 레이턴시가 값 이상으로 증가하지 않는 한도로 제한된 상태일 수 있다. 예를 들어, 새로운 SRT 레이턴시 값은 히스테리시스에 기초하여 획득될 수 있다. 예를 들어, 레이턴시는 끊김의 레벨이 제1 레벨(예를 들어, 최대 임계치)보다 높은 경우 (예를 들어, 제1 값만큼) 증분될 수 있고 끊김의 레벨이 제2 레벨(예를 들어, 임계치)보다 낮은 경우 (예를 들어, 제2 값만큼) 감소될 수 있다. 보다 일반적으로, 새로운(예를 들어, 요청된) 레이턴시 값은 (예를 들어, 클라이언트 디바이스 및 서버 중 임의의 것에 위치될 수 있는 레이턴시 관리자 모듈(715, 725)에 의해) 프레임 페이스 변동에 기초하여 결정될 수 있다. 예를 들어, (예를 들어, 관측, 측정, 예측된) 프레임 페이스 변동이 증가하는 경우, 새로운(예를 들어, 요청된) 레이턴시 값은 (초기 레이턴시 값에 비해) 증가하는 것으로 결정될 수 있고, (관측, 측정, 예측된) 프레임 페이스 변동이 감소하는 경우, 새로운(예를 들어, 요청된) 레이턴시 값은 (초기 레이턴시 값에 비해) 감소하는 것으로 결정될 수 있다.
SRT 레이턴시는 본 명세서에 기술된 실시예에 개시된 바와 같이 SRT 메시지를 교환함으로써 전송자 및 클라이언트 디바이스에서 조정(예를 들어, 업데이트)될 수 있다. 예를 들어, SRT 버퍼링 레이턴시 업데이트는 (예를 들어, 레이턴시 관리자 모듈의 위치에 따라) 클라이언트 디바이스 또는 서버 중 임의의 것에서 주도적으로 이루어질 수 있다(예를 들어, 임의의 것에 의해 트리거될 수 있다).
예를 들어, 제한 없이, 새로운 SRT 레이턴시 값은 다음 수학식에 의해 기술되는 바와 같이, 도착간 시간 Ti에 적용되는 프레임간 지연 변동(지터로컬) 함수에 기초하여 획득될 수 있다:
Figure pct00003
SRT 세션 레이턴시 설정의 예
예를 들어, (예를 들어, SRT 버퍼 레이턴시 값의 설정을 통한) 레이턴시는 확장된 핸드쉐이크 위상 동안 구성될 수 있고 게임 세션에 대해 동일한 값으로 유지될 수 있다.
실시예에 따르면, SRT 프로토콜은 라이브 송신 모드 및 클라우드 게이밍 송신 모드 중 임의의 것을 포함할 수 있다. 클라우드 게이밍 송신 모드는 예를 들어 SRT 세션의 생성 후에(예를 들어, 및 임의의 시간에) SRT 레이턴시 값을 동적으로 업데이트(예를 들어, 조정)하는 능력과 연관될 수 있다.
도 8a는 확장된 핸드쉐이크 패킷 포맷의 2개의 예를 예시하는 도면이다. 제1 예에서, HSv4 확장된 핸드쉐이크 패킷(81)은 동적 SRT 레이턴시 업데이트를 지원하는지 여부의 능력을 표시하는 능력 정보(810)를 포함할 수 있다. 제2 예에서, HSv5 확장된 핸드쉐이크 패킷(82)은 동적 SRT 레이턴시 업데이트를 지원하는지 여부의 능력을 표시하는 능력 정보(820)를 포함할 수 있다.
예를 들어, 동적 SRT 레이턴시 업데이트를 지원하는 능력은 본 명세서에서 SRT_OPT_DYNTSBPD(예를 들어, 동적 타임스탬프 버퍼 패킷 전달)로 지칭될 수 있는 SRT 플래그(810, 820) 필드의 7번째 비트에 의해 표시될 수 있다. SRT_OPT_DYNTSBPD 플래그가 1로 설정된 SRT 메시지는 동적 SRT 레이턴시 업데이트를 지원하는 SRT 메시지의 전송자의 능력을 표시할 수 있다. SRT 플래그(810, 820) 필드의 임의의 다른 비트를 통해 동적 SRT 레이턴시 업데이트를 지원하는 능력을 표시하는 것은 본 명세서에 기술된 실시예에 적용될 수 있다.
도 8b는 핸드쉐이크 확장 메시지 플래그의 일 예를 예시하는 도면이다. 예를 들어, SRT_OPT_DYNTSBPD에 대한 비트마스크는 0x00000100일 수 있다.
본 명세서에 기술된 실시예는 단일 비트 플래그를 통해 동적 SRT 레이턴시 업데이트를 지원하는 능력을 표시하는 것으로 제한되지 않는다. 예를 들어, 동적 SRT 레이턴시 업데이트를 지원하는 능력을 표시하는 SRT 확장된 핸드쉐이크 패킷의 필드의 임의의 값이 본 명세서에 기술된 실시예에 적용될 수 있다.
실시예에 따르면, 임의의 엔티티(예를 들어, SRT 청취자 및 SRT 호출자 중 임의의 것)는 동적 SRT 레이턴시 업데이트가 게임 세션에 대해 활성화될 수 있는지를 표시할 수 있다. 다른 엔티티는 동적 SRT 레이턴시 업데이트의 수락 및 활성화 거부 중 임의의 것을 할 수 있다.
도 9a는 레이턴시 동적 변경을 지원하는 능력을 나타내기 위한 확장된 핸드쉐이크 메시지 교환의 일 예를 예시하는 도면이다. 예를 들어, 메시지 교환은 서버에 의해 개시될 수 있다.
제1 예(90A)에서, 클라이언트 디바이스는 동적 SRT 레이턴시 업데이트를 지원하는 서버 능력을 표시하는 정보를 포함하는 SRT 확장된 핸드쉐이크 요청 메시지(901A)를 수신할 수 있다. 예를 들어, 클라이언트 디바이스는 동적 SRT 레이턴시 업데이트를 지원하는 클라이언트 능력을 표시하는 정보를 포함하는 SRT 확장된 핸드쉐이크 응답 메시지(902A)를 송신함으로써 게임 세션 동안 동적 SRT 레이턴시 업데이트를 수행하는 것을 수락할 수 있다.
제2 예(91A)에서, 클라이언트 디바이스는 서버로부터 동적 SRT 레이턴시 업데이트 지원이 없음을 표시하는 정보를 포함하는 제1 SRT 확장된 핸드쉐이크 요청 메시지(911A)를 수신할 수 있다. 예를 들어, 클라이언트 디바이스는 동적 SRT 레이턴시 업데이트를 수행하도록 서버에 요청하기 위해 동적 SRT 레이턴시 업데이트를 지원하는 클라이언트 능력을 표시하는 정보를 포함하는 제1 SRT 확장된 핸드쉐이크 응답 메시지(912A)를 송신할 수 있다. 예를 들어, 클라이언트 디바이스는 서버로부터 동적 SRT 레이턴시 업데이트 지원이 없음을 확인하는 정보를 포함하는 제2 SRT 확장된 핸드쉐이크 요청 메시지(913A)를 수신할 수 있다. 예를 들어, 클라이언트 디바이스는 게임 세션에서 동적 SRT 레이턴시 업데이트가 수행될 수 없음을 확인하는 정보를 포함하는 제2 SRT 확장된 핸드쉐이크 응답 메시지(914A)를 송신할 수 있다.
제3 예(92A)에서, 클라이언트 디바이스는 서버로부터 동적 SRT 레이턴시 업데이트 지원이 없음을 표시하는 정보를 포함하는 제1 SRT 확장된 핸드쉐이크 요청 메시지(921A)를 수신할 수 있다. 예를 들어, 클라이언트 디바이스는 동적 SRT 레이턴시 업데이트를 수행하도록 서버에 요청하기 위해 동적 SRT 레이턴시 업데이트를 지원하는 클라이언트 능력을 표시하는 정보를 포함하는 제1 SRT 확장된 핸드쉐이크 응답 메시지(922A)를 송신할 수 있다. 예를 들어, 클라이언트 디바이스는 게임 세션 동안 동적 SRT 레이턴시 업데이트를 수행한다는 서버로부터의 동의를 표시하는, 동적 SRT 레이턴시 업데이트를 지원하는 서버 능력을 표시하는 정보를 포함하는 제2 SRT 확장된 핸드쉐이크 요청 메시지(923A)를 수신할 수 있다. 예를 들어, 클라이언트 디바이스는 게임 세션에서 동적 SRT 레이턴시 업데이트가 수행될 수 있음을 확인하는 정보를 포함하는 제2 SRT 확장된 핸드쉐이크 응답 메시지(924A)를 송신할 수 있다.
도 9b는 레이턴시 동적 변경을 지원하는 능력을 나타내기 위한 확장된 핸드쉐이크 메시지 교환의 다른 예를 예시하는 도면이다. 예를 들어, 메시지 교환은 클라이언트 디바이스에 의해 개시될 수 있다.
제1 예(90B)에서, 클라이언트 디바이스는, 게임 세션 동안 SRT 레이턴시를 동적으로 업데이트할 수 있도록 서버에 요청하기 위해, 동적 SRT 레이턴시 업데이트를 지원하는 클라이언트 디바이스 능력을 표시하는 정보를 포함하는 SRT 확장된 핸드쉐이크 요청 메시지(901B)를 전송할 수 있다. 클라이언트 디바이스는 게임 세션 동안 동적 SRT 레이턴시 업데이트를 수행한다는 서버로부터의 동의를 표시할 수 있는, 동적 SRT 레이턴시 업데이트를 지원하는 서버 능력을 표시하는 정보를 포함하는 SRT 확장된 핸드쉐이크 응답 메시지(902B)를 수신할 수 있다.
제2 예(91B)에서, 클라이언트 디바이스는 클라이언트 디바이스로부터 동적 SRT 레이턴시 업데이트 지원이 없음을 표시하는 정보를 포함하는 제1 SRT 확장된 핸드쉐이크 요청 메시지(911B)를 전송할 수 있다. 예를 들어, 클라이언트 디바이스는 동적 SRT 레이턴시 업데이트를 수행하도록 클라이언트 디바이스에 요청하기 위해 동적 SRT 레이턴시 업데이트를 지원하는 서버 능력을 표시하는 정보를 포함하는 제1 SRT 확장된 핸드쉐이크 응답 메시지(912B)를 수신할 수 있다. 예를 들어, 클라이언트 디바이스는 서버 요청을 거절하기 위해, 클라이언트 디바이스로부터 동적 SRT 레이턴시 업데이트 지원이 없음을 확인하는 정보를 포함하는 제2 SRT 확장된 핸드쉐이크 요청 메시지(913B)를 전송할 수 있다. 예를 들어, 클라이언트 디바이스는 게임 세션에서 동적 SRT 레이턴시 업데이트가 수행될 수 없음을 확인하는 정보를 포함하는 제2 SRT 확장된 핸드쉐이크 응답 메시지(914B)를 수신할 수 있다.
제3 예(92B)에서, 클라이언트 디바이스는 동적 SRT 레이턴시 업데이트 지원이 없음을 표시하는 정보를 포함하는 제1 SRT 확장된 핸드쉐이크 요청 메시지(921B)를 전송할 수 있다. 예를 들어, 클라이언트 디바이스는 동적 SRT 레이턴시 업데이트를 수행하도록 클라이언트 디바이스에 요청하기 위해 동적 SRT 레이턴시 업데이트를 지원하는 서버 능력을 표시하는 정보를 포함하는 제1 SRT 확장된 핸드쉐이크 응답 메시지(922B)를 수신할 수 있다. 예를 들어, 클라이언트 디바이스는 게임 세션 동안 동적 SRT 레이턴시 업데이트를 수행한다는 동의를 표시하기 위해, 동적 SRT 레이턴시 업데이트를 지원하는 클라이언트 능력을 표시하는 정보를 포함하는 제2 SRT 확장된 핸드쉐이크 요청 메시지(923B)를 전송할 수 있다. 예를 들어, 클라이언트 디바이스는 게임 세션에서 수행될 수 있는 동적 SRT 레이턴시 업데이트를 확인하는 정보를 포함하는 제2 SRT 확장된 핸드쉐이크 응답 메시지(924B)를 수신할 수 있다.
SRT 세션 레이턴시 변경의 예
예를 들어, 동적 레이턴시 업데이트가 (예를 들어, 주어진) SRT 세션 상에서 (예를 들어, SRT 확장된 핸드쉐이크 능력 교환에 기초하여) 동작할 수 있는 후에, 수신기는 예를 들어, 비디오 끊김의 검출에 기초하여 레이턴시 변경 절차(예를 들어, 동적 SRT 레이턴시 업데이트)를 활성화할 수 있다. 본 명세서에 기술된 실시예 전체에 걸쳐, 표현 "동적 SRT 레이턴시 업데이트" 및 "레이턴시 변경 절차"는 서버 및 클라이언트 디바이스에서 SRT 레이턴시 값을 업데이트할 목적으로 SRT 메시지의 교환을 지칭하기 위해 상호 교환적으로 사용될 수 있다.
예를 들어, 새로운 SRT 레이턴시 값은 본 명세서에 기술된 임의의 실시예에 따라 획득될 수 있다. 본 명세서에서 추가로 기술되는 바와 같이, 레이턴시 변경 절차는 클라이언트 디바이스 및 서버 중 임의의 것에 의해 개시될 수 있다.
실시예에 따르면, 개시자(예를 들어, 서버 및 클라이언트 디바이스 중 임의의 것)는 새로운 SRT 레이턴시 값을 표시하는, 본 명세서에서 동적 타임스탬프 버퍼 패킷 전달(DYNTSBPD) 요청 메시지로 지칭될 수 있는 SRT 요청 메시지를 전송할 수 있다.
도 10은 새로운 SRT 레이턴시 값을 요청하기 위한 SRT 메시지의 포맷의 일 예를 예시하는 도면이다. 예를 들어, SRT 동적 타임스탬프 버퍼 패킷 전달(DYNTSBPD) 요청 메시지(1010)는 SRT 레이턴시 변경 절차의 개시자(예를 들어, 서버 및 클라이언트 디바이스 중 임의의 것)에 의해 요청되고 있는 새로운 SRT 레이턴시 값을 표시하는 제1 정보를 포함할 수 있다. 예를 들어, SRT DYNTSBPD 응답 메시지(1020)는 새로운 SRT 레이턴시 값이 개시자(예를 들어, 서버 및 클라이언트 디바이스 중 임의의 것)에 의해 요청되는 것에 응답하여 응답된 SRT 레이턴시 값을 표시하는 제2 정보를 포함할 수 있다. SRT DYNTSBPD 응답 메시지(1020)는 개시자에 의해 전송된 SRT DYNTSBPD 요청 메시지(1010)에 응답하여 상대방(예를 들어, 서버 및 클라이언트 디바이스 중 임의의 것)에 의해 전송될 수 있다.
도 11a도 11b는 클라이언트 디바이스 및 서버에 의해 각각 개시되는 동적 레이턴시 변경 절차에 대한 메시지 교환의 2개의 예를 예시하는 2개의 도면이다.
도 10 도 11a를 참조하면, 단계(1110A)에서, 클라이언트 디바이스는 게임의 비디오 프레임을 운반하는 패킷을 수신할 수 있고, 이를 SRT 프로토콜에 따라 확인응답할 수 있다. 클라이언트 디바이스는 본 명세서에 기술된 임의의 실시예에 따라 메트릭 및 새로운 SRT 레이턴시 값 중 임의의 것을 획득할 수 있다.
예를 들어, 단계(1120A)에서, SRT DYNTSBPD 요청 메시지(1010, 1121A)는 클라이언트 디바이스에 의해 게임 서버로 전송될 수 있다. 새로운(예를 들어, 요청된) SRT 레이턴시 값은 SRT DYNTSBPD 요청 메시지(1010, 1121A)에 포함될 수 있는 제1 정보(예를 들어, TsbPd Rcv 필드)(1011)에 표시될 수 있다. 예를 들어, SRT DYNTSBPD 요청 메시지(1010, 1121A)는 초기 SRT 레이턴시를 표시할 수 있는 전송자 레이턴시 값을 표시하는 TsbPd Snd 필드(1012)를 포함할 수 있다. 초기 SRT 레이턴시는 예를 들어, SRT 레이턴시 업데이트 전에 (예를 들어, 현재 SRT 레이턴시 값을) 표시할 수 있다. 초기 SRT 레이턴시는 (예를 들어, 초기) SRT 핸드쉐이크 동안 동의된 값일 수 있다.
예를 들어, 단계(1130A)에서, 서버는 SRT 레이턴시 값을 새로운(예를 들어, 요청된) 값으로 업데이트하는 것을 수락할 수 있다. 수락을 표시하기 위해, 서버는 새로운 SRT 레이턴시 값을 표시하는 SRT DYNTSBPD 응답 메시지(1020, 1131A)를 클라이언트 디바이스에 송신할 수 있다. SRT DYNTSBPD 응답 메시지(1020, 1131A)는 새로운(예를 들어, 요청된) SRT 레이턴시 값으로 설정될 수 있는 제2 정보(예를 들어, TsbPd Snd 필드)(1022)를 포함할 수 있다. 예를 들어, SRT DYNTSBPD 응답 메시지(1020, 1131A)는 새로운 SRT(예를 들어, 요청된) 레이턴시 값으로 설정될 수 있는 TsbPd Snd 필드(1021)를 포함할 수 있다. 단계(1132A)에서, 클라이언트 디바이스는 새로운 SRT 레이턴시 값의 수락을 표시하는 SRT DYNTSBPD 응답 메시지(1020, 1131A)의 수신 후, SRT 수신기 레이턴시 값을 새로운 SRT 레이턴시 값으로 업데이트할 수 있다.
예를 들어, 단계(1140A)에서, 서버는 변경을 거부(예를 들어, 거절)할 수 있다. 거절을 표시하기 위해, 서버는 현재(예를 들어, 초기) SRT 값을 표시하는 SRT DYNTSBPD 응답 메시지(1020, 1141A)를 클라이언트 디바이스에 송신할 수 있다. SRT DYNTSBPD 응답 메시지(1020, 1141A)는 현재(예를 들어, 초기) SRT 레이턴시 값으로 설정될 수 있는 제2 정보(예를 들어, TsbPd Snd 필드)(1022)를 포함할 수 있다. 단계(1142A)에서, 클라이언트 디바이스는 새로운 SRT 레이턴시 값의 거절을 표시하는 제2 정보를 포함하는 SRT DYNTSBPD 응답 메시지(1020, 1141A)의 수신 후, SRT 수신기 레이턴시 값을 현재(예를 들어, 초기) SRT 레이턴시 값으로 유지할 수 있다.
예를 들어, 단계(1150A)에서, 서버는 SRT 레이턴시 값을 업데이트하는 것을 수락할 수 있지만, (예를 들어, 새로운 값과는 상이한) 대안적인 값을 사용할 수 있다. 예를 들어, 대안적인 값은 현재(예를 들어, 초기) SRT 레이턴시 값과 새로운(예를 들어, 요청된) SRT 레이턴시 값 사이에 엄격하게 포함된 임의의 SRT 레이턴시 값일 수 있다.
부분적 수락(예를 들어, 및 대안적인 제안)을 표시하기 위해, 서버는 대안적인 SRT 값을 표시하는 SRT DYNTSBPD 응답 메시지(1020, 1151A)를 클라이언트 디바이스에 송신할 수 있다. SRT DYNTSBPD 응답 메시지(1020, 1151A)는 대안적인 SRT 레이턴시 값으로 설정될 수 있는 제2 정보(예를 들어, TsbPd Snd 필드)(1022)를 포함할 수 있다. 단계(1152A)에서, 클라이언트 디바이스는, 대안적인 SRT 레이턴시 값을 표시하는 제2 정보를 포함하는 SRT DYNTSBPD 응답 메시지(1020, 1151A)의 수신 후, SRT 수신기 레이턴시 값을 대안적인 SRT 레이턴시 값으로 업데이트할 수 있다.
도 10 도 11b를 참조하면, 단계(1110B)에서, 클라이언트 디바이스는 게임의 비디오 프레임을 운반하는 패킷을 수신할 수 있고, 이를 SRT 프로토콜에 따라 확인응답할 수 있다. 클라이언트 디바이스는 본 명세서에 기술된 임의의 실시예에 따라 메트릭 및 새로운 SRT 레이턴시 값 중 임의의 것을 획득할 수 있다.
예를 들어, 단계(1111B)에서, 클라이언트 디바이스는 예를 들어, 비디오 프레임 페이스 변동을 나타내는 정보를 포함하는 메시지를 전송할 수 있다. 예를 들어, 정보는 본 명세서에 기술된 임의의 실시예에 따라 클라이언트 디바이스에서의 임의의 도착 시간의 모니터링에 기초하여 획득된 임의의 메트릭의 임의의 값을 기술(예를 들어, 표시)할 수 있다.
예를 들어, 단계(1120B)에서, SRT DYNTSBPD 요청 메시지(1010, 1121B)는 서버에 의해 클라이언트로 전송될 수 있다. 새로운(예를 들어, 요청된) SRT 레이턴시 값은 SRT DYNTSBPD 요청 메시지(1010, 1121B)에 포함될 수 있는 제1 정보(예를 들어, TsbPd Snd 필드)(1012)에 표시될 수 있다. 예를 들어, SRT DYNTSBPD 요청 메시지(1010, 1121B)는 현재(예를 들어, 초기) SRT 레이턴시를 표시할 수 있는 수신기 레이턴시 값을 표시하는 TsbPd Rcv 필드(1011)를 포함할 수 있다.
예를 들어, 단계(1130B)에서, 클라이언트 디바이스는 SRT 레이턴시 값을 새로운 값으로 업데이트하는 것을 수락할 수 있다. 예를 들어, 클라이언트 디바이스는 새로운 값에 따라 SRT 수신기 버퍼 레이턴시를 업데이트할 수 있다. 수락을 표시하기 위해, 클라이언트 디바이스는 새로운 SRT 레이턴시 값을 표시하는 SRT DYNTSBPD 응답 메시지(1020, 1131B)를 서버에 송신할 수 있다. SRT DYNTSBPD 응답 메시지(1020, 1131B)는 새로운(예를 들어, 요청된) SRT 레이턴시 값으로 설정될 수 있는 제2 정보(예를 들어, TsbPd Rcv 필드)(1021)를 포함할 수 있다. 예를 들어, SRT DYNTSBPD 응답 메시지(1020, 1131B)는 새로운 SRT(예를 들어, 요청된) 레이턴시 값으로 설정될 수 있는 TsbPd Snd 필드(1022)를 포함할 수 있다. 단계(1132B)에서, 서버는 새로운 SRT 레이턴시 값의 수락을 표시하는 SRT DYNTSBPD 응답 메시지(1020, 1131B)의 수신 후, SRT 전송자 레이턴시 값(SndTsbPdDelay)을 새로운 SRT 레이턴시 값으로 업데이트할 수 있다.
예를 들어, 단계(1140B)에서, 클라이언트 디바이스는 변경을 거절(예를 들어, 거부)할 수 있고, SRT 수신기 레이턴시 값을 현재(예를 들어, 초기) SRT 레이턴시 값으로 유지할 수 있다. 거절을 표시하기 위해, 클라이언트는 현재(예를 들어, 초기) SRT 값을 표시하는 SRT DYNTSBPD 응답 메시지(1020, 1141B)를 서버에 송신할 수 있다. SRT DYNTSBPD 응답 메시지(1020, 1141B)는 현재(예를 들어, 초기) SRT 레이턴시 값으로 설정될 수 있는 제2 정보(예를 들어, TsbPd Rcv 필드)(1021)를 포함할 수 있다. 단계(1142B)에서, 서버는 새로운 SRT 레이턴시 값의 거절을 표시하는 SRT DYNTSBPD 응답 메시지(1020, 1131B)의 수신 후, SRT 전송자 레이턴시 값을 현재(예를 들어, 초기) SRT 레이턴시 값으로 유지할 수 있다.
예를 들어, 단계(1150A)에서, 클라이언트 디바이스는 SRT 레이턴시 값을 업데이트하는 것을 수락할 수 있지만, (예를 들어, 새로운 값과는 상이한) 대안적인 값을 사용할 수 있다. 예를 들어, (예를 들어, 서버에 의해 요청된) 새로운 값은 클라이언트 디바이스 버퍼링 능력과 호환되지 않을 수 있다(버퍼가 너무 작을 수 있음). 다른 예에서, 클라이언트 디바이스는 (예를 들어, 새로운 레이턴시가 현재 RTT 값의 3배보다 낮은 경우에) 재송신 기술이 누락 패킷을 (예를 들어, 효율적으로) 복구할 수 있게 하기 위해, 서버에 의해 요청된 새로운 SRT 레이턴시 값이 너무 작을 수 있다고 결정할 수 있다. 예를 들어, 대안적인 값은 현재(예를 들어, 초기) SRT 레이턴시 값과 새로운(예를 들어, 요청된) SRT 레이턴시 값 사이에 엄격하게 포함된 임의의 SRT 레이턴시 값일 수 있다. 부분적 수락(예를 들어, 및 대안적인 제안)을 표시하기 위해, 클라이언트 디바이스는 대안적인 SRT 값을 표시하는 SRT DYNTSBPD 응답 메시지(1020, 1151B)를 서버에 송신할 수 있다. SRT DYNTSBPD 응답 메시지(1020, 1151B)는 대안적인 SRT 레이턴시 값으로 설정될 수 있는 제2 정보(예를 들어, TsbPd Rcv 필드)(1021)를 포함할 수 있다. 단계(1152B)에서, 서버는 대안적인 SRT 레이턴시 값을 표시하는 SRT DYNTSBPD 응답 메시지(1020, 1151B)의 수신 후, SRT 전송자 레이턴시 값을 대안적인 SRT 레이턴시 값으로 업데이트할 수 있다.
본 명세서에 기술된 실시예는 본 명세서에 기술된 SRT 메시지 포맷(들)(예를 들어, 필드), 임의의 다른 SRT 메시지 포맷으로 제한되지 않으며, 보다 일반적으로 서버와 클라이언트 디바이스 사이의 버퍼 크기를 업데이트하기 위한 임의의 다른 프로토콜에 따른 임의의 메시지가 본 명세서에 기술된 실시예에 적용될 수 있다.
프로토콜 레이턴시 업데이트에 대한 프리젠테이션 모듈 프로세싱의 예
클라이언트 디바이스(예를 들어, 클라이언트 디바이스의 프리젠테이션 프로세싱 모듈)의 프로세싱의 예는, 예를 들어, 도 7을 참조하여 본 명세서에서 기술된다.
제1 예에서, 클라이언트 디바이스(예를 들어, 클라이언트 디바이스의 프리젠테이션 프로세싱 모듈(729))의 프로세싱은 임의의 SRT 레이턴시(예를 들어, 동적) 업데이트의 경우에 불가지론적(agnostic)(예를 들어, 변경되지 않음)일 수 있다. 예를 들어, 프리젠테이션 프로세싱 모듈(729)은 디코딩된 프레임 큐(728)에서 디코딩된 프레임을 획득(예를 들어, 청취)할 수 있다. VSync 신호의 (예를 들어, 각각의) 주기에, 하나의 이용가능한 프레임이 큐(728)로부터 팝(예를 들어, 추출)되어 화면에 디스플레이될 수 있다. VSync 신호 주기에 어떠한 프레임도 큐에서 이용가능하지 않은 경우, 이전에 제시된(예를 들어, 디스플레이된) 프레임이 다시 제시(예를 들어, 디스플레이)될 수 있다. 디코딩된 프레임 큐(728)가 오버플로우되는 경우, 임의의 기준에 따라 임의의 수의 프레임이 드롭될 수 있다. 기준은, 예를 들어, 프레임의 프리젠테이션 시간과는 독립적일 수 있다.
제2 예에서, 클라이언트 디바이스(예를 들어, 클라이언트 디바이스의 프리젠테이션 프로세싱 모듈(729))는 (예를 들어, 각각의) 프레임과 연관된 프리젠테이션 시간을 프로세싱할 수 있다. 예를 들어, SRT 레이턴시 값이 새로운 값으로 업데이트되는 경우에, 프리젠테이션 프로세싱 모듈(729)은 (예를 들어, 클라이언트 디바이스 내부의 임의의 메커니즘에 따라) 이러한 변경을 통지(예를 들어, 표시) 받을 수 있다. 예를 들어, SRT 레이턴시 업데이트는 추가적인 부호있는 지연(예를 들어, 레이턴시 증가의 경우에는 양(positive)이고 그렇지 않은 경우에는 음(negative))의 형태로 나타낼(예를 들어, 표시될) 수 있다. 예를 들어, 이전 프로토콜 레이턴시와 현재 프로토콜 레이턴시 사이의 차이에 대응하는 추가적인 부호있는 지연은 (예를 들어, 디코딩을 위해) 애플리케이션에 전달되기 전에, 프레임이 프로토콜 스택에서 버퍼링되었을 수 있는 추가적인 부호있는 시간을 나타낼 수 있다.
예를 들어, 프리젠테이션 프로세싱 모듈(729)은, 제1 프레임(F0)이 VSync 주기에서 스크린 상에 제시(예를 들어, 디스플레이)될 수 있는 시간에 대응할 수 있는, 클록 기준 시간(T0)을 획득(예를 들어, 홀딩)할 수 있다. 단순화를 위해 그리고 일반성의 손실 없이, 프레임은 캡처 레이트로 순차적으로 전달될 수 있다. 예를 들어, 프레임은 프레임의 시퀀스 인덱스로부터 획득(예를 들어, 유도)될 수 있는 계산된 프리젠테이션 시간 Ti에 기초하여 제시(예를 들어, 디스플레이)될 수 있다(예를 들어, i 번째 프레임 Fi는 Ti = T0 + i x 캡처_주기에서 제시될 수 있다). SRT 레이턴시가 업데이트되는 경우, 추가적인 부호있는 지연은 클록 기준 시간을 양으로 또는 음으로 시프트하는 데 사용될 수 있고, 예를 들어, T0 = T0 + 지연이 된다.
예를 들어, SRT 레이턴시가 증가하는 경우, 프리젠테이션을 위해 디코딩된 프레임 큐(728)로부터 프레임을 팝하는 동작을 복원하기 전에, 마지막으로 디스플레이된 프레임이 레이턴시 증가에 대응하는 횟수 동안 다시 디스플레이될 수 있다(예를 들어, 디스플레이를 위해 디코딩된 프레임 큐(728)로부터 어떠한 프레임도 팝되지 않을 수 있다). SRT 레이턴시 증가에서의 (복제될 수 있는) 마지막 디스플레이 프레임은 SRT 레이턴시가 업데이트되었을 수 있기 전에 디스플레이되었을 수 있는 마지막 프레임에 대응할 수 있다. 예를 들어, (예를 들어, 60 ㎐ 스크린의 2회의 주기에 대응하는) 33 밀리초의 SRT 레이턴시 증가가 프리젠테이션 시간 Ti에서 발생하는 경우(예를 들어, 프레임 Fi가 디스플레이되었을 수 있는 후에), 프리젠테이션 모듈은 프리젠테이션 모듈이 큐로부터 임의의 프레임을 팝할 수 있기 전에 2개의 다음(예를 들어, 캡처) 주기에 대해 이 동일한 프레임을 디스플레이할 수 있다. 예를 들어, 하나의 프레임이 3주기 동안 정지될 수 있는 한편, 모든 후속 프레임은 어떠한 끊김 없이 일정한 간격으로 디스플레이될 수 있다. 레이턴시 버퍼 증가에 대응하는 (예를 들어, 단일) 시점에서 프레임을 복제하면 레이턴시 변경 시간에 임의의 끊김 이슈를 집중 가능하게 할 수 있어서, 전체 QoE 개선에 기여할 수 있다.
예를 들어, 추가적인 부호있는 지연에 기초하여 클록 기준 시간을 조정하면 또한 어느(예를 들어, 늦은) 프레임이 드롭될(예를 들어, 디스플레이되지 않을) 수 있는지를 결정 가능하게 할 수 있다. 예를 들어, 프레임 Fi가 너무 늦게 디코딩되어 제 시간에 제시되지 않는 경우, 및 다음 프레임 Fi+1이 디코딩된 프레임 큐(728)에서 이용가능한 경우, 프리젠테이션 프로세싱 모듈은 클록 기준 시간에 기초하여 VSync 신호의 다음 주기에서(예를 들어, 시간 Tsync_주기에서) 어느 프레임이 제시(예를 들어, 디스플레이)될 수 있는지를 결정할 수 있다. 예를 들어, 클록 기준 시간은 T0에 기초하여 각각 i 번째 프레임 및 (i+1) 번째 프레임의 프리젠테이션 시간(Ti 및 Ti+1)을 결정하는 데 사용될 수 있다. 예를 들어, VSync 신호의 다음 주기에서 디스플레이될 프레임은 그 프리젠테이션 시간이 Tsync_주기(예를 들어, |Tsync_주기 ?? Ti|, |Tsync_주기 ?? Ti+1| 사이의 최소)에 가장 가까울 수 있는 (Fi 및 Fi+1 중에서) 프레임일 수 있고, (Fi 및 Fi+1 중에서) 다른 프레임은 드롭될 수 있다.
프로토콜 레이턴시 업데이트에 대한 서버 프로세싱의 예
실시예에 따르면, SRT 버퍼 레이턴시는 전송된 패킷을 (예를 들어, SRT 버퍼 레이턴시에 대응하는 시간량 동안) 유지하기 위해 서버 측에서 사용되어, (예를 들어, 가능한 재송신을 위해) 수신기에 의한 그의 확인응답을 대기할 수 있다. 실시예에 따르면, 서버는 SRT 세션 동안 발생할 수 있는 버퍼 레이턴시 값 변경에 SRT 전송자 버퍼를 적응시킬 수 있다.
제1 예에서, SRT 버퍼 레이턴시(예를 들어, RcvTsbPdDelay)는 클라이언트 디바이스(예를 들어, 수신기)에 의해 감소될 수 있다. 서버(예를 들어, 전송자)는 (예를 들어, 업데이트된 더 짧은 클라이언트 데드라인(예를 들어, 더 낮은 SRT 버퍼 레이턴시)으로 인해 오래되었을 수 있는) 일부 재송신 패킷을 전송하도록 결정할 수 있다. 높은 지터 디스패리티(disparity)(예를 들어, 및 예를 들어 빈번한 버퍼 레이턴시 변경으로 인한, SRT 버퍼 레이턴시의 향후의 증가)를 예상하기 위해, 서버는 버퍼가 가까운 미래에 증가할 경우를 대비하여, 방금 오래되었을 수 있는 패킷을 재송신할 수 있도록 여분의 지속시간 동안 그 패킷을 유지할 수 있다.
제2 예에서, SRT 버퍼 레이턴시가 수신기에 의해 더 많은 패킷을 버퍼링하기 위해 증가되는 경우에, 여분이 시간이 전송자에 의해 더 많은 재송신 패킷을 전송하기 위해 사용될 수 있다.
도 12a는 예를 들어 게임과 같은 비디오 콘텐츠의 QoE를 개선하기 위한 클라이언트(예를 들어, 프로세싱) 디바이스(12A)의 일 예를 예시하는 도면이다. 예를 들어, 프로세싱 디바이스(12A)는 콘텐츠(예를 들어, 게임) 서버와 상호작용할 수 있는 클라우드 게이밍(예를 들어, 씬) 클라이언트를 포함할 수 있다. 예를 들어, 프로세싱 디바이스(12A)는 (예를 들어, 조이스틱, 마우스, 키보드, 원격 제어기 중 임의의 것과 같은) 임의의 수의 입력 디바이스로부터 (예를 들어, 사용자 입력) 커맨드를 수신하도록 구성된 입력 인터페이스(1260)를 포함할 수 있다. 커맨드는 콘텐츠(예를 들어, 게임) 서버로 전달될 수 있다. 예를 들어, 프로세싱 디바이스(12A)는 네트워크에 대한 접속을 위해 네트워크 인터페이스(1200)를 포함할 수 있다. 네트워크 인터페이스(1200)는 서버로부터 복수의 패킷을 수신하도록 구성될 수 있다. 패킷은 클라이언트 (예를 들어, 프로세싱) 디바이스(12A)에 의해 디코딩 및 디스플레이될 비디오 콘텐츠(예를 들어, 게임)의 비디오 프레임을 포함(예를 들어, 운반)할 수 있다(예를 들어, 패킷은 비디오 프레임의 일부를 포함할 수 있고 비디오 프레임은 패킷의 세트를 통해 운반될 수 있다). 예를 들어, 네트워크 인터페이스(1200)는 패킷을 서버로 전송하도록 구성될 수 있다. 패킷은, 예를 들어, (예를 들어, 사용자) 입력 커맨드를 포함할 수 있다. 예를 들어, 네트워크 인터페이스(1200)는 임의의 종류의 제어 메시지(예를 들어, SRT 메시지)를 서버와 교환하도록 구성될 수 있다. 실시예에 따르면, 네트워크 인터페이스(1200)는 다음 중 임의의 것일 수 있다:
- 블루투스, 모든 종류의 Wi-Fi, 또는 IEEE 802 계열의 네트워크 인터페이스 중 임의의 종류의 무선 인터페이스와 같은 무선 근거리 네트워크 인터페이스;
- 이더넷, IEEE 802.3, 또는 IEEE 802 계열의 네트워크 인터페이스 중 임의의 유선 인터페이스와 같은 유선 LAN 인터페이스;
- USB, 파이어와이어, 또는 임의의 종류의 유선 버스 테크놀로지와 같은 유선 버스 인터페이스;
- 임의의 릴리즈에서 3GPP 사양을 준수하는 2G/3G/4G/5G 셀룰러 무선 네트워크 인터페이스와 같은 광대역 셀룰러 무선 네트워크 인터페이스;
- xDSL, FFTx 또는 WiMAX 인터페이스와 같은 광역 네트워크 인터페이스.
보다 일반적으로, (예를 들어, 사용자 입력 커맨드 및 제어 중 임의의 것의) 패킷을 전송 가능하게 하고 비디오 프레임을 운반하는 복수의 패킷을 수신 가능하게 하는 임의의 네트워크 인터페이스가 본 명세서에 기술된 실시예에 적용될 수 있다.
실시예에 따르면, 네트워크 인터페이스(1200)는 디코딩 및 디스플레이 전에 초기 레이턴시 값을 수신된 패킷에 적용하도록 구성될 수 있는 프로세싱 모듈(1220)에 결합될 수 있다. 예를 들어, 프로세싱 모듈(1220)은 비디오 끊김 레벨 및 비디오 프레임이 도달할 수 있는 페이스의 변동 중 임의의 것을 나타내는 메트릭의 값을 획득하도록 구성될 수 있다. 예를 들어, 프로세싱 모듈(1220)은 메트릭의 값에 기초하여 새로운 레이턴시 값을 획득하기 위해 네트워크 인터페이스(1200)를 통해 서버와 메시지를 교환하도록 구성될 수도 있다. 메시지 교환의 제1 예에서, 프로세싱 모듈(1220)은 요청 메시지를 서버로 전송하도록 구성될 수도 있고, 요청 메시지는 프레임 페이스 변동에 기초하여 결정된 요청된 레이턴시 값을 표시하는 제1 정보를 포함하고, 프로세싱 모듈(1220)은 서버로부터 응답 메시지를 수신하도록 구성될 수도 있고, 응답 메시지는 새로운 레이턴시 값을 표시하는 제2 정보를 포함한다. 메시지 교환의 제2 예에서, 프로세싱 모듈(1220)은 프레임 페이스 변동을 나타내는 메트릭을 표시하는 정보를 서버에 전송하도록 구성될 수도 있고, 프로세싱 모듈(1220)은 서버로부터 요청 메시지를 수신하도록 구성될 수도 있고, 요청 메시지는 요청된 레이턴시 값을 표시하는 제1 정보를 포함하고, 프로세싱 모듈(1220)은 응답 메시지를 서버에 전송하도록 구성될 수도 있고, 응답 메시지는 요청된 레이턴시 값에 기초하여 새로운 레이턴시 값을 표시하는 제2 정보를 포함한다. 예를 들어, 프로세싱 모듈(1220)은 후속 패킷을 디코딩하고 디스플레이하기 전에 새로운 SRT 레이턴시 값을 수신된 후속 패킷에 적용하도록 구성될 수 있다. 예를 들어, 프로세싱 모듈(1220)은 비디오 프레임을 디코딩하고, 예를 들어, 디스플레이 수단과 같은 비디오 출력(1240) 상에 디스플레이하기 위해 비디오 프레임을 전송하도록 구성될 수 있다.실시예에 따르면, 내부 또는 외부의 디스플레이 수단은 개인용 컴퓨터 스크린, TV 스크린, 태블릿 스크린, 스마트폰 스크린 중 임의의 것일 수 있다.보다 일반적으로, 예를 들어 게임과 같은 비디오 콘텐츠의 비디오를 디스플레이 가능하게 하는 임의의 디스플레이 수단이 본 명세서에 기술된 실시예에 적용될 수 있다.
도 12c는 예를 들어 게임과 같은 비디오 콘텐츠의 QoE를 개선하기 위한 서버(예를 들어, 프로세싱) 디바이스(12C)의 일 예를 예시하는 도면이다. 예를 들어, 프로세싱 디바이스(12C)는 클라이언트 디바이스와 상호작용할 수 있다. 예를 들어, 프로세싱 디바이스(12C)는 네트워크에 대한 접속을 위해 네트워크 인터페이스(1210)를 포함할 수 있다. 네트워크 인터페이스(1210)는 클라이언트 디바이스로 복수의 패킷을 전송하도록 구성될 수 있다. 패킷은 클라이언트 디바이스에 의해 디코딩 및 디스플레이될 비디오 콘텐츠(예를 들어, 게임)의 비디오 프레임을 포함(예를 들어, 운반)할 수 있다. 예를 들어, 패킷은 비디오 프레임의 일부를 포함할 수 있고, 비디오 프레임은 패킷의 세트를 통해 운반될 수 있다. 예를 들어, 네트워크 인터페이스(1210)는 패킷을 클라이언트 디바이스로부터 수신하도록 구성될 수 있다. 패킷은, 예를 들어, (예를 들어, 사용자) 입력 커맨드를 포함할 수 있다. 예를 들어, 네트워크 인터페이스(1210)는 임의의 종류의 제어 메시지(예를 들어, SRT 메시지)를 클라이언트 디바이스와 교환하도록 구성될 수 있다. 실시예에 따르면, 네트워크 인터페이스(1210)는 다음 중 임의의 것일 수 있다:
- 블루투스, 모든 종류의 Wi-Fi, 또는 IEEE 802 계열의 네트워크 인터페이스 중 임의의 종류의 무선 인터페이스와 같은 무선 근거리 네트워크 인터페이스;
- 이더넷, IEEE 802.3, 또는 IEEE 802 계열의 네트워크 인터페이스 중 임의의 유선 인터페이스와 같은 유선 LAN 인터페이스;
- USB, 파이어와이어, 또는 임의의 종류의 유선 버스 테크놀로지와 같은 유선 버스 인터페이스;
- 임의의 릴리즈에서 3GPP 사양을 준수하는 2G/3G/4G/5G 셀룰러 무선 네트워크 인터페이스와 같은 광대역 셀룰러 무선 네트워크 인터페이스;
- xDSL, FFTx 또는 WiMAX 인터페이스와 같은 광역 네트워크 인터페이스.
보다 일반적으로, (예를 들어, 사용자 입력 커맨드 및 제어 중 임의의 것의) 패킷을 수신 가능하게 하고 비디오 프레임을 운반하는 복수의 패킷을 전송 가능하게 하는 임의의 네트워크 인터페이스가 본 명세서에 기술된 실시예에 적용될 수 있다.
실시예에 따르면, 네트워크 인터페이스(1210)는, 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 클라이언트 디바이스에 전송하도록 구성될 수 있는 프로세싱 모듈(1230)에 결합될 수 있다. 예를 들어, 프로세싱 모듈(1230)은 초기 레이턴시 값과 연관된 제1 시간량 동안 재송신을 위해 버퍼에 패킷을 유지하도록 구성될 수도 있다. 예를 들어, 프로세싱 모듈(1230)은 새로운 레이턴시 값을 획득하기 위해 네트워크 인터페이스(1210)를 통해 서버와 메시지를 교환하도록 구성될 수도 있다. 메시지 교환의 제1 예에서, 프로세싱 모듈(1230)은 클라이언트 디바이스로부터 요청 메시지를 수신하도록 구성될 수도 있고, 요청 메시지는 요청된 레이턴시 값을 표시하는 제1 정보를 포함하고, 프로세싱 모듈(1230)은 클라이언트 디바이스에 응답 메시지를 전송하도록 구성될 수도 있고, 응답 메시지는 (예를 들어, 요청된 레이턴시 값으로 설정될 수 있는) 새로운 레이턴시 값을 표시하는 제2 정보를 포함한다. 메시지 교환의 제2 예에서, 프로세싱 모듈(1230)은 프레임 페이스 변동을 나타내는 메트릭을 표시하는 정보를 수신하도록 구성될 수 있고, 프로세싱 모듈(1230)은 요청 메시지를 클라이언트 디바이스로 전송하도록 구성될 수도 있고, 요청 메시지는 표시된 메트릭에 기초하여 결정된 요청된 레이턴시 값을 표시하는 제1 정보를 포함하고, 프로세싱 모듈(1230)은 클라이언트 디바이스로부터 응답 메시지를 수신하도록 구성될 수 있고, 응답 메시지는 새로운 레이턴시 값을 표시하는 제2 정보를 포함한다.
예를 들어, 프로세싱 모듈(1230)은 게임 인스턴스를 실행하도록 구성될 수 있다. 예를 들어, 프로세싱 모듈(1230)은 게임의 (예를 들어, 후속) 비디오 프레임을 렌더링하도록 구성될 수 있는 GPU(나타내지 않음)를 포함할 수 있다. 예를 들어, 프로세싱 모듈(1230)은 렌더링된 (예를 들어, 후속) 비디오 프레임을 인코딩하고 클라이언트 디바이스로 전송될 복수의 (예를 들어, 후속) 패킷에 인코딩된 (예를 들어, 후속) 비디오 프레임을 캡슐화하도록 구성될 수 있다. 예를 들어, 프로세싱 모듈(1230)은 비디오 콘텐츠의 후속 비디오 프레임을 운반하는 복수의 후속 패킷을 클라이언트 디바이스에 전송하도록 구성될 수 있다. 예를 들어, 프로세싱 모듈(1230)은 새로운 레이턴시 값과 연관된 제2 시간량 동안 재송신을 위해 후속 패킷을 버퍼에 유지하도록 구성될 수 있다.
도 12b는 본 명세서에 기술된 클라이언트 및 서버(예를 들어, 프로세싱) 디바이스(12A, 12C) 중 임의의 것의 아키텍처의 일 예를 나타낸다. 프로세싱 디바이스(12A, 12C)는, 예를 들어, 내부 메모리(1250)(예를 들어, RAM, ROM, EPROM 중 임의의 것)와 함께, CPU, GPU, DSP(디지털 신호 프로세서의 영어 약어) 중 임의의 것일 수 있는 하나 이상의 프로세서(들)(1210)를 포함할 수 있다. 프로세싱 디바이스(12A, 12C)는 출력 정보를 전송하고/하거나 사용자가 커맨드 및/또는 데이터(예를 들어, 키보드, 마우스, 터치패드, 웹캠, 디스플레이 중 임의의 것)를 입력할 수 있게 하고/하거나, 네트워크 인터페이스를 통해 데이터를 전송/수신할 수 있게 하도록 조정된 임의의 수의 입력/출력 인터페이스(들)(1230); 및 프로세싱 디바이스(12A, 12C) 외부에 있을 수도 있는 전원(1270)을 포함할 수도 있다.
실시예에 따르면, 프로세싱 디바이스(12A, 12C)는 메모리(1250)에 저장된 컴퓨터 프로그램을 더 포함할 수 있다. 컴퓨터 프로그램은, 프로세싱 디바이스(12A, 12C)에 의해, 특히 프로세서(들)(1210)에 의해 실행될 때, 프로세싱 디바이스(12A, 12C)가 도 13, 도 14, 도 15, 도 16 및 도 17 중 임의의 것을 참조하여 기술된 프로세싱 방법을 실행하게 하는 명령어를 포함할 수 있다. 일 변형예에 따르면, 컴퓨터 프로그램은 비일시적 디지털 데이터 지원 상에서, 예를 들어 모두 당해 분야에 공지된 SD 카드, HDD, CD-ROM, DVD, 판독-전용 및/또는 DVD 드라이브, DVD 판독/기록 드라이브 중 임의의 것과 같은 외부 저장 매체 상에서, 프로세싱 디바이스(12A, 12C)의 외부에 저장될 수 있다. 프로세싱 디바이스(12A, 12C)는 컴퓨터 프로그램을 판독하기 위한 인터페이스를 포함할 수 있다. 추가로, 프로세싱 디바이스(12A, 12C)는 대응하는 범용 직렬 버스(Universal Serial Bus; USB) 포트(도시되지 않음)를 통해 임의의 수의 USB 유형 저장 디바이스(예를 들어, "메모리 스틱")에 액세스할 수 있다.
실시예에 따르면, 프로세싱 디바이스(12A)는 게임 디바이스, 셋톱 박스 디바이스, TV 세트, 디지털 미디어 플레이어(예를 들어, 렌더러) 디바이스, 인터넷 게이트웨이, 모바일 디바이스, 통신 디바이스, 태블릿(또는 태블릿 컴퓨터), 스마트폰, 랩톱 컴퓨터, 데스크톱 컴퓨터 중 임의의 것일 수 있다. 실시예에 따르면, 프로세싱 디바이스(12C)는 데스크톱 컴퓨터, 서버, 및 서버의 인스턴스 중 임의의 것일 수 있다.
도 13은 게임의 QoE 개선 방법의 일 예를 예시하는 도면이다. 예를 들어, 방법은 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에서 구현될 수 있다. 실시예에 따르면, 단계(1310)에서, 게임의 비디오 프레임을 운반하는 복수의 패킷이 서버로부터 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 수신될 수 있다. 실시예에 따르면, 단계(1320)에서, 디코딩 및 디스플레이 전에 초기 SRT 레이턴시 값이 수신된 패킷에 적용될 수 있다. 실시예에 따르면, 단계(1330)에서, 비디오 프레임 페이스 변동에 기초하여 비디오 끊김 레벨을 나타내는 메트릭의 값이 획득될 수 있다. 실시예에 따르면, 단계(1340)에서, 메트릭의 값에 기초하여 새로운 SRT 레이턴시 값을 획득하기 위해 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스와 서버 사이에서 SRT 메시지가 교환될 수 있다. 실시예에 따르면, 단계(1350)에서, 디코딩 및 디스플레이 전에 새로운 SRT 레이턴시 값을 수신된 후속 패킷에 적용함으로써 게임의 QoE가 개선될 수 있다.
예를 들어, 수신된 패킷 및 수신된 후속 패킷은 SRT 수신기 버퍼에 저장될 수 있고, SRT 레이턴시 값에, 그리고 패킷 내에 포함된 타임 스탬프 정보에 기초하여 패킷을 SRT 수신기 버퍼로부터 추출함으로써 SRT 레이턴시 값을 패킷에 적용할 수 있다. 예를 들어, 타임 스탬프 정보는 서버의 SRT 전송자 버퍼에서 패킷의 저장과 연관된 각각의 시간을 표시할 수 있다. 예를 들어, SRT 레이턴시 값은 초기 SRT 레이턴시 값 또는 새로운 SRT 레이턴시 값 중 어느 것일 수 있다.
예를 들어, 패킷에 포함된 타임스탬프는 패킷이 SRT 전송자 버퍼에 저장되었을 수 있는 제1 시간을 표시할 수 있다. 예를 들어, 패킷은 제1 시간 이후의 시간량에 대응하는 제2 시간에 추출될 수 있고, 시간량은 연속적인 패킷에 대해 일정할 수 있고 SRT 레이턴시 값과 연관될 수 있다.
예를 들어, 비디오 프레임 페이스 변동은 비디오 프레임이 수신될 수 있는 페이스, SRT 수신기 버퍼로부터 추출될 수 있는 페이스, 디코딩될 수 있는 페이스 중 임의의 것의 변동일 수 있다.
예를 들어, 새로운 SRT 레이턴시 값은 상이한 선행 기간 동안 획득된 메트릭의 값의 이력에 기초하여 획득될 수 있다.
예를 들어, 메트릭 값은 프레임 도착 시간, 패킷 도착 시간, 프레임 디코딩 시간 및 프레임 디스플레이 시간 중 임의의 것의 분산 함수에 기초하여 획득될 수 있다.
예를 들어, 분산 함수는 평균, 중앙값, 표준 편차, 분산, 평균 절대 편차 및 사분위수간 중 임의의 것일 수 있다.
예를 들어, 메트릭의 값은 지연된 프레임의 제1 수 및 드롭된 프레임의 제2 수 중 임의의 것에 추가로 기초할 수도 있다.
예를 들어, SRT 요청 메시지는 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 서버로 전송될 수 있다. SRT 요청 메시지는 요청된 SRT 레이턴시 값을 표시하는 제1 정보를 포함할 수 있다. 요청된 SRT 레이턴시 값은 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 결정되었을 수 있는 새로운 SRT 레이턴시 값에 대응할 수 있다.
예를 들어, SRT 응답 메시지는 서버로부터 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 수신될 수 있다. SRT 응답 메시지는 요청된 레이턴시 값에 응답하여 전송자 SRT 레이턴시 값을 표시하는 제2 정보를 포함할 수 있다. 예를 들어, 수신된 후속 패킷에 적용될 새로운 SRT 레이턴시 값은, 전송자 SRT 레이턴시 값이 요청된 SRT 레이턴시 값과 동일하거나 요청된 SRT 레이턴시 값과 초기 SRT 레이턴시 값 사이에 엄격하게 포함된다는 조건 상에서 전송자 SRT 레이턴시 값으로 설정될 수 있다.
예를 들어, 메트릭의 값은 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 서버로 전송될 수 있다.
예를 들어, SRT 요청 메시지는 서버로부터 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 수신될 수 있다. SRT 요청 메시지는 새로운 SRT 레이턴시 값을 표시하는 제1 정보를 포함할 수 있다.
예를 들어, SRT 응답 메시지는 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 서버로 전송될 수 있다. SRT 응답 메시지는 새로운 SRT 레이턴시 값을 확인응답하기 위해 새로운 SRT 레이턴시 값을 표시하는 제2 정보를 포함할 수 있다.
예를 들어, 비디오 프레임을 운반하는 패킷이 수신될 수 있기 전에, SRT 확장된 핸드쉐이크 요청 메시지가 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 서버로 전송될 수 있다. SRT 확장된 핸드쉐이크 요청 메시지는 동적 레이턴시 동작을 지원하는 클라이언트 능력을 표시할 수 있다.
예를 들어, SRT 확장된 핸드쉐이크 응답 메시지는 SRT 확장된 핸드쉐이크 요청 메시지에 응답하여 서버로부터 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 수신될 수 있다. (예를 들어, 클라우드 게이밍) 클라이언트 디바이스는 SRT 확장된 핸드쉐이크 응답 메시지가 동적 레이턴시 동작을 지원하는 서버 능력을 표시한다는 조건 상에서 동적 레이턴시 동작을 수행할 수 있다.
예를 들어, 비디오 프레임을 운반하는 패킷이 수신될 수 있기 전에, SRT 확장된 핸드쉐이크 요청 메시지가 서버로부터 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 수신될 수 있다. SRT 확장된 핸드쉐이크 요청 메시지가 동적 레이턴시 동작을 지원하는 서버 능력을 표시한다는 조건 상에서, SRT 확장된 핸드쉐이크 응답 메시지는 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 서버에 전송되어 동적 레이턴시 동작을 지원하는 클라이언트 능력을 표시할 수 있다.
예를 들어, 비디오 프레임을 운반하는 패킷이 수신될 수 있기 전에, SRT 확장된 핸드쉐이크 요청 메시지가 서버로부터 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 수신될 수 있고, SRT 확장된 핸드쉐이크 요청 메시지가 동적 레이턴시 동작을 지원하는 서버 능력의 어떠한 표시도 포함하지 않는다는 조건 상에서, SRT 확장된 핸드쉐이크 응답 메시지가 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 동적 레이턴시 동작을 지원하는 클라이언트 능력을 표시하는 서버에 전송될 수 있다.
예를 들어, 다른 SRT 확장된 핸드쉐이크 요청 메시지가 (예를 들어, 클라우드 게이밍) 클라이언트 디바이스에 의해 수신될 수 있고, 동적 레이턴시 동작은 다른 SRT 확장된 핸드쉐이크 요청 메시지가 동적 레이턴시 동작을 지원하는 서버 능력을 표시한다는 조건 상에서 수행될 수 있다.
도 14는 예를 들어, 비디오 콘텐츠의 QoE를 개선하기 위해 클라이언트 디바이스에서 구현되는 방법의 제1 예를 예시하는 도면이다. 예를 들어, 단계(1410)에서, 클라이언트 디바이스는 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 서버로부터 수신할 수 있다. 예를 들어, 단계(1420)에서, 클라이언트 디바이스는 디코딩 및 디스플레이 전에 초기 레이턴시 값을 수신된 패킷에 적용할 수 있다. 예를 들어, 단계(1430)에서, 클라이언트 디바이스는 요청 메시지를 서버에 전송할 수 있고, 요청 메시지는 프레임 페이스 변동에 기초하여 결정될 수 있는 요청된 레이턴시 값을 표시하는 제1 정보를 포함할 수 있다. 예를 들어, 단계(1440)에서, 클라이언트 디바이스는 서버로부터 응답 메시지를 수신할 수 있고, 응답 메시지는 새로운 레이턴시 값을 표시하는 제2 정보를 포함할 수 있다. 예를 들어, 단계(1450)에서, 클라이언트 디바이스는 디코딩 및 디스플레이 전에 새로운 레이턴시 값을 수신된 후속 패킷에 적용할 수 있다.
예를 들어, 초기 레이턴시 값 및 새로운 레이턴시 값은, (i) 각각의 초기 레이턴시 값 및 새로운 레이턴시 값 및 (ii) 패킷 및 후속 패킷에 포함된 타임 스탬프 정보에 기초하여, 각각의 패킷 및 후속 패킷을 수신기 버퍼로부터 추출함으로써 각각의 패킷 및 후속 패킷에 적용될 수 있다. 타임 스탬프 정보는, 예를 들어, 서버의 전송자 버퍼에 패킷 및 후속 패킷을 저장하는 것과 연관된 각각의 시간을 예를 들어 표시할 수 있다.
예를 들어, 패킷 및 후속 패킷 중 임의의 패킷에 포함된 타임 스탬프 정보는 패킷이 예를 들어 전송자 버퍼에 저장되었을 수 있는 제1 시간을 표시할 수 있다. 예를 들어, 패킷은 제1 시간 이후의 시간량에 대응하는 제2 시간에서 추출될 수 있고, 시간량은 연속적인 패킷에 대해 일정하고 초기 레이턴시 값 및 새로운 레이턴시 값 중 임의의 것과 연관된다.
예를 들어, 프레임 페이스 변동은 비디오 프레임이 수신될 수 있는 페이스, 수신기 버퍼로부터 추출될 수 있는 페이스, 디코딩될 수 있는 페이스 중 임의의 것의 변동일 수 있다.
예를 들어, 새로운 레이턴시 값은 상이한 선행 기간 동안 프레임 페이스 변동의 이력에 기초하여 획득될 수 있다.
예를 들어, 새로운 레이턴시 값은 지연된 프레임의 수 및 드롭된 프레임의 수 중 임의의 것에 추가로 기초할 수도 있다.
예를 들어, 새로운 레이턴시 값은, 새로운 레이턴시 값이 요청된 레이턴시 값과 동일하거나 요청된 레이턴시 값과 초기 레이턴시 값 사이에 엄격하게 포함된다는 조건 상에서, 후속 패킷에 적용될 수 있다.
예를 들어, 비디오 프레임을 운반하는 패킷이 수신될 수 있기 전에, 클라이언트 디바이스는 핸드쉐이크 요청 메시지를 서버에 전송할 수 있다. 예를 들어, 핸드쉐이크 요청 메시지는 동적 레이턴시 동작을 지원하는 클라이언트 능력을 표시하는 제3 정보를 포함할 수 있다.
예를 들어, 클라이언트 디바이스는 예를 들어 핸드쉐이크 요청 메시지에 대한 응답으로 서버로부터 핸드쉐이크 응답 메시지를 수신할 수 있다. 예를 들어, 클라이언트 디바이스는, 핸드쉐이크 응답 메시지가 동적 레이턴시 동작을 지원하는 서버 능력을 표시하는 제4 정보를 포함한다는 조건 상에서 요청 메시지를 전송함으로써 동적 레이턴시 동작을 수행할 수 있다.
예를 들어, 비디오 프레임을 운반하는 패킷이 수신될 수 있기 전에, 클라이언트 디바이스는 서버로부터 핸드쉐이크 요청 메시지를 수신할 수 있다. 핸드쉐이크 요청 메시지가 동적 레이턴시 동작을 지원하는 서버 능력을 표시하는 제3 정보를 포함한다는 조건 상에서, 클라이언트 디바이스는 핸드쉐이크 응답 메시지를 서버에 전송할 수 있고, 핸드쉐이크 응답 메시지는 동적 레이턴시 동작을 지원하는 클라이언트 능력을 표시하는 제4 정보를 포함할 수 있다.
예를 들어, 초기 레이턴시 값 및 새로운 레이턴시 값은 보안 신뢰성 전송(SRT)일 수 있고, 레이턴시 값은 SRT 프로토콜과 연관된다.
도 15는 예를 들어, 비디오 콘텐츠의 QoE를 개선하기 위해 서버에서 구현되는 방법의 제2 예를 예시하는 도면이다. 예를 들어, 단계(1510)에서, 서버는 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 클라이언트 디바이스에 전송할 수 있다. 예를 들어, 단계(1520)에서, 서버는 패킷을, 예를 들어, 초기 레이턴시 값과 연관된 제1 시간량 동안 재송신을 위해 버퍼에 유지할 수 있다. 예를 들어, 단계(1530)에서, 서버는 클라이언트 디바이스로부터 요청 메시지를 수신할 수 있고, 요청 메시지는 요청된 레이턴시 값을 표시하는 제1 정보를 포함할 수 있다. 예를 들어, 단계(1540)에서, 서버는 응답 메시지를 클라이언트 디바이스에 전송할 수 있고, 응답 메시지는 새로운 레이턴시 값을 표시하는 제2 정보를 포함할 수 있다. 예를 들어, 새로운 레이턴시 값은 요청된 레이턴시 값의 서버에 의한 수락을 표시하기 위해 요청된 레이턴시 값으로 설정될 수 있다. 예를 들어, 단계(1550)에서, 서버는 비디오 콘텐츠의 후속 비디오 프레임을 운반하는 복수의 후속 패킷을 클라이언트 디바이스에 전송할 수 있다. 예를 들어, 단계(1560)에서, 서버는 새로운 레이턴시 값과 연관된 제2 시간량 동안 재송신을 위해 후속 패킷을 예를 들어 버퍼에 유지할 수 있다.
도 16은 예를 들어, 비디오 콘텐츠의 QoE를 개선하기 위해 클라이언트 디바이스에서 구현되는 방법의 제3 예를 예시하는 도면이다. 예를 들어, 단계(1610)에서, 클라이언트 디바이스는 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 서버로부터 수신할 수 있다. 예를 들어, 단계(1620)에서, 클라이언트 디바이스는 디코딩 및 디스플레이 전에 초기 레이턴시 값을 수신된 패킷에 적용할 수 있다. 예를 들어, 단계(1630)에서, 클라이언트 디바이스는 프레임 페이스 변동을 나타내는 메트릭을 표시하는 정보를 서버에 전송할 수 있다. 예를 들어, 단계(1640)에서, 클라이언트 디바이스는 서버로부터 요청 메시지를 수신할 수 있고, 요청 메시지는 요청된 레이턴시를 표시하는 제1 정보를 포함할 수 있다. 예를 들어, 단계(1650)에서, 클라이언트 디바이스는 응답 메시지를 서버에 전송할 수 있고, 응답 메시지는 요청된 레이턴시 값에 기초한 새로운 레이턴시 값을 표시하는 제2 정보를 포함할 수 있다. 예를 들어, 새로운 레이턴시 값은 요청된 레이턴시 값의 클라이언트 디바이스에 의한 수락을 표시하기 위해 요청된 레이턴시 값으로 설정될 수 있다. 예를 들어, 단계(1660)에서, 클라이언트 디바이스는 디코딩 및 디스플레이 전에 새로운 레이턴시 값을 수신된 후속 패킷에 적용할 수 있다.
예를 들어, 메트릭은 프레임 도착 시간, 패킷 도착 시간, 프레임 디코딩 시간 및 프레임 디스플레이 시간 중 임의의 것의 분산 함수에 기초할 수도 있다.
예를 들어, 분산 함수는 평균, 중앙값, 표준 편차, 분산, 평균 절대 편차 및 사분위수간 중 임의의 것을 포함할 수 있다.
예를 들어, 메트릭은 지연된 프레임의 수 및 드롭된 프레임의 수 중 임의의 것에 추가로 기초할 수도 있다.
도 17은 예를 들어, 비디오 콘텐츠의 QoE를 개선하기 위해 서버에서 구현되는 방법의 제4 예를 예시하는 도면이다. 예를 들어, 단계(1710)에서, 서버는 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 클라이언트 디바이스에 전송할 수 있다. 예를 들어, 단계(1720)에서, 서버는 패킷을, 예를 들어, 초기 레이턴시 값과 연관된 제1 시간량 동안 재송신을 위해 버퍼에 유지할 수 있다. 예를 들어, 단계(1730)에서, 서버는 프레임 페이스 변동을 나타내는 메트릭을 표시하는 정보를 수신할 수 있다. 예를 들어, 단계(1740)에서, 서버는 요청 메시지를 클라이언트 디바이스에 전송할 수 있고, 요청 메시지는 요청된 레이턴시 값을 표시하는 제1 정보를 포함할 수 있다. 예를 들어, 서버는 표시된 메트릭에 기초하여 요청된 레이턴시 값을 결정할 수 있다. 예를 들어, 단계(1750)에서, 서버는 클라이언트 디바이스로부터 응답 메시지를 수신할 수 있고, 응답 메시지는 새로운 레이턴시 값을 표시하는 제2 정보를 포함할 수 있다. 예를 들어, 새로운 레이턴시 값은 요청된 레이턴시 값의 클라이언트 디바이스에 의한 수락을 표시하기 위해 요청된 레이턴시 값으로 설정될 수 있다. 예를 들어, 단계(1760)에서, 서버는 비디오 콘텐츠의 후속 비디오 프레임을 운반하는 복수의 후속 패킷을 클라이언트 디바이스에 전송할 수 있다. 예를 들어, 단계(1770)에서, 서버는 새로운 레이턴시 값과 연관된 제2 시간량 동안 재송신을 위해 후속 패킷을 예를 들어 버퍼에 유지할 수 있다.
결론
특징 및 요소가 특정 조합으로 위에서 설명되었지만, 당업자는 각각의 특징 또는 요소가 단독으로 또는 다른 특징 및 요소와의 임의의 조합으로 사용될 수 있다는 것을 이해할 것이다. 또한, 본 명세서에서 설명된 방법은 컴퓨터 또는 프로세서에 의한 실행을 위해 컴퓨터 판독 가능 매체에 통합된 컴퓨터 프로그램, 소프트웨어 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독 가능 매체의 예는 (유선 또는 무선 접속을 통해 송신되는) 전자 신호 및 컴퓨터 판독 가능 저장 매체를 포함한다. 컴퓨터 판독 가능 저장 매체의 예는 판독 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 레지스터, 캐시 메모리, 반도체 메모리 디바이스, 내부 하드 디스크 및 착탈식 디스크와 같은 자기 매체, 광자기 매체, 및 CD-ROM 디스크 및 디지털 다기능 디스크(DVD)와 같은 광학 매체를 포함하지만, 이들로 제한되지 않는다. 소프트웨어와 연관된 프로세서는 WTRU(102), UE, 단말기, 기지국, RNC 또는 임의의 호스트 컴퓨터에서 사용하기 위한 무선 주파수 송수신기를 구현하는 데 사용될 수 있다.
명시적으로 기술되어 있지 않지만, 본 실시예는 임의의 조합 또는 하위 조합으로 채용될 수 있다. 예를 들어, 본 원리는 기술된 변형으로 제한되지 않고, 변형 및 실시예의 임의의 배열이 사용될 수 있다. 더욱이, 본 원리는 기술된 채널 액세스 방법으로 제한되지 않고, 임의의 다른 유형의 채널 액세스 방법이 본 원리와 호환 가능하다.
방법에 대해 기술된 임의의 특성, 변형 또는 실시예는 개시된 방법을 프로세싱하기 위한 수단을 포함하는 장치 디바이스와 호환 가능하며, 이때 디바이스는 개시된 방법을 프로세싱하도록 구성된 프로세서를 포함하고, 컴퓨터 프로그램 제품은 프로그램 코드 명령어를 포함하고, 비일시적 컴퓨터 판독 가능 저장 매체는 프로그램 명령어를 저장한다.
또한, 전술된 실시예에서, 프로세싱 플랫폼, 컴퓨팅 시스템, 제어기, 및 프로세서를 포함하는 다른 디바이스가 언급된다. 이러한 디바이스는 적어도 하나의 중앙처리장치("CPU") 및 메모리를 포함할 수 있다. 컴퓨터 프로그래밍의 당업자의 실시에 따르면, 동작 또는 명령어의 부호 표현 및 행위(act)에 대한 참조는 다양한 CPU 및 메모리에 의해 수행될 수 있다. 그러한 행위 및 동작 또는 명령어는 "실행되는", "컴퓨터 실행되는" 또는 "CPU 실행되는" 것으로 지칭될 수 있다.
당업자는, 행위 및 부호로 표현된 동작 또는 명령어가 CPU에 의한 전기 신호의 조작을 포함한다는 것을 이해할 것이다. 전기 시스템은, 전기 신호의 결과적인 변환 또는 감소 및 메모리 시스템 내의 메모리 위치에서의 데이터 비트의 유지를 야기하여, 그에 의해 CPU의 동작뿐만 아니라 신호의 다른 프로세싱을 재구성하거나 또는 달리 변경할 수 있는 데이터 비트를 나타낸다. 데이터 비트가 유지되는 메모리 위치는 데이터 비트에 대응하거나 데이터 비트를 나타내는 특정의 전기적, 자기적, 광학적 또는 유기적 속성을 갖는 물리적 위치이다. 대표적인 실시예는 위에서 언급된 플랫폼 또는 CPU로 제한되지 않으며, 다른 플랫폼 및 CPU가 제공된 방법을 지원할 수 있다는 것이 이해되어야 한다.
데이터 비트는 또한 CPU에 의해 판독 가능한 자기 디스크, 광학 디스크, 및 임의의 다른 휘발성(예를 들어, 랜덤 액세스 메모리("RAM")) 또는 비휘발성(예를 들어, 판독 전용 메모리("ROM")) 대용량 저장 시스템을 포함하는 컴퓨터 판독 가능 매체 상에 유지될 수 있다. 컴퓨터 판독 가능 매체는 프로세싱 시스템 상에 배타적으로 존재하거나 프로세싱 시스템에 대해 국부적이거나 원격일 수 있는 다수의 상호접속된 프로세싱 시스템 사이에 분산되는, 협력하거나 또는 상호접속된 컴퓨터 판독 가능 매체를 포함할 수 있다. 대표적인 실시예가 위에서 언급된 메모리로 제한되지 않으며 다른 플랫폼 및 메모리가 설명된 방법을 지원할 수 있다는 것이 이해되어야 한다.
예시적인 실시예에서, 본 명세서에 기술된 동작, 프로세스 등 중 임의의 것은 컴퓨터 판독 가능 매체 상에 저장된 컴퓨터 판독 가능 명령어로서 구현될 수 있다. 컴퓨터 판독 가능 명령어는 모바일 유닛, 네트워크 요소, 및/또는 임의의 다른 컴퓨팅 디바이스의 프로세서에 의해 실행될 수 있다.
시스템의 양태의 하드웨어 구현과 소프트웨어 구현 사이에는 차이가 거의 없다. 하드웨어 또는 소프트웨어의 사용은 대체적으로 (예를 들어, 특정 상황에서 하드웨어와 소프트웨어 중의 선택이 중요하게 될 수 있다는 점에서, 항상은 아니지만) 비용 대 효율성 트레이드오프를 나타내는 설계 선택사항이다. 본 명세서에 기술된 프로세스 및/또는 시스템 및/또는 다른 기술이 실시될 수 있는 다양한 수단(예를 들어, 하드웨어, 소프트웨어, 및/또는 펌웨어)이 있을 수 있고, 선호된 수단은 프로세스 및/또는 시스템 및/또는 다른 기술이 배치되는 정황에 따라 달라질 수 있다. 예를 들어, 속도 및 정확도가 가장 중요하다고 구현자가 결정하는 경우, 구현자는 주로 하드웨어 및/또는 펌웨어 수단을 선택할 수 있다. 유연성이 가장 중요한 경우, 구현자는 주로 소프트웨어 구현을 선택할 수 있다. 대안적으로, 구현자는 하드웨어, 소프트웨어, 및/또는 펌웨어의 일부 조합을 선택할 수 있다.
전술한 상세한 설명은 블록도, 흐름도, 및/또는 예의 사용을 통해 디바이스 및/또는 프로세스의 다양한 실시예를 기재하였다. 그러한 블록도, 흐름도, 및/또는 예가 하나 이상의 기능 및/또는 동작을 포함하는 한, 그러한 블록도, 흐름도, 또는 예에서의 각각의 기능 및/또는 동작이 광범위한 하드웨어, 소프트웨어, 펌웨어, 또는 이의 사실상 임의의 조합에 의해 개별적으로 및/또는 집합적으로 구현될 수 있다는 것이 당업자에 의해 이해될 것이다. 적합한 프로세서는 예로서, 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(DSP), 복수의 마이크로프로세서, DSP 코어와 연관된 하나 이상의 마이크로프로세서, 제어기, 마이크로제어기, 주문형 집적 회로(ASIC), 특정 용도 표준 제품(Application Specific Standard Product; ASSP); 필드 프로그램 가능 게이트 어레이(FPGA) 회로, 임의의 다른 유형의 집적 회로(IC), 및/또는 상태 기계를 포함한다.
특징 및 요소가 특정 조합으로 위에서 제공되어 있지만, 당업자는 각각의 특징 또는 요소가 단독으로 또는 다른 특징 및 요소와의 임의의 조합으로 사용될 수 있다는 것을 이해할 것이다. 본 개시내용은, 다양한 양태의 예시로서 의도되는, 본 출원에 기술된 특정 실시예의 관점에서 제한되지 않는다. 당업자에게 명백할 바로서, 본 개시내용의 사상 및 범주를 벗어나지 않고서 많은 수정 및 변형이 이루어질 수 있다. 본 출원의 설명에서 사용되는 어떠한 요소, 행위, 또는 명령어도, 명시적으로 그와 같이 제공되지 않는 한, 본 발명에 중요하거나 또는 필수적인 것으로 해석되지 않아야 한다. 본 명세서에서 열거된 것 외에도, 본 개시내용의 범주 내의 기능적으로 동등한 방법 및 장치가 전술한 설명으로부터 당업자에게 명백할 것이다. 그러한 수정 및 변형은 첨부된 청구항의 범주 내에 속하는 것으로 의도된다. 본 개시내용은, 그러한 청구항의 자격을 갖는 동등물의 전체 범주와 함께, 첨부된 청구항의 조건에 의해서만 제한되어야 한다. 본 개시내용은 특정 방법 또는 시스템으로 제한되지 않는다는 것이 이해되어야 한다.
또한, 본 명세서에서 사용되는 전문용어가 특정 실시예만을 기술하기 위한 것이고, 제한하는 것으로 의도되지 않는다는 것이 이해되어야 한다. 본 명세서에서 사용되는 바와 같이, 본 명세서에서 언급될 때, 용어 "스테이션" 및 그의 약어 "STA", "사용자 장비" 및 그의 약어 "UE"는 아래에 기술된 것과 같은, (i) 무선 송수신 유닛(WTRU); (ii) 아래에 기술된 것과 같은, WTRU의 다수의 실시예 중 임의의 것; (iii) 그 중에서도, 아래에 기술된 것과 같은, WTRU의 일부 또는 모든 구조 및 기능으로 구성된 무선가능(wireless-capable) 및/또는 유선가능(wired-capable)(예를 들어, 테더링가능(tetherable)) 디바이스; (iii) 아래에 기술된 것과 같은, WTRU의 전부보다 적은 구조 및 기능으로 구성된 무선가능 및/또는 유선가능 디바이스; 또는 (iv) 유사한 것을 의미할 수 있다. 본 명세서에 열거된 임의의 UE를 대표할 수 있는 예시적인 WTRU의 상세사항이 도 1a 내지 도 1d와 관련하여 하기에 제공된다.
특정 대표적인 실시예에서, 본 명세서에 기술된 주제의 여러 부분은 주문형 집적 회로(ASIC), 필드 프로그램 가능 게이트 어레이(FPGA), 디지털 신호 프로세서(DSP), 및/또는 다른 통합된 포맷을 통해 구현될 수 있다. 그러나, 본 명세서에 개시된 실시예의 일부 양태가, 전체적으로 또는 부분적으로, 집적 회로로, 하나 이상의 컴퓨터 상에서 실행되는 하나 이상의 컴퓨터 프로그램으로서(예를 들어, 하나 이상의 컴퓨터 시스템 상에서 실행되는 하나 이상의 프로그램으로서), 하나 이상의 프로세서 상에서 실행되는 하나 이상의 프로그램으로서(예를 들어, 하나 이상의 마이크로프로세서 상에서 실행되는 하나 이상의 프로그램으로서), 펌웨어로서, 또는 이의 사실상 임의의 조합으로서 동등하게 구현될 수 있고, 회로부를 설계하는 것 및/또는 소프트웨어 및/또는 펌웨어에 대한 코드를 기록하는 것이 본 개시내용을 고려하여 당업자의 역량 내에 충분히 있을 것임을 당업자는 인식할 것이다. 추가로, 본 명세서에 기술된 주제의 메커니즘이 다양한 형태의 프로그램 제품으로서 배포될 수 있으며, 본 명세서에 기술된 주제의 예시적인 실시예가 배포를 실제로 수행하는 데 사용되는 특정 유형의 신호 베어링 매체(signal bearing medium)에 관계없이 적용된다는 것을 당업자는 이해할 것이다. 신호 베어링 매체의 예는 다음을 포함하지만, 이로 제한되지는 않는다: 플로피 디스크, 하드 디스크 드라이브, CD, DVD, 디지털 테이프, 컴퓨터 메모리 등과 같은 기록가능 유형 매체, 및 디지털 및/또는 아날로그 통신 매체(예를 들어, 광섬유 케이블, 도파관, 유선 통신 링크, 무선 통신 링크 등)와 같은 송신 유형 매체.
본 명세서에서 기술된 주제는 때때로 상이한 다른 컴포넌트 내에 포함되거나 그에 접속되는 상이한 컴포넌트를 예시한다. 그러한 도시된 아키텍처는 단지 예일뿐이라는 것, 및 실제로 동일한 기능을 달성하는 많은 다른 아키텍처가 구현될 수 있다는 것이 이해되어야 한다. 개념적 의미에서, 동일한 기능을 달성하기 위한 컴포넌트의 임의의 배열은 원하는 기능이 달성될 수 있도록 효과적으로 "연관"되어 있다. 따라서, 특정 기능을 달성하도록 조합되는 본 명세서에서의 임의의 2개의 컴포넌트는, 아키텍처 또는 중간 컴포넌트(intermedial component)와 관계없이, 원하는 기능이 달성되도록 서로 "연관"되어 있는 것으로 보일 수 있다. 마찬가지로, 그렇게 연관된 임의의 2개의 컴포넌트는 원하는 기능을 달성하도록 서로 "동작가능하게 접속된(operably connected)" 또는 "동작가능하게 결합된(operably coupled)" 것으로 또한 보일 수 있고, 그렇게 연관될 수 있는 임의의 2개의 컴포넌트는 원하는 기능을 달성하도록 서로 "동작가능하게 결합가능한(operably couplable)" 것으로 또한 보일 수 있다. 동작가능하게 결합가능한의 특정 예는 물리적으로 정합가능한(physically mateable) 및/또는 물리적으로 상호작용하는 컴포넌트, 및/또는 무선으로 상호작용가능한 및/또는 무선으로 상호작용하는 컴포넌트, 및/또는 논리적으로 상호작용하는 및/또는 논리적으로 상호작용가능한 컴포넌트를 포함하지만 이로 제한되지 않는다.
본 명세서에서의 실질적으로 임의의 복수 및/또는 단수 용어의 사용과 관련하여, 당업자는 정황 및/또는 응용에 적절한 바와 같이 복수로부터 단수로 그리고/또는 단수로부터 복수로 해석할 수 있다. 명확성을 위해 다양한 단수/복수 치환(permutation)이 본 명세서에서 명시적으로 기재될 수 있다.
대체적으로, 본 명세서에서 그리고 특히 첨부된 청구항(예를 들어, 첨부된 청구항의 본문)에서 사용되는 용어가 대체적으로 "개방형(open)" 용어로서 의도된다는 것이 당업자에 의해 이해될 것이다(예를 들어, 용어 "포함하는(including)"은 "포함하지만 이에 제한되지 않는(including but not limited to)"으로서 해석되어야 하고, 용어 "갖는(having)"은 "적어도 갖는(having at least)"으로서 해석되어야 하고, 용어 "포함한다(includes)"는 "포함하지만 이에 제한되지 않는다(includes but is not limited to)"로서 해석되어야 하는 등이다). 특정 수의 도입된 청구항 열거가 의도되는 경우, 그러한 의도가 청구항에 명시적으로 열거될 것이고, 그러한 열거가 없는 경우, 그러한 의도가 존재하지 않는다는 것이 당업자에 의해 추가로 이해될 것이다. 예를 들어, 하나의 항목만이 의도되는 경우, 용어 "단일" 또는 유사한 언어가 사용될 수 있다. 이해에 대한 보조로서, 이하의 첨부된 청구항 및/또는 본 명세서에서의 설명은 청구항 열거를 도입하기 위해 "적어도 하나" 및 "하나 이상"이라는 도입 문구의 사용을 포함할 수 있다. 그러나, 동일한 청구항이 도입 문구 "하나 이상" 또는 "적어도 하나" 및 "a" 또는 "an"과 같은 부정 관사(예를 들어, "a" 및/또는 "an"은 "적어도 하나" 또는 "하나 이상"을 의미하는 것으로 해석되어야 함)를 포함할 때에도, 그러한 문구의 사용은 부정관사 "a" 또는 "an"에 의한 청구항 열거의 도입이 그러한 도입된 청구항 열거를 포함하는 임의의 특정의 청구항을 단지 하나의 그러한 열거를 포함하는 실시예로 제한한다는 것을 암시하는 것으로 해석되어서는 안된다. 청구항 열거를 도입하는 데 사용되는 정관사의 사용에 대해서도 마찬가지이다. 추가로, 특정 수의 도입된 청구항 열거가 명시적으로 열거되더라도, 당업자는 그러한 열거가 적어도 열거된 수를 의미하는 것으로 해석되어야 한다는 것을 인식할 것이다(예를 들어, 다른 수식어를 갖지 않는 "2개의 열거"인 기본 열거(bare recitation)는 적어도 2개의 열거 또는 2개 이상의 열거를 의미함).
더욱이, "A, B, 및 C 등 중 적어도 하나"와 유사한 관습적 표현(convention)이 사용되는 그러한 인스턴스에서, 대체적으로, 그러한 구조는 당업자가 관습적 표현을 이해하는 의미로 의도된다(예를 들어, "A, B, 및 C 중 적어도 하나를 갖는 시스템"은 A만을, B만을, C만을, A 및 B를 함께, A 및 C를 함께, B 및 C를 함께, 그리고/또는 A, B, 및 C를 함께, 등을 갖는 시스템을 포함하지만 이로 제한되지 않을 것임). "A, B, 또는 C 등 중 적어도 하나"와 유사한 관습적 표현이 사용되는 그러한 인스턴스에서, 대체적으로, 그러한 구조는 당업자가 관습적 표현을 이해하는 의미로 의도된다(예를 들어, "A, B, 또는 C 중 적어도 하나를 갖는 시스템"은 A만을, B만을, C만을, A 및 B를 함께, A 및 C를 함께, B 및 C를 함께, 그리고/또는 A, B, 및 C를 함께, 등을 갖는 시스템을 포함하지만 이로 제한되지 않을 것임). 설명에서든, 청구항에서든, 또는 도면에서든, 2개 이상의 대안적 용어를 제시하는 사실상 임의의 이접 접속어(disjunctive word) 및/또는 이접 접속구(disjunctive phrase)가 용어 중 하나, 용어 중 어느 하나, 또는 용어 둘 모두를 포함하는 가능성을 고려하도록 이해되어야 한다는 것이 당업자에 의해 추가로 이해될 것이다. 예를 들어, 문구 "A 또는 B"는 "A" 또는 "B" 또는 "A 및 B"의 가능성을 포함하는 것으로 이해될 것이다. 게다가, 본 명세서에 사용된 바와 같이, 용어 "~중 임의의 것"에 이어지는 복수의 항목 및/또는 복수의 항목의 카테고리의 목록은 항목 및/또는 항목의 카테고리 "~중 임의의 것", "~의 임의의 조합", "~중 임의의 다수", 및/또는 "~중 다수의 임의의 조합"을, 개별적으로 또는 다른 항목 및/또는 다른 항목의 카테고리와 함께, 포함하는 것으로 의도된다. 더욱이, 본 명세서에서 사용되는 바와 같이, 용어 "세트" 또는 "그룹"은, 제로를 포함한, 임의의 수의 항목을 포함하는 것으로 의도된다. 추가적으로, 본 명세서에서 사용되는 바와 같이, 용어 "수"는, 제로를 포함한, 임의의 수를 포함하는 것으로 의도된다.
추가로, 본 개시내용의 특징 또는 양태가 마쿠쉬(Markush) 그룹의 관점에서 기술되는 경우, 당업자는 본 개시내용이 또한 그에 의해 마쿠쉬 그룹의 임의의 개별 멤버 또는 멤버의 서브그룹의 관점에서 기술됨을 인식할 것이다.
당업자에 의해 이해될 것으로서, 서면 설명을 제공하는 관점에서와 같은, 임의의 및 모든 목적을 위해, 본 명세서에 개시된 모든 범위는 임의의 및 모든 가능한 서브범위 및 이의 서브범위의 조합을 또한 포괄한다. 임의의 열거된 범위는 동일한 범위가 적어도 동일한 1/2, 1/3, 1/4, 1/5, 1/10 등으로 나누어지는 것을 충분히 기술하고 가능하게 하는 것으로 용이하게 인식될 수 있다. 비제한적인 예로서, 본 명세서에서 논의된 각각의 범위는 하위 1/3, 중간 1/3 및 상위 1/3 등으로 쉽게 나누어질 수 있다. 당업자에 의해 또한 이해될 것인 바와 같이, "최대(up to)", "적어도(at least)", "초과(greater than)", "미만(less than)" 등과 같은 모든 표현은 열거된 수를 포함하고, 위에서 논의된 바와 같이 서브범위로 후속적으로 나누어질 수 있는 범위를 지칭한다. 마지막으로, 당업자에 의해 이해될 바로서, 범위는 각각의 개별 멤버를 포함한다. 따라서, 예를 들어, 1 내지 3개의 셀을 갖는 그룹은 1개, 2개 또는 3개의 셀을 갖는 그룹을 지칭한다. 유사하게, 1 내지 5개의 셀을 갖는 그룹은 1개, 2개, 3개, 4개, 또는 5개의 셀을 갖는 그룹을 지칭하고, 기타 등등이다.
더욱이, 청구항은, 그러한 취지로 언급되지 않는 한, 제공된 순서 또는 요소로 제한되는 것으로 읽히지 않아야 한다. 추가로, 임의의 청구항에서 용어 "~하기 위한 수단"을 사용하는 것은 35 U.S.C. §112, 6 또는 기능식 청구항(means-plus-function claim) 포맷을 인보크하도록 의도되고, 용어 "~하기 위한 수단"을 갖지 않는 임의의 청구항은 그렇게 의도되지 않는다.
소프트웨어와 연관된 프로세서는 무선 송수신 유닛(WTRU), 사용자 장비(UE), 단말기, 기지국, 이동성 관리 엔티티(MME) 또는 진화된 패킷 코어(EPC), 또는 임의의 호스트 컴퓨터에 사용하기 위한 무선 주파수 송수신기를 구현하는 데 사용될 수 있다. WTRU는 소프트웨어 정의 무선 장치(Software Defined Radio; SDR) 및 카메라, 비디오 카메라 모듈, 비디오폰, 스피커폰, 진동 디바이스, 스피커, 마이크로폰, 텔레비전 송수신기, 핸즈 프리 헤드셋, 키보드, 블루투스® 모듈, 주파수 변조(FM) 무선 유닛, 근거리 통신(Near Field Communication; NFC) 모듈, 액정 디스플레이(LCD) 디스플레이 유닛, 유기 발광 다이오드(OLED) 디스플레이 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저 및/또는 임의의 무선 근거리 네트워크(WLAN) 또는 초광대역(Ultra Wide Band; UWB) 모듈과 같은 다른 컴포넌트를 포함하는 하드웨어 및/또는 소프트웨어로 구현되는 모듈과 함께 사용될 수 있다.
본 발명은 통신 시스템의 관점에서 기술되었지만, 시스템은 마이크로프로세서/범용 컴퓨터(도시되지 않음) 상에서 소프트웨어로 구현될 수 있다는 것이 고려된다. 소정 실시예에서, 다양한 컴포넌트의 기능 중 하나 이상은 범용 컴퓨터를 제어하는 소프트웨어로 구현될 수 있다.
또한, 본 발명이 특정 실시예를 참조하여 본 명세서에 예시되고 기술되지만, 본 발명은 도시된 상세사항에 제한되는 것으로 의도되지 않는다. 오히려, 청구범위의 동등물의 범주 및 범위 내에서 그리고 본 발명을 벗어나지 않고서 상세사항에서 다양한 수정이 이루어질 수 있다.
본 개시내용 전반에 걸쳐, 당업자는 소정의 대표적인 실시예가 대안적으로 또는 다른 대표적인 실시예와 조합하여 사용될 수 있음을 이해한다.

Claims (20)

  1. 클라이언트 디바이스에서 구현되는 방법으로서,
    - 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 서버로부터 수신하는 단계;
    - 디코딩 및 디스플레이 전에 초기 레이턴시 값을 상기 수신된 패킷에 적용하는 단계;
    - 프레임 페이스 변동에 기초하여 결정된 요청된 레이턴시 값을 표시하는 제1 정보를 포함하는 요청 메시지를 상기 서버로 전송하는 단계;
    - 새로운 레이턴시 값을 표시하는 제2 정보를 포함하는 응답 메시지를 상기 서버로부터 수신하는 단계; 및
    - 디코딩 및 디스플레이 전에 상기 새로운 레이턴시 값을 수신된 후속 패킷에 적용하는 단계를 포함하는, 방법.
  2. 제1항에 있어서, 상기 초기 레이턴시 값 및 상기 새로운 레이턴시 값은, (i) 각각의 상기 초기 레이턴시 값 및 상기 새로운 레이턴시 값 및 (ii) 상기 패킷 및 상기 후속 패킷에 포함된 타임 스탬프 정보에 기초하여, 각각의 상기 패킷 및 상기 후속 패킷을 수신기 버퍼로부터 추출함으로써 각각의 상기 패킷 및 상기 후속 패킷에 적용되고, 상기 타임 스탬프 정보는 상기 서버의 전송자 버퍼에 상기 패킷 및 상기 후속 패킷을 저장하는 것과 연관된 각각의 시간을 표시하는, 방법.
  3. 제2항에 있어서, 상기 패킷 및 상기 후속 패킷 중 임의의 것의 패킷에 포함된 상기 타임 스탬프 정보는 상기 패킷이 상기 전송자 버퍼에 저장된 제1 시간을 표시하고, 상기 패킷은 상기 제1 시간 후의 시간량에 대응하는 제2 시간에 추출되고, 상기 시간량은 연속적인 패킷에 대해 일정하고 상기 초기 레이턴시 값 및 상기 새로운 레이턴시 값 중 임의의 것과 연관되는, 방법.
  4. 제2항 또는 제3항에 있어서, 상기 프레임 페이스 변동은 상기 비디오 프레임이 수신되는 페이스, 상기 수신기 버퍼로부터 추출되는 페이스, 및 디코딩되는 페이스 중 임의의 것의 변동인, 방법.
  5. 제1항 내지 제4항 중 어느 한 항에 있어서, 상기 새로운 레이턴시 값은 상이한 선행 기간에 대한 프레임 페이스 변동의 이력에 기초하여 획득되는, 방법.
  6. 제1항 내지 제5항 중 어느 한 항에 있어서, 상기 새로운 레이턴시 값은 지연된 프레임의 수 및 드롭된 프레임의 수 중 임의의 것에 추가로 기초하는, 방법.
  7. 제1항 내지 제6항 중 어느 한 항에 있어서, 상기 새로운 레이턴시 값은, 상기 새로운 레이턴시 값이 상기 요청된 레이턴시 값과 동일하거나 상기 요청된 레이턴시 값과 상기 초기 레이턴시 값 사이에 엄격하게 포함된다는 조건 상에서 상기 후속 패킷에 적용되는, 방법.
  8. 제1항 내지 제7항 중 어느 한 항에 있어서, 상기 비디오 프레임을 운반하는 상기 패킷이 수신되기 전에, 핸드쉐이크 요청 메시지는 상기 클라이언트 디바이스에 의해 상기 서버로 전송되고, 상기 핸드쉐이크 요청 메시지는 동적 레이턴시 동작을 지원하는 클라이언트 능력을 표시하는 제3 정보를 포함하는, 방법.
  9. 제8항에 있어서, 핸드쉐이크 응답 메시지는 상기 핸드쉐이크 요청 메시지에 응답하여 상기 클라이언트 디바이스에 의해 상기 서버로부터 수신되고, 상기 클라이언트 디바이스는 상기 핸드쉐이크 응답 메시지가 동적 레이턴시 동작을 지원하는 서버 능력을 표시하는 제4 정보를 포함한다는 조건 상에서 상기 요청 메시지를 전송함으로써 동적 레이턴시 동작을 수행하는, 방법.
  10. 제1항 내지 제7항 중 어느 한 항에 있어서, 상기 비디오 프레임을 운반하는 상기 패킷이 수신되기 전에, 핸드쉐이크 요청 메시지는 상기 클라이언트 디바이스에 의해 상기 서버로부터 수신되고, 상기 핸드쉐이크 요청 메시지가 동적 레이턴시 동작을 지원하는 서버 능력을 표시하는 제3 정보를 포함한다는 조건 상에서, 핸드쉐이크 응답 메시지는 상기 클라이언트 디바이스에 의해 상기 서버로 전송되고, 상기 핸드쉐이크 응답 메시지는 동적 레이턴시 동작을 지원하는 클라이언트 능력을 표시하는 제4 정보를 포함하는, 방법.
  11. 제1항 내지 제10항 중 어느 한 항에 있어서, 상기 초기 레이턴시 값 및 상기 새로운 레이턴시 값은 보안 신뢰성 전송(secure reliable transport; SRT)이고, 레이턴시 값은 SRT 프로토콜과 연관되는, 방법.
  12. 송신기, 수신기, 프로세서, 및 메모리 중 임의의 것을 포함하는 회로부를 포함하는 클라이언트 디바이스로서,
    - 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 서버로부터 수신하고;
    - 디코딩 및 디스플레이 전에 초기 레이턴시 값을 상기 수신된 패킷에 적용하고;
    - 프레임 페이스 변동에 기초하여 결정된 요청된 레이턴시 값을 표시하는 제1 정보를 포함하는 요청 메시지를 상기 서버로 전송하고;
    - 새로운 레이턴시 값을 표시하는 제2 정보를 포함하는 응답 메시지를 상기 서버로부터 수신하고;
    - 디코딩 및 디스플레이 전에 상기 새로운 레이턴시 값을 수신된 후속 패킷에 적용하도록 구성되는, 클라이언트 디바이스.
  13. 서버에서 구현되는 방법으로서,
    - 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 클라이언트 디바이스로 전송하는 단계;
    - 초기 레이턴시 값과 연관된 제1 시간량 동안 재송신을 위해 상기 패킷을 버퍼에 유지하는 단계;
    - 요청된 레이턴시 값을 표시하는 제1 정보를 포함하는 요청 메시지를 상기 클라이언트 디바이스로부터 수신하는 단계;
    - 새로운 레이턴시 값을 표시하는 제2 정보를 포함하는 응답 메시지를 상기 클라이언트 디바이스로 전송하는 단계;
    - 상기 비디오 콘텐츠의 후속 비디오 프레임을 운반하는 복수의 후속 패킷을 상기 클라이언트 디바이스로 전송하는 단계; 및
    - 상기 새로운 레이턴시 값과 연관된 제2 시간량 동안 재송신을 위해 상기 후속 패킷을 상기 버퍼에 유지하는 단계를 포함하는, 방법.
  14. 송신기, 수신기, 프로세서, 및 메모리 중 임의의 것을 포함하는 회로부를 포함하는 서버로서,
    - 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 클라이언트 디바이스로 전송하고;
    - 초기 레이턴시 값과 연관된 제1 시간량 동안 재송신을 위해 상기 패킷을 버퍼에 유지하고;
    - 요청된 레이턴시 값을 표시하는 제1 정보를 포함하는 요청 메시지를 상기 클라이언트 디바이스로부터 수신하고;
    - 새로운 레이턴시 값을 표시하는 제2 정보를 포함하는 응답 메시지를 상기 클라이언트 디바이스로 전송하고;
    - 상기 비디오 콘텐츠의 후속 비디오 프레임을 운반하는 복수의 후속 패킷을 상기 클라이언트 디바이스로 전송하고;
    - 상기 새로운 레이턴시 값과 연관된 제2 시간량 동안 재송신을 위해 상기 후속 패킷을 상기 버퍼에 유지하도록 구성되는, 서버.
  15. 클라이언트 디바이스에서 구현되는 방법으로서,
    - 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 서버로부터 수신하는 단계;
    - 디코딩 및 디스플레이 전에 초기 레이턴시 값을 상기 수신된 패킷에 적용하는 단계;
    - 프레임 페이스 변동을 나타내는 메트릭을 표시하는 정보를 상기 서버로 전송하는 단계;
    - 요청된 레이턴시 값을 표시하는 제1 정보를 포함하는 요청 메시지를 상기 서버로부터 수신하는 단계;
    - 상기 요청된 레이턴시 값에 기초한 새로운 레이턴시 값을 표시하는 제2 정보를 포함하는 응답 메시지를 상기 서버로 전송하는 단계; 및
    - 디코딩 및 디스플레이 전에 상기 새로운 레이턴시 값을 수신된 후속 패킷에 적용하는 단계를 포함하는, 방법.
  16. 제15항에 있어서, 상기 메트릭은 프레임 도착 시간, 패킷 도착 시간, 프레임 디코딩 시간, 및 프레임 디스플레이 시간 중 임의의 것의 분산 함수에 기초하고, 상기 분산 함수는 평균, 중앙값, 표준 편차, 분산, 평균 절대 편차, 및 사분위수간(interquartile) 중 임의의 것을 포함하는, 방법.
  17. 제15항 또는 제16항에 있어서, 상기 메트릭은 지연된 프레임의 수 및 드롭된 프레임의 수 중 임의의 것에 추가로 기초하는, 방법.
  18. 송신기, 수신기, 프로세서, 및 메모리 중 임의의 것을 포함하는 회로부를 포함하는 클라이언트 디바이스로서,
    - 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 서버로부터 수신하고;
    - 디코딩 및 디스플레이 전에 초기 레이턴시 값을 상기 수신된 패킷에 적용하고;
    - 프레임 페이스 변동을 나타내는 메트릭을 표시하는 정보를 상기 서버로 전송하고;
    - 요청된 레이턴시 값을 표시하는 제1 정보를 포함하는 요청 메시지를 상기 서버로부터 수신하고;
    - 상기 요청된 레이턴시 값에 기초한 새로운 레이턴시 값을 표시하는 제2 정보를 포함하는 응답 메시지를 상기 서버로 전송하고;
    - 디코딩 및 디스플레이 전에 상기 새로운 레이턴시 값을 수신된 후속 패킷에 적용하도록 구성되는, 클라이언트 디바이스.
  19. 서버에서 구현되는 방법으로서,
    - 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 클라이언트 디바이스로 전송하는 단계;
    - 초기 레이턴시 값과 연관된 제1 시간량 동안 재송신을 위해 상기 패킷을 버퍼에 유지하는 단계;
    - 프레임 페이스 변동을 나타내는 메트릭을 표시하는 정보를 수신하는 단계;
    - 상기 표시된 메트릭에 기초하여 결정된 요청된 레이턴시 값을 표시하는 제1 정보를 포함하는 요청 메시지를 상기 클라이언트 디바이스로 전송하는 단계;
    - 새로운 레이턴시 값을 표시하는 제2 정보를 포함하는 응답 메시지를 상기 클라이언트 디바이스로부터 수신하는 단계;
    - 상기 비디오 콘텐츠의 후속 비디오 프레임을 운반하는 복수의 후속 패킷을 상기 클라이언트 디바이스로 전송하는 단계; 및
    - 상기 새로운 레이턴시 값과 연관된 제2 시간량 동안 재송신을 위해 상기 후속 패킷을 상기 버퍼에 유지하는 단계를 포함하는, 방법.
  20. 송신기, 수신기, 프로세서, 및 메모리 중 임의의 것을 포함하는 회로부를 포함하는 서버로서,
    - 비디오 콘텐츠의 비디오 프레임을 운반하는 복수의 패킷을 클라이언트 디바이스로 전송하고;
    - 초기 레이턴시 값과 연관된 제1 시간량 동안 재송신을 위해 상기 패킷을 버퍼에 유지하고;
    - 프레임 페이스 변동을 나타내는 메트릭을 표시하는 정보를 수신하고;
    - 상기 표시된 메트릭에 기초하여 결정된 요청된 레이턴시 값을 표시하는 제1 정보를 포함하는 요청 메시지를 상기 클라이언트 디바이스로 전송하고;
    - 새로운 레이턴시 값을 표시하는 제2 정보를 포함하는 응답 메시지를 상기 클라이언트 디바이스로부터 수신하고;
    - 상기 비디오 콘텐츠의 후속 비디오 프레임을 운반하는 복수의 후속 패킷을 상기 클라이언트 디바이스로 전송하고;
    - 상기 새로운 레이턴시 값과 연관된 제2 시간량 동안 재송신을 위해 상기 후속 패킷을 상기 버퍼에 유지하도록 구성되는, 서버.
KR1020237035840A 2021-03-22 2022-03-18 클라우드 게이밍에서의 경험 품질 개선에 관한 방법, 장치 및 시스템 KR20230159533A (ko)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP21305349 2021-03-22
EP21305349.9 2021-03-22
PCT/EP2022/057178 WO2022200215A1 (en) 2021-03-22 2022-03-18 Method, apparatuses and systems directed to quality of experience improvement in cloud gaming

Publications (1)

Publication Number Publication Date
KR20230159533A true KR20230159533A (ko) 2023-11-21

Family

ID=75302491

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237035840A KR20230159533A (ko) 2021-03-22 2022-03-18 클라우드 게이밍에서의 경험 품질 개선에 관한 방법, 장치 및 시스템

Country Status (6)

Country Link
US (1) US20240165508A1 (ko)
EP (1) EP4313336A1 (ko)
JP (1) JP2024513707A (ko)
KR (1) KR20230159533A (ko)
CN (1) CN117222457A (ko)
WO (1) WO2022200215A1 (ko)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110126255A1 (en) * 2002-12-10 2011-05-26 Onlive, Inc. System and method for remote-hosted video effects

Also Published As

Publication number Publication date
WO2022200215A1 (en) 2022-09-29
CN117222457A (zh) 2023-12-12
EP4313336A1 (en) 2024-02-07
JP2024513707A (ja) 2024-03-27
US20240165508A1 (en) 2024-05-23

Similar Documents

Publication Publication Date Title
CN106464601B (zh) 信道捆绑
US9042444B2 (en) System and method for transmission of data signals over a wireless network
JP5149628B2 (ja) 順序付けられたビデオ・フレーム組を送信し、受信するためのシステム、送信器、受信器、方法及びソフトウェア
US9565482B1 (en) Adaptive profile switching system and method for media streaming over IP networks
EP3108639B1 (en) Transport accelerator implementing extended transmission control functionality
US9585062B2 (en) System and method for implementation of dynamic encoding rates for mobile devices
US8633963B2 (en) Determining buffer size based on retransmission latency
CN109644162B (zh) 媒体缓冲
US20130346562A1 (en) Data transmission method and apparatus for mobile terminal
KR102486847B1 (ko) 링크 인식 스트리밍 적응
JP2004007823A (ja) データ伝送方法および装置
US10230651B2 (en) Effective intra-frame refresh in multimedia communications over packet networks
EP3528469B1 (en) Adaptive restful real-time live media streaming
KR20150030713A (ko) 낙관적인 윈도우 조정들을 이용한 원치않은 tcp 재송신들의 회피
JP2010028378A (ja) 通信装置及び通信方法
US20200107069A1 (en) Systems and methods for reducing latency of a video transmission system
CN105611424B (zh) 基于rudp的音视频可靠传输qos方法、接收端及系统
KR20230159533A (ko) 클라우드 게이밍에서의 경험 품질 개선에 관한 방법, 장치 및 시스템
GB2543840A (en) Method and server for managing the transmission of packets over a plurality of paths
Tabari et al. Low latency live video streaming on android devices using web-socket
TWI549496B (zh) 行動電子裝置以及視訊補償方法
Yang et al. An adaptive multi-layer low-latency transmission scheme for H. 264 based screen sharing system
WO2024080976A1 (en) Real-time meeting data recovery after proactive participant interruption
WO2024080975A1 (en) Client adaptation for real-time meeting data recovery
McQuistin Deployable transport services for low-latency multimedia applications