KR20230129259A - 시각적 볼류메트릭 비디오 기반(v3c) 및 기하구조 기반 포인트 클라우드(g-pcc) 매체들의 스트리밍을 위한 mmt 시그널링 - Google Patents

시각적 볼류메트릭 비디오 기반(v3c) 및 기하구조 기반 포인트 클라우드(g-pcc) 매체들의 스트리밍을 위한 mmt 시그널링 Download PDF

Info

Publication number
KR20230129259A
KR20230129259A KR1020237026390A KR20237026390A KR20230129259A KR 20230129259 A KR20230129259 A KR 20230129259A KR 1020237026390 A KR1020237026390 A KR 1020237026390A KR 20237026390 A KR20237026390 A KR 20237026390A KR 20230129259 A KR20230129259 A KR 20230129259A
Authority
KR
South Korea
Prior art keywords
media
message
asset
data
pcc
Prior art date
Application number
KR1020237026390A
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 KR20230129259A publication Critical patent/KR20230129259A/ko

Links

Classifications

    • 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/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • 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/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23614Multiplexing of additional data and video streams
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81Monomedia components thereof
    • H04N21/816Monomedia components thereof involving special video data, e.g 3D video
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/10Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding
    • H04N19/134Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using adaptive coding characterised by the element, parameter or criterion affecting or controlling the adaptive coding
    • H04N19/136Incoming video signal characteristics or properties
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/50Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding
    • H04N19/597Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using predictive coding specially adapted for multi-view video sequence encoding
    • 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/21Server components or server architectures
    • H04N21/218Source of audio or video content, e.g. local disk arrays
    • H04N21/21805Source of audio or video content, e.g. local disk arrays enabling multiple viewpoints, e.g. using a plurality of cameras
    • 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/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/23605Creation or processing of packetized elementary streams [PES]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41Structure of client; Structure of client peripherals
    • H04N21/414Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/41407Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a portable device, e.g. video client on a mobile phone, PDA, laptop
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81Monomedia components thereof
    • H04N21/8146Monomedia components thereof involving graphical data, e.g. 3D object, 2D graphics
    • AHUMAN NECESSITIES
    • A63SPORTS; GAMES; AMUSEMENTS
    • A63FCARD, BOARD, OR ROULETTE GAMES; INDOOR GAMES USING SMALL MOVING PLAYING BODIES; VIDEO GAMES; GAMES NOT OTHERWISE PROVIDED FOR
    • A63F2300/00Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game
    • A63F2300/80Features of games using an electronically generated display having two or more dimensions, e.g. on a television screen, showing representations related to the game specially adapted for executing a specific type of game
    • A63F2300/8082Virtual reality
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06TIMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00Image coding
    • G06T9/001Model-based coding, e.g. wire frame

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Graphics (AREA)
  • Databases & Information Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

시각적 볼류메트릭 비디오 기반 코딩(V3C) 매체들 및 기하구조 기반 포인트 클라우드 코딩(G-PCC) 매체들의 스트리밍을 위한 방법들, 시스템들, 및 장치들이 본 명세서에 기술된다. 수신용 디바이스에서 구현되는 방법은, 전송용 디바이스로부터 스트리밍되기 위해 이용가능한 매체 자산들의 목록을 포함하는 제1 메시지, 또는 매체 자산들을 각각 설명하는 하나 이상의 메시지들 중 하나 이상을 수신하는 단계를 포함할 수 있다. 본 방법은, 전송용 디바이스로부터 스트리밍될 매체 자산들의 서브세트에 대한 요청을 나타내는 제2 메시지를 전송하는 단계를 추가로 포함할 수 있다. 매체 자산들의 요청된 서브세트는 수신용 디바이스의 뷰포트에 기초하여 결정될 수 있다. 본 방법은 동영상 전문가 그룹(MPEG) 매체 전송 프로토콜(MMTP) 패킷들을 수신하는 단계, 및 매체 자산들의 요청된 서브세트의 적어도 일부분을 복구하기 위해 패킷들을 프로세싱하는 단계를 추가로 포함할 수 있다.

Description

