WO2020071703A1 - 포인트 클라우드 데이터 전송 장치, 포인트 클라우드 데이터 전송 방법, 포인트 클라우드 데이터 수신 장치 및/또는 포인트 클라우드 데이터 수신 방법 - Google Patents

포인트 클라우드 데이터 전송 장치, 포인트 클라우드 데이터 전송 방법, 포인트 클라우드 데이터 수신 장치 및/또는 포인트 클라우드 데이터 수신 방법

Info

Publication number
WO2020071703A1
WO2020071703A1 PCT/KR2019/012719 KR2019012719W WO2020071703A1 WO 2020071703 A1 WO2020071703 A1 WO 2020071703A1 KR 2019012719 W KR2019012719 W KR 2019012719W WO 2020071703 A1 WO2020071703 A1 WO 2020071703A1
Authority
WO
WIPO (PCT)
Prior art keywords
video
point cloud
image
information
data
Prior art date
Application number
PCT/KR2019/012719
Other languages
English (en)
French (fr)
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 WO2020071703A1 publication Critical patent/WO2020071703A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • G06T9/001—Model-based coding, e.g. wire frame
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/005—General purpose rendering architectures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T15/00—3D [Three Dimensional] image rendering
    • G06T15/04—Texture mapping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T19/00—Manipulating 3D models or images for computer graphics
    • G06T19/006—Mixed reality
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T9/00—Image coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/70—Media network packetisation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/765—Media network packet handling intermediate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/106—Processing image signals
    • H04N13/161—Encoding, multiplexing or demultiplexing different image signal components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/10—Processing, recording or transmission of stereoscopic or multi-view image signals
    • H04N13/194—Transmission of image signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/21—Server components or server architectures
    • H04N21/218—Source of audio or video content, e.g. local disk arrays
    • H04N21/21805—Source of audio or video content, e.g. local disk arrays enabling multiple viewpoints, e.g. using a plurality of cameras
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8146—Monomedia components thereof involving graphical data, e.g. 3D object, 2D graphics
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
    • G06T2210/00—Indexing scheme for image generation or computer graphics
    • G06T2210/56—Particle system, point based geometry or rendering

Definitions

  • Embodiments provide Point Cloud content to provide various services to users, such as VR (Virtual Reality), AR (Augmented Reality), MR (Mixed Reality), and autonomous driving services. Provide a plan.
  • VR Virtual Reality
  • AR Augmented Reality
  • MR Magnetic Reality
  • autonomous driving services Provide a plan.
  • a point cloud is a collection of points in 3D space. There is a problem in that it is difficult to generate point cloud data due to the large number of points in 3D space.
  • the technical problem according to the embodiments is to provide a point cloud data transmission device, a transmission method, a point cloud data reception device and a reception method for efficiently transmitting and receiving a point cloud in order to solve the above-mentioned problems.
  • the technical problem according to the embodiments is to provide a point cloud data transmission device, a transmission method, a point cloud data reception device and a reception method for solving latency and encoding / decoding complexity.
  • the method for transmitting point cloud data includes generating a geometric image related to a location of point cloud data; Generating a texture image related to the attribute of the point cloud; Generating an accuancy map related to the patch of the point cloud; Generating affiliation patch information related to the patch of the point cloud; And / or multiplexing the geometry image, the texture image, the accuancy map, and the affiliation patch information; It includes.
  • the method for receiving point cloud data includes a geometric image related to the location of the point cloud data, a texture image related to the attributes of the point cloud, an accuancy map related to the patching of the point cloud, and an ailment related to the patching of the point cloud. Demultiplexing the Larry patch information; Decompressing the geometry image; Decompressing the texture image; Decompressing the accuancy map; And / or decompressing the affiliation patch information.
  • a point cloud data transmission method, a transmission device, a point cloud data reception method, and a reception device may provide a quality point cloud service.
  • the point cloud data transmission method, the transmission device, the point cloud data reception method, and the reception device may achieve various video codec methods.
  • the point cloud data transmission method, the transmission device, the point cloud data reception method, and the reception device may provide general point cloud content such as an autonomous driving service.
  • FIG. 1 is a diagram showing an overall architecture for providing 360-degree video according to embodiments.
  • FIG. 2 is a diagram illustrating a 360-degree video transmission apparatus according to an aspect of the embodiments.
  • FIG. 3 is a diagram illustrating a 360-degree video receiving apparatus according to another aspect of the embodiments.
  • FIG. 4 is a diagram illustrating a 360-degree video transmitting device / 360-degree video receiving device according to another embodiment of the embodiments.
  • FIG. 5 is a diagram illustrating the concept of Aircraft Principal Axes for describing the 3D space of the embodiments.
  • FIG. 6 is a diagram illustrating projection schemes according to an embodiment of the embodiments.
  • FIG. 7 is a diagram illustrating a tile according to an embodiment of the embodiments.
  • FIG. 8 is a diagram illustrating metadata related to 360-degree video according to an embodiment of the embodiments.
  • FIG 9 shows a view point and a viewing position that are additionally defined in a 3DoF + VR system.
  • FIG. 10 shows a method of implementing a 360-degree video signal processing based on a 3DoF + system and a related transmission / reception device.
  • FIG. 11 shows the structure of a 3DoF + end-to-end system.
  • FLUS Framework for Live Uplink Streaming
  • 16 shows the type of media according to the user's movement.
  • 17 shows the overall architecture for providing 6DoF video.
  • FIG. 18 shows a configuration of a transmission device for providing a 6DoF video service.
  • Figure 21 shows the 6 DoF space.
  • FIG. 22 shows a general point cloud compression process according to embodiments.
  • FIG 23 shows an arrangement of Point Cloud capture equipment according to embodiments.
  • FIG 24 shows an example of point cloud, geometry, and texture image (non-padded) according to embodiments.
  • FIG. 25 shows a V-PCC encoding process according to embodiments.
  • 26 shows a tangent plane and a normal vector of a surface according to embodiments.
  • FIG. 27 shows a bounding box of a point cloud according to embodiments.
  • 29 shows a relationship between normal, tangent, and bitangent axes according to embodiments.
  • 30 shows d0 and d1 configurations in min mode and d0 and d1 configurations in max mode according to embodiments.
  • 33 shows pseudo code for block to patch mapping according to embodiments.
  • Figure 34 shows push-pull background filling according to embodiments.
  • 35 shows an example of possible traversal order for a 4 * 4 size block according to embodiments.
  • 39 shows a 2D video / image decoder according to embodiments.
  • 40 is a flowchart of an operation of a transmitting end according to embodiments.
  • 41 shows a flowchart of operation of a receiving end according to embodiments.
  • FIG. 42 shows an architecture for storing and streaming V-PCC-based point cloud data according to embodiments.
  • FIG. 43 shows a point cloud data storage and transmission device according to embodiments.
  • FIG. 44 shows a point cloud data receiving device according to embodiments.
  • 45 shows an encoding process of a point cloud data transmission device according to embodiments.
  • 49 illustrates NALU stream-based multiplexing / demultiplexing according to embodiments.
  • 50 shows PCC layer information according to embodiments.
  • FIG. 53 shows a PCC group of frames header according to embodiments.
  • 55 shows a method of arranging between geometry and image components according to embodiments.
  • VPS extension 56 shows a VPS extension according to embodiments.
  • 57 shows pic_parameter_set according to embodiments.
  • 58 shows pps_pcc_auxiliary_patch_info_extension () according to embodiments.
  • 59 shows pps_pcc_occupancy_map_extension () according to embodiments.
  • 60 shows vps_pcc_gof_header_extension () according to embodiments.
  • 61 shows pcc_nal_unit according to embodiments.
  • 64 shows a method of transmitting point cloud data according to embodiments.
  • 65 shows a method for receiving point cloud data according to embodiments.
  • FIG. 1 is a diagram illustrating an overall architecture for providing 360-degree video according to embodiments.
  • Embodiments propose a method of providing 360-degree content in order to provide VR (Virtual Reality) to a user.
  • VR may refer to a technology or environment for replicating a real or virtual environment.
  • VR artificially provides the user with a sensuous experience, which allows the user to experience the same experience as being in an electronically projected environment.
  • the 360-degree content refers to overall content for implementing and providing VR, and may include 360-degree video and / or 360-degree audio.
  • the 360-degree video may refer to video or image content necessary to provide VR, and simultaneously captured or played in all directions (360-degree).
  • the 360-degree video may mean a video or image displayed on various forms of 3D space according to a 3D model, and for example, the 360-degree video may be displayed on a spherical surface.
  • 360-degree audio is also audio content for providing VR, and may mean spatial audio content, which can be recognized as being located in a specific space in 3D.
  • 360-degree content can be generated, processed, and transmitted to users, and users can consume the VR experience using the 360-degree content.
  • 360-degree content / video / image / audio, etc. may be used as 360 content / video / image / audio, etc. in which the unit (degree) is omitted, or may be used as VR content / video / image / audio.
  • the embodiments particularly propose a method for effectively providing 360 video.
  • the 360 video can be captured through one or more cameras first.
  • the captured 360 video is transmitted through a series of processes, and the receiving side can process the received data back to the original 360 video and render it.
  • 360 videos may be provided to the user.
  • the entire process for providing 360 video may include a capture process, a preparation process, a transmission process, a processing process, a rendering process, and / or a feedback process.
  • the capturing process may refer to a process of capturing an image or video for each of a plurality of viewpoints through one or more cameras.
  • Image / video data such as (t1010) shown by the capture process may be generated.
  • Each plane of (t1010) illustrated may mean an image / video for each viewpoint.
  • the plurality of captured images / videos may be referred to as raw data.
  • metadata related to capture may be generated.
  • a special camera for VR can be used for this capture.
  • capture through a real camera may not be performed.
  • the capturing process may be replaced by simply generating the relevant data.
  • the preparation process may be a process of processing the captured image / video and metadata generated in the capture process.
  • the captured image / video may undergo a stitching process, a projection process, a region-wise packing process, and / or an encoding process in the preparation process.
  • each image / video may go through a stitching process.
  • the stitching process may be a process of making a panoramic image / video or a spherical image / video by connecting each captured image / video.
  • the stitched image / video may be subjected to a projection process.
  • the stretched image / video can be projected onto a 2D image.
  • This 2D image may be referred to as a 2D image frame depending on the context. Projecting with a 2D image can also be expressed as mapping to a 2D image.
  • the projected image / video data may be in the form of a 2D image as illustrated (t1020).
  • Video data projected on a 2D image may be subjected to a region-wise packing to increase video coding efficiency and the like.
  • Packing by region may mean a process of dividing and processing video data projected on a 2D image for each region.
  • the region may mean an area in which a 2D image in which 360 video data is projected is divided.
  • these regions may be divided into equally divided 2D images or arbitrarily divided.
  • regions may be classified according to a projection scheme.
  • the region-specific packing process is an optional process and may be omitted in the preparation process.
  • this processing may include rotating each region or rearranging on a 2D image to increase video coding efficiency. For example, by rotating regions so that specific sides of regions are positioned close to each other, efficiency in coding can be increased.
  • the process may include increasing or decreasing the resolution for a specific region in order to differentiate resolution for each region on the 360 video. For example, regions corresponding to a region that is relatively more important on 360 video may have higher resolution than other regions.
  • Video data projected on a 2D image or packed video data by region is encoded through a video codec. You can go through the process.
  • the preparation process may further include an editing process.
  • editing process editing of image / video data before and after projection may be further performed.
  • metadata about stitching / projection / encoding / editing, etc. may be generated.
  • metadata regarding an initial viewpoint of a video data projected on a 2D image or a Region of Interest (ROI) may be generated.
  • the transmission process may be a process of processing and transmitting image / video data and metadata that have undergone a preparation process. For transmission, processing according to any transmission protocol may be performed. Data that has been processed for transmission may be transmitted through a broadcast network and / or broadband. These data may be delivered to the receiving side in an on demand manner. The receiving side can receive the corresponding data through various paths.
  • the processing process may mean a process of decoding the received data and re-projecting the projected image / video data onto a 3D model.
  • image / video data projected on 2D images may be re-projected onto 3D space.
  • this process can also be called mapping and projection.
  • the 3D space to be mapped may have a different shape according to the 3D model.
  • a 3D model may have a sphere, cube, cylinder, or pyramid.
  • the processing process may further include an editing process, an up scaling process, and the like.
  • editing process editing of image / video data before and after re-projection may be further performed.
  • the size may be enlarged through upscaling of samples in the upscaling process. If necessary, the operation of reducing the size through downscaling may be performed.
  • the rendering process may refer to a process of rendering and displaying re-projected image / video data in 3D space.
  • re-projection and rendering can be combined to render on a 3D model.
  • the image / video re-projected onto the 3D model (or rendered onto the 3D model) may have a shape as shown (t1030).
  • the illustrated (t1030) is a case where the 3D model of a sphere is re-projected.
  • the user can view some areas of the rendered image / video through a VR display or the like. At this time, the area viewed by the user may be in the form of (t1040) shown.
  • the feedback process may refer to a process of transmitting various feedback information that can be obtained in the display process to the transmitting side. Through the feedback process, interactivity in 360 video consumption may be provided. According to an embodiment, in the feedback process, head orientation information, viewport information indicating an area currently viewed by a user, and the like may be transmitted to the transmitting side. Depending on the embodiment, the user may interact with those implemented on the VR environment, in which case information related to the interaction may be delivered to the sending side or the service provider side in the feedback process. Depending on the embodiment, the feedback process may not be performed.
  • the head orientation information may mean information about a user's head position, angle, and movement. Based on this information, information about an area that a user is currently viewing within a 360 video, that is, viewport information may be calculated.
  • the viewport information may be information about an area currently viewed by a user in 360 video. Through this, gaze analysis may be performed to check how the user consumes 360 video, which area of the 360 video, and how much gaze. Gaze analysis may be performed at the receiving side and transmitted to the transmitting side through a feedback channel.
  • a device such as a VR display can extract a viewport area based on the user's head position / orientation, and a vertical or horizontal FOV supported by the device.
  • the feedback information described above may not only be transmitted to the transmitting side, but may be consumed at the receiving side. That is, the decoding, re-projection, and rendering processes of the receiver may be performed using the feedback information described above. For example, only 360 videos for an area currently viewed by a user may be preferentially decoded and rendered using head orientation information and / or viewport information.
  • a viewport or a viewport area may mean an area that a user is viewing in 360 video.
  • a viewpoint is a point that a user is viewing in 360 video, and may mean a center point of the viewport area. That is, the viewport is an area centered on a viewpoint, and a size shape occupied by the area may be determined by a field of view (FOV), which will be described later.
  • FOV field of view
  • 360 video data image / video data that undergoes a series of processes of capture / projection / encoding / transfer / decoding / re-projection / rendering may be referred to as 360 video data.
  • the term 360 video data may also be used as a concept including metadata or signaling information related to these image / video data.
  • FIG. 2 is a diagram illustrating a 360-degree video transmission apparatus according to an aspect of the embodiments.
  • embodiments may relate to a 360 video transmission device.
  • the 360 video transmission apparatus according to the embodiments may perform operations related to the above-described preparation process or transmission process.
  • the 360 video transmission device according to the embodiments includes a data input unit, a stitcher, a projection processing unit, a region-specific packing processing unit (not shown), a metadata processing unit, a (transmission-side) feedback processing unit, a data encoder, and an encapsulation processing unit.
  • the transmission processing unit and / or the transmission unit may be included as internal / external elements.
  • the data input unit may receive captured images / videos for each viewpoint.
  • the viewpoint-specific images / videos may be images / videos captured by one or more cameras.
  • the data input unit may receive metadata generated during the capture process.
  • the data input unit may transmit the input image / video for each view point to the stitcher, and transmit metadata of the capture process to the signaling processing unit.
  • the stitcher may perform stitching on captured images / videos by viewpoint.
  • the stitcher may deliver the stitched 360 video data to the projection processing unit. If necessary, the stitcher can receive necessary metadata from the metadata processing unit and use it for stitching.
  • the stitcher may transmit metadata generated in the stitching process to the metadata processing unit. In the metadata of the stitching process, there may be information such as whether stitching has been performed, stitching type, and the like.
  • the projection processing unit may project stitched 360 video data onto a 2D image.
  • the projection processing unit may perform projection according to various schemes, which will be described later.
  • the projection processing unit may perform mapping in consideration of a corresponding depth of 360 video data for each viewpoint. If necessary, the projection processing unit may receive metadata required for projection from the metadata processing unit and use it for projection work.
  • the projection processing unit may transmit metadata generated in the projection process to the metadata processing unit.
  • the metadata of the projection processing unit may include a type of projection scheme and the like.
  • the region-specific packing processing unit may perform the aforementioned region-specific packing process. That is, the region-specific packing processing unit may perform processing such as dividing the projected 360 video data into regions, rotating and rearranging each region, or changing the resolution of each region. As described above, the packing process for each region is an optional process. When the packing for each region is not performed, the packing process for each region may be omitted. If necessary, the region-specific packing processing unit may receive metadata required for region-specific packing from the metadata processing unit and use the region-specific packing operation. The region-specific packing processing unit may transmit metadata generated in the region-specific packing process to the metadata processing unit.
  • the region-specific packing processing unit metadata may include a rotation degree and a size of each region.
  • the above-described stitcher, projection processing unit and / or region-specific packing processing unit may be performed in one hardware component according to an embodiment.
  • the metadata processing unit may process metadata that may occur in the capture process, stitching process, projection process, region-specific packing process, encoding process, encapsulation process, and / or transmission process.
  • the metadata processing unit may generate 360 video-related metadata using these metadata.
  • the metadata processing unit may generate 360 video-related metadata in the form of a signaling table.
  • 360 video-related metadata may be referred to as metadata or 360 video-related signaling information.
  • the metadata processing unit may transmit the acquired or generated metadata to internal elements of the 360 video transmission device as needed.
  • the metadata processing unit may transmit the 360 video-related metadata to the data encoder, the encapsulation processing unit, and / or the transmission processing unit so that the metadata can be transmitted to the receiver.
  • the data encoder can encode 360 video data projected on a 2D image and / or packed regional video. 360 video data can be encoded in a variety of formats.
  • the encapsulation processing unit may encapsulate encoded 360 video data and / or 360 video-related metadata in the form of a file.
  • the 360 video-related metadata may be received from the metadata processing unit described above.
  • the encapsulation processing unit may encapsulate the data in a file format such as ISOBMFF, CFF, or other DASH segments.
  • the encapsulation processing unit may include 360 video-related metadata on a file format.
  • the 360-related metadata may be included, for example, in various levels of boxes on the ISOBMFF file format, or as data in separate tracks in the file.
  • the encapsulation processing unit may encapsulate the 360 video-related metadata itself into a file.
  • the transmission processing unit may apply processing for transmission to the encapsulated 360 video data according to a file format.
  • the transmission processing unit may process 360 video data according to any transmission protocol.
  • the processing for transmission may include processing for delivery through a broadcast network, and processing for delivery through a broadband.
  • the transmission processing unit may receive not only 360 video data, but also 360 video related metadata from the metadata processing unit, and may apply processing for transmission to the 360 video data.
  • the transmitting unit may transmit the processed 360 video data and / or metadata related to 360 video through a broadcast network and / or broadband.
  • the transmission unit may include an element for transmission over a broadcast network and / or an element for transmission over broadband.
  • the 360 video transmission device may further include a data storage unit (not shown) as an internal / external element.
  • the data storage unit may store the encoded 360 video data and / or 360 video-related metadata before transmitting it to the transmission processing unit.
  • the format in which these data are stored may be a file format such as ISOBMFF.
  • a data storage unit may not be required, but when transmitting through on-demand, NRT (Non Real Time), broadband, etc., encapsulated 360 data is stored in a data storage unit for a certain period of time. It can also be transmitted.
  • the 360 video transmission apparatus may further include a (transmission side) feedback processor and / or a network interface (not shown) as internal / external elements.
  • the network interface may receive feedback information from the 360 video receiving apparatus according to the embodiments, and transmit the feedback information to the transmitting side feedback processing unit.
  • the transmitting-side feedback processing unit may transmit feedback information to the stitcher, projection processing unit, region-specific packing processing unit, data encoder, encapsulation processing unit, metadata processing unit, and / or transmission processing unit.
  • the feedback information may be transmitted once to the metadata processing unit, and then to each internal element again. Internal elements that receive feedback information may reflect the feedback information in subsequent processing of 360 video data.
  • the region-specific packing processing unit may rotate each region to map on a 2D image. At this time, each region may be rotated at different directions and at different angles and mapped on the 2D image. The rotation of the region can be performed by taking into account the portion where the 360 video data was contiguous before projection on the spherical surface, the stitched portion, and the like. Information about the rotation of the region, that is, rotation direction, angle, etc., may be signaled by 360 video related metadata.
  • the data encoder may perform encoding differently for each region. The data encoder may perform encoding in a specific region with high quality and in other regions with low quality.
  • the transmitting-side feedback processing unit may transmit the feedback information received from the 360 video receiving device to the data encoder, so that the data encoder uses a region-specific differential encoding method.
  • the feedback processing unit of the transmitting side may transmit the viewport information received from the receiving side to the data encoder.
  • the data encoder may perform encoding for regions including an area indicated by viewport information with higher quality (UHD, etc.) than other regions.
  • the transmission processing unit may perform processing for transmission differently for each region.
  • the transmission processing unit may apply different transmission parameters (modulation order, code rate, etc.) for each region, so that the robustness of data transmitted for each region may be different.
  • the transmission-side feedback processing unit may transmit the feedback information received from the 360 video receiving device to the transmission processing unit, so that the transmission processing unit performs differential transmission processing for each region.
  • the transmission-side feedback processing unit may transmit viewport information received from the reception side to the transmission processing unit.
  • the transmission processing unit may perform transmission processing for regions including a region indicated by the corresponding viewport information to have higher robustness than other regions.
  • the internal / external elements of the 360 video transmission device may be hardware elements implemented in hardware. Depending on the embodiment, internal / external elements may be changed, omitted, or replaced with other elements. Depending on the embodiment, additional elements may be added to the 360 video transmission device.
  • FIG. 3 is a diagram illustrating a 360-degree video receiving apparatus according to another aspect of the embodiments.
  • embodiments may relate to a 360 video receiving device.
  • the 360 video receiving apparatus according to the embodiments may perform operations related to the above-described processing process and / or rendering process.
  • the 360 video receiving apparatus according to the embodiments includes a receiving unit, a receiving processing unit, a decapsulation processing unit, a data decoder, a metadata parser, a (receiving side) feedback processing unit, a re-projection processing unit and / or a renderer as internal / external elements. You can.
  • the reception unit may receive 360 video data transmitted by the 360 video transmission device according to the embodiments. Depending on the channel being transmitted, the receiver may receive 360 video data through a broadcast network or 360 video data through a broadband.
  • the reception processing unit may perform processing according to a transmission protocol on the received 360 video data.
  • the reception processing unit may perform the reverse process of the above-described transmission processing unit so that the transmission side corresponds to the processing for transmission.
  • the receiving processing unit may deliver the obtained 360 video data to the decapsulation processing unit, and transmit the obtained 360 video-related metadata to the metadata parser.
  • the 360 video-related metadata obtained by the reception processing unit may be in the form of a signaling table.
  • the decapsulation processing unit may decapsulate 360 video data in a file format received from the reception processing unit.
  • the decapsulation processing unit may decapsulate files according to ISOBMFF or the like to obtain 360 video data to 360 video related metadata.
  • the obtained 360 video data may be transmitted to a data decoder, and the obtained 360 video related metadata may be transmitted to a metadata parser.
  • the metadata related to 360 video acquired by the decapsulation processor may be in the form of a box or track in a file format. If necessary, the decapsulation processing unit may receive metadata required for decapsulation from a metadata parser.
  • the data decoder may decode 360 video data.
  • the data decoder may receive metadata required for decoding from the metadata parser.
  • the metadata related to 360 video obtained in the data decoding process may be transmitted to a metadata parser.
  • the metadata parser may perform parsing / decoding of 360 video-related metadata.
  • the metadata parser may transfer the obtained metadata to a data decapsulation processing unit, a data decoder, a re-projection processing unit, and / or a renderer.
  • the re-projection processor may perform re-projection on the decoded 360 video data.
  • the re-projection processor may re-project 360 video data into 3D space.
  • the 3D space may have a different shape depending on the 3D model used.
  • the re-projection processing unit may receive metadata required for re-projection from the metadata parser.
  • the re-projection processing unit may receive information on the type of the 3D model used and its detailed information from a metadata parser.
  • the re-projection processing unit may re-project only 360 video data corresponding to a specific area in 3D space into 3D space using metadata required for re-projection.
  • the renderer can render the re-projected 360 video data. As described above, it may be expressed that 360 video data is rendered in 3D space. In this case, when both processes occur at once, the re-projection processing unit and the renderer are integrated, so that all of these processes can be performed in the renderer. According to an embodiment, the renderer may render only the part the user is viewing according to the user's viewpoint information.
  • the user can view a partial area of the rendered 360 video through a VR display or the like.
  • the VR display is a device that plays 360 video, may be included in a 360 video receiving device (tethered), or may be connected to a 360 video receiving device as a separate device (un-tethered).
  • the 360 video receiving apparatus may further include a (receiving side) feedback processor and / or a network interface (not shown) as internal / external elements.
  • the receiver feedback processing unit may obtain and process feedback information from a renderer, a re-projection processing unit, a data decoder, a decapsulation processing unit, and / or a VR display.
  • the feedback information may include viewport information, head orientation information, gaze information, and the like.
  • the network interface may receive feedback information from the feedback processing unit on the receiving side and transmit it to a 360 video transmission device.
  • the receiving-side feedback processing unit may transmit the obtained feedback information to internal elements of the 360-video receiving device, so that it can be reflected in a process such as rendering.
  • the receiving-side feedback processing unit may transmit feedback information to a renderer, a re-projection processing unit, a data decoder and / or a decapsulation processing unit.
  • the renderer may preferentially render an area viewed by a user using feedback information.
  • the decapsulation processing unit, the data decoder, etc. may preferentially decapsulate and decode the area viewed by the user or the area to be viewed.
  • the internal / external elements of the 360 video receiving apparatus may be hardware elements implemented in hardware. Depending on the embodiment, internal / external elements may be changed, omitted, or replaced with other elements. Depending on the embodiment, additional elements may be added to the 360 video receiving device.
  • Another aspect of embodiments may relate to a method of transmitting 360 video and a method of receiving 360 video.
  • the method for transmitting / receiving 360 videos according to the embodiments may be performed by the 360 video transmission / reception devices according to the above-described embodiments or embodiments of the device, respectively.
  • each embodiment of the 360 video transmission / reception device may be combined with each other.
  • the embodiments of the projection processing unit and the embodiments of the data encoder can be combined with each other to produce as many embodiments of the 360 video transmission device as the number of cases. Such combined embodiments are also included in the scope of the embodiments.
  • FIG. 4 is a diagram illustrating a 360-degree video transmitting device / 360-degree video receiving device according to another embodiment of the embodiments.
  • 360 content may be provided by an architecture as shown in (a).
  • the 360 content may be provided in the form of a file, or may be provided in the form of a segment-based download or streaming service such as DASH.
  • the 360 content may be referred to as VR content.
  • 360 video data and / or 360 audio data may be acquired (Acquisition).
  • the 360 audio data may go through an audio pre-processing process and an audio encoding process.
  • audio-related metadata may be generated, and encoded audio and audio-related metadata may be processed for transmission (file / segment encapsulation).
  • the 360 video data may go through the same process as described above.
  • the stitcher of the 360 video transmission device may perform stitching on 360 video data (Visual stitching). This process may be omitted according to an embodiment and may be performed at the receiving side.
  • the projection processing unit of the 360 video transmission device may project 360 video data on a 2D image (Projection and mapping (packing)).
  • This stitching and projection process is specifically shown in (b).
  • stitching and projection may be performed thereon.
  • stitched 360 video data may be projected onto a 3D space, and the projected 360 video data may be viewed as being arranged on a 2D image.
  • this process may be expressed as projecting 360 video data onto a 2D image.
  • the 3D space may be a sphere or a cube. This 3D space may be the same as the 3D space used for re-projection at the receiving side.
  • the 2D image may also be called a projected frame (C).
  • Region-wise packing may be selectively performed on this 2D image.
  • regions on a 2D image may be mapped onto a packed frame (D) by indicating the location, shape, and size of each region.
  • the projected frame may be the same as the packed frame. The region will be described later.
  • the projection process and the region-specific packing process may be expressed as each region of 360 video data being projected on a 2D image. Depending on the design, 360 video data may be directly converted into packed frames without intermediate processing.
  • the projected 360 video data may be image encoded to video encoded. Since the same content may exist for different viewpoints, the same content may be encoded in different bit streams.
  • the encoded 360 video data may be processed in a file format such as ISOBMFF by the encapsulation processing unit described above.
  • the encapsulation processor may process the encoded 360 video data into segments. Segments may be included in individual tracks for DASH based transmission.
  • 360 video related metadata can be generated as described above.
  • This metadata can be delivered as part of a video stream or file format.
  • This metadata can also be used in processes such as encoding, file format encapsulation, and processing for transmission.
  • the 360 audio / video data is processed for transmission according to a transmission protocol, and then transmitted.
  • the above-described 360 video receiving device may receive it through a broadcast network or broadband.
  • the VR service platform may correspond to one embodiment of the above-described 360 video receiving device.
  • loudspeakers / headphones, displays, and head / eye tracking components are shown to be performed by external devices or VR applications of the 360 video receiving device,
  • the 360 video receiving apparatus may include all of them.
  • the head / eye tracking component may correspond to the aforementioned feedback processing unit.
  • the 360 video receiving apparatus may perform processing (File / segment decapsulation) for receiving 360 audio / video data.
  • the 360 audio data may be provided to a user through a speaker / headphone through audio decoding and audio rendering processes.
  • the 360 video data may be provided to a user through a display through an image decoding, video decoding, and rendering process.
  • the display may be a display supporting VR or a general display.
  • the rendering process may be specifically viewed as 360 video data being re-projected onto the 3D space, and the re-projected 360 video data being rendered. It can also be expressed that 360 video data is rendered in 3D space.
  • the head / eye tracking component may acquire and process a user's head orientation information, gaze information, viewport information, and the like. This was described above.
  • the receiving side there may be a VR application communicating with the above-described receiving-side processes.
  • FIG. 5 is a diagram illustrating the concept of Aircraft Principal Axes for explaining 3D space of embodiments.
  • the airplane headstock concept may be used to represent a specific point, position, direction, spacing, area, etc. in 3D space.
  • a 3D space is described before or after re-projection, and an airplane headstock concept may be used to perform signaling for the 3D space.
  • the X, Y, Z axis concept or a method using a spherical coordinate system may be used.
  • the plane can rotate freely in three dimensions.
  • the three-dimensional axes are called a pitch axis, a yaw axis, and a roll axis, respectively.
  • pitch axis a pitch axis
  • yaw axis a yaw axis
  • roll axis a yaw axis
  • the pitch axis may mean an axis that is a reference for a direction in which the front nose of the airplane rotates up / down.
  • the pitch axis may mean an axis extending from the wing of the airplane to the wing.
  • the yaw axis may mean an axis that serves as a reference for a direction in which the front nose of the airplane rotates left / right.
  • the yaw axis may mean an axis extending from the top to the bottom of the airplane.
  • the roll axis is an axis from the nose of the airplane to the tail in the concept of the main axis of the airplane, and rotation in the roll direction may mean rotation based on the roll axis.
  • the 3D space in the embodiments can be described through the concept of pitch, yaw, and roll.
  • FIG. 6 is a diagram illustrating projection schemes according to an embodiment of the embodiments.
  • the projection processing unit of the 360 video transmission apparatus may project stitched 360 video data onto a 2D image.
  • Various projection schemes can be used in this process.
  • the projection processing unit may perform projection using a Cubic Projection scheme. For example, stitched 360 video data may be displayed on a spherical surface.
  • the projection processing unit may divide the 360 video data into cubes (cubes) to project on a 2D image.
  • 360 video data on a spherical face corresponds to each face of the cube, and can be projected on the 2D image as (a) left or (a) right.
  • the projection processing unit may perform projection using a cylindrical projection scheme.
  • the projection processing unit may divide the 360 video data into a cylinder shape and project the 2D image.
  • the 360 video data on the spherical surface corresponds to the side, top, and bottom of the cylinder, respectively, and can be projected on the 2D image as (b) left or (b) right.
  • the projection processing unit may perform projection using a pyramid projection scheme.
  • the projection processing unit can view the 360 video data in a pyramid shape and divide each surface to project on a 2D image.
  • the 360 video data on the spherical face corresponds to the front side of the pyramid and the four sides of the pyramid (Left top, Left bottom, Right top, Right bottom), respectively. c) It can be projected as shown on the right.
  • the projection processing unit may perform projection using an equirectangular projection scheme, a panoramic projection scheme, or the like, in addition to the above-described schemes.
  • a region may mean an area in which 2D images projected with 360 video data are divided. These regions do not have to match each face on the projected 2D image according to the projection scheme. However, according to an embodiment, regions are divided so that each surface on the projected 2D image corresponds to a region, and region-specific packing may be performed. Depending on the embodiment, a plurality of faces may correspond to one region, or regions may be divided so that one face corresponds to a plurality of regions. In this case, the region may vary depending on the projection scheme. For example, in (a), each face of the cube (top, bottom, front, left, right, and back) may be a region. In (b), the side, top, and bottom of the cylinder may each be regions. In (c), the pyramid's front and four-way sides (Left top, Left bottom, Right top, Right bottom) may each be a region.
  • FIG. 7 is a diagram illustrating a tile according to an embodiment of the embodiments.
  • 360 video data projected on a 2D image or 360 video data performed up to region-specific packing may be divided into one or more tiles.
  • the illustrated (a) shows a form in which one 2D image is divided into 16 tiles.
  • the 2D image may be the aforementioned projected frame or packed frame.
  • the data encoder may independently encode each tile.
  • the above-mentioned region-specific packing and tiling may be divided.
  • the above-mentioned region-specific packing may mean processing 360 video data projected on a 2D image into regions to improve coding efficiency or to adjust resolution.
  • the tiling may mean that the data encoder divides the projected frame or the packed frame into sections called tiles, and performs encoding independently for each tile.
  • 360 video is provided, the user does not consume all parts of the 360 video simultaneously.
  • the tiling can make it possible to transmit or consume only tiles corresponding to an important part or a certain part, such as a viewport currently viewed by a user, on a limited bandwidth. Through tiling, the limited bandwidth can be utilized more efficiently, and the receiving side can also reduce the computational load compared to processing all 360 video data at once.
  • Regions and tiles are distinct, so the two areas need not be the same. However, depending on the embodiment, the region and the tile may refer to the same area. Depending on the embodiment, packing by region is performed according to a tile, so that the region and the tile may be the same. Also, according to an embodiment, when each surface and region according to the projection scheme are the same, each surface, region, and tile according to the projection scheme may refer to the same region. Depending on the context, a region may be called a VR region, or a tile region.
  • ROI may mean an area of interest of users, as suggested by the 360 content provider.
  • a 360 content provider may view a certain area as users' interest, and may take into account this and produce a 360 video.
  • the ROI may correspond to an area in which important content is reproduced on the content of the 360 video.
  • the receiving-side feedback processing unit may extract and collect viewport information and transmit it to the transmitting-side feedback processing unit.
  • viewport information can be transferred using both network interfaces.
  • a viewport t6010 is displayed.
  • the viewport can span 9 tiles on a 2D image.
  • the 360 video transmission device may further include a tiling system.
  • the tiling system may be located after the data encoder ((b) shown), may be included in the above-described data encoder or transmission processing unit, or may be included in the 360 video transmission device as a separate internal / external element. .
  • the tiling system may receive viewport information from the feedback processing unit of the transmitting side.
  • the tiling system may select and transmit only the tile including the viewport area. Of the total of 16 tiles in the 2D image of (a) shown, only 9 tiles including the viewport area t6010 may be transmitted.
  • the tiling system may transmit tiles in a unicast manner over broadband. This is because the viewport area is different for each user.
  • the transmitting-side feedback processor may transmit viewport information to the data encoder.
  • the data encoder may perform encoding on tiles including the viewport area with higher quality than other tiles.
  • the transmission-side feedback processing unit may transmit viewport information to the metadata processing unit.
  • the metadata processing unit may transmit metadata related to the viewport area to each internal element of the 360 video transmission device, or may include it in the 360 video related metadata.
  • the above-described embodiments related to the viewport area may be applied in a similar manner to specific areas other than the viewport area. For example, through the above-mentioned gaze analysis, it is also determined that the area that users are mainly interested in, the ROI area, the area that is played first when the user touches 360 video through the VR display (initial view point, Initial Viewpoint) , In the same manner as the viewport area described above, the processes may be performed.
  • the transmission processing unit may perform processing for transmission differently for each tile.
  • the transmission processing unit may apply different transmission parameters (modulation order, code rate, etc.) for each tile, so that the robustness of data transmitted for each tile may be different.
  • the feedback processing unit on the transmission side may transmit the feedback information received from the 360 video receiving device to the transmission processing unit, so that the transmission processing unit performs differential transmission processing for each tile.
  • the transmission-side feedback processing unit may transmit viewport information received from the reception side to the transmission processing unit.
  • the transmission processing unit may perform transmission processing on tiles including the corresponding viewport region to have higher robustness than other tiles.
  • FIG. 8 is a diagram illustrating metadata related to 360-degree video according to an embodiment of the embodiments.
  • the aforementioned 360 video-related metadata may include various metadata for 360 video.
  • 360 video-related metadata may be referred to as 360 video-related signaling information.
  • the 360 video-related metadata may be transmitted in a separate signaling table, may be included in a DASH MPD, and may be transmitted in a file format such as ISOBMFF.
  • files, fragments, tracks, sample entries, samples, etc. may be included in various levels to include metadata for the corresponding level of data.
  • a part of the metadata to be described later is configured and delivered as a signaling table, and the other part may be included in a file format in a box or track form.
  • the 360 video-related metadata includes basic metadata related to a projection scheme, stereoscopic related metadata, and initial view (Initial View / Initial Viewpoint). Metadata, ROI-related metadata, FOV (Field of View) -related metadata, and / or cropped region-related metadata. According to an embodiment, the 360 video-related metadata may further include additional metadata in addition to the above.
  • the embodiments of the 360 video-related metadata according to the embodiments include the above-described basic metadata, stereoscopic-related metadata, initial view-related metadata, ROI-related metadata, FOV-related metadata, cropped area-related metadata, and / or Or it may be a form including at least one or more of metadata that can be added later.
  • Embodiments of the 360 video-related metadata according to the embodiments may be variously configured according to the number of cases of detailed metadata each included.
  • the metadata related to 360 video may further include additional information in addition to the above.
  • the basic metadata may include 3D model-related information, projection scheme-related information, and the like.
  • Basic metadata may include a vr_geometry field, a projection_scheme field, and the like.
  • the basic metadata may further include additional information.
  • the vr_geometry field may indicate the type of 3D model supported by the corresponding 360 video data.
  • the 3D space may have a shape according to the 3D model indicated by the vr_geometry field.
  • the 3D model used for rendering may be different from the 3D model used for re-projection indicated by the vr_geometry field.
  • the basic metadata may further include a field indicating a 3D model used in rendering.
  • the corresponding field has a value of 0, 1, 2, 3, the 3D space may follow a 3D model of a sphere, a cube, a cylinder, and a pyramid, respectively.
  • the 360 video-related metadata may further include specific information on the 3D model indicated by the corresponding field.
  • the detailed information on the 3D model may mean, for example, spherical radius information, cylinder height information, and the like. This field can be omitted.
  • the projection_scheme field may indicate a projection scheme used when the corresponding 360 video data is projected on a 2D image. If the corresponding field has values of 0, 1, 2, 3, 4, 5, respectively, the equirectangular projection scheme, the cubic projection scheme, the cylindrical projection scheme, and the tile-based projection scheme , Pyramid projection scheme, Panoramic projection scheme may have been used. If the corresponding field has a value of 6, it may be a case where 360 video data is directly projected on a 2D image without stitching. If the corresponding field has the remaining value, it can be reserved for future use (Reserved for Future Use). According to an embodiment, the 360 video-related metadata may further include specific information about a region generated by a projection scheme specified by a corresponding field. Here, the specific information about the region may mean, for example, whether the region is rotated, radius information of a top region of the cylinder, and the like.
  • the stereoscopic related metadata may include information about 3D related properties of 360 video data.
  • the stereoscopic related metadata may include an is_stereoscopic field and / or a stereo_mode field. According to an embodiment, the stereoscopic related metadata may further include additional information.
  • the is_stereoscopic field may indicate whether the corresponding 360 video data supports 3D. If the corresponding field is 1, it means 3D support, and if it is 0, it may mean 3D support. This field can be omitted.
  • the stereo_mode field may indicate a 3D layout supported by the corresponding 360 video. It is also possible to indicate whether the corresponding 360 video supports 3D only with this field. In this case, the above-described is_stereoscopic field may be omitted. When the value of this field is 0, the corresponding 360 video may be in a mono mode. That is, the projected 2D image may include only one mono view. In this case, the corresponding 360 video may not support 3D.
  • the corresponding 360 video may follow a left-right layout and a top-bottom layout, respectively.
  • the left and right layouts and the top and bottom layouts may also be called side-by-side and top-bottom formats, respectively.
  • 2D images in which the left image / right image is projected may be positioned left and right respectively on the image frame.
  • the 2D images in which the left / right images are projected may be positioned up / down on the image frame, respectively. If the corresponding field has the remaining value, it can be reserved for future use (Reserved for Future Use).
  • the metadata related to the initial viewpoint may include information about a viewpoint (initial viewpoint) that the user sees when the 360 video is first played.
  • the initial view-related metadata may include an initial_view_yaw_degree field, an initial_view_pitch_degree field, and / or an initial_view_roll_degree field.
  • the metadata related to the initial view may further include additional information.
  • the initial_view_yaw_degree field, the initial_view_pitch_degree field, and the initial_view_roll_degree field may indicate an initial viewpoint when playing the corresponding 360 video. That is, the center point of the viewport, which is initially displayed during playback, may be indicated by these three fields. Each field can indicate the position of the center point in the direction rotated around the yaw, pitch, and roll axis (sign) and the degree (angle).
  • the viewport that is displayed during the first playback may be determined according to the FOV. Through the FOV, the horizontal and vertical lengths (width and height) of the initial viewport based on the indicated initial viewpoint may be determined. That is, using these three fields and FOV information, the 360 video receiving apparatus may provide a user with a predetermined area of 360 video as an initial viewport.
  • the initial time point indicated by the metadata related to the initial time point may be changed for each scene. That is, the scene of the 360 video changes according to the temporal flow of the 360 content, and the initial view or initial viewport that the user first sees may be changed for each scene of the 360 video.
  • metadata related to the initial viewpoint may indicate an initial viewpoint for each scene.
  • the metadata related to the initial view may further include a scene identifier that identifies a scene to which the corresponding initial view is applied.
  • the metadata related to the initial view may further include FOV information for each scene indicating the FOV corresponding to the scene.
  • the ROI-related metadata may include information related to the ROI described above.
  • the ROI-related metadata may include a 2d_roi_range_flag field and / or a 3d_roi_range_flag field.
  • Each of the two fields may indicate whether ROI-related metadata includes fields representing an ROI based on a 2D image or fields representing an ROI based on 3D space.
  • the ROI-related metadata may further include additional information such as differential encoding information according to the ROI and differential transmission processing information according to the ROI.
  • the ROI-related metadata includes fields representing an ROI based on a 2D image
  • the ROI-related metadata includes a min_top_left_x field, max_top_left_x field, min_top_left_y field, max_top_left_y field, min_width field, max_width field, min_height field, max_height field, min_x Field, max_x field, min_y field, and / or max_y field.
  • the min_top_left_x field, max_top_left_x field, min_top_left_y field, and max_top_left_y field may indicate minimum / maximum values of coordinates at the upper left end of the ROI. These fields in turn may indicate the minimum x-coordinate, maximum x-coordinate, minimum y-coordinate, and maximum y-coordinate at the top left corner.
  • the min_width field, the max_width field, the min_height field, and the max_height field may indicate minimum / maximum values of the ROI's horizontal size and vertical height. These fields in turn may indicate the minimum value of the horizontal size, the maximum value of the horizontal size, the minimum value of the vertical size, and the maximum value of the vertical size.
  • the min_x field, the max_x field, the min_y field, and the max_y field may indicate minimum / maximum values of coordinates in the ROI. These fields in turn may indicate the minimum x coordinate, maximum x coordinate, minimum y coordinate, and maximum y coordinate of the coordinates in the ROI. These fields can be omitted.
  • the ROI-related metadata includes fields that represent an ROI based on coordinates in the 3D rendering space
  • the ROI-related metadata include min_yaw field, max_yaw field, min_pitch field, max_pitch field, min_roll field, max_roll field, min_field_of_view field, and / or The max_field_of_view field may be included.
  • the min_yaw field, the max_yaw field, the min_pitch field, the max_pitch field, the min_roll field, and the max_roll field may represent the area occupied by the ROI in 3D space as the minimum / maximum values of yaw, pitch, and roll.
  • These fields are, in turn, the minimum value of yaw axis rotation amount, the maximum yaw axis rotation amount, the pitch axis rotation amount, the maximum pitch axis rotation amount, the roll axis rotation amount, and the roll axis rotation. It can represent the maximum value of the whole quantity.
  • the min_field_of_view field and the max_field_of_view field may indicate the minimum / maximum value of the FOV of the corresponding 360 video data.
  • the FOV may mean a field of view displayed at a time when the 360 video is played.
  • the min_field_of_view field and the max_field_of_view field may indicate minimum and maximum values of the FOV, respectively. These fields can be omitted. These fields may be included in FOV-related metadata, which will be described later.
  • the FOV-related metadata may include information related to the FOV described above.
  • the FOV-related metadata may include a content_fov_flag field and / or a content_fov field.
  • the FOV-related metadata may further include additional information, such as information related to minimum / maximum values of the FOV described above.
  • the content_fov_flag field may indicate whether information about an intended FOV at the time of production for the corresponding 360 video exists. When this field value is 1, a content_fov field may be present.
  • the content_fov field may indicate information about an intended FOV in production for a corresponding 360 video.
  • an area displayed to the user at one time among 360 images may be determined.
  • an area of 360 video displayed at a time to a user may be determined by reflecting FOV information of this field.
  • the cropped region-related metadata may include information on a region including actual 360 video data on an image frame.
  • the image frame may include an active video area that is actually projected with 360 video data and an area that is not.
  • the active video area may be referred to as a cropped area or a default display area.
  • This active video area is an area shown as 360 video on an actual VR display, and the 360 video receiving device or VR display can process / display only the active video area. For example, if the aspect ratio of the image frame is 4: 3, only the area excluding the upper part and the lower part of the image frame may include 360 video data, which can be referred to as an active video area. .
  • the cropped region-related metadata may include is_cropped_region field, cr_region_left_top_x field, cr_region_left_top_y field, cr_region_width field, and / or cr_region_height field. According to an embodiment, the cropped region-related metadata may further include additional information.
  • the is_cropped_region field may be a flag indicating whether the entire region of the image frame is used by the 360 video receiving device or the VR display. That is, this field may indicate whether the entire image frame is an active video area. If only part of the image frame is an active video area, the following 4 fields may be further added.
  • the cr_region_left_top_x field, cr_region_left_top_y field, cr_region_width field, and cr_region_height field may indicate an active video region on an image frame.
  • Each of these fields may indicate the x-coordinate of the upper left of the active video area, the y-coordinate of the upper left of the active video area, the width of the active video area, and the height of the active video area.
  • the horizontal length and vertical length may be expressed in units of pixels.
  • 360-degree video-related signaling information or metadata may be included in an arbitrarily defined signaling table, or may be included in a file format such as ISOBMFF or Common File Format in a box form, and may be included in DASH MPD and transmitted. have.
  • 360-degree media data may be transmitted in such a file format or DASH segment.
  • FIG 9 shows a view point and a viewing position that are additionally defined in a 3DoF + VR system.
  • Embodiments of the 360 video-based VR system may provide a visual / aural experience for different viewing directions based on the user's location with respect to the 360 video based on the above-described 360 video processing process.
  • This method can be called 3 degree of freedom (DoDoF) plus.
  • a VR system that provides a start / audible experience for different directions in a user's fixed position for 360 video may be referred to as a 3DoF based VR system.
  • a VR system capable of providing an extended visual / aural experience for different directions at the same time zone and different directions at different viewing positions may be referred to as a 3DoF + or 3DoF plus based VR system. You can.
  • FIG. 10 shows a method of implementing a 360-degree video signal processing based on a 3DoF + system and a related transmission / reception device.
  • FIG. 10 is an example of a 3DoF + end-to-end system flow diagram including 3DoF + image acquisition, preprocessing, transmission, (post) processing, rendering, and feedback processes.
  • the image information may include depth information (depth) as well as visual information (texture).
  • depth depth
  • texture texture
  • Composition Synthesis to include not only information obtained through a video / audio input device, but also video (video / image, etc.), voice (audio / effect sound, etc.) and text (subtitles, etc.) through external media in the user experience. You can define a way to do it.
  • Pre-processing As a preparation (pre-processing) process for transmission / delivery of the obtained 360 video, it may include stitching, projection, packing process by region, and / or encoding process. That is, this process may include a pre-processing process and an encoding process for changing / supplementing video / audio / text information according to the manufacturer's intention. For example, in the pre-processing process of the image, the acquired visual information is mapped onto a 360 sphere (stitching), the area boundary is removed, the color / brightness difference is reduced, or the editing operation that gives the visual effect of the image is edited.
  • the process of separating the images (view segmentation), the projection process of mapping an image on a 360 sphere into a 2D image, the process of rearranging images according to regions (region-wise packing), and the encoding process of compressing image information Can be included.
  • a plurality of projection images of different viewing positions according to different viewing positions may be generated.
  • Delivery may refer to a process of processing and transmitting video / audio data and metadata that have undergone a preparation process (pre-processing process).
  • pre-processing process As a method of transmitting a plurality of video / audio data and related metadata of different viewing positions according to different viewing positions, a broadcasting network, a communication network, or a one-way transmission method may be used as described above. You can.
  • Post-processing & composition Decode received / stored video / audio / text data and may refer to a post-processing process for final playback.
  • the post-processing process may include an unpacking to unpack the packed image and a re-projection process to restore a 2D projected image to a 3D spherical image as described above.
  • Rendering It can mean the process of rendering and displaying re-projected image / video data in 3D space.
  • the video / audio signal can be reconstructed into a form for final output.
  • the orientation, viewing position / head position, and viewpoint of the user's region of interest can be tracked, and only necessary video / audio / text information can be selectively used according to this information.
  • different viewpoints such as c may be selected according to a user's region of interest, and finally, an image in a specific direction at a specific viewpoint at a specific position as d may be output.
  • Feedback It may mean a process of transmitting various feedback information that can be obtained in the display process to the transmitting side.
  • the viewing direction, the viewing position, and the viewing point of the user's region of interest may be estimated, and feedback may be transmitted to reproduce a video / audio based on this.
  • FIG. 11 shows the structure of a 3DoF + end-to-end system.
  • 3DoF + 360 content may be provided as described above by the architecture of FIG. 11.
  • the 360 video transmission device is largely composed of a 360 video (image) / audio data acquisition part (acquisition unit), a part that processes the acquired data (video / audio pre-processor), and a composition generation unit for synthesizing additional information. ), Text, audio and a projected 360-degree video encoding unit (encoding unit) and encapsulated encoded data (encapsulation unit).
  • the encoded data may be output in the form of a bitstream, and the encoded data may be encapsulated in a file format such as ISOBMFF or CFF, or processed in the form of other DASH segments.
  • the encoded data may be delivered to a 360 video receiving device through a digital storage medium, or although not explicitly shown, undergoes processing for transmission through a transmission processing unit as described above, and then broadcasts a network or broadband. It can be transmitted through.
  • sensor orientation sensor orientation, viewing orientation for images
  • sensor information acquisition point sensor position, viewing position for images
  • sensor information acquisition location viewpoint for images
  • texture and depth information can be respectively obtained, and different video pre-processing is possible according to characteristics of each component.
  • texture information 360 omnidirectional images may be configured using images of different viewing orientations at the same viewing position obtained at the same location using image sensor location information.
  • an image stitching process may be performed.
  • projection and / or region-specific packing for changing to a format for encoding an image may be performed.
  • a depth image an image can generally be acquired through a depth camera, and in this case, a depth image may be created in the form of a texture (for example, a color for a point of a location).
  • depth data may be generated based on separately measured data.
  • a sub-picture generation may be performed by additionally packing into a video format for efficient compression or dividing it into parts that are actually required.
  • Information about the video composition used in the video pre-processing stage is transmitted as video metadata.
  • the composition generation unit synthesizes externally generated media data (video / image for video, audio / effect sound for voice, subtitle for text, etc.) based on the creator's intention in the final playback stage. Information is generated, and this information is transmitted as composition metadata.
  • the video / audio / text information after each processing is compressed using each encoder and encapsulated in units of files or segments depending on the application. At this time, only necessary information can be extracted according to the video, file, or segment configuration method.
  • information for reconstructing each data in the receiver is transmitted at a codec or file format / system level, in which information for video / audio reconstruction (video / audio metadata), composition metadata for overlay, video / It includes audio playable position (viewpoint) and viewing position information (viewing position and viewpoint metadata) for each position.
  • the processing of such information may be generated through a separate metadata processing unit.
  • the 360 video receiving device reproduces a largely received file or segment (file / segment decapsulation unit), a part that generates video / audio / text information from a bitstream (decoding unit), and plays video / audio / text It may be composed of a post-processor reconstructed in a form for tracking, a tracking unit tracking a user's region of interest, and a display that is a playback device.
  • the bitstream generated through decapsulation can be divided into video / audio / text, etc., and decoded separately in a playable form according to the type of data.
  • the location of the user's region of interest (viewpoint), the viewing position (viewing position), and the viewing orientation (viewing orientation) information are generated based on the sensor and user input information.
  • This information may be used for selection or extraction of a region of interest in each module of the 360 video receiving device, or may be used for a post-processing process for emphasizing information of the region of interest.
  • it when delivered to a 360 video transmission device, it can be used for file extraction or sub-picture selection for efficient bandwidth use, and various image reconstruction methods based on a region of interest (viewport / viewing position / viewpoint dependent processing).
  • the decoded video signal may be processed according to various processing methods according to a video configuration method.
  • a process of reconstructing an image based on information transmitted through metadata is required.
  • video metadata generated by the 360 video transmission device may be used.
  • the location, viewpoint, and direction of the user's region of interest generated through tracking Information matching the information can be selected and processed.
  • the viewing position and viewpoint metadata generated by the transmitting end can be used.
  • a rendering process according to each may be included.
  • the video data (texture, depth, overlay) that has undergone a separate rendering process undergoes a composition process, and at this time, composition metadata generated by the transmitting end may be used.
  • information for playback in the viewport can be generated according to the user's region of interest.
  • the decoded voice signal generates a reproducible voice signal through an audio renderer and / or a post-processing process. At this time, based on the information on the user's region of interest and metadata transmitted to the 360 video receiving device, the user's request is made. You can generate the right information.
  • the decoded text signal is transmitted to an overlay renderer and processed as text-based overlay information such as subtitles. If necessary, a separate text post-processing process may be included.
  • FLUS Framework for Live Uplink Streaming
  • the detailed blocks of the transmitting end and the receiving end described above can be classified into the functions of the source and the sink in FLUS (Framework for Live Uplink Streaming), respectively.
  • You can implement the function of, or source / sink in a network node.
  • the network node may include user equipment (UE).
  • the UE may include the above-described 360 video transmission device or 360 video reception device.
  • the process of transmitting and receiving based on the architecture described above can be represented as follows. The following transmit / receive processing process is described based on the video signal processing process. When processing other signals such as voice or text, the part marked with italic is omitted or changed to suit the voice or text processing. You can.
  • the transmitting end may perform stitching for constructing a sphere image for each location / viewpoint / component.
  • a sphere image for each position / viewpoint / component is constructed, projection can be performed as a 2D image for coding.
  • a plurality of images can be created as packings to make an integrated image or as sub-pictures that are divided into images in a detailed area.
  • the packing process for each region may not be performed as an optional process, and in this case, the packing processing unit may be omitted.
  • the input data is video / audio / text supplementary information, it can tell how to add the additional information to the central image and display it, and also transmit the additional data.
  • the encapsulation process of converting the generated image and the added data into a file format for transmission or storage may be performed through an encoding process of compressing and generating a bit stream.
  • a process of extracting a file required by the receiver may be processed according to an application or a system request.
  • the generated bitstream can be transmitted after being converted into a transmission format through a transmission processing unit.
  • the transmitting side feedback processing unit may process the location / viewpoint / direction information and necessary metadata based on the information transmitted from the receiving end, and transmit it to be processed by the related transmitting unit.
  • the receiving end may extract a necessary file after receiving the bitstream delivered by the transmitting end.
  • the video stream in the generated file format is selected using position / viewpoint / direction information and video metadata delivered from the feedback processor, and the selected bitstream can be reconstructed into video information through a decoder.
  • unpacking may be performed based on packing information transmitted through metadata. If the packing process is omitted at the transmitting end, unpacking at the receiving end may also be omitted.
  • an image suitable for a position / viewpoint / direction transmitted from the feedback processing unit and a required component may be performed.
  • a rendering process of reconstructing an image texture, depth, and overlay information into a format suitable for reproduction may be performed.
  • a composition process of integrating information of different layers may be performed, and an image suitable for a display viewport may be generated and reproduced.
  • the 360 video-based VR system may provide a visual / aural experience for different viewing directions based on the user's location with respect to the 360 video based on the 360 video processing process.
  • a service that provides a start / audience experience for different directions in a user's fixed position for 360 video may be referred to as a 3DoF-based service.
  • a service capable of providing an extended visual / aural experience for different directions at an arbitrary position and viewing position in the same time zone may be referred to as a 6 degree of freedom (DoF) based service.
  • DoF 6 degree of freedom
  • the file format for the 3DoF service has a structure in which, for example, as shown in FIG. 15, the location of rendering, information of a file to be transmitted, decoding information, etc. may vary according to a head / eye tracking module.
  • this method is not suitable for 6DoF media file transmission, where rendering information / transmission content and decoding information vary depending on the user's location or position.
  • 16 shows the type of media according to the user's movement.
  • Embodiments propose a method of providing 6DoF contents to provide the user with an immersive media / Immersive media experience.
  • Immersive media / realistic media is an expanded concept in the virtual environment provided by the existing 360 contents, and the user's position position is fixed in the form of (a) of the existing 360 contents.
  • the type media / sensational media provides the environment or contents that can provide more various sensory experiences such as movement / rotation of the user in the virtual space by giving the concept of movement when experiencing the content to the user as shown in (b) or (c) Can mean
  • (a) represents the media experience when the user's view is rotated while the user's position is fixed.
  • (b) shows the media experience when the user's head can move further while the user's position is fixed.
  • (c) represents the media experience when the user's position can move.
  • the sensational media content may include 6DoF video and 6DoF audio to provide the content, and the 6DoF video is a video or image captured or played as a newly formed 3DoF or 360 video for each movement required to provide the sensational media content.
  • 6DoF content may mean a video or image displayed on a 3D space. If the movement is fixed within the content, the content can be represented in various forms of 3D space, such as the existing 360 video. For example, it may be represented on a spherical surface. If the movement is free within the content, a three-dimensional space is newly formed around the user on the movement path each time, and the user can experience the content at the corresponding location.
  • 6DoF audio is audio content for providing content that enables users to experience sensational media, and may mean content for newly forming and consuming spatial audio as the location of sound consumption moves.
  • the embodiments particularly propose a method for effectively providing 6DoF video.
  • 6DoF video can be captured by two or more cameras at different locations. The captured video is transmitted through a series of processes, and the receiving side can process and render some of the received data as a 360 video with the user's initial position as the origin. By processing and rendering 360 video, 6 DoF video can be provided to the user.
  • 17 shows the overall architecture for providing 6DoF video.
  • HDCA High Density Camera Array
  • Lenslet microlens
  • the pre-processing process of the acquired image may be a process of processing captured images / videos and metadata transmitted in the capture process.
  • the stitching process, color correction process, projection process, and view segmenation process are separated into a primary view and a secondary view to improve coding efficiency.
  • Any type of pre-processing step of processing content before transmission, such as an encoding process, may be applicable.
  • the stitching process may be a process of creating an image / video connecting images captured in the 360 direction from the position of each camera in a panorama or spherical shape centered on each camera position.
  • Projection means the process of projecting the image of each stitching result into a 2D image as shown in Fig3b, and can be expressed as mapping to a 2D image. Images mapped from each camera position can be separated into a main view and a sub view to apply different resolutions for each view to increase video coding efficiency. Efficiency can be improved when coding.
  • the secondary view may not exist depending on the capture environment.
  • the secondary view means an image / video that needs to be reproduced in a moving process when the user moves from the main view to another main view, and may have a lower resolution than the main view, but may have the same resolution as needed. In some cases, the secondary view may be newly generated as virtual information in the receiver.
  • a pre-processing process may further include an editing process.
  • editing of image / video data before and after projection may be further performed, and metadata may be generated in the pre-processing process.
  • metadata may be generated in the pre-processing process.
  • metadata regarding an initial viewpoint, an initial location of a user, and a region of interest (ROI) may be generated.
  • the media transmission step may be a process of processing and transmitting image / video data and metadata obtained in the pre-processing process.
  • processing according to any transmission protocol may be performed, and pre-processed data may be transmitted through a broadcast network and / or broadband, and these data may be delivered to a receiver in an on demand manner.
  • the processing process includes decoding the received image / video data and metadata, mapping it into a 3D model, or re-projecting it can also be called projection, and creating and synthesizing virtual views. All steps before generating an image for reproduction may be included in the processing step.
  • the 3D model or projection map to be mapped may have a sphere, cube, cylinder, or pyramid like the existing 360 video, and a modified form of the projection map of the existing 360 video. It can be, and in some cases, can be a freeform projection map.
  • the process of generating and synthesizing a virtual view may refer to a process of generating and synthesizing image / video data to be reproduced when the user moves between the main view and the sub view or between the main view and the main view.
  • a process of processing the metadata transferred in the capture and pre-processing process may be required, and in some cases, only a part of the 360 images / videos in the virtual viewpoint may be generated / composited.
  • the processing process may further include an editing process, an up scaling, a down scaling process, and the like.
  • an additional editing process required before playback may be applied after the processing process. If necessary, upscaling or downscaling of the transmitted image / video may be performed.
  • the rendering process may refer to a process of rendering to display a reprojected image / video transmitted or generated. Sometimes the rendering and reprojection process is collectively referred to as rendering. Therefore, a reprojection process may be included in the rendering process.
  • the re-projection can be a result of a large number of re-projections in the form of a user-centered 360 video / image and a 360 video / image that is formed around a position where the user moves according to the movement direction. have.
  • the user can view some areas of the 360 video / image, where the area the user sees can be shaped like fig.3d, and when the user moves, the entire 360 video / image is rendered. Instead, only the image corresponding to the location the user is viewing can be rendered.
  • it is possible to predict the motion in advance by receiving metadata about the user's location and the moving direction, and additionally render a video / image of the moving position.
  • the feedback process may refer to a process of transmitting various feedback information that can be obtained in the display process to the transmitting side.
  • interactivity between the 6DoF content and the user may occur, and according to an embodiment, the user's head and position position information (head / position orientation) and the area the user is currently viewing in the feedback process Information about, etc. may be delivered.
  • the information may be transmitted to the transmitting side or the service provider in the feedback process, and depending on the embodiment, the feedback process may not be performed.
  • the user's location information may mean information about the user's head position, angle, movement, and movement distance, and the viewport information viewed by the user may be calculated based on the information.
  • FIG. 18 shows a configuration of a transmission device for providing a 6DoF video service.
  • Embodiments at the transmitting side may relate to a 6DoF video transmission device.
  • the 6DoF video transmission apparatus according to the embodiments may perform the above-described preparation process and operations.
  • the 6DoF video / image transmission apparatus according to the embodiments includes a data input unit, a depth information processing unit (not shown), a stitcher, a projection processing unit, a view separation processing unit, a packing processing unit for each view, a metadata processing unit, a feedback processing unit, A data encoder, an encapsulation processing unit, a transmission processing unit, and / or a transmission unit may be included as internal / external components.
  • the data input unit may receive image / video / depth information / audio data for each viewpoint captured by one or more cameras at one or more locations.
  • the data input unit may receive metadata generated in the capture process together with video / image / depth information / audio data.
  • the data input unit may transmit the input video / image data for each viewpoint to the stitcher, and transfer the metadata generated in the capture process to the metadata processing unit.
  • the stitcher may perform stitching operations on captured images / videos for each viewpoint / position.
  • the stitcher may deliver the stitched 360 video data to the projection processing unit. If necessary, the stitcher can be stitched by receiving it from the metadata processing unit.
  • the stitcher can transfer the metadata generated during the stitching process to the metadata processing unit.
  • the stitcher can make the video / image stitching position different by using the position value received from the depth information processing unit (not shown).
  • the stitcher can transfer the metadata generated in the stitching process to the processing unit.
  • the transmitted metadata may include whether or not stitching is performed, the stitching type, the ID of the primary view and the secondary view, and location information of the corresponding view.
  • the projection processing unit may project stitched 6DoF video data into a 2D image frame. Depending on the scheme, the projection processing unit may obtain different types of results. The scheme may be similar to the existing 360 video projection scheme, or the newly proposed scheme for 6DoF may be applied. Also, different schemes can be applied for each viewpoint.
  • the depth information processing unit may transmit depth information to the projection processing unit to change the mapping result value. If necessary, the projection processing unit may receive metadata required for projection from the metadata processing unit and use it for projection, and the projection processing unit may transmit metadata generated in the projection process to the metadata processing unit.
  • the metadata may include the type of scheme, whether or not projection is performed, ID of a 2D frame after projection at a main view point and a secondary view point, and location information for each view point.
  • the packing processing unit for each time point is divided into a main time point and a secondary time point, and may perform a packing process for each region within each time point. That is, the packing processing unit for each view classifies the projected 6DoF video data for each view / location into main view and sub view, so that the main view and sub view can have different resolutions or rotate the video data of each view to improve coding efficiency. In other words, you can rearrange them, and you can have different regional resolutions divided within each time point.
  • the process of classifying the main view and the sub view may be omitted, it may be an optional process, and different resolutions for different regions or different arrangements may be selectively performed.
  • the packing may be performed by using the information received from the metadata processing unit, and the metadata generated in the packing process may be transmitted to the metadata processing unit.
  • the metadata defined in the packing process for each viewpoint may be an ID of each viewpoint to classify a major viewpoint and a secondary viewpoint, a size applied to each region within the viewpoint, and a position value for each region of rotation.
  • the above-described stitcher, projection processing unit, and / or packing processing unit for each view may occur in one or more hardware components or an ingest server in a streaming / download service.
  • the metadata processing unit may process metadata that may occur in a capture process, a stitching process, a projection process, a packing process for each viewpoint, an encoding process, an encapsulation process, and / or a processing process for transmission.
  • the metadata processing unit may generate new metadata for a 6DOF video service by using the metadata received from each process.
  • the metadata processing unit may generate the newly generated metadata in the form of a signaling table.
  • the metadata processing unit may transfer the received metadata or newly created / processed metadata from the metadata processing unit to other elements.
  • the metadata processing unit may transmit the generated or received metadata to the data encoder, the encapsulation processing unit, and / or the transmission processing unit to be transmitted to the receiving side.
  • the data encoder may encode 6DoF video data projected on 2D image frames and / or packed video data by view / region. Encoding can be performed in various formats, and if it is classified by view, the encoding result value for each view can be transmitted separately.
  • the encapsulation processing unit may encapsulate the encoded 6DoF video data and / or related metadata in the form of a file.
  • the related metadata can be received from the aforementioned metadata processing unit.
  • the encapsulation processing unit may encapsulate the data in a file format such as ISOBMFF or OMAF, or in the form of a DASH segment, or may be processed in a new format.
  • Metadata can be included in boxes that exist at various levels in the file format, included as data in separate tracks, or only metadata can be encapsulated as files. Separate encapsulation processing for each view may be possible, or necessary metadata for each view and corresponding video information may be encapsulated together.
  • the transmission processing unit may apply additional processing for transmission to the encapsulated video data according to the format.
  • the processing can be performed by using the metadata received from the metadata processing unit.
  • the transmission unit may transmit data and / or metadata received from the transmission processing unit through a broadcast network and / or broadband.
  • the transmission unit may include components necessary for transmission through a broadcasting network and / or broadband.
  • the feedback processing unit may further include and / or a network interface (not shown).
  • the network interface may receive feedback information from the receiving device described later in the embodiments, and transmit the feedback information to the feedback processing unit (transmission side).
  • the feedback processing unit may transmit information received from the receiving side to the stitching, projection, point-by-point packing, encoder, encapsulation processing unit and / or transmission processing unit. It can be delivered to the field or the new metadata can be created / processed by the metadata processing unit.
  • the feedback processing unit transmits the location / viewpoint information received from the network interface to the metadata processing unit, and the metadata processing unit projection, view-by-view packing processing unit, encapsulation processing unit and / or data Coding efficiency can be improved by transmitting the corresponding location / viewpoint information to the encoder to transmit only the information and surrounding information that fits the current user's viewpoint / location.
  • the above-described components of the 6DoF video transmission device may be hardware components implemented in hardware. Depending on the embodiment, each component may be changed, omitted, or a new component may be added or replaced with another component.
  • Embodiments may relate to a receiving device.
  • the 6DoF video receiving apparatus comprises a receiving unit, a receiving processing unit, a decapsulation processing unit, a metadata parser, a feedback processing unit, a data decoder, a re-projection processing unit, a virtual view generation / synthesis unit and / or a renderer as components.
  • the receiving unit may receive video data from the above-described 6DoF transmission device. Depending on the channel through which the video data is transmitted, the receiver may receive through a broadcast network or broadband.
  • the reception processing unit may perform processing according to a transmission protocol on the received 6DoF video data.
  • the reception processing unit acquires data obtained in the previous step of the transmission processing unit by performing the procedure in the reverse order of the process performed by the transmission processing unit or through a process according to a protocol processing method.
  • the reception processing unit may transmit the obtained data to the decapsulation processing unit, and may transmit metadata received from the reception unit to the metadata parser.
  • the decapsulation processing unit may decapsulate 6 DoF video data in a file format received from the reception processing unit.
  • the decapsulation processing unit may decapsulate files according to a corresponding file format to obtain 6 DoF video and / or metadata.
  • the obtained 6DoF video data can be sent to a data decoder, and the 6DoF metadata can be delivered to a metadata parser.
  • the decapsulation processing unit may receive metametries necessary for decapsulation from a metameta parser, if necessary.
  • the data decoder can decode 6DoF video data.
  • the data decoder can receive metadata required for decoding from the metadata parser. Metadata obtained in the data decoding process may be transmitted to a metameta parser and processed.
  • the metameta parser can perform parsing / decoding for 6DoF video-related metameta.
  • the metameta-parser may transfer the obtained meta-metadata to a decapsulation processing unit, a data decoder, a re-projection processing unit, a virtual view generation / synthesis unit, and / or a renderer.
  • the re-projection processing unit may perform re-projection on the decoded 6DoF video data.
  • the re-projection processing unit may re-project 6 DoF data for each viewpoint / position into a 3D space.
  • the 3D space may have a different shape depending on the 3D model used, or may be re-projected into a 3D model of the same shape through a transformation process.
  • the re-projection processing unit may receive necessary metadata from the metadata parser. Metameta defined in the re-projection process can also be transferred to the metameta parser.
  • a 3D model of 6DoF video data for each viewpoint / location can be delivered to a metameter parser, and the 3D model of video data for each viewpoint / location is different, and the video data for all viewpoints is the same 3D model.
  • a meta area required for re-projection may be used to re-project only a specific area in a three-dimensional space, and one or more specific areas may be re-projected.
  • the virtual viewpoint generation / composite unit generates video data using the given data in the virtual viewpoint area that is not included in the 6 DoF video data received in the transmitted and re-projected 3D space, but focuses on the virtual viewpoint A process of synthesizing video data at a new viewpoint / position may be performed.
  • data of a depth information processing unit (not shown) may be used.
  • the virtual viewpoint generation / composite unit can only generate / compose a specific area received from the metameta parser and a part of the surrounding virtual viewpoint area not received.
  • the virtual viewpoint generation / synthesis unit may be selectively performed, and is performed when there is no video information corresponding to a required viewpoint and location.
  • the renderer can render 6DoF video data delivered from a re-projection or virtual view generation / composite unit. As described above, all processes occurring in the re-projection or virtual view generation / synthesis unit in the 3D space are integrated with the renderer and these processes can be performed within the renderer. Depending on the user's viewpoint / location information, only the part the user is viewing and the part on the expected path may be rendered.
  • a feedback processing unit (receiving side) and / or a network interface (not shown) may be included as additional components.
  • the receiving feedback processing unit may obtain and process feedback information from a renderer, a virtual view generation / synthesis unit, a re-projection processing unit, a data decoder, decapsulation, and / or a VR display.
  • the feedback information may include user viewport information, head and position orientation information, gaze information, gesture information, and the like.
  • the network interface may receive feedback information from the feedback processing unit, transmit it to the transmission device, or consume it in each component of the receiving side.
  • the decapsulation processing unit receives the location / viewpoint information of the user from the feedback processing unit, and if there is information of the corresponding location in the received 6DoF video, only the location information is decapsulated, decoded, re-projected, and rendered. can do. If there is no information of the location, it is possible to go through the process of decapsulation, decoding, re-projection, virtual view creation / compositing, and rendering of all 6DoF videos located around the location.
  • the above-described components of the 6DoF video receiving device may be hardware components implemented in hardware. Depending on the embodiment, each component may be changed, omitted, or a new component may be added or replaced with another component.
  • Figure 20 6 shows the configuration of a DoF video transmission / reception device.
  • the 6DoF content may be provided in the form of a file or a segment-based download or streaming service such as DASH, and a new file format or a streaming / download service method may be used instead.
  • 6DoF content may be referred to as immersive media content, light field content, or point cloud content.
  • Audio Encoding 6DoF audio data may be subjected to an audio pre-processing and encoding process.
  • metadata may be generated, and the related metadata may be subjected to an encapsulation / encoding process for transmission.
  • 6DoF video data may undergo editing, stitching, and projection processes of images acquired at various locations. Depending on the embodiment, this process may be partially performed, or the entire process may be omitted and performed at the receiver side.
  • View segmentation / packing As described above, the view separation / packing processing unit separates and packs the main view required at the receiver side and the image at the primary view (PV) position based on the stitched image, and packs it separately. After it is processed, a pre-processing process of packing the remaining images into secondary views and secondary views (SV) may be performed. In the packing process, the size and resolution of the main view and the sub view can be adjusted to increase coding efficiency. Even within the viewpoint of the same personality, it can have resolution under different conditions for each region, or be rotated and rearranged depending on the region.
  • Depth sensing and / or estimation To perform the process of extracting a depth map from two or more acquired images when a depth capture camera does not exist, and where to acquire the image if there is a depth capture camera
  • a process for storing location information may be performed to determine the depth of each object included in the image.
  • Point Cloud Fusion / extraction You can perform the process of transforming the pre-obtained depth map into encodeable data. For example, by transforming to a point cloud data type, a pre-processing process for allocating the position value of each object in 3D may be performed. Instead of the pointer cloud data type, a data type capable of expressing 3D spatial information may be applied instead. You can.
  • PV encoding / SV encoding / light field / point cloud encoding pre-packed for each viewpoint or depth information and / or location information may be image-encoded or video-encoded, respectively. Even the same content at the same time may be encoded in different bit streams for each region. It can be a new codec to be defined in MPEG-I and media formats such as HEVC-3D and OMAF ++.
  • File encapsulation 6DoF video data encoded as described above can be processed in a file format such as ISOBMFF by File-encapsulation, an encapsulation processing unit. Or, the encoded 6DoF video data can be processed into segments.
  • Metadata (including depth information) : Transfers metadata generated during the process of acquisition, stitching, projection, separation / packing, encoding, and encapsulation by 6DoF video data to the metadata processing unit or generated by the metadata processing unit Metadata can be delivered to each process.
  • the metadata generated by the transmitting side can be generated as one track or file in the encapsulation process and delivered to the receiving side.
  • the receiving side may receive a metadata stored as a separate file or a track in the file through a broadcast network or broadband.
  • Files and / or segments can be included in individual tracks for delivery based on DASH or a new model with similar functionality. At this time, MPEG DASH, MMT and / or new standards may be applied for transmission.
  • the receiving device may perform processing for receiving 6DoF video / audio data.
  • Audio deconding / Audio rendering / Loudspeakers / headphones 6DoF audio data can be provided to users through speakers and headphones after audio decoding and rendering.
  • PV / SV / light field / point cloud decoding 6DoF video data can be image to video decoding.
  • a codec applied to decoding a newly proposed codec for 6DoF in HEVC-3D, OMAF ++, and MPEG can be applied.
  • the main view point (PV) and the sub view point (SV) are separated, so that the video or image can be decoded within each view packing, and the video or image can be decoded regardless of the view classification.
  • feedback of head, position, and eye tracking can be delivered first, and images or videos from the periphery of the user's location can be separated and decoded.
  • Head / eye / position tracking As described above, a user's head, position, gaze, and viewport information can be acquired and processed.
  • Point Cloud rendering When re-projecting the captured video / image data onto a 3D space, the 3D spatial position is set, and the received video / image data is not secured, but the virtual view is a location that the user can move. The process of creating a 3D space is performed.
  • Virtual view synthesis As described above, when there is no 6DoF video data in the space where the user is located, a process of generating and synthesizing video data of a new viewpoint is performed using 6DoF video data already secured around the user's location / viewpoint. Depending on the embodiment, the process of generating and / or synthesizing the virtual viewpoint may be omitted.
  • Image composition, and rendering As described above, this is a process for rendering an image centered on the user's location. It uses video data decoded according to the user's location and gaze, or creates a virtual view / composite video around the user and The image can be rendered.
  • Figure 21 shows the 6 DoF space.
  • a concept as shown in FIG. 21 may be used to describe 6 DoF space before or after re-projection and to perform signaling thereon.
  • 6DoF space is a 360 video or 3DoF space that can be described as yaw, pitch, and roll, and the direction of movement can be divided into two types: rational and translation.
  • the rational movement can be described as a yaw, pitch, or roll, as described for the direction of the existing 3DoF as a, and may also be called an orientation movement.
  • the translation movement it can be called a movement of the position as b. It can tell where the axis has moved in the left / right (Left / Right), forward / backward, and up / down directions.Describes the value of one or more axes to describe the movement of the central axis. can do.
  • the features of the embodiments can be utilized in the invention for future 6DoF-related metadata and signaling extension by proposing an architecture for 6DoF video service and streaming, and proposing basic metadata of a signaling and file storage method.
  • Metadata generated for each process can be extended.
  • -6DoF video metadata can be stored and signaled through SEI or VUI of 6DoF video stream by adding / modifying / extending based on the proposed metadata.
  • Region may refer to a region where 360 video data projected on a 2D image is located in a packed frame through region-wise packing. .
  • the region may mean a region used in packing by region according to context. As described above, regions may be divided evenly by dividing the 2D image, or may be arbitrarily divided by a projection scheme or the like.
  • Region (general meaning, region) : Unlike the region in the region-specific packing described above, the term region may be used as a dictionary meaning. In this case, the region can have the meanings of 'region', 'zone', 'part of', which are dictionary meanings. For example, when referring to a region of a face to be described later, an expression such as 'one region of the corresponding face' may be used. In this case, the region has a meaning different from the region in the above-described region-specific packing, and both may indicate different regions, which are independent of each other.
  • Picture may refer to the entire 2D image in which 360 video data is projected. Depending on the embodiment, a projected frame or a packed frame may be a picture.
  • the sub-picture may mean a part of the above-described picture.
  • a picture may be divided into several sub-pictures to perform tiling or the like.
  • each sub-picture may be a tile.
  • an operation of reconstructing tiles or MCTS into a picture form compatible with existing HEVC may be referred to as MCTS extraction.
  • the result of this MCTS extraction may be an original tile or a sub-picture of a picture to which MCTS belongs.
  • a sub-picture may be used as a tile for tiling. That is, in tiling, the sub-picture and the tile may have the same concept.
  • the Bondi tile may be a tool for enabling parallel decoding, or may be a tool for independent decoding in VR.
  • a tile may mean a Motion Constrained Tile Set (MCTS) that limits the range of temporal inter prediction to the current tile inner range.
  • MCTS Motion Constrained Tile Set
  • the Spherical region or the Sphere region is a region on a spherical surface when 360 video data is rendered on a 3D space (for example, a spherical surface) at the receiving side.
  • the superior region is independent of the region in packing by region. That is, it is not necessary for the Superior Region to mean the same region as the Region defined in Regional Packaging.
  • the Superior Region is a term used to mean a portion of a spherical surface to be rendered, where 'Region' may mean 'region' as a dictionary meaning. Depending on the context, the Superior Region may simply be called the Region.
  • Face may be a term that refers to each face according to a projection scheme. For example, when cubemap projection is used, the front, back, sides, top, bottom, etc. may be called a face.
  • FIG. 22 shows a general point cloud compression process according to embodiments.
  • An apparatus for providing Point Cloud content may be as shown in the figure.
  • Point Cloud content is provided to provide various services to users, such as VR (Virtual Reality), AR (Augmented Reality), MR (Mixed Reality), and autonomous driving services. It provides a way to do.
  • a point cloud video may be obtained first.
  • the acquired Point Cloud video is transmitted through a series of processes, and the receiving side can process the received data back to the original Point Cloud video and render it. Through this, the Point Cloud video can be provided to the user.
  • the embodiments provide the necessary measures to effectively perform this series of processes.
  • the entire process for providing the point cloud content service may include an acquisition process, an encoding process, a transmission process, a decoding process, a rendering process, and / or a feedback process.
  • the Point Cloud Compression system may include a transmitting device and a receiving device.
  • the transmitting device may output a bitstream by encoding the Point Cloud video, and transmit it to a receiving device through a digital storage medium or a network in the form of a file or streaming (streaming segment).
  • the digital storage media may include various storage media such as USB, SD, CD, DVD, Blu-ray, HDD, SSD.
  • the transmission device may schematically include a point cloud video acquisition unit, a point cloud video encoder, and a transmission unit.
  • the receiving device may schematically include a receiving unit, a Point Cloud video decoder and a renderer.
  • the encoder may be referred to as a Point Cloud video / video / picture / frame encoding device, and the decoder may be referred to as a Point Cloud video / picture / picture / frame decoding device.
  • the transmitter can be included in the Point Cloud video encoder.
  • the receiver may be included in the Point Cloud video decoder.
  • the renderer may include a display unit, and the renderer and / or display unit may be configured as separate devices or external components.
  • the transmitting device and the receiving device may further include separate internal or external modules / units / components for a feedback process.
  • the point cloud video acquisition unit may perform a process of acquiring a point cloud video through a capture, synthesis, or generation process of a point cloud video.
  • 3D position (x, y, z) / attribute (color, reflectance, transparency, etc.) data for a number of points by the acquisition process such as PLY (Polygon File format or the Stanford Triangle format) file Can be.
  • PLY Polygon File format or the Stanford Triangle format
  • one or more files may be obtained.
  • point cloud-related metadata eg, metadata related to capture, etc.
  • It can be composed of a combination of camera equipment (a combination of an infrared pattern projector and an infrared camera) that can acquire depth for capturing point cloud content, and RGB cameras that can extract color information corresponding to depth information.
  • depth information may be extracted through a LiDAR using a radar system that measures a positional coordinate of a reflector by measuring a return time by shooting a laser pulse and returning. From the depth information, a geometry (notifying the location) composed of points in 3D space can be extracted, and an attribute representing the color / reflection of each point can be extracted from the RGB information.
  • Point Cloud content can be composed of location (x, y, z) and color (YCbCr or RGB) or reflectance (r) information for points.
  • Point Cloud content may be an outward-facing method for capturing an external environment, and an inward-facing method for capturing a central object.
  • an object e.g., a key object such as a character, a player, an object, an actor, etc.
  • the configuration of the capture camera uses the inward-facing method Can be used.
  • the configuration of the capture camera may use an outward-facing method. Since Point Cloud content can be captured through multiple cameras, a calibration process of the camera may be required before capturing the content in order to establish a global coordinate system between the cameras.
  • FIG 23 shows an arrangement of Point Cloud capture equipment according to embodiments.
  • the point cloud according to the embodiments may capture an object from the outside to the inside based on an inward-facing scheme.
  • the point cloud according to the embodiments may capture in an outward direction of an object based on an outward-facing scheme.
  • Point Cloud content may be a video or still image of an object / environment displayed on various types of 3D space.
  • the method of acquiring Point Cloud content can be composed of arbitrary Point Cloud videos based on the captured Point Cloud videos.
  • capture through a real camera may not be performed.
  • the capturing process may be replaced by simply generating the relevant data.
  • the captured Point Cloud video may need post-processing to improve the quality of the content.
  • the maximum / minimum depth value can be adjusted within the range provided by the camera equipment, but after that point data of the unwanted area may be included to remove the unwanted area (e.g., background), or to recognize the connected space.
  • a post-treatment to fill the spatial hole can be performed.
  • the point cloud extracted from cameras sharing the spatial coordinate system can be integrated into one content through a process of converting to global global coordinate systems for each point based on the position coordinates of each camera obtained through the calibration process. Through this, one wide range of Point Cloud content can be generated, or Point Cloud content with a high density of points can be obtained.
  • the Point Cloud Video Encoder can encode the input Point Cloud video into one or more video streams.
  • One video may include a plurality of frames, and one frame may correspond to a still image / picture.
  • a point cloud video may include a point cloud video / frame / picture, and a point cloud video may be used interchangeably with a point cloud video / frame / picture.
  • the Point Cloud video encoder can perform a Video-based Point Cloud Compression (V-PCC) procedure.
  • the Point Cloud video encoder can perform a series of procedures such as prediction, transform, quantization, and entropy coding for compression and coding efficiency.
  • the encoded data (encoded video / video information) may be output in the form of a bitstream.
  • the Point Cloud Video Encoder can encode the Point Cloud video by dividing it into geometry video, attribute video, occupancy map video, and auxiliary information, as described below.
  • the geometry video may include a geometry image
  • the attribute video may include an attribute image
  • the occupancy map video may include an accuancy map image.
  • the additional information may include additional patch information.
  • the attribute video / image may include a texture video / image.
  • the encapsulation processing unit may encapsulate the encoded point cloud video data and / or point cloud video related metadata in the form of a file.
  • the point cloud video-related metadata may be received from a metadata processing unit or the like.
  • the metadata processing unit may be included in the point cloud video encoder, or may be configured as a separate component / module.
  • the encapsulation processing unit may encapsulate the data in a file format such as ISOBMFF, or may process it in the form of other DASH segments.
  • the encapsulation processing unit may include point cloud video-related metadata on a file format.
  • Point cloud video metadata may be included, for example, in various levels of boxes on the ISOBMFF file format, or as data in separate tracks within a file.
  • the encapsulation processing unit may encapsulate the point cloud video-related metadata itself into a file.
  • the transmission processing unit may apply processing for transmission to the encapsulated Point cloud video data according to the file format.
  • the transmission processing unit may be included in the transmission unit, or may be configured as a separate component / module.
  • the transmission processing unit may process Point cloud video video data according to any transmission protocol.
  • the processing for transmission may include processing for delivery through a broadcast network, and processing for delivery through a broadband.
  • the transmission processing unit may receive not only the point cloud video data, but also the metadata related to the point cloud video from the metadata processing unit, and may apply processing for transmission to this.
  • the transmitting unit may transmit the encoded video / video information or data output in the form of a bitstream to a receiving unit of a receiving device through a digital storage medium or a network in a file or streaming format.
  • the digital storage media may include various storage media such as USB, SD, CD, DVD, Blu-ray, HDD, SSD.
  • the transmission unit may include an element for generating a media file through a predetermined file format, and may include an element for transmission through a broadcast / communication network.
  • the receiver may extract the bitstream and transmit it to a decoding device.
  • the receiver may receive the point cloud video data transmitted by the point cloud video transmission device according to the embodiments. Depending on the channel being transmitted, the receiver may receive point cloud video data through a broadcast network or receive point cloud video data through broadband. Alternatively, point cloud video data may be received through a digital storage medium.
  • the reception processing unit may perform processing according to a transmission protocol for the received point cloud video data.
  • the reception processing unit may be included in the reception unit, or may be configured as a separate component / module.
  • the reception processing unit may perform the reverse process of the above-described transmission processing unit so that the transmission side corresponds to the processing for transmission.
  • the receiving processing unit may transmit the acquired point cloud video data to the decapsulation processing unit, and the acquired point cloud video-related metadata may be transmitted to the metadata parser.
  • the point cloud video-related metadata obtained by the reception processing unit may be in the form of a signaling table.
  • the decapsulation processing unit may decapsulate point cloud video data in a file format received from the reception processing unit.
  • the decapsulation processing unit may decapsulate files according to ISOBMFF or the like to obtain point cloud video bitstream to point cloud video related metadata (metadata bitstream).
  • the obtained point cloud video bitstream may be delivered to the point cloud video decoder, and the acquired point cloud video related metadata (metadata bitstream) may be transmitted to the metadata processor.
  • the point cloud video bitstream may include the metadata (metadata bitstream).
  • the metadata processing unit may be included in the point cloud video decoder, or may be configured as a separate component / module.
  • the point cloud video-related metadata acquired by the decapsulation processor may be in the form of a box or track in a file format. If necessary, the decapsulation processing unit may receive metadata required for decapsulation from the metadata processing unit.
  • the point cloud video-related metadata may be transmitted to the point cloud video decoder and used in a point cloud video decoding procedure, or may be transmitted to a renderer and used in a point cloud video rendering procedure.
  • the Point Cloud video decoder may decode the video / image by receiving the bitstream and performing an operation corresponding to the operation of the Point Cloud video encoder.
  • the Point Cloud video decoder can decode the Point Cloud video into geometry video, attribute video, occupancy map video, and auxilIary information, as described later.
  • the geometry video may include a geometry image
  • the attribute video may include an attribute image
  • the occupancy map video may include an accuancy map image.
  • the additional information may include additional patch information.
  • the attribute video / image may include a texture video / image.
  • the 3D geometry is reconstructed using the decoded geometry image, the ocupancy map, and additional patch information, and may be subjected to a smoothing process afterwards.
  • the color point cloud image / picture may be reconstructed by applying a color value to the smoothed 3D geometry using a texture image.
  • the renderer can render the restored geometry and color point cloud images / pictures.
  • the rendered video / image may be displayed through the display unit. The user can view all or part of the rendered result through a VR / AR display or a general display.
  • the feedback process may include transmitting various feedback information that can be obtained in the rendering / display process to the transmitting side or to the receiving side decoder. Through the feedback process, interactivity can be provided in the consumption of Point Cloud video.
  • head orientation information, viewport information indicating an area currently viewed by the user, and the like may be transmitted.
  • the user may interact with those implemented on the VR / AR / MR / autonomous driving environment, in which case information related to the interaction may be transmitted to the sending side or the service provider side in the feedback process. have.
  • the feedback process may not be performed.
  • the head orientation information may mean information about a user's head position, angle, and movement. Based on this information, information about an area that the user is currently viewing in the Point Cloud video, that is, viewport information may be calculated.
  • Viewport information may be information about an area currently viewed by a user in the Point Cloud video.
  • gaze analysis can be performed to check how the user consumes the Point Cloud video, which area of the Point Cloud video, and how much gaze.
  • Gaze analysis may be performed at the receiving side and transmitted to the transmitting side through a feedback channel.
  • Devices such as VR / AR / MR displays can extract the viewport area based on the user's head position / orientation, and vertical or horizontal FOV supported by the device.
  • the feedback information described above may not only be delivered to the transmitting side, but may also be consumed at the receiving side. That is, a decoding process, a rendering process, and the like of the receiving side may be performed using the aforementioned feedback information. For example, only the Point Cloud video for an area currently viewed by a user may be preferentially decoded and rendered using head orientation information and / or viewport information.
  • a viewport or a viewport area may mean an area that a user is viewing in a Point Cloud video.
  • a viewpoint is a point that the user is viewing in the Point Cloud video, and may mean a center point of the viewport area. That is, the viewport is an area centered on a viewpoint, and a size shape occupied by the area may be determined by a field of view (FOV).
  • FOV field of view
  • This document relates to Point Cloud video compression as described above.
  • the method / embodiment disclosed in this document may be applied to the Moving Picture Experts Group (MPEG) PCC (point cloud compression or point cloud coding) standard or the next generation video / image coding standard.
  • MPEG Moving Picture Experts Group
  • PCC point cloud compression or point cloud coding
  • a picture / frame may generally mean a unit representing one image at a specific time.
  • a pixel or pel may mean a minimum unit constituting one picture (or image).
  • 'sample' may be used as a term corresponding to a pixel.
  • the sample may generally represent a pixel or a pixel value, may represent only a pixel / pixel value of a luma component, may represent only a pixel / pixel value of a chroma component, or a depth component It may represent only the pixel / pixel value of.
  • the unit may represent a basic unit of image processing.
  • the unit may include at least one of a specific region of a picture and information related to the region.
  • the unit may be used interchangeably with terms such as a block or area depending on the case.
  • the MxN block may include samples (or sample arrays) of M columns and N rows or a set (or array) of transform coefficients.
  • FIG 24 shows an example of point cloud, geometry, and texture image (non-padded) according to embodiments.
  • V-PCC Video-based Point Cloud Compression
  • HEVC High Efficiency Video Coding
  • VVC Video-based Point Cloud Compression
  • Occupancy map When dividing the points forming the point cloud into * patches and mapping them to the 2D plane, a binary map (binary map) indicating whether data is present at a corresponding position of the 2D plane with a value of 0 or 1 )
  • a set of points constituting a point cloud, and points belonging to the same patch are adjacent to each other in a 3D space and are mapped in the same direction among the bounding box planes on the six sides in the process of mapping to a 2D image. Can be.
  • Geometry image An image in the form of a depth map that expresses the geometry of each point constituting a point cloud in patch units. It may be composed of pixel values of one channel.
  • Texture image An image representing the color information of each point constituting a point cloud in a patch unit. It may be composed of multiple channel pixel values (e.g. 3 channels R, G, B).
  • Metadata necessary to reconstruct a point cloud from individual patches may include information about a location, size, etc. in a 2D / 3D space of a patch.
  • FIG. 25 shows a V-PCC encoding process according to embodiments.
  • the figure shows the V-PCC encoding process for generating and compressing an occupancy map, geometry image, texture image, and auxiliary patch information. .
  • the operation of each process is as follows.
  • the oscillatory patch information according to the embodiments includes information on the distribution of patches.
  • the patch generation process refers to a process of dividing a point cloud into a patch that is a unit that performs mapping in order to map a point cloud to a 2D image.
  • the patch generation process can be divided into three steps: normal value calculation, segmentation, and patch division.
  • the patch according to the embodiments represents data that maps three-dimensional data to two-dimensional data (eg, images).
  • Each point that forms a point cloud has its own direction, which is represented by a three-dimensional vector called normal.
  • normal By using the neighbors of each point obtained using K-D tree, etc., * tangent plane and normal vector of each point constituting the surface of the point cloud as shown in Figure 1-3 below can be obtained.
  • the search range in the process of finding adjacent points can be defined by the user.
  • 26 shows a tangent plane and a normal vector of a surface according to embodiments.
  • Tangent plane A plane that completely includes a tangent to a curve on a surface passing through a point of the surface.
  • the normal vector according to the embodiments is a normal vector for a tangent plane.
  • Segmentation consists of two processes: initial segmentation and refinement segmentation.
  • Each point forming the point cloud is projected on one of the six bounding box faces surrounding the point cloud, as shown in FIG. 27 to be described later.
  • Initial segmentation determines one of the planes of the bounding box to which each point is projected. It is a process.
  • FIG. 27 shows a bounding box of a point cloud according to embodiments.
  • the bounding box of the point cloud may be in the form of, for example, a cube.
  • the normal value of each point obtained in the normal value calculation process ( )and The plane with the largest dot product is determined as the projection plane of the plane. That is, the plane having the normal in the direction most similar to the normal of the point is determined as the projection plane of the corresponding point.
  • the determined plane can be identified by a value in the form of an index from 0 to 5 (cluster index).
  • Refine segmentation is a process of improving the projection plane of each point constituting the point cloud determined in the initial segmentation process in consideration of the projection planes of adjacent points.
  • the projection plane of the current point and the projection plane of adjacent points Score smoothness, which indicates the degree of coincidence, can be considered simultaneously.
  • Score smooth can be considered by assigning a weight to the score normal, and the weight value can be defined by the user. Refine segmentation can be performed repeatedly, and the number of iterations can also be defined by the user.
  • Patch segmentation is a process of dividing the entire point cloud into a patch, which is a set of adjacent points, based on the projection plane information of each point constituting the point cloud obtained in the initial / refine segmentation process.
  • Patch division can consist of the following steps.
  • the size of each patch and the occupancy map, geometry image, and texture image for each patch are determined.
  • This process is a process of determining the positions of the individual patches in the 2D image to map the previously divided patches to one 2D image.
  • Occupancy map is one of the 2D images, and is a binary map that tells whether or not data exists at a corresponding position with a value of 0 or 1.
  • Occupancy map is composed of blocks, and its resolution can be determined according to the size of the block. For example, if the block size is 1 * 1, it has a resolution in pixels. The size of the block (occupancy packing block size) can be determined by the user.
  • the process of determining the location of individual patches in the occupancy map can be configured as follows.
  • OccupancySizeU indicates the width of the occupancy map, and the unit is the occupancy packing block size.
  • OccupancySizeV indicates the height of the occupancy map, and the unit is occupancy packing block size.
  • Patch.sizeU0 indicates the width of the occupancy map, and the unit is occupancy packing block size.
  • Patch.sizeV0 indicates the height of the occupancy map, and the unit is occupancy packing block size.
  • depth values constituting the geometry image of each patch are determined, and the entire geometry image is generated based on the location of the patch determined in the above-described process.
  • the process of determining the depth values constituting the geometry image of each patch can be configured as follows.
  • the parameters may include the following information.
  • normal is obtained in the patch generation process
  • the tangent axis is the axis that coincides with the horizontal (u) axis of the patch image among the axes perpendicular to the normal
  • bitangent axis is the axes perpendicular to the normal.
  • the vertical (v) axes of the patch image three axes may be represented as in FIG. 28.
  • 29 shows a relationship between normal, tangent, and bitangent axes according to embodiments.
  • the surface according to the embodiments may include a plurality of regions (regions, for example, C1, C2, D1, D2, E1, ..etc.).
  • the tangent axis of the surface according to the embodiments is an axis coinciding with the horizontal (u) axis of the patch image among the axes perpendicular to the normal.
  • the bitangent axis of the surface according to the embodiments is an axis that coincides with the vertical (v) axis of the patch image among the axes perpendicular to the normal.
  • the normal axis of the surface according to the embodiments represents the normal generated in the patch generation.
  • -3D spatial coordinates of the patch It can be calculated through a minimum size bounding box surrounding the patch.
  • the minimum value of the tangent direction of the patch (patch 3d shift tangent axis), the minimum value of the patch bitangent direction (patch 3d shift bitangent axis), the minimum value of the patch normal direction (patch 3d shift normal axis) may be included.
  • -2D size of the patch indicates the horizontal and vertical size when the patch is packed into a 2D image.
  • the horizontal direction size (patch 2d size u) is the difference between the maximum and minimum values in the tangent direction of the bounding box
  • the vertical direction size (patch 2d size v) can be obtained as the difference between the maximum and minimum values in the bitangent direction of the bounding box.
  • 30 shows d0 and d1 configurations in min mode and d0 and d1 configurations in max mode according to embodiments.
  • the projection mode of the patch of the 2D point cloud includes a minimum mode and a maximum mode.
  • D0 according to embodiments is an image of the first layer
  • d1 according to embodiments is an image of the second layer.
  • the projection of the patch of the 2D point cloud is projected based on the minimum value, and the missing points are determined based on the layers d0 and d1.
  • Geometry image generation reconstructs the connected component for the patch and there are missing points.
  • the delta according to the embodiments may be a difference between d0 and d1.
  • Geometry image generation according to embodiments may determine missing points based on a delta value.
  • Projection mode may be one of min mode and max mode.
  • the geometry information of the patch is expressed as a depth value.
  • the minimum depth is configured in d0 as shown in FIG. 30, and the maximum depth existing within the surface thickness from the minimum depth may be composed of d1.
  • the maximum depth may be configured at d0, and the minimum depth existing within the surface thickness from the maximum depth may be configured as d1.
  • Projection mode may be applied to all point clouds by user definition, or may be applied differently for each frame or patch.
  • a projection mode capable of increasing compression efficiency or minimizing a missing point may be adaptively selected.
  • the configuration of the connected component varies depending on the projection mode according to the embodiments.
  • d0 image is set to depth0, which is the value of the normal axis minimum value of each point minus the patch's normal direction minimum value (patch 3d shift normal axis) from the patch's normal direction minimum value (patch 3d shift normal axis). Make up. If another depth value exists in a range within depth0 and surface thickness at the same location, set this value to depth1. If it does not exist, the value of depth0 is also assigned to depth1. Construct a d1 image with the Depth1 value.
  • d0 image with depth 0 which is the maximum value of each point's normal axis minus the patch's normal direction minimum value (patch 3d shift normal axis), and the patch's normal direction minimum value (patch 3d shift normal axis).
  • the entire geometry image can be created by placing the geometry image of each patch created through the above process on the entire geometry image using the location information of the patch determined in the previous 1.2 patch packing process.
  • the d1 layer of the entire created geometry image can be encoded in several ways.
  • the first is a method of encoding the depth values of the d1 image generated earlier (absolute d1 method).
  • the second method is a method of encoding a difference value between a depth value of a d1 image and a depth value of a d0 image previously generated.
  • EDD Enhanced-Delta-Depth
  • Smoothing is an operation to remove discontinuities that may occur at the patch interface due to deterioration of image quality that occurs in the compression process and can be performed as follows.
  • the process of generating a texture image is similar to the process of generating the geometry image described above, and consists of a process of generating texture images of individual patches, and arranging them at a determined position to generate the entire texture image.
  • an image having a color value e.g. R, G, B
  • a point constituting a point cloud corresponding to a corresponding location is generated instead of a depth value for generating geometry.
  • a new color value may be calculated by considering color values of the closest point and color values of adjacent points.
  • Texture images according to embodiments may also be generated with two layers of t0 / t1, such as a geometry image generated with two layers of d0 / d1.
  • 33 shows pseudo code for block to patch mapping according to embodiments.
  • Additional patch information generated in the patch generation, patch packing, geometry generation process, etc. described above is compressed.
  • Additional patch information may include the following parameters.
  • luster index that identifies the projection plane (normal)
  • patch's tangent direction minimum value patch's bitangent direction minimum value
  • patch's normal direction minimum value patch's normal direction minimum value
  • candidate index when placing the patch in order based on the 2D spatial location and size information of the patch above, multiple patches can be mapped to one block.
  • the mapped patch These make up a candidate list, and the index of how many patch data is present in the block in this list), and the local patch index (index indicating one of all patches in the frame).
  • the figure is a pseudo code showing the process of block and patch match using candidate list and local patch index.
  • the maximum number of candidate lists according to embodiments may be defined by a user.
  • Figure 34 shows push-pull background filling according to embodiments.
  • Image padding is a process of filling space other than the patch area with meaningless data for the purpose of improving compression efficiency.
  • the method of filling the empty space by copying the pixel values of the column or row corresponding to the boundary surface inside the patch can be used.
  • a push-pull background filling method may be used to fill an empty space with pixel values from a low-resolution image in the process of gradually reducing the resolution of the non-padded image and increasing the resolution again.
  • 35 shows an example of possible traversal order for a 4 * 4 size block according to embodiments.
  • Group dilation is a method of filling the empty space of geometry and texture image composed of two layers d0 / d1, t0 / t1, and the values of the two-layer empty space previously calculated through image padding are the same between the two layers. This is the process of filling in the average of the values for the location.
  • Video compression is described in FIG. 37.
  • Entropy compression process may be performed as follows.
  • Figure 1-12 shows four possible traversal orders as an example for a 4 * 4 block.
  • the best traversal order with the minimum number of runs among the possible traversal orders is selected and the index is encoded.
  • the drawing according to the embodiments is a case of selecting the third traversal order of the preceding drawing, and in this case, since the number of runs can be minimized to 2, it can be selected as the best traversal order.
  • the drawing according to the embodiments is an embodiment in which video compression is applied, and shows a schematic block diagram of a 2D video / image encoder 100 in which encoding of a video / image signal is performed.
  • the 2D video / image encoder 100 may be included in the point cloud video encoder described above, or may be composed of internal / external components.
  • the input image may include the above-described geometry image, texture image (attribute (s) image), occupancy map image, and the like.
  • the output bitstream (ie, point cloud video / image bitstream) of the point cloud video encoder may include output bitstreams for each input image (geometry image, texture image (attribute (s) image), occupancy map image, etc.). .
  • the encoder 100 includes an image segmentation unit 110, a subtraction unit 115, a conversion unit 120, a quantization unit 130, an inverse quantization unit 140, and an inverse conversion unit ( 150), an adding unit 155, a filtering unit 160, a memory 170, an inter prediction unit 180, an intra prediction unit 185, and an entropy encoding unit 190.
  • the inter prediction unit 180 and the intra prediction unit 185 may be collectively called a prediction unit. That is, the prediction unit may include an inter prediction unit 180 and an intra prediction unit 185.
  • the transform unit 120, the quantization unit 130, the inverse quantization unit 140, and the inverse transform unit 150 may be included in a residual processing unit.
  • the residual processing unit may further include a subtraction unit 115.
  • the inter prediction unit 180, the intra prediction unit 185 and the entropy encoding unit 190 may be configured by one hardware component (for example, an encoder or processor) according to an embodiment.
  • the memory 170 may include a decoded picture buffer (DPB), or may be configured by a digital storage medium.
  • DPB decoded picture buffer
  • the image splitter 110 may split an input image (or picture, frame) input to the encoding apparatus 100 into one or more processing units.
  • the processing unit may be called a coding unit (CU).
  • the coding unit may be recursively divided according to a quad-tree binary-tree (QTBT) structure from a coding tree unit (CTU) or a largest coding unit (LCU).
  • QTBT quad-tree binary-tree
  • CTU coding tree unit
  • LCU largest coding unit
  • one coding unit may be divided into a plurality of coding units of a deeper depth based on a quad tree structure and / or a binary tree structure.
  • a quad tree structure may be applied first, and a binary tree structure may be applied later.
  • a binary tree structure may be applied first.
  • a coding procedure may be performed based on a final coding unit that is no longer split.
  • the maximum coding unit may be directly used as a final coding unit based on coding efficiency according to image characteristics, or the coding unit may be recursively divided into coding units having a lower depth than optimal if necessary.
  • the coding unit of the size of can be used as the final coding unit.
  • the coding procedure may include procedures such as prediction, transformation, and reconstruction, which will be described later.
  • the processing unit may further include a prediction unit (PU) or a transform unit (TU).
  • the prediction unit and the transform unit may be partitioned or partitioned from the above-described final coding unit, respectively.
  • the prediction unit may be a unit of sample prediction
  • the transformation unit may be a unit for deriving a transform coefficient and / or a unit for deriving a residual signal from the transform coefficient.
  • the unit according to the embodiments may be used interchangeably with terms such as a block or an area.
  • the MxN block may represent samples of M columns and N rows or a set of transform coefficients.
  • the sample may generally represent a pixel or a pixel value, and may indicate only a pixel / pixel value of a luma component or only a pixel / pixel value of a saturation component.
  • the sample may be used as a term for one picture (or image) corresponding to a pixel or pel.
  • the encoding apparatus 100 is a prediction signal (a predicted block, a prediction sample array) output from the inter prediction unit 180 or the intra prediction unit 185 in an input video signal (original block, original sample array) By subtracting, a residual signal (residual block, residual sample array) may be generated, and the generated residual signal is transmitted to the conversion unit 120.
  • a unit that subtracts a prediction signal (a prediction block, a prediction sample array) from an input image signal (original block, original sample array) in the encoder 100 may be referred to as a subtraction unit 115.
  • the prediction unit may perform prediction on a block to be processed (hereinafter, referred to as a current block), and generate a predicted block including prediction samples for the current block.
  • the prediction unit may determine whether intra prediction or inter prediction is applied in units of a current block or CU. As described later in the description of each prediction mode, the prediction unit may generate various information regarding prediction, such as prediction mode information, and transmit it to the entropy encoding unit 190.
  • the prediction information may be encoded by the entropy encoding unit 190 and output in the form of a bitstream.
  • the intra prediction unit 185 may predict the current block by referring to samples in the current picture.
  • the referenced samples may be located in the neighborhood of the current block or may be located apart depending on a prediction mode.
  • prediction modes may include a plurality of non-directional modes and a plurality of directional modes.
  • the non-directional mode may include, for example, a DC mode and a planar mode (Planar mode).
  • the directional mode may include, for example, 33 directional prediction modes or 65 directional prediction modes depending on the degree of detail of the prediction direction. However, this is an example, and more or less directional prediction modes may be used depending on the setting.
  • the intra prediction unit 185 may determine a prediction mode applied to the current block using a prediction mode applied to neighboring blocks.
  • the inter prediction unit 180 may derive the predicted block for the current block based on a reference block (reference sample array) specified by a motion vector on the reference picture.
  • motion information may be predicted in units of blocks, subblocks, or samples based on the correlation of motion information between a neighboring block and a current block.
  • the motion information may include a motion vector and a reference picture index.
  • the motion information may further include inter prediction direction (L0 prediction, L1 prediction, Bi prediction, etc.) information.
  • the neighboring block may include a spatial neighboring block existing in the current picture and a temporal neighboring block present in the reference picture.
  • the reference picture including the reference block and the reference picture including the temporal neighboring block may be the same or different.
  • the temporal neighboring block may be referred to by a name such as a collocated reference block or a colCU, and a reference picture including the temporal neighboring block may be called a collocated picture (colPic).
  • the inter prediction unit 180 constructs a motion information candidate list based on neighboring blocks, and provides information indicating which candidate is used to derive the motion vector and / or reference picture index of the current block. Can be created. Inter prediction may be performed based on various prediction modes. For example, in the case of the skip mode and the merge mode, the inter prediction unit 180 may use motion information of neighboring blocks as motion information of the current block.
  • the residual signal may not be transmitted.
  • a motion vector of a current block is obtained by using a motion vector of a neighboring block as a motion vector predictor and signaling a motion vector difference. I can order.
  • the prediction signal generated through the inter prediction unit 180 or the intra prediction unit 185 may be used to generate a reconstructed signal or may be used to generate a residual signal.
  • the transform unit 120 may generate transform coefficients by applying a transform technique to the residual signal.
  • the transformation technique may include at least one of a DCT (Discrete Cosine Transform), a DST (Discrete Sine Transform), a KLT (Karhunen-Loeve Transform), a GBT (Graph-Based Transform), or a CNT (Conditionally Non-linear Transform).
  • GBT refers to a transformation obtained from this graph when it is said that the relationship information between pixels is graphically represented.
  • CNT means a transform obtained by generating a predictive signal using all previously reconstructed pixels and based on it.
  • the transform process may be applied to pixel blocks having the same size of a square, or may be applied to blocks of variable sizes other than squares.
  • the quantization unit 130 quantizes transform coefficients and is transmitted to the entropy encoding unit 190, and the entropy encoding unit 190 encodes a quantized signal (information about quantized transform coefficients) and bit You can output it as a stream. Information about the quantized transform coefficients may be called residual information.
  • the quantization unit 130 may rearrange block-type quantized transform coefficients into a one-dimensional vector form based on a coefficient scan order, and quantize the quantized transform coefficients based on the one-dimensional vector form. Information regarding transform coefficients may be generated.
  • the entropy encoding unit 190 may perform various encoding methods such as exponential Golomb (CAVLC), context-adaptive variable length coding (CAVLC), and context-adaptive binary arithmetic coding (CABAC).
  • the entropy encoding unit 190 may encode information necessary for video / image reconstruction (eg, values of syntax elements, etc.) together with the quantized transform coefficients together or separately.
  • the encoded information (ex. Encoded video / video information) may be transmitted or stored in units of network abstraction layer (NAL) units in the form of a bitstream.
  • NAL network abstraction layer
  • the network may include a broadcasting network and / or a communication network
  • the digital storage medium may include various storage media such as USB, SD, CD, DVD, Blu-ray, HDD, SSD.
  • the signal output from the entropy encoding unit 190 may be configured as an internal / external element of the encoding apparatus 100 by a transmitting unit (not shown) and / or a storing unit (not shown) for storing, or the transmitting unit It may be included in the entropy encoding unit 190.
  • the quantized transform coefficients output from the quantization unit 130 may be used to generate a prediction signal.
  • a residual signal residual block or residual samples
  • the adder 155 adds the reconstructed residual signal to the predicted signal output from the inter predictor 180 or the intra predictor 185, so that the reconstructed signal (restored picture, reconstructed block, reconstructed sample array) Can be created. If there is no residual for the block to be processed, such as when the skip mode is applied, the predicted block may be used as a reconstructed block.
  • the adding unit 155 may be called a restoration unit or a restoration block generation unit.
  • the generated reconstructed signal may be used for intra prediction of the next processing target block in the current picture, or may be used for inter prediction of the next picture through filtering as described below.
  • the filtering unit 160 may improve subjective / objective image quality by applying filtering to the reconstructed signal.
  • the filtering unit 160 may generate a modified reconstructed picture by applying various filtering methods to the reconstructed picture, and the modified reconstructed picture may be a DPB of the memory 170, specifically, the memory 170 Can be stored in.
  • the various filtering methods may include, for example, deblocking filtering, sample adaptive offset, adaptive loop filter, bilateral filter, and the like.
  • the filtering unit 160 may generate various information regarding filtering as described later in the description of each filtering method and transmit it to the entropy encoding unit 190.
  • the filtering information may be encoded by the entropy encoding unit 190 and output in the form of a bitstream.
  • the modified reconstructed picture transmitted to the memory 170 may be used as a reference picture in the inter prediction unit 180.
  • the inter prediction is applied through the encoding apparatus, prediction mismatch between the encoding apparatus 100 and the decoding apparatus can be avoided, and encoding efficiency can be improved.
  • the memory 170 DPB may store the modified reconstructed picture for use as a reference picture in the inter prediction unit 180.
  • the memory 170 may store motion information of a block from which motion information in a current picture is derived (or encoded) and / or motion information of blocks in a picture that has already been reconstructed.
  • the stored motion information may be transmitted to the inter prediction unit 180 for use as motion information of a spatial neighboring block or motion information of a temporal neighboring block.
  • the memory 170 may store reconstructed samples of blocks reconstructed in the current picture, and may transmit the reconstructed samples to the intra prediction unit 185.
  • prediction, transform, and quantization procedures may be omitted.
  • prediction, transform, and quantization procedures may be omitted for a block to which PCM (pulse coding mode) is applied, and the original sample value may be encoded as it is and output as a bitstream.
  • PCM pulse coding mode
  • the drawing according to the embodiments shows a decoding process of V-PCC for reconstructing a point cloud by decoding compressed occupancy map, geometry image, texture image, auxiliary path information. same.
  • the operation of each process is as follows.
  • 39 shows a 2D video / image decoder according to embodiments.
  • the figure is an embodiment in which video decompression is applied, and shows a schematic block diagram of a 2D video / image decoder 200 in which decoding of a video / video signal is performed.
  • the 2D video / image decoder 200 may be included in the point cloud video decoder described above, or may be composed of internal / external components.
  • the input bitstream may include a bitstream for the above-described geometry image, texture image (attribute (s) image), occupancy map image, and the like.
  • the reconstructed image (or output image, decoded image) may represent a reconstructed image for the above-described geometry image, texture image (attribute (s) image), and occupancy map image.
  • the decoding apparatus 200 includes an entropy decoding unit 210, an inverse quantization unit 220, an inverse transform unit 230, an adding unit 235, a filtering unit 240, a memory 250, and inter prediction It may be configured to include a unit 260 and the intra prediction unit 265.
  • the inter prediction unit 260 and the intra prediction unit 265 may be collectively called a prediction unit. That is, the prediction unit may include an inter prediction unit 180 and an intra prediction unit 185.
  • the inverse quantization unit 220 and the inverse conversion unit 230 may be collectively referred to as a residual processing unit. That is, the residual processing unit may include an inverse quantization unit 220 and an inverse conversion unit 230.
  • the entropy decoding unit 210, the inverse quantization unit 220, the inverse transform unit 230, the addition unit 235, the filtering unit 240, the inter prediction unit 260, and the intra prediction unit 265 described above are exemplary embodiments. It may be configured by one hardware component (for example, a decoder or processor). Also, the memory 170 may include a decoded picture buffer (DPB), or may be configured by a digital storage medium.
  • DPB decoded picture buffer
  • the decoding apparatus 200 may restore an image in response to a process in which the video / image information is processed in the encoding apparatus of FIG. 0.2-1.
  • the decoding apparatus 200 may perform decoding using a processing unit applied in the encoding apparatus.
  • the processing unit of decoding may be, for example, a coding unit, and the coding unit may be divided along a quad tree structure and / or a binary tree structure from a coding tree unit or a largest coding unit. Then, the decoded video signal decoded and output through the decoding apparatus 200 may be reproduced through the reproduction apparatus.
  • the decoding apparatus 200 may receive a signal output from the encoding apparatus of the drawing in the form of a bitstream, and the received signal may be decoded through the entropy decoding unit 210.
  • the entropy decoding unit 210 may parse the bitstream to derive information (eg, video / image information) necessary for image reconstruction (or picture reconstruction).
  • the entropy decoding unit 210 decodes information in a bitstream based on a coding method such as exponential Golomb coding, CAVLC, or CABAC, and quantizes a value of a syntax element required for image reconstruction and a transform coefficient for residual.
  • the CABAC entropy decoding method receives bins corresponding to each syntax element in the bitstream, and decodes the syntax element information to be decoded and decoding information of neighboring and decoding target blocks or information of symbols / bins decoded in the previous step.
  • the context model is determined by using, and the probability of occurrence of the bin is predicted according to the determined context model, and arithmetic decoding of the bin is performed to generate a symbol corresponding to the value of each syntax element. have.
  • the CABAC entropy decoding method may update the context model using the decoded symbol / bin information for the next symbol / bin context model after determining the context model.
  • a prediction unit inter prediction unit 260 and intra prediction unit 265
  • the entropy decoding unit 210 performs entropy decoding.
  • the dual value that is, quantized transform coefficients and related parameter information may be input to the inverse quantization unit 220.
  • information related to filtering among information decoded by the entropy decoding unit 210 may be provided to the filtering unit 240.
  • a receiving unit (not shown) receiving a signal output from the encoding device may be further configured as an internal / external element of the decoding device 200, or the receiving unit may be a component of the entropy decoding unit 210.
  • the inverse quantization unit 220 may inverse quantize the quantized transform coefficients to output transform coefficients.
  • the inverse quantization unit 220 may rearrange the quantized transform coefficients in a two-dimensional block form. In this case, the reordering may be performed based on the coefficient scan order performed by the encoding device.
  • the inverse quantization unit 220 may perform inverse quantization on the quantized transform coefficients by using a quantization parameter (for example, quantization step size information), and obtain transform coefficients.
  • a quantization parameter for example, quantization step size information
  • the inverse transform unit 230 inversely transforms the transform coefficients to obtain a residual signal (residual block, residual sample array).
  • the prediction unit may perform prediction on a current block and generate a predicted block including prediction samples for the current block.
  • the prediction unit may determine whether intra prediction is applied or inter prediction is applied to the current block based on information about the prediction output from the entropy decoding unit 210, and may determine a specific intra / inter prediction mode.
  • the intra prediction unit 265 may predict the current block by referring to samples in the current picture.
  • the referenced samples may be located in the neighborhood of the current block or may be located apart depending on a prediction mode.
  • prediction modes may include a plurality of non-directional modes and a plurality of directional modes.
  • the intra prediction unit 265 may determine a prediction mode applied to the current block using a prediction mode applied to neighboring blocks.
  • the inter prediction unit 260 may derive the predicted block for the current block based on a reference block (reference sample array) specified by a motion vector on the reference picture.
  • motion information may be predicted in units of blocks, subblocks, or samples based on the correlation of motion information between a neighboring block and a current block.
  • the motion information may include a motion vector and a reference picture index.
  • the motion information may further include inter prediction direction (L0 prediction, L1 prediction, Bi prediction, etc.) information.
  • the neighboring block may include a spatial neighboring block existing in the current picture and a temporal neighboring block present in the reference picture.
  • the inter prediction unit 260 may construct a motion information candidate list based on neighboring blocks, and derive a motion vector and / or reference picture index of the current block based on the received candidate selection information.
  • Inter prediction may be performed based on various prediction modes, and information on the prediction may include information indicating a mode of inter prediction for the current block.
  • the adder 235 adds the obtained residual signal to the predicted signal (predicted block, predicted sample array) output from the inter predictor 260 or the intra predictor 265 to restore the signal ( A reconstructed picture, a reconstructed block, and a reconstructed sample array) can be generated. If there is no residual for the block to be processed, such as when the skip mode is applied, the predicted block may be used as a reconstructed block.
  • the adder 235 may be referred to as a restoration unit or a restoration block generation unit.
  • the generated reconstructed signal may be used for intra prediction of the next processing target block in the current picture, or may be used for inter prediction of the next picture through filtering as described below.
  • the filtering unit 240 may improve subjective / objective image quality by applying filtering to the reconstructed signal.
  • the filtering unit 240 may generate a modified reconstructed picture by applying various filtering methods to the reconstructed picture, and the modified reconstructed picture may be a DPB of the memory 250, specifically, the memory 250 Can be transferred to.
  • the various filtering methods may include, for example, deblocking filtering, sample adaptive offset, adaptive loop filter, bilateral filter, and the like.
  • the (corrected) reconstructed picture stored in the DPB of the memory 250 may be used as a reference picture in the inter prediction unit 260.
  • the memory 250 may store motion information of a block from which motion information in a current picture is derived (or decoded) and / or motion information of blocks in a picture that has already been reconstructed.
  • the stored motion information may be transmitted to the inter prediction unit 260 to be used as motion information of a spatial neighboring block or motion information of a temporal neighboring block.
  • the memory 170 may store reconstructed samples of blocks reconstructed in the current picture, and may transmit the reconstructed samples to the intra prediction unit 265.
  • the embodiments described in the filtering unit 160, the inter prediction unit 180, and the intra prediction unit 185 of the encoding apparatus 100 are respectively the filtering unit 240 of the decoding apparatus 200,
  • the inter prediction unit 260 and the intra prediction unit 265 may be applied to the same or corresponding ones.
  • the prediction, transform, and quantization procedures may be omitted.
  • the prediction, transform, and quantization procedures may be omitted, and the decoded sample value may be used as a sample of the reconstructed image.
  • this is a process for restoring the occupancy map by decoding the compressed occupancy map bitstream.
  • this is a process for restoring the auxiliary patch info by decoding the compressed auxiliary patch info bitstream.
  • the patch is extracted from the geometry image using 2D position / size information of the patch included in the restored occupancy map and auxiliary patch info and mapping information of the block and patch. Then, the point cloud is restored to the 3D space by using the 3D location information of the patch included in the extracted patch geometry image and auxiliary patch info.
  • the geometry value corresponding to any point (u, v) existing in one patch is called g (u, v), and the normal, tangent, and bitangent axis coordinate values of the patch's three-dimensional space location are (0 , s0, r0), normal axis, tangent axis, and bitangent axis coordinate values (u, v), s (u, v), r ( u, v) can be expressed as follows.
  • the color values corresponding to the texture image pixel in the same position as in the geometry image in 2D space the point of the point cloud corresponding to the same position in 3D space It can be done by giving.
  • Interface information calculated in the above-described geometry smoothing process may be used as it is.
  • 40 is a flowchart of an operation of a transmitting end according to embodiments.
  • An operation process of a transmitting end for compressing and transmitting point cloud data using V-PCC according to embodiments may be as shown in the figure.
  • a patch for 2D image mapping of a point cloud is generated. Additional patch information is generated as a result of patch generation, and the information can be used in a geometry image generation process, a texture image generation, and a geometry restoration process for smoothing.
  • the generated patches go through a patch packing process that maps into a 2D image.
  • an occupancy map can be generated, and the occupancy map can be used in a geometry image generation, texture image generation, and geometry restoration process for smoothing.
  • a geometric image is generated using the additional patch information and the ocupancy map, and the generated geometric image is encoded into a bitstream through video encoding.
  • the encoding pre-processing may include an image padding procedure.
  • the generated geometry image or the reconstructed geometry image by decoding the encoded geometry bitstream may be used for 3D geometry reconstruction and may then be subjected to a smoothing process.
  • the texture image generator may generate a texture image using (smoothed) three-dimensional geometry and point clouds, additional patch information, and an ocupancy map.
  • the generated texture image can be encoded into one video bitstream.
  • the additional patch information may be encoded as one metadata bitstream in the metadata encoding unit, and the ocupancy map may be encoded as one video bitstream in the video encoding unit.
  • the generated geometry, texture image, video bitstream of the ocupancy map and additional patch information metadata bitstream can be multiplexed into one bitstream and transmitted to a receiving end through a transmitter.
  • the generated geometry, texture image, video bitstream of the ocupancy map, and additional patch information metadata bitstream may be generated with one or more track data or encapsulated into segments and transmitted to a receiving end through a transmitter.
  • the occupancy map according to the embodiments includes distribution information for a portion that may be an area, for example, a black area (padded area) other than the patch in the process of patch mapping and transmission.
  • the decoder or the receiver according to the embodiments may identify the patch and padding area based on the ocupancy map and oscillatory patch information.
  • 41 shows a flowchart of operation of a receiving end according to embodiments.
  • the operation process of the receiving end for receiving and restoring point cloud data using V-PCC may be as shown in the figure.
  • the bitstream of the received point cloud is demultiplexed into a compressed geometry image, a texture image, video bitstreams of the ocupancy map, and additional patch information metadata bitstream after file / segment decapsulation.
  • the video decoding unit and the metadata decoding unit decode the demultiplexed video bitstream and the metadata bitstream.
  • the 3D geometry is reconstructed using the decoded geometry image, the ocupancy map, and additional patch information, and then smoothed.
  • the color point cloud image / picture may be reconstructed by applying a color value to the smoothed 3D geometry using a texture image.
  • a color smoothing process may be additionally performed to improve the objective / subjective visual quality, and the modified point cloud image / picture derived through this may be performed through a rendering process (ex. By point cloud renderer). Is shown to the user through. Meanwhile, the color smoothing process may be omitted in some cases.
  • FIG. 42 shows an architecture for storing and streaming V-PCC-based point cloud data according to embodiments.
  • a method for storing and streaming Point Cloud data that supports various services such as VR (Virtual Reality), AR (Augmented Reality), MR (Mixed Reality), and autonomous driving to users.
  • Point cloud data storage and streaming may include an acquisition process, an encoding process, a transmission process, a decoding process, a rendering process, and / or a feedback process.
  • Embodiments propose a method for effectively providing point cloud media / content / data.
  • a point cloud video can be obtained.
  • Point Cloud data can be obtained through the capture, synthesis, or generation process of Point Cloud through one or more cameras.
  • a point cloud video including 3D position of each point (x, y, z position values, etc., hereinafter referred to as geometry) and property of each point (color, reflectance, transparency, etc.) It can be obtained and generated, for example, in a PLY (Polygon File format or the Stanford Triangle format) file.
  • PLY Polygon File format or the Stanford Triangle format
  • point cloud-related metadata eg, metadata related to capture, etc.
  • the captured Point Cloud video may need post-processing to improve the quality of the content.
  • the maximum / minimum depth value can be adjusted within the range provided by the camera equipment, but after that point data of the unwanted area may be included to remove the unwanted area (e.g., background), or to recognize the connected space.
  • a post-treatment to fill the spatial hole can be performed.
  • the point cloud extracted from cameras sharing the spatial coordinate system can be integrated into one content through a process of converting to global global coordinate systems for each point based on the position coordinates of each camera obtained through the calibration process. Through this, it is possible to acquire a point cloud video with a high density of points.
  • the point cloud pre-processing unit may generate one or more pictures / frames of the point cloud video.
  • a picture / frame may generally mean a unit representing one image in a specific time period.
  • Point cloud consists of one or more patches that make up a video (a set of points that make up a point cloud, and points belonging to the same patch are adjacent to each other in 3D space, and among the planes of the bounding box on the six sides in the process of mapping to a 2D image
  • a binary map that indicates whether data is present at a corresponding position in a 2D plane is a value of 0 or 1 (binary map) occupancy
  • a map picture / frame can be generated.
  • a geometry picture / frame which is a depth map type picture / frame that expresses the location information of each point constituting the Point Cloud video in units of patches
  • texture pictures / frames which are pictures / frames that express color information of each point constituting a point cloud video in a patch unit.
  • metadata necessary to reconstruct a point cloud from individual patches can be generated. This may include information about the patch, such as location and size in 2D / 3D space of each patch.
  • These pictures / frames may be continuously generated in chronological order to form a video stream or a metadata stream.
  • the Point Cloud video encoder can encode into one or more video streams associated with Point Cloud video.
  • One video may include a plurality of frames, and one frame may correspond to a still image / picture.
  • a point cloud video may include a point cloud video / frame / picture, and a point cloud video may be used interchangeably with a point cloud video / frame / picture.
  • the Point Cloud video encoder can perform a Video-based Point Cloud Compression (V-PCC) procedure.
  • the Point Cloud video encoder can perform a series of procedures such as prediction, transform, quantization, and entropy coding for compression and coding efficiency.
  • the encoded data (encoded video / video information) may be output in the form of a bitstream.
  • the Point Cloud Video Encoder converts the Point Cloud video into geometry video, attribute video, occupancy map video, and metadata, such as information about the patch, as described below. It can be divided and encoded.
  • the geometry video may include a geometry image
  • the attribute video may include an attribute image
  • the occupancy map video may include an accuancy map image.
  • the patch data which is the additional information, may include patch-related information.
  • the attribute video / image may include a texture video / image.
  • the Point Cloud image encoder can encode one or more images associated with a Point Cloud video.
  • the Point Cloud image encoder can perform a Video-based Point Cloud Compression (V-PCC) procedure.
  • the Point Cloud image encoder can perform a series of procedures such as prediction, transform, quantization, and entropy coding for compression and coding efficiency.
  • the encoded image may be output in the form of a bitstream.
  • the Point Cloud image encoder uses the Point Cloud image as a geometry image, an attribute image, an occupancy map image, and metadata, such as information about a patch, as described below. It can be divided and encoded.
  • Encapsulation may encapsulate encoded point cloud data and / or point cloud-related metadata in the form of a segment for file or streaming.
  • the point cloud-related metadata may be received from a metadata processing unit or the like.
  • the metadata processing unit may be included in the point cloud video / image encoder, or may be configured as a separate component / module.
  • the encapsulation processing unit may encapsulate the video / image / metadata in a file format such as ISOBMFF or process it in the form of a DASH segment.
  • the encapsulation processing unit may include point cloud-related metadata on a file format.
  • Point cloud metadata may be included in various levels of boxes on the ISOBMFF file format, for example, or may be included as data in separate tracks in the file.
  • the encapsulation processing unit may encapsulate the point cloud-related metadata itself into a file.
  • the transmission processing unit may apply processing for transmission to the encapsulated Point cloud data according to the file format.
  • the transmission processing unit may be included in the transmission unit, or may be configured as a separate component / module.
  • the transmission processing unit may process point cloud data according to an arbitrary transmission protocol.
  • the processing for transmission may include processing for delivery through a broadcast network, and processing for delivery through a broadband.
  • the transmission processing unit may receive point cloud-related metadata from the metadata processing unit, as well as point cloud data, and may apply processing for transmission to this.
  • the transmitting unit may transmit a point cloud bitstream or a file / segment containing the bitstream to a receiving unit of a receiving device through a digital storage medium or a network. For transmission, processing according to any transmission protocol may be performed. Data that has been processed for transmission may be transmitted through a broadcast network and / or broadband. These data may be transmitted to the receiving side in an on-demand manner.
  • the digital storage media may include various storage media such as USB, SD, CD, DVD, Blu-ray, HDD, SSD.
  • the transmission unit may include an element for generating a media file through a predetermined file format, and may include an element for transmission through a broadcast / communication network.
  • the receiver may extract the bitstream and transmit it to a decoding device.
  • the receiver may receive the point cloud data transmitted by the point cloud data transmission device according to the embodiments. Depending on the channel being transmitted, the receiver may receive point cloud data through a broadcast network or point cloud data through a broadband. Alternatively, point cloud video data may be received through a digital storage medium. The receiver may include a process of decoding the received data and rendering it according to a user's viewport.
  • the reception processing unit may perform processing according to a transmission protocol for the received point cloud video data.
  • the reception processing unit may be included in the reception unit, or may be configured as a separate component / module.
  • the reception processing unit may perform the reverse process of the above-described transmission processing unit so that the transmission side corresponds to the processing for transmission.
  • the receiving processing unit may transmit the acquired point cloud video to the decapsulation processing unit, and the acquired point cloud-related metadata may be transmitted to the metadata parser.
  • the decapsulation processing unit may decapsulate point cloud data in a file format received from the reception processing unit.
  • the decapsulation processing unit may decapsulate files according to ISOBMFF or the like to obtain point cloud bitstream to point cloud related metadata (or separate metadata bitstream).
  • the obtained point cloud bitstream may be transmitted to the point cloud decoder, and the acquired point cloud-related metadata (or metadata bitstream) may be transmitted to the metadata processing unit.
  • the point cloud bitstream may include the metadata (metadata bitstream).
  • the metadata processing unit may be included in the point cloud video decoder, or may be configured as a separate component / module.
  • the point cloud-related metadata obtained by the decapsulation processor may be in the form of a box or track in a file format.
  • the decapsulation processing unit may receive metadata required for decapsulation from the metadata processing unit.
  • the point cloud-related metadata may be transmitted to the point cloud decoder and used in the point cloud decoding procedure, or may be transmitted to a renderer and used in the point cloud rendering procedure.
  • the Point Cloud video decoder may decode the video / image by receiving the bitstream and performing an operation corresponding to the operation of the Point Cloud video encoder.
  • the Point Cloud video decoder can decode the Point Cloud video by dividing it into a geometry video, an attribute video, an occupancy map video, and additional patch related information as described below.
  • the geometry video may include a geometry image
  • the attribute video may include an attribute image
  • the occupancy map video may include an accuancy map image.
  • the additional information may include additional patch information.
  • the attribute video / image may include a texture video / image.
  • the 3D geometry is reconstructed using the decoded geometry image, the ocupancy map, and additional patch information, and may be subjected to a smoothing process afterwards.
  • the color point cloud image / picture may be reconstructed by applying a color value to the smoothed 3D geometry using a texture image.
  • the renderer can render the restored geometry and color point cloud images / pictures.
  • the rendered video / image may be displayed through the display unit. The user can view all or part of the rendered result through a VR / AR display or a general display.
  • the sensing / tracking unit obtains orientation information and / or user viewport information from a user or a receiver and transmits it to the receiver and / or transmitter.
  • Orientation information may indicate information about a user's head position, angle, movement, etc., or may indicate information about a device's location, angle, movement, etc. that the user is viewing. Based on this information, information about an area currently viewed by a user in 3D space, that is, viewport information may be calculated.
  • the viewport information may be information about an area currently viewed by a user through a device or an HMD on a 3D space.
  • a device such as a display may extract a viewport area based on orientation information and a vertical or horizontal FOV supported by the device.
  • Orientation or viewport information can be extracted or calculated at the receiving end.
  • the orientation or viewport information analyzed by the receiving side may be transmitted to the transmitting side through a feedback channel.
  • the receiving unit uses the orientation information obtained by the sensing / tracking unit and / or the viewport information indicating the area currently being viewed by the user to efficiently only media data in a specific area, that is, the area indicated by the orientation information and / or viewport information, from the file. It can be extracted or decoded.
  • the transmission unit can efficiently encode or generate and transmit only media data in a specific area, that is, an area indicated by orientation information and / or viewport information, by using orientation information and / or viewport information obtained by the sensing / tracking unit. .
  • the renderer can render the decoded Point Cloud data on the 3D space.
  • the rendered video / image may be displayed through the display unit.
  • the user can view all or part of the rendered result through a VR / AR display or a general display.
  • the feedback process may include transmitting various feedback information that can be obtained in the rendering / display process to the transmitting side or to the receiving side decoder. Through the feedback process, interactivity can be provided in the consumption of Point Cloud data.
  • head orientation information, viewport information indicating an area currently viewed by the user, and the like may be transmitted.
  • the user may interact with those implemented on a VR / AR / MR / autonomous driving environment. In this case, information related to the interaction may be transmitted to a transmitting side or a service provider side in a feedback process. have.
  • the feedback process may not be performed.
  • the feedback information described above may not only be transmitted to the transmitting side, but may also be consumed at the receiving side. That is, the decapsulation processing, decoding, and rendering process of the receiving side may be performed using the above-described feedback information.
  • point cloud data for an area currently viewed by a user may be preferentially decapsulated, decoded, and rendered using orientation information and / or viewport information.
  • FIG. 43 shows a point cloud data storage and transmission device according to embodiments.
  • the Point Cloud data storage and transmission device includes a Point Cloud Acquisition, Patch Generation, Geometry Image Generation, Attribute Image Generation, AccuCancy Map Generation (Occupancy Map Generation), Auxiliary Data Generation (Auxiliary Data Generation), Mesh Data Generation (Mesh Data Generation), Video Encoding (Image Encoding), Image Encoding (Image Encoding), File / Segment Encapsulation (File / Segment Encapsulation, and Delivery.
  • patch generation, geometry image generation, attribute image generation, accumulate map generation, auxiliary data generation, mesh data generation are referred to as point cloud pre-processing, pre-processor or control unit. can do.
  • the video encoding unit includes geometry video compression, attribute video compression, occupancy map compression, auxiliary data compression, and mesh data compression. do.
  • the image encoding unit includes Geometry video compression, Attribute video compression, Accuancy map compression, Auxiliary data compression, Mesh data compression. do.
  • the file / segment encapsulation unit includes video track encapsulation, metadata track encapsulation, and image encapsulation.
  • Each configuration of the transmission device may be a module / unit / component / hardware / software / processor or the like.
  • Point cloud geometry, attributes, auxiliary data, mesh data, etc. can be composed of separate streams or stored in different tracks in a file. Furthermore, it may be included in a separate segment.
  • Point Cloud Acquisition acquires a point cloud.
  • Point Cloud data can be acquired through the capture, synthesis or generation process of Point Cloud through one or more cameras.
  • point cloud data including the 3D position of each point (x, y, z position values, etc., hereinafter referred to as geometry) and properties of each point (color, reflectance, transparency, etc.) It can be obtained and generated, for example, in a PLY (Polygon File format or the Stanford Triangle format) file.
  • PLY Polygon File format or the Stanford Triangle format
  • point cloud-related metadata eg, metadata related to capture, etc.
  • the patch generation or patch generator creates a patch from point cloud data.
  • the patch generator generates point cloud data or point cloud video as one or more pictures / frames.
  • a picture / frame may generally mean a unit representing one image in a specific time period.
  • Point cloud consists of one or more patches that make up a video (a set of points that make up a point cloud, and points belonging to the same patch are adjacent to each other in 3D space, and among the planes of the bounding box on the six sides in the process of mapping to a 2D image When it is divided into a set of points mapped in the same direction) and mapped to a 2D plane, occupancy, which is a binary map that tells whether there is data at a corresponding position in the 2D plane as a value of 0 or 1 A map picture / frame can be generated.
  • a geometry picture / frame which is a depth map type picture / frame that expresses the location information of each point constituting the Point Cloud video in units of patches
  • a texture picture / frame which is a picture / frame representing color information of each point constituting a point cloud video in a patch unit, may be generated.
  • metadata required to reconstruct the point cloud from individual patches may be generated, and this may include information about the patch, such as the location and size of each patch in 2D / 3D space.
  • These pictures / frames may be continuously generated in chronological order to form a video stream or a metadata stream.
  • the patch can be used for 2D image mapping.
  • point cloud data can be projected on each side of a cube.
  • patch generation a geometric image, one or more attribute images, an accuancy map, auxiliary data, and / or mesh data may be generated based on the generated patch.
  • Geometry Image Generation Geometry Image Generation, Attribute Image Generation, Occupancy Map Generation, Auxiliary Data Generation and / or Mesh by pre-processor or controller Mesh data generation is performed.
  • Geometry Image Generation generates a geometry image based on the result of patch generation. Geometry represents points in three-dimensional space. Based on the patch, a geometric image is generated using an accumulate map, auxiliary data (patch data), and / or mesh data including information related to the 2D image packing of the patch. The geometry image is related to information such as depth (e.g., near, far) of the patch generated after patch generation.
  • Attribute Image Generation creates attribute images.
  • the attribute may represent texture.
  • the texture may be a color value matching each point.
  • a plurality of (N) attribute images including a texture may be generated.
  • the plurality of attributes may include materials (information about materials), reflectance, and the like.
  • the attribute may additionally include information that may vary in color depending on time and light even with the same texture.
  • Occupancy Map Generation creates an AccuFancy map from the patch.
  • the AccuFancy map includes information indicating the presence or absence of data in a pixel such as a corresponding geometry or attribute image.
  • Auxiliary data generation generates auxiliary data including information about the patch. That is, the auxiliary data represents metadata about patching of point cloud objects. For example, information such as a normal vector for a patch may be indicated. Specifically, according to embodiments, the auxiliary data may include information necessary to reconstruct a point cloud from patches (for example, information on a location, size, etc. of a patch in 2D / 3D space, projection normality (normal). ) Identification information, patch mapping information, etc.)
  • Mesh Data Generation generates mesh data from the patch.
  • Mesh indicates connection information between adjacent points.
  • it may represent triangular data.
  • mesh data according to embodiments means connectivity information between points.
  • the point cloud pre-processor or control unit generates metadata related to patch generation, geometry image generation, attribute image generation, accumulate map generation, auxiliary data generation, and mesh data generation.
  • the point cloud transmission device performs video encoding and / or image encoding in response to a result generated by the pre-processor.
  • the point cloud transmission device may generate point cloud image data as well as point cloud image data.
  • the point cloud data includes only video data, only image data and / or both video data and image data. There may be.
  • the video encoding unit performs geometric video compression, attribute video compression, accumulate map compression, auxiliary data compression, and / or mesh data compression.
  • the video encoding unit generates video stream (s) containing each encoded video data.
  • the geometry video compression encodes point cloud geometry video data.
  • the attribute video compression encodes the attribute video data of the point cloud.
  • Auxiliary data compression encodes auxiliary data associated with point cloud video data.
  • Mesh data compression encodes mesh data of Point Cloud video data. Each operation of the point cloud video encoding unit may be performed in parallel.
  • the image encoding unit performs geometric image compression, attribute image compression, accumulate map compression, auxiliary data compression, and / or mesh data compression.
  • the image encoding unit generates image (s) including each encoded image data.
  • the geometry image compression encodes point cloud geometry image data.
  • the attribute image compression encodes the attribute image data of the point cloud.
  • Auxiliary data compression encodes auxiliary data associated with point cloud image data.
  • Mesh data compression encodes mesh data associated with point cloud image data. Each operation of the point cloud image encoding unit may be performed in parallel.
  • the video encoding unit and / or the image encoding unit may receive metadata from the pre-processor.
  • the video encoding unit and / or the image encoding unit may perform each encoding process based on metadata.
  • the file / segment encapsulation unit encapsulates the video stream (s) and / or image (s) in the form of files and / or segments.
  • the file / segment encapsulation unit performs video track encapsulation, metadata track encapsulation, and / or image encapsulation.
  • Video track encapsulation can encapsulate one or more video streams into one or more tracks.
  • Metadata track encapsulation may encapsulate metadata related to a video stream and / or image into one or more tracks. Metadata includes data related to the content of point cloud data. For example, it may include Initial Viewing Orientation Metadata. According to embodiments, metadata may be encapsulated in a metadata track, or may be encapsulated together in a video track or an image track.
  • Image encapsulation can encapsulate one or more images into one or more tracks or items.
  • the four video streams and the two images may be encapsulated in one file.
  • the file / segment encapsulation unit may receive metadata from the pre-processor.
  • the file / segment encapsulation unit may perform encapsulation based on metadata.
  • the files and / or segments generated by the file / segment encapsulation are transmitted by the point cloud transmission device or transmission unit.
  • segment (s) may be delivered based on a DASH-based protocol.
  • the delivery unit may deliver a point cloud bitstream or a file / segment containing the bitstream to a receiving unit of a receiving device through a digital storage medium or a network. For transmission, processing according to any transmission protocol may be performed. Data that has been processed for transmission may be transmitted through a broadcast network and / or broadband. These data may be transmitted to the receiving side in an on-demand manner.
  • the digital storage media may include various storage media such as USB, SD, CD, DVD, Blu-ray, HDD, SSD.
  • the delivery unit may include an element for generating a media file through a predetermined file format, and may include an element for transmission through a broadcast / communication network. The delivery unit receives orientation information and / or viewport information from the receiver.
  • the delivery unit may deliver the obtained orientation information and / or viewport information (or information selected by the user) to the pre-processor, video encoding unit, image encoding unit, file / segment encapsulation unit, and / or point cloud encoding unit.
  • the point cloud encoding unit may encode all the point cloud data or the point cloud data indicated by the orientation information and / or viewport information.
  • the file / segment encapsulation unit may encapsulate all point cloud data or encapsulate point cloud data indicated by orientation information and / or viewport information.
  • the delivery unit may deliver all point cloud data or point cloud data indicated by the orientation information and / or viewport information.
  • the pre-processor may perform the above-described operation on all point cloud data or may perform the above-described operation on point cloud data indicated by orientation information and / or viewport information.
  • the video encoding unit and / or the image encoding unit may perform the above-described operation on all point cloud data, or may perform the above-described operation on point cloud data indicated by orientation information and / or viewport information.
  • the file / segment encapsulation unit may perform the above-described operation on all point cloud data, or may perform the above-described operation on point cloud data indicated by orientation information and / or viewport information.
  • the transmitting unit may perform the above-described operation on all point cloud data, or may perform the above-described operation on point cloud data indicated by orientation information and / or viewport information.
  • FIG. 44 shows a point cloud data receiving device according to embodiments.
  • the point cloud data receiving device includes a delivery client, a sensing / tracking unit, a file / segment decapsulation unit, a video decoding unit, It includes an image decoding unit, a point cloud processing and / or a point cloud rendering unit, and a display.
  • the video decoding unit is Geometry Video Decompression, Attribute Video Decompresssion, Accuancy Map Decompression, Auxiliary Data Decompression and / or Mesh Data Decompression. (Mesh Data Decompression).
  • the Image Decoding section is Geometry Image Decompression, Attribute Image Decompresssion, Accuancy Map Decompression, Auxiliary Data Decompression and / or Mesh Data Decompression. (Mesh Data Decompression).
  • Point cloud processing includes Geometry Reconstruction and Attribute Reconstruction.
  • Each configuration of the receiving device may be a module / unit / component / hardware / software / processor or the like.
  • the delivery client may receive a point cloud data, a point cloud bitstream or a file / segment including the bitstream transmitted by the point cloud data transmission device according to the embodiments.
  • the receiver may receive point cloud data through a broadcast network or point cloud data through a broadband.
  • point cloud video data may be received through a digital storage medium.
  • the receiver may include a process of decoding the received data and rendering it according to a user's viewport.
  • the reception processing unit may perform processing according to a transmission protocol for the received point cloud data.
  • the reception processing unit may be included in the reception unit, or may be configured as a separate component / module.
  • the reception processing unit may perform the reverse process of the above-described transmission processing unit so that the transmission side corresponds to the processing for transmission.
  • the receiving processing unit may transmit the acquired point cloud data to the decapsulation processing unit, and acquire the acquired point cloud-related metadata to the metadata parser.
  • the sensing / tracking unit acquires orientation information and / or viewport information.
  • the sensing / tracking unit may deliver the obtained orientation information and / or viewport information to a delivery client, a file / segment decapsulation unit, and a point cloud decoding unit.
  • the delivery client may receive all point cloud data based on orientation information and / or viewport information, or receive point cloud data indicated by orientation information and / or viewport information.
  • the file / segment decapsulation unit may decapsulate all point cloud data based on orientation information and / or viewport information, or decapsulate point cloud data indicated by orientation information and / or viewport information.
  • the point cloud decoding unit (video decoding unit and / or image decoding unit) decodes all point cloud data based on orientation information and / or viewport information, or decodes point cloud data represented by orientation information and / or viewport information. You can.
  • the point cloud processing unit may process all point cloud data or point cloud data indicated by orientation information and / or viewport information.
  • the file / segment decapsulation unit performs video track decapsulation, metadata track decapsulation, and / or image decapsulation.
  • the decapsulation processing unit may decapsulate point cloud data in a file format received from the reception processing unit.
  • the decapsulation processing unit may decapsulate files or segments according to ISOBMFF or the like to obtain point cloud bitstream to point cloud related metadata (or separate metadata bitstream).
  • the obtained point cloud bitstream may be transmitted to the point cloud decoder, and the acquired point cloud-related metadata (or metadata bitstream) may be transmitted to the metadata processing unit.
  • the point cloud bitstream may include the metadata (metadata bitstream).
  • the metadata processing unit may be included in the point cloud video decoder, or may be configured as a separate component / module.
  • the point cloud-related metadata obtained by the decapsulation processor may be in the form of a box or track in a file format. If necessary, the decapsulation processing unit may receive metadata required for decapsulation from the metadata processing unit. The point cloud-related metadata may be transmitted to the point cloud decoder and used in the point cloud decoding procedure, or may be transmitted to a renderer and used in the point cloud rendering procedure. The file / segment decapsulation unit may generate metadata related to point cloud data.
  • Video Track Decapsulation decapsulates video tracks contained in files and / or segments. Decapsulate the video stream (s) containing geometry video, attribute video, accuancy map, auxiliary data and / or mesh data.
  • Metadata Track Decapsulation decapsulates a bitstream including metadata and / or additional data related to point cloud data.
  • Image Decapsulation decapsulates image (s) including geometry images, attribute images, accumulate maps, auxiliary data and / or mesh data.
  • the video decoding unit performs geometric video decompression, attribute video decompression, accumulate map decompression, auxiliary data decompression, and / or mesh data decompression.
  • the video decoding unit decodes geometry video, attribute video, auxiliary data, and / or mesh data in response to a process performed by the video encoding unit of the point cloud transmission device according to the embodiments.
  • the image decoding unit performs geometric image decompression, attribute image decompression, accumulate map decompression, auxiliary data decompression, and / or mesh data decompression.
  • the image decoding unit decodes the geometric image, attribute image, auxiliary data, and / or mesh data in response to a process performed by the image encoding unit of the point cloud transmission device according to the embodiments.
  • the video decoding unit and / or the image decoding unit may generate video data and / or metadata related to image data.
  • the point cloud processing unit performs Geometry Reconstruction and / or Attribute Reconstruction.
  • Geometry reconstituting reconstructs the geometry video and / or geometry image based on the accumulate map, auxiliary data and / or mesh data from the decoded video data and / or the decoded image data.
  • the attribute reconstruction reconstructs the attribute video and / or attribute image based on the accuancy map, auxiliary data and / or mesh data from the decoded attribute video and / or decoded attribute image.
  • the attribute may be a texture.
  • the attribute may mean a plurality of attribute information.
  • the point cloud processing unit may receive metadata from the video decoding unit, the image decoding unit and / or the file / segment decapsulation unit, and process the point cloud based on the metadata.
  • the point cloud rendering unit renders the reconstituted point cloud.
  • the point cloud rendering unit may receive metadata from the video decoding unit, the image decoding unit and / or the file / segment decapsulation unit, and render the point cloud based on the metadata.
  • the display displays the rendered result on the actual display device.
  • 45 shows an encoding process of a point cloud data transmission device according to embodiments.
  • Patch generation receives a frame including point cloud data to generate a patch.
  • a patch may be a set of points that perform mapping together when mapping a PCC frame to a 2D plane.
  • the process of creating a patch from the PCC frame can be done in the following steps: calculating the normal vector of each point constituting the PCC, referring to FIG. 27, clustering the images projected on the six bounding box planes. Generating, reconstructing a cluster using a normal vector and an adjacent cluster, and extracting adjacent points from the cluster to generate a patch.
  • threed planes may be bound to a 3D object, and an object may be projected to each plane.
  • one point (point) may be projected onto one projection plan.
  • Embodiments can determine which plane to project the point on. Based on a vector such as a surface vector or a plane orientation vector, the corresponding projection plan of the corresponding point may be determined.
  • the previously projected result is a patch and the patch can be projected in 2D.
  • an ocupancy map is generated.
  • a process of giving data corresponding to a location is performed.
  • the patch generation according to the embodiments may generate patch information including patch generation related metadata or signaling information.
  • Patch generation according to embodiments may deliver patch information to geometry image generation, patch packing, texture image generation, smoothing and / or oscillatory patch information compression.
  • the ocupancy map according to the embodiments may be encoded based on a video coding scheme.
  • the smoothing according to the embodiments may smooth the separation in order to solve a problem (eg, to increase coding efficiency) that may cause image deterioration (for example, separation between patches) due to artifacts between patches due to an encoding process. .
  • Point cloud data can be restored again by applying texture and color to the smoothed result.
  • the generated patch data may be composed of occupancy maps, geometry images, and texture images corresponding to individual patches.
  • the Occupancy map may be a binary map indicating whether data is present at points constituting the patch.
  • Geometry image can be used to identify the positions of points constituting PCC in 3D space, can be represented by 1 channel value such as depth map, or can be composed of multiple layers. For example, near layer (D0) may be obtained by setting a specific point in the PCC to the lowest depth value, and far layer (D1) may be obtained by setting the same point to the highest depth value.
  • the texture image represents color values corresponding to each point, and can be expressed as multi-channel values such as RGB and YUV.
  • Patch packing according to embodiments: Referring to FIG. 28, description is as follows. It may be a process of determining the location of each patch in the entire 2D image. Since the determined patch location is applied equally to the occupancy map, geometry image, and texture image, one of them can be used in the packing process. The process of determining the location of the patches using the occupancy map can be as follows.
  • Patch packing according to the embodiments may generate an accuancy map including patch packing related metadata or signaling information. Patch packing according to embodiments may deliver the accuancy map to geometric image generation, texture image generation, image padding, and / or accumulation map compression.
  • Geometry image generation generates a geometry image based on a frame containing point cloud data, patch information, and / or an accumulate map. Geometry image generation may be a process of filling the entire geometry with data (i.e. depth value) based on the determined patch position and the geometry of each patch. Geometry images of multiple layers (e.g. near [d0] / far [d1] layers) can be created.
  • Texture image generation generates a texture image based on a frame including point cloud data, patch information, an accumulate map and / or smoothed geometry. Texture image generation may be a process of filling data (i.e. color value) in the entire geometry based on the determined patch position and the geometry of each patch.
  • Smoothing according to embodiments is a process of alleviating potential discontinuities. As a result of the compression, discontinuities may occur on the patch boundary. Smoothing according to embodiments reduces discontinuities.
  • the implemented approach moves boundary points to.
  • the smoothing procedure can aim at alleviating potential discontinuities that may arise at the patch boundaries due to compression artifacts.
  • the smoothing procedure can aim at alleviating potential discontinuities that may arise at the patch boundaries due to compression artifacts. the centroid of their nearest neighbors).
  • the occupancy map compression (or generation) generates an accuancy map according to the patch packing result, and compresses the accuancy map.
  • Accucity map processing may be a process of filling data (i.e. 0 or 1) in the entire occupancy map based on the determined patch location and occupancy map of individual patches. It may be considered part of the patch packing process described above.
  • the accuancy map compression according to the embodiments may be a process of compressing an occupancy map generated using arithmetic coding.
  • Auxiliary patch information compression compresses additional patch information based on patch information according to patch generation.
  • additional information of an individual patch information corresponding to an index of a projection plane, a 2D bounding box, and a 3D location of a patch may be included.
  • Image padding pads a geometry image and / or a texture image.
  • the image padding fills empty areas of the data that are not filled between patches so that they are suitable for video compression.
  • the padding data according to the embodiments may use neighboring area pixel values, average values of neighboring area pixel values, and the like.
  • Video compression encodes a geometry image and a texture image generated using codec (e.g. HEVC, AVC).
  • codec e.g. HEVC, AVC
  • the encoded geometry image (or Reconstructed geometry image) according to embodiments may be smoothed by smoothing.
  • the encoder or the point cloud data transmission device is based on the occupancy map and / or oscillatory patch information, and the decoder or the point cloud data receiving device according to the embodiments is a point position in 3D and a point position in 2D. It can be signaled to know.
  • the multiplexer includes a compressed geometry image, a compressed texture image, a compressed occupancy map, and a compressed patch information ( compressed patch info) to create a bitstream by multiplexing data constituting one PCC image.
  • a set of compressed geometry image, compressed texture image, compressed occupancy map, and compressed patch info data corresponding to one GOP may be referred to as Group of Frames (GOF).
  • the generated bitstream may be in the form of NAL unit stream, ISO BMFF file, DASH segment, MMT MPU, and the like.
  • the generated bitstream may include GOF header data indicating coding characteristics of PCC GOF.
  • Each process of the encoding process according to the embodiments may be interpreted as an operation such as a combination of hardware, software and / or processor.
  • the point cloud data transmission device may be variously referred to as an encoder, a transmitter, and a transmission device.
  • the point cloud data transmission device provides an effect of efficiently coding the point cloud data based on the embodiments described in this document, and the point cloud data receiving device according to the embodiments is a point cloud It provides an effect to efficiently decode / restore data.
  • a method of transmitting point cloud data may include generating a geometric image related to a location of point cloud data; Generating a texture image related to attributes of the point cloud data; Generating an accuancy map related to patching of point cloud data; And / or multiplexing the geometry image, texture image and accuancy map; It may include.
  • the geometry image is geometry information
  • geometry data the texture image is texture information, texture data, attribute information, attribute data, accumulate map, accumulate information, etc. It is possible.
  • the de-multiplexer includes one compressed geometry image, compressed texture image, compressed occupancy map, compressed patch info, etc. from one PCC bitstream (eg NAL unit stream, ISO BMFF file, DASH segment, MMT MPU) Demultiplex the individual data constituting the PCC image and extract it. It may include an analysis process of GOF header data indicating the coding characteristics of PCC GOF.
  • PCC bitstream eg NAL unit stream, ISO BMFF file, DASH segment, MMT MPU
  • the video decompression decodes the extracted compressed geometry image and compressed texture image using codec (e.g. HEVC, AVC).
  • codec e.g. HEVC, AVC
  • the accupancy map decompression decodes the extracted compressed occupancy map using arithmetic coding or the like.
  • Auxiliary patch information decompression is a process of decoding extracted compressed auxiliary patch information and interpreting additional information of individual patches, including index of projection plane, 2D bounding box, 3D location of patch can be included.
  • Geometry reconstruction may be a process of calculating the positions of points constituting a PCC in a three-dimensional space using decompressed geometry images, decompressed occupancy maps, decompressed auxiliary patch information, and the like.
  • the position of the calculated points can be expressed in the form of a three-dimensional position of the point (e.g. x, y, z) or the presence or absence of data (0 or 1).
  • Smoothing according to embodiments is a process to mitigate potential discontinuities. As a result of the compression, discontinuities may occur on the patch boundary. Smoothing according to embodiments reduces discontinuities. Smoothing can move boundary points to the center of the nearest neighbors on the point. Smoothing reduces discontinuities that can occur during decoding.
  • Texture reconstruction may be a process of applying a color value to a corresponding point by using the decompressed texture image and the position of the points calculated in the geometry reconstruction process.
  • the decoding process according to the embodiments may be an inverse process of the encoding process according to the embodiments.
  • a point cloud data receiving device may be variously called a decoder, a receiver, a receiving device, and the like.
  • Multiplexing multiplexes a geometry image, a texture image, an accumulate map and / or oscillatory patch information.
  • the geometry image according to embodiments may be a NALU stream.
  • the texture image according to the embodiments may be a NALU stream.
  • the geometry image, texture image, accumulate map and / or oscillatory patch information are encapsulated in the form of a file.
  • Embodiments of this document are related to how to codec to transmit and receive point cloud data, in particular, based on the V-PCC method, e.g. will be.
  • the delivery according to the embodiments transmits a PCC bitstream multiplexed with a geometry image, a texture image, an accumulate map and / or oscillatory patch information.
  • the form of delivery may include the form of an ISOBMFF file.
  • Demultiplexing demultiplexes a geometry image, a texture image, an accumulate map and / or oscillatory patch information.
  • the geometry image according to embodiments may be a NALU stream.
  • the texture image according to the embodiments may be a NALU stream.
  • the geometry image, texture image, accumulate map and / or oscillatory patch information are de-encapsulated in the form of a file.
  • the ISO BMFF file according to the embodiments may have multiple PCC tracks. Individual tracks of PCC tracks according to embodiments may include the following information.
  • the multiple track according to the embodiments may be composed of four tracks as follows.
  • a track related to Geometry / Texture image includes a restricted scheme type definition and / or an additional box of a video sample entry.
  • the restricted scheme type may further define a scheme type box to indicate information that data transmitted / received is a geometry and / or texture image (video) for a point cloud.
  • the additional box of the video sample entry may include metadata for interpreting the point cloud.
  • the video sample entry according to the embodiments may include a PCC sub box including PCC-related metadata. For example, geometry, textures, ocupancy maps, oscilloscope patch metadata, and the like can be identified.
  • Geometry / Texture image may be composed of two layers (eg, D0, D1, T0, T1). According to embodiments, a geometry / texture image may be constructed based on at least two layers for efficiency when points on a surface overlap.
  • a track related to Occupancy map / Auxiliary patch information includes a timed metadata track definition, for example, a sample entry and a sample format definition.
  • information about the position of the patch may be included in the track in the case of an ocupancy.
  • a track related to PCC track referencing according to embodiments, and includes track reference (when using differential method) between geometry D0 and D1.
  • the ISO BMFF file according to the embodiments may have a single PCC track.
  • a single track according to embodiments may include the following information.
  • a restricted scheme type definition and / or an additional box of a video sample entry is included.
  • sub-samples and sample grouping may be included.
  • the sub-sample is composed of individual images as a sub-sample, and signaling (eg, D0 or D1 or texture) is possible.
  • Sample grouping consists of individual images as samples, and can be classified using sample grouping after interleaving.
  • Sub-sampling may be necessary because samples of a single track may contain multiple pieces of information according to embodiments, and sample grouping has an effect of sequentially distinguishing samples.
  • sample auxiliary information In relation to the occupancy map / auxiliary patch information according to the embodiments, sample auxiliary information, sample grouping (Sample grouping) and / or sub-sample (Sub-sample) is included.
  • Sample auxiliary information ('saiz', 'szio' box) can be composed of individual metadata as sample auxiliary information, and can be signaled.
  • Sample grouping may be the same / similar to that described above.
  • the sub-sample is composed of individual metadata as a sub-sample and can be signaled.
  • a file may be multiplexed on one track and transmitted, and a file may be multiplexed and transmitted on multiple tracks.
  • video data for example, a geometry / texture image
  • metadata for example, accumulate map / oscillary patch information, and the like can be distinguished.
  • SchemeType for a PCC track is as follows.
  • the decoded PCC frame may include data such as geometry image of one or two layers, texture image, occupancy map, auxiliary patch information, and the like.
  • the PCC video track can contain one or more of these data, and post processing can be used to reconstruct the point cloud based on these data.
  • a track including PCC data may be identified, for example, through a 'pccv' value of scheme_type existing in SchemeTypeBox.
  • class SchemeTypeBox extends FullBox ('schm', 0, flags) ⁇
  • the SchemeType according to the embodiments may represent that the track carries point cloud data.
  • the receiver can know the type of data capable of checking whether reception / decoding is possible, and has an effect of providing compatibility.
  • the PCC file may include a PCC Video Box.
  • PCC tracks containing PCC data may have a PccVideoBox.
  • PccVideoBox can exist under SchemeInfomationBox when SchemeType is 'pccv'. Or, it can exist under VisualSampleEntry regardless of SchemeType.
  • PccVideoBox informs whether the data required to reconstruct the PCC frame, such as PCC GOF header, geometry image (D0 / D1), texture imgage, occupancy map, auxiliary patch information, etc. exists in the current track, and directly includes the PCC GOF header data. It might be.
  • Pcc_gof_header_flag may indicate whether the current track includes a PCC GOF header. If 1, the corresponding data may be included in the form of a PccGofHeader box under the PccVideoBox. If 0, PCC GOF heade is not included in the current track.
  • Geometry_image_d0_flag It may indicate whether the current track includes a geometry image of a near layer. If 1, a geometry image of the near layer may be included in the form of media data of the current track. If 0, the geometry image data of the near layer is not included in the current track.
  • Geometry_image_d1_flag It may indicate whether the current track includes a geometry image of a far layer. When 1, a geometry image of a far layer may be included in the form of media data of the current track. If 0, the current track does not include the far layer geometry image data.
  • Texture_image_flag It may indicate whether the current track includes a texture image. When 1, a texture image may be included in the form of media data of the current track. If 0, texture image data is not included in the current track.
  • Occupancy_map_flag It may indicate whether the current track includes an occupancy map. If 1, occupancy map data is included in the current track. If 0, occupancy map data is not included in the current track.
  • Auxiliary_patch_info_flag may indicate whether the current track includes auxiliary patch information. If 1, auxiliary patch information data is included in the current track. If 0, auxiliary patch information data is not included in the current track.
  • the shape of the box according to the embodiments is as follows.
  • the PccGofHeaderBox may include parameters indicating coding characteristics of PCC GoF (Group of Frames).
  • Group_of_frames_size indicates the number of frames in the current group of frames (indicates the number of frames in the current group of frames.)
  • Frame_width represents the frame width in pixels of geometry and texture videos, and this value will be multiple accusion resolution. (Indicates the frame width, in pixels, of the geometry and texture videos.It shall be multiple of occupancyResolution.)
  • Frame_height represents the frame height in pixels of geometry and texture videos, and this value will be multiple accusion resolutions (indicates the frame height, in pixels, of the geometry and texture videos.It shall be multiple of occupancyResolution.)
  • Occupancy_resolution indicates horizontal resolution and vertical resolution in pixels in which patches in geometry and texture videos are packed. It will be an even value multiple of occupancyPrecision. (Indicates the horizontal and vertical resolution, in pixels, at which patches are packed in the geometry and texture videos.It shall be an even value multiple of occupancyPrecision.)
  • Radius_to_smoothing indicates a radius for sensing neighbors for smoothing.
  • the value of radius_to_smoothing shall be in the range of 0 to 255, inclusive.
  • the value of radius_to_smoothing can be in the range of 0 to 255 (inclusive).
  • Neighbor_count_smoothing indicates the maximum number of neighbors used for smoothing.
  • the value of neighbor_count_smoothing shall be in the range of 0 to 255, inclusive.) the value of neighbor_count_smoothing can be in the range of 0 to 255 (inclusive).
  • Radius2_boundary_detection indicates a radius for boundary point detection.
  • the range of radius2_boundary_detection can be in the range of 0 to 255 (inclusive). (The value of radius2_boundary_detection shall be in the range of 0 to 255, inclusive.)
  • Threshold_smoothing represents a smoothing threshold.
  • the value of threshold_smoothing shall be in the range of 0 to 255, inclusive.
  • Lossless_geometry indicates lossless geometry coding. When lossless_geometry is 1, it indicates that the point cloud geometry information is coded losslessly. The value of lossless_geometry equal to 0 indicates that point cloud geometry information is coded losslessly. point cloud geometry information is coded in a lossy manner.
  • Lossless_texture indicates lossless texture encoding.
  • the value of lossless_texture is 1, it indicates that the point cloud texture information is coded losslessly.
  • the value of lossless_texture equal to 0 indicates that point cloud texture information is coded losslessly.
  • the value of lossless_texture equal to 0 indicates that point cloud texture information is coded losslessly.
  • point cloud texture information is coded in a lossy manner.
  • the no_attributes indicate whether the attribute is coded with geometry data. When the value of no_attributes is 1, it indicates that the coded point cloud bitstream does not include any attribute information. The value of no_attributes equal to 1 indicates that the coded point cloud bitstream does not contain any attributes information. The value of no_attributes equal to 0 indicates that the coded point cloud bitstream contains attributes information.
  • Lossless_geometry_444 indicates whether to use a 4: 2: 0 or 4: 4: 4 video format for the geometry premise.
  • the value of lossless_geometry_444 is 1, it indicates that the geometry video is coded in 4: 4: 4 format. If the value of 4: 4: 4 format is 0, it indicates that the geometry video is coded in 4: 2: 0 format. (Indicates whether to use 4: 2: 0 or 4: 4: 4 video format for geometry frames.
  • the value of lossless_geometry_444 equal to 1 indicates that the geometry video is coded in 4: 4: 4 format.
  • the value of lossless_geometry_444 equal to 0 indicates that the geometry video is coded in 4: 2: 0 format.
  • Absolute_d1_coding indicates how layers and other geometry radars proximate the projection plan are coded. When the value of absolute_d1_coding is 1, it indicates that the actual geometry values are coded for other geometry layers and layers close to the projection plane. If the value of absolute_d1_coding is 0, it indicates that the layers close to the projection plane and other geometry layers are coded differently. (indicates how the geometry layers other than the layer nearest to the projection plane are coded.absolute_d1_coding equal to 1 indicates that the actual geometry values are coded for the geometry layers other than the layer nearest to the projection plane.absolute_d1_coding equal to 0 indicates that the geometry layers other than the layer nearest to the projection plane are coded differentially.)
  • Bin_arithmetic_coding indicates that binary arithmetic coding is used. When the value of bin_arithmetic_coding is 1, it indicates that binary arithmetic coding is used for all syntax elements. The value of bin_arithmetic_coding equal to 1 indicates that binary arithmetic coding is used for all the syntax elements, which indicates that non-binary arithmetic coding is used for some syntax elements. . The value of bin_arithmetic_coding equal to 0 indicates that non-binary arithmetic coding is used for some syntax elements.)
  • the PCC file may include a PCC auxiliary patch information timed metadata track.
  • the PCC auxiliary patch information timed metadata track may include PccAuxiliaryPatchInfoSampleEntry ().
  • PccAuxiliaryPatchInfoSampleEntry can be identified as 'papi' type value, and static PCC auxiliary patch information can be included in the entry.
  • Individual samples of media data ('mdat') of the PCC auxiliary patch information timed metadata track can be configured as PccAuxiliaryPatchInfoSample (), and dynamically changing PCC auxiliary patch information can be included inside the sample.
  • class PccAuxiliaryPatchInfoSampleEntry () extends MetaDataSampleEntry ('papi') ⁇
  • Patch_count indicates the number of patches in geometry and texture videos.
  • patch_count can be greater than 0 (is the number of patches in the geometry and texture videos.It shall be larger than 0.)
  • Occupancy_precision is the horizontal and vertical resolution in pixels of the occupancy map preseason. This value corresponds to the sub-block size to which occuancy is signaled. This value can be set to size 1 to achieve lossless coding of ocupancy maps. (This corresponds to the sub-block size for which occupancy is. signaled.To achieve lossless coding of occupancy map this should be set to size 1.)
  • Max_candidate_count specifies the maximum number of candy dates in the patch candy date list (specifies the maximum number of candidates in the patch candidate list.)
  • Byte_count_u0 specifies the number of bytes for fix-length coding of patch_u0 (specifies the number of bytes for fixed-length coding of patch_u0.)
  • Byte_count_v0 specifies the number of bytes for fix-length coding of patch_v0 (specifies the number of bytes for fixed-length coding of patch_v0.)
  • Byte_count_u1 specifies the number of bytes for fix-length coding of patch_u1 (specifies the number of bytes for fixed-length coding of patch_u1.)
  • Byte_count_v1 specifies the number of bytes for fix-length coding of patch_v1 (specifies the number of bytes for fixed-length coding of patch_v1.)
  • Byte_count_d1 specifies the number of bytes for fix-length coding of patch_d1 (specifies the number of bytes for fixed-length coding of patch_d1.)
  • Byte_count_delta_size_u0 specifies the number of bytes for fix-length coding of delta_size_u0 (specifies the number of bytes for fixed-length coding of delta_size_u0.)
  • Byte_count_delta_size_v0 specifies the number of bytes for fix-length coding of delta_size_v0 (specifies the number of bytes for fixed-length coding of delta_size_v0.)
  • Patch_u0 represents the X-coordinate of the top-left corner subblock of size occupancy_resolution x occupancy_resolution of the patch bounding box.
  • the value of patch_u0 shall be in the range of 0 to frame_width / occupancy_resolution -1 (inclusive) (specifies the x-coordinate of the top-left corner subblock of size occupancy_resolution x occupancy_resolution of the patch bounding box. in the range of 0 to frame_width / occupancy_resolution 1, inclusive.)
  • Patch_v0 represents the Y-coordinate of the top-left corner subblock of size occupancy_resolution x occupancy_resolution of the patch bounding box.
  • the value of patch_v0 shall be in the range of 0 to frame_height / occupancy_resolution 1, inclusive.
  • Patch_u1 represents a minimal X-coordinate of a 3D bounding box of patch points.
  • the value of patch_u1 shall be in the range of 0 to to frame_width-1 (inclusive) (specifies the minimum x-coordinate of the 3D bounding box of patch points ..
  • the value of patch_u1 shall be in the range of 0 to frame_width 1 , inclusive.
  • Patch_v1 represents the maximum X-coordinate of the 3D bounding box of patch points.
  • the value of patch_v1 shall be in the range of 0 to frameHeight 1, (is the minimum y-coordinate of the 3D bounding box of patch points ,. inclusive.)
  • Patch_d1 specifies the minimum depth of the patches.
  • Delta_size_u0 is the difference of patch width between the current patch and the previous one.
  • Delta_size_v0 represents a difference in patch height between a current patch and a previous patch (is the difference of patch height between the current patch and the previous one.)
  • the normal_axis represents a planar projection box.
  • the value of normal_axis may be in the range of 0 to 2 (inclusive).
  • the values of normal_axis shall be in the range of 0 to 2, inclusive.normalAxis values of 0, 1, and 2 correspond to the X, Y, and Z projection axis, respectively.)
  • Candidate_index_flag specifies whether candidate_index exists or not (specifies whether candidate_index is present or not.)
  • Patch_index_flag specifies whether patch_index is present or not (specifies whether patch_index is present or not.)
  • Byte_count_candidate_index specifies the number of bytes for fix-length coding of candidate_index (specifies the number of bytes for fixed-length coding of candidate_index.)
  • Byte_count_patch_index specifies the number of bytes for fix-length coding of patch_index (specifies the number of bytes for fixed-length coding of patch_index.)
  • Candidate_index indicates an index for a patch candytate list.
  • the value of candidate_index may be in the range of 0 to max_candidate_count (inclusive) (is the index into the patch candidate list.
  • the value of candidate_index shall be in the range of 0 to max_candidate_count, inclusive.
  • Patch_index indicates an index for a patch list stored in a descending size order associated with a frame (is an index to a sorted patch list, in descending size order, associated with a frame.)
  • the PCC file includes a PCC occupancy map timed metadata track.
  • the PCC occupancy map timed metadata track may include PccOccupancyMapSampleEntry ().
  • PccOccupancyMapSampleEntry can be identified as 'papi' type value, and static PCC occupancy map data can be included in the entry.
  • Individual samples of media data ('mdat') of the PCC occupancy map timed metadata track may be configured as PccOccupancyMapSample (), and dynamically changing PCC occupancy map data may be included in the sample.
  • Block_count specifies the number of occupancy blocks (specifies the number of occupancy blocks.)
  • Empty_block_flag indicates whether the current occupancy block of ze occupancy_resolution ⁇ occupancy_resolution block is empty or not.
  • empty_block_flag 0 specifies that the current occupancy block is empty. (specifies whether the current occupancy block of size occupancy_resolution ⁇ occupancy_resolution block is empty or not.
  • Is_full indicates whether the current occupancy block of size occupancy_resolution ⁇ occupancy_resolution block is full. When is_full is 1, it indicates that the current block is full. (is_full equal to 1 specifies that the curret block is full. is_full equal to 0 specifies that the current occupancy block of size occupancy_resolution ⁇ occupancy_resolution block is full. occupancy block is not full.)
  • Best_traversal_order_index indicates a scan order for sub-blocks of size occupancy_precision ⁇ occupancy_precision in the current occupancy_resolution ⁇ occupancy_resolution block.
  • the value of best_traversal_order_index shall be in the range of 0 to 0. 4, inclusive.
  • Run_count_prefix may be used in the description of the runCountMinusTwo variable (is used in the derivation of variable runCountMinusTwo.)
  • Run_count_suffix may be used in the description of the runCountMinusTwo variable. When not present, the value of run_count_suffix is inferred to be equal to 0. (is used in the derivation of variable runCountMinusTwo.
  • unCountMinusTwo plus 2 indicates the number of signaled runs for the block.
  • runCountMinusTwo plus 2 represents the number of signalled runs for a block.
  • the value of runCountMinusTwo shall be in the range of 0 to (occupancy_resolution * occupancy_resolution) 1, inclusive.)
  • runCountMinusTwo (1 ⁇ run_count_prefix)-1 + run_count_suffix
  • the occuancy represents the occuancy value for the first subblock (of occupancyPrecision ⁇ occupancyPrecision pixels). When the ocueancy is 0, it indicates that the first sub-block is empty. If occupancy is 1, it indicates that the first sub-block is occupied (occupancy specifies the occupancy value for the first sub-block (of occupancyPrecision ⁇ occupancyPrecision pixels). Occupancy equal to 0 specifies that the first sub-block is empty. occupancy equal to 1 specifies that the first sub-block is occupied.)
  • Run_length_idx represents a run length.
  • the value of runLengthIdx shall be in the range of 0 to 14, inclusive.
  • isLengthIdx shall be in the range of 0 to 14 (inclusive).
  • Multiplexing multiplexes four data into a file.
  • multiple tracks may include each bitstream of a plurality of bitstreams, and a single track may include a plurality of bitstreams.
  • the multiple / single track according to the embodiments will be described later.
  • the multiplexing of the point cloud data transmission method may multiplex a geometry image, a texture image, an accuancy map, and an affiliation patch information into a file type or a NALU type.
  • the multiplexing of the point cloud data transmission method multiplexes a geometry image, a texture image, an accuancy map, and an affiliation patch information into a file type, where the type may include multiple tracks.
  • the multiple tracks of the point cloud data transmission method may include a first track including a geometric image, a second track including a texture image, a third track including an accumulate map and assimil patch information. have.
  • the first and second expressions are interpreted as expressions used to distinguish and / or name.
  • first track, the second track, and the third track of the point cloud data transmission method include a video group box, the video group box includes a header box, and the header box includes point cloud related data. Can indicate whether or not.
  • the multiplexing of the method for transmitting a point cloud data may multiplex a geometric image, a texture image, and an accumulate map into a file.
  • the file of the method for transmitting point cloud data may include multiple PCC tracks.
  • the multiple tracks of the point cloud data transmission method may include a first track including a geometry image, a second track including a texture image, and a third track including an accumulate map.
  • the file of the method for transmitting point cloud data may include a group box, and the group box may include information indicating at least one of a first track, a second track, or a third track.
  • embodiments may use a coding scheme for determining the presence or absence of pixels on a 4by4 block. Specifically, embodiments may use a zigzag scan method to determine the number of 1s and the number of 0s by scanning pixels. Furthermore, embodiments may use a scan scheme that reduces the number of runs based on a particular direction. This method can increase the efficiency of run-type coding.
  • the table in the drawing shows the run length according to the run length index.
  • a track / file related to PCC track grouping includes the following information.
  • Geometry image D0 / D1 tracks, texture image track, occupancy map / auxiliary patch information tracks including the data constituting the PCC may include the following PccVideoGroupBox, and may indicate that they are necessary tracks for one PCC content.
  • the PccTrackGroupBox may include the PccHeaderBox described above.
  • PCC track grouping according to embodiments may be delivered through multiple PCC tracks.
  • the decoder can efficiently identify PCC data using the above-described embodiments.
  • the demultiplexer can efficiently decode PCC data required by the decoder without latency and decoder complexity.
  • a file parser (demultiplexer) of a receiver can quickly filter data necessary for PCC content reproduction using this information. For example, geometry, image, occupancy map, aux for PCC in one file. patch info.
  • content other than PCC such as 4 tracks and 2D video tracks, is present at the same time, only 4 tracks necessary for PCC content playback can be quickly filtered using this information.
  • the receiver calculates the necessary resources to process the filtered tracks using this information, and allows the PCC content to be reproduced using only the minimum resouce (memory, decoder instance, etc.) for PCC content reproduction.
  • the decoder can identify tracks grouped based on track_group_type and / or track_group_id by viewing PCC track grouping box information according to embodiments, and can quickly filter point cloud data included in the tracks.
  • a track / file related to PCC geometry track referencing includes the following information.
  • the dependency between two tracks can be expressed through TrackReferenceBox.
  • a new 'pgdp' PCC geometry image dependency
  • the D1 track may include the 'pgdp' reference_type's TrackReferenceTypeBox
  • Track_IDs [] may include the D0 track's track_ID value.
  • PCC geometry track referencing may be delivered through multiple PCC tracks.
  • SchemeType related tracks / files for PCC tracks include the following information.
  • the decoded PCC frame may include data such as geometry image of one or two layers, texture image, occupancy map, auxiliary patch information, and the like. All of these data can be included in one PCC video track, and post cloud can be reconstructed based on these data.
  • a track including all PCC data can be identified through a 'pccs' value of scheme_type existing in SchemeTypeBox.
  • SchemeType for PCC track is delivered by a single PCC track (single PCC track). Can be.
  • class SchemeTypeBox extends FullBox ('schm', 0, flags) ⁇
  • the PCC Video Box includes the following information.
  • PCC tracks containing PCC data may have a PccVideoBox.
  • PccVideoBox can exist under SchemeInfomationBox when SchemeType is 'pccv'. Or, it can exist under VisualSampleEntry regardless of SchemeType.
  • PccVideoBox can directly include PCC GOF header data.
  • the PCC Video Box according to embodiments may be delivered by a single PCC track.
  • a method for classifying PCC data in a single track using sub-samples may be performed based on the following information.
  • media samples of the track can be divided into several sub-samples, and each sub-sample is PCC such as geometry image (D0 / D1), texture image, occupancy map, auxiliary patch information, etc. It may correspond to data.
  • codec_specific_parameters of SubSampleInformationBox can be defined and used as follows.
  • SubSampleInformationBox extends FullBox ('subs', version, flags) ⁇
  • Pcc_data_type represents a type of PCC data included in a sub-sample. For example, if 0, geometry image D0, if 1, geometry image D1, if 2, texture image, if 3, occupancy map, if 4, it can indicate that auxiliary patch information is included in the sub-sample.
  • a single PCC track may include a sample including each of geometry, texture, ocuphansi, and oscillatory map, and one sample may include a plurality of samples. Samples can be distinguished using sub-samples according to embodiments. Sub-samples according to embodiments may include geometry, textures, and the like.
  • sample, sample grouping and / or sub-sample method according to the embodiments may be applied to geometry, texture video, ocupancy map, oscillatory patch information, and the like.
  • the method of classifying PCC data using sample grouping according to the embodiments may be performed based on the following information.
  • media samples of the track may include one of PCC data such as geometry image (D0 / D1), texture image, occupancy map, and auxiliary patch information.
  • D0 / D1 geometry image
  • texture image texture image
  • occupancy map occupancy map
  • auxiliary patch information auxiliary patch information
  • class PccGeometryD0ImageGroupEntry extends VisualSampleGroupEntry ('pd0g') ⁇
  • class PccGeometryD1ImageGroupEntry extends VisualSampleGroupEntry ('pd1g') ⁇
  • class PccOccupancyMapGroupEntry extends VisualSampleGroupEntry ('pomg') ⁇
  • class PccAuxiliaryPatchInfoGroupEntry extends VisualSampleGroupEntry ('papg') ⁇
  • the visual sample group entry according to the embodiments may be extended to entries indicating type information for each of PccGeometryD0, PccGeometryD1, PccTexture, PccOccupancyMap, and PccAuxiliaryPatchInfo. Due to this, it is possible to inform the decoder according to embodiments of what data the sample transmits.
  • sample auxiliary information may be carried by a single PCC track.
  • media samples of the track can be used as one of PCC data such as geometry image (D0 / D1), texture image, occupancy map, auxiliary patch information, or using the sub-sample suggested above.
  • PCC data may be included in the media sample.
  • PCC data not included in the media sample can be set as sample auxiliary information and linked with the sample.
  • Sample auxiliary information can be stored in the same file as sample, and the following SampleAuxiliaryInformationSizesBox and SampleAuxiliaryInformationOffsetsBox can be used to describe the size and offset of the data.
  • aux_info_type and aux_info_type_parameter can be defined as follows.
  • Aux_info_type according to embodiments: In the case of 'pccd', it may indicate that PCC data is included in sample auxiliary information.
  • Pcc_data_type indicates the type of PCC data included in the sample auxiliary information. For example, if 0, occupancy map, 1, auxiliary patch information, 2, geometry image D1, 3, geometry image D0, 4, texture image may be included in sample auxiliary information.
  • aux_info_type unsigned int (32) aux_info_type
  • aux_info_type_parameter
  • sample_info_size [sample_count]
  • aux_info_type unsigned int (32) aux_info_type
  • aux_info_type_parameter
  • Signaling information is not interpreted by name, and may be interpreted based on functions / effects of signaling information.
  • 49 illustrates NALU stream-based multiplexing / demultiplexing according to embodiments.
  • Multiplexing multiplexes a geometry image (NALU stream), a texture image (NALU stream), an accuancy map and / or oscillatory patch information.
  • Multiplexing according to embodiments may be NALU-based encapsulation.
  • Delivery according to embodiments transmits multiplexed data.
  • the delivery according to the embodiments delivers a PCC bitstream including a geometry image (NALU stream), a texture image (NALU stream), an accumulate map and / or oscillatory patch information based on an ISOBMFF file.
  • Demultiplexing demultiplexes a geometry image (NALU stream), a texture image (NALU stream), an accuancy map, and / or oscillatory patch information.
  • the demultiplexing according to the embodiments may be NALU-based decapsulation.
  • NALU stream-based multiplexing / demultiplexing Detailed operations of NALU stream-based multiplexing / demultiplexing according to embodiments are described below.
  • Geometry / Texture image may distinguish D0, D1, texture, etc. using Nuh_layer_id.
  • PCC signaling for each layer. (For example, add new SEI message, information to VPS)
  • SEI messages In relation to Occupancy map / Auxiliary patch information according to embodiments, SEI messages according to embodiments are proposed.
  • 50 shows PCC layer information according to embodiments.
  • the PCC layer information SEI may be configured as follows.
  • the NAL unit stream may be composed of various layers separated by nuh_layer_id of nal_unit_header ().
  • nuh_layer_id of nal_unit_header In order to organize PCC data into one NAL unit stream, various types of PCC data can be configured as one layer.
  • PCC layer information SEI serves to identify PCC data mapping information for each layer.
  • Num_layers may mean the number of layers included in a NAL unit stream.
  • Nuh_layer_id according to embodiments: Unique identifier assigned to each layer and has the same meaning as nuh_layer_id of nal_unit_header ().
  • Pcc_data_type represents a type of PCC data included in a corresponding layer. For example, if 0, occupancy map, 1, auxiliary patch information, 2, geometry image D1, 3, geometry image D0, 4, texture image may be included in sample auxiliary information.
  • Metadata according to embodiments described below has an effect of informing pcc_data_type for each nuh_layer_id according to embodiments.
  • PCC data can be expressed using metadata according to nuh_layer_id and nuh_layer_id according to embodiments, and there is an effect of efficiently distinguishing geometry and texture.
  • the PCC auxiliary patch information SEI message may be configured as follows. The meaning of each field is similar to that of the PCC auxiliary patch information timed metadata described above. .
  • the PCC auxiliary patch information SEI message serves to provide auxiliary patch information metadata to the geometry image, texture image, etc. transmitted through the VCL NAL unit, and can be changed dynamically over time. The current SEI message contents are valid only until the next SEI message of the same type is interpreted, so that dynamic metadata can be applied.
  • Patch_count indicates the number of patches in geometry and texture videos.
  • patch_count can be greater than 0 (is the number of patches in the geometry and texture videos.It shall be larger than 0.)
  • Occupancy_precision is the horizontal and vertical resolution in pixels of the occupancy map preseason. This value corresponds to the sub-block size to which occuancy is signaled. This value can be set to size 1 to achieve lossless coding of ocupancy maps. (This corresponds to the sub-block size for which occupancy is. signaled.To achieve lossless coding of occupancy map this should be set to size 1.)
  • Max_candidate_count specifies the maximum number of candy dates in the patch candy date list (specifies the maximum number of candidates in the patch candidate list.)
  • Byte_count_u0 specifies the number of bytes for fix-length coding of patch_u0 (specifies the number of bytes for fixed-length coding of patch_u0.)
  • Byte_count_v0 specifies the number of bytes for fix-length coding of patch_v0 (specifies the number of bytes for fixed-length coding of patch_v0.)
  • Byte_count_u1 specifies the number of bytes for fix-length coding of patch_u1 (specifies the number of bytes for fixed-length coding of patch_u1.)
  • Byte_count_v1 specifies the number of bytes for fix-length coding of patch_v1 (specifies the number of bytes for fixed-length coding of patch_v1.)
  • Byte_count_d1 specifies the number of bytes for fix-length coding of patch_d1 (specifies the number of bytes for fixed-length coding of patch_d1.)
  • Byte_count_delta_size_u0 specifies the number of bytes for fix-length coding of delta_size_u0 (specifies the number of bytes for fixed-length coding of delta_size_u0.)
  • Byte_count_delta_size_v0 specifies the number of bytes for fix-length coding of delta_size_v0 (specifies the number of bytes for fixed-length coding of delta_size_v0.)
  • Patch_u0 represents the X-coordinate of the top-left corner subblock of size occupancy_resolution x occupancy_resolution of the patch bounding box.
  • the value of patch_u0 shall be in the range of 0 to frame_width / occupancy_resolution -1 (inclusive) (specifies the x-coordinate of the top-left corner subblock of size occupancy_resolution x occupancy_resolution of the patch bounding box. in the range of 0 to frame_width / occupancy_resolution 1, inclusive.)
  • Patch_v0 represents the Y-coordinate of the top-left corner subblock of size occupancy_resolution x occupancy_resolution of the patch bounding box.
  • the value of patch_v0 shall be in the range of 0 to frame_height / occupancy_resolution 1, inclusive.
  • Patch_u1 represents a minimal X-coordinate of a 3D bounding box of patch points.
  • the value of patch_u1 shall be in the range of 0 to to frame_width-1 (inclusive) (specifies the minimum x-coordinate of the 3D bounding box of patch points ..
  • the value of patch_u1 shall be in the range of 0 to frame_width 1 , inclusive.
  • Patch_v1 represents the maximum X-coordinate of the 3D bounding box of patch points.
  • the value of patch_v1 shall be in the range of 0 to frameHeight 1, (is the minimum y-coordinate of the 3D bounding box of patch points ,. inclusive.)
  • Patch_d1 specifies the minimum depth of the patches.
  • Delta_size_u0 is the difference of patch width between the current patch and the previous one.
  • Delta_size_v0 represents a difference in patch height between a current patch and a previous patch (is the difference of patch height between the current patch and the previous one.)
  • the normal_axis represents a planar projection box.
  • the value of normal_axis may be in the range of 0 to 2 (inclusive).
  • the values of normal_axis shall be in the range of 0 to 2, inclusive.normalAxis values of 0, 1, and 2 correspond to the X, Y, and Z projection axis, respectively.)
  • Candidate_index_flag specifies whether candidate_index exists or not (specifies whether candidate_index is present or not.)
  • Patch_index_flag specifies whether patch_index is present or not (specifies whether patch_index is present or not.)

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Computer Graphics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

실시예들에 따른 포인트 클라우드 데이터 송신 방법은 포인트 클라우드 데이터의 위치에 관련된 지오메트리 이미지를 생성하는 단계; 상기 포인트 클라우드의 속성에 관련된 텍스쳐 이미지를 생성하는 단계; 상기 포인트 클라우드의 패치에 관련된 어큐판시 맵을 생성하는 단계; 상기 포인트 클라우드의 패치에 관련된 어실러리 패치 정보를 생성하는 단계; 및/또는 상기 지오메트리 이미지, 상기 텍스쳐 이미지, 상기 어큐판시 맵 및 상기 어실러리 패치 정보를 멀티플렉싱하는 단계; 를 포함한다. 실시예들에 따른 포인트 클라우드 데이터 수신 방법은 포인트 클라우드 데이터의 위치에 관련된 지오메트리 이미지, 상기 포인트 클라우드의 속성에 관련된 텍스쳐 이미지, 상기 포인트 클라우드의 패치에 관련된 어큐판시 맵 및 상기 포인트 클라우드의 패치에 관련된 어실러리 패치 정보를 디멀티플렉싱하는 단계; 상기 지오메트리 이미지를 디컴프레션하는 단계; 상기 텍스쳐 이미지를 디컴프레션하는 단계; 상기 어큐판시 맵을 디컴프레션하는 단계; 및/또는 상기 어실러리 패치 정보를 디컴프레션하는 단계;를 포함한다.

Description

포인트 클라우드 데이터 전송 장치, 포인트 클라우드 데이터 전송 방법, 포인트 클라우드 데이터 수신 장치 및/또는 포인트 클라우드 데이터 수신 방법
실시예들은 사용자에게 VR (Virtual Reality, 가상현실), AR (Augmented Reality, 증강현실), MR (Mixed Reality, 혼합현실), 및 자율 주행 서비스 등의 다양한 서비스를 제공하기 위하여 Point Cloud 콘텐츠를 제공하는 방안을 제공한다.
포인트 클라우드는 3D공간 상의 포인트들의 집합이다. 3D공간 상의 포인트들의 개수가 많아서 포인트 클라우드 데이터를 생성하기 어려운 문제점이 있다.
포인트 클라우드의 데이터를 전송하고 수신하기 위해서 많은 처리량이 요구되는 문제점이 있다.
실시예들에 따른 기술적 과제는, 전술한 문제점 등을 헤결하기 위해서, 포인트 클라우드를 효율적으로 송수신하기 위한 포인트 클라우드 데이터 전송 장치, 전송 방법, 포인트 클라우드 데이터 수신 장치 및 수신 방법을 제공하는데 있다.
실시예들에 따른 기술적 과제는, 지연시간(latency) 및 인코딩/디코딩 복잡도를 해결하기 위한 포인트 클라우드 데이터 전송 장치, 전송 방법, 포인트 클라우드 데이터 수신 장치 및 수신 방법을 제공하는데 있다.
다만, 전술한 기술적 과제만으로 제한되는 것은 아니고, 본 문서 전체 내용에 기초하여 당업자가 유추할 수 있는 다른 기술적 과제로 실시예들의 권리범위가 확장될 수 있다.
상술한 목적 및 다른 이점을 달성하기 위해서 실시예들에 따른 포인트 클라우드 데이터 송신 방법은 포인트 클라우드 데이터의 위치에 관련된 지오메트리 이미지를 생성하는 단계; 상기 포인트 클라우드의 속성에 관련된 텍스쳐 이미지를 생성하는 단계; 상기 포인트 클라우드의 패치에 관련된 어큐판시 맵을 생성하는 단계; 상기 포인트 클라우드의 패치에 관련된 어실러리 패치 정보를 생성하는 단계; 및/또는 상기 지오메트리 이미지, 상기 텍스쳐 이미지, 상기 어큐판시 맵 및 상기 어실러리 패치 정보를 멀티플렉싱하는 단계; 를 포함한다.
실시예들에 따른 포인트 클라우드 데이터 수신 방법은 포인트 클라우드 데이터의 위치에 관련된 지오메트리 이미지, 상기 포인트 클라우드의 속성에 관련된 텍스쳐 이미지, 상기 포인트 클라우드의 패치에 관련된 어큐판시 맵 및 상기 포인트 클라우드의 패치에 관련된 어실러리 패치 정보를 디멀티플렉싱하는 단계; 상기 지오메트리 이미지를 디컴프레션하는 단계; 상기 텍스쳐 이미지를 디컴프레션하는 단계; 상기 어큐판시 맵을 디컴프레션하는 단계; 및/또는 상기 어실러리 패치 정보를 디컴프레션하는 단계;를 포함한다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법, 송신 장치, 포인트 클라우드 데이터 수신 방법, 수신 장치는 퀄리티 있는 포인트 클라우드 서비스를 제공할 수 있다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법, 송신 장치, 포인트 클라우드 데이터 수신 방법, 수신 장치는 다양한 비디오 코덱 방식을 달성할 수 있다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법, 송신 장치, 포인트 클라우드 데이터 수신 방법, 수신 장치는 자율주행 서비스 등 범용적인 포인트 클라우드 콘텐츠를 제공할 수 있다.
도면은 실시예들을 더욱 이해하기 위해서 포함되며, 도면은 실시예들에 관련된 설명과 함께 실시예들을 나타낸다.
도1 은 실시예들에 따른 360도 비디오 제공을 위한 전체 아키텍처를 도시한 도면이다.
도2 은 실시예들의 일 측면(aspect)에 따른 360도 비디오 전송 장치를 도시한 도면이다.
도3 은 실시예들의 다른 측면에 따른 360도 비디오 수신 장치를 도시한 도면이다.
도4 는 실시예들의 다른 실시예에 따른 360도 비디오 전송 장치/360도 비디오 수신 장치를 도시한 도면이다.
도5 는 실시예들의 3D 공간을 설명하기 위한 비행기 주축(Aircraft Principal Axes) 개념을 도시한 도면이다.
도6 는 실시예들의 일 실시예에 따른 프로젝션 스킴들을 도시한 도면이다.
도7 은 실시예들의 일 실시예에 따른 타일(Tile)을 도시한 도면이다.
도8 은 실시예들의 일 실시예에 따른 360도 비디오 관련 메타데이터를 도시한 도면이다.
도9는 3DoF+ VR 시스템에서 추가적으로 정의되는 위치(viewpoint)와 시점(viewing position)를 나타낸다.
도10은 3DoF+ 시스템에 기반한 360도 비디오 신호처리 및 관련 전송장치/수신장치 구현 방법에 대해서 도시한다.
도11은 3DoF+ end-to-end 시스템의 구조를 나타낸다.
도12는 FLUS (Framework for Live Uplink Streaming)의 구조를 나타낸다.
도13은 3DoF+ 송신단의 구성을 나타낸다.
도14는 3DoF+ 수신단의 구성을 나타낸다.
도15는 OMAF 구조를 나타낸다.
도16은 사용자의 이동에 따른 미디어의 종류를 나타낸다.
도17은 6DoF 비디오 제공을 위한 전체 아키텍처를 나타낸다.
도18은 6DoF 비디오 서비스 제공을 위한 전송 장치의 구성을 나타낸다.
도19는 6DoF 비디오 수신 장치의 구성을 나타낸다.
도20은 6 DoF 비디오 전송/수신 장치의 구성을 나타낸다.
도21은 6DoF 공간을 나타낸다.
도22는 실시예들에 따른 Point Cloud Compression 처리 일반을 나타낸다.
도23은 실시예들에 따른 Point Cloud 캡쳐 장비 배열 구성을 나타낸다.
도24는 실시예들에 따른 point cloud 및 geometry, texture image (non-padded)의 예시를 나타낸다.
도25는 실시예들에 따른 V-PCC 인코딩 프로세스를 나타낸다.
도26은 실시예들에 따른 서페이스(Surface)의 탄젠트 플레인(tangent plane) 및 노멀 벡터(normal vector)를 나타낸다.
도27은 실시예들에 따른 Point cloud의 bounding box를 나타낸다.
도28은 실시예들에 따른 Occupancy map에서의 개별 patch 위치 결정 방식을 나타낸다.
도29은 실시예들에 따른 normal, tangent, bitangent 축의 관계를 나타낸다.
도30는 실시예들에 따른 min mode에서의 d0, d1 구성 및 max mode에서의 d0, d1 구성을 나타낸다.
도31은 실시예들에 따른 EDD code의 예시를 나타낸다.
도32는 실시예들에 따른 인접점들의 color 값들을 이용한 recoloring을 나타낸다.
도33는 실시예들에 따른 block과 patch 맵핑을 위한 pseudo code 를 나타낸다.
도34는 실시예들에 따른 push-pull background filling을 나타낸다.
도35는 실시예들에 따른 4*4 크기의 block에 대해 가능한 traversal order의 예시를 나타낸다.
도36는 실시예들에 따른 best traversal order 선택의 예시를 나타낸다.
도37은 실시예들에 따른 2D video/image encoder 을 나타낸다.
도38은 실시예들에 따른 V-PCC decoding process 을 나타낸다.
도39는 실시예들에 따른 2D video/image decoder 을 나타낸다.
도40는 실시예들에 따른 송신단 동작 흐름도를 나타낸다.
도41는 실시예들에 따른 수신단 동작 흐름도를 나타낸다.
도42는 실시예들에 따른 V-PCC 기반 point cloud 데이터 저장 및 스트리밍을 위한 아키텍쳐를 나타낸다.
도43은 실시예들에 따른 point cloud 데이터 저장 및 전송 장치를 나타낸다.
도44는 실시예들에 따른 point cloud 데이터 수신 장치를 나타낸다.
도45는 실시예들에 따른 포인트 클라우드 데이터 전송 장치의 인코딩 과정을 나타낸다.
도46은 실시예들에 따른 디코딩 프로세스를 나타낸다.
도47은 실시예들에 따른 ISO BMFF 기반 Multiplexing/Demultiplexing을 나타낸다.
도48은 실시예들에 따른 runLength 및 best_traversal_order_index의 예시를 나타낸다.
도49는 실시예들에 따른 NALU stream 기반 Multiplexing/Demultiplexing을 나타낸다.
도50은 실시예들에 따른 PCC layer information을 나타낸다.
도51은 실시예들에 따른 PCC auxiliary patch information을 나타낸다.
도52는 실시예들에 따른 PCC occupancy map을 나타낸다.
도53은 실시예들에 따른 PCC group of frames header를 나타낸다.
도54는 실시예들에 따른 Geometry/Texture image packing을 나타낸다.
도55는 실시예들에 따른 geometry와 image component들 간의 배치 방법을 나타낸다.
도56은 실시예들에 따른 VPS extension을 나타낸다.
도57은 실시예들에 따른 pic_parameter_set을 나타낸다.
도58은 실시예들에 따른pps_pcc_auxiliary_patch_info_extension ()를 나타낸다.
도59는 실시예들에 따른pps_pcc_occupancy_map_extension()을 나타낸다.
도60은 실시예들에 따른 vps_pcc_gof_header_extension()을 나타낸다.
도61은 실시예들에 따른 pcc_nal_unit을 나타낸다.
도62는 실시예들에 따른 PCC 관련 구문의 예시를 나타낸다.
도63은 실시예들에 따른 PCC data interleaving 정보를 나타낸다.
도64는 실시예들에 따른 포인트 클라우드 데이터 전송 방법을 나타낸다.
도65는 실시예들에 따른 포인트 클라우드 데이터 수신 방법을 나타낸다.
실시예들의 바람직한 실시예에 대해 구체적으로 설명하며, 그 예는 첨부된 도면에 나타낸다. 첨부된 도면을 참조한 아래의 상세한 설명은 실시예들의 실시예에 따라 구현될 수 있는 실시예만을 나타내기보다는 실시예들의 바람직한 실시예를 설명하기 위한 것이다. 다음의 상세한 설명은 실시예들에 대한 철저한 이해를 제공하기 위해 세부 사항을 포함한다. 그러나 실시예들이 이러한 세부 사항 없이 실행될 수 있다는 것은 당업자에게 자명하다.
실시예들에서 사용되는 대부분의 용어는 해당 분야에서 널리 사용되는 일반적인 것들에서 선택되지만, 일부 용어는 출원인에 의해 임의로 선택되며 그 의미는 필요에 따라 다음 설명에서 자세히 서술한다. 따라서 실시예들은 용어의 단순한 명칭이나 의미가 아닌 용어의 의도된 의미에 근거하여 이해되어야 한다.
도 1 은 실시예들에 따른 360도 비디오 제공을 위한 전체 아키텍처를 도시한 도면이다.
실시예들은 사용자에게 VR (Virtual Reality, 가상현실)을 제공하기 위하여, 360도 컨텐츠를 제공하는 방안을 제안한다. VR 이란 실제 또는 가상의 환경을 복제(replicates) 하기 위한 기술 내지는 그 환경을 의미할 수 있다. VR 은 인공적으로 사용자에게 감각적 경험을 제공하며, 이를 통해 사용자는 전자적으로 프로젝션된 환경에 있는 것과 같은 경험을 할 수 있다.
360도 컨텐츠는 VR 을 구현, 제공하기 위한 컨텐츠 전반을 의미하며, 360도 비디오 및/또는 360도 오디오를 포함할 수 있다. 360도 비디오는 VR 을 제공하기 위해 필요한, 동시에 모든 방향(360도) 으로 캡쳐되거나 재생되는 비디오 내지 이미지 컨텐츠를 의미할 수 있다. 360도 비디오는 3D 모델에 따라 다양한 형태의 3D 공간 상에 나타내어지는 비디오 내지 이미지를 의미할 수 있으며, 예를 들어 360도 비디오는 구형(Spherical)면 상에 나타내어질 수 있다. 360도 오디오 역시 VR 을 제공하기 위한 오디오 컨텐츠로서, 음향 발생지가 3차원의 특정 공간상에 위치하는 것으로 인지될 수 있는, 공간적(Spatial) 오디오 컨텐츠를 의미할 수 있다. 360도 컨텐츠는 생성, 처리되어 사용자들로 전송될 수 있으며, 사용자들은 360도 컨텐츠를 이용하여 VR 경험을 소비할 수 있다. 이하, 360도 콘텐트/비디오/이미지/오디오 등은 단위(도, degree)가 생략된 360 콘텐트/비디오/이미지/오디오 등으로 사용될 수도 있고 VR 콘텐트/비디오/이미지/오디오 등으로 사용될 수도 있다.
실시예들은 특히 360 비디오를 효과적으로 제공하는 방안을 제안한다. 360 비디오를 제공하기 위하여, 먼저 하나 이상의 카메라를 통해 360 비디오가 캡쳐될 수 있다. 캡쳐된 360 비디오는 일련의 과정을 거쳐 전송되고, 수신측에서는 수신된 데이터를 다시 원래의 360 비디오로 가공하여 렌더링할 수 있다. 이를 통해 360 비디오가 사용자에게 제공될 수 있다.
구체적으로 360 비디오 제공을 위한 전체의 과정은 캡처 과정(process), 준비 과정, 전송 과정, 프로세싱 과정, 렌더링 과정 및/또는 피드백 과정을 포함할 수 있다.
캡처 과정은 하나 이상의 카메라를 통하여 복수개의 시점 각각에 대한 이미지 또는 비디오를 캡쳐하는 과정을 의미할 수 있다. 캡처 과정에 의해 도시된 (t1010) 과 같은 이미지/비디오 데이터가 생성될 수 있다. 도시된 (t1010) 의 각 평면은 각 시점에 대한 이미지/비디오를 의미할 수 있다. 이 캡쳐된 복수개의 이미지/비디오를 로(raw) 데이터라 할 수도 있다. 캡쳐 과정에서 캡쳐와 관련된 메타데이터가 생성될 수 있다.
이 캡처를 위하여 VR 을 위한 특수한 카메라가 사용될 수 있다. 실시예에 따라 컴퓨터로 생성된 가상의 공간에 대한 360 비디오를 제공하고자 하는 경우, 실제 카메라를 통한 캡처가 수행되지 않을 수 있다. 이 경우 단순히 관련 데이터가 생성되는 과정으로 해당 캡처 과정이 갈음될 수 있다.
준비 과정은 캡처된 이미지/비디오 및 캡쳐 과정에서 발생한 메타데이터를 처리하는 과정일 수 있다. 캡처된 이미지/비디오는 이 준비 과정에서, 스티칭 과정, 프로젝션 과정, 리전별 패킹 과정(Region-wise Packing) 및/또는 인코딩 과정 등을 거칠 수 있다.
먼저 각각의 이미지/비디오가 스티칭(Stitching) 과정을 거칠 수 있다. 스티칭 과정은 각각의 캡처된 이미지/비디오들을 연결하여 하나의 파노라마 이미지/비디오 또는 구형의 이미지/비디오를 만드는 과정일 수 있다.
이 후, 스티칭된 이미지/비디오는 프로젝션(Projection) 과정을 거칠 수 있다. 프로젝션 과정에서, 스트칭된 이미지/비디오는 2D 이미지 상에 프로젝션될 수 있다. 이 2D 이미지는 문맥에 따라 2D 이미지 프레임으로 불릴 수도 있다. 2D 이미지로 프로젝션하는 것을 2D 이미지로 매핑한다고 표현할 수도 있다. 프로젝션된 이미지/비디오 데이터는 도시된 (t1020) 과 같은 2D 이미지의 형태가 될 수 있다.
2D 이미지 상에 프로젝션된 비디오 데이터는 비디오 코딩 효율 등을 높이기 위하여 리전별 패킹 과정(Region-wise Packing)을 거칠 수 있다. 리전별 패킹이란, 2D 이미지 상에 프로젝션된 비디오 데이터를 리전(Region) 별로 나누어 처리를 가하는 과정을 의미할 수 있다. 여기서 리전(Region)이란, 360 비디오 데이터가 프로젝션된 2D 이미지가 나누어진 영역을 의미할 수 있다. 이 리전들은, 실시예에 따라, 2D 이미지를 균등하게 나누어 구분되거나, 임의로 나누어져 구분될 수 있다. 또한 실시예에 따라 리전들은, 프로젝션 스킴에 따라 구분되어질 수도 있다. 리전별 패킹 과정은 선택적(optional) 과정으로써, 준비 과정에서 생략될 수 있다.
실시예에 따라 이 처리 과정은, 비디오 코딩 효율을 높이기 위해, 각 리전을 회전한다거나 2D 이미지 상에서 재배열하는 과정을 포함할 수 있다. 예를 들어, 리전들을 회전하여 리전들의 특정 변들이 서로 근접하여 위치되도록 함으로써, 코딩 시의 효율이 높아지게 할 수 있다.
실시예에 따라 이 처리 과정은, 360 비디오상의 영역별로 레졸루션(resolution) 을 차등화하기 위하여, 특정 리전에 대한 레졸루션을 높인다거나, 낮추는 과정을 포함할 수 있다. 예를 들어, 360 비디오 상에서 상대적으로 더 중요한 영역에 해당하는 리전들은, 다른 리전들보다 레졸루션을 높게할 수 있다.2D 이미지 상에 프로젝션된 비디오 데이터 또는 리전별 패킹된 비디오 데이터는 비디오 코덱을 통한 인코딩 과정을 거칠 수 있다.
실시예에 따라 준비 과정은 부가적으로 에디팅(editing) 과정 등을 더 포함할 수 있다. 이 에디팅 과정에서 프로젝션 전후의 이미지/비디오 데이터들에 대한 편집 등이 더 수행될 수 있다. 준비 과정에서도 마찬가지로, 스티칭/프로젝션/인코딩/에디팅 등에 대한 메타데이터가 생성될 수 있다. 또한 2D 이미지 상에 프로젝션된 비디오 데이터들의 초기 시점, 혹은 ROI (Region of Interest) 등에 관한 메타데이터가 생성될 수 있다.
전송 과정은 준비 과정을 거친 이미지/비디오 데이터 및 메타데이터들을 처리하여 전송하는 과정일 수 있다. 전송을 위해 임의의 전송 프로토콜에 따른 처리가 수행될 수 있다. 전송을 위한 처리를 마친 데이터들은 방송망 및/또는 브로드밴드를 통해 전달될 수 있다. 이 데이터들은 온 디맨드(On Demand) 방식으로 수신측으로 전달될 수도 있다. 수신측에서는 다양한 경로를 통해 해당 데이터를 수신할 수 있다.
프로세싱 과정은 수신한 데이터를 디코딩하고, 프로젝션되어 있는 이미지/비디오 데이터를 3D 모델 상에 리-프로젝션(Re-projection) 하는 과정을 의미할 수 있다. 이 과정에서 2D 이미지들 상에 프로젝션되어 있는 이미지/비디오 데이터가 3D 공간 상으로 리-프로젝션될 수 있다. 이 과정을 문맥에 따라 매핑, 프로젝션이라고 부를 수도 있다. 이 때 매핑되는 3D 공간은 3D 모델에 따라 다른 형태를 가질 수 있다. 예를 들어 3D 모델에는 구형(Sphere), 큐브(Cube), 실린더(Cylinder) 또는 피라미드(Pyramid) 가 있을 수 있다.
실시예에 따라 프로세싱 과정은 부가적으로 에디팅(editing) 과정, 업 스케일링(up scaling) 과정 등을 더 포함할 수 있다. 이 에디팅 과정에서 리-프로젝션 전후의 이미지/비디오 데이터에 대한 편집 등이 더 수행될 수 있다. 이미지/비디오 데이터가 축소되어 있는 경우 업 스케일링 과정에서 샘플들의 업 스케일링을 통해 그 크기를 확대할 수 있다. 필요한 경우 다운 스케일링을 통해 사이즈를 축소하는 작업이 수행될 수도 있다.
렌더링 과정은 3D 공간상에 리-프로젝션된 이미지/비디오 데이터를 렌더링하고 디스플레이하는 과정을 의미할 수 있다. 표현에 따라 리-프로젝션과 렌더링을 합쳐 3D 모델 상에 렌더링한다 라고 표현할 수도 있다. 3D 모델 상에 리-프로젝션된 (또는 3D 모델 상으로 렌더링된) 이미지/비디오는 도시된 (t1030) 과 같은 형태를 가질 수 있다. 도시된 (t1030) 은 구형(Sphere) 의 3D 모델에 리-프로젝션된 경우이다. 사용자는 VR 디스플레이 등을 통하여 렌더링된 이미지/비디오의 일부 영역을 볼 수 있다. 이 때 사용자가 보게되는 영역은 도시된 (t1040) 과 같은 형태일 수 있다.
피드백 과정은 디스플레이 과정에서 획득될 수 있는 다양한 피드백 정보들을 송신측으로 전달하는 과정을 의미할 수 있다. 피드백 과정을 통해 360 비디오 소비에 있어 인터랙티비티(Interactivity) 가 제공될 수 있다. 실시예에 따라, 피드백 과정에서 헤드 오리엔테이션(Head Orientation) 정보, 사용자가 현재 보고 있는 영역을 나타내는 뷰포트(Viewport) 정보 등이 송신측으로 전달될 수 있다. 실시예에 따라, 사용자는 VR 환경 상에 구현된 것들과 상호작용할 수도 있는데, 이 경우 그 상호작용과 관련된 정보가 피드백 과정에서 송신측 내지 서비스 프로바이더 측으로 전달될 수도 있다. 실시예에 따라 피드백 과정은 수행되지 않을 수도 있다.
헤드 오리엔테이션 정보는 사용자의 머리 위치, 각도, 움직임 등에 대한 정보를 의미할 수 있다. 이 정보를 기반으로 사용자가 현재 360 비디오 내에서 보고 있는 영역에 대한 정보, 즉 뷰포트 정보가 계산될 수 있다.
뷰포트 정보는 현재 사용자가 360 비디오에서 보고 있는 영역에 대한 정보일 수 있다. 이를 통해 게이즈 분석(Gaze Analysis) 이 수행되어, 사용자가 어떠한 방식으로 360 비디오를 소비하는지, 360 비디오의 어느 영역을 얼마나 응시하는지 등을 확인할 수도 있다. 게이즈 분석은 수신측에서 수행되어 송신측으로 피드백 채널을 통해 전달될 수도 있다. VR 디스플레이 등의 장치는 사용자의 머리 위치/방향, 장치가 지원하는 수직(vertical) 혹은 수평(horizontal) FOV 등에 근거하여 뷰포트 영역을 추출할 수 있다.
실시예에 따라, 전술한 피드백 정보는 송신측으로 전달되는 것 뿐아니라, 수신측에서 소비될 수도 있다. 즉, 전술한 피드백 정보를 이용하여 수신측의 디코딩, 리-프로젝션, 렌더링 과정 등이 수행될 수 있다. 예를 들어, 헤드 오리엔테이션 정보 및/또는 뷰포트 정보를 이용하여 현재 사용자가 보고 있는 영역에 대한 360 비디오만 우선적으로 디코딩 및 렌더링될 수도 있다.
여기서 뷰포트(viewport) 내지 뷰포트 영역이란, 사용자가 360 비디오에서 보고 있는 영역을 의미할 수 있다. 시점(viewpoint) 는 사용자가 360 비디오에서 보고 있는 지점으로서, 뷰포트 영역의 정중앙 지점을 의미할 수 있다. 즉, 뷰포트는 시점을 중심으로 한 영역인데, 그 영역이 차지하는 크기 형태 등은 후술할 FOV(Field Of View) 에 의해 결정될 수 있다.
전술한 360 비디오 제공을 위한 전체 아키텍처 내에서, 캡쳐/프로젝션/인코딩/전송/디코딩/리-프로젝션/렌더링의 일련의 과정을 거치게 되는 이미지/비디오 데이터들을 360 비디오 데이터라 부를 수 있다. 360 비디오 데이터라는 용어는 또한 이러한 이미지/비디오 데이터들과 관련되는 메타데이터 내지 시그널링 정보를 포함하는 개념으로 쓰일 수도 있다.
도 2 은 실시예들의 일 측면(aspect)에 따른 360도 비디오 전송 장치를 도시한 도면이다.
일 측면에 따르면 실시예들은 360 비디오 전송 장치와 관련될 수 있다. 실시예들에 따른 360 비디오 전송 장치는 전술한 준비 과정 내지 전송 과정에 관련된 동작들을 수행할 수 있다. 실시예들에 따른 360 비디오 전송 장치는 데이터 입력부, 스티처(Stitcher), 프로젝션 처리부, 리전별 패킹 처리부(도시되지 않음), 메타데이터 처리부, (송신측) 피드백 처리부, 데이터 인코더, 인캡슐레이션 처리부, 전송 처리부 및/또는 전송부를 내/외부 엘레멘트로서 포함할 수 있다.
데이터 입력부는 캡쳐된 각 시점별 이미지/비디오 들을 입력받을 수 있다. 이 시점별 이미지/비디오 들은 하나 이상의 카메라들에 의해 캡쳐된 이미지/비디오들일 수 있다. 또한 데이터 입력부는 캡쳐 과정에서 발생된 메타데이터를 입력받을 수 있다. 데이터 입력부는 입력된 시점별 이미지/비디오들을 스티처로 전달하고, 캡쳐 과정의 메타데이터를 시그널링 처리부로 전달할 수 있다.
스티처는 캡쳐된 시점별 이미지/비디오들에 대한 스티칭 작업을 수행할 수 있다. 스티처는 스티칭된 360 비디오 데이터를 프로젝션 처리부로 전달할 수 있다. 스티처는 필요한 경우 메타데이터 처리부로부터 필요한 메타데이터를 전달받아 스티칭 작업에 이용할 수 있다. 스티처는 스티칭 과정에서 발생된 메타데이터를 메타데이터 처리부로 전달할 수 있다. 스티칭 과정의 메타데이터에는 스티칭이 수행되었는지 여부, 스티칭 타입 등의 정보들이 있을 수 있다.
프로젝션 처리부는 스티칭된 360 비디오 데이터를 2D 이미지 상에 프로젝션할 수 있다. 프로젝션 처리부는 다양한 스킴(scheme)에 따라 프로젝션을 수행할 수 있는데, 이에 대해서는 후술한다. 프로젝션 처리부는 각 시점별 360 비디오 데이터의 해당 뎁스(depth)를 고려하여 매핑을 수행할 수 있다. 프로젝션 처리부는 필요한 경우 메타데이터 처리부로부터 프로젝션에 필요한 메타데이터를 전달받아 프로젝션 작업에 이용할 수 있다. 프로젝션 처리부는 프로젝션 과정에서 발생된 메타데이터를 메타데이터 처리부로 전달할 수 있다. 프로젝션 처리부의 메타데이터에는 프로젝션 스킴의 종류 등이 있을 수 있다.
리전별 패킹 처리부(도시되지 않음)는 전술한 리전별 패킹 과정을 수행할 수 있다. 즉, 리전별 패킹 처리부는 프로젝션된 360 비디오 데이터를 리전별로 나누고, 각 리전들을 회전, 재배열하거나, 각 리전의 레졸루션을 변경하는 등의 처리를 수행할 수 있다. 전술한 바와 같이 리전별 패킹 과정은 선택적(optional) 과정이며, 리전별 패킹이 수행되지 않는 경우, 리전별 패킹 처리부는 생략될 수 있다. 리전별 패킹 처리부는 필요한 경우 메타데이터 처리부로부터 리전별 패킹에 필요한 메타데이터를 전달받아 리전별 패킹 작업에 이용할 수 있다. 리전별 패킹 처리부는 리전별 패킹 과정에서 발생된 메타데이터를 메타데이터 처리부로 전달할 수 있다. 리전별 패킹 처리부의 메타데이터에는 각 리전의 회전 정도, 사이즈 등이 있을 수 있다.
전술한 스티처, 프로젝션 처리부 및/또는 리전별 패킹 처리부는 실시예에 따라 하나의 하드웨어 컴포넌트에서 수행될 수도 있다.
메타데이터 처리부는 캡처 과정, 스티칭 과정, 프로젝션 과정, 리전별 패킹 과정, 인코딩 과정, 인캡슐레이션 과정 및/또는 전송을 위한 처리 과정에서 발생할 수 있는 메타데이터들을 처리할 수 있다. 메타데이터 처리부는 이러한 메타데이터들을 이용하여 360 비디오 관련 메타데이터를 생성할 수 있다. 실시예에 따라 메타데이터 처리부는 360 비디오 관련 메타데이터를 시그널링 테이블의 형태로 생성할 수도 있다. 문맥에 따라 360 비디오 관련 메타데이터는 메타데이터 또는 360 비디오 관련 시그널링 정보라 불릴 수도 있다. 또한 메타데이터 처리부는 획득하거나 생성한 메타데이터들을 필요에 따라 360 비디오 전송 장치의 내부 엘레멘트들에 전달할 수 있다. 메타데이터 처리부는 360 비디오 관련 메타데이터가 수신측으로 전송될 수 있도록 데이터 인코더, 인캡슐레이션 처리부 및/또는 전송 처리부에 전달할 수 있다.
데이터 인코더는 2D 이미지 상에 프로젝션된 360 비디오 데이터 및/또는 리전별 패킹된 360 비디오 데이터를 인코딩할 수 있다. 360 비디오 데이터는 다양한 포맷으로 인코딩될 수 있다.
인캡슐레이션 처리부는 인코딩된 360 비디오 데이터 및/또는 360 비디오 관련 메타데이터를 파일 등의 형태로 인캡슐레이션할 수 있다. 여기서 360 비디오 관련 메타데이터는 전술한 메타데이터 처리부로부터 전달받은 것일 수 있다. 인캡슐레이션 처리부는 해당 데이터들을 ISOBMFF, CFF 등의 파일 포맷으로 인캡슐레이션하거나, 기타 DASH 세그먼트 등의 형태로 처리할 수 있다. 인캡슐레이션 처리부는 실시예에 따라 360 비디오 관련 메타데이터를 파일 포맷 상에 포함시킬 수 있다. 360 관련 메타데이터는 예를 들어 ISOBMFF 파일 포맷 상의 다양한 레벨의 박스(box)에 포함되거나 파일 내에서 별도의 트랙내의 데이터로 포함될 수 있다. 실시예에 따라, 인캡슐레이션 처리부는 360 비디오 관련 메타데이터 자체를 파일로 인캡슐레이션할 수 있다.전송 처리부는 파일 포맷에 따라 인캡슐레이션된 360 비디오 데이터에 전송을 위한 처리를 가할 수 있다. 전송 처리부는 임의의 전송 프로토콜에 따라 360 비디오 데이터를 처리할 수 있다. 전송을 위한 처리에는 방송망을 통한 전달을 위한 처리, 브로드밴드를 통한 전달을 위한 처리를 포함할 수 있다. 실시예에 따라 전송 처리부는 360 비디오 데이터 뿐 아니라, 메타데이터 처리부로부터 360 비디오 관련 메타데이터를 전달받아, 이 것에 전송을 위한 처리를 가할 수도 있다.
전송부는 전송 처리된 360 비디오 데이터 및/또는 360 비디오 관련 메타데이터를 방송망 및/또는 브로드밴드를 통해 전송할 수 있다. 전송부는 방송망을 통한 전송을 위한 엘레멘트 및/또는 브로드밴드를 통한 전송을 위한 엘레멘트를 포함할 수 있다.
실시예들에 따른 360 비디오 전송 장치의 일 실시예에 의하면, 360 비디오 전송 장치는 데이터 저장부(도시되지 않음)를 내/외부 엘레멘트로서 더 포함할 수 있다. 데이터 저장부는 인코딩된 360 비디오 데이터 및/또는 360 비디오 관련 메타데이터를 전송 처리부로 전달하기 전에 저장하고 있을 수 있다. 이 데이터들이 저장되는 형태는 ISOBMFF 등의 파일 형태일 수 있다. 실시간으로 360 비디오를 전송하는 경우에는 데이터 저장부가 필요하지 않을 수 있으나, 온 디맨드, NRT (Non Real Time), 브로드밴드 등을 통해 전달하는 경우에는 인캡슐레이션된 360 데이터가 데이터 저장부에 일정 기간 저장되었다가 전송될 수도 있다.
실시예들에 따른 360 비디오 전송 장치의 다른 실시예에 의하면, 360 비디오 전송 장치는 (송신측) 피드백 처리부 및/또는 네트워크 인터페이스(도시되지 않음)를 내/외부 엘레멘트로서 더 포함할 수 있다. 네트워크 인터페이스는 실시예들에 따른 360 비디오 수신 장치로부터 피드백 정보를 전달받고, 이를 송신측 피드백 처리부로 전달할 수 있다. 송신측 피드백 처리부는 피드백 정보를 스티처, 프로젝션 처리부, 리전별 패킹 처리부, 데이터 인코더, 인캡슐레이션 처리부, 메타데이터 처리부 및/또는 전송 처리부로 전달할 수 있다. 실시예에 따라 피드백 정보는 메타데이터 처리부에 일단 전달된 후, 다시 각 내부 엘레멘트들로 전달될 수 있다. 피드백 정보를 전달받은 내부 엘레먼트들은 이 후의 360 비디오 데이터의 처리에 피드백 정보를 반영할 수 있다.
실시예들에 따른 360 비디오 전송 장치의 또 다른 실시예에 의하면, 리전별 패킹 처리부는 각 리전을 회전하여 2D 이미지 상에 매핑할 수 있다. 이 때 각 리전들은 서로 다른 방향, 서로 다른 각도로 회전되어 2D 이미지 상에 매핑될 수 있다. 리전의 회전은 360 비디오 데이터가 구형의 면 상에서 프로젝션 전에 인접했던 부분, 스티칭된 부분 등을 고려하여 수행될 수 있다. 리전의 회전에 관한 정보들, 즉 회전 방향, 각도 등은 360 비디오 관련 메타데이터에 의해 시그널링될 수 있다. 실시예들에 따른 360 비디오 전송 장치의 또 다른 실시예에 의하면, 데이터 인코더는 각 리전 별로 다르게 인코딩을 수행할 수 있다. 데이터 인코더는 특정 리전은 높은 퀄리티로, 다른 리전은 낮은 퀄리티로 인코딩을 수행할 수 있다. 송신측 피드백 처리부는 360 비디오 수신 장치로부터 전달받은 피드백 정보를 데이터 인코더로 전달하여, 데이터 인코더가 리전별 차등화된 인코딩 방법을 사용하도록 할 수 있다. 예를 들어 송신측 피드백 처리부는 수신측으로부터 전달받은 뷰포트 정보를 데이터 인코더로 전달할 수 있다. 데이터 인코더는 뷰포트 정보가 지시하는 영역을 포함하는 리전들에 대해 다른 리전들보다 더 높은 퀄리티(UHD 등) 로 인코딩을 수행할 수 있다.
실시예들에 따른 360 비디오 전송 장치의 또 다른 실시예에 의하면, 전송 처리부는 각 리전 별로 다르게 전송을 위한 처리를 수행할 수 있다. 전송 처리부는 리전 별로 다른 전송 파라미터(모듈레이션 오더, 코드 레이트 등)를 적용하여, 각 리전 별로 전달되는 데이터의 강건성(robustenss) 을 다르게 할 수 있다.
이 때, 송신측 피드백 처리부는 360 비디오 수신 장치로부터 전달받은 피드백 정보를 전송 처리부로 전달하여, 전송 처리부가 리전별 차등화된 전송 처리를 수행하도록 할 수 있다. 예를 들어 송신측 피드백 처리부는 수신측으로부터 전달받은 뷰포트 정보를 전송 처리부로 전달할 수 있다. 전송 처리부는 해당 뷰포트 정보가 지시하는 영역을 포함하는 리전들에 대해 다른 리전들보다 더 높은 강건성을 가지도록 전송 처리를 수행할 수 있다.
전술한 실시예들에 따른 360 비디오 전송 장치의 내/외부 엘레멘트들은 하드웨어로 구현되는 하드웨어 엘레멘트들일 수 있다. 실시예에 따라 내/외부 엘레멘트들은 변경, 생략되거나 다른 엘레멘트로 대체, 통합될 수 있다. 실시예에 따라 부가 엘레멘트들이 360 비디오 전송 장치에 추가될 수도 있다.
도 3 은 실시예들의 다른 측면에 따른 360도 비디오 수신 장치를 도시한 도면이다.
다른 측면에 따르면 실시예들은 360 비디오 수신 장치와 관련될 수 있다. 실시예들에 따른 360 비디오 수신 장치는 전술한 프로세싱 과정 및/또는 렌더링 과정에 관련된 동작들을 수행할 수 있다. 실시예들에 따른 360 비디오 수신 장치는 수신부, 수신 처리부, 디캡슐레이션 처리부, 데이터 디코더, 메타데이터 파서, (수신측) 피드백 처리부, 리-프로젝션 처리부 및/또는 렌더러를 내/외부 엘레멘트로서 포함할 수 있다.
수신부는 실시예들에 따른 360 비디오 전송 장치가 전송한 360 비디오 데이터를 수신할 수 있다. 전송되는 채널에 따라 수신부는 방송망을 통하여 360 비디오 데이터를 수신할 수도 있고, 브로드밴드를 통하여 360 비디오 데이터를 수신할 수도 있다.
수신 처리부는 수신된 360 비디오 데이터에 대해 전송 프로토콜에 따른 처리를 수행할 수 있다. 전송측에서 전송을 위한 처리가 수행된 것에 대응되도록, 수신 처리부는 전술한 전송 처리부의 역과정을 수행할 수 있다. 수신 처리부는 획득한 360 비디오 데이터는 디캡슐레이션 처리부로 전달하고, 획득한 360 비디오 관련 메타데이터는 메타데이터 파서로 전달할 수 있다. 수신 처리부가 획득하는 360 비디오 관련 메타데이터는 시그널링 테이블의 형태일 수 있다.
디캡슐레이션 처리부는 수신 처리부로부터 전달받은 파일 형태의 360 비디오 데이터를 디캡슐레이션할 수 있다. 디캡슐레이션 처리부는 ISOBMFF 등에 따른 파일들을 디캡슐레이션하여, 360 비디오 데이터 내지 360 비디오 관련 메타데이터를 획득할 수 있다. 획득된 360 비디오 데이터는 데이터 디코더로, 획득된 360 비디오 관련 메타데이터는 메타데이터 파서로 전달할 수 있다. 디캡슐레이션 처리부가 획득하는 360 비디오 관련 메타데이터는 파일 포맷 내의 박스 혹은 트랙 형태일 수 있다. 디캡슐레이션 처리부는 필요한 경우 메타데이터 파서로부터 디캡슐레이션에 필요한 메타데이터를 전달받을 수도 있다.
데이터 디코더는 360 비디오 데이터에 대한 디코딩을 수행할 수 있다. 데이터 디코더는 메타데이터 파서로부터 디코딩에 필요한 메타데이터를 전달받을 수도 있다. 데이터 디코딩 과정에서 획득된 360 비디오 관련 메타데이터는 메타데이터 파서로 전달될 수도 있다.
메타데이터 파서는 360 비디오 관련 메타데이터에 대한 파싱/디코딩을 수행할 수 있다. 메타데이터 파서는 획득한 메타데이터를 데이터 디캡슐레이션 처리부, 데이터 디코더, 리-프로젝션 처리부 및/또는 렌더러로 전달할 수 있다.
리-프로젝션 처리부는 디코딩된 360 비디오 데이터에 대하여 리-프로젝션을 수행할 수 있다. 리-프로젝션 처리부는 360 비디오 데이터를 3D 공간으로 리-프로젝션할 수 있다. 3D 공간은 사용되는 3D 모델에 따라 다른 형태를 가질 수 있다. 리-프로젝션 처리부는 메타데이터 파서로부터 리-프로젝션에 필요한 메타데이터를 전달받을 수도 있다. 예를 들어 리-프로젝션 처리부는 사용되는 3D 모델의 타입 및 그 세부 정보에 대한 정보를 메타데이터 파서로부터 전달받을 수 있다. 실시예에 따라 리-프로젝션 처리부는 리-프로젝션에 필요한 메타데이터를 이용하여, 3D 공간 상의 특정 영역에 해당하는 360 비디오 데이터만을 3D 공간으로 리-프로젝션할 수도 있다.
렌더러는 리-프로젝션된 360 비디오 데이터를 렌더링할 수 있다. 전술한 바와 같이 360 비디오 데이터가 3D 공간상에 렌더링된다고 표현할 수도 있는데, 이처럼 두 과정이 한번에 일어나는 경우 리-프로젝션 처리부와 렌더러는 통합되어, 렌더러에서 이 과정들이 모두 진행될 수 있다. 실시예에 따라 렌더러는 사용자의 시점 정보에 따라 사용자가 보고 있는 부분만을 렌더링할 수도 있다.
사용자는 VR 디스플레이 등을 통하여 렌더링된 360 비디오의 일부 영역을 볼 수 있다. VR 디스플레이는 360 비디오를 재생하는 장치로서, 360 비디오 수신 장치에 포함될 수도 있고(tethered), 별도의 장치로서 360 비디오 수신 장치에 연결될 수도 있다(un-tethered).
실시예들에 따른 360 비디오 수신 장치의 일 실시예에 의하면, 360 비디오 수신 장치는 (수신측) 피드백 처리부 및/또는 네트워크 인터페이스(도시되지 않음)를 내/외부 엘레멘트로서 더 포함할 수 있다. 수신측 피드백 처리부는 렌더러, 리-프로젝션 처리부, 데이터 디코더, 디캡슐레이션 처리부 및/또는 VR 디스플레이로부터 피드백 정보를 획득하여 처리할 수 있다. 피드백 정보는 뷰포트 정보, 헤드 오리엔테이션 정보, 게이즈(Gaze) 정보 등을 포함할 수 있다. 네트워크 인터페이스는 피드백 정보를 수신측 피드백 처리부로부터 전달받고, 이를 360 비디오 전송 장치로 전송할 수 있다.
전술한 바와 같이, 피드백 정보는 송신측으로 전달되는 것 뿐아니라, 수신측에서 소비될 수도 있다. 수신측 피드백 처리부는 획득한 피드백 정보를 360 비디오 수신 장치의 내부 엘레멘트들로 전달하여, 렌더링 등의 과정에 반영되게 할 수 있다. 수신측 피드백 처리부는 피드백 정보를 렌더러, 리-프로젝션 처리부, 데이터 디코더 및/또는 디캡슐레이션 처리부로 전달할 수 있다. 예를 들어, 렌더러는 피드백 정보를 활용하여 사용자가 보고 있는 영역을 우선적으로 렌더링할 수 있다. 또한 디캡슐레이션 처리부, 데이터 디코더 등은 사용자가 보고 있는 영역 내지 보게될 영역을 우선적으로 디캡슐레이션, 디코딩할 수 있다.
전술한 실시예들에 따른 360 비디오 수신 장치의 내/외부 엘레멘트들은 하드웨어로 구현되는 하드웨어 엘레멘트들일 수 있다. 실시예에 따라 내/외부 엘레멘트들은 변경, 생략되거나 다른 엘레멘트로 대체, 통합될 수 있다. 실시예에 따라 부가 엘레멘트들이 360 비디오 수신 장치에 추가될 수도 있다.
실시예들의 또 다른 측면은 360 비디오를 전송하는 방법 및 360 비디오를 수신하는 방법과 관련될 수 있다. 실시예들에 따른 360 비디오를 전송/수신하는 방법은, 각각 전술한 실시예들에 따른 360 비디오 전송/수신 장치 또는 그 장치의 실시예들에 의해 수행될 수 있다.
전술한 실시예들에 따른 360 비디오 전송/수신 장치, 전송/수신 방법의 각각의 실시예 및 그 내/외부 엘리멘트 각각의 실시예들을 서로 조합될 수 있다. 예를 들어 프로젝션 처리부의 실시예들과, 데이터 인코더의 실시예들은 서로 조합되어, 그 경우의 수만큼의 360 비디오 전송 장치의 실시예들을 만들어 낼 수 있다. 이렇게 조합된 실시예들 역시 실시예들의 범위에 포함된다.
도 4 는 실시예들의 다른 실시예에 따른 360도 비디오 전송 장치/360도 비디오 수신 장치를 도시한 도면이다.
전술한 바와 같이, 도시된 (a) 와 같은 아키텍처에 의하여 360 컨텐츠가 제공될 수 있다. 360 컨텐츠는 파일 형태로 제공되거나, DASH 등과 같이 세그먼트(segment) 기반 다운로드 또는 스트리밍 서비스의 형태로 제공될 수 있다. 여기서 360 컨텐츠는 VR 컨텐츠로 불릴 수 있다.
전술한 바와 같이 360 비디오 데이터 및/또는 360 오디오 데이터가 획득될 수 있다(Acquisition).
360 오디오 데이터는 오디오 프리-프로세싱 과정(Audio Preprocessing), 오디오 인코딩 과정(Audio encoding)을 거칠 수 있다. 이 과정에서 오디오 관련 메타데이터가 생성될 수 있으며, 인코딩된 오디오와 오디오 관련 메타데이터는 전송을 위한 처리(file/segment encapsulation)를 거칠 수 있다.
360 비디오 데이터는 전술한 것과 같은 과정을 거칠 수 있다. 360 비디오 전송 장치의 스티처는 360 비디오 데이터에 스티칭을 수행할 수 있다(Visual stitching). 이 과정은 실시예에 따라 생략되고 수신측에서 수행될 수도 있다. 360 비디오 전송 장치의 프로젝션 처리부는 360 비디오 데이터를 2D 이미지 상에 프로젝션할 수 있다(Projection and mapping(packing)).
이 스티칭 및 프로젝션 과정은 (b) 에 구체적으로 도시되었다. 도시된 (b) 에서, 360 비디오 데이터(Input Images) 를 전달받으면, 이에 스티칭 및 프로젝션이 수행될 수 있다. 프로젝션 과정은 구체적으로 스티칭된 360 비디오 데이터를 3D 공간 상으로 프로젝션하고, 프로젝션된 360 비디오 데이터가 2D 이미지 상으로 배열되는 것으로 볼 수 있다. 본 명세서에서 이 과정을 360 비디오 데이터를 2D 이미지 상으로 프로젝션한다고 표현할 수도 있다. 여기서 3D 공간은 구(sphere) 또는 큐브(cube) 등일 수 있다. 이 3D 공간은 수신측에서 리-프로젝션에 사용되는 3D 공간과 같을 수도 있다.
2D 이미지는 프로젝티드 프레임(C, Projected frame) 이라 불릴 수도 있다. 이 2D 이미지에 리전별 패킹(Region-wise packing) 이 선택적으로 더 수행될 수도 있다. 리전별 패킹이 수행되는 경우, 각 리전(Region)의 위치, 형태, 크기를 지시함으로써, 2D 이미지 상의 리전들이 팩드 프레임(D, packed frame) 상으로 매핑될 수 있다. 리전별 패킹이 수행되지 않는 경우, 프로젝티드 프레임은 팩드 프레임과 같을 수 있다. 리전에 대해서는 후술한다. 프로젝션 과정 및 리전별 패킹 과정을, 360 비디오 데이터의 각 리전들이 2D 이미지 상에 프로젝션된다고 표현할 수도 있다. 설계에 따라, 360 비디오 데이터는 중간 과정 없이 팩드 프레임으로 바로 변환될 수도 있다.
도시된 (a) 에서, 프로젝션된 360 비디오 데이터는 이미지 인코딩 내지 비디오 인코딩될 수 있다. 같은 컨텐트라도 다른 시점(viewpoints)별로 존재할 수 있으므로, 같은 컨텐트가 서로 다른 비트 스트림으로 인코딩될 수도 있다. 인코딩된 360 비디오 데이터는 전술한 인캡슐레이션 처리부에 의해 ISOBMFF 등의 파일 포맷으로 처리될 수 있다. 또는 인캡슐레이션 처리부는 인코딩된 360 비디오 데이터를 세그먼트들로 처리할 수 있다. 세그먼트들은 DASH 에 기반한 전송을 위한 개별 트랙에 포함될 수 있다.
360 비디오 데이터의 처리와 함께, 전술한 것과 같이 360 비디오 관련 메타데이터가 생성될 수 있다. 이 메타데이터는 비디오 스트림 혹은 파일 포맷에 포함되어 전달될 수 있다. 이 메타데이터는 인코딩 과정이나 파일 포맷 인캡슐레이션, 전송을 위한 처리 등과 같은 과정에도 쓰일 수 있다.
360 오디오/비디오 데이터는 전송 프로토콜에 따라 전송을 위한 처리를 거치고, 이후 전송될 수 있다. 전술한 360 비디오 수신 장치는 이를 방송망 또는 브로드밴드를 통해 수신할 수 있다.
도시된 (a) 에서 VR 서비스 플랫폼(VR service platform) 은 전술한 360 비디오 수신 장치의 일 실시예에 해당할 수 있다. 도시된 (a) 에서 스피커/헤드폰(Loudspeakers/headphones), 디스플레이(Display), 헤드/아이 트랙킹 컴포넌트(Head/eye tracking) 는 360 비디오 수신 장치의 외부 장치 내지 VR 어플리케이션에 의해 수행되는 것으로 도시되었는데, 실시예에 따라 360 비디오 수신 장치는 이 들을 모두 포함할 수도 있다. 실시예에 따라 헤드/아이 트랙킹 컴포넌트는 전술한 수신측 피드백 처리부에 해당할 수 있다.
360 비디오 수신 장치는 360 오디오/비디오 데이터에 수신을 위한 처리(File/segment decapsulation)를 수행할 수 있다. 360 오디오 데이터는 오디오 디코딩(Audio decoding), 오디오 렌더링(Audio rendering) 과정을 거쳐 스피커/헤드폰을 통해 사용자에게 제공될 수 있다.
360 비디오 데이터는 이미지 디코딩 내지 비디오 디코딩, 렌더링(Visual rendering) 과정을 거쳐 디스플레이를 통해 사용자에게 제공될 수 있다. 여기서 디스플레이는 VR 을 지원하는 디스플레이거나 일반 디스플레이일 수 있다.
전술한 바와 같이 렌더링 과정은 구체적으로, 360 비디오 데이터가 3D 공간 상에 리-프로젝션되고, 리-프로젝션된 360 비디오 데이터가 렌더링되는 것으로 볼 수 있다. 이를 360 비디오 데이터가 3D 공간 상에 렌더링된다고 표현할 수도 있다.
헤드/아이 트랙킹 컴포넌트는 사용자의 헤드 오리엔테이션 정보, 게이즈 정보, 뷰포트(Viewport) 정보 등을 획득, 처리할 수 있다. 이에 대해서는 전술하였다.
수신측에서는 전술한 수신측 과정들과 통신하는 VR 어플리케이션이 존재할 수 있다.
도 5 는 실시예들의 3D 공간을 설명하기 위한 비행기 주축(Aircraft Principal Axes) 개념을 도시한 도면이다.
실시예들에서, 3D 공간에서의 특정 지점, 위치, 방향, 간격, 영역 등을 표현하기 위하여 비행기 주축 개념이 사용될 수 있다.
즉, 실시예들에서 프로젝션 전 또는 리-프로젝션 후의 3D 공간에 대해 기술하고, 그에 대한 시그널링을 수행하기 위하여 비행기 주축 개념이 사용될 수 있다. 실시예에 따라 X, Y, Z 축 개념 또는 구 좌표계를 이용한 방법이 사용될 수도 있다.
비행기는 3 차원으로 자유롭게 회전할 수 있다. 3차원을 이루는 축을 각각 피치(pitch) 축, 야(yaw) 축 및 롤(roll) 축이라고 한다. 본 명세서에서 이 들을 줄여서 pitch, yaw, roll 내지 pitch 방향, yaw 방향, roll 방향이라고 표현할 수도 있다.
Pitch 축은 비행기의 앞코가 위/아래로 회전하는 방향의 기준이 되는 축을 의미할 수 있다. 도시된 비행기 주축 개념에서 pitch 축은 비행기의 날개에서 날개로 이어지는 축을 의미할 수 있다.
Yaw 축은 비행기의 앞코가 좌/우로 회전하는 방향의 기준이 되는 축을 의미할 수 있다. 도시된 비행기 주축 개념에서 yaw 축은 비행기의 위에서 아래로 이어지는 축을 의미할 수 있다.
Roll 축은 도시된 비행기 주축 개념에서 비행기의 앞코에서 꼬리로 이어지는 축으로서, roll 방향의 회전이란 roll 축을 기준으로 한 회전을 의미할 수 있다.
전술한 바와 같이, pitch, yaw, roll 개념을 통해 실시예들에서의 3D 공간이 기술될 수 있다.
도 6 는 실시예들의 일 실시예에 따른 프로젝션 스킴들을 도시한 도면이다.
전술한 바와 같이 실시예들에 따른 360 비디오 전송 장치의 프로젝션 처리부는 스티칭된 360 비디오 데이터를 2D 이미지 상에 프로젝션할 수 있다. 이 과정에서 다양한 프로젝션 스킴들이 활용될 수 있다.
실시예들에 따른 360 비디오 전송 장치의 또 다른 실시예에 의하면, 프로젝션 처리부는 큐빅 프로젝션(Cubic Projection) 스킴을 이용하여 프로젝션을 수행할 수 있다. 예를 들어 스티칭된 360 비디오 데이터는 구형의 면 상에 나타내어질 수 있다. 프로젝션 처리부는 이러한 360 비디오 데이터를 큐브(Cube, 정육면체) 형태로 나누어 2D 이미지 상에 프로젝션할 수 있다. 구형의 면 상의 360 비디오 데이터는 큐브의 각 면에 대응되어, 2D 이미지 상에 (a) 좌측 또는 (a) 우측과 같이 프로젝션될 수 있다.
실시예들에 따른 360 비디오 전송 장치의 또 다른 실시예에 의하면, 프로젝션 처리부는 실린더형 프로젝션(Cylindrical Projection) 스킴을 이용하여 프로젝션을 수행할 수 있다. 마찬가지로 스티칭된 360 비디오 데이터가 구형의 면 상에 나타내어질 수 있다고 가정할 때, 프로젝션 처리부는 이러한 360 비디오 데이터를 실린더(Cylinder) 형태로 나누어 2D 이미지 상에 프로젝션할 수 있다. 구형의 면 상의 360 비디오 데이터는 실린더의 옆면(side)과 윗면(top), 바닥면(bottom) 에 각각 대응되어, 2D 이미지 상에 (b) 좌측 또는 (b) 우측과 같이 프로젝션될 수 있다.
실시예들에 따른 360 비디오 전송 장치의 또 다른 실시예에 의하면, 프로젝션 처리부는 피라미드 프로젝션(Pyramid Projection) 스킴을 이용하여 프로젝션을 수행할 수 있다. 마찬가지로 스티칭된 360 비디오 데이터가 구형의 면 상에 나타내어질 수 있다고 가정할 때, 프로젝션 처리부는 이러한 360 비디오 데이터를 피라미드 형태로 보고, 각 면을 나누어 2D 이미지 상에 프로젝션할 수 있다. 구형의 면 상의 360 비디오 데이터는 피라미드의 바닥면(front), 피라미드의 4방향의 옆면(Left top, Left bottom, Right top, Right bottom) 에 각각 대응되어, 2D 이미지 상에 (c) 좌측 또는 (c) 우측과 같이 프로젝션될 수 있다.
실시예에 따라 프로젝션 처리부는 전술한 스킴들 외에 등정방형 프로젝션(Equirectangular Projection) 스킴, 파노라믹 프로젝션(Panoramic Projection) 스킴 등을 이용하여 프로젝션을 수행할 수도 있다.
전술한 바와 같이 리전(Region) 이란, 360 비디오 데이터가 프로젝션된 2D 이미지가 나누어진 영역을 의미할 수 있다. 이 리전들은 프로젝션 스킴에 따라 프로젝션된 2D 이미지 상의 각 면들과 일치할 필요는 없다. 그러나 실시예에 따라, 프로젝션된 2D 이미지 상의 각 면들이 리전과 대응되도록 리전이 구분되어, 리전별 패킹이 수행될 수도 있다. 실시예에 따라 복수개의 면들이 하나의 리전에 대응될 수도 있고, 하나의 면이 복수개의 리전에 대응되게 리전이 구분될 수도 있다. 이 경우, 리전은 프로젝션 스킴에 따라 달라질 수 있다. 예를 들어 (a) 에서 정육면체의 각 면들(top, bottom, front, left, right, back) 은 각각 리전일 수 있다. (b) 에서 실린더의 옆면(side), 윗면(top), 바닥면(bottom) 은 각각 리전일 수 있다. (c) 에서 피라미드의 바닥면(front), 4방향 옆면(Left top, Left bottom, Right top, Right bottom) 들은 각각 리전일 수 있다.
도 7 은 실시예들의 일 실시예에 따른 타일(Tile)을 도시한 도면이다.
2D 이미지에 프로젝션된 360 비디오 데이터 또는 리전별 패킹까지 수행된 360 비디오 데이터는 하나 이상의 타일로 구분될 수 있다. 도시된 (a) 는 하나의 2D 이미지가 16 개의 타일로 나뉘어진 형태를 도시하고 있다. 여기서 2D 이미지란 전술한 프로젝티드 프레임 내지는 팩드 프레임일 수 있다. 실시예들에 따른 360 비디오 전송 장치의 또 다른 실시예에 의하면, 데이터 인코더는 각각의 타일을 독립적으로 인코딩할 수 있다.
전술한 리전별 패킹과 타일링(Tiling)은 구분될 수 있다. 전술한 리전별 패킹은 코딩 효율을 높이기 위해 또는 레졸루션을 조정하기 위하여 2D 이미지상에 프로젝션된 360 비디오 데이터를 리전으로 구분하여 처리하는 것을 의미할 수 있다. 타일링은 데이터 인코더가 프로젝티드 프레임 내지는 팩드 프레임을 타일이라는 구획별로 나누고, 해당 타일들 별로 독립적으로 인코딩을 수행하는 것을 의미할 수 있다. 360 비디오가 제공될 때, 사용자는 360 비디오의 모든 부분을 동시에 소비하지 않는다. 타일링은 제한된 밴드위스(bandwidth)상에서 사용자가 현재 보는 뷰포트 등 중요 부분 내지 일정 부분에 해당하는 타일만을 수신측으로 전송 혹은 소비하는 것을 가능케할 수 있다. 타일링을 통해 제한된 밴드위스가 더 효율적으로 활용될 수 있고, 수신측에서도 모든 360 비디오 데이터를 한번에 다 처리하는 것에 비하여 연산 부하를 줄일 수 있다.
리전과 타일은 구분되므로, 두 영역이 같을 필요는 없다. 그러나 실시예에 따라 리전과 타일은 같은 영역을 지칭할 수도 있다. 실시예에 따라 타일에 맞추어 리전별 패킹이 수행되어 리전과 타일이 같아질 수 있다. 또한 실시예에 따라, 프로젝션 스킴에 따른 각 면과 리전이 같은 경우, 프로젝션 스킴에 따른 각 면, 리전, 타일이 같은 영역을 지칭할 수도 있다. 문맥에 따라 리전은 VR 리전, 타일을 타일 리전으로 불릴 수도 있다.
ROI (Region of Interest) 는 360 컨텐츠 제공자가 제안하는, 사용자들의 관심 영역을 의미할 수 있다. 360 컨텐츠 제공자는 360 비디오를 제작할 때, 어느 특정 영역을 사용자들이 관심있어 할 것으로 보고, 이를 고려하여 360 비디오를 제작할 수 있다. 실시예에 따라 ROI 는 360 비디오의 컨텐츠 상, 중요한 내용이 재생되는 영역에 해당할 수 있다.
실시예들에 따른 360 비디오 전송/수신 장치의 또 다른 실시예에 의하면, 수신측 피드백 처리부는 뷰포트 정보를 추출, 수집하여 이를 송신측 피드백 처리부로 전달할 수 있다. 이 과정에서 뷰포트 정보는 양 측의 네트워크 인터페이스를 이용해 전달될 수 있다. 도시된 (a) 의 2D 이미지에서 뷰포트 (t6010) 가 표시되었다. 여기서 뷰포트 는 2D 이미지 상의 9 개의 타일에 걸쳐 있을 수 있다.
이 경우 360 비디오 전송 장치는 타일링 시스템을 더 포함할 수 있다. 실시예에 따라 타일링 시스템은 데이터 인코더 다음에 위치할 수도 있고(도시된 (b)), 전술한 데이터 인코더 내지 전송 처리부 내에 포함될 수도 있고, 별개의 내/외부 엘리먼트로서 360 비디오 전송 장치에 포함될 수 있다.
타일링 시스템은 송신측 피드백 처리부로부터 뷰포트 정보를 전달받을 수 있다. 타일링 시스템은 뷰포트 영역이 포함되는 타일만을 선별하여 전송할 수 있다. 도시된 (a) 의 2D 이미지에서 총 16 개의 타일 중 뷰포트 영역(t6010) 을 포함하는 9 개의 타일들만이 전송될 수 있다. 여기서 타일링 시스템은 브로드밴드를 통한 유니캐스트 방식으로 타일들을 전송할 수 있다. 사용자에 따라 뷰포트 영역이 다르기 때문이다.
또한 이 경우 송신측 피드백 처리부는 뷰포트 정보를 데이터 인코더로 전달할 수 있다. 데이터 인코더는 뷰포트 영역을 포함하는 타일들에 대해 다른 타일들보다 더 높은 퀄리티로 인코딩을 수행할 수 있다.
또한 이 경우 송신측 피드백 처리부는 뷰포트 정보를 메타데이터 처리부로 전달할 수 있다. 메타데이터 처리부는 뷰포트 영역과 관련된 메타데이터 를 360 비디오 전송 장치의 각 내부 엘레먼트로 전달해주거나, 360 비디오 관련 메타데이터에 포함시킬 수 있다.
이러한 타일링 방식을 통하여, 전송 밴드위스(bandwidth)가 절약될 수 있으며, 타일 별로 차등화된 처리를 수행하여 효율적 데이터 처리/전송이 가능해질 수 있다.
전술한 뷰포트 영역과 관련된 실시예들은 뷰포트 영역이 아닌 다른 특정 영역들에 대해서도 유사한 방식으로 적용될 수 있다. 예를 들어, 전술한 게이즈 분석을 통해 사용자들이 주로 관심있어 하는 것으로 판단된 영역, ROI 영역, 사용자가 VR 디스플레이를 통해 360 비디오를 접할 때 처음으로 재생되는 영역(초기 시점, Initial Viewpoint) 등에 대해서도, 전술한 뷰포트 영역과 같은 방식의 처리들이 수행될 수 있다.
실시예들에 따른 360 비디오 전송 장치의 또 다른 실시예에 의하면, 전송 처리부는 각 타일 별로 다르게 전송을 위한 처리를 수행할 수 있다. 전송 처리부는 타일 별로 다른 전송 파라미터(모듈레이션 오더, 코드 레이트 등)를 적용하여, 각 타일 별로 전달되는 데이터의 강건성(robustenss)을 다르게 할 수 있다.
이 때, 송신측 피드백 처리부는 360 비디오 수신 장치로부터 전달받은 피드백 정보를 전송 처리부로 전달하여, 전송 처리부가 타일별 차등화된 전송 처리를 수행하도록 할 수 있다. 예를 들어 송신측 피드백 처리부는 수신측으로부터 전달받은 뷰포트 정보를 전송 처리부로 전달할 수 있다. 전송 처리부는 해당 뷰포트 영역을 포함하는 타일들에 대해 다른 타일들보다 더 높은 강건성을 가지도록 전송 처리를 수행할 수 있다.
도 8 은 실시예들의 일 실시예에 따른 360도 비디오 관련 메타데이터를 도시한 도면이다.
전술한 360 비디오 관련 메타데이터는 360 비디오에 대한 다양한 메타데이터를 포함할 수 있다. 문맥에 따라, 360 비디오 관련 메타데이터는 360 비디오 관련 시그널링 정보라고 불릴 수도 있다. 360 비디오 관련 메타데이터는 별도의 시그널링 테이블에 포함되어 전송될 수도 있고, DASH MPD 내에 포함되어 전송될 수도 있고, ISOBMFF 등의 파일 포맷에 box 형태로 포함되어 전달될 수도 있다. 360 비디오 관련 메타데이터가 box 형태로 포함되는 경우 파일, 프래그먼트, 트랙, 샘플 엔트리, 샘플 등등 다양한 레벨에 포함되어 해당되는 레벨의 데이터에 대한 메타데이터를 포함할 수 있다.
실시예에 따라, 후술하는 메타데이터의 일부는 시그널링 테이블로 구성되어 전달되고, 나머지 일부는 파일 포맷 내에 box 혹은 트랙 형태로 포함될 수도 있다.
실시예들에 따른 360 비디오 관련 메타데이터의 일 실시예에 의하면, 360 비디오 관련 메타데이터는 프로젝션 스킴 등에 관한 기본 메타데이터, 스테레오스코픽(stereoscopic) 관련 메타데이터, 초기 시점(Initial View/Initial Viewpoint) 관련 메타데이터, ROI 관련 메타데이터, FOV (Field of View) 관련 메타데이터 및/또는 크롭된 영역(cropped region) 관련 메타데이터를 포함할 수 있다. 실시예에 따라 360 비디오 관련 메타데이터는 전술한 것 외에 추가적인 메타데이터를 더 포함할 수 있다.
실시예들에 따른 360 비디오 관련 메타데이터의 실시예들은 전술한 기본 메타데이터, 스테레오스코픽 관련 메타데이터, 초기 시점 관련 메타데이터, ROI 관련 메타데이터, FOV 관련 메타데이터, 크롭된 영역 관련 메타데이터 및/또는 이후 추가될 수 있는 메타데이터들 중 적어도 하나 이상을 포함하는 형태일 수 있다. 실시예들에 따른 360 비디오 관련 메타데이터의 실시예들은, 각각 포함하는 세부 메타데이터들의 경우의 수에 따라 다양하게 구성될 수 있다. 실시예에 따라 360 비디오 관련 메타데이터는 전술한 것 외에 추가적인 정보들을 더 포함할 수도 있다.
기본 메타데이터에는 3D 모델 관련 정보, 프로젝션 스킴 관련 정보 등이 포함될 수 있다. 기본 메타데이터에는 vr_geometry 필드, projection_scheme 필드 등이 포함될 수 있다. 실시예에 따라 기본 메타데이터는 추가적인 정보들을 더 포함할 수도 있다.
vr_geometry 필드는 해당 360 비디오 데이터가 지원하는 3D 모델의 타입을 지시할 수 있다. 전술한 바와 같이 360 비디오 데이터가 3D 공간 상에 리-프로젝션되는 경우, 해당 3D 공간은 vr_geometry 필드가 지시하는 3D 모델에 따른 형태를 가질 수 있다. 실시예에 따라, 렌더링시에 사용되는 3D 모델은 vr_geometry 필드가 지시하는 리-프로젝션에 사용되는 3D 모델과 다를 수도 있다. 이 경우, 기본 메타데이터는 렌더링시에 사용되는 3D 모델을 지시하는 필드를 더 포함할 수도 있다. 해당 필드가 0, 1, 2, 3 의 값을 가지는 경우 3D 공간은 각각 구형(Sphere), 큐브(Cube), 실린더(Cylinder), 피라미드(Pyramid)의 3D 모델을 따를 수 있다. 해당 필드가 나머지 값을 가지는 경우는 향후 사용을 위해 남겨둘 수 있다(Reserved for Future Use). 실시예에 따라 360 비디오 관련 메타데이터는 해당 필드에 의해 지시되는 3D 모델에 대한 구체적인 정보를 더 포함할 수 있다. 여기서 3D 모델에 대한 구체적인 정보란 예를 들어 구형의 반지름 정보, 실린더의 높이 정보 등을 의미할 수 있다. 본 필드는 생략될 수 있다.
projection_scheme 필드는 해당 360 비디오 데이터가 2D 이미지 상에 프로젝션될 때 사용된 프로젝션 스킴을 지시할 수 있다. 해당 필드가 0, 1, 2, 3, 4, 5 의 값을 가지는 경우, 각각 등정방형 프로젝션(Equirectangular Projection) 스킴, 큐빅 프로젝션 스킴, 실린더형 프로젝션 스킴, 타일-베이스드(Tile-based) 프로젝션 스킴, 피라미드 프로젝션 스킴, 파노라믹 프로젝션 스킴이 사용되었을 수 있다. 해당 필드가 6 의 값을 가지는 경우는, 360 비디오 데이터가 스티칭 없이 바로 2D 이미지 상에 프로젝션된 경우일 수 있다. 해당 필드가 나머지 값을 가지는 경우는 향후 사용을 위해 남겨둘 수 있다(Reserved for Future Use). 실시예에 따라 360 비디오 관련 메타데이터는 해당 필드에 의해 특정되는 프로젝션 스킴에 의해 발생한 리전(Region)에 대한 구체적인 정보를 더 포함할 수 있다. 여기서 리전에 대한 구체적인 정보란 예를 들어 리전의 회전 여부, 실린더의 윗면(top) 리전의 반지름 정보 등을 의미할 수 있다.
스테레오스코픽 관련 메타데이터는 360 비디오 데이터의 3D 관련 속성들에 대한 정보들을 포함할 수 있다. 스테레오스코픽 관련 메타데이터는 is_stereoscopic 필드 및/또는 stereo_mode 필드를 포함할 수 있다. 실시예에 따라 스테레오스코픽 관련 메타데이터는 추가적인 정보들을 더 포함할 수도 있다.
is_stereoscopic 필드는 해당 360 비디오 데이터가 3D 를 지원하는지 여부를 지시할 수 있다. 해당 필드가 1 이면 3D 지원, 0 이면 3D 미지원을 의미할 수 있다. 본 필드는 생략될 수 있다.
stereo_mode 필드는 해당 360 비디오가 지원하는 3D 레이아웃을 지시할 수 있다. 본 필드만으로 해당 360 비디오가 3D 를 지원하는지 여부를 지시할 수도 있는데, 이 경우 전술한 is_stereoscopic 필드는 생략될 수 있다. 본 필드 값이 0 인 경우, 해당 360 비디오는 모노(mono) 모드일 수 있다. 즉 프로젝션된 2D 이미지는 하나의 모노 뷰(mono view) 만을 포함할 수 있다. 이 경우 해당 360 비디오는 3D 를 지원하지 않을 수 있다.
본 필드 값이 1, 2 인 경우, 해당 360 비디오는 각각 좌우(Left-Right) 레이아웃, 상하(Top-Bottom) 레이아웃에 따를 수 있다. 좌우 레이아웃, 상하 레이아웃은 각각 사이드-바이-사이드 포맷, 탑-바텀 포맷으로 불릴 수도 있다. 좌우 레이아웃의 경우, 좌영상/우영상이 프로젝션된 2D 이미지들은 이미지 프레임 상에서 각각 좌/우로 위치할 수 있다. 상하 레이아웃의 경우, 좌영상/우영상이 프로젝션된 2D 이미지들은 이미지 프레임 상에서 각각 위/아래로 위치할 수 있다. 해당 필드가 나머지 값을 가지는 경우는 향후 사용을 위해 남겨둘 수 있다(Reserved for Future Use).
초기 시점 관련 메타데이터는 사용자가 360 비디오를 처음 재생했을 때 보게되는 시점(초기 시점)에 대한 정보를 포함할 수 있다. 초기 시점 관련 메타데이터는 initial_view_yaw_degree 필드, initial_view_pitch_degree 필드 및/또는 initial_view_roll_degree 필드를 포함할 수 있다. 실시예에 따라 초기 시점 관련 메타데이터는 추가적인 정보들을 더 포함할 수도 있다.
initial_view_yaw_degree 필드, initial_view_pitch_degree 필드, initial_view_roll_degree 필드는 해당 360 비디오 재생 시의 초기 시점을 나타낼 수 있다. 즉, 재생시 처음 보여지는 뷰포트의 정중앙 지점이, 이 세 필드들에 의해 나타내어질 수 있다. 각 필드는 그 정중앙 지점이 위치를 yaw, pitch, roll 축을 기준으로 회전된 방향(부호) 및 그 정도(각도)로 나타낼 수 있다. 이 때 FOV 에 따라 처음 재생시 보여지게 되는 뷰포트가 결정될 수 있다. FOV 를 통하여, 지시된 초기 시점을 기준으로 한, 초기 뷰포트의 가로길이 및 세로길이(width, height) 가 결정될 수 있다. 즉, 이 세 필드들 및 FOV 정보를 이용하여, 360 비디오 수신 장치는 사용자에게 360 비디오의 일정 영역을 초기 뷰포트로서 제공할 수 있다.
실시예에 따라, 초기 시점 관련 메타데이터가 지시하는 초기 시점은, 장면(scene) 별로 변경될 수 있다. 즉, 360 컨텐츠의 시간적 흐름에 따라 360 비디오의 장면이 바뀌게 되는데, 해당 360 비디오의 장면마다 사용자가 처음 보게되는 초기 시점 내지 초기 뷰포트가 변경될 수 있다. 이 경우, 초기 시점 관련 메타데이터는 각 장면별로의 초기 시점을 지시할 수 있다. 이를 위해 초기 시점 관련 메타데이터는, 해당 초기 시점이 적용되는 장면을 식별하는 장면(scene) 식별자를 더 포함할 수도 있다. 또한 360 비디오의 장면별로 FOV 가 변할 수도 있으므로, 초기 시점 관련 메타데이터는 해당 장면에 해당하는 FOV 를 나타내는 장면별 FOV 정보를 더 포함할 수도 있다.
ROI 관련 메타데이터는 전술한 ROI 에 관련된 정보들을 포함할 수 있다. ROI 관련 메타데이터는, 2d_roi_range_flag 필드 및/또는 3d_roi_range_flag 필드를 포함할 수 있다. 두 필드는 각각 ROI 관련 메타데이터가 2D 이미지를 기준으로 ROI 를 표현하는 필드들을 포함하는지, 3D 공간을 기준으로 ROI 를 표현하는 필드들을 포함하는지 여부를 지시할 수 있다. 실시예에 따라 ROI 관련 메타데이터는, ROI 에 따른 차등 인코딩 정보, ROI 에 따른 차등 전송처리 정보 등 추가적인 정보들을 더 포함할 수도 있다.
ROI 관련 메타데이터가 2D 이미지를 기준으로 ROI 를 표현하는 필드들을 포함하는 경우, ROI 관련 메타데이터는 min_top_left_x 필드, max_top_left_x 필드, min_top_left_y 필드, max_top_left_y 필드, min_width 필드, max_width 필드, min_height 필드, max_height 필드, min_x 필드, max_x 필드, min_y 필드 및/또는 max_y 필드를 포함할 수 있다.
min_top_left_x 필드, max_top_left_x 필드, min_top_left_y 필드, max_top_left_y 필드는 ROI 의 좌측 상단 끝의 좌표의 최소/최대값을 나타낼 수 있다. 이 필드들은 차례로 좌상단 끝의 최소 x 좌표, 최대 x 좌표, 최소 y 좌표, 최대 y 좌표 를 나타낼 수 있다.
min_width 필드, max_width 필드, min_height 필드, max_height 필드는 ROI 의 가로 크기(width), 세로 크기(height)의 최소/최대값을 나타낼 수 있다. 이 필드들은 차례로 가로 크기의 최소값, 가로 크기의 최대값, 세로 크기의 최소값, 세로 크기의 최대값을 나타낼 수 있다.
min_x 필드, max_x 필드, min_y 필드, max_y 필드는 ROI 내의 좌표들의 최소/최대값을 나타낼 수 있다. 이 필드들은 차례로 ROI 내 좌표들의 최소 x 좌표, 최대 x 좌표, 최소 y 좌표, 최대 y 좌표 를 나타낼 수 있다. 이 필드들은 생략될 수 있다.
ROI 관련 메타데이터가 3D 랜더링 공간 상의 좌표 기준으로 ROI 를 표현하는 필드들을 포함하는 경우, ROI 관련 메타데이터는 min_yaw 필드, max_yaw 필드, min_pitch 필드, max_pitch 필드, min_roll 필드, max_roll 필드, min_field_of_view 필드 및/또는 max_field_of_view 필드를 포함할 수 있다.
min_yaw 필드, max_yaw 필드, min_pitch 필드, max_pitch 필드, min_roll 필드, max_roll 필드는 ROI 가 3D 공간상에서 차지하는 영역을 yaw, pitch, roll 의 최소/최대값으로 나타낼 수 있다. 이 필드들은 차례로 yaw 축 기준 회전량의 최소값, yaw 축 기준 회전량의 최대값, pitch 축 기준 회전량의 최소값, pitch 축 기준 회전량의 최대값, roll 축 기준 회전량의 최소값, roll 축 기준 회전량의 최대값을 나타낼 수 있다.
min_field_of_view 필드, max_field_of_view 필드는 해당 360 비디오 데이터의 FOV 의 최소/최대값을 나타낼 수 있다. FOV 는 360 비디오의 재생시 한번에 디스플레이되는 시야범위를 의미할 수 있다. min_field_of_view 필드, max_field_of_view 필드는 각각 FOV 의 최소값, 최대값을 나타낼 수 있다. 이 필드들은 생략될 수 있다. 이 필드들은 후술할 FOV 관련 메타데이터에 포함될 수도 있다.
FOV 관련 메타데이터는 전술한 FOV 에 관련한 정보들을 포함할 수 있다. FOV 관련 메타데이터는 content_fov_flag 필드 및/또는 content_fov 필드를 포함할 수 있다. 실시예에 따라 FOV 관련 메타데이터는 전술한 FOV 의 최소/최대값 관련 정보 등 추가적인 정보들을 더 포함할 수도 있다.
content_fov_flag 필드는 해당 360 비디오에 대하여 제작시 의도한 FOV 에 대한 정보가 존재하는지 여부를 지시할 수 있다. 본 필드값이 1인 경우, content_fov 필드가 존재할 수 있다.
content_fov 필드는 해당 360 비디오에 대하여 제작시 의도한 FOV 에 대한 정보를 나타낼 수 있다. 실시예에 따라 해당 360 비디오 수신 장치의 수직(vertical) 혹은 수평(horizontal) FOV 에 따라, 360 영상 중에서 사용자에게 한번에 디스플레이되는 영역이 결정될 수 있다. 혹은 실시예에 따라 본 필드의 FOV 정보를 반영하여 사용자에게 한번에 디스플레이되는 360 비디오의 영역이 결정될 수도 있다.
크롭된 영역 관련 메타데이터는 이미지 프레임 상에서 실제 360 비디오 데이터를 포함하는 영역에 대한 정보를 포함할 수 있다. 이미지 프레임은 실제 360 비디오 데이터 프로젝션된 액티브 비디오 영역(Active Video Area)과 그렇지 않은 영역을 포함할 수 있다. 이 때 액티브 비디오 영역은 크롭된 영역 또는 디폴트 디스플레이 영역이라고 칭할 수 있다. 이 액티브 비디오 영역은 실제 VR 디스플레이 상에서 360 비디오로서 보여지는 영역으로서, 360 비디오 수신 장치 또는 VR 디스플레이는 액티브 비디오 영역만을 처리/디스플레이할 수 있다. 예를 들어 이미지 프레임의 종횡비(aspect ratio) 가 4:3 인 경우 이미지 프레임의 윗 부분 일부와 아랫부분 일부를 제외한 영역만 360 비디오 데이터를 포함할 수 있는데, 이 부분을 액티브 비디오 영역이라고 할 수 있다.
크롭된 영역 관련 메타데이터는 is_cropped_region 필드, cr_region_left_top_x 필드, cr_region_left_top_y 필드, cr_region_width 필드 및/또는 cr_region_height 필드를 포함할 수 있다. 실시예에 따라 크롭된 영역 관련 메타데이터는 추가적인 정보들을 더 포함할 수도 있다.
is_cropped_region 필드는 이미지 프레임의 전체 영역이 360 비디오 수신 장치 내지 VR 디스플레이에 의해 사용되는지 여부를 나타내는 플래그일 수 있다. 즉, 본 필드는 이미지 프레임 전체가 액티브 비디오 영역인지 여부를 지시할 수 있다. 이미지 프레임의 일부만이 액티브 비디오 영역인 경우, 하기의 4 필드가 더 추가될 수 있다.
cr_region_left_top_x 필드, cr_region_left_top_y 필드, cr_region_width 필드, cr_region_height 필드는 이미지 프레임 상에서 액티브 비디오 영역을 나타낼 수 있다. 이 필드들은 각각 액티브 비디오 영역의 좌상단의 x 좌표, 액티브 비디오 영역의 좌상단의 y 좌표, 액티브 비디오 영역의 가로 길이(width), 액티브 비디오 영역의 세로 길이(height) 를 나타낼 수 있다. 가로 길이와 세로 길이는 픽셀을 단위로 나타내어질 수 있다.
전술한 바와 같이, 360도 비디오 관련 시그널링 정보 또는 메타데이터는 임의로 정의된 시그널링 테이블에 포함될 수 있고, ISOBMFF 또는 Common File Format 등의 파일 포맷에 box형태로 포함될 수도 있으며, DASH MPD 내에 포함되어 전송될 수도 있다. 또한, 360도 미디어 데이터는 이러한 파일 포맷 또는 DASH segment에 포함되어 전송될 수도 있다.
이하, ISOBMFF 및 DASH MPD에 대해 순차적으로 설명한다.
도9는 3DoF+ VR 시스템에서 추가적으로 정의되는 위치(viewpoint)와 시점(viewing position)를 나타낸다.
실시예들은360 비디오 기반 VR 시스템은 전술한 360 비디오 처리 과정을 기반으로 360 비디오에 대하여 사용자의 위치를 기준으로 서로 다른 방향(viewing orientation)에 대한 시각적/청각적 경험을 제공할 수 있다. 이러한 방법을 3DoF (three degree of freedom) plus라고 명명할 수 있다. 구체적으로, 360 비디오에 대하여 사용자의 고정 위치에서의 서로 다른 방향에 대한 시작적/청각적 경험을 제공하는 VR 시스템은 3DoF 기반 VR 시스템이라고 불릴 수 있다.
한편, 동일 시간대에서 서로 다른 위치 (viewpoint), 서로 다른 시점(viewing position)에서의 서로 다른 방향에 대한 확장된 시각적/청각적 경험을 제공할 수 있는 VR 시스템은 3DoF+ 또는 3DoF plus 기반 VR 시스템라고 불릴 수 있다.
1) (a)와 같은 공간(공연장의 예)을 가정했을 때, 서로 다른 위치(붉은색 동그라미로 표시된 공연장의 위치의 예)를 각각의 viewpoint로 고려할 수 있다. 이 때, 예제와 같이 동일 공간에 존재하는 각 viewpoint에서 제공되는 영상/음성은 동일한 시간 흐름을 가질 수 있다.
2) 이 경우 특정 위치에서 사용자의 시점 변화(head motion)에 따라 서로 다른 시각적/청각적 경험 제공할 수 있다. 즉, 특정 viewpoint에 대해 (b)에 도시된 바와 같은 다양한 viewing position의 sphere를 가정할 수 있으며, 각 시점의 상대적인 위치를 반영한 영상/음성/텍스트 정보를 제공할 수 있다.
3) 한편, (c)에 도시된 바와 같이 특정 위치의 특정 시점에서는 기존의 3DoF와 같이 다양한 방향의 시각적/청각적 정보를 전달할 수 있다. 이 때, main source(영상/음성/텍스트) 뿐만 아니라 추가적인 다양한 소스를 통합하여 제공할 수 있으며, 이는 사용자의 시청 방향 (viewing orientation)과 연계되거나 독립적으로 정보를 전달할 수 있다.
도10은 3DoF+ 시스템에 기반한 360도 비디오 신호처리 및 관련 전송장치/수신장치 구현 방법에 대해서 도시한다.
도 10은 3DoF+ 의 영상획득, 전처리, 전송, (후)처리, 렌더링 및 피드백 과정을 포함한 3DoF+ end-to-end system 흐름도에 대한 예시이다.
1) Acquisition: 360 비디오의 캡쳐, 합성 또는 생성 과정 등을 통한 360 비디오를 획득하는 과정을 의미할 수 있다. 이 과정을 통하여 다수의 위치에 대해 head motion에 따른 다수의 영상/음성 정보를 획득할 수 있다. 이 때, 영상 정보는 시각적 정보(texture) 뿐 아니라 깊이 정보(depth)를 포함할 수 있다. 이 때 a의 영상 정보 예시와 같이 서로 다른 촬영 위치(viewpoint)에 따른 서로 다른 시점(viewing position)의 복수의 정보를 각각 획득할 수 있다.
2) Composition: 영상/음성 입력 장치를 통해 획득한 정보 뿐 아니라 외부 미디어를 통한 영상(비디오/이미지 등), 음성(오디오/효과음향 등), 텍스트(자막 등)을 사용자 경험에 포함하기 위해 합성하기 위한 방법을 정의할 수 있다.
3) Pre-processing: 획득된 360 비디오의 전송/전달을 위한 준비(전처리) 과정으로서, 스티칭, 프로젝션, 리전별 패킹 과정 및/또는 인코딩 과정 등을 포함할 수 있다. 즉, 이 과정은 영상/음성/텍스트 정보를 제작자의 의도에 따라 데이터를 변경/보완 하기위한 전처리 과정 및 인코딩 과정이 포함될 수 있다. 예를 들어 영상의 전처리 과정에서는 획득된 시각 정보를 360 sphere 상에 매핑하는 작업(stitching), 영역 경계를 없애거나 색상/밝기 차이를 줄이거나 영상의 시각적 효과를 주는 보정 작업(editing), 시점에 따른 영상을 분리하는 과정(view segmentation), 360 sphere 상의 영상을 2D 영상으로 매핑하는 프로젝션 과정(projection), 영역에 따라 영상을 재배치 하는 과정 (region-wise packing), 영상 정보를 압축하는 인코딩 과정이 포함될 수 있다. B의 비디오 측면의 예시와 같이 서로 다른 촬영 위치(viewpoint)에 따른 서로 다른 시점(viewing position)의 복수의 프로젝션 영상이 생성될 수 있다.
4) Delivery: 준비 과정(전처리 과정)을 거친 영상/음성 데이터 및 메타데이터들을 처리하여 전송하는 과정을 의미할 수 있다. 서로 다른 촬영 위치(viewpoint)에 따른 서로 다른 시점(viewing position)의 복수의 영상/음성 데이터 및 관련 메타데이터를 전달하는 방법으로써 전술한 바와 같이 방송망, 통신망을 이용하거나, 단방향 전달 등의 방법을 사용할 수 있다.
5) Post-processing & composition: 수신된/저장된 비디오/오디오/텍스트 데이터를 디코딩하고 최종 재생을 위한 후처리 과정을 의미할 수 있다. 예를 들어 후처리 과정은 전술한 바와 같이 패킹 된 영상을 풀어주는 언패킹 및 2D 프로젝션 된 영상을 3D 구형 영상으로복원하는 리-프로젝션 과정 등이 포함될 수 있다.
6) Rendering: 3D 공간상에 리-프로젝션된 이미지/비디오 데이터를 렌더링하고 디스플레이하는 과정을 의미할 수 있다. 이 과정에서 영상/음성 신호를 최종적으로 출력하기 위한 형태로 재구성할 수 있다. 사용자의 관심영역이 존재하는 방향(viewing orientation), 시점(viewing position/head position), 위치(viewpoint)를 추적할 수 있으며, 이 정보에 따라 필요한 영상/음성/텍스트 정보만을 선택적으로 사용할 수 있다. 이 때, 영상 신호의 경우 사용자의 관심영역에 따라 c와 같이 서로 다른 시점을 선택할 수 있으며, 최종적으로 d와 같이 특정 위치에서의 특정 시점의 특정 방향의 영상을 출력할 수 있다.
7) Feedback: 디스플레이 과정에서 획득될 수 있는 다양한 피드백 정보들을 송신측으로 전달하는 과정을 의미할 수 있다. 본 실시예의 경우 사용자 관심영역의 방향(viewing orientation), 시점(viewing position), 위치(viewpoint)를 추정하고, 이를 기반으로 영상/음성을 재생할 수 있도록 피드백을 전달할 수 있다.
도11은 3DoF+ end-to-end 시스템의 구조를 나타낸다.
도11은 3DoF+ end-to-end 시스템 아키텍쳐의 예시이다. 도 11의 아키텍처에 의하여 전술된 바와 같이 3DoF+ 360 컨텐츠가 제공될 수 있다.
360 비디오 전송 장치는 크게 360 비디오(이미지)/오디오 데이터 획득이 이루어지는 부분 (acquisition unit), 획득된 데이터를 처리하는 부분 (video/audio pre-processor), 추가 정보를 합성하기 위한 부분(composition generation unit), 텍스트, 오디오 및 프로젝션된 360도 비디오를 인코딩하는 부분(encoding unit) 및 인코딩된 데이터를 인캡슐레이션하는 부분(encapsulation unit)으로 구성될 수 있다. 전술한 바와 같이 인코딩된 데이터는 비트스트림(bitstream) 형태로 출력될 수 있으며, 인코딩된 데이터는 ISOBMFF, CFF 등의 파일 포맷으로 인캡슐레이션되거나, 기타 DASH 세그먼트 등의 형태로 처리할 수 있다. 인코딩된 데이터는 디지털 저장 매체를 통하여 360 비디오 수신 장치로 전달될 수 있으며, 또는 비록 명시적으로 도시되지는 않았으나, 전술한 바와 같이 전송 처리부를 통하여 전송을 위한 처리를 거치고, 이후 방송망 또는 브로드밴드 등을 통하여 전송될 수 있다.
데이터 획득 부분에서는 센서의 방향(sensor orientation, 영상의 경우 viewing orientation), 센서의 정보 획득 시점(sensor position, 영상의 경우 viewing position), 센서의 정보 획득 위치(영상의 경우 viewpoint)에 따라 서로 다른 정보를 동시에 혹은 연속적으로 획득할 수 있으며, 이 때 비디오, 이미지, 오디오, 위치 정보 등을 획득할 수 있다.
영상 데이터의 경우 텍스처 (texture) 및 깊이 정보(depth)를 각각 획득할 수 있으며, 각 컴포넌트의 특성에 따라 서로 다른 전처리 (video pre-processing)가 가능하다. 예를 들어 텍스처 정보의 경우 이미지 센서 위치 정보를 이용하여 동일 위치 (viewpoint)에서 획득한 동일 시점 (viewing position)의 서로 다른 방향 (viewing orientation)의 영상들을 이용하여 360 전방위 영상을 구성할 수 있으며, 이를 위해 영상 스티칭 (stitching) 과정을 수행할 수 있다. 또한 영상을 인코딩하기 위한 포맷으로 변경하기 위한 프로젝션(projection) 및/또는 리전별 팩킹을 수행할 수 있다. 깊이 영상의 경우 일반적으로 뎁스 카메라를 통해 영상을 획득할 수 있으며, 이 경우 텍스쳐(예를 들어, 위치의 포인트에 대한 컬러를 알려줌)와 같은 형태로 깊이 영상을 만들 수 있다. 혹은, 별도로 측정된 데이터를 바탕으로 깊이 데이터를 생성할 수도 있다. 컴포넌트 별 영상이 생성된 후 효율적인 압축을 위한 비디오 포맷으로의 추가 변환 (packing)을 하거나 실제 필요한 부분으로 나누어 재 구성하는 과정 (sub-picture generation)이 수행될 수 있다. Video pre-processing 단에서 사용된 영상 구성에 대한 정보는 video metadata로 전달된다.
획득된 데이터 (혹은 주요하게 서비스 하기 위한 데이터) 이외에 추가적으로 주어지는 영상/음성/텍스트 정보를 함께 서비스 하는 경우, 이들 정보를 최종 재생 시 합성하기 위한 정보를 제공할 필요가 있다. 컴포지션 생성부(Composition generation unit)에서는 제작자의 의도를 바탕으로 외부에서 생성된 미디어 데이터 (영상의 경우 비디오/이미지, 음성의 경우 오디오/효과 음향, 텍스트의 경우 자막 등)를 최종 재생 단에서 합성하기 위한 정보를 생성하며, 이 정보는 composition metadata로 전달된다.
각각의 처리를 거친 영상/음성/텍스트 정보는 각각의 인코더를 이용해 압축되고, 어플리케이션에 따라 파일 혹은 세그먼트 단위로 인캡슐레이션 된다. 이 때, 비디오, 파일 혹은 세그먼트 구성 방법에 따라 필요한 정보만을 추출(file extractor)이 가능하다.
또한 각 데이터를 수신기에서 재구성하기 위한 정보가 코덱 혹은 파일 포멧/시스템 레벨에서 전달되는데, 여기에서는 비디오/오디오 재구성을 위한 정보 (video/audio metadata), 오버레이를 위한 합성 정보 (composition metadata), 비디오/오디오 재생 가능 위치 (viewpoint) 및 각 위치에 따른 시점 (viewing position) 정보 (viewing position and viewpoint metadata) 등이 포함된다. 이와 같은 정보의 처리는 별도의 메타데이터 처리부를 통한 생성도 가능하다.
360 비디오 수신 장치는 크게 수신된 파일 혹은 세그먼트를 디캡슐레이션하는 부분 (file/segment decapsulation unit), 비트스트림으로부터 영상/음성/텍스트 정보를 생성하는 부분 (decoding unit), 영상/음성/텍스트를 재생하기 위한 형태로 재구성하는 부분 (post-processor), 사용자의 관심영역을 추적하는 부분 (tracking unit) 및 재생 장치인 디스플레이로 구성될 수 있다.
디캡슐레이션을 통해 생성된 비트스트림은 데이터의 종류에 따라 영상/음성/텍스트 등으로 나뉘어 재생 가능한 형태로 개별적으로 디코딩될 수 있다.
tracking 부분에서는 센서 및 사용자의 입력 정보 등을 바탕으로 사용자의 관심 영역 (Region of interest)의 위치 (viewpoint), 해당 위치에서의 시점 (viewing position), 해당 시점에서의 방향 (viewing orientation) 정보를 생성하게 되며, 이 정보는 360 비디오 수신 장치의 각 모듈에서 관심 영역 선택 혹은 추출 등에 사용되거나, 관심 영역의 정보를 강조하기 위한 후처리 과정 등에 사용될 수 있다. 또한 360 비디오 전송 장치 에 전달되는 경우 효율적인 대역폭 사용을 위한 파일 선택 (file extractor) 혹은 서브 픽처 선택, 관심영역에 기반한 다양한 영상 재구성 방법 (viewport/viewing position / viewpoint dependent processing) 등에 사용될 수 있다.
디코딩 된 영상 신호는 영상 구성 방법에 따라 다양한 처리 방법에 따라 처리될 수 있다. 360 비디오 전송 장치에서 영상 패킹이 이루어 진 경우 메타데이터를 통해 전달된 정보를 바탕으로 영상을 재구성 하는 과정이 필요하다. 이 경우 360 비디오 전송 장치에서 생성한 video metadata를 이용할 수 있다. 또한 디코딩 된 영상 내에 복수의 시청 위치 (viewpoint), 혹은 복수의 시점 (viewing position), 혹은 다양한 방향 (viewing orientation)의 영상이 포함된 경우 tracking 을 통해 생성된 사용자의 관심 영역의 위치, 시점, 방향 정보와 매칭되는 정보를 선택하여 처리할 수 있다. 이 때, 송신단에서 생성한 viewing position and viewpoint metadata가 사용될 수 있다. 또한 특정 위치, 시점, 방향에 대해 복수의 컴포넌트가 전달되거나, 오버레이를 위한 비디오 정보가 별도로 전달되는 경우 각각에 따른 렌더링 과정이 포함될 수 있다. 별도의 렌더링 과정을 거친 비디오 데이터(텍스처, 뎁스, 오버레이)는 합성 과정 (composition)을 거치게 되며, 이 때, 송신단에서 생성한 composition metadata가 사용될 수 있다. 최종적으로 사용자의 관심 영역에 따라 viewport에 재생하기 위한 정보를 생성할 수 있다.
디코딩 된 음성 신호는 오디오 렌더러 그리고/혹은 후처리 과정을 통해 재생 가능한 음성 신호를 생성하게 되며, 이 때 사용자의 관심 영역에 대한 정보 및 360 비디오 수신 장치에 전달된 메타데이터를 바탕으로 사용자의 요구에 맞는 정보를 생성할 수 있다.
디코딩 된 텍스트 신호는 오버레이 렌더러에 전달되어 서브타이틀 등의 텍스트 기반의 오버레이 정보로써 처리된다. 필요한 경우 별도의 텍스트 후처리 과정이 포함될 수 있다.
도12는 FLUS (Framework for Live Uplink Streaming)의 구조를 나타낸다.
위에서 기술한 송신단 및 수신단의 세부 블록은 FLUS (Framework for Live Uplink Streaming)에서의 source 와 sink의 기능으로 각각 분류할 수 있으며, 이 경우 아래와 같이 정보 획득 장치에서 source의 기능을 구현하고, 네트워크 상에서 sink의 기능을 구현하거나, 혹은 네트워크 노드 내에서 source / sink를 각각 구현할 수 있다. 네트워크 노드는 UE(user equipment)를 포함할 수 있다. UE는 상술한 360 비디오 전송 장치 또는 360 비디오 수신 장치를 포함할 수 있다.
위에서 기술한 아키텍처를 기반으로 한 송수신 처리 과정을 아래와 같이 나타낼 수 있다. 아래의 송수신 처리 과정은 영상 신호 처리 과정을 기준으로 기술하며, 음성 혹은 텍스트와 같은 다른 신호를 처리하는 경우 기울임(italic)으로 표시된 부분은 생략하거나, 음성 혹은 텍스트 처리 과정에 맞도록 변경하여 처리할 수 있다.
도13은 3DoF+ 송신단의 구성을 나타낸다.
송신단(360 비디오 전송 장치)에서는 입력된 데이터가 카메라 출력 영상인 경우 sphere 영상 구성을 위한 스티칭을 위치/시점/컴포넌트 별로 진행할 수 있다. 위치/시점/컴포넌트 별 sphere 영상이 구성되면 코딩을 위해 2D 영상으로 프로젝션을 수행할 수 있다. 어플리케이션에 따라 복수의 영상을 통합 영상으로 만들기 위한 패킹 혹은 세부 영역의 영상으로 나누는 서브 픽처로 생성할 수 있다. 전술한 바와 같이 리전별 패킹 과정은 선택적(optional) 과정으로서 수행되지 않을 수 있으며, 이 경우 패킹 처리부는 생략될 수 있다. 입력된 데이터가 영상/음성/텍스트 추가 정보인 경우 추가 정보를 중심 영상에 추가하여 디스플레이 하는 방법을 알려줄 수 있으며, 추가 데이터도 함께 전송할 수 있다. 생성된 영상 및 추가된 데이터를 압축하여 비트 스트림으로 생성하는 인코딩 과정을 거쳐 전송 혹은 저장을 위한 파일 포맷으로 변환하는 인캡슐레이션 과정을 거칠 수 있다. 이 때 어플리케이션 혹은 시스템의 요구에 따라 수신부에서 필요로하는 파일을 추출하는 과정이 처리될 수 있다. 생성된 비트스트림은 전송처리부를 통해 전송 포맷으로 변환된 후 전송될 수 있다. 이 때, 송신측 피드백 처리부에서는 수신단에서 전달된 정보를 바탕으로 위치/시점/방향 정보와 필요한 메타데이터를 처리하여 관련된 송신부에서 처리하도록 전달할 수 있다.
도14는 3DoF+ 수신단의 구성을 나타낸다.
수신단(360 비디오 수신 장치)에서는 송신단에서 전달한 비트스트림을 수신한 후 필요한 파일을 추출할 수 있다. 생성된 파일 포맷 내의 영상 스트림을 피드백 처리부에서 전달하는 위치/시점/방향 정보 및 비디오 메타데이터를 이용하여 선별하며, 선별된 비트스트림을 디코더를 통해 영상 정보로 재구성할 수 있다. 패킹된 영상의 경우 메타데이터를 통해 전달된 패킹 정보를 바탕으로 언패킹을 수행할 수 있다. 송신단에서 패킹 과정이 생략된 경우, 수신단의 언패킹 또한 생략될 수 있다. 또한 필요에 따라 피드백 처리부에서 전달된 위치/시점/방향에 적합한 영상 및 필요한 컴포넌트를 선택하는 과정을 수행할 수 있다. 영상의 텍스처, 뎁스, 오버레이 정보 등을 재생하기 적합한 포맷으로 재구성하는 렌더링 과정을 수행할 수 있다. 최종 영상을 생성하기에 앞서 서로 다른 레이어의 정보를 통합하는 컴포지션 과정을 거칠 수 있으며, 디스플레이 뷰포트(viewport)에 적합한 영상을 생성하여 재생할 수 있다.
도 15는 OMAF 구조를 나타낸다.
360 비디오 기반 VR 시스템은 360 비디오 처리 과정을 기반으로 360 비디오에 대하여 사용자의 위치를 기준으로 서로 다른 방향(viewing orientation)에 대한 시각적/청각적 경험을 제공할 수 있다. 360 비디오에 대하여 사용자의 고정 위치에서의 서로 다른 방향에 대한 시작적/청각적 경험을 제공하는 서비스를 3DoF 기반 서비스라고 불릴 수 있다. 한편, 동일 시간대에서 임의의 위치 및 시점(viewing position)에서의 서로 다른 방향에 대한 확장된 시각적/청각적 경험을 제공할 수 있는 서비스는 6DoF (six degree of freedom) 기반 서비스라고 불릴 수 있다.
3DoF service를 위한 File format은 예를 들면 도15에 도시된 바와 같이 Head/eye tracking 모듈에 따라 rendering의 위치, 전송할 file의 정보, decoding 정보 등이 달라질 수 있는 구조를 가지고 있다. 그러나, 이러한 방식은 사용자의 위치 혹은 position에 따라 rendering의 정보/전송 내용, decoding의 정보가 달라지는 6DoF의 media file 전송에는 적합하지 않기에 수정이 필요하다.
도16은 사용자의 이동에 따른 미디어의 종류를 나타낸다.
실시예들은 사용자에게 몰입형 미디어/실감미디어(Immersive media)의 경험을 제공하기 위해, 6DoF contents를 제공하는 방안을 제안한다. 몰입형 미디어/실감미디어는 기존의 360 콘텐츠가 제공하는 가상의 환경에서 확대된 개념으로 기존의 360 콘텐츠가 (a)와 같은 형태로 사용자의 position 위치는 고정되어 있고, 회전에 대한 개념만 있었다면 몰입형 미디어/실감미디어는 (b) 혹은 (c) 와 같이 사용자에게 콘텐츠를 경험할 때 이동의 개념을 부여함으로써 가상의 공간에서 사용자의 이동/회전 등 더 다양한 감각적 경험을 제공할 수 있는 환경 혹은 콘텐츠를 의미할 수 있다.
(a)는 사용자의 포지션이 고정된 상태에서 사용자의 뷰가 회전하는 경우의 미디어 경험을 나타낸다.
(b) 는 사용자의 포지션이 고정된 상태에서 나아가 사용자의 머리가 추가적으로 움직일 수 있는 경우의 미디어 경험을 나타낸다.
(c) 는 사용자의 포지션이 움직일 수 있는 경우의 미디어 경험을 나타낸다.
실감 미디어 콘텐츠는 해당 콘텐츠를 제공하기 위한 6DoF비디오 및 6DoF오디오를 포함할 수 있으며, 6DoF 비디오는 실감미디어 콘텐츠 제공에 필요한 매 이동 때마다 새롭게 형성되는 3DoF 혹은 360비디오로 캡쳐되거나 재생되는 비디오 혹은 이미지를 의미 할 수 있다. 6DoF 콘텐츠는 3차원 공간 상에 나타내어지는 비디오 내지 이미지를 의미할 수 있다. 콘텐츠 내에서 이동이 고정된 상태라면 해당 콘텐츠는 기존의 360비디오와 같이 다양한 형태의 3차원 공간에서 나타내어질 수 있다. 예를 들어 구형 (Spherical)면 상에 나타내어질 수 있다. 콘텐츠 내에서 이동이 자유로운 상태라면 이동 경로 상에 사용자를 중심으로 3차원 공간이 매번 새롭게 형성되고 해당 위치의 콘텐츠를 사용자가 경험할 수 있다. 예를 들어 사용자가 처음 보는 위치에서의 구형(spherical)면 상에 나타내어진 영상을 경험하고, 3차원 공간에서 실제 사용자가 이동을 하였다면 이동한 위치를 중심으로 새로운 구형(spherical)면의 영상이 형성되고 해당 콘텐츠를 소비할 수 있다. 6DoF 오디오도 마찬가지로 실감형 미디어를 경험할 수 있도록 하는 콘텐츠를 제공하기 위한 오디오 콘텐츠로, 음향의 소비하는 위치가 이동함에 따른 공간적(spatial)오디오를 새롭게 형성하고 소비하기 위한 콘텐츠를 의미할 수 있다.
실시예들은 특히 6DoF 비디오를 효과적으로 제공하는 방안을 제안한다. 6DoF 비디오는 서로 다른 위치에서 두 개 이상의 카메라로 캡처 될 수 있다. 캡처된 비디오는 일련의 과정을 거쳐 전송되고, 수신측에서는 수신된 데이터 중 일부를 사용자의 초기 위치를 원점으로 하는 360비디오로 가공하여 렌더링 할 수 있으며 사용자의 위치가 이동하면 이동한 위치를 중심으로 새로운 360 비디오를 가공하여 렌더링 함으로써 6DoF비디오가 사용자에게 제공될 수 있다.
이하에서, 6DoF 비디오 서비스 제공을 위한 송신 방법 및 수신 방법을 설명한다.
도 17은 6DoF 비디오 제공을 위한 전체 아키텍처를 나타낸다.
앞서 정리한 일련의 과정들을 도17을 바탕으로 구체적으로 설명하자면 먼저 획득(Acquisition)단계로 6DoF contents 를 캡처를 위해 HDCA(High Density Camera Array), Lenslet (microlens) camera 등이 사용될 수 있으며, 6DoF 비디오 캡처를 위해 디자인 된 새로운 디바이스로 획득 될 수 있다. 획득된 영상은 Fig.3a와 같이 캡처한 카메라의 위치에 따라 생성된 이미지/비디오 데이터 집합이 여러 개 생성될 수 있다. 이 때 캡처 과정에서 카메라의 내부/외부 설정 값 등의 메타메이타가 생성될 수 있다. 카메라가 아닌 컴퓨터로 생성된 영상의 경우 캡처 과정이 갈음될 수 있다. 획득된 영상의 전처리(pre-processing)과정은 캡처된 이미지/비디오 및 캡처 과정에서 전달된 메타데이타(metadata)를 처리하는 과정일 수 있다. 이 준비 과정에서는 스티칭(Stitching) 과정, 색보정(color correction)과정, 프로젝션 과정, 코딩 효율을 높이기 위해 주요 시점 (primary view)와 부차 시점(secondary view)로 분리 하는 시점 분리(view segmenation)과정 및 인코딩 과정 등 전송 전 콘텐츠를 처리하는 모든 형태의 전처리 단계가 해당될 수 있다.
스티칭 과정은 각 카메라의 위치에서 360 방향으로 캡처된 영상을 각각의 카메라 위치를 중심으로 하는 파노라마 혹은 구형의 형태로 영상을 잇는 이미지/비디오를 만드는 과정일 수 있다. 프로젝션은 각각의 스티칭 결과 영상을 Fig3b와 같이 2D 이미지로 투영 시키는 과정을 의미하며, 2D 이미지로 맵핑한다고 표현할 수 있다. 각 카메라 위치에서 맵핑한 영상은 주요시점과 부차 시점으로 분리 하여 비디오 코딩 효율을 높이기 위해 시점별 다른 해상도(resolution)를 적용할 수 있으며, 주요 시점 내에서도 맵핑 영상의 배치나 해상도(resolution)를 달리 함으로써 코딩 시 효율을 높일 수 있다. 부차 시점은 캡처 환경에 따라 없을 수도 있다. 부차 시점은 주요 시점에서 또 다른 주요 시점으로 사용자가 이동할 경우 이동 과정에서 재생되어야 하는 이미지/비디오를 의미하며 주요 시점에 비해 낮은 해상도를 가질 수도 있으나 필요에 따라 동일한 해상도를 가질 수도 있다. 때에 따라서는 부차 시점은 수신기에서 가상의 정보로 새롭게 생성 될 수 있다.
실시예에 따라 전처리 과정으로 에디팅(editing)과정 등을 더 포함할 수 있다. 이 과정에서 프로젝션 전 후의 이미지/비디오 데이터들에 대한 편집 등이 더 수행될 수 있으며, 전처리 과정에서도 메타메이타가 생성될 수 있다. 또한 이미지/비디오 제공시 가장 처음 재생해야 하는 초기 시점, 사용자의 초기 위치 및 ROI(Region of Interest)등에 관한 메타메이타가 생성될 수 있다.
미디어 전송 단계는 전처리 과정에서 얻어진 이미지/비디오 데이터 및 메타메이타들을 처리하여 전송하는 과정일 수 있다. 전송을 위해 임의의 전송 프로토콜에 따른 처리가 수행될 수 있으며, 전처리 된 데이터들은 방송망 및/또는 브로드밴드를 통해 전달될 수 있으며, 이 데이터들은 온디맨드(on demand) 방식으로 수신측으로 전달될 수 있다.
프로세싱 과정은 수신된 이미지/비디오 데이터 및 메타메이타를 디코딩, 3차원 모델로 맵핑 혹은 프로젝션이라고도 불릴 수 있는 리-프로젝션(re-projection) 하는 과정, 가상 시점의 생성 및 합성 과정 등 이미지/비디오를 재생하기 위한 이미지 생성 전 모든 단계가 프로세싱(processing) 단계에 포함될 수 있다. 맵핑 되는 3차원 모델 혹은 프로젝션 맵은 기존의 360비디오와 같이 구형(sphere), 큐브(cube), 실린더(cylinder), 또는 피라미드(pyramid)가 있을 수 있으며 기존의 360 비디오의 프로젝션 맵의 변형된 형태가 될 수 있으며, 경우에 따라 자유형 형태의 프로젝션 맵이 될 수 있다.
가상 시점의 생성 및 합성 과정은 주요 시점과 부차 시점 사이에 혹은 주요 시점과 주요 시점 사이에 사용자가 이동할 경우 재생되어야 하는 이미지/비디오 데이터를 생성하고 합성하는 과정을 의미할 수 있다. 가상 시점 생성을 위해 캡쳐 및 전처리 과정에서 전달된 메타메이타를 처리하는 과정이 필요할 수 있고, 경우에 따라서는 가상 시점에서 360 이미지/비디오 전체가 아닌 일부만 생성/합성할 수도 있다.
실시예에 따라 프로세싱 과정은 부가적으로 에디팅(editing)과정, 업스케일링(up scaling), 다운 스케일링(down scaling) 과정 등이 더 포함될 수도 있다. 에디팅 과정에서 프로세싱 과정 후에 재생 전 필요한 추가 편집 과정이 적용될 수 있다. 필요에 따라서는 전송 받은 이미지/비디오를 업스케일링 혹은 다운 스케일링 하는 작업이 수행될 수도 있다.
렌더링 과정은 전송 혹은 생성되어 리프로젝션 된 이미지/비디오를 디스플레이 할 수 있도록 렌더링 하는 과정을 의미할 수 있다. 때에 따라서는 렌더링과 리프로젝션 과정을 렌더링이라고 통칭하기도 한다. 따라서 렌더링 과정 중에 리프로젝션 과정이 포함될 수 있다. 리프로젝션은 fig.3c와 같은 형태로 사용자 중심의 360 비디오/이미지와 사용자가 이동 방향에 따라 각 이동한 위치를 중심으로 형성되는 360 비디오/이미지가 형성되는 형태로 다수의 리프로젝션 결과물이 있을 수 있다. 사용자는 디스플레이 할 디바이스에 따라 360 비디오/이미지의 일부 영역을 볼 수 있으며, 이 때 사용자가 보게 되는 영역은 fig.3d와 같은 형태가 될 수 있으며, 사용자가 이동하는 경우 전체 360 비디오/이미지가 렌더링 되는 것이 아니라 사용자가 보고 있는 위치에 해당되는 영상만 렌더링 될 수 있다. 또한 사용자의 위치와 이동 방향에 관한 메타메이타를 전달 받아 미리 움직임을 예측하고 이동할 위치의 비디오/이미지를 추가로 렌더링할 수 있다.
피드백 과정은 디스플레이 과정에서 획득될 수 있는 다양한 피드백 정보들을 송신 측으로 전달하는 과정을 의미할 수 있다. 피드백 과정을 통해 6DoF콘텐츠와 사용자간의 인터렉티비티 (interactivity)가 일어날 수 있으며, 실시예에 따라 피드백 과정에서 사용자의 머리와 포지션 위치 정보 (head/position orientation) 및 사용자가 현재 보고 있는 영역(viewport)에 대한 정보 등이 전달 될 수도 있다. 해당 정보는 피드백 과정에서 송신측 혹은 서비스 제공자 측에 전달 될 수 있으며, 실시예에 따라 피드백 과정은 수행되지 않을 수도 있다.
사용자의 위치 정보는 사용자의 머리 위치, 각도, 움직임 및 이동 거리 등에 대한 정보를 의미할 수 있으며, 해당 정보를 바탕으로 사용자가 보고 있는 위치(viewport) 정보가 계산 될 수 있다.
도18은 6DoF 비디오 서비스 제공을 위한 전송 장치의 구성을 나타낸다.
송신측에서의 실시예들은 6DoF 비디오 전송 장치와 관련 될 수 있다. 실시예들에 따른 6DoF 비디오 전송 장치는 전술한 준비 과정 및 동작들을 수행할 수 있다. 실시예들에 따른 6DoF 비디오/이미지 전송 장치는 데이터 입력부, 깊이 정보 처리부 (도시되지 않음), 스티처(Stitcher), 프로젝션 처리부, 시점 분리 처리부, 시점별 패킹 처리부, 메타메이타 처리부, 피드백 처리부, 데이터 인코더, 인캡슐레이션 처리부, 전송 처리부 및/또는 전송부를 내/외부 구성 요소로 포함할 수 있다.
데이터 입력부는 한 군데 이상의 위치에서 한 개 이상의 카메라로 캡쳐된 각 시점별 이미지/비디오/깊이정보/오디오 데이터를 입력 받을 수 있다. 데이터 입력부는 캡처 과정에서 발생된 메타메이타를 비디오/이미지/깊이정보/오디오 데이터와 함께 입력 받을 수 있다. 데이터 입력부는 입력된 각 시점별 비디오/이미지 데이터를 스티처로 전달하고, 캡쳐 과정에서 발생된 메타메이타를 메타메이타 처리부로 전달 할 수 있다.
스티처는 캡쳐된 시점별/위치별 이미지/비디오들에 대한 스티칭 작업을 수행할 수 있다. 스티처는 스티칭된 360 비디오 데이터를 프로젝션 처리부로 전달할 수 있다. 스티처는 필요한 경우 메타메이타 처리부로부터 전달받아 스티칭을 할 수 있다. 스티처는 스티칭 과정에서 발생한 메타메이타를 메타메이타 처리부로 전달 할 수 있다. 스티처는 깊이(depth)정보 처리부 (도식되지 않음) 에서 전달 받은 위치값을 활용하여 비디오/이미지 스티칭 위치를 다르게 할 수 있다. 스티처는 스티칭 과정에서 발생된 메타메이타를 처리부로 전달할 수 있다. 전달 되는 메타메이타는 스티칭 수행 여부, 스티칭 타입, 주요 시점(primary view)과 부차 시점(secondary view)의 ID 및 해당 시점의 위치 정보 등이 있을 수 있다.
프로젝션 처리부는 스티칭된 6DoF 비디오 데이터를 2D 이미지 프레임에 프로젝션할 수 있다. 프로젝션 처리부는 스킴(scheme)에 따라 다른 형태의 결과물을 얻을 수 있는데, 해당 스킴은 기존의 360비디오의 프로젝션 스킴과 유사할 수도 있고, 6DoF를 위해 새롭게 제안된 스킴이 적용 될수도 있다. 또한 각 시점별 서로 다른 스킴을 적용할 수 있다. 깊이 정보 처리부는 깊이 정보를 프로젝션 처리부로 전달하여 맵핑 결과 값을 다르게 할 수 있다. 프로젝션 처리부는 필요한 경우 메타메이타 처리부로부터 프로젝션에 필요한 메타메이타를 전달받아 프로젝션 작업에 이용할 수 있으며, 프로젝션 처리부는 프로젝션 과정에서 발생된 메타메이타를 메타메이타 처리부로 전달 할 수 있다. 해당 메타메이타는 스킴의 종류, 프로젝션 수행 여부, 주요시점과 부차 시점의 프로젝션 후의 2D 프레임의 ID 및 시점별 위치 정보 등이 있을 수 있다.
시점별 패킹 처리부는 전술한 바와 같이 주요 시점과 부차 시점으로 나누고, 각 시점 내 리전별 패킹 과정을 수행할 수 있다. 즉 시점별 패킹 처리부는 각 시점/위치별 프로젝션된 6DoF 비디오 데이터를 주요 시점과 부차 시점으로 분류하여 코딩 효율을 높이기 위해 주요 시점과 부차 시점을 다른 해상도를 가질 수 있도록 하거나 각 시점의 비디오 데이터를 회전, 재배열 달리하고 각 시점 안에서 나누어진 리전별 해상도를 다르게 할 수도 있다. 주요 시점과 부차 시점을 분류하는 과정은 생략될 수 있으며, 선택적인 과정일 수 있으며, 리전별 다른 해상도를 가지거나 배치를 다르게 하는 것도 선택적으로 수행될 수 있다. 시점별 패킹 처리부가 수행될 경우에 패킹은 메타메이타 처리부로부터 전달 받은 정보를 활용하여 수행 될 수 있으며, 패킹 과정에서 발생한 메타메이타를 메타메이타 처리부로 전달 할 수도 있다. 시점별 패킹 처리 과정에서 정의되는 메타메이타는 주요 시점과 부차 시점을 분류하기 위한 각 시점의 ID와 시점 내 리전별 적용되는 사이즈, 회전 각 리전별 위치 값 등이 될 수 있다.
전술한 스티처, 프로젝션 처리부 및/또는 시점별 패킹 처리부는 실시예에 따라 하나 이상의 하드웨어 컴포넌트 혹은 스트리밍/다운로드 서비스 내의 인제스트 서버(Ingest server)에서 일어날 수도 있다.
메타메이타 처리부는 캡쳐 과정, 스티칭 과정, 프로젝션 과정, 시점별 패킹 과정, 인코딩 과정, 인캡슐레이션 과정 및/또는 전송을 위한 처리 과정에서 발생할 수 있는 메타메이타들을 처리할 수 있다. 메타메이타 처리부는 각 프로세스에서 전달 받은 메타메이타를 활용하여 6DOF 비디오 서비스를 위한 새로운 메타메이타를 생성할 수 있다. 실시예에 따라 메타메이타 처리부는 새롭게 생성된 메타메이타를 시그널링 테이블의 형태로 생성할 수도 있다. 메타메이타 처리부는 전달받거나 메타메이타 처리부에서 새롭게 생성/가공된 메타메이타를 다른 요소들에 전달 할 수 있다. 메타메이타 처리부는 생성되거나 전달 받은 메타메이타를 수신측으로 전송될 수 있도록 데이터 인코더, 인캡슐레이션 처리부 및/또는 전송 처리부에 전달 할 수 있다.
데이터 인코더는 2D 이미지 프레임 상에 프로젝션 된 6DoF 비디오 데이터 및/또는 시점별/리전별 패킹된 비디오 데이터를 인코딩 할 수 있다. 인코딩은 다양한 포맷으로 수행 될 수 있으며, 시점별 분류가 되었다면, 시점별 인코딩 결과 값을 분리하여 전달 할 수도 있다.
인캡슐레이션 처리부는 인코딩된 6DoF 비디오 데이터 및/또는 관련 메타메이타를 파일 등의 형태로 인캡슐레이션 할 수 있다. 관련 메타메이타는 전술한 메타메이타 처리부로부터 전달 받을 수 있다. 인캡슐레이션 처리부는 해당 데이터를 ISOBMFF, OMAF 등의 파일 포맷으로 인캡슐레이션 하거나 DASH 세그먼트 등의 형태로 처리할 수 있으며, 새로운 형태의 파일 포맷으로 처리될 수도 있다. 메타메이타는 파일 포맷 내 다양한 레벨에 존재하는 박스(box)에 포함되거나 별로의 트랙내의 데이터로 포함하거나 메타메이타만 파일로 인캡슐레이션 할 수 있다. 시점별 별도의 인캡슐레이션 처리가 가능할 수도 있고, 시점별 필요한 메타메이타와 해당 비디오 정보를 함께 인캡슐레이션 할 수도 있다.
전송 처리부는 포맷에 따라 인캡슐레이션된 비디오 데이터에 전송을 위한 추가 처리를 가할 수 있다. 해당 처리는 메타메이타 처리부에서 전달 받은 메타메이타를 활용하여 작동할 수 있다. 전송부는 전송 처리부로부터 전달 받은 데이터 및/또는 메타메이타를 방송망 및/또는 브로드밴드를 통해 전송될 수 있다. 전송부는 방송망및/또는 브로드밴드를 통한 전송 시 필요한 구성 요소가 포함될 수 있다.
피드백 처리부(송신측)는 및/또는 네트워크 인터페이스(도시되지 않음)를 추가로 더 포함할 수 있다. 네트워크 인터페이스는 실시예들에서 후술 되는 수신 장치로부터 피드백 정보를 전달 받고 피드백 처리부(송신측) 으로 전달 할 수 있다. 피드백 처리부는 수신측에서 전달받은 정보를 스티칭, 프로젝션, 시점별 패킹, 인코터, 인캡슐레이션 처리부 및/또는 전송 처리부로 전달 할 수 있으며, 메타메이타 처리부로 전달하여 메타메이타 처리부가 다른 요소들에 전달하거나 메타메이타 처리부에서 새로운 메타메이타를 생성/가공하여 전달 할 수 있다. 실시예들의 또 다른 실시예에 따르면 피드백 처리부가 네트워크 인터페이스로부터 전달 받은 위치/시점 정보를 메타메이타 처리부로 전달하며, 메타메이타 처리부는 프로젝션, 시점별 패킹 처리부, 인캡슐레이션 처리부 및/또는 데이터 인코더로 해당 위치/시점 정보를 전달하여 현재 사용자의 시점/위치에 맞는 정보와 주변 정보만을 전송하여 코딩 효율을 높일 수 있다.
전술한 6DoF비디오 전송 장치의 구성 요소들은 하드웨어로 구현되는 하드웨어 구성 요소 일 수 있다. 실시예에 따라 각 구성요소들은 변경, 생략 되거나 새로운 구성요소를 추가 혹은 다른 구성요소로 대체, 통합될 수 있다.
도19는 6DoF 비디오 수신 장치의 구성을 나타낸다.
실시예들은 수신 장치와 관련될 수 있다. 실시예들에 따르면 6DoF 비디오 수신 장치는 수신부, 수신 처리부, 디캡슐레이션 처리부, 메타메이타 파서, 피드백 처리부, 데이터 디코더, 리-프로젝션 처리부, 가상시점 생성/합성부 및/또는 렌더러를 구성요소로 가질 수 있다.
수신부는 전술한 6DoF송신 장치로부터 비디오 데이터를 수신할 수 있다. 비디오 데이터가 전송되는 채널에 따라 수신부는 방송망 또는 브로드밴드를 통해 수신할 수도 있다.
수신 처리부는 수신된 6DoF 비디오 데이터에 대해 전송 프로토콜에 따른 처리를 수행할 수 있다. 수신 처리부는 전송 처리부에서 수행된 과정의 역순으로 수행하거나 프로토콜 처리 방법에 따른 과정을 거쳐 전송 처리부 이전 단계에서 얻은 데이터를 획득한다. 수신 처리부는 획득한 데이터를 디캡슐레이션 처리부로 전달하고, 수신부로 부터 받은 메타메이타 정보를 메타메이타 파서로 전달할 수 있다.
디캡슐레이션 처리부는 수신 처리부로부터 전달받은 파일 형태의 6DoF 비디오 데이터를 디캡슐레이션할 수 있다. 디캡슐레이션 처리부는 해당 파일 포맷에 맞추어 파일들을 디캡슐레이션하여, 6DoF 비디오 및/또는 메타메이타를 획득할 수 있다. 획득된 6DoF 비디오 데이터는 데이터 디코더로 보낼 수 있고, 6DoF 메타메이타는 메타메이타 파서로 전달할 수 있다. 디캡슐레이션 처리부는 필요에 따라 메타메이타 파서로부터 디캡슐레이션에 필요한 메타메이타를 전달받을 수도 있다.
데이터 디코더는 6DoF 비디오 데이터에 대한 디코딩을 수행할 수 있다. 데이터 디코더는 메타메이타 파서로부터 디코딩에 필요한 메타메이타를 전달 받을 수 있다. 데이터 디코딩 과정에서 획득 된 메타메이타는 메타메이타 파서로 전달되어 처리될 수 있다.
메타메이타 파서는 6DoF 비디오 관련 메타메이타에 대한 파싱/디코딩을 수행할 수 있다. 메타메이타 파서는 획득한 메타메이타를 디캡슐레이션 처리부, 데이터 디코더, 리-프로젝션 처리부, 가상 시점 생성/합성부 및/또는 렌더러로 전달 할 수도 있다.
리-프로젝션 처리부는 디코딩된 6DoF 비디오 데이터에 대하여 리-프로젝션을 수행할 수 있다. 리-프로젝션 처리부는 각 시점/위치별 6DoF 데이터를 각각 3차원 공간으로 리-프로젝션할 수 있다. 3차원 공간은 사용되는 3차원 모델에 따라 다른 형태를 가질 수도 있고, 변환 과정을 거처 동일한 형태의 3차원 모델로 리-프로젝션 될 수도있다. 리-프로젝션 처리부는 메타메이타 파서로부터 필요한 메타메이타를 전달 받을 수 있다. 리-프로젝션 과정에서 정의된 메타메이타를 메타메이타 파서로 전달할 수도 있다. 예를 들어 각 시점/위치 별 6DoF 비디오 데이터의 3차원 모델을 메타메이타 파서로 전달 받을 수 있고, 각 시점/위치별 비디오 데이터의 3차원 모델이 다르고 모든 시점의 비디오 데이터를 동일한 3차원 모델로 리-프로젝션 되었을 경우 어떤 모델이 적용 되었는지 메타메이타 파서로 전달할 수 있다. 때에 따라서는 리-프로젝션에 필요한 메타메이타를 이용하여, 3차원 공간 내에 특정 영역만 리-프로젝션 할 수 있으며, 한 개 이상의 특정 영역을 리-프로젝션 할 수도 있다.
가상 시점 생성/합성부는 전송되어 리-프로젝션 된 3차원 공간상에서 수신된 6DoF 비디오 데이터에 포함되어 있지 않으나 재생이 필요한 가상의 시점 영역에서 비디오 데이터를 주어진 데이터를 활용하여 생성하고, 가상 시점을 중심으로 새로운 시점/위치에서의 비디오 데이터를 합성하는 과정을 수행할 수 있다. 새로운 시점의 비디오 데이터를 생성할 때 깊이(depth)정보 처리부 (도시하지 않음)의 데이터를 활용할 수 있다. 가상 시점 생성/합성부는 메타메이타 파서로부터 전달 받은 특정 영역과 수신 되지 않은 주변 가상 시점 영역의 일부만 생성/합성 할 수 있다. 가상 시점 생성/합성부는 선택적으로 수행될 수 있으며, 필요한 시점 및 위치에 해당하는 비디오 정보가 없을 때 수행된다.
렌더러는 리-프로젝션 혹은 가상 시점 생성/합성부에서 전달된 6DoF 비디오 데이터를 렌더링 할 수 있다. 전술 한 바와 같이 3차원 공간상에서 리-프로젝션 혹은 가상 시점 생성/합성부에서 일어나는 모든 과정은 렌더러와 통합되어 렌더러 내에서 이 과정들이 진행될 수 있다. 실시예에 따라 사용자의 시점/위치 정보에 따라 사용자가 보고 있는 부분 및 예상 경로 상의 일부만 렌더링 할 수도 있다.
실시예들에서 피드백 처리부(수신측) 및/또는 네트워크 인터페이스(도시되지 않음)을 추가적인 구성요소로 포함할 수 있다. 수신측 피드백 처리부는 렌더러, 가상 시점 생성/합성부, 리-프로젝션 처리부, 데이터 디코더, 디캡슐레이션 및/또는 VR 디스플레이로부터 피드백 정보를 획득하여 처리할 수 있다. 피드백 정보는 사용자의 뷰포트 정보, 헤드 및 포지션 오리엔테이션 정보, 게이즈(gaze) 정보, 제스처(gesture) 정보 등을 포함할 수 있다. 네트워크 인터페이스는 피드백 정보를 피드백 처리부로부터 전달 받고, 전송 장치로 전송할 수 있으며, 수신측의 각 구성요소에서 소비될 수도 있다. 예를 들면, 디캡슐레이션 처리부에서는 피드백 처리부로 부터 사용자의 위치/시점 정보를 전달 받아 수신된 6DoF 비디오 중에 해당 위치의 정보가 있을 경우 해당 위치 정보만 디캡슐레이션, 디코딩, 리-프로젝션, 렌더링을 할 수 있다. 만약 해당 위치의 정보가 없을 경우 해당 위치 주변에 위치한 6DoF 비디오를 모두 디캡슐레이션, 디코딩, 리-프로젝션, 가상 시점 생성/합성, 렌더링의 과정을 거칠 수 있도록 할 수 있다.
전술한 6DoF비디오 수신 장치의 구성 요소들은 하드웨어로 구현되는 하드웨어 구성 요소 일 수 있다. 실시예에 따라 각 구성요소들은 변경, 생략 되거나 새로운 구성요소를 추가 혹은 다른 구성요소로 대체, 통합될 수 있다.
도20은 6 DoF 비디오 전송/수신 장치의 구성을 나타낸다.
6DoF 콘텐츠는 파일 형태로 제공되거나 DASH 등과 같이 세그먼트(segment) 기반 다운로드 또는 스트리밍 서비스의 형태로 제공될 수 있으며, 새로운 파일 포맷 혹은 스트리밍/다운로드 서비스 방법이 대신 쓰일 수도 있다. 여기서 6DoF 콘텐츠는 실감미디어(immersive media) 콘텐츠 혹은 라이트필드(light field) 콘텐츠, 혹은 포인트 클라우드(point cloud) 콘텐츠로 불릴 수 있다.
전술한 바와 같이 해당 파일 제공 및 스트리밍/다운로드 서비스를 위한 각 과정은 아래와 같이 상세하게 설명될 수 있다.
Acquisition : multi view/stereo/depth image를 획득하기 위한 camera 로 부터 capture 후 얻어지는 output 이며, 2개 이상의 video/image및 오디오 데이터가 얻어지게 되고, depth camera가 있는 경우 각 scene에서의 depth map도 획득(acquisition) 될 수 있다.
Audio Encoding : 6DoF 오디오 데이터는 오디오 전처리 과정, 인코딩 과정을 거칠 수 있다. 이 과정에서 메타메이타가 생성될 수 있으며, 관련 메타메이타는 전송을 위해 인캡슐레이션/인코딩 과정을 거칠 수 있다.
Stitching, Projection, mapping, and correction : 6DoF 비디오 데이터는 전술한 바와 같이 다양한 위치에서 획득된 영상의 에디팅, 스티칭, 프로젝션 과정을 거칠 수 있다. 이 과정은 실시예에 따라 일부만 수행되기도 하고, 전체가 생략되어 수신기측에서 수행 될 수도 있다.
View segmentation/packing : 전술한 바와 같이 시점 분리/패킹 처리부는 스티칭 된 영상을 바탕으로 수신기 측에서 요구 되는 주요 시점,Primary View(PV) 위치의 영상을 분리해 내어 패킹 하고, 주요 시점으로 분리되어 패킹 된 후 나머지 영상을 부차 시점, Secondary View(SV)로 패킹하는 전처리 과정을 거칠 수 있다. 패킹하는 과정에서 코딩 효율을 높이기 위해 주요 시점과 부차 시점의 사이즈, 해상도 등이 조정될 수 있다. 동일한 성격의 시점 내에서도 리전별 다른 조건으로 해상도를 가지거나 리전에 따라 회전, 재배치 될 수 있다.
Depth sensing and/or estimation: 깊이 캡처 카메라 (depth camera)가 존재하지 않는 경우 획득된 2개 이상의 영상에서 깊이 맵을 추출해 내는 과정을 수행하기 위함이며 깊이 캡처 카메라 (depth camera)가 있는 경우 영상 획득 위치에서 영상 내 포함된 각 오브젝트(object)의 깊이가 얼만큼 되는지 위치 정보를 저장하기 위한 과정을 수행할 수 있다.
Point Cloud Fusion/extraction 미리 획득 된 깊이 맵을 인코딩 가능한 형태의 데이터로 변형하는 과정을 수행할 수 있다. 예를 들어 포인트 클라우드 데이터 타입으로 변형하여 3차원에서 영상의 각 오브젝트의 위치 값을 할당하는 전처리 과정을 수행할 수 있으며, 포인터 클라우드 데이터 타입이 아닌 3차원 공간 정보를 표현할 수 있는 데이터 타입이 대신 적용될 수 있다.
PV encoding/SV encoding/light field/point cloud encoding : 시점별로 미리 패킹되거나 깊이 정보 및/또는 위치 정보는 각각 이미지 인코딩 내지 비디오 인코딩 될 수 있다. 동일한 시점의 같은 콘텐츠라도 리전별로 다른 비트 스트림으로 인코딩될 수도 있다. MPEG-I에서 정의될 새로운 codec 및 HEVC-3D, OMAF++ 등 media format이 될 수 있다.
File encapsulation : 전술한 대로 인코딩된 6DoF 비디오 데이터는 인캡슐레이션 처리부인 File-encapsulation에 의해 ISOBMFF 등의 파일 포맷으로 처리될 수 있다. 또는 인코딩 된 6DoF 비디오 데이터는 세그먼트들로 처리할 수 있다.
Metadata(including depth information) : 6DoF 비디오 데이터 처리와 같이 획득, 스티칭, 프로젝션, 시점별 분리/패킹, 인코딩, 인캡슐레이션 과정중에 발생한 메타메이타를 메타메이타 처리부로 전달하거나 메타메이타 처리부에서 생성된 메타메이타를 각 과정으로 전달 할 수 있다. 또한 송신측에서 생성된 메타메이타는 인캡슐레이션 과정에서 하나의 트랙 혹은 파일로 생성하여 수신측으로 전달 할 수 있다. 수신측에서는 방송망이나 브로드밴드를 통해 별도의 파일 혹은 파일 내 트랙으로 저장되어 있는 메타메이타를 수신할 수 있다.
Delivery : 파일 및/또는 세그먼트들은 DASH 혹은 유사한 기능을 가진 새로운 모델을 기반으로 전송을 위한 개별 트랙에 포함될 수 있다. 이때 전송을 위해 MPEG DASH, MMT및/또는 새로운 표준이 적용될 수 있다.
File decapsulation : 수신 장치는 6DoF 비디오/오디오 데이터 수신을 위한 처리를 수행할 수 있다.
Audio deconding/Audio rendering/Loudspeakers/headphones : 6DoF 오디오 데이터는 오디오 디코딩, 렌더링 과정을 거쳐 스피커, 헤드폰을 통해 사용자에게 제공될 수 있다.
PV/SV/light field/point cloud decoding : 6DoF 비디오 데이터는 이미지 내지 비디오 디코딩 할 수 있다. 디코딩에 적용되는 코덱은 HEVC-3D, OMAF++ 및 MPEG에서 6DoF를 위해 새롭게 제안되는 코덱이 적용될 수 있다. 이 때 주요 시점(PV)와 부차 시점(SV)이 분리되어 각 시점 패킹 내에서 비디오 내지 이미지가 각각 디코딩 될 수 있고, 시점 분류와 상관없이 비디오 내지 이미지 디코딩이 될 수 있다. 또한 위치, 깊이 정보를 가지고 있는 라이트필드와 포인트 클라우드 디코딩이 먼저 이루어지고나서 헤드, 포지션, 시선 트래킹의 피드백을 먼저 전달하고 사용자가 위치한 주변부 시점의 이미지 내지 비디오만 분리해 내어 디코딩 될 수도 있다.
Head/eye/position tracking : 전술한 바와 같이 사용자의 헤드, 포지션, 게이즈, 뷰포트 정보 등을 획득, 처리할 수 있다.
Point Cloud rendering : 캡쳐한 비디오/이미지 데이터를 3차원 공간상에 리-프로젝션 할 때 3차원의 공간 위치를 설정하고, 수신한 비디오/이미지 데이터에서 확보하지 못하였으나 사용자가 이동 가능한 위치인 가상 시점의 3차원 공간을 생성하는 과정을 수행한다.
Virtual view synthesis : 전술한 바와 같이 사용자가 위치한 공간에 6DoF 비디오 데이터가 없을 경우 사용자 위치/시점 주변에 이미 확보된 6DoF 비디오 데이터를 활용하여 새로운 시점의 비디오 데이터를 생성하고 합성하는 과정을 수행한다. 실시예에 따라 가상 시점 생성 및/또는 합성 과정은 생략될 수 있다.
Image composition, and rendering : 전술한 바와 같이 사용자의 위치를 중심으로 한 영상을 렌더링 하기 위한 과정으로 사용자의 위치 및 시선에 따라 디코딩 된 비디오 데이터를 이용하거나 가상 시점 생성/합성으로 만들어진 사용자 주변의 비디오 및 이미지를 렌더링 할 수 있다.
도21은 6DoF 공간을 나타낸다.
실시예들에서 프로젝션 전 또는 리-프로젝션 후의 6DoF 공간에 대해 기술하고 그에 대한 시그널링을 수행하기 위하여 도 21과 같은 개념을 사용할 수 있다.
6DoF 공간은 360비디오 혹은 3DoF 공간이 야(Yaw), 피치(Pitch), 롤(Roll)로 설명할 수 있는 것과 달리 이동의 방향을 레이셔널(rational)과 트렌스레이션(translation) 두 종류로 나뉠 수 있다. 레이셔널 이동은 a와 같이 기존의 3DoF 의 방향을 설명한 것과 마찬가지로 야, 피치, 롤 로 설명할 수 있으며 방향의 이동(orientation movement)으로 불릴 수도 있다. 반면 트렌스레이션 이동의 경우는 b와 같이 포지션의 이동으로 불릴 수 있다. 왼쪽/오른쪽(Left/Right), 앞/뒤(Forward/Backward), 위/아래(Up/down) 방향 중 축이 어디로 이동했는지 알려 줄 수 있는 것으로 한 축 이상의 값을 정의하여 중심축의 이동을 설명할 수 있다.
실시예들의 특징은 6DoF 비디오 서비스 및 스트리밍을 위한 아키텍쳐를 제안하고 시그널링 및 파일 저장 방법의 기본 메타데이터를 제안하여 향후 6DoF 관련 메타데이터 및 시그널링 확장을 위한 발명에 활용될 수 있다.
- 제안한 6DoF 송,수신기 아키텍처를 바탕으로 각 과정마다 발생하는 메타데이터를 확장할 수 있다.
- 제안한 아키텍처의 과정간에 발생하는 메타데이터를 제안할 수 있다.
- 제안한 메타데이터를 바탕으로 추후 추가/수정/확장하여 6DoF 비디오 서비스를 제공하는 콘텐츠의 6DoF 비디오 관련 파라미터를 ISOBMFF 등 파일에 저장 및 시그널링 할 수 있다.
- 제안한 메타데이터를 바탕으로 추후 추가/수정/확장하여 6DoF 비디오 스트림의 SEI 혹은 VUI를 통해 6DoF 비디오 메타데이터 저장 및 시그널링을 할 수 있다.
리전(리전별 패킹에서의 의미, Region) : 리전(Region) 은 2D 이미지에 프로젝션된 360 비디오 데이터가 리전별 패킹(region-wise packing) 을 통해 팩드 프레임 내에서 위치하게 되는 영역을 의미할 수 있다. 여기서의 리전은 문맥에 따라 리전별 패킹에서 사용되는 리전을 의미할 수 있다. 전술한 바와 같이 리전들을 2D 이미지를 균등하게 나누어 구분되거나, 프로젝션 스킴 등에 따라 임의로 나누어져 구분될 수도 있다.
리전(일반적 의미, region) : 전술한 리전별 패킹에서의 리전과 달리, 사전적 의미로서 리전(region) 이라는 용어가 사용될 수도 있다. 이 경우 리전이란 사전적 의미인 '영역', '구역', '일부분' 등의 의미를 가질 수 있다. 예를 들어 후술할 페이스(face) 의 일 영역을 의미할 때, '해당 페이스의 한 리전' 등과 같은 표현이 사용될 수 있다. 이 경우 리전은 전술한 리전별 패킹에서의 리전과는 구분되는 의미로서, 양자는 서로 무관한, 다른 영역을 지시할 수 있다.
픽쳐 : 픽쳐는 360 비디오 데이터가 프로젝션된 2D 이미지 전체를 의미할 수 있다. 실시예에 따라 프로젝티드 프레임 내지는 팩드 프레임이 픽쳐가 될 수 있다.
서브-픽쳐 : 서브 픽쳐는 전술한 픽쳐의 일부분을 의미할 수 있다. 예를 들어 타일링 등을 수행하기 위해 픽쳐가 여러 서브-픽쳐로 나누어질 수 있다. 이 때 각 서브 픽쳐가 타일이 될 수 있다. 구체적으로, 타일 내지 MCTS 를 기존의 HEVC 와 호환되는 픽쳐 형태로 재구성하는 동작을 MCTS 추출(extraction) 이라고 할 수 있다. 이 MCTS 추출의 결과물은 원래의 타일 내지 MCTS 가 속하는 픽쳐의 서브-픽쳐일 수 있다.
타일 : 서브 픽처의 하위 개념으로서, 서브 픽처가 타일링을 위한 타일로 쓰일 수 있다. 즉, 타일링에 있어서는 서브 픽처와 타일은 동일한 개념일 수 있다. 구체적으로, 본디 타일은 병렬 디코딩을 가능케 하기 위한 툴이나, VR 에 있어서는 독립 디코딩을 위한 툴일 수 있다. VR 에 있어서 타일은, 템포럴 인터 프리딕션(temporal inter prediction) 의 범위를 현재의 타일 내부 범위로 제한한 MCTS (Motion Constrained Tile Set) 을 의미할 수 있다. 이에 이 문서에서 타일은 MCTS 로도 불릴 수 있다.
슈페리컬 리전(Spherical region) : 슈페리컬 리전 내지 슈피어 리전(Sphere region) 은, 360 비디오 데이터가 수신측에서 3D 공간(예를 들어 구면) 상에 렌더링될 때, 그 구면 상의 일 영역을 의미할 수 있다. 여기서 슈페리컬 리전은, 리전별 패킹에서의 리전과는 무관하다. 즉, 슈페리컬 리전이 리전별 패킹에서 정의되었던 리전과 같은 영역을 의미할 필요는 없다. 슈페리컬 리전은 렌더링되는 구면 상의 일 부분을 의미하는 데 사용되는 용어로서, 여기서의 '리전' 은 사전적 의미로서의 '영역'을 뜻할 수 있다. 문맥에 따라 슈페리컬 리전이 단순히 리전이라고 불릴 수도 있다.
페이스(face) : 페이스는 프로젝션 스킴에 따라 각 면을 부르는 용어일 수 있다. 예를 들어 큐브맵 프로젝션이 사용되는 경우, 앞면, 뒷면, 양 옆면, 윗면, 아랫면 등은 페이스라고 불릴 수 있다.
도22는 실시예들에 따른 Point Cloud Compression 처리 일반을 나타낸다.
실시예들에 따른 Point Cloud 콘텐츠 제공을 위한 장치가 도면과 같을 수 있다.
실시예들에서는 사용자에게 VR (Virtual Reality, 가상현실), AR (Augmented Reality, 증강현실), MR (Mixed Reality, 혼합현실), 및 자율 주행 서비스 등의 다양한 서비스를 제공하기 위하여 Point Cloud 콘텐츠를 제공하는 방안을 제공한다.
Point Cloud 콘텐츠 서비스를 제공하기 위하여, 먼저 Point Cloud 비디오가 획득될 수 있다. 획득된 Point Cloud 비디오는 일련의 과정을 거쳐 전송되고, 수신측에서는 수신된 데이터를 다시 원래의 Point Cloud 비디오로 가공하여 렌더링 할 수 있다. 이를 통해 Point Cloud 비디오가 사용자에게 제공될 수 있다. 실시예들은 이러한 일련의 과정을 효과적으로 수행하기 위해 필요한 방안을 제공한다.
Point Cloud 콘텐츠 서비스를 제공하기 위한 전체의 과정은 획득 과정, 인코딩 과정, 전송 과정, 디코딩 과정, 렌더링 과정 및/또는 피드백 과정을 포함할 수 있다.
Point Cloud Compression 시스템은 전송 디바이스 및 수신 디바이스를 포함할 수 있다. 전송 디바이스는 Point Cloud 비디오를 인코딩하여 비트스트림을 출력할 수 있으며, 이를 파일 또는 스트리밍 (스트리밍 세그먼트) 형태로 디지털 저장매체 또는 네트워크를 통하여 수신 디바이스로 전달할 수 있다. 디지털 저장 매체는 USB, SD, CD, DVD, 블루레이, HDD, SSD 등 다양한 저장 매체를 포함할 수 있다.
상기 전송 디바이스는 개략적으로 Point Cloud 비디오 획득부, Point Cloud 비디오 인코더, 전송부를 포함할 수 있다. 상기 수신 디바이스는 개략적으로 수신부, Point Cloud 비디오 디코더 및 렌더러를 포함할 수 있다. 상기 인코더는 Point Cloud 비디오/영상/픽처/프레임 인코딩 장치라고 불릴 수 있고, 상기 디코더는 Point Cloud 비디오/영상/픽처/프레임 디코딩 장치라고 불릴 수 있다. 송신기는 Point Cloud 비디오 인코더에 포함될 수 있다. 수신기는 Point Cloud 비디오 디코더에 포함될 수 있다. 렌더러는 디스플레이부를 포함할 수도 있고, 렌더러 및/또는 디스플레이부는 별개의 디바이스 또는 외부 컴포넌트로 구성될 수도 있다. 상기 전송 디바이스 및 상기 수신 디바이스는 피드백 과정을 위한 별도의 내부 또는 외부의 모듈/유닛/컴포넌트를 더 포함할 수도 있다.
Point Cloud 비디오 획득부는 Point Cloud 비디오의 캡처, 합성 또는 생성 과정 등을 통한 Point Cloud 비디오를 획득하는 과정을 수행할 수 있다. 획득 과정에 의해 다수의 Point들에 대한 3D 위치(x, y, z)/속성 (color, reflectance, transparency 등) 데이터, 예를 들어, PLY(Polygon File format or the Stanford Triangle format) 파일 등이 생성 될 수 있다. 여러 개의 프레임을 갖는 비디오의 경우 하나 이상의 파일들이 획득될 수 있다. 캡처 과정에서 point cloud 관련 메타데이터(예를 들어 캡처와 관련된 메타데이터 등)가 생성될 수 있다.
Point Cloud 콘텐츠 캡쳐를 위해서 깊이(depth)를 획득 할 수 있는 카메라 장비(적외선 패턴 프로젝터와 적외선 카메라의 조합)와 깊이 정보에 대응되는 색상 정보를 추출 할 수 있는 RGB 카메라들의 조합으로 구성될 수 있다. 또는 레이저 펄스를 쏘고 반사되어 돌아오는 시간을 측정하여 반사체의 위치 좌표를 측정하는 레이더 시스템을 이용하는 라이다(LiDAR)를 통해 깊이 정보를 추출할 수 있다. 깊이 정보로부터 3차원 공간상의 점들로 구성된 지오메트리(geometry)(위치를 알려줌)의 형태를 추출하고, RGB 정보로부터 각 점의 색상/반사를 표현하는 속성(attribute)을 추출할 수 있다. Point Cloud 콘텐츠는 점들에 대한 위치(x, y, z)와 색상(YCbCr 또는 RGB) 또는 반사율(r) 정보로 구성될 수 있다. Point Cloud 콘텐츠는 외부 환경을 캡쳐하는 아웃워드-페이싱(outward-facing) 방식과, 중심 객체를 캡쳐하는 인워드-페이싱(inward-facing) 방식이 있을 수 있다. VR/AR 환경에서 객체(예-캐릭터, 선수, 물건, 배우 등 핵심이 되는 객체)를 360도로 사용자가 자유롭게 볼 수 있는 Point Cloud 콘텐츠로 구성할 경우, 캡쳐 카메라의 구성은 인워드-페이싱 방식을 사용하게 될 수 있다. 자율 주행과 같이 자동차에서 현재 주변 환경을 Point Cloud 콘텐츠로 구성할 경우, 캡쳐 카메라의 구성은 아웃워드-페이싱 방식을 사용하게 될 수 있다. 여러대의 카메라를 통해 Point Cloud 콘텐츠가 캡쳐 될 수 있기 때문에, 카메라들 사이의 글로벌 공간 좌표계(global coordinate system)를 설정하기 위해 콘텐츠를 캡쳐 하기 전에 카메라의 캘리브레이션 과정이 필요할 수도 있다.
도23은 실시예들에 따른 Point Cloud 캡쳐 장비 배열 구성을 나타낸다.
실시예들에 따른 포인트 클라우드는 인워드-페이싱 방식에 기반하여, 오브젝트의 밖에서 안으로 방향으로의 캡쳐할 수 있다.
실시예들에 따른 포인트 클라우드는 아웃워드-페이싱 방식에 기반하여, 오브젝트의 안에서 밖으로의 방향으로 캡쳐할 수 있다.
Point Cloud 콘텐츠는 다양한 형태의 3D 공간상에 나타내어지는 객체/환경의 비디오 또는 정지 영상일 수 있다.
그 외에 Point Cloud 콘텐츠의 획득 방법은 캡쳐 된 Point Cloud 비디오를 기반으로 임의의 Point Cloud 비디오가 합성 될 수 있다. 또는 컴퓨터로 생성된 가상의 공간에 대한 Point Cloud 비디오를 제공하고자 하는 경우, 실제 카메라를 통한 캡처가 수행되지 않을 수 있다. 이 경우 단순히 관련 데이터가 생성되는 과정으로 해당 캡처 과정이 갈음될 수 있다.
캡쳐된 Point Cloud 비디오는 콘텐츠의 질을 향상시키기 위한 후처리가 필요할 수 있다. 영상 캡쳐 과정에서 카메라 장비가 제공하는 범위에서 최대/최소 깊이 값을 조정할 수 있지만 그 이후에도 원하지 않는 영역의 points 데이터들이 포함될 수 있어서 원하지 않는 영역(예, 배경)을 제거 한다거나, 또는 연결된 공간을 인식하고 구멍(spatial hole)을 메우는 후처리를 수행할 수 있다. 또한 공간 좌표계를 공유하는 카메라들로부터 추출된 Point Cloud는 캘리브레이션 과정을 통해 획득된 각 카메라의 위치 좌표를 기준으로 각 point들에 대한 글로벌 좌표계로의 변환 과정을 통해 하나의 콘텐츠로 통합될 수 있다. 이를 통해 하나의 넓은 범위의 Point Cloud 콘텐츠를 생성할 수도 있고, 또는 point들의 밀도가 높은 Point Cloud 콘텐츠를 획득할 수도 있다.
Point Cloud 비디오 인코더는 입력 Point Cloud 비디오를 하나 이상의 비디오 스트림으로 인코딩할 수 있다. 하나의 비디오는 다수의 프레임을 포함할 수 있으며, 하나의 프레임은 정지 영상/픽처에 대응될 수 있다. 본 문서에서, Point Cloud 비디오라 함은 Point Cloud 영상/프레임/픽처를 포함할 수 있으며, Point Cloud 비디오는 Point Cloud 영상/프레임/픽처와 혼용되어 사용될 수 있다. Point Cloud 비디오 인코더는 Video-based Point Cloud Compression (V-PCC) 절차를 수행할 수 있다. Point Cloud 비디오 인코더는 압축 및 코딩 효율을 위하여 예측, 변환, 양자화, 엔트로피 코딩 등의 일련의 절차를 수행할 수 있다. 인코딩된 데이터(인코딩된 비디오/영상 정보)는 비트스트림(bitstream) 형태로 출력될 수 있다. V-PCC 절차에 기반하는 경우 Point Cloud 비디오 인코더는 Point Cloud 비디오를 후술하는 바와 같이 지오메트리 비디오, 어트리뷰트(attribute) 비디오, 어큐판시(occupancy) 맵 비디오, 그리고 부가 정보(auxiliary information)으로 나누어 인코딩할 수 있다. 상기 지오메트리 비디오는 지오메트리 이미지를 포함할 수 있고, 상기 어트리뷰트(attribute) 비디오는 어트리뷰트 이미지를 포함할 수 있고, 상기 어큐판시(occupancy) 맵 비디오는 어큐판시 맵 이미지를 포함할 수 있다. 상기 부가 정보는 부가 패치 정보(auxiliary patch information)를 포함할 수 있다. 상기 어트리뷰트 비디오/이미지는 텍스쳐 비디오/이미지를 포함할 수 있다.
인캡슐레이션 처리부(file/segment encapsulation module)는 인코딩된 Point cloud 비디오 데이터 및/또는 Point cloud 비디오 관련 메타데이터를 파일 등의 형태로 인캡슐레이션할 수 있다. 여기서 Point cloud 비디오 관련 메타데이터는 메타데이터 처리부 등으로부터 전달받은 것일 수 있다. 메타데이터 처리부는 상기 point cloud 비디오 인코더에 포함될 수도 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 인캡슐레이션 처리부는 해당 데이터들을 ISOBMFF 등의 파일 포맷으로 인캡슐레이션하거나, 기타 DASH 세그먼트 등의 형태로 처리할 수 있다. 인캡슐레이션 처리부는 실시예에 따라 Point cloud 비디오 관련 메타데이터를 파일 포맷 상에 포함시킬 수 있다. Point cloud 비디오 메타데이터는 예를 들어 ISOBMFF 파일 포맷 상의 다양한 레벨의 박스(box)에 포함되거나 파일 내에서 별도의 트랙내의 데이터로 포함될 수 있다. 실시예에 따라, 인캡슐레이션 처리부는 Point cloud 비디오 관련 메타데이터 자체를 파일로 인캡슐레이션할 수 있다. 전송 처리부는 파일 포맷에 따라 인캡슐레이션된 Point cloud 비디오 데이터에 전송을 위한 처리를 가할 수 있다. 전송 처리부는 전송부에 포함될 수도 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 전송 처리부는 임의의 전송 프로토콜에 따라 Point cloud 비디오비디오 데이터를 처리할 수 있다. 전송을 위한 처리에는 방송망을 통한 전달을 위한 처리, 브로드밴드를 통한 전달을 위한 처리를 포함할 수 있다. 실시예에 따라 전송 처리부는 Point cloud 비디오 데이터 뿐 아니라, 메타데이터 처리부로부터 Point cloud 비디오관련 메타데이터를 전달받아, 이 것에 전송을 위한 처리를 가할 수도 있다.
전송부는 비트스트림 형태로 출력된 인코딩된 비디오/영상 정보 또는 데이터를 파일 또는 스트리밍 형태로 디지털 저장매체 또는 네트워크를 통하여 수신 디바이스의 수신부로 전달할 수 있다. 디지털 저장 매체는 USB, SD, CD, DVD, 블루레이, HDD, SSD 등 다양한 저장 매체를 포함할 수 있다. 전송부는 미리 정해진 파일 포멧을 통하여 미디어 파일을 생성하기 위한 엘리먼트를 포함할 수 있고, 방송/통신 네트워크를 통한 전송을 위한 엘레멘트를 포함할 수 있다. 수신부는 상기 비트스트림을 추출하여 디코딩 장치로 전달할 수 있다.
수신부는 실시예들에 따른 point cloud 비디오 전송 장치가 전송한 point cloud 비디오 데이터를 수신할 수 있다. 전송되는 채널에 따라 수신부는 방송망을 통하여 point cloud 비디오 데이터를 수신할 수도 있고, 브로드밴드를 통하여 point cloud 비디오 데이터를 수신할 수도 있다. 혹은 디지털 저장 매체를 통하여 point cloud 비디오 데이터를 수신할 수도 있다.
수신 처리부는 수신된 point cloud 비디오 데이터에 대해 전송 프로토콜에 따른 처리를 수행할 수 있다. 수신 처리부는 수신부에 포함될 수 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 전송측에서 전송을 위한 처리가 수행된 것에 대응되도록, 수신 처리부는 전술한 전송 처리부의 역과정을 수행할 수 있다. 수신 처리부는 획득한 point cloud 비디오 데이터는 디캡슐레이션 처리부로 전달하고, 획득한 point cloud 비디오 관련 메타데이터는 메타데이터 파서로 전달할 수 있다. 수신 처리부가 획득하는 point cloud 비디오 관련 메타데이터는 시그널링 테이블의 형태일 수 있다.
디캡슐레이션 처리부(file/segment decapsulation module)는 수신 처리부로부터 전달받은 파일 형태의 point cloud 비디오 데이터를 디캡슐레이션할 수 있다. 디캡슐레이션 처리부는 ISOBMFF 등에 따른 파일들을 디캡슐레이션하여, point cloud 비디오 비트스트림 내지 point cloud 비디오 관련 메타데이터(메타데이터 비트스트림)를 획득할 수 있다. 획득된 point cloud 비디오 비트스트림은 상기 point cloud 비디오 디코더로, 획득된 point cloud 비디오 관련 메타데이터(메타데이터 비트스트림)는 메타데이터 처리부로 전달할 수 있다. 상기 point cloud 비디오 비트스트림은 상기 메타데이터(메타데이터 비트스트림)를 포함할 수도 있다. 상기 메타데이터 처리부는 상기 point cloud 비디오 디코더에 포함될 수도 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 디캡슐레이션 처리부가 획득하는 point cloud 비디오 관련 메타데이터는 파일 포맷 내의 박스 혹은 트랙 형태일 수 있다. 디캡슐레이션 처리부는 필요한 경우 메타데이터 처리부로부터 디캡슐레이션에 필요한 메타데이터를 전달받을 수도 있다. 상기 point cloud 비디오 관련 메타데이터는 상기 point cloud 비디오 디코더에 전달되어 point cloud 비디오 디코딩 절차에 사용될 수도 있고, 또는 렌더러에 전달되어 point cloud 비디오 렌더링 절차에 사용될 수도 있다.
Point Cloud 비디오 디코더는 상기 비트스트림을 입력받아 상기 Point Cloud 비디오 인코더의 동작에 대응하는 동작을 수행하여 비디오/영상을 디코딩할 수 있다. 이 경우 Point Cloud 비디오 디코더는 Point Cloud 비디오를 후술하는 바와 같이 지오메트리 비디오, 어트리뷰트(attribute) 비디오, 어큐판시(occupancy) 맵 비디오, 그리고 부가 정보(auxilIary information )으로 나누어 디코딩할 수 있다. 상기 지오메트리 비디오는 지오메트리 이미지를 포함할 수 있고, 상기 어트리뷰트(attribute) 비디오는 어트리뷰트 이미지를 포함할 수 있고, 상기 어큐판시(occupancy) 맵 비디오는 어큐판시 맵 이미지를 포함할 수 있다. 상기 부가 정보는 부가 패치 정보(auxiliary patch information)를 포함할 수 있다. 상기 어트리뷰트 비디오/이미지는 텍스쳐 비디오/이미지를 포함할 수 있다.
디코딩된 지오메트리 이미지와 오큐판시 맵 및 부가 패치 정보를 이용하여 3차원 지오메트리가 복원되며 이후 스무딩 과정을 거칠 수 있다. 스무딩된 3차원 지오메트리에 텍스처 이미지를 이용하여 컬러값을 부여함으로써 컬러 포인트 클라우드 영상/픽처가 복원될 수 있다. 렌더러는 복원된 지오메트리, 컬러 포인트 클라우드 영상/픽처를렌더링할 수 있다. 렌더링된 비디오/영상은 디스플레이부를 통하여 디스플레이될 수 있다. 사용자는 VR/AR 디스플레이 또는 일반 디스플레이 등을 통하여 렌더링 된 결과의 전부 또는 일부 영역을 볼 수 있다.
피드백 과정은 렌더링/디스플레이 과정에서 획득될 수 있는 다양한 피드백 정보들을 송신측으로 전달하거나 수신측의 디코더에 전달하는 과정을 포함할 수 있다. 피드백 과정을 통해 Point Cloud 비디오 소비에 있어 인터랙티비티(interactivity) 가 제공될 수 있다. 실시예에 따라, 피드백 과정에서 헤드 오리엔테이션(Head Orientation) 정보, 사용자가 현재 보고 있는 영역을 나타내는 뷰포트(Viewport) 정보 등이 전달될 수 있다. 실시예에 따라, 사용자는 VR/AR/MR/자율주행 환경 상에 구현된 것들과 상호작용 할 수도 있는데, 이 경우 그 상호작용과 관련된 정보가 피드백 과정에서 송신측 내지 서비스 프로바이더 측으로 전달될 수도 있다. 실시예에 따라 피드백 과정은 수행되지 않을 수도 있다.
헤드 오리엔테이션 정보는 사용자의 머리 위치, 각도, 움직임 등에 대한 정보를 의미할 수 있다. 이 정보를 기반으로 사용자가 현재 Point Cloud 비디오 내에서 보고 있는 영역에 대한 정보, 즉 뷰포트 정보가 계산될 수 있다.
뷰포트 정보는 현재 사용자가 Point Cloud 비디오에서 보고 있는 영역에 대한 정보일 수 있다. 이를 통해 게이즈 분석(Gaze Analysis) 이 수행되어, 사용자가 어떠한 방식으로 Point Cloud 비디오를 소비하는지, Point Cloud 비디오의 어느 영역을 얼마나 응시하는지 등을 확인할 수도 있다. 게이즈 분석은 수신측에서 수행되어 송신측으로 피드백 채널을 통해 전달될 수도 있다. VR/AR/MR 디스플레이 등의 장치는 사용자의 머리 위치/방향, 장치가 지원하는 수직(vertical) 혹은 수평(horizontal) FOV 등에 근거하여 뷰포트 영역을 추출할 수 있다.
실시예에 따라, 전술한 피드백 정보는 송신측으로 전달되는 것 뿐 아니라, 수신측에서 소비될 수도 있다. 즉, 전술한 피드백 정보를 이용하여 수신측의 디코딩, 렌더링 과정 등이 수행될 수 있다. 예를 들어, 헤드 오리엔테이션 정보 및/또는 뷰포트 정보를 이용하여 현재 사용자가 보고 있는 영역에 대한 Point Cloud 비디오만 우선적으로 디코딩 및 렌더링 될 수도 있다.
여기서 뷰포트(viewport) 내지 뷰포트 영역이란, 사용자가 Point Cloud 비디오에서 보고 있는 영역을 의미할 수 있다. 시점(viewpoint) 는 사용자가 Point Cloud 비디오에서 보고 있는 지점으로서, 뷰포트 영역의 정중앙 지점을 의미할 수 있다. 즉, 뷰포트는 시점을 중심으로 한 영역인데, 그 영역이 차지하는 크기 형태 등은 FOV(Field Of View) 에 의해 결정될 수 있다.
이 문서는 상술한 바와 같이 Point Cloud 비디오 압축에 관한 것이다. 예를 들어 이 문서에서 개시된 방법/실시예는 MPEG (Moving Picture Experts Group)의 PCC (point cloud compression or point cloud coding) 표준 또는 차세대 비디오/이미지 코딩 표준에 적용될 수 있다.
이 문서에서 픽처(picture)/프레임(frame)은 일반적으로 특정 시간대의 하나의 영상을 나타내는 단위를 의미할 수 있다.
픽셀(pixel) 또는 펠(pel)은 하나의 픽처(또는 영상)을 구성하는 최소의 단위를 의미할 수 있다. 또한, 픽셀에 대응하는 용어로서 '샘플(sample)'이 사용될 수 있다. 샘플은 일반적으로 픽셀 또는 픽셀의 값을 나타낼 수 있으며, 루마(luma) 성분의 픽셀/픽셀값만을 나타낼 수도 있고, 크로마(chroma) 성분의 픽셀/픽셀 값만을 나타낼 수도 있고, 또는 뎁스(depth) 성분의 픽셀/픽셀값만을 나타낼 수도 있다.
유닛(unit)은 영상 처리의 기본 단위를 나타낼 수 있다. 유닛은 픽처의 특정 영역 및 해당 영역에 관련된 정보 중 적어도 하나를 포함할 수 있다. 유닛은 경우에 따라서 블록(block) 또는 영역(area) 등의 용어와 혼용하여 사용될 수 있다. 일반적인 경우, MxN 블록은 M개의 열과 N개의 행으로 이루어진 샘플들(또는 샘플 어레이) 또는 변환 계수(transform coefficient)들의 집합(또는 어레이)을 포함할 수 있다.
도24는 실시예들에 따른 point cloud 및 geometry, texture image (non-padded)의 예시를 나타낸다.
실시예들에 따른 인코딩 프로세스와 관련하여,
실시예들에 따른 Video-based Point Cloud Compression (V-PCC)는 HEVC, VVC 등의 2D video codec을 기반으로 3차원 point cloud 데이터를 압축하는 방법을 제공할 수 있다. V-PCC 압축 과정에서 다음과 같은 데이터 및 정보들이 생성될 수 있다.
실시예들에 따른 occupancy map: point cloud를 이루는 점들을 *patch로 나누어 2D 평면에 맵핑할 때 2D 평면의 해당 위치에 데이터가 존재하는 여부를 0 또는 1의 값으로 알려주는 2진 맵 (binary map)
실시예들에 따른 *patch: point cloud를 구성하는 점들의 집합으로, 같은 patch에 속하는 점들은 3차원 공간상에서 서로 인접해 있으며 2D 이미지로의 맵핑 과정에서 6면의 bounding box 평면 중 같은 방향으로 맵핑될 수 있다.
실시예들에 따른 geometry image: point cloud를 이루는 각 점들의 위치 정보 (geometry)를 patch 단위로 표현하는 depth map 형태의 이미지. 1 채널의 픽셀 값으로 구성될 수 있다.
실시예들에 따른 texture image: point cloud를 이루는 각 점들의 색상 정보를 patch 단위로 표현하는 image. 복수 채널의 픽셀 값 (e.g. 3채널 R, G, B)으로 구성될 수 있다.
실시예들에 따른 auxiliary patch info: 개별 patch들로부터 point cloud를 재구성하기 위해 필요한 메타데이터로, patch의 2D/3D 공간에서의 위치, 크기 등에 대한 정보를 포할 수 있다.
도25는 실시예들에 따른 V-PCC 인코딩 프로세스를 나타낸다.
도면은 어큐판시 맵(occupancy map), 지오메트리 이미지(geometry image), 텍스쳐 이미지(texture image), 오실러리 패치 인포메이션(auxiliary patch information)을 생성하고 압축하기 위한 V-PCC encoding process를 도시하여 보여주고 있다. 각 process의 동작은 다음과 같다.
실시예들에 따른 오실러리 패치 인포메이션은 패치들의 분포에 관한 정보를 포함한다.
실시예들에 따른 Patch generation
Patch generation 과정은 point cloud를 2D 이미지에 맵핑 (mapping)하기 위하여, 맵핑을 수행하는 단위인 patch로 point cloud를 분할하는 과정을 의미한다. Patch generation 과정은 다음과 같이 normal 값 계산, segmentation, patch 분할의 세 단계로 구분될 수 있다.
실시예들에 따른 패치는 3차원 데이터를 2차원 데이터(예를 들어, 이미지)로 맵핑하는 데이터를 나타낸다.
실시예들에 따른 Normal 계산
Point cloud를 이루는 각 점들은 고유의 방향을 가지고 있는데 이것은 normal이라는 3차원 vector로 표현된다. K-D tree 등을 이용하여 구해지는 각 점들의 인접점들 (neighbors)을 이용하여, 다음의 Figure 1-3에서와 같은 point cloud의 surface를 이루는 각 점들의 *tangent plane 및 normal vector를 구할 수 있다. 인접점들을 찾는 과정에서의 search range는 사용자에 의해 정의될 수 있다.
도26은 실시예들에 따른 서페이스(Surface)의 탄젠트 플레인(tangent plane) 및 노멀 벡터(normal vector)를 나타낸다.
실시예들에 따른 *tangent plane: surface의 한 점을 지나면서 surface 위의 곡선에 대한 접선을 완전이 포함하고 있는 평면이다.
실시예들에 따른 노멀 벡터는 탄젠트 플레인에 대한 노멀 벡터이다.
이어서, 실시예들에 따른 V-PCC 인코딩 프로세스를 설명하면 다음과 같다.
세그멘테이션(Segmentation):
Segmentation은 initial segmentation과 refine segmentation의 두 과정으로 이루어 진다.
Point cloud를 이루는 각 점들은 후술할 도27에서와 같이 point cloud를 감싸는 6개의 bounding box의 면들 중 하나의 면에 projection되는데, initial segmentation은 각 점들이 projection될 bounding box의 평면들 중 하나를 결정하는 과정이다.
도27은 실시예들에 따른 Point cloud의 bounding box를 나타낸다.
실시예들에 따른 포인트 클라우드의 바운딩 박스는, 예를 들어 정육면체를 이루는 형태일 수 있다.
실시예들에 따른6개의 각 평면들과 대응되는 normal값인
Figure PCTKR2019012719-appb-img-000001
는 다음과 같이 정의된다.
(1.0, 0.0, 0.0),
(0.0, 1.0, 0.0),
(0.0, 0.0, 1.0),
(-1.0, 0.0, 0.0),
(0.0, -1.0, 0.0),
(0.0, 0.0, -1.0).
다음의 수식과 같이 앞서 normal 값 계산과정에서 얻은 각 점들의 normal 값(
Figure PCTKR2019012719-appb-img-000002
)과
Figure PCTKR2019012719-appb-img-000003
의 외적 (dot product)이 최대인 면을 해당 면의 projection 평면으로 결정한다. 즉, point의 normal과 가장 유사한 방향의 normal을 갖는 평면이 해당 point 의 projection 평면으로 결정된다.
Figure PCTKR2019012719-appb-img-000004
결정된 평면은 0~5 중 하나의 index 형태의 값 (cluster index) 으로 식별될 수 있다.
Refine segmentation은 앞서 initial segmentation 과정에서 결정된 point cloud를 이루는 각 점의projection 평면을 인접 점들의 projection 평면을 고려하여 개선하는 과정이다. 이 과정에서는 앞서 initial segmentation 과정에서 projection 평면 결정을 위해 고려된 각 포인트의 normal과 bounding box의 각 평면의 normal 값과의 유사 정도를 이루는 score normal과 함께, 현재 점의 projection 평면과 인접 점들의 projection 평면과의 일치 정도를 나타내는 score smooth가 동시에 고려될 수 있다.
Score smooth는 score normal에 대하여 가중치를 부여하여 고려될 수 있으며, 이 때 가중치 값은 사용자에 의해 정의될 수 있다. Refine segmentation은 반복적으로 수행될 수 있으며, 반복 횟수 또한 사용자에 의해 정의될 수 있다.
Patch 분할 (segment patches):
Patch 분할은 앞서 initial/refine segmentation 과정에서 얻은 point cloud를 이루는 각 점들의 projection 평면 정보를 바탕으로, 전체 point cloud를 인접한 점들의 집합인 patch로 나누는 과정이다. Patch 분할은 다음과 같은 단계들로 구성될 수 있다.
1) K-D tree 등을 이용하여 point cloud를 이루는 각 점들의 인접 점들을 산출한다. 최대 인접점으 개수는 사용자에 의해 정의될 수 있다.
2) 인접 점들이 현재의 점과 동일한 평면에 projection 될 경우 (동일한 cluster index 값을 가질 경우) 현재의 점과 해당 인접 점들을 하나의 patch로 추출한다.
3) 추출된 patch의 geometry 값들을 산출한다. 자세한 과정은 1.3절에서 설명한다.
4) 추출되지 않은 점들이 없어질 때까지 ②내지④과정을 반복한다.
Patch 분할 과정을 통해 각 patch의 크기 및 patch별 occupancy map, geometry image, texture image 등이 결정된다.
Patch packing & Occupancy map generation:
본 과정은 앞서 분할된 patch들을 하나의 2D 이미지에 맵핑하기 위해 개별 patch들의 2D 이미지 내에서의 위치를 결정하는 과정이다. Occupancy map은 상기 2D 이미지의 하나로, 해당 위치에 데이터가 존재하는지 여부를 0 또는 1의 값으로 알려주는 binary map이다. Occupancy map은 block으로 이루어 지며 block의 크기에 따라 그 해상도가 결정될 수 있는데, 일례로 block 크기가 1*1일 경우 픽셀 (pixel) 단위의 해상도를 갖는다. Block의 크기 (occupancy packing block size)는 사용자에 의해 결정될 수 있다.
Occupancy map 내에서 개별 patch의 위치를 결정하는 과정은 다음과 같이 구성될 수 있다.
1) 전체 occupancy map의 값들을 모두 0으로 설정한다.
2) occupancy map 평면에 존재하는 수평 좌표가 [0, *occupancySizeU - *patch.sizeU0), 수직 좌표가 [0, *occupancySizeV - *patch.sizeV0) 범위에 있는 점 (u, v)에 patch를 위치시킨다.
3) patch 평면에 존재하는 수평 좌표가 [0, patch.sizeU0), 수직 좌표가 [0, patch.sizeV0) 범위에 있는 점 (x, y)를 현재 점으로 설정한다.
4) 점 (x, y)에 대하여, patch occupancy map의 (x, y) 좌표 값이 1이고 (patch 내 해당 지점에 데이터가 존재하고), 전체 occupancy map의 (u+x, v+y) 좌표 값이 1 (이전 patch에 의해 occupancy map이 채워진 경우) raster order 순으로 (x, y) 위치를 변경하여 3번 및 4번 과정을 반복한다. 그렇지 않을 경우, 6번의 과정을 수행한다.
5) raster order 순으로 (u, v) 위치를 변경하여 ③내지⑤의 과정을 반복한다.
6) (u, v)를 해당 patch의 위치로 결정하고, patch의 occupancy map 데이터를 전체 occupancy map의 해당 부분에 할당(copy)한다.
7) 다음 patch에 대하여 2번 내지 7번의 과정을 반복한다.
도28은 실시예들에 따른 Occupancy map에서의 개별 patch 위치 결정 방식을 나타낸다.
실시예들에 따른 *occupancySizeU: occupancy map의 width를 나타내며, 단위는 occupancy packing block size이다.
실시예들에 따른 *occupancySizeV: occupancy map의 height를 나타내며, 단위는 occupancy packing block size.
실시예들에 따른 *patch.sizeU0: occupancy map의 width를 나타내며, 단위는 occupancy packing block size.
실시예들에 따른 *patch.sizeV0: occupancy map의 height를 나타내며, 단위는 occupancy packing block size.
실시예들에 따른Geometry image generation:
본 과정에서는 개별 patch의 geometry image를 구성하는 depth 값들을 결정하고, 상술한 과정에서 결정된 patch의 위치를 바탕으로 전체 geometry image를 생성한다. 개별 patch의 geometry image를 구성하는 depth 값들을 결정하는 과정은 다음과 같이 구성될 수 있다.
① 실시예들에 따른 개별 patch의 위치, 크기 관련 파라미터들을 산출한다. 파라미터들은 다음과 같은 정보들을 포함할 수 있다.
- 실시예들에 따른normal 축을 나타내는 index: normal은 앞서 patch generation 과정에서 구해지며, tangent 축은 normal과 직각인 축들 중 patch image의 수평(u)축과 일치하는 축이며, bitangent 축은 normal과 직각인 축들 중 patch image의 수직(v)축과 일치하는 축으로, 세 가지 축은 도28에서와 같이 표현될 수 있다.
도29은 실시예들에 따른 normal, tangent, bitangent 축의 관계를 나타낸다.
실시예들에 따른 서페이스는 복수의 리전(영역, 예를 들어, C1,C2, D1, D2, E1, ..etc.)을 포함할 수 있다.
실시예들에 따른 서페이스의 tangent 축은 normal과 직각인 축들 중 patch image의 수평(u)축과 일치하는 축이다.
실시예들에 따른 서페이스의 bitangent 축은 normal과 직각인 축들 중 patch image의 수직(v)축과 일치하는 축이다.
실시예들에 따른 서페이스의 normal 축은 patch generation에서 생성된 노멀을 나타낸다.
- 실시예들에 따른patch의 3D 공간 좌표: patch를 감싸는 최소 크기의 bounding box를 통해 산출될 수 있다. patch의 tangent 방향 최소값 (patch 3d shift tangent axis), patch의 bitangent 방향 최소값 (patch 3d shift bitangent axis), patch의 normal 방향 최소값 (patch 3d shift normal axis) 등이 포함될 수 있다.
- 실시예들에 따른patch의 2D 크기: patch가 2D 이미지로 패킹될 때의 수평, 수직 방향 크기를 나타낸다. 수평 방향 크기 (patch 2d size u)는 bounding box의 tangent 방향 최대값과 최소값의 차이로, 수직 방향 크기 (patch 2d size v)는 bounding box의 bitangent 방향 최대값과 최소값의 차이로 구해질 수 있다.
도30는 실시예들에 따른 min mode에서의 d0, d1 구성 및 max mode에서의 d0, d1 구성을 나타낸다.
실시예들에 따른 2D 포인트 클라우드의 패치의 프로젝션 모드는 최소 모드 및 최대 모드를 포함한다.
실시예들에 따른 d0는 제1레이어의 이미지이고, 실시예들에 따른 d1은 제2레이어의 이미지이다.
2D 포인트 클라우드의 패치의 프로젝션은 최소 값을 기준으로 프로젝션하고, 미싱 포인트들을 레이어 d0, d1에 기초하여 결정한다.
실시예들에 따른 Geometry image generation은 패치에 대한 커넥티드 컴포넌트를 재구성하고 이때 미싱 포인트들이 존재한다.
실시예들에 따른 delta는 d0 및 d1 간의 차이일 수 있다. 실시예들에 따른 Geometry image generation은 delta 값에 기반하여 미싱 포인트들을 결정할 수 있다.
② Patch의 projection mode를 결정한다. Projection mode는 min mode와 max mode 중 하나일 수 있다. Patch의 geometry 정보는 depth 값으로 표현되는데, patch의 normal 방향으로 patch를 이루는 각 점들을 projection 할 때 depth 값의 최대 값으로 구성되는 이미지와 최소값으로 구성되는 이미지 두 계층(layer)의 이미지들이 생성될 수 있다.
실시예들에 따른 두 계층의 이미지 d0와 d1을 생성함에 있어, min mode일 경우 도30과 같이 최소 depth가 d0에 구성되고, 최소 depth로부터 surface thickness 이내에 존재하는 최대 depth가 d1으로 구성될 수 있다. Max mode일 경우 도30과 같이 최대 depth가 d0에 구성되고, 최대 depth로부터 surface thickness 이내에 존재하는 최소 depth가 d1으로 구성될 수 있다.
실시예들에 따른Projection mode는 사용자 정의에 의해 모든 point cloud에 동일한 방법이 적용되거나, frame 또는 patch 별로 다르게 적용될 수 있다. Frame 또는 patch 별로 다른 projection mode가 적용될 경우, 압축 효율을 높이거나 소실 점 (missed point)을 최소화 할 수 있는 projection mode가 적응적으로 선택될 수 있다.
실시예들에 따른 프로젝션 모드에 따라서 커넥티드 컴포넌트의 구성이 달라진다.
③ 개별 점들의 depth 값을 산출한다. Min mode일 경우 각 점의 normal 축 최소값에 patch의 normal 방향 최소값 (patch 3d shift normal axis)에서 ①의 과정에서 산출된 patch의 normal 방향 최소값 (patch 3d shift normal axis)을 뺀 값인 depth0로 d0 이미지를 구성한다. 동일 위치에 depth0와 surface thickness 이내의 범위에 또 다른 depth 값이 존재할 경우, 이 값을 depth1으로 설정한다. 존재하지 않을 경우 depth0의 값을 depth1에도 할당한다. Depth1 값으로 d1 이미지를 구성한다.
Max mode일 경우 각 점의 normal 축 최대값에 patch의 normal 방향 최소값 (patch 3d shift normal axis)에서 ①의 과정에서 산출된 patch의 normal 방향 최소값 (patch 3d shift normal axis)을 뺀 값인 depth0로 d0 이미지를 구성한다. 동일 위치에 depth0와 surface thickness 이내의 범위에 또 다른 depth 값이 존재할 경우, 이 값을 depth1으로 설정한다. 존재하지 않을 경우 depth0의 값을 depth1에도 할당한다. Depth1 값으로 d1 이미지를 구성한다.
위와 같은 과정을 통해 생성된 개별 patch의 geometry image를 앞서 1.2 patch packing 과정에서 결정된 patch의 위치 정보를 이용하여 전체 geometry image에 배치시킴으로써 전체 geometry image를 생성할 수 있다.
생성된 전체 geometry image의 d1 계층은 여러 가지 방법으로 부호화 될 수 있다. 첫 번째는 앞서 생성한 d1 이미지의 depth값들을 그대로 부호화 (absolute d1 method)하는 방법이다. 두 번째는 앞서 생성한 d1 이미지의 depth값과 d0 이미지의 depth값이 차이 값을 부호화 (differential method)하는 방법이다.
도31은 실시예들에 따른 EDD code의 예시를 나타낸다.
상술한 실시예들과 같은 d0, d1 두 계층의 depth 값을 이용한 부호화 방법은 두 depth 사이에 또 다른 점들이 존재할 경우 해당 점의 geometry 정보를 부호화 과정에서 잃어버리기 때문에, 무손실 압축 (lossless coding)을 위해 Enhanced-Delta-Depth (EDD) code를 이용할 수도 있다. EDD code는 Figure 1-9에 도시된 바와 같이, d1을 포함하여 surface thickness 범위 내의 모든 점들의 위치를 이진으로 부호화 하는 방법이다. 일례로 Figure 1-9의 좌측에서 두 번째 열에 포함되는 점들의 경우, D0 위쪽으로 첫 번째, 네 번째 위치에 점들이 존재하고, 두 번째와 세 번째 위치는 비어있기 때문에 0b1001 (=9)의 EDD code로 표현될 수 있다. D0와 함께 EDD code를 부호화하여 보내 주면 수신단에서는 모든 점들의 geometry 정보를 손실 없이 복원할 수 있게 된다.
실시예들에 따른 Smoothing:
Smoothing은 압축 과정에서 발생하는 화질의 열화로 인해 patch 경계면에서 발생할 수 있는 불연속성을 제거하기 위한 작업이며 다음과 같은 과정으로 수행될 수 있다.
① geometry image로부터 point cloud를 재생성(reconstruction)한다. 본 과정은 1.3에서 설명한 geometry image 생성의 역과정이라고 할 수 있다.
② K-D tree 등을 이용하여 재생성된 point cloud를 구성하는 각 점들의 인접점들을 산출한다.
③ 각 점들에 대하여, 해당 점이 patch 경계면에 위치하는지를 판단한다. 일례로 현재 점과 다른 projection 평면 (cluster index)을 갖는 인접점이 존재할 경우, 해당 점은 patch 경계면에 위치한다고 판단할 수 있다.
④ patch 경계면에 존재할 경우, 해당 점을 인접점들의 무게중심 (인접점들의 평균 x, y, z 좌표에 위치)으로 이동시킨다. 즉, geometry 값을 변경시킨다. 그렇지 않을 경위 이전 geometry 값을 유지한다.
도32는 실시예들에 따른 인접점들의 color 값들을 이용한 recoloring을 나타낸다.
실시예들에 따른 Texture image generation:
실시예들에 따른 Texture image 생성 과정은 상술한 geometry image 생성 과정과 유사하게, 개별 patch의 texture image 생성하고, 이들은 결정된 위치에 배치하여 전체 texture image를 생성하는 과정으로 구성된다. 다만 개별 patch의 texture image를 생성하는 과정에 있어서 geometry 생성을 위한 depth 값을 대신하여 해당 위치에 대응되는 point cloud를 구성하는 점의 color 값 (e.g. R, G, B)을 갖는 image가 생성된다.
실시예들에 따른 Point cloud를 구성하는 각 점의 color 값을 구하는 과정에 있어서 앞서 smoothing 과정을 거친 geometry가 사용될 수 있다. Smoothing된 point cloud는 원본 point cloud에서 일부 점들의 위치가 이동된 상태일 수 있으므로, 변경된 위치에 적합한 color를 찾아내는 recoloring과정이 필요할 수 있다. Recoloring은 인접점들의 color 값들을 이용하여 수행될 수 있다. 실시예들에 따라 도32에서와 같이 새로운 color값은 최인접점의 color값과 인접점들의 color값들을 고려하여 산출될 수 있다.
실시예들에 따른 Texture image 또한 d0/d1의 두 계층으로 생성되는 geometry image와 같이 t0/t1의 두 개의 계층 으로 생성될 수 있다.
도33는 실시예들에 따른 block과 patch 맵핑을 위한 pseudo code 를 나타낸다.
실시예들에 따른 Auxiliary patch info compression:
실시예들에 따른 과정에서는 앞서 설명한 patch generation, patch packing, geometry generation 과정 등에서 생성된 부가 patch 정보들을 압축한다. 부가 patch 정보에는 다음과 같은 파라미터들이 포함될 수 있다.
- projection 평면 (normal)을 식별하는 index (cluster index)
- patch의 3D 공간 위치: patch의 tangent 방향 최소값 (patch 3d shift tangent axis), patch의 bitangent 방향 최소값 (patch 3d shift bitangent axis), patch의 normal 방향 최소값 (patch 3d shift normal axis)
- patch의 2D 공간 위치, 크기: 수평 방향 크기 (patch 2d size u), 수직 방향 크기 (patch 2d size v), 수평 방향 최소값 (patch 2d shift u), 수직 방향 최소값 (patch 2d shift u)
- 각 block과 patch의 맵핑 정보: candidate index (위의 patch의 2D 공간 위치, 크기 정보를 기반으로 patch를 순서대로 위치시켰을 때, 한 block에 중복으로 복수 patch가 맵핑될 수 있음. 이때 맵핑되는 patch들이 candidate list를 구성하며, 이 list 중 몇 번째 patch의 data가 해당 block에 존재하는지를 나타내는 index), local patch index (frame에 존재하는 전체 patch들 중 하나를 가리키는 index). 도면은 candidate list와 local patch index를 이용한 block과 patch match 과정을 나타내는 pseudo code이다.
실시예들에 따른 * candidate list의 최대 개수는 사용자에 의해 정의될 수 있다.
도34는 실시예들에 따른 push-pull background filling을 나타낸다.
실시예들에 따른 Image padding and group dilation:
Image padding은 압축 효율 향상을 목적으로 patch 영역 이외의 공간을 의미 없는 데이터로 채우는 과정이다. Image padding을 위해 patch 내부의 경계면 쪽에 해당하는 열 또는 행의 픽셀 값들이 복사되어 빈 공간을 채우는 방법이 사용될 수 있다. 또는 도면에서와 같이, padding 되지 않은 이미지를 단계적으로 해상도를 줄이고, 다시 해상도를 늘리는 과정에서 낮은 해상도의 이미지로부터 온 픽셀 값들로 빈 공간을 채우는 push-pull background filling 방법이 사용될 수도 있다.
도35는 실시예들에 따른 4*4 크기의 block에 대해 가능한 traversal order의 예시를 나타낸다.
실시예들에 따른 Group dilation은 d0/d1, t0/t1 두 계층으로 이루어진 geometry, texture image의 빈 공간을 채우는 방법으로, 앞서 image padding을 통해 산출된 두 계층 빈 공간의 값들을, 두 계층의 동일 위치에 대한 값의 평균값으로 채우는 과정이다.
실시예들에 따른Occupancy map compression:
앞서 설명한 실시예들의 과정에서 생성된 occupancy map을 압축하는 과정으로 손실 (lossy) 압축을 위한 video compression과 무손실 (lossless) 압축을 위한 entropy compression, 두 가지 방법이 존재할 수 있다. video compression은 도37에서 설명한다.
실시예들에 따른 Entropy compression 과정은 다음과 같은 과정으로 수행될 수 있다.
① occupancy map을 구성하는 각 block에 대하여, block이 모두 채워진 경우 1을 부호화 하고 다음 block에 대해 동일 과정을 반복한다. 그렇지 않은 경우 0을 부호화하고, ②내지⑤의 과정을 수행한다. .
② block의 채워진 pixel들에 대해 run-length coding을 수행하기 위한 best traversal order를 결정한다. Figure 1-12는 4*4 크기의 block에 대해 가능한 4가지 traversal order를 일례로 보여주고 있다.
도36는 실시예들에 따른 best traversal order 선택의 예시를 나타낸다.
가능한 traversal order들 중 최소의 run 개수를 갖는 best traversal order를 선택하여 그 index를 부호화 한다. 실시예들에 따른 도면은 앞선 도면의 세 번째 traversal order를 선택할 경우이며, 이 경우 run의 개수가 2로 최소화될 수 있으므로 이를 best traversal order로 선택할 수 있다.
③ run의 개수를 부호화 한다. 도면의 예에서는 2개의 run이 존재하므로 2가 부호화 된다.
④ 첫 번째 run의 occupancy를 부호화 한다. 도면의 예에서는 첫 번째 run이 채워지지 않은 픽셀들에 해당하므로 0이 부호화된다.
⑤ 개별 run에 대한 (run의 개수만큼의) length를 부호화 한다. 도면의 예에서는 첫 번째 run과 두 번째 run의 length인 6과 10이 순차적으로 부호화된다.
도37은 실시예들에 따른 2D video/image encoder 을 나타낸다.
실시예들에 따른 Video compression:
실시예들에 따른 HEVC, VVC 등의 2D video codec 등을 이용하여, 앞서 설명한 과정으로 생성된 geometry image, texture image, occupancy map image 등의 시퀀스를 부호화 하는 과정이다.
실시예들에 따른 도면은 Video compression이 적용되는 실시예로서, 비디오/영상 신호의 인코딩이 수행되는 2D video/image encoder(100)의 개략적인 블록도를 나타낸다. 상기 2D video/image encoder(100)는 상술한 point cloud video encoder에 포함될 수 있고, 또는 내/외부 컴포넌트로 구성될 수도 있다. 여기서 입력 영상은 상술한 geometry image, texture image (attribute(s) image), occupancy map image 등을 포함할 수 있다. point cloud video encoder의 출력 bitstream (즉, point cloud video/image bitstream)은 각 입력 영상(geometry image, texture image (attribute(s) image), occupancy map image 등)에 대한 출력 비트스트림들을 포함할 수 있다.
실시예들에 따른 도면들을 참조하면, 인코더(100)는 영상 분할부(110), 감산부(115), 변환부(120), 양자화부(130), 역양자화부(140), 역변환부(150), 가산부(155), 필터링부(160), 메모리(170), 인터 예측부(180), 인트라 예측부(185) 및 엔트로피 인코딩부(190)를 포함하여 구성될 수 있다. 인터 예측부(180) 및 인트라 예측부(185)를 합쳐서 예측부라고 불릴 수 있다. 즉, 예측부는 인터 예측부(180) 및 인트라 예측부(185)를 포함할 수 있다. 변환부(120), 양자화부(130), 역양자화부(140), 역변환부(150)는 레지듀얼(residual) 처리부에 포함될 수 있다. 레지듀얼 처리부는 감산부(115)를 더 포함할 수도 있다. 상술한 영상 분할부(110), 감산부(115), 변환부(120), 양자화부(130), 역양자화부(140), 역변환부(150), 가산부(155), 필터링부(160), 인터 예측부(180), 인트라 예측부(185) 및 엔트로피 인코딩부(190)는 실시예에 따라 하나의 하드웨어 컴포넌트(예를 들어 인코더 또는 프로세서)에 의하여 구성될 수 있다. 또한 메모리(170)는 DPB(decoded picture buffer)를 포함할 수 있고, 디지털 저장 매체에 의하여 구성될 수도 있다.
실시예들에 따른 영상 분할부(110)는 인코딩 장치(100)에 입력된 입력 영상(또는, 픽쳐, 프레임)를 하나 이상의 처리 유닛(processing unit)으로 분할할 수 있다. 일 예로, 상기 처리 유닛은 코딩 유닛(coding unit, CU)이라고 불릴 수 있다. 이 경우 코딩 유닛은 코딩 트리 유닛(coding tree unit, CTU) 또는 최대 코딩 유닛(largest coding unit, LCU)으로부터 QTBT (Quad-tree binary-tree) 구조에 따라 재귀적으로(recursively) 분할될 수 있다. 예를 들어, 하나의 코딩 유닛은 쿼드 트리 구조 및/또는 바이너리 트리 구조를 기반으로 하위(deeper) 뎁스의 복수의 코딩 유닛들로 분할될 수 있다. 이 경우 예를 들어 쿼드 트리 구조가 먼저 적용되고 바이너리 트리 구조가 나중에 적용될 수 있다. 또는 바이너리 트리 구조가 먼저 적용될 수도 있다. 더 이상 분할되지 않는 최종 코딩 유닛을 기반으로 실시예들에 따른 코딩 절차가 수행될 수 있다. 이 경우 영상 특성에 따른 코딩 효율 등을 기반으로, 최대 코딩 유닛이 바로 최종 코딩 유닛으로 사용될 수 있고, 또는 필요에 따라 코딩 유닛은 재귀적으로(recursively) 보다 하위 뎁스의 코딩 유닛들로 분할되어 최적의 사이즈의 코딩 유닛이 최종 코딩 유닛으로 사용될 수 있다. 여기서 코딩 절차라 함은 후술하는 예측, 변환, 및 복원 등의 절차를 포함할 수 있다. 다른 예로, 상기 처리 유닛은 예측 유닛(PU: Prediction Unit) 또는 변환 유닛(TU: Transform Unit)을 더 포함할 수 있다. 이 경우 상기 예측 유닛 및 상기 변환 유닛은 각각 상술한 최종 코딩 유닛으로부터 분할 또는 파티셔닝될 수 있다. 상기 예측 유닛은 샘플 예측의 단위일 수 있고, 상기 변환 유닛은 변환 계수를 유도하는 단위 및/또는 변환 계수로부터 레지듀얼 신호(residual signal)를 유도하는 단위일 수 있다.
실시예들에 따른 유닛은 경우에 따라서 블록(block) 또는 영역(area) 등의 용어와 혼용하여 사용될 수 있다. 일반적인 경우, MxN 블록은 M개의 열과 N개의 행으로 이루어진 샘플들 또는 변환 계수(transform coefficient)들의 집합을 나타낼 수 있다. 샘플은 일반적으로 픽셀 또는 픽셀의 값을 나타낼 수 있으며, 휘도(luma) 성분의 픽셀/픽셀값만을 나타낼 수도 있고, 채도(chroma) 성분의 픽셀/픽셀 값만을 나타낼 수도 있다. 샘플은 하나의 픽처(또는 영상)을 픽셀(pixel) 또는 펠(pel)에 대응하는 용어로서 사용될 수 있다.
실시예들에 따른 인코딩 장치(100)는 입력 영상 신호(원본 블록, 원본 샘플 어레이)에서 인터 예측부(180) 또는 인트라 예측부(185)로부터 출력된 예측 신호(예측된 블록, 예측 샘플 어레이)를 감산하여 레지듀얼 신호(residual signal, 잔여 블록, 잔여 샘플 어레이)를 생성할 수 있고, 생성된 레지듀얼 신호는 변환부(120)로 전송된다. 이 경우 도시된 바와 같이 인코더(100) 내에서 입력 영상 신호(원본 블록, 원본 샘플 어레이)에서 예측 신호(예측 블록, 예측 샘플 어레이)를 감산하는 유닛은 감산부(115)라고 불릴 수 있다. 예측부는 처리 대상 블록(이하, 현재 블록이라 함)에 대한 예측을 수행하고, 상기 현재 블록에 대한 예측 샘플들을 포함하는 예측된 블록(predicted block)을 생성할 수 있다. 예측부는 현재 블록 또는 CU 단위로 인트라 예측이 적용되는지 또는 인터 예측이 적용되는지 결정할 수 있다. 예측부는 각 예측모드에 대한 설명에서 후술하는 바와 같이 예측 모드 정보 등 예측에 관한 다양한 정보를 생성하여 엔트로피 인코딩부(190)로 전달할 수 있다. 예측에 관한 정보는 엔트로피 인코딩부(190)에서 인코딩되어 비트스트림 형태로 출력될 수 있다.
실시예들에 따른 인트라 예측부(185)는 현재 픽처 내의 샘플들을 참조하여 현재 블록을 예측할 수 있다. 상기 참조되는 샘플들은 예측 모드에 따라 상기 현재 블록의 주변(neighbor)에 위치할 수 있고, 또는 떨어져서 위치할 수도 있다. 인트라 예측에서 예측 모드들은 복수의 비방향성 모드와 복수의 방향성 모드를 포함할 수 있다. 비방향성 모드는 예를 들어 DC 모드 및 플래너 모드(Planar 모드)를 포함할 수 있다. 방향성 모드는 예측 방향의 세밀한 정도에 따라 예를 들어 33개의 방향성 예측 모드 또는 65개의 방향성 예측 모드를 포함할 수 있다. 다만, 이는 예시로서 설정에 따라 그 이상 또는 그 이하의 개수의 방향성 예측 모드들이 사용될 수 있다. 인트라 예측부(185)는 주변 블록에 적용된 예측 모드를 이용하여, 현재 블록에 적용되는 예측 모드를 결정할 수도 있다.
실시예들에 따른 인터 예측부(180)는 참조 픽처 상에서 움직임 벡터에 의해 특정되는 참조 블록(참조 샘플 어레이)을 기반으로, 현재 블록에 대한 예측된 블록을 유도할 수 있다. 이때, 인터 예측 모드에서 전송되는 움직임 정보의 양을 줄이기 위해 주변 블록과 현재 블록 간의 움직임 정보의 상관성에 기초하여 움직임 정보를 블록, 서브블록 또는 샘플 단위로 예측할 수 있다. 상기 움직임 정보는 움직임 벡터 및 참조 픽처 인덱스를 포함할 수 있다. 상기 움직임 정보는 인터 예측 방향(L0 예측, L1 예측, Bi 예측 등) 정보를 더 포함할 수 있다. 인터 예측의 경우에, 주변 블록은 현재 픽처 내에 존재하는 공간적 주변 블록(spatial neighboring block)과 참조 픽처에 존재하는 시간적 주변 블록(temporal neighboring block)을 포함할 수 있다. 상기 참조 블록을 포함하는 참조 픽처와 상기 시간적 주변 블록을 포함하는 참조 픽처는 동일할 수도 있고, 다를 수도 있다. 상기 시간적 주변 블록은 동일 위치 참조 블록(collocated reference block), 동일 위치 CU(colCU) 등의 이름으로 불릴 수 있으며, 상기 시간적 주변 블록을 포함하는 참조 픽처는 동일 위치 픽처(collocated picture, colPic)라고 불릴 수도 있다. 예를 들어, 인터 예측부(180)는 주변 블록들을 기반으로 움직임 정보 후보 리스트를 구성하고, 상기 현재 블록의 움직임 벡터 및/또는 참조 픽처 인덱스를 도출하기 위하여 어떤 후보가 사용되는지를 지시하는 정보를 생성할 수 있다. 다양한 예측 모드를 기반으로 인터 예측이 수행될 수 있으며, 예를 들어 스킵 모드와 머지 모드의 경우에, 인터 예측부(180)는 주변 블록의 움직임 정보를 현재 블록의 움직임 정보로 이용할 수 있다. 스킵 모드의 경우, 머지 모드와 달리 레지듀얼 신호가 전송되지 않을 수 있다. 움직임 정보 예측(motion vector prediction, MVP) 모드의 경우, 주변 블록의 움직임 벡터를 움직임 벡터 예측자(motion vector predictor)로 이용하고, 움직임 벡터 차분(motion vector difference)을 시그널링함으로써 현재 블록의 움직임 벡터를 지시할 수 있다.
실시예들에 따른 인터 예측부(180) 또는 인트라 예측부(185)를 통해 생성된 예측 신호는 복원 신호를 생성하기 위해 이용되거나 레지듀얼 신호를 생성하기 위해 이용될 수 있다.
실시예들에 따른 변환부(120)는 레지듀얼 신호에 변환 기법을 적용하여 변환 계수들(transform coefficients)를 생성할 수 있다. 예를 들어, 변환 기법은 DCT(Discrete Cosine Transform), DST(Discrete Sine Transform), KLT(Karhunen-Loeve Transform), GBT(Graph-Based Transform), 또는 CNT(Conditionally Non-linear Transform) 중 적어도 하나를 포함할 수 있다. 여기서, GBT는 픽셀 간의 관계 정보를 그래프로 표현한다고 할 때 이 그래프로부터 얻어진 변환을 의미한다. CNT는 이전에 복원된 모든 픽셀(all previously reconstructed pixel)를 이용하여 예측 신호를 생성하고 그에 기초하여 획득되는 변환을 의미한다. 또한, 변환 과정은 정사각형의 동일한 크기를 갖는 픽셀 블록에 적용될 수도 있고, 정사각형이 아닌 가변 크기의 블록에도 적용될 수 있다.
실시예들에 따른 양자화부(130)는 변환 계수들을 양자화하여 엔트로피 인코딩부(190)로 전송되고, 엔트로피 인코딩부(190)는 양자화된 신호(양자화된 변환 계수들에 관한 정보)를 인코딩하여 비트스트림으로 출력할 수 있다. 상기 양자화된 변환 계수들에 관한 정보는 레지듀얼 정보라고 불릴 수 있다. 양자화부(130)는 계수 스캔 순서(scan order)를 기반으로 블록 형태의 양자화된 변환 계수들을 1차원 벡터 형태로 재정렬할 수 있고, 상기 1차원 벡터 형태의 양자화된 변환 계수들을 기반으로 상기 양자화된 변환 계수들에 관한 정보를 생성할 수도 있다. 엔트로피 인코딩부(190)는 예를 들어 지수 골롬(exponential Golomb), CAVLC(context-adaptive variable length coding), CABAC(context-adaptive binary arithmetic coding) 등과 같은 다양한 인코딩 방법을 수행할 수 있다. 엔트로피 인코딩부(190)는 양자화된 변환 계수들 외 비디오/이미지 복원에 필요한 정보들(예컨대 신택스 요소들(syntax elements)의 값 등)을 함께 또는 별도로 인코딩할 수도 있다. 인코딩된 정보(ex. 인코딩된 비디오/영상 정보)는 비트스트림 형태로 NAL(network abstraction layer) 유닛 단위로 전송 또는 저장될 수 있다. 상기 비트스트림은 네트워크를 통하여 전송될 수 있고, 또는 디지털 저장매체에 저장될 수 있다. 여기서 네트워크는 방송망 및/또는 통신망 등을 포함할 수 있고, 디지털 저장매체는 USB, SD, CD, DVD, 블루레이, HDD, SSD 등 다양한 저장매체를 포함할 수 있다. 엔트로피 인코딩부(190)로부터 출력된 신호는 전송하는 전송부(미도시) 및/또는 저장하는 저장부(미도시)가 인코딩 장치(100)의 내/외부 엘리먼트로서 구성될 수 있고, 또는 전송부는 엔트로피 인코딩부(190)에 포함될 수도 있다.
실시예들에 따른 양자화부(130)로부터 출력된 양자화된 변환 계수들은 예측 신호를 생성하기 위해 이용될 수 있다. 예를 들어, 양자화된 변환 계수들에 역양자화부(140) 및 역변환부(150)를 통해 역양자화 및 역변환을 적용함으로써 레지듀얼 신호(레지듀얼 블록 or 레지듀얼 샘플들)를 복원할 수 있다. 가산부(155)는 복원된 레지듀얼 신호를 인터 예측부(180) 또는 인트라 예측부(185)로부터 출력된 예측 신호에 더함으로써 복원(reconstructed) 신호(복원 픽처, 복원 블록, 복원 샘플 어레이)가 생성될 수 있다. 스킵 모드가 적용된 경우와 같이 처리 대상 블록에 대한 레지듀얼이 없는 경우, 예측된 블록이 복원 블록으로 사용될 수 있다. 가산부(155)는 복원부 또는 복원 블록 생성부라고 불릴 수 있다. 생성된 복원 신호는 현재 픽처 내 다음 처리 대상 블록의 인트라 예측을 위하여 사용될 수 있고, 후술하는 바와 같이 필터링을 거쳐서 다음 픽처의 인터 예측을 위하여 사용될 수도 있다.
실시예들에 따른 필터링부(160)는 복원 신호에 필터링을 적용하여 주관적/객관적 화질을 향상시킬 수 있다. 예를 들어 필터링부(160)은 복원 픽처에 다양한 필터링 방법을 적용하여 수정된(modified) 복원 픽처를 생성할 수 있고, 상기 수정된 복원 픽처를 메모리(170), 구체적으로 메모리(170)의 DPB에 저장할 수 있다. 상기 다양한 필터링 방법은 예를 들어, 디블록킹 필터링, 샘플 적응적 오프셋(sample adaptive offset), 적응적 루프 필터(adaptive loop filter), 양방향 필터(bilateral filter) 등을 포함할 수 있다. 필터링부(160)은 각 필터링 방법에 대한 설명에서 후술하는 바와 같이 필터링에 관한 다양한 정보를 생성하여 엔트로피 인코딩부(190)로 전달할 수 있다. 필터링 관한 정보는 엔트로피 인코딩부(190)에서 인코딩되어 비트스트림 형태로 출력될 수 있다.
실시예들에 따른 메모리(170)에 전송된 수정된 복원 픽처는 인터 예측부(180)에서 참조 픽처로 사용될 수 있다. 인코딩 장치는 이를 통하여 인터 예측이 적용되는 경우, 인코딩 장치(100)와 디코딩 장치에서의 예측 미스매치를 피할 수 있고, 부호화 효율도 향상시킬 수 있다.
실시예들에 따른 메모리(170) DPB는 수정된 복원 픽처를 인터 예측부(180)에서의 참조 픽처로 사용하기 위해 저장할 수 있다. 메모리(170)는 현재 픽처 내 움직임 정보가 도출된(또는 인코딩된) 블록의 움직임 정보 및/또는 이미 복원된 픽처 내 블록들의 움직임 정보를 저장할 수 있다. 상기 저장된 움직임 정보는 공간적 주변 블록의 움직임 정보 또는 시간적 주변 블록의 움직임 정보로 활용하기 위하여 인터 예측부(180)에 전달할 수 있다. 메모리(170)는 현재 픽처 내 복원된 블록들의 복원 샘플들을 저장할 수 있고, 인트라 예측부(185)에 전달할 수 있다.
한편, 상술한 예측, 변환, 양자화 절차 중 적어도 하나가 생략될 수도 있다. 예를 들어, PCM(pulse coding mode)가 적용되는 블록에 대하여는 예측, 변환, 양자화 절차를 생략하고 원본 샘플의 값이 그대로 인코딩되어 비트스트림으로 출력될 수도 있다.
도38은 실시예들에 따른 V-PCC decoding process 을 나타낸다.
실시예들에 따른 도면은 압축된 occupancy map, geometry image, texture image, auxiliary path information 복호화하여 point cloud를 재구성하기 위한 V-PCC의 decoding process를 도시하여 보여주고 있다. 같다. 각 process의 동작은 다음과 같다.
실시예들에 따른 Video decompression:
앞서 설명한 video compression의 역과정으로, HEVC, VVC 등의 2D video codec을 이용하여, 앞서 설명한 과정으로 생성된 geometry image, texture image, occupancy map image 등의 compressed bitstream을 복호화하는 과정이다.
도39는 실시예들에 따른 2D video/image decoder 을 나타낸다.
도면은 Video decompression이 적용되는 실시예로서, 비디오/영상 신호의 디코딩이 수행되는 2D video/image decoder(200)의 개략적인 블록도를 나타낸다. 상기 2D video/image decoder(200)은 상술한 point cloud video decoder에 포함될 수 있고, 또는 내/외부 컴포넌트로 구성될 수도 있다. 여기서 입력 비트스트림은 상술한 geometry image, texture image (attribute(s) image), occupancy map image 등에 대한 비트스트림을 포함할 수 있다. 상기 복원 영상(또는 출력 영상, 디코딩된 영상)은 상술한 geometry image, texture image (attribute(s) image), occupancy map image에 대한 복원 영상을 나타낼 수 있다.
도면들을 참조하면, 디코딩 장치(200)는 엔트로피 디코딩부(210), 역양자화부(220), 역변환부(230), 가산부(235), 필터링부(240), 메모리(250), 인터 예측부(260) 및 인트라 예측부(265)를 포함하여 구성될 수 있다. 인터 예측부(260) 및 인트라 예측부(265)를 합쳐서 예측부라고 불릴 수 있다. 즉, 예측부는 인터 예측부(180) 및 인트라 예측부(185)를 포함할 수 있다. 역양자화부(220), 역변환부(230)를 합쳐서 레지듀얼 처리부라고 불릴 수 있다. 즉, 레지듀얼 처리부는 역양자화부(220), 역변환부(230)을 포함할 수 있다. 상술한 엔트로피 디코딩부(210), 역양자화부(220), 역변환부(230), 가산부(235), 필터링부(240), 인터 예측부(260) 및 인트라 예측부(265)는 실시예에 따라 하나의 하드웨어 컴포넌트(예를 들어 디코더 또는 프로세서)에 의하여 구성될 수 있다. 또한 메모리(170)는 DPB(decoded picture buffer)를 포함할 수 있고, 디지털 저장 매체에 의하여 구성될 수도 있다.
실시예들에 따른 비디오/영상 정보를 포함하는 비트스트림이 입력되면, 디코딩 장치(200)는 도 0.2-1의 인코딩 장치에서 비디오/영상 정보가 처리된 프로세스에 대응하여 영상을 복원할 수 있다. 예를 들어, 디코딩 장치(200)는 인코딩 장치에서 적용된 처리 유닛을 이용하여 디코딩을 수행할 수 있다. 따라서 디코딩의 처리 유닛은 예를 들어 코딩 유닛일 수 있고, 코딩 유닛은 코딩 트리 유닛 또는 최대 코딩 유닛으로부터 쿼드 트리 구조 및/또는 바이너리 트리 구조를 따라서 분할될 수 있다. 그리고, 디코딩 장치(200)를 통해 디코딩 및 출력된 복원 영상 신호는 재생 장치를 통해 재생될 수 있다.
실시예들에 따른 디코딩 장치(200)는 도면의 인코딩 장치로부터 출력된 신호를 비트스트림 형태로 수신할 수 있고, 수신된 신호는 엔트로피 디코딩부(210)를 통해 디코딩될 수 있다. 예를 들어, 엔트로피 디코딩부(210)는 상기 비트스트림을 파싱하여 영상 복원(또는 픽처 복원)에 필요한 정보(ex. 비디오/영상 정보)를 도출할 수 있다. 예컨대, 엔트로피 디코딩부(210)는 지수 골롬 부호화, CAVLC 또는 CABAC 등의 코딩 방법을 기초로 비트스트림 내 정보를 디코딩하고, 영상 복원에 필요한 신택스 엘리먼트의 값, 레지듀얼에 관한 변환 계수의 양자화된 값 들을 출력할 수 있다. 보다 상세하게, CABAC 엔트로피 디코딩 방법은, 비트스트림에서 각 구문 요소에 해당하는 빈을 수신하고, 디코딩 대상 구문 요소 정보와 주변 및 디코딩 대상 블록의 디코딩 정보 혹은 이전 단계에서 디코딩된 심볼/빈의 정보를 이용하여 문맥(context) 모델을 결정하고, 결정된 문맥 모델에 따라 빈(bin)의 발생 확률을 예측하여 빈의 산술 디코딩(arithmetic decoding)를 수행하여 각 구문 요소의 값에 해당하는 심볼을 생성할 수 있다. 이때, CABAC 엔트로피 디코딩 방법은 문맥 모델 결정 후 다음 심볼/빈의 문맥 모델을 위해 디코딩된 심볼/빈의 정보를 이용하여 문맥 모델을 업데이트할 수 있다. 엔트로피 디코딩부(210)에서 디코딩된 정보 중 예측에 관한 정보는 예측부(인터 예측부(260) 및 인트라 예측부(265))로 제공되고, 엔트로피 디코딩부(210)에서 엔트로피 디코딩이 수행된 레지듀얼 값, 즉 양자화된 변환 계수들 및 관련 파라미터 정보는 역양자화부(220)로 입력될 수 있다. 또한, 엔트로피 디코딩부(210)에서 디코딩된 정보 중 필터링에 관한 정보는 필터링부(240)으로 제공될 수 있다. 한편, 인코딩 장치로부터 출력된 신호를 수신하는 수신부(미도시)가 디코딩 장치(200)의 내/외부 엘리먼트로서 더 구성될 수 있고, 또는 수신부는 엔트로피 디코딩부(210)의 구성요소일 수도 있다.
실시예들에 따른 역양자화부(220)에서는 양자화된 변환 계수들을 역양자화하여 변환 계수들을 출력할 수 있다. 역양자화부(220)는 양자화된 변환 계수들을 2차원의 블록 형태로 재정렬할 수 있다. 이 경우 상기 재정렬은 인코딩 장치에서 수행된 계수 스캔 순서를 기반하여 재정렬을 수행할 수 있다. 역양자화부(220)는 양자화 파라미터(예를 들어 양자화 스텝 사이즈 정보)를 이용하여 양자화된 변환 계수들에 대한 역양자화를 수행하고, 변환 계수들(transform coefficient)를 획득할 수 있다.
실시예들에 따른 역변환부(230)에서는 변환 계수들를 역변환하여 레지듀얼 신호(레지듀얼 블록, 레지듀얼 샘플 어레이)를 획득하게 된다.
실시예들에 따른 예측부는 현재 블록에 대한 예측을 수행하고, 상기 현재 블록에 대한 예측 샘플들을 포함하는 예측된 블록(predicted block)을 생성할 수 있다. 예측부는 엔트로피 디코딩부(210)로부터 출력된 상기 예측에 관한 정보를 기반으로 상기 현재 블록에 인트라 예측이 적용되는지 또는 인터 예측이 적용되는지 결정할 수 있고, 구체적인 인트라/인터 예측 모드를 결정할 수 있다.
실시예들에 따른 인트라 예측부(265)는 현재 픽처 내의 샘플들을 참조하여 현재 블록을 예측할 수 있다. 상기 참조되는 샘플들은 예측 모드에 따라 상기 현재 블록의 주변(neighbor)에 위치할 수 있고, 또는 떨어져서 위치할 수도 있다. 인트라 예측에서 예측 모드들은 복수의 비방향성 모드와 복수의 방향성 모드를 포함할 수 있다. 인트라 예측부(265)는 주변 블록에 적용된 예측 모드를 이용하여, 현재 블록에 적용되는 예측 모드를 결정할 수도 있다.
실시예들에 따른 인터 예측부(260)는 참조 픽처 상에서 움직임 벡터에 의해 특정되는 참조 블록(참조 샘플 어레이)을 기반으로, 현재 블록에 대한 예측된 블록을 유도할 수 있다. 이때, 인터 예측 모드에서 전송되는 움직임 정보의 양을 줄이기 위해 주변 블록과 현재 블록 간의 움직임 정보의 상관성에 기초하여 움직임 정보를 블록, 서브블록 또는 샘플 단위로 예측할 수 있다. 상기 움직임 정보는 움직임 벡터 및 참조 픽처 인덱스를 포함할 수 있다. 상기 움직임 정보는 인터 예측 방향(L0 예측, L1 예측, Bi 예측 등) 정보를 더 포함할 수 있다. 인터 예측의 경우에, 주변 블록은 현재 픽처 내에 존재하는 공간적 주변 블록(spatial neighboring block)과 참조 픽처에 존재하는 시간적 주변 블록(temporal neighboring block)을 포함할 수 있다. 예를 들어, 인터 예측부(260)는 주변 블록들을 기반으로 움직임 정보 후보 리스트를 구성하고, 수신한 후보 선택 정보를 기반으로 상기 현재 블록의 움직임 벡터 및/또는 참조 픽처 인덱스를 도출할 수 있다. 다양한 예측 모드를 기반으로 인터 예측이 수행될 수 있으며, 상기 예측에 관한 정보는 상기 현재 블록에 대한 인터 예측의 모드를 지시하는 정보를 포함할 수 있다.
실시예들에 따른 가산부(235)는 획득된 레지듀얼 신호를 인터 예측부(260) 또는 인트라 예측부(265)로부터 출력된 예측 신호(예측된 블록, 예측 샘플 어레이)에 더함으로써 복원 신호(복원 픽처, 복원 블록, 복원 샘플 어레이)를 생성할 수 있다. 스킵 모드가 적용된 경우와 같이 처리 대상 블록에 대한 레지듀얼이 없는 경우, 예측된 블록이 복원 블록으로 사용될 수 있다.
실시예들에 따른 가산부(235)는 복원부 또는 복원 블록 생성부라고 불릴 수 있다. 생성된 복원 신호는 현재 픽처 내 다음 처리 대상 블록의 인트라 예측을 위하여 사용될 수 있고, 후술하는 바와 같이 필터링을 거쳐서 다음 픽처의 인터 예측을 위하여 사용될 수도 있다.
실시예들에 따른 필터링부(240)는 복원 신호에 필터링을 적용하여 주관적/객관적 화질을 향상시킬 수 있다. 예를 들어 필터링부(240)는 복원 픽처에 다양한 필터링 방법을 적용하여 수정된(modified) 복원 픽처를 생성할 수 있고, 상기 수정된 복원 픽처를 메모리(250), 구체적으로 메모리(250)의 DPB에 전송할 수 있다. 상기 다양한 필터링 방법은 예를 들어, 디블록킹 필터링, 샘플 적응적 오프셋(sample adaptive offset), 적응적 루프 필터(adaptive loop filter), 양방향 필터(bilateral filter) 등을 포함할 수 있다.
실시예들에 따른 메모리(250)의 DPB에 저장된 (수정된) 복원 픽처는 인터 예측부(260)에서 참조 픽쳐로 사용될 수 있다. 메모리(250)는 현재 픽처 내 움직임 정보가 도출된(또는 디코딩된) 블록의 움직임 정보 및/또는 이미 복원된 픽처 내 블록들의 움직임 정보를 저장할 수 있다. 상기 저장된 움직임 정보는 공간적 주변 블록의 움직임 정보 또는 시간적 주변 블록의 움직임 정보로 활용하기 위하여 인터 예측부(260)에 전달할 수 있다. 메모리(170)는 현재 픽처 내 복원된 블록들의 복원 샘플들을 저장할 수 있고, 인트라 예측부(265)에 전달할 수 있다.
실시예들에 따라, 인코딩 장치(100)의 필터링부(160), 인터 예측부(180) 및 인트라 예측부(185)에서 설명된 실시예들은 각각 디코딩 장치(200)의 필터링부(240), 인터 예측부(260) 및 인트라 예측부(265)에도 동일 또는 대응되도록 적용될 수 있다.
한편, 상술한 예측, 변환, 양자화 절차 중 적어도 하나가 생략될 수도 있다. 예를 들어, PCM(pulse coding mode)가 적용되는 블록에 대하여는 예측, 변환, 양자화 절차를 생략하고 디코딩된 샘플의 값이 그대로 복원 영상의 샘플로 사용될 수도 있다.
실시예들에 따른 Occupancy map decompression:
앞서 설명한 occupancy map compression의 역과정으로, 압축된 occupancy map bitstream을 복호화하여 occupancy map을 복원하기 위한 과정이다.
실시예들에 따른 Auxiliary patch info decompression:
앞서 설명한 auxiliary patch info compression의 역과정으로, 압축된 auxiliary patch info bitstream 를 복호화하여 auxiliary patch info를 복원하기 위한 과정이다.
실시예들에 따른 Geometry reconstruction:
앞서 설명한 geometry image generation의 역과정이다. 먼저, 복원된 occupancy map 과 auxiliary patch info에 포함되는 patch의 2D 위치/크기 정보 및 block과 patch의 맵핑 정보를 이용하여 geometry image에서 patch를 추출한다. 이후 추출된 patch의 geometry image와 auxiliary patch info에 포함되는 patch의 3D 위치 정보를 이용하여 point cloud를 3차원 공간상에 복원한다. 하나의 patch내에 존재하는 임의의 점 (u, v)에 해당하는 geometry 값을 g(u, v)라 하고, patch의 3차원 공간상 위치의 normal 축, tangent 축, bitangent 축 좌표값을 (0, s0, r0)라 할 때, 점 (u, v)에 맵핑되는 3차원 공간상 위치의 normal 축, tangent 축, bitangent 축 좌표값인 (u, v), s(u, v), r(u, v)는 다음과 같이 나타낼 수 있다.
d(u, v) = d0 + g(u, v)
s(u, v) = s0 + u
r(u, v) = r0 + v
실시예들에 따른 Smoothing
앞서 설명한 encoding process에서의 smoothing과 동일하며, 압축 과정에서 발생하는 화질의 열화로 인해 patch 경계면에서 발생할 수 있는 불연속성을 제거하기 위한 과정이다.
실시예들에 따른 Texture reconstruction
Smoothing된 point cloud를 구성하는 각 점들에 color값을 부여하여 color point cloud를 복원하는 과정이다. 앞서 설명한 geometry reconstruction 과정에서의 geometry image와 point cloud의 맵핑 정보를 이용하여 2D 공간에서 geometry image에서와 동일한 위치의 texture image 픽셀에 해당되는 color 값들을, 3D 공간에서 동일한 위치에 대응되는 point cloud의 점에 부여함으로써 수행될 수 있다.
실시예들에 따른 Color smoothing
앞서 설명한 geometry smoothing의 과정과 유사하며, 압축 과정에서 발생하는 화질의 열화로 인해 patch 경계면에서 발생할 수 있는 color 값들의 불연속성을 제거하기 위한 작업이다. 다음과 같은 과정으로 수행될 수 있다.
① K-D tree 등을 이용하여 복원된 color point cloud를 구성하는 각 점들의 인접점들을 산출한다. 2.5절에서 설명한 geometry smoothing 과정에서 산출된 인접점 정보를 그대로 이용할 수도 있다.
② 각 점들에 대하여, 해당 점이 patch 경계면에 위치하는지를 판단한다. 앞서 설명한 geometry smoothing 과정에서 산출된 경계면 정보를 그대로 이용할 수도 있다.
③ 경계면에 존재하는 점의 인접점들에 대하여, color 값의 분포를 조사하여 smoothing 여부를 판단한다. 일례로, 휘도값의 entropy가 경계 값 (threshold local entry) 이하일 경우 (유사한 휘도 값들이 많을 경우), edge가 아닌 부분으로 판단하여 smoothing을 수행할 수 있다. Smoothing의 방법으로 인접접들의 평균값으로 해당 점의 color값을 바꾸는 방법 등이 사용될 수 있다
도40는 실시예들에 따른 송신단 동작 흐름도를 나타낸다.
실시예들에 따른 V-PCC를 이용한 포인트 클라우드 데이터의 압축 및 전송을 위한 송신단의 동작 과정은 도면과 같을 수 있다.
먼저, 포인트 클라우드(point cloud)의 2D 이미지 맵핑을 위한 패치 (patch)를 생성한다. 패치 생성의 결과물로 부가 패치 정보가 생성되며, 해당 정보는 지오메트리 이미지 (geometry image) 생성, 텍스처 이미지 (texture image) 생성, 스무딩 (smoothing)을 위한 지오메트리 복원과정에 사용될 수 있다. 생성된 패치들은 2D 이미지 안에 맵핑하는 패치 패킹 과정을 거치게 된다. 패치 패킹의 결과물로 오큐판시 맵 (occupancy map)을 생성할 수 있으며, 오큐판시 맵은 지오메트리 이미지 생성, 텍스처 이미지 생성, 스무딩을 위한 지오메트리 복원과정에 사용될 수 있다. 이후 부가 패치 정보와 오큐판시 맵을 이용하여 지오메트리 이미지가 생성되며, 생성된 지오메트리 이미지는 비디오 부호화를 통해 하나의 비트스트림 (bitstream)으로 부호화된다. 부호화 전처리는 이미지 패딩 절차를 포함할 수 있다. 생성된 지오메트리 이미지 또는 부호화된 지오메트리 비트스트림을 복호화하여 재생성된 지오메트리 이미지는 3차원 지오메트리 복원에 사용될 수 있고 이후 스무딩 과정을 거칠 수 있다. 텍스처 이미지 생성부는 (스무딩된) 3차원 지오메트리와 포인트 클라우드, 부가 패치 정보 및 오큐판시 맵을 이용하여 텍스처 이미지를 생성할 수 있다. 생성된 텍스처 이미지는 하나의 비디오 비트스트림으로 부호화될 수 있다. 부가 패치 정보는 메타데이터 부호화부에서 하나의 메타데이터 비트스트림으로 부호화될 수 있으며, 오큐판시 맵은 비디오 부호화부에서 하나의 비디오 비트스트림으로 부호화될 수 있다. 생성된 지오메트리, 텍스처 이미지, 오큐판시 맵의 비디오 비트스트림과 부가 패치 정보 메타데이터 비트스트림은 하나의 비트스트림으로 다중화되어 송신부를 통해 수신단에 전송될 수 있다. 또는 생성된 지오메트리, 텍스처 이미지, 오큐판시 맵의 비디오 비트스트림과 부가 패치 정보 메타데이터 비트스트림은 하나 이상의 트랙 데이터로 파일이 생성되거나 세그먼트로 인캡슐레이션 되어 송신부를 통해 수신단에 전송 될 수 있다.
실시예들에 따른 오큐판시 맵은 패치 매핑 및 전송 과정에서 패치 이외에 영역, 예를 들어 검은색 영역(패딩된 영역)일 수 있는 부분에 대한 분포 정보를 포함한다. 실시예들에 따른 디코더 또는 수신기는 오큐판시 맵 및 오실러리 패치 인포메이션에 기반하여 패치 및 패딩 영역을 식별할 수 있다.
도41는 실시예들에 따른 수신단 동작 흐름도를 나타낸다.
실시예들에 따른 V-PCC를 이용한 포인트 클라우드 데이터의 수신 및 복원을 위한 수신단의 동작 과정은 도면과 같을 수 있다.
수신된 포인트 클라우드의 비트스트림은 파일/세그먼트 디캡슐레이션 후 압축된 지오메트리 이미지, 텍스처 이미지, 오큐판시 맵의 비디오 비트스트림들과 부가 패치 정보 메테데이터 비트스트림으로 역다중화된다. 비디오 복호화부와 메타데이터 복호화부는 역다중화된 비디오 비트스트림들과 메타데이터 비트스트림을 복호화한다. 복호화된 지오메트리 이미지와 오큐판시 맵 및 부가 패치 정보를 이용하여 3차원 지오메트리가 복원되며 이후 스무딩 과정을 거친다. 스무딩된 3차원 지오메트리에 텍스처 이미지를 이용하여 컬러값을 부여함으로써 컬러 포인트 클라우드 영상/픽처가 복원될 수 있다. 이후 객관적/주관적 비주얼 퀄리티 향상을 위하여 컬러 스무딩 (color smoothing)과정을 추가적으로 수행할 수 있으며, 이를 통하여 도출된 수정된(modified) 포인트 클라우드 영상/픽처는 렌더링 과정을 통하여(ex. by 포인트 클라우드 렌더러)를 통해 사용자에게 보여진다. 한편, 상기 컬러 스무딩 과정은 경우에 따라 생략될 수 있다.
도42는 실시예들에 따른 V-PCC 기반 point cloud 데이터 저장 및 스트리밍을 위한 아키텍쳐를 나타낸다.
실시예들에서는 사용자에게 VR (Virtual Reality, 가상현실), AR (Augmented Reality, 증강현실), MR (Mixed Reality, 혼합현실), 및 자율 주행 등 다양한 서비스를 지원하는Point Cloud 데이터를 저장 및 스트리밍 방안을 제공한다.
도면은 Video-based Point Cloud Compression(이하 V-PCC) 를 기반으로 압축되는 point cloud 데이터를 저장 혹은 스트리밍을 위한 전체 아키텍쳐를 도시한 도면이다. Point cloud 데이터 저장 및 스트리밍의 과정은 획득 과정, 인코딩 과정, 전송 과정, 디코딩 과정, 랜더링 과정 및/또는 피드백 과정을 포함할 수 있다.
실시예들은 point cloud 미디어/콘텐츠/데이터를 효과적으로 제공하는 방안을 제안한다. Point cloud 미디어/콘텐츠/데이터를 효과적으로 제공하기 위하여 먼저, point cloud 비디오가 획득될 수 있다. 예를 들어 하나 이상의 카메라를 통하여 Point Cloud의 캡처, 합성 또는 생성 과정 등을 통한 Point Cloud 데이터를 획득할 수 있다. 이러한 획득 과정에 의해 각 포인트의 3D 위치(x, y, z 위치 값 등으로 나타낼 수 있다. 이하 이를 지오메트리라고 일컫는다), 각 포인트의 속성 (color, reflectance, transparency 등)을 포함하는 point cloud 비디오를 획득할 수 있으며 이를 포함하는, 예를 들어, PLY(Polygon File format or the Stanford Triangle format) 파일 등으로 생성 될 수 있다. 여러 개의 프레임을 갖는 point cloud 데이터의 경우 하나 이상의 파일들이 획득될 수 있다. 이러한 과정에서 point cloud 관련 메타데이터 (예를 들어 캡처 등과 관련된 메타데이터 등)가 생성될 수 있다.
캡쳐된 Point Cloud 비디오는 콘텐츠의 질을 향상시키기 위한 후처리가 필요할 수 있다. 영상 캡쳐 과정에서 카메라 장비가 제공하는 범위에서 최대/최소 깊이 값을 조정할 수 있지만 그 이후에도 원하지 않는 영역의 points 데이터들이 포함될 수 있어서 원하지 않는 영역(예, 배경)을 제거 한다거나, 또는 연결된 공간을 인식하고 구멍(spatial hole)을 메우는 후처리를 수행할 수 있다. 또한 공간 좌표계를 공유하는 카메라들로부터 추출된 Point Cloud는 캘리브레이션 과정을 통해 획득된 각 카메라의 위치 좌표를 기준으로 각 point들에 대한 글로벌 좌표계로의 변환 과정을 통해 하나의 콘텐츠로 통합될 수 있다. 이를 통해point들의 밀도가 높은 Point Cloud 비디오를 획득할 수도 있다.
Point Cloud 전처리부(point cloud pre-processing) 는 point cloud 비디오를 하나 이상의 픽처(picture)/프레임(frame)을 생성할 수 있다. 여기서 픽처(picture)/프레임(frame)은 일반적으로 특정 시간대의 하나의 영상을 나타내는 단위를 의미할 수 있다. Point cloud 비디오를 구성하는 점들을 하나 이상의 패치(point cloud를 구성하는 점들의 집합으로, 같은 patch에 속하는 점들은 3차원 공간상에서 서로 인접해 있으며 2D 이미지로의 맵핑 과정에서 6면의 bounding box 평면 중 같은 방향으로 맵핑되는 점들의 집합)로 나누어2D 평면에 맵핑할 때 2D 평면의 해당 위치에 데이터가 존재하는 여부를 0 또는 1의 값으로 알려주는 2진 맵 (binary map) 인어큐판시(occupancy) 맵 픽처/프레임을 생성할 수 있다. 그리고 Point Cloud 비디오를 이루는 각 점들의 위치 정보 (geometry)를 패치 단위로 표현하는 depth map 형태의 픽처/프레임인 지오메트리 픽처/프레임을 생성할 수 있다. Point cloud 비디오를 이루는 각 점들의 색상 정보를 패치 단위로 표현하는 픽처/프레임인 텍스처 픽츠/프레임을 생성할 수 있다.이러한 과정에서 개별 패치들로부터 point cloud를 재구성하기 위해 필요한 메타데이터가 생성될 수 있으며 이는 각 패치의2D/3D 공간에서의 위치, 크기 등 패치에 대한 정보를 포함할 수 있다. 이러한 픽처/프레임들이 시간순으로 연속적으로 생성되어 비디오 스트림 혹은 메타데이터 스트림을 구성할 수 있다.
Point Cloud 비디오 인코더는Point Cloud 비디오와 연관된 하나 이상의 비디오 스트림으로 인코딩할 수 있다. 하나의 비디오는 다수의 프레임을 포함할 수 있으며, 하나의 프레임은 정지 영상/픽처에 대응될 수 있다. 본 문서에서, Point Cloud 비디오라 함은 Point Cloud 영상/프레임/픽처를 포함할 수 있으며, Point Cloud 비디오는 Point Cloud 영상/프레임/픽처와 혼용되어 사용될 수 있다. Point Cloud 비디오 인코더는 Video-based Point Cloud Compression (V-PCC) 절차를 수행할 수 있다. Point Cloud 비디오 인코더는 압축 및 코딩 효율을 위하여 예측, 변환, 양자화, 엔트로피 코딩 등의 일련의 절차를 수행할 수 있다. 인코딩된 데이터(인코딩된 비디오/영상 정보)는 비트스트림(bitstream) 형태로 출력될 수 있다. V-PCC 절차에 기반하는 경우 Point Cloud 비디오 인코더는 Point Cloud 비디오를 후술하는 바와 같이 지오메트리 비디오, 어트리뷰트(attribute) 비디오, 어큐판시(occupancy) 맵 비디오, 그리고 메타데이터, 예를 들어 패치에 대한 정보로 나누어 인코딩할 수 있다. 상기 지오메트리 비디오는 지오메트리 이미지를 포함할 수 있고, 상기 어트리뷰트(attribute) 비디오는 어트리뷰트 이미지를 포함할 수 있고, 상기 어큐판시(occupancy) 맵 비디오는 어큐판시 맵 이미지를 포함할 수 있다. 상기 부가 정보인 패치 데이터는 패치 관련 정보를 포함할 수 있다. 상기 어트리뷰트 비디오/이미지는 텍스쳐 비디오/이미지를 포함할 수 있다.
Point Cloud 이미지 인코더는Point Cloud 비디오와 연관된 하나 이상의 이미지로 인코딩할 수 있다. Point Cloud이미지인코더는 Video-based Point Cloud Compression (V-PCC) 절차를 수행할 수 있다. Point Cloud이미지 인코더는 압축 및 코딩 효율을 위하여 예측, 변환, 양자화, 엔트로피 코딩 등의 일련의 절차를 수행할 수 있다. 인코딩된 이미지는 비트스트림(bitstream) 형태로 출력될 수 있다. V-PCC 절차에 기반하는 경우 Point Cloud이미지 인코더는 Point Cloud 이미지를 후술하는 바와 같이 지오메트리 이미지, 어트리뷰트(attribute) 이미지, 어큐판시(occupancy) 맵 이미지, 그리고 메타데이터, 예를 들어 패치에 대한 정보로 나누어 인코딩할 수 있다.
인캡슐레이션(file/segment encapsulation)는 인코딩된 Point cloud데이터 및/또는 Point cloud관련 메타데이터를 파일 또는 스트리밍을 위한 세그먼트 등의 형태로 인캡슐레이션할 수 있다. 여기서 Point cloud 관련 메타데이터는 메타데이터 처리부 등으로부터 전달받은 것일 수 있다. 메타데이터 처리부는 상기 point cloud 비디오/이미지 인코더에 포함될 수도 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 인캡슐레이션 처리부는 해당 비디오/이미지/메타데이터를 ISOBMFF 등의 파일 포맷으로 인캡슐레이션하거나, DASH 세그먼트 등의 형태로 처리할 수 있다. 인캡슐레이션 처리부는 실시 예에 따라 Point cloud관련 메타데이터를 파일 포맷 상에 포함시킬 수 있다. Point cloud 메타데이터는 예를 들어 ISOBMFF 파일 포맷 상의 다양한 레벨의 박스(box)에 포함되거나 파일 내에서 별도의 트랙내의 데이터로 포함될 수 있다. 실시 예에 따라, 인캡슐레이션 처리부는 Point cloud관련 메타데이터 자체를 파일로 인캡슐레이션할 수 있다.
전송 처리부는 파일 포맷에 따라 인캡슐레이션된 Point cloud데이터에 전송을 위한 처리를 가할 수 있다. 전송 처리부는 전송부에 포함될 수도 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 전송 처리부는 임의의 전송 프로토콜에 따라 Point cloud데이터를 처리할 수 있다. 전송을 위한 처리에는 방송망을 통한 전달을 위한 처리, 브로드밴드를 통한 전달을 위한 처리를 포함할 수 있다. 실시 예에 따라 전송 처리부는 Point cloud 데이터 뿐 아니라, 메타데이터 처리부로부터 Point cloud 관련 메타데이터를 전달받아, 이 것에 전송을 위한 처리를 가할 수도 있다.
전송부는 point cloud 비트스트림 혹은 해당 비트스트림을 포함하는 파일/세그먼트를 디지털 저장매체 또는 네트워크를 통하여 수신 디바이스의 수신부로 전달할 수 있다. 전송을 위해 임의의 전송 프로토콜에 따른 처리가 수행될 수 있다. 전송을 위한 처리를 마친 데이터들은 방송망 및/또는 브로드밴드를 통해 전달될 수 있다. 이 데이터들은 온 디맨드(On Demand) 방식으로 수신측으로 전달될 수도 있다.디지털 저장 매체는 USB, SD, CD, DVD, 블루레이, HDD, SSD 등 다양한 저장 매체를 포함할 수 있다. 전송부는 미리 정해진 파일 포멧을 통하여 미디어 파일을 생성하기 위한 엘리먼트를 포함할 수 있고, 방송/통신 네트워크를 통한 전송을 위한 엘레멘트를 포함할 수 있다. 수신부는 상기 비트스트림을 추출하여 디코딩 장치로 전달할 수 있다.
수신부는 실시예들에 따른 point cloud 데이터 전송 장치가 전송한 point cloud 데이터를 수신할 수 있다. 전송되는 채널에 따라 수신부는 방송망을 통하여 point cloud데이터를 수신할 수도 있고, 브로드밴드를 통하여 point cloud데이터를 수신할 수도 있다. 혹은 디지털 저장 매체를 통하여 point cloud 비디오 데이터를 수신할 수도 있다. 수신부는 수신한 데이터를 디코딩 하고 이를 사용자의 뷰포트 등에 따라 랜더링하는 과정을 포함할 수 있다.
수신 처리부는 수신된 point cloud비디오 데이터에 대해 전송 프로토콜에 따른 처리를 수행할 수 있다. 수신 처리부는 수신부에 포함될 수 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 전송측에서 전송을 위한 처리가 수행된 것에 대응되도록, 수신 처리부는 전술한 전송 처리부의 역과정을 수행할 수 있다. 수신 처리부는 획득한 point cloud 비디오를 디캡슐레이션 처리부로 전달하고, 획득한 point cloud 관련 메타데이터는 메타데이터 파서로 전달할 수 있다.
디캡슐레이션 처리부(file/segment decapsulation)는 수신 처리부로부터 전달받은 파일 형태의 point cloud데이터를 디캡슐레이션할 수 있다. 디캡슐레이션 처리부는 ISOBMFF 등에 따른 파일들을 디캡슐레이션하여, point cloud비트스트림 내지 point cloud 관련 메타데이터(혹은 별도의 메타데이터 비트스트림)를 획득할 수 있다. 획득된 point cloud비트스트림은 상기 point cloud디코더로, 획득된 point cloud관련 메타데이터(혹은 메타데이터 비트스트림)는 메타데이터 처리부로 전달할 수 있다. 상기 point cloud비트스트림은 상기 메타데이터(메타데이터 비트스트림)를 포함할 수도 있다. 상기 메타데이터 처리부는 상기 point cloud 비디오 디코더에 포함될 수도 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 디캡슐레이션 처리부가 획득하는 point cloud관련 메타데이터는 파일 포맷 내의 박스 혹은 트랙 형태일 수 있다. 디캡슐레이션 처리부는 필요한 경우 메타데이터 처리부로부터 디캡슐레이션에 필요한 메타데이터를 전달받을 수도 있다. 상기 point cloud관련 메타데이터는 상기 point cloud디코더에 전달되어 point cloud디코딩 절차에 사용될 수도 있고, 또는 렌더러에 전달되어 point cloud렌더링 절차에 사용될 수도 있다.
Point Cloud 비디오 디코더는 상기 비트스트림을 입력받아 상기 Point Cloud 비디오 인코더의 동작에 대응하는 동작을 수행하여 비디오/영상을 디코딩할 수 있다. 이 경우 Point Cloud 비디오 디코더는 Point Cloud 비디오를 후술하는 바와 같이 지오메트리 비디오, 어트리뷰트(attribute) 비디오, 어큐판시(occupancy) 맵 비디오, 그리고 부가적인 패치 관련 정보(auxiliary patch information )으로 나누어 디코딩할 수 있다. 상기 지오메트리 비디오는 지오메트리 이미지를 포함할 수 있고, 상기 어트리뷰트(attribute) 비디오는 어트리뷰트 이미지를 포함할 수 있고, 상기 어큐판시(occupancy) 맵 비디오는 어큐판시 맵 이미지를 포함할 수 있다. 상기 부가 정보는 부가 패치 정보(auxiliary patch information)를 포함할 수 있다. 상기 어트리뷰트 비디오/이미지는 텍스쳐 비디오/이미지를 포함할 수 있다.
디코딩된 지오메트리 이미지와 오큐판시 맵 및 부가 패치 정보를 이용하여 3차원 지오메트리가 복원되며 이후 스무딩 과정을 거칠 수 있다. 스무딩된 3차원 지오메트리에 텍스처 이미지를 이용하여 컬러값을 부여함으로써 컬러 포인트 클라우드 영상/픽처가 복원될 수 있다. 렌더러는 복원된 지오메트리, 컬러 포인트 클라우드 영상/픽처를렌더링할 수 있다. 렌더링된 비디오/영상은 디스플레이부를 통하여 디스플레이될 수 있다. 사용자는 VR/AR 디스플레이 또는 일반 디스플레이 등을 통하여 렌더링 된 결과의 전부 또는 일부 영역을 볼 수 있다.
센싱/트랙킹부(Sensing/Tracking)는 사용자 또는 수신측로부터 오리엔테이션 정보 및/또는 사용자 뷰포트 정보를 획득하여 수신부 및/또는 송신부에 전달한다. 오리엔테이션 정보는 사용자의 머리 위치, 각도, 움직임 등에 대한 정보를 나타내거나 혹은 사용자가 보고 있는 장치의 위치, 각도, 움직임 등에 대한 정보를 나타낼 수 있다. 이 정보를 기반으로 사용자가 현재 3차원 공간 상에서 보고 있는 영역에 대한 정보, 즉 뷰포트 정보가 계산될 수 있다.
뷰포트 정보는 현재 사용자가 3차원 공간 상에서 디바이스 혹은 HMD 등을 통하여 보고 있는 영역에 대한 정보일 수 있다. 디스플레이 등의 장치는 오리엔테이션 정보, 장치가 지원하는 수직(vertical) 혹은 수평(horizontal) FOV 등에 근거하여 뷰포트 영역을 추출할 수 있다. 오리엔테이션 혹은 뷰포트 정보는 수신측에서 추출 혹은 계산될 수 있다. 수신측에서 분석된 오리엔테이션 혹은 뷰포트 정보는 송신측으로 피드백 채널을 통해 전달될 수도 있다.
수신부는 센싱/트랙킹부에 의해 획득된 오리엔테이션 정보 및/또는사용자가 현재 보고 있는 영역을 나타내는뷰포트 정보를 사용하여 특정 영역, 즉 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 영역의 미디어 데이터만 효율적으로 파일에서 추출하거나 디코딩할 수 있다. 또한, 송신부는 센싱/트랙부에 의해 획득된 오리엔테이션 정보 및/또는 뷰포트 정보를 사용하여 특정 영역, 즉 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 영역의 미디어 데이터만 효율적으로 인코딩하거나 파일 생성 및 전송할 수 있다.
렌더러는 3차원 공간 상에 디코딩된 Point Cloud 데이터를 렌더링 할 수 있다. 렌더링된 비디오/영상은 디스플레이부를 통하여 디스플레이될 수 있다. 사용자는 VR/AR 디스플레이 또는 일반 디스플레이 등을 통하여 렌더링 된 결과의 전부 또는 일부 영역을 볼 수 있다.
피드백 과정은 렌더링/디스플레이 과정에서 획득될 수 있는 다양한 피드백 정보들을 송신측으로 전달하거나 수신측의 디코더에 전달하는 과정을 포함할 수 있다. 피드백 과정을 통해 Point Cloud 데이터 소비에 있어 인터랙티비티(interactivity)가 제공될 수 있다. 실시예에 따라, 피드백 과정에서 헤드 오리엔테이션(Head Orientation) 정보, 사용자가 현재 보고 있는 영역을 나타내는 뷰포트(Viewport) 정보 등이 전달될 수 있다. 실시 예에 따라, 사용자는 VR/AR/MR/자율주행 환경 상에 구현된 것들과 상호작용 할 수도 있는데, 이 경우 그 상호작용과 관련된 정보가 피드백 과정에서 송신측 내지 서비스 프로바이더 측으로 전달될 수도 있다. 실시 예에 따라 피드백 과정은 수행되지 않을 수도 있다.
실시예에 따라 전술한 피드백 정보는 송신측으로 전달되는 것 뿐아니라, 수신측에서 소비될 수도 있다. 즉, 전술한 피드백 정보를 이용하여 수신측의 디캡슐레이션 처리, 디코딩, 렌더링 과정 등이 수행될 수 있다. 예를 들어, 오리엔테이션 정보 및/또는 뷰포트 정보를 이용하여 현재 사용자가 보고 있는 영역에 대한 point cloud 데이터가 우선적으로 디캡슐레이션, 디코딩 및 렌더링될 수도 있다.
도43은 실시예들에 따른 point cloud 데이터 저장 및 전송 장치를 나타낸다.
실시예들에 따른 Point Cloud 데이터 저장 및 전송 장치는 Point Cloud 획득부(Point Cloud Acquisition), 패치 제너레이션(Patch Generation), 지오메트리 이미지 제너레이션(Geometry Image Generation), 어트리뷰트 이미지 제너레이션(Attribute Image Generation), 어큐판시 맵 제너레이션(Occupancy Map Generation), Auxiliary 데이터 제너레이션(Auxiliary Data Generation), Mesh 데이터 제너레이션(Mesh Data Generation), 비디오 인코딩(Video Encoding), 이미지 인코딩(Image Encoding), 파일/세그먼트 인캡슐레이션부(File/Segment Encapsulation),딜리버리부(Delivery)를 포함한다. 실시예들에 따라서, 패치 제너레이션, 지오메트리 이미지 제너레이션, 어트리뷰트 이미지 제너레이션, 어큐판시 맵 제너레이션, Auxiliary 데이터 제너레이션, Mesh 데이터 제너레이션은 포인트 클라우드 프리-프로세싱(Point Cloud Pre-processing), 프리-프로세서 또는 제어부라고 명명할 수 있다. 비디오 인코딩부는 지오메트리 비디오 컴프레션(Geometry video compression), 어트리뷰트 비디오 컴프레션(Attribute video compression), 어큐판시 맵 컴프레션(Occupancy map compression), Auxiliary 데이터 컴프레션(Auxiliary data compression), Mesh 데이터 컴프레션(Mesh data compression)을 포함한다. 이미지 인코딩부는 지오메트리 비디오 컴프레션(Geometry video compression), 어트리뷰트 비디오 컴프레션(Attribute video compression), 어큐판시 맵 컴프레션(Occupancy map compression), Auxiliary 데이터 컴프레션(Auxiliary data compression), Mesh 데이터 컴프레션(Mesh data compression)을 포함한다. 파일/세그먼트 인캡슐레이션부는 비디오 트랙 인캡슐레이션(Video Track Encapsulation), 메타데이터 트랙 인캡슐레이션(Metadata Track Encapsulation), 이미지 인캡슐레이션(Image Encapsulation)을 포함한다. 전송 장치의 각 구성은 모듈/유닛/컴포넌트/하드웨어/소프트웨어/프로세서 등일 수 있다.
Point cloud 의 geometry, attribute, auxiliary data, mesh data 등은 각각 별도의 스트림으로 구성되거나 혹은 파일 내 각각 다른 트랙에 저장될 수 있다. 더 나아가 별도의 세그먼트에 포함될 수 있다.
Point Cloud 획득부(Point Cloud Acquisition)은 point cloud 를 획득한다. 예를 들어 하나 이상의 카메라를 통하여 Point Cloud의 캡쳐, 합성 또는 생성 과정 등을 통한 Point Cloud 데이터를 획득할 수 있다. 이러한 획득 과정에 의해 각 포인트의 3D 위치(x, y, z 위치 값 등으로 나타낼 수 있다. 이하 이를 지오메트리라고 일컫는다), 각 포인트의 속성 (color, reflectance, transparency 등)을 포함하는 point cloud 데이터를 획득할 수 있으며 이를 포함하는, 예를 들어, PLY(Polygon File format or the Stanford Triangle format) 파일 등으로 생성 될 수 있다. 여러 개의 프레임을 갖는 point cloud 데이터의 경우 하나 이상의 파일들이 획득될 수 있다. 이러한 과정에서 point cloud 관련 메타데이터 (예를 들어 캡처 등과 관련된 메타데이터 등)가 생성될 수 있다.
패치 제너레이션(Patch Generation) 또는 패치 제너레이터는 포인트 클라우드 데이터로부터 패치를 생성한다. 패치 제너레이터는 포인트 클라우드 데이터 또는 포인트 클라우드 비디오를 하나 이상의 픽처(picture)/프레임(frame)으로 생성한다. 픽처(picture)/프레임(frame)은 일반적으로 특정 시간대의 하나의 영상을 나타내는 단위를 의미할 수 있다. Point cloud 비디오를 구성하는 점들을 하나 이상의 패치(point cloud를 구성하는 점들의 집합으로, 같은 patch에 속하는 점들은 3차원 공간상에서 서로 인접해 있으며 2D 이미지로의 맵핑 과정에서 6면의 bounding box 평면 중 같은 방향으로 맵핑되는 점들의 집합)로 나누어2D 평면에 맵핑할 때 2D 평면의 해당 위치에 데이터가 존재하는 여부를 0 또는 1의 값으로 알려주는 2진 맵 (binary map) 인 어큐판시(occupancy) 맵 픽처/프레임을 생성할 수 있다. 그리고 Point Cloud 비디오를 이루는 각 점들의 위치 정보 (geometry)를 패치 단위로 표현하는 depth map 형태의 픽처/프레임인 지오메트리 픽처/프레임을 생성할 수 있다. Point cloud 비디오를 이루는 각 점들의 색상 정보를 패치 단위로 표현하는 픽처/프레임인 텍스처 픽처/프레임을 생성할 수 있다. 이러한 과정에서 개별 패치들로부터 point cloud를 재구성하기 위해 필요한 메타데이터가 생성될 수 있으며 이는 각 패치의2D/3D 공간에서의 위치, 크기 등 패치에 대한 정보를 포함할 수 있다. 이러한 픽처/프레임들이 시간순으로 연속적으로 생성되어 비디오 스트림 혹은 메타데이터 스트림을 구성할 수 있다.
또한, 패치는 2D 이미지 맵핑을 위해 사용될 수 있다. 예를 들어, 포인트 클라우드 데이터가 정육면체의 각 면에 프로젝션될 수 있다. 패치 제너레이션 후, 생성된 패치를 기반으로 지오메트리 이미지, 하나 또는 하나 이상의 어트리뷰트 이미지, 어큐판시 맵, Auxiliary 데이터 및/또는 Mesh 데이터 등이 생성될 수 있다.
프리-프로세서 또는 제어부(controller)에 의해 지오메트리 이미지 제너레이션(Geometry Image Generation), 어트리뷰트 이미지 제너레이션(Attribute Image Generation), 어큐판시 맵 제너레이션(Occupancy Map Generation), Auxiliary 데이터 제너레이션(Auxiliary Data Generation) 및/또는 Mesh 데이터 제너레이션(Mesh Data Generation)이 수행된다.
지오메트리 이미지 제너레이션(Geometry Image Generation)은 패치 제너레이션의 결과물에 기반하여 지오메트리 이미지를 생성한다. 지오메트리는 3차원 공간상의 포인트를 나타낸다. 패치에 기반하여 패치의 2D이미지 패킹에 관련된 정보를 포함하는 어큐판시 맵, Auxiliary 데이터(패치 데이터) 및/또는 Mesh 데이터 등을 사용하여, 지오메트리 이미지가 생성된다. 지오메트리 이미지는 패치 제너레이션 후 생성된 패치에 대한 뎁스(e.g., near, far) 등의 정보와 관련된다.
어트리뷰트 이미지 제너레이션(Attribute Image Generation)은 어트리뷰트 이미지를 생성한다. 예를 들어, 어트리뷰트는 텍스쳐(Texture)를 나타낼 수 있다. 텍스쳐는 각 포인트에 매칭되는 컬러 값일 수 있다. 실시예들에 따라서, 텍스쳐를 포함한 복수 개(N개)의 어트리뷰트(color, reflectance 등의 속성) 이미지가 생성될 수 있다. 복수 개의 어트리뷰트는 머터리얼 (재질에 대한 정보), 리플렉턴스 등을 포함할 수 있다. 또한, 실시예들에 따라 어트리뷰트는 같은 텍스쳐라도 시각, 빛에 의해 컬러가 달라질 수 있는 정보를 추가적으로 포함할 수 있다.
어큐판시 맵 제너레이션(Occupancy Map Generation)은 패치로부터 어큐판시 맵을 생성한다. 어큐판시 맵은 해당 지오메트리 혹은 에트리뷰트 이미지 등의 픽셀에 데이터의 존재 유무를 나타내는 정보를 포함한다.
Auxiliary 데이터 제너레이션(Auxiliary Data Generation)은 패치에 대한 정보를 포함하는Auxiliary 데이터를 생성한다. 즉, Auxiliary 데이터는 Point Cloud객체의 패치에 관한 메타데이터를 나타낸다. 예를 들어, 패치에 대한 노멀(normal) 벡터 등의 정보를 나타낼 수 있다. 구체적으로, 실시예들에 따라 Auxiliary 데이터는 패치들로부터 포인트 클라우드를 재구성하기 위해서 필요한 정보를 포함할 수 있다(예를 들어, 패치의 2D/3D 공간 상 위치, 크기 등에 대한 정보, 프로젝션 평명(normal) 식별 정보, 패치 매핑 정보 등)
Mesh 데이터 제너레이션(Mesh Data Generation)은 패치로부터 Mesh 데이터를 생성한다. Mesh 는 인접한 포인트 들간의 연결정보를 나타낸다. 예를 들어, 삼각형 형태의 데이터를 나타낼 수 있다. 예를 들어, 실시예들에 따른 Mesh 데이터는 각 포인트 간의커넥티비티(connectivity) 정보를 의미한다.
포인트 클라우드 프리-프로세서 또는 제어부는 패치 제너레이션, 지오메트리 이미지 제너레이션, 어트리뷰트 이미지 제너레이션, 어큐판시 맵 제너레이션, Auxiliary 데이터 제너레이션, Mesh 데이터 제너레이션에 관련된 메타데이터(Metadata)를 생성한다.
포인트 클라우드 전송 장치는 프리-프로세서에서 생성된 결과물에 대응하여 비디오 인코딩 및/또는 이미지 인코딩을 수행한다. 포인트 클라우드 전송 장치는 포인트 클라우드 비디오 데이터뿐만 아니라 포인트 클라우드 이미지 데이터를 생성할 수 있다.실시예들에 따라 포인트 클라우드 데이터는 오직 비디오 데이터, 오직 이미지 데이터 및/또는 비디오 데이터 및 이미지 데이터 둘 다를 포함하는 경우가 있을 수 있다.
비디오 인코딩부는 지오메트리 비디오 컴프레션, 어트리뷰트 비디오 컴프레션, 어큐판시 맵 컴프레션, Auxiliary 데이터 컴프레션 및/또는 Mesh 데이터 컴프레션을 수행한다. 비디오 인코딩부는 각 인코딩된 비디오 데이터를 포함하는 비디오 스트림(들)을 생성한다.
구체적으로, 지오메트리 비디오 컴프레션은 point cloud 지오메트리 비디오 데이터를 인코딩한다. 어트리뷰트 비디오 컴프레션은 point cloud 의 어트리뷰트 비디오 데이터를 인코딩한다. Auxiliary 데이터 컴프레션은 point cloud 비디오 데이터와 연관된 Auxiliary 데이터를 인코딩한다. Mesh 데이터 컴프레션(Mesh data compression)은 Point Cloud 비디오 데이터의 Mesh 데이터를 인코딩한다. 포인트 클라우드 비디오 인코딩부의 각 동작은 병렬적으로 수행될 수 있다.
이미지 인코딩부는 지오메트리 이미지 컴프레션, 어트리뷰트 이미지 컴프레션, 어큐판시 맵 컴프레션, Auxiliary 데이터 컴프레션 및/또는 Mesh 데이터 컴프레션을 수행한다. 이미지 인코딩부는 각 인코딩된 이미지 데이터를 포함하는 이미지(들)을 생성한다.
구체적으로, 지오메트리 이미지 컴프레션은 point cloud 지오메트리 이미지 데이터를 인코딩한다. 어트리뷰트 이미지 컴프레션은 point cloud 의 어트리뷰트 이미지 데이터를 인코딩한다. Auxiliary 데이터 컴프레션은 point cloud 이미지 데이터와 연관된 Auxiliary 데이터를 인코딩한다. Mesh 데이터 컴프레션(Mesh data compression)은 point cloud 이미지 데이터와 연관된 Mesh 데이터를 인코딩한다. 포인트 클라우드 이미지 인코딩부의 각 동작은 병렬적으로 수행될 수 있다.
비디오 인코딩부 및/또는 이미지 인코딩부는 프리-프로세서로부터 메타데이터를 수신할 수 있다. 비디오 인코딩부 및/또는 이미지 인코딩부는 메타데이터에 기반하여 각 인코딩 과정을 수행할 수 있다.
파일/세그먼트 인캡슐레이션(File/Segment Encapsulation)부는 비디오 스트림(들) 및/또는 이미지(들)을 파일 및/또는 세그먼트의 형태로 인캡슐레이션한다. 파일/세그먼트 인캡슐레이션부는 비디오 트랙 인캡슐레이션, 메타데이터 트랙 인캡슐레이션 및/또는 이미지 인캡슐레이션을 수행한다.
비디오 트랙 인캡슐레이션은 하나 또는 하나 이상의 비디오 스트림을 하나 또는 하나 이상의 트랙에 인캡슐레이션할 수 있다.
메타데이터 트랙 인캡슐레이션은 비디오 스트림 및/또는 이미지에 관련된 메타데이터를 하나 또는 하나 이상의 트랙에 인캡슐레이션할 수 있다. 메타데이터는 포인트 클라우드 데이터의 컨텐츠에 관련된 데이터를 포함한다. 예를 들어, 이니셜 뷰잉 오리엔테이션 메타데이터(Initial Viewing Orientation Metadata)를 포함할 수 있다. 실시예들에 따라 메타데이터는 메타데이터 트랙에 인캡슐레이션 될 수 있고, 또는 비디오 트랙이나 이미지 트랙에 함께 인캡슐레이션될 수 있다.
이미지 인캡슐레이션은 하나 또는 하나 이상의 이미지들을 하나 또는 하나 이상의 트랙 혹은 아이템에 인캡슐레이션할 수 있다.
예를 들어,실시예들에 따라 비디오 스트림이 4개 및 이미지가 2개를 인캡슐레이션부에 입력되는 경우, 4개의 비디오 스트림 및 2개의 이미지를 하나의 파일 안에 인캡슐레이션할 수 있다.
파일/세그먼트 인캡슐레이션부는 프리-프로세서로부터 메타데이터를 수신할 수 있다. 파일/세그먼트 인캡슐레이션부는 메타데이터에 기반하여 인캡슐레이션을 할 수 있다.
파일/세그먼트 인캡슐레이션에 의해 생성된 파일 및/또는 세그먼트는 포인트 클라우드 전송 장치 또는 전송부에 의해서 전송된다. 예를 들어, DASH 기반의 프로토콜에 기반하여 세그먼트(들)이 딜리버리(Delivery)될 수 있다.
딜리버리부(Delivery)는 point cloud 비트스트림 혹은 해당 비트스트림을 포함하는 파일/세그먼트를 디지털 저장매체 또는 네트워크를 통하여 수신 디바이스의 수신부로 전달할 수 있다. 전송을 위해 임의의 전송 프로토콜에 따른 처리가 수행될 수 있다. 전송을 위한 처리를 마친 데이터들은 방송망 및/또는 브로드밴드를 통해 전달될 수 있다. 이 데이터들은 온 디맨드(On Demand) 방식으로 수신측으로 전달될 수도 있다.디지털 저장 매체는 USB, SD, CD, DVD, 블루레이, HDD, SSD 등 다양한 저장 매체를 포함할 수 있다. 딜리버리부는 미리 정해진 파일 포멧을 통하여 미디어 파일을 생성하기 위한 엘리먼트를 포함할 수 있고, 방송/통신 네트워크를 통한 전송을 위한 엘레멘트를 포함할 수 있다. 딜리버리부는 수신부로부터 오리엔테이션 정보 및/또는 뷰포트 정보를 수신한다. 딜리버리부는 획득한 오리엔테이션 정보 및/또는 뷰포트 정보(또는 사용자가 선택한 정보)를 프리-프로세서, 비디오 인코딩부, 이미지 인코딩부, 파일/세그먼트 인캡슐레이션부 및/또는 포인트 클라우드 인코딩부에 전달할 수 있다. 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 포인트 클라우드 인코딩부는 모든 포인트 클라우드 데이터를 인코딩하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 인코딩할 수 있다. 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 파일/세그먼트 인캡슐레이션부는 모든 포인트 클라우드 데이터를 인캡슐레이션하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 인캡슐레이션할 수 있다. 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 딜리버리부는 모든 포인트 클라우드 데이터를 딜리버리하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 딜리버리할 수 있다.
예를 들어, 프리-프로세서는 모든 포인트 클라우드 데이터에 대해 상술한 동작을 수행하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터에 대해 상술한 동작을 수행할 수 있다. 비디오 인코딩부 및/또는 이미지 인코딩부는 모든 포인트 클라우드 데이터에 대해 상술한 동작을 수행하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터에 대해 상술한 동작을 수행할 수 있다. 파일/세그먼트 인캡슐레이션부는 모든 포인트 클라우드 데이터에 대해 상술한 동작을 수행하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터에 대해 상술한 동작을 수행할 수 있다. 전송부는 모든 포인트 클라우드 데이터에 대해 상술한 동작을 수행하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터에 대해 상술한 동작을 수행할 수 있다.
도44는 실시예들에 따른 point cloud 데이터 수신 장치를 나타낸다.
실시예들에 따른 Point Cloud 데이터 수신 장치는 딜리버리 클라이언트(Delivery Client), 센싱/트랙킹부(Sensing/Tracking), 파일/세그먼트 디캡슐레이션부(File/Segment decapsulation), 비디오 디코딩부(Video Decoding), 이미지 디코딩부(Image Decoding), 포인트 클라우드 프로세싱 및/또는 Point Cloud 렌더링부(Point Cloud Rendering), 디스플레이를 포함한다. 비디오 디코딩부는 지오메트리 비디오 디컴프레션(Geometry Video Decompression), 어트리뷰트 비디오 디컴프레션(Attribute Video Decompresssion), 어큐판시 맵 디컴프레션(Occupancy Map Decompression), Auxiliary 데이터 디컴프레션(Auxiliary Data Decompression) 및/또는 Mesh 데이터 디컴프레션(Mesh Data Decompression)를 포함한다. 이미지 디코딩부는 지오메트리 이미지 디컴프레션(Geometry Image Decompression), 어트리뷰트 이미지 디컴프레션(Attribute Image Decompresssion), 어큐판시 맵 디컴프레션(Occupancy Map Decompression), Auxiliary 데이터 디컴프레션(Auxiliary Data Decompression) 및/또는 Mesh 데이터 디컴프레션(Mesh Data Decompression)를 포함한다. 포인트 클라우드 프로세싱은 지오메트리 리컨스턱션(Geometry Reconstruction), 어트리뷰트 리컨스트럭션(Attribute Reconstruction)를 포함한다.
수신 장치의 각 구성은 모듈/유닛/컴포넌트/하드웨어/소프트웨어/프로세서 등일 수 있다.
딜리버리 클라이언트(Delivery Client)는 실시예들에 따른 point cloud 데이터 전송 장치가 전송한 point cloud 데이터, point cloud 비트스트림 혹은 해당 비트스트림을 포함하는 파일/세그먼트를 수신할 수 있다. 전송되는 채널에 따라 수신부는 방송망을 통하여 point cloud데이터를 수신할 수도 있고, 브로드밴드를 통하여 point cloud데이터를 수신할 수도 있다. 혹은 디지털 저장 매체를 통하여 point cloud 비디오 데이터를 수신할 수도 있다. 수신부는 수신한 데이터를 디코딩 하고 이를 사용자의 뷰포트 등에 따라 랜더링하는 과정을 포함할 수 있다. 수신 처리부는 수신된 point cloud데이터에 대해 전송 프로토콜에 따른 처리를 수행할 수 있다. 수신 처리부는 수신부에 포함될 수 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 전송측에서 전송을 위한 처리가 수행된 것에 대응되도록, 수신 처리부는 전술한 전송 처리부의 역과정을 수행할 수 있다. 수신 처리부는 획득한 point cloud 데이터는 디캡슐레이션 처리부로 전달하고, 획득한 point cloud 관련 메타데이터는 메타데이터 파서로 전달할 수 있다.
센싱/트랙킹부(Sensing/Tracking)는 오리엔테이션 정보 및/또는 뷰포트 정보를 획득한다. 센싱/트랙킹부는 획득한 오리엔테이션 정보 및/또는 뷰포트 정보를 딜리버리 클라이언트, 파일/세그먼트 디캡슐레이션부, 포인트 클라우드 디코딩부에 전달할 수 있다.
딜리버리 클라이언트는 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 모든 포인트 클라우드 데이터를 수신하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 수신할 수 있다. 파일/세그먼트 디캡슐레이션부는 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 모든 포인트 클라우드 데이터를 디캡슐레이션하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 디캡슐레이션할 수 있다. 포인트 클라우드 디코딩부(비디오 디코딩부 및/또는 이미지 디코딩부)는 오리엔테이션 정보 및/또는 뷰포트 정보에 기반하여, 모든 포인트 클라우드 데이터를 디코딩하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 디코딩할 수 있다. 포인트 클라우드 프로세싱부는 모든 포인트 클라우드 데이터를 처리하거나 또는 오리엔테이션 정보 및/또는 뷰포트 정보가 나타내는 포인트 클라우드 데이터를 처리할 수 있다.
파일/세그먼트 디캡슐레이션부(File/Segment decapsulation)는 비디오 트랙 디캡슐레이션(Video Track Decapsulation), 메타데이터 트랙 디캡슐레이션(Metadata Track Decapsulation) 및/또는 이미지 디캡슐레이션(Image Decapsulation)을 수행한다. 디캡슐레이션 처리부(file/segment decapsulation)는 수신 처리부로부터 전달받은 파일 형태의 point cloud데이터를 디캡슐레이션할 수 있다. 디캡슐레이션 처리부는 ISOBMFF 등에 따른 파일 혹은 세그먼트들을 디캡슐레이션하여, point cloud비트스트림 내지 point cloud 관련 메타데이터(혹은 별도의 메타데이터 비트스트림)를 획득할 수 있다. 획득된 point cloud비트스트림은 상기 point cloud디코더로, 획득된 point cloud관련 메타데이터(혹은 메타데이터 비트스트림)는 메타데이터 처리부로 전달할 수 있다. 상기 point cloud비트스트림은 상기 메타데이터(메타데이터 비트스트림)를 포함할 수도 있다. 상기 메타데이터 처리부는 상기 point cloud 비디오 디코더에 포함될 수도 있고, 또는 별도의 컴포넌트/모듈로 구성될 수도 있다. 디캡슐레이션 처리부가 획득하는 point cloud관련 메타데이터는 파일 포맷 내의 박스 혹은 트랙 형태일 수 있다. 디캡슐레이션 처리부는 필요한 경우 메타데이터 처리부로부터 디캡슐레이션에 필요한 메타데이터를 전달받을 수도 있다. 상기 point cloud관련 메타데이터는 상기 point cloud디코더에 전달되어 point cloud디코딩 절차에 사용될 수도 있고, 또는 렌더러에 전달되어 point cloud렌더링 절차에 사용될 수도 있다. 파일/세그먼트 디캡슐레이션부는 포인트 클라우드 데이터에 관련된 메타데이터를 생성할 수 있다.
비디오 트랙 디캡슐레이션(Video Track Decapsulation)은 파일 및/또는 세그먼트에 포함된 비디오 트랙을 디캡슐레이션한다. 지오메트리 비디오, 어트리뷰트 비디오, 어큐판시 맵 , Auxiliary 데이터 및/또는 Mesh 데이터를 포함하는 비디오 스트림(들)을 디캡슐레이션한다.
메타데이터 트랙 디캡슐레이션(Metadata Track Decapsulation)은 포인트 클라우드 데이터에 관련된 메타데이터 및/또는 부가 데이터 등을 포함하는 비트스트림을 디캡슐레이션한다.
이미지 디캡슐레이션(Image Decapsulation)은 지오메트리 이미지, 어트리뷰트 이미지, 어큐판시 맵, Auxiliary 데이터 및/또는 Mesh 데이터를 포함하는 이미지(들)을 디캡슐레이션한다.
비디오 디코딩부(Video Decoding)는 지오메트리 비디오 디컴프레션, 어트리뷰트 비디오 디컴프레션, 어큐판시 맵 디컴프레션, Auxiliary 데이터 디컴프레션 및/또는 Mesh데이터 디컴프레션을 수행한다. 비디오 디코딩부는 실시예들에 따른 포인트 클라우드 전송 장치의 비디오 인코딩부가 수행한 프로세스에 대응하여 지오메트리 비디오, 어트리뷰트 비디오, Auxiliary데이터 및/또는 Mesh데이터를 디코딩한다.
이미지 디코딩부(Image Decoding)는 지오메트리 이미지 디컴프레션, 어트리뷰트 이미지 디컴프레션, 어큐판시 맵 디컴프레션, Auxiliary 데이터 디컴프레션 및/또는 Mesh데이터 디컴프레션을 수행한다. 이미지 디코딩부는 실시예들에 따른 포인트 클라우드 전송 장치의 이미지 인코딩부가 수행한 프로세스에 대응하여 지오메트리 이미지, 어트리뷰트 이미지, Auxiliary데이터 및/또는 Mesh데이터를 디코딩한다.
비디오 디코딩부 및/또는 이미지 디코딩부는 비디오 데이터 및/또는 이미지 데이터에 관련된 메타데이터를 생성할 수 있다.
포인트 클라우드 프로세싱부(Point Cloud Processing)은 지오메트리 리컨스트럭션(Geometry Reconstruction) 및/또는 어트리뷰트 리컨스트럭션(Attribute Reconstruction)을 수행한다.
지오메트리 리컨스턱션은 디코딩된 비디오 데이터 및/또는 디코딩된 이미지 데이터로부터 어큐판시 맵, Auxiliary 데이터 및/또는 Mesh데이터에 기반하여 지오메트리 비디오 및/또는 지오메트리 이미지를 복원한다.
어트리뷰트 리컨스럭션은 디코딩된 어트리뷰트 비디오 및/또는 디코딩된 어트리뷰트 이미지로부터 어큐판시 맵, Auxiliary 데이터 및/또는 Mesh데이터에 기반하여 어트리뷰트 비디오 및/또는 어트리뷰트 이미지를 복원한다. 실시예들에 따라, 예를 들어, 어트리뷰트는 텍스쳐일 수 있다. 실시예들에 따라 어트리뷰트는 복수 개의 속성 정보를 의미할 수 있다. 복수개의 어트리뷰트가 있는 경우, 실시예들에 따른 포인트 클라우드 프로세싱부는 복수개의 어트리뷰트 리컨스럭션을 수행한다.
포인트 클라우드 프로세싱부는 비디오 디코딩부, 이미지 디코딩부 및/또는 파일/세그먼트 디캡슐레이션부로부터 메타데이터를 수신하고, 메타데이터게 기반하여 포인트 클라우드를 처리할 수 있다.
포인트 클라우드 렌더링부(Point Cloud Rendering)는 리컨스럭션된 포인트 클라우드를 렌더링한다. 포인트 클라우드 렌더링부는 비디오 디코딩부, 이미지 디코딩부 및/또는 파일/세그먼트 디캡슐레이션부로부터 메타데이터를 수신하고, 메타데이터게 기반하여 포인트 클라우드를 렌더링할 수 있다.
디스플레이는 랜더링된 결과를 실제 디스플레이 장치 상에 디스플레이한다.
도45는 실시예들에 따른 포인트 클라우드 데이터 전송 장치의 인코딩 과정을 나타낸다.
실시예들에 따른 패치 제너레이션(patch generation) : 패치 제너레이션은 포인트 클라우드 데이터를 포함하는 프레임을 수신하여 패치(patch)를 생성한다. patch는 PCC frame을 2D plane에 mapping할때, 함께 mapping을 수행하는 point들의 집합일 수 있다. PCC frame으로 부터 patch를 생성하는 과정은 다음의 단계로 이루어 질 수 있다: PCC를 구성하는 각 포인트의 normal vector를 계산하는 단계, 도27을 참조하여 6개의 bounding box plane에 projection된 이미지인 cluster를 생성하고, normal vector와 인접 cluster를 이용하여 cluster를 재구성하는 단계, Cluster로부터 인접한 점들을 extraction 해여 patch를 생성하는 단계를 포함한다.
실시예들에 따른 패치 제너레이션은 3차원 오브젝트를 3차원의 6개 플렌이 바운딩할 수 있고, 각 플렌에 오브젝트를 프로젝션할 수 있다. 실시예들에 따라 포인트(점) 하나는 하나의 프로젝션 플렌에 투영될 수 있다. 실시예들은 포인트를 어느 플렌에 투영할지 결정할 수 있다. 서페이스에 대한 벡터, 플레인의 오리엔테이션 벡터 등의 벡터에 기반하여, 해당 포인트의 해당 프로젝션 플렌을 결정할 수 있다.
실시예들에 따른 패치 패킹 관련하여, 앞서 투영된 결과가 패치이고 패치를 2D에 프로젝션할 수 있다. 패치 패킹 과정에서 오큐판시 맵이 생성된다. 이후, 실시예들은 위치에 해당하는 데이터를 부여하는 과정이 수행한다.
실시예들에 따른 패치 제너레이션은 패치 제너레이션 관련된 메타데이터 또는 시그널링 정보를 포함하는 패치 인포메이션을 생성할 수 있다. 실시예들에 따른 패치 제너레이션은 패치 인포메이션을 지오메트리 이미지 제너레이션, 패치 패킹, 텍스쳐 이미지 제너레이션, 스무딩 및/또는 오실러리 패치 인포메이션 컴프레션에 전달할 수 있다.
실시예들에 따른 오큐판시 맵은 비디오 코딩 방식에 기반하여 인코딩될 수 있다.
실시예들에 따른 스무딩은 인코딩 프로세스로 인한 패치 간 아티팩트들로 인하여 화질열화(예를 들어 패치 간 이격)가 있을 수 있는 문제를 해결하기 위해서(코딩 효율을 높이기 위해서), 이격을 스무딩할 수 있다. 스무딩된 결과에 텍스쳐, 컬러를 부여하여 다시 포인트 클라우드 데이터를 복원할 수 있다.
도27을 참조하여, 생성된 patch의 데이터는 개별 patch에 해당하는 occupancy map, geometry image, texture image 등으로 구성될 수 있다. Occupancy map은 patch를 구성하는 포인트에 데이터가 존재하는지 여부를 나타내는 이진 (binary) map일 수 있다. Geometry image는 3D 공간상에서 PCC를 구성하는 포인트들의 위치를 식별하기 위해 사용될 수 있으며 depth map 등 1채널 값으로 표현될 수 있으며, 복수 layer로 구성될 수도 있다. 일례로 PCC 내 특정 점을 가장 낮은 깊이값으로 설정하여 Near layer (D0)를 획득하고, 동일 점을 가장 높은 깊이값으로 설정하여 far layer (D1)을 획득할 수 있다. Texture image는 각 포인트에 해당하는 color값을 나타내며, RGB, YUV 등 다채널 값으로 표현될 수 있다.
실시예들에 따른 패치 패킹(patch packding): 도28을 참조하여, 설명하면 다음과 같다. 전체 2D image에서 각 patch들의 위치를 결정하는 과정일 수 있다. 결정된 patch의 위치는 occupancy map, geometry image, texture image에 동일하게 적용되므로 이들 중 한가지를 packing 과정에 사용할 수 있다. Occupancy map을 이용하여 patch들의 위치를 결정하는 과정은 다음과 같을 수 있다
Occupancy map (occupancySizeU * occupancySizeV)를 생성하고 모든 pixel 값을 false(=0)으로 설정한다.
Patch를 2D image의 좌상단을 occupancy map 내의 임의의 점인 (u,v) 에 위치시킨다. ( 0 <= u < occupancySizeU - patch.sizeU0, 0 <= v < occupancySizeV - patch.sizeV0)
Patch 내 임의의 점인 (x, y)에 대하여, patch generation 과정에서 얻어진 patch occupancy map의 해당 포인트 값을 확인한다. 또한 전체 occupancy map의 해당 포인트 값을 확인한다. (0 <= x< patch.sizeU0, 0 <= y < patch.sizeV0)
특정 (x, y) 에 대하여, 두 값이 모두 1(=true)일 경우, patch 좌상단 위치를 변경시켜 3의 과정을 반복한다. 그렇지 않을 경우, (u, v)를 해당 patch의 위치로 결정한다.
실시예들에 따른 패치 패킹은 패치 패킹 관련된 메타데이터 또는 시그널링 정보를 포함하는 어큐판시 맵을 생성할 수 있다. 실시예들에 따른 패치 패킹은 어큐판시 맵을 지오메트리 이미지 제너레이션, 텍스쳐 이미지 제너레이션, 이미지 패딩 및/또는 어큐판시 맵 컴프레션에 전달할 수 있다.
실시예들에 따른 지오메트리 이미지 제너레이션(geometry image generation)은 포인트 클라우드 데이터를 포함하는 프레임, 패치 인포메이션 및/또는 어큐판시 맵에 기반하여 지오메트리 이미지를 생성한다. 지오메트리 이미지 제너레이션은 결정된 patch 위치 및 개별 patch의 geometry를 기반으로 전체 geometry 에 데이터 (i.e. depth value)를 채우는 과정일 수 있다. 복수 layer (e.g. near[d0] / far[d1] layer)의 geometry image들이 생성될 수 있다.
실시예들에 따른 텍스쳐 이미지 제너레이션(texture image generation)은 포인트 클라우드 데이터를 포함하는 프레임, 패치 인포메이션, 어큐판시 맵 및/또는 스무딩된 지오메트리에 기반하여 텍스쳐 이미지를 생성한다. 텍스쳐 이미지 제너레이션은 결정된 patch 위치 및 개별 patch의 geometry를 기반으로 전체 geometry 에 데이터 (i.e. color value)를 채우는 과정일 수 있다.
실시예들에 따른 스무딩(smoting)은 잠재적인 불연속성을 완화하는 과정이다. 컴프레션 결과로 인하여 패치 바운더리 상에서 불연속이 발생할 수 있다. 실시예들에 따른 스무딩은 불연속을 감소시킨다. 스무딩은 바운더리 포인트들을 포인트 상의 최근겁 이웃들(nearest neighbors)의 중심으로 이동시킬 수 있다(The smoothing procedure can aim at alleviating potential discontinuities that may arise at the patch boundaries due to compression artifacts. The implemented approach moves boundary points to the centroid of their nearest neighbors).
실시예들에 따른 어큐판시 맵 컴프레션(occupancy map compression)(or generation)은 패치 패킹 결과에 따른 어큐판시 맵을 생성하고, 어큐판시 맵을 컴프레션한다. 어큐판시 맵 프로세싱은 결정된 patch 위치 및 개별 patch의 occupancy map을 기반으로 전체 occupancy map에 데이터 (i.e. 0 or 1)를 채우는 과정일 수 있다. 앞서 설명한 patch packing과정의 일부로 여겨질 수도 있다. 실시예들에 따른 어큐판시 맵 컴프레션은 arithmetic coding 등을 사용하여 생성된 occupancy map을 압축하는 과정일 수 있다.
실시예들에 따른 오실러리 패치 인포메이션 컴프레션(auxiliary patch information compression)은 패치 제너레이션에 따른 패치 인포메이션에 기반하여 부가적 패치 정보를 컴프레션한다. 개별 patch의 부가 정보들을 부호화 하는 과정으로, projection plane의 index, 2D bounding box, patch의 3D location 등에 해당하는 정보를 포함할 수 있다.
실시예들에 따른 이미지 패딩(image padding)은 지오메트리 이미지(geometry image) 및/또는 텍스쳐 이미지(texture image)를 패딩한다. 이미지 패딩은 video compression에 적합하도록, patch들 사이에 데이터가 채워지지 않은 빈영역의 데이터를 채워넣는다. 실시예들에 따른 패딩 데이터는 인접영역 픽셀값, 인접영역 픽셀값들의 평균값 등이 사용될 수 있다.
실시예들에 따른 비디오 컴프레션(video compression)은 codec (e.g. HEVC, AVC)을 사용하여 생성된 geometry image와 texture image를 부호화한다. 실시예들에 따른 부호화된 지오메트리 이미지(또는 Reconstructed geometry image)는 스무딩에 의해 스무딩될 수 있다.
실시예들에 따른 인코더 또는 포인트 클라우드 데이터 송신 장치는 오큐판시 맵 및/또는 오실러리 패치 인포메이션에 기반하여 실시예들에 따른 디코더 또는 포인트 클라우드 데이터 수신 장치가 3차원 상의 포인트 위치, 2차원 상의 포인트 위치를 알 수 있게 시그널링할 수 있다.
실시예들에 따른 멀티플렉서(multiplexer)는 컴프레스된 지오메트리 이미지(compressed geometry image), 컴프레스된 텍스쳐 이미지(compressed texture image), 컴프레스된 어큐판시 맵(compressed occupancy map), 컴프레스된 패치 인포메이션(compressed patch info) 등 하나의 PCC 영상을 구성하는 데이터들을 다중화하여 하나의 bitstream을 생성한다. 실시예들에 따라서, 하나의 GOP (Group of Pictures)에 해당되는 compressed geometry image, compressed texture image, compressed occupancy map, compressed patch info 데이터의 셋을 GOF (Group of Frames)라 명명할 수 있다. 생성된 bitstream은 NAL unit stream, ISO BMFF file, DASH segment, MMT MPU 등의 형태일 수 있다. 생성된 bitstream에는 PCC GOF의 coding 특성을 나타내는 GOF header 데이터가 포함될 수 있다. 실시예들에 따른 인코딩 과정의 각 과정은 하드웨어, 소프트웨어 및/또는 프로세서의 조합 등의 동작으로 해석될 수 있다.
본 문서에서 실시예들에 따른 포인트 클라우드 데이터 전송 장치는 인코더, 송신기, 송신 장치 등으로 다양하게 호칭될 수 있다.
실시예들에 따른 포인트 클라우드 데이터 전송 장치는 본 문서에서 설명하는 실시예들에 기반하여 포인트 클라우드 데이터를 효율적으로 코딩할 수 있는 효과를 제공하고, 실시예들에 따른 포인트 클라우드 데이터 수신 장치가 포인트 클라우드 데이터를 효율적으로 디코딩/복원할 수 있는 효과를 제공한다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법은 포인트 클라우드 데이터의 위치에 관련된 지오메트리 이미지를 생성하는 단계; 포인트 클라우드 데이터의 속성에 관련된 텍스쳐 이미지를 생성하는 단계; 포인트 클라우드 데이터의 패치에 관련된 어큐판시 맵을 생성하는 단계; 및/또는 지오메트리 이미지, 텍스쳐 이미지 및 어큐판시 맵을 멀티플렉싱하는 단계; 를 포함할 수 있다. 실시예들에 따라, 지오메트리 이미지는 지오메트리 정보, 지오메트리 데이터, 텍스쳐 이미지는 텍스쳐 정보, 텍스쳐 데이터, 속성 정보, 속성 데이터, 어큐판시 맵은 어큐판시 정보 등으로 용어가 의미하는 범위 내에서 명칭은 변경이 가능하다.
도46은 실시예들에 따른 디코딩 프로세스를 나타낸다.
실시예들에 따른 디멀티플렉서(de-multiplexer)는 하나의 PCC bitstream (e.g. NAL unit stream, ISO BMFF file, DASH segment, MMT MPU)으로부터 compressed geometry image, compressed texture image, compressed occupancy map, compressed patch info 등 하나의 PCC 영상을 구성하는 개별 데이터들을 역다중화하여 추출한다. PCC GOF의 coding 특성을 나타내는 GOF header 데이터의 해석 과정을 포함할 수도 있다.
실시예들에 따른 비디오 디컴프레션(video decompression)은 추출된 compressed geometry image와 compressed texture image를 codec (e.g. HEVC, AVC)을 사용하여 복호화한다.
실시예들에 따른 어큐판시 맵 디컴프레션(accupancy map decompression)은 추출된 compressed occupancy map을 arithmetic coding 등을 사용하여 복호화한다.
실시예들에 따른 어실러리 패치 인포메이션 디컴프레션(auxiliary patch information decompression)은 추출된 compressed auxiliary patch information을 복호화하여 개별 patch의 부가 정보들을 해석하는 과정으로, 이러한 정보에는 projection plane의 index, 2D bounding box, patch의 3D location 등이 포함될 수 있다.
실시예들에 따른 지오메트리 리컨스럭션(geometry reconstruction)은decompressed geometry image, decompressed occupancy map, decompressed auxiliary patch information 등을 이용하여 3차원 공간상에 PCC를 구성하는 점들의 위치를 계산해 내는 과정일 수 있다. 계산된 점들의 위치는 해당 점의 3차원 위치와 (e.g. x,y,z) 데이터의 존재 유무 (0 or 1) 형태로 표현될 수 있다.
실시예들에 따른 스무딩(smoothing)은 잠재적인 불연속성을 완화하는 과정이다. 컴프레션 결과로 인하여 패치 바운더리 상에서 불연속이 발생할 수 있다. 실시예들에 따른 스무딩은 불연속을 감소시킨다. 스무딩은 바운더리 포인트들을 포인트 상의 최근겁 이웃들(nearest neighbors)의 중심으로 이동시킬 수 있다. 스무딩은 디코딩 과정에서 발생할 수 있는 불연속을 감소시킨다.
실시예들에 따른 텍스쳐 리컨스트럭션(texture reconstruction)은geometry reconstruction 과정에서 계산된 점들의 위치와decompressed texture image을 이용하여 해당 점에 컬러값을 부여하는 과정일 수 있다.
실시예들에 따른 디코딩 과정은 실시예들에 따른 인코딩 과정의 역과정일 수 있다.
본 문서에서 실시예들에 따른 포인트 클라우드 데이터 수신 장치는 디코더, 수신기, 수신 장치 등으로 다양하게 호칭될 수 있다.
도47은 실시예들에 따른 ISO BMFF 기반 Multiplexing/Demultiplexing을 나타낸다.
실시예들에 따른 멀티플렉싱은 지오메트리 이미지, 텍스쳐 이미지, 어큐판시 맵 및/또는 오실러리 패치 인포메이션을 멀티플렉싱한다. 실시예들에 따른 지오메트리 이미지는 NALU 스트림일 수 있다. 실시예들에 따른 텍스쳐 이미지는 NALU 스트림일 수 있다. 실시예들에 따라 지오메트리 이미지, 텍스쳐 이미지, 어큐판시 맵 및/또는 오실러리 패치 인포메이션은 파일의 형태로 인캡슐레이션된다.
본 문서의 실시예들은 포인트 클라우드 데이터, 특히 V-PCC 방식에 기반한, 예를 들어, 네 가지 데이터(지오메트리, 텍스쳐, 어큐판시 맵, 오실러리 맵 정보)를 어떻게 코덱해서 전송하고 수신할지 방법에 관한 것이다.
실시예들에 따른 딜리버리는 지오메트리 이미지, 텍스쳐 이미지, 어큐판시 맵 및/또는 오실러리 패치 인포메이션이 멀티플렉싱된 PCC 비트스트림을 전송한다. 실시예들에 따라 딜리버리의 형태는 ISOBMFF 파일의 형태를 포함할 수 있다.
실시예들에 따른 디멀티플렉싱은 지오메트리 이미지, 텍스쳐 이미지, 어큐판시 맵 및/또는 오실러리 패치 인포메이션을 디멀티플렉싱한다. 실시예들에 따른 지오메트리 이미지는 NALU 스트림일 수 있다. 실시예들에 따른 텍스쳐 이미지는 NALU 스트림일 수 있다. 실시예들에 따라 지오메트리 이미지, 텍스쳐 이미지, 어큐판시 맵 및/또는 오실러리 패치 인포메이션은 파일의 형태로 디인캡슐레이션된다.
실시예들에 따른 멀티플렉싱/디멀티플렉싱의 형태는 다음과 같다.
실시예들에 따른 ISO BMFF 파일은 멀티플 PCC 트랙들(multiple PCC tracks)을 가질 수 있다. 실시예들에 따른 PCC 트랙들의 개별적인 트랙은 다음의 정보를 포함할 수 있다.
실시예들에 따른 멀티플 트랙은 다음과 같이, 예를 들어 4개의 트랙으로 구성될 수 있다.
실시예들에 따른 Geometry / Texture image관련 트랙으로, restricted scheme type 정의 및/또는 Video sample entry의 추가 박스(box)를 포함한다.
실시예들에 따른 restricted scheme type은 scheme type박스를 추가로 정의하여, 송신/수신하는 데이터가 포인트 클라우드를 위한 지오메트리 및/또는 텍스쳐 이미지(비디오)라는 정보를 나타낼 수 있다.
실시예들에 따른 Video sample entry의 추가 박스는 포인트 클라우드를 해석하기 위한 메타데이터를 포함할 수 있다. 실시예들에 따른 Video sample entry는 PCC 관련 메타데이터를 포함하는 PCC 하위 박스를 포함할 수 있다. 예를 들어, 지오메트리, 텍스쳐, 오큐판시 맵, 오실러리 패치 메타데이터 등이 식별될 수 있다.
실시예들에 따른 Geometry / Texture image은 두 개의 레이어로 구성될 수 있다(예를 들어, D0, D1, T0, T1). 실시예들에 따라 서페이스 상의 포인트들이 중복될 때 효율성을 위해서 최소한의 두 개의 레이어에 기반하여 Geometry / Texture image 를 구성할 수 있다.
실시예들에 따른 Occupancy map / Auxiliary patch information 관련 트랙으로, timed metadata track 정의, 예를 들어 sample entry, sample format 정의를 포함한다. 또한, 오큐판시, 패치의 위치에 관한 정보가 트랙 내에 포함될 수 있다.
실시예들에 따른 PCC track grouping 관련 트랙으로, geometry/texture/occupancy map /auxiliary patch information track들 grouping 이 있을 수 있고, PCC GOF header 정보 포함한다.
실시예들에 따른 PCC track referencing 관련 트랙으로, geometry D0, D1 사이의 track reference (differential method 사용시) 정보를 포함한다.
실시예들에 따른 ISO BMFF 파일은 싱글 PCC 트랙(a single PCC track)을 가질 수 있다.
실시예들에 따른 싱글 트랙은 다음의 정보를 포함할 수 있다.
실시예들에 따른 PCC GOF header 정보와 관련하여, restricted scheme type 정의 및/또는 Video sample entry의 추가 box를 포함한다.
실시예들에 따른Geometry / Texture image 관련하여, 서브 샘플(Sub-sample) 및 샘플 그룹핑(Sample grouping)을 포함할 수 있다. Sub-sample은 개별 image를 sub-sample로 구성한 것이고, 시그널링 (예를 들어, D0 or D1 or texture)이 가능하다. Sample grouping은 개별 image를 sample로 구성한 것이고, interleaving 후 sample grouping을 이용해 구분할 수 있다.
실시예들에 따라 싱글 트랙의 샘플에 여러 개 정보가 들어갈 수 있기 때문에 서브-샘플(분류를 하는 것)이 필요할 수 있고, 샘플 그룹핑은 샘플을 시퀀셜하게 구별할 수 있는 효과가 있다.
실시예들에 따른Occupancy map / Auxiliary patch information 관련하여, 샘플 오실러리 인포메이션(Sample auxiliary information), 샘플 그룹핑(Sample grouping) 및/또는 서브-샘플(Sub-sample)을 포함한다. Sample auxiliary information ('saiz', 'szio' box)은 개별 metadata를 sample auxiliary information으로 구성할 수 있고, 시그널링이 될 수 있다. Sample grouping은 상술한 바와 동일/유사할 수 있다. Sub-sample은 개별 메타데이터를 sub-sample로 구성한 것이고, 시그널링될 수 있다.
실시예들에 따라 파일을 하나의 트랙에 멀티플렉싱하여 전송할 수 있고, 파일을 여러 개의 트랙에 멀티플렉싱하여 전송할 수 있다. 또한, 시그널링 정보를 통해 비디오 데이터, 예를 들어 지오메트리/텍스쳐 이미지를 구별할 수 있고, 메타데이터, 예를 들어 어큐판시 맵/오실러리 패치 정보 등을 구별할 수 있다.
실시예들에 따른PCC track을 위한 SchemeType은 다음과 같다.
PCC frame이 복호화될 경우, 복호화된 PCC frame은 하나 또는 두 layer의 geometry image, texture image, occupancy map, auxiliary patch information 등의 데이터를 포함할 수 있다. PCC video track은 이들 데이터들 중 하나 혹은 여러가지를 포함할 수 있으며, 이 데이터들을 기반으로 post processing하여 point cloud를 재구성할 수 있다. 이와 같이 PCC 데이터를 포함하는 track은 예를 들어, SchemeTypeBox에 존재하는 scheme_type의 'pccv' 값을 통해 식별될 수 있다.
실시예들에 따른 SchemeType의 박스는 다음과 같이 표현될 수 있다.
aligned(8) class SchemeTypeBox extends FullBox('schm', 0, flags) {
unsigned int(32) scheme_type;
unsigned int(32) scheme_version;
if (flags & 0x000001) {
unsigned int(8) scheme_uri[];
}
}
실시예들에 따른 SchemeType는 포인트 클라우드 데이터를 전달하는 트랙임을 표현할 수 있다.
실시예들에 따른 SchemeType을 통해 수신기는 수신/디코딩 가능 여부를 확인할 수 있는 데이터의 타입을 알 수 있고, 호환성을 제공하는 효과가 있다.
실시예들에 따른 PCC 파일은 PCC Video Box를 포함할 수 있다. PCC 데이터를 포함하는 PCC track은 PccVideoBox를 가질 수 있다. PccVideoBox는 SchemeType이 'pccv'일 경우 SchemeInfomationBox 하위에 존재할 수 있다. 또는 SchemeType 과 무관하게 VisualSampleEntry 하위에 존재할 수도 있다. PccVideoBox는 PCC GOF header, geometry image (D0/D1), texture imgage, occupancy map, auxiliary patch information 등 PCC frame을 재구성하기 위해 필요한 데이터들이 현재 track에 존재하는지 여부를 알려주고, PCC GOF header 데이터를 직접 포함할 수도 있다.
Box Type: 'pccv'
Container: SchemeInformationBox or VisualSampleEntry
Mandatory: Yes (when the SchemeType is 'pccv')
Quantity: One
aligned(8) class PccVideoBox extends FullBox('pccv', version = 0, 0) {
unsigned int(1) pcc_gof_header_flag;
unsigned int(1) geometry_image_d0_flag;
unsigned int(1) geometry_image_d1_flag;
unsigned int(1) texture_image_flag;
unsigned int(1) occupancy_map_flag;
unsigned int(1) auxiliary_patch_info_flag;
unsigned int(2) reserved = 0;
if (pcc_header_flag == 1) {
PccHeaderBox pcc_header_box;
}
Box[] any_box; // optional
}
실시예들에 따른 pcc_gof_header_flag : 현재 track이 PCC GOF header를 포함하는지 여부를 나타낼 수 있다. 1일 경우, PccVideoBox 하위에 PccGofHeader box의 형태로 해당 데이터를 포함할 수 있다. 0 일 경우 현재 track에 PCC GOF heade가 포함되지 않는다.
실시예들에 따른 geometry_image_d0_flag : 현재 track이 near layer의 geometry image를 포함하는지 여부를 나타낼 수 있다. 1일 경우, 현재 track의 미디어 데이터 등의 형태로 near layer의 geometry image를 를 포함할 수 있다. 0일 경우, 현재 track에 near layer의 geometry image 데이터를 포함히지 않는다.
실시예들에 따른 geometry_image_d1_flag :현재 track이 far layer의 geometry image를 포함하는지 여부를 나타낼 수 있다. 1일 경우, 현재 track의 미디어 데이터 등의 형태로 far layer의 geometry image를 를 포함할 수 있다. 0일 경우, 현재 track에 far layer의 geometry image 데이터를 포함히지 않는다.
실시예들에 따른 texture_image_flag: 현재 track이 texture image를 포함하는지 여부를 나타낼 수 있다. 1일 경우, 현재 track의 미디어 데이터 등의 형태로 texture image를 를 포함할 수 있다. 0일 경우, 현재 track에 texture image 데이터를 포함히지 않는다.
실시예들에 따른 occupancy_map_flag: 현재 track이 occupancy map을 포함하는지 여부를 나타낼 수 있다. 1일 경우, 현재 track에 occupancy map 데이터를 포함한다. 0일 경우, 현재 track에 occupancy map 데이터를 포함히지 않는다.
실시예들에 따른 auxiliary_patch_info_flag : 현재 track이 auxiliary patch information을 포함하는지 여부를 나타낼 수 있다. 1일 경우, 현재 track에 auxiliary patch information 데이터를 포함한다. 0일 경우, 현재 track에 auxiliary patch information 데이터를 포함히지 않는다.
상술한 바와 같이 PCC GOF HEADER를 포함하는 경우, 실시예들에 따른 박스의 형태는 다음과 같다.
실시예들에 따른 PCC GOF Header Box 관련하여, PccGofHeaderBox는 PCC GoF(Group of Frames)의 코딩 특성을 나타내는 파라미터들을 포함할 수 있다.
Box Type: 'pghd'
Container: PccVideoBox
Mandatory: No
Quantity: Zero or one
aligned(8) class PccGofHeaderBox extends FullBox('pghd', version = 0, 0) {
unsigned int(8) group_of_frames_size;
unsigned int(16) frame_width;
unsigned int(16) frame_height;
unsigned int(8) occupancy_resolution;
unsigned int(8) radius_to_smoothing;
unsigned int(8) neighbor_count_smoothing;
unsigned int(8) radius2_boundary_detection;
unsigned int(8) threshold_smoothing;
unsigned int(8) lossless_geometry;
unsigned int(8) lossless_texture;
unsigned int(8) no_attributes;
unsigned int(8) lossless_geometry_444;
unsigned int(8) absolute_d1_coding;
unsigned int(8) binary_arithmetic_coding;
}
실시예들에 따른 group_of_frames_size : 프레임들의 현재 그룹 내 프레임들의 수를 나타낸다(indicates the number of frames in the current group of frames.)
실시예들에 따른 frame_width : 지오메트리 및 텍스쳐 비디오들의 픽셀들 내 프레임 너비를 나타내고, 이 값은 멀티플 어큐판시 레졸루션일 것이다.(indicates the frame width, in pixels, of the geometry and texture videos. It shall be multiple of occupancyResolution.)
실시예들에 따른 frame_height : 지오메트리 및 텍스쳐 비디오들의 픽셀들 내 프레임 높이를 나타내고, 이 값은 멀티플 어큐판시 레졸루션일 것이다(indicates the frame height, in pixels, of the geometry and texture videos. It shall be multiple of occupancyResolution.)
실시예들에 따른 occupancy_resolution : 지오메트리 및 텍스쳐 비디오들 내 패치들이 패킹된 픽셀들 내의 horizontal 레졸루션 및 vertical 레졸루션을 나타낸다. 이 값은 어큐판시 레졸루션 이븐 값일 것이다.(indicates the horizontal and vertical resolution, in pixels, at which patches are packed in the geometry and texture videos. It shall be an even value multiple of occupancyPrecision.)
실시예들에 따른 radius_to_smoothing 은 스무딩을 위한 이웃들을 감지하는 반경을 나타낸다. radius_to_smoothing의 값은 0 내지 255(포함)의 범위 내에 있을 수 있다( indicates the radius to detect neighbours for smoothing. The value of radius_to_smoothing shall be in the range of 0 to 255, inclusive.)
실시예들에 따른 neighbor_count_smoothing 은 스무딩을 위해 사용되는 이웃들의 최대 개수를 나타낸다. neighbor_count_smoothing의 값은 0 내지 255(포함)의 범위 내에 있을 수 있다( indicates the maximum number of neighours used for smoothing. The value of neighbor_count_smoothing shall be in the range of 0 to 255, inclusive.)
실시예들에 따른 radius2_boundary_detection 은 바운더리 포인트 디텍션을 위한 반경을 나타낸다. radius2_boundary_detection의 범위는 0 내지 255(포함)의 범위 내에 있을 수 있다( indicates the radius for boundary point detection. The value of radius2_boundary_detection shall be in the range of 0 to 255, inclusive.)
실시예들에 따른 threshold_smoothing 은 스무딩 트레스홀드를 나타낸다. threshold_smoothing의 값은 0 내지 255(포함)의 범위 내에 있을 수 있다( indicates the smoothing threshold. The value of threshold_smoothing shall be in the range of 0 to 255, inclusive.)
실시예들에 따른 lossless_geometry 은 로스리스 지오메트리 코딩을 나타낸다. lossless_geometry이 1일 때 포인트 클라우드 지오메트리 인포메이션이 로스리스하게 코딩됨을 나타낸다. lossless_geometry의 값이 0인 경우 포인트 클라우드 지오메트리 인포메이션이 로시 매너로 코딩됨을 나타낸다( indicates lossless geometry coding. The value of lossless_geometry equal to 1 indicates that point cloud geometry information is coded losslessly. The value of lossless_geometry equal to 0 indicates that point cloud geometry information is coded in a lossy manner.)
실시예들에 따른 lossless_texture 은 로스리스 텍스쳐 인코딩을 나타낸다. lossless_texture의 값이 1인 경우 포인트 클라우드 텍스쳐 인포메이션이 로스리스하게 코딩됨을 나타낸다. lossless_texture의 값이 0인 경우 포인트 클라우드 텍스쳐 인포메이션이 로시 매너로 코딩됨을 나타낸다( indicates lossless texture encoding. The value of lossless_texture equal to 1 indicates that point cloud texture information is coded losslessly. The value of lossless_texture equal to 0 indicates that point cloud texture information is coded in a lossy manner.)
실시예들에 따른 no_attributes 은 어트리뷰트가 지오메트리 데이터와 함께 코딩되는지 여부를 나타낸다. no_attributes의 값이 1인 경우 코딩된 포인트 클라우드 비트스트림은 어떠한 어트리뷰트 인포메이션을 포함하지 않음을 나타낸다. no_attributes의 값이 0인경우 코딩된 포인트 클라우드 비트스트림이 어트리뷰트 인포메이션을 포함함을 나타낸다( indicates whether to attributes are coded along with geometry data. The value of no_attributes equal to 1 indicates that the coded point cloud bitstream does not contain any attributes information. The value of no_attributes equal to 0 indicates that the coded point cloud bitstream contains attributes information.)
실시예들에 따른 lossless_geometry_444 은 지오메트리 프렝미들을 위한 4:2:0 또는4:4:4 video format을 사용하는지 여부를 나타낸다. lossless_geometry_444의 값이 1인 경우 지오메트리 비디오는 4:4:4 format으로 코딩됨을 나타낸다. 4:4:4 format의 값이 0인 경우 지오메트리 비디오가 4:2:0 format으로 코딩됨을 나타낸다( indicates whether to use 4:2:0 or 4:4:4 video format for geometry frames. The value of lossless_geometry_444 equal to 1 indicates that the geometry video is coded in 4:4:4 format. The value of lossless_geometry_444 equal to 0 indicates that the geometry video is coded in 4:2:0 format.)
실시예들에 따른 absolute_d1_coding 은 프로젝션 플렌에 근접한 레이어와 다른 지오메트리 레이더들이 어떻게 코딩되는지를 나타낸다. absolute_d1_coding의 값이 1인 경우 액츄얼 지오메트리 값들은 프로젝션 플렌에 가까운 레이어와 다른 지오메트리 레이어들을 위해 코딩됨을 나타낸다. absolute_d1_coding의 값이 0인 경우 프로젝션 플렌에 가까운 레이어와 다른 지오메트리 레이어들이 다르게 코딩됨을 나타낸다(indicates how the geometry layers other than the layer nearest to the projection plane are coded. absolute_d1_coding equal to 1 indicates that the actual geometry values are coded for the geometry layers other than the layer nearest to the projection plane. absolute_d1_coding equal to 0 indicates that the geometry layers other than the layer nearest to the projection plane are coded differentially. )
실시예들에 따른 bin_arithmetic_coding 은 바이너리 아리스메틱 코딩이 사용됨을 나타낸다. bin_arithmetic_coding의 값이 1인 경우 바이너리 아리스메틱 코딩이 모든 신택스 엘리먼트들을 위해 사용됨을 나타낸다. bin_arithmetic_coding의 값이 0인 경우 논-바이너리 아리스메틱 코딩이 일부 신택스 엘리먼트들을 위해 사용됨을 나타낸다( indicates whether binary arithmetic coding is used. The value of bin_arithmetic_coding equal to 1 indicates that binary arithmetic coding is used for all the syntax elements. The value of bin_arithmetic_coding equal to 0 indicates that non-binary arithmetic coding is used for some syntax elements.)
실시예들에 따른 PCC 파일은 PCC auxiliary patch information timed metadata track을 포함할 수 있다. PCC auxiliary patch information timed metadata track은 PccAuxiliaryPatchInfoSampleEntry()를 포함할 수 있다. PccAuxiliaryPatchInfoSampleEntry는 'papi' type 값으로 식별될 수 있으며, static한 PCC auxiliary patch information을 entry 내부에 포함할 수도 있다. PCC auxiliary patch information timed metadata track의 media data('mdat')의 개별 sample은 PccAuxiliaryPatchInfoSample() 과 같이 구성될 수 있으며, dynamic하게 변화하는 PCC auxiliary patch information을 sample 내부에 포함할 수 있다
class PccAuxiliaryPatchInfoSampleEntry() extends MetaDataSampleEntry ('papi') {
}
class PccAuxiliaryPatchInfoSample() {
unsigned int(32) patch_count;
unsigned int(8) occupancy_precision;
unsigned int(8) max_candidate_count;
unsigned int(2) byte_count_u0;
unsigned int(2) byte_count_v0;
unsigned int(2) byte_count_u1;
unsigned int(2) byte_count_v1;
unsigned int(2) byte_count_d1;
unsigned int(2) byte_count_delta_size_u0;
unsigned int(2) byte_count_delta_size_v0;
unsigned int(2) reserved = 0;
for(i=0; i<patch_count; i++) {
unsigned int(byte_count_u0 * 8) patch_u0;
unsigned int(byte_count_v0 * 8) patch_v0;
unsigned int(byte_count_u1 * 8) patch_u1;
unsigned int(byte_count_v1 * 8) patch_v1;
unsigned int(byte_count_d1 * 8) patch_d1;
unsigned int(byte_count_delta_size_u0 * 8) delta_size_u0;
unsigned int(byte_count_delta_size_v0 * 8) delta_size_v0;
unsigned int(2) normal_axis;
unsigned int(6) reserved = 0;
}
unsinged int(1) candidate_index_flag;
unsigned int(1) patch_index_flag;
unsigned int(3) byte_count_candidate_index;
unsigned int(3) byte_count_patch_index;
if(candidate_index_flag == 1) {
unsigned int(byte_count_candidate_index * 8) candidate_index;
}
if(patch_index_flag == 1) {
unsigned int(byte_count_candidate_index * 8) patch_index;
}
}
실시예들에 따른 patch_count은 지오메트리 및 텍스쳐 비디오들 내 패치들의 개수를 나타낸다. patch_count은 0보다 클 수 있다( is the number of patches in the geometry and texture videos. It shall be larger than 0.)
실시예들에 따른 occupancy_precision은 오큐판시 맵 프리시즌의 픽셀 내 수평 및 수직 해상도이다. 이 값은 오큐판시가 시그널링되는 서브-블록 사이즈에 대응된다. 오큐판시 맵의 로스리스 코딩을 달성하기 위해서 이 값은 사이즈 1로 세팅될 수 있다( is the horizontal and vertical resolution, in pixels, of the occupancy map precision. This corresponds to the sub-block size for which occupancy is signaled. To achieve lossless coding of occupancy map this should be set to size 1.)
실시예들에 따른 max_candidate_count 은 패치 캔디데이트 리스트 내 캔디데이트들의 최대 개수를 나타낸다(specifies the maximum number of candidates in the patch candidate list. )
실시예들에 따른 byte_count_u0 은 patch_u0의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_u0.)
실시예들에 따른 byte_count_v0 은 patch_v0의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_v0.)
실시예들에 따른 byte_count_u1 은 patch_u1의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_u1.)
실시예들에 따른 byte_count_v1 은 patch_v1의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_v1.)
실시예들에 따른 byte_count_d1 은 patch_d1의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_d1.)
실시예들에 따른 byte_count_delta_size_u0 은 delta_size_u0 의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of delta_size_u0.)
실시예들에 따른 byte_count_delta_size_v0 은 delta_size_v0의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of delta_size_v0.)
실시예들에 따른 patch_u0 은 patch bounding box의 size occupancy_resolution x occupancy_resolution의 탑-레프트 코너 서브블록의 X-코디네이트를 나타낸다. patch_u0의 값은 0 내지 frame_width/occupancy_resolution -1(포함)의 범위 내에 있을 수 있다(specifies the x-coordinate of the top-left corner subblock of size occupancy_resolution x occupancy_resolution of the patch bounding box. The value of patch_u0 shall be in the range of 0 to frame_width/occupancy_resolution 1, inclusive.)
실시예들에 따른 patch_v0 은 patch bounding box의 size occupancy_resolution x occupancy_resolution의 탑-레프트 코너 서브블록의 Y-코디네이트를 나타낸다. patch_v0의 값은 0 내지 frame_height/occupancy_resolution -1(포함)의 범위 내에 있을 수 있다(specifies the y-coordinate of the top-left corner subblock of size occupancy_resolution x occupancy_resolution of the patch bounding box. The value of patch_v0 shall be in the range of 0 to frame_height/occupancy_resolution 1, inclusive.)
실시예들에 따른 patch_u1 은 패치 포인트들의 3D bounding box의 미니멈 X-코디네이트를 나타낸다. patch_u1의 값은 0 내지 to frame_width-1(포함)의 범위 내에 있을 수 있다(specifies the minimum x-coordinate of the 3D bounding box of patch points.. The value of patch_u1 shall be in the range of 0 to frame_width 1, inclusive.)
실시예들에 따른 patch_v1 은 패치 포인트들의 3D bounding box의 맥시멈 X-코디네이트를 나타낸다. patch_v1의 값은 0 내지 frameHeight-1(포함)의 범위 내에 있을 수 있다(is the minimum y-coordinate of the 3D bounding box of patch points,. The value of patch_v1 shall be in the range of 0 to frameHeight 1, inclusive.)
실시예들에 따른 patch_d1 은 패치들의 미니멈 뎁스를 나타낸다(specifies the minimum depth of the patch. )
실시예들에 따른 delta_size_u0 is the difference of patch width between the current patch and the previous one.
실시예들에 따른 delta_size_v0 은 커런트 패치 및 이전 패치 간 패치 높이의 차이를 나타낸다(is the difference of patch height between the current patch and the previous one. )
실시예들에 따른 normal_axis 은 플렌 프로젝션 박스를 나타낸다. normal_axis의 값은 0 내지 2(포함)의 범위 내에 있을 수 있다. 0, 1, 2의 normalAxis 값은 X, Y, Z 프로젝션 축 각각에 대응된다(specifies the plane projection index. The value of normal_axis shall be in the range of 0 to 2, inclusive. normalAxis values of 0, 1, and 2 correspond to the X, Y, and Z projection axis, respectively.)
실시예들에 따른 candidate_index_flag 은 candidate_index이 존재하는지 아닌지 여부를 나타낸다(specifies whether candidate_index is present or not.)
실시예들에 따른 patch_index_flag 은 patch_index이 존재하는지 아닌지 여부를 나타낸다(specifies whether patch_index is present or not.)
실시예들에 따른 byte_count_candidate_index 은 candidate_index 의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of candidate_index.)
실시예들에 따른 byte_count_patch_index 은 patch_index 의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_index.)
실시예들에 따른 candidate_index 은 패치 캔디테이트 리스트에 대한 인덱스를 나타낸다. candidate_index의 값은 0 내지 max_candidate_count(포함)의 범위 내에 있을 수 있다(is the index into the patch candidate list. The value of candidate_index shall be in the range of 0 to max_candidate_count, inclusive.)
실시예들에 따른 patch_index 은 프레임 연관된 descending size order 내 저장된 패치 리스트에 대한 인덱스를 나타낸다( is an index to a sorted patch list, in descending size order, associated with a frame.)
실시예들에 따른 PCC 파일은 PCC occupancy map timed metadata track을 포함한다. PCC occupancy map timed metadata track은 PccOccupancyMapSampleEntry()를 포함할 수 있다. PccOccupancyMapSampleEntry 는 'papi' type 값으로 식별될 수 있으며, static한 PCC occupancy map 데이터를 entry 내부에 포함할 수도 있다. PCC occupancy map timed metadata track의 media data('mdat')의 개별 sample은 PccOccupancyMapSample () 과 같이 구성될 수 있으며, dynamic하게 변화하는 PCC occupancy map 데이터를 sample 내부에 포함할 수 있다.
class PccOccupancyMapSampleEntry() extends MetaDataSampleEntry ('popm') {
}
class PccOccupancyMapSample() {
unsigned int(32) block_count;
for( i = 0; i < block_count; i++ ) {
unsigned int(1) empty_block_frag;
unsigned int(7) reserved = 0;
if(empty_block_frag == 1) {
unsigned int(1) is_full;
unsigned int(7) reserved = 0;
if(is_full == 0) {
unsinged int(2) best_traversal_order_index;
unsigned int(6) reserved = 0;
unsinged int(16) run_count_prefix;
if (run_count_prefix > 0) {
unsigned int(16) run_count_suffix;
}
unsigned int(1) occupancy;
unsigned int(7) reserved = 0;
for( j = 0; j <= runCountMinusTwo+1; j++ ) {
unsigned int(16) run_length_idx;
}
}
}
}
}
}
실시예들에 따른 block_count 은 오큐판시 블록들의 개수를 나타낸다(specifies the number of occupancy blocks.)
실시예들에 따른 empty_block_flag 은 ze occupancy_resolution × occupancy_resolution block의 커런트 오큐판시 블록이 비어있는지 아닌지 여부를 나타낸다. empty_block_flag이 0인 경우 커런트 오큐판시 블록이 비어있음을 나타낸다(specifies whether the current occupancy block of size occupancy_resolution × occupancy_resolution block is empty or not. empty_block_flag equal to 0 specifies that the current occupancy block is empty.)
실시예들에 따른 is_full 은 size occupancy_resolution × occupancy_resolution block의 커런트 오큐판시 블록이 풀인지 여부를 나타낸다. is_full이1인 경우 커런트 블록이 풀임을 나타낸다. is_full이 0인 경우 커런트 오큐판시 블록이 풀이 아님을 나타낸다(specifies whether the current occupancy block of size occupancy_resolution × occupancy_resolution block is full. is_full equal to 1 specifies that the curret block is full. is_full equal to 0 specifies that the current occupancy block is not full. )
실시예들에 따른 best_traversal_order_index 은 current occupancy_resolution × occupancy_resolution block 내 size occupancy_precision × occupancy_precision의 서브-블록들을 위한 스캔 오더를 나타낸다. best_traversal_order_index의 값은 0 내지 4(포함)의 범위 내에 있을 수 있다(specifies the scan order for sub-blocks of size occupancy_precision × occupancy_precision in the current occupancy_resolution × occupancy_resolution block. The value of best_traversal_order_index shall be in the range of 0 to 4, inclusive.)
실시예들에 따른 run_count_prefix 은 runCountMinusTwo변수의 데리베이션 내 사용될 수 있다(is used in the derivation of variable runCountMinusTwo.)
실시예들에 따른 run_count_suffix 은 runCountMinusTwo 변수의 데리베이션 내 사용될 수 있다. 존재하지 않는 경우, run_count_suffix의 값은 0일 수 있다(is used in the derivation of variable runCountMinusTwo. When not present, the value of run_count_suffix is inferred to be equal to 0.)
파티큘러 블록을 위한 blockToPatch의 값이 제로와 같이 않은 경우, 블록은 풀이 아닐 수 있다. unCountMinusTwo 플러스 2는 블록을 위한 시그널된 런들의 개수를 나타낸다. runCountMinusTwo의 값은 0 내지 (occupancy_resolution * occupancy_resolution)-1(포함)의 범위 내에 있을 수 있다(When the value of blockToPatch for a particular block is no equal to zero and the block is not full, runCountMinusTwo plus 2 represents the number of signalled runs for a block. The value of runCountMinusTwo shall be in the range of 0 to (occupancy_resolution * occupancy_resolution) 1, inclusive.)
실시예들에 따른 runCountMinusTwo 는 다음과 같이 표현될 수 있다:
runCountMinusTwo = (1 << run_count_prefix) - 1 + run_count_suffix
오큐판시는 제 1 서브블록(of occupancyPrecision × occupancyPrecision pixels)을 위한 오큐판시 값을 나타낸다. 오큐판시가 0인 경우 제 1 서브블록이 비어 있음을 나타낸다. 오큐판시가 1인 경우 제1 서브블록이 차지되어 있음을 나타낸다(occupancy specifies the occupancy value for the first sub-block (of occupancyPrecision × occupancyPrecision pixels). occupancy equal to 0 specifies that the first sub-block is empty. occupancy equal to 1 specifies that the first sub-block is occupied. )
실시예들에 따른 run_length_idx 는 런 렝스를 나타낸다. runLengthIdx의 값은 0내지14(포함)의 범위 내에 있을 수 있다(is indication of the run length. The value of runLengthIdx shall be in the range of 0 to 14, inclusive.)
실시예들에 따른 멀티플렉싱은 파일로 네 가지 데이터를 멀티플렉싱한다. 실시예들에 따른 파일 관련하여, 복수의 비트스트림의 각 비트스트림을 멀티플 트랙이 포함할 수 있고, 복수의 비트스트림을 싱글 트랙이 포함할 수 있다. 실시예들에 따른 멀티플/싱글 트랙은 후술한다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법의 멀티플렉싱은 지오메트리 이미지, 텍스쳐 이미지, 어큐판시 맵 및 어실러리 패치 정보를 파일 타입 또는 NALU타입으로 멀티플렉싱할 수 있다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법의 멀티플렉싱은 지오메트리 이미지, 텍스쳐 이미지, 어큐판시 맵 및 어실러리 패치 정보를 파일 타입으로 멀티플렉싱하고, 여기서 타입은 멀티플 트랙들을 포함할 수 있다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법의 멀티플 트랙들은 지오메트리 이미지를 포함하는 제1트랙, 텍스쳐 이미지를 포함하는 제2트랙, 어큐판시 맵 및 어실러리 패치 정보를 포함하는 제3트랙을 포함할 수 있다. 실시예들에 따라, 제1, 제2 표현은 구분 및/또는 명명하기 위해서 사용된 표현으로 해석된다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법의 제1트랙, 제2트랙 및 제3트랙은 비디오 그룹 박스를 포함하고, 비디오 그룹 박스는 헤더 박스를 포함하고, 헤더 박스는 포인트 클라우드 관련 데이터를 포함하는지 여부를 나타낼 수 있다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법의 멀티플렉싱은 지오메트리 이미지, 텍스쳐 이미지 및 어큐판시 맵을 파일로 멀티플렉싱할 수 있다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법의 파일은 멀티플 트랙(multiple PCC tracks)들을 포함할 수 있다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법의 멀티플 트랙들은 지오메트리 이미지를 포함하는 제1트랙, 텍스쳐 이미지를 포함하는 제2트랙, 어큐판시 맵을 포함하는 제3트랙을 포함할 수 있다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법의 파일은 그룹 박스를 포함하고, 그룹 박스는 제1트랙, 제2트랙 또는 제3트랙 중 적어도 하나를 나타내는 정보를 포함할 수 있다.
도48은 실시예들에 따른 runLength 및 best_traversal_order_index의 예시를 나타낸다.
예를 들어, 실시예들은 4by4 블록 상에 픽셀의 유무를 파악하는 코딩 방식을 사용할 수 있다. 구체적으로, 실시예들은 픽셀을 스캔하여 1의 개수, 0의 개수를 파악하기 위해서 지그재그 스캔 방식을 사용할 수 있다. 나아가, 실시예들은 특정 방향에 기반하여 런의 숫자를 감소 시키는 스캔 방식을 사용할 수 있다. 이러한 방법은 런 방식 코딩의 효율을 증가시킬 수 있다. 도면의 테이블은 run length 인덱스에 따른 run length를 나타낸다.
실시예들에 따른 PCC track grouping 관련 트랙/파일은 다음 정보를 포함한다. PCC를 구성하는 데이터를 포함하는 geometry image D0/D1 track들, texture image track, occupancy map/auxiliary patch information track들은 다음의 PccVideoGroupBox를 포함할 수 있으며, 하나의 PCC 콘텐트를 위해 필요한 track들임을 나타낼 수 있다. PccTrackGroupBox는 앞서 설명한 PccHeaderBox를 포함할 수도 있다. 하나의 PCC track group에 속한 track들은 동일한 track_group_type (='pctg') 및 동일한 track_group_id 값을 갖는 PccTrackGroupBox를 포함한다. 동일한 PCC track group내에는 geometry image D0/D1 track들, texture image track, occupancy map/auxiliary patch information track이 종류별로 각각 하나씩만 존재해야 한다는 제약사항을 둘 수도 있다. 실시예들에 따른 PCC track grouping은 멀티플 PCC 트랙들(multiple PCC tracks)을 통해서 전달될 수 있다.
class PccTrackGroupBox() extends TrackGroupTypeBox ('pctg') {
PccHeaderBox pcc_header_box; // optional
}
하나의 파일 내 PCC 데이터 외 다른 데이터, 예를 들어 2D데이터 등이 있는 경우, 상술한 실시예들을 사용하여 디코더가 효율적으로 PCC 데이터를 식별할 수 있는 효과가 있다. 실시예들에 따른 디멀티플렉서는 멀티플 PCC 트랙들 상 PCC track grouping에 기반하여 pcc_header_box를 획득하면, 디코더가 필요한 PCC 데이터를 latency 및 디코더 복잡도 없이 효울적으로 디코딩할 수 있다.
실시예들에 따른 PCC track grouping로 인하여, 수신기의 file parser (demultiplexer) 는 본 정보를 이용하여 PCC content 재생에 필요한 데이터들을 빠르게 필터링 할 수 있다. 일례로 하나의 파일에 PCC를위한 geometry, image, occupancy map, aux. patch info. 4개의 track과 2D 비디오 track 등 PCC 이외의 content들이 동시에 존재할 경우 본 정보를 이용하여 PCC　content 재생에 필요한 4개의 track만을 빠르게 필터링할 수 있다. 또한 수신기는 본 정보를 이용하여 필터링한 track들을 처리하기 위해　필요한 resource를 계산하여 PCC content 재생을 위한 최소의 resouce (memory, decoder instance 등)만을 이용하여 PCC content를 재생할 수 있게 한다.
실시예들에 따른 PCC track grouping 박스 정보를 보고, 예를 들어, track_group_type 및/또는 track_group_id에 기반하여 그룹핑된 트랙을 디코더가 식별할 수 있고, 트랙에 포함된 포인트 클라우드 데이터를 빠르게 필터링할 수 있다.
실시예들에 따른 PCC geometry track referencing 관련 트랙/파일은 다음 정보를 포함한다. PCC를 구성하는 geometry image D0 track과 geometry image D1 track이 존재하고, 두 track이 포함하는 geometry image D0, D1 layer들 간에 coding dependenc가 존재할 경우 (e.g. D0는 intra coding, D1은 D0와의 차분영상으로 coding된 경우), TrackReferenceBox를 통해 두 track들 간의 의존성이 표현될 수 있다. 이를 위해 새로운 'pgdp' (PCC geometry image dependency) referemce_type이 정의될 수 있으며, 일례로 D1 track이 'pgdp' reference_type의 TrackReferenceTypeBox를 포함하고 Track_IDs[]에 D0 track의 track_ID 값을 포함할 수 있다. 동일한 방법으로 'pgdp'를 대신하여 기존의 'sbas'와 같은 reference_type이 사용될 수도 있다. 실시예들에 따른 PCC geometry track referencing 은 멀티플 PCC 트랙들(multiple PCC tracks)을 통해서 전달될 수 있다.
aligned(8) class TrackReferenceBox extends Box('tref') {
TrackReferenceTypeBox [];
}
aligned(8) class TrackReferenceTypeBox (unsigned int(32) reference_type) extends Box(reference_type) {
unsigned int(32) track_IDs[];
}
실시예들에 따른 PCC track을 위한 SchemeType 관련 트랙/파일은 다음 정보를 포함한다. PCC frame이 복호화될 경우, 복호화된 PCC frame은 하나 또는 두 layer의 geometry image, texture image, occupancy map, auxiliary patch information 등의 데이터를 포함할 수 있다. 이들 데이터들 모두가 하나의 PCC video track에 포함될 수 있으며, 이 데이터들을 기반으로 post processing하여 point cloud를 재구성할 수 있다. 이와 같이 PCC 데이터를 모두 포함하는 track은 일례로, SchemeTypeBox에 존재하는 scheme_type의 'pccs' 값을 통해 식별될 수 있다. (앞서 설명한 PCC 데이터들이 여러 track에 나뉘어 포함되는 'pccv'와 구분을 위해 다른 scheme_type을 정의할 수 있다. ) 실시예들에 따른 PCC track을 위한 SchemeType은 싱글 PCC 트랙(single PCC track)에 의해 전달될 수 있다.
aligned(8) class SchemeTypeBox extends FullBox('schm', 0, flags) {
unsigned int(32) scheme_type;
unsigned int(32) scheme_version;
if (flags & 0x000001) {
unsigned int(8) scheme_uri[];
}
}
실시예들에 따른 PCC Video Box은 다음과 같은 정보를 포함한다.
PCC 데이터를 포함하는 PCC track은 PccVideoBox를 가질 수 있다. PccVideoBox는 SchemeType이 'pccv'일 경우 SchemeInfomationBox 하위에 존재할 수 있다. 또는 SchemeType 과 무관하게 VisualSampleEntry 하위에 존재할 수도 있다. PccVideoBox는, PCC GOF header 데이터를 직접 포함할 수 있다. 실시예들에 따른 PCC Video Box은 싱글 PCC 트랙(single PCC track)에 의해 전달될 수 있다.
Box Type: 'pccs'
Container: SchemeInformationBox or VisualSampleEntry
Mandatory: Yes (when the SchemeType is 'pccs')
Quantity: One
aligned(8) class PccVideoBox extends FullBox('pccs', version = 0, 0) {
PccHeaderBox pcc_header_box; // optional
Box[] any_box; // optional
}
실시예들에 따른 Sub-sample을 이용한 single track내 PCC 데이터 구분 방법 다음의 정보에 기초하여 수행될 수 있다. PCC 데이터들이 하나의 track에 존재할 경우, 해당 track의 media sample들을 여러 sub-sample로 나눌 수 있고, 각 sub-sample이 geometry image (D0/D1), texture image, occupancy map, auxiliary patch information 등의 PCC 데이터에 해당될 수 있다. 이처럼 sub-sample과 PCC 데이터의 맵핑 관계를 기술하기 위해, SubSampleInformationBox의 codec_specific_parameters를 아래와 같이 정의하여 사용할 수 있다.
aligned(8) class SubSampleInformationBox extends FullBox('subs', version, flags) {
unsigned int(32) entry_count;
for (i=0; i < entry_count; i++) {
unsigned int(32) sample_delta;
unsigned int(16) subsample_count;
if (subsample_count > 0) {
for (j=0; j < subsample_count; j++) {
if(version == 1) {
unsigned int(32) subsample_size;
}
else {
unsigned int(16) subsample_size;
}
unsigned int(8) subsample_priority;
unsigned int(8) discardable;
unsigned int(32) codec_specific_parameters;
}
}
}
}
unsigned int(3) pcc_data_type;
bit(29) reserved = 0;
실시예들에 따른 pcc_data_type : sub-sample에 포함된 PCC 데이터의 type을 나타낸다. 예를 들어, 0일 경우 geometry image D0, 1일 경우 geometry image D1, 2일 경우 texture image, 3일 경우 occupancy map, 4일 경우 auxiliary patch information이 sub-sample에 포함됨을 나타낼 수 있다.
실시예들에 따른 싱글 PCC 트랙은 지오메트리, 텍스쳐, 오큐판시, 오실러리 맵 각각을 포함하는 샘플을 포함할 수 있고, 하나의 샘플이 복수의 샘플들을 포함할 수 있다. 샘플을 실시예들에 따른 서브-샘플을 사용하여 구별할 수 있다. 실시예들에 따른 서브-샘플이 지오메트리, 텍스쳐 등을 포함할 수 있다.
실시예들에 따른 샘플, 샘플 그룹핑 및/또는 서브-샘플 방식은 지오메트리, 텍스쳐 비디오, 오큐판시 맵, 오실러리 패치 인포메이션 등에 적용될 수 있다.
실시예들에 따른 Sample grouping을 이용한 PCC 데이터 구분 방법은 다음의 정보에 기초하여 수행될 수 있다. PCC 데이터들이 하나의 track에 존재할 경우, 해당 track의 media sample들을 geometry image (D0/D1), texture image, occupancy map, auxiliary patch information 등의 PCC 데이터들 중 하나를 포함할 수 있다. 이처럼 sample이 여러 PCC 데이터들 중 하나임을 식별하기 위해 다음과 같은 sample group box들이 사용될 수 있다. 각각의 box들은 특정 sample들과 링크되어 해당 sample이 어느 PCC 데이터인지를 식별하는데 사용될 수 있다. 실시예들에 따른 Sample grouping은 싱글 PCC 트랙(single PCC track)에 의해 전송될 수 있다.
class PccGeometryD0ImageGroupEntry extends VisualSampleGroupEntry('pd0g') {
}
class PccGeometryD1ImageGroupEntry extends VisualSampleGroupEntry('pd1g') {
}
class PccTextureImageGroupEntry extends VisualSampleGroupEntry('pteg') {
}
class PccOccupancyMapGroupEntry extends VisualSampleGroupEntry('pomg') {
}
class PccAuxiliaryPatchInfoGroupEntry extends VisualSampleGroupEntry('papg') {
}
실시예들에 따른 비쥬얼 샘플 그룹 엔트리는 PccGeometryD0, PccGeometryD1, PccTexture, PccOccupancyMap, PccAuxiliaryPatchInfo 각각에 대한 타입 정보 알려주는 엔트리로 확장될 수 있다. 이로 인하여, 샘플이 어떤한 데이터를 전송하는지를 실시예들에 따른 디코더에 알려줄 수 있다.
이하에서는 실시예들에 따른 메타데이터를 세부적으로 분류하는 방법을 설명한다.
실시예들에 따른Sample auxiliary information을 이용한 occupancy map, auxiliary patch information, geometry image, texture image 제공 방법은 다음의 정보에 기반하여 수행될 수 있다. 실시예들에 따른Sample auxiliary information은 싱글 PCC 트랙에 의해 전달될 수 있다. PCC 데이터들이 하나의 track에 존재할 경우, 해당 track의 media sample들을 geometry image (D0/D1), texture image, occupancy map, auxiliary patch information 등의 PCC 데이터들 중 하나, 또는 앞서 제안한 sub-sample을 이용하여 하나 이상의 다른 종류의 PCC 데이터가 media sample에 포함될 수 있다. Media sample에 포함되지 않은 PCC 데이터는 sample auxiliary information으로 설정되어 해당 sample과 링크될 수 있다. Sample auxiliary information은 sample과 같은 파일 내에 저장될 수 있으며, 해당 데이터의 size와 offset을 기술하기 위해 다음의 SampleAuxiliaryInformationSizesBox와 SampleAuxiliaryInformationOffsetsBox가 각각 사용될 수 있다. Sample auxiliary information에 포함된 PCC data 식별을 위해 aux_info_type과 aux_info_type_parameter를 다음과 같이 정의할 수 있다.
실시예들에 따른aux_info_type : 'pccd' 일 경우 sample auxiliary information에 PCC 데이터를 포함함을 나타낼 수 있다.
실시예들에 따른aux_info_type_parameter : aux_info_type이 'pccd' 일 경우, 본 필드는 다음과 같이 정의될 수 있다: unsigned int(3) pcc_data_type; bit(29) reserved = 0;
실시예들에 따른pcc_data_type은 sample auxiliary information에 포함된 PCC 데이터의 type을 나타낸다. 일례로 0일 경우 occupancy map, 1일 경우 auxiliary patch information, 2일 경우 geometry image D1, 3일 경우 geometry image D0, 4일 경우 texture image가 sample auxiliary information에 포함됨을 나타낼 수 있다.
aligned(8) class SampleAuxiliaryInformationSizesBox extends FullBox('saiz', version = 0, flags)
{
if (flags & 1) {
unsigned int(32) aux_info_type;
unsigned int(32) aux_info_type_parameter;
}
unsigned int(8) default_sample_info_size;
unsigned int(32) sample_count;
if (default_sample_info_size == 0) {
unsigned int(8) sample_info_size[ sample_count ];
}
}
aligned(8) class SampleAuxiliaryInformationOffsetsBox extends FullBox('saio', version, flags) {
if (flags & 1) {
unsigned int(32) aux_info_type;
unsigned int(32) aux_info_type_parameter;
}
unsigned int(32) entry_count;
if ( version == 0 ) {
unsigned int(32) offset[ entry_count];
}
else {
unsigned int(64) offset[ entry_count];
}
}
실시예들에 따른 시그널링 정보는 명칭으로 제한해석되지 않으며, 시그널링 정보의 기능/효과 등에 기반하여 해석될 수 있다.
도49는 실시예들에 따른 NALU stream 기반 Multiplexing/Demultiplexing을 나타낸다.
실시예들에 따른 멀티플렉싱은 지오메트리 이미지(NALU 스트림), 텍스쳐 이미지(NALU 스트림), 어큐판시 맵 및/또는 오실러리 패치 인포메이션을 멀티플렉싱한다. 실시예들에 따른 멀티플렉싱은 NALU 기반 인캡슐레이션할 수 있다.
실시예들에 따른 딜리버리는 멀티플렉싱된 데이터를 전송한다. 실시예들에 따른 딜리버리는 지오메트리 이미지(NALU 스트림), 텍스쳐 이미지(NALU 스트림), 어큐판시 맵 및/또는 오실러리 패치 인포메이션을 포함하는 PCC 비트스트림을 ISOBMFF 파일 기반으로 전달한다.
실시예들에 따른 디멀티플렉싱은 지오메트리 이미지(NALU 스트림), 텍스쳐 이미지(NALU 스트림), 어큐판시 맵 및/또는 오실러리 패치 인포메이션을 디멀티플렉싱한다. 실시예들에 따른 디멀티플렉싱은 NALU 기반 디캡슐레이션할 수 있다.
실시예들에 따른 NALU stream 기반 Multiplexing/Demultiplexing의 상세 동작은 이하에서 설명한다.
실시예들에 따른 Geometry / Texture image는 Nuh_layer_id를 이용한 D0, D1, texture 등을 구분할 수 있다. layer 별 PCC 시그널링하는 실시예들을 제안한다. (예를 들어, new SEI message, VPS에 정보 추가)
실시예들에 따른 Occupancy map / Auxiliary patch information 관련하여, 실시예들에 따른 SEI 메시지를 제안한다.
실시예들에 따른 PCC GOF header 관련하여, 실시예들에 따른 SEI 메시지를 제안한다.
도50은 실시예들에 따른 PCC layer information을 나타낸다.
실시예들에 따른 PCC layer information SEI message와 관련하여, PCC layer information SEI는 다음과 같이 구성될 수 있다. NAL unit stream은 nal_unit_header()의 nuh_layer_id에 의해 구분되는 다양한 layer로 구성될 수 있다. PCC 데이터들을 하나의 NAL unit stream으로 구성하기 위해 여러 종류의 PCC 데이터들을 각각 하나의 layer로 구성할 수 있다. PCC layer information SEI는 layer별 PCC 데이터 맵핑 정보를 식별해 주는 역할을 한다.
실시예들에 따른 num_layers : NAL unit stream에 포함된 layer의 개수를 의미할 수 있다.
실시예들에 따른 nuh_layer_id : 각 layer에 부여된 고유 식별자로 nal_unit_header()의 nuh_layer_id와 동일한 의미를 갖는다.
실시예들에 따른 pcc_data_type : 해당 layer에 포함된 PCC 데이터의 type을 나타낸다. 일례로 0일 경우 occupancy map, 1일 경우 auxiliary patch information, 2일 경우 geometry image D1, 3일 경우 geometry image D0, 4일 경우 texture image가 sample auxiliary information에 포함됨을 나타낼 수 있다.
이하에서 설명하는 실시예들에 따른 메타데이터는 실시예들에 따른 nuh_layer_id마다 pcc_data_type을 알려줄 수 있는 효과가 있다.
실시예들에 따른 nuh_layer_id 및 nuh_layer_id에 따른 메타데이터를 사용하여 PCC 데이터를 표현할 수 있고 효율적으로 지오메트리 및 텍스쳐를 구별할 수 있는 효과가 있다.
도51은 실시예들에 따른 PCC auxiliary patch information을 나타낸다.
실시예들에 따른 PCC auxiliary patch information SEI message 관련하여, PCC auxiliary patch information SEI message는 다음과 같이 구성될 수 있다. 각 필드의 의미는 앞서 설명한 PCC auxiliary patch information timed metadata에서와 유사하다. . PCC auxiliary patch information SEI message는 VCL NAL unit을 통해 전송되는 geometry image, texture image 등에 auxiliary patch information 메타데이터를 제공하는 역할을 하며 시간의 흐름에 따라 dynamic하게 변화할 수 있다. 현재 SEI message 내용은 같은 종류의 다음 SEI message가 해석될 때 까지만 유효하게 함으로써 dynamic한 메타데이터를 적용할 수 있게 한다.
실시예들에 따른 patch_count은 지오메트리 및 텍스쳐 비디오들 내 패치들의 개수를 나타낸다. patch_count은 0보다 클 수 있다( is the number of patches in the geometry and texture videos. It shall be larger than 0.)
실시예들에 따른 occupancy_precision은 오큐판시 맵 프리시즌의 픽셀 내 수평 및 수직 해상도이다. 이 값은 오큐판시가 시그널링되는 서브-블록 사이즈에 대응된다. 오큐판시 맵의 로스리스 코딩을 달성하기 위해서 이 값은 사이즈 1로 세팅될 수 있다( is the horizontal and vertical resolution, in pixels, of the occupancy map precision. This corresponds to the sub-block size for which occupancy is signaled. To achieve lossless coding of occupancy map this should be set to size 1.)
실시예들에 따른 max_candidate_count 은 패치 캔디데이트 리스트 내 캔디데이트들의 최대 개수를 나타낸다(specifies the maximum number of candidates in the patch candidate list. )
실시예들에 따른 byte_count_u0 은 patch_u0의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_u0.)
실시예들에 따른 byte_count_v0 은 patch_v0의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_v0.)
실시예들에 따른 byte_count_u1 은 patch_u1의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_u1.)
실시예들에 따른 byte_count_v1 은 patch_v1의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_v1.)
실시예들에 따른 byte_count_d1 은 patch_d1의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_d1.)
실시예들에 따른 byte_count_delta_size_u0 은 delta_size_u0 의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of delta_size_u0.)
실시예들에 따른 byte_count_delta_size_v0 은 delta_size_v0의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of delta_size_v0.)
실시예들에 따른 patch_u0 은 patch bounding box의 size occupancy_resolution x occupancy_resolution의 탑-레프트 코너 서브블록의 X-코디네이트를 나타낸다. patch_u0의 값은 0 내지 frame_width/occupancy_resolution -1(포함)의 범위 내에 있을 수 있다(specifies the x-coordinate of the top-left corner subblock of size occupancy_resolution x occupancy_resolution of the patch bounding box. The value of patch_u0 shall be in the range of 0 to frame_width/occupancy_resolution 1, inclusive.)
실시예들에 따른 patch_v0 은 patch bounding box의 size occupancy_resolution x occupancy_resolution의 탑-레프트 코너 서브블록의 Y-코디네이트를 나타낸다. patch_v0의 값은 0 내지 frame_height/occupancy_resolution -1(포함)의 범위 내에 있을 수 있다(specifies the y-coordinate of the top-left corner subblock of size occupancy_resolution x occupancy_resolution of the patch bounding box. The value of patch_v0 shall be in the range of 0 to frame_height/occupancy_resolution 1, inclusive.)
실시예들에 따른 patch_u1 은 패치 포인트들의 3D bounding box의 미니멈 X-코디네이트를 나타낸다. patch_u1의 값은 0 내지 to frame_width-1(포함)의 범위 내에 있을 수 있다(specifies the minimum x-coordinate of the 3D bounding box of patch points.. The value of patch_u1 shall be in the range of 0 to frame_width 1, inclusive.)
실시예들에 따른 patch_v1 은 패치 포인트들의 3D bounding box의 맥시멈 X-코디네이트를 나타낸다. patch_v1의 값은 0 내지 frameHeight-1(포함)의 범위 내에 있을 수 있다(is the minimum y-coordinate of the 3D bounding box of patch points,. The value of patch_v1 shall be in the range of 0 to frameHeight 1, inclusive.)
실시예들에 따른 patch_d1 은 패치들의 미니멈 뎁스를 나타낸다(specifies the minimum depth of the patch. )
실시예들에 따른 delta_size_u0 is the difference of patch width between the current patch and the previous one.
실시예들에 따른 delta_size_v0 은 커런트 패치 및 이전 패치 간 패치 높이의 차이를 나타낸다(is the difference of patch height between the current patch and the previous one. )
실시예들에 따른 normal_axis 은 플렌 프로젝션 박스를 나타낸다. normal_axis의 값은 0 내지 2(포함)의 범위 내에 있을 수 있다. 0, 1, 2의 normalAxis 값은 X, Y, Z 프로젝션 축 각각에 대응된다(specifies the plane projection index. The value of normal_axis shall be in the range of 0 to 2, inclusive. normalAxis values of 0, 1, and 2 correspond to the X, Y, and Z projection axis, respectively.)
실시예들에 따른 candidate_index_flag 은 candidate_index이 존재하는지 아닌지 여부를 나타낸다(specifies whether candidate_index is present or not.)
실시예들에 따른 patch_index_flag 은 patch_index이 존재하는지 아닌지 여부를 나타낸다(specifies whether patch_index is present or not.)
실시예들에 따른 byte_count_candidate_index 은 candidate_index 의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of candidate_index.)
실시예들에 따른 byte_count_patch_index 은 patch_index 의 픽스-렝스 코딩을 위한 바이트들의 개수를 나타낸다(specifies the number of bytes for fixed-length coding of patch_index.)
실시예들에 따른 candidate_index 은 패치 캔디테이트 리스트에 대한 인덱스를 나타낸다. candidate_index의 값은 0 내지 max_candidate_count(포함)의 범위 내에 있을 수 있다(is the index into the patch candidate list. The value of candidate_index shall be in the range of 0 to max_candidate_count, inclusive.)
실시예들에 따른 patch_index 은 프레임 연관된 descending size order 내 저장된 패치 리스트에 대한 인덱스를 나타낸다( is an index to a sorted patch list, in descending size order, associated with a frame.)
도52는 실시예들에 따른 PCC occupancy map을 나타낸다.
실시예들에 따른 PCC occupancy map SEI message 관련하여, PCC occupancy map SEI message는 다음과 같이 구성될 수 있다. 각 필드의 의미는 앞서 설명한 PCC auxiliary patch information timed metadata에서와 유사하다. PCC auxiliary patch information SEI message는 VCL NAL unit을 통해 전송되는 geometry image, texture image 등에 occupancy map 데이터를 제공하는 역할을 하며 시간의 흐름에 따라 dynamic하게 변화할 수 있다. 현재 SEI message 내용은 같은 종류의 다음 SEI message가 해석될 때 까지만 유효하게 함으로써 dynamic한 메타데이터를 적용할 수 있게 한다.
실시예들에 따른 is_full 은 size occupancy_resolution × occupancy_resolution block의 커런트 오큐판시 블록이 풀인지 여부를 나타낸다. is_full이1인 경우 커런트 블록이 풀임을 나타낸다. is_full이 0인 경우 커런트 오큐판시 블록이 풀이 아님을 나타낸다(specifies whether the current occupancy block of size occupancy_resolution × occupancy_resolution block is full. is_full equal to 1 specifies that the curret block is full. is_full equal to 0 specifies that the current occupancy block is not full. )
실시예들에 따른 best_traversal_order_index 은 current occupancy_resolution × occupancy_resolution block 내 size occupancy_precision × occupancy_precision의 서브-블록들을 위한 스캔 오더를 나타낸다. best_traversal_order_index의 값은 0 내지 4(포함)의 범위 내에 있을 수 있다(specifies the scan order for sub-blocks of size occupancy_precision × occupancy_precision in the current occupancy_resolution × occupancy_resolution block. The value of best_traversal_order_index shall be in the range of 0 to 4, inclusive.)
실시예들에 따른 run_count_prefix 은 runCountMinusTwo변수의 데리베이션 내 사용될 수 있다(is used in the derivation of variable runCountMinusTwo.)
실시예들에 따른 run_count_suffix 은 runCountMinusTwo 변수의 데리베이션 내 사용될 수 있다. 존재하지 않는 경우, run_count_suffix의 값은 0일 수 있다(is used in the derivation of variable runCountMinusTwo. When not present, the value of run_count_suffix is inferred to be equal to 0.)
파티큘러 블록을 위한 blockToPatch의 값이 제로와 같이 않은 경우, 블록은 풀이 아닐 수 있다. unCountMinusTwo 플러스 2는 블록을 위한 시그널된 런들의 개수를 나타낸다. runCountMinusTwo의 값은 0 내지 (occupancy_resolution * occupancy_resolution)-1(포함)의 범위 내에 있을 수 있다(When the value of blockToPatch for a particular block is no equal to zero and the block is not full, runCountMinusTwo plus 2 represents the number of signalled runs for a block. The value of runCountMinusTwo shall be in the range of 0 to (occupancy_resolution * occupancy_resolution) 1, inclusive.)
실시예들에 따른 runCountMinusTwo 는 다음과 같이 표현될 수 있다:
runCountMinusTwo = (1 << run_count_prefix)-1+ run_count_suffix
오큐판시는 제 1 서브블록(of occupancyPrecision × occupancyPrecision pixels)을 위한 오큐판시 값을 나타낸다. 오큐판시가 0인 경우 제 1 서브블록이 비어 있음을 나타낸다. 오큐판시가 1인 경우 제1 서브블록이 차지되어 있음을 나타낸다(occupancy specifies the occupancy value for the first sub-block (of occupancyPrecision × occupancyPrecision pixels). occupancy equal to 0 specifies that the first sub-block is empty. occupancy equal to 1 specifies that the first sub-block is occupied. )
실시예들에 따른 run_length_idx 는 런 렝스를 나타낸다. runLengthIdx의 값은 0내지14(포함)의 범위 내에 있을 수 있다(is indication of the run length. The value of runLengthIdx shall be in the range of 0 to 14, inclusive.)
도53은 실시예들에 따른 PCC group of frames header를 나타낸다.
실시예들에 따른 PCC group of frames header SEI message 관련하여, PCC group of frames header SEI message는 다음과 같이 구성될 수 있다. 각 필드의 의미는 앞서 설명한 PccGofHeaderBox에서와 유사하다. PCC group of frames header SEI message 는 VCL NAL unit을 통해 전송되는 geometry image, texture image 및 SEI message로 전송되는 occupancy map, patch auxiliary information등에 occupancy map 에 header 데이터를 제공하는 역할을 하며 시간의 흐름에 따라 dynamic하게 변화할 수 있다. 현재 SEI message 내용은 같은 종류의 다음 SEI message가 해석될 때 까지만 유효하게 함으로써 dynamic한 메타데이터를 적용할 수 있게 한다.
실시예들에 따른 identified_codec은 PCC 데이터에 사용된 코덱을 나타낸다.
실시예들에 따른 frame_width 은 지오메트리 및 텍스쳐 비디오들의 픽셀들 내 프레임 너비를 나타내고, 이 값은 멀티플 어큐판시 레졸루션일 것이다.(indicates the frame width, in pixels, of the geometry and texture videos. It shall be multiple of occupancyResolution.)
실시예들에 따른 frame_height 은 지오메트리 및 텍스쳐 비디오들의 픽셀들 내 프레임 높이를 나타내고, 이 값은 멀티플 어큐판시 레졸루션일 것이다(indicates the frame height, in pixels, of the geometry and texture videos. It shall be multiple of occupancyResolution.)
실시예들에 따른 occupancy_resolution 은 지오메트리 및 텍스쳐 비디오들 내 패치들이 패킹된 픽셀들 내의 horizontal 레졸루션 및 vertical 레졸루션을 나타낸다. 이 값은 어큐판시 레졸루션 이븐 값일 것이다.(indicates the horizontal and vertical resolution, in pixels, at which patches are packed in the geometry and texture videos. It shall be an even value multiple of occupancyPrecision.)
실시예들에 따른 radius_to_smoothing 은 스무딩을 위한 이웃들을 감지하는 반경을 나타낸다. radius_to_smoothing의 값은 0 내지 255(포함)의 범위 내에 있을 수 있다( indicates the radius to detect neighbours for smoothing. The value of radius_to_smoothing shall be in the range of 0 to 255, inclusive.)
실시예들에 따른 neighbor_count_smoothing 은 스무딩을 위해 사용되는 이웃들의 최대 개수를 나타낸다. neighbor_count_smoothing의 값은 0 내지 255(포함)의 범위 내에 있을 수 있다( indicates the maximum number of neighours used for smoothing. The value of neighbor_count_smoothing shall be in the range of 0 to 255, inclusive.)
실시예들에 따른 radius2_boundary_detection 은 바운더리 포인트 디텍션을 위한 반경을 나타낸다. radius2_boundary_detection의 범위는 0 내지 255(포함)의 범위 내에 있을 수 있다( indicates the radius for boundary point detection. The value of radius2_boundary_detection shall be in the range of 0 to 255, inclusive.)
실시예들에 따른 threshold_smoothing 은 스무딩 트레스홀드를 나타낸다. threshold_smoothing의 값은 0 내지 255(포함)의 범위 내에 있을 수 있다( indicates the smoothing threshold. The value of threshold_smoothing shall be in the range of 0 to 255, inclusive.)
실시예들에 따른 lossless_geometry 은 로스리스 지오메트리 코딩을 나타낸다. lossless_geometry이 1일 때 포인트 클라우드 지오메트리 인포메이션이 로스리스하게 코딩됨을 나타낸다. lossless_geometry의 값이 0인 경우 포인트 클라우드 지오메트리 인포메이션이 로시 매너로 코딩됨을 나타낸다( indicates lossless geometry coding. The value of lossless_geometry equal to 1 indicates that point cloud geometry information is coded losslessly. The value of lossless_geometry equal to 0 indicates that point cloud geometry information is coded in a lossy manner.)
실시예들에 따른 lossless_texture 은 로스리스 텍스쳐 인코딩을 나타낸다. lossless_texture의 값이 1인 경우 포인트 클라우드 텍스쳐 인포메이션이 로스리스하게 코딩됨을 나타낸다. lossless_texture의 값이 0인 경우 포인트 클라우드 텍스쳐 인포메이션이 로시 매너로 코딩됨을 나타낸다( indicates lossless texture encoding. The value of lossless_texture equal to 1 indicates that point cloud texture information is coded losslessly. The value of lossless_texture equal to 0 indicates that point cloud texture information is coded in a lossy manner.)
실시예들에 따른 no_attributes 은 어트리뷰트가 지오메트리 데이터와 함께 코딩되는지 여부를 나타낸다. no_attributes의 값이 1인 경우 코딩된 포인트 클라우드 비트스트림은 어떠한 어트리뷰트 인포메이션을 포함하지 않음을 나타낸다. no_attributes의 값이 0인경우 코딩된 포인트 클라우드 비트스트림이 어트리뷰트 인포메이션을 포함함을 나타낸다( indicates whether to attributes are coded along with geometry data. The value of no_attributes equal to 1 indicates that the coded point cloud bitstream does not contain any attributes information. The value of no_attributes equal to 0 indicates that the coded point cloud bitstream contains attributes information.)
실시예들에 따른 lossless_geometry_444 은 지오메트리 프렝미들을 위한 4:2:0 또는4:4:4 video format을 사용하는지 여부를 나타낸다. lossless_geometry_444의 값이 1인 경우 지오메트리 비디오는 4:4:4 format으로 코딩됨을 나타낸다. 4:4:4 format의 값이 0인 경우 지오메트리 비디오가 4:2:0 format으로 코딩됨을 나타낸다( indicates whether to use 4:2:0 or 4:4:4 video format for geometry frames. The value of lossless_geometry_444 equal to 1 indicates that the geometry video is coded in 4:4:4 format. The value of lossless_geometry_444 equal to 0 indicates that the geometry video is coded in 4:2:0 format.)
실시예들에 따른 absolute_d1_coding 은 프로젝션 플렌에 근접한 레이어와 다른 지오메트리 레이더들이 어떻게 코딩되는지를 나타낸다. absolute_d1_coding의 값이 1인 경우 액츄얼 지오메트리 값들은 프로젝션 플렌에 가까운 레이어와 다른 지오메트리 레이어들을 위해 코딩됨을 나타낸다. absolute_d1_coding의 값이 0인 경우 프로젝션 플렌에 가까운 레이어와 다른 지오메트리 레이어들이 다르게 코딩됨을 나타낸다(indicates how the geometry layers other than the layer nearest to the projection plane are coded. absolute_d1_coding equal to 1 indicates that the actual geometry values are coded for the geometry layers other than the layer nearest to the projection plane. absolute_d1_coding equal to 0 indicates that the geometry layers other than the layer nearest to the projection plane are coded differentially. )
실시예들에 따른 bin_arithmetic_coding 은 바이너리 아리스메틱 코딩이 사용됨을 나타낸다. bin_arithmetic_coding의 값이 1인 경우 바이너리 아리스메틱 코딩이 모든 신택스 엘리먼트들을 위해 사용됨을 나타낸다. bin_arithmetic_coding의 값이 0인 경우 논-바이너리 아리스메틱 코딩이 일부 신택스 엘리먼트들을 위해 사용됨을 나타낸다( indicates whether binary arithmetic coding is used. The value of bin_arithmetic_coding equal to 1 indicates that binary arithmetic coding is used for all the syntax elements. The value of bin_arithmetic_coding equal to 0 indicates that non-binary arithmetic coding is used for some syntax elements.)
실시예들에 따른 gof_header_extension_flag은 GOF 헤더 익스텐션이 있는지 여부를 나타낸다.
도54는 실시예들에 따른 Geometry/Texture image packing을 나타낸다.
실시예들에 따른 이미지 패킹(Image packing)은 지오메트리 및 텍스쳐 이미지를 패킹된 이미지로 패킹할 수 있다.
실시예들에 따른 이미지 패킹은 Stereo frame packing 방법과 유사할 수 있다. 예를 들어, D0, texture만 존재할 경우에 적용될 수 있다. 또한, packing type (e.g. side-by-side..) 기술이 적용될 수 있다. 또한, 실시예들에 따른 이미지 패킹은 Region-wise packing 방법과 유사할 수 있다. 예를 들어, source (D0, D1 또는 texture) 에서 destination (packed image)으로 맵핑하고, 그 관계를 메타데이터로 기술할 수 있다.
실시예들에 따른 비디오 컴프레션은 패킹된 이미지를 NALU 스트림 기반으로 컴프레션할 수 있다.
실시예들에 따른 멀티플렉싱은 컴프레스된 이미지, 컴프레스된 오큐판시 맵, 컴프레스된 오실러리 패치 인포메이션을 멀티플렉싱할 수 있다.
실시예들에 따른 딜리버리는 PCC 비트스트림을 전송할 수 있다.
실시예들에 따른 디멀티플렉싱은 PCC 비트스트림을 디멀티플렉싱하여, 컴프레스된 이미지, 컴프레스된 오큐판시 맵, 컴프레스된 오실러리 패치 인포메이션을 생성할 수 있다.
실시예들에 따른 비디오 디컴프레션은 컴프레스된 이미지를 디컴프레션하여 패킹된 이미지를 생성할 수 있다.
실시예들에 따른이미지 언패킹(unpacking)은 패킹된 이미지로부터 지오메트리 이미지 및 텍스쳐 이미지를 생성할 수 있다.
실시예들에 따른 이미지 언패킹은 Stereo frame packing 방법과 유사할 수 있다. 예를 들어, D0, texture만 존재할 경우에 적용될 수 있다. 실시예들에 따른 이미지 언패킹은 packing type (e.g. side-by-side..) 기술이 적용될 수 있다. 또한, 실시예들에 따른 이미지 언패킹은 Region-wise packing 방법과 유사할 수 있다. 예를 들어, source (D0, D1 or texture) 에서 destination (packed image)으로 맵핑하고 그 관계를 기술할 수 있다.
실시예들에 따른 이미지 패킹은 지오메트리 이미지 및/또는 텍스쳐 이미지를 하나의 이미지로 패킹하여, latency 및 디코딩 복잡도 측면에서 효율성을 제공하는 효과가 있다.
도55는 실시예들에 따른 geometry와 image component들 간의 배치 방법을 나타낸다.
실시예들에 따른 PCC frame packing 관련하여, PCC를 구성하는 geometry image (e.g. D0 layer)와 texture image는 하나의 image frame sequence에 배치되어 하나의 layer로 구성되는 하나의 bitstream으로 복호화될 수 있다. 이러한 경우 다음의 PccFramePackingBox는 geometry와 image component들 간의 배치 방법을 알려줄 수 있다. 실시예들에 따른 PCC frame packing은 멀티플 PCC 트랙들(multiple PCC tracks)에 적용될 수 있다.
aligned(8) class PccFramePackingBox extends FullBox('pccp', version = 0, 0) {
unsigned int(8) pcc_frame_packing_type
}
실시예들에 따른 pcc_frame_packing_type : geometry와 image component들 간의 배치 방법을 도면과 같이 값으로 할당하여 알려줄 수 있다.
실시예들에 따른 PCC frame packing 관련하여, PCC를 구성하는 geometry image (e.g. D0 layer)와 texture image는 하나의 image frame sequence에 배치되어 하나의 layer로 구성되는 하나의 bitstream으로 복호화될 수 있다. 이러한 경우 다음의 PccFramePackingBox는 geometry와 image component들 간의 배치 방법을 알려줄 수 있다.
aligned(8) class PccFramePackingRegionBox extends FullBox('pccr', version = 0, 0) {
unsigned int(16) packed_picture_width;
unsigned int(16) packed_picture_height;
unsigned int(8) num_sources;
for(i = 0; i<num_sources; i++) {
unsigned int(8) num_regions[i];
unsigned int(2) source_picture_type[i]
bit(6) reserved = 0;
unsigned int(32) source_picture_width[i];
unsigned int(32) source_picture_height[i];
for (j = 0; j < num_regions; j++) {
unsigned int(32) source_reg_width[i][j];
unsigned int(32) source_reg_height[i][j];
unsigned int(32) source_reg_top[i][j];
unsigned int(32) source_reg_left[i][j];
unsigned int(3) transform_type[i][j];
bit(5) reserved = 0;
unsigned int(16) packed_reg_width[i][j];
unsigned int(16) packed_reg_height[i][j];
unsigned int(16) packed_reg_top[i][j];
unsigned int(16) packed_reg_left[i][j];
}
}
}
실시예들에 따른 packed_picture_width 및 packed_picture_height 은 패킹된 픽쳐 샘플 유닛 관련 패킹된 픽쳐의 너비 및 높이를 각각 나타낸다. packed_picture_width 및 packed_picture_height은 0보다 클 수 있다(specify the width and height, respectively, of the packed picture, in relative packed picture sample units. packed_picture_width and packed_picture_height shall both be greater than 0.)
실시예들에 따른 num_sources 은 소스 픽쳐들의 개수를 나타낸다(specifies the number of source pictures.)
실시예들에 따른 num_regions[i] 각 소스 픽쳐 마다 패킹된 리젼들의 개수를 나타낸다(specifies the number of packed regions per each source picture.)
실시예들에 따른 num_sourece_picture_type[i] 은 PCC 프레임들을 위한 소스 픽쳐의 타입을 나타낸다. 다음 값들이 기술된다 0: geometry image D0, 1: geometry image D1, 2: texture image, 3: reserved (specifies the type of source picture for PCC frames. The following values are specified: 0: geometry image D0, 1: geometry image D1, 2: texture image, 3: reserved)
실시예들에 따른 source_picture_width[i] 및source_picture_height[i] 은 소프 픽쳐 샘플 유닛들에 관한 소스 픽쳐의 각각 너비 및 높이를 나타낸다. source_picture_width[i] 및 sourcej_picture_height[i]은 0보다 클 수 있다(specify the width and height, respectively, of the source picture, in relative source picture sample units. source_picture_width[i] and sourcej_picture_height[i] shall both be greater than 0.)
실시예들에 따른 source_reg_width[i][j], source_reg_height[i][j], source_reg_top[i][j], 및 source_reg_left[i][j] 은 i번째 소스 픽쳐 내 j번째 소스 리젼 각각의 너비, 높이, 탑 오프셋 및 레프트 오프셋을 나타낸다(specify the width, height, top offset, and left offset, respectively, of the j-th source region, either within the i-th source picture.)
실시예들에 따른 transform_type[i][j] 은 i번째 소스 픽쳐의 j번째 프로젝트된 리젼에 리맵핑하는 j번째 패킹된 리젼에 적용되는 로테이션 및 미러링을 나타낸다. transform_type[i][j]이 로테이션 및 미러링 모두를 나타내는 경우, 로테이션은 패킹된 리젼의 샘플 로케이션들을 프로젝트된 리젼의 샘플 로케이션들로 전환하기 위한 미러링 이전에 적용될 수 있다. 다음 값들이 표현된다: 0: no transform, 1: mirroring horizontally, 2: rotation by 180 degrees (counter-clockwise), 3: rotation by 180 degrees (counter-clockwise) before mirroring horizontally, 4: rotation by 90 degrees (counter-clockwise) before mirroring horizontally, 5: rotation by 90 degrees (counter-clockwise), 6: rotation by 270 degrees (counter-clockwise) before mirroring horizontally, 7: rotation by 270 degrees (counter-clockwise) (specifies the rotation and mirroring that is applied to the j-th packed region to remap it to the j-th projected region of the i-th source picthre. When transform_type[i][j] specifies both rotation and mirroring, rotation is applied before mirroring for converting sample locations of a packed region to sample locations of a projected region. )
실시예들에 따른 packed_reg_width[i][j], packed_reg_height[i][j], packed_reg_top[i][j], 및 packed_reg_left[i][j] 은 i번째 소스 픽쳐을 위한 j번째 패킹된 리젼의 너비, 높이, 포프셋, 레프트 오프셋을 나타낸다(specify the width, height, the offset, and the left offset, respectively, of the j-th packed region for the i-the source picture.)
이하에서, 도 49의 NALU stream 기반 Multiplexing/Demultiplexing 관련하여, 추가 실시예들을 설명한다. 도49 및 이하의 설명을 함께 참조할 수 있다.
이하에서, 실시예들에 따른 메타데이터를 확장(extension)하는 방안을 제안한다.
실시예들에 따른 Geometry / Texture image 관련하여, Nuh_layer_id를 이용한 D0, D1, texture 구분이 가능하다. 또한, layer 별 PCC 시그널링 방안을 제안한다 (e.g. new SEI message, VPS에 정보 추가). 실시예들에 따른SEI message가 제공될 수 있고, VPS extension syntax 정의를 제안한다. 추가로, 실시예들은 PPS를 이용한 D0, D1, texture 구분이 가능하다. PPS extension을 이용한 시그널링 (D0 or D1 or texture)을 제안하고, 하나의 스트림에 복수 PPS에 기반하여 개별 NAL unit(slice)에서 해당 VPS 링크 (activation)를 제공하는 방안을 제안한다.
실시예들에 따른 Occupancy map / Auxiliary patch information 관련하여, 새로운SEI message를 제안한다. 또한, PPS extension syntax 정의를 제안한다.
실시예들에 따른 PCC GOF header 관련하여, 새로운 SEI message를 제안한다. 또한, 실시예들은 VPS extension syntax 정의 및 SPS extension syntax 정의를 제안한다.
실시예들에 따른 PCC NAL unit 은 new NAL unit type 을 정의한다. 예를 들어, Parameter set 만 포함하는 NAL unit 이 있을 수 있다. 예를 들어, PCC_VPS_NUT, PCC_SPS_NUT, PCC_PPS_NUT.
실시예들에 따른 IRAP PCC AU 은 PCC GOF 의 시작 AU를 포함하는 NAL unit일 수 있다.
실시예들에 따른 Access unit delimiter 은 PCC AU의 끝을 알릴 수 있다 (AU단위로 interleaving 되었을때).
실시예들에 따른 NAL unit interleaving 은 component 별로 다른 interleaving 적용이 가능하다. 예를 들어, GOP 구조가 같은 경우 AU 단위 interleaving, 그렇지 않은 경우 GOF 단위 interleaving. 구체적으로, GOF 단위 interleaving 및/또는 AU 단위 interleaving 이 가능하다. 실시예들에 따른 AU 단위 interleaving은 Component들의 GOP 구조가 같은 경우 및/또는 Component들의 GOP 구조가 다른 경우에 수행될 수 있다. 여기서 실시예들에 따른 GOP 구조가 다른 경우는 Decoding delay (DPB output delay) 차이 값에 기반하여 결정될 수 있다.
제안하는 실시예들을 이하에서 좀 더 상세하게 설명한다.
도56은 실시예들에 따른 VPS extension을 나타낸다.
실시예들에 따른 VPS extension with PCC layer information 관련하여, 앞서 설명한 PCC layer information은 SEI message로 구성되는 방법 이외에도 VPS extension 형태로 VPS 내에 포함될 수도 있다. 예를 들어 vps_pcc_layer_info_extension_flag를 VPS내에 추가하여 vps_pcc_layer_info_extension()의 존재 유무를 알릴 수 있다. vps_pcc_extension() 내부의 필드의 의미는 앞선 PCC layer information SEI message에서와 동일하다.
여러 개의 VPS에서 서로 다른 vps_pcc_layer_info_extension() 정보를 포함하여, 시간의 흐름에 따라 다른 VPS를 활성화(activation) 함으로써, 시간의 흐름에 따라 변화하는 PCC layer information을 적용할 수 있다. VPS의 activation을 위해 active parameter sets SEI message가 사용될 수 있다.
실시예들에 따른 video_parameter_set 는 vps_pcc_layer_info_extension_flag에 기반하여 실시예들에 따른 vps_pcc_extension() 를 시그널링할 수 있다.
실시예들에 따른 vps_pcc_layer_info_extension()는 num_layers, nuh_layer_id 및/또는 pcc_data_type을 전달할 수 있다. 각 필드의 정의는 상술한 바와 같다.
도57은 실시예들에 따른 pic_parameter_set을 나타낸다.
실시예들에 따른 PPS extension with PCC data type 관련하여, PCC bitstream에 포함된 PCC component들의 data type을 구분하기 위하여 PPS extension syntax가 정의될 수 있다. 일례로 pps_data_type_extension_flag를 PPS내에 추가하여 pps_data_type_extension()의 존재 유무를 알릴 수 있다. pps_data_type_extension()의 pcc_data_type은 slice header의 slice_pic_parameter_set_id를 이용하여 현재의 PCC를 참조 (activation)하는 slice에 포함된 PCC component의 data type을 나타낸다. 일례로 0일 경우 occupancy map, 1일 경우 auxiliary patch information, 2일 경우 geometry image D1, 3일 경우 geometry image D0, 4일 경우 texture image가 sample auxiliary information임을 나타낼 수 있다.
이 경우 앞서 하나의 layer를 하나의 PCC data type에 적용한 경우와 달리, 하나의 layer에 모든 data type의 PCC component들을 포함할 수 있다.
실시예들에 따른 NALU 스트림은 도면과 같이 VPS, SPS를 포함하고, 지오메트리 텍스쳐에 대한 PPS를 갖는 NALU유닛을 포함하고, 지오메트리, 텍스쳐에 대한 슬라이스를 갖는 NALU유닛을 포함한다. PPS 및 슬라이스 간 참조 방법은 실시예들에 따른 시그널링 정보(메타데이터)에 기반하여 수행된다.
실시예들에 따른 pic_parameter_set은 pps_pcc_data_type_extension_flag 에 기반하여 pps_pcc_data_type_extension(　)을 시그널링할 수 있다. 실시예들에 따른 vps_pcc_data_type_extension()은 pcc_data_type을 알려준다. 이로 인하여, 슬라이스 간 activation 관계를 디코더가 획득할 수 있다. 실시예들에 따른 pps_extension_data_flag은 pps extension data의 존재 여부를 시그널링할 수 있다.
도58은 실시예들에 따른pps_pcc_auxiliary_patch_info_extension ()를 나타낸다.
실시예들에 따른 PPS extension with auxiliary patch information 관련하여, PCC auxiliary patch information을 전달하기 위하여 PPS extension syntax가 정의될 수 있다. 일례로 pps_pcc_auxiliary_patch_info_extension_flag를 PPS내에 추가하여 pps_pcc_auxiliary_patch_info_extension()의 존재 유무를 알릴 수 있다. pps_pcc_auxiliary_patch_info_extension()의 내부 필드들은 slice header의 slice_pic_parameter_set_id를 이용하여 현재의 PCC를 참조 (activation)하는 slice에 적용될 PCC auxiliary patch information을 나타낸다. 서로 다른 pps_pcc_auxiliary_patch_info_extension()을 갖는 여러 개의 PPS를 송신단에 전달하고 slice에서 시간의 흐름에 따라 다른 PPS를 activation함으로써 시간에 따라 변화하는 PCC auxiliary patch information을 적용할 수 있다.
pps_pcc_auxiliary_patch_info_extension()과 동일한 정보 [e.g. sps_pcc_auxiliary_patch_info_extension()]가 SPS에 포함될 수 있다. 시간의 흐름에 따른 SPS의 activation을 위해 active parameter sets SEI message가 사용될 수 있다.
실시예들에 따른 pic_parameter_set은 pps_pcc_auxiliary_patch_info_extension_flag에 기반하여 pps_pcc_auxiliary_patch_info_extension(　)을 시그널링할 수 있다. pps_pcc_auxiliary_patch_info_extension ()은 slice header의 slice_pic_parameter_set_id에 기반하여 PCC를 참조 (activation)하는 slice에 적용될 PCC auxiliary patch information일 수 있다. 예를 들어, 하나의 PPS를 포함하는 NALU유닛을 activation하는 슬라이스가 하나 또는 하나 이상일 수 있다.
실시예들에 따른 PPS는 NALU유닛 링크를 제공하고, 실시예들에 따른 pps_pcc_data_type_extension(　)를 추가함으로써, 유닛 링크에 기반한 PCC데이터 타입을 시그널링할 수 있는 효과가 있다.
실시예들에 따른 pps_pcc_auxiliary_patch_info_extension(　)는 별도의 SEI 메시지를 정의하지 않고 PCC데이터를 시그널링할 수 있는 효과가 있다.
도59는 실시예들에 따른pps_pcc_occupancy_map_extension()을 나타낸다.
실시예들에 따른 PPS extension with occupancy map 관련하여, PCC occupancy map 을 전달하기 위하여 PPS extension syntax가 정의될 수 있다. 일례로 pps_pcc_occupancy_map_extension_flag를 PPS내에 추가하여 pps_pcc_occupancy_map_extension()의 존재 유무를 알릴 수 있다. pps_pcc_occupancy_map_extension()의 내부 필드들은 slice header의 slice_pic_parameter_set_id를 이용하여 현재의 PCC를 참조 (activation)하는 slice에 적용될 PCC occupancy map을 나타낸다. 서로 다른 pps_pcc_occupancy_map_extension()을 갖는 여러 개의 PPS를 송신단에 전달하고 slice에서 시간의 흐름에 따라 다른 PPS를 activation함으로써 시간에 따라 변화하는 PCC occupancy map을 적용할 수 있다.
pps_pcc_occupancy_map_extension()과 동일한 정보 [e.g. sps_pcc_occupancy_map_extension()]가 SPS에 포함될 수 있다. 시간의 흐름에 따른 SPS의 activation을 위해 active parameter sets SEI message가 사용될 수 있다.
실시예들에 따른 pic_parameter_set은 pps_pcc_occupancy_map_extension_flag에 기반하여 pps_pcc_occupancy_map_extension(　)를 시그널링할 수 있다. 실시예들에 따른 pps_pcc_occupancy_map_extension()은 어큐판시 맵 관련 정보를 전달한다. 또한, 하나의 PPS를 포함하는 NALU유닛을 activation하는 슬라이스가 하나 또는 하나 이상일 수 있다.
도60은 실시예들에 따른 vps_pcc_gof_header_extension()을 나타낸다.
실시예들에 따른 VPS extension with PCC GOF header 관련하여, 앞서 설명한 PCC group of frames header는 SEI message로 구성되는 방법 이외에도 VPS extension 형태로 VPS 내에 포함될 수도 있다. 일례로 vps_pcc_gof_header_extension_flag를 VPS내에 추가하여 vps_pcc_gof_header_extension()의 존재 유무를 알릴 수 있다. vps_pcc_gof_header_extension() 내부의 필드의 의미는 앞선 PCC group of frames header SEI message에서와 동일하다.
여러 개의 VPS에서 서로 다른 vps_pcc_gof_header_extension() 정보를 포함하여, 시간의 흐름에 따라 다른 VPS를 활성화(activation) 함으로써, 시간의 흐름에 따라 변화하는 PCC GOF header를 적용할 수 있다. VPS의 activation을 위해 active parameter sets SEI message가 사용될 수 있다.
VPS extension을 이용한 PCC GOF header 전달 방법은 앞서 설명한 하나의 layer가 하나의 data type의 PCC component와 맵핑될 때 적용 가능하다.
VPS extension이 아닌, SPS extension을 이용하여 PCC GOF heade를 전달할 수도 있다. [e.g. vps_pcc_gof_header_extension()]. 이 경우는 앞서 모든 data type의 PCC componen들이 하나의 layer를 통해 전달될 때 적용 가능하다.
실시예들에 따른 video_parameter_set은 vps_pcc_gof_header_extension_flag에 기반하여 vps_pcc_gof_header_extension()을 시그널링하고, 실시예들에 따른 vps_pcc_gof_header_extension()은 프레임 헤어듸 PCC 그룹 정보를 전달한다.
도61은 실시예들에 따른 pcc_nal_unit을 나타낸다.
실시예들에 따른 PCC NAL unit 관련하여, PCC component 전달을 위해 PCC NAL unit syntax가 다음과 같이 정의될 수 있다. PCC NAL unit header는 PCC component 구분을 위한 pcc_nal_unit_type_plus1을 포함할 수 있다. PCC NAL unit payload (rbsp_byte)에는 기존 HEVC NAL unit 또는 AVC NAL unit이 포함될 수 있다.
실시예들에 따른 forbidden_zero_bit은 0일 수 있다.
실시예들에 따른 타입은 PCC group of frames의 시작 NAL unit을 나타낼 수있다. VPS, SPS, PPS 등의 parameter set과 IDR, CRA, BLA 등 IRAP picture의 slice data를 포함할 수 있다.
실시예들에 따른 타입은 VPS, SPS, PPS 등 parameter set을 포함할 수 있다.
실시예들에 따른 타입은 PCC access unit delimiter로 PCC AU의 끝을 나타내며 pcc_access_unit_delimiter_rbsp()를 포함할 수 있다.
실시예들에 따른 타입은 PCC group of frames delimiter로 PCC AU의 끝을 나타내며 pcc_group_of_frames_delimiter_rbsp()를 포함할 수 있다.
실시예들에 따른 타입은 PCC sequence의 끝을 나타내며 pcc_end_of_seq_rbsp()를 포함할 수 있다. PCC sequence는 하나의 PCC component의 coded bitstream을 의미할 수 있다.
실시예들에 따른 타입은 PCC bitstream의 끝을 나타내며 pcc_end_of_bitstream_rbsp()를 포함할 수 있다. PCC bitstream은 전체 PCC componen들의 coded bitstream을 의미할 수 있다.
실시예들에 따른 pcc_nal_unit_type_plus1 은 이 값이 1을 마이너스 한 값이 PccNalUnitType 변수의 값을 나타낸다. 실시예들에 따른 PccNalUnitType 변수는 PCC NAL unit에 포함된 RBSP data의 구조의 타입을 나타낸다.
도62는 실시예들에 따른 PCC 관련 구문의 예시를 나타낸다.
실시예들에 따라, 앞서 언급한 pcc_access_unit_delimiter_rbsp(), pcc_group_of_frames_delimiter_rbsp(), pcc_end_of_seq_rbsp(), pcc_end_of_bitstream_rbsp()의 구문및 의미는 다음과 같을 수 있다.
실시예들에 따른 pcc_geometry_d0_flag : 1로 설정될 경우 현재 PCC access unit delimiter에 의해 구분되는 PCC access unit에 PCC geometry d0 image가 포함됨을 의미할 수 있다. 0일 경우 PCC geometry d0 image를 포함하지 않음을 의미할 수 있다.
실시예들에 따른 pcc_geometry_d1_flag : 1로 설정될 경우 현재 PCC access unit delimiter에 의해 구분되는 PCC access unit에 PCC geometry d1 image가 포함됨을 의미할 수 있다. 0일 경우 PCC geometry d1 image를 포함하지 않음을 의미할 수 있다.
실시예들에 따른 pcc_texture_flag : 1로 설정될 경우 현재 PCC access unit delimiter에 의해 구분되는 PCC access unit에 PCC texture image가 포함됨을 의미할 수 있다. 0일 경우 PCC texture image 를 포함하지 않음을 의미할 수 있다.
실시예들에 따른 pcc_auxiliary_patch_info_flag : 1로 설정될 경우 현재 PCC access unit delimiter에 의해 구분되는 PCC access unit에 PCC auxiliary patch information이 포함됨을 의미할 수 있다. 0일 경우 PCC auxiliary patch information을 포함하지 않음을 의미할 수 있다.
실시예들에 따른 pcc_occupancy_map_flag : 1로 설정될 경우 현재 PCC access unit delimiter에 의해 구분되는 PCC access unit에 PCC occupancy map이 포함됨을 의미할 수 있다. 0일 경우 PCC occupancy map을 포함하지 않음을 의미할 수 있다.
이러한 필드들에 의해 수신기는 현재 AU에 PCC component들이 존재하는지 여부를 알 수 있고, 존재하지 않을 경우 이전 AU들에서 해당 component들을 가져와 point cloud를 재구성하는데 사용할 수 있다.
도63은 실시예들에 따른 PCC data interleaving 정보를 나타낸다.
실시예들에 따른 PCC data interleaving 방법 관련하여, PCC data들의 interleaving 방법을 기술하기 위해 다음의 pcc_data_interleaving_info()와 같은 구문을 정의할 수 있다. 각 필드의 의미는 아래와 같을 수 있다.
실시예들에 따른 num_of_data_set : 하나의 PCC GOF (또는 bitstream)에 포함된 PCC component의 data들 중 interleaving boundary가 동일한 set의 개수를 의미할 수 있다. 일례로 모든 data들의 interleaving boundary가 동일할 경우 1로 설정될 수 있다.
실시예들에 따른 interleaving_boundary[i] : i번째 data set의 interleaving boundary를 나타낼 수 있다. 일례로 0일 경우 GOF 내에서, 1일 경우 AU 내에서 data들이 interleaving 되어 있음을 나타낼 수 있다.
실시예들에 따른 num_of_data[i] : i번째 data set을 구성하는 PCC data들의 개수를 의미할 수 있다.
실시예들에 따른 pcc_data_type[i][j] : i번째 data set의 j번째 data에 해당하는 PCC component의 data type을 나타낼 수 있다. 일례로 0일 경우 occupancy map, 1일 경우 auxiliary patch information, 2일 경우 geometry image D1, 3일 경우 geometry image D0, 4일 경우 texture image가 sample auxiliary information임을 나타낼 수 있다.
실시예들에 따른 base_decoding_delay_flag[i][j]: i번째 data set의 j번째 data가 decoding delay의 기준값으로 설정됨을 나타낼 수 있다.
실시예들에 따른 decoding delay는 hierarchical B picture 등 GOP 코딩에 있어서의 참조 구조에 의해 나타날 수 있는, 입력과 출력 사이의 시간 차이을 의미할 수 있다. hierarchy level -1 [frames]로 정의될 수 있다. 일례로 hierarchy level이 1인 “…”구조의 decoding delay 는 0이며, hierarchy level이 2인 “…”구조의 decoding delay 는 0이며, 1 [frame] 이다.
실시예들에 따른 decoding_delay_delta[i][j]: i번째 data set의 j번째 data의 decoding delay와 가 decoding delay의 기준값과의 차이를 나타낼 수 있다.
실시예들에 따른 pcc_data_interleaving_info()는 다양한 방법으로 PCC bitstream에 포함될 수 있다. 일례로, VPS 또는 PCC extension에 포함되거나, 새로운 SEI message로 정의될 수 있다. 또는 앞서 설명한 PCC GOF header에 포함되어 전달될 수도 있다.
수신기는 본 정보를 바탕으로 PCC data를 동기화 하기위한 버퍼링 방법을 결정할 수있다. 일례로 모든 component들이 AU boundary에서 interleaving되고 decoding delay의 차이가 없다면, 최소 하나의 PCC AU에 해당하는 데이터의 버퍼링 만으로 component들을 동기화 할 수 있다.
실시예들에 따라 PCC data의 multiplexing 할 때, 4가지 PCC data들이 interleaving되는 단위 (GOF or AU)와 이에 따른 수신기에서의 버퍼링 방법을 제안한다. 특히 PCC data가AU 단위로 interleaving되어 있고 video component들의 GOP 참조 구조가 다를 경우, 하나의 AU만을 버퍼링한 (e.g. decoding 완료한) 시점에 재생 (display)을 시작할 수 없다. (예를들어 geometry는 첫번째 프레임이 디코더에서 출력 되었지만, texture의 첫번째 프레임은 디코더에서 출력되지 않은 상태일 수 있다). 이러한 경우에 decoding_delay_delta를 통해 decoding delay의 차이 값을 프레임 수로 식별하여 최소 decoding_delay_delta 만큼의 PCC AU가 버퍼링 되었을 경우 재생을 시작하게 할 수 있는 효과를 실시예들이 제공한다.
도64는 실시예들에 따른 포인트 클라우드 데이터 전송 방법을 나타낸다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법은 포인트 클라우드 데이터의 위치에 관련된 지오메트리 이미지를 생성하는 단계(S6400); 포인트 클라우드의 속성에 관련된 텍스쳐 이미지를 생성하는 단계(S6401); 포인트 클라우드의 패치에 관련된 어큐판시 맵을 생성하는 단계(S6402); 포인트 클라우드의 패치에 관련된 어실러리 패치 정보를 생성하는 단계(S6403); 및/또는 지오메트리 이미지, 텍스쳐 이미지, 어큐판시 맵 및 어실러리 패치 정보를 멀티플렉싱하는 단계(S6404); 를 포함한다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법은 도45에서 설명한 실시예들에 따른 포인트 클라우드 데이터 송신 장치 및/또는 포인트 클라우드 송신 장치의 각 구성요소에 의해서 수행될 수 있다.
방법S6400 관련하여, 포인트 클라우드 데이터에 관한 지오메트리 이미지를 생성하는 과정이다. 도45에서 설명한 바와 같이 포인트 클라우드 프레임, 패치 및 관련된 메타데이터 등에 기반하여 지오메트리 이미지를 생성한다.
방법S6401 관련하여, 포인트 클라우드 데이터에 관한 텍스쳐 이미지를 생성하는 과정이다. 도45에서 설명한 바와 같이 포인트 클라우드 프레임, 패치 및 관련된 메타데이터 등에 기반하여 텍스쳐 이미지를 생성한다.
방법S6402 관련하여, 생성된 패치를 실시예들에 따른 디코더가 복원하기 위해서 필요한 메타데이터를 생성하는 과정이다.
방법S6403 관련하여, 생성된 패치를 실시예들에 따른 디코더가 복원하기 위해서 필요한 메타데이터를 생성하는 과정이다. 패치뿐만 아니라 부가적인 패치 정보도 포인트 클라우드 데이터를 효율적으로 디코딩하기 위해서 필요하다.
실시예들에 따른 메타데이터의 정의 및 이용방법은 포인트 클라우드의 송수신, 인코딩 및/또는 디코딩 성능을 향상시키는 효과가 있다.
방법S6404 관련하여, 상술한 데이터를 전송하기 위해서 인캡슐레이션 및/또는 멀티플렉싱하는 과정이다. 실시예들에 따른 멀티플렉싱 방법은 포인트 클라우드의 송수신, 인코딩 및/또는 디코딩 성능을 향상시키는 효과가 있다.
실시예들에 따른 포인트 클라우드 데이터 송신 방법은 상술한 실시예들에 따른 추가적인 실시예들의 엘리먼트들, 동작들 및/또는 메타데이터들과 결합될 수 있다.
도65는 실시예들에 따른 포인트 클라우드 데이터 수신 방법을 나타낸다.
실시예들에 따른 포인트 클라우드 데이터 수신 방법은 포인트 클라우드 데이터의 위치에 관련된 지오메트리 이미지, 포인트 클라우드의 속성에 관련된 텍스쳐 이미지, 포인트 클라우드의 패치에 관련된 어큐판시 맵 및 포인트 클라우드의 패치에 관련된 어실러리 패치 정보를 디멀티플렉싱하는 단계(S6500); 지오메트리 이미지를 디컴프레션하는 단계(S6501); 텍스쳐 이미지를 디컴프레션하는 단계(S6502); 어큐판시 맵을 디컴프레션하는 단계(S6503); 및/또는 어실러리 패치 정보를 디컴프레션하는 단계(S6504);를 포함할 수 있다.
실시예들에 따른 포인트 클라우드 데이터 수신 방법은 상술한 실시예들에 따른 추가적인 실시예들의 엘리먼트들, 동작들 및/또는 메타데이터들과 결합될 수 있다.
전술한 각각의 파트, 모듈 또는 유닛은 메모리(또는 저장 유닛)에 저장된 연속된 수행과정들을 실행하는 소프트웨어, 프로세서, 하드웨어 파트일 수 있다. 전술한 실시예에 기술된 각 단계들은 프로세서, 소프트웨어, 하드웨어 파트들에 의해 수행될 수 있다. 전술한 실시예에 기술된 각 모듈/블락/유닛들은 프로세서, 소프트웨어, 하드웨어로서 동작할 수 있다. 또한, 실시예들이 제시하는 방법들은 코드로서 실행될 수 있다. 이 코드는 프로세서가 읽을 수 있는 저장매체에 쓰여질 수 있고, 따라서 장치(apparatus)가 제공하는 프로세서에 의해 읽혀질 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 통상의 기술자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 실시예들의 권리범위에 속한다.
실시예들에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상술한 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 실시예들이 제안하는 방법을 네트워크 디바이스에 구비된, 프로세서가 읽을 수 있는 기록매체에, 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 실시예들의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 실시예들은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 실시예들의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 실시예들의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
실시예들의 사상이나 범위를 벗어나지 않고 실시예들에서 다양한 변경 및 변형이 가능함은 당업자에게 이해된다. 따라서, 실시예들은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 실시예들의 변경 및 변형을 포함하는 것으로 의도된다.
본 명세서에서 장치 및 방법 발명이 모두 언급되고, 장치 및 방법 발명 모두의 설명은 서로 보완하여 적용될 수 있다.
이 문서에서 /와 ,는 및/또는으로 해석된다. 예를 들어, A/B는 A 및/또는 B로 해석되고, A, B는 A 및/또는 B로 해석된다. 추가적으로, A/B/C는 A, B 및/또는 C 중 적어도 하나를 의미한다. 또한, A, B, C도 A, B 및/또는 C 중 적어도 하나를 의미한다. (In this document, the term / and , should be interpreted to indicate and/or. For instance, the expression A/B may mean A and/or B. Further, A, B may mean A and/or B. Further, A/B/C may mean at least one of A, B, and/or C. Also, A/B/C may mean at least one of A, B, and/or C.)
추가적으로, 이 문서에서 또는는 및/또는으로 해석된다. 예를 들어, A 또는 B은, 1) A 만을 의미하고, 2) B만을 의미하거나, 3) A 및 B를 의미할 수 있다. 달리 표현하면, 본 문서의 또는은 추가적으로 또는 대체적으로(additionally or alternatively)를 의미할 수 있다. (Further, in the document, the term or should be interpreted to indicate and/or. For instance, the expression A or B may comprise 1) only A, 2) only B, and/or 3) both A and B. In other words, the term or in this document should be interpreted to indicate additionally or alternatively.)
포인트 클라우드 데이터 송수신 장치의 다양한 엘리먼트는 하드웨어, 소프트웨어, 펌웨어 또는 그것들의 결합에 의해 수행될 수 있다. 실시예들에 다양한 엘리먼트들은 하드웨어 회로와 같이 싱글 칩에 의해 수행될 수 있다. 실시예들에 따라, 선택적으로 개별적 칩에 의해 다양한 엘리먼트들이 수행될 수 있다. 실시예들에 따라, 실시예들에 따른 동작을 수행하는 하나 또는 하나 이상의 프로그램들을 실행할 수 있는 하나 또는 하나 이상의 프로세서들에 의해 엘리먼트들이 수행될 수 있다.
실시예들에 따른 용어 해석과 관련하여, 제1, 제2등의 표현은 다양한 엘리먼트들을 설명하기 위해 사용될 수 있다. 이러한 용어들에 의해 실시예들의 엘리먼트들이 해석이 제한되지 않는다. 이러한 용어는 엘리먼트들 간 구별하기 위해 사용될 수 있다.
실시예들의 설명과 관련하여 사용된 용어는 실시예들을 설명하기 위해 사용되었으며, 실시예들을 제한하지 않는다. 단수 및 복수 표현과 관련하여, 단수는 복수로도 해석될 수도록 의도되었고, 및/또는 표현 역시 가능한 모든 결합을 포함하도록 의도되었다. 포함한다는 표현과 관련하여, 포함이라는 의미는 포함된 엘리먼트 외에도 다양한 특징, 숫자, 방법 단계, 동작, 엘리먼트들을 추가로 포함/결합할 수 있도록 의도되었다.
조건 표현과 관련하여, ~인 경우, ~때 등의 조건 표현은 선택적인 경우로만 제한 해석되지 않고, 특정 조건을 만족하는 때, 특정 조건에 대응하여 관련 동작을 수행하거나, 관련 정의가 해석되도록 의도되었다.
상술한 바와 같이, 실시예들을 실시하기 위한 최선의 형태에서 관련 내용을 설명하였다.
상술한 바와 같이, 실시예들은 포인트 클라우드 데이터 송수신 장치 및 시스템에 전체적 또는 부분적으로 적용될 수 있다.
당업자는 실시예들의 범위 내에서 실시예들을 다양하게 변경 또는 변형할 수 있다.
실시예들은 변경/변형들을 포함할 수 있고, 변경/변형은 청구항들 및 그 와 동일한 것들의 범위를 벗어나지 않는다.

Claims (20)

  1. 포인트 클라우드 데이터의 위치에 관련된 지오메트리 이미지를 생성하는 단계;
    상기 포인트 클라우드 데이터의 속성에 관련된 텍스쳐 이미지를 생성하는 단계;
    상기 포인트 클라우드 데이터의 패치에 관련된 어큐판시 맵을 생성하는 단계;
    상기 지오메트리 이미지, 상기 텍스쳐 이미지 및 상기 어큐판시 맵을 멀티플렉싱하는 단계; 를 포함하는
    포인트 클라우드 데이터 송신 방법.
  2. 제1항에 있어서,
    상기 멀티플렉싱은 상기 지오메트리 이미지, 상기 텍스쳐 이미지 및 상기 어큐판시 맵을 파일로 멀티플렉싱하는,
    포인트 클라우드 데이터 송신 방법.
  3. 제 2항에 있어서,
    상기 파일은 멀티플 트랙들을 포함하는,
    포인트 클라우드 데이터 송신 방법.
  4. 제3항에 있어서,
    상기 멀티플 트랙들은 상기 지오메트리 이미지를 포함하는 제1트랙, 상기 텍스쳐 이미지를 포함하는 제2트랙, 상기 어큐판시 맵을 포함하는 제3트랙을 포함하는,
    포인트 클라우드 데이터 송신 방법.
  5. 제4항에 있어서,
    상기 파일은 그룹 박스를 포함하고,
    상기 그룹 박스는 상기 제1트랙, 상기 제2트랙 또는 상기 제3트랙 중 적어도 하나를 나타내는 정보를 포함하는,
    포인트 클라우드 데이터 송신 방법.
  6. 포인트 클라우드 데이터의 위치에 관련된 지오메트리 이미지를 생성하는 제너레이터;
    상기 포인트 클라우드 데이터의 속성에 관련된 텍스쳐 이미지를 생성하는 제너레이터;
    상기 포인트 클라우드 데이터의 패치에 관련된 어큐판시 맵을 생성하는 제너레이터;
    상기 지오메트리 이미지, 상기 텍스쳐 이미지, 상기 어큐판시 맵을 멀티플렉싱하는 멀티플렉서; 를 포함하는,
    포인트 클라우드 데이터 송신 장치.
  7. 제6항에 있어서,
    상기 멀티플렉서는 상기 지오메트리 이미지, 상기 텍스쳐 이미지, 상기 어큐판시 맵을 파일로 멀티플렉싱하는,
    포인트 클라우드 데이터 송신 장치.
  8. 제 7항에 있어서,
    상기 파일은 멀티플 트랙들을 포함하는,
    포인트 클라우드 데이터 송신 장치.
  9. 제8항에 있어서,
    상기 멀티플 트랙들은 상기 지오메트리 이미지를 포함하는 제1트랙, 상기 텍스쳐 이미지를 포함하는 제2트랙, 상기 어큐판시 맵을 포함하는 제3트랙을 포함하는,
    포인트 클라우드 데이터 송신 장치.
  10. 제9항에 있어서,
    상기 파일은 그룹 박스를 포함하고,
    상기 그룹 박스는 상기 제1트랙, 상기 제2트랙 또는 상기 제3트랙 중 적어도 하나를 나타내는 정보를 포함하는,
    포인트 클라우드 데이터 송신 장치.
  11. 포인트 클라우드 데이터의 위치에 관련된 지오메트리 이미지, 상기 포인트 클라우드 데이터의 속성에 관련된 텍스쳐 이미지, 상기 포인트 클라우드 데이터의 패치에 관련된 어큐판시 맵을 디멀티플렉싱하는 단계;
    상기 지오메트리 이미지를 디컴프레션하는 단계;
    상기 텍스쳐 이미지를 디컴프레션하는 단계;
    상기 어큐판시 맵을 디컴프레션하는 단계; 를 포함하는,
    포인트 클라우드 데이터 수신 방법.
  12. 제11항에 있어서,
    상기 디멀티플렉싱은 상기 지오메트리 이미지, 상기 텍스쳐 이미지, 상기 어큐판시 맵을 파일로 디멀티플렉싱하는,
    포인트 클라우드 데이터 수신 방법.
  13. 제 11항에 있어서,
    상기 파일은 멀티플 트랙들을 포함하는,
    포인트 클라우드 데이터 수신 방법.
  14. 제13항에 있어서,
    상기 멀티플 트랙들은 상기 지오메트리 이미지를 포함하는 제1트랙, 상기 텍스쳐 이미지를 포함하는 제2트랙, 상기 어큐판시 맵을 포함하는 제3트랙을 포함하는,
    포인트 클라우드 데이터 수신 방법.
  15. 제14항에 있어서,
    상기 파일은 그룹 박스를 포함하고,
    상기 그룹 박스는 상기 제1트랙, 상기 제2트랙 또는 상기 제3트랙 중 적어도 하나를 나타내는 정보를 포함하는,
    포인트 클라우드 데이터 수신 방법.
  16. 포인트 클라우드 데이터의 위치에 관련된 지오메트리 이미지, 상기 포인트 클라우드 데이터의 속성에 관련된 텍스쳐 이미지, 상기 포인트 클라우드 데이터의 패치에 관련된 어큐판시 맵을 디멀티플렉싱하는 디멀티플렉서;
    상기 지오메트리 이미지를 디컴프레션하는 디컴프레서;
    상기 텍스쳐 이미지를 디컴프레션하는 디컴프레서;
    상기 어큐판시 맵을 디컴프레션하는 디컴프레서; 를 포함하는,
    포인트 클라우드 데이터 수신 장치.
  17. 제16항에 있어서,
    상기 디멀티플렉서는 상기 지오메트리 이미지, 상기 텍스쳐 이미지, 상기 어큐판시 맵을 파일로 디멀티플렉싱하는,
    포인트 클라우드 데이터 수신 장치.
  18. 제 16항에 있어서,
    상기 파일은 멀티플 트랙들을 포함하는,
    포인트 클라우드 데이터 수신 장치.
  19. 제18항에 있어서,
    상기 멀티플 트랙들은 상기 지오메트리 이미지를 포함하는 제1트랙, 상기 텍스쳐 이미지를 포함하는 제2트랙, 상기 어큐판시 맵을 포함하는 제3트랙을 포함하는,
    포인트 클라우드 데이터 수신 장치.
  20. 제19항에 있어서,
    상기 파일은 그룹 박스를 포함하고,
    상기 그룹 박스는 상기 제1트랙, 상기 제2트랙 또는 상기 제3트랙 중 적어도 하나를 나타내는 정보를 포함하는,
    포인트 클라우드 데이터 수신 장치.
PCT/KR2019/012719 2018-10-01 2019-09-30 포인트 클라우드 데이터 전송 장치, 포인트 클라우드 데이터 전송 방법, 포인트 클라우드 데이터 수신 장치 및/또는 포인트 클라우드 데이터 수신 방법 WO2020071703A1 (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201862739838P 2018-10-01 2018-10-01
US62/739,838 2018-10-01
KR20180118326 2018-10-04
KR10-2018-0118326 2018-10-04

Publications (1)

Publication Number Publication Date
WO2020071703A1 true WO2020071703A1 (ko) 2020-04-09

Family

ID=70055962

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/012719 WO2020071703A1 (ko) 2018-10-01 2019-09-30 포인트 클라우드 데이터 전송 장치, 포인트 클라우드 데이터 전송 방법, 포인트 클라우드 데이터 수신 장치 및/또는 포인트 클라우드 데이터 수신 방법

Country Status (2)

Country Link
US (1) US20200153885A1 (ko)
WO (1) WO2020071703A1 (ko)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021210837A1 (ko) * 2020-04-13 2021-10-21 엘지전자 주식회사 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2022019713A1 (ko) * 2020-07-23 2022-01-27 엘지전자 주식회사 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2022125241A1 (en) * 2020-12-08 2022-06-16 Argo AI, LLC Methods and system for analyzing dynamic lidar point cloud data
TWI793602B (zh) * 2020-05-13 2023-02-21 新加坡商聯發科技（新加坡）私人有限公司 用以傳訊沉浸式媒體中多種類型視域的方法和裝置

Families Citing this family (80)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102598082B1 (ko) * 2016-10-28 2023-11-03 삼성전자주식회사 영상 표시 장치, 모바일 장치 및 그 동작방법
EP3557866A4 (en) * 2016-12-16 2019-12-04 Samsung Electronics Co., Ltd. METHOD FOR TRANSMITTING DATA RELATED TO A THREE-DIMENSIONAL IMAGE
US11259046B2 (en) 2017-02-15 2022-02-22 Apple Inc. Processing of equirectangular object data to compensate for distortion by spherical projections
US11093752B2 (en) 2017-06-02 2021-08-17 Apple Inc. Object tracking in multi-view video
US10897269B2 (en) 2017-09-14 2021-01-19 Apple Inc. Hierarchical point cloud compression
US10861196B2 (en) 2017-09-14 2020-12-08 Apple Inc. Point cloud compression
US11818401B2 (en) 2017-09-14 2023-11-14 Apple Inc. Point cloud geometry compression using octrees and binary arithmetic encoding with adaptive look-up tables
US10805646B2 (en) 2018-06-22 2020-10-13 Apple Inc. Point cloud geometry compression using octrees and binary arithmetic encoding with adaptive look-up tables
US10909725B2 (en) 2017-09-18 2021-02-02 Apple Inc. Point cloud compression
US11113845B2 (en) 2017-09-18 2021-09-07 Apple Inc. Point cloud compression using non-cubic projections and masks
US10607373B2 (en) 2017-11-22 2020-03-31 Apple Inc. Point cloud compression with closed-loop color conversion
US10699444B2 (en) 2017-11-22 2020-06-30 Apple Inc Point cloud occupancy map compression
US10939129B2 (en) * 2018-04-10 2021-03-02 Apple Inc. Point cloud compression
US10909727B2 (en) 2018-04-10 2021-02-02 Apple Inc. Hierarchical point cloud compression with smoothing
US10909726B2 (en) 2018-04-10 2021-02-02 Apple Inc. Point cloud compression
US11010928B2 (en) 2018-04-10 2021-05-18 Apple Inc. Adaptive distance based point cloud compression
US11756234B2 (en) 2018-04-11 2023-09-12 Interdigital Vc Holdings, Inc. Method for encoding depth values of a set of 3D points once orthogonally projected into at least one image region of a projection plane
US10984541B2 (en) * 2018-04-12 2021-04-20 Samsung Electronics Co., Ltd. 3D point cloud compression systems for delivery and access of a subset of a compressed 3D point cloud
US11044478B2 (en) 2018-07-02 2021-06-22 Apple Inc. Compression with multi-level encoding
US11017566B1 (en) 2018-07-02 2021-05-25 Apple Inc. Point cloud compression with adaptive filtering
US11202098B2 (en) 2018-07-05 2021-12-14 Apple Inc. Point cloud compression with multi-resolution video encoding
US10911787B2 (en) 2018-07-10 2021-02-02 Apple Inc. Hierarchical point cloud compression
EP3595179B1 (en) * 2018-07-10 2023-07-05 BlackBerry Limited Methods and devices for lossy coding of point cloud occupancy
US11012713B2 (en) 2018-07-12 2021-05-18 Apple Inc. Bit stream structure for compressed point cloud data
CN110719497B (zh) * 2018-07-12 2021-06-22 华为技术有限公司 点云编解码方法和编解码器
JP7100523B2 (ja) * 2018-07-27 2022-07-13 京セラ株式会社 表示装置、表示システムおよび移動体
CN112930557A (zh) * 2018-09-26 2021-06-08 相干逻辑公司 任何世界视图生成
US11132818B2 (en) 2018-09-28 2021-09-28 Apple Inc. Predicting attributes for point cloud compression according to a space filling curve
US11386524B2 (en) 2018-09-28 2022-07-12 Apple Inc. Point cloud compression image padding
US11122279B2 (en) * 2018-10-02 2021-09-14 Samsung Electronics Co., Ltd. Point cloud compression using continuous surface codes
US11367224B2 (en) 2018-10-02 2022-06-21 Apple Inc. Occupancy map block-to-patch information compression
US10853973B2 (en) 2018-10-03 2020-12-01 Apple Inc. Point cloud compression using fixed-point numbers
US11109012B2 (en) * 2018-10-03 2021-08-31 Samsung Electronics Co., Ltd. Carriage of PCC in ISOBMFF for flexible combination
US11430155B2 (en) 2018-10-05 2022-08-30 Apple Inc. Quantized depths for projection point cloud compression
CN111327902B (zh) * 2018-12-13 2022-11-22 华为技术有限公司 点云的编解码方法及装置
US11995854B2 (en) * 2018-12-19 2024-05-28 Nvidia Corporation Mesh reconstruction using data-driven priors
JPWO2020137642A1 (ja) * 2018-12-28 2021-11-11 ソニーグループ株式会社 情報処理装置および情報処理方法
US11454710B2 (en) 2019-01-08 2022-09-27 Apple Inc. Point cloud compression using a space filling curve for level of detail generation
US11348284B2 (en) 2019-01-08 2022-05-31 Apple Inc. Auxiliary information signaling and reference management for projection-based point cloud compression
EP3734970B1 (en) * 2019-01-08 2023-07-05 Samsung Electronics Co., Ltd. Method for processing and transmitting three-dimensional content
US11284091B2 (en) 2019-03-25 2022-03-22 Apple Inc. Video based point cloud compression-patch alignment and size determination in bounding box
US11956478B2 (en) * 2019-01-09 2024-04-09 Tencent America LLC Method and apparatus for point cloud chunking for improved patch packing and coding efficiency
EP3703013A1 (en) * 2019-03-01 2020-09-02 Koninklijke Philips N.V. Apparatus and method of generating an image signal
US11457231B2 (en) * 2019-03-15 2022-09-27 Mediatek Singapore Pte. Ltd. Methods and apparatus for signaling spatial relationships for point cloud multimedia data tracks
US11107249B2 (en) * 2019-03-18 2021-08-31 Sony Group Corporation Point cloud global tetris packing
US11245926B2 (en) * 2019-03-19 2022-02-08 Mediatek Singapore Pte. Ltd. Methods and apparatus for track derivation for immersive media data tracks
EP3713238A1 (en) * 2019-03-20 2020-09-23 InterDigital VC Holdings, Inc. Processing a point cloud
US11057564B2 (en) 2019-03-28 2021-07-06 Apple Inc. Multiple layer flexure for supporting a moving image sensor
IL267211A (en) 2019-06-10 2019-08-29 Elbit Systems Ltd System and method for video display
US11218715B2 (en) * 2019-06-14 2022-01-04 Mediatek Singapore Pte. Ltd. Methods and apparatus for spatial grouping and coordinate signaling for immersive media data tracks
US11711544B2 (en) * 2019-07-02 2023-07-25 Apple Inc. Point cloud compression with supplemental information messages
US11122102B2 (en) * 2019-07-03 2021-09-14 Lg Electronics Inc. Point cloud data transmission apparatus, point cloud data transmission method, point cloud data reception apparatus and point cloud data reception method
CN112333453A (zh) 2019-08-05 2021-02-05 腾讯美国有限责任公司 解码方法和装置以及计算机系统和存储介质
US11158116B2 (en) * 2019-08-05 2021-10-26 Tencent America LLC Geometry model for point cloud coding
US11627314B2 (en) 2019-09-27 2023-04-11 Apple Inc. Video-based point cloud compression with non-normative smoothing
KR20220065861A (ko) * 2019-09-27 2022-05-20 브이아이디 스케일, 인크. 비디오 기반 포인트 클라우드 스트림들
US11202078B2 (en) 2019-09-27 2021-12-14 Apple Inc. Dynamic point cloud compression using inter-prediction
US11562507B2 (en) 2019-09-27 2023-01-24 Apple Inc. Point cloud compression using video encoding with time consistent patches
US11409998B2 (en) 2019-10-02 2022-08-09 Apple Inc. Trimming search space for nearest neighbor determinations in point cloud compression
US11538196B2 (en) 2019-10-02 2022-12-27 Apple Inc. Predictive coding for point cloud compression
US11895307B2 (en) 2019-10-04 2024-02-06 Apple Inc. Block-based predictive coding for point cloud compression
CN110933364A (zh) * 2019-10-25 2020-03-27 深圳市道通智能航空技术有限公司 全向视觉避障实现方法、系统、装置及存储介质
US11798196B2 (en) 2020-01-08 2023-10-24 Apple Inc. Video-based point cloud compression with predicted patches
US11625866B2 (en) 2020-01-09 2023-04-11 Apple Inc. Geometry encoding using octrees and predictive trees
WO2021141233A1 (ko) * 2020-01-10 2021-07-15 엘지전자 주식회사 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
US11206294B2 (en) * 2020-03-31 2021-12-21 Konica Minolta Business Solutions U.S.A., Inc. Method for separating local and remote content in a camera-projector based collaborative system
CN115428467B (zh) * 2020-04-14 2024-03-08 Lg电子株式会社 点云数据发送设备和方法、点云数据接收设备和方法
US11615557B2 (en) 2020-06-24 2023-03-28 Apple Inc. Point cloud compression using octrees with slicing
US11620768B2 (en) 2020-06-24 2023-04-04 Apple Inc. Point cloud geometry compression using octrees with multiple scan orders
KR20220010907A (ko) * 2020-07-20 2022-01-27 삼성전자주식회사 3d(ar) 미디어 랜덤 액세스를 위한 방법 및 장치
WO2022032161A1 (en) * 2020-08-07 2022-02-10 Vid Scale, Inc. Tile tracks for geometry‑based point cloud data
US20230316584A1 (en) * 2020-08-12 2023-10-05 Lg Electronics Inc. Point cloud data transmission device, point cloud data transmission method, point cloud data reception device, and point cloud data reception method
WO2022035256A1 (ko) * 2020-08-12 2022-02-17 엘지전자 주식회사 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
US11941856B2 (en) * 2020-08-18 2024-03-26 Tencent America LLC Predictive tree-based geometry coding for a point cloud
EP3979644A1 (en) * 2020-10-02 2022-04-06 Koninklijke Philips N.V. A method and apparatus for encoding and decoding one or more views of a scene
US11948338B1 (en) 2021-03-29 2024-04-02 Apple Inc. 3D volumetric content encoding using 2D videos and simplified 3D meshes
US11683523B2 (en) 2021-07-07 2023-06-20 Tencent America LLC Group of pictures based patch packing for video based point cloud coding
EP4372314A1 (en) * 2021-07-13 2024-05-22 LG Electronics Inc. Route guiding device and route guiding system based on augmented reality and mixed reality
CN113673425B (zh) * 2021-08-19 2022-03-15 清华大学 一种基于Transformer的多视角目标检测方法及系统
CN115422387B (zh) * 2022-11-04 2023-02-24 山东矩阵软件工程股份有限公司 基于多维点云融合数据的点云数据处理方法及系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160086353A1 (en) * 2014-09-24 2016-03-24 University of Maribor Method and apparatus for near-lossless compression and decompression of 3d meshes and point clouds
CN108198145A (zh) * 2017-12-29 2018-06-22 百度在线网络技术（北京）有限公司 用于点云数据修复的方法和装置
JP2018105644A (ja) * 2016-12-22 2018-07-05 日立Ｇｅニュークリア・エナジー株式会社 点群処理装置、および、点群処理方法
CN108460791A (zh) * 2017-12-29 2018-08-28 百度在线网络技术（北京）有限公司 用于处理点云数据的方法和装置
US20180268570A1 (en) * 2017-03-16 2018-09-20 Samsung Electronics Co., Ltd. Point cloud and mesh compression using image/video codecs

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160086353A1 (en) * 2014-09-24 2016-03-24 University of Maribor Method and apparatus for near-lossless compression and decompression of 3d meshes and point clouds
JP2018105644A (ja) * 2016-12-22 2018-07-05 日立Ｇｅニュークリア・エナジー株式会社 点群処理装置、および、点群処理方法
US20180268570A1 (en) * 2017-03-16 2018-09-20 Samsung Electronics Co., Ltd. Point cloud and mesh compression using image/video codecs
CN108198145A (zh) * 2017-12-29 2018-06-22 百度在线网络技术（北京）有限公司 用于点云数据修复的方法和装置
CN108460791A (zh) * 2017-12-29 2018-08-28 百度在线网络技术（北京）有限公司 用于处理点云数据的方法和装置

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2021210837A1 (ko) * 2020-04-13 2021-10-21 엘지전자 주식회사 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
TWI793602B (zh) * 2020-05-13 2023-02-21 新加坡商聯發科技（新加坡）私人有限公司 用以傳訊沉浸式媒體中多種類型視域的方法和裝置
US11818326B2 (en) 2020-05-13 2023-11-14 Mediatek Singapore Pte. Ltd. Methods and apparatus for signaling viewing regions of various types in immersive media
WO2022019713A1 (ko) * 2020-07-23 2022-01-27 엘지전자 주식회사 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2022125241A1 (en) * 2020-12-08 2022-06-16 Argo AI, LLC Methods and system for analyzing dynamic lidar point cloud data

Also Published As

Publication number Publication date
US20200153885A1 (en) 2020-05-14

Similar Documents

Publication Publication Date Title
WO2020071703A1 (ko) 포인트 클라우드 데이터 전송 장치, 포인트 클라우드 데이터 전송 방법, 포인트 클라우드 데이터 수신 장치 및/또는 포인트 클라우드 데이터 수신 방법
WO2020190114A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2020189895A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021187737A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021002657A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2020190075A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021002633A2 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021002730A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021141208A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2020189903A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021141264A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2018174387A1 (ko) 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
WO2018182144A1 (ko) 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
WO2021071257A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021141233A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021206333A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2020091404A1 (ko) 비디오 송신 방법, 비디오 전송 장치, 비디오 수신 방법 및 비디오 수신 장치
WO2020242023A1 (ko) 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
WO2020050577A1 (ko) 비디오 송신 방법, 비디오 송신 장치, 비디오 수신 방법 및 비디오 수신 장치
WO2020242027A1 (ko) 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
WO2021210860A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021210763A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021141258A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021256909A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2021261865A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19869269

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19869269

Country of ref document: EP

Kind code of ref document: A1