시각적 볼류메트릭 비디오 기반(V3C) 및 기하구조 기반 포인트 클라우드(G-PCC) 매체들의 스트리밍을 위한 MMT 시그널링
관련 출원들에 대한 상호 참조
본 출원은 2021년 1월 5일자로 출원된 미국 가출원 제63/134,038호 및 2021년 1월 5일자로 출원된 미국 가출원 제63/134,143호의 이익을 주장하며; 이들의 내용들은 본 명세서에 참고로 포함된다.
고품질의 3차원(3D) 포인트 클라우드들 및 다른 시각적 볼류메트릭 매체들, 예컨대 실제 또는 가상 3D 장면이 다수의 실제 또는 가상 카메라들에 의해 캡처되는 몰입형 비디오(immersive video) 콘텐츠가 최근에 몰입형 매체들의 진보된 표현들로서 부상하였다.
3D 포인트들을 캡처하고 렌더링하는 데 있어서 기술들의 최근 진보들은 원격 현실(tele-presence), 가상 현실, 및 대규모 동적 3D 맵들의 영역들에서 신규한 애플리케이션들을 허용할 수 있다. ISO/IEC JTC1/SC29/WG11 동영상 전문가 그룹(Moving Picture Experts Group, MPEG)의 3D 그래픽 서브그룹은 현재 2개의 3D 포인트 클라우드 압축(point cloud compression, PCC) 표준들, 즉 정적 포인트 클라우드들에 대한 기하구조 기반 압축 표준 및 동적 포인트 클라우드들에 대한 비디오 기반 압축 표준의 개발에 착수하고 있다. 이들 표준들의 목표는 3D 포인트 클라우드들의 효율적인 그리고 상호동작가능한 저장 및 송신을 지원하는 것일 수 있다. 이들 표준들의 요건들 중에는 포인트 클라우드 기하구조 좌표들 및 속성들의 손실 및/또는 무손실 코딩에 대한 지원이 있을 수 있다. MPEG-I 비주얼은, 경계지어진 볼륨 내에서 정확한 모션 시차를 갖는 6자유도(six degrees of freedom, 6DoF) 가상 워크스루(walkthrough)들을 지원하기 위해 몰입형 비디오 콘텐츠의 압축에 대한 표준의 개발에 착수하는 다른 MPEG 서브그룹이다. 제한된 6DoF를 갖는 몰입형 비디오들 및 비디오 기반 포인트 클라우드 압축 둘 모두가 비디오 코딩된 컴포넌트들에 의존할 수 있기 때문에, 이들 2개의 유형들의 몰입형 매체들의 이러한 코딩은 시각적 볼류메트릭 비디오 기반 코딩(visual volumetric video-based coding, V3C)으로 총칭될 수 있고, 동일한 비트스트림 포맷이 그들의 코딩된 정보를 표현하는 데 사용될 수 있다.
시각적 볼류메트릭 비디오 기반 코딩(V3C) 매체들 및 기하구조 기반 포인트 클라우드 코딩(geometry-based point cloud coding, G-PCC) 매체들의 스트리밍을 위한 방법들, 시스템들, 및 장치들이 본 명세서에 기술된다. 수신용 디바이스에서 구현되는 방법은, 전송용 디바이스로부터 스트리밍되기 위해 이용가능한 매체 자산들의 목록을 포함하는 제1 메시지, 또는 매체 자산들을 각각 설명하는 하나 이상의 메시지들 중 하나 이상을 수신하는 단계를 포함할 수 있다. 본 방법은, 전송용 디바이스로부터 스트리밍될 매체 자산들의 서브세트에 대한 요청을 나타내는 제2 메시지를 전송하는 단계를 추가로 포함할 수 있다. 매체 자산들의 요청된 서브세트는 수신용 디바이스의 뷰포트에 기초하여 결정될 수 있다. 본 방법은 동영상 전문가 그룹(MPEG) 매체 전송 프로토콜(Media Transport Protocol, MMTP) 패킷들을 수신하는 단계, 및 매체 자산들의 요청된 서브세트의 적어도 일부분을 복구하기 위해 패킷들을 프로세싱하는 단계를 추가로 포함할 수 있다.
첨부 도면과 함께 예로서 주어진 다음의 설명으로부터 보다 상세한 이해가 이루어질 수 있으며, 도면에서 유사한 참조 번호는 유사한 요소를 나타낸다.
도 1a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 통신 시스템을 예시하는 시스템도이다.
도 1b는 일 실시예에 따라 도 1a에 예시된 통신 시스템 내에서 사용될 수 있는 예시적인 무선 송수신 유닛(wireless transmit/receive unit, WTRU)을 예시하는 시스템도이다.
도 1c는 일 실시예에 따라 도 1a에 예시된 통신 시스템 내에서 사용될 수 있는 예시적인 무선 액세스 네트워크(radio access network, RAN) 및 예시적인 코어 네트워크(core network, CN)를 예시하는 시스템도이다.
도 1d는 일 실시예에 따라 도 1a에 예시된 통신 시스템 내에서 사용될 수 있는 추가의 예시적인 RAN 및 추가의 예시적인 CN을 예시하는 시스템도이다.
도 2는 비디오 인코더의 일례를 예시하는 도면이다.
도 3은 비디오 디코더의 일례를 예시하는 도면이다.
도 4는 본 명세서에 기술된 다양한 태양들 및 실시예들이 구현될 수 있는 시스템의 일례를 예시하는 도면이다.
도 5는 서버 및 클라이언트에 대한 시스템 인터페이스의 일례를 도시하는 도면이다.
도 6은 서버 및 클라이언트에 대한 시스템 인터페이스의 다른 예를 도시하는 도면이다.
도 7은 V3C 비트스트림의 구조의 일례를 예시한다.
도 8은 지원된 V3C 속성 유형들의 예들을 예시하는 표이다.
도 9는 ISOBMFF(international organization for standardization base media file format) 표준들에 따라 구현될 수 있는 바와 같은 V3C 컨테이너의 구조의 일례를 도시한다.
도 10은 하나 초과의 아틀라스 및 다수의 아틀라스 타일들을 갖는 다중 트랙 컨테이너의 일례를 예시한다.
도 11은 비트스트림의 구조의 일례를 예시하는 도면이다.
도 12는 G-PCC 유형-길이-값(type-length-value, TLV) 캡슐화 유닛의 예시적인 신택스 구조를 제공하는 표이다.
도 13은 TLV 유형 파라미터의 가능한 값들 및 대응하는 설명들을 제공하는 표이다.
도 14는 G-PCC TLV 유닛 페이로드의 예시적인 신택스 구조를 제공하는 표이다.
도 15는, G-PCC 기하구조 및 속성 정보를 제공하는 비트스트림이 단일 트랙에 저장되는 스킴들에 따른 샘플 구조의 일례를 예시한다.
도 16은 다중 트랙 ISOBMFF G-PCC 컨테이너의 예시적인 구조를 도시한다.
도 17은 MMT 시그널링이 수행되는 시스템의 예시적인 종단간 아키텍처를 도시한다.
도 18은 일부 실시예들에 따른 패키지 구조의 예시이다.
도 19는 정의된 애플리케이션 메시지 유형들의 목록을 제공하는 표이다.
도 20은 V3C 자산 디스크립터의 신택스 구조의 일례를 제공하는 표이다.
도 21은 V3CAssetGroupMessage의 예시적인 신택스를 예시하는 표이다.
도 22는 Data_type 필드에서 사용될 수 있는 바와 같은 V3C 데이터 유형 값들의 일례를 예시하는 표이다.
도 23은 V3CSelectionMessage의 예시적인 신택스를 예시하는 표이다.
도 24는 switching_mode 필드의 정의들을 제공하는 표이다.
도 25는 V3CViewChangeFeedbackMessage의 예시적인 신택스를 예시하는 표이다.
도 26은 G-PCC 자산 디스크립터의 신택스 구조의 일례를 제공하는 표이다.
도 27은 정의된 G-PCC 애플리케이션 메시지 유형들의 예들을 예시하는 표이다.
도 28은 그룹 메시지의 예시적인 신택스를 예시하는 표이다.
도 29는 Data_type 필드에서 사용될 수 있는 바와 같은 G-PCC 데이터 유형 값들의 일례를 예시하는 표이다.
도 30은 GPCC 선택 피드백 메시지의 예시적인 신택스를 예시하는 표이다.
도 31은 switching_mode 필드의 정의들을 제공하는 표이다.
도 32는 G-PCC 뷰 변경 피드백 메시지(예컨대, "GPCCViewChangeFeedback")의 예시적인 신택스를 예시하는 표이다.
도 1a는 하나 이상의 개시된 실시예들이 구현될 수 있는 예시적인 통신 시스템(100)을 예시하는 도면이다. 통신 시스템(100)은 음성, 데이터, 비디오, 메시징, 방송 등과 같은 콘텐츠를 다수의 무선 사용자에게 제공하는 다중 액세스 시스템일 수 있다. 통신 시스템(100)은 다수의 무선 사용자가 무선 대역폭을 포함한 시스템 자원들의 공유를 통해 그러한 콘텐츠에 액세스하는 것을 가능하게 할 수 있다. 예를 들어, 통신 시스템들(100)은 CDMA(code division multiple access), TDMA(time division multiple access), FDMA(frequency division multiple access), OFDMA(orthogonal FDMA), SC-FDMA(single-carrier FDMA), ZT-UW-DFT-S-OFDM(zero-tail unique-word discrete Fourier transform Spread OFDM), UW-OFDM(unique word OFDM), 자원 블록 필터링된 OFDM, FBMC(filter bank multicarrier) 등과 같은 하나 이상의 채널 액세스 방법들을 사용할 수 있다.
도 1a에서 도시되는 바와 같이, 통신 시스템(100)은 무선 송수신 유닛(WTRU)들(102a, 102b, 102c, 102d), 무선 액세스 네트워크(RAN)(104), 코어 네트워크(CN)(106), 공중 교환 전화망(public switched telephone network, PSTN)(108), 인터넷(110), 및 다른 네트워크들(112)을 포함할 수 있지만, 개시된 실시예들은 임의의 수의 WTRU들, 기지국들, 네트워크들, 및/또는 네트워크 요소들을 고려한다는 것이 이해될 것이다. WTRU들(102a, 102b, 102c, 102d) 각각은 무선 환경에서 동작하고/하거나 통신하도록 구성된 임의의 유형의 디바이스일 수 있다. 예로서, WTRU들(102a, 102b, 102c, 102d) - 이들 중 임의의 것은 "스테이션(STA)"이라고 지칭될 수 있음 - 은 무선 신호들을 송신 및/또는 수신하도록 구성될 수 있고, 사용자 장비(user equipment, UE), 이동국, 고정 또는 이동 가입자 유닛, 가입 기반 유닛, 페이저, 셀룰러 전화, PDA(personal digital assistant), 스마트폰, 랩톱, 넷북, 개인용 컴퓨터, 무선 센서, 핫스폿 또는 Mi-Fi 디바이스, 사물 인터넷(Internet of Things, IoT) 디바이스, 시계 또는 다른 웨어러블, HMD(head-mounted display), 차량, 드론, 의료 디바이스 및 응용들(예컨대, 원격 수술), 산업 디바이스 및 응용들(예컨대, 산업 및/또는 자동화된 프로세싱 체인 상황들에서 동작하는 로봇 및/또는 다른 무선 디바이스들), 가전 디바이스, 상업 및/또는 산업 무선 네트워크들 상에서 동작하는 디바이스 등을 포함할 수 있다. WTRU들(102a, 102b, 102c, 및 102d) 중 임의의 것은 UE로 교환가능하게 지칭될 수 있다.
통신 시스템들(100)은 또한 기지국(114a) 및/또는 기지국(114b)을 포함할 수 있다. 기지국들(114a, 114b) 각각은 예를 들어, CN(106), 인터넷(110), 및/또는 다른 네트워크들(112)과 같은 하나 이상의 통신 네트워크들에 대한 액세스를 용이하게 하기 위해 WTRU들(102a, 102b, 102c, 102d) 중 적어도 하나와 무선으로 인터페이싱하도록 구성된 임의의 유형의 디바이스일 수 있다. 예로서, 기지국들(114a, 114b)은 BTS(base transceiver station), NodeB, eNode B(eNB), 홈 노드 B, 홈 eNode B, 예를 들어, gNode B(gNB)와 같은 차세대 NodeB, 사이트 제어기(site controller), 액세스 포인트(access point, AP), 무선 라우터 등일 수 있다. 기지국들(114a, 114b)은 각각 단일 요소로서 도시되지만, 기지국들(114a, 114b)은 임의의 수의 상호 접속된 기지국들 및/또는 네트워크 요소들을 포함할 수 있음을 알 것이다.
기지국(114a)은 RAN(104)의 일부일 수 있고, RAN(104)은 기지국 제어기(base station controller, BSC), 무선 네트워크 제어기(radio network controller, RNC), 릴레이 노드 등과 같은 다른 기지국 및/또는 네트워크 요소(도시되지 않음)를 또한 포함할 수 있다. 기지국(114a) 및/또는 기지국(114b)은 셀(도시되지 않음)이라고 지칭될 수 있는 하나 이상의 반송파 주파수들 상에서 무선 신호들을 송신하도록 그리고/또는 수신하도록 구성될 수 있다. 이러한 주파수들은 면허 스펙트럼 및 무면허 스펙트럼 또는 면허 스펙트럼과 무면허 스펙트럼의 조합 내에 있을 수 있다. 셀은 비교적 고정될 수 있거나 시간 경과에 따라 변할 수 있는 특정 지리 영역에 대한 무선 서비스를 위한 커버리지를 제공할 수 있다. 셀은 셀 섹터들로 더욱 분할될 수 있다. 예를 들어, 기지국(114a)과 연관된 셀은 3개의 섹터들로 분할될 수 있다. 따라서, 일 실시예에서, 기지국(114a)은 3개의 송수신기, 즉 셀의 각각의 섹터에 대해 하나씩을 포함할 수 있다. 실시예에서, 기지국(114a)은 MIMO(multiple-input multiple-output) 기술을 채용할 수 있고, 셀의 섹터마다 다수의 송수신기를 이용할 수 있다. 예를 들어, 신호들을 원하는 공간 방향들로 송신하고/하거나 수신하기 위해 빔포밍(beamforming)이 사용될 수 있다.
기지국들(114a, 114b)은 임의의 적합한 무선 통신 링크(예컨대, RF(radio frequency), 마이크로파, 센티미터파, 마이크로미터파, IR(infrared), UV(ultraviolet), 가시광 등)일 수 있는 에어 인터페이스(air interface)(116)를 통해 WTRU들(102a, 102b, 102c, 102d) 중 하나 이상과 통신할 수 있다. 에어 인터페이스(116)는 임의의 적합한 무선 액세스 기술(radio access technology, RAT)을 사용하여 확립될 수 있다.
더 구체적으로, 전술한 바와 같이, 통신 시스템(100)은 다중 액세스 시스템일 수 있으며, CDMA, TDMA, FDMA, OFDMA, SC-FDMA 등과 같은 하나 이상의 채널 액세스 스킴을 채용할 수 있다. 예를 들어, RAN(104) 내의 기지국(114a) 및 WTRU들(102a, 102b, 102c)은 광대역 CDMA(WCDMA)를 사용하여 에어 인터페이스(116)를 확립할 수 있는 유니버설 이동 통신 시스템(UMTS) 지상 무선 액세스(UTRA)와 같은 무선 기술을 구현할 수 있다. WCDMA는 고속 패킷 액세스(High-Speed Packet Access, HSPA) 및/또는 진화된 HSPA(HSPA+)와 같은 통신 프로토콜들을 포함할 수 있다. HSPA는 고속 다운링크(DL) 패킷 액세스(High-Speed Downlink Packet Access, HSDPA) 및/또는 고속 업링크(uplink, UL) 패킷 액세스(High-Speed Uplink Packet Access, HSUPA)를 포함할 수 있다.
실시예에서, 기지국(114a) 및 WTRU들(102a, 102b, 102c)은 예를 들어, LTE(Long Term Evolution) 및/또는 LTE-A(LTE-Advanced) 및/또는 LTE-A Pro(LTE-Advanced Pro)를 사용하여 에어 인터페이스(116)를 확립할 수 있는 E-UTRA(Evolved UMTS Terrestrial Radio Access)와 같은 무선 기술을 구현할 수 있다.
실시예에서, 기지국(114a) 및 WTRU들(102a, 102b, 102c)은 NR을 사용하여 에어 인터페이스(116)를 확립할 수 있는 NR 무선 액세스와 같은 무선 기술을 구현할 수 있다.
실시예에서, 기지국(114a) 및 WTRU들(102a, 102b, 102c)은 다수의 무선 액세스 기술을 구현할 수 있다. 예를 들어, 기지국(114a) 및 WTRU들(102a, 102b, 102c)은 예를 들어, 이중 접속성(dual connectivity, DC) 원리들을 사용하여 LTE 무선 액세스 및 NR 무선 액세스를 함께 구현할 수 있다. 따라서, WTRU들(102a, 102b, 102c)에 의해 이용되는 에어 인터페이스는 다수의 유형의 무선 액세스 기술들 및/또는 다수의 유형의 기지국들(예컨대, eNB 및 gNB)로/로부터 송신되는 송신물들에 의해 특성화될 수 있다.
다른 실시예에서, 기지국(114a) 및 WTRU들(102a, 102b, 102c)은 IEEE 802.11(즉, WiFi(Wireless Fidelity)), IEEE 802.16(즉, WiMAX(Worldwide Interoperability for Microwave Access)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, IS -2000(Interim Standard 2000), IS-95(Interim Standard 95), IS-856(Interim Standard 856), GSM(Global System for Mobile communications), EDGE(Enhanced Data rates for GSM Evolution), GERAN(GSM EDGE) 등과 같은 무선 기술들을 구현할 수 있다.
도 1a의 기지국(114b)은 예를 들어, 무선 라우터, 홈 Node B, 홈 eNode B, 또는 액세스 포인트일 수 있고, 예를 들어, 사업장, 집, 차량, 캠퍼스, 산업 시설, (예컨대, 드론들에 의한 사용을 위한) 에어 코리도(air corridor), 도로 등과 같은 국부화된 영역에서의 무선 접속성을 용이하게 하기 위해 임의의 적합한 RAT를 이용할 수 있다. 일 실시예에서, 기지국(114b) 및 WTRU들(102c, 102d)은 IEEE 802.11과 같은 무선 기술을 구현하여 무선 근거리 네트워크(wireless local area network, WLAN)를 확립할 수 있다. 일 실시예에서, 기지국(114b) 및 WTRU들(102c, 102d)은 무선 개인 영역 네트워크(wireless personal area network, WPAN)를 확립하기 위해 IEEE 802.15와 같은 무선 기술을 구현할 수 있다. 또 다른 실시예에서, 기지국(114b) 및 WTRU들(102c, 102d)은 피코셀 또는 펨토셀을 확립하기 위해 셀룰러 기반 RAT(예컨대, WCDMA, CDMA2000, GSM, LTE, LTE-A, LTE-A Pro, NR 등)를 활용할 수 있다. 도 1a에 도시된 바와 같이, 기지국(114b)은 인터넷(110)에 대한 직접 접속을 가질 수 있다. 따라서, 기지국(114b)은 CN(106)을 통해 인터넷(110)에 액세스하도록 요구되지 않을 수 있다.
RAN(104)은 음성, 데이터, 애플리케이션들, 및/또는 VoIP(voice over internet protocol) 서비스들을 WTRU들(102a, 102b, 102c, 102d) 중 하나 이상에 제공하도록 구성된 임의의 유형의 네트워크일 수 있는 CN(106)과 통신할 수 있다. 데이터는 상이한 처리량 요건들, 레이턴시 요건들, 오류 허용 한계 요건들, 신뢰성 요건들, 데이터 처리량 요건들, 이동성 요건들 등과 같은 다양한 서비스 품질(quality of service, QoS) 요건들을 가질 수 있다. CN(106)은 호출 제어, 과금 서비스들, 이동 위치 기반 서비스들, 선불 통화, 인터넷 접속성, 비디오 배포 등을 제공하고 그리고/또는 예를 들어, 사용자 인증과 같은 하이 레벨 보안 기능들을 수행할 수 있다. 도 1a에 도시되진 않지만, RAN(104) 및/또는 CN(106)은, RAN(104)과 동일한 RAT 또는 상이한 RAT를 채용하는 다른 RAN들과 직접 또는 간접 통신할 수 있음이 이해될 것이다. 예를 들어, NR 무선 기술을 사용하는 것일 수 있는 RAN(104)에 대한 접속에 더하여, CN(106)은 또한 GSM, UMTS, CDMA 2000, WiMAX, E-UTRA, 또는 WiFi 무선 기술을 사용하여 또 다른 RAN(도시되지 않음)과 통신할 수 있다.
CN(106)은 또한 WTRU들(102a, 102b, 102c, 102d)이 PSTN(108), 인터넷(110), 및/또는 다른 네트워크들(112)에 액세스하기 위한 게이트웨이로서 역할을 할 수 있다. PSTN(108)은 POTS(plain old telephone service)를 제공하는 회선 교환 전화망들을 포함할 수 있다. 인터넷(110)은, 송신 제어 프로토콜/인터넷 프로토콜(transmission control protocol/internet protocol, TCP/IP) 일군(suite)에서의 TCP, 사용자 데이터그램 프로토콜(user datagram protocol, UDP) 및/또는 IP와 같은 공통 통신 프로토콜을 사용하는 상호접속된 컴퓨터 네트워크들 및 디바이스들의 글로벌 시스템을 포함할 수 있다. 네트워크들(112)은 다른 서비스 제공자들에 의해 소유되고 그리고/또는 운영되는 유선 및/또는 무선 통신 네트워크들을 포함할 수 있다. 예를 들어, 네트워크들(112)은 RAN(104)과 동일한 RAT 또는 상이한 RAT를 사용할 수 있는 하나 이상의 RAN들에 접속된 또 다른 CN을 포함할 수 있다.
통신 시스템(100) 내의 WTRU들(102a, 102b, 102c, 102d) 중 일부 또는 전부는 다중 모드 능력들을 포함할 수 있다(예컨대, WTRU들(102a, 102b, 102c, 102d)은 상이한 무선 링크들을 통해 상이한 무선 네트워크들과 통신하기 위해 다수의 송수신기들을 포함할 수 있다). 예를 들어, 도 1a에 도시된 WTRU(102c)는 셀룰러 기반 무선 기술을 채용할 수 있는 기지국(114a) 및 IEEE 802 무선 기술을 채용할 수 있는 기지국(114b)과 통신하도록 구성될 수 있다.
도 1b는 예시적인 WTRU(102)를 예시하는 시스템 도면이다. 도 1b에 도시된 바와 같이, WTRU(102)는 특히 프로세서(118), 송수신기(120), 송수신 요소(122), 스피커/마이크로폰(124), 키패드(126), 디스플레이/터치패드(128), 비착탈식 메모리(130), 착탈식 메모리(132), 전원(134), GPS(global positioning system) 칩셋(136), 및/또는 다른 주변기기들(138)을 포함할 수 있다. WTRU(102)는 실시예와 여전히 부합하면서 전술한 요소들의 임의의 하위 조합을 포함할 수 있음을 알 것이다.
프로세서(118)는 범용 프로세서, 특수 목적 프로세서, 종래의 프로세서, 디지털 신호 프로세서(digital signal processor, DSP), 복수의 마이크로프로세서들, DSP 코어와 연관된 하나 이상의 마이크로프로세서들, 제어기, 마이크로제어기, 주문형 집적 회로(Application Specific Integrated Circuit, ASIC), 필드 프로그래밍가능 게이트 어레이(Field Programmable Gate Array, FPGA), 임의의 다른 유형의 집적 회로(integrated circuit, IC), 상태 기계 등일 수 있다. 프로세서(118)는 신호 코딩, 데이터 프로세싱, 전력 제어, 입출력 프로세싱, 및/또는 WTRU(102)가 무선 환경에서 동작하는 것을 가능하게 하는 임의의 다른 기능을 수행할 수 있다. 프로세서(118)는 송수신 요소(122)에 결합될 수 있는 송수신기(120)에 결합될 수 있다. 도 1b는 프로세서(118) 및 송수신기(120)를 별개의 컴포넌트들로서 도시하지만, 프로세서(118) 및 송수신기(120)는 전자 패키지 또는 칩 내에 함께 통합될 수 있다는 것을 알 것이다.
송수신 요소(122)는 에어 인터페이스(116)를 통해 기지국(예를 들어, 기지국(114a))에 신호를 송신하거나 그로부터 신호를 수신하도록 구성될 수 있다. 예를 들어, 일 실시예에서, 송수신 요소(122)는 RF 신호를 송신하도록 그리고/또는 수신하도록 구성된 안테나일 수 있다. 실시예에서, 송수신 요소(122)는, 예를 들면, IR, UV, 또는 가시광 신호를 송신하도록 그리고/또는 수신하도록 구성되는 방출기(emitter)/검출기(detector)일 수 있다. 또 다른 실시예에서, 송수신 요소(122)는 RF 신호 및 광 신호 둘 모두를 송신하도록 그리고/또는 수신하도록 구성될 수 있다. 송수신 요소(122)는 무선 신호들의 임의의 조합을 송신하도록 그리고/또는 수신하도록 구성될 수 있음을 알 것이다.
송수신 요소(122)가 단일 요소로서 도 1b에 도시되지만, WTRU(102)는 임의의 수의 송수신 요소(122)를 포함할 수 있다. 더 구체적으로, WTRU(102)는 MIMO 기술을 채용할 수 있다. 따라서, 일 실시예에서, WTRU(102)는 에어 인터페이스(116)를 통해 무선 신호를 송신 및 수신하기 위한 2개 이상의 송수신 요소(122)(예를 들어, 다수의 안테나)를 포함할 수 있다.
송수신기(120)는 송수신 요소(122)에 의해 송신될 신호를 변조하도록, 그리고 송수신 요소(122)에 의해 수신된 신호를 복조하도록 구성될 수 있다. 전술한 바와 같이, WTRU(102)는 다중 모드 능력을 가질 수 있다. 따라서, 송수신기(120)는, WTRU(102)가, 예를 들면, NR 및 IEEE 802.11과 같은 다수의 RAT를 통해 통신하는 것을 가능하게 하기 위한 다수의 송수신기를 포함할 수 있다.
WTRU(102)의 프로세서(118)는 스피커/마이크로폰(124), 키패드(126) 및/또는 디스플레이/터치 패드(128)(예를 들어, 액정 디스플레이(liquid crystal display, LCD) 디스플레이 유닛 또는 유기 발광 다이오드(organic light-emitting diode, OLED) 디스플레이 유닛)에 결합될 수 있고, 그들로부터 사용자 입력 데이터를 수신할 수 있다. 프로세서(118)는 또한 사용자 데이터를 스피커/마이크로폰(124), 키패드(126) 및/또는 디스플레이/터치 패드(128)에 출력할 수 있다. 또한, 프로세서(118)는 비착탈식 메모리(130) 및/또는 착탈식 메모리(132)와 같은 임의의 유형의 적합한 메모리로부터의 정보에 액세스하고, 그 안에 데이터를 저장할 수 있다. 비착탈식 메모리(130)는 랜덤 액세스 메모리(random-access memory, RAM), 판독 전용 메모리(read-only memory, ROM), 하드 디스크 또는 임의의 다른 유형의 메모리 저장 디바이스를 포함할 수 있다. 착탈식 메모리(132)는 가입자 식별 모듈(subscriber identity module, SIM) 카드, 메모리 스틱, 보안 디지털(secure digital, SD) 메모리 카드 등을 포함할 수 있다. 다른 실시예들에서, 프로세서(118)는 서버 또는 홈 컴퓨터(도시되지 않음)와 같은 WTRU(102) 상에 물리적으로 위치하지 않는 메모리로부터 정보에 액세스하고 그 안에 데이터를 저장할 수 있다.
프로세서(118)는 전원(134)으로부터 전력을 수신할 수 있고, 전력을 WTRU(102) 내의 다른 컴포넌트들에 분배하도록 그리고/또는 제어하도록 구성될 수 있다. 전원(134)은 WTRU(102)에 전력을 공급하기 위한 임의의 적합한 디바이스일 수 있다. 예를 들어, 전원(134)은 하나 이상의 건전지(예컨대, 니켈-카드뮴(NiCd), 니켈-아연(NiZn), 니켈 금속 수소화물(NiMH), 리튬 이온(Li-ion) 등), 태양 전지, 연료 전지 등을 포함할 수 있다.
프로세서(118)는 또한 WTRU(102)의 현재 위치에 관한 위치 정보(예컨대, 경도 및 위도)를 제공하도록 구성될 수 있는 GPS 칩셋(136)에 결합될 수 있다. GPS 칩셋(136)으로부터의 정보에 더하여 또는 그 대신에, WTRU(102)는 기지국(예를 들어, 기지국들(114a, 114b))으로부터 에어 인터페이스(116)를 통해 위치 정보를 수신하고/하거나, 2개 이상의 인근 기지국으로부터 수신되는 신호들의 타이밍에 기초하여 그의 위치를 결정할 수 있다. WTRU(102)는 실시예와 여전히 부합하면서 임의의 적합한 위치 결정 방법에 의해 위치 정보를 획득할 수 있다는 것을 알 것이다.
프로세서(118)는 추가적인 특징들, 기능 및/또는 유선 또는 무선 접속성을 제공하는 하나 이상의 소프트웨어 및/또는 하드웨어 모듈을 포함할 수 있는 다른 주변기기들(138)에 추가로 결합될 수 있다. 예를 들어, 주변기기들(138)은 가속도계, 전자 나침반, 위성 송수신기, (사진들 및/또는 비디오를 위한) 디지털 카메라, 범용 직렬 버스(universal serial bus, USB) 포트, 진동 디바이스, 텔레비전 송수신기, 핸즈프리 헤드셋, 블루투스® 모듈, 주파수 변조(frequency modulated, FM) 무선 유닛, 디지털 음악 플레이어, 미디어 플레이어, 비디오 게임 플레이어 모듈, 인터넷 브라우저, 가상 현실 및/또는 증강 현실(VR/AR) 디바이스, 활동 추적기 등을 포함할 수 있다. 주변기기(138)는 하나 이상의 센서들을 포함할 수 있다. 센서들은 자이로스코프, 가속도계, 홀 효과 센서, 자력계, 배향 센서, 근접 센서, 온도 센서, 시간 센서; 지리 위치 센서(geolocation sensor), 고도계, 광 센서, 터치 센서, 자력계, 기압계, 제스처 센서, 생체 인식 센서, 습도 센서 등 중 하나 이상일 수 있다.
WTRU(102)는 (예컨대, (예컨대, 송신을 위한) UL 및(예컨대, 수신을 위한) DL 둘 모두에 대해 특정 서브프레임들과 연관된) 신호들의 일부 또는 전부의 송신 및 수신이 동반적이고 그리고/또는 동시적일 수 있는 전이중 무선 장치(full duplex radio)를 포함할 수 있다. 전이중 무선 장치는 하드웨어(예컨대, 초크(choke))를 통해 또는 프로세서(예컨대, 별개의 프로세서(도시되지 않음) 또는 프로세서(118))를 통한 신호 프로세싱을 통해 자가 간섭(self-interference)을 줄이고 그리고/또는 실질적으로 제거하는 간섭 관리 유닛을 포함할 수 있다. 실시예에서, WTRU(102)는 (예컨대, (예컨대, 송신을 위한) UL 또는 (예컨대, 수신을 위한) DL에 대해 특정 서브프레임들과 연관된) 신호들의 일부 또는 전부의 송신 및 수신을 위한 반이중 무선 장치(half-duplex radio)를 포함할 수 있다.
도 1c는 실시예에 따른 RAN(104) 및 CN(106)을 예시하는 시스템도이다. 전술한 바와 같이, RAN(104)은 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c)과 통신하기 위해 E-UTRA 무선 기술을 채용할 수 있다. RAN(104)은 또한 CN(106)과 통신할 수 있다.
RAN(104)은 eNode-B(160a, 160b, 160c)를 포함할 수 있지만, RAN(104)은 실시예와 여전히 부합하면서 임의의 수의 eNode-B를 포함할 수 있다는 것이 인식될 것이다. eNode-B들(160a, 160b, 160c) 각각은 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c)과 통신하기 위해 하나 이상의 송수신기를 포함할 수 있다. 일 실시예에서, eNode-B(160a, 160b, 160c)는 MIMO 기술을 구현할 수 있다. 따라서, eNode-B(160a)는 예를 들어, WTRU(102a)에 무선 신호들을 송신하고 그리고/또는 그로부터 무선 신호들을 수신하기 위해 다수의 안테나를 사용할 수 있다.
eNode-B들(160a, 160b, 160c) 각각은 특정 셀(도시되지 않음)과 연관될 수 있고, 무선 자원 관리 결정들, 핸드오버 결정들, UL 및/또는 DL에서의 사용자들의 스케줄링 등을 핸들링하도록 구성될 수 있다. 도 1c에 도시된 바와 같이, eNodeB들(160a, 160b, 160c)은 X2 인터페이스를 통해 서로 통신할 수 있다.
도 1c에 도시된 CN(106)은 이동성 관리 엔티티(MME)(162), 서빙 게이트웨이(SGW)(164), 및 패킷 데이터 네트워크(PDN) 게이트웨이(PGW)(166)를 포함할 수 있다. 전술한 요소들이 CN(106)의 일부로서 묘사되지만, 이들 요소들 중 임의의 것이 CN 운영자 이외의 엔티티에 의해 소유되고/되거나 운영될 수 있다는 것이 이해될 것이다.
MME(162)는 S1 인터페이스를 통해 RAN(104) 내의 eNode-B들(162a, 162b, 162c) 각각에 접속될 수 있고 제어 노드로서의 역할을 할 수 있다. 예를 들어, MME(162)는 WTRU들(102a, 102b, 102c)의 사용자들을 인증하는 것, 베어러 활성화/비활성화, WTRU들(102a, 102b, 102c)의 초기 접속(initial attach) 동안 특정의 서빙 게이트웨이를 선택하는 것 등을 책임지고 있을 수 있다. MME(162)는 RAN(104)과, GSM 및/또는 WCDMA와 같은 다른 무선 기술들을 사용하는 다른 RAN들(도시되지 않음) 간에 스위칭하기 위한 제어 평면 기능을 제공할 수 있다.
SGW(164)는 S1 인터페이스를 통해 RAN(104) 내의 eNode B들(160a, 160b, 160c) 각각에 접속될 수 있다. SGW(164)는 일반적으로 WTRU들(102a, 102b, 102c)로/로부터 사용자 데이터 패킷들을 라우팅하고 포워딩할 수 있다. SGW(164)는 인터-eNode B 핸드오버들 동안 사용자 평면들을 앵커링(anchoring)하는 것, WTRU들(102a, 102b, 102c)에 대해 DL 데이터가 이용가능할 때 페이징(paging)을 트리거하는 것, WTRU들(102a, 102b, 102c)의 정황들을 관리하고 저장하는 것 등과 같은 다른 기능들을 수행할 수 있다.
SGW(164)는 WTRU들(102a, 102b, 102c)과 IP 인에이블드 디바이스(IP-enabled device)들 사이의 통신을 용이하게 하기 위해, 예를 들어, 인터넷(110)과 같은 패킷 교환 네트워크들에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수 있는 PGW(166)에 접속될 수 있다.
CN(106)은 다른 네트워크들과의 통신을 용이하게 할 수 있다. 예를 들어, CN(106)은 WTRU들(102a, 102b, 102c)과 전통적인 지상선 통신 디바이스들 사이의 통신을 용이하게 하기 위해, PSTN(108)과 같은 회선 교환 네트워크들에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수 있다. 예를 들어, CN(106)은, CN(106)과 PSTN(108) 사이의 인터페이스로서 역할을 하는 IP 게이트웨이(예컨대, IP 멀티미디어 서브시스템(multimedia subsystem, IMS) 서버)를 포함할 수 있거나, 또는 그와 통신할 수 있다. 추가로, CN(106)은 다른 서비스 제공자들에 의해 소유되고 그리고/또는 운영되는 다른 유선 및/또는 무선 네트워크들을 포함할 수 있는 다른 네트워크들(112)에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수 있다.
WTRU가 도 1a 내지 도 1d에서 무선 단말기로서 설명되지만, 특정한 대표적 실시예들에서 그러한 단말기는 통신 네트워크와의 유선 통신 인터페이스들을 (예컨대, 일시적으로 또는 영구적으로) 사용할 수 있다는 것이 고려된다.
대표적 실시예에서, 다른 네트워크(112)는 WLAN일 수 있다.
인프라구조 기본 서비스 세트(Basic Service Set, BSS) 모드의 WLAN은 BSS에 대한 액세스 포인트(AP) 및 AP와 연관된 하나 이상의 스테이션(STA)을 가질 수 있다. AP는 BSS로 그리고/또는 BSS로부터 트래픽을 운반하는 분배 시스템(Distribution System, DS) 또는 또 다른 유형의 유선/무선 네트워크에 대한 액세스 또는 인터페이스를 가질 수 있다. BSS 외부로부터 비롯되는 STA들로의 트래픽은 AP를 통해 도착할 수 있고 STA들에 전달될 수 있다. STA들로부터 비롯되어 BSS 외부의 목적지들로의 트래픽은 각각의 목적지들로 전달되도록 AP에 송신될 수 있다. BSS 내의 STA들 간의 트래픽은 AP를 통해 송신될 수 있는데, 예를 들어, 소스(source) STA는 트래픽을 AP에 송신할 수 있고, AP는 트래픽을 목적지 STA에 전달할 수 있다. BSS 내의 STA들 사이의 트래픽은 피어-투-피어 트래픽(peer-to-peer traffic)으로 간주되고 그리고/또는 지칭될 수 있다. 피어-투-피어 트래픽은 직접 링크 셋업(direct link setup, DLS)을 사용하여 소스 STA와 목적지 STA 사이에서 (예컨대, 그들 사이에서 직접) 송신될 수 있다. 특정 대표적 실시예들에서, DLS는 802.11e DLS 또는 802.11z TDLS(tunneled DLS)를 사용할 수 있다. IBSS(Independent BSS) 모드를 사용하는 WLAN은 AP를 갖지 않을 수 있고, IBSS 내의 또는 IBSS를 사용하는 STA들(예컨대, 모든 STA들)은 서로 직접 통신할 수 있다. IBSS 통신 모드는 때때로 본 명세서에서 "애드혹(ad-hoc)" 통신 모드라고 지칭될 수 있다.
802.11ac 인프라구조 동작 모드 또는 유사한 동작 모드를 사용할 때, AP는 주 채널과 같은 고정 채널 상에서 비콘(beacon)을 송신할 수 있다. 주 채널은 고정된 폭(예컨대, 20 ㎒ 폭의 대역폭) 또는 동적 설정 폭일 수 있다. 주 채널은 BSS의 동작 채널일 수 있으며, STA들에 의해 AP와의 접속을 확립하기 위해 사용될 수 있다. 특정 대표적 실시예들에서, CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance)가 예를 들어, 802.11 시스템들에서 구현될 수 있다. CSMA/CA의 경우, AP를 포함하는 STA들(예컨대, 모든 STA)은 주 채널을 감지할 수 있다. 주 채널이 특정 STA에 의해 사용 중인 것으로 감지/검출 및/또는 결정되면, 특정 STA는 백오프될 수 있다. 하나의 STA가(예컨대, 하나의 스테이션만이) 주어진 BSS에서 임의의 주어진 시간에 송신할 수 있다.
고처리량(High Throughput, HT) STA들은, 예를 들어 40 ㎒ 폭의 채널을 형성하기 위해 인접하거나 인접하지 않은 20 ㎒ 채널과 주 20 ㎒ 채널의 조합을 통해, 통신을 위한 40 ㎒ 폭의 채널을 사용할 수 있다.
초고처리량(Very High Throughput, VHT) STA들은 20 ㎒, 40 ㎒, 80 ㎒ 및/또는 160 ㎒ 폭의 채널들을 지원할 수 있다. 40 ㎒ 및/또는 80 ㎒ 채널들은 인접한 20 ㎒ 채널들을 조합함으로써 형성될 수 있다. 160 ㎒ 채널은 8개의 인접한 20 ㎒ 채널들을 조합함으로써, 또는 80+80 구성으로 지칭될 수 있는 2개의 비-인접한 80 ㎒ 채널을 조합함으로써 형성될 수 있다. 80+80 구성의 경우, 데이터는 채널 인코딩 후에 데이터를 2개의 스트림으로 분할할 수 있는 세그먼트 파서(segment parser)를 통해 전달될 수 있다. IFFT(Inverse Fast Fourier Transform) 프로세싱 및 시간 도메인 프로세싱이 각각의 스트림에 대해 개별적으로 행해질 수 있다. 스트림들은 2개의 80 ㎒ 채널에 맵핑될 수 있고, 데이터는 송신 STA에 의해 송신될 수 있다. 수신용 STA의 수신기에서, 80+80 구성에 대한 전술된 동작이 반전될 수 있고, 조합된 데이터는 매체 액세스 제어(Medium Access Control, MAC)로 전송될 수 있다.
802.11af 및 802.11ah에 의해 서브(sub) 1 ㎓ 동작 모드가 지원된다. 채널 동작 대역폭들 및 반송파들은 802.11n 및 802.11ac에서 사용되는 것들에 비해 802.11af 및 802.11ah에서 감소된다. 802.11af는 TV 백색 공간(TV White Space, TVWS) 스펙트럼에서 5 ㎒, 10 ㎒ 및 20 ㎒ 대역폭들을 지원하고, 802.11ah는 비-TVWS 스펙트럼을 사용하는 1 ㎒, 2 ㎒, 4 ㎒, 8 ㎒ 및 16 ㎒ 대역폭들을 지원한다. 대표적 실시예에 따르면, 802.11ah는 매크로 커버리지 영역 내의 MTC 디바이스들과 같은 미터 유형 제어/기계 유형 통신(Meter Type Control/Machine-Type Communications, MTC)을 지원할 수 있다. MTC 디바이스들은 특정 능력들 예를 들어, 특정의 그리고/또는 제한된 대역폭들에 대한 지원(예컨대, 그것들만의 지원)을 포함하는 제한된 능력들을 가질 수 있다. MTC 디바이스들은 (예컨대, 매우 긴 배터리 수명을 유지하기 위해) 임계치를 초과하는 배터리 수명을 갖는 배터리를 포함할 수 있다.
802.11n, 802.11ac, 802.11af 및 802.11ah와 같은 다수의 채널 및 채널 대역폭을 지원할 수 있는 WLAN 시스템들은 주 채널로서 지정될 수 있는 채널을 포함한다. 주 채널은 BSS 내의 모든 STA들에 의해 지원되는 가장 큰 공통 동작 대역폭과 동일한 대역폭을 가질 수 있다. 주 채널의 대역폭은 BSS에서 동작하는 모든 STA들 중에서 가장 작은 대역폭 동작 모드를 지원하는 STA에 의해 설정되고 그리고/또는 제한될 수 있다. 802.11ah의 예에서, 주 채널은 AP 및 BSS 내의 다른 STA들이 2 ㎒, 4 ㎒, 8 ㎒, 16 ㎒ 및/또는 다른 채널 대역폭 동작 모드들을 지원하더라도 1 ㎒ 모드를 지원하는(예컨대, 그것만을 지원하는) STA들(예컨대, MTC 유형 디바이스들)에 대해 1 ㎒ 폭일 수 있다. 반송파 감지 및/또는 네트워크 할당 벡터(Network Allocation Vector, NAV) 설정들은 주 채널의 상태에 의존할 수 있다. 주 채널이, 예를 들어, STA(이는, 1 ㎒ 동작 모드만을 지원함)의 AP로의 송신으로 인해 사용 중인 경우, 모든 이용가능 주파수 대역들은 이용가능 주파수 대역들의 대부분이 유휴 상태로 유지되더라도 사용 중인 것으로 간주될 수 있다.
미국에서, 802.11ah에 의해 사용될 수 있는 이용가능 주파수 대역들은 902 ㎒ 내지 928 ㎒이다. 한국에서, 이용가능 주파수 대역들은 917.5 ㎒ 내지 923.5 ㎒이다. 일본에서, 이용가능 주파수 대역들은 916.5 ㎒ 내지 927.5 ㎒이다. 802.11ah에 대해 이용가능한 총 대역폭은 국가 코드에 따라 6 ㎒ 내지 26 ㎒이다.
도 1d는 실시예에 따른 RAN(104) 및 CN(106)을 예시하는 시스템도이다. 상기에서 언급된 바와 같이, RAN(104)은 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c)과 통신하기 위해 NR 무선 기술을 채용할 수 있다. RAN(104)은 또한 CN(106)과 통신할 수 있다.
RAN(104)은 gNB들(180a, 180b, 180c)을 포함할 수 있지만, RAN(104)은 실시예와 여전히 부합하면서 임의의 수의 gNB들을 포함할 수도 있다는 것이 이해될 것이다. gNB들(180a, 180b, 180c) 각각은 에어 인터페이스(116)를 통해 WTRU들(102a, 102b, 102c)과 통신하기 위한 하나 이상의 송수신기를 포함할 수 있다. 일 실시예에서, gNB들(180a, 180b, 180c)은 MIMO 기술을 구현할 수 있다. 예를 들어, gNB들(180a, 180b)은 gNB들(180a, 180b, 180c)로 신호들을 송신하고, 그리고/또는 그들로부터 신호들을 수신하기 위해 빔포밍을 활용할 수 있다. 따라서, gNB(180a)는 예를 들어, WTRU(102a)에 무선 신호들을 송신하고 그리고/또는 그로부터 무선 신호들을 수신하기 위해 다수의 안테나를 사용할 수 있다. 실시예에서, gNB들(180a, 180b, 180c)은 반송파 집성 기술을 구현할 수 있다. 예를 들어, gNB(180a)는 다수의 컴포넌트 반송파를 WTRU(102a)에 송신할 수 있다(도시되지 않음). 이러한 컴포넌트 반송파들의 서브세트는 무면허 스펙트럼 상에 있을 수 있는 반면, 나머지 컴포넌트 반송파들은 면허 스펙트럼 상에 있을 수 있다. 실시예에서, gNB들(180a, 180b, 180c)은 CoMP(Coordinated Multi-Point) 기술을 구현할 수 있다. 예를 들어, WTRU(102a)는 gNB(180a) 및 gNB(180b)(및/또는 gNB(180c))로부터 조정된 송신물들을 수신할 수 있다.
WTRU들(102a, 102b, 102c)은 확장가능 뉴머롤로지(scalable numerology)와 연관된 송신들을 사용하여 gNB들(180a, 180b, 180c)과 통신할 수 있다. 예를 들어, OFDM 심볼 간격 및/또는 OFDM 부반송파 간격은 상이한 송신들, 상이한 셀들, 및/또는 무선 송신 스펙트럼의 상이한 부분들에 대해 변할 수 있다. WTRU들(102a, 102b, 102c)은 (예컨대, 변하는 수의 OFDM 심볼들 및/또는 지속적인(lasting) 변하는 절대 시간 길이들을 포함하는) 다양한 또는 확장가능 길이들의 서브프레임 또는 송신 시간 간격(transmission time interval, TTI)들을 사용하여 gNB들(180a, 180b, 180c)과 통신할 수 있다.
gNB들(180a, 180b, 180c)은 독립형 구성 및/또는 비독립형 구성에서 WTRU들(102a, 102b, 102c)과 통신하도록 구성될 수 있다. 독립형 구성에서, WTRU들(102a, 102b, 102c)은 (예컨대, eNodeB들(160a, 160b, 160c)과 같은) 다른 RAN들에 또한 액세스하지 않고 gNB들(180a, 180b, 180c)과 통신할 수 있다. 독립형 구성에서, WTRU들(102a, 102b, 102c)은 이동성 앵커 포인트로서 gNB들(180a, 180b, 180c) 중 하나 이상을 이용할 수 있다. 독립형 구성에서, WTRU들(102a, 102b, 102c)은 무면허 대역 내의 신호들을 사용하여 gNB들(180a, 180b, 180c)과 통신할 수 있다. 비독립형 구성에서, WTRU들(102a, 102b, 102c)은 예를 들어, eNode-B들(160a, 160b, 160c)과 같은 또 다른 RAN과 또한 통신하면서/그에 접속하면서 gNB들(180a, 180b, 180c)과 통신하면서/그에 접속할 수 있다. 예를 들어, WTRU들(102a, 102b, 102c)은 하나 이상의 gNB(180a, 180b, 180c) 및 하나 이상의 eNode-B(160a, 160b, 160c)와 실질적으로 동시에 통신하기 위해 DC 원리들을 구현할 수 있다. 비독립형 구성에서, eNode-B들(160a, 160b, 160c)은 WTRU들(102a, 102b, 102c)에 대한 이동성 앵커로서 역할을 할 수 있고, gNB들(180a, 180b, 180c)은 WTRU들(102a, 102b, 102c)을 서비스하기 위한 추가적인 커버리지 및/또는 처리량을 제공할 수 있다.
gNB들(180a, 180b, 180c) 각각은 특정의 셀(도시되지 않음)과 연관될 수 있고, 무선 자원 관리 결정들, 핸드오버 결정들, UL 및/또는 DL에서의 사용자들의 스케줄링, 네트워크 슬라이싱의 지원, DC, NR과 E-UTRA 사이의 연동, 사용자 평면 데이터의 사용자 평면 기능(User Plane Function, UPF)(184a, 184b)으로의 라우팅, 제어 평면 정보의 액세스 및 이동성 관리 기능(Access and Mobility Management Function, AMF)(182a, 182b)으로의 라우팅 등을 핸들링하도록 구성될 수 있다. 도 1d에 도시된 바와 같이, gNB들(180a, 180b, 180c)은 Xn 인터페이스를 통해 서로 통신할 수 있다.
도 1d에 도시된 CN(106)은 적어도 하나의 AMF(182a, 182b), 적어도 하나의 UPF(184a, 184b), 적어도 하나의 세션 관리 기능(Session Management Function, SMF)(183a, 183b), 및 가능하게는 데이터 네트워크(Data Network, DN)(185a, 185b)를 포함할 수 있다. 전술한 요소들이 CN(106)의 일부로서 묘사되지만, 이들 요소들 중 임의의 것이 CN 운영자 이외의 엔티티에 의해 소유되고/되거나 운영될 수 있다는 것이 이해될 것이다.
AMF(182a, 182b)는 N2 인터페이스를 통해 RAN(104) 내의 gNB들(180a, 180b, 180c) 중 하나 이상에 접속될 수 있고, 제어 노드로서 역할을 할 수 있다. 예를 들어, AMF(182a, 182b)는 WTRU들(102a, 102b, 102c)의 사용자들의 인증, 네트워크 슬라이싱(예컨대, 상이한 요건들을 갖는 상이한 프로토콜 데이터 유닛(protocol data unit, PDU) 세션들의 핸들링)에 대한 지원, 특정의 SMF(183a, 183b)의 선택, 등록 영역의 관리, 비액세스 층(non-access stratum, NAS) 시그널링의 종료, 이동성 관리 등을 담당할 수 있다. 네트워크 슬라이싱은 WTRU들(102a, 102b, 102c)에 의해 이용되는 서비스들의 유형들에 기초하여 WTRU들(102a, 102b, 102c)에 대한 CN 지원을 맞춤화하기 위해 AMF(182a, 182b)에 의해 사용될 수 있다. 예를 들어, URLLC(ultra-reliable low latency) 액세스에 의존하는 서비스들, eMBB(enhanced massive mobile broadband) 액세스에 의존하는 서비스들, MTC 액세스에 대한 서비스들 등과 같은 상이한 사용 사례들에 대해 상이한 네트워크 슬라이스들이 확립될 수 있다. AMF(182a, 182b)는 RAN(104)과, 예를 들어, LTE, LTE-A, LTE-A Pro 및/또는 예를 들어, WiFi와 같은 비-3GPP 액세스 기술들과 같은 다른 무선 기술들을 사용하는 다른 RAN들(도시되지 않음) 사이에서 스위칭하기 위한 제어 평면 기능을 제공할 수 있다.
SMF(183a, 183b)는 N11 인터페이스를 통해 CN(106) 내의 AMF(182a, 182b)에 접속될 수 있다. SMF(183a, 183b)는 또한 N4 인터페이스를 통해 CN(106) 내의 UPF(184a, 184b)에 접속될 수 있다. SMF(183a, 183b)는 UPF(184a, 184b)를 선택 및 제어하고, UPF(184a, 184b)를 통한 트래픽의 라우팅을 구성할 수 있다. SMF(183a, 183b)는 UE IP 주소를 관리하고 할당하는 것, PDU 세션들을 관리하는 것, 정책 시행 및 QoS를 제어하는 것, DL 데이터 통지들을 제공하는 것 등과 같은 다른 기능들을 수행할 수 있다. PDU 세션 유형은 IP 기반, 비-IP 기반, 이더넷 기반 등일 수 있다.
UPF(184a, 184b)는 WTRU들(102a, 102b, 102c)과 IP 인에이블드 디바이스들 사이의 통신을 용이하게 하기 위해, 인터넷(110)과 같은 패킷 교환 네트워크들에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수 있는 N3 인터페이스를 통해 RAN(104) 내의 gNB들(180a, 180b, 180c) 중 하나 이상에 접속될 수 있다. UPF(184, 184b)는 패킷들을 라우팅 및 포워딩하는 것, 사용자 평면 정책들을 시행하는 것, 멀티-홈 PDU 세션들을 지원하는 것, 사용자 평면 QoS를 핸들링하는 것, DL 패킷들을 버퍼링하는 것, 이동성 앵커링을 제공하는 것 등과 같은 다른 기능들을 수행할 수 있다.
CN(106)은 다른 네트워크들과의 통신을 용이하게 할 수 있다. 예를 들어, CN(106)은, CN(106)과 PSTN(108) 사이의 인터페이스로서 역할을 하는 IP 게이트웨이(예컨대, IP 멀티미디어 서브시스템(IMS) 서버)를 포함할 수 있거나, 또는 그와 통신할 수 있다. 추가로, CN(106)은 다른 서비스 제공자들에 의해 소유되고 그리고/또는 운영되는 다른 유선 및/또는 무선 네트워크들을 포함할 수 있는 다른 네트워크들(112)에 대한 액세스를 WTRU들(102a, 102b, 102c)에 제공할 수 있다. 일 실시예에서, WTRU들(102a, 102b, 102c)은 UPF(184a, 184b)에 대한 N3 인터페이스 및 UPF(184a, 184b)와 DN(185a, 185b) 사이의 N6 인터페이스를 경유해 UPF(184a, 184b)를 통해 로컬 DN(185a, 185b)에 접속될 수 있다.
도 1a 내지 도 1d, 및 도 1a 내지 도 1d의 대응하는 설명의 관점에서, WTRU(102a 내지 102d), 기지국(114a, 114b), eNode-B(160a 내지 160c), MME(162), SGW(164), PGW(166), gNB(180a 내지 180c), AMF(182a, 182b), UPF(184a, 184b), SMF(183a, 183b), DN(185a, 185b) 및/또는 본 명세서에 설명된 임의의 다른 디바이스(들) 중 하나 이상과 관련하여 본 명세서에 설명된 기능들 중 하나 이상 또는 전부는 하나 이상의 에뮬레이션 디바이스(emulation device)들(도시되지 않음)에 의해 수행될 수 있다. 에뮬레이션 디바이스들은 본 명세서에 설명된 기능들 중 하나 이상 또는 전부를 에뮬레이션하도록 구성된 하나 이상의 디바이스일 수 있다. 예를 들어, 에뮬레이션 디바이스들은 다른 디바이스들을 테스트하고 그리고/또는 네트워크 및/또는 WTRU 기능들을 시뮬레이션하기 위해 사용될 수 있다.
에뮬레이션 디바이스들은 실험실 환경 및/또는 운영자 네트워크 환경에서 다른 디바이스들의 하나 이상의 테스트를 구현하도록 설계될 수 있다. 예를 들어, 하나 이상의 에뮬레이션 디바이스는 통신 네트워크 내의 다른 디바이스들을 테스트하기 위해 유선 및/또는 무선 통신 네트워크의 일부로서 완전히 또는 부분적으로 구현되고 그리고/또는 배치되면서 하나 이상의 또는 모든 기능들을 수행할 수 있다. 하나 이상의 에뮬레이션 디바이스는 유선 및/또는 무선 통신 네트워크의 일부로서 일시적으로 구현/배치되면서 하나 이상의 또는 모든 기능들을 수행할 수 있다. 에뮬레이션 디바이스는 테스트를 위해 그리고/또는 OTA(over-the-air) 무선 통신을 사용하여 테스트를 수행하기 위해 또 다른 디바이스에 직접 결합될 수 있다.
하나 이상의 에뮬레이션 디바이스는 유선 및/또는 무선 통신 네트워크의 일부로서 구현/배치되지 않으면서 모든 기능들을 포함하는 하나 이상의 기능을 수행할 수 있다. 예를 들어, 에뮬레이션 디바이스들은 하나 이상의 컴포넌트의 테스트를 구현하기 위해 테스트 실험실 및/또는 배치되지 않은(예컨대, 테스트) 유선 및/또는 무선 통신 네트워크에서의 테스트 시나리오에서 이용될 수 있다. 하나 이상의 에뮬레이션 디바이스는 테스트 장비일 수 있다. RF 회로부(예컨대, 이는 하나 이상의 안테나를 포함할 수 있음)를 통한 직접 RF 결합 및/또는 무선 통신이 데이터를 송신하고 그리고/또는 수신하기 위해 에뮬레이션 디바이스들에 의해 사용될 수 있다.
본 출원에서 기술된 다양한 방법들 및 다른 태양들은, 예를 들어, 도 2 및 도 3에 도시된 바와 같은 비디오 인코더(200) 및 디코더(300)의 모듈들을 수정하는 데 사용될 수 있다. 더욱이, 본 명세서에 개시된 주제는 V3C, G-PCC로 제한되지 않는 태양들을 제시하고, 표준으로 설명되든 또는 권고사항으로 설명되든, 기존에 있든 또는 미래에 개발되든, 예를 들어, 임의의 유형, 포맷 또는 버전의 비디오 코딩에, 그리고 (예컨대, V3C 및 G-PCC를 포함한) 임의의 그러한 표준들 및 권고사항들의 확장들에 적용될 수 있다. 달리 나타내지 않거나 기술적으로 배제되지 않는 한, 본 출원에 기술된 태양들은 개별적으로 또는 조합하여 사용될 수 있다.
V3C 애플리케이션 메시지 또는 G-PCC 애플리케이션 메시지의 필드들에 대해 예약된 비트들의 수와 같은, 다양한 수치 값들이 본 출원을 기술한 예들에서 사용된다. 이들 및 다른 특정 값들은 예들을 설명하기 위한 것이고, 기술된 태양들은 이들 특정 값들로 제한되지 않는다.
도 2는 비디오 인코더의 일례를 예시하는 도면이다. 예시적인 인코더(200)의 변형들이 고려되지만, 인코더(200)는 모든 예상되는 변형들을 기술하지 않고서 명확성을 위해 하기에 기술된다,
인코딩되기 전에, 비디오 시퀀스는, 예를 들어, 입력 컬러 픽처에 컬러 변환을 적용하거나(예를 들어, RGB 4:4:4로부터 YCbCr 4:2:0으로의 변환), 또는 (예를 들어, 컬러 성분들 중 하나의 성분의 히스토그램 등화를 사용하여) 압축에 더 탄력적인 신호 분포를 얻기 위해 입력 픽처 성분들의 재맵핑(remapping)을 수행하는, 사전 인코딩 프로세싱(201)을 거칠 수 있다. 메타데이터가 사전-프로세싱과 연관될 수 있고, 그러한 메타데이터는 비트스트림에 첨부될 수 있다.
인코더(200)에서, 픽처는 후술되는 바와 같이 인코더 요소들에 의해 인코딩될 수 있다. 인코딩될 픽처가 파티셔닝되고(202), 예를 들어, 코딩 유닛(CU)들의 유닛으로 프로세싱될 수 있다. 각각의 유닛은, 예를 들어, 인트라 또는 인터 모드 중 어느 하나를 사용하여 인코딩될 수 있다. 유닛이 인트라 모드에서 인코딩될 때, 그것은 인트라 예측(260)을 수행하고, 인터 모드에서는, 모션 추정(275) 및 보상(270)이 수행된다. 인코더는 유닛을 인코딩하기 위해 인트라 모드 또는 인터 모드 중 어느 것을 사용할지를 결정할 수 있고(205), 예를 들어, 예측 모드 플래그에 의해 인트라/인터 결정을 나타낸다. 예측 잔차들은, 예를 들어, 오리지널 이미지 블록에서 예측된 블록을 감산함으로써(210) 계산될 수 있다.
이어서, 예측 잔차들은 변환되고(225) 양자화될 수 있다(230). 양자화된 변환 계수들뿐만 아니라 모션 벡터들 및 다른 신택스 요소들은 엔트로피 코딩되어(245) 비트스트림을 출력할 수 있다. 인코더는 변환을 스킵하고, 변환되지 않은 잔차 신호에 직접 양자화를 적용할 수 있다. 인코더는 변환 및 양자화 모두를 스킵할 수 있으며, 즉, 잔차는 변환 또는 양자화 프로세스들의 적용 없이 직접 코딩된다.
인코더는 인코딩된 블록을 디코딩하여 추가 예측들을 위한 기준을 제공한다. 양자화된 변환 계수들은 예측 잔차들을 디코딩하기 위해 역양자화되고(240) 역변환된다(250). 디코딩된 예측 잔차들 및 예측된 블록을 조합하여(255), 이미지 블록이 재구성된다. 인-루프 필터들(265)이 재구성된 픽처에 적용되어, 예를 들어, 인코딩 아티팩트들을 감소시키기 위한 디블록킹/SAO(Sample Adaptive Offset) 필터링을 수행한다. 필터링된 이미지는 기준 픽처 버퍼(280)에 저장된다.
도 3은 비디오 디코더의 일례를 도시하는 도면이다. 예시적인 디코더(300)에서, 비트스트림은 후술되는 바와 같이 디코더 요소들에 의해 디코딩된다. 비디오 디코더(300)는 대체적으로 도 2에 설명된 바와 같은 인코딩 과정과 상반되는 디코딩 과정을 수행한다. 인코더(200)는 또한 대체적으로 비디오 데이터를 인코딩하는 것의 일부로서 비디오 디코딩을 수행한다. 특히, 디코더의 입력은 비디오 인코더(200)에 의해 생성될 수 있는 비디오 비트스트림을 포함할 수 있다. 비트스트림은 먼저 엔트로피 디코딩되어(330), 변환 계수들, 모션 벡터들, 및 다른 코딩된 정보를 획득할 수 있다. 픽처 파티션 정보는, 픽처가 어떻게 파티셔닝되는지를 나타내고, 따라서 디코더는 디코딩된 픽처 파티셔닝 정보에 따라 픽처를 분할할 수 있다(335). 변환 계수들은 예측 잔차들을 디코딩하기 위해 역양자화되고(340) 역변환된다(350). 디코딩된 예측 잔차들 및 예측된 블록을 조합하여(355), 이미지 블록이 재구성되고, 예측된 블록은 인트라 예측(360) 또는 모션 보상형 예측(즉, 인터 예측)(375)으로부터 획득될 수 있다(370). 재구성된 이미지에 인루프 필터들(365)이 적용된다. 필터링된 이미지는 기준 픽처 버퍼(380)에 저장된다.
디코딩된 픽처는 사후 디코딩 프로세싱(385), 예를 들어, 역 컬러 변환(예컨대, YCbCr 4:2:0으로부터 RGB 4: :4로의 변환) 또는 사전 인코딩 프로세싱(201)에서 수행된 재맵핑 프로세스의 역을 수행하는 역 재맵핑을 추가로 거칠 수 있다. 사후 디코딩 프로세싱은, 사전 인코딩 프로세싱에서 도출되고 비트스트림에서 시그널링된 메타데이터를 사용할 수 있다.
도 4는 본 명세서에 기술된 다양한 태양들 및 실시예들이 구현될 수 있는 시스템의 일례를 도시하는 도면이다. 시스템(400)은 후술되는 다양한 컴포넌트들을 포함하는 디바이스로서 구현될 수 있고, 본 문헌에 기술된 태양들 중 하나 이상을 수행하도록 구성된다. 그러한 디바이스들의 예들은 개인용 컴퓨터들, 랩톱 컴퓨터들, 스마트폰들, 태블릿 컴퓨터들, 디지털 멀티미디어 셋톱 박스들, 디지털 텔레비전 수신기들, 개인용 비디오 레코딩 시스템들, 접속형 가정용 전자기기들, 및 서버들과 같은 다양한 전자 디바이스들을 포함하지만, 이로 제한되지 않는다. 시스템(400)의 요소들은, 단독으로 또는 조합하여, 단일 집적 회로(IG), 다수의 IC들, 및/또는 별개의 컴포넌트들에서 구현될 수 있다. 예를 들어, 적어도 하나의 예에서, 시스템(400)의 프로세싱 및 인코더/디코더 요소들은 다수의 IC들 및/또는 별개의 컴포넌트들에 걸쳐 분포되고, 다양한 실시예들에서, 시스템(400)은, 예를 들어, 통신 버스를 통해 또는 전용 입력 및/또는 출력 포트들을 통해 하나 이상의 다른 시스템들, 또는 다른 전자 디바이스들에 통신가능하게 결합된다. 다양한 실시예들에서, 시스템(400)은 본 문헌에 기술된 태양들 중 하나 이상을 구현하도록 구성된다.
시스템(400)은, 예를 들어, 본 문헌에 설명된 다양한 태양들을 구현하기 위해 내부에 로딩된 명령어들을 실행하도록 구성된 적어도 하나의 프로세서(410)를 포함하고, 프로세서(410)는 임베디드 메모리, 입력 출력 인터페이스, 및 당업계에 알려진 바와 같은 다양한 다른 회로부들을 포함할 수 있다. 시스템(400)은 적어도 하나의 메모리(420)(예컨대, 휘발성 메모리 디바이스, 및/또는 비휘발성 메모리 디바이스)를 포함한다. 시스템(400)은 저장 디바이스(440)를 포함하며, 이는 전기적으로 소거가능한 프로그래밍가능 판독 전용 메모리(EEPROM)를 포함하지만, 이로 제한되지 않는 비휘발성 메모리 및/또는 휘발성 메모리를 포함할 수 있다. 판독 전용 메모리(ROM), 프로그래밍가능 판독 전용 메모리(PROM), 랜덤 액세스 메모리(RAM), 동적 랜덤 액세스 메모리(DRAM), 정적 랜덤 액세스 메모리(SRAM), 플래시, 자기 디스크 드라이브, 및/또는 광학 디스크 드라이브. 저장 디바이스(440)는 비제한적인 예들로서, 내부 저장 디바이스, 부착된 저장 디바이스(분리가능한 저장 디바이스 및 분리가능하지 않은 저장 디바이스를 포함함), 및/또는 네트워크 액세스가능한 저장 디바이스를 포함할 수 있다.
시스템(400)은, 예를 들어 데이터를 프로세싱하여 인코딩된 비디오 또는 디코딩된 비디오를 제공하도록 구성된 인코더/디코더 모듈(430)을 포함하고, 인코더/디코더 모듈(430)은 그 자신의 프로세서 및 메모리를 포함할 수 있다. 인코더/디코더 모듈(430)은 인코딩 및/또는 디코딩 기능들을 수행하기 위해 디바이스에 포함될 수 있는 모듈(들)을 나타낸다. 알려진 대로, 디바이스는 인코딩 및 디코딩 모듈들 중 하나 또는 둘 모두를 포함할 수 있다. 또한, 인코더/디코더 모듈(430)은 시스템(400)의 별개의 요소로서 구현될 수 있거나, 또는 당업자에게 알려진 바와 같이 하드웨어와 소프트웨어의 조합으로서 프로세서(410) 내에 통합될 수 있다.
본 문헌에 설명된 다양한 태양들을 수행하기 위해 프로세서(410) 또는 인코더/디코더(430)에 로딩될 프로그램 코드는 저장 디바이스(440)에 저장되고 후속적으로, 프로세서(410)에 의한 실행을 위해 메모리(420)에 로딩될 수 있고, 다양한 실시예들에 따라, 프로세서(410), 메모리(420), 저장 디바이스(440), 및 인코더/디코더 모듈(430) 중 하나 이상은 본 문헌에 설명된 프로세스들의 수행 동안 다양한 항목들 중 하나 이상을 저장할 수 있다. 이러한 저장된 항목들은 입력 비디오, 디코딩된 비디오 또는 디코딩된 비디오의 일부들, 비트스트림, 행렬들, 변수들, 및 식들, 공식들, 연산들 및 연산 로직의 프로세싱으로부터의 중간 또는 최종 결과들을 포함할 수 있지만, 이들로 제한되지 않는다.
일부 실시예들에서, 프로세서(410) 및/또는 인코더/디코더 모듈(430) 내부의 메모리는 명령어들을 저장하고, 인코딩 또는 디코딩 동안 필요한 프로세싱을 위한 작업 메모리를 제공하는 데 사용된다. 그러나, 다른 실시예들에서, 프로세싱 디바이스(예를 들어, 프로세싱 디바이스는 프로세서(410) 또는 인코더/디코더 모듈(430) 중 어느 하나일 수 있음) 외부의 메모리가 이러한 기능들 중 하나 이상에 사용된다. 외부 메모리는 메모리(420) 및/또는 저장 디바이스(440), 예를 들어, 동적 휘발성 메모리 및/또는 비휘발성 플래시 메모리일 수 있다. 일부 실시예들에서, 외부 비휘발성 플래시 메모리는 예를 들어, 텔레비전의 운영 체제를 저장하는 데 사용된다. 적어도 하나의 실시예에서, RAM과 같은 고속의 외부 동적 휘발성 메모리는, 예를 들어 MPEG-2와 같은 비디오 코딩 및 디코딩 동작들을 위한 작업 메모리로서 사용된다. MPEG는 동영상 전문가 그룹을 지칭할 수 있고, MPEG-2는 또한 ISO/IEC 13818로서 지칭될 수 있다. ISO/IEC 13818-1은 H.222로도 알려져 있을 수 있고, 13818-2는 H.262, HEVG(HEVC는 H.265 및 MPEG-H 파트 2로도 알려진, High Efficiency Video Coding을 지칭함), 또는 VVC(Versatile Video Coding, JVET(Joint Video Experts Team)에 의해 개발되고 있는 새로운 표준)로도 알려져 있다.
시스템(400)의 요소들에 대한 입력은 블록(445)에 나타낸 바와 같은 다양한 입력 디바이스들을 통해 제공될 수 있다. 그러한 입력 디바이스들은, (i) 예를 들어 브로드캐스터(broadcaster)에 의해 무선으로 송신된 무선 주파수(RF) 신호를 수신하는 RF 부분, (ii) 컴포넌트(COMP) 입력 단자(또는 COMP 입력 단자들의 세트), (iii) 범용 직렬 버스(USB) 입력 단자, 및/또는 (iv) 고화질 멀티미디어 인터페이스(High Definition Multimedia Interface, HDMI) 입력 단자를 포함하지만, 이들로 제한되지 않는다. 도 4에 도시되지 않은 다른 예들은 복합 비디오(composite video)를 포함할 수 있다.
다양한 실시예들에서, 블록(445)의 입력 디바이스들은 당업계에 알려진 바와 같은 연관된 각자의 입력 프로세싱 요소들을 가질 수 있다. 예를 들어, RF 부분은, (i) 원하는 주파수를 선택하는 것(신호를 선택하는 것, 또는 신호를 주파수들의 대역으로 대역-제한하는 것으로도 지칭됨), (ii) 선택된 신호를 하향 변환(downconvert)하는 것, (iii) (예를 들어) 소정 실시예들에서 채널로 지칭될 수 있는 신호 주파수 대역을 선택하기 위해 주파수들의 더 좁은 대역으로 다시 대역-제한하는 것, (iv) 하향 변환되고 대역-제한된 신호를 복조하는 것, (v) 오류 정정을 수행하는 것, 및 (vi) 데이터 패킷들의 원하는 스트림을 선택하기 위해 역다중화하는 것에 적합한 요소들과 연관될 수 있다. 다양한 실시예들의 RF 부분은 이들 기능들을 수행하기 위한 하나 이상의 요소들, 예를 들어, 주파수 선택기들, 신호 선택기들, 대역 제한기들, 채널 선택기들, 필터들, 하향변환기들, 복조기들, 오류 정정기들, 및 역다중화기들을 포함한다. RF 부분은, 예를 들어, 수신된 신호를 더 낮은 주파수(예를 들어, 중간 주파수 또는 기저대역 근접 주파수)로 또는 기저대역으로 하향 변환하는 것을 포함하는 이들 기능들 중 다양한 것을 수행하는 튜너를 포함할 수 있고, 하나의 셋톱 박스 실시예에서, RF 부분 및 그의 연관된 입력 프로세싱 요소는 유선(예를 들어, 케이블) 매체를 통해 송신된 RF 신호를 수신하고, 필터링, 하향 변환, 및 원하는 주파수 대역으로 다시 필터링함으로써 주파수 선택을 수행한다. 다양한 실시예들은 전술된(및 다른) 요소들의 순서를 재배열하고, 이들 요소들 중 일부를 제거하고, 그리고/또는 유사한 또는 상이한 기능들을 수행하는 다른 요소들을 추가할 수 있다. 요소들을 추가하는 것은, 예를 들어, 증폭기들 및 아날로그-디지털 변환기를 삽입하는 것과 같이, 기존 요소들 사이에 요소들을 삽입하는 것을 포함할 수 있고, 다양한 실시예들에서, RF 부분은 안테나를 포함한다.
추가적으로, USB 및/또는 HDMI 단자들은 USB 및/또는 HDMI 접속들을 통해 시스템(400)을 다른 전자 디바이스들에 접속하기 위한 각자의 인터페이스 프로세서들을 포함할 수 있고, 입력 프로세싱의 다양한 태양들, 예를 들어, 리드 솔로몬(Reed-Solomon) 오류 정정이, 예를 들어, 필요에 따라 별개의 입력 프로세싱(1C) 내에서 또는 프로세서(410) 내에서 구현될 수 있다는 것이 이해되어야 한다. 유사하게, USB 또는 HDMI 인터페이스 프로세싱의 태양들이, 필요에 따라, 별개의 인터페이스 IC들 내에서 또는 프로세서(410) 내에서 구현될 수 있다. 복조된, 오류 정정된, 그리고 역다중화된 스트림은, 예를 들어, 출력 디바이스 상에서의 프리젠테이션을 위해 필요에 따라 데이터 스트림을 프로세싱하도록 메모리 및 저장 요소들과 조합하여 동작하는 프로세서(410), 및 인코더/디코더(430)를 포함한 다양한 프로세싱 요소들에 제공된다.
시스템(400)의 다양한 요소들이 통합된 하우징 내에 제공될 수 있다. 통합된 하우징 내에서, 다양한 요소들은 적합한 접속 배열(425), 예를 들어, 인터-IC(I2C) 버스, 배선, 및 인쇄 회로 기판들을 포함하는, 당업계에 알려진 바와 같은 내부 버스를 사용하여 상호접속되고 그들 사이에서 데이터를 전송할 수 있다.
시스템(400)은 통신 채널(460)을 통해 다른 디바이스들과의 통신을 가능하게 하는 통신 인터페이스(450)를 포함한다. 통신 인터페이스(450)는 통신 채널(460)을 통해 데이터를 송신하도록 그리고 이를 수신하도록 구성된 송수신기를 포함할 수 있지만 이로 제한되지 않는다. 통신 인터페이스(450)는 모뎀 또는 네트워크 카드를 포함할 수 있지만 이에 제한되지 않으며, 통신 채널(460)은, 예를 들어, 유선 및/또는 무선 매체 내에서 구현될 수 있다.
데이터는, 다양한 실시예들에서, Wi-Fi 네트워크, 예를 들어, IEEE 802.11(IEEE는 전기 전자 기술자 협회(Institute of Electrical and Electronics Engineers)를 지칭함)과 같은 무선 네트워크를 사용하여, 시스템(400)에 스트리밍되거나 또는 달리 제공될 수 있다. 이들 실시예들의 Wi-Fi 신호는 Wi-Fi 통신들에 대해 적응된 통신 채널(460) 및 통신 인터페이스(450)를 통해 수신된다. 이들 실시예들의 통신 채널(460)은 전형적으로, 스트리밍 응용들 및 다른 오버-더-탑 통신을 허용하기 위한 인터넷을 포함하는 외부 네트워크들에 대한 액세스를 제공하는 액세스 포인트 또는 라우터에 접속된다. 다른 실시예들은 입력 블록(445)의 HDMI 접속을 통해 데이터를 전달하는 셋톱 박스를 사용하여 스트리밍된 데이터를 시스템(400)에 제공한다. 또 다른 실시예들은 입력 블록(445)의 RF 접속을 사용하여 시스템(400)에 스트리밍된 데이터를 제공한다. 상기에 나타낸 바와 같이, 다양한 실시예들은 비-스트리밍 방식으로 데이터를 제공한다. 또한, 다양한 실시예들은 Wi-Fi 이외의 무선 네트워크들, 예를 들어, 셀룰러 네트워크 또는 블루투스 네트워크를 사용할 수 있다.
시스템(400)은 디스플레이(475), 스피커들(485), 및 다른 주변 디바이스들(495)을 포함하는 다양한 출력 디바이스들에 출력 신호를 제공할 수 있다. 다양한 실시예들의 디스플레이(475)는, 예를 들어, 터치스크린 디스플레이, 유기 발광 다이오드(OLED) 디스플레이, 곡선형 디스플레이, 및/또는 폴더블 디스플레이(foldable display) 중 하나 이상을 포함한다. 디스플레이(475)는 텔레비전, 태블릿, 랩톱, 휴대폰(모바일 폰), 또는 다른 디바이스에 대한 것일 수 있다. 디스플레이(475)는 또한 (예를 들어, 스마트폰에서와 같이) 다른 컴포넌트들과 통합되거나, 또는 분리될 수 있다(예를 들어, 랩톱용 외부 모니터). 다른 주변 디바이스들(495)은, 실시예들의 다양한 예들에서, 독립형 디지털 비디오 디스크(또는 디지털 다목적 디스크)(용어들 둘 모두에 대해 DVR), 디스크 플레이어, 스테레오 시스템, 및/또는 조명 시스템 중 하나 이상을 포함한다. 다양한 실시예들은 시스템(400)의 출력에 기초하여 기능을 제공하는 하나 이상의 주변 디바이스들(495)을 사용한다. 예를 들어, 디스크 플레이어는 시스템(400)의 출력을 재생하는 기능을 수행한다.
다양한 실시예들에서, 제어 신호들은, AV. Link, 소비자 전자제품 제어(Consumer Electronics Control, CEC)와 같은 시그널링, 또는 사용자 개입이 있거나 또는 개입 없이 디바이스 대 디바이스 제어를 가능하게 하는 다른 통신 프로토콜들을 사용하여 시스템(400)과 디스플레이(475), 스피커들(485), 또는 다른 주변 디바이스들(495) 사이에서 통신될 수 있다. 출력 디바이스들은 각자의 인터페이스들(470, 480, 490)을 통한 전용 접속들을 통해 시스템(400)에 통신가능하게 결합될 수 있다. 대안적으로, 출력 디바이스들은 통신 인터페이스(450)를 통해 통신 채널(460)을 사용하여 시스템(400)에 접속될 수 있다. 디스플레이(475) 및 스피커들(485)은, 예를 들어, 텔레비전과 같은 전자 디바이스에서 시스템(400)의 다른 컴포넌트들과 단일 유닛으로 통합될 수 있고, 다양한 실시예들에서, 디스플레이 인터페이스(470)는, 예를 들어, 타이밍 제어기(T Con) 칩과 같은 디스플레이 드라이버를 포함한다.
디스플레이(475) 및 스피커들(485)은 대안적으로, 예를 들어, 입력(445)의 RF 부분이 별개의 셋톱 박스의 일부인 경우, 다른 컴포넌트들 중 하나 이상과 별개일 수 있다. 디스플레이(475) 및 스피커들(485)이 외부 컴포넌트들인 다양한 실시예들에서, 출력 신호는, 예를 들어, HDMI 포트들, USB 포트들, 또는 COMP 출력들을 포함하는 전용 출력 접속들을 통해 제공될 수 있다.
실시예들은 프로세서(410)에 의해 구현되는 컴퓨터 소프트웨어에 의해 또는 하드웨어에 의해, 또는 하드웨어와 소프트웨어의 조합에 의해 수행될 수 있다. 비제한적인 예로서, 실시예들은 하나 이상의 집적 회로들에 의해 구현될 수 있다. 메모리(420)는 기술적 환경에 적절한 임의의 유형의 것일 수 있고, 비제한적인 예들로서, 광학 메모리 디바이스들, 자기 메모리 디바이스들, 반도체 기반 메모리 디바이스들, 고정형 메모리, 및 착탈식 메모리와 같은 임의의 적절한 데이터 저장 기술을 사용하여 구현될 수 있다. 프로세서(410)는 기술적 환경에 적절한 임의의 유형의 것일 수 있고, 비제한적인 예들로서, 마이크로프로세서들, 범용 컴퓨터들, 특수 목적 컴퓨터들, 및 다중 코어 아키텍처에 기초한 프로세서들 중 하나 이상을 포함할 수 있다.
다양한 구현예들이 디코딩을 수반한다. 본 출원에서 사용되는 바와 같이, "디코딩"은, 예를 들어, 디스플레이에 적합한 최종 출력을 생성하기 위해 수신된 인코딩된 시퀀스 상에서 수행되는 프로세스들의 전부 또는 일부를 포괄할 수 있고, 다양한 실시예들에서, 그러한 프로세스들은 디코더에 의해 전형적으로 수행되는 프로세스들, 예를 들어, 엔트로피 디코딩, 역양자화, 역변환, 및 차동 디코딩 중 하나 이상을 포함한다. 다양한 실시예들에서, 그러한 프로세스들은 또한 또는 대안적으로, 코딩된 포인트 클라우드 시퀀스(예컨대, ISOBMFF 컨테이너에 캡슐화됨)에 대한 부분 액세스를 제공하기 위해, 본 출원에 기술된 다양한 구현예들의 디코더에 의해 수행되는 프로세스들, 예를 들어 코딩된 포인트 클라우드 시퀀스(예컨대, 예를 들어 본 명세서에 개시된 바와 같은 하나 이상의 파일 포맷 구조들을 사용하여 ISOBMFF 컨테이너에 캡슐화됨)의 일부분의 디코딩 등을 포함한다.
추가적인 실시예들로서, 일부 예들에서, "디코딩"은 엔트로피 디코딩만을 지칭할 수 있는 한편, 다른 실시예들에서 "디코딩"은 차동 디코딩만을 지칭할 수 있고, 다른 실시예들에서, "디코딩"은 엔트로피 디코딩 및 차동 디코딩의 조합을 지칭할 수 있다. 어구 "디코딩 프로세스"가 동작들의 서브세트를 구체적으로 지칭하기 위한 것인지, 또는 대체적으로 보다 광의의 디코딩 프로세스를 지칭하기 위한 것인지 여부는 특정 설명들의 맥락에 기초하여 명확할 것이며, 당업자에 의해 잘 이해될 것으로 여겨진다.
다양한 구현예들은 인코딩을 수반한다. "디코딩"에 대한 상기 논의와 유사한 방식으로, 본 출원에서 사용되는 바와 같은 "인코딩"은, 예를 들어 입력 비디오 시퀀스에 대해 수행되어 인코딩된 비트스트림을 생성하는 프로세스들의 전부 또는 일부를 포함할 수 있다. 다양한 실시예들에서, 이러한 프로세스들은 전형적으로 인코더에 의해 수행되는 프로세스들, 예를 들어, 파티셔닝, 차동 인코딩, 변환, 양자화, 및 엔트로피 인코딩 중 하나 이상을 포함한다. 다양한 실시예들에서, 그러한 프로세스들은 또한, 또는 대안적으로, 본 출원에 기술된 다양한 구현예들의 인코더에 의해 수행되는 프로세스들, 예를 들어, 코딩된 포인트 클라우드 시퀀스(예컨대, ISOBMFF 컨테이너에 캡슐화됨)의 상이한 부분들에 대한 부분 액세스 지원을 제공하기 위해 하나 이상의 파일 포맷 구조들(예컨대, 본 명세서에 개시된 바와 같음)을 포함하는 비디오 기반 포인트 클라우드 비트스트림의 인코딩 등을 포함한다.
추가적인 예들에서, 하나의 실시예에서, "인코딩"은 단지 엔트로피 인코딩을 지칭하고, 다른 실시예에서 "인코딩"은 단지 차동 인코딩을 지칭하고, 다른 실시예에서 "인코딩"은 차동 인코딩 및 엔트로피 인코딩의 조합을 지칭한다. 어구 "인코딩 프로세스"가 동작들의 서브세트를 구체적으로 나타내기 위한 것인지, 또는 대체적으로 보다 광의의 인코딩 프로세스를 나타내기 위한 것인지 여부는 특정 설명들의 맥락에 기초하여 명확할 것이며, 당업자에 의해 잘 이해될 것으로 여겨진다.
본 명세서에 사용되는 바와 같은 신택스 요소들, 예를 들어 V3CSelectionMessage, V3CAssetGroupMessage, 및 V3CViewChangeFeedbackMessage 등은 설명적인 용어들임에 유의해야 한다. 이와 같이, 이들은 다른 신택스 요소 명칭들의 사용을 배제하지 않는다.
도면이 흐름도로서 제시될 때, 그것은 또한 대응하는 장치의 블록도를 제공한다는 것을 이해해야 한다. 유사하게, 도면이 블록도로서 제시될 때, 그것은 또한 대응하는 방법/프로세스의 흐름도를 제공한다는 것을 이해해야 한다.
본 명세서에 기술된 구현예들 및 태양들은, 예를 들어, 방법 또는 프로세스, 장치, 소프트웨어 프로그램, 데이터 스트림, 또는 신호에서 구현될 수 있다. 구현예의 단일 형태의 맥락에서 논의된다 하더라도(예를 들어, 방법으로서만 논의됨), 논의된 특징들의 구현예는 다른 형태들(예를 들어, 장치 또는 프로그램)에서 구현될 수 있다. 장치는, 예를 들어, 적절한 하드웨어, 소프트웨어, 및 펌웨어로 구현될 수 있다. 방법들은, 대체적으로, 예를 들어, 컴퓨터, 마이크로프로세서, 집적 회로, 또는 프로그래밍가능 로직 디바이스를 포함하는, 예를 들어, 프로세싱 디바이스들을 지칭하는 프로세서에서 구현될 수 있다. 프로세서들은 또한, 예를 들어, 컴퓨터들, 휴대폰들, 휴대용/개인용 디지털 어시스턴트("PDA")들, 및 최종 사용자들 사이의 정보의 통신을 용이하게 하는 다른 디바이스들과 같은 통신 디바이스들을 포함한다.
"하나의 실시예", "일 실시예", "일례", "하나의 구현예" 또는 "일 구현예"뿐만 아니라 그의 다른 변형예들에 대한 언급은, 실시예와 관련하여 설명된 특정 특징, 구조, 특성 등이 적어도 하나의 실시예에 포함된다는 것을 의미한다. 따라서, 어구 "하나의 실시예에서", "일 실시예에서", "일례에서", "하나의 구현예에서", 또는 "일 구현예에서"의 출현뿐만 아니라 본 출원 전체에 걸쳐 다양한 곳들에서 나타나는 임의의 다른 변형예들은 반드시 모두 동일한 실시예 또는 예를 지칭하는 것은 아니다.
추가적으로, 본 출원은 다양한 정보 조각들을 "결정하는 것"을 지칭할 수 있다. 정보를 결정하는 것은, 예를 들어, 정보를 추정하는 것, 정보를 계산하는 것, 정보를 예측하는 것, 또는 메모리로부터 정보를 취출하는 것 중 하나 이상을 포함할 수 있다. 획득하는 것은 수신하는 것, 취출하는 것, 구성하는 것, 생성하는 것, 및/또는 결정하는 것을 포함할 수 있다.
또한, 본 출원은 다양한 정보 조각들에 "액세스하는 것"을 지칭할 수 있다. 정보에 액세스하는 것은, 예를 들어, 정보를 수신하는 것, (예를 들어, 메모리로부터) 정보를 취출하는 것, 정보를 저장하는 것, 정보를 이동하는 것, 정보를 복사하는 것, 정보를 계산하는 것, 정보를 결정하는 것, 정보를 예측하는 것, 또는 정보를 추정하는 것 중 하나 이상을 포함할 수 있다.
또한, 본 출원은 다양한 조각들의 정보를 "수신하는 것"을 지칭할 수 있다. 수신하는 것은, "액세스하는 것"과 마찬가지로, 광의의 용어인 것으로 의도된다. 정보를 수신하는 것은, 예를 들어, 정보에 액세스하는 것, 또는 (예를 들어, 메모리로부터) 정보를 취출하는 것 중 하나 이상을 포함할 수 있다. 또한, "수신하는 것"은 전형적으로, 예를 들어, 정보를 저장하는 것, 정보를 프로세싱하는 것, 정보를 전송하는 것, 정보를 이동하는 것, 정보를 복사하는 것, 정보를 소거하는 것, 정보를 계산하는 것, 정보를 결정하는 것, 정보를 예측하는 것, 또는 정보를 추정하는 것과 같은 동작들 동안 어떤 방식으로든 수반된다.
예를 들어, 다음의 "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)의 선택을 포괄하도록 의도된다. 이는, 본 명세서에 기술된 바와 같은 많은 항목들에 대해, 본 명세서 및 관련 분야의 당업자에게 명백한 바와 같이 확장될 수 있다.
또한, 본 명세서에 사용된 바와 같이, 단어 "신호"는 특히, 대응하는 디코더에게 무언가를 나타내는 것을 지칭한다. 일부 실시예들에서, 인코더는 (예컨대, 인코딩된 비트스트림에서 그리고/또는 ISOBMFF 컨테이너와 같은 캡슐화 파일에서), 예를 들어, 파라미터 세트, SEI 메시지들, 메타데이터, 편집 목록, 사후 디코더 요건들, ISOBMFF 컨테이너에 캡슐화된 코딩된 포인트 클라우드 시퀀스의 상이한 부분들에 대한 유연한 부분 액세스를 가능하게 하는 신호들, 각각의 시그널링된 객체에 대한 의존성 목록, 공간 영역에 대한 맵핑, 3D 경계 박스 정보 등을 시그널링할 수 있다. 이러한 방식으로, 일 실시예에서, 동일한 파라미터가 인코더 측 및 디코더 측 둘 모두에서 사용된다. 따라서, 예를 들어, 인코더는 특정 파라미터를 디코더로 송신(명시적 시그널링)할 수 있어, 디코더가 동일한 특정 파라미터를 사용할 수 있도록 할 수 있다. 반대로, 디코더가 이미 특정 파라미터뿐만 아니라 다른 것들을 갖는 경우, 시그널링은, 단순히 디코더가 특정 파라미터를 알고 선택하게 할 수 있도록, 전송 없이 사용될 수 있다(암시적 시그널링). 임의의 실제 기능들의 송신을 회피함으로써, 다양한 실시예들에서 비트 절약들이 실현되고, 시그널링은 다양한 방식들로 달성될 수 있다는 것이 이해되어야 한다. 예를 들어, 하나 이상의 신택스 요소들, 플래그들 등이 다양한 실시예들에서 대응하는 디코더에 정보를 시그널링하는 데 사용된다. 선행하는 것은 단어 "신호"의 동사 형태와 관련되지만, 단어 "신호"는 또한 본 명세서에서 명사로서 사용될 수 있다.
당업자에게 명백한 바와 같이, 구현예들은, 예를 들어 저장되거나 송신될 수 있는 정보를 전달하도록 포맷화된 다양한 신호들을 생성할 수 있다. 예를 들어, 정보는 방법을 수행하기 위한 명령어들, 또는 기술된 구현예들 중 하나에 의해 생성된 데이터를 포함할 수 있다. 예를 들어, 신호는 기술된 실시예의 비트스트림을 전달하도록 포맷화될 수 있다. 그러한 신호는, 예를 들어, 전자기파로서(예를 들어, 스펙트럼의 무선 주파수 부분을 사용함) 또는 기저대역 신호로서 포맷화될 수 있다. 포맷화는, 예를 들어, 데이터 스트림을 인코딩하는 것, 및 인코딩된 데이터 스트림으로 캐리어를 변조하는 것을 포함할 수 있다. 신호가 반송하는 정보는, 예를 들어, 아날로그 또는 디지털 정보일 수 있다. 신호는, 알려진 바와 같이, 다양한 상이한 유선 또는 무선 링크들을 통해 송신될 수 있다. 신호는 프로세서 판독가능 매체 상에 저장될 수 있다.
(예컨대, 3D 포인트 클라우드들을 사용하여) 3차원(3D) 이미지들을 캡처하고 렌더링하는 것은 많은 애플리케이션들(예컨대, 원격현실, 가상 현실, 및 대규모 동적 3D 맵들)을 가질 수 있다. 3D 포인트 클라우드들은 몰입형 매체를 표현하는 데 사용될 수 있다. 3D 포인트 클라우드는 3D 공간에 표현된 포인트들의 세트를 포함할 수 있다. (예컨대, 각각의) 포인트는 좌표들 및/또는 하나 이상의 속성들을 포함할 수 있다. 좌표들은 (예컨대, 각각의) 포인트의 위치를 나타낼 수 있다. 속성들은, 예를 들어, 다음 중 하나 이상을 포함할 수 있다: 각각의 포인트와 연관된 색상, 투명도, 획득 시간, 레이저의 반사율 또는 재료 특성 등. 포인트 클라우드들은 다수의 방식들로 캡처되거나 또는 배치될 수 있다. 포인트 클라우드는, 예를 들어, (예컨대, 3D 공간을 샘플링하기 위해) 다수의 카메라들 및 깊이 센서들, 광 검출 및 레인징(LIDAR) 레이저 스캐너들 등을 사용하여 캡처되거나 또는 배치될 수 있다. 예를 들어 3D 공간 내의 객체를 샘플링함으로써 (예컨대, 좌표들 및/또는 속성들로 표현되는) 포인트가 생성될 수 있다. 포인트 클라우드들은 복수의 포인트들을 포함할 수 있으며, 이들 각각은 3D 공간에 맵핑되는 좌표들의 세트(예컨대, x, y, z 좌표들)에 의해 표현될 수 있고, 일례에서, 3D 객체 또는 장면은 수백만 또는 수십억 개의 샘플링된 포인트들을 포함하는 포인트 클라우드로 표현되거나 또는 재구성될 수 있다. 3D 포인트 클라우드들은 정적 및/또는 동적(움직이는) 3D 장면들을 표현할 수 있다.
포인트 클라우드 데이터는, 예를 들어 포인트 클라우드 데이터를 (예컨대, 효율적으로) 저장하고/하거나 송신하기 위해, 표현되고/되거나 압축(예컨대, 포인트 클라우드 압축(point cloud compression, PCC))될 수 있다. 기하구조 기반 압축은 정적 포인트 클라우드들을 인코딩하고 디코딩하는 데 활용될 수 있고, 비디오 기반 압축은, 예를 들어, 3D 포인트 클라우드들의 효율적이고 상호동작가능한 저장 및 송신을 지원하기 위해 동적 포인트 클라우드들을 인코딩하고 디코딩하는 데 활용될 수 있다. 포인트 클라우드 샘플링, 표현, 압축, 및/또는 렌더링은 포인트 클라우드의 기하구조 좌표들 및/또는 속성들의 손실 및/또는 무손실 코딩(예컨대, 인코딩 또는 디코딩)을 지원할 수 있다.
도 5는 서버(502) 및 클라이언트(510)를 위한 시스템 인터페이스(500)를 도시하는 도면이다. 서버(502)는 인터넷(504) 및 다른 네트워크들(506)에 접속되는 포인트 클라우드 서버일 수 있다. 클라이언트(510)는 또한, 인터넷(504) 및 다른 네트워크들(506)에 접속되어, 노드들(예컨대, 서버(502)와 클라이언트(510)) 사이의 통신을 가능하게 할 수 있다. 각각의 노드는 프로세서, 비일시적 컴퓨터 판독가능 메모리 저장 매체, 및 본 명세서에 개시된 방법들 또는 방법들의 일부분들을 수행하기 위해 프로세서에 의해 실행가능한 저장 매체 내에 포함된 실행가능 명령어들을 포함할 수 있다. 하나 이상의 노드들은 하나 이상의 센서들을 추가로 포함할 수 있다. 클라이언트(510)는 (예컨대, 또한) 헤드 마운트 디스플레이(HMD)(508)와 같은 디스플레이를 위해 3D 비디오를 렌더링하기 위한 그래픽 프로세서(512)를 포함할 수 있다. 노드들 중 임의의 것 또는 모두는 도 1a 내지 도 1d와 관련하여 전술된 바와 같이, WTRU를 포함할 수 있고, 네트워크들을 통해 통신할 수 있다.
도 6은 서버(602) 및 클라이언트(604)를 위한 시스템 인터페이스(600)를 보여주는 도면이다. 서버(602)는 포인트 클라우드 콘텐츠 서버(602)일 수 있고, 포인트 클라우드 콘텐츠의 데이터베이스, 세부 레벨을 프로세싱하기 위한 로직, 및 서버 관리 기능을 포함할 수 있다. 일부 예들에서, 세부세항에 대한 프로세싱은, 예컨대 대역폭 제한들로 인해 또는 뷰잉(viewing) 거리가 감소를 허용하기에 충분하기 때문에 허용되는 대로, 클라이언트(604)(예컨대, 뷰잉 클라이언트(604))로의 송신을 위해 해상도를 감소시킬 수 있다. 포인트 클라우드 콘텐츠 서버(602)는 클라이언트(604)와 통신할 수 있고, 포인트 클라우드 데이터 및/또는 포인트 클라우드 메타데이터는 교환될 수 있다. 일부 예들의 경우, 뷰어를 위해 렌더링된 포인트 클라우드 데이터는, 예컨대 (예컨대, 포인트 클라우드 서버(602)로부터 뷰잉 클라이언트(604)에게로 스트리밍되는) 포인트 클라우드 데이터 및/또는 포인트 클라우드 메타데이터로부터, 상세 레벨을 감소시키고/시키거나 증가시키기 위해 데이터 구성의 프로세스를 겪을 수 있다. 포인트 클라우드 서버(602)는, 예컨대 대역폭 제약들 또는 뷰잉 거리 공차들에 순응하기 위해, 공간 캡처링이 제공했거나 일부 실시예들의 경우에 다운-샘플링한 해상도로 포인트 클라우드 데이터를 스트리밍할 수 있다. 포인트 클라우드 서버(602)는 상세 레벨을 동적으로 감소시킬 수 있고, 일부 예들에서, 포인트 클라우드 서버(602)는 (예컨대, 또한) 포인트 클라우드 데이터를 세그먼트화하고, 포인트 클라우드 내의 객체들을 식별할 수 있다. 일부 예들에서, 선택된 객체에 대응하는 포인트 클라우드 데이터 내의 포인트들은 더 낮은 해상도 데이터로 대체될 수 있다.
클라이언트(604)(예컨대, HMD를 갖는 클라이언트(604))는 비트 스트림, 예를 들어, 비디오 기반 포인트 클라우드 압축(V-PCC) 코딩된 비트스트림을 통해 포인트 클라우드 콘텐츠 서버(602)로부터 포인트 클라우드의 일부분들 및/또는 타일들을 요청할 수 있다. 예를 들어, 포인트 클라우드의 일부분들 및/또는 타일들은 HMD의 위치 및/또는 배향에 기초하여 회수될 수 있다.
포인트 클라우드는 각각의 포인트와 연관된 색상, 투명도, 획득 시간, 레이저의 반사율 또는 재료 특성 등과 같은 하나 이상의 속성들과 함께 각각의 포인트의 위치를 나타내는 좌표들을 사용하여 3D 공간에 표현된 포인트들의 세트로 구성될 수 있다. 포인트 클라우드들은 다수의 방식들로 캡처될 수 있다. 예를 들어, 포인트 클라우드들을 캡처하기 위한 하나의 기법은 다수의 카메라들 및 깊이 센서들을 사용하는 것을 수반할 수 있다. 광 검출 및 레인징(LiDAR) 레이저 스캐너들이 또한, 포인트 클라우드들을 캡처하기 위해 사용될 수 있다. 포인트 클라우드들을 사용하여 객체들 및 장면들을 현실적으로 재구성하기 위해 요구되는 포인트들의 수는 수백만(또는 심지어 수십억) 정도일 수 있다. 따라서, 효율적인 표현 및 압축은 포인트 클라우드 데이터를 저장 및 송신하기 위해 필수적일 수 있다. 포인트 클라우드들과 유사하게, 일부 몰입형 비디오 유형들은 또한, 시각적 볼류메트릭 콘텐츠를 표현하고, 예를 들어, 6 자유도(6DoF)로, 제한된 범위의 뷰잉 포지션들 및 배향들 내에서 3D 장면의 재생을 위한 지원을 제공할 수 있다.
상기의 단락들에 실질적으로 기술된 바와 같이, 적어도 2개의 3D 포인트 클라우드 압축(PCC) 표준들, 즉 정적 포인트 클라우드들에 대한 기하구조 기반 압축 표준, 및 동적 포인트 클라우드들에 대한 비디오 기반 압축 표준이 제안된다. 동적 포인트 클라우드들에 대한 비디오 기반 압축 표준과 관련하여, 시각적 볼류메트릭 비디오 기반 코딩(V3C)은 일례이고, V3C 기반 구현예들의 다양한 태양들이 다음과 같이 설명될 수 있다.
도 7은 V3C 비트스트림의 구조의 일례를 예시한다. 도 7에 도시된 바와 같이, 비트스트림은 V3C 샘플 스트림(701)을 포함할 수 있으며, 이는 V3C 유닛들의 세트를 포함할 수 있고, 이들 각각은 V3C 유닛 헤더 및 V3C 유닛 페이로드를 갖는다. V3C 유닛 헤더는 V3C 유닛 유형을 설명할 수 있다. 예를 들어, V3C 유닛 유형들은 V3C_OVD, V3C_GVD, 및/또는 V3C_AVD를 포함할 수 있다. 유닛 유형들 V3C_OVD, V3C_GVD, 및 V3C_AVD를 갖는 V3C 유닛들은 각각 점유도, 기하구조, 및 속성 비디오 데이터 유닛들일 수 있다. 이들 데이터 유닛들은 시각적 볼류메트릭 매체 콘텐츠를 재구성하는 데 필요한 3개의 메인 컴포넌트들을 표현할 수 있다. 점유도, 기하구조, 및 속성 V3C 유닛 페이로드들은 적절한 비디오 디코더에 의해 디코딩될 수 있는 비디오 데이터 유닛들(예컨대, 네트워크 추상 계층(network abstraction layer, NAL) 유닛들)에 대응할 수 있다. V3C 비트스트림은 또한 하나 이상의 V3C_VPS 유닛들을 포함할 수 있고, 이는 V3C 유닛 헤더들에서 사용될 수 있는 바와 같은 신택스 요소들을 정의하는 파라미터 세트를 제공할 수 있다. V3C 비트스트림은 아틀라스 서브비트스트림(예컨대, V3C 유닛 헤더(V3C_AD)에 의해 표기됨)을 추가로 포함할 수 있고, 이는 적어도 네트워크 추상 계층(NAL) 유닛 헤더를 포함하는 유닛들을 포함하고 코딩된 아틀라스를 정의하는(또는 부분적으로 정의하는) 데이터를 캡슐화하는 NAL 샘플 스트림(702)을 반송할 수 있다. 예를 들어, 도 7에 도시된 바와 같이, NAL 유닛은 아틀라스 타일 그룹에 대응하는 아틀라스 타일 그룹 계층(703)의 페이로드(예컨대, 원시 바이트 시퀀스 페이로드(raw byte sequence payload, RBSP))를 포함할 수 있고, 이는 헤더, 및 패치(즉, 볼류메트릭 정보와 연관되는 아틀라스 내의 영역)를 설명하는 데이터를 포함할 수 있다.
도 8은 지원된 V3C 속성 유형들의 예들을 예시하는 표이다. V3C 유닛 유형에 더하여, V3C 속성 유닛 헤더는 속성 유형을 특정할 수 있다. V3C 속성 유닛 헤더는 또한, 동일한 속성 유형의 다수의 인스턴스들이 지원될 수 있게 하는 인덱스를 특정할 수 있다. 예를 들어, 지원되는 속성 유형들은 텍스처, 재료, 투명도, 반사율, 또는 표면 법선(surface normal)을 포함할 수 있다.
V3C 컨테이너 파일 포맷들이 본 명세서에 설명된다.
도 9는 ISOBMFF 표준들에 따라 구현될 수 있는 바와 같은 V3C 컨테이너의 구조의 일례를 도시한다. 대체적으로, V3C 컨테이너는 아틀라스 데이터, 기하구조 데이터, 속성 데이터, 및 점유도 데이터에 의해 추가로 정의되는 볼류메트릭 비디오 데이터(900)를 포함할 수 있다. 더 구체적으로, 컨테이너는 V3C 아틀라스 트랙(910)을 포함할 수 있으며, 이는 샘플 엔트리 내의 V3C 파라미터 세트 및 아틀라스 파라미터 세트들 및 샘플들 내의 아틀라스 컴포넌트 비트스트림 NAL 유닛들을 포함한다. V3C 아틀라스 트랙은 또한, 비디오 압축된 V3C 유닛들(즉, V3C_OVD, V3C_GVD, 및 V3C_AVD와 동일한 V3C 유닛 유형들)의 페이로드들을 반송하는 다른 트랙들(920, 930, 940)에 대한 또는 V3C 아틀라스 타일 트랙들에 대한 트랙 참조들을 포함할 수 있다.
컨테이너는, 920에서 도 9에 예시된 바와 같이, 하나 이상의 V3C 비디오 컴포넌트 트랙들을 포함할 수 있으며, 여기서 샘플들은 기하구조 데이터(즉, V3C_GVD와 동일한 유형의 V3C 유닛들의 페이로드들)에 대한 비디오 코딩된 기본 스트림들의 액세스 유닛들을 포함한다. 컨테이너는, 930에서 도 9에 예시된 바와 같이, 0개 이상의 V3C 비디오 컴포넌트 트랙들을 포함할 수 있으며, 여기서 샘플들은 속성 데이터(즉, V3C_AVD와 동일한 유형의 V3C 유닛들의 페이로드들)에 대한 비디오 코딩된 기본 스트림들의 액세스 유닛들을 포함한다. 컨테이너는, 940에서 도 9에 예시된 바와 같이, 0개 이상의 V3C 비디오 컴포넌트 트랙들을 포함할 수 있으며, 여기서 샘플들은 점유도 데이터(즉, V3C_OVD와 동일한 유형의 V3C 유닛들의 페이로드들)에 대한 비디오 코딩된 기본 스트림의 액세스 유닛들을 포함한다.
도 10은 하나 초과의 아틀라스 및 다수의 아틀라스 타일들을 갖는 다중 트랙 컨테이너의 일례를 예시한다. 다수의 아틀라스들이 V3C 매체들에 존재할 때, 이들 아틀라스들은 연관된 V3C 컴포넌트 트랙들(즉, 연관된 점유도 맵, 기하구조, 및 속성 정보를 반송하는 트랙들)에 대한 트랙 참조들을 갖는 별개의 아틀라스 트랙들에서 반송될 수 있다. 아틀라스 데이터가 2개 이상의 아틀라스 타일들을 포함하는 경우, 이들 아틀라스 타일들은 아틀라스 트랙에 의해 참조되는 별개의 아틀라스 타일 트랙들에 저장될 수 있으며, 이때 아틀라스 타일 트랙들로부터 트랙들로의 추가적인 트랙 참조들은 아틀라스 타일 트랙에 의해 반송되는 아틀라스 타일들에 대한 연관된 V3C 비디오 컴포넌트 정보를 반송한다. 이것은, 예를 들어, 도 10에서 입증될 수 있다. 1001에 예시된 바와 같이, V3C 트랙 'v3cb'는 다수의 아틀라스들을 포함할 수 있다. 아틀라스들은, 예를 들어, ' v3a1' 또는 'v3ag'의 샘플 엔트리들을 갖는 별개의 V3C 트랙들(1010, 1020)에 저장될 수 있다. V3C 트랙들(1010, 1020)은 각각 다수의 아틀라스 타일 트랙들(1011, 1012)을 포함할 수 있고, 아틀라스 타일 트랙들(1011, 1012) 각각은 V3C 컴포넌트 트랙들(1013, 1014)을 각각 포함할 수 있다.
상기의 단락들에 실질적으로 기술된 바와 같이, 정적 포인트 클라우드들에 대한 기하구조 기반 압축(G-PCC) 표준들은 또한, 3D 포인트 클라우드들의 효율적인 그리고 상호동작가능한 저장 및 송신을 지원하도록 정의될 수 있다. 그러한 기하구조 기반 압축 표준들에 따라 수행되고/되거나 구현될 수 있는 방법들, 장치들, 및 시스템들이 본 명세서에서 제안된다.
도 11은 G-PCC 표준들에 따라 인코딩된 비트스트림의 구조의 일례를 예시하는 도면이다. 도 11에 도시된 바와 같이, G-PCC 비트스트림(1100)은, 유형-길이-값(TLV) 캡슐화 구조체들로도 알려진, G-PCC 유닛들의 세트를 반송할 수 있다. 1110에 도시된 바와 같이, (즉, 각각의) G-PCC TLV 유닛은 TLV 유형(1111) 및 G-PCC TLV 유닛 페이로드(1112)를 나타내는 정보를 포함할 수 있다. 도 11에 도시되지 않았지만, GPCC TLV 유닛은, 예를 들어, 바이트 또는 비트의 관점에서 표현될 수 있는 G-PCC TLV 유닛 페이로드 길이를 나타내는 정보를 추가로 포함할 수 있다. G-PCC TLV 유닛 페이로드(1112)는 주어진 유형의 정보를 포함할 수 있다. 예를 들어, G-PCC TLV 유닛 페이로드는 주어진 유형의 정보를 반송할 수 있으며, 이는, 예를 들어, 시퀀스 파라미터 세트, 기하구조 파라미터 세트, 기하구조 데이터 유닛, 속성 파라미터 세트, 속성 데이터 유닛, 타일 인벤토리, 프레임 경계 마커, 또는 디폴트형 속성 데이터 유닛일 수 있다.
도 12는, 예를 들어, MPEG 표준들에 따라 정의될 수 있는 바와 같은 G-PCC TLV 캡슐화 유닛의 예시적인 신택스 구조를 제공하는 표이다. 도 12에 도시된 바와 같이, TLV 캡슐화 유닛은 제1 수의 비트들(또는 바이트들), 예컨대 8 비트를 사용하여 페이로드 유형을 나타낼 수 있다. 이어서, TLV 캡슐화 유닛 페이로드 길이는 제2 수의 비트들(예컨대, 32 비트들)로 표현될 수 있다. G-PCC TLV 캡슐화 유닛은 표시된 페이로드 유형 및 페이로드 길이를 갖는 페이로드를 포함할 수 있다.
도 13은 TLV 유형 파라미터의 가능한 값들 및 가능한 값들 각각의 대응하는 설명들을 제공하는 표이다. 도 13에 도시된 바와 같이, TLV 페이로드 유형은 시퀀스 파라미터 세트, 기하구조 파라미터 세트, 기하구조 데이터 유닛, 속성 파라미터 세트, 속성 데이터 유닛, 타일 인벤토리, 프레임 경계 마커, 또는 디폴트형 속성 데이터 유닛일 수 있다. 유닛 유형들 '2' 및 '4'를 갖는 G-PCC TLV 유닛들은 각각 기하구조 및 속성 데이터 유닛들일 수 있다.
도 14는 G-PCC TLV 유닛 페이로드의 예시적인 신택스 구조를 제공하는 표이다. 도 14에 도시된 예시적인 신택스는, 예를 들어, MPEG-I 파트 9(ISO/IEC 23090-9)에 정의된 바와 같은 신택스 구조와 일치할 수 있다. 기하구조 및 속성 G-PCC 유닛들의 페이로드 정보는, G-PCC 디코더에 의해 디코딩될 수 있고 대응하는 기하구조에서 특정되는 매체 데이터 유닛들(예컨대, TLV 유닛들), 및 속성 파라미터 세트 G-PCC 유닛에 대응할 수 있다.
일부 스킴들에서, G-PCC 비트스트림 고레벨 신택스(high-level syntax, HLS)는 기하구조 및 속성 데이터에서 슬라이스 및 타일 그룹들의 개념을 지원할 수 있다. 프레임은 다수의 타일들 및 슬라이스들로 피티셔닝될 수 있다. 슬라이스는, 독립적으로 인코딩되거나 또는 디코딩될 수 있는 포인트들의 세트로서 이해될 수 있다. 슬라이스는, 예를 들어, 하나의 기하구조 데이터 유닛 및 0개 이상의 속성 데이터 유닛들을 포함할 수 있다. 속성 데이터 유닛의 정보는 동일한 슬라이스 내의 기하구조 데이터 유닛의 대응하는 정보에 의존할 수 있다. 슬라이스 내에서, 기하구조 데이터 유닛은 반드시, 연관된 속성 유닛들 이전에 나타날 수 있다. 슬라이스의 데이터 유닛들은 인접할 수 있다. 프레임 내에서 슬라이스들의 순서화는 반드시 특정될 필요는 없다.
일부 스킴들에서, 슬라이스들의 그룹은 공통 타일 식별자에 의해 식별될 수 있다. 일부 표준들과 부합하여, 각각의 타일에 대한 경계 박스를 설명하는 타일 인벤토리가 제공될 수 있다. 타일은 경계 박스 내의 다른 타일과 중첩할 수 있다. 각각의 슬라이스는, 그것이 속하는 타일을 식별하는 인덱스를 포함할 수 있다.
G-PCC 컨테이너 파일 포맷들이 본 명세서에 기술된다. G-PCC 비트스트림이 단일 트랙에서 반송될 때, G-PCC 인코딩된 비트스트림이 단일 트랙 선언에 의해 표현되는 것이 요구될 수 있다. G-PCC 데이터의 단일 트랙 캡슐화는, 일부 경우들에서, 추가적인 프로세싱 없이, G-PCC 비트스트림이 단일 트랙에 저장되는 간단한 ISOBMFF 캡슐화를 활용할 수 있다. 그러한 트랙 내의 각각의 샘플은 하나 이상의 G-PCC 컴포넌트들을 포함할 수 있다. 다시 말해서, 각각의 샘플은 하나 이상의 TLV 캡슐화 구조들을 포함할 수 있다.
도 15는, G-PCC 기하구조 및 속성 정보를 제공하는 비트스트림이 단일 트랙에 저장되는 스킴들에 따른 샘플 구조의 일례를 예시한다. 도 15에 도시된 바와 같이, G-PCC 비트스트림을 반송하는 트랙의 샘플(1500)은 파라미터 세트를 제공하는 제1 TLV(1510), 기하구조 데이터를 제공하는 제2 TLV(1520), 및 제2 TLV(1520)의 기하구조 데이터에 대응하는 속성 데이터를 제공하는 제3 TLV(1530) 중 적어도 하나를 포함할 수 있다.
코딩된 G-PCC 기하구조 비트스트림 또는 비트스트림들 및 코딩된 G-PCC 속성 비트스트림 또는 비트스트림들이 별개의 트랙들에 저장될 때, 트랙 내의 각각의 샘플은 단일 G-PCC 컴포넌트 데이터를 반송하는 적어도 하나의 TLV 캡슐화 구조를 포함할 수 있다.
도 16은 일부 표준들(예컨대, MPEG-I 파트 18(ISO/IEC 23090-18))에 따라 구현될 수 있는 바와 같은 다중 트랙 ISOBMFF G-PCC 컨테이너의 예시적인 구조를 도시한다. 다중 트랙 G-PCC 컨테이너는, ISO/IEC 14496-12에 정의된 기본 매체 파일 포맷과 일치할 수 있는, ftyp, moov, 및 mdat 구조들(1610, 1620, 및 1630)에 의해 각각 도 16에 도시된, "박스들"로 알려진 정보 유닛들을 포함할 수 있다. ftyp 박스(1610)는, 예를 들어, 매체들 파일에 사용되는 파일 유형 설명 정보 및 공통 데이터 구조들을 제공할 수 있다. moov 박스(1620) 및 mdat 박스(1630)는, 기하구조 파라미터 세트, 시퀀스 파라미터 세트 및 기하구조 데이터 TLV 유닛들을 반송하는 기하구조 비트스트림 샘플들을 함께 포함하는 G-PCC 트랙들(1621, 1631)을 포함할 수 있다. 트랙들은 또한 G-PCC 속성 컴포넌트(들)의 페이로드들을 반송하는 다른 트랙들에 대한 트랙 참조들을 포함할 수 있다. moov 박스(1620) 및 mdat 박스(1630)는, 각자의 속성의 속성 파라미터 세트, 및 속성 데이터 TLV 유닛들을 반송하는 속성 비트스트림 샘플들을 포함할 수 있는 G-PCC 트랙들(1622, 1632)을 집합적으로 포함할 수 있다.
G-PCC 비트스트림이 다수의 트랙들에서 반송될 때, 일부 표준들(예컨대, ISO/IEC 14496-12)에 따라 구현될 수 있는 트랙 참조 툴이 G-PCC 컴포넌트 트랙들을 링크시키는 데 사용될 수 있다. 일부 예들에서, 하나 이상의 TrackReferenceTypeBoxes는 G-PCC 트랙의 TrackBox 내의 TrackReferenceBox에 추가될 수 있다. TrackReferenceTypeBox는 G-PCC 트랙이 참조하는 트랙들을 지정하는 track_ID들의 어레이를 포함할 수 있다. G-PCC 기하구조 트랙을 G-PCC 속성 트랙에 링크시키기 위해, G-PCC 기하구조 트랙 내의 TrackReferenceTypeBox의 reference_type이 연관된 속성 트랙들을 식별할 수 있다. 이들 트랙 참조 유형들과 연관된 4문자 코드(4CC)는 'gpca'일 수 있으며, 이는, 참조된 트랙(들)이 G-PCC 속성 데이터의 코딩된 비트스트림을 포함한다는 것을 나타낼 수 있다.
G-PCC 비트스트림의 기하구조 스트림이 다수의 타일들을 포함할 때, 각각의 타일 또는 타일들의 그룹은 기하구조 타일 트랙으로서 지칭될 수 있는 별개의 트랙에 캡슐화될 수 있다. 기하구조 타일 트랙은 하나 이상의 기하구조 타일들의 TLV 유닛들을 반송하고, 따라서 이들 타일들에 대한 직접 액세스를 가능하게 할 수 있다. 유사하게, 다수의 타일들을 포함하는 G-PCC 비트스트림의 속성 스트림(들)은 또한 다수의 속성 타일 트랙들에서 반송될 수 있다.
G-PCC 타일 또는 타일들의 데이터는 컨테이터의 속성 타일 트랙들 및 별개의 기하구조에서 반송될 수 있다. G-PCC 코딩된 스트림들에 대한 ISOBMFF 컨테이너들에서의 부분 액세스를 지원하기 위해, 포인트 클라우드 장면 내의 공간 영역에 대응하는 타일들은, 일부 MPEG 표준들과 부합하여 정의될 수 있는 Dynamic3DSpatialRegionSampleEntry를 갖는 트랙과 같은, 타임드(timed) 메타데이터 트랙의 샘플들에서, 또는 일부 MPEG 표준들에서 또한 정의될 수 있는 바와 같은 GPCCSpatialRegionInfoBox 박스에서 시그널링될 수 있다. 이것은, 플레이어들 및 스트리밍 클라이언트들이 포인트 클라우드 장면 내에 소정 공간 영역들 또는 타일들을 렌더링하는 데 필요한 정보를 반송하는 타일 트랙들의 세트만을 취출하는 것을 가능하게 할 수 있다.
G-PCC 기본 트랙은, 예를 들어, ISO/IEC 23090-9와 부합하는, SPS, GPS, APS, 및 타일 인벤토리 정보만을 포함하는 TLV 캡슐화 구조들을 반송할 수 있다. G-PCC 기본 트랙을 기하구조 타일 트랙들에 링크시키기 위해, 새로운 트랙 참조 유형을 갖는 트랙 참조가 4CC 'gpbt'를 사용하여 정의될 수 있다. 새로운 유형의 트랙 참조들은 G-PCC 기본 트랙을 기하구조 타일 트랙들 각각과 링크시키는 데 사용될 수 있다.
각각의 기하구조 타일 트랙은, 예를 들어, ISO/IEC 14496-12와 부합하여 구현될 수 있는 바와 같은 트랙 참조 툴을 사용하여 각자의 타일 또는 타일 그룹의 속성 정보를 반송하는 G-PCC 타일 트랙들의 다른 속성 또는 속성들과 링크될 수 있다. 이들 트랙 참조 유형들의 4CC들은, 예를 들어, MPEG 표준들과 부합하여 정의될 수 있는 바와 같은 'gpca'일 수 있다.
포인트 클라우드 장면이 대안들에서 코딩될 수 있다. 그러한 경우에, 코딩된 G-PCC 데이터의 대안들은, ISO/IEC 14496-12와 부합하여 구현될 수 있는 바와 같이, 대체 트랙 메커니즘에 의해 표시될 수 있다. 예를 들어, TrackHeaderBox의 alternate_group 필드는 코딩된 G-PCC 데이터의 대안을 나타내는 데 사용될 수 있다. 각각의 대안의 G-PCC 비트스트림이 단일 트랙에 저장될 때, 서로의 대안들일 수 있는 코딩된 G-PCC 비트스트림을 포함하는 G-PCC 트랙들은 그들의 TrackHeaderBox에서 동일한 alternate_group 값을 가질 수 있다. 각각의 대안의 G-PCC 비트스트림이 다중 트랙 컨테이너에 저장될 때, 즉, 각각의 대안의 G-PCC 비트스트림의 상이한 컴포넌트 비트스트림이 별개의 트랙들에서 반송될 때, 대안의 G-PCC 비트스트림의 G-PCC 기하구조 트랙들은 그들의 TrackHeaderBox에서 동일한 alternate_group 값을 가질 수 있다.
MPEG 매체 전송(MMT)을 위한 방법들, 절차들, 장치들, 및 시스템들이 본 명세서에 기술된다. 대체적으로 말하면, 툴들의 세트는 진행된 매체 전송 및 전달 서비스들을 가능하게 하는 데 사용될 수 있다. 툴들은 3개의 상이한 기능적 영역들, 즉 매체들 프로세싱 유닛(MPU) 포맷, 전달, 및 시그널링에 걸쳐 확산될 수 있다. 그러한 툴들이 함께 효율적으로 사용되도록 설계될 수 있더라도, 그들은 또한 독립적으로 사용될 수 있다.
매체들 프로세싱 유닛(MPU) 기능 영역은 매체 콘텐츠의 논리 구조, MMT 엔티티에 의해 프로세싱될 데이터 유닛들의 패키지 및 포맷, 및 예를 들어, ISO 기본 매체들 파일 포맷을 이용한 그들의 인스턴스화를 정의할 수 있다. 패키지는 매체 콘텐츠를 포함하는 컴포넌트들 및 그들 사이의 관계를 특정하여, 진행된 전달에 필요한 정보를 제공할 수 있다. 데이터의 포맷은 저장이나 전달을 위해 인코딩된 매체 데이터를 캡슐화하도록, 그리고 저장될 데이터와 전달될 데이터 사이의 용이한 전환을 허용하도록 정의될 수 있다.
전달 기능 영역은 MMT 프로토콜(MMTP)로 불리는 애플리케이션 계층 전송 프로토콜 및 페이로드 포맷을 정의할 수 있다. 애플리케이션 계층 전송 프로토콜은, 단일 패킷 흐름에서 스트리밍 및 다운로드 전달의 혼합 사용의 다중화 및 지원과 같은, 멀티미디어 데이터의 전달을 위한 향상된 특징들을 제공할 수 있다. 페이로드 포맷은 인코딩된 매체 데이터의 반송을 가능하게 할 수 있으며, 이는 매체 유형 및 인코딩 방법들에 대해 애그노스틱일 수 있다.
시그널링 기능 영역은 매체 데이터의 전달 및 소비를 관리하기 위해 시그널링 메시지들의 포맷들을 정의할 수 있다. 소비 관리를 위한 시그널링 메시지들은 패키지의 구조를 시그널링하는 데 사용될 수 있고, 전달 관리를 위한 시그널링 메시지들은 페이로드 포맷 및 프로토콜 구성의 구조를 시그널링하는 데 사용될 수 있다.
MMT 프로토콜은 단일 MMTP 패킷 흐름을 통해 다양한 자산들로부터 매체들 프로세싱 유닛(Media Processing Unit, MPU)들과 같은 상이한 매체 데이터의 다중화를 지원할 수 있다. 그것은, 큰 지연을 도입하거나 또는 큰 버퍼를 요구하지 않고서 상이한 유형들의 매체 데이터 사이의 동기화를 돕기 위해, 소비 순서로 다수의 유형들의 데이터를 수신용 엔티티에 전달할 수 있다. MMTP는 또한, 단일 패킷 흐름 내에서 매체 데이터 및 시그널링 메시지들의 다중화를 지원할 수 있다.
일부 실시예들에서, MMTP 페이로드는 하나의 MMTP 패킷에서만 수행될 수 있다. 단편화(fragmentation) 및 집성은 페이로드 포맷에 의해 제공될 수 있고, MMTP 자체에 의해 제공되지 않을 수 있다. MMTP는 2개의 패킷화 모드들, 즉 일반 파일 전달(Generic File Delivery, GFD) 모드 및 MPU 모드를 정의할 수 있다. GFD 모드는 전송 객체 내부의 그들의 바이트 포지션을 사용하여 데이터 유닛들을 식별할 수 있다. MPU 모드는 MPU 내부의 그들의 역할 및 매체들 포지션을 사용하여 데이터 유닛들을 식별할 수 있다. MMT 프로토콜은 단일 전달 세션에서 2개의 상이한 모드들을 갖는 패킷들의 혼합 사용을 지원할 수 있다. MMT 패킷들의 단일 패킷 흐름은 2개의 유형들을 갖는 페이로드들로 임의로 구성될 수 있다.
도 17은 MMT 시그널링이 수행되는 시스템의 예시적인 종단간 아키텍처를 도시한다. 아키텍처는 적어도, 패키지 제공자(1710), 하나 이상의 자산 제공자들(1721, 1722), MMT 전송용 엔티티(1730), 및 MMT 수신용 엔티티(1740)를 포함할 수 있지만, 이로 제한되지 않는다. 도 17에 도시된 바와 같이, MMT 전송용 엔티티(1730)는 패키지 제공자(1710)로부터 패키지들을 수신할 수 있다. MMT 전송용 엔티티(1730)는, MMTP 패킷 흐름들로서, MMT 수신용 엔티티(1740)로 패키지들을 전송하는 것을 담당할 수 있다. MMT 전송용 엔티티(1730)는 패키지 제공자(1710)에 의해 제공되는 패키지의 프레젠테이션 정보에 기초하여 콘텐츠 제공자들로부터의 매체 콘텐츠들을 수집하도록 요구될 수 있다. 매체 콘텐츠는, MMTP 패킷 흐름을 형성하는 일련의 캡슐화된 MMT 프로세싱 유닛들로 세그먼트화되는 자산으로서 제공될 수 있다. 따라서, MMT 전송용 엔티티(1730)는 자산 제공자들(1721 및/또는 1722) 중 하나 이상으로부터의 자산 정보를 수집할 수 있다.
시그널링 메시지들은 패키지들의 전달 및 소비를 관리하는 데 사용될 수 있다. MMT 전송용 엔티티(1730)와 MMT 수신용 엔티티(1740) 사이의 인터페이스들뿐만 아니라 그들의 동작들은 표준화될 수 있다. MMT 프로토콜(MMTP)은, packet_id 및 페이로드 유형에 기초하여, 스트리밍된 매체들을 수신 및 역다중화하기 위해 MMT 수신용 엔티티(1740)에 의해 사용될 수 있다. MMT 수신용 엔티티(1740)에 의해 수행되는 역캡슐화 절차는 반송되는 페이로드의 유형에 의존할 수 있고, 예를 들어, 도 17에 도시된 시나리오에서 별개로 프로세싱될 수 있다.
MMT 데이터 모델의 다양한 태양들이 본 명세서에 기술된다. MMT 프로토콜은 코딩된 매체 데이터의 스트리밍 전달 및 다운로드 전달 둘 모두를 제공할 수 있다. 스트리밍 전달의 경우, MMT 프로토콜은 MPU들, 자산들 및 패키지를 포함하는 특정 데이터 모델을 가정할 수 있다. MMT 프로토콜은, 시그널링 메시지들을 사용하여 MPU, 자산, 및 패키지 사이의 구조적 관계들을 나타냄으로써 전달 동안 데이터 모델을 보존할 수 있다.
인코딩된 매체 데이터 및 그의 관련된 메타데이터의 집합은 패키지를 구축할 수 있다. 패키지는 하나 이상의 MMT 전송용 엔티티들로부터 하나 이상의 MMT 수신용 엔티티들로 전달될 수 있다. 오디오 또는 비디오 콘텐츠의 조각과 같은, 패키지의 인코딩된 매체 데이터의 하나 이상의 조각들이 자산을 구성할 수 있다.
자산은 그의 실제 물리적 위치 또는 그것을 제공하고 있는 서비스 제공자에 대해 애그노스틱일 수 있는 식별자와 연관될 수 있어서, 자산이 전세계적으로 고유하게 식별될 수 있게 할 수 있다. 상이한 식별자들을 갖는 자산들은 상호교환가능하지 않을 수 있다. 예를 들어, 2개의 상이한 자산들은 동일한 콘텐츠의 2개의 상이한 인코딩들을 반송할 수 있지만, 그들은 상호교환가능하지 않을 수 있다. MMT는 특정 식별 메커니즘을 특정하지 않을 수 있지만, 이러한 목적을 위한 URI들 또는 UUID들의 사용을 허용할 수 있다. 각각의 자산은 그 자신의 타임라인을 가질 수 있으며, 이는 패키지에 의해 생성된 전체 프레젠테이션의 것과 상이한 지속기간의 것일 수 있다.
각각의 MPU는 자산의 중첩되지 않는 조각을 구성할 수 있는데, 즉, 동일한 자산의 2개의 연속적인 MPU들은 동일한 매체 샘플들을 포함하지 않을 수 있다. 각각의 MPU는 MMT 수신용 엔티티의 프레젠테이션 엔진에 의해 독립적으로 소비될 수 있다.
도 18은 일부 실시예들에 따른 패키지 구조의 예시이다. 도 18에 도시된 바와 같이, 패키지(1800)는 논리 엔티티일 수 있다. 패키지(1800)는 하나 이상의 프레젠테이션 정보 문서들(1810), 하나 이상의 자산들(1820), 및 각각의 자산에 대해, 연관된 자산 전달 특성(asset delivery characteristic, ADC)들을 포함할 수 있다. 자산들(1820) 각각은 하나 이상의 MPU들(1830)을 포함할 수 있다. 패키지의 프로세싱은 MPU당 단위로 수행될 수 있고, 각각의 MPU는 동일한 자산 ID를 공유할 수 있다.
MMT 자산들은, 일부 실시예들에 따라 본 명세서에서 추가로 기술된다. 자산은 멀티미디어 프레젠테이션을 구축하기 위해 사용될 임의의 멀티미디어 데이터일 수 있다. 자산은 인코딩된 매체 데이터를 반송하기 위해 동일한 자산 ID를 공유하는 MPU들의 논리적 그룹화일 수 있다. 자산의 인코딩된 매체 데이터는 타임드 데이터 또는 비-타임드 데이터일 수 있다. 타임드 데이터는 고유 타임라인을 갖는 인코딩된 매체 데이터를 포함할 수 있고, 지정된 시간에 데이터 유닛들의 동기화된 디코딩 및 프레젠테이션을 요구할 수 있다. 비-타임드 데이터는 그의 매체 콘텐츠를 디코딩 및 제시하기 위한 고유 타임라인을 갖지 않는 임의의 다른 유형의 데이터를 포함할 수 있다. 비-타임드 데이터의 각각의 항목의 디코딩 시간 및 프레젠테이션 시간은 반드시 동일한 비-타임드 데이터의 다른 항목들의 것과 관련되는 것은 아닐 수 있다. 예를 들어, 이들은 사용자 상호작용 또는 프레젠테이션 정보에 의해 결정될 수 있다.
타임드 매체 데이터를 반송하는 동일한 자산의 2개의 MPU들은 그들의 프레젠테이션 시간에서 어떠한 중첩도 갖지 않을 수 있다. 프레젠테이션 정보에 의해 참조되는 임의의 유형의 데이터는 자산으로 간주될 수 있다. 개별 자산들로 간주될 수 있는 매체 데이터의 유형의 예들은 오디오 데이터, 비디오 데이터, 또는 웹 페이지 데이터를 포함할 수 있다.
매체들 프로세싱 유닛(MPU)의 특징들 및 특성들이 본 명세서에 기술된다. 매체들 프로세싱 유닛(MPU)은, MMT 엔티티에 의해 프로세싱되고 다른 MPU들로부터 독립적으로 프레젠테이션 엔진에 의해 소비될 수 있는 매체 데이터 항목일 수 있다.
MMT 엔티티에 의한 MPU의 프로세싱은 캡슐화/캡슐화해제 및 패킷화/패킷화해제를 포함할 수 있다. MPU는 매체 인식 패킷화를 위한 MFU들의 경계들을 나타내는 MMT 힌트 트랙을 포함할 수 있다. MPU의 소비는 매체들 프로세싱(예컨대, 인코딩/디코딩) 및 프레젠테이션을 포함할 수 있다.
패킷화 목적들을 위해, MPU는 액세스 유닛(AU)보다 더 작을 수 있는 데이터 유닛들로 단편화될 수 있다. MPU의 신택스 및 시맨틱들은 MPU에서 반송되는 매체 데이터의 유형에 의존하지 않을 수 있다. 단일 자산의 MPU들은 타임드 또는 비-타임드 매체들 중 어느 하나를 가질 수 있다. MPU는 MPEG-4 AVC(ISO/IEC 14496-10) 또는 MPEG-2 TS와 같은, 여러 개의 표준들 중 하나 이상에 따라 포맷화된 데이터의 일부분을 포함할 수 있다.
단일 MPU는 정수의 AU들 또는 비-타임드 데이터를 포함할 수 있다. 타임드 데이터의 경우, 단일 AU는 다수의 MPU들로 단편화되지 않을 수 있다. 비-타임드 데이터의 경우, 단일 MPU는 프레젠테이션 엔진에 의해 소비될 하나 이상의 비-타임드 데이터 항목들을 포함할 수 있다. MPU는 연관된 자산 식별(asset_id) 및/또는 시퀀스 번호에 의해 식별될 수 있다.
MMTP 페이로드의 태양들이 본 명세서에 기술된다. MMTP 페이로드는 MMT 프로토콜을 통한 패키지의 소비를 위해 MPU들, 일반 객체들, 및 다른 정보와 같은 매체 데이터를 패킷화하고 전달하는 데 사용되는 일반 페이로드일 수 있다. 적절한 MMTP 페이로드 포맷은 MPU들, 일반 객체들, 및 시그널링 메시지들을 패킷화하는 데 사용될 수 있다.
MMTP 페이로드는 완전한 MPU들 또는 MPU들의 단편들, 시그널링 메시지들, 일반 객체들, AL-FEC 스킴들의 복구 심볼들, 또는 다른 데이터 유닛들 또는 구조들을 반송할 수 있다. 페이로드의 유형은 MMT 프로토콜 패킷 헤더에서 유형 필드에 의해 표시될 수 있다. 각각의 페이로드 유형에 대해, 전달을 위한 하나 이상의 데이터 유닛들, 및 추가적으로 또는 대안적으로, 유형 특정 페이로드 헤더가 정의될 수 있다. 예를 들어, MMTP 페이로드가 MPU 단편들을 반송할 때, MPU의 단편(예컨대, MFU)이 단일 데이터 유닛으로 간주될 수 있다. MMT 프로토콜은 동일한 데이터 유형을 갖는 다수의 데이터 유닛들을 단일 MMTP 페이로드로 집성할 수 있다. 그것은 또한 단일 데이터 유닛을 다수의 MMTP 패킷들로 단편화할 수 있다.
MFU는 타임드 데이터의 샘플 또는 서브샘플 또는 비-타임드 데이터의 항목일 수 있다. MFU는 타임드 데이터에 대한 AU보다 더 작을 수 있는 매체 데이터를 포함할 수 있고, 포함된 매체 데이터는 매체 디코더에 의해 프로세싱될 수 있다. MFU는 반송된 매체 데이터의 경계들에 대한 정보를 포함하는 MFU 헤더를 포함할 수 있다. MFU는 MPU 내부에서 MFU를 고유하게 구별하기 위한 식별자를 포함할 수 있다. 그것은 또한 동일한 MPU 내의 다른 MFU들에 대한 의존성 및 우선순위 정보를 제공할 수 있다.
MMTP 페이로드는 페이로드 헤더 및 페이로드 데이터를 포함할 수 있다. 일부 데이터 유형들은 단편화 및 집성을 허용할 수 있고, 이 경우에 단일 데이터 유닛이 다수의 단편들로 분할될 수 있거나 또는 데이터 유닛들의 세트가 단일 MMTP 패킷으로 전달될 수 있다.
최근에, 가상 현실(VR) 및 몰입형 비디오 및 3D 그래픽들과 같은 새로운 및 신생 매체 유형들에 상당한 관심이 있었다. 고품질 3D 포인트 클라우드들 및 몰입형 비디오들은 몰입형 매체의 진보된 표현들을 제공하여, 가상 세계들과의 새로운 형태들의 상호작용 및 통신을 가능하게 한다. 이들 새로운 매체 유형들을 표현하는 데 필요한 많은 양의 정보는 효율적인 코딩 알고리즘들을 요구할 수 있다. 비디오 기반 포인트 클라우드 압축에 대한 새로운 표준들은 현재 개발 하에 있고, 시각적 볼류메트릭 비디오 기반 코딩(V3C)에 대한 기초를 형성할 것이다. 기하구조 기반 포인트 클라우드 압축에 대한 표준들이 또한 개발되고 있고, 압축된 정적 포인트 클라우드들에 대한 비트스트림들을 정의할 수 있다. 이와 동시에, V3C 매체들 및 기하구조 기반 포인트 클라우드 데이터의 반송을 정의하는 표준들이 또한 개발 하에 있다.
V3C 반송 및 포인트 클라우드 표준들을 둘러싸는 논의들은 V3C 데이터 및 포인트 클라우드 데이터의 저장 및 시그널링 태양들을 다룰 수 있지만, 그러한 논의들은, 그들이 예를 들어, MPEG-DASH 표준에 기초한 HTTP를 통한 동적 적응적 스트리밍을 위한 시그널링에만 관련될 수 있다는 점에서, 제한될 수 있다. 상이한 스트리밍 및 전달 애플리케이션들을 가능하게 하기 위한 다른 중요한 후보 표준은 MPEG 매체 전송(MMT)이다. 그러나, MMT 표준들은 현재, V3C 매체들에 대한 임의의 시그널링 메커니즘들을 제공하지 않을 수 있다. 따라서, 스트리밍 클라이언트들이 V3C 스트림들 및 그들의 컴포넌트 서브스트림들을 식별할 수 있게 하는 새로운 시그널링 요소들이 요구된다. 추가로, 스트리밍 클라이언트가, 임의의 주어진 시간에 소정의 네트워크 제약들 또는 사용자의 뷰포트를 고려하여 그것이 지원할 수 있거나 또는 전달될 수 있는 V3C 콘텐츠 또는 그의 컴포넌트들의 최선의 버전 또는 버전들을 선택하는 것을 가능하게 하는 V3C 컴포넌트들과 연관된 상이한 종류들의 메타데이터를 시그널링하는 것이 또한 필요할 수 있다.
또한, 실제 포인트 클라우드 애플리케이션들이 네트워크를 통해 포인트 클라우드 데이터를 스트리밍할 것을 요구할 것임이 구상된다. 그러한 애플리케이션들은, 콘텐츠가 어떻게 생성되었는지에 따라 포인트 클라우드 콘텐츠의 라이브 또는 주문형(on-demand) 스트리밍 중 어느 하나를 수행할 수 있다. 포인트 클라우드들을 표현하는 데 필요한 많은 양의 정보로 인해, 그러한 애플리케이션들은 네트워크를 오버로딩하는 것을 회피하고, 임의의 주어진 순간에, 예컨대 그러한 순간에서의 네트워크 용량에 대하여 최적의 뷰잉 경험을 제공하기 위해 적응적 스트리밍 기법들을 지원할 필요가 있을 수 있다. 추가적으로, 포인트 클라우드 콘텐츠의 컴포넌트들은 다수의 타일들로 분할될 수 있다. 하나 이상의 스트리밍 클라이언트들은, 예를 들어, 대역폭 이용가능성에 기초하여, (예컨대, 전체 포인트 클라우드 데이터 대신에) 기하구조 컴포넌트들의 특정 타일 부분을(예컨대, 그 부분만을) 스트리밍하기를 원할 수 있다(예컨대, 결정하거나 또는 선택할 수 있음). G-PCC 컴포넌트들 타일 데이터는 상이한 G-PCC 타일 트랙들에 캡슐화될 수 있다. (예컨대, 각각의) 타일 트랙은 G-PCC 컴포넌트 타일들의 세트 또는 모든 G-PCC 컴포넌트 타일들의 세트를 표현할 수 있다.
현재, MMT는, MPEG G-PCC 표준에 기초한 포인트 클라우드 스트림들을 포함하는, 포인트 클라우드 매체들에 대한 시그널링 메커니즘들을 제공하지 않는다. 따라서, 스트리밍 클라이언트들이 포인트 클라우드 스트림들 및 그들의 컴포넌트 서브스트림들을 식별할 수 있게 하는 새로운 시그널링 요소들을 정의하는 것이 중요하다. 또한, 스트리밍 클라이언트가, 지원할 수 있는 포인트 클라우드 또는 그의 컴포넌트들의 최상의 버전(들)을 선택할 수 있게 하기 위해 포인트 클라우드 컴포넌트들과 연관된 상이한 종류들의 메타데이터를 시그널링하는 것이 필요하다.
본 명세서에 기술된 솔루션들은, MMT 스트리밍 클라이언트들이, V3C 및 GPCC 매체 콘텐츠와 연관된 상이한 컴포넌트들 및 메타데이터를 식별하고, 클라이언트가 스트리밍 세션 동안 임의의 시점에 콘텐츠 서버로부터 취출할 필요가 있는 매체 데이터를 선택하는 것을 가능하게 하는 새로운 시그널링 요소들을 제공할 수 있다. 추가적으로, 본 명세서에 기술된 솔루션들은 MMT를 통한 G-PCC 데이터의 전달을 지원하기 위해 필요한 MMT 시그널링 메시지들 및 MMT 스트리밍을 위한 G-PCC 데이터의 캡슐화를 위한 다양한 방법들을 제공할 수 있다.
V3C 콘텐츠의 MMT 전달이 본 명세서에 추가로 기술된다. V3C 콘텐츠는 스트리밍 프로세스 동안 MMT 전송용 엔티티를 보조할 수 있다. 예를 들어, 프레젠테이션 정보는 애플리케이션에 의한 적절한 프로세싱을 가능하게 하기 위해 V3C와 부합하는 MPU들을 설명하기 위한 정보를 포함할 수 있다.
플레이어는, 실행되고 있는 디바이스에 대한 디스플레이의 현재 뷰잉 방향, 현재 뷰포트, 및 특성들에 관한 정보를 수신할 수 있다. 이러한 정보에 기초하여, 뷰-의존적 스트리밍이 스트리밍 세션에서 필요한 대역폭을 감소시키는 데 사용될 수 있다. MMT의 경우에, 뷰-의존적 스트리밍은 하나 이상의 접근법들에 의해 달성될 수 있다.
일부 클라이언트 기반 스트리밍 접근법들에서, MMT 수신용 엔티티는 현재 뷰포트 내에 속하는(또는 그와 교차하는) V3C 콘텐츠의 부분들을 렌더링하는 데 필요한 V3C 정보를 반송하는 자산들의 서브세트를 선택하기 위해 플레이어에 의해 지시받을 수 있다. MMT 세션 제어 절차들은 MMT 전송용 엔티티로부터 자산들의 선택된 세트를 요청하는 데 사용될 수 있다. 플레이어는 서버로부터의 V3C 애플리케이션 특정 시그널링 메시지들을 사용하여, 뷰-의존적 스트리밍을 위해 스위칭할 적절한 자산들을 선택할 수 있다.
일부 서버 기반 접근법들에서, MMT 수신용 엔티티는 현재 뷰포트를 커버하는 V3C 콘텐츠의 부분들을 렌더링하기 위해 V3C 정보를 제공하는 자산들의 정확한 서브세트를 선택하기 위해 MMT 전송용 엔티티에 의존할 수 있다. 수신용 엔티티는 현재 뷰포트에 관한 정보를 전송용 엔티티로 전송하기 위해 V3C 애플리케이션 특정 시그널링을 사용할 수 있다.
V3C 컨테이너들을 MMT 자산들에 맵핑하기 위한 방법들 및 절차들이 본 명세서에 기술된다. MMT를 사용한 V3C 콘텐츠의 전달을 지원하기 위해, 다중 트랙 ISOBMFF V3C 컨테이너 내부의 각각의 트랙은 별개의 자산으로서 캡슐화될 수 있다. 따라서, 자산들의 수는 컨테이너 내부의 트랙들의 수와 동일할 수 있다. 동일한 V3C 컴포넌트에 속하는 자산들은 자산 그룹들로 논리적으로 그룹화될 수 있다. 이들 자산 그룹들은, 스트리밍 클라이언트가 어느 자산 그룹들을 요청할지에 대한 결정들을 행하는 것을 가능하게 하기 위해 수신용 엔티티로 시그널링될 수 있다. V3C 애플리케이션 특정 MMT 시그널링이 본 명세서에 기술된다.
MMT를 사용하여 V3C 인코딩된 데이터를 스트리밍하기 위해, V3C 특정 MMT 메시지들의 수가 정의된다. 예를 들어, V3C 애플리케이션 특정 시그널링은, V3CAssetGroupMessage와 같은 그룹 메시지, V3CSelectionMessage와 같은 선택 메시지, 또는 V3CViewChangeFeedbackMessage와 같은 변경 뷰 피드백 메시지의 전송을 포함할 수 있다. 일부 실시예들에서, 이들 메시지들은 예를 들어, URN(uniform resource name) "urn:mpeg:mmt:app:v3c:2020"을 갖는 애플리케이션 식별자를 포함할 수 있으며, 이는 전송용 엔티티가 V3C 애프리케이션과 시그널링을 연관시키는 것을 가능하게 할 수 있다.
도 19는 정의된 애플리케이션 메시지 유형들의 목록을 제공하는 표이다. 제안된 MMT V3C 시그널링에서, 애플리케이션 메시지 유형들의 세트가 정의될 수 있고, 세트의 각각의 메시지 유형은 도 19에 도시된 바와 같이 애플리케이션 메시지 명칭과 연관될 수 있다. V3CAssetGroupMessage를 통해, 전송용 엔티티는 서버에서 이용가능한 자산들의 세트에 관하여 클라이언트에 통지하고, 스트리밍되고 있는 그들 자산들의 목록을 수신용 엔티티에 제공할 수 있다. V3CSelectionMessage에서, 클라이언트는 전송용 엔티티에 의해 수신용 엔티티로 스트리밍될 자산들의 세트를 요청할 수 있다. V3CViewChangeFeedbackMessage에서, 클라이언트는 서버 기반 뷰-의존적 스트리밍 세션에서 사용자의 현재 뷰잉 방향 및 뷰포트의 표시를 서버로 전송할 수 있다.
MMT를 통해 V3C 콘텐츠를 전송할 때, 일부 실시예들에서, V3CAssetGroupMessage는 필수적일 수 있고, V3C 콘텐츠와 연관되는 서버에서 이용가능한 자산들의 목록을 수신용 엔티티에 제공할 수 있다. 이러한 메시지는 또한, 이들 자산들 중 어느 자산이 현재 수신용 엔티티로 스트리밍되고 있는지에 관하여 수신용 엔티티에 통지하는 데 사용될 수 있다. 이러한 목록으로부터, 수신용 엔티티 상에서 실행되는 클라이언트는 V3CSelectionMessage 메시지를 사용하여 이들 V3C 자산들의 고유한 서브세트를 요청할 수 있다.
MMT를 통한 V3C 콘텐츠의 뷰-의존적 전달을 위해, 클라이언트는 V3CViewChangeFeedbackMessage 메시지를 사용하여 그의 현재 뷰포트 정보를 서버로 전송할 수 있고, 그 후에 서버는 그러한 뷰포트에 대응하는 자산들을 선택하여 클라이언트에 전달할 수 있다. V3CAssetGroupMessage는 또한 자산들의 선택된 서브세트에 관해 클라이언트를 업데이트하는 데 사용될 수 있다. 도 20은 V3C 자산 디스크립터의 신택스 구조의 일례를 제공하는 표이다. 자산 디스크립터는 V3C 콘텐츠를 반송하는 자산의 콘텐츠에 관하여 수신용 엔티티 및 소비용 애플리케이션에 통지하는 데 사용될 수 있다. V3C 자산 디스크립터의 시맨틱들이 본 명세서에 제공된다. 디스크립터 태그, 예컨대 "Descriptor_tag"는 디스크립터의 유형을 나타낼 수 있다. 디스크립터 길이, 예컨대 "Descriptor_length"는, 이러한 필드 이후의 다음 바이트로부터 디스크립터의 마지막 바이트까지 카운트하는 바이트 단위의 길이를 특정할 수 있다. 데이터 유형, 예컨대 "Data_type"은 이러한 자산에 존재하는 V3C 데이터의 유형을 나타낼 수 있다. 이러한 필드에 대한 값들은 도 22에 추가로 예시되고, 실질적으로 하기의 단락들에서 도입 및 설명될 수 있다. 의존성 플래그, 예컨대 "Dependency_flag"는, V3C 자산이 디코딩을 위해 다른 V3C 자산에서의 데이터에 의존하는지 여부를 나타낼 수 있다. 0의 값은, 이러한 V3C 컴포넌트 자산 그룹 데이터가 독립적으로 디코딩될 수 있다는 것을 나타낼 수 있다. 1의 값은, 이러한 V3C 자산이 디코딩을 위해 다른 V3C 자산 데이터에 의존한다는 것을 나타낼 수 있다. 대체 그룹 플래그, 예컨대 "Alternate_group_flag"는, 이러한 V3C 자산이 대체 버전을 갖는지 또는 그렇지 않은지를 나타낼 수 있다. 0의 값은, 이러한 V3C 컴포넌트 자산이 어떠한 대체 자산도 갖지 않음을 나타낼 수 있다. 1의 값은, 이러한 V3C 자산이 하나 이상의 대체들을 갖는다는 것을 나타낼 수 있다. 대체 그룹 ID, 예컨대 "Alternate_group_id"는 대체 자산들의 그룹을 식별하는 ID를 나타낼 수 있다. 동일한 V3C 자산의 상이한 인코딩된 버전들은 이러한 필드에 대해 동일한 값을 가질 수 있다. 의존적 자산 ID, 예컨대 "Dep_asset_id"는 이러한 자산의 디코딩이 의존하는 자산 ID의 값을 나타낼 수 있다. 일부 경우들에서, 이러한 값은, dependency_flag가 1로 설정될 때에만 존재할 수 있다. 예를 들어, V3C 비디오 컴포넌트 자산들은 이러한 필드에 대한 대응하는 V3C 아틀라스 컴포넌트 자산 ID를 사용할 수 있다. "Num_tiles"는 이러한 자산에서 반송되는 타일들의 수를 나타낼 수 있다. "Tile_id"는 특정 아틀라스 타일에 대한 고유 식별자를 나타낼 수 있다.
도 21은 V3CAssetGroupMessage의 예시적인 신택스를 예시하는 표이다. 도 21의 표와 부합하여, V3CAssetGroupMessage의 시맨틱들은 다음과 같이 설명될 수 있다. "Message_id"는 V3C 애플리케이션 메시지의 식별자를 나타낼 수 있다. "Version"은 V3C 애플리케이션 메시지의 버전을 나타낼 수 있다. "Length"는, 다음 필드의 시작으로부터 메시지의 마지막 바이트까지 카운트하는, 바이트 단위의 V3C 애플리케이션 메시지의 길이를 나타낼 수 있다. 이러한 필드의 값은 0과 동일하지 않을 수 있다. 애플리케이션 식별자, 예컨대 "Application_identifier"는, 이러한 메시지의 콘텐츠를 소비하기 위해 애플리케이션을 고유하게 식별하는 URN으로서 애플리케이션 식별자를 나타낼 수 있다. "App_message_type"은, 도 19와 관련하여 실질적으로 상기에서 설명된 바와 같이, 애플리케이션 특정 메시지 유형을 나타낼 수 있다. "Num_v3c_asset_groups"는 V3C 자산 그룹들의 수를 나타낼 수 있으며, 여기서 각각의 그룹은 V3C 컴포넌트와 연관된 자산들을 포함한다. "Asset_group_id"는 V3C 컴포넌트와 연관된 자산 그룹의 식별자를 나타낼 수 있다. "Num_assets"은 V3C 컴포넌트와 연관되는 자산 그룹 내의 자산들의 수를 나타낸다. "Start_time"은, 이러한 메시지에 열거된 자산들의 상태가 적용가능한 V3C 컴포넌트의 프레젠테이션 시간을 나타낼 수 있다. "Data_type"은 이러한 자산 그룹에 존재하는 V3C 데이터의 유형을 나타낼 수 있다. 이러한 필드에 대한 값들의 예들은 도 22의 맥락에서 설명되고, 뒤따르는 단락들에서 실질적으로 도입 및 설명될 수 있다. "Pending_flag"는, 모든 데이터 컴포넌트들이 자산 그룹에 대해 렌더링할 준비가 되어있는지 여부를 나타낼 수 있다. 예를 들어, "1"로 설정될 때, 그것은 데이터가 준비되었음을 나타낼 수 있고, 그렇지 않은 경우 플래그는 "0"일 수 있다. "Asset_id"는 자산의 자산 식별자를 제공할 수 있다. "State_flag"는 자산의 전달 상태를 나타낼 수 있다. 일("1")로 설정될 때, 이것은, 전송용 엔티티가 자산을 수신용 엔티티로 능동적으로 전송하고 있음을 나타낼 수 있다. 영("0")으로 설정될 때, 이것은, 전송용 엔티티가 자산을 수신용 엔티티로 능동적으로 전송하고 있지 않음을 나타낼 수 있다. "Sending_time_flag"는, 자산 스트림의 제1 MPU를 포함하는 제1 MMTP 패킷에 대한 "sending_time"의 존재를 나타낼 수 있다. 디폴트 값은 "0"일 수 있다. "Alternate_group_flag"는, 이러한 V3C 컴포넌트 자산이 대체 버전을 갖는지 또는 그렇지 않은지를 나타낼 수 있다. 0의 값은, 이러한 V3C 자산이 어떠한 대체 자산도 갖지 않음을 나타낼 수 있다. 1의 값은, 이러한 V3C 자산이 대체 자산을 갖는다는 것을 나타낼 수 있다. 의존성 플래그, 예컨대 "Dependency_flag"는, 이러한 V3C 컴포넌트 자산이 디코딩을 위해 다른 V3C 자산들에서의 데이터에 의존하는지 여부를 나타낼 수 있다. 0의 값은, 이러한 V3C 컴포넌트 자산 그룹 데이터가 독립적으로 디코딩될 수 있다는 것을 나타낼 수 있다. 1의 값은, 이러한 V3C 자산이 디코딩을 위해 다른 V3C 자산 데이터에 의존한다는 것을 나타낼 수 있다. 전송 시간, 예컨대 "Sending_time"은 자산 스트림의 제1 MPU를 포함하는 제1 MMTP 패킷에 대한 전송 시간을 나타낼 수 있다. 이러한 정보를 사용하여, 클라이언트는 새로운 자산 스트림에 대한 새로운 패킷 프로세싱 파이프라인을 준비할 수 있다. "Alternate_group_id"는 대체 V3C 컴포넌트 자산들의 식별자를 나타낼 수 있다. 동일한 V3C 자산의 상이한 인코딩된 버전들은 이러한 필드에 대해 동일한 값을 가질 수 있다. "Dep_asset_group_id"는 이러한 자산의 디코딩이 의존하는 자산에 대한 ID를 나타낼 수 있다. 일부 경우들에서, 이러한 값은, 예를 들어, dependency_flag가 1로 설정될 때에만 존재할 수 있다. 예를 들어, V3C 속성 컴포넌트 자산은 이러한 필드에 대한 대응하는 V3C 아틀라스 컴포넌트 자산 ID를 사용할 수 있다. "All_tiles_present_flag"는, 아틀라스 컴포넌트에 대한 모든 타일들이 자산의 일부인지 또는 그렇지 않은지를 나타낼 수 있다. 1의 값은, 모든 아틀라스 타일들에 대한 데이터가 자산에서 이용가능하다는 것을 나타낼 수 있다. 0의 값은, 아틀라스 타일들의 서브세트에 대한 데이터가 자산에서 이용가능하다는 것을 나타낼 수 있다. "Num_tiles"는 이러한 자산에서 반송되는 타일들의 수를 나타낼 수 있다. "Tile_id"는 특정 아틀라스 타일에 대한 고유 식별자를 제공할 수 있다.
도 22는 Data_type 필드에서 사용될 수 있는 바와 같은 V3C 데이터 유형 값들의 일례를 예시하는 표이다. 도 22에 도시된 바와 같이, Data_type 필드에 대한 값들은 모든 V3C 컴포넌트 데이터, 아틀라스 컴포넌트 데이터, 점유도 컴포넌트 데이터, 기하구조 컴포넌트 데이터, 속성 컴포넌트 데이터, 코덱 초기화 데이터, 동적 볼류메트릭 타임드 메타데이터 정보, 또는 뷰포트 타임드 메타데이터 정보를 나타낼 수 있다.
도 23은 V3CSelectionMessage의 예시적인 신택스를 예시하는 표이다. 도 23의 표와 부합하여, V3CSelectionMessage의 시맨틱들은 다음과 같이 설명될 수 있다. "Message_id"는 V3C 애플리케이션 메시지의 식별자를 나타낼 수 있다. "Version"은 V3C 애플리케이션 메시지의 버전을 나타낼 수 있다. "Length"는, 예를 들어, 다음 필드의 시작으로부터 메시지의 마지막 바이트까지 카운트하는, 바이트 단위의 V3C 애플리케이션 메시지의 길이를 나타낼 수 있다. 이러한 필드의 값은 0과 동일하지 않을 수 있다. "Application_identifier"는, 이러한 메시지의 콘텐츠를 소비하기 위해 애플리케이션을 고유하게 식별하는 URN으로서 애플리케이션 식별자를 나타낼 수 있다. "App_message_type"은, 도 19와 관련하여 상기의 단락들에서 실질적으로 설명된 바와 같이, 애플리케이션 특정 메시지 유형을 나타낼 수 있다. "Num_selected_asset_groups"은 수신용 엔티티에 의한 연관된 상태 변경 요청이 존재하는 자산 그룹들의 수를 나타낼 수 있다. "Asset_group_id"는 V3C 콘텐츠와 연관된 자산 그룹의 식별자를 나타낼 수 있다. "Switching_mode"는 수신용 엔티티에 의해 요청된 바와 같이 자산들의 선택에 사용되는 스위칭 모드를 나타낼 수 있다. 예를 들어, 도 23을 도입하고 설명하는 하기의 단락들과 부합하여, "switching_mode"에 대한 값들의 목록이 정의될 수 있다. "Num_assets"은 특정된 스위칭 모드에 따라 상태 변경에 대해 시그널링된 자산들의 수를 나타낼 수 있다. "Asset_id"는 특정된 스위칭 모드에 따라 상태 변경에 대한 자산에 대한 식별자를 나타낼 수 있다.
도 24는 switching_mode 필드의 정의들을 제공하는 표이다. 도 24에 도시된 바와 같이, "switching_mode" 필드는 자산들의 선택에 사용되는 스위칭 모드를 나타낼 수 있다. 예를 들어, 스위칭 모드가 리프레시로 설정되는 경우, V3CSelectionMessage에 열거된 각각의 자산에 대해, 각각의 자산의 State_flag는 '1'로 설정될 것인 반면, V3CSelectionMessage에 열거되지 않은 모든 자산들의 State_flag는 '0'으로 설정될 것이다. 스위칭 모드가 토글로 설정되는 경우, V3CSelectionMessage에 열거된 각각의 자산에 대해, 각각의 자산의 State_flag는 예컨대, 원래 '0'인 경우 '1'로 그리고 원래 '1'인 경우 '0'으로 변경될 것인 반면, V3CSelectionMessage에 열거되지 않은 모든 자산들의 State_flag는 변경되지 않을 것이다. 스위칭 모드가 전부를 전송하도록 설정되는 경우, V3CSelectionMessage에 특정된 자산 그룹의 모든 자산들에 대해, 각각의 자산의 State_flag는 '1'로 설정될 것이다.
도 25는 V3CViewChangeFeedbackMessage의 예시적인 신택스를 예시하는 표이다. 도 25의 표와 부합하여, V3CViewChangeFeedbackMessage의 시맨틱들은 다음과 같이 설명될 수 있다. "Message_id"는 V3C 애플리케이션 메시지의 식별자를 나타낼 수 있다. "Version"은 V3C 애플리케이션 메시지의 버전을 나타낼 수 있다. "Length"는, 다음 필드의 시작으로부터 메시지의 마지막 바이트까지 카운트하는, 바이트 단위의 V3C 애플리케이션 메시지의 길이를 나타낼 수 있다. 이러한 필드의 값은 0과 동일하지 않을 것이다. "Application_identifier"는, 이러한 메시지의 콘텐츠를 소비하기 위해 애플리케이션을 고유하게 식별하는 URN으로서 애플리케이션 식별자를 나타낼 수 있다. "App_message_type"은, 도 19와 관련하여 상기의 단락들에서 실질적으로 설명된 바와 같이, 애플리케이션 특정 메시지 유형을 나타낼 수 있다. "Vp_pos_x", "vp_pos_y", 및 "vp_pos_z"는 글로벌 기준 좌표계에서 뷰포트의 포지션의 x, y, 및 z 좌표들을 미터 단위로 각각 나타낼 수 있다. 값들은, 예를 들어, 2-16 미터 단위로 제공될 수 있다. "Vp_quat_x", "vp_quat_y", 및 "vp_quat_z"는 4원수 표현(quaternion representation)을 사용하여 뷰포트 영역의 회전의 x, y, 및 z 성분들을 각각 나타낼 수 있다. 값들은 -1 내지 1(이를 포함함) 범위 내의 부동 소수점 값들일 수 있다. 이들 값들은 4원수 표현을 사용하여 글로벌 좌표 축들을 카메라의 로컬 좌표 축들로 변환하기 위해 적용되는 회전들에 대해 x, y 및 z 성분들, 즉 qX, qY 및 qZ를 특정할 수 있다. 4원수의 제4 컴포넌트 qW가 수식 1에 따라 계산될 수 있다:
수식 (1)
포인트 (w,x,y,z)는 일정 각도만큼의 벡터 (x, y, z)가 향하는 축 주위의 회전을 나타낼 수 있으며, 이는 수식 2에 따라 결정될 수 있다
. 수식 (2)
"Clipping_near_plane" 및 "clipping_far_plane"는 뷰포트의 근거리 및 원거리 클리핑 평면들에 기초하여 근거리 및 원거리 깊이들(또는 거리들)을 미터 단위로 나타낼 수 있다. "Horizontal_fov"는, 예를 들어, 뷰포트 영역의 수평 크기에 대응하는 경도 범위를 라디안 단위로 특정할 수 있다. 그 값은 0 내지 2π의 범위에 있을 수 있다. "Vertical_fov"는, 예를 들어, 뷰포트 영역의 수직 크기에 대응하는 위도 범위를 라디안 단위로 특정할 수 있다. 그 값은 0 내지 π의 범위에 있을 수 있다.
스트리밍 클라이언트 거동에 관련한 방법들 및 장치들이 본 명세서에 기술된다. MMT 클라이언트는 애플리케이션 특정 시그널링 메시지들에 제공된 정보에 의해 안내될 수 있다. 다음은 본 문헌에 제시된 MMT 시그널링을 사용하여 V3C 콘텐츠를 스트리밍하기 위한 클라이언트 거동의 일례이다.
일부 방법들에서, MMT 전송용 엔티티는 "V3CAssetGroupMessage" 애플리케이션 메시지를 관심 클라이언트들에 전송할 수 있다. 수신용 클라이언트는 "V3CAssetGroupMessage"애플리케이션 메시지를 파싱하고, MMT 콘텐츠 전송용 엔티티에 존재하는 V3C 매체 자산들을 식별할 수 있다. 이용가능한 V3C 매체 콘텐츠를 식별하기 위해, 스트리밍 클라이언트는 "urn:mpeg:mmt:app:v3c:2020"로 설정된 "V3CAssetGroupMessage" 애플리케이션 메시지 내의 "application_identifier" 필드를 체크할 수 있다. V3C 콘텐츠에서 이용가능한 V3C 자산들 중 전부 또는 일부는 "V3CAssetGroupMessage" 애플리케이션 메시지에서 시그널링된 자산 ID들을 체크함으로써 식별될 수 있다. 클라이언트는, 사용자의 현재 뷰포트에 기초하여 스트리밍될 필요한 자산들을 선택할 수 있다. MMT 클라이언트는 이용가능한 V3C 자산들의 목록으로부터 그것이 관심 있는 V3C 자산들을 요청하는 "V3CSelectionMessage" 애플리케이션 메시지를 전송용 엔티티로 전송할 수 있다. MMT 전송용 엔티티는 MTP들을 갖는 MMTP 패킷들을 형성하고, MTTP 패킷들을 클라이언트들로 전송할 수 있다.
일부 방법들에서, MMT 클라이언트는 MMTP 패킷들을 수신하고, MTU들 또는 MFU들을 패킷화해제할 수 있다. MPU들/MFU들은 타임드 또는 비-타임드 V3C 매체 콘텐츠를 포함할 수 있다. MMT 클라이언트가 "0x05"로 설정된 자산 그룹 "data_type"을 갖는 MMTP 패킷들을 수신할 때, 이러한 V3C 자산 데이터는 VPS, ASPS, AAPS, AFPS 및 SEI 메시지들과 같은 초기화 정보를 표현한다. MMT 클라이언트가 "0x06"로 설정된 자산 그룹 "data_type"을 갖는 MMTP 패킷들을 수신할 때, 이러한 V3C 자산 데이터는 3D 공간 영역들 타임드 메타데이터 정보를 표현할 수 있다. 이러한 자산에서의 정보는 V3C 콘텐츠의 부분적 액세스를 위해 사용될 수 있다. MMT 클라이언트가 "0x07"로 설정된 자산 그룹 "data_type"을 갖는 MMTP 패킷들을 수신할 때, 이러한 V3C 자산 데이터는 초기 또는 추천된 뷰포인트 정보를 나타낼 수 있다. 이러한 정보는 상이한 기준들에 기초하여 자동 뷰포트 변경들을 가능하게 하는 데 사용될 수 있다. MMT 클라이언트는, 예를 들어, 사용자의 뷰포트 또는 추천된 뷰포트 및 대응하는 3D 공간 영역 또는 영역들에 기초하여, 요구되는 V3C 자산들을 선택할 수 있다. MMT 클라이언트는 관심 있는 V3C 자산들을 요청하는 "V3CSelectionMessage" 애플리케이션 메시지를 전송용 엔티티로 전송할 수 있다.
일부 방법들에서, 사용자의 뷰포트가 클라이언트 기반 스트리밍 접근법에서 변경될 때, MMT 클라이언트는 "V3CSelectionMessage" 애플리케이션 메시지를 사용하여 V3C 자산들의 상이한 세트를 요청할 수 있다. 사용자의 뷰포트가 서버 기반 스트리밍 접근법에서 변경될 때, MMT 클라이언트는 "V3CViewChangeFeedbackMessage" 메시지를 전송용 엔티티로 전송하여, 사용자의 현재 뷰포트를 시그널링할 수 있다. 이러한 메시지를 수신할 시에, MMT 전송용 엔티티는 사용자의 새로운 뷰포트 정보에 기초하여 V3C 자산들의 새로운 세트를 선택하고, "V3CAssetGroupMessage" 애플리케이션 메시지를 대응하는 V3C 자산들을 갖는 MMT 클라이언트로 전송한다. MMT 전송용 엔티티는 V3C 자산 데이터를 MMTP 패킷들로서 스트리밍할 수 있다. MMT 클라이언트는 모든 그들 요청된 V3C 자산들에 대한 MMTP 패킷들을 수신하는 것을 시작하고, MMTP 페이로드로부터 MPU들 및 MFU들을 추출할 수 있다. MPU들 및 MFU들은 매체 샘플들을 직접 포함하거나 또는 매체 세그먼트들을 포함할 수 있다. MMT 클라이언트는 V3C 표준에 따라 기본 스트림 정보를 추출하고 V3C 비트스트림을 구조화하기 위해 매체들 세그먼트 컨테이너(예컨대, ISOBMFF)를 파싱하는 것을 시작할 수 있다. 비트스트림은 V3C 디코더로 전달될 수 있다. MMTP 페이로드가 V3C 매체 샘플들을 포함할 때, 기본 스트림 데이터는 V3C 비트스트림 표준에 따라 추출되고 구조화된다. 비트스트림은 V3C 디코더로 전달될 수 있다.
MMT에서의 G-PCC 데이터의 캡슐화 및 시그널링에 관한 실시예들이 본 명세서에 기술된다. 전통적인 매체 콘텐츠와 달리, G-PCC 매체 콘텐츠는 기하구조 및 속성들과 같은 다수의 컴포넌트들을 포함할 수 있다. 각각의 컴포넌트는 G-PCC 비트스트림의 서브스트림으로서 별개로 인코딩될 수 있다. 기하구조 및 속성들과 같은 컴포넌트들은 GPCC 인코더를 사용하여 인코딩될 수 있다. 그러나, 이들 서브스트림들은, 포인트 클라우드를 렌더링하기 위해 추가적인 메타데이터와 함께 집합적으로 디코딩될 필요가 있을 수 있다.
G-PCC 인코딩된 콘텐츠는 MMT를 사용하여 네트워크들을 통해 전달될 수 있다. ISOBMFF 내부의 G-PCC 컴포넌트들이 다수의 트랙들을 사용하여 시그널링될 때, 각각의 트랙은 별개의 자산으로 캡슐화되도록 제안될 수 있고, 이는 이어서 통상적인 방식으로 MMTP 패킷들로 패킷화될 수 있다. 서버 및 클라이언트가 소정 G-PCC 컴포넌트에 대한 다수의 자산들의 그룹을 식별할 수 있도록 하기 위해, G-PCC 정의된 애플리케이션 메시지가 또한 제안된다.
G-PCC 매체 콘텐츠는, 기하구조 및 속성들과 같은 하나 이상의(예컨대, 다수의) 컴포넌트들을 포함할 수 있다. (예컨대, 각각의) 컴포넌트는 G-PCC 비트스트림의 서브스트림으로서 (예컨대, 별개로) 인코딩될 수 있다. 기하구조 및 속성들과 같은 컴포넌트들은 GPCC 인코더를 사용하여 인코딩될 수 있다. 서브스트림들은, 예컨대 포인트 클라우드를 렌더링하기 위해 추가적인 메타데이터와 함께 집합적으로 디코딩될 수 있다.
G-PCC 데이터는 MMT에서 캡슐화되고 시그널링될 수 있다. G-PCC 인코딩된 콘텐츠는 MMT를 사용하여 네트워크들을 통해 전달될 수 있다. G-PCC 데이터는 (예컨대, 본 명세서에 기술된 바와 같이) 다양한 캡슐화 방법들을 사용하여 MMT 스트리밍을 위해 캡슐화될 수 있다. MMT 시그널링 메시지들은 MMT를 통한 G-PCC 데이터의 전달을 지원할 수 있다(예컨대, 이를 위해 생성 및 송신될 수 있음).
ISOBMFF 내부의 G-PCC 컴포넌트들은 다수의 트랙들을 사용하여 시그널링될 수 있다. (예컨대, 다수의 트랙들 사이에서) (예컨대, 각각의) 트랙은 별개의 자산에 캡슐화될 수 있고, 이는 (예컨대, 이어서) MMTP 패킷들로 패킷화될 수 있다. G-PCC 정의된 애플리케이션 메시지는 (예컨대, 또한), 예를 들어, 서버 및 클라이언트가 다수의 자산들의 그룹을 소정 G-PCC 컴포넌트로 또는 이에 대해 식별하기 위해 구성/배치될 수 있다.
일부 예들에서, (예컨대, MMT를 사용한 G-PCC 콘텐츠의 전달을 지원하기 위해) 다중 트랙 ISOBMFF G-PCC 컨테이너 내부의 (예컨대, 각각의) 트랙이 별개의 자산에 캡슐화될 수 있다. 자산들의 수는 멀티트랙 ISOBMFF G-PCC 컨테이너 내부의 트랙들의 수와 동일할 수 있다. 일부 예들에서, (예컨대, 단일) G-PCC 컴포넌트에 대응하는 다수의 자산들은 메시지(예컨대, "GPCCAssetGroupMessage" 애플리케이션 메시지) 내의 자산 그룹으로서 그룹화되고 시그널링될 수 있다. 대안의 컴포넌트 트랙들은 (예컨대, 또한) (예컨대, "GPCCAssetGroupMessage" 메시지를 사용하여) 메시지에 노출되어, 예를 들어, (예컨대, MMTP 패킷 내부의 ISOBMFF 파일을 먼저 파싱하지 않고서) (예컨대, 효율적인) 서버 및 클라이언트 선택 결정들을 가능하게 할 수 있다.
MMT는 애플리케이션 특정 시그널링 메시지들을 정의할 수 있으며, 이는 애플리케이션 특정 정보의 전달을 지원할 수 있다(예컨대, 허용할 수 있음). G-PCC 특정 시그널링 메시지가 MMT를 사용하여 G-PCC 인코딩된 데이터를 스트리밍하도록 정의될 수 있다(예컨대, 구성될 수 있음). G-PCC 특정 시그널링 메시지는 URN 값(예컨대, "urn:mpeg:mmt:app:gpcc:2020"의 URN 값)을 갖는 애플리케이션 식별자를 가질 수 있다.
도 26은 G-PCC 자산 디스크립터의 신택스 구조의 일례를 제공하는 표이다. 자산 디스크립터는 G-PCC 콘텐츠를 반송하는 자산의 콘텐츠에 관하여 수신용 엔티티 및 소비용 애플리케이션에 통지하는 데 사용될 수 있다. G-PCC 자산 디스크립터의 시맨틱들이 본 명세서에 제공된다. "Descriptor_tag"는 디스크립터의 유형을 나타낼 수 있다. "Descriptor_length"는, 이러한 필드 이후의 다음 바이트로부터 디스크립터의 마지막 바이트까지 카운트하는 바이트 단위의 길이를 특정할 수 있다. "Data_type"은 이러한 자산에 존재하는 G-PCC 데이터의 유형을 나타낼 수 있다. 이러한 필드에 대한 값들은 도 29에 추가로 예시되고, 실질적으로 하기의 단락들에서 도입 및 설명될 수 있다. "Dependency_flag"는, G-PCC 자산이 디코딩을 위해 다른 G-PCC 자산에서의 데이터에 의존하는지 여부를 나타낼 수 있다. 0의 값은, 이러한 G-PCC 컴포넌트 자산 그룹 데이터가 독립적으로 디코딩될 수 있다는 것을 나타낼 수 있다. 1의 값은, 이러한 G-PCC 자산이 디코딩을 위해 다른 G-PCC 자산 데이터에 의존한다는 것을 나타낼 수 있다. "Alternate_group_flag"는, 이러한 G-PCC 자산이 대체 버전을 갖는지 또는 그렇지 않은지를 나타낼 수 있다. 0의 값은, 이러한 G-PCC 컴포넌트 자산이 어떠한 대체 자산도 갖지 않음을 나타낼 수 있다. 1의 값은, 이러한 G-PCC 자산이 하나 이상의 대체 자산들을 갖는다는 것을 나타낼 수 있다. "Alternate_group_id"는 대체 자산들의 그룹을 식별하는 ID를 나타낼 수 있다. 동일한 G-PCC 자산의 상이한 인코딩된 버전들은 이러한 필드에 대해 동일한 값을 가질 수 있다. "Dep_asset_id"는 이러한 자산의 디코딩이 의존하는 자산 ID의 값을 나타낼 수 있다. 일부 경우들에서, 이러한 값은, dependency_flag가 1로 설정될 때에만 존재할 수 있다. 예를 들어, G-PCC 속성 컴포넌트 자산들은 이러한 필드에 대한 대응하는 G-PCC 기하구조 컴포넌트 자산 ID를 사용할 수 있다. "Num_tiles"는 이러한 자산에서 반송되는 타일들의 수를 나타낼 수 있다. "Tile_id"는, 타일 인벤토리 내의 특정 타일에 대한 고유 식별자를 나타낸다. dynamic_tile_flag가 값 0으로 설정될 때, tile_id는 타일 인벤토리에 존재하는 타일 id 값들 중 하나를 나타낼 수 있다.
MMT G-PCC 시그널링은, 예를 들어, (예컨대, 정의된) 애플리케이션 메시지 유형들의 다음의 세트들 중 하나 이상을 포함할 수 있다: GPCCAssetGroupMessage와 같은 그룹 메시지, GPCCSelectionMessageFeedback과 같은 선택 피드백 메시지, 및/또는 GPCCViewChangeFeedback과 같은 변경 뷰 피드백 메시지.
도 27은 정의된 G-PCC 애플리케이션 메시지 유형들의 예들을 예시하는 표이다. 도 27에 도시된 바와 같이, 애플리케이션 메시지 유형은, 메시지가 GPCCAssetGroupMessage, GPCCSelectionMessageFeedback 메시지, 또는 GPCCViewChangeFeedback 메시지임을 나타낼 수 있다. GPCCAssetGroupMessage 메시지 유형의 일례에서, 전송용 엔티티는 그룹 메시지(예컨대, GPCCAssetGroupMessage 메시지)를 전송하여, 서버에서 이용가능한 자산들의 세트, 및/또는 수신용 엔티티로 스트리밍될 수 있는(예컨대, 스트리밍되고 있는) 자산들의 목록에 관하여 클라이언트에게 통지할 수 있다. 선택 피드백 메시지 유형(예컨대, GPCCSelectionMessageFeedback 메시지 유형)의 일례에서, 클라이언트는 선택 피드백 메시지를 사용하여, 전송용 엔티티에 의해 수신용 엔티티로 스트리밍될 자산들의 세트를 요청할 수 있다. 변경 뷰 피드백 메시지(예컨대, GPCCViewChangeFeedback 메시지)의 일례에서, 클라이언트는 뷰 변경 피드백 메시지를 사용하여, 사용자의 현재 뷰잉 공간의 표시를 서버에 전송할 수 있다.
그룹 메시지(예컨대, GPCCAssetGroupMessage 메시지)는 MMT를 통해 G-PCC 인코딩된 콘텐츠를 전송하는 데 사용될 수 있다. 그룹 메시지(예컨대, GPCCAssetGroupMessage 메시지)는 서버에서 이용가능한 G-PCC 데이터 유형 자산들의 목록을 클라이언트에 제공할 수 있고/있거나, 자산들 중 어느 것이 수신용 엔티티로 스트리밍될 수 있는지(예컨대, 현재 스트리밍되고 있는지)에 관하여 클라이언트에 통지할 수 있다. 클라이언트는 G-PCC 데이터 유형 자산들의 고유 서브세트를 (예컨대, 목록으로부터) 요청할 수 있다. 요청은, 예를 들어, GPCCSelectionFeedback 메시지를 사용하여 이루어질 수 있다.
클라이언트는 (예컨대, MMT를 통한 G-PCC 콘텐츠의 뷰-의존적 전달을 위해) GPCCViewChangeFeedback 메시지를 사용하여, 예를 들어, 현재 뷰잉 공간(예컨대, 절단체(frustum)) 정보를 서버로 전송할 수 있다. 서버는 뷰잉 공간에 대응하는 자산들을 선택하고 클라이언트에 전달할 수 있다. GPCCAssetGroupMessage는 (예컨대, 또한) 업데이트되고 클라이언트에게 전송될 수 있다. 표 4는 정의된 G-PCC 애플리케이션 메시지 유형들의 예들을 제공한다.
도 28은 GPCCAssetGroupMessage와 같은, 그룹 메시지의 예시적인 신택스를 예시하는 표이다. 도 28의 표와 부합하여, GPCCAssetGroupMessage의 시맨틱들은 다음과 같을 수 있다. "Message_id"는 G-PCC 애플리케이션 메시지의 식별자를 나타낼 수 있다. "Version"은 G-PCC 애플리케이션 메시지의 버전을 나타낼 수 있다. "Length"는 G-PCC 애플리케이션 메시지의(예컨대, 다음 필드의 시작으로부터 메시지의 마지막 바이트까지 카운트하는, 바이트 단위의) 길이를 나타낼 수 있다. 길이 필드의 값은 영(0)과 동일하지 않을 수 있다. 애플리케이션 식별자(예컨대, "application_identifier")는, 예컨대 메시지의 콘텐츠를 소비하기 위해 애플리케이션의 유형을 (예컨대, 고유하게) 식별하는 URN으로서 애플리케이션 식별자를 나타낼 수 있다. 애플리케이션 메시지 유형(예컨대, "app_message_type")은 (예컨대, 표 4의 예에 의해 제공되는 바와 같은) 애플리케이션 특정 메시지 유형을 정의할 수 있다. 애플리케이션 메시지 유형 필드의 길이는, 예를 들어, 8 비트일 수 있다. G-PCC 자산 그룹들의 수(예컨대, "num_gpcc_asset_groups")는 G-PCC 자산 그룹들의 수를 나타낼 수 있다. (예컨대, 각각의) 자산 그룹은 G-PCC 컴포넌트와 연관된 자산들을 포함할 수 있다. 자산 그룹 식별자(예컨대, "asset_group_id")는 G-PCC 컴포넌트와 연관된 자산 그룹의 식별자를 나타낼 수 있다. 자산들의 수(예컨대, "num_assets")는 G-PCC 컴포넌트와 연관된 자산 그룹 내의 자산들의 수를 나타낼 수 있다. 시작 시간(예컨대, "start_time")은, 메시지에 열거된 자산들의 상태가 적용가능할 수 있는 G-PCC 컴포넌트의 프레젠테이션 시간을 나타낼 수 있다. 데이터 유형(예컨대, "data_type")은, 도 29와 관련하여 하기의 단락들에서 추가로 기술되는, 자산 그룹에 존재하는 G-PCC 포인트 클라우드 데이터의 유형을 나타낼 수 있다. 보류 중인 플래그(예컨대, "pending_flag")는, 예를 들어, (예컨대, 모든) 데이터 컴포넌트들이 자산 그룹에 대해 렌더링할 준비가 되어 있는지 여부를 나타낼 수 있다. "1"로 설정된 보류 중인 플래그는, 데이터가 준비되어 있음을 나타낼 수 있다. 영("0")으로 설정된 보류 중인 플래그는, 데이터가 준비되어 있지 않음을 나타낼 수 있다. 의존성 플래그(예컨대, "dependy_flag")는, G-PCC 컴포넌트 자산 그룹이 디코딩을 위해 다른 G-PCC 컴포넌트 자산 그룹 데이터에 의존하는지 여부를 나타낼 수 있다. 영("0")의 값은, G-PCC 컴포넌트 자산 그룹 데이터가 독립적으로 디코딩될 수 있다는 것을 나타낼 수 있다. 일("1")의 값은, G-PCC 컴포넌트 자산 그룹이 디코딩을 위해 다른 G-PCC 컴포넌트 자산 그룹 데이터에 의존한다는 것을 나타낼 수 있다. 의존적 자산 그룹 ID(예컨대, "dep_asset_group_id")는, 자산 그룹 콘텐츠 디코딩이 의존하는 자산 그룹 ID의 값을 나타낼 수 있다. 그 값은, 예를 들어, dependency_flag가 1로 설정되는 경우/결정될 때(예컨대, 그 경우에만/그 때에만) 존재할 수 있다. 예를 들어, G-PCC 속성 컴포넌트 자산 그룹은 의존적 자산 그룹 ID 필드에 대한 대응하는 G-PCC 기하구조 컴포넌트 자산 그룹 ID를 사용할 수 있다. 자산 ID(예컨대, "asset_id")는 자산의 자산 식별자를 제공할 수 있다. 대체 자산 그룹 플래그(예컨대, "alternate_asset_group_flag")는, G-PCC 컴포넌트 자산이 대체 버전을 갖는지 여부를 나타낼 수 있다. 영("0")의 값은, G-PCC 컴포넌트 자산이 대체 버전을 갖지 않음을 나타낼 수 있다. 일("1")의 값은, G-PCC 컴포넌트 자산이 대체 버전을 갖는다는 것을 나타낼 수 있다. 대체 그룹 플래그 필드의 값은, 예를 들어, 동일한 G-PCC 컴포넌트 및/또는 자산의 상이한 인코딩된 버전들이 비트스트림에서 이용가능한 경우/이용가능할 때, 일("1")로 설정될 수 있다. 대체 그룹 플래그 필드의 값은, 예를 들어, 동일한 G-PCC 컴포넌트 및/또는 자산의 상이한 인코딩된 버전들이 비트스트림에서 이용가능하지 않은 경우/이용가능하지 않을 때, 영("0")으로 설정될 수 있다. 대체 자산 그룹 ID(예컨대, "alternate_asset_group_id")는 대안적인 G-PCC 컴포넌트 자산들의 값(예컨대, 고유 값)을 나타낼 수 있다. G-PCC 컴포넌트 또는 자산의 상이한 인코딩된 버전들은 대체 자산 그룹 ID 필드에 대한 동일한 값을 나타낼 수 있다. 상태 플래그(예컨대, "state_flag")는 자산의 전달 상태를 나타낼 수 있다. 일("1")로 설정된 상태 플래그는, 전송용 엔티티가 자산을 수신용 엔티티로 능동적으로 전송하고 있음을 나타낼 수 있다. 영("0")으로 설정된 상태 플래그는, 전송용 엔티티가 자산을 수신용 엔티티로 능동적으로 전송하고 있지 않음을 나타낼 수 있다. 전송 시간 플래그(예컨대, "sending_time_flag")는 자산 스트림의 제1 MPU를 포함하는 제1 MMTP 패킷에 대한 전송 시간(예컨대, sending_time)의 존재를 나타낼 수 있다. 디폴트 값은, 예를 들어, 영("0")일 수 있다. 전송 시간(예컨대, "sending_time")은 자산 스트림의 제1 MPU를 포함하는 제1 MMTP 패킷에 대한 전송 시간을 나타낼 수 있다. 클라이언트(예컨대, 전송 시간 정보를 사용함)는 새로운 자산 스트림에 대한 새로운 패킷 프로세싱 파이프라인을 준비할 수 있다. 동적 타일 플래그(예컨대, "dynamic_tile_flag")는, 타일들의 수 및/또는 타일 식별자들이 자산에서 동적으로 변경될 수 있는지 여부를 나타낼 수 있다. 영("0")의 값은, 자산 내의 타일들의 수 및 타일 식별자들이 비트스트림 전체에 걸쳐 변경되지 않는다는 것 및/또는 타일들의 수(예컨대, "num_tiles") 및 타일 ID(예컨대, "tile_id")가 시그널링된다는 것을 나타낼 수 있다. 일("1")의 값은, 타일들의 수 및 타일 식별자들이 자산에서 변경될 수 있음을 나타낼 수 있다. 일("1")의 값은, 타일 트랙에 존재하는 타일 ID들이 비트스트림에서 시간에 따라 동적으로 변경되고 있음을 나타낼 수 있다. 타일들의 수(예컨대, "num_tiles")는 자산에서 반송되는 타일들의 수를 나타낼 수 있다. 타일 ID(예컨대, "tile_id")는 타일 인벤토리 내의 특정 타일에 대한 (예컨대, 고유) 식별자를 나타낼 수 있다. 타일 ID(예컨대, "tile_id")는, 예를 들어, 동적 타일 플래그(예컨대, "dynamic_tile_flag")가 영("0")의 값으로 설정되는 경우/설정될 때, 타일 인벤토리에 존재하는 타일 id 값들(예컨대, 이들 중 하나)을 표현할 수 있다.
도 29는 Data_type 필드에서 사용될 수 있는 바와 같은 G-PCC 데이터 유형 값들의 일례를 예시하는 표이다. 도 24에 도시된 바와 같이, Data_type 필드에 대한 값들은 모든 G-PCC 컴포넌트 데이터, 기하구조 데이터, 속성 데이터, SPS, GPS, APS, 및 타일 인벤토리 데이터, 또는 3D 공간 영역 타임드 메타데이터 정보를 나타낼 수 있다.
도 30은 GPCC 선택 피드백 메시지(예컨대, "GPCCSelectionFeedback")의 예시적인 신택스를 예시하는 표이다. 도 30의 표와 부합하여, GPCCSelectionFeedback 메시지의 시맨틱들은 다음과 같을 수 있다. 메시지 ID(예컨대, "message_id")는 G-PCC 애플리케이션 메시지의 식별자를 나타낼 수 있다. 버전(예컨대, "version")은 G-PCC 애플리케이션 메시지의 버전을 나타낼 수 있다. 길이(예컨대, "length")는 G-PCC 애플리케이션 메시지의(예컨대, 다음 필드의 시작으로부터 메시지의 마지막 바이트까지 카운트하는, 바이트 단위의) 길이를 나타낼 수 있다. 길이 필드의 값은 0과 동일하지 않을 수 있다. 애플리케이션 식별자(예컨대, "application_identifier")는, 예컨대 메시지의 콘텐츠를 소비하기 위해 애플리케이션의 유형을 (예컨대, 고유하게) 식별하는 URN으로서 애플리케이션 식별자를 나타낼 수 있다. 애플리케이션 메시지 유형(예컨대, "app_message_type")은 애플리케이션 특정 메시지 유형을 정의할 수 있다(예컨대, 도 27과 관련하여 상기 단락들에서 실질적으로 기술됨). 애플리케이션 메시지 유형 필드의 길이는, 예를 들어, 8 비트일 수 있다. 선택된 자산 그룹들의 수(예컨대, "num_selected_asset_groups")는, 수신용 엔티티에 의한 연관된 상태 변경 요청이 존재하는 자산 그룹들의 수를 나타낼 수 있다. 자산 그룹 ID(예컨대, "asset_group_id")는 G-PCC 콘텐츠와 연관된 자산 그룹의 식별자를 나타낼 수 있다. 스위칭 모드(예컨대, "switching_mode")는 (예컨대, 수신용 엔티티에 의해 요청된 바와 같은) 자산들의 선택에 사용되는 스위칭 모드를 나타낼 수 있다. 자산들의 수(예컨대, "num_assets")는 (예컨대, 특정된 스위칭 모드에 따라) 상태 변경에 대해 시그널링된 자산들의 수를 나타낼 수 있다. 자산 ID(예컨대, "asset_id")는 (예컨대, 특정된 스위칭 모드에 따라) 상태 변경에 대한 자산에 대한 식별자를 나타낼 수 있다.
도 31은 switching_mode 필드의 정의들을 제공하는 표이다. 도 31에 도시된 바와 같이, "switching_mode" 필드는 자산들의 선택에 사용되는 스위칭 모드를 나타낼 수 있다. 예를 들어, 스위칭 모드가 리프레시로 설정되는 경우, GPCCSelectionMessageFeedback에 열거된 각각의 자산에 대해, 각각의 자산의 State_flag는 '1'로 설정될 것인 반면, GPCCSelectionMessageFeedback에 열거되지 않은 모든 자산들의 State_flag는 '0'으로 설정될 것이다. 스위칭 모드가 토글로 설정되는 경우, GPCCSelectionMessageFeedback에 열거된 각각의 자산에 대해, 각각의 자산의 State_flag는 예컨대, 원래 '0'인 경우 '1'로 그리고 원래 '1'인 경우 '0'으로 변경될 것인 반면, GPCCSelectionMessageFeedback에 열거되지 않은 모든 자산들의 State_flag는 변경되지 않을 것이다. 스위칭 모드가 모두 전송으로 설정되는 경우, GPCCSelectionMessageFeedback에 특정된 자산 그룹의 모든 자산들에 대해, 각각의 자산의 State_flag는 '1'로 설정될 것이다.
도 32는 G-PCC 뷰 변경 피드백 메시지(예컨대, "GPCCViewChangeFeedback")의 예시적인 신택스를 예시하는 표이다. 도 32의 표와 부합하여, GPCCViewChangeFeedback 메시지의 시맨틱들은 다음과 같을 수 있다. 메시지 ID(예컨대, "message_id")는 G-PCC 애플리케이션 메시지의 식별자를 나타낼 수 있다. Version은 G-PCC 애플리케이션 메시지의 버전을 나타낼 수 있다. Length는 G-PCC 애플리케이션 메시지의(예컨대, 다음 필드의 시작으로부터 메시지의 마지막 바이트까지 카운트하는, 바이트 단위의) 길이를 나타낼 수 있다. 길이 필드의 값은 0과 동일하지 않을 수 있다. 애플리케이션 식별자(예컨대, "application_identifier")는, 예컨대 메시지의 콘텐츠를 소비하기 위해 애플리케이션의 유형을 (예컨대, 고유하게) 식별하는 URN으로서 애플리케이션 식별자를 나타낼 수 있다. 애플리케이션 메시지 유형(예컨대, "app_message_type")은 (예컨대, 표 4의 예에 의해 제공되는 바와 같은) 애플리케이션 특정 메시지 유형을 정의할 수 있다. 애플리케이션 메시지 유형 필드의 길이는, 예를 들어, 8 비트일 수 있다. 뷰포트 포지션 좌표들(예컨대, vp_pos_x, vp_pos_y, vp_pos_z)은 뷰포트의 포지션의 x, y 및 z 좌표들을 글로벌 기준 좌표계에서 미터 단위로 나타낼 수 있다. 값들은, 예를 들어, 2-16 미터 단위일 수 있다. 뷰포트 회전(예컨대, vp_quat_x, vp_quat_y, vp_quat_z)은 (예컨대, 4원수 표현을 사용하여) 뷰포트 영역의 회전의 x, y, 및 z 성분들을 나타낼 수 있다. 값들은, 예를 들어, -1 내지 1(이를 포함함) 범위 내의 부동 소수점 값들일 수 있다. 값들은 (예컨대, 4원수 표현을 사용하여) 글로벌 좌표 축들을 카메라의 로컬 좌표 축들로 변환하기 위해 적용되는 회전들에 대해 x, y 및 z 성분들(예컨대, qX, qY 및 qZ)을 특정할 수 있다. 4원수의 제4 컴포넌트 qW는, 예를 들어, 상기의 단락들에서 실질적으로 기술되는, 수식 1에 따라 계산될 수 있다. 포인트 (w,x,y,z)는, 상기의 단락들에서 실질적으로 또한 기술되는 수식 2에 따라 결정된 각도만큼의 벡터 (x, y, z)가 향하는 축 주위의 회전을 나타낼 수 있다.
근거리 평면에서의 클리핑(예컨대, clipping_near_plane) 및 원거리 평면에서의 클리핑(예컨대, clpiping_far_plane)은, 예를 들어, 뷰포트의 근거리 및 원거리 클리핑 평면들에 기초하여 근거리 및 원거리 깊이들 또는 거리들을 (예컨대, 미터 단위로) 나타낼 수 있다.
수평 시야(FOV)(예컨대, horizontal_fov)는 뷰포트 영역의 수평 크기에 대응하는 경도 범위를 (예컨대, 라디안 단위로) 특정할 수 있다. 그 값은 0 내지 2π의 범위에 있을 수 있다.
수직 FOV(예컨대, vertical_fov)는 뷰포트 영역의 수직 크기에 대응하는 위도 범위를 (예컨대, 라디안 단위로) 특정할 수 있다. 그 값은 0 내지 π의 범위에 있을 수 있다.
스트리밍 클라이언트 거동이 제공될 수 있다(예컨대, 정의되거나 구성될 수 있음). MMT 클라이언트는, 예를 들어, 애플리케이션 특정 시그널링 메시지들에 제공된 정보에 의해 안내될 수 있다. 클라이언트 거동의 일례는 (예컨대, 본 명세서에 개시된 MMT 시그널링의 일례를 사용하여) 기하구조 기반 포인트 클라우드 압축 콘텐츠를 스트리밍하기 위해 제공된다.
MMT 전송용 엔티티는 "GPCCAssetGroupMessage" 애플리케이션 메시지를 관심 클라이언트들에게 전송할 수 있다. 수신용 클라이언트는 "GPCCAssetGroupMessage"애플리케이션 메시지를 파싱하고, MMT 콘텐츠 전송용 엔티티에 존재하는 G-PCC 매체 자산들을 식별할 수 있다. 스트리밍 클라이언트는 예를 들어, 이용가능한 G-PCC 매체 콘텐츠를 식별하기 위해, (예컨대, "urn:mpeg:mmt:app:gpcc:2020"로 설정된) "GPCCAssetGroupMessage" 애플리케이션 메시지에서 "application_identifier" 필드를 체크할 수 있다. G-PCC 포인트 클라우드 콘텐츠에서 이용가능한 G-PCC 자산들(예컨대, 모든 G-PCC 자산들)은, 예를 들어, "GPCCAssetGroupMessage" 애플리케이션 메시지에 존재하는 asset_id들을 체크함으로써 식별될 수 있다. 클라이언트는, 예를 들어, 사용자 현재 뷰포트에 기초하여, 스트리밍될 asset_id들을 선정(예컨대, 선택)할 수 있다. MMT 클라이언트는 이용가능한 G-PCC 자산들의 목록으로부터 관심 있는 G-PCC 자산들을 요청하는 "GPCCSelectionFeedback" 애플리케이션 메시지를 전송용 엔티티로 전송할 수 있다. MMT 전송용 엔티티는 MTP들을 갖는 MMTP 패킷들을 형성할 수 있다. MMT 전송용 엔티티는 MTTP 패킷들을 클라이언트들로 전송할 수 있다. MMT 클라이언트는 MMTP 패킷들을 수신할 수 있다. MMT 클라이언트는 MPU들 또는 MFU들을 패킷화해제할 수 있다. MPU들/MFU들은 타임드 또는 비-타임드 G-PCC 매체 콘텐츠를 포함할 수 있다.
G-PCC 자산 데이터는, 예를 들어, MMT 클라이언트가 "3"으로 설정된 자산 그룹 "data_type"를 갖는 MMTP 패킷들을 수신하는 경우/수신할 때, 초기화 정보(예컨대, SPS, GPS, APS, 및/또는 타일 인벤토리)를 표현할 수 있다 G-PCC 자산 데이터는, 예를 들어, MMT 클라이언트가 "4"로 설정된 자산 그룹 "data_type"을 갖는 MMTP 패킷들을 수신하는 경우/수신할 때, 3D 공간 영역 타임드 메타데이터 정보를 표현할 수 있다 G-PCC 자산 정보는 G-PCC 데이터의 부분적 액세스를 위해 사용될 수 있다.
MMT 클라이언트는 사용자 뷰포트 및 대응하는 3D 공간 영역(들)에 기초하여 G-PCC 자산들을 선택할 수 있다. MMT 클라이언트는 관심 있는 G-PCC 자산들을 요청하는 "GPCCSelectionFeedback" 애플리케이션 메시지를 전송용 엔티티로 전송할 수 있다. MMT 클라이언트는, 예를 들어, 사용자 뷰포트가 변경되는 경우/변경될 때, (예컨대, "GPCCSelectionFeedback" 애플리케이션 메시지를 사용하여) G-PCC 자산들의 상이한 세트를 요청할 수 있다.
MMT 클라이언트는, 예를 들어, 사용자 뷰포트가 변경되는 경우/변경될 때, (예컨대, 사용자의 현재 뷰포트를 시그널링하기 위해) "GPCCViewChangeFeedback" 메시지를 전송용 엔티티로 전송할 수 있다. (예컨대, MMT 클라이언트로부터 메시지를 수신할 시에) MMT 전송용 엔티티는 (예컨대, 사용자의 새로운 뷰포트 정보에 기초하여) G-PCC 자산들을 선택할 수 있다. MMT 전송용 엔티티는 "GPCCAssetGroupMessage" 애플리케이션 메시지를 대응하는 G-PCC 자산들을 갖는 MMT 클라이언트로 전송할 수 있다. MMT 전송용 엔티티는 G-PCC 자산 데이터를 MMTP 패킷들로서 스트리밍할 수 있다.
MMT 클라이언트는 (예컨대, 모든) 요청된 G-PCC 자산들에 대한 MMTP 패킷들을 수신하는 것을 시작할 수 있다. MMT 클라이언트는 MMTP 페이로드로부터 MPU들 및 MFU들을 추출할 수 있다. MPU들 및 MFU들은 매체 샘플들을 (예컨대, 직접) 포함하거나 또는 매체 세그먼트들을 포함할 수 있다.
MMT 클라이언트는 매체들 세그먼트 컨테이너(예컨대, ISOBMFF)를 파싱하기 시작하여, 기본 스트림 정보를 추출하고, G-PCC 비트스트림을 구조화하고, 비트스트림을 G-PCC 디코더로 전달할 수 있다. 기본 스트림 데이터는 추출되고 구조화될 수 있고, 비트스트림은, 예를 들어, MMTP 페이로드가 G-PCC 매체 샘플들을 포함하는 경우/포함할 때, G-PCC 디코더로 전달될 수 있다.
기하구조 기반 포인트 클라우드들(G-PCC)의 MPEG 매체 전송(MMT) 스트리밍을 위한 시스템들, 방법들, 및 장치들이 본 명세서에서 설명되었다. G-PCC 인코딩된 콘텐츠는 MMT를 사용하여 네트워크들을 통해 전달될 수 있다. G-PCC 데이터는 MMT 스트리밍을 위해 캡슐화될 수 있다. MMT 시그널링 메시지들은 MMT를 통한 G-PCC 데이터의 전달을 지원할 수 있다. (예컨대, 각각의) 트랙은, 예를 들어, ISOBMFF 내의 G-PCC 컴포넌트들이 다수의 트랙들을 사용하여 시그널링되는 경우/시그널링될 때, MMTP 패킷들로 패킷화될 수 있는 별개의 자산에 캡슐화될 수 있다. G-PCC 정의된 애플리케이션 메시지는, 서버 및 클라이언트가 G-PCC 컴포넌트에 대한 다수의 자산들의 그룹을 식별하는 것을 가능하게 할 수 있다.
특징들 및 요소들이 특정 조합들로 위에서 설명되었지만, 당업자는 각각의 특징 또는 요소가 단독으로 또는 다른 특징들 및 요소들과의 임의의 조합으로 사용될 수 있다는 것을 알 것이다. 또한, 본 명세서에서 설명된 방법들은 컴퓨터 또는 프로세서에 의한 실행을 위해 컴퓨터 판독가능 매체에 통합된 컴퓨터 프로그램, 소프트웨어 또는 펌웨어로 구현될 수 있다. 컴퓨터 판독가능 매체들의 예들은 (유선 또는 무선 접속을 통해 송신되는) 전자 신호들 및 컴퓨터 판독가능 저장 매체들을 포함한다. 컴퓨터 판독가능 저장 매체들의 예들은 판독 전용 메모리(ROM), 랜덤 액세스 메모리(RAM), 레지스터, 캐시 메모리, 반도체 메모리 디바이스들, 내부 하드 디스크들 및 착탈식 디스크들과 같은 자기 매체들, 광자기 매체들, 및 CD-ROM 디스크들 및 디지털 다기능 디스크(DVD)들과 같은 광학 매체들을 포함하지만, 이들로 제한되지 않는다. 소프트웨어와 연관된 프로세서는 WTRU, UE, 단말기, 기지국, RNC 또는 임의의 호스트 컴퓨터에서 사용하기 위한 무선 주파수 송수신기를 구현하는 데 사용될 수 있다.

Claims (18)

  1. 수신용 디바이스에서 구현되는 방법으로서,
    전송용 디바이스로부터,
    상기 전송용 디바이스로부터 상기 수신용 디바이스로 스트리밍되는 데 이용가능한 매체 자산들의 목록을 포함하는 제1 메시지; 또는
    상기 전송용 디바이스로부터 상기 수신용 디바이스로 스트리밍되는 데 이용가능한 상기 매체 자산들을 각각 설명하는 하나 이상의 메시지들 중 적어도 하나를 수신하는 단계; 상기 전송용 디바이스로부터 상기 수신용 디바이스로 스트리밍될 상기 매체 자산들의 서브세트에 대한 요청을 나타내는 정보를 포함하는 제2 메시지를 상기 전송용 디바이스로 전송하는 단계 - 상기 매체 자산들의 요청된 서브세트는 상기 수신용 디바이스의 뷰포트에 기초하여 결정됨 -;
    상기 제2 메시지에 응답하여, 상기 전송용 디바이스로부터, 하나 이상의 동영상 전문가 그룹(Motion Picture Experts Group, MPEG) 매체 전송 프로토콜(Media Transport Protocol, MMTP) 패킷들을 수신하는 단계; 및
    상기 하나 이상의 MMTP 패킷들을 프로세싱하여 상기 매체 자산들의 요청된 서브세트의 적어도 일부분을 복구하는 단계를 포함하는, 방법.
  2. 제1항에 있어서, 상기 전송용 디바이스로부터 상기 수신용 디바이스로 스트리밍될 상기 매체 자산들의 업데이트된 서브세트에 대한 요청을 나타내는 정보를 포함하는 제3 메시지를 상기 전송용 디바이스로 전송하는 단계를 추가로 포함하고, 상기 매체 자산들의 요청된 업데이트된 서브세트는 상기 수신용 디바이스의 업데이트된 뷰포트에 기초하여 결정되는, 방법.
  3. 제1항에 있어서, 상기 전송용 디바이스로부터 수신된 상기 제1 메시지는 상기 매체 자산들의 목록과 연관된 애플리케이션을 식별하는 정보를 추가로 포함하는, 방법.
  4. 제3항에 있어서, 상기 애플리케이션을 식별하는 정보는, 상기 애플리케이션이 시각적 볼류메트릭 비디오 기반 코딩(visual volumetric video-based coding, V3C) 데이터를 소비한다는 것을 나타내는, 방법.
  5. 제3항에 있어서, 상기 애플리케이션을 식별하는 정보는, 상기 애플리케이션이 기하구조 기반 포인트 클라우드 압축(geometry-based point cloud compression, G-PCC) 데이터를 소비한다는 것을 나타내는, 방법.
  6. 제1항에 있어서, 상기 제1 메시지는, 디코딩을 위한 다른 매체 자산에 대한 매체 자산의 의존성; 상기 매체 자산이 의존하는 상기 다른 매체 자산의 표시; 매체 자산이 대체 버전을 갖는지 여부; 및 상기 매체 자산의 대체 버전의 식별 중 하나 이상을 나타내는 정보를 포함하는, 방법.
  7. 수신용 디바이스로서,
    프로세서; 및
    통신 인터페이스를 포함하고,
    상기 프로세서 및 상기 통신 인터페이스는, 전송용 디바이스로부터,
    상기 전송용 디바이스로부터 상기 수신용 디바이스로 스트리밍되는 데 이용가능한 매체 자산들의 목록을 나타내는 정보를 포함하는 제1 메시지; 또는
    상기 전송용 디바이스로부터 상기 수신용 디바이스로 스트리밍되는 데 이용가능한 상기 매체 자산들을 각각 설명하는 하나 이상의 메시지들 중 적어도 하나를 수신하도록 구성되고,
    상기 프로세서 및 상기 통신 인터페이스는, 상기 전송용 디바이스로부터 상기 수신용 디바이스로 스트리밍될 상기 매체 자산들의 서브세트에 대한 요청을 나타내는 정보를 포함하는 제2 메시지를 상기 전송용 디바이스로 전송하도록 구성되고, 상기 매체 자산들의 요청된 서브세트는 상기 수신용 디바이스의 뷰포트에 기초하여 결정되며;
    상기 프로세서 및 상기 통신 인터페이스는, 상기 제2 메시지에 응답하여, 상기 전송용 디바이스로부터, 하나 이상의 동영상 전문가 그룹(MPEG) 매체 전송 프로토콜(MMTP) 패킷들을 수신하도록 구성되고;
    상기 프로세서는, 상기 하나 이상의 MMTP 패킷들을 프로세싱하여 상기 매체 자산들의 요청된 서브세트의 적어도 일부분을 복구하도록 구성되는, 수신용 디바이스.
  8. 제7항에 있어서, 상기 전송용 디바이스로부터 상기 수신용 디바이스로 스트리밍될 상기 매체 자산들의 업데이트된 서브세트에 대한 요청을 나타내는 정보를 포함하는 제3 메시지를 상기 전송용 디바이스로 전송하는 것을 추가로 포함하고, 상기 매체 자산들의 요청된 업데이트된 서브세트는 상기 수신용 디바이스의 업데이트된 뷰포트에 기초하여 결정되는, 수신용 디바이스.
  9. 제7항에 있어서, 상기 전송용 디바이스로부터 수신된 상기 제1 메시지는 상기 매체 자산들의 목록과 연관된 애플리케이션을 식별하는 정보를 추가로 포함하는, 수신용 디바이스.
  10. 제9항에 있어서, 상기 애플리케이션을 식별하는 정보는, 상기 애플리케이션이 시각적 볼류메트릭 비디오 기반 코딩(V3C) 데이터를 소비한다는 것을 나타내는, 수신용 디바이스.
  11. 제9항에 있어서, 상기 애플리케이션을 식별하는 정보는, 상기 애플리케이션이 기하구조 기반 포인트 클라우드 압축(G-PCC) 데이터를 소비한다는 것을 나타내는, 수신용 디바이스.
  12. 제7항에 있어서, 상기 제1 메시지는, 디코딩을 위한 다른 매체 자산에 대한 매체 자산의 의존성; 상기 매체 자산이 의존하는 상기 다른 매체 자산의 표시; 매체 자산이 대체 버전을 갖는지 여부; 및 상기 매체 자산의 대체 버전의 식별 중 하나 이상을 나타내는 정보를 포함하는, 수신용 디바이스.
  13. 수신용 디바이스로서,
    프로세서; 및
    통신 인터페이스를 포함하고,
    상기 프로세서 및 상기 통신 인터페이스는, 전송용 디바이스로부터,
    상기 전송용 디바이스로부터 상기 수신용 디바이스로 스트리밍되는 데 이용가능한 매체 자산들의 세트를 나타내는 정보를 포함하는 제1 메시지; 또는
    상기 전송용 디바이스로부터 상기 수신용 디바이스로 스트리밍되는 데 이용가능한 상기 매체 자산들을 각각 설명하는 하나 이상의 메시지들 중 적어도 하나를 수신하도록 구성되고,
    상기 프로세서 및 상기 통신 인터페이스는, 상기 수신용 디바이스의 뷰포트를 나타내는 정보를 포함하는 제2 메시지를 상기 전송용 디바이스로 전송하도록 구성되고;
    상기 프로세서 및 상기 통신 인터페이스는, 상기 전송용 디바이스로부터 상기 수신용 디바이스로 스트리밍될 상기 매체 자산들의 서브세트를 나타내는 정보를 포함하는 제3 메시지를 상기 전송용 디바이스로부터 수신하도록 구성되고, 상기 매체 자산들의 나타내어진 서브세트는 상기 수신용 디바이스의 나타내어진 뷰포트에 기초하여 결정되고;
    상기 프로세서 및 상기 통신 인터페이스는, 상기 제3 메시지에 응답하여, 상기 전송용 디바이스로부터, 하나 이상의 동영상 전문가 그룹(MPEG) 매체 전송 프로토콜(MMTP) 패킷들을 수신하도록 구성되고;
    상기 프로세서는, 상기 하나 이상의 MMTP 패킷들을 프로세싱하여 상기 매체 자산들의 나타내어진 서브세트의 적어도 일부분을 복구하도록 구성되는, 수신용 디바이스.
  14. 제13항에 있어서,
    상기 프로세서 및 상기 통신 인터페이스는, 상기 수신용 디바이스의 업데이트된 뷰포트를 나타내는 정보를 포함하는 제4 메시지를 상기 전송용 디바이스로 전송하도록 구성되고;
    상기 프로세서 및 상기 통신 인터페이스는, 상기 전송용 디바이스로부터, 상기 업데이트된 뷰포트와 연관된 매체 자산들의 업데이트된 세트를 나타내는 정보를 포함하는 제4 메시지를 수신하도록 구성되고;
    상기 프로세서 및 상기 통신 인터페이스는, 상기 전송용 디바이스로부터, 다른 하나 이상의 MMTP 패킷들을 수신하도록 구성되고;
    상기 프로세서는, 상기 다른 하나 이상의 MMTP 패킷들을 프로세싱하여 상기 수신용 디바이스의 업데이트된 뷰포트와 연관된 상기 매체 자산들의 업데이트된 세트의 적어도 일부분을 복구하도록 구성되는, 수신용 디바이스.
  15. 제13항에 있어서, 상기 전송용 디바이스로부터 수신된 상기 제1 메시지는 상기 매체 자산들의 목록과 연관된 애플리케이션을 식별하는 정보를 추가로 포함하는, 수신용 디바이스.
  16. 제15항에 있어서, 상기 애플리케이션을 식별하는 정보는, 상기 애플리케이션이 시각적 볼류메트릭 비디오 기반 코딩(V3C) 데이터를 소비한다는 것을 나타내는, 수신용 디바이스.
  17. 제15항에 있어서, 상기 애플리케이션을 식별하는 정보는, 상기 애플리케이션이 기하구조 기반 포인트 클라우드 압축(G-PCC) 데이터를 소비한다는 것을 나타내는, 수신용 디바이스.
  18. 제13항에 있어서, 상기 제1 메시지는, 디코딩을 위한 다른 매체 자산에 대한 매체 자산의 의존성; 상기 매체 자산이 의존하는 상기 다른 매체 자산의 표시; 매체 자산이 대체 버전을 갖는지 여부; 및 상기 매체 자산의 대체 버전의 식별 중 하나 이상을 나타내는 정보를 포함하는, 수신용 디바이스.
KR1020237026390A 2021-01-05 2022-01-05 시각적 볼류메트릭 비디오 기반(v3c) 및 기하구조 기반 포인트 클라우드(g-pcc) 매체들의 스트리밍을 위한 mmt 시그널링 KR20230129259A (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202163134143P 2021-01-05 2021-01-05
US202163134038P 2021-01-05 2021-01-05
US63/134,143 2021-01-05
US63/134,038 2021-01-05
PCT/US2022/011298 WO2022150376A1 (en) 2021-01-05 2022-01-05 Mmt signaling for streaming of visual volumetric video-based (v3c) and geometry-based point cloud (g-pcc) media

Publications (1)

Publication Number Publication Date
KR20230129259A true KR20230129259A (ko) 2023-09-07

Family

ID=80050976

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020237026390A KR20230129259A (ko) 2021-01-05 2022-01-05 시각적 볼류메트릭 비디오 기반(v3c) 및 기하구조 기반 포인트 클라우드(g-pcc) 매체들의 스트리밍을 위한 mmt 시그널링

Country Status (6)

Country Link
US (1) US20240022773A1 (ko)
EP (1) EP4275358A1 (ko)
JP (1) JP2024502822A (ko)
KR (1) KR20230129259A (ko)
IL (1) IL304205A (ko)
WO (1) WO2022150376A1 (ko)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220329857A1 (en) * 2021-04-13 2022-10-13 Samsung Electronics Co., Ltd. Mpeg media transport (mmt) signaling of visual volumetric video-based coding (v3c) content

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP3818716A4 (en) * 2018-07-02 2022-06-01 Nokia Technologies Oy DEVICE, METHOD AND COMPUTER PROGRAM FOR VIDEO ENCODING AND DECODING
US11823421B2 (en) * 2019-03-14 2023-11-21 Nokia Technologies Oy Signalling of metadata for volumetric video
US20220159261A1 (en) * 2019-03-21 2022-05-19 Lg Electronics Inc. Point cloud data transmission device, point cloud data transmission method, point cloud data reception device, and point cloud data reception method

Also Published As

Publication number Publication date
IL304205A (en) 2023-09-01
WO2022150376A1 (en) 2022-07-14
US20240022773A1 (en) 2024-01-18
EP4275358A1 (en) 2023-11-15
JP2024502822A (ja) 2024-01-23

Similar Documents

Publication Publication Date Title
US11568573B2 (en) Methods and apparatus for point cloud compression bitstream format
US11917177B2 (en) Dynamic adaptation of volumetric content component sub-bitstreams in streaming services
US20230188751A1 (en) Partial access support in isobmff containers for video-based point cloud streams
US20230281923A1 (en) Tile tracks for geometry-based point cloud data
US20220239947A1 (en) Video-based point cloud streams
US20240022773A1 (en) Mmt signaling for streaming of visual volumetric video-based and geometry-based point cloud media
US20220329923A1 (en) Video-based point cloud streams
US20230276053A1 (en) Adaptive streaming of geometry-based point clouds
CN116830588A (zh) 用于基于视觉体积视频(v3c)媒体和基于几何的点云(g-pcc)媒体的流式传输的mmt信令
WO2024006279A1 (en) Signaling parameter sets for geometry-based point cloud streams
WO2023059730A1 (en) Adaptive streaming of geometry-based point clouds