WO2018182144A1 - 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치 - Google Patents

360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치 Download PDF

Info

Publication number
WO2018182144A1
WO2018182144A1 PCT/KR2018/000106 KR2018000106W WO2018182144A1 WO 2018182144 A1 WO2018182144 A1 WO 2018182144A1 KR 2018000106 W KR2018000106 W KR 2018000106W WO 2018182144 A1 WO2018182144 A1 WO 2018182144A1
Authority
WO
WIPO (PCT)
Prior art keywords
video
information
region
picture
video data
Prior art date
Application number
PCT/KR2018/000106
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 엘지전자 주식회사
Priority to KR1020197019426A priority Critical patent/KR102277267B1/ko
Priority to US16/485,142 priority patent/US20190373245A1/en
Publication of WO2018182144A1 publication Critical patent/WO2018182144A1/ko

Links

Images

Classifications

    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/156—Mixing image signals
    • 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/172—Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • 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/172—Processing image signals image signals comprising non-image signal components, e.g. headers or format information
    • H04N13/178—Metadata, e.g. disparity information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/20—Image signal generators
    • H04N13/282—Image signal generators for generating image signals corresponding to three or more geometrical viewpoints, e.g. multi-view systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N13/00—Stereoscopic video systems; Multi-view video systems; Details thereof
    • H04N13/30—Image reproducers
    • H04N13/363—Image reproducers using image projection screens
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234345—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements the reformatting operation being performed only on part of the stream, e.g. a region of the image or a time segment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams, manipulating MPEG-4 scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • 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/816—Monomedia components thereof involving special video data, e.g 3D video
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • 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/85—Assembly of content; Generation of multimedia applications
    • H04N21/854—Content authoring
    • H04N21/85406—Content authoring involving a specific file format, e.g. MP4 format

Definitions

  • the present invention relates to a method for transmitting 360 video, a method for receiving 360 video, a 360 video transmitting apparatus, and a 360 video receiving apparatus.
  • the VR (Vertial Reality) system gives the user the feeling of being in an electronically projected environment.
  • the system for providing VR can be further refined to provide higher quality images and spatial sound.
  • the VR system can enable a user to consume VR content interactively.
  • the VR system needs to be improved in order to provide the VR environment to the user more efficiently.
  • data transmission efficiency for transmitting a large amount of data such as VR content robustness between a transmission and reception network, network flexibility considering a mobile receiving device, and methods for efficient playback and signaling should be proposed.
  • the present invention proposes a method for transmitting 360 video, a method for receiving 360 video, a 360 video transmitting apparatus, and a 360 video receiving apparatus.
  • a method of transmitting 360 video includes stitching 360 video data captured by at least one camera; Projecting the stitched 360 video data onto a first picture; Performing region-wise packing by mapping regions of the first picture to a second picture; Processing the data of the second picture into Dynamic Adaptive Streaming over HTTP (DASH) representations; Generating a media presentation description (MPD) including signaling information for the 360 video data; And transmitting the DASH representations and the MPD; It may include.
  • DASH Dynamic Adaptive Streaming over HTTP
  • MPD media presentation description
  • said MPD comprises a first descriptor and a second descriptor, said first descriptor comprising information indicating a projection type used when said stitched 360 video data is projected onto said first picture.
  • the second descriptor may include information indicating a packing type used when region-wise packing is performed from the first picture to the second picture.
  • the information indicating the projection type indicates that the projection has an isquirectangular projection or a cubemap projection type
  • the information indicating the packing type indicates that the region-wise packing is a rectangle ( rectangular) may indicate having a region-wise packing type.
  • the MPD includes a third descriptor
  • the third descriptor includes coverage information indicating an area occupied in 3D space by an entire area corresponding to the 360 video data, and the coverage information is
  • the midpoint of the area on the 3D space may be specified using azimuth and elevation values, and the horizontal and vertical ranges of the area may be specified.
  • At least one of said DASH representations is a timed metadata representation comprising timed metadata, wherein said timed metadata is initial viewpoint information indicating an initial viewpoint;
  • the timed metadata may include information for identifying a DASH representation having 360 video data to which the initial viewpoint information is applied.
  • the timed metadata includes recommended viewport information indicating a viewport recommended by a service provider, and the timed metadata has 360 video data to which the recommended viewport information is applied. It may include information identifying the DASH representation.
  • the third descriptor further includes a frame packing arrangement information of 360 video corresponding to the region and a singular signaling field simultaneously indicating whether the 360 video is a stereoscopic 360 video. It may include.
  • a 360 video transmission device includes a video processor for stitching 360 video data captured by at least one camera, the processor projecting the stitched 360 video data onto a first picture, Performing region wise packing by mapping regions of the first picture to a second picture;
  • An encapsulation processor configured to process data of the second picture as DASH (Dynamic Adaptive Streaming over HTTP) representations;
  • a metadata processor configured to generate a media presentation description (MPD) including signaling information of the 360 video data;
  • MPD media presentation description
  • said MPD comprises a first descriptor and a second descriptor, said first descriptor comprising information indicating a projection type used when said stitched 360 video data is projected onto said first picture.
  • the second descriptor may include information indicating a packing type used when region-wise packing is performed from the first picture to the second picture.
  • the information indicating the projection type indicates that the projection has an isquirectangular projection or a cubemap projection type
  • the information indicating the packing type indicates that the region-wise packing is a rectangle ( rectangular) may indicate having a region-wise packing type.
  • the MPD includes a third descriptor
  • the third descriptor includes coverage information indicating an area occupied in 3D space by an entire area corresponding to the 360 video data, and the coverage information is
  • the midpoint of the area on the 3D space may be specified using azimuth and elevation values, and the horizontal and vertical ranges of the area may be specified.
  • At least one of said DASH representations is a timed metadata representation comprising timed metadata, wherein said timed metadata is initial viewpoint information indicating an initial viewpoint;
  • the timed metadata may include information for identifying a DASH representation having 360 video data to which the initial viewpoint information is applied.
  • the timed metadata includes recommended viewport information indicating a viewport recommended by a service provider, and the timed metadata has 360 video data to which the recommended viewport information is applied. It may include information identifying the DASH representation.
  • the third descriptor further includes a frame packing arrangement information of 360 video corresponding to the region and a singular signaling field simultaneously indicating whether the 360 video is a stereoscopic 360 video. It may include.
  • the present invention can efficiently transmit 360 content in an environment supporting next generation hybrid broadcasting using a terrestrial broadcasting network and an internet network.
  • the present invention can propose a method for providing an interactive experience in the user's 360 content consumption.
  • the present invention can propose a method of signaling to accurately reflect the intention of the 360 content producer in the 360 content consumption of the user.
  • the present invention can propose a method for efficiently increasing transmission capacity and delivering necessary information in 360 content delivery.
  • FIG. 1 is a diagram showing the overall architecture for providing 360 video according to the present invention.
  • FIG. 2 is a diagram illustrating a 360 video transmission apparatus according to an aspect of the present invention.
  • FIG. 3 is a diagram illustrating a 360 video receiving apparatus according to another aspect of the present invention.
  • FIG. 4 is a diagram illustrating a 360 video transmission device / 360 video receiving device according to another embodiment of the present invention.
  • FIG. 5 is a diagram illustrating the concept of an airplane main axis (Aircraft Principal Axes) for explaining the 3D space of the present invention.
  • FIG. 6 is a diagram illustrating projection schemes according to an embodiment of the present invention.
  • FIG. 7 is a diagram illustrating a tile according to an embodiment of the present invention.
  • FIG 8 illustrates 360 video related metadata according to an embodiment of the present invention.
  • FIG. 9 illustrates the structure of a media file according to an embodiment of the present invention.
  • FIG. 10 illustrates a hierarchical structure of boxes in an ISOBMFF according to an embodiment of the present invention.
  • FIG. 11 is a diagram illustrating the overall operation of the DASH-based adaptive streaming model according to an embodiment of the present invention.
  • FIG. 12 is a diagram exemplarily illustrating a configuration of a data encoder according to the present invention.
  • FIG. 13 is a diagram exemplarily illustrating a configuration of a data decoder according to the present invention.
  • FIG. 15 illustratively illustrates a motion constraint tile set (MCTS) extraction and delivery process as an example of region based independent processing.
  • MCTS motion constraint tile set
  • 16 illustrates an example of an image frame for region based independent processing support.
  • FIG. 17 shows an example of a bitstream configuration for region based independent processing support.
  • FIG. 21 illustrates a RegionToTrackBox according to an embodiment of the present invention.
  • FIG. 24 illustrates MCTS region related information in a file including a plurality of MCTS bitstreams according to an embodiment of the present invention.
  • FIG. 25 illustrates viewport based processing according to an embodiment of the present invention.
  • 26 shows coverage information according to an embodiment of the present invention.
  • FIG. 27 illustrates a subpicture configuration according to an embodiment of the present invention.
  • 30 shows a hierarchical structure of RegionWisePackingBox.
  • FIG. 31 schematically illustrates a process of transmitting and receiving 360-degree video using a subpicture configuration according to the present invention.
  • 35 illustrates a 360 video transmission apparatus according to an aspect of the present invention.
  • FIG. 36 illustrates a 360 video receiving apparatus according to another aspect of the present invention.
  • 41 is a view showing another embodiment of coverage information according to the present invention.
  • FIG 43 is a view showing a 360 video transmission apparatus according to an aspect of the present invention.
  • 44 is a diagram illustrating a 360 video receiving apparatus according to another aspect of the present invention.
  • FIG. 47 is a diagram illustrating an example of using initial viewpoint information and / or recommended viewpoint / viewport information according to the present invention.
  • FIG. 48 is a diagram illustrating another application example of initial viewpoint information and / or recommended viewpoint / viewport information according to the present invention.
  • FIG. 49 illustrates another example of use of initial viewpoint information and / or recommended viewpoint / viewport information according to the present invention.
  • 50 is a view for explaining gap analysis in stereoscopic 360 video data signaling according to the present invention.
  • FIG. 51 illustrates another embodiment of a track coverage information box according to the present invention.
  • FIG. 52 illustrates another embodiment of a content coverage descriptor according to the present invention.
  • 53 is a diagram illustrating an embodiment of a subpicture composition box according to the present invention.
  • FIG. 54 is a diagram illustrating an embodiment of a signaling process when fisheye 360 video data is rendered on a sphere according to the present invention.
  • 55 is a diagram illustrating an embodiment of signaling information in which a new shape_type is defined according to the present invention.
  • FIG. 58 illustrates another embodiment of SphereRegionStruct for fisheye 360 video according to the present invention.
  • 59 is a view showing an embodiment of a method for transmitting 360 video, which may be performed by the 360 video transmitting apparatus according to the present invention.
  • FIG. 1 is a diagram showing the overall architecture for providing 360 video according to the present invention.
  • the present invention proposes a method of providing 360 content in order to provide VR (Virtual Reality) to a user.
  • VR may refer to a technique or environment for replicating a real or virtual environment.
  • VR artificially provides the user with a sensational experience, which allows the user to experience the same as being in an electronically projected environment.
  • 360 content refers to the overall content for implementing and providing VR, and may include 360 video and / or 360 audio.
  • 360 video may refer to video or image content that is needed to provide VR, and simultaneously captured or played back in all directions (360 degrees).
  • 360 video may refer to video or an image displayed on various types of 3D space according to a 3D model, for example, 360 video may be represented on a spherical surface.
  • 360 audio is also audio content for providing VR, and may refer to spatial audio content, in which a sound source can be recognized as being located in a specific space in three dimensions.
  • 360 content may be generated, processed, and transmitted to users, and users may consume the VR experience using 360 content.
  • the present invention particularly proposes a method for effectively providing 360 video.
  • first 360 video may be captured through one or more cameras.
  • the captured 360 video is transmitted through a series of processes, and the receiving side can process and render the received data back into the original 360 video. Through this, 360 video may be provided to the user.
  • the entire process for providing the 360 video may include a capture process, preparation process, transmission process, processing process, rendering process, and / or feedback process.
  • the capturing process may mean a process of capturing an image or a video for each of a plurality of viewpoints through one or more cameras.
  • image / video data such as illustrated at t1010 may be generated.
  • Each plane of t1010 illustrated may mean an image / video for each viewpoint.
  • the captured plurality of images / videos may be referred to as raw data.
  • metadata related to capture may be generated.
  • Special cameras for VR can be used for this capture.
  • capture through an actual camera may not be performed.
  • the corresponding capture process may be replaced by simply generating related data.
  • the preparation process may be a process of processing the captured image / video and metadata generated during 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 this preparation process.
  • each image / video can be stitched.
  • the stitching process may be a process of connecting each captured image / video to create a panoramic image / video or a spherical 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 called a 2D image frame depending on the context. It can also be expressed as mapping a projection to a 2D image to a 2D image.
  • the projected image / video data may be in the form of a 2D image as shown (t1020).
  • the video data projected onto the 2D image may be subjected to region-wise packing to increase video coding efficiency and the like.
  • the region-specific packing may refer to a process of dividing the video data projected on the 2D image by region and applying the process.
  • the region may refer to a region in which 2D images projected with 360 video data are divided.
  • the regions may be divided evenly or arbitrarily divided into 2D images according to an embodiment. In some embodiments, regions may be divided 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 2D images in order to increase video coding efficiency. For example, by rotating the regions so that certain sides of the regions are located close to each other, efficiency in coding can be increased.
  • the process may include increasing or decreasing a resolution for a specific region in order to differentiate the resolution for each region of the 360 video. For example, regions that correspond to regions of greater importance on 360 video may have higher resolution than other regions.
  • Video data projected on 2D images or region-packed video data may be encoded via 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 may be generated.
  • metadata about an initial time point, or a region of interest (ROI) of video data projected on the 2D image may be generated.
  • the transmission process may be a process of processing and transmitting image / video data and metadata that have been prepared. Processing may be performed according to any transport protocol for the transmission. Data that has been processed for transmission may be delivered 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 may refer to a process of decoding the received data and re-projecting the projected image / video data onto the 3D model.
  • image / video data projected on 2D images may be re-projected onto 3D space.
  • This process may be called mapping or projection depending on the context.
  • the mapped 3D space may have a different shape according to the 3D model.
  • the 3D model may have a sphere, a cube, a cylinder, or a 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 of the sample may be increased by upscaling the samples during the upscaling process. If necessary, downscaling may be performed to reduce the size.
  • the rendering process may refer to a process of rendering and displaying re-projected image / video data in 3D space. Depending on the representation, it may be said to combine re-projection and rendering 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 it is re-projected onto a 3D model of a sphere.
  • the user may view some areas of the rendered image / video through the VR display. In this case, the region seen by the user may be in the form as illustrated in t1040.
  • the feedback process may mean a process of transmitting various feedback information that can be obtained in the display process to the transmitter. Through the feedback process, interactivity may be provided for 360 video consumption. According to an embodiment, in the feedback process, head orientation information, viewport information indicating an area currently viewed by the user, and the like may be transmitted to the transmitter. According to an embodiment, the user may interact with those implemented on the VR environment, in which case the information related to the interaction may be transmitted to the sender or service provider side in the feedback process. In some embodiments, the feedback process may not be performed.
  • the head orientation information may mean information about a head position, an angle, and a movement of the user. Based on this information, information about the area currently viewed by the user in the 360 video, that is, viewport information, may be calculated.
  • the viewport information may be information about an area currently viewed by the user in the 360 video. Through this, a gaze analysis may be performed to determine how the user consumes 360 video, which areas of the 360 video are viewed and how much. Gayes analysis may be performed at the receiving end and delivered to the transmitting side via a feedback channel.
  • a device such as a VR display may extract a viewport area based on a user's head position / direction, a vertical or horizontal FOV supported by the device.
  • the above-described feedback information may be consumed at the receiving side as well as being transmitted to the transmitting side. That is, the decoding, re-projection, rendering process, etc. of the receiving side may be performed using the above-described feedback information. For example, only 360 video for the area currently viewed by the user may be preferentially decoded and rendered using head orientation information and / or viewport information.
  • the viewport to the viewport area may mean an area that the user is viewing in 360 video.
  • a viewpoint is a point that a user is viewing in the 360 video and may mean a center point of the viewport area. That is, the viewport is an area centered on the viewpoint, and the size shape occupied by the area may be determined by a field of view (FOV) to be described later.
  • FOV field of view
  • 360 video data image / video data that undergoes a series of processes of capture / projection / encoding / transmission / decoding / re-projection / rendering may be referred to as 360 video data.
  • 360 video data may also be used as a concept including metadata or signaling information associated with such image / video data.
  • FIG. 2 is a diagram illustrating a 360 video transmission apparatus according to an aspect of the present invention.
  • the invention may relate to a 360 video transmission device.
  • the 360 video transmission apparatus according to the present invention may perform operations related to the above-described preparation process or transmission process.
  • the 360 video transmission apparatus according to the present invention includes a data input unit, a stitcher, a projection processing unit, a region-specific packing processing unit (not shown), a metadata processing unit, a (transmitting side) feedback processing unit, a data encoder, 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 the captured images / videos of each viewpoint. These point-in-time images / videos may be images / videos captured by one or more cameras. In addition, the data input unit may receive metadata generated during the capture process. The data input unit may transfer the input image / video for each view to the stitcher, and may transmit metadata of the capture process to the signaling processor.
  • the stitcher may perform stitching on the captured view-point images / videos.
  • the stitcher may transfer the stitched 360 video data to the projection processor. If necessary, the stitcher may receive the necessary metadata from the metadata processor and use the stitching work.
  • the stitcher may transmit metadata generated during the stitching process to the metadata processing unit.
  • the metadata of the stitching process may include information such as whether stitching is performed or a stitching type.
  • the projection processor may project the stitched 360 video data onto the 2D image.
  • the projection processor may perform projection according to various schemes, which will be described later.
  • the projection processor 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 the same for the projection work.
  • the projection processor may transmit the metadata generated in the projection process to the metadata processor. Metadata of the projection processing unit may include a type of projection scheme.
  • the region-specific packing processor may perform the region-specific packing process described above. That is, the region-specific packing processing unit may divide the projected 360 video data into regions, and perform processes such as rotating and rearranging the regions, changing the resolution of each region, and the like. As described above, the region-specific packing process is an optional process. If the region-specific packing is not performed, the region-packing processing unit may be omitted.
  • the region-specific packing processor may receive metadata necessary for region-packing from the metadata processor and use the region-specific packing operation if necessary.
  • the region-specific packing processor may transmit metadata generated in the region-specific packing process to the metadata processor.
  • the metadata of each region packing processing unit may include a rotation degree and a size of each region.
  • the stitcher, the projection processing unit, and / or the regional packing processing unit may be performed in one hardware component according to an embodiment.
  • the metadata processor may process metadata that may occur in a capture process, a stitching process, a projection process, a region-specific packing process, an encoding process, an encapsulation process, and / or a processing for transmission.
  • the metadata processor may generate 360 video related metadata using these metadata.
  • the metadata processor 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 processor may transfer the acquired or generated metadata to internal elements of the 360 video transmission apparatus as needed.
  • the metadata processor may transmit the 360 video related metadata to the data encoder, the encapsulation processor, and / or the transmission processor so that the 360 video related metadata may be transmitted to the receiver.
  • the data encoder may encode 360 video data projected onto the 2D image and / or region-packed 360 video data.
  • 360 video data may be encoded in various formats.
  • the encapsulation processing unit may encapsulate the 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 above-described metadata processing unit.
  • 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 boxes at various levels in the ISOBMFF file format or as data in separate tracks within the file.
  • the encapsulation processing unit may encapsulate the 360 video-related metadata itself into a file.
  • the transmission processor may apply processing for transmission to the encapsulated 360 video data according to the file format.
  • the transmission processor may process the 360 video data according to any transmission protocol.
  • the processing for transmission may include processing for delivery through a broadcasting network and processing for delivery through a broadband.
  • the transmission processor may receive not only 360 video data but also metadata related to 360 video from the metadata processor, and may apply processing for transmission thereto.
  • the transmitter may transmit the processed 360 video data and / or 360 video related metadata through a broadcast network and / or broadband.
  • the transmitter may include an element for transmission through a broadcasting network and / or an element for transmission through a broadband.
  • the 360 video transmission device may further include a data storage unit (not shown) as an internal / external element.
  • the data store may store the encoded 360 video data and / or 360 video related metadata before transmitting to the transfer processor.
  • the data is stored in the form of a file such as ISOBMFF.
  • the data storage unit may not be required.However, when delivering on demand, non real time (NRT) or broadband, the encapsulated 360 data is stored in the data storage unit for a certain period of time. May be sent.
  • the 360 video transmitting apparatus may further include a (transmitting side) feedback processing unit and / or a network interface (not shown) as internal / external elements.
  • the network interface may receive the feedback information from the 360 video receiving apparatus according to the present invention, and transmit the feedback information to the transmitter feedback processor.
  • the transmitter feedback processor may transmit the feedback information to the stitcher, the projection processor, the region-specific packing processor, the data encoder, the encapsulation processor, the metadata processor, and / or the transmission processor.
  • the feedback information may be delivered to each of the internal elements after being transmitted to the metadata processor.
  • the internal elements receiving the feedback information may reflect the feedback information in the subsequent processing of the 360 video data.
  • the region-specific packing processing unit may rotate each region to map on the 2D image.
  • the regions may be rotated at different angles and at different angles and mapped on the 2D image.
  • the rotation of the region can be performed taking into account the portion where the 360 video data was adjacent before projection on the spherical face, 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 be different for each region. Encoding can be performed. The data encoder may encode at a high quality in one region and at a low quality in another region.
  • the transmitter feedback processor may transmit the feedback information received from the 360 video receiving apparatus to the data encoder so that the data encoder uses a region-differential encoding method.
  • the transmitter feedback processor may transmit the viewport information received from the receiver to the data encoder.
  • the data encoder may perform encoding with higher quality (UHD, etc.) than other regions for regions including the region indicated by the viewport information.
  • 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 to change the robustness of the data transmitted for each region.
  • the transmitting-side feedback processor may transmit the feedback information received from the 360 video receiving apparatus to the transmission processing unit so that the transmission processing unit may perform regional differential transmission processing.
  • the transmitter feedback processor may transmit the viewport information received from the receiver to the transmitter.
  • the transmission processor may perform transmission processing on regions that include an area indicated by corresponding viewport information so as to have higher robustness than other regions.
  • Inner and outer elements of the 360 video transmission apparatus may be hardware elements implemented in hardware.
  • the inner and outer elements may be changed, omitted, or replaced with other elements.
  • additional elements may be added to the 360 video transmission device.
  • FIG. 3 is a diagram illustrating a 360 video receiving apparatus according to another aspect of the present invention.
  • the present invention may be related to a 360 video receiving apparatus.
  • the 360 video receiving apparatus according to the present invention may perform operations related to the above-described processing and / or rendering.
  • the 360 video receiving apparatus according to the present invention may include a receiver, a receiver processor, a decapsulation processor, a data decoder, a metadata parser, a (receiver side) feedback processor, a re-projection processor, and / or a renderer as internal / external elements. have.
  • the receiver may receive 360 video data transmitted by the 360 video transmission device according to the present invention. According to the transmitted channel, the receiver may receive 360 video data through a broadcasting network or may receive 360 video data through a broadband.
  • the reception processor may perform processing according to a transmission protocol on the received 360 video data.
  • the reception processing unit may perform a reverse process of the above-described transmission processing unit so as to correspond to that the processing for transmission is performed at the transmission side.
  • the reception processor may transmit the obtained 360 video data to the decapsulation processing unit, and the obtained 360 video data may be transferred to the metadata parser.
  • the 360 video related metadata acquired by the reception processor may be in the form of a signaling table.
  • the decapsulation processor may decapsulate the 360 video data in the form of a file received from the reception processor.
  • 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 the data decoder, and the obtained 360 video related metadata may be transmitted to the metadata parser.
  • the 360 video related metadata acquired by the decapsulation processing unit may be in the form of a box or track in a file format.
  • the decapsulation processing unit may receive metadata necessary for decapsulation from the metadata parser if necessary.
  • the data decoder may perform decoding on 360 video data.
  • the data decoder may receive metadata required for decoding from the metadata parser.
  • the 360 video-related metadata obtained in the data decoding process may be delivered to the metadata parser.
  • the metadata parser may parse / decode 360 video related metadata.
  • the metadata parser may transfer the obtained metadata to the data decapsulation processor, the data decoder, the re-projection processor, and / or the renderer.
  • the re-projection processor may perform re-projection on the decoded 360 video data.
  • the re-projection processor may re-project the 360 video data into the 3D space.
  • the 3D space may have a different shape depending on the 3D model used.
  • the re-projection processor may receive metadata required for re-projection from the metadata parser.
  • the re-projection processor may receive information about the type of the 3D model used and the details thereof from the metadata parser.
  • the re-projection processor may re-project only 360 video data corresponding to a specific area in the 3D space into the 3D space by using metadata required for the re-projection.
  • the renderer may render the re-projected 360 video data.
  • the 360 video data may be rendered in 3D space. If the two processes occur at once, the re-projection unit and the renderer may be integrated so that all processes may be performed in the renderer. According to an exemplary embodiment, the renderer may render only the portion that the user is viewing based on the viewpoint information of the user.
  • the user may view a portion of the 360 video rendered through the VR display.
  • the VR display is a device for playing 360 video, which may be included in the 360 video receiving device (tethered) or may be un-tethered as a separate device to the 360 video receiving device.
  • the 360 video receiving apparatus may further include a (receiving side) feedback processing unit and / or a network interface (not shown) as internal / external elements.
  • the receiving feedback processor may obtain and process feedback information from a renderer, a re-projection processor, a data decoder, a decapsulation processor, 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 the feedback information from the receiver feedback processor and transmit the feedback information to the 360 video transmission apparatus.
  • the receiving side feedback processor may transmit the obtained feedback information to the internal elements of the 360 video receiving apparatus to be reflected in a rendering process.
  • the receiving feedback processor may transmit the feedback information to the renderer, the re-projection processor, the data decoder, and / or the decapsulation processor.
  • the renderer may preferentially render the area that the user is viewing by using the feedback information.
  • the decapsulation processing unit, the data decoder, and the like may preferentially decapsulate and decode the region viewed by the user or the region to be viewed.
  • Inner and outer elements of the 360 video receiving apparatus may be hardware elements implemented in hardware. In some embodiments, the inner and outer elements may be changed, omitted, or replaced with other elements. According to an embodiment, additional elements may be added to the 360 video receiving apparatus.
  • Another aspect of the invention may relate to a method of transmitting 360 video and a method of receiving 360 video.
  • the method of transmitting / receiving 360 video according to the present invention may be performed by the above-described 360 video transmitting / receiving device or embodiments of the device, respectively.
  • the above-described embodiments of the 360 video transmission / reception apparatus, the transmission / reception method, and the respective internal / external elements may be combined with each other.
  • the embodiments of the projection processing unit and the embodiments of the data encoder may be combined with each other to produce as many embodiments of the 360 video transmission device as that case. Embodiments thus combined are also included in the scope of the present invention.
  • FIG. 4 is a diagram illustrating a 360 video transmission device / 360 video receiving device according to another embodiment of the present invention.
  • 360 content may be provided by an architecture as shown (a).
  • the 360 content may be provided in the form of a file or in the form of a segment-based download or streaming service such as a 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 preprocessing process and an audio encoding process.
  • audio related metadata may be generated, and the 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 the 360 video data (Visual stitching). This process may be omitted in some embodiments and may be performed at the receiving side.
  • the projection processor of the 360 video transmission apparatus may project 360 video data onto a 2D image (Projection and mapping (packing)).
  • This stitching and projection process is shown in detail in (b).
  • stitching and projection may be performed.
  • the projection process specifically, the stitched 360 video data is projected onto the 3D space, and the projected 360 video data may be viewed as being arranged on the 2D image.
  • This process may be expressed herein 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 on the receiving side.
  • the 2D image may be called a projected frame (C).
  • Region-wise packing may optionally be further performed on this 2D image.
  • regions on a 2D image may be mapped onto a packed frame by indicating the location, shape, and size of each region. If regional packing is not performed, 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 onto a 2D image. Depending on the design, 360 video data may be converted directly to packed frames without intermediate processing.
  • the projected 360 video data may be image encoded or 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 can be included in separate tracks for DASH-based transmission.
  • 360 video related metadata may be generated as described above.
  • This metadata may be delivered in a video stream or file format.
  • This metadata can also be used for encoding, file format encapsulation, and processing for transfer.
  • the 360 audio / video data is processed for transmission according to the transmission protocol and then transmitted.
  • the above-described 360 video receiving apparatus may receive this through a broadcasting network or a broadband.
  • a VR service platform may correspond to an embodiment of the above-described 360 video receiving apparatus.
  • speakers / headphones, displays, and head / eye tracking components are shown to be performed by an external device or a VR application 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 above-described feedback feedback processor.
  • the 360 video receiving apparatus may perform file / segment decapsulation on the 360 audio / video data.
  • the 360 audio data may be provided to the user through a speaker / headphone through an audio decoding process and an audio rendering process.
  • 360 video data may be provided to a user through a display through image decoding, video decoding, and rendering.
  • the display may be a display supporting VR or a general display.
  • the rendering process may specifically be regarded as 360 video data being re-projected onto 3D space, and the re-projected 360 video data is rendered. This may be expressed as 360 video data being rendered in 3D space.
  • the head / eye tracking component may acquire and process user head orientation information, gaze information, viewport information, and the like. This has been described above.
  • FIG. 5 is a diagram illustrating the concept of an airplane main axis (Aircraft Principal Axes) for explaining the 3D space of the present invention.
  • the plane principal axis concept may be used to represent a specific point, position, direction, spacing, area, etc. in 3D space.
  • the plane axis concept may be used to describe the 3D space before the projection or after the re-projection and to perform signaling on the 3D space.
  • a method using an X, Y, Z axis concept or a spherical coordinate system may be used.
  • the plane can rotate freely in three dimensions.
  • the three-dimensional axes are called the pitch axis, the yaw axis, and the roll axis, respectively. In the present specification, these may be reduced to express pitch, yaw, roll to pitch direction, yaw direction, and roll direction.
  • the pitch axis may mean an axis that is a reference for the direction in which the nose of the airplane rotates up and down.
  • the pitch axis may mean an axis extending from the wing of the plane to the wing.
  • the Yaw axis may mean an axis that is a reference of the direction in which the front nose of the plane rotates left and right.
  • the yaw axis can mean an axis running from top to bottom of the plane.
  • the roll axis is an axis extending from the front nose to the tail of the plane in the illustrated plane axis concept, and the rotation in the roll direction may mean a rotation about the roll axis.
  • the 3D space in the present invention 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 present invention.
  • the projection processing unit of the 360 video transmission apparatus may project the stitched 360 video data onto the 2D image.
  • Various projection schemes can be used in this process.
  • the projection processing unit may perform projection using a cubic projection scheme (Cubic Projection) scheme.
  • Cubic Projection cubic projection scheme
  • stitched 360 video data may be represented on a spherical face.
  • the projection processor may divide the 360 video data into cubes and project them on a 2D image.
  • 360 video data on a spherical face may correspond to each face of a cube and may be projected onto the 2D image as (a) left or (a) right.
  • the projection processing unit may perform the projection by using a cylindrical projection (Cylindrical Projection) scheme.
  • the projection processor may divide the 360 video data into a cylinder and project it on a 2D image.
  • 360 video data on a spherical surface may be projected on the 2D image as (b) left or (b) right, respectively, corresponding to the side, top and bottom of the cylinder.
  • the projection processing unit may perform projection by using a pyramid projection scheme.
  • the projection processor can view the 360 video data in a pyramid form, and divide each face to project on a 2D image.
  • 360 video data on a spherical face correspond to the front of the pyramid and the four sides of the pyramid (Left top, Left bottom, Right top, Right bottom), respectively, and (c) left or ( c) can be projected as shown on the right.
  • the projection processing unit may perform projection using an isometric square projection scheme, a panoramic projection scheme, or the like in addition to the above-described schemes.
  • the region may mean a region in which the 2D image projected with the 360 video data is divided. These regions need not coincide with the faces on the projected 2D image according to the projection scheme. However, according to an embodiment, regions may be divided so that respective surfaces on the projected 2D image correspond to regions, and region-specific packing may be performed. According to an embodiment, a plurality of faces may correspond to one region or regions may be divided such 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 side of the cube (top, bottom, front, left, right, back) may be a region, respectively. In (b), the side, top and bottom of the cylinder may each be a region. In (c), the front, left, right, and bottom of the pyramid may be regions, respectively.
  • FIG. 7 is a diagram illustrating a tile according to an embodiment of the present invention.
  • 360 video data projected onto a 2D image or 360 video data performed up to region-specific packing may be divided into one or more tiles.
  • (A) shows a form in which one 2D image is divided into 16 tiles.
  • the 2D image may be the above-described projected frame or packed frame.
  • the data encoder can encode each tile independently.
  • the region-specific packing and tiling may be distinguished.
  • the region-specific packing described above may mean processing the 360 video data projected on the 2D image into regions in order to increase coding efficiency or to adjust resolution.
  • Tiling may mean that the data encoder divides a projected frame or a packed frame into sections called tiles, and independently encodes corresponding tiles.
  • the user does not consume all parts of the 360 video at the same time.
  • Tiling may enable transmitting or consuming only the tiles corresponding to the critical part or a certain part, such as the viewport currently viewed by the user, on the limited bandwidth. Tiling allows for more efficient use of limited bandwidth and reduces the computational load on the receiving side compared to processing all 360 video data at once.
  • Regions and tiles are distinct, so the two regions do not have to be the same. However, in some embodiments, regions and tiles may refer to the same area. According to an exemplary embodiment, region-specific packing may be performed according to tiles so that regions and tiles may be the same. Further, according to an embodiment, when each side and region according to the projection scheme are the same, each side, 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, a tile region.
  • Region of Interest may refer to areas of interest of users, which are suggested by 360 content providers.
  • a 360 content provider produces a 360 video
  • a certain area may be considered to be of interest to users, and the 360 content provider may produce a 360 video in consideration of this.
  • the ROI may correspond to an area where important content is played on the content of the 360 video.
  • the receiving feedback processor may extract and collect the viewport information and transmit it to the transmitting feedback processor.
  • viewport information can be delivered using both network interfaces.
  • the viewport t6010 is displayed in the 2D image of (a) shown.
  • the viewport may span nine tiles on the 2D image.
  • the 360 video transmission device may further include a tiling system.
  • the tiling system may be located after the data encoder ((b)), may be included in the above-described data encoder or transmission processing unit, or may be included in the 360 video transmission apparatus as a separate internal / external element. .
  • the tiling system may receive viewport information from the feedback feedback processor.
  • the tiling system may select and transmit only the tiles including the viewport area. In the 2D image shown in (a), only nine tiles including the viewport area t6010 among the total 16 tiles may be transmitted.
  • the tiling system may transmit tiles in a unicast manner through broadband. This is because the viewport area is different for each user.
  • the transmitter-side feedback processor may transmit the viewport information to the data encoder.
  • the data encoder may perform encoding on tiles including the viewport area at higher quality than other tiles.
  • the feedback feedback processor may transmit the viewport information to the metadata processor.
  • the metadata processor may transmit metadata related to the viewport area to each internal element of the 360 video transmission apparatus or include the metadata related to 360 video.
  • Embodiments related to the viewport area described above may be applied in a similar manner to specific areas other than the viewport area.
  • the above-described gaze analysis may be used to determine areas of interest, ROI areas, and areas that are first played when the user encounters 360 video through a VR display (initial viewpoint).
  • the processes may be performed.
  • the transmission processor may perform processing for transmission differently for each tile.
  • the transmission processor may apply different transmission parameters (modulation order, code rate, etc.) for each tile to vary the robustness of the data transmitted for each tile.
  • the transmitting-side feedback processor may transmit the feedback information received from the 360 video receiving apparatus to the transmission processor so that the transmission processor performs the differential transmission process for each tile.
  • the transmitter feedback processor may transmit the viewport information received from the receiver to the transmitter.
  • the transmission processor may perform transmission processing on tiles including the corresponding viewport area to have higher robustness than other tiles.
  • FIG 8 illustrates 360 video related metadata according to an embodiment of the present invention.
  • the above-described 360 video related metadata may include various metadata about 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, included in a DASH MPD, transmitted, or included in a box format in a file format such as ISOBMFF.
  • the file, the fragment, the track, the sample entry, the sample, and the like may be included in various levels to include metadata about the data of the corresponding level.
  • some of the metadata to be described later may be configured as a signaling table, and the other may be included in a box or track in the file format.
  • the 360 video related metadata may include basic metadata related to a projection scheme, stereoscopic related metadata, and initial view / initial viewpoint related metadata. Data, ROI related metadata, Field of View (FOV) 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.
  • Embodiments of 360 video related metadata according to the present invention include the above-described basic metadata, stereoscopic related metadata, initial viewpoint related metadata, ROI related metadata, FOV related metadata, cropped region related metadata and / or It may be in the form including at least one or more of the metadata that can be added later.
  • Embodiments of the 360 video related metadata according to the present invention may be variously configured according to the number of detailed metadata cases included in the 360 video. According to an embodiment, the 360 video related metadata may further include additional information in addition to the above.
  • the basic metadata may include 3D model related information and projection scheme related information.
  • 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 during 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 the 3D model used at the time of rendering. If the corresponding field has a value of 0, 1, 2, and 3, the 3D space may follow 3D models of sphere, cube, cylinder, and pyramid, respectively.
  • the 360 video related metadata may further include specific information about the 3D model indicated by the corresponding field.
  • the specific information about the 3D model may mean, for example, radius information of a sphere and height information of a cylinder. This field may be omitted.
  • the projection_scheme field may indicate a projection scheme used when the corresponding 360 video data is projected on the 2D image. If the field has a value of 0, 1, 2, 3, 4, 5, respectively, an isometric square projection scheme, a cubic projection scheme, a cylindrical projection scheme, and a tile-based projection scheme , Pyramid projection scheme, panoramic projection scheme may have been used. If the corresponding field has a value of 6, 360 video data may be directly projected onto the 2D image without stitching. If the field has the remaining values, it can be reserved for future use.
  • the 360 video related metadata may further include specific information about a region generated by the projection scheme specified by the corresponding field.
  • the specific information about the region may mean, for example, whether the region is rotated or radius information of the top region of the cylinder.
  • Stereoscopic related metadata may include information about 3D related attributes of 360 video data.
  • Stereoscopic related metadata may include an is_stereoscopic field and / or a stereo_mode field.
  • stereoscopic related metadata may further include additional information.
  • the is_stereoscopic field may indicate whether the corresponding 360 video data supports 3D. If the field is 1, 3D support is available. If the field is 0, 3D support is not supported. This field may be omitted.
  • the stereo_mode field may indicate a 3D layout supported by the corresponding 360 video. Only this field may indicate whether the corresponding 360 video supports 3D. In this case, the above-described is_stereoscopic field may be omitted. If this field value is 0, the 360 video may be in mono mode. That is, the projected 2D image may include only one mono view. In this case, the 360 video may not support 3D.
  • the corresponding 360 video may be based on left-right layout and top-bottom layout, respectively.
  • the left and right layouts and the top and bottom layouts may be referred to as side-by-side format and top-bottom format, respectively.
  • 2D images projected from the left image and the right image may be positioned left and right on the image frame, respectively.
  • 2D images projected from the left image and the right image may be positioned up and down on the image frame, respectively. If the field has the remaining values, it can be reserved for future use.
  • the initial view-related metadata may include information about a view point (initial view point) when the user first plays the 360 video.
  • 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 initial view-related metadata 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 time point when playing the corresponding 360 video.
  • the center point of the viewport that is first seen upon playback can be represented by these three fields.
  • Each field may indicate a position (sign) and a degree (angle) at which its center point is rotated about the yaw, pitch, and roll axes.
  • the viewport that is displayed during the first playback may be determined according to the FOV. Through the FOV, the width and height of the initial viewport may be determined based on the indicated initial view. That is, using these three fields and the FOV information, the 360 video receiving apparatus may provide a user with a predetermined area of 360 video as an initial viewport.
  • the initial view point indicated by the initial view-related metadata may be changed for each scene. That is, the scene of the 360 video is changed according to the temporal flow of the 360 content. For each scene of the 360 video, the initial view point or the initial viewport that the user first sees may be changed.
  • the metadata regarding the initial view may indicate the initial view for each scene.
  • the initial view-related metadata may further include a scene identifier for identifying a scene to which the initial view is applied.
  • the initial view-related metadata may further include scene-specific FOV information indicating the FOV corresponding to the scene.
  • the ROI related metadata may include information related to the above-described ROI.
  • 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 the ROI-related metadata includes fields representing the ROI based on the 2D image or fields representing the ROI based on the 3D space.
  • the ROI related metadata may further include additional information such as differential encoding information according to ROI and differential transmission processing information according to ROI.
  • ROI related metadata may include 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 of the upper left end of the ROI. These fields may indicate the minimum x coordinate, the maximum x coordinate, the minimum y coordinate, and the maximum y coordinate of the upper left end in order.
  • the min_width field, the max_width field, the min_height field, and the max_height field may indicate minimum / maximum values of the width and height of the ROI. These fields 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 in order.
  • the min_x field, max_x field, min_y field, and max_y field may indicate minimum / maximum values of coordinates in the ROI. These fields may in turn indicate the minimum x coordinate, maximum x coordinate, minimum y coordinate, and maximum y coordinate of coordinates in the ROI. These fields may be omitted.
  • the ROI related metadata may include a 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 It may include a max_field_of_view field.
  • the min_yaw field, max_yaw field, min_pitch field, max_pitch field, min_roll field, and max_roll field may indicate 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, maximum yaw axis rotation, minimum pitch axis rotation, pitch axis rotation, minimum roll axis rotation, 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 a minimum / maximum value of the FOV of the corresponding 360 video data.
  • the FOV may refer to 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 represent minimum and maximum values of the FOV, respectively. These fields may be omitted. These fields may be included in FOV related metadata to be described later.
  • the FOV related metadata may include information related to the above-described FOV.
  • 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 the minimum / maximum value related information of the above-described FOV.
  • the content_fov_flag field may indicate whether information about an FOV intended for production is present for the corresponding 360 video. If this field value is 1, there may be a content_fov field.
  • the content_fov field may indicate information about an FOV intended for production of the corresponding 360 video.
  • an area displayed at one time from among 360 images may be determined based on a vertical or horizontal FOV of the corresponding 360 video receiving apparatus.
  • an area of 360 video displayed to the user at one time may be determined by reflecting the FOV information of the field.
  • the cropped region related metadata may include information about an region including actual 360 video data on an image frame.
  • the image frame may include an active 360 video projected active video area and an area that is not.
  • the active video region may be referred to as a cropped region or a default display region.
  • This active video area is an area shown as 360 video on the actual VR display, and the 360 video receiving apparatus or the VR display can process / display only the active video area. For example, if the aspect ratio of an image frame is 4: 3, only the regions except for the upper part and the lower part of the image frame may include 360 video data, which may be called an active video area. .
  • the cropped region related metadata may include an is_cropped_region field, a cr_region_left_top_x field, a cr_region_left_top_y field, a cr_region_width field, and / or a 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 an entire region of an image frame is used by the 360 video receiving apparatus or the VR display. That is, this field may indicate whether the entire image frame is an active video area. If only a part of the image frame is an active video area, the following four fields may be 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. 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, respectively. The width and height may be expressed in pixels.
  • FIG. 9 illustrates the structure of a media file according to an embodiment of the present invention.
  • FIG. 10 illustrates a hierarchical structure of boxes in an ISOBMFF according to an embodiment of the present invention.
  • the media file may have a file format based on ISO BMFF (ISO base media file format).
  • the media file according to the present invention may include at least one box.
  • the box may be a data block or an object including media data or metadata related to the media data.
  • the boxes may form a hierarchical structure with each other, such that the data may be classified so that the media file may be in a form suitable for storage and / or transmission of large media data.
  • the media file may have an easy structure for accessing the media information, such as a user moving to a specific point of the media content.
  • the media file according to the present invention may include an ftyp box, a moov box and / or an mdat box.
  • An ftyp box can provide file type or compatibility related information for a corresponding media file.
  • the ftyp box may include configuration version information about media data of a corresponding media file.
  • the decoder can identify the media file by referring to the ftyp box.
  • the moov box may be a box including metadata about media data of a corresponding media file.
  • the moov box can act as a container for all metadata.
  • the moov box may be a box of the highest layer among metadata related boxes. According to an embodiment, only one moov box may exist in a media file.
  • the mdat box may be a box containing actual media data of the media file.
  • Media data may include audio samples and / or video samples, where the mdat box may serve as a container for storing these media samples.
  • the above-described moov box may further include a mvhd box, a trak box and / or an mvex box as a lower box.
  • the mvhd box may include media presentation related information of media data included in the media file. That is, the mvhd box may include information such as media generation time, change time, time specification, duration, etc. of the media presentation.
  • the trak box can provide information related to the track of the media data.
  • the trak box may include information such as stream related information, presentation related information, and access related information for an audio track or a video track. There may be a plurality of trak boxes according to the number of tracks.
  • the trak box may further include a tkhd box (track header box) as a lower box.
  • the tkhd box may include information about the track indicated by the trak box.
  • the tkhd box may include information such as a creation time, a change time, and a track identifier of the corresponding track.
  • the mvex box (movie extend box) may indicate that the media file may have a moof box to be described later. To know all the media samples of a particular track, moof boxes may have to be scanned.
  • the media file according to the present invention may be divided into a plurality of fragments according to an embodiment (t18010). Through this, the media file may be divided and stored or transmitted.
  • the media data (mdat box) of the media file may be divided into a plurality of fragments, and each fragment may include a mdat box and a moof box. According to an embodiment, information of the ftyp box and / or the moov box may be needed to utilize the fragments.
  • the moof box may provide metadata about media data of the fragment.
  • the moof box may be a box of the highest layer among metadata-related boxes of the fragment.
  • the mdat box may contain the actual media data as described above.
  • This mdat box may include media samples of media data corresponding to each corresponding fragment.
  • the above-described moof box may further include a mfhd box and / or a traf box as a lower box.
  • the mfhd box may include information related to an association between a plurality of fragmented fragments.
  • the mfhd box may include a sequence number to indicate how many times the media data of the corresponding fragment is divided. In addition, it may be confirmed whether there is no missing data divided using the mfhd box.
  • the traf box may include information about a corresponding track fragment.
  • the traf box may provide metadata about the divided track fragments included in the fragment.
  • the traf box may provide metadata so that media samples in the track fragment can be decoded / played back. There may be a plurality of traf boxes according to the number of track fragments.
  • the above-described traf box may further include a tfhd box and / or a trun box as a lower box.
  • the tfhd box may include header information of the corresponding track fragment.
  • the tfhd box may provide information such as a basic sample size, a duration, an offset, an identifier, and the like for media samples of the track fragment indicated by the traf box described above.
  • the trun box may include corresponding track fragment related information.
  • the trun box may include information such as duration, size, and playback time of each media sample.
  • the aforementioned media file or fragments of the media file may be processed into segments and transmitted.
  • the segment may have an initialization segment and / or a media segment.
  • the file of the illustrated embodiment t18020 may be a file including information related to initialization of the media decoder except media data. This file may correspond to the initialization segment described above, for example.
  • the initialization segment may include the ftyp box and / or moov box described above.
  • the file of the illustrated embodiment t18030 may be a file including the above-described fragment. This file may correspond to the media segment described above, for example.
  • the media segment may include the moof box and / or mdat box described above.
  • the media segment may further include a styp box and / or a sidx box.
  • the styp box may provide information for identifying the media data of the fragmented fragment.
  • the styp box may play the same role as the above-described ftyp box for the divided fragment.
  • the styp box may have the same format as the ftyp box.
  • the sidx box may provide information indicating an index for the divided fragment. Through this, it is possible to indicate how many fragments are the corresponding fragments.
  • the ssix box may be further included.
  • the ssix box (sub-segment index box) may provide information indicating an index of the sub-segment when the segment is further divided into sub-segments.
  • the boxes in the media file may include more extended information based on a box to full box form such as the illustrated embodiment t18050.
  • the size field and the largesize field may indicate the length of the corresponding box in bytes.
  • the version field may indicate the version of the box format.
  • the type field may indicate the type or identifier of the corresponding box.
  • the flags field may indicate a flag related to the box.
  • FIG. 11 is a diagram illustrating the overall operation of the DASH-based adaptive streaming model according to an embodiment of the present invention.
  • the DASH-based adaptive streaming model according to the illustrated embodiment t50010 describes the operation between the HTTP server and the DASH client.
  • DASH Dynamic Adaptive Streaming over HTTP
  • AV content can be provided without interruption.
  • the DASH client can obtain the MPD.
  • MPD may be delivered from a service provider such as an HTTP server.
  • the DASH client can request the segments from the server using the access information to the segment described in the MPD. In this case, the request may be performed by reflecting the network state.
  • the DASH client may process it in the media engine and display the segment on the screen.
  • the DASH client may request and acquire a required segment by adaptively reflecting a playing time and / or a network condition (Adaptive Streaming). This allows the content to be played back seamlessly.
  • Adaptive Streaming a network condition
  • MPD Media Presentation Description
  • the DASH Client Controller may generate a command for requesting the MPD and / or the segment reflecting the network situation.
  • the controller can control the obtained information to be used in an internal block of the media engine or the like.
  • the MPD Parser may parse the acquired MPD in real time. This allows the DASH client controller to generate a command to obtain the required segment.
  • the segment parser may parse the acquired segment in real time. Internal blocks such as the media engine may perform a specific operation according to the information included in the segment.
  • the HTTP client may request the HTTP server for necessary MPDs and / or segments.
  • the HTTP client may also pass MPD and / or segments obtained from the server to the MPD parser or segment parser.
  • the media engine may display content on the screen using media data included in the segment. At this time, the information of the MPD may be utilized.
  • the DASH data model may have a high key structure t50020.
  • Media presentation can be described by the MPD.
  • MPD may describe a temporal sequence of a plurality of periods that make up a media presentation.
  • the duration may represent one section of media content.
  • the data may be included in the adaptation sets.
  • the adaptation set may be a collection of a plurality of media content components that may be exchanged with each other.
  • the adaptation may comprise a set of representations.
  • the representation may correspond to a media content component.
  • content can be divided in time into a plurality of segments. This may be for proper accessibility and delivery.
  • the URL of each segment may be provided to access each segment.
  • the MPD may provide information related to the media presentation, and the pyorium element, the adaptation set element, and the presentation element may describe the corresponding pyoride, the adaptation set, and the presentation, respectively.
  • Representation may be divided into sub-representations, the sub-representation element may describe the sub-representation.
  • Common properties / elements can be defined here, which can be applied (included) to adaptation sets, representations, subrepresentations, and so on.
  • common properties / elements there may be an essential property and / or a supplemental property.
  • the essential property may be information including elements that are considered essential in processing the media presentation related data.
  • the supplemental property may be information including elements that may be used in processing the media presentation related data.
  • the descriptors to be described below may be defined and delivered in essential properties and / or supplemental properties when delivered through the MPD.
  • the data encoder according to the present invention may perform various encoding schemes including a video / image encoding scheme according to high efficiency video codec (HEVC).
  • HEVC high efficiency video codec
  • the data decoder 700 may include a picture divider 705, a predictor 710, a subtractor 715, a transformer 720, a quantizer 725, a realigner 730, and entropy.
  • the encoder 735 may include a residual processor 740, an adder 750, a filter 755, and a memory 760.
  • the residual processor 740 may include an inverse quantizer 741 and an inverse transform unit 742.
  • the picture divider 705 may divide the input image into at least one processing unit.
  • a unit represents the basic unit of image processing.
  • the unit may include at least one of a specific region of the picture and information related to the region.
  • the unit may be used interchangeably with terms such as block or area in some cases.
  • an M ⁇ N block may represent a set of samples or transform coefficients composed of M columns and N rows.
  • the processing unit may be called a coding unit (CU).
  • the coding unit may be recursively split from the largest coding unit (LCU) according to a quad-tree binary-tree (QTBT) structure.
  • LCU largest coding unit
  • QTBT quad-tree binary-tree
  • 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.
  • the quad tree structure may be applied first and the binary tree structure may be applied later.
  • the binary tree structure may be applied first.
  • the coding procedure according to the present invention may be performed based on the final coding unit that is no longer split.
  • the maximum coding unit may be used as the final coding unit immediately based on coding efficiency according to the image characteristic, or if necessary, the coding unit is recursively divided into coding units of lower depths and optimized.
  • a coding unit of size may be used as the final coding unit.
  • the coding procedure may include a procedure of prediction, transform, and reconstruction, which will be described later.
  • the processing unit may include a coding unit (CU) prediction unit (PU) or a transform unit (TU).
  • the coding unit may be split from the largest coding unit (LCU) into coding units of deeper depths along the quad tree structure.
  • LCU largest coding unit
  • the maximum coding unit may be used as the final coding unit immediately based on coding efficiency according to the image characteristic, or if necessary, the coding unit is recursively divided into coding units of lower depths and optimized.
  • a coding unit of size may be used as the final coding unit. If a smallest coding unit (SCU) is set, the coding unit may not be split into smaller coding units than the minimum coding unit.
  • the final coding unit refers to a coding unit that is the basis of partitioning or partitioning into a prediction unit or a transform unit.
  • the prediction unit is a unit partitioning from the coding unit and may be a unit of sample prediction. In this case, the prediction unit may be divided into sub blocks.
  • the transform unit may be divided along the quad tree structure from the coding unit, and may be a unit for deriving a transform coefficient and / or a unit for deriving a residual signal from the transform coefficient.
  • a coding unit may be called a coding block (CB)
  • a prediction unit is a prediction block (PB)
  • a transform unit may be called a transform block (TB).
  • a prediction block or prediction unit may mean a specific area in the form of a block within a picture, and may include an array of prediction samples.
  • a transform block or a transform unit may mean a specific area in a block form within a picture, and may include an array of transform coefficients or residual samples.
  • the prediction unit 710 may perform a prediction on a block to be processed (hereinafter, referred to as a current block) and generate a predicted block including prediction samples of the current block.
  • the unit of prediction performed by the prediction unit 710 may be a coding block, a transform block, or a prediction block.
  • the prediction unit 710 may determine whether intra prediction or inter prediction is applied to the current block. As an example, the prediction unit 710 may determine whether intra prediction or inter prediction is applied on a CU basis.
  • the prediction unit 710 may derive a prediction sample for the current block based on reference samples outside the current block in the picture to which the current block belongs (hereinafter, referred to as the current picture). In this case, the prediction unit 710 may derive the prediction sample based on (i) average or interpolation of neighboring reference samples of the current block, and (ii) neighbor reference of the current block.
  • the prediction sample may be derived based on a reference sample present in a specific (prediction) direction with respect to the prediction sample among the samples. In case of (i), it may be called non-directional mode or non-angle mode, and in case of (ii), it may be called directional mode or angular mode.
  • the prediction mode may have, for example, 33 or more directional prediction modes and at least 2 or more non-directional modes.
  • the non-directional mode may include a DC prediction mode and a planner mode (Planar mode).
  • the prediction unit 710 may determine the prediction mode applied to the current block by using the prediction mode applied to the neighboring block.
  • the prediction unit 710 may derive the prediction sample for the current block based on the sample specified by the motion vector on the reference picture.
  • the prediction unit 710 may derive the prediction sample for the current block by applying any one of a skip mode, a merge mode, and a motion vector prediction (MVP) mode.
  • the prediction unit 710 may use the motion information of the neighboring block as the motion information of the current block.
  • the skip mode unlike the merge mode, the difference (residual) between the prediction sample and the original sample is not transmitted.
  • the motion vector of the current block may be derived using the motion vector of the neighboring block as a motion vector predictor.
  • the neighboring block may include a spatial neighboring block existing in the current picture and a temporal neighboring block present in the reference picture.
  • a reference picture including the temporal neighboring block may be called a collocated picture (colPic).
  • the motion information may include a motion vector and a reference picture index.
  • Information such as prediction mode information and motion information may be encoded (entropy) and output in the form of a bitstream.
  • the highest picture on the reference picture list may be used as the reference picture.
  • Reference pictures included in a reference picture list may be sorted based on a difference in a picture order count (POC) between a current picture and a corresponding reference picture.
  • POC picture order count
  • the subtraction unit 715 generates a residual sample which is a difference between the original sample and the prediction sample.
  • residual samples may not be generated as described above.
  • the transform unit 720 generates transform coefficients by converting the residual samples in units of transform blocks.
  • the transformer 720 may perform the transformation according to the size of the transform block and the prediction mode applied to the coding block or the prediction block that spatially overlaps the transform block. For example, if intra prediction is applied to the coding block or the prediction block that overlaps the transform block, and the transform block is a 4 ⁇ 4 residual array, the residual sample is configured to perform a discrete sine transform (DST) transform kernel.
  • the residual sample may be transformed using a discrete cosine transform (DCT) transform kernel.
  • DST discrete sine transform
  • DCT discrete cosine transform
  • the quantization unit 725 may quantize the transform coefficients to generate quantized transform coefficients.
  • the reordering unit 730 rearranges the quantized transform coefficients.
  • the reordering unit 130 may reorder the quantized transform coefficients in the form of a block into a one-dimensional vector form through a coefficient scanning method. Although the reordering unit 130 has been described in a separate configuration, the reordering unit 730 may be part of the quantization unit 725.
  • the entropy encoding unit 735 may perform entropy encoding on the quantized transform coefficients.
  • Entropy encoding may include, for example, encoding methods such as exponential Golomb, context-adaptive variable length coding (CAVLC), context-adaptive binary arithmetic coding (CABAC), and the like.
  • the entropy encoding unit 735 may encode information necessary for video reconstruction other than the quantized transform coefficients (for example, a value of a syntax element) together or separately. Entropy encoded information may be transmitted or stored in units of network abstraction layer (NAL) units in the form of bitstreams.
  • NAL network abstraction layer
  • the inverse quantization unit 741 inversely quantizes the quantized values (quantized transform coefficients) in the quantization unit 725, and the inverse transformer 742 inversely transforms the inverse quantized values in the inverse quantization unit 741.
  • the adder 750 reconstructs the picture by combining the residual sample and the predictive sample.
  • the residual sample and the predictive sample may be added in units of blocks to generate a reconstructed block.
  • the adder 750 has been described in a separate configuration, the adder 750 may be part of the predictor 710.
  • the adder 750 may be called a restoration unit or a restoration block generation unit.
  • the filter unit 755 may apply a deblocking filter and / or a sample adaptive offset to the reconstructed picture. Through deblocking filtering and / or sample adaptive offset, the artifacts of the block boundaries in the reconstructed picture or the distortion in the quantization process can be corrected.
  • the sample adaptive offset may be applied on a sample basis and may be applied after the process of deblocking filtering is completed.
  • the filter unit 755 may apply an adaptive loop filter (ALF) to the reconstructed picture. ALF may be applied to the reconstructed picture after the deblocking filter and / or sample adaptive offset is applied.
  • ALF adaptive loop filter
  • the memory 760 may store a reconstructed picture (decoded picture) or information necessary for encoding / decoding.
  • the reconstructed picture may be a reconstructed picture after the filtering process is completed by the filter unit 755.
  • the stored reconstructed picture may be used as a reference picture for (inter) prediction of another picture.
  • the memory 760 may store (reference) pictures used for inter prediction.
  • pictures used for inter prediction may be designated by a reference picture set or a reference picture list.
  • FIG. 13 is a diagram exemplarily illustrating a configuration of a data decoder according to the present invention.
  • the data decoder 800 includes an entropy decoding unit 810, a residual processor 820, a predictor 830, an adder 840, a filter 850, and a memory 860. can do.
  • the residual processor 820 may include a reordering unit 821, an inverse quantization unit 822, and an inverse transform unit 823.
  • the video decoding apparatus 800 may restore the video in response to a process in which the video information is processed in the video encoding apparatus.
  • the video decoding apparatus 800 may perform video decoding using a processing unit applied in the video encoding apparatus.
  • the processing unit block of video decoding may be, for example, a coding unit, and in another example, a coding unit, a prediction unit, or a transform unit.
  • the coding unit may be split along the quad tree structure and / or binary tree structure from the largest coding unit.
  • the prediction unit and the transform unit may be further used in some cases, in which case the prediction block is a block derived or partitioned from the coding unit and may be a unit of sample prediction. At this point, the prediction unit may be divided into subblocks.
  • the transform unit may be divided along the quad tree structure from the coding unit, and may be a unit for deriving a transform coefficient or a unit for deriving a residual signal from the transform coefficient.
  • the entropy decoding unit 810 may parse the bitstream and output information necessary for video reconstruction or picture reconstruction. For example, the entropy decoding unit 810 decodes the information in the bitstream based on a coding method such as exponential Golomb coding, CAVLC, or CABAC, quantized values of syntax elements required for video reconstruction, and transform coefficients for residuals. Can be output.
  • a coding method such as exponential Golomb coding, CAVLC, or CABAC, quantized values of syntax elements required for video reconstruction, and transform coefficients for residuals. Can be output.
  • the CABAC entropy decoding method receives a bin corresponding to each syntax element in a bitstream, and decodes syntax element information and decoding information of neighboring and decoding target blocks or information of symbols / bins decoded in a previous step.
  • the context model may be determined using the context model, the probability of occurrence of a bin may be predicted according to the determined context model, and arithmetic decoding of the bin may be performed to generate a symbol corresponding to the value of each syntax element. have.
  • the CABAC entropy decoding method may update the context model by using the information of the decoded symbol / bin for the context model of the next symbol / bean after determining the context model.
  • the information related to the prediction among the information decoded by the entropy decoding unit 810 is provided to the prediction unit 830, and the residual value on which the entropy decoding is performed by the entropy decoding unit 810, that is, the quantized transform coefficients, is arranged in the rearrangement unit ( 821).
  • the reordering unit 821 may rearrange the quantized transform coefficients into a two-dimensional block.
  • the reordering unit 821 may perform reordering in response to coefficient scanning performed by the encoding apparatus. Although the reordering unit 821 is described in a separate configuration, the reordering unit 821 may be a part of the inverse quantization unit 822.
  • the inverse quantization unit 822 may output the transform coefficients by dequantizing the quantized transform coefficients based on the (inverse) quantization parameter.
  • information for deriving a quantization parameter may be signaled from the encoding apparatus.
  • the inverse transform unit 823 may inverse transform the transform coefficients to derive the residual samples.
  • the prediction unit 830 may perform prediction on the current block and generate a predicted block including prediction samples for the current block.
  • the unit of prediction performed by the prediction unit 830 may be a coding block, a transform block, or a prediction block.
  • the prediction unit 830 may determine whether to apply intra prediction or inter prediction based on the information about the prediction.
  • a unit for determining which of intra prediction and inter prediction is to be applied and a unit for generating a prediction sample may be different.
  • the unit for generating a prediction sample in inter prediction and intra prediction may also be different. For example, whether to apply inter prediction or intra prediction may be determined in units of CUs.
  • a prediction mode may be determined and a prediction sample may be generated in PU units
  • intra prediction a prediction mode may be determined in PU units and a prediction sample may be generated in TU units.
  • the prediction unit 830 may derive the prediction sample for the current block based on the neighbor reference samples in the current picture.
  • the prediction unit 830 may derive the prediction sample for the current block by applying the directional mode or the non-directional mode based on the neighbor reference samples of the current block.
  • the prediction mode to be applied to the current block may be determined using the intra prediction mode of the neighboring block.
  • the prediction unit 830 may derive the prediction sample for the current block based on the sample specified on the reference picture by the motion vector on the reference picture.
  • the prediction unit 830 may derive the prediction sample for the current block by applying any one of a skip mode, a merge mode, and an MVP mode.
  • motion information required for inter prediction of the current block provided by the video encoding apparatus for example, information about a motion vector, a reference picture index, and the like may be obtained or derived based on the prediction information.
  • the motion information of the neighboring block may be used as the motion information of the current block.
  • the neighboring block may include a spatial neighboring block and a temporal neighboring block.
  • the predictor 830 may construct a merge candidate list using motion information of available neighboring blocks, and may use information indicated by the merge index on the merge candidate list as a motion vector of the current block.
  • the merge index may be signaled from the encoding device.
  • the motion information may include a motion vector and a reference picture. When the motion information of the temporal neighboring block is used in the skip mode and the merge mode, the highest picture on the reference picture list may be used as the reference picture.
  • the difference (residual) between the prediction sample and the original sample is not transmitted.
  • the motion vector of the current block may be derived using the motion vector of the neighboring block as a motion vector predictor.
  • the neighboring block may include a spatial neighboring block and a temporal neighboring block.
  • a merge candidate list may be generated by using a motion vector of a reconstructed spatial neighboring block and / or a motion vector corresponding to a Col block, which is a temporal neighboring block.
  • the motion vector of the candidate block selected from the merge candidate list is used as the motion vector of the current block.
  • the information about the prediction may include a merge index indicating a candidate block having an optimal motion vector selected from candidate blocks included in the merge candidate list.
  • the prediction unit 830 may derive the motion vector of the current block by using the merge index.
  • a motion vector predictor candidate list may be generated using a motion vector of a reconstructed spatial neighboring block and / or a motion vector corresponding to a Col block, which is a temporal neighboring block.
  • the prediction information may include a prediction motion vector index indicating an optimal motion vector selected from the motion vector candidates included in the list.
  • the prediction unit 830 may select the predicted motion vector of the current block from the motion vector candidates included in the motion vector candidate list using the motion vector index.
  • the prediction unit of the encoding apparatus may obtain a motion vector difference (MVD) between the motion vector of the current block and the motion vector predictor, and may encode the output vector in a bitstream form. That is, MVD may be obtained by subtracting the motion vector predictor from the motion vector of the current block.
  • the prediction unit 830 may obtain a motion vector difference included in the information about the prediction, and derive the motion vector of the current block by adding the motion vector difference and the motion vector predictor.
  • the prediction unit may also obtain or derive a reference picture index or the like indicating a reference picture from the information about the prediction.
  • the adder 840 may reconstruct the current block or the current picture by adding the residual sample and the predictive sample.
  • the adder 840 may reconstruct the current picture by adding the residual sample and the predictive sample in block units. Since the residual is not transmitted when the skip mode is applied, the prediction sample may be a reconstruction sample.
  • the adder 840 has been described in a separate configuration, the adder 840 may be part of the predictor 830. On the other hand, the adder 840 may be called a restoration unit or a restoration block generation unit.
  • the filter unit 850 may apply deblocking filtering sample adaptive offset, and / or ALF to the reconstructed picture.
  • the sample adaptive offset may be applied in units of samples and may be applied after deblocking filtering.
  • ALF may be applied after deblocking filtering and / or sample adaptive offset.
  • the memory 860 may store reconstructed pictures (decoded pictures) or information necessary for decoding.
  • the reconstructed picture may be a reconstructed picture after the filtering process is completed by the filter unit 850.
  • the memory 860 may store pictures used for inter prediction.
  • pictures used for inter prediction may be designated by a reference picture set or a reference picture list.
  • the reconstructed picture can be used as a reference picture for another picture.
  • the memory 860 may output the reconstructed picture in the output order.
  • coded data is a network coding between a video coding layer (VCL) that handles coding processing of video / images itself and a subsystem that stores and transmits data of coded video / images. abstraction layer).
  • VCL video coding layer
  • the NAL unit which is a basic unit of the NAL, serves to map a coded image to a bit string of a sub-system such as a file format, a real-time transport protocol (RTP), a transport Strea (TS), etc. according to a predetermined standard.
  • a sub-system such as a file format, a real-time transport protocol (RTP), a transport Strea (TS), etc.
  • the VCL includes a parameter set (picture parameter set, sequence parameter set, video parameter set, etc.) corresponding to a header such as a sequence and a picture, and an SEI (in addition to the related procedures such as display) in the coding process of a video / image.
  • the supplemental enhancement information message is separated from the video / image information (slice data).
  • VCL including video / image information consists of slice data and slice header.
  • the NAL unit consists of two parts: a NAL unit header and a raw byte sequence payload (RBSP) generated in the VCL.
  • the NAL unit header includes information on the type of the corresponding NAL unit.
  • the NAL unit is divided into a VCL NAL unit and a non-VCL NAL unit according to the RBSP generated in the VCL.
  • the VCL NAL unit refers to a NAL unit containing information about a video / image
  • the non-VCL NAL unit represents a NAL unit containing information (parameter set or SEI message) necessary for coding a video / image.
  • the VCL NAL unit may be divided into various types according to the nature and type of pictures included in the corresponding NAL unit.
  • the present invention may relate to a method of transmitting 360 degree video and a method of receiving 360 degree video.
  • the method of transmitting / receiving 360-degree video according to the present invention may be performed by the above-described 360-degree video transmitting / receiving device or embodiments of the device, respectively.
  • each of the above-described embodiments of the 360-degree video transmission / reception apparatus, the transmission / reception method, and the respective internal / external elements thereof may be combined with each other.
  • the embodiments of the projection processing unit and the embodiments of the data encoder may be combined with each other to produce as many embodiments of the 360 degree video transmission apparatus as that case. Embodiments thus combined are also included in the scope of the present invention.
  • region-based independent processing can be supported for user viewpoint-based efficient processing.
  • an independent bitstream may be configured by extracting and / or processing a specific region of an image, and a file format for extracting and / or processing the specific region may be configured.
  • the original coordinate information of the extracted region may be signaled to support efficient image region decoding and rendering at the receiving end.
  • an area in which independent processing of an input image is supported may be called a sub-picture.
  • the input image may be split into subpicture sequences before encoding, and each subpicture sequence may cover a subset of a spatial area of 360 degree video content.
  • Each subpicture sequence may be independently encoded and output as a single-layer bitstream.
  • Each subpicture bitstream may be encapsulated in a file on an individual track and may be streamed.
  • the receiving apparatus may decode and render tracks covering the entire area, or may select and decode and render tracks related to a specific subpicture based on metadata about an orientation and a viewport.
  • FIG. 15 illustratively illustrates a motion constraint tile set (MCTS) extraction and delivery process as an example of region based independent processing.
  • MCTS motion constraint tile set
  • the transmission device encodes an input video.
  • the input image may correspond to the above-described projected picture or packed picture.
  • the transmitting device may encode the input image according to a general HEVC encoding procedure (1-1).
  • the input video may be encoded and output as one HEVC bitstream (HEVC bs) (1-1-a).
  • region-based independent encoding may be performed on the input image (1-2).
  • the MCTS streams for the plurality of regions may be output (1-2-b).
  • some regions may be extracted from the MCTS stream and output as one HEVC bitstream (1-2-a).
  • intact information for decoding and restoring a partial region is included in the bitstream, and thus a receiving end may completely restore the partial region based on one bitstream for the partial region.
  • the MCTS stream may be called an MCTS bitstream.
  • the transmitting device encapsulates the encoded HEVC bitstream according to (1-1-a) or (1-2-a) into one track in a file for storage and transmission (2-1), and then to the receiving device. Can be delivered (2-1-a).
  • the track may be represented by an identifier such as hvcX, hevX, or the like.
  • the transmitting device may encapsulate the encoded MCTS stream according to (1-2-b) into a file for storing and transmitting (2-2).
  • the transmitting device may encapsulate and deliver MCTSs for independent processing to individual tracks (2-2-b).
  • information such as a base track for processing the entire MCTS stream or an extractor track for extracting and processing some MCTS regions may be included in the file.
  • the individual tracks may be represented by identifiers such as hvcX, hevX, and the like.
  • the transmission device may use an extractor track to encapsulate and deliver a file including a track for one MCTS region (2-2-a). That is, the transmission device may extract and transmit only a track corresponding to one MCTS.
  • the track may be represented by an identifier such as hvt1.
  • the receiving device may receive a file according to (2-1-a) or (2-2-a), perform a decapsulation procedure (4-1), and derive an HEVC bitstream (4-1). -a). In this case, the receiving device may derive one bitstream by decapsulating one track in the received file.
  • the reception apparatus may receive a file according to (2-2-b), perform a decapsulation procedure (4-2), and derive an MCTS stream or one HEVC bitstream.
  • the receiving apparatus may extract the entire MCTS stream (4-2-b).
  • the receiving device may extract and decapsulate the corresponding MCTS track to generate one (HEVC) bitstream (4-2-a).
  • the receiving device may generate an output image by decoding one bitstream according to (4-1-a) or (4-2-a) (5-1).
  • decoding one bitstream according to (4-2-a) it may be an output image of a part of the MCTS region of the output image.
  • the receiving device may generate an output image by decoding the MCTS stream according to (4-2-b) (5-2).
  • FIG. 16 illustrates an example of an image frame for region based independent processing support.
  • the region supporting independent processing may be called a subpicture.
  • one input image may include two left and right MCTS regions.
  • the shape of the image frame encoded / decoded through the 1-2 to 5-2 procedure described above with reference to FIG. 15 may correspond to or be part of (A) to (D) of FIG. 16.
  • FIG. 16 shows an image frame in which both 1 and 2 regions exist and enable independent region / parallel processing.
  • (B) shows only one region, and represents an independent image frame having half horizontal resolution.
  • (C) shows only two regions, and represents an independent image frame having half horizontal resolution.
  • (D) shows an image frame in which both 1 and 2 regions exist and can be processed without supporting separate region independent / parallel processing.
  • bitstream configuration of 1-2-b and 4-2-b for deriving the image frame as described above may correspond to the following or a part thereof.
  • FIG. 17 shows an example of a bitstream configuration for region based independent processing support.
  • VSP represents VPS, SPS, and PPS
  • VSP1 represents a VSP for region 1
  • VSP2 represents a VSP for region 2
  • VSP12 represents a VSP for both regions 1 and 2.
  • VCL1 represents a VCL for region 1
  • VCL2 represents a VCL for region 2.
  • (a) represents Non-VCL NAL units (eg, VPS NAL unit, SPS NAL unit, PPS NAL unit, etc.) for image frames capable of independent / parallel processing of 1 and 2 regions.
  • (b) shows only one region and represents Non-VCL NAL units (eg, VPS NAL unit, SPS NAL unit, PPS NAL unit, etc.) for image frames having half resolution.
  • (c) shows only two regions and represents Non-VCL NAL units (eg, VPS NAL unit, SPS NAL unit, PPS NAL unit, etc.) for image frames having half resolution.
  • Non-VCL NAL units e.g., VPS NAL unit, SPS NAL unit, PPS NAL unit
  • VPS NAL unit e.g., VPS NAL unit, SPS NAL unit, PPS NAL unit
  • VCL NAL units of one region e.g., VPS NAL unit, SPS NAL unit, PPS NAL unit
  • VCL NAL units of two regions e.g., VPS NAL unit, SPS NAL unit, PPS NAL unit
  • a bitstream including NAL units of (a), (e), and (f) may be generated.
  • a bitstream including the NAL units of (b) and (e) may be generated.
  • a bitstream including the NAL units of (c) and (f) may be generated.
  • a bitstream including the NAL units of (d), (e), and (f) may be generated.
  • information indicating a location of a specific region on a picture (for example, mcts_sub_bitstream_region_in_original_picture_coordinate_info (), etc., to be described later) is included in a bitstream for image frames such as (B), (C), and (D) to be transmitted.
  • the information may make it possible to identify the position information in the original frame of the selected area.
  • the bitstream includes (c) and (f) NAL units)
  • the slice of the slice segment header Processes such as modifying the segment segment address during bitstream extraction may be involved.
  • the related file configuration may include the following cases or a part thereof.
  • a related file configuration when selectively encapsulating or coding a specific region, such as 2-2-a or 4-2-a described above with reference to FIG. 15, a related file configuration may include or partially include the following cases. It may include.
  • one track 10 includes the NAL units of (b), (e),
  • one track 20 includes the NAL units of (c), (f),
  • the related file configuration may include all of the following tracks or a combination of some tracks.
  • a base track 40 comprising (a)
  • an extractor track 50 comprising (d) and having extractors (ex. Ext1, ext2) for accessing (e) and (f)
  • an extractor track 60 comprising (b) and having an extractor for accessing (e)
  • an extractor track 70 comprising (c) and having an extractor for accessing (f)
  • tile track 80 comprising (e)
  • tile track 90 comprising (f)
  • the information indicating the position of the specific region on the picture is included in the above-described tracks 10, 20, 30, 50, 60, 70, etc. in the form of a box such as RegionOriginalCoordninateBox, which will be described later.
  • Location information at can be identified.
  • the region may be called a subpicture.
  • the service provider may configure all of the above-described tracks, and may transmit only a part of the tracks.
  • 19 illustrates a RegionOriginalCoordninateBox according to an embodiment of the present invention.
  • 20 exemplarily shows an area indicated by corresponding information in an original picture.
  • RegionOriginalCoordninateBox is information indicating the size and / or location of a region (subpicture, or MCTS) capable of region-based independent processing according to the present invention.
  • the RegionOriginalCoordninateBox may be used to identify where the region exists on the coordinates of the entire visual content. For example, packed frames (packed pictures) or projected frames (projected pictures) for full 360-degree video can be stored / transmitted into multiple discrete areas in the form of independent video streams for efficient user-point-based processing.
  • One track may correspond to a rectangular area composed of one or several tiles.
  • the separate region may correspond to HEVC bitstreams extracted from the HEVC MCTS bitstream.
  • the RegionOriginalCoordninateBox exists under a visual sample entry of a track in which an individual region is stored / transmitted and may describe coordinate information of a corresponding region.
  • the RegionOriginalCoordninateBox may be hierarchically beneath other boxes such as a scheme information box other than the visual sample entry.
  • RegionOriginalCoordninateBox may include original_picture_width field, original_picture_height field, region_horizontal_left_offset field, region_vertical_top_offset field, region_width field, region_height field. Some of the fields may be omitted. For example, the original_picture_width field, the original_picture_height field, etc. may be omitted when the size of the original picture is predefined or already obtained through information such as another box.
  • the original_picture_width field represents the horizontal resolution (width) of the original picture (ie, a packed frame or a projected frame) to which the region (subpicture or tile) belongs.
  • the original_picture_height field represents the vertical resolution (height) of the original picture (ie, a packed frame or a projected frame) to which the region (subpicture or tile) belongs.
  • region_horizontal_left_offset field represents the horizontal coordinate of the left end of the region corresponding to the original picture coordinate. For example, the field may indicate a value of horizontal coordinates of the left end of the region based on the coordinates of the upper left end of the original picture.
  • the region_vertical_top_offset field represents the vertical coordinate of the left end of the region corresponding to the original picture coordinate.
  • the field may indicate a value of the vertical coordinate of the upper end of the region based on the coordinates of the upper left end of the original picture.
  • the region_width field represents the horizontal resolution (width) of the region.
  • the region_height field represents the vertical resolution (height) of the region. Based on the above-described fields, the corresponding area may be derived as shown in FIG. 20 from the original picture.
  • RegionToTrackBox may be used.
  • FIG. 21 illustrates a RegionToTrackBox according to an embodiment of the present invention.
  • the RegionToTrackBox can allow you to identify the track associated with that region.
  • the box (box-type information) may be sent for each track, or only for a representative track.
  • RegionToTrackBox can be stored under the 'schi' box along with 360 degree video information such as projection and packing information.
  • the horizontal resolution and the vertical resolution of the original picture may be identified by width and width values (of the original picture) present in a track header box or a visual sample entry.
  • the track carrying the box and the track where individual regions are stored / transmitted may be identified by a new reference type such as 'ovrf' (omnidirectional video reference) in a track reference box. have.
  • the box may be hierarchically beneath other boxes such as visual sample entries other than the Scheme Information box.
  • RegionToTrackBox may include a num_regions field, and may include a region_horizontal_left_offset field, region_vertical_top_offset field, region_width field, region_width field, and track_ID field for each region. In some cases, some of the fields may be omitted.
  • the num_region field represents the number of regions in the original picture.
  • the region_horizontal_left_offset field represents the horizontal coordinate of the left end of the region corresponding to the original picture coordinate. For example, the field may indicate a value of horizontal coordinates of the left end of the region based on the coordinates of the upper left end of the original picture.
  • the region_vertical_top_offset field represents the vertical coordinate of the left end of the region corresponding to the original picture coordinate. For example, the field may indicate a value of the vertical coordinate of the upper end of the region based on the coordinates of the upper left end of the original picture.
  • the region_width field represents the horizontal resolution (width) of the region.
  • the region_height field represents the vertical resolution (height) of the region.
  • the Track_ID field represents an ID of a track in which data corresponding to a region is stored / transmitted.
  • the following information may be included in the SEI message.
  • the num_sub_bs_region_coordinate_info_minus1 [i] field indicates the number ⁇ 1 of mcts_sub_bitstream_region_in_original_picture_coordinate_info corresponding to extraction information.
  • the sub_bs_region_coordinate_info_data_length ['i'] ['j'] field indicates the number of bytes of individual mcts_sub_bitstream_region_in_original_picture_coordinate_info included.
  • the num_sub_bs_region_coordinate_info_minus1 ['i'] field and the sub_bs_region_coordinate_info_data_length ['i'] ['j'] field may be coded based on ue (v) indicating unsigned integer 0-th Exp-Golomb coding.
  • (v) may indicate that the bits used to code corresponding information are variable.
  • the sub_bs_region_coordinate_info_data_bytes ['i'] ['j'] ['k'] field indicates bytes of individual mcts_sub_bitstream_region_in_original_picture_coordinate_info included.
  • the sub_bs_region_coordinate_info_data_bytes ['i'] ['j'] ['k'] field may be coded based on u (8) indicating unsigned integer zero-order coding using 8 bits.
  • mcts_sub_bitstream_region_in_original_picture_coordinate_info may be hierarchically included in the SEI message.
  • an original_picture_width_in_luma_sample field indicates a horizontal resolution of an extracted MCTS sub-bitstream region before extraction (ie, a packed frame or a projected frame).
  • the original_picture_height_in_luma_sample field represents the vertical resolution of an extracted MCTS sub-bitstream region before extraction (ie, a packed frame or a projected frame).
  • the sub_bitstream_region_horizontal_left_offset_in_luma_sample field represents the left end abscissa of the region corresponding to the original picture coordinate.
  • the sub_bitstream_region_vertical_top_offset_in_luma_sample field represents vertical coordinates of the upper end of the region corresponding to the original picture coordinates.
  • the sub_bitstream_region_width_in_luma_sample field represents the horizontal resolution of the corresponding region.
  • the sub_bitstream_region_height_in_luma_sample field represents the vertical resolution of the corresponding region.
  • the following information may be used to extract data for a specific MCTS region.
  • FIG. 24 illustrates MCTS region related information in a file including a plurality of MCTS bitstreams according to an embodiment of the present invention.
  • the extracted MCTS bitstreams may be defined as one group through sample grouping, and the VPS, SPS, and PPS associated with the corresponding MCTS described above may be included in the nalUnit field of FIG. 24.
  • the NAL_unit_type field may indicate one of the VPS, the SPS, and the PPS as a type of the corresponding NAL unit, and the NAL unit (s) of the indicated type may be included in the nalUnit field.
  • the above-described independent processing region, MCTS region, etc. are different in their representation, but may be used in the same meaning, and may be referred to as a sub-picture.
  • Omni-directional 360 degree video can be stored and delivered through a file consisting of subpicture tracks, which can be used for user viewpoint or viewport dependent processing.
  • the subpictures can be a subset of the spatial area of the original picture, and each subpicture can generally be stored on a separate track.
  • Viewport based processing may be performed based on the following flow, for example.
  • FIG. 25 illustrates viewport based processing according to an embodiment of the present invention.
  • the receiving apparatus performs head and / or eye tracking (S2010).
  • the receiving device derives viewport information through head and / or eye tracking.
  • the receiving device performs file / segment decapsulation for the received file (S2020).
  • the receiving device may grasp areas (viewport areas) corresponding to the current viewport through coordinate conversion (S2021).
  • tracks containing subpictures covering the viewport areas may be selected and extracted.
  • the receiving device decodes (sub) bitstream (s) for the selected track (s) (S2030).
  • the receiving device may decode / restore subpictures through the decoding. In this case, unlike the conventional decoding procedure in which decoding is performed on a unit of the original picture, the receiving device may decode only the subpictures, not the entire picture.
  • the receiving device maps the decoded subpicture (s) to a rendering space through coordinate conversion (S2040). Since it performs decoding on subpicture (s) rather than the entire picture, it can map to the rendering space based on the information that the subpicture corresponds to which position of the original picture, and can perform viewport-based processing. .
  • the receiving device may generate an image (viewport image) associated with the corresponding viewport and display the image to the user (S2050).
  • a coordinate conversion procedure for the subpictures may be necessary for the rendering procedure. This is a procedure that was not necessary in the conventional 360 degree video processing procedure.
  • the subpicture since decoding is performed on the subpicture (s), not the entire picture, the subpicture can be mapped to the rendering space based on the information that the subpicture corresponds to which position of the original picture, and the viewport-based processing is performed. can do.
  • the decoded pictures may need to be aligned for proper rendering.
  • Packed frames can be rearranged into projected frames (if applied to per-region packing processes), and projected frames can be aligned according to a projection structure for rendering.
  • the coverage information may include information indicating the position (position and size) of the area according to the present invention described above.
  • one subpicture may be configured to be spaced apart on the packed frame / projected frame.
  • regions that are separated from each other on the 2D space in one subpicture may be called subpicture regions.
  • the ERP Equirectangular Projection
  • the left and right ends of the packed frame / projected frame may stick together on the spherical surface that is actually rendered.
  • subpicture regions spaced apart from each other on the packed frame / projected frame may be configured as one subpicture, and the related coverage information and the subpicture configuration may be as follows.
  • FIG. 26 illustrates coverage information according to an embodiment of the present invention
  • FIG. 27 illustrates a subpicture configuration according to an embodiment of the present invention.
  • the subpicture configuration of FIG. 27 may be derived based on coverage information shown in FIG. 26.
  • an ori_pic_width field and an ori_pic_height field indicate a width and a height of all original pictures constituting subpictures, respectively.
  • the width and height of the subpicture can be represented by the width and height within the visual sample entry.
  • the sub_pic_reg_flag field indicates whether a subpicture region exists. When the value of the sub_pic_reg_flag field is 0, it indicates that the subpicture is completely aligned on the original picture. When the value of the sub_pic_reg_flag field is 1, the subpicture may be divided into subpicture regions, and each subpicture region may be aligned on a frame (original picture). As shown in FIG.
  • the sub_pic_on_ori_pic_top field and the sub_pic_on_ori_pic_left field indicate a top sample row and a left-most sample column of the sub picture on the original picture, respectively.
  • the ranges of the values of the sub_pic_on_ori_pic_top field and the sub_pic_on_ori_pic_left field may be inclusive from 0 indicating the top-left corner of the original picture, and the values of the ori_pic_height field and the values of the ori_pic_width field, respectively.
  • the num_sub_pic_regions field represents the number of subpicture regions constituting the subpicture.
  • the sub_pic_reg_top [i] field and the sub_pic_reg_left [i] field indicate the topmost sample row and leftmost sample column of the corresponding subpicture region on the subpicture, respectively. Through these fields, correlations (position order and placement) between a plurality of subpicture regions within one subpicture may be derived.
  • the range of values of the sub_pic_reg_top [i] field and the sub_pic_reg_left [i] field may be inclusive from 0 indicating the upper left corner of the subpicture, and up to the width and height of the subpicture.
  • the width and height of the subpicture may be derived from a visual sample entry.
  • the sub_pic_reg_width [i] field and the sub_pic_reg_height [i] field indicate the width and height of the corresponding subpicture region, respectively.
  • the sum of the values of the sub_pic_reg_width [i] field (i is from 0 to the value ⁇ 1 of the num_sub_pic_regions field) may be equal to the width of the subpicture.
  • the sum of the values of the sub_pic_reg_height [i] field i is from 0 to the value ⁇ 1 of the num_sub_pic_regions field) may be equal to the height of the subpicture.
  • the sub_pic_reg_on_ori_pic_top [i] field and the sub_pic_reg_on_ori_pic_left [i] field indicate the topmost sample row and leftmost sample column of the corresponding subpicture region on the original picture, respectively.
  • the range of values of the sub_pic_reg_on_ori_pic_top [i] field and the sub_pic_reg_on_ori_pic_left [i] field may be inclusive from 0 indicating the upper left corner of the projected frame, and up to the value of the ori_pic_height field and the value of the ori_pic_width field.
  • one subpicture includes a plurality of subpicture regions, and according to the present invention, the subpictures may overlap each other. Assuming that each subpicture bitstream is exclusively decoded by one video decoder at a time, overlapped subpictures can be used to limit the number of video decoders.
  • FIG. 28 illustrates overlapped subpictures according to an embodiment of the present invention.
  • FIG. 28 illustrates a case where source content (eg, an original picture) is divided into seven rectangular regions, and the regions are grouped into seven subpictures.
  • source content eg, an original picture
  • subpicture 1 is composed of regions (subpicture regions) A and B
  • subpicture 2 is composed of regions B and C
  • subpicture 3 is composed of regions C and D
  • subpicture 5 is composed of regions E and A
  • subpicture 6 is composed of region F
  • subpicture 7 is composed of region G.
  • One SubpictureCompositionBox can describe one rectangular area.
  • TrackGroupBox can have multiple SubpictureCompositionBox.
  • the order of the multiple SubpictureCompositionBoxes may indicate the position of the rectangular regions within the subpicture. In this case, the order may be a raster scan order.
  • a TrackGroupTypeBox whose track_group_type is 'spco' may indicate that the track belongs to a configuration of tracks that can be spatially aligned to obtain suitable pictures for presentation.
  • Visual tracks mapped to the grouping ie, visual tracks having the same track_group_id value in a TrackGroupTypeBox whose track_group_type is 'spco'
  • Each individual visual track mapped to that grouping may or may not be sufficient for the presentation.
  • the boxes may appear in the raster scan order of the rectangular regions on a subpicture within the TrackGroupBox.
  • a CompositionRestrictionBox can be used to indicate that the visual track is not enough for a presentation alone.
  • a picture suitable for presentation can be constructed by spatially aligning the time-parallel samples of all tracks of the same subpicture constituent track group as indicated by the syntax elements of the track group.
  • the region_x field indicates a horizontal position of an upper left corner of a rectangular region of samples of a corresponding track on a composed picture in luma sample units.
  • the range of the value of the region_x field may range from 0 to the value ⁇ 1 (minus 1) of the composition_width field.
  • the region_y field indicates the vertical position of the upper left corner of the rectangular area of the samples of the corresponding track on the configured picture in luma sample units.
  • the range of the value of the region_y field may be from 0 to a value of ⁇ 1 of the composition_height field.
  • the region_width field indicates a width of a rectangular area of samples of the corresponding track on the configured picture in luma sample units.
  • the range of the value of the region_width field may range from 1 to the value of the composition_width field minus the value of the region_x field.
  • the region_height field indicates the height of the rectangular region of the samples of the corresponding track on the configured picture in luma sample units.
  • the range of the value of the region_height field may range from 1 to the value of the composition_height field-(minus) the value of the region_y field.
  • the composition_width field represents the width of a composed picture in luma sample units.
  • the value of the composition_width field may be greater than or equal to the value of the region_x field + the value of the (plus) region_width field.
  • the composition_height field represents the height of the constructed picture in luma sample units.
  • the value of the composition_height field may be greater than or equal to the value of the region_y field + the value of the region_height field.
  • the constructed picture may correspond to the above-described original picture, packed picture, or
  • the following methods may be used for identification of a subpicture track including a multi-square area mapped in a configured picture.
  • the information for identifying the rectangular area may be signaled through information about a guard band.
  • the 2D image When continuous 360 degree video data in 3D space is mapped to a region of a 2D image, the 2D image may be coded for each region of the 2D image and transmitted to a receiving side.
  • a problem may arise in that boundaries between regions appear in the three-dimensional space due to differences in coding processing of each region.
  • the problem in which boundaries between the regions appear in the three-dimensional space may be called a boundary error.
  • the boundary error may reduce a user's immersion in virtual reality, and a guard band may be used to prevent such a problem.
  • the guard band is not directly rendered, but may represent an area used to enhance the rendered portion of the associated area or to avoid or mitigate visual artifacts such as seams.
  • the guard band may be used when a region-specific packing process is applied.
  • the multiple rectangular areas can be identified using RegionWisePackingBox.
  • 30 shows a hierarchical structure of RegionWisePackingBox.
  • the guard_band_flag [i] field having a value of 0 indicates that the i-th region does not have a guard band.
  • a guard_band_flag [i] field of value 1 indicates that region i has a guard band.
  • the packing_type [i] field represents the type of packing for each region.
  • a packing_type [i] field of value 0 indicates rectangular packing per region. The remaining values may be reserved.
  • the left_gb_width [i] field represents the width of the guard band on the left side of region i.
  • the left_gb_width [i] field may indicate the width of the guard band in units of two luma samples.
  • the right_gb_width [i] field represents the width of the guard band on the right side of region i.
  • the right_gb_width [i] field may indicate the width of the guard band in units of a double luma sample.
  • the top_gb_width [i] field represents the width of the guard band on the upper side of region i.
  • the top_gb_width [i] field may indicate the width of the guard band in units of two luma samples.
  • the bottom_gb_width [i] field represents the width of the guard band at the bottom of region i.
  • the bottom_gb_width [i] field may indicate the width of the guard band in units of a double luma sample.
  • guard_band_flag [i] When the value of guard_band_flag [i] is 1, the value of the left_gb_width [i] field, the right_gb_width [i] field, the top_gb_width [i] field, or the bottom_gb_width [i] field is greater than zero.
  • a gb_not_used_for_pred_flag [i] field of value 0 indicates that guard bands are available for inter prediction. That is, when the value of the gb_not_used_for_pred_flag [i] field is 0, the guard bands may or may not be used for inter prediction.
  • a gb_not_used_for_pred_flag [i] of value 1 indicates that sample values of guard bands are not used in the inter prediction procedure. If the value of the gb_not_used_for_pred_flag [i] field is 1, even if decoded pictures (decoded packed pictures) were used as references for inter prediction of pictures to be decoded later Sample values in guard bands on pictures can be rewritten or modified. For example, the content of a region can be seamlessly extended to its guard band, using decoded and reprojected samples of another region.
  • the gb_type [i] field may indicate the type of guard bands in region i as follows.
  • a gb_type [i] field of value 0 indicates that the contents of the corresponding guard bands are unspeficied in relation to the contents of the corresponding region (s).
  • the value of the gb_not_used_for_pred_flag field is 0, the value of the gb_type field cannot be 0.
  • a gb_type [i] field of value 1 indicates that the contents of the guard bands are sufficient for interpolation of subpixel values within an area (and within one pixel outside the area boundary).
  • a gb_type [i] field of value 1 may be used when boundary samples of the region are copied horizontally or vertically to the guard band.
  • a gb_type [i] field with a value of 2 indicates that the contents of the guard bands are gradually based on the quality of the actual image content, and the gradually changing quality is gradually changed from the picture quality of the corresponding area to the picture quality of the adjacent area on the spherical plane. To change.
  • a value of gb_type [i] of 3 indicates that the contents of the guard bands represent the actual image contents based on the picture quality of the corresponding region.
  • one track when one track includes rectangular regions mapped to a plurality of rectangular regions in a configured picture, some regions are region-specific packing regions identified by RectRegionPacking (i), and other regions are the guard_band_flag [i].
  • Guard band area identified based on some or all of the field, left_gb_width [i] field, right_gb_width [i] field, top_gb_height [i] field, bottom_gb_height [o] field, gb_not_used_for_pred_flag [i] field, or gb_type [i] field Can be identified.
  • region E may be identified as a region-specific packing region, and region A may be identified as a guard band region located to the right of the region E.
  • the guard band region The width of may be identified based on the right_gb_width [i] field.
  • region A may be identified by region-specific packing region, and region E may be identified by a guard band region located on the left side, in which case the width of the guard band region may be identified based on the left_gb_width [i] field.
  • the type of the guard band region may be indicated through the gb_type [i] field, and the rectangular region may be identified as an area having the same quality as the same neighboring region through the above-described '3' value.
  • the rectangular region may be identified through the aforementioned '2' value.
  • the rectangular area may be identified through values '4' to '7' of the gb_type [i] field as follows.
  • a gb_type [i] field having a value of 4 may indicate that the contents of the rectangular region are actual image contents existing adjacent to the corresponding region on the spherical surface and gradually change from the region-specific packing region associated with the quality.
  • a gb_type [i] field of value 5 may indicate that the content is actual image content existing adjacent to the corresponding area on the spherical surface and that the quality is the same as the quality of the region-specific packing area.
  • a gb_type [i] field having a value of 6 is actual image content existing adjacent to the corresponding area on the projected picture of the rectangular area and may indicate that the quality gradually changes from the regional packing area.
  • a gb_type [i] field having a value of 7 may represent that the content of the rectangular area is the actual image content existing adjacent to the corresponding area on the projected picture and that the quality is the same as the quality of the region-specific packing area associated with the quality.
  • information for identifying the rectangular area may be signaled using a SubPicturecompositionBox.
  • the multi-square area may be divided into a region existing in the configured picture region and a region existing outside the configured picture region based on a coordinate value.
  • the multi-square area may be represented by clipping an area existing outside the configured picture area and placing it at opposite corners.
  • the value obtained by subtracting the composition_width field value from x is used, and y, the vertical coordinate of the rectangular region, is equal to the composition_height field. If it is equal to or greater than the value, a value obtained by subtracting the value of the composition_height field from y may be used.
  • the ranges of the track_width field, track_height field, composition_width field, and composition_height field of the SubPictureCompositionBox described above with reference to FIG. 28 may be modified as follows.
  • the range of the value of the region_width field may be from 1 to the value of the composition_width field.
  • the range of the value of the region_height field may be from 1 to the value of the composition_height field.
  • the value of the composition_width field may be greater than or equal to the value +1 (plus 1) of the region_x field.
  • the value of the composition_height field may be greater than or equal to the value +1 (plus 1) of the region_y field.
  • FIG. 31 schematically illustrates a process of transmitting and receiving 360-degree video using a subpicture configuration according to the present invention.
  • the transmission apparatus acquires a 360 degree image and maps the obtained image to one 2D picture through stitching and projection (S2600).
  • the region-specific packing process may be optionally included.
  • the 360 degree image may be an image photographed using at least one 360 degree camera, or may be an image generated or synthesized through an image processing apparatus such as a computer.
  • the 2D picture may include the original picture, the projected picture / packed picture, and the configured picture.
  • the transmission device divides the 2D picture into a plurality of subpictures (S2610).
  • the transmission device may generate and / or use subpicture configuration information.
  • the transmission device may encode at least one of the plurality of subpictures (S2520).
  • the transmitting device may select and encode some of the plurality of subpictures, or the transmitting device may encode all of the plurality of subpictures.
  • Each of the plurality of subpictures may be independently coded.
  • the transmitting device configures a file using the encoded subpicture stream (S2630).
  • the subpicture stream can be stored in the form of individual tracks.
  • the subpicture configuration information may be included in the corresponding subpicture track through at least one of the above-described methods.
  • the transmitting device or the receiving device may select a sub picture (S2640).
  • the transmission device may select a subpicture using the viewport information of the user and feedback related to the interaction, and deliver the related track.
  • the transmitting apparatus may transmit a plurality of subpicture tracks, and the receiving apparatus may select at least one subpicture (subpicture track) using viewport information and interaction related feedback information of the user.
  • the receiving device analyzes the file, obtains the subpicture bitstream and the subpicture configuration information (S2650), and decodes the subpicture bitstream (S2660).
  • the receiving device maps the decoded subpicture to the configured picture (original picture) region based on the subpicture configuration information (S2670).
  • the receiving device renders the mapped configured picture (S2680).
  • the receiving device may perform a rectilinear projection process that maps a portion of the spherical surface corresponding to the viewport of the user to the viewport plane.
  • the subpicture may include regions that are not spatially adjacent to the 2D configured picture as the subpicture region.
  • an area corresponding to the position (track_x, track_y) and the size (width, height) given by the subpicture configuration information is extracted with respect to the pixels (x, y) constituting the composed picture.
  • the subpicture can be derived, and in this case, the positions (i, j) of the pixels in the subpicture can be derived as shown in Table 1 below.
  • the position (x, y) of the pixel in the configured picture mapped to the position (i, j) of the pixel constituting the subpicture may be derived as shown in Table 2 below.
  • the position (i, j) of the pixel in the sub picture may be mapped to the position (x, y) of the pixel constituting the composed picture.
  • (x, y) When (x, y) is out of the boundary of the configured picture, it may be connected to the left side of the configured picture when it is deviated to the right as shown in FIG. 32, and may be connected to the top of the configured picture when it is deviated downward.
  • FIG. 33 schematically shows a 360 degree video data processing method by the 360 degree video transmission apparatus according to the present invention.
  • the method disclosed in FIG. 33 may be performed by a 360 degree video transmission device.
  • the 360-degree video transmission device acquires 360-degree video data (S2800).
  • the 360 degree image may be an image photographed using at least one 360 degree camera, or may be an image generated or synthesized through an image processing apparatus such as a computer.
  • the 360-degree video transmission device processes the 360-degree video data to obtain a 2D picture (S2810).
  • the obtained image may be mapped to one 2D picture through stitching and projection.
  • the above-described region-specific packing process may be optionally performed.
  • the 2D picture may include the above-described original picture, projected picture / packed picture, configured picture, and the like.
  • the 360-degree video transmission device divides the 2D picture to derive subpictures (S2820).
  • the subpictures can be processed independently.
  • the 360 degree video transmission device may generate and / or use subpicture configuration information.
  • the subpicture configuration information may be included in metadata.
  • the subpicture may include a plurality of subpicture regions, and the subpicture regions may not be spatially adjacent to each other on the 2D picture.
  • the subpicture regions may be spatially adjacent to each other on the 2D picture and spatially adjacent to each other on the 3D space (spherical surface) to be presented or rendered.
  • Meta data about the 360 degree video data is generated (S2830).
  • the metadata may include various pieces of information proposed by the present invention.
  • the metadata may include location information of a subpicture on the 2D picture.
  • the location information of the subpicture is information indicating a left end horizontal coordinate of the subpicture, based on the coordinates of the packed picture, the subpicture Information indicating the upper end vertical coordinate of the picture, information indicating the width of the subpicture, and information indicating the height of the subpicture may be included.
  • the location information of the subpicture may further include information representing the width of the packed picture and information representing the height of the packed picture.
  • the location information of the subpicture may be included in RegionOriginalCoordinateBox included in metadata.
  • At least one subpicture track may be generated through S2850 described later, and the metadata may include position information of the subpicture and track ID information associated with the subpicture. For example, location information of the subpicture and track ID information associated with the subpicture may be included in a RegionToTrackBox included in the metadata.
  • a file including a plurality of subpicture tracks may be generated through the processing for storing or transmitting, and the metadata may be a video parameter set (VPS) associated with a subpicture as shown in FIG. 24. It may include a sequence parameter set (SPS) or a picture parameter set (PPS).
  • SPS sequence parameter set
  • PPS picture parameter set
  • the location information of the subpicture may be included in an SEI message, wherein the SEI message is information indicating the left end horizontal coordinate of the subpicture, based on the coordinates of the 2D picture, in luma sample units, and the subpicture. May include information indicating an upper end vertical coordinate of the information, information indicating a width of the subpicture, and information indicating a height of the subpicture. As shown in FIG. 22, the SEI message may further include information indicating the number of bytes of location information of the subpicture.
  • the subpicture may include a plurality of subpicture regions.
  • the metadata may include subpicture region information
  • the subpicture region information may include location information of the subpicture regions and association information between the subpicture regions.
  • the subpicture regions may be indexed in a raster scan order.
  • the association information may include at least one of information representing an uppermost row of each subpicture region on the subpicture or information representing an assumed left column of each subpicture region on the subpicture. have.
  • the location information of the subpicture is information indicating a left end abscissa of the subpicture, information indicating an upper end ordinate of the subpicture, information indicating a width of the subpicture, and the subpicture based on the coordinates of the 2D picture. It may include information indicating the height of the picture, the value range of the information indicating the width of the subpicture is from 1 to the width of the 2D picture, the value range of the information indicating the height of the subpicture is from 1 to the 2D Up to the height of the picture.
  • the subpicture may include the plurality of subpicture regions, and the upper end length of the subpicture may be greater.
  • the subpicture may include the plurality of subpicture regions.
  • the 360-degree video transmission device encodes at least one of the subpictures (S2840).
  • the 360-degree video transmission device may select and encode some of the plurality of subpictures, or may encode all of the plurality of subpictures.
  • Each of the plurality of subpictures may be independently coded.
  • the 360-degree video transmission device performs processing for storing or transmitting the encoded at least one subpicture and the metadata (S2850).
  • the 360-degree video transmission device may encapsulate the encoded at least one subpicture and / or the metadata in the form of a file or the like.
  • the 360-degree video transmission device may encapsulate the encoded at least one subpicture and / or the metadata into a file format such as ISOBMFF, CFF, or other DASH segments in order to store or transmit the metadata.
  • the 360-degree video transmission device may include the metadata in a file format.
  • the metadata may be included in boxes of various levels in the ISOBMFF file format or as data in separate tracks in the file.
  • the 360-degree video transmission device may apply processing for transmission to the encapsulated file according to the file format.
  • the 360 degree video transmission device can process files according to any transmission protocol.
  • the processing for transmission may include processing for delivery through a broadcasting network, or processing for delivery through a communication network such as broadband.
  • the 360-degree video transmission device may apply a process for transmission to the metadata.
  • the 360-degree video transmission device may transmit the 360-degree video data and the meta data transmitted through a broadcast network and / or broadband.
  • FIG. 34 schematically illustrates a 360 degree video data processing method by the 360 degree video receiving apparatus according to the present invention.
  • the method disclosed in FIG. 34 may be performed by a 360 degree video receiving apparatus.
  • the 360-degree video receiving apparatus receives a signal including tracks and metadata for a subpicture (S2900).
  • the 360 degree video receiving apparatus may receive image information and the metadata for the sub picture signaled from the 360 degree video transmitting apparatus through a broadcasting network.
  • the video receiving apparatus may receive image information and the metadata for the subpicture through a communication network such as broadband or a storage medium.
  • the subpicture may be located on the packed picture or the projected picture.
  • the 360-degree video receiving apparatus processes the signal to obtain image information and metadata about the subpicture (S2910).
  • the 360-degree video receiving apparatus may perform processing according to a transmission protocol on the received image information and the metadata of the subpicture.
  • the 360-degree video receiving apparatus may perform a reverse process of the above-described processing for transmitting the 360-degree video transmitting apparatus.
  • the received signal may include a track for at least one subpicture.
  • the 360-degree video receiving apparatus may select some (including one) of tracks for the plurality of subpictures. In this case, viewport information may be used.
  • the subpicture may include a plurality of subpicture regions, and the subpicture regions may not be spatially adjacent to each other on the 2D picture.
  • the subpicture regions may be spatially adjacent to each other on the 2D picture and spatially adjacent to each other on the 3D space (spherical surface) to be presented or rendered.
  • the metadata may include various pieces of information proposed by the present invention.
  • the metadata may include location information of a subpicture on the 2D picture.
  • the location information of the subpicture is information indicating a left end horizontal coordinate of the subpicture, based on the coordinates of the packed picture, the subpicture Information indicating the upper end vertical coordinate of the picture, information indicating the width of the subpicture, and information indicating the height of the subpicture may be included.
  • the location information of the subpicture may further include information representing the width of the packed picture and information representing the height of the packed picture.
  • the location information of the subpicture may be included in RegionOriginalCoordinateBox included in metadata.
  • the metadata may include location information of the subpicture and track ID information associated with the subpicture. For example, location information of the subpicture and track ID information associated with the subpicture may be included in a RegionToTrackBox included in the metadata.
  • a file including a plurality of subpicture tracks may be generated through the processing for storing or transmitting, and the metadata may be a video parameter set (VPS) associated with a subpicture as shown in FIG. 24. It may include a sequence parameter set (SPS) or a picture parameter set (PPS).
  • SPS sequence parameter set
  • PPS picture parameter set
  • the location information of the subpicture may be included in an SEI message, wherein the SEI message is information indicating the left end horizontal coordinate of the subpicture, based on the coordinates of the 2D picture, in luma sample units, and the subpicture. May include information indicating an upper end vertical coordinate of the information, information indicating a width of the subpicture, and information indicating a height of the subpicture. As shown in FIG. 22, the SEI message may further include information indicating the number of bytes of location information of the subpicture.
  • the subpicture may include a plurality of subpicture regions.
  • the metadata may include subpicture region information
  • the subpicture region information may include location information of the subpicture regions and association information between the subpicture regions.
  • the subpicture regions may be indexed in a raster scan order.
  • the association information may include at least one of information representing an uppermost row of each subpicture region on the subpicture or information representing an assumed left column of each subpicture region on the subpicture. have.
  • the location information of the subpicture is information indicating a left end abscissa of the subpicture, information indicating an upper end ordinate of the subpicture, information indicating a width of the subpicture, and the subpicture based on the coordinates of the 2D picture. It may include information indicating the height of the picture, the value range of the information indicating the width of the subpicture is from 1 to the width of the 2D picture, the value range of the information indicating the height of the subpicture is from 1 to the 2D Up to the height of the picture.
  • the subpicture may include the plurality of subpicture regions, and the upper end length of the subpicture may be greater.
  • the subpicture may include the plurality of subpicture regions.
  • the 360-degree video receiving apparatus decodes the subpicture based on the image information about the subpicture (S2920).
  • the 360-degree video receiving apparatus may independently decode the subpicture based on the image information about the subpicture. Also, even when image information about a plurality of subpictures is input, the 360-degree video receiving apparatus may decode only a specific subpicture based on the obtained viewport-related metadata.
  • the 360-degree video receiving apparatus processes the decoded subpicture based on the metadata and renders it in 3D space (S2930).
  • the 360 degree video receiving apparatus may map the decoded subpicture to 3D space based on the metadata.
  • the 360-degree video receiving apparatus may perform coordinate conversion based on the location information of the subpicture and / or subpicture region according to the present invention to map and render the decoded subpicture into 3D space.
  • the 360-degree video transmission apparatus may include the data input unit, the stitcher, the signaling processor, the projection processor, the data encoder, the transmission processor, and / or the transmitter. Each of the internal components is as described above.
  • the 360-degree video transmission apparatus and its internal components according to an embodiment of the present invention may perform the above-described embodiments of the method of transmitting the 360-degree video of the present invention.
  • the 360-degree video receiving apparatus may include the above-described receiver, reception processor, data decoder, signaling parser, re-projection processor, and / or renderer. Each of the internal components is as described above.
  • the 360-degree video receiving apparatus and its internal components according to an embodiment of the present invention may perform the above-described embodiments of the method of receiving the 360-degree video of the present invention.
  • the internal components of the apparatus described above may be processors for executing successive procedures stored in a memory, or hardware components configured with other hardware. They can be located inside or outside the device.
  • the above-described modules may be omitted or replaced by other modules performing similar / same operations according to the embodiment.
  • 35 illustrates a 360 video transmission apparatus according to an aspect of the present invention.
  • the invention may relate to a 360 video transmission device.
  • the 360 video transmission apparatus may process 360 video data, generate signaling information on the 360 video data, and transmit the same to the receiver.
  • the 360 video transmission apparatus stitches 360 video, projects and processes the picture, encodes a picture, generates signaling information for the 360 video data, and converts the 360 video data and / or signaling information into various forms. There are various ways to send.
  • the 360 video transmission apparatus may include a video processor, a data encoder, a metadata processor, an encapsulation processor, and / or a transmitter as internal / external components.
  • the video processor may process 360 video data captured by at least one camera.
  • the video processor may stitch 360 video data and project the stitched 360 video data onto a 2D image, that is, a picture.
  • the video processor may further perform region wise packing.
  • stitching, projection, and region wise packing may correspond to the process of the same name described above.
  • the region wise packing may be called a region-specific packing name according to an embodiment.
  • the video processor may be a hardware processor that performs a role corresponding to the stitcher, the projection processor, and / or the region-specific packing processor.
  • the data encoder may encode a picture to which 360 video data is projected. According to an embodiment, when region-wise packing is performed, the data encoder may encode the packed picture.
  • the data encoder may correspond to the above-described data encoder.
  • the metadata processor may generate signaling information for the 360 video data.
  • the metadata processor may correspond to the aforementioned metadata processor.
  • the encapsulation processing unit may encapsulate the encoded picture and signaling information into a file.
  • the encapsulation processing unit may correspond to the encapsulation processing unit described above.
  • the transmitter may transmit 360 video data and signaling information.
  • the transmitter may transmit the files.
  • the transmission unit may be a component corresponding to the aforementioned transmission processor and / or the transmission unit.
  • the transmitter may transmit corresponding information through a broadcast network or broadband.
  • the signaling information may include coverage information.
  • the coverage information may indicate an area occupied by the subpicture of the picture on the 3D space.
  • the coverage information may indicate a region occupied by one region of the picture in the 3D space even if the subpicture is not a subpicture.
  • the data encoder may process a portion of the entire 360 video data as an independent video stream for processing based on a user viewpoint.
  • the data encoder may process some regions in the form of an independent video stream, respectively, in the projected picture or region size packed picture. These video streams may be stored and transmitted separately. Each of the regions may be the tile described above.
  • one track may contain this rectangular region, which may correspond to one or more tiles.
  • one adaptation set, representation, or sub representation may include a rectangular area. This area may correspond to one or more tiles.
  • each region may be HEVC bitstreams extracted from an HEVC MCTS bitstream. According to an embodiment, this process may be performed by the aforementioned tiling system or the transmission processing unit, not the data encoder.
  • the coverage information may include information for specifying a corresponding area.
  • the coverage information may include information specifying the center, width and / or height of the region.
  • the coverage information may include information representing a yaw value and / or a pitch value of a point that is the center of the corresponding area.
  • the information may be represented by an azimuth value or an elevation value when the 3D space is spherical.
  • the coverage information may include a width value and / or a height value of the corresponding area, each of which specifies the width and height of the corresponding area based on the specified midpoint, indicating the coverage of the entire corresponding area. Can be.
  • the coverage information may include information specifying the shape of the corresponding area.
  • the region may be shaped by four spherical circles or by two yaw circles and two pitch circles.
  • the coverage information may have information indicating which form of the corresponding area is present.
  • the coverage information may include information indicating whether the 360 video of the region is a 3D video and / or a left and right image.
  • the coverage information may indicate whether the 360 video corresponds to a 2D video or a 3D video, and if the 3D video corresponds to a left video or a right video.
  • this information may also indicate whether the corresponding 360 video includes both left and right images.
  • this information is defined as one field, and all of the above items may be signaled according to the value of this field.
  • the coverage information may be generated in the form of a DASH (Dynamic Adaptive Streaming over HTTP) descriptor.
  • the coverage information may be composed of DASH descriptors according to different formats.
  • the DASH descriptor may be included in a media presentation description (MPD) and transmitted in a separate path from the 360 video data file.
  • MPD media presentation description
  • the coverage information may not be encapsulated like 360 video data in the file. That is, the coverage information may be delivered to the receiver through a separate signaling channel in the form of MPD and the like.
  • the coverage information may be simultaneously included in separate signaling information such as a file and an MPD.
  • the 360 video transmitting apparatus may further include a (transmitting side) feedback processing unit.
  • the (sending side) feedback processing unit may correspond to the (sending side) feedback processing unit described above.
  • the feedback processing unit may receive feedback information indicating the viewport of the current user from the receiving side.
  • the feedback information may include information for specifying the viewport that the user is currently watching through the VR device. As described above, tiling or the like may be performed using this feedback information.
  • one region of the subpicture or the picture transmitted by the 360 video transmission device may be a region of the subpicture or the picture corresponding to the viewport indicated by the feedback information.
  • the coverage information may indicate coverage of a subpicture or a region of a picture corresponding to the viewport indicated by the feedback information.
  • the 3D space may be a sphere.
  • the 3D space may be a cube or the like.
  • signaling information for 360 video data may be inserted into a file in the form of an ISO Base Media File Format (ISOBMFF) box.
  • the file may be an ISOBMFF file or a file according to CFF (Common File Format).
  • the 360 video transmitting apparatus may further include a data input unit (not shown).
  • the data input unit may correspond to an internal component of the same name as described above.
  • the 360 video transmission apparatus when the 360 video content is provided, proposes a method for effectively providing a 360 video service by defining and transmitting metadata about the property of the 360 video.
  • the shape_type field or parameter is added to the coverage information, so that the reception side can effectively select a region corresponding to the viewport.
  • the 360 video transmission apparatus may receive and process only a video area corresponding to the viewport currently viewed by the user through tiling and provide the same to the user. This may enable efficient data transfer and processing.
  • the 360 video transmission apparatus effectively acquires the 3D 360 video by signaling whether the left / right image of the corresponding region, 2D / 3D, etc. is included in the coverage information. , Can handle.
  • Embodiments of the 360 video transmission apparatus according to the present invention described above may be combined with each other.
  • the above-described internal / external components of the 360 video transmission apparatus according to the present invention can be added, changed, replaced or deleted according to the embodiment.
  • the above-described internal / external components of the 360 video transmission apparatus may be implemented as a hardware component.
  • FIG. 36 illustrates a 360 video receiving apparatus according to another aspect of the present invention.
  • the present invention may be related to a 360 video receiving apparatus.
  • the 360 video receiving apparatus may receive the 360 video data and / or signaling information about the 360 video data and process the same to render the 360 video to the user.
  • the 360 video receiving apparatus may be a device at a receiving side corresponding to the 360 video transmitting apparatus described above.
  • the 360 video receiving apparatus may receive 360 video data and / or signaling information about 360 video data, obtain signaling information, and process 360 video data based on the 360 video data to render 360 video.
  • the 360 video receiving apparatus may include a receiver, a data processor and / or a metadata parser as internal / external components.
  • the receiver may receive 360 video data and / or signaling information about 360 video data. According to an embodiment, the receiver may receive the information in the form of a file. According to an embodiment, the receiver may receive corresponding information through a broadcast network or a broadband. The receiver may be a component corresponding to the receiver described above.
  • the data processor may obtain signaling information for 360 video data and / or 360 video data from the received file or the like.
  • the data processor may process the received information according to a transmission protocol, decapsulate a file, or perform decoding on 360 video data.
  • the data processor may also perform re-projection on the 360 video data, and thus perform rendering.
  • the data processor may be a hardware processor that performs a role corresponding to the aforementioned reception processor, decapsulation processor, data decoder, re-projection processor, and / or renderer.
  • the metadata parser may parse the obtained signaling information.
  • the metadata parser may correspond to the above-described metadata parser.
  • the 360 video receiving apparatus may have embodiments corresponding to the above 360 video transmitting apparatus according to the present invention.
  • the 360 video receiving apparatus and its internal / external components according to the present invention may perform embodiments corresponding to the above-described embodiments of the 360 video transmitting apparatus according to the present invention.
  • Embodiments of the 360 video receiving apparatus according to the present invention described above may be combined with each other.
  • the above-described internal / external components of the 360 video receiving apparatus according to the present invention can be added, changed, replaced or deleted according to the embodiment.
  • the above-described internal / external components of the 360 video receiving apparatus may be implemented as a hardware component.
  • the coverage information according to the present invention may indicate an area occupied in the 3D space by the subpicture of the picture as described above. According to an embodiment, the coverage information may indicate a region occupied by one region of the picture in the 3D space even if the subpicture is not a subpicture.
  • the coverage information indicates information for specifying a corresponding region, information specifying a shape of the corresponding region, and / or whether 360 video of the region is a 3D video and / or a left and right image. Information and the like.
  • the coverage information may be defined as SpatialRelationshipDescriptionOnSphereBox.
  • SpatialRelationshipDescriptionOnSphereBox can be defined as a box that can be represented as srds, which can be included in the ISOBMFF file. According to an embodiment, this box may exist below the visual sample entry of the track where each area is stored / transmitted. Depending on the embodiment, this box may exist below other boxes, such as a Scheme Information box.
  • the SpatialRelationshipDescriptionOnSphereBox may include a total_center_yaw, total_center_pitch, total_hor_range, total_ver_range, region_shape_type, and / or num_of_region fields.
  • the total_center_yaw field may indicate a yaw (longitude) value of the center point of the entire 3D geometry surface to which the corresponding region (in some embodiments, a tile) belongs.
  • the total_center_pitch field may indicate a pitch (latitude) value of the center point of the entire 3D space region to which the corresponding region belongs.
  • the total_hor_range field may indicate a yaw value range of the entire 3D space region to which the corresponding region belongs.
  • the total_ver_range field may indicate a range of pitch values of the entire 3D space region to which the corresponding region belongs.
  • the region_shape_type field may indicate what type of corresponding regions have a shape.
  • the shape of the region may be one of a shape specified by four great circles or a shape specified by two yaw circles and two pitch circles. If the field value is 0, the corresponding areas may have the same shape as the area surrounded by four members (37020). In this case, one region may represent one cube face such as a front face, a back face, a back face, or the like. If the value of this field is 1, the corresponding areas may have the same shape as an area surrounded by two yaw circles and two pitch circles (37030).
  • the num_of_region field may indicate the number of regions corresponding to the SpatialRelationshipDescriptionOnSphereBox. According to this field value, SpatialRelationshipDescriptionOnSphereBox may include RegionOnSphereStruct () for each region.
  • RegionOnSphereStruct () may indicate information about the corresponding region.
  • RegionOnSphereStruct () may include center_yaw, center_pitch, hor_range, and / or ver_range fields.
  • the center_yaw and center_pitch fields may indicate a yaw value and a pitch value of a point that is the center of the corresponding area.
  • the range_included_flag field may indicate whether RegionOnSphereStruct () includes hor_range and ver_range fields. According to the range_included_flag field, RegionOnSphereStruct () may include hor_range and ver_range fields.
  • the hor_range and ver_range fields may indicate the width value and the height value of the corresponding area. This width and height may be relative to the center point of the specified area concerned.
  • the coverage occupied in the 3D space can be specified through the position, width, and height values of the center point.
  • RegionOnSphereStruct () may further include a center_roll field.
  • center_yaw, center_pitch, center_roll field on the basis of the coordinate system specified in ProjectionOrientationBox, may represent the yaw, pitch, roll value of the point is the center of the zone, 2-16 degrees.
  • RegionOnSphereStruct () may further have an interpolate field. The interpolate field may have a value of zero.
  • the center_yaw may have a range of 180 * 2 16 to 180 * 2 161 .
  • center_pitch may range from 90 * 2 16 to 90 * 2 161 .
  • center_roll may range from 180 * 2 16 to 180 * 2 161 .
  • ver_range field may indicate a width dimension and height values of the zone, 2-16 degrees.
  • hor_range may have a range of 1 to 720 * 2 16 .
  • ver_range may range from 1 to 180 * 216.
  • the coverage information may have the form of a DASH descriptor.
  • 360 video data when 360 video data is transmitted by being divided into areas, 360 video data may be transmitted through DASH.
  • the coverage information may be delivered in the form of an Essential Property or Supplemental Property Descriptor of the DASH MPD.
  • the descriptor including the coverage information may be identified with a new schemIdURI such as “urn: mpeg: dash: mpd: vr-srd: 201x”. This descriptor may also exist below the adaptation set, representation or sub-representation in which each region is stored / transmitted.
  • the illustrated descriptor may include a source_id, region_shape_type, region_center_yaw, region_center_pitch, region_hor_range, region_ver_range, total_center_yaw, total_center_pitch, total_hor_range and / or total_ver_range parameters.
  • the source_id parameter may represent an identifier for identifying source 360 video content of corresponding regions. Regions from the same 360 video content may have the same source_id parameter values.
  • the region_shape_type parameter may be the same as the above-described region_shape_type field.
  • the region_center_yaw and region_center_pitch parameters may include a plurality of sets, and may represent yaw (longitude) and pitch (latitude) values of center points of the N-th region, respectively.
  • the region_hor_range and region_ver_range parameters may include a plurality of sets and may indicate a yaw value range and a pitch value range of the N-th region, respectively.
  • the total_center_yaw, total_center_pitch, total_hor_range and total_ver_range parameters may be the same as the above-described total_center_yaw, total_center_pitch, total_hor_range and total_ver_range fields.
  • coverage information may also take the form of a DASH descriptor.
  • This DASH descriptor like the above-mentioned coverage information, can provide information indicating spatial relationship between regions.
  • This descriptor can be identified by a schemIdURI such as "urn: mpeg: dash: spherical-region: 201X”.
  • the coverage information may be delivered in the form of an Essential Property or Supplemental Property Descriptor of the DASH MPD.
  • This descriptor may also exist below the adaptation set, representation or sub-representation in which each region is stored / transmitted.
  • the DASH descriptor of the illustrated embodiment may exist only below the adaptation set or the sub representation.
  • the depicted descriptor 3910 may include a source_id, object_center_yaw, object_center_pitch, object_hor_range, object_ver_range, sub_pic_reg_flag, and / or shape_type parameters.
  • the source_id parameter may be an identifier for identifying a source of the corresponding VR content. This parameter may be the same as the parameter of the same name mentioned above. According to an embodiment, this parameter may have a non-negative integer value.
  • the object_center_yaw and object_center_pitch parameters may indicate yaw and pitch values of midpoints of the corresponding area, respectively.
  • the corresponding area may mean an area on which a corresponding object (video area) is projected on a sphere.
  • the object_hor_range and object_ver_range parameters may indicate the width and height ranges of the corresponding area, respectively. These parameters can represent the range of yaw values and the range of pitch values as degrees.
  • the sub_pic_reg_flag parameter may indicate whether or not the corresponding area is the entire subpicture arranged on the spherical surface. When this parameter value is 0, the corresponding area may correspond to one entire subpicture. When this parameter value is 1, the corresponding area may correspond to a subpicture region in one subpicture.
  • the subpicture ie, the tile, may be divided into a plurality of subpicture regions (39020).
  • One subpicture may include a 'top' subpicture region and a 'bottom' subpicture region.
  • the descriptor 3910 may describe a subpicture region, that is, a corresponding region.
  • the adaptation set or subrepresentation may include a plurality of descriptors 3910 to describe respective subpicture regions.
  • the subpicture region may be a different concept from the region in the region-wise packing described above.
  • the shape_type parameter may be the same as the aforementioned region_shape_type field.
  • 360 video may be provided in 3D.
  • Such 360 video may be referred to as 3D 360 video or stereoscopic omnidirectional video.
  • each track may carry a left image or a right image of video regions.
  • each track may simultaneously carry a left image and a right image of an area.
  • the receiver supporting only 2D may reproduce the 360 video data in 2D using only one image.
  • the number of video decoders required to decode the subpicture bitstreams corresponding to the current viewport of the 3D 360 video is limited. Can be.
  • the coverage information in order to select a subpicture bitstream of the 3D 360 video corresponding to the viewport, may provide coverage information about a spherical area associated with each track.
  • the coverage information of the illustrated embodiment may further include view_idc information.
  • the view_idc information may be further included in all other embodiments of the aforementioned coverage information.
  • view_idc information may be included in a CoverageInformationBox and / or a content converage (CC) descriptor.
  • CoverageInformationBox may additionally include the view_idc field in the existing RegionOnSphereStruct ().
  • the view_idc field may indicate whether the 360 video of the corresponding region is a 3D video and / or a left and right image. If this field is 0, the 360 video of the corresponding region may be 2D video. If this field is 1, the 360 video of the corresponding region may be a left image of the 3D video. If this field is 2, the 360 video of the corresponding region may be a right image of the 3D video. If this field is 3, the 360 video of the corresponding region may be a left image and a right image of the 3D video.
  • RegionOnSphereStruct () may be as described above.
  • 41 is a view showing another embodiment of coverage information according to the present invention.
  • view_idc information may be added in the form of a parameter to coverage information composed of a DASH descriptor.
  • the DASH descriptor of the illustrated embodiment may include center_yaw, center_pitch, hor_range, ver_range, and / or view_idc parameters.
  • the center_yaw, center_pitch, hor_range, and ver_range parameters may be the same as the above-described center_yaw, center_pitch, hor_range, and ver_range fields.
  • the view_idc parameter may indicate whether the 360 video of the corresponding region is a 3D video and / or a left and right image, like the above-described view_idc field. Meanings assigned to the value of this parameter may be the same as the above-described view_idc field.
  • the coverage information may be the coverage information according to the above-described embodiments. have.
  • One embodiment of a method for transmitting 360 video includes processing 360 video data captured by at least one camera, encoding the picture, generating signaling information for the 360 video data, encoding Encapsulating the captured picture and the signaling information into a file and / or transmitting the file.
  • the video processor of the 360 video transmission device may process 360 video data captured by at least one or more cameras.
  • the video processor can stitch 360 video data and project the stitched 360 video data onto the picture.
  • the video processor may perform region-wise packing that maps the projected picture to the packed picture.
  • the data encoder of the 360 video transmission device may encode the picture.
  • the metadata processor of the 360 video transmission device may generate signaling information about 360 video data.
  • the signaling information may include coverage information indicating an area occupied by the subpicture of the picture on the 3D space.
  • the encapsulation processing unit of the 360 video transmission device may encapsulate the encoded picture and signaling information into a file.
  • the transmitter of the 360 video transmission apparatus may transmit a file.
  • the coverage information may include information representing a yaw value and a pitch value of a point that is the center of the corresponding area in the 3D space.
  • the coverage information may include information indicating a width value and a height value of the corresponding area in the 3D space.
  • the coverage information is in a 3D space where the area is specified by four great circles, or two yaw circles and two. It may further include information indicating whether or not the shape is specified by the pitch circle (pitch circle).
  • the coverage information is whether the 360 video corresponding to the corresponding area is a 2D video, a left video of 3D video, a right video of 3D video, or a left and right video of 3D video. It may further include information indicating whether to include all.
  • the coverage information is generated in the form of a Dynamic Adaptive Streaming over HTTP (DASH) descriptor, which is included in the Media Presentation Description (MPD) and is separate from the file having the 360 video data. Can be sent in the path of.
  • DASH Dynamic Adaptive Streaming over HTTP
  • the 360 video transmitting apparatus further includes a (sending side) feedback processing unit, and the (sending side) feedback processing unit receives feedback information indicating a viewport of the current user from the receiving side. can do.
  • the subpicture is a subpicture corresponding to the viewport of the current user indicated by the received feedback information
  • the coverage information is for a subpicture corresponding to the viewport indicated by the feedback information. It may be coverage information.
  • the above-described 360 video receiving apparatus may perform a method of receiving 360 video.
  • the method of receiving 360 video may have embodiments corresponding to the method of transmitting 360 video according to the present invention described above.
  • the method and embodiments thereof for receiving 360 video may be performed by the 360 video receiving apparatus and internal / external components thereof according to the present invention described above.
  • FIG 43 is a view showing a 360 video transmission apparatus according to an aspect of the present invention.
  • the invention may relate to a 360 video transmission device.
  • the 360 video transmission apparatus may process 360 video data, generate signaling information on the 360 video data, and transmit the same to the receiver.
  • the 360 video transmission device stitches 360 video, projects it into a picture, performs region wise packing, processes it in a format according to DASH, generates signaling information for the 360 video data, generates 360 video data and And / or signaling information may be transmitted through a broadcast network or a broadband.
  • the 360 video transmission apparatus may include a video processor, a metadata processor, an encapsulation processor, and / or a transmitter as internal / external components.
  • the video processor may process 360 video data captured by at least one camera.
  • the video processor may stitch 360 video data and project the stitched 360 video data onto a 2D image, that is, a picture.
  • the projected picture may be referred to as a first picture.
  • the video processor may further perform region wise packing by mapping regions of the projected picture to packed pictures.
  • the packed picture may be referred to as a second picture.
  • stitching, projection, and region wise packing may correspond to the process of the same name described above.
  • the region wise packing may be referred to as region-specific packing, region-specific packing, or the like according to an embodiment.
  • the video processor may be a hardware processor that performs a role corresponding to the stitcher, the projection processor, the region-specific packing processor, and / or the data encoder.
  • the encapsulation processing unit may process the processed 360 video data as data in a DASH (Dynamic Adaptive Streaming over HTTP) format.
  • the encapsulation processing unit may process the projected picture (first picture) or the packed picture (second picture) as data in a DASH format when region-wise packing is performed.
  • the encapsulation processor may process the corresponding 360 video data into DASH segments, that is, DASH representations.
  • the encapsulation processing unit may correspond to the encapsulation processing unit described above.
  • the metadata processor may generate signaling information for the 360 video data.
  • the metadata processor may generate signaling information about the 360 video data in the form of a media presentation description (MPD). This MPD may include signaling information for 360 video data carried in the DASH format.
  • the metadata processor may correspond to the aforementioned metadata processor.
  • the transmitter may transmit 360 video data and signaling information.
  • the transmitter may transmit the DASH representations and the MPD.
  • the transmission unit may be a component corresponding to the aforementioned transmission processor and / or the transmission unit.
  • the transmitter may transmit corresponding information through a broadcast network or broadband.
  • the above-described MPD may include a first descriptor.
  • the first descriptor may provide signaling information for the aforementioned projection process.
  • the first descriptor may include information indicating the projection type used when the 360 video data is projected on the first picture.
  • the information indicating the projection type described above may indicate whether the projection is an equirectangular projection or a cubemap projection type.
  • the information indicating the projection type may also indicate other projection types.
  • the above-described MPD may include a second descriptor.
  • the second descriptor may provide signaling information about the region-wise packing process described above.
  • the second descriptor may include information indicating a packing type used when region-wise packing is performed from the first picture to the second picture.
  • the information indicating the packing type described above may indicate that the region wise packing has a rectangular region wise packing type.
  • the information indicating the packing type may indicate that the region wise packing has other packing types.
  • the above-described MPD may include a third descriptor.
  • the third descriptor may include information regarding the coverage of the 360 video data.
  • the coverage information may indicate an area occupied in the 3D space by an entire area corresponding to 360 video data. This coverage information may indicate an area occupied by the area when the entire 360 video content is rendered in the 3D space.
  • the above-mentioned coverage information may specify an area occupied by the entire area on the 3D space by indicating a midpoint coordinate and / or a horizontal range and a vertical range of the area. can do.
  • the midpoint of the region can be specified here through azimuth and elevation values. Depending on the embodiment, this midpoint may be specified via yaw and pitch values.
  • the horizontal range and the vertical range may be represented as a range of angles. In some embodiments, the horizontal range and the vertical range may be represented by width and height.
  • At least one of the above-described DASH representations may be a timed metadata representation including timed metadata.
  • Timed metadata can provide metadata for 360 video data delivered via other DASH representations.
  • the above-described timed metadata may include initial viewpoint or initial viewing orientation information.
  • the initial viewpoint or initial viewpoint information may indicate a viewpoint that the user sees for the first time when the corresponding 360 content is started. As described above, the viewpoint may be the midpoint of the initial viewport.
  • the timed metadata including initial viewpoint information may indicate a DASH representation having 360 video data to which the initial viewpoint information is applied.
  • Timed metadata including the initial viewpoint information may include identifier information therefor. Through this identifier information, the DASH representation associated with the corresponding initial viewpoint information may be identified / indicated.
  • the above-described timed metadata may include recommended viewport information.
  • the recommended viewport information may indicate a viewport recommended by the service provider in the corresponding 360 content.
  • the timed metadata including recommended viewport information may indicate a DASH representation having 360 video data to which the corresponding recommended viewport information is applied.
  • Timed metadata including recommended viewport information may include identifier information therefor. Through this identifier information, the DASH representation associated with the recommended viewport information may be identified / indicated.
  • the 360 video transmission device whether the 360 video data is monoscopic 360 or stereoscopic 360 video, and if the stereoscopic 360 video data, the 360 video data
  • a signaling field indicating whether a is a left image, a right image, or both a left image and a right image may be defined at one time. That is, the signaling field may indicate frame packing arrangement information and stereoscopic 360 video at the same time with respect to the corresponding 360 video data.
  • the aforementioned first descriptor, second descriptor and / or third descriptor may each include a signaling field indicating the above-described matters with respect to the related 360 video data. This signaling field may correspond to the view_idc field.
  • the monoscopic 360 video data may refer to 360 video data provided in 2-Dimension (2D).
  • Stereoscopic 360 video data may refer to 360 video data that can be provided in 3D.
  • stereoscopic 360 video data may also be provided in 2D.
  • Embodiments of the 360 video transmission apparatus according to the present invention described above may be combined with each other.
  • the above-described internal / external components of the 360 video transmission apparatus according to the present invention can be added, changed, replaced or deleted according to the embodiment.
  • the above-described internal / external components of the 360 video transmission apparatus may be implemented as a hardware component.
  • 44 is a diagram illustrating a 360 video receiving apparatus according to another aspect of the present invention.
  • the present invention may be related to a 360 video receiving apparatus.
  • the 360 video receiving apparatus may receive the 360 video data and / or signaling information about the 360 video data and process the same to render the 360 video to the user.
  • the 360 video receiving apparatus may be a device at a receiving side corresponding to the 360 video transmitting apparatus described above.
  • the 360 video receiving apparatus may receive 360 video data and / or signaling information about 360 video data, obtain signaling information, and process 360 video data based on the 360 video data to render 360 video.
  • the 360 video receiving apparatus may include a receiver, a data processor and / or a metadata parser as internal / external components.
  • the receiver may receive 360 video data and / or signaling information about 360 video data.
  • the receiver may receive the information in the form of DASH representation and MPD.
  • the receiver may receive corresponding information through a broadcast network or a broadband.
  • the receiver may be a component corresponding to the receiver described above.
  • the data processor may obtain signaling information for 360 video data and / or 360 video data from the received information.
  • the data processor may process the received information according to a transmission protocol, decapsulate DASH segments of the DASH representation, or perform decoding on 360 video data.
  • the data processor may also perform re-projection on the 360 video data, and thus perform rendering.
  • the data processor may be a hardware processor that performs a role corresponding to the aforementioned reception processor, decapsulation processor, data decoder, re-projection processor, and / or renderer.
  • the metadata parser may parse signaling information from the obtained MPD.
  • the metadata parser may correspond to the above-described metadata parser.
  • the 360 video receiving apparatus may have embodiments corresponding to the above 360 video transmitting apparatus according to the present invention.
  • the 360 video receiving apparatus and its internal / external components according to the present invention may perform embodiments corresponding to the above-described embodiments of the 360 video transmitting apparatus according to the present invention.
  • Embodiments of the 360 video receiving apparatus according to the present invention described above may be combined with each other.
  • the above-described internal / external components of the 360 video receiving apparatus according to the present invention can be added, changed, replaced or deleted according to the embodiment.
  • the above-described internal / external components of the 360 video receiving apparatus may be implemented as a hardware component.
  • signaling information for the 360 video data can be defined.
  • the signaling information for such 360 video data includes an indication of whether the 360 video is fisheye content, an indication of a projection and / or mapping type for the 360 video if the fish video is not fisheye content, and the 360 video.
  • the area on the spherical surface covered by the content of the data may include information about an initial viewpoint and / or recommendation viewpoint when the corresponding 360 video data starts rendering.
  • various signaling information may be defined in the form of a DASH descriptor.
  • a fisheye 360 video indication descriptor a projection descriptor, a packing descriptor and / or a coverage descriptor may be defined.
  • the fisheye 360 video instruction descriptor may include information related to the fisheye 360 video instruction.
  • the fisheye 360 video indication descriptor is a DASH descriptor and may be used to indicate whether the corresponding 360 video content is fisheye content.
  • the fisheye 360 video instruction descriptor may be identified with a new schemIdURI such as "urn: mpeg: dash: omv-fisheye: 201x".
  • a new schemIdURI such as "urn: mpeg: dash: omv-fisheye: 201x”.
  • the fisheye 360 video indication descriptor may be delivered in the form of an Essential Property or Supplemental Property descriptor of the DASH MPD. This descriptor may also exist below the adaptation set, representation or sub-representation in which the corresponding video data is stored / transmitted.
  • the projection descriptor according to the present invention may include projection related information.
  • the projection descriptor is a DASH descriptor and may be used to indicate the projection format of the corresponding 360 video data.
  • the projection descriptor may be called the first descriptor.
  • the projection descriptor may be identified with a new schemIdURI such as "urn: mpeg: dash: omv-proj: 201x".
  • the @value value of this descriptor can indicate the projection format used when the 360 video data is projected onto the picture.
  • the @value value of this descriptor can have the same meaning as the projection_type of ProjectionFormatBox.
  • the projection descriptor may be delivered in the form of an Essential Property or Supplemental Property Descriptor in DASH MPD. This descriptor may also exist below the adaptation set, representation or sub-representation in which the corresponding video data is stored / transmitted.
  • the projection descriptor may indicate whether the projection type used in the projection process is an isquirectangular projection or a cubemap projection type.
  • the projection descriptor may also indicate other projection types.
  • the packing descriptor according to the present invention may include packing related information.
  • the packing descriptor is a DASH descriptor and can be used to indicate the packing format of the corresponding 360 video data.
  • the packing descriptor may be called a second descriptor.
  • the packing descriptor may be identified with a new schemIdURI such as "urn: mpeg: dash: omv-pack: 201x".
  • the @value value of this descriptor may indicate the packing format used when region Wise packing is performed from 360 video data from the first picture to the second picture.
  • the @value value of this descriptor can be a list of packing_type values of RegionWisePackingBox separated by commas.
  • the packing descriptor may be delivered in the form of an Essential Property or Supplemental Property descriptor of the DASH MPD. This descriptor may also exist below the adaptation set, representation or sub-representation in which the corresponding video data is stored / transmitted.
  • the packing descriptor may indicate that the packing type used in the region-wise packing process has a rectangular region-wise packing type.
  • the packing descriptor may indicate that the region wise packing has other packing types.
  • the coverage descriptor may include coverage related information.
  • the coverage descriptor is a DASH descriptor and may indicate an area occupied in the 3D space by the entire area corresponding to the 360 video data. That is, when the entirety of the corresponding 360 video content is rendered in the 3D space, the coverage descriptor may indicate an area occupied on the 3D space.
  • the coverage descriptor may be called a third descriptor.
  • the coverage descriptor may be identified with a new schemIdURI such as “urn: mpeg: dash: omv-coverage: 201x”.
  • the @value value of this descriptor may indicate an area occupied in 3D space by an area corresponding to 360 video data.
  • the @value value of this descriptor can be a list of CoverageInformationBox values separated by commas.
  • the coverage descriptor may be delivered in the form of an Essential Property or Supplemental Property descriptor of the DASH MPD. This descriptor may also exist below an adaptation set or sub-representation in which the corresponding video data is stored / transmitted.
  • the coverage descriptor may include source_id, total_center_yaw, total_center_pitch, total_hor_range and / or total_ver_range parameters.
  • the source_id parameter may represent an identifier for identifying the corresponding source 360 video content. This parameter may be a non-negative integer.
  • the total_center_yaw and total_center_pitch parameters may indicate the coordinates of the center point (center point) of the spherical surface onto which the entire 360 video content is projected.
  • each parameter may represent a yaw and a pitch value of a center point, respectively.
  • each parameter may represent a longitude and latitude value of a center point, respectively.
  • each parameter may represent an azimuth and an elevation value of the center point, respectively.
  • the total_hor_range and total_ver_range parameters may indicate a horizontal range and a vertical range of the spherical area on which the entire 360 video content is projected.
  • the horizontal range and vertical range may be represented as a range of angles.
  • the horizontal range and the vertical range may be represented by width and height.
  • each parameter may have the same meaning as hor_range and ver_range of the aforementioned CoverageInformationBox.
  • the fisheye 360 video instruction descriptor may be combined with each other.
  • the fisheye 360 video instruction descriptor may be combined with the fisheye 360 video according to the aforementioned embodiments. It may be an instruction descriptor.
  • the projection descriptor may be the projection descriptor according to the above-described embodiments.
  • the packing descriptor may be the packing descriptor according to the above-described embodiments.
  • the coverage descriptor may be the coverage descriptor according to the above-described embodiments.
  • initial viewpoint information and / or recommended viewpoint / viewport information may be provided as signaling information.
  • the initial viewpoint information and / or recommended viewpoint / viewport information may be delivered in the form of timed metadata.
  • At least one of the aforementioned DASH representations may be a timed metadata representation, and the timed metadata representation may include timed metadata.
  • a dynamic region descriptor may be used to utilize initial viewpoint information and / or recommended viewpoint / viewport information delivered as timed metadata.
  • the dynamic region descriptor can provide information about the region changing on the sphere.
  • the dynamic region descriptor is a DASH descriptor and can be used to provide information about a dynamic region on a sphere.
  • the dynamic region descriptor can be identified by a new schemIdURI such as "urn: mpeg: dash: dynamic-ros: 201x".
  • the @value value of this descriptor may be a list of parameter values as shown, separated by commas.
  • the projection descriptor may be delivered in the form of an Essential Property or Supplemental Property Descriptor in DASH MPD. This descriptor may also exist below an adaptation set or sub-representation in which the corresponding video data is stored / transmitted.
  • the illustrated dynamic region descriptor may include source_id and / or coordinate_id.
  • the source_id parameter may represent an identifier for identifying the corresponding source 360 video content. This parameter may be a non-negative integer.
  • the coordinate_id parameter may indicate a representation of a timed metadata track that carries timed metadata for a spherical region. That is, this parameter may specify @id of the representation providing the corresponding timed metadata.
  • the dynamic region descriptor may be used to distinguish initial viewpoint information and / or recommended viewpoint / viewport information. That is, the representation through which particular 360 video data is delivered may include a dynamic region descriptor. This dynamic region descriptor may indicate a representation that provides timed metadata for the corresponding 360 video data. At this time, the timed metadata representation providing initial viewpoint information and / or recommended viewpoint / viewport information may be identified by the dynamic region descriptor. Through this, initial viewpoint information and / or recommendation viewpoint / viewport information may be associated with the corresponding 360 video data.
  • the initial viewpoint information may indicate a viewpoint that the user sees for the first time when the 360 content starts.
  • the viewpoint may be the midpoint of the initial viewport.
  • the recommended viewport information may indicate a viewport recommended by the service provider in the corresponding 360 content.
  • Timed metadata indicative of initial viewpoint information and / or recommended viewpoint / viewport information may be provided by a timed metadata representation.
  • This timed metadata representation can provide an invp track.
  • This timed metadata representation may be associated with a representation that carries actual 360 video data with which the signaling information is associated.
  • a timed metadata representation that includes initial viewpoint information may include @associationId.
  • @associationId may indicate a representation that carries actual 360 video data to which the corresponding initial viewpoint information is applied. That is, @associationId can identify the DASH representation in which the associated actual data is carried. This example is equally applicable to recommended viewpoints / viewports.
  • the timed metadata representation may further include @associationType.
  • @associationType may indicate the type of association between the timed metadata representation and the representation carrying the actual data.
  • @associationType has a cdsc value
  • corresponding timed metadata may be described for one media track, respectively.
  • the media track may mean a track that carries actual data.
  • @associationType has a cdtg value
  • the corresponding timed metadata may be described for a track group.
  • initial viewpoint information and recommended viewpoint / viewport information according to the present invention may be combined with each other.
  • the initial viewpoint information, the recommended viewpoint / viewport information may be the initial viewpoint information, the recommended viewpoint / viewport information according to the above-described embodiments.
  • the above-described embodiments of the method for delivering initial viewpoint information and recommended viewpoint / viewport according to the present invention may be combined with each other.
  • the initial viewpoint information and the recommended view may be combined.
  • the method of delivering the point / viewport may be a method of delivering initial viewpoint information and recommended viewpoint / viewport according to the above-described embodiments.
  • FIG. 47 is a diagram illustrating an example of using initial viewpoint information and / or recommended viewpoint / viewport information according to the present invention.
  • the MPD describes two sets of adaptations for one period.
  • the first adaptation set 4710 may be an adaptation set that carries actual 360 video data
  • the second adaptation set 4730 may be an adaptation set that includes timed metadata that provides initial viewpoint information.
  • the first adaptation set 4710 includes one representation, which may be a representation having an ID of '360-video'.
  • This representation may include DASH descriptors that describe information about the 360 video data being conveyed through that representation (47020).
  • DASH descriptors 4704 are included in the representation level, the 360 video data included in the representation can be described.
  • These descriptors may each be a projection descriptor, a packing descriptor, and a dynamic region descriptor.
  • the projection descriptor of the use case has a value of 0, it can be seen that equirectangular projection is used for the 360 video data of this representation. Since the packing descriptor has a value of 0, it can be seen that the rectangular region-wise packing has been performed on the 360 video data of this representation.
  • source_id may be 1 and coordinate_id may be 'initial-viewpoint'.
  • the second adaptation set 47030 also includes one representation 4704, which may be a representation having an ID of 'initial-viewpoint'. This representation may include timed metadata that provides information about the initial viewpoint described above.
  • This representation 47040 may have 360-video as an associationId value 47050. Accordingly, it can be seen that the timed metadata is associated with a representation identified by an ID called 360-video. Timed metadata provided by timed metadata representation 4704 may be applied to 360 video data of this representation.
  • FIG. 48 is a diagram illustrating another application example of initial viewpoint information and / or recommended viewpoint / viewport information according to the present invention.
  • signaling information for 360 video data may be delivered as timed metadata.
  • the timed metadata is conveyed through a representation, which may include an invp track providing initial viewpoint information and / or an rcvp track providing recommended viewpoint / viewport information.
  • MPD describes a timed metadata representation that provides one 360 video stream and initial viewpoint information.
  • the MPD may describe two sets of adaptations.
  • the first adaptation set 48010 may be an adaptation set having real 360 video data.
  • This adaptation set may have a representation identified as '360-video'.
  • This representation can carry 360 video data.
  • This representation may include a rwpk descriptor, that is, a descriptor 48020 that provides information about region wise packing. This descriptor may indicate that region-wise packing has not been performed on the 360 video data of the representation.
  • the second adaptation set 4480 may include timed metadata that provides initial viewpoint related information.
  • This adaptation set may include a timed metadata representation.
  • This representation can be identified by the ID 'initial-viewpoint' and the associationId value can have '360-video'. Through the associationId value, it can be seen that the timed metadata of the timed metadata representation can be applied to the 360 video data of the representation having the '360-video' ID of the first adaptation set 48010. .
  • FIG. 49 illustrates another example of use of initial viewpoint information and / or recommended viewpoint / viewport information according to the present invention.
  • MPD describes a timed metadata representation that provides two 360 video streams and recommended viewport information.
  • Two 360 video streams may each carry a subpicture stream of 360 video. That is, one video stream may carry one subpicture of 360 video data.
  • the MPD may describe three sets of adaptations.
  • the first adaptation set 4910 may be an adaptation set having actual 360 video data.
  • This adaptation set may have a representation identified as '180-video-1'. This representation may carry a subpicture of 360 video data corresponding to -180 degrees to 0 degrees.
  • the second adaptation set 4920 may be an adaptation set with actual 360 video data.
  • This adaptation set may have a representation identified as '180-video-2'. This representation may carry a subpicture of 360 video data corresponding to 0 degrees to 180 degrees.
  • the third adaptation set 4930 may include timed metadata that provides recommended viewport related information.
  • This adaptation set may include a timed metadata representation.
  • This representation may be identified by an ID of 'recommended-viewport' and the associationId value may have '180-video-1, 180-video-2'.
  • the associationId value indicates that the timed metadata of this timed metadata representation can be applied to 360 video data of each representation of the first and second adaptation sets 449010 and 49020.
  • the assocationType value may have cdtg.
  • 50 is a view for explaining gap analysis in stereoscopic 360 video data signaling according to the present invention.
  • the signaling information for the 360 video data may be stored / delivered in the form of a box of ISOBMFF, or stored / transmitted in the form of a descriptor of a DASH MPD.
  • a gap analysis may be performed with respect to signaling for a frame packing arrangement and signaling for a view indication among signaling information about the stereoscopic 360 video data.
  • the difference can be analyzed.
  • the frame packing may mean that a plurality of images are mapped to one subpicture, track, or the like. For example, if a track includes both a left image and a right image, it may be said that frame packing is performed. At this time, the arrangement form in which the left image and the right image are included may be called a frame packing arrangement. In the case of the illustrated 50030, it can be said to have a side by side frame packing arrangement.
  • the view indication may refer to indicating whether the stereoscopic 360 video data is a left image or a right image, or an image having a left image and a right image together.
  • the frame packing arrangement can be indicated via the StereoVideoBox of ISOBMFF.
  • the frame packing arrangement may be indicated in various ways according to stereo_scheme.
  • stereo_scheme is 1, a frame packing scheme according to ISO / IEC 14496-10, a frame packing scheme according to ISO / IEC 13818-2 for 2, and a frame packing scheme according to ISO / IEC 23000-11 for 3 are used. Can be.
  • stereo_scheme having a value of 1 and stereo_indication_type having a value of 3 may indicate that a side by side frame packing arrangement is used for the corresponding track.
  • This frame packing arrangement may again be indicated by stereo_scheme having a value of 2, stereo_indication_type having a value of 0000011.
  • This frame packing arrangement may also be indicated by stereo_scheme having a value of 3, stereo_indication_type having a value of 0x00.
  • the frame packing arrangement may be indicated by the FramePacking element.
  • This element may identify a frame packing configuration scheme and / or frame packing arrangement.
  • the DASH client can select or reject an adaptation set based on this element. For example, if the 360 video data of the adaptation set and / or representation has a side by side frame packing arrangement, the @value of the FramePacking element may have a value of three.
  • view indication may be performed by the StereoVideoBox.
  • the StereoVideoBox may indicate whether the left video or the right video is for stereoscopic 360 video data carried by other tracks of the ISOBMFF.
  • scheme_type may have a value of 3
  • stereo_indication_type may have a value of 0x03. This may indicate to use the stereo scheme defined in ISO / IEC 23000-11, respectively, and may follow the “left / right view sequence type”.
  • view indication may be performed by a role descriptor.
  • the @value of the Role descriptor where @schemeUri has the value "urn: mpeg: dash: stereoid: 2011" can be used to indicate a pair of left and right images of stereoscopic video.
  • the AdaptationSet element describing either two streams has a Role descriptor with @schemeUri value of "urn: mpeg: dash: stereoid: 2011” and the @value values are l0 and r0, then each stream This may correspond to the left and right images.
  • a FramePacking element may be used. To indicate configuration, the @value of the FramePacking element can be set to 6. This may indicate “one frame of a frame pair”.
  • the projected left and right images may be arranged on the projected picture (the first picture).
  • the top-bottom or side-by-side frame packing arrangement may be used.
  • the stereoscopic arrangement of the projected picture can be indicated by the stereo_scheme of the StereoVideoBox pointing to 4 and the stereo_indication_type pointing to the frame packing arrangement, as described above.
  • the stereoscopic arrangement of the projected picture may also be indicated by the @value value of FramePacking of the MPD as described above.
  • the location, resolution, size, etc. of the projected region may differ from those of the packed region.
  • 50010 shows whether the position and / or size of the projected region before and after region wise packing can be changed. While projected regions (eg, L1, L2) of the same view are located in close proximity on the projected picture, the packed regions can be changed so that their position is far behind the region-wise packing. Also, resolution may change after region wise packing. In 50010, L1 and R1 had the same resolution, but after region wise packing, L1 'had a higher resolution than R1'.
  • the packed picture of 50010 can be divided into four subpictures.
  • Four subpictures may be included in four subpicture tracks and transmitted.
  • Each track may be a left image or a right image.
  • StereoVideoBox indicates stereo video arrangement of each subpicture according to ISOBMFF
  • scheme_type may be 3 and stereo_indication_type may be 0x03.
  • the @Descriptor of the FramePacking element is 3 or the Role descriptor according to the "urn: mpeg: dash: stereoid: 2011" scheme URI described above. Can be used.
  • the StereoVideoBox and FramePacking elements are limited to indicating frame packing arrangements of the projected left and right images, so that the view indication of the associated subpicture may not be performed. Therefore, an extended method may be needed for view information corresponding to the subpicture of each track.
  • the packed pictures of 50010 can be divided into two subpictures.
  • Two subpictures may be included in two subpicture tracks and transmitted.
  • each subpicture track may include two packed regions corresponding to the left and right views.
  • StereoVideoBox indicates stereo video arrangement of each sub picture according to ISOBMFF, it may not be indicated that the sub picture track includes both left and right images having different resolutions together.
  • the FramePacking element indicates a stereo video arrangement of each sub-picture adaptation set or representation according to DASH MPD, it may not be able to indicate an adaptation set or representation carrying both left and right images having different resolutions together. .
  • FIG. 51 illustrates another embodiment of a track coverage information box according to the present invention.
  • signaling can be improved.
  • the sub picture track includes left and right view regions of different resolutions
  • signaling needs to be improved to indicate view information corresponding to each sub picture track.
  • view_idc information may be added to the aforementioned track coverage information box (TrackCoverageInformationBox), content coverage descriptor (CC) descriptor and / or subpicture composition box (SubPictureCompositionBox).
  • TrackCoverageInformationBox content coverage descriptor
  • CC content coverage descriptor
  • SubPictureCompositionBox subpicture composition box
  • the view_idc field may indicate whether the corresponding 360 video data is stereoscopic 360 video and / or a left and right image. If this field is 0, the corresponding 360 video may be monoscopic 360 video. If this field is 1, the 360 video may be a left image of the stereoscopic 360 video. If this field is 2, the 360 video may be a right image of the stereoscopic 360 video. If this field is 3, the 360 video may be a left image and a right image of the stereoscopic 360 video.
  • the view_idc field may be added to the track coverage information box.
  • the view_idc field may describe the same information as described above with respect to the sphere region represented by the content of the packed pictures of the corresponding track.
  • the track coverage information box may further include track_coverage_shape_type and / or SphereRegionStruct.
  • track_coverage_shape_type may indicate the shape of the spherical area. This field may be the same as the shape_type described above.
  • the same content as the above-described RegionOnSphereStruct () can be described for the spherical area. That is, the center_yaw, center_pitch, center_roll, hor_range, ver_range and / or interpolate of SphereRegionStruct can describe the same contents as the fields of the same name of the aforementioned RegionOnSphereStruct () for the spherical region.
  • the above-described embodiments of the track coverage information box according to the present invention can be combined with each other. It may be a track coverage information box according to.
  • FIG. 52 illustrates another embodiment of a content coverage descriptor according to the present invention.
  • the content coverage descriptor may indicate a spherical area covered by the corresponding 360 video content. This may be implemented in the form of a DASH descriptor.
  • the content coverage descriptor may be a descriptor that provides the aforementioned coverage information.
  • the view_idc field may be added to the content coverage descriptor.
  • the view_idc field may describe the same information as described above with respect to the sphere region represented by the 360 video data of each representation.
  • the content coverage descriptor may further include shape_type, center_yaw, center_pitch, center_roll, hor_range and / or ver_range.
  • shape_type may indicate the shape of the spherical area. This field may be the same as the shape_type described above. This field may be the same as the shape_type described above.
  • center_yaw, center_pitch, center_roll, hor_range and / or ver_range may represent the yaw of the midpoint of the corresponding spherical region, the pitch of the midpoint, the roll of the midpoint, the horizontal range, and the vertical range, respectively. These values can be expressed in terms of global coordinate axes. Horizontal and vertical ranges can be used to represent the width and height relative to the midpoint of the spherical region.
  • the above-described embodiments of the content coverage descriptor according to the present invention may be combined with each other.
  • the content coverage descriptor may correspond to the above-described embodiments. It may be a content coverage descriptor.
  • 53 is a diagram illustrating an embodiment of a subpicture composition box according to the present invention.
  • the subpicture composition box according to the present invention may include information about subpicture composition track grouping.
  • TrackGroupTypeBox having a track_group_type of 'spco' value may indicate whether a corresponding track is included in the composition of tracks.
  • the tracks included in the composition may be arranged spatially in order to obtain a composition picture.
  • Visual tracks mapped to a grouping of these tracks represent visual content that can be presented collectively.
  • the visual tracks mapped to the grouping may refer to visual tracks having the same track_group_id value in a TrackGroupTypeBox having a track_group_type of 'spco'.
  • Each visual track mapped to this grouping may or may not be intended to be presented alone without other visual tracks.
  • the content producer may indicate that one visual track is not intended to be played alone without the other visual track using the CompositionRestrictionBox.
  • the tile base track may include a sub picture composition box.
  • composition picture is indicated in a track group, which can be derived by arranging in time-parallel samples of all the tracks of the same subpicture composition track group in space.
  • a view_idc field may be added to the subpicture composition box.
  • the view_idc field may describe information as described above with respect to samples of the corresponding track of the composition picture.
  • the illustrated sub picture composition box may further include track_x, track_y, track_width, track_height, composition_width, and / or composition_height.
  • track_x and track_y may represent the horizontal position and the vertical position of the upper left point of the samples of the corresponding track of the composition picture, respectively, as luma sample units. These two values can range from 0 to composition_width-1 and from 0 to composition_height-1, respectively.
  • track_width and track_height may indicate the width and height of the samples of the corresponding track of the composition picture in luma sample units, respectively. These two values can range from 1 to composition_width-1 and from 1 to composition_height-1, respectively.
  • composition_width and composition_height may represent the width and height of the composition picture in luma sample units, respectively.
  • an i th column of the corresponding track samples may be a colComposedPic th column of luma samples of the composition picture.
  • colComposedPic may be (i + track_x)% composition_width.
  • the j th row of the corresponding track samples may be the rowComposedPic th row of luma samples of the composition picture.
  • rowComposedPic may be (j + track_y)% composition_height.
  • the subpicture composition box may be combined with each other.
  • the subpicture composition box is described in the above embodiments. It may be a sub picture composition box according to.
  • FIG. 54 is a diagram illustrating an embodiment of a signaling process when fisheye 360 video data is rendered on a sphere according to the present invention.
  • the 360 video transmission apparatus maps circular images acquired by a fisheye lens to a picture, generates signaling information on fisheye 360 video data corresponding to the circular image, and in various forms, There are various ways to send.
  • the circular image is an image for 360 video captured by the fisheye lens, and may be referred to as a fisheye image or the like.
  • the video processor may process at least one circular image captured by a camera having at least one fish eye lens.
  • the video processor may map the circular images to the first picture.
  • the video processor may map circular images to rectangular regions of the first picture. Depending on the embodiment, this mapping process may be called 'packing' of the circular image.
  • the video processor may not stitch or region-wise pack circular images having fisheye 360 video data. That is, the video processor may omit stitching and region wise packing processes in processing fisheye 360 video data based on the fisheye lens.
  • the subpicture composition grouping described above may be used for the fisheye 360 video.
  • the subpicture track carrying the circular images corresponding to the user viewport can be efficiently selected.
  • the overall coverage of the entire projected picture to which fisheye images are mapped may be indicated.
  • Each circular image of the fisheye 360 video may be mapped to a sphere region.
  • the coverage angle of each circular image may be set as ⁇ . For example, when ⁇ is 180 degrees, this may mean having coverage corresponding to a hemisphere.
  • the area on the spherical surface can be specified by one small circle. This small circle is a circle having a radius corresponding to sin ( ⁇ / 2), and may be a circle surrounding a sphere along the latitude plane indicated by ⁇ / 2 (54010).
  • the spherical region corresponding to the circular image is indicated by the GlobalCoverageInformationBox or by a TrackCoverageInformationBox with a global_coverage_shape_type or track_coverage_shape_type value of 1.
  • the arctic point may mean a point having a pitch value of 90 degrees.
  • the spherical region of the circular image having a coverage angle of 170 degrees may be defined by two yaw circles and two pitch circles (54020).
  • the two yaw circles may have -180 degrees and 180 degrees, respectively. These two yaw circles are circles passing through the North Pole and can overlap each other on the sphere.
  • two pitch circles may have 5 degrees and 90 degrees, respectively. That is, the two pitch circles may be a circle in the shape of enclosing a sphere along a point of pitch 5 and a circle substantially represented as a point on an arctic point with a pitch of 90 degrees.
  • a ProjectionOrientationBox can exist for each circular image to indicate the location of the center point of the circular image at the north pole.
  • the hor_range value of SphereRegionStruct () should always be set to 360 * 216
  • the center_pitch value should be set to 90 * 216 minus half of the ver_range value.
  • the center_pitch value may be set to indicate an intermediate point between one pitch circle (north pole point) and another pitch circle.
  • the midpoint of the spherical region specified by SphereRegionStruct () can be located midway between the North Pole and another pitch circle.
  • the midpoint of the spherical region in the depicted figure 5520 may be a point on a pitch circle of 47.5 degrees (54030).
  • the midpoint of the spherical region specified by SphereRegionStruct () may be different from the midpoint of the actual spherical region.
  • the location of the wrong midpoint may produce incorrect results when center_roll is applied.
  • 55 is a diagram illustrating an embodiment of signaling information in which a new shape_type is defined according to the present invention.
  • a new shape_type value may be defined in the GlobalCoverageInformationBox and / or GlobalCoverageInformationBox. These new shape_type values can be used to indicate coverage information of fisheye 360 video.
  • the proposed new shape_type values may be further defined in the aforementioned fisheye 360 video box, global coverage information box and / or track coverage information box.
  • the illustrated fisheye 360 video box 55010 can provide fisheye video information.
  • the fisheye video information is one of signaling information, and is a type of a circular image, a rectangular region to which a circular image is mapped, or monoscopic 360 video data or stereoscopic 360 video data transmitted in the form of a circular image, a type of a rectangular region. And so on, for example.
  • the fisheye video information may provide information necessary for extracting, projecting, and blending the aforementioned circular image on the receiving side.
  • Fish eye 360 video boxes (55010, 55020) defined as fovd, shown, may describe features for the projected picture (picture to which circular images are mapped).
  • Fisheye 360 video box 5510 may provide fisheye video information for the fisheye 360 video and / or information about coverage on the spherical surface of the fisheye 360 video.
  • the global coverage information box can provide information about the coverage of the spherical area represented by the picture of the entire content.
  • the illustrated global coverage information box 55030 may be included in the fisheye 360 video box 55010 described above. According to an embodiment, the global coverage information box 55030 may be included in a projection 360 video box povd that provides information about the projected 360 video.
  • the global coverage information box may include global_coverage_shape_type and / or SphereRegionStruct ().
  • the global_coverage_shape_type is information indicating the shape of the spherical region, and may have the same meaning as the shape_type field described above with respect to the spherical region represented by the entire content.
  • the shape_type information may indicate what shape the corresponding region has.
  • the corresponding area may be a shape specified by the above four spherical circles.
  • shape_type may be a shape specified by two yaw circles and two pitch circles.
  • the corresponding area or the spherical area may be defined as one small circle as shown in the figure 5550.
  • a circle marked cSmall can be defined by the cPitch variable.
  • the cSmall circle is defined by the cPitch variable, it can be defined relative to the Y axis aligned with the direction of the midpoint specified by the center_yaw and center_pitch.
  • center_yaw, center_pitch, and center_roll may represent yaw, pitch, and roll values for the midpoint of the spherical area, similar to the center_yaw, center_pitch, and center_roll of the SphereRegionStruct described above.
  • center_yaw, center_pitch, and center_roll may represent yaw, pitch, and roll values of the midpoint of the spherical area relative to the global coordinate axes.
  • center_yaw, center_pitch, and center_roll may be the same as those of SphereRegionStruct described above.
  • hor_range and ver_range may indicate a horizontal range and a vertical range of the spherical region similarly to hor_range and ver_range of the SphereRegionStruct described above.
  • the units and ranges of hor_range and ver_range may be the same as those of SphereRegionStruct described above.
  • ver_range may indicate the range based on the midpoint of the spherical area (55050). ver_range can have a value between 0 and 360 * 2 16 .
  • the interpolate value may be zero.
  • the track coverage information box can provide information about the coverage of the spherical region represented by the track.
  • the illustrated track coverage information box 55040 may be included in the fisheye 360 video box 55010 described above. According to an embodiment, the track coverage information box 55040 may be included in the projection 360 video box povd.
  • the track coverage information box may include track_coverage_shape_type and / or SphereRegionStruct ().
  • the track_coverage_shape_type is information indicating the shape of the spherical region.
  • the track_coverage_shape_type may have the same meaning as the shape_type field described above with respect to the spherical region represented by the track.
  • center_yaw, center_pitch, and center_roll may represent yaw, pitch, and roll values for the midpoint of the spherical area as in the above-described center_yaw, center_pitch, and center_roll of SphereRegionStruct.
  • center_yaw, center_pitch, and center_roll may represent yaw, pitch, and roll values with respect to the midpoint of the spherical area relative to the global coordinate axes.
  • center_yaw, center_pitch, and center_roll may be the same as those of SphereRegionStruct described above.
  • hor_range and ver_range may indicate a horizontal range and a vertical range of the spherical area as in the above-described hor_range and ver_range of SphereRegionStruct.
  • the units and ranges of hor_range and ver_range may be the same as those of SphereRegionStruct described above.
  • ver_range may indicate the range based on the midpoint of the spherical area (55050). ver_range can have a value between 0 and 360 * 216. The interpolate value may be zero.
  • Embodiments of the fisheye 360 video box according to the present invention described above may be combined with each other. According to may be a fisheye 360 video box.
  • Embodiments of the global coverage information box according to the present invention described above may be combined with each other. It may be a global coverage information box according to.
  • the above-described embodiments of the track coverage information box according to the present invention can be combined with each other. It may be a track coverage information box according to.
  • SphereRegionStruct may describe a region appearing on a spherical surface.
  • SphereRegionStruct can specify the center of the region through center_yaw, center_pitch, and center_roll.
  • the SphereRegionStruct according to the illustrated embodiment may be a SphereRegionStruct modified in shape according to the shape_type having the new value described above.
  • SphereRegionStruct according to the illustrated embodiment may be used to describe areas that appear on spherical surfaces when fisheye 360 video data is used.
  • shape_type values may be further defined.
  • the range field may be included in SphereRegionStruct to specify the range of the corresponding region.
  • the range field may indicate the value of half of the angle from the midpoint to the 'small circle' as in ver_range described above.
  • shape_type When shape_type is 3, it may be indicated that the corresponding area is surrounded by curved surfaces having a plurality of ranges (57010). At this time, in order to specify the range of the corresponding region, a num_range field for indicating the number of ranges may be included in SphereRegionStruct. A range field may be further added for each range according to the num_range field.
  • the range field can represent the value of half of the angle from the midpoint to each surface.
  • an order in which a plurality of range field values are applied and / or an interval between curved surfaces may be determined.
  • the order may be determined in a clockwise or counterclockwise direction with respect to the Z axis.
  • the distance between curved surfaces may be determined as 360 / num_range. In this case, if num_range has a value of 4, the curved surfaces may be positioned at intervals of 90 degrees.
  • shape_type 4
  • it may be indicated that the corresponding area is a shape surrounded by two small circles (57020).
  • an inner_range and / or outer_range field may be included in SphereRegionStruct.
  • the outer_range field may indicate the value of half of the angle from the small circle farthest to the midpoint.
  • the inner_range field may indicate the value of half of the angle from the small circle near the midpoint to the midpoint.
  • the region of this shape may be mapped to the circular image of the donut shape.
  • shape_type When shape_type is 5, two surfaces same as the shape when shape_type is 3 may exist, and a corresponding region may be indicated to be surrounded by these two surfaces (57030). At this time, in order to specify the range of the corresponding region, a num_inner_ranges field and / or a num_outer_ranges field may be included in SphereRegionStruct.
  • Inner_range fields may be further added to each inner range according to the num_inner_ranges field.
  • the inner_range field may indicate a value of half of the angle from the curved surface near the midpoint to the midpoint.
  • outer_range fields may be further added for each outer range according to the num_outer_ranges field.
  • the outer_range field may indicate a value of half of the angle from the surface farthest from the midpoint to the midpoint.
  • FIG. 58 illustrates another embodiment of SphereRegionStruct for fisheye 360 video according to the present invention.
  • SphereRegionStruct for the fisheye 360 video described above may take the form of a DASH descriptor. As described above, when fisheye 360 video data is transmitted, it may be transmitted through DASH. At this time, the SphereRegionStruct for the fisheye 360 video may be delivered in the form of an Essential Property or Supplemental Property descriptor of the DASH MPD. In some embodiments, this descriptor may be included in each level of the MPD such as the adaptation set, the representation and / or the sub-representation.
  • SphereRegionStruct for fisheye 360 video may include shape_type, center_yaw, center_pitch, center_roll, hor_range, ver_range, range, num_ranges, ranges, inner_range, outer_range, num_inner_ranges, num_outer_ranges, num_inner_ranges, and / or.
  • the shape_type may correspond to the shape_type in which the aforementioned new value is defined.
  • the shape of the spherical region of the fisheye 360 video data for the representation may be indicated.
  • center_yaw, center_pitch, and center_roll may indicate the yaw, pitch, and roll values of the midpoint of the spherical area based on the global coordinate axes.
  • hor_range and ver_range may indicate the horizontal and vertical ranges of the spherical area based on the center point specified by center_yaw, center_pitch, and center_roll.
  • Range, num_ranges, ranges, inner_range, outer_range, num_inner_ranges, num_outer_ranges, num_inner_ranges, and num_outer_ranges may have the same meaning as the above-described fields of the same name.
  • ranges may be described by comma-separated descriptions of individual range values because they are described in the form of DASH descriptors.
  • num_inner_ranges and num_outer_ranges may be described by separating individual inner_range and outer_range values with commas.
  • SphereRegionStruct for fisheye 360 video according to the present invention may be combined with each other.
  • the SphereRegionStruct for fisheye 360 video according to the present invention SphereRegionStruct for fisheye 360 video according to one embodiment.
  • 59 is a view showing an embodiment of a method for transmitting 360 video, which may be performed by the 360 video transmitting apparatus according to the present invention.
  • One embodiment of a method for transmitting 360 video includes stitching 360 video data captured by at least one camera, projecting the stitched 360 video data onto a first picture, and Mapping regions to a second picture to perform region-wise packing, processing data of the second picture as Dynamic Adaptive Streaming over HTTP (DASH) representations, and signaling information for 360 video data Generating a media presentation description (MPD) including and / or transmitting the MPASH with the DASH representations; It may include.
  • DASH Dynamic Adaptive Streaming over HTTP
  • MPD media presentation description
  • the video processor of the 360 video transmission device may stitch the 360 video data captured by the at least one camera and project the stitched 360 video data onto the first picture.
  • the video processor may perform region wise packing by mapping regions of the first picture to the second picture.
  • the encapsulation processing unit may process data of the second picture as DASH (Dynamic Adaptive Streaming over HTTP) representations.
  • the metadata processor may generate a media presentation description (MPD) including signaling information for 360 video data.
  • the transmission processor or the transmission unit may transmit the DASH representations and the MPD.
  • the MPD may include a first descriptor and / or a second descriptor.
  • the first descriptor may include information indicating a projection type used when the stitched 360 video data is projected on the first picture.
  • the second descriptor may include information indicating a packing type used when region-wise packing is performed from the first picture to the second picture.
  • the information indicating the projection type may indicate that the projection has an equictangular projection or a cubemap projection type.
  • the information indicating the packing type may indicate that the region wise packing has a rectangular region wise packing type.
  • the MPD may include a third descriptor.
  • the third descriptor may include coverage information indicating an area occupied in the 3D space by the entire area corresponding to the 360 video data.
  • the coverage information may specify the midpoint of the region on the 3D space using azimuth and elevation values, and may specify a horizontal range and a vertical range of the region.
  • At least one of the DASH representations may be a timed metadata representation that includes timed metadata.
  • the timed metadata may include initial viewpoint information indicating an initial viewpoint.
  • the timed metadata may include information for identifying a DASH representation having 360 video data to which initial viewpoint information is applied.
  • the timed metadata may include recommended viewport information indicating a viewport recommended by the service provider.
  • the timed metadata may also include information for identifying a DASH representation having 360 video data to which recommended viewport information is applied.
  • the third descriptor may simultaneously determine frame packing arrangement information of the 360 video corresponding to the region and / or whether the 360 video is a stereoscopic 360 video. It may further include a singular signaling field indicating. This signaling field may be the above-described view_idc.
  • the above 360 video receiving apparatus may perform a method for receiving 360 video.
  • the method of receiving 360 video may have embodiments corresponding to the method of transmitting 360 video according to the present invention described above.
  • the method and embodiments thereof for receiving 360 video may be performed by the 360 video receiving apparatus and internal / external components thereof according to the present invention described above.
  • the region may mean a region in which 360 video data projected in a 2D image is located in a packed frame through region-wise packing.
  • the region herein may mean a region used in region-specific packing according to the context. As described above, regions may be divided equally by dividing the 2D image, or may be arbitrarily divided according to a projection scheme.
  • a region (general meaning, region) may be used as a dictionary meaning, unlike regions in the region-specific packing described above.
  • the region may have the meaning of 'region', 'region', 'partial', and so on.
  • an expression such as 'one region of the face' may be used.
  • the region is a meaning distinguished from the region in the region-specific packing described above, and both regions may indicate different regions irrelevant to each other.
  • the picture may refer to the entire 2D image projected with 360 video data.
  • 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 subpictures to perform tiling and the like.
  • each subpicture may be a tile.
  • the tile is a sub-concept of the sub picture, and the sub picture may be used as a tile for tiling. That is, in tiling, a subpicture and a tile may have the same concept.
  • the spherical region to the sphere region may refer to a region on the sphere when 360 video data is rendered in 3D space (eg, a sphere) on the receiving side.
  • the superior region is independent of the region in the region-specific packing. In other words, it is not necessary to mean the same region as a region defined in a regional packing.
  • Superior region is a term used to mean a part of a rendered sphere, and 'region' may mean 'region' in a dictionary meaning. Depending on the context, a superior region may simply be called a region. Superior regions to sphere regions may be referred to as spherical regions.
  • the face may be a term for calling each side according to the projection scheme.
  • the front, back, sides, top, bottom, etc. may be called faces.
  • Each part, module, or unit described above may be a processor or hardware part that executes successive procedures stored in a memory (or storage unit). Each of the steps described in the above embodiments may be performed by a processor or hardware parts. Each module / block / unit described in the above embodiments can operate as a hardware / processor.
  • the methods proposed by the present invention can be executed as code. This code can be written to a processor readable storage medium and thus read by a processor provided by an apparatus.
  • Apparatus and method according to the present invention is not limited to the configuration and method of the embodiments described as described above, the above-described embodiments may be selectively all or part of each embodiment so that various modifications can be made It may be configured in combination.
  • the processor-readable recording medium includes all kinds of recording devices that store data that can be read by the processor.
  • Examples of the processor-readable recording medium include ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, and the like, and may also be implemented in the form of a carrier wave such as transmission over the Internet.
  • the processor-readable recording medium can also be distributed over network coupled computer systems so that the processor-readable code is stored and executed in a distributed fashion.
  • the present invention is used in a series of VR related fields.

Abstract

본 발명은 360 비디오를 전송하는 방법과 관계될 수 있다. 본 발명에 따른 360 비디오를 전송하는 방법은 적어도 하나 이상의 카메라에 의해 캡쳐된 360 비디오 데이터를 처리하는 단계; 상기 픽쳐를 인코딩하는 단계; 상기 360 비디오 데이터에 대한 시그널링 정보를 생성하는 단계; 상기 인코딩된 픽쳐와 상기 시그널링 정보를 파일로 인캡슐레이팅하는 단계; 및 상기 파일을 전송하는 단계; 를 포함할 수 있다.

Description

360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
본 발명은 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치에 관한 것이다.
VR (Vertial Reality) 시스템은 사용자에게 전자적으로 투영된 환경내에 있는 것 같은 감각을 제공한다. VR 을 제공하기 위한 시스템은 더 고화질의 이미지들과, 공간적인 음향을 제공하기 위하여 더 개선될 수 있다. VR 시스템은 사용자가 인터랙티브하게 VR 컨텐트들을 소비할 수 있도록 할 수 있다.
VR 시스템은 더 효율적으로 VR 환경을 사용자에게 제공하기 위하여, 개선될 필요가 있다. 이를 위하여 VR 컨텐츠와 같은 많은 양의 데이터 전송을 위한 데이터 전송 효율, 송수신 네트워크 간의 강건성, 모바일 수신 장치를 고려한 네트워크 유연성, 효율적인 재생 및 시그널링을 위한 방안등이 제안되어야 한다.
또한 일반적인 TTML (Timed Text Markup Language) 기반의 자막(subtitle) 이나 비트맵 기반의 자막은 360 비디오를 고려하여 제작되지 않았기 때문에, 360 비디오에 적합한 자막을 제공하기 위해서는 VR 서비스의 유즈 케이스(use case) 에 적합하도록 자막 관련 특징 및 자막 관련 시그널링 정보 등이 더 확장될 필요가 있다.
본 발명의 목적에 따라, 본 발명은 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치를 제안한다.
본 발명의 한 관점에 따른 360 비디오를 전송하는 방법은 적어도 하나 이상의 카메라에 의해 캡쳐된 360 비디오 데이터를 스티칭(stitching)하는 단계; 상기 스티칭된 360 비디오 데이터를 제 1 픽쳐 상에 프로젝션하는 단계; 상기 제 1 픽쳐의 각 리전(Region) 들을 제 2 픽쳐로 매핑하여 리전 와이즈 패킹을 수행하는 단계; 상기 제 2 픽쳐의 데이터를 DASH (Dynamic Adaptive Streaming over HTTP) 레프리젠테이션들로 처리하는 단계; 상기 360 비디오 데이터에 대한 시그널링 정보를 포함하는 MPD (Media Presentation Description) 를 생성하는 단계; 및 상기 DASH 레프리젠테이션들과 상기 MPD 를 전송하는 단계; 를 포함할 수 있다.
바람직하게는, 상기 MPD 는 제 1 디스크립터 및 제 2 디스크립터를 포함하고, 상기 제 1 디스크립터는 상기 스티칭된 360 비디오 데이터가 상기 제 1 픽쳐 상에 프로젝션될 때 사용된 프로젝션 타입을 지시하는 정보를 포함하고, 상기 제 2 디스크립터는 상기 제 1 픽쳐에서 상기 제 2 픽쳐로 리전 와이즈 패킹이 수행될 때 사용된 패킹 타입을 지시하는 정보를 포함할 수 있다.
바람직하게는, 상기 프로젝션 타입을 지시하는 정보는 상기 프로젝션이 등장방형(equirectangular) 프로젝션 또는 큐브맵(cubemap) 프로젝션 타입을 가짐을 지시하고, 상기 패킹 타입을 지시하는 정보는 상기 리전 와이즈 패킹이 사각형(rectangular) 리전 와이즈 패킹 타입을 가짐을 지시할 수 있다.
바람직하게는, 상기 MPD 는 제 3 디스크립터를 포함하고, 상기 제 3 디스크립터는 상기 360 비디오 데이터에 해당하는 전체 영역이 3D 공간 상에서 차지하는 영역을 지시하는 커버리지(coverage) 정보를 포함하고, 상기 커버리지 정보는 상기 3D 공간 상의 상기 영역의 중점을 방위각(azimuth) 및 고도(elevation) 값을 이용해 특정하고, 상기 영역의 수평 범위 및 수직 범위를 특정할 수 있다.
바람직하게는, 상기 DASH 레프리젠테이션들 중 적어도 하나는 타임드 메타데이터를 포함하는 타임드 메타데이터 레프리젠테이션이고, 상기 타임드 메타데이터는 초기 뷰포인트(initial viewpoint) 를 지시하는 초기 뷰포인트 정보를 포함하고, 상기 타임드 메타데이터는 상기 초기 뷰포인트 정보가 적용되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 식별하는 정보를 포함할 수 있다.
바람직하게는, 상기 타임드 메타데이터는 서비스 프로바이더에 의해 추천되는 뷰포트를 지시하는 추천 뷰포트(recommended viewport) 정보를 포함하고, 상기 타임드 메타데이터는 상기 추천 뷰포트 정보가 적용되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 식별하는 정보를 포함할 수 있다.
바람직하게는, 상기 제 3 디스크립터는 상기 영역에 대응되는 360 비디오의 프레임 패킹 어레인지먼트(frame packing arrangement) 정보 및 상기 360 비디오가 스테레오스코픽(steremoscopic) 360 비디오인지 여부를 동시에 지시하는 단수개의 시그널링 필드를 더 포함할 수 있다.
본 발명의 다른 관점에 따른 360 비디오 전송 장치는 적어도 하나 이상의 카메라에 의해 캡쳐된 360 비디오 데이터를 스티칭(stitching)하는 비디오 프로세서, 상기 프로세서는 상기 스티칭된 360 비디오 데이터를 제 1 픽쳐 상에 프로젝션하고, 상기 제 1 픽쳐의 각 리전(Region) 들을 제 2 픽쳐로 매핑하여 리전 와이즈 패킹을 수행하고; 상기 제 2 픽쳐의 데이터를 DASH (Dynamic Adaptive Streaming over HTTP) 레프리젠테이션들로 처리하는 인캡슐레이션 처리부; 상기 360 비디오 데이터에 대한 시그널링 정보를 포함하는 MPD (Media Presentation Description) 를 생성하는 메타데이터 처리부; 및 상기 DASH 레프리젠테이션들과 상기 MPD 를 전송하는 전송부; 를 포함할 수 있다.
바람직하게는, 상기 MPD 는 제 1 디스크립터 및 제 2 디스크립터를 포함하고, 상기 제 1 디스크립터는 상기 스티칭된 360 비디오 데이터가 상기 제 1 픽쳐 상에 프로젝션될 때 사용된 프로젝션 타입을 지시하는 정보를 포함하고, 상기 제 2 디스크립터는 상기 제 1 픽쳐에서 상기 제 2 픽쳐로 리전 와이즈 패킹이 수행될 때 사용된 패킹 타입을 지시하는 정보를 포함할 수 있다.
바람직하게는, 상기 프로젝션 타입을 지시하는 정보는 상기 프로젝션이 등장방형(equirectangular) 프로젝션 또는 큐브맵(cubemap) 프로젝션 타입을 가짐을 지시하고, 상기 패킹 타입을 지시하는 정보는 상기 리전 와이즈 패킹이 사각형(rectangular) 리전 와이즈 패킹 타입을 가짐을 지시할 수 있다.
바람직하게는, 상기 MPD 는 제 3 디스크립터를 포함하고, 상기 제 3 디스크립터는 상기 360 비디오 데이터에 해당하는 전체 영역이 3D 공간 상에서 차지하는 영역을 지시하는 커버리지(coverage) 정보를 포함하고, 상기 커버리지 정보는 상기 3D 공간 상의 상기 영역의 중점을 방위각(azimuth) 및 고도(elevation) 값을 이용해 특정하고, 상기 영역의 수평 범위 및 수직 범위를 특정할 수 있다.
바람직하게는, 상기 DASH 레프리젠테이션들 중 적어도 하나는 타임드 메타데이터를 포함하는 타임드 메타데이터 레프리젠테이션이고, 상기 타임드 메타데이터는 초기 뷰포인트(initial viewpoint) 를 지시하는 초기 뷰포인트 정보를 포함하고, 상기 타임드 메타데이터는 상기 초기 뷰포인트 정보가 적용되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 식별하는 정보를 포함할 수 있다.
바람직하게는, 상기 타임드 메타데이터는 서비스 프로바이더에 의해 추천되는 뷰포트를 지시하는 추천 뷰포트(recommended viewport) 정보를 포함하고, 상기 타임드 메타데이터는 상기 추천 뷰포트 정보가 적용되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 식별하는 정보를 포함할 수 있다.
바람직하게는, 상기 제 3 디스크립터는 상기 영역에 대응되는 360 비디오의 프레임 패킹 어레인지먼트(frame packing arrangement) 정보 및 상기 360 비디오가 스테레오스코픽(steremoscopic) 360 비디오인지 여부를 동시에 지시하는 단수개의 시그널링 필드를 더 포함할 수 있다.
본 발명은 지상파 방송망과 인터넷 망을 사용하는 차세대 하이브리드 방송을 지원하는 환경에서 360 컨텐츠를 효율적으로 전송할 수 있다.
본 발명은 사용자의 360 컨텐츠 소비에 있어서, 인터랙티브 경험(interactive experience) 를 제공하기 위한 방안을 제안할 수 있다.
본 발명은 사용자의 360 컨텐츠 소비에 있어서, 360 컨텐츠 제작자가 의도하는 바가 정확히 반영되도록 시그널링 하는 방안을 제안할 수 있다.
본 발명은 360 컨텐츠 전달에 있어, 효율적으로 전송 캐패시티를 늘리고, 필요한 정보가 전달될 수 있도록 하는 방안을 제안할 수 있다.
도 1 은 본 발명에 따른 360 비디오 제공을 위한 전체 아키텍처를 도시한 도면이다.
도 2 은 본 발명의 한 관점(aspect)에 따른 360 비디오 전송 장치를 도시한 도면이다.
도 3 은 본 발명의 다른 관점에 따른 360 비디오 수신 장치를 도시한 도면이다.
도 4 는 본 발명의 다른 실시예에 따른 360 비디오 전송 장치/360 비디오 수신 장치를 도시한 도면이다.
도 5 는 본 발명의 3D 공간을 설명하기 위한 비행기 주축(Aircraft Principal Axes) 개념을 도시한 도면이다.
도 6 는 본 발명의 일 실시예에 따른 프로젝션 스킴들을 도시한 도면이다.
도 7 은 본 발명의 일 실시예에 따른 타일(Tile)을 도시한 도면이다.
도 8 은 본 발명의 일 실시예에 따른 360 비디오 관련 메타데이터를 도시한 도면이다.
도 9 은 본 발명의 일 실시예에 따른 미디어 파일의 구조를 도시한 도면이다.
도 10 는 본 발명의 일 실시예에 따른 ISOBMFF 내의 박스들의 계층적 구조를 도시한 도면이다.
도 11 는 본 발명의 일 실시예에 따른 DASH 기반 적응형(Adaptive) 스트리밍 모델의 전반적인 동작을 도시한 도면이다.
도 12은 본 발명에 따른 데이터 인코더의 구성을 예시적으로 설명하는 도면이다.
도 13는 본 발명에 따른 데이터 디코더의 구성을 예시적으로 설명하는 도면이다.
도 14는 코딩된 데이터에 대한 계층 구조를 예시적으로 나타낸다.
도 15은 영역 기반 독립적 프로세싱의 일 예인 MCTS(motion constraint tile set) 추출 및 전달 프로세스를 예시적으로 나타낸다.
도 16은 영역 기반 독립적 프로세싱 지원을 위한 이미지 프레임의 예를 나타낸다.
도 17는 영역 기반 독립적 프로세싱 지원을 위한 비트스트림 구성의 예를 나타낸다.
도 18은 본 발명에 따른 파일의 트랙 구성을 예시적으로 나타낸다.
도 19는 본 발명의 일 예에 따른 RegionOriginalCoordninateBox를 나타낸다.
도 20는 원본 픽처 내에서 해당 정보가 가리키는 영역을 예시적으로 나타낸다.
도 21은 본 발명의 일 실시예에 따른 RegionToTrackBox를 나타낸다.
도 22은 본 발명의 일 실시예에 따른 SEI 메시지를 나타낸다.
도 23은 본 발명의 일 실시예에 따른 mcts_sub_bitstream_region_in_original_picture_coordinate_info를 나타낸다.
도 24는 본 발명의 일 실시예에 따른 다수의 MCTS 비트스트림을 포함하는 파일 내의 MCTS 영역 관련 정보를 나타낸다.
도 25은 본 발명의 일실시예에 따른 뷰포트 기반 프로세싱을 나타낸다.
도 26은 본 발명의 일 실시예에 따른 커버리지 정보를 나타낸다.
도 27는 본 발명의 일 실시예에 따른 서브픽처 구성을 나타낸다.
도 28은 본 발명의 일 실시예에 따른 오버랩된 서브픽처들을 나타낸다.
도 29는 SubpictureCompositionBox의 신텍스를 나타낸다.
도 30는 RegionWisePackingBox의 계층적 구조를 나타낸다.
도 31은 본 발명에 따른 서브픽처 구성을 이용한 360도 비디오의 송수신 과정을 개략적으로 나타낸다.
도 32은 본 발명에 따른 서브픽처 구성을 예시적으로 나타낸다.
도 33은 본 발명에 따른 360도 비디오 전송 장치에 의한 360도 비디오 데이터 처리 방법을 개략적으로 나타낸다.
도 34는 본 발명에 따른 360도 비디오 수신 장치에 의한 360도 비디오 데이터 처리 방법을 개략적으로 나타낸다.
도 35 는 본 발명의 한 관점(aspect) 에 따른 360 비디오 전송 장치를 도시한 도면이다.
도 36 은 본 발명의 다른 관점에 따른 360 비디오 수신 장치 를 도시한 도면이다.
도 37 은 본 발명에 따른 커버리지 정보의 일 실시예를 도시한 도면이다.
도 38 은 본 발명에 따른 커버리지 정보 의 다른 실시예를 도시한 도면이다.
도 39 는 본 발명에 따른 커버리지 정보 의 또 다른 실시예를 도시한 도면이다.
도 40 은 본 발명에 따른 커버리지 정보 의 또 다른 실시예를 도시한 도면이다.
도 41 은 본 발명에 따른 커버리지 정보 의 또 다른 실시예를 도시한 도면이다.
도 42 는 본 발명에 따른 360 비디오 전송 장치에 의해 수행될 수 있는, 360 비디오를 전송하는 방법의 일 실시예를 나타낸 도면이다.
도 43 은 본 발명의 한 관점(aspect) 에 따른 360 비디오 전송 장치를 도시한 도면이다.
도 44 는 본 발명의 다른 관점에 따른 360 비디오 수신 장치 를 도시한 도면이다.
도 45 는 본 발명에 따른 커버리지 디스크립터의 일 실시예를 도시한 도면이다.
도 46 은 본 발명에 따른 다이나믹(dynamic) 영역 디스크립터의 일 실시예를 도시한 도면이다.
도 47 은 본 발명에 따른 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보의 활용례를 도시한 도면이다.
도 48 은 본 발명에 따른 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보의 다른 활용례를 도시한 도면이다.
도 49 는 본 발명에 따른 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보의 또 다른 활용례를 도시한 도면이다.
도 50 은 본 발명에 따른 스테레오스코픽 360 비디오 데이터 시그널링에 있어서, 갭 분석(gap analysis) 설명을 위한 도면이다.
도 51 은 본 발명에 따른 트랙 커버리지 정보 박스의 또 다른 실시예를 도시한 도면이다.
도 52 은 본 발명에 따른 컨텐트 커버리지 디스크립터의 또 다른 실시예를 도시한 도면이다.
도 53 은 본 발명에 따른 서브 픽쳐 컴포지션 박스의 일 실시예를 도시한 도면이다.
도 54 는 본 발명에 따른 어안 360 비디오 데이터가 구면 상에 렌더링될 때의 시그널링 과정의 일 실시예를 도시한 도면이다.
도 55 는 본 발명에 따른 새로운 shape_type 이 정의되는 시그널링 정보들의 일 실시예를 도시한 도면이다.
도 56 및 도 57 은 본 발명에 따른 어안 360 비디오를 위한 SphereRegionStruct 의 또 다른 실시예를 도시한 도면이다.
도 58 은 본 발명에 따른 어안 360 비디오를 위한 SphereRegionStruct 의 또 다른 실시예를 도시한 도면이다.
도 59 는 본 발명에 따른 360 비디오 전송 장치에 의해 수행될 수 있는, 360 비디오를 전송하는 방법의 일 실시예를 나타낸 도면이다.
본 발명의 바람직한 실시예에 대해 구체적으로 설명하며, 그 예는 첨부된 도면에 나타낸다. 첨부된 도면을 참조한 아래의 상세한 설명은 본 발명의 실시예에 따라 구현될 수 있는 실시예만을 나타내기보다는 본 발명의 바람직한 실시예를 설명하기 위한 것이다. 다음의 상세한 설명은 본 발명에 대한 철저한 이해를 제공하기 위해 세부 사항을 포함한다. 그러나 본 발명이 이러한 세부 사항 없이 실행될 수 있다는 것은 당업자에게 자명하다.
본 발명에서 사용되는 대부분의 용어는 해당 분야에서 널리 사용되는 일반적인 것들에서 선택되지만, 일부 용어는 출원인에 의해 임의로 선택되며 그 의미는 필요에 따라 다음 설명에서 자세히 서술한다. 따라서 본 발명은 용어의 단순한 명칭이나 의미가 아닌 용어의 의도된 의미에 근거하여 이해되어야 한다.
도 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 비디오를 효과적으로 제공하는 방안을 제안한다. 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) 를 나타낼 수 있다. 가로 길이와 세로 길이는 픽셀을 단위로 나타내어질 수 있다.
도 9 은 본 발명의 일 실시예에 따른 미디어 파일의 구조를 도시한 도면이다.
도 10 는 본 발명의 일 실시예에 따른 ISOBMFF 내의 박스들의 계층적 구조를 도시한 도면이다.
오디오 또는 비디오 등의 미디어 데이터를 저장하고 전송하기 위하여, 정형화된 미디어 파일 포맷이 정의될 수 있다. 실시예에 따라 미디어 파일은 ISO BMFF (ISO base media file format) 를 기반으로한 파일 포맷을 가질 수 있다.
본 발명에 따른 미디어 파일은 적어도 하나 이상의 박스를 포함할 수 있다. 여기서 박스(box)는 미디어 데이터 또는 미디어 데이터에 관련된 메타데이터 등을 포함하는 데이터 블락 내지 오브젝트일 수 있다. 박스들은 서로 계층적 구조를 이룰 수 있으며, 이에 따라 데이터들이 분류되어 미디어 파일이 대용량 미디어 데이터의 저장 및/또는 전송에 적합한 형태를 띄게 될 수 있다. 또한 미디어 파일은, 사용자가 미디어 컨텐츠의 특정지점으로 이동하는 등, 미디어 정보에 접근하는데 있어 용이한 구조를 가질 수 있다.
본 발명에 따른 미디어 파일은 ftyp 박스, moov 박스 및/또는 mdat 박스를 포함할 수 있다.
ftyp 박스(파일 타입 박스)는 해당 미디어 파일에 대한 파일 타입 또는 호환성 관련 정보를 제공할 수 있다. ftyp 박스는 해당 미디어 파일의 미디어 데이터에 대한 구성 버전 정보를 포함할 수 있다. 복호기는 ftyp 박스를 참조하여 해당 미디어 파일을 구분할 수 있다.
moov 박스(무비 박스)는 해당 미디어 파일의 미디어 데이터에 대한 메타 데이터를 포함하는 박스일 수 있다. moov 박스는 모든 메타 데이터들을 위한 컨테이너 역할을 할 수 있다. moov 박스는 메타 데이터 관련 박스들 중 최상위 계층의 박스일 수 있다. 실시예에 따라 moov 박스는 미디어 파일 내에 하나만 존재할 수 있다.
mdat 박스(미디어 데이터 박스) 는 해당 미디어 파일의 실제 미디어 데이터들을 담는 박스일 수 있다. 미디어 데이터들은 오디오 샘플 및/또는 비디오 샘플들을 포함할 수 있는데, mdat 박스는 이러한 미디어 샘플들을 담는 컨테이너 역할을 할 수 있다.
실시예에 따라 전술한 moov 박스는 mvhd 박스, trak 박스 및/또는 mvex 박스 등을 하위 박스로서 더 포함할 수 있다.
mvhd 박스(무비 헤더 박스)는 해당 미디어 파일에 포함되는 미디어 데이터의 미디어 프리젠테이션 관련 정보를 포함할 수 있다. 즉, mvhd 박스는 해당 미디어 프리젠테이션의 미디어 생성시간, 변경시간, 시간규격, 기간 등의 정보를 포함할 수 있다.
trak 박스(트랙 박스)는 해당 미디어 데이터의 트랙에 관련된 정보를 제공할 수 있다. trak 박스는 오디오 트랙 또는 비디오 트랙에 대한 스트림 관련 정보, 프리젠테이션 관련 정보, 액세스 관련 정보 등의 정보를 포함할 수 있다. trak 박스는 트랙의 개수에 따라 복수개 존재할 수 있다.
trak 박스는 실시예에 따라 tkhd 박스(트랙 헤더 박스)를 하위 박스로서 더 포함할 수 있다. tkhd 박스는 trak 박스가 나타내는 해당 트랙에 대한 정보를 포함할 수 있다. tkhd 박스는 해당 트랙의 생성시간, 변경시간, 트랙 식별자 등의 정보를 포함할 수 있다.
mvex 박스(무비 익스텐드 박스)는 해당 미디어 파일에 후술할 moof 박스가 있을 수 있음을 지시할 수 있다. 특정 트랙의 모든 미디어 샘플들을 알기 위해서, moof 박스들이 스캔되어야할 수 있다.
본 발명에 따른 미디어 파일은, 실시예에 따라, 복수개의 프래그먼트로 나뉘어질 수 있다(t18010). 이를 통해 미디어 파일이 분할되어 저장되거나 전송될 수 있다. 미디어 파일의 미디어 데이터들(mdat 박스)은 복수개의 프래그먼트로 나뉘어지고, 각각의 프래그먼트는 moof 박스와 나뉘어진 mdat 박스를 포함할 수 있다. 실시예에 따라 프래그먼트들을 활용하기 위해서는 ftyp 박스 및/또는 moov 박스의 정보가 필요할 수 있다.
moof 박스(무비 프래그먼트 박스)는 해당 프래그먼트의 미디어 데이터에 대한 메타 데이터를 제공할 수 있다. moof 박스는 해당 프래그먼트의 메타데이터 관련 박스들 중 최상위 계층의 박스일 수 있다.
mdat 박스(미디어 데이터 박스)는 전술한 바와 같이 실제 미디어 데이터를 포함할 수 있다. 이 mdat 박스는 각각의 해당 프래그먼트에 해당하는 미디어 데이터들의 미디어 샘플들을 포함할 수 있다.
실시예에 따라 전술한 moof 박스는 mfhd 박스 및/또는 traf 박스 등을 하위 박스로서 더 포함할 수 있다.
mfhd 박스(무비 프래그먼트 헤더 박스)는 분할된 복수개의 프래그먼트들 간의 연관성과 관련한 정보들을 포함할 수 있다. mfhd 박스는 시퀀스 넘버(sequence number) 를 포함하여, 해당 프래그먼트의 미디어 데이터가 분할된 몇 번째 데이터인지를 나타낼 수 있다. 또한, mfhd 박스를 이용하여 분할된 데이터 중 누락된 것은 없는지 여부가 확인될 수 있다.
traf 박스(트랙 프래그먼트 박스)는 해당 트랙 프래그먼트에 대한 정보를 포함할 수 있다. traf 박스는 해당 프래그먼트에 포함되는 분할된 트랙 프래그먼트에 대한 메타데이터를 제공할 수 있다. traf 박스는 해당 트랙 프래그먼트 내의 미디어 샘플들이 복호화/재생될 수 있도록 메타데이터를 제공할 수 있다. traf 박스는 트랙 프래그먼트의 개수에 따라 복수개 존재할 수 있다.
실시예에 따라 전술한 traf 박스는 tfhd 박스 및/또는 trun 박스 등을 하위 박스로서 더 포함할 수 있다.
tfhd 박스(트랙 프래그먼트 헤더 박스)는 해당 트랙 프래그먼트의 헤더 정보를 포함할 수 있다. tfhd 박스는 전술한 traf 박스가 나타내는 트랙 프래그먼트의 미디어 샘플들에 대하여, 기본적인 샘플크기, 기간, 오프셋, 식별자 등의 정보를 제공할 수 있다.
trun 박스(트랙 프래그먼트 런 박스)는 해당 트랙 프래그먼트 관련 정보를 포함할 수 있다. trun 박스는 미디어 샘플별 기간, 크기, 재생시점 등과 같은 정보를 포함할 수 있다.
전술한 미디어 파일 내지 미디어 파일의 프래그먼트들은 세그먼트들로 처리되어 전송될 수 있다. 세그먼트에는 초기화 세그먼트(initialization segment) 및/또는 미디어 세그먼트(media segment) 가 있을 수 있다.
도시된 실시예(t18020)의 파일은, 미디어 데이터는 제외하고 미디어 디코더의 초기화와 관련된 정보 등을 포함하는 파일일 수 있다. 이 파일은 예를 들어 전술한 초기화 세그먼트에 해당할 수 있다. 초기화 세그먼트는 전술한 ftyp 박스 및/또는 moov 박스를 포함할 수 있다.
도시된 실시예(t18030)의 파일은, 전술한 프래그먼트를 포함하는 파일일 수 있다. 이 파일은 예를 들어 전술한 미디어 세그먼트에 해당할 수 있다. 미디어 세그먼트는 전술한 moof 박스 및/또는 mdat 박스를 포함할 수 있다. 또한, 미디어 세그먼트는 styp 박스 및/또는 sidx 박스를 더 포함할 수 있다.
styp 박스(세그먼트 타입 박스) 는 분할된 프래그먼트의 미디어 데이터를 식별하기 위한 정보를 제공할 수 있다. styp 박스는 분할된 프래그먼트에 대해, 전술한 ftyp 박스와 같은 역할을 수행할 수 있다. 실시예에 따라 styp 박스는 ftyp 박스와 동일한 포맷을 가질 수 있다.
sidx 박스(세그먼트 인덱스 박스) 는 분할된 프래그먼트에 대한 인덱스를 나타내는 정보를 제공할 수 있다. 이를 통해 해당 분할된 프래그먼트가 몇번째 프래그먼트인지가 지시될 수 있다.
실시예에 따라(t18040) ssix 박스가 더 포함될 수 있는데, ssix 박스(서브 세그먼트 인덱스 박스)는 세그먼트가 서브 세그먼트로 더 나뉘어지는 경우에 있어, 그 서브 세그먼트의 인덱스를 나타내는 정보를 제공할 수 있다.
미디어 파일 내의 박스들은, 도시된 실시예(t18050)와 같은 박스 내지 풀 박스(FullBox) 형태를 기반으로, 더 확장된 정보들을 포함할 수 있다. 이 실시예에서 size 필드, largesize 필드는 해당 박스의 길이를 바이트 단위 등으로 나타낼 수 있다. version 필드는 해당 박스 포맷의 버전을 나타낼 수 있다. type 필드는 해당 박스의 타입 내지 식별자를 나타낼 수 있다. flags 필드는 해당 박스와 관련된 플래그 등을 나타낼 수 있다.
도 11 는 본 발명의 일 실시예에 따른 DASH 기반 적응형(Adaptive) 스트리밍 모델의 전반적인 동작을 도시한 도면이다.
도시된 실시예(t50010)에 따른 DASH 기반 적응형 스트리밍 모델은, HTTP 서버와 DASH 클라이언트 간의 동작을 기술하고 있다. 여기서 DASH (Dynamic Adaptive Streaming over HTTP) 는, HTTP 기반 적응형 스트리밍을 지원하기 위한 프로토콜로서, 네트워크 상황에 따라 동적으로 스트리밍을 지원할 수 있다. 이에 따라 AV 컨텐트 재생이 끊김없이 제공될 수 있다.
먼저 DASH 클라이언트는 MPD 를 획득할 수 있다. MPD 는 HTTP 서버 등의 서비스 프로바이더로부터 전달될 수 있다. DASH 클라이언트는 MPD 에 기술된 세그먼트에의 접근 정보를 이용하여 서버로 해당 세그먼트들을 요청할 수 있다. 여기서 이 요청은 네트워크 상태를 반영하여 수행될 수 있다.
DASH 클라이언트는 해당 세그먼트를 획득한 후, 이를 미디어 엔진에서 처리하여 화면에 디스플레이할 수 있다. DASH 클라이언트는 재생 시간 및/또는 네트워크 상황 등을 실시간으로 반영하여, 필요한 세그먼트를 요청, 획득할 수 있다(Adaptive Streaming). 이를 통해 컨텐트가 끊김없이 재생될 수 있다.
MPD (Media Presentation Description) 는 DASH 클라이언트로 하여금 세그먼트를 동적으로 획득할 수 있도록 하기 위한 상세 정보를 포함하는 파일로서 XML 형태로 표현될 수 있다.
DASH 클라이언트 컨트롤러(DASH Client Controller) 는 네트워크 상황을 반영하여 MPD 및/또는 세그먼트를 요청하는 커맨드를 생성할 수 있다. 또한, 이 컨트롤러는 획득된 정보를 미디어 엔진 등등의 내부 블락에서 사용할 수 있도록 제어할 수 있다.
MPD 파서(Parser) 는 획득한 MPD 를 실시간으로 파싱할 수 있다. 이를 통해, DASH 클라이언트 컨트롤러는 필요한 세그먼트를 획득할 수 있는 커맨드를 생성할 수 있게 될 수 있다.
세그먼트 파서(Parser) 는 획득한 세그먼트를 실시간으로 파싱할 수 있다. 세그먼트에 포함된 정보들에 따라 미디어 엔진 등의 내부 블락들은 특정 동작을 수행할 수 있다.
HTTP 클라이언트는 필요한 MPD 및/또는 세그먼트 등을 HTTP 서버에 요청할 수 있다. 또한 HTTP 클라이언트는 서버로부터 획득한 MPD 및/또는 세그먼트들을 MPD 파서 또는 세그먼트 파서로 전달할 수 있다.
미디어 엔진(Media Engine) 은 세그먼트에 포함된 미디어 데이터를 이용하여 컨텐트를 화면상에 표시할 수 있다. 이 때, MPD 의 정보들이 활용될 수 있다.
DASH 데이터 모델은 하이라키 구조(t50020)를 가질 수 있다. 미디어 프리젠테이션은 MPD 에 의해 기술될 수 있다. MPD 는 미디어 프리젠테이션를 만드는 복수개의 피리오드(Period)들의 시간적인 시퀀스를 기술할 수 있다. 피리오드는 미디어 컨텐트의 한 구간을 나타낼 수 있다.
한 피리오드에서, 데이터들은 어댑테이션 셋들에 포함될 수 있다. 어댑테이션 셋은 서로 교환될 수 있는 복수개의 미디어 컨텐트 컴포넌트들의 집합일 수 있다. 어댑테이션은 레프리젠테이션들의 집합을 포함할 수 있다. 레프리젠테이션은 미디어 컨텐트 컴포넌트에 해당할 수 있다. 한 레프리젠테이션 내에서, 컨텐트는 복수개의 세그먼트들로 시간적으로 나뉘어질 수 있다. 이는 적절한 접근성과 전달(delivery)를 위함일 수 있다. 각각의 세그먼트에 접근하기 위해서 각 세그먼트의 URL 이 제공될 수 있다.
MPD 는 미디어 프리젠테이션에 관련된 정보들을 제공할 수 있고, 피리오드 엘레멘트, 어댑테이션 셋 엘레멘트, 레프리젠테이션 엘레멘트는 각각 해당 피리오드, 어댑테이션 셋, 레프리젠테이션에 대해서 기술할 수 있다. 레프리젠테이션은 서브 레프리젠테이션들로 나뉘어질 수 있는데, 서브 레프리젠테이션 엘레멘트는 해당 서브 레프리젠테이션에 대해서 기술할 수 있다.
여기서 공통(Common) 속성/엘레멘트들이 정의될 수 있는데, 이 들은 어댑테이션 셋, 레프리젠테이션, 서브 레프리젠테이션 등에 적용될 수 (포함될 수) 있다. 공통 속성/엘레멘트 중에는 에센셜 프로퍼티(EssentialProperty) 및/또는 서플멘탈 프로퍼티(SupplementalProperty) 가 있을 수 있다.
에센셜 프로퍼티는 해당 미디어 프리젠테이션 관련 데이터를 처리함에 있어서 필수적이라고 여겨지는 엘레멘트들을 포함하는 정보일 수 있다. 서플멘탈 프로퍼티는 해당 미디어 프리젠테이션 관련 데이터를 처리함에 있어서 사용될 수도 있는 엘레멘트들을 포함하는 정보일 수 있다. 실시예에 따라후술할 디스크립터들은, MPD 를 통해 전달되는 경우, 에센셜 프로퍼티 및/또는 서플멘탈 프로퍼티 내에 정의되어 전달될 수 있다.
도 12은 본 발명에 따른 데이터 인코더의 구성을 예시적으로 설명하는 도면이다. 본 발명에 따른 데이터 인코더는 HEVC(high efficiency video codec)에 따른 비디오/이미지 인코딩 스킴을 포함한 다양한 인코딩 스킴을 수행할 수 있다.
도 12을 참조하면, 데이터 디코더(700)는 픽처 분할부(705), 예측부(710), 감산부(715), 변환부(720), 양자화부(725), 재정렬부(730), 엔트로피 인코딩부(735), 레지듀얼 처리부(740), 가산부(750), 필터부(755) 및 메모리(760)을 포함할 수 있다. 레지듀얼 처리부(740)는 역양자화부(741) 및 역변환부(742)를 포함할 수 있다.
픽처 분할부(705)는 입력된 영상(input image)를 적어도 하나의 처리 유닛(processing unit)으로 분할할 수 있다. 유닛(unit)은 영상 처리의 기본 단위를 나타낸다. 유닛은 픽처의 특정 영역 및 해당 영역에 관련된 정보 중 적어도 하나를 포함할 수 있다. 유닛은 경우에 따라서 블록(block) 또는 영역(area) 등의 용어와 혼용하여 사용될 수 있다. 일반적인 경우, MxN 블록은 M개의 열과 N개의 행으로 이루어진 샘플들 또는 변환 계수(transform coefficient)들의 집합을 나타낼 수 있다.
일 예로, 처리 유닛은 코딩 유닛(coding unit, CU)이라고 불릴 수 있다. 이 경우 코딩 유닛은 최대 코딩 유닛(largest coding unit, LCU)으로부터 QTBT (Quad-tree binary-tree) 구조에 따라 재귀적으로(recursively) 분할될 수 있다. 예를 들어, 하나의 코딩 유닛은 쿼드 트리 구조 및/또는 바이너리 트리 구조를 기반으로 하위(deeper) 뎁스의 복수의 코딩 유닛들로 분할될 수 있다. 이 경우 예를 들어 쿼드 트리 구조가 먼저 적용되고 바이너리 트리 구조가 나중에 적용될 수 있다. 또는 바이너리 트리 구조가 먼저 적용될 수도 있다. 더 이상 분할되지 않는 최종 코딩 유닛을 기반으로 본 발명에 따른 코딩 절차가 수행될 수 있다. 이 경우 영상 특성에 따른 코딩 효율 등을 기반으로, 최대 코딩 유닛이 바로 최종 코딩 유닛으로 사용될 수 있고, 또는 필요에 따라 코딩 유닛은 재귀적으로(recursively) 보다 하위 뎁스의 코딩 유닛들로 분할되어 최적의 사이즈의 코딩 유닛이 최종 코딩 유닛으로 사용될 수 있다. 여기서 코딩 절차라 함은 후술하는 예측, 변환, 및 복원 등의 절차를 포함할 수 있다.
다른 예로, 처리 유닛은 코딩 유닛(coding unit, CU) 예측 유닛(prediction unit, PU) 또는 변환 유닛(transform unit, TU)을 포함할 수도 있다. 코딩 유닛은 최대 코딩 유닛(largest coding unit, LCU)으로부터 쿼드 트리 구조를 따라서 하위(deeper) 뎁스의 코딩 유닛들로 분할(split)될 수 있다. 이 경우 영상 특성에 따른 코딩 효율 등을 기반으로, 최대 코딩 유닛이 바로 최종 코딩 유닛으로 사용될 수 있고, 또는 필요에 따라 코딩 유닛은 재귀적으로(recursively) 보다 하위 뎁스의 코딩 유닛들로 분할되어 최적의 사이즈의 코딩 유닛이 최종 코딩 유닛으로 사용될 수 있다. 최소 코딩 유닛(smallest coding unit, SCU)이 설정된 경우 코딩 유닛은 최소 코딩 유닛보다 더 작은 코딩 유닛으로 분할될 수 없다. 여기서 최종 코딩 유닛이라 함은 예측 유닛 또는 변환 유닛으로 파티셔닝 또는 분할되는 기반이 되는 코딩 유닛을 의미한다. 예측 유닛은 코딩 유닛으로부터 파티셔닝(partitioning)되는 유닛으로서, 샘플 예측의 유닛일 수 있다. 이 때, 예측 유닛은 서브 블록(sub block)으로 나뉠 수도 있다. 변환 유닛은 코딩 유닛으로부터 쿼드 트리 구조를 따라서 분할 될 수 있으며, 변환 계수를 유도하는 유닛 및/또는 변환 계수로부터 레지듀얼 신호(residual signal)를 유도하는 유닛일 수 있다. 이하, 코딩 유닛은 코딩 블록(coding block, CB), 예측 유닛은 예측 블록(prediction block, PB), 변환 유닛은 변환 블록(transform block, TB) 으로 불릴 수 있다. 예측 블록 또는 예측 유닛은 픽처 내에서 블록 형태의 특정 영역을 의미할 수 있고, 예측 샘플의 어레이(array)를 포함할 수 있다. 또한, 변환 블록 또는 변환 유닛은 픽처 내에서 블록 형태의 특정 영역을 의미할 수 있고, 변환 계수 또는 레지듀얼 샘플의 어레이를 포함할 수 있다.
예측부(710)는 처리 대상 블록(이하, 현재 블록이라 함)에 대한 예측을 수행하고, 상기 현재 블록에 대한 예측 샘플들을 포함하는 예측된 블록(predicted block)을 생성할 수 있다. 예측부(710)에서 수행되는 예측의 단위는 코딩 블록일 수 있고, 변환 블록일 수도 있고, 예측 블록일 수도 있다.
예측부(710)는 현재 블록에 인트라 예측이 적용되는지 인터 예측이 적용되는지를 결정할 수 있다. 일 예로, 예측부(710)는 CU 단위로 인트라 예측 또는 인터 예측이 적용되는지를 결정할 수 있다.
인트라 예측의 경우에, 예측부(710)는 현재 블록이 속하는 픽처(이하, 현재 픽처) 내의 현재 블록 외부의 참조 샘플을 기반으로 현재 블록에 대한 예측 샘플을 유도할 수 있다. 이 때, 예측부(710)는 (i) 현재 블록의 주변(neighboring) 참조 샘플들의 평균(average) 혹은 인터폴레이션(interpolation)을 기반으로 예측 샘플을 유도할 수 있고, (ii) 현재 블록의 주변 참조 샘플들 중 예측 샘플에 대하여 특정 (예측) 방향에 존재하는 참조 샘플을 기반으로 상기 예측 샘플을 유도할 수도 있다. (i)의 경우는 비방향성 모드 또는 비각도 모드, (ii)의 경우는 방향성(directional) 모드 또는 각도(angular) 모드라고 불릴 수 있다. 인트라 예측에서 예측 모드는 예를 들어 33개 이상의 방향성 예측 모드와 적어도 2개 이상의 비방향성 모드를 가질 수 있다. 비방향성 모드는 DC 예측 모드 및 플래너 모드(Planar 모드)를 포함할 수 있다. 예측부(710)는 주변 블록에 적용된 예측 모드를 이용하여, 현재 블록에 적용되는 예측 모드를 결정할 수도 있다.
인터 예측의 경우에, 예측부(710)는 참조 픽처 상에서 움직임 벡터에 의해 특정되는 샘플을 기반으로, 현재 블록에 대한 예측 샘플을 유도할 수 있다. 예측부(710)는 스킵(skip) 모드, 머지(merge) 모드, 및 MVP(motion vector prediction) 모드 중 어느 하나를 적용하여 현재 블록에 대한 예측 샘플을 유도할 수 있다. 스킵 모드와 머지 모드의 경우에, 예측부(710)는 주변 블록의 움직임 정보를 현재 블록의 움직임 정보로 이용할 수 있다. 스킵 모드의 경우, 머지 모드와 달리 예측 샘플과 원본 샘플 사이의 차(레지듀얼)가 전송되지 않는다. MVP 모드의 경우, 주변 블록의 움직임 벡터를 움직임 벡터 예측자(Motion Vector Predictor)로 이용하여 현재 블록의 움직임 벡터 예측자로 이용하여 현재 블록의 움직임 벡터를 유도할 수 있다.
인터 예측의 경우에, 주변 블록은 현재 픽처 내에 존재하는 공간적 주변 블록(spatial neighboring block)과 참조 픽처(reference picture)에 존재하는 시간적 주변 블록(temporal neighboring block)을 포함할 수 있다. 상기 시간적 주변 블록을 포함하는 참조 픽처는 동일 위치 픽처(collocated picture, colPic)라고 불릴 수도 있다. 움직임 정보(motion information)는 움직임 벡터와 참조 픽처 인덱스를 포함할 수 있다. 예측 모드 정보와 움직임 정보 등의 정보는 (엔트로피) 인코딩되어 비트스트림 형태로 출력될 수 있다.
스킵 모드와 머지 모드에서 시간적 주변 블록의 움직임 정보가 이용되는 경우에, 참조 픽처 리스트(reference picture list) 상의 최상위 픽처가 참조 픽처로서 이용될 수도 있다. 참조 픽처 리스트(Picture Order Count)에 포함되는 참조 픽처들은 현재 픽처와 해당 참조 픽처 간의 POC(Picture order count) 차이 기반으로 정렬될 수 있다. POC는 픽처의 디스플레이 순서에 대응하며, 코딩 순서와 구분될 수 있다.
감산부(715)는 원본 샘플과 예측 샘플 간의 차이인 레지듀얼 샘플을 생성한다. 스킵 모드가 적용되는 경우에는, 상술한 바와 같이 레지듀얼 샘플을 생성하지 않을 수 있다.
변환부(720)는 변환 블록 단위로 레지듀얼 샘플을 변환하여 변환 계수(transform coefficient)를 생성한다. 변환부(720)는 해당 변환 블록의 사이즈와, 해당 변환 블록과 공간적으로 겹치는 코딩 블록 또는 예측 블록에 적용된 예측 모드에 따라서 변환을 수행할 수 있다. 예컨대, 상기 변환 블록과 겹치는 상기 코딩 블록 또는 상기 예측 블록에 인트라 예측이 적용되었고, 상기 변환 블록이 4×4의 레지듀얼 어레이(array)라면, 레지듀얼 샘플은 DST(Discrete Sine Transform) 변환 커널을 이용하여 변환되고, 그 외의 경우라면 레지듀얼 샘플은 DCT(Discrete Cosine Transform) 변환 커널을 이용하여 변환할 수 있다.
양자화부(725)는 변환 계수들을 양자화하여, 양자화된 변환 계수를 생성할 수 있다.
재정렬부(730)는 양자화된 변환 계수를 재정렬한다. 재정렬부(130)는 계수들 스캐닝(scanning) 방법을 통해 블록 형태의 양자화된 변환 계수들을 1차원 벡터 형태로 재정렬할 수 있다. 여기서 재정렬부(130)는 별도의 구성으로 설명하였으나, 재정렬부(730)는 양자화부(725)의 일부일 수 있다.
엔트로피 인코딩부(735)는 양자화된 변환 계수들에 대한 엔트로피 인코딩을 수행할 수 있다. 엔트로피 인코딩은 예를 들어 지수 골롬(exponential Golomb), CAVLC(context-adaptive variable length coding), CABAC(context-adaptive binary arithmetic coding) 등과 같은 인코딩 방법을 포함할 수 있다. 엔트로피 인코딩부(735)는 양자화된 변환 계수 외 비디오 복원에 필요한 정보들(예컨대 신택스 요소(syntax element)의 값 등)을 함께 또는 별도로 인코딩할 수도 있다. 엔트로피 인코딩된 정보들은 비트스트림 형태로 NAL(network abstraction layer) 유닛 단위로 전송 또는 저장될 수 있다.
역양자화부(741)는 양자화부(725)에서 양자화된 값(양자화된 변환 계수)들을 역양자화하고, 역변환부(742)는 역양자화부(741)에서 역양자화된 값들을 역변환하여 레지듀얼 샘플을 생성한다.
가산부(750)는 레지듀얼 샘플과 예측 샘플을 합쳐서 픽처를 복원한다. 레지듀얼 샘플과 예측 샘플은 블록 단위로 더해져서 복원 블록이 생성될 수 있다. 여기서 가산부(750)는 별도의 구성으로 설명하였으나, 가산부(750)는 예측부(710)의 일부일 수 있다. 한편, 가산부(750)는 복원부 또는 복원 블록 생성부로 불릴 수도 있다.
복원된 픽처(reconstructed picture)에 대하여 필터부(755)는 디블록킹 필터 및/또는 샘플 적응적 오프셋(sample adaptive offset)을 적용할 수 있다. 디블록킹 필터링 및/또는 샘플 적응적 오프셋을 통해, 복원 픽처 내 블록 경계의 아티팩트나 양자화 과정에서의 왜곡이 보정될 수 있다. 샘플 적응적 오프셋은 샘플 단위로 적용될 수 있으며, 디블록킹 필터링의 과정이 완료된 후 적용될 수 있다. 필터부(755)는 ALF(Adaptive Loop Filter)를 복원된 픽처에 적용할 수도 있다. ALF는 디블록킹 필터 및/또는 샘플 적응적 오프셋이 적용된 후의 복원된 픽처에 대하여 적용될 수 있다.
메모리(760)는 복원 픽처(디코딩된 픽처) 또는 인코딩/디코딩에 필요한 정보를 저장할 수 있다. 여기서 복원 픽처는 상기 필터부(755)에 의하여 필터링 절차가 완료된 복원 픽처일 수 있다. 상기 저장된 복원 픽처는 다른 픽처의 (인터) 예측을 위한 참조 픽처로 활용될 수 있다. 예컨대, 메모리(760)는 인터 예측에 사용되는 (참조) 픽처들을 저장할 수 있다. 이 때, 인터 예측에 사용되는 픽처들은 참조 픽처 세트(reference picture set) 혹은 참조 픽처 리스트(reference picture list)에 의해 지정될 수 있다.
도 13는 본 발명에 따른 데이터 디코더의 구성을 예시적으로 설명하는 도면이다.
도 13을 참조하면, 데이터 디코더(800)는 엔트로피 디코딩부(810), 레지듀얼 처리부(820), 예측부(830), 가산부(840), 필터부(850) 및 메모리(860)을 포함할 수 있다. 여기서 레지듀얼 처리부(820)는 재정렬부(821), 역양자화부(822), 역변환부(823)을 포함할 수 있다.
비디오 정보를 포함하는 비트스트림이 입력되면, 비디오 디코딩 장치는(800)는 비디오 인코딩 장치에서 비디오 정보가 처리된 프로세스에 대응하여 비디오를 복원할 수 있다.
예컨대, 비디오 디코딩 장치(800)는 비디오 인코딩 장치에서 적용된 처리 유닛을 이용하여 비디오 디코딩을 수행할 수 있다. 따라서 비디오 디코딩의 처리 유닛 블록은 일 예로 코딩 유닛일 수 있고, 다른 예로 코딩 유닛, 예측 유닛 또는 변환 유닛일 수 있다. 코딩 유닛은 최대 코딩 유닛으로부터 쿼드 트리 구조 및/또는 바이너리 트리 구조를 따라서 분할될 수 있다.
예측 유닛 및 변환 유닛이 경우에 따라 더 사용될 수 있으며, 이 경우 예측 블록은 코딩 유닛으로부터 도출 또는 파티셔닝되는 블록으로서, 샘플 예측의 유닛일 수 있다. 이 때, 예측 유닛은 서브 블록으로 나뉠 수도 있다. 변환 유닛은 코딩 유닛으로부터 쿼드 트리 구조를 따라서 분할 될 수 있으며, 변환 계수를 유도하는 유닛 또는 변환 계수로부터 레지듀얼 신호를 유도하는 유닛일 수 있다.
엔트로피 디코딩부(810)는 비트스트림을 파싱하여 비디오 복원 또는 픽처 복원에 필요한 정보를 출력할 수 있다. 예컨대, 엔트로피 디코딩부(810)는 지수 골롬 부호화, CAVLC 또는 CABAC 등의 코딩 방법을 기초로 비트스트림 내 정보를 디코딩하고, 비디오 복원에 필요한 신택스 엘리먼트의 값, 레지듀얼에 관한 변환 계수의 양자화된 값 들을 출력할 수 있다.
보다 상세하게, CABAC 엔트로피 디코딩 방법은, 비트스트림에서 각 구문 요소에 해당하는 빈을 수신하고, 디코딩 대상 구문 요소 정보와 주변 및 디코딩 대상 블록의 디코딩 정보 혹은 이전 단계에서 디코딩된 심볼/빈의 정보를 이용하여 문맥(context) 모델을 결정하고, 결정된 문맥 모델에 따라 빈(bin)의 발생 확률을 예측하여 빈의 산술 디코딩(arithmetic decoding)를 수행하여 각 구문 요소의 값에 해당하는 심볼을 생성할 수 있다. 이때, CABAC 엔트로피 디코딩 방법은 문맥 모델 결정 후 다음 심볼/빈의 문맥 모델을 위해 디코딩된 심볼/빈의 정보를 이용하여 문맥 모델을 업데이트할 수 있다.
엔트로피 디코딩부(810)에서 디코딩된 정보 중 예측에 관한 정보는 예측부(830)로 제공되고, 엔트로피 디코딩부(810)에서 엔트로피 디코딩이 수행된 레지듀얼 값, 즉 양자화된 변환 계수는 재정렬부(821)로 입력될 수 있다.
재정렬부(821)는 양자화되어 있는 변환 계수들을 2차원의 블록 형태로 재정렬할 수 있다. 재정렬부(821)는 인코딩 장치에서 수행된 계수 스캐닝에 대응하여 재정렬을 수행할 수 있다. 여기서 재정렬부(821)는 별도의 구성으로 설명하였으나, 재정렬부(821)는 역양자화부(822)의 일부일 수 있다.
역양자화부(822)는 양자화되어 있는 변환 계수들을 (역)양자화 파라미터를 기반으로 역양자화하여 변환 계수를 출력할 수 있다. 이 때, 양자화 파라미터를 유도하기 위한 정보는 인코딩 장치로부터 시그널링될 수 있다.
역변환부(823)는 변환 계수들을 역변환하여 레지듀얼 샘플들을 유도할 수 있다.
예측부(830)는 현재 블록에 대한 예측을 수행하고, 상기 현재 블록에 대한 예측 샘플들을 포함하는 예측된 블록(predicted block)을 생성할 수 있다. 예측부(830)에서 수행되는 예측의 단위는 코딩 블록일 수도 있고, 변환 블록일 수도 있고, 예측 블록일 수도 있다.
예측부(830)는 상기 예측에 관한 정보를 기반으로 인트라 예측을 적용할 것인지 인터 예측을 적용할 것인지를 결정할 수 있다. 이 때, 인트라 예측과 인터 예측 중 어느 것을 적용할 것인지를 결정하는 단위와 예측 샘플을 생성하는 단위는 상이할 수 있다. 아울러, 인터 예측과 인트라 예측에 있어서 예측 샘플을 생성하는 단위 또한 상이할 수 있다. 예를 들어, 인터 예측과 인트라 예측 중 어느 것을 적용할 것인지는 CU 단위로 결정할 수 있다. 또한 예를 들어, 인터 예측에 있어서 PU 단위로 예측 모드를 결정하고 예측 샘플을 생성할 수 있고, 인트라 예측에 있어서 PU 단위로 예측 모드를 결정하고 TU 단위로 예측 샘플을 생성할 수도 있다.
인트라 예측의 경우에, 예측부(830)는 현재 픽처 내의 주변 참조 샘플을 기반으로 현재 블록에 대한 예측 샘플을 유도할 수 있다. 예측부(830)는 현재 블록의 주변 참조 샘플을 기반으로 방향성 모드 또는 비방향성 모드를 적용하여 현재 블록에 대한 예측 샘플을 유도할 수 있다. 이 때, 주변 블록의 인트라 예측 모드를 이용하여 현재 블록에 적용할 예측 모드가 결정될 수도 있다.
인터 예측의 경우에, 예측부(830)는 참조 픽처 상에서 움직임 벡터에 의해 참조 픽처 상에서 특정되는 샘플을 기반으로 현재 블록에 대한 예측 샘플을 유도할 수 있다. 예측부(830)는 스킵(skip) 모드, 머지(merge) 모드 및 MVP 모드 중 어느 하나를 적용하여 현재 블록에 대한 예측 샘플을 유도할 수 있다. 이때, 비디오 인코딩 장치에서 제공된 현재 블록의 인터 예측에 필요한 움직임 정보, 예컨대 움직임 벡터, 참조 픽처 인덱스 등에 관한 정보는 상기 예측에 관한 정보를 기반으로 획득 또는 유도될 수 있다
스킵 모드와 머지 모드의 경우에, 주변 블록의 움직임 정보가 현재 블록의 움직임 정보로 이용될 수 있다. 이 때, 주변 블록은 공간적 주변 블록과 시간적 주변 블록을 포함할 수 있다.
예측부(830)는 가용한 주변 블록의 움직임 정보로 머지 후보 리스트를 구성하고, 머지 인덱스가 머지 후보 리스트 상에서 지시하는 정보를 현재 블록의 움직임 벡터로 사용할 수 있다. 머지 인덱스는 인코딩 장치로부터 시그널링될 수 있다. 움직임 정보는 움직임 벡터와 참조 픽처를 포함할 수 있다. 스킵 모드와 머지 모드에서 시간적 주변 블록의 움직임 정보가 이용되는 경우에, 참조 픽처 리스트 상의 최상위 픽처가 참조 픽처로서 이용될 수 있다.
스킵 모드의 경우, 머지 모드와 달리 예측 샘플과 원본 샘플 사이의 차이(레지듀얼)이 전송되지 않는다.
MVP 모드의 경우, 주변 블록의 움직임 벡터를 움직임 벡터 예측자(motion vector predictor)로 이용하여 현재 블록의 움직임 벡터가 유도될 수 있다. 이 때, 주변 블록은 공간적 주변 블록과 시간적 주변 블록을 포함할 수 있다.
일 예로, 머지 모드가 적용되는 경우, 복원된 공간적 주변 블록의 움직임 벡터 및/또는 시간적 주변 블록인 Col 블록에 대응하는 움직임 벡터를 이용하여, 머지 후보 리스트가 생성될 수 있다. 머지 모드에서는 머지 후보 리스트에서 선택된 후보 블록의 움직임 벡터가 현재 블록의 움직임 벡터로 사용된다. 상기 예측에 관한 정보는 상기 머지 후보 리스트에 포함된 후보 블록들 중에서 선택된 최적의 움직임 벡터를 갖는 후보 블록을 지시하는 머지 인덱스를 포함할 수 있다. 이 때, 예측부(830)는 상기 머지 인덱스를 이용하여, 현재 블록의 움직임 벡터를 도출할 수 있다.
다른 예로, MVP(Motion Vector Prediction) 모드가 적용되는 경우, 복원된 공간적 주변 블록의 움직임 벡터 및/또는 시간적 주변 블록인 Col 블록에 대응하는 움직임 벡터를 이용하여, 움직임 벡터 예측자 후보 리스트가 생성될 수 있다. 즉, 복원된 공간적 주변 블록의 움직임 벡터 및/또는 시간적 주변 블록인 Col 블록에 대응하는 움직임 벡터는 움직임 벡터 후보로 사용될 수 있다. 상기 예측에 관한 정보는 상기 리스트에 포함된 움직임 벡터 후보 중에서 선택된 최적의 움직임 벡터를 지시하는 예측 움직임 벡터 인덱스를 포함할 수 있다. 이 때, 예측부(830)는 상기 움직임 벡터 인덱스를 이용하여, 움직임 벡터 후보 리스트에 포함된 움직임 벡터 후보 중에서, 현재 블록의 예측 움직임 벡터를 선택할 수 있다. 인코딩 장치의 예측부는 현재 블록의 움직임 벡터와 움직임 벡터 예측자 간의 움직임 벡터 차분(MVD)을 구할 수 있고, 이를 인코딩하여 비트스트림 형태로 출력할 수 있다. 즉, MVD는 현재 블록의 움직임 벡터에서 상기 움직임 벡터 예측자를 뺀 값으로 구해질 수 있다. 이 때, 예측부(830)는 상기 예측에 관한 정보에 포함된 움직임 벡터 차분을 획득하고, 상기 움직임 벡터 차분과 상기 움직임 벡터 예측자의 가산을 통해 현재 블록의 상기 움직임 벡터를 도출할 수 있다. 예측부는 또한 참조 픽처를 지시하는 참조 픽처 인덱스 등을 상기 예측에 관한 정보로부터 획득 또는 유도할 수 있다.
가산부(840)는 레지듀얼 샘플과 예측 샘플을 더하여 현재 블록 혹은 현재 픽처를 복원할 수 있다. 가산부(840)는 레지듀얼 샘플과 예측 샘플을 블록 단위로 더하여 현재 픽처를 복원할 수도 있다. 스킵 모드가 적용된 경우에는 레지듀얼이 전송되지 않으므로, 예측 샘플이 복원 샘플이 될 수 있다. 여기서는 가산부(840)를 별도의 구성으로 설명하였으나, 가산부(840)는 예측부(830)의 일부일 수도 있다. 한편, 가산부(840)는 복원부 또는 복원 블록 생성부로 불릴 수도 있다.
필터부(850)는 복원된 픽처에 디블록킹 필터링 샘플 적응적 오프셋, 및/또는 ALF 등을 적용할 수 있다. 이 때, 샘플 적응적 오프셋은 샘플 단위로 적용될 수 있으며, 디블록킹 필터링 이후 적용될 수도 있다. ALF는 디블록킹 필터링 및/또는 샘플 적응적 오프셋 이후 적용될 수도 있다.
메모리(860)는 복원 픽처(디코딩된 픽처) 또는 디코딩에 필요한 정보를 저장할 수 있다. 여기서 복원 픽처는 상기 필터부(850)에 의하여 필터링 절차가 완료된 복원 픽처일 수 있다. 예컨대, 메모리(860)는 인터 예측에 사용되는 픽처들을 저장할 수 있다. 이 때, 인터 예측에 사용되는 픽처들은 참조 픽처 세트 혹은 참조 픽처 리스트에 의해 지정될 수도 있다. 복원된 픽처는 다른 픽처에 대한 참조 픽처로서 이용될 수 있다. 또한, 메모리(860)는 복원된 픽처를 출력 순서에 따라서 출력할 수도 있다.
도 14는 코딩된 데이터에 대한 계층 구조를 예시적으로 나타낸다.
도 14를 참조하면, 코딩된 데이터는 비디오/이미지의 코딩 처리 및 그 자체를 다루는 VCL(video coding layer)과 코딩된 비디오/이미지의 데이터를 저장하고 전송하는 하위 시스템과의 사이에 있는 NAL(Network abstraction layer)로 구분될 수 있다.
NAL의 기본 단위인 NAL 유닛은 코딩된 영상을 소정의 규격에 따른 파일 포맷, RTP(Real-time Transport Protocol), TS(Transport Strea) 등과 같은 하위 시스템의 비트열에 매핑시키는 역할을 한다.
한편, VCL은 시퀀스와 픽처 등의 헤더에 해당하는 파라미터 세트(픽처 파라미터 세트, 시퀀스 파라미터 세트, 비디오 파라미터 세트 등) 및 비디오/이미지의 코딩 과정에, 디스플레이 등의 관련 절차에 부가적으로 필요한 SEI(Supplemental enhancement information) 메시지는 비디오/이미지에 대한 정보(슬라이스 데이터)와 분리되어 있다. 비디오/이미지에 대한 정보를 포함한 VCL은 슬라이스 데이터와 슬라이스 헤더로 이루어진다.
도시된 바와 같이 NAL 유닛은 NAL 유닛 헤더와 VCL에서 생성된 RBSP(Raw Byte Sequence Payload)의 두 부분으로 구성된다. NAL 유닛 헤더에는 해당 NAL 유닛의 타입에 대한 정보가 포함되어 있다.
NAL 유닛은 VCL에서 생성된 RBSP에 따라 VCL NAL 유닛과 non-VCL NAL 유닛으로 구분된다. VCL NAL 유닛은 비디오/이미지에 대한 정보를 포함하고 있는 NAL 유닛을 의미하고, non-VCL NAL 유닛은 비디오/이미지를 코딩하기 위하여 필요한 정보(파라미터 세트 또는 SEI 메시지)를 포함하고 있는 NAL 유닛을 나타낸다. VCL NAL 유닛은 해당 NAL 유닛이 포함하는 픽처의 성질 및 종류 등에 따라 여러 타입으로 나뉠 수 있다.
본 발명은 360도 비디오를 전송하는 방법 및 360도 비디오를 수신하는 방법과 관련될 수 있다. 본 발명에 따른 360도 비디오를 전송/수신하는 방법은, 각각 전술한 본 발명에 따른 360도 비디오 전송/수신 장치 또는 그 장치의 실시예들에 의해 수행될 수 있다.
전술한 본 발명에 따른 360도 비디오 전송/수신 장치, 전송/수신 방법의 각각의 실시예 및 그 내/외부 엘리멘트 각각의 실시예들을 서로 조합될 수 있다. 예를 들어 프로젝션 처리부의 실시예들과, 데이터 인코더의 실시예들은 서로 조합되어, 그 경우의 수만큼의 360도 비디오 전송 장치의 실시예들을 만들어 낼 수 있다. 이렇게 조합된 실시예들 역시 본 발명의 범위에 포함된다.
본 발명에 따르면 사용자 시점 기반 효율적 프로세싱을 위하여 영역 기반 독립적 프로세싱을 지원할 수 있다. 이를 위하여 영상의 특정 영역을 추출 및/또는 처리하여 독립적인 비트스트림을 구성할 수 있으며, 상기 특정 영역 추출 및/또는 처리를 위한 파일포맷이 구성될 수 있다. 이 경우 상기 추출된 영역의 원 좌표 정보를 시그널링하여 수신단에서의 효율적인 영상 영역 디코딩 및 렌더링을 지원할 수 있다. 이하, 입력 영상의 독립적 프로세싱이 지원되는 영역은 서브픽처(sub-picture)라고 불릴 수 있다. 상기 입력 영상은 인코딩 전에 서브픽처 시퀀스들로 분할(split)될 수 있으며, 각 서브픽처 시퀀스는 360도 비디오 컨텐츠의 공간적 에어리어(spatial area)의 서브셋(subset)을 커버할 수 있다. 각 서브픽처 시퀀스는 독립적으로 인코딩되어 단일 계층(single-layer) 비트스트림으로 출력될 수 있다. 각 서브픽처 비트스트림은 개별적 트랙(track) 기반으로 파일 내에 인캡슐레이션될 수 있고 스트리밍될 수도 있다. 이 경우 수신 장치는 전체 영역을 커버하는 트랙들을 디코딩 및 렌더링할 수 있고, 또는 오리엔테이션 및 뷰포트에 관한 메타데이터 등을 기반으로 특정 서브픽처에 관련된 트랙을 선택하여 디코딩 및 렌더링할 수도 있다.
도 15은 영역 기반 독립적 프로세싱의 일 예인 MCTS(motion constraint tile set) 추출 및 전달 프로세스를 예시적으로 나타낸다.
도 15을 참조하면, 전송 장치는 입력 영상을 인코딩한다. 여기서 입력 영상은 상술한 프로젝션된 픽처(projected picture) 또는 팩드 픽처(packed picture)에 대응할 수 있다.
일 예로, 전송 장치는 입력 영상을 일반 HEVC 인코딩 절차에 따라 인코딩할 수 있다(1-1). 이 경우 입력 영상은 인코딩되어 하나의 HEVC 비트스트림(HEVC bs)으로 출력될 수 있다(1-1-a).
다른 예로, 입력 영상은 영역 기반 독립적 인코딩(HEVC MCTS 인코딩)이 수행될 수 있다(1-2). 이를 통하여 복수의 영역들에 대한 MCTS 스트림이 출력될 수 있다(1-2-b). 또는 MCTS 스트림에서 일부 영역을 추출하여 하나의 HEVC 비트스트림으로 출력할 수도 있다(1-2-a). 이 경우 일부 영역의 디코딩 및 복원을 위한 온전한 정보가 상기 비트스트림에 포함되며 따라서 수신단에서는 상기 일부 영역에 대한 하나의 비트스트림을 기반으로 상기 일부 영역을 온전하게 복원할 수 있다. MCTS 스트림은 MCTS 비트스트림이라고 불릴 수 있다.
전송 장치는 (1-1-a) 또는 (1-2-a)에 따른 인코딩된 HEVC 비트스트림을 저장 및 전송을 위한 파일 내 하나의 트랙으로 인캡슐레이션하고(2-1), 수신 장치로 전달할 수 있다(2-1-a). 이 경우 해당 트랙은 예를 들어, hvcX, hevX 등의 식별자로 나타내어질 수 있다.
한편, 전송 장치는 (1-2-b)에 따른 인코딩된 MCTS 스트림을 저장 및 전송을 위한 파일로 인캡슐레이션할 수 있다(2-2). 일 예로, 전송 장치는 독립적 프로세싱을 위한 MCTS들을 개별 트랙으로 인캡슐레이션하여 전달할 수 있다(2-2-b). 이 때 전체 MCTS 스트림의 프로세싱을 위한 베이스 트랙(base track) 또는 일부 MCTS 영역을 추출하여 프로세싱하기 위한 익스트랙터 트랙(extractor track) 등의 정보가 파일에 함께 포함될 수 있다. 이 경우 상기 개별 트랙은 예를 들어, hvcX, hevX 등의 식별자로 나타내어질 수 있다. 다른 예로, 전송 장치는 익스트랙터 트랙을 이용하여 하나의 MCTS 영역에 대한 트랙을 포함하는 파일을 인캡슐레이션하여 전달할 수도 있다(2-2-a). 즉, 전송 장치는 하나의 MCTS에 해당하는 트랙만 추출하여 전달할 수 있다. 이 경우 해당 트랙은 예를 들어, hvt1 등의 식별자로 나타내어질 수 있다.
수신 장치는 (2-1-a) 또는 (2-2-a)에 따른 파일을 수신하여, 디캡슐레이션 절차를 수행하고(4-1), HEVC 비트스트림을 도출할 수 있다(4-1-a). 이 경우 수신 장치는 수신된 파일 내 하나의 트랙을 디캡슐레이션하여 하나의 비트스트림을 도출할 수 있다.
한편, 수신 장치는 (2-2-b)에 따른 파일을 수신하여, 디캡슐레이션 절차를 수행하고(4-2), MCTS 스트림 또는 하나의 HEVC 비트스트림을 도출할 수 있다. 일 예로, 수신 장치는 파일 내 모든 영역에 해당하는 MCTS들의 트랙들과 베이스 트랙이 포함되어 있을 경우, 전체 MCTS 스트림을 추출할 수 있다(4-2-b). 다른 예로, 수신 장치는 파일 내 익스트랙터 트랙이 포함되어 있을 경우, 해당 MCTS 트랙을 추출한 후 디캡슐레이션하여 하나의 (HEVC) 비트스트림을 생성할 수 있다(4-2-a).
수신 장치는 (4-1-a) 또는 (4-2-a)에 따른 하나의 비트스트림을 디코딩하여 출력 영상을 생성할 수 있다(5-1). 여기서, (4-2-a)에 따른 하나의 비트스트림을 디코딩하는 경우 출력 영상의 일부 MCTS 영역에 대한 출력 영상일 수 있다. 또는 수신 장치는 (4-2-b)에 따른 MCTS 스트림을 디코딩하여 출력 영상을 생성할 수 있다(5-2).
도 16은 영역 기반 독립적 프로세싱 지원을 위한 이미지 프레임의 예를 나타낸다. 상술한 바와 같이 독립적 프로세싱을 지원하는 상기 영역은 서브픽처로 불릴 수 있다.
도 16을 참조하면, 하나의 입력 영상은 좌, 우 두개의 MCTS 영역으로 구성될 수 있다. 도 15에서 상술한 1-2 내지 5-2 절차를 통해 인코딩/디코딩되는 이미지 프레임의 형상은 도 16의 (A) 내지 (D)와 같거나 그 일부에 해당할 수 있다.
도 16에서 (A)는 1, 2 영역이 모두 존재하며, 개별 영역 독립/병렬 프로세싱이 가능한 이미지 프레임을 나타낸다. (B)는 1 영역만 존재하며, 절반의 가로 해상도를 갖는 독립된 이미지 프레임을 나타낸다. (C)는 2 영역만 존재하며, 절반의 가로 해상도를 갖는 독립된 이미지 프레임을 나타낸다. (D)는 1, 2 영역이 모두 존재하며, 개별 영역 독립/병렬 프로세싱 지원 없이 프로세싱이 가능한 이미지 프레임을 나타낸다.
상기와 같은 이미지 프레임 도출을 위한 1-2-b와 4-2-b의 비트스트림 구성은 다음과 같거나 그 일부에 해당할 수 있다.
도 17는 영역 기반 독립적 프로세싱 지원을 위한 비트스트림 구성의 예를 나타낸다.
도 17를 참조하면, VSP는 VPS, SPS, 및 PPS를 나타내며, VSP1은 1번 영역에 대한 VSP, VSP2는 2번 영역에 대한 VSP, VSP12는 1번 및 2번 영역 둘 다에 대한 VSP를 나타낸다. 또한, VCL1은 1번 영역에 대한 VCL, VCL2는 2번 영역에 대한 VCL을 나타낸다.
도 17에서, (a)는 1, 2 모든 영역의 독립/병렬 프로세싱이 가능한 이미지 프레임들을 위한 Non-VCL NAL 유닛들(예를 들어, VPS NAL 유닛, SPS NAL 유닛, PPS NAL 유닛 등)을 나타낸다. (b)는 1 영역만 존재하며, 절반의 해상도를 갖는 이미지 프레임들을 위한 Non-VCL NAL 유닛들(예를 들어, VPS NAL 유닛, SPS NAL 유닛, PPS NAL 유닛 등)을 나타낸다. (c)는 2 영역만 존재하며, 절반의 해상도를 갖는 이미지 프레임들을 위한 Non-VCL NAL 유닛들(예를 들어, VPS NAL 유닛, SPS NAL 유닛, PPS NAL 유닛 등)을 나타낸다. (d)는 1, 2 영역 모두가 존재하며, 개별 영역 독립/병렬 프로세싱 지원 없이 프로세싱이 가능한 이미지 프레임들을 위한 Non-VCL NAL 유닛들(예를 들어, VPS NAL 유닛, SPS NAL 유닛, PPS NAL 유닛 등)을 나타낸다. (e)는 1 영역의 VCL NAL 유닛들을 나타낸다. (f)는 2 영역의 VCL NAL 유닛들을 나타낸다.
예를 들어, 이미지 프레임 (A) 생성을 위하여는 (a), (e), (f)의 NAL 유닛들을 포함하는 비트스트림이 생성될 수 있다. 이미지 프레임 (B) 생성을 위하여는 (b), (e)의 NAL 유닛들을 포함하는 비트스트림이 생성될 수 있다. 이미지 프레임 (C) 생성을 위하여는 (c), (f)의 NAL 유닛들을 포함하는 비트스트림이 생성될 수 있다. 이미지 프레임 (D) 생성을 위하여는 (d), (e), (f)의 NAL 유닛들을 포함하는 비트스트림이 생성될 수 있다. 이 경우 픽처 상에서 특정 영역의 위치를 지시하는 정보(예를 들어, 후술되는 mcts_sub_bitstream_region_in_original_picture_coordinate_info() 등)는 (B), (C), (D)와 같은 이미지 프레임 등을 위한 비트스트림에 포함되어 전달될 수 있으며, 이 경우 상기 정보는 선택된 영역의 원본 프레임에서의 위치 정보를 식별가능하게 할 수 있다.
2 영역만 선택된 경우와 같이(비트스트림이 (c), (f) NAL 유닛들 포함) 선택된 영역이 원본 이미지 프레임의 기준이 되는 좌상단 끝에 위치하지 않는 경우, 슬라이스 세그먼트 헤더(slice segment header)의 슬라이스 세그먼트 어드레스(slice segment address)를 비트스트림 추출과정에서 수정하는 등의 프로세스가 수반될 수도 잇다.
도 18은 본 발명에 따른 파일의 트랙 구성을 예시적으로 나타낸다. 도 15에서 상술한 2-2-a 또는 4-2-a와 같이 특정 영역에 대하여 선택적으로 인캡슐레이션하거나 코딩하는 경우, 관련 파일 구성은 다음 경우들과 같거나 그 일부를 포함할 수 있다.
도 18을 참조하면, 도 15에서 상술한 2-2-a 또는 4-2-a와 같이 특정 영역에 대하여 선택적으로 인캡슐레이션하거나 코딩하는 경우, 관련 파일 구성은 다음 경우들을 포함하거나 그 일부를 포함할 수 있다.
(1) 하나의 트랙(10)이 (b), (e)의 NAL 유닛들을 포함하는 경우,
(2) 하나의 트랙(20)이 (c), (f)의 NAL 유닛들을 포함하는 경우,
(3) 하나의 트랙(30)이 (d), (e), (f)의 NAL 유닛들을 포함하는 경우.
또한, 상기 관련 파일 구성은 다음과 같은 트랙들을 모두 포함하거나 일부 트랙들의 조합을 포함할 수도 있다.
(4) (a)를 포함하는 베이스 트랙(40)
(5) (d)를 포함하며 (e)와 (f)에 접근하기 위한 익스트랙터(ex. ext1, ext2)를 갖는 익스트랙터 트랙(50)
(6) (b)를 포함하며 (e)에 접근하기 위한 익스트랙터를 갖는 익스트랙터 트랙(60)
(7) (c)를 포함하며 (f)에 접근하기 위한 익스트랙터를 갖는 익스트랙터 트랙(70)
(8) (e)를 포함하는 타일 트랙(80)
(9) (f)를 포함하는 타일 트랙(90)
이 경우, 이 경우 픽처 상에서 특정 영역의 위치를 지시하는 정보는 후술하는 RegionOriginalCoordninateBox 등의 박스 형태로 상술한 트랙들(10, 20, 30, 50, 60, 70 등)에 포함되어 선택된 영역의 원본 프레임에서의 위치 정보를 식별 가능하게 할 수 있다. 여기서 상기 영역은 서브픽처로 불릴 수 있음은 상술한 바와 같다. 서비스 프로바이더는 상술한 트랙들을 모두 구성할 수 있으며, 전송시에는 일부만 선택 및 조합해서 전달할 수 있다.
도 19는 본 발명의 일 예에 따른 RegionOriginalCoordninateBox를 나타낸다. 도 20는 원본 픽처 내에서 해당 정보가 가리키는 영역을 예시적으로 나타낸다.
도 19를 참조하면, RegionOriginalCoordninateBox는 본 발명에 따른 영역 기반 독립 프로세싱이 가능한 영역(서브픽처, 또는 MCTS)의 사이즈 및/또는 위치를 알려주는 정보이다. 구체적으로 RegionOriginalCoordninateBox는 하나의 비주얼 컨텐츠가 하나 이상의 영역(region)으로 나누어져 저장/전송될 경우, 해당 영역이 전체 비주얼 컨텐츠의 좌표(coordinate) 상에서 어느 위치에 존재하는지 식별하기 위해 사용될 수 있다. 예를 들어, 전체 360도 비디오를 위한 팩드 프레임(팩드 픽처) 또는 프로젝션된 프레임(프로젝티드 픽처)이 사용자 시점 기반 효율적 프로세싱을 위해 독립된 비디오 스트림의 형태로 여려 개별 영역으로 저장/전송될 수 있으며, 하나의 트랙은 하나 또는 또는 여러 개의 타일로 구성되는 사각형 영역에 대응될 수 있다. 개별 영역은 HEVC MCTS 비트스트림으로부터 추출(extraction)된 HEVC 비트스트림들에 대응될 수도 있다. RegionOriginalCoordninateBox는 개별 여역이 저장/전송되는 트랙의 비주얼 샘플 엔트리(visual sample entry) 하위에 존재하여 해당 영역의 좌표 정보를 기술할 수 있다. RegionOriginalCoordninateBox는 비주얼 샘플 엔트리 외의 스킴 정보 박스(scheme information box) 등 다른 박스의 하위에 계층적으로 존재할 수도 있다.
RegionOriginalCoordninateBox의 신텍스(syntax)는 original_picture_width 필드, original_picture_height 필드, region_horizontal_left_offset 필드, region_vertical_top_offset 필드, region_width 필드, region_height 필드를 포함할 수 있다. 상기 필드들 중 일부는 생략될 수 있다. 예를 들어, 원본 픽처의 사이즈가 미리 정의되어 있거나 다른 박스 등의 정보를 통하여 이미 획득된 경우 상기 original_picture_width 필드, original_picture_height 필드 등은 생략될 수 있다.
original_picture_width 필드는 해당 리전(서브픽처 또는 타일)이 속한 원본 픽처(즉, 팩드 프레임 또는 프로젝션된 프레임)의 가로 해상도(너비)를 나타낸다. original_picture_height 필드는 해당 리전(서브픽처 또는 타일)이 속한 원본 픽처(즉, 팩드 프레임 또는 프로젝션된 프레임)의 세로 해상도(높이)를 나타낸다. , region_horizontal_left_offset 필드는 원본 픽처 좌표 기준 해당 리전의 좌측 끝의 가로 좌표를 나타낸다. 예를 들어 상기 필드는 원본 픽처의 좌상단 끝의 좌표를 기준으로 상기 해당 리전의 좌측 끝의 가로 좌표의 값을 나타낼 수 있다. region_vertical_top_offset 필드는 원본 픽처 좌표 기준 해당 리전의 좌측 끝의 세로 좌표를 나타낸다. 예를 들어 상기 필드는 원본 픽처의 좌상단 끝의 좌표를 기준으로 상기 해당 리전의 상측 끝의 세로 좌표의 값을 나타낼 수 있다. region_width 필드는 해당 리전의 가로 해상도(너비)를 나타낸다. region_height 필드는 해당 리전의 세로 해상도(높이)를 나타낸다. 상술한 필드들을 기반으로 해당 영역은 원본 픽처로부터 도 20와 같이 도출될 수 있다.
한편, 본 발명의 일 실시예에 따르면 RegionToTrackBox가 사용될 수도 있다.
도 21은 본 발명의 일 실시예에 따른 RegionToTrackBox를 나타낸다.
RegionToTrackBox는 해당 영역과 연관되는 트랙을 식별하게 할 수 있다. 상기 박스(박스 형태의 정보)는 트랙마다 보낼 수도 있고, 대표 트랙에서만 보낼 수도 있다. RegionToTrackBox는 프로젝션, 패킹 정보 등 360도 비디오 정보와 함께 'schi' 박스 하위에 저장될 수 있다. 이 경우 원본 픽처의 가로 해상도, 세로 해상도는 트랙 헤더 박스(track header box) 또는 비주얼 샘플 엔트리(visual sample entry)에 존재하는 (원본 픽처의) 폭, 너비 값으로 식별될 수도 있다. 또한 상기 박스를 나르는 트랙과 개별 리전이 저장/전송되는 트랙은 트랙 참조 박스(track reference box)에서 'ovrf'(omnidirectional video reference)와 같은 새로운 참조 타입(reference type)에 의해 참조 관계가 식별될 수 있다.
상기 박스는 스킴 정보 박스(Scheme Information box) 외의 비주얼 샘플 엔ㅌ리(visual sample entry) 등 다른 박스의 하위에 계층적으로 존재할 수도 있다.
RegionToTrackBox의 신텍스(syntax)는 num_regions 필드를 포함할 수 있고, 및 각 영역에 대한 region_horizontal_left_offset 필드, region_vertical_top_offset 필드, region_width 필드, region_width 필드 및 track_ID 필드를 포함할 수 있다. 경우에 따라 상기 필드들 중 일부는 생략될 수 있다.
num_region 필드는 원본 픽처 내 영역들의 개수를 나타낸다. region_horizontal_left_offset 필드는 원본 픽처 좌표 기준 해당 리전의 좌측 끝의 가로 좌표를 나타낸다. 예를 들어 상기 필드는 원본 픽처의 좌상단 끝의 좌표를 기준으로 상기 해당 리전의 좌측 끝의 가로 좌표의 값을 나타낼 수 있다. region_vertical_top_offset 필드는 원본 픽처 좌표 기준 해당 리전의 좌측 끝의 세로 좌표를 나타낸다. 예를 들어 상기 필드는 원본 픽처의 좌상단 끝의 좌표를 기준으로 상기 해당 리전의 상측 끝의 세로 좌표의 값을 나타낼 수 있다. region_width 필드는 해당 리전의 가로 해상도(너비)를 나타낸다. region_height 필드는 해당 리전의 세로 해상도(높이)를 나타낸다. Track_ID 필드는 해당 리전에 해당하는 데이터가 저장/전송되는 트랙의 ID를 나타낸다.
한편, 본 발명의 일 실시예에 따르면 SEI 메시지에 다음과 같은 정보가 포함될 수 있다.
도 22은 본 발명의 일 실시예에 따른 SEI 메시지를 나타낸다.
도 22을 참조하면, num_sub_bs_region_coordinate_info_minus1[　i　] 필드는 추출 정보에 해당하는 mcts_sub_bitstream_region_in_original_picture_coordinate_info 의 개수 - 1 값을 나타낸다. sub_bs_region_coordinate_info_data_length[　i　][　j　] 필드는 포함된 개별 mcts_sub_bitstream_region_in_original_picture_coordinate_info의 바이트수를 나타낸다. 상기 num_sub_bs_region_coordinate_info_minus1[　i　] 필드 및 sub_bs_region_coordinate_info_data_length[　i　][　j　] 필드는 무부호 정수 0차 지수 골룸(unsigned integer 0-th Exp-Golomb) 코딩을 나타내는 ue(v)를 기반으로 코딩될 수 있다. 여기서 (v)는 해당 정보를 코딩하는데 사용되는 비트가 가변적임을 나타낼 수 있다. sub_bs_region_coordinate_info_data_bytes[　i　][　j　][　k　] 필드는 포함된 개별 mcts_sub_bitstream_region_in_original_picture_coordinate_info의 바이트들을 나타낸다. 상기 sub_bs_region_coordinate_info_data_bytes[　i　][　j　][　k　] 필드는 8비트를 사용하는 무부호 정수 0차 코딩을 나타내는 u(8)를 기반으로 코딩될 수 있다.
도 23은 본 발명의 일 실시예에 따른 mcts_sub_bitstream_region_in_original_picture_coordinate_info를 나타낸다. mcts_sub_bitstream_region_in_original_picture_coordinate_info는 상기 SEI 메시지에 계층적으로 포함될 수 있다.
도 23을 참조하면, original_picture_width_in_luma_sample 필드는 추출(extraction)된 MCTS 서브비트스트림 영역(sub-bitstream region) 추출전 원본 픽처(즉, 팩드 프레임 또는 프로젝션된 프레임)의 가로 해상도를 나타낸다. original_picture_height_in_luma_sample 필드는 추출(extraction)된 MCTS 서브비트스트림 영역(sub-bitstream region) 추출전 원본 픽처(즉, 팩드 프레임 또는 프로젝션된 프레임)의 세로 해상도를 나타낸다. sub_bitstream_region_horizontal_left_offset_in_luma_sample 필드는 원본 픽처 좌표 기준 해당 영역의 좌측 끝 가로 좌표를 나타낸다. sub_bitstream_region_vertical_top_offset_in_luma_sample 필드는 원본 픽처 좌표 기준 해당 영역의 위쪽 끝 세로 좌표를 나타낸다. sub_bitstream_region_width_in_luma_sample 필드는 해당 영역의 가로 해상도를 나타낸다. sub_bitstream_region_height_in_luma_sample 필드는 해당 영역의 세로 해상도를 나타낸다.
한편, 하나의 파일 내에 모든 MCTS 비트스트림들이 존재할 경우, 특정 MCTS 영역에 대한 데이터 추출을 위하여 다음과 같은 정보가 사용될 수 있다.
도 24는 본 발명의 일 실시예에 따른 다수의 MCTS 비트스트림을 포함하는 파일 내의 MCTS 영역 관련 정보를 나타낸다.
도 24를 참조하면, 추출된 MCTS 비트스트림들은 샘플 그룹핑을 통해 하나의 그룹으로 정의될 수 있으며, 앞서 설명한 해당 MCTS와 연관된 VPS, SPS, PPS 등은 도 24의 nalUnit 필드에 포함될 수 있다. NAL_unit_type 필드는 상기 VPS, SPS, PPS 등 중 하나를 해당 NAL 유닛의 타입으로 지시할 수 있으며, 지시된 타입의 NAL 유닛(들)이 상기 nalUnit 필드에 포함될 수 있다.
본 발명에서 상술한 독립적 프로세싱이 지원되는 영역, MCTS 영역 등은 그 표현에 차이가 있으나, 동일한 의미로 사용될 수 있으며, 서브픽처(sub-picture)라고 불릴 수 있음은 상술한 바와 같다. 전방향의 360도 비디오는 서브픽처 트랙들로 구성된 파일을 통하여 저장 및 전달될 수 있으며, 이는 사용자 시점 또는 뷰포트 기반 프로세싱(viewport dependent processing)을 위하여 사용될 수 있다. 상기 서브픽처들은 원본 픽처의 공간적 에어리어의 서브셋일 수 있으며, 각각의 서브픽처들은 일반적으로 개별 트랙(separate track)에 저장될 수 있다.
뷰포트 기반 프로세싱은 예를 들어 다음과 같은 플로우를 기반으로 수행될 수 있다.
도 25은 본 발명의 일실시예에 따른 뷰포트 기반 프로세싱을 나타낸다.
도 25을 참조하면, 수신 장치는 헤드(head) 및/또는 아이(eye) 트랙킹을 수행한다(S2010). 수신 장치는 헤드 및 또는 아이 트랙킹을 통하여 뷰포트 정보를 도출한다
수신 장치는 전달받은 파일에 대한 파일/세그먼트 디캡슐레이션을 수행한다(S2020). 이 경우 수신 장치는 좌표 컨버젼을 통하여 현재 뷰포트에 대응하는 영역들(뷰포트 영역들)을 파악할 수 있고(S2021). 상기 뷰포트 영역들을 커버하는 서브픽처들을 포함하는(containing) 트랙들을 선택 및 추출할 수 있다(S2022).
수신 장치는 선택된 트랙(들)에 대한 (서브)비트스트림(들)을 디코딩한다(S2030). 수신 장치는 상기 디코딩을 통하여 서브픽처들을 디코딩/복원할 수 있다. 이 경우 기존 디코딩 절차에서는 원본 픽처 단위로 디코딩을 수행하였던 것과 달리, 수신 장치는 원본 픽처가 전체가 아닌 상기 서브픽처들만을 디코딩할 수 있다.
수신 장치는 좌표 컨버전을 통하여 디코딩된 서브픽처(들)을 렌더링 공간(rendering space)에 맵핑한다(S2040). 이는 전체 픽처가 아닌 서브픽처(들)에 대한 디코딩을 수행하기 때문에, 해당 서브픽처가 원본 픽처의 어느 위치에 해당한다는 정보를 기반으로 렌더링 공간에 맵핑할 수 있고, 뷰포트 기반 프로세싱을 수행할 수 있다. 수신 장치는 해당 뷰포트에 연관된 이미지(뷰포트 이미지)를 생성하여 사용자에게 디스플레이할 수 있다(S2050).
상기와 같이 서브픽처들에 대한 좌표 컨버전 절차가 렌더링 절차에 필요할 수 있다. 이는 종래의 360도 비디오 프로세싱 절차에서는 필요하지 않았던 절차이다. 본 발며에 따르면 전체 픽처가 아닌 서브픽처(들)에 대한 디코딩을 수행하기 때문에, 해당 서브픽처가 원본 픽처의 어느 위치에 해당한다는 정보를 기반으로 렌더링 공간에 맵핑할 수 있고, 뷰포트 기반 프로세싱을 수행할 수 있다.
즉, 서브픽처 단위 디코딩 후, 디코딩된 픽처는 적절한 렌더링을 위하여 정렬될 필요가 있을 수 있다. 팩드 프레임은 프로젝션된 프레임으로 재정렬될 수 있으며(만약 리전별 패킹 과정에 적용된 경우), 프로젝션된 프레임은 렌더링을 위하여 프로젝션 구조(projection structure)에 따라 정렬될 수 있다. 따라서, 서브픽처들을 나르는 트랙들의 커버리지 정보의 시그널링에서 팩드 프레임/프로젝션된 프레임 상의 2D 좌표가 나타내어지는 경우, 디코딩된 서브픽처는 렌더링 전에 팩드 프레임/프로젝션된 프레임에(into) 정렬될 수 있다. 여기서 커버리지 정보는 상술한 본 발명에 따른 영역의 위치(위치 및 사이즈)를 나타내는 정보를 포함할 수 있다.
한편, 본 발명에 따르면 하나의 서브픽처라도 팩드 프레임/프로젝션된 프레임 상에서 공간적으로 떨어져서 구성될 수 있다. 이 경우 하나의 서브픽처 내에 2D 공간 상에서 서로 떨어져있는 영역들은 서브픽처 영역(subpicture region)들이라고 불릴 수 있다. 예를 들어, 프로젝션 포멧으로 ERP(Equirectangular Projection) 포멧이 사용된 경우, 팩드 프레임/프로젝션된 프레임의 왼쪽 끝과 오른쪽 끝은 실제로 렌더링되는 구형면 상에서는 서로 붙어있을 수 있다. 이를 커버하기 위하여 팩드 프레임/프로젝션된 프레임 상에서 공간적으로 서로 떨어져있는 서브픽처 영역들이 하나의 서브픽처로 구성될 수 있으며, 관련 커버리지 정보 및 서브픽처 구성은 예를 들어 다음과 같을 수 있다.
도 26은 본 발명의 일 실시예에 따른 커버리지 정보를 나타내고, 도 27는 본 발명의 일 실시예에 따른 서브픽처 구성을 나타낸다. 도 27의 서브픽처 구성은 도 26에 도시된 커버리지 정보를 기반으로 도출될 수 있다.
도 26을 참조하면, ori_pic_width 필드 및 ori_pic_height 필드는 서브픽처들을 구성하는 전체 원본 픽처의 너비 및 높이를 각각 나타낸다. 서비픽처의 너비 및 높이는 비주얼 샘플 엔트리 내에서의 너비 및 높이로 나타내어질 수 있다. sub_pic_reg_flag 필드는 서브픽처 리전의 존재 여부를 나타낸다. sub_pic_reg_flag 필드의 값이 0인 경우, 서브픽처가 온전하게 원본 픽처 상으로 정렬됨을 나타낸다. sub_pic_reg_flag 필드의 값이 1인 경우, 서브픽처는 서브픽처 리전들로 나누어지고, 각 서브픽처 리전은 프레임(원본 픽처) 상으로 정렬됨을 나타낼 수 있다. 도 26에서 도시된 바와 같이 서브픽처 리전들은 프레임의 경계를 가로질러서 정렬될 수 있다. sub_pic_on_ori_pic_top 필드 및 sub_pic_on_ori_pic_left 필드는 원본 픽처 상에서 서브픽처의 가장 상측 샘플 행(top sample row) 및 가장 좌측 샘플 열(left-most sample column)을 각각 나타낸다. sub_pic_on_ori_pic_top 필드 및 sub_pic_on_ori_pic_left 필드의 값들의 범위는 각각 원본 픽처의 좌상단(top-left) 코너를 가리키는 0부터(inclusive), ori_pic_height 필드의 값 및 ori_pic_width 필드의 값까지(exclusive)일 수 있다. num_sub_pic_regions 필드는 서브픽처를 구성하는 서브픽처 리전들의 개수를 나타낸다. sub_pic_reg_top[i] 필드 및 sub_pic_reg_left[i] 필드는 각각 서브픽처 상에서 해당(i번) 서브픽처 리전의 가장 상측 샘플 행 및 가장 좌측 샘플 열을 나타낸다. 이 필드들을 통하여 하나의 서브픽처 내에 있는 복수의 서브픽처 리전들 간의 연관관계(위치 순서 및 배치)를 도출할 수 있다. sub_pic_reg_top[i] 필드 및 sub_pic_reg_left[i] 필드의 값들이 범위는 각각 서브픽처의 좌상단 코너를 가리키는 0부터(inclusive), 상기 서브픽처의 너비 및 높이까지(exclusive)일 수 있다. 여기서 상기 서브픽처의 너비 및 높이는 비주얼 샘플 엔터리에서 도출될 수 있다. sub_pic_reg_width[i] 필드 및 sub_pic_reg_height[i] 필드는 각각 해당(i번) 서브픽처 리전의 너비 및 높이를 나타낸다. sub_pic_reg_width[i] 필드의 값들의 합(i는 0부터 num_sub_pic_regions 필드의 값 -1까지)은 서브픽처의 너비와 같을 수 있다. 또는 sub_pic_reg_height[i] 필드의 값들의 합(i는 0부터 num_sub_pic_regions 필드의 값 -1까지)은 상기 서브픽처의 높이와 같을 수 있다. sub_pic_reg_on_ori_pic_top[i] 필드 및 sub_pic_reg_on_ori_pic_left[i] 필드는 각각 원본 픽처 상에서 해당 서브픽처 영역의 가장상측 샘플 행 및 가장좌측 샘플 열을 나타낸다. sub_pic_reg_on_ori_pic_top[i] 필드 및 sub_pic_reg_on_ori_pic_left[i] 필드의 값들의 범위는 각각 프로젝티드 프레임의 좌상단 코너를 가리키는 0부터(inclusive), ori_pic_height 필드의 값 및 ori_pic_width 필드의 값까지(exclusive)일 수 있다.
상술한 예에서는 하나의 서브픽처가 복수의 서브픽처 리전들을 포함하는 경우를 설명하였으며, 본 발명에 따르면 서브픽처들이 오버랩되어 구성될 수도 있다. 각 서브픽처 비트스트림은 한번에 하나의 비디오 디코더에 의하여 배타적으로(exclusively) 디코딩되는 것을 가정하는 경우, 오버랩된 서브픽처들은 비디오 디코더들의 수를 제한하기 위하여 사용될 수 있다.
도 28은 본 발명의 일 실시예에 따른 오버랩된 서브픽처들을 나타낸다. 도 28은 소스 컨텐츠(예를 들어, 원본 픽처) 7개의 사각 영역들로 분할되고, 상기 영역들이 7개의 서브픽처들로 그룹핑되는 경우이다.
도 28을 참조하면, 서브픽처1은 영역(서브픽처 영역) A 및 B로 구성되고, 서브픽처2는 영역 B 및 C로 구성되고, 서브픽처3은 영역 C 및 D로 구성되고, 서브픽처4는 영역 D 및 E로 구성되고, 서브픽처5는 영역 E 및 A로 구성되고, 서브픽처6은 영역 F로 구성되고, 서브픽처7은 영역 G로 구성된다.
상기와 같은 구성을 통하여, 현재 뷰포트를 위한 서브픽처 비트스트림들의 디코딩에 필요한 비디오 디코더들의 수를 줄일 수 있으며, 특히 뷰포트가 ERP 포멧의 픽처의 사이드에 위치하는 경우에 효율적으로 서브픽처를 추출 및 디코딩할 수 있다.
상술한 트랙 내에 다중 사각 영역들을 포함하는 서브픽처 구성(composition)을 지원하기 위하여, 예를 들어, 다음과 같은 조건이 고려될 수 있다. 하나의 SubpictureCompositionBox는 하나의 사각 영역을 기술(describe)할 수 있다. TrackGroupBox는 다중 SubpictureCompositionBox를 가질 수 있다. 다중 SubpictureCompositionBox의 순서는 서브픽처 내의 사각 영역들의 포지션을 가리킬 수 있다. 여기서 상기 순서는 래스터 스캔 순서(rater scan order)일 수 있다.
track_group_type이 'spco'인 TrackGroupTypeBox는 해당 트랙이, 프리젠테이션을 위한 적합한 픽처들을 획득하기 위하여 공간적으로 정렬될 수 있는 트랙들의 구성에 속함을 지시할 수 있다. 해당 그룹핑에 맵핑된 비주얼 트랙들(즉, track_group_type이 'spco'인 TrackGroupTypeBox 내에서 동일한 track_group_id 값을 갖는 비주얼 트랙들)은 제공될(presented) 수 있는 비주얼 컨텐츠를 집합적으로(collectively) 나타낼 수 있다. 해당 그룹핑에 맵핑된 각 개별적인 비주얼 트랙은 프리젠테이션에 충분할 수 있고 또는 충분하지 않을 수도 있다. 트랙이 구성된 픽처(composed picture) 상의 다중 사각 영역들에 맵핑된 서브픽처 시퀀스를 나르는 경우, 동일한 track_group_id 값을 갖고 track_group_type이 'spco'인 다중 TrackGroupTypeBox가 존재할 수 있다. 상기 박스들은 상기 TrackGroupBox 내에서 서브픽처 상의 사각 영역들의 래스터 스캔 순서에 따라 나타날 수 있다. 이 경우, CompositionRestrictionBox가 비주얼 트랙이 단독으로는(alone) 프리젠테이션을 위하여 충분하지 않음을 지시하기 위하여 사용될 수 있다. 프리젠테이션을 위하여 적합한 픽처는 트랙 그룹의 신텍스 요소들에 의하여 지시된 것과 같이 동일한 서브픽처 구성 트랙 그룹의 모든 트랙의 시간-병렬 샘플들을 공간적으로 정렬함으로써 구성될 수 있다.
도 29는 SubpictureCompositionBox의 신텍스를 나타낸다.
도 29를 참조하면, region_x 필드는, 루마 샘플 단위에서(in luma sample units), 구성된 픽처(composed picture) 상의 해당 트랙의 샘플들의 사각 영역의 좌상단 코너의 수평 포지션을 나타낸다. region_x 필드의 값의 범위는 0부터 composition_width 필드의 값 -1(minus 1)까지일 수 있다. region_y 필드는, 루마 샘플 단위에서, 구성된 픽처 상의 해당 트랙의 샘플들의 사각 영역의 좌상단 코너의 수직 포지션을 나타낸다. region_y 필드의 값의 범위는 0부터 composition_height 필드의 값 -1까지일 수 있다. region_width 필드는, 루마 샘플 단위에서, 구성된 픽처 상의 해당 트랙의 샘플들의 사각 영역의 너비를 나타낸다. region_width 필드의 값의 범위는 1부터 composition_width 필드의 값 -(minus) region_x 필드의 값까지일 수 있다. region_height 필드는, 루마 샘플 단위에서, 구성된 픽처 상의 해당 트랙의 샘플들의 사각 영역의 높이를 나타낸다. region_height 필드의 값의 범위는 1부터 composition_height 필드의 값 -(minus) region_y 필드의 값까지일 수 있다. composition_width 필드는, 루마 샘플 단위에서, 구성된 픽처의 너비를 나타낸다. composition_width 필드의 값은 region_x 필드의 값 +(plus) region_width 필드의 값보다 크거나 같을 수 있다. composition_height 필드는, 루마 샘플 단위에서, 구성된 픽처의 높이를 나타낸다. composition_height 필드의 값은 region_y 필드의 값 +(plus) region_height 필드의 값보다 크거나 같을 수 있다. 구성된 픽처는 상술한 원본 픽처, 팩드 픽처 또는 프로젝션된 픽처에 대응될 수 있다.
한편, 구성된 픽처 내에 맵핑되는 다중 사각형 영역을 포함하는 서브픽처 트랙의 식별을 위하여, 다음과 같은 방법들이 사용될 수도 있다.
일 예로, 상기 사각형 영역을 식별하기 위한 정보는 가드 밴드에 관한 정보를 통하여 시그널링될 수 있다.
3차원 공간에서 연속되는 360도 비디오 데이터가 2D 이미지의 리전에 맵핑되는 경우, 상기 2D 이미지의 리전별로 코딩되어 수신측에 전달될 수 있고, 이에, 상기 2D 이미지에 맵핑된 360도 비디오 데이터가 다시 3차원 공간으로 렌더링되면 각 리전의 코딩 처리의 차이로 인하여 3차원 공간에 리전들 사이의 경계가 나타나는 문제가 발생될 수 있다. 상기 3차원 공간에 상기 리전들 사이의 경계가 나타나는 문제는 경계 오류라고 불릴 수 있다. 상기 경계 오류는 사용자의 가상 현실에 대한 몰입감을 저하시킬 수 있으며, 이러한 문제를 방지하기 위하여 가드 밴드가 사용될 수 있다. 가드 밴드는 직접 렌더링되지는 않으나, 연관된 영역의 렌더링된 부분을 향상시키거나 심(seam)과 같은 비주얼 아티팩트를 회피 또는 완화(mitigate)하기 위하여 사용되는 영역을 나타낼 수 있다. 상기 가드 밴드는 리전별 패킹 과정이 적용되는 경우 사용될 수 있다.
본 예에서는 상기 다중 사각형 영역은 RegionWisePackingBox를 이용하여 식별될 수 있다.
도 30는 RegionWisePackingBox의 계층적 구조를 나타낸다.
도 30를 참조하면, 값 0의 guard_band_flag[i] 필드는 i번(i-th) 영역이 가드 밴드를 가지고 있지 않음을 나타낸다. 값 1의 guard_band_flag[i] 필드는 i번 영역이 가드 밴드를 가지고 있음을 나타낸다. packing_type[i] 필드는 리전별 패킹의 타입을 나타낸다. 값 0의 packing_type[i] 필드는 사각(rectangular) 리전별 패킹을 지시한다. 나머지 값들은 유보될(reserved) 수 있다. left_gb_width[i] 필드는 i번 영역의 좌측의 가드 밴드의 너비를 나타낸다. left_gb_width[i] 필드는 상기 가드 밴드의 너비를 두 루마 샘플 단위(in units of two luma samples)로 나타낼 수 있다. right_gb_width[i] 필드는 i번 영역의 우측의 가드 밴드의 너비를 나타낸다. right_gb_width[i] 필드는 상기 가드 밴드의 너비를 두 루마 샘플 단위로 나타낼 수 있다. top_gb_width[i] 필드는 i번 영역의 상측의 가드 밴드의 너비를 나타낸다. top_gb_width[i] 필드는 상기 가드 밴드의 너비를 두 루마 샘플 단위로 나타낼 수 있다. bottom_gb_width[i] 필드는 i번 영역의 하측의 가드 밴드의 너비를 나타낸다. bottom_gb_width[i] 필드는 상기 가드 밴드의 너비를 두 루마 샘플 단위로 나타낼 수 있다. guard_band_flag[i]의 값이 1인 경우, left_gb_width[i] 필드, right_gb_width[i] 필드, top_gb_width[i] 필드, 또는 bottom_gb_width[i] 필드의 값은 0보다 크다. 상기 i번 영역 및 그의 가드 밴드들은, 다른 영역 및 다른 영역의 가드 밴드들과 오버랩되지 않는다(The i-th region, including its guard bands, if any, shall not overlap with any other region, including its guard bands).
값 0의 gb_not_used_for_pred_flag[i] 필드는 가드 밴드들이 인터 예측을 위하여 가용함을 나타낸다. 즉, gb_not_used_for_pred_flag[i] 필드의 값이 0인 경우, 가드 밴드들은 인터 예측을 위하여 사용되거나 사용되지 않을 수 있다. 값 1의 gb_not_used_for_pred_flag[i] 는 가드 밴드들의 샘플값들이 인터 예측 절차에 사용되지 않음을 나타낸다. gb_not_used_for_pred_flag[i] 필드의 값이 1인 경우, 비록 디코딩된 픽처(디코딩된 팩드 픽처)들이 이후 디코딩될 픽처들(subsequent pictures to be decoded)의 인터 예측을 위한 참조(references)로 사용되었더라도, 디코딩된 픽처들 상의 가드 밴드들 내 샘플 값들은 다시 작성될(rewritten) 또는 수정될 수 있다. 예를 들어, 영역의 컨텐츠는 그의 가드 밴드로, 다른 영역의 디코딩된 및 리프로젝션된 샘플들을 이용하여, 심리스하게 확장될 수 있다.
gb_type[i] 필드는 i번 영역의 가드 밴드들의 타입을 다음과 같이 나타낼 수 있다. 값 0의 gb_type[i] 필드는 해당 영역(들)의 컨텐츠와의 관계에서 해당 가드 밴드들의 컨텐츠가 명시되지 않았음을(unspeficied) 나타낸다. gb_not_used_for_pred_flag 필드의 값이 0인 경우, gb_type 필드의 값은 0이 될 수 없다. 값 1의 gb_type[i] 필드는 가드 밴드들의 컨텐츠가 영역(및 영역 경계 외부 하나의 픽셀 이내) 내의 서브픽셀 값들의 보간을 위하여 충분함을 나타낸다. 값 1의 gb_type[i] 필드는 영역의 경계 샘플들이 가드 밴드에 수평적으로 또는 수직적으로 복사된 경우에 사용될 수 있다. 값 2의 gb_type[i] 필드는 가드 밴드들의 컨텐츠가 실제 이미지 컨텐츠를 점진적으로 변하는 퀄리티 기반으로 나타내되, 상기 점진적으로 변하는 퀄리티는 해당 영역의 픽처 퀄리티로부터 구형면 상에서 인접하는 영역의 픽처 퀄리티로 점진적으로 변하는 것을 나타낸다. 값 3의 gb_type[i]는 가드 밴드들의 컨텐츠가 실제 이미지 컨텐츠를 해당 영역의 픽처 퀄리티 기반으로 나타냄을 나타낸다.
한편, 하나의 트랙이, 구성된 픽처 내의 다수의 사각형 영역으로 맵핑되는 사각형 영역들을 포함하는 경우, 일부의 영역은 RectRegionPacking(i)으로 식별되는 리전별 패킹 영역으로, 나마지 영역들은 상기 guard_band_flag[i] 필드, left_gb_width[i] 필드, right_gb_width[i] 필드, top_gb_height[i] 필드, bottom_gb_height[o] 필드, gb_not_used_for_pred_flag[i] 필드, gb_type[i] 필드들 중 일부 또는 전부를 기반으로 식별되는 가드 밴드 영역으로 식별될 수 있다.
예를 들어, 도 27 및 그 설명에서 상술한 서브픽처7의 경우, 영역 E는 리전별 패킹 영역, 영역 A는 상기 영역 E의 오른쪽에 위치한 가드 밴드 영역으로 식별될 수 있으며, 이 경우 가드밴드 영역의 너비는 right_gb_width[i] 필드를 기반으로 식별될 수 있다. 반대로, 영역 A는 리전별 패킹 영역, 영역 E는 왼쪽에 위치한 가드 밴드 영역으로 식별될 수 있으며, 이 경우 가드밴드 영역의 너비는 left_gb_width[i] 필드를 기반으로 식별될 수 있다. 이러한 가드 밴드 영역의 타입은 gb_type[i] 필드를 통해 나타낼 수 있으며 상술한 '3' 값을 통해 상기 사각형 영역은 동일 인접 영역과 동일한 퀄리티를 갖는 영역으로 식별될 수 있다. 또는, 리전별 패킹 영역과 가드 밴드 영역의 퀄리티가 다를 경우 상술한 '2' 값을 통해 상기 사각형 영역이 식별될 수도 있다.
또한, 다음과 같은 gb_type[i] 필드의 '4' 내지 '7' 값을 통해 상기 사각형 영역이 식별될 수도 있다. 값 4의 gb_type[i] 필드는 사각형 영역의 컨텐츠가 구형면 상에서 해당 영역에 인접해 존재하는 실제 이미지 컨텐츠이며 퀄리티가 연관된 리전별 패킹 영역으로부터 점진적으로 변함을 나타낼 수 있다. 값 5의 gb_type[i] 필드는, 컨텐츠가 구형면 상에서 해당 영역에 인접해 존재하는 실제 이미지 컨텐츠이며 퀄리티가 연관된 리전별 패킹 영역의 퀄리티와 같음을 나타낼 수 있다. 값 6의 gb_type[i] 필드는 사각형 영역의 컨텐츠가 프로젝션된 픽처 상에서 해당 영역에 인접해 존재하는 실제 이미지 컨텐츠이며 퀄리티가 리전별 패킹 영역으로부터 점진적으로 변함을 나타낼 수 있다. 값 7의 gb_type[i] 필드는 사각형 영역의 컨텐츠가 프로젝션된 픽처 상에서 해당 영역에 인접해 존재하는 실제 이미지 컨텐츠이며 퀄리티가 연관된 리전별 패킹 영역의 퀄리티와 같음을 나타낼 수 있다.
한편, 다른 예로, 상기 사각형 영역을 식별하기 위한 정보는 SubPicturecompositionBox를 이용하여 시그널링할 수 있다.
본 발명에서, 상기 다중 사각형 영역은, 좌표 값을 기준으로, 구성된 픽처 영역 내에 존재하는 영역과 구성된 픽처 영역 외에 존재하는 영역으로 구분될 수 있다. 구성된 픽처 영역 외에 존재하는 영역을 클리핑하여 반대편 모서리에 위치시킴으로써 상기 다중 사각형 영역을 나타낼 수 있다.
일 예로, 구성된 픽처 영역 내의 사각형 영역의 가로 좌표인 x가 composition_width 필드의 값과 같거나 클 경우, 상기 x에서 composition_width 필드의 값을 뺀 값을 사용하고, 사각형 영역의 세로 좌표인 y가 composition_height 필드의 값과 같거나 클 경우, 상기 y에서 composition_height 필드의 값을 뺀 값을 사용할 수 있다.
이를 위해 상기 도 28에서 상술한 SubPictureCompositionBox의 track_width 필드, track_height 필드, composition_width 필드, composition_height 필드의 범위는 다음과 같이 수정될 수 있다.
region_width 필드의 값의 범위는 1부터 composition_width 필드의 값까지일 수 있다. region_height 필드의 값의 범위는 1부터 composition_height 필드의 값까지일 수 있다. composition_width 필드의 값은 region_x 필드의 값 +1(plus 1) 보다 크거나 같을 수 있다. composition_height 필드의 값은 region_y 필드의 값 +1(plus 1) 보다 크거나 같을 수 있다.
도 31은 본 발명에 따른 서브픽처 구성을 이용한 360도 비디오의 송수신 과정을 개략적으로 나타낸다.
도 31을 참조하면, 전송 장치는 360도 영상을 획득하고, 획득된 영상을 스티칭, 및 프로젝션을 통해 하나의 2D 픽처에 맵핑한다(S2600). 이 경우 리전별 패킹 과정이 선택적으로(optional) 포함될 수 있다. 여기서 상기 360도 영상은 적어도 하나의 360도 카메라를 이용하여 촬영된 영상일 수 있고, 또는 컴퓨터 등의 영상 처리 장치를 통하여 생성 또는 합성된(synthesized) 영상일 수 있다. 또한 여기서 상기 2D 픽처는 상술한 원본 픽처, 프로젝티드 픽처/팩드 픽처, 및 구성된 픽처 등을 포함할 수 있다.
전송 장치는 상기 2D 픽처를 다수의 서브픽처로 분할한다(S2610). 전송 장치는 이 경우 서브픽처 구성 정보를 생성 및/또는 이용할 수 있다.
전송 장치는 상기 다수의 서브픽처 중 적어도 하나를 인코딩할 수 있다(S2520). 전송 장치는 상기 다수의 서브픽처 중 일부를 선택하여 인코딩할 수 있고, 또는 전송 장치는 상기 다수의 서브픽처들을 모두 인코딩할 수도 있다. 상기 다수의 서브픽처 각각은 독립적으로 코딩될 수 있다.
전송 장치는 인코딩된 서브픽처 스트림을 이용하여 파일을 구성한다(S2630). 서브픽처 스트림은 개별 트랙의 형태로 저장될 수 있다. 서브픽처 구성 정보는 상술한 본 발명에 따른 방법들 중 적어도 하나를 통해 해당 서브픽처 트랙에 포함될 수 있다.
전송 장치 또는 수신 장치는 서브 픽처를 선택할 수 있다(S2640). 전송 장치는 사용자의 뷰포트 정보 및 인터랙션 관련 피드백 정보 등을 이용하여 서브픽처를 선택하고 관련 트랙을 전달할 수 있다. 또는 전송 장치는 복수의 서브픽처 트랙들을 전달하고 수신 장치는 사용자의 뷰포트 정보 및 인터랙션 관련 피드백 정보 등을 이용하여 적어도 하나의 서브픽처(서브픽처 트랙)을 선택할 수 있다.
수신 장치는 파일을 해석하여, 서브픽처 비트스트림 및 서브픽처 구성 정보를 획득하고(S2650), 서브픽처 비트스트림을 디코딩한다(S2660). 수신 장치는 상기 서브픽처 구성 정보를 기반으로 디코딩된 서브픽처를 구성된 픽처(원본 픽처) 영역에 맵핑한다(S2670). 수신 장치는 맵핑된 구성된 픽처를 렌더링한다(S2680). 이 경우 수신 장치는 사용자의 뷰포트에 해당하는 구형면의 일부 영역을 뷰포트 평면에 맵핑하는 렉티리니어 프로젝션(rectilinear projection) 과정 등을 수행할 수 있다.
본 발명에 따르면 도 32과 같이 상기 서브픽처는 2D의 구성된 픽처 상의 공간적으로 인접하지 않은 영역들을 서브픽처 영역으로 포함할 수 있다. 상술한 S2610 절차에서, 구성된 픽처(composed picture)를 구성하는 픽셀 (x, y)에 대하여 서브픽처 구성 정보에 의하여 주어진 위치 (track_x, track_y)와 사이즈 (width, height)에 해당하는 영역을 추출하여 서브픽처를 도출할 수 있으며, 이 경우 서브픽처 내 픽셀의 위치(i, j)는 다음 표 1과 같이 도출될 수 있다.
Figure PCTKR2018000106-appb-T000001
또한, 상술한 S2680 절차에서, 서브픽처를 구성하는 픽셀의 위치 (i, j)에 대하여 맵핑되는 구성된 픽처 내의 픽셀의 위치 (x, y) 다음 표 2와 같이 도출될 수 있다.
Figure PCTKR2018000106-appb-T000002
상기와 같이 서브픽처 내의 픽셀의 위치 (i, j)를 구성된 픽처(composed picture)를 구성하는 픽셀의 위치 (x, y)와 매핑할 수 있다. (x, y)가 구성된 픽처의 경계를 벗어났을 때, 도 32에 도시된 바와 같이 오른쪽으로 벗어난 경우 구성된 픽처의 왼쪽으로 연결될 수 있고, 아래쪽으로 벗어난 경우 구성된 픽처의 위쪽으로 연결될 수 있다.
도 33은 본 발명에 따른 360도 비디오 전송 장치에 의한 360도 비디오 데이터 처리 방법을 개략적으로 나타낸다. 도 33에서 개시된 방법은 360도 비디오 전송 장치에 의하여 수행될 수 있다.
360도 비디오 전송 장치는 360도 비디오 데이터를 획득한다(S2800). 여기서 상기 360도 영상은 적어도 하나의 360도 카메라를 이용하여 촬영된 영상일 수 있고, 또는 컴퓨터 등의 영상 처리 장치를 통하여 생성 또는 합성된(synthesized) 영상일 수 있다.
360도 비디오 전송 장치는 상기 360도 비디오 데이터를 처리하여 2D 픽처를 획득한다(S2810). 획득된 영상을 스티칭, 및 프로젝션을 통해 하나의 2D 픽처에 맵핑될 수 있다. 이 경우 상술한 리전별 패킹 과정이 선택적으로(optional) 수행될 수 있다. 여기서 상기 2D 픽처는 상술한 원본 픽처, 프로젝티드 픽처/팩드 픽처, 및 구성된 픽처 등을 포함할 수 있다.
360도 비디오 전송 장치는 상기 2D 픽처를 분할하여 서브픽처들을 도출한다(S2820). 상기 서브픽처들은 독립적으로 프로세싱될 수 있다. 360도 비디오 전송 장치는 서브픽처 구성 정보를 생성 및/또는 이용할 수 있다. 상기 서브픽처 구성 정보는 메타데이터에 포함될 수 있다.
상기 서브픽처는 다수의 서브픽처 리전들을 포함할 수 있으며, 상기 서브픽처 리전들은 상기 2D 픽처 상에서 공간적으로 서로 인접하지 않을 수 있다. 상기 서브픽처 리전들은 상기 2D 픽처 상에서 공간적으로 서로 인접하 프리젠테이션 또는 렌더링될 3D 공간(구형면) 상에서 공간적으로 서로 인접할 수 있다.
상기 360도 비디오 데이터에 대한 메타데이터를 생성한다(S2830). 상기 메타데이터는 본 발명에서 제안한 다양한 정보들을 포함할 수 있다.
예를 들어, 상기 메타데이터는 상기 2D 픽처 상에서의 서브픽처의 위치 정보를 포함할 수 있다. 상기 2D 픽처가 리전별 패킹 과정을 통하여 도출된 팩드 픽처(packed picture)인 경우, 상기 서브픽처의 위치 정보는 상기 팩드 픽처의 좌표 기준으로, 상기 서브픽처의 좌측 끝 가로 좌표를 나타내는 정보, 상기 서브픽처의 상측 끝 세로 좌표를 나타내는 정보, 상기 서브픽처의 너비를 나타내는 정보 및 상기 서브픽처의 높이를 나타내는 정보를 포함할 수 있다. 상기 서브픽처의 위치 정보는 상기 팩드 픽처의 너비를 나타내는 정보 및 상기 팩드 픽처의 높이를 나타내는 정보를 더 포함할 수 있다. 예를 들어, 상기 서브픽처의 위치 정보는 메타데이터에 포함되는 RegionOriginalCoordinateBox에 포함될 수 있다.
한편, 후술하는 S2850을 통하여 적어도 하나의 서브픽처 트랙이 생성될 수 있으며, 상기 메타데이터는 상기 서브픽처의 위치 정보 및 상기 서브픽처에 연관된 트랙 ID 정보를 포함할 수 있다. 예를 들어, 상기 서브픽처의 위치 정보 및 상기 서브픽처에 연관된 트랙 ID 정보는 상기 메타데이터에 포함되는 RegionToTrackBox에 포함될 수 있다. 또한, 상기 저장 또는 전송을 위한 처리를 수행하는 단계를 통하여 복수의 서브픽처 트랙들을 포함하는 파일이 생성될 수 있으며, 상기 메타데이터는 도 24에 나타낸 바와 같이 서브픽처에 연관된 VPS(video parameter set), SPS(sequence parameter set) 또는 PPS(picture parameter set)를 포함할 수 있다.
다른 예로, 상기 서브픽처의 위치 정보는 SEI 메시지에 포함될 수 있으며, 상기 SEI 메시지는, 루마 샘플 단위에서, 상기 2D 픽처의 좌표 기준으로, 상기 서브픽처의 좌측 끝 가로 좌표를 나타내는 정보, 상기 서브픽처의 상측 끝 세로 좌표를 나타내는 정보, 상기 서브픽처의 너비를 나타내는 정보 및 상기 서브픽처의 높이를 나타내는 정보를 포함할 수도 있다. 상기 SEI 메시지는 도 22에 나타난 바와 같이 상기 서브픽처의 위치 정보의 바이트 수를 나타내는 정보를 더 포함할 수 있다.
상기 서브픽처가 다수의 서브픽처 리전들을 포함할 수 있다. 이 경우, 상기 메타데이터는 서브픽처 리전 정보를 포함하고, 상기 서브픽처 리전 정보는 상기 서브픽처 리전들의 위치 정보 및 상기 서브픽처 리전들 간의 연관관계 정보를 포함할 수 있다. 상기 서브픽처 리전들은 래스터 스캔 순서(raster scan order)로 인덱싱될 수 있다. 도 26에서 나타낸 바와 같이, 상기 연관관계 정보는 상기 서브픽처 상에서 각 서브픽처 리전의 가장 상측 행을 나타내는 정보 또는 상기 서브픽처 상에서 각 서브픽처 리전의 가정 좌측 열을 나타내는 정보 중 적어도 하나를 포함할 수 있다.
상기 서브픽처의 위치 정보는 상기 2D 픽처의 좌표 기준으로, 상기 서브픽처의 좌측 끝 가로 좌표를 나타내는 정보, 상기 서브픽처의 상측 끝 세로 좌표를 나타내는 정보, 상기 서브픽처의 너비를 나타내는 정보 및 상기 서브픽처의 높이를 나타내는 정보를 포함할 수있으며, 상기 서브픽처의 너비를 나타내는 정보의 값 범위는 1부터 상기 2D 픽처의 너비까지이고, 상기 서브픽처의 높이를 나타내는 정보의 값 범위는 1부터 상기 2D 픽처의 높이까지일 수 있다. 상기 서브픽처의 좌측 끝 가로 좌표 더하기(plus) 상기 서브픽처의 너비가 상기 2D 픽처의 너비보다 큰 경우, 상기 서브픽처는 상기 복수의 서브픽처 리전들을 포함할 수 있고, 상기 서브픽처의 상측 끝 세로 좌표 더하기(plus) 상기 서브픽처의 높이가 상기 2D 픽처의 높이보다 큰 경우, 상기 서브픽처는 상기 복수의 서브픽처 리전들을 포함할 수 있다.
360도 비디오 전송 장치는 상기 서브픽처들 중 적어도 하나를 인코딩한다(S2840). 360도 비디오 전송 장치는 상기 다수의 서브픽처 중 일부를 선택하여 인코딩할 수 있고, 또는 상기 다수의 서브픽처들을 모두 인코딩할 수도 있다. 상기 다수의 서브픽처 각각은 독립적으로 코딩될 수 있다.
360도 비디오 전송 장치는 상기 인코딩된 적어도 하나의 서브픽처 및 상기 메타데이터에 대하여 저장 또는 전송을 위한 처리를 수행한다(S2850). 360도 비디오 전송 장치는 상기 인코딩된 적어도 하나의 서브픽처 및/또는 상기 메타데이터를 파일 등의 형태로 인캡슐레이션(encapsulation)할 수 있다. 360도 비디오 전송 장치는 상기 인코딩된 적어도 하나의 서브픽처 및/또는 상기 메타데이터를 저장 또는 전송하기 위하여 ISOBMFF, CFF 등의 파일 포맷으로 인캡슐레이션하거나, 기타 DASH 세그먼트 등의 형태로 처리할 수 있다. 360도 비디오 전송 장치는 상기 메타데이터를 파일 포맷 상에 포함시킬 수 있다. 예를 들어, 상기 메타데이터는 ISOBMFF 파일 포맷 상의 다양한 레벨의 박스(box)에 포함되거나 파일 내에서 별도의 트랙내의 데이터로 포함될 수 있다. 360도 비디오 전송 장치는 파일 포맷에 따라 인캡슐레이션된 파일에 전송을 위한 처리를 가할 수 있다. 360도 비디오 전송 장치는 임의의 전송 프로토콜에 따라 파일을 처리할 수 있다. 전송을 위한 처리에는 방송망을 통한 전달을 위한 처리, 또는 브로드밴드 등의 통신 네트워크를 통한 전달을 위한 처리를 포함할 수 있다. 또한, 360도 비디오 전송 장치는 상기 메타데이터에 전송을 위한 처리를 가할 수도 있다. 360도 비디오 전송 장치는 전송 처리된 상기 360도 비디오 데이터 및 상기 메타데이터를 방송망 및/또는 브로드밴드를 통해 전송할 수 있다.
도 34는 본 발명에 따른 360도 비디오 수신 장치에 의한 360도 비디오 데이터 처리 방법을 개략적으로 나타낸다. 도 34에서 개시된 방법은 360도 비디오 수신 장치에 의하여 수행될 수 있다.
360도 비디오 수신 장치는 서브픽처에 대한 트랙 및 메타데이터를 포함하는 신호를 수신한다(S2900). 360도 비디오 수신 장치는 방송망을 통하여 360도 비디오 전송 장치로부터 시그널링된 상기 서브픽처에에 대한 영상정보 및 상기 메타데이터를 수신할 수 있다. 도 비디오 수신 장치는 브로드밴드 등의 통신 네트워크, 또는 저장매체를 통하여 상기 서브픽처에에 대한 영상정보 및 상기 메타데이터를 수신할 수도 있다. 여기서, 상기 서브픽처는 팩드 픽처 또는 프로젝션된 픽처 상에 위치할 수 있다.
360도 비디오 수신 장치는 신호를 처리하여 서브픽처에 대한 영상정보 및 메타데이터를 획득한다(S2910). 360도 비디오 수신 장치는 수신된 상기 서브픽처에 대한 영상정보 및 상기 메타데이터에 대해 전송 프로토콜에 따른 처리를 수행할 수 있다. 또한, 360도 비디오 수신 장치는 전술한 360도 비디오 전송 장치의 전송을 위한 처리의 역과정을 수행할 수 있다.
상기 수신된 신호는 적어도 하나의 서브픽처에 대한 트랙을 포함할 수 있다. 상기 수신된 신호가 복수의 서브픽처에 대한 트랙을 포함하는 경우 360도 비디오 수신 장치는 상기 복수의 서브픽처에 대한 트랙들 중 일부(하나를 포함)를 선택할 수 있다. 이 경우 뷰포트 정보 등이 사용될 수 있다.
상기 서브픽처는 다수의 서브픽처 리전들을 포함할 수 있으며, 상기 서브픽처 리전들은 상기 2D 픽처 상에서 공간적으로 서로 인접하지 않을 수 있다. 상기 서브픽처 리전들은 상기 2D 픽처 상에서 공간적으로 서로 인접하 프리젠테이션 또는 렌더링될 3D 공간(구형면) 상에서 공간적으로 서로 인접할 수 있다.
상기 메타데이터는 본 발명에서 제안한 다양한 정보들을 포함할 수 있다.
예를 들어, 상기 메타데이터는 상기 2D 픽처 상에서의 서브픽처의 위치 정보를 포함할 수 있다. 상기 2D 픽처가 리전별 패킹 과정을 통하여 도출된 팩드 픽처(packed picture)인 경우, 상기 서브픽처의 위치 정보는 상기 팩드 픽처의 좌표 기준으로, 상기 서브픽처의 좌측 끝 가로 좌표를 나타내는 정보, 상기 서브픽처의 상측 끝 세로 좌표를 나타내는 정보, 상기 서브픽처의 너비를 나타내는 정보 및 상기 서브픽처의 높이를 나타내는 정보를 포함할 수 있다. 상기 서브픽처의 위치 정보는 상기 팩드 픽처의 너비를 나타내는 정보 및 상기 팩드 픽처의 높이를 나타내는 정보를 더 포함할 수 있다. 예를 들어, 상기 서브픽처의 위치 정보는 메타데이터에 포함되는 RegionOriginalCoordinateBox에 포함될 수 있다.
상기 메타데이터는 상기 서브픽처의 위치 정보 및 상기 서브픽처에 연관된 트랙 ID 정보를 포함할 수 있다. 예를 들어, 상기 서브픽처의 위치 정보 및 상기 서브픽처에 연관된 트랙 ID 정보는 상기 메타데이터에 포함되는 RegionToTrackBox에 포함될 수 있다. 또한, 상기 저장 또는 전송을 위한 처리를 수행하는 단계를 통하여 복수의 서브픽처 트랙들을 포함하는 파일이 생성될 수 있으며, 상기 메타데이터는 도 24에 나타낸 바와 같이 서브픽처에 연관된 VPS(video parameter set), SPS(sequence parameter set) 또는 PPS(picture parameter set)를 포함할 수 있다.
다른 예로, 상기 서브픽처의 위치 정보는 SEI 메시지에 포함될 수 있으며, 상기 SEI 메시지는, 루마 샘플 단위에서, 상기 2D 픽처의 좌표 기준으로, 상기 서브픽처의 좌측 끝 가로 좌표를 나타내는 정보, 상기 서브픽처의 상측 끝 세로 좌표를 나타내는 정보, 상기 서브픽처의 너비를 나타내는 정보 및 상기 서브픽처의 높이를 나타내는 정보를 포함할 수도 있다. 상기 SEI 메시지는 도 22에 나타난 바와 같이 상기 서브픽처의 위치 정보의 바이트 수를 나타내는 정보를 더 포함할 수 있다.
상기 서브픽처가 다수의 서브픽처 리전들을 포함할 수 있다. 이 경우, 상기 메타데이터는 서브픽처 리전 정보를 포함하고, 상기 서브픽처 리전 정보는 상기 서브픽처 리전들의 위치 정보 및 상기 서브픽처 리전들 간의 연관관계 정보를 포함할 수 있다. 상기 서브픽처 리전들은 래스터 스캔 순서(raster scan order)로 인덱싱될 수 있다. 도 26에서 나타낸 바와 같이, 상기 연관관계 정보는 상기 서브픽처 상에서 각 서브픽처 리전의 가장 상측 행을 나타내는 정보 또는 상기 서브픽처 상에서 각 서브픽처 리전의 가정 좌측 열을 나타내는 정보 중 적어도 하나를 포함할 수 있다.
상기 서브픽처의 위치 정보는 상기 2D 픽처의 좌표 기준으로, 상기 서브픽처의 좌측 끝 가로 좌표를 나타내는 정보, 상기 서브픽처의 상측 끝 세로 좌표를 나타내는 정보, 상기 서브픽처의 너비를 나타내는 정보 및 상기 서브픽처의 높이를 나타내는 정보를 포함할 수있으며, 상기 서브픽처의 너비를 나타내는 정보의 값 범위는 1부터 상기 2D 픽처의 너비까지이고, 상기 서브픽처의 높이를 나타내는 정보의 값 범위는 1부터 상기 2D 픽처의 높이까지일 수 있다. 상기 서브픽처의 좌측 끝 가로 좌표 더하기(plus) 상기 서브픽처의 너비가 상기 2D 픽처의 너비보다 큰 경우, 상기 서브픽처는 상기 복수의 서브픽처 리전들을 포함할 수 있고, 상기 서브픽처의 상측 끝 세로 좌표 더하기(plus) 상기 서브픽처의 높이가 상기 2D 픽처의 높이보다 큰 경우, 상기 서브픽처는 상기 복수의 서브픽처 리전들을 포함할 수 있다.
360도 비디오 수신 장치는 서브픽처에 대한 영상정보를 기반으로 서브픽처를 디코딩한다(S2920). 360도 비디오 수신 장치는 상기 서브픽처에 대한 영상정보를 기반으로 상기 서브픽처를 독립적으로 디코딩할 수 있다. 또한, 복수의 서브픽처 들에 대한 영상정보가 입력된 경우에도, 360도 비디오 수신 장치는 획득된 뷰포트 관련 메타데이터를 기반으로 특정 서브픽처만을 디코딩할 수 있다.
360도 비디오 수신 장치는 메타데이터를 기반으로 디코딩된 서브픽처를 처리하여 3D 공간으로 렌더링한다(S2930). 360도 비디오 수신 장치는 상기 메타데이터를 기반으로 상기 디코딩된 서브픽처를 3D 공간으로 맵핑할 수 있다. 이 경우 360도 비디오 수신 장치는 상기 본 발명에 따른 서브픽처 및/또는 서브픽처 리전의 위치정보를 기반으로 좌표 컨버전을 수행하여, 상기 디코딩된 서브픽처를 3D 공간으로 매핑 및 렌더링할 수 있다.
전술한 단계들은 실시예에 따라 생략되거나, 유사/동일한 동작을 수행하는 다른 단계에 의해 대체될 수 있다.
본 발명의 일 실시예에 따른 360도 비디오 전송 장치는 전술한 데이터 입력부, 스티처, 시그널링 처리부, 프로젝션 처리부, 데이터 인코더, 전송 처리부 및/또는 전송부를 포함할 수 있다. 각각의 내부 컴포넌트들은 전술한 바와 같다. 본 발명의 일 실시예에 따른 360도 비디오 전송 장치 및 그 내부 컴포넌트들은, 전술한 본 발명의 360도 비디오를 전송하는 방법의 실시예들을 수행할 수 있다.
본 발명의 일 실시예에 따른 360도 비디오 수신 장치는 전술한 수신부, 수신 처리부, 데이터 디코더, 시그널링 파서, 리-프로젝션 처리부 및/또는 렌더러를 포함할 수 있다. 각각의 내부 컴포넌트들은 전술한 바와 같다. 본 발명의 일 실시예에 따른 360도 비디오 수신 장치 및 그 내부 컴포넌트들은, 전술한 본 발명의 360도 비디오를 수신하는 방법의 실시예들을 수행할 수 있다.
전술한 장치의 내부 컴포넌트들은 메모리에 저장된 연속된 수행과정들을 실행하는 프로세서들이거나, 그 외의 하드웨어로 구성된 하드웨어 컴포넌트들일 수 있다. 이 들은 장치 내/외부에 위치할 수 있다.
전술한 모듈들은 실시예에 따라 생략되거나, 유사/동일한 동작을 수행하는 다른 모듈에 의해 대체될 수 있다.
도 35 는 본 발명의 한 관점(aspect) 에 따른 360 비디오 전송 장치를 도시한 도면이다.
한 관점에 따르면 본 발명은 360 비디오 전송 장치와 관련될 수 있다. 360 비디오 전송 장치는 360 비디오 데이터를 처리하고, 360 비디오 데이터에 대한 시그널링 정보를 생성하여 이를 수신측으로 전송할 수 있다.
구체적으로, 360 비디오 전송 장치는 360 비디오를 스티칭하고, 픽쳐에 프로젝션하여 처리하고, 픽쳐를 인코딩하고, 360 비디오 데이터에 대한 시그널링 정보를 생성하고, 360 비디오 데이터 및/또는 시그널링 정보를 다양한 형태로, 다양한 방법으로 전송할 수 있다.
본 발명에 따른 360 비디오 전송 장치는 비디오 프로세서, 데이터 인코더, 메타데이터 처리부, 인캡슐레이션 처리부 및/또는 전송부를 내/외부 컴포넌트로서 포함할 수 있다.
비디오 프로세서는 적어도 하나 이상의 카메라에 의해 캡쳐된 360 비디오 데이터를 처리할 수 있다. 비디오 프로세서는 360 비디오 데이터를 스티칭하고, 스티칭된 360 비디오 데이터를 2D 이미지 즉, 픽쳐 상에 프로젝션할 수 있다. 실시예에 따라 비디오 프로세서는 리전 와이즈 패킹을 더 수행할 수도 있다. 여기서 스티칭, 프로젝션, 리전 와이즈 패킹은 전술한 동명의 프로세스에 대응될 수 있다. 리전 와이즈 패킹은 실시예에 따라 리전별 패킹의 명칭으로 불릴 수 있다. 비디오 프로세서는 전술한 스티처, 프로젝션 처리부 및/또는 리전별 패킹 처리부에 대응되는 역할을 수행하는 하드웨어 프로세서일 수 있다.
데이터 인코더는 360 비디오 데이터가 프로젝션된 픽쳐를 인코딩할 수 있다. 실시예에 따라 리전 와이즈 패킹이 수행된 경우, 데이터 인코더는 패킹된 픽쳐를 인코딩할 수 있다. 데이터 인코더는 전술한 데이터 인코더에 대응될 수 있다.
메타데이터 처리부는 360 비디오 데이터에 대한 시그널링 정보를 생성할 수 있다. 메타데이터 처리부는 전술한 메타데이터 처리부에 대응될 수 있다.
인캡슐레이션 처리부는 인코딩된 픽쳐와 시그널링 정보를 파일로 인캡슐레이션할 수 있다. 인캡슐레이션 처리부는 전술한 인캡슐레이션 처리부에 대응될 수 있다.
전송부는 360 비디오 데이터 및 시그널링 정보를 전송할 수 있다. 해당 정보들이 파일로 인캡슐레이션되는 경우, 전송부는 파일들을 전송할 수 있다. 전송부는 전술한 전송처리부 및/또는 전송부에 대응되는 컴포넌트일 수 있다. 전송부는 방송망 또는 브로드밴드를 통해 해당 정보들을 전송할 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 일 실시예에서, 시그널링 정보는 커버리지(coverage) 정보를 포함할 수 있다. 커버리지 정보는 전술한 픽쳐의 서브 픽쳐가 3D 공간 상에서 차지하는 영역을 지시할 수 있다. 실시예에 따라 커버리지 정보는 서브 픽쳐가 아니더라도 픽쳐의 일 영역이 3D 공간 상에서 차지하는 영역을 지시할 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 다른 실시예에서, 데이터 인코더는 전체 360 비디오 데이터 중 일부 영역을, 사용자 시점 기반의 프로세싱을 위하여, 독립된 비디오 스트림으로 처리할 수 있다. 데이터 인코더는 프로젝션된 픽쳐 또는 리전 와이즈 패킹된 픽쳐에서, 일부 영역들을 독립된 비디오 스트림의 형태로 각각 처리할 수 있다. 이러한 비디오 스트림들은 개별적으로 저장, 전송될 수 있다. 여기서 각각의 영역들은 전술한 타일일 수 있다.
해당 비디오 스트림들이 파일로 인캡슐레이션되는 경우, 하나의 트랙은 이 사각형의 영역을 포함할 수 있는데, 이 영역은 하나 또는 그 이상의 타일들에 대응될 수 있다. 실시예에 따라, 해당 비디오 스트림들이 DASH 에 의해 전달되는 경우, 하나의 어댑테이션 셋(Adaptation Set), 레프리젠테이션(Representation) 또는 서브 레프리젠테이션(Sub Representation) 은 사각형의 영역을 포함할 수 있고, 이 영역은 하나 또는 그 이상의 타일들에 대응될 수 있다. 실시예에 따라 각 영역은 HEVC MCTS 비트스트림으로부터 추출된 HEVC 비트스트림들일 수도 있다. 실시예에 따라 이 과정은 데이터 인코더가 아닌, 전술한 타일링 시스템 또는 전송 처리부에 의해 수행될 수도 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 커버리지 정보는 해당 영역을 특정하기 위한 정보를 포함할 수 있다. 해당 영역을 특정하기 위하여, 커버리지 정보는 해당 영역의 중심, 너비 및/또는 높이를 특정하는 정보를 포함할 수 있다. 커버리지 정보는 해당 영역의 중심이 되는 점의 야(yaw) 값 및/또는 피치(pitch) 값을 나타내는 정보를 포함할 수 있다. 이 정보들은 3D 공간이 구면이라고 하였을 때, 방위각(azimuth) 값 또는 고도(elevation) 값으로 나타내어 질 수도 있다. 또한, 커버리지 정보는 해당 영역의 너비 값 및/또는 높이 값을 포함할 수 있는데, 이 들은 각각 특정된 중점을 기준으로 해당 영역의 너비 및 높이를 특정하여, 전체 해당 영역의 커버리지(coverage) 를 나타낼 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 커버리지 정보는 해당 영역의 형태(shape) 을 특정하는 정보를 포함할 수 있다. 실시예에 따라 해당 영역은 4 개의 구면 상 대원(4 great circles) 에 의해 특정되는 형태 또는 2 개의 야 원(yaw circle) 및 2 개의 피치 원(pitch circle) 에 의해 특정되는 형태일 수 있다. 커버리지 정보는 해당 영역이 이들 중 어떠한 형태를 띄는 지를 나타내는 정보를 가질 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 커버리지 정보는 해당 영역이 가지는 360 비디오가 3D 비디오인지 여부 및/또는 좌우영상인지 여부를 나타내는 정보를 포함할 수 있다. 커버리지 정보는 해당 360 비디오가 2D 비디오인지 3D 비디오인지, 또한 3D 비디오라면 좌영상에 해당하는지, 우영상에 해당하는지 여부를 나타낼 수 있다. 실시예에 따라 이 정보는 해당 360 비디오가 좌영상 및 우영상을 모두 포함하는지 여부 또한 나타낼 수 있다. 실시예에 따라 이 정보는 하나의 필드로 정의되어, 이 필드의 값에 따라 전술한 사항들이 모두 시그널링될 수도 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 커버리지 정보는 DASH (Dynamic Adaptive Streaming over HTTP) 디스크립터의 형태로 생성될 수 있다. 커버리지 정보는 포맷만 달리하여 DASH 디스크립터로 구성될 수 있으며, 이 경우 DASH 디스크립터는 MPD (Media Presentation Description) 에 포함되어 360 비디오 데이터 파일과는 다른, 별도의 경로로 전송될 수 있다. 이 경우 커버리지 정보는 파일 내에 360 비디오 데이터와 같이 인캡슐레이션되지 않을 수 있다. 즉, 커버리지 정보는 MPD 등등의 형태로 별도의 시그널링 채널을 통해 수신측으로 전달될 수도 있다. 실시예에 따라 커버리지 정보는 파일 내 그리고 MPD 등 별도의 시그널링 정보 내에 동시에 포함될 수도 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 360 비디오 전송 장치는 (송신측) 피드백 처리부를 더 포함할 수 있다. (송신측) 피드백 처리부는 전술한 (송신측) 피드백 처리부에 대응될 수 있다. (송신측) 피드백 처리부는 수신측으로부터 현재 사용자의 뷰포트를 지시하는 피드백 정보를 수신할 수 있다. 이 피드백 정보는 현재 사용자가 VR 기기 등을 통해 시청하고 있는 뷰포트를 특정하는 정보를 포함할 수 있다. 전술한 바와 같이 이 피드백 정보를 이용하여 타일링 등이 수행될 수 있다. 이 때, 360 비디오 전송 장치가 전송하는 서브 픽쳐 내지 픽쳐의 일 영역은, 이 피드백 정보가 지시하는 뷰포트에 해당하는 서브 픽쳐 내지 픽쳐의 일 영역일 수 있다. 이 때, 커버리지 정보는 피드백 정보가 지시하는 뷰포트에 해당하는 서브 픽쳐 내지 픽쳐의 일 영역에 대한 커버리지를 나타낼 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 3D 공간은 구(sphere) 일 수 있다. 실시예에 따라 3D 공간은 큐브 등일 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 360 비디오 데이터에 대한 시그널링 정보는 ISOBMFF (ISO Base Media File Format) 박스의 형태로 파일에 삽입될 수 있다. 실시예에 따라 파일은 ISOBMFF 파일이거나 CFF (Common File Format) 에 따른 파일일 수 있다.
본 발명에 따른 360 비디오 전송 장치의 또 다른 실시예에서, 360 비디오 전송 장치는 도시되지 않은 데이터 입력부 등을 더 포함할 수 있다. 데이터 입력부는 전술한 동명의 내부 컴포넌트에 대응될 수 있다.
본 발명의 실시예들에 따른 360 비디오 전송 장치는, 360 비디오 콘텐츠가 제공될 때, 360 비디오의 속성 등에 대한 메타데이터를 정의 및 전달함으로써, 효과적으로 360 비디오 서비스를 제공할 수 있도록 하는 방안을 제안한다
본 발명의 실시예들에 따른 360 비디오 전송 장치는, shape_type 필드 내지 파라미터가 커버리지 정보에 추가됨으로써, 수신측에서 뷰포트에 해당하는 영역을 효과적으로 셀렉팅할 수 있다.
본 발명의 실시예들에 따른 360 비디오 전송 장치는, 타일링을 통하여 현재 사용자가 보고 있는 뷰포트에 해당하는 비디오 영역만을 수신, 처리하여 사용자에 제공할 수 있다. 이를 통해 효율적인 데이터 전달 및 처리가 가능할 수 있다.
본 발명의 실시예들에 따른 360 비디오 전송 장치는, 3D 360 비디오의 경우에 있어서, 커버리지 정보에 해당 영역의 좌/우 영상 여부, 2D/3D 여부 등을 시그널링함으로써, 효과적으로 해당 3D 360 비디오를 획득, 처리할 수 있다.
전술한 본 발명에 따른 360 비디오 전송 장치 의 실시예들은 서로 조합될 수 있다. 또한 전술한 본 발명에 따른 360 비디오 전송 장치 의 내/외부 컴포넌트들은 실시예에 따라 추가, 변경, 대체 또는 삭제될 수 있다. 또한 전술한 360 비디오 전송 장치의 내/외부 컴포넌트들은 하드웨어 컴포넌트로 구현될 수 있다.
도 36 은 본 발명의 다른 관점에 따른 360 비디오 수신 장치 를 도시한 도면이다.
다른 관점에 따르면 본 발명은 360 비디오 수신 장치와 관련될 수 있다. 360 비디오 수신 장치는 360 비디오 데이터 및/또는 360 비디오 데이터에 대한 시그널링 정보를 수신하고, 이를 처리하여 360 비디오를 사용자에게 렌더링할 수 있다. 360 비디오 수신 장치는 전술한 360 비디오 전송 장치 에 대응되는 수신측에서의 장치일 수 있다.
구체적으로, 360 비디오 수신 장치는 360 비디오 데이터 및/또는 360 비디오 데이터에 대한 시그널링 정보를 수신하고, 시그널링 정보를 획득하고, 이를 기반으로 360 비디오 데이터를 처리하여 360 비디오를 렌더링할 수 있다.
본 발명에 따른 360 비디오 수신 장치는 수신부, 데이터 프로세서 및/또는 메타데이터 파서를 내/외부 컴포넌트로서 포함할 수 있다.
수신부는 360 비디오 데이터 및/또는 360 비디오 데이터에 대한 시그널링 정보를 수신할 수 있다. 실시예에 따라 수신부는 이 정보들을 파일의 형태로 수신할 수 있다. 실시예에 따라 수신부는 방송망 또는 브로드밴드를 통해 해당 정보들을 수신할 수 있다. 수신부는 전술한 수신부에 대응되는 컴포넌트일 수 있다.
데이터 프로세서는 수신된 파일 등으로부터 360 비디오 데이터 및/또는 360 비디오 데이터에 대한 시그널링 정보를 획득할 수 있다. 데이터 프로세서는 수신된 정보에 대하여 전송 프로토콜에 따른 처리를 하거나, 파일을 디캡슐레이션하거나, 360 비디오 데이터에 대해 디코딩을 수행할 수 있다. 또한 데이터 프로세서는 360 비디오 데이터에 대해 리-프로젝션을 수행하고, 이에 따라 렌더링을 수행할 수 있다. 데이터 프로세서는 전술한 수신 처리부, 디캡슐레이션 처리부, 데이터 디코더, 리-프로젝션 처리부 및/또는 렌더러에 대응되는 역할을 수행하는 하드웨어 프로세서일 수 있다.
메타데이터 파서는 획득된 시그널링 정보를 파싱할 수 있다. 메타데이터 파서는 전술한 메타데이터 파서에 대응될 수 있다.
본 발명에 따른 360 비디오 수신 장치는, 전술한 본 발명에 따른 360 비디오 전송 장치에 대응되는 실시예들을 가질 수 있다. 본 발명에 따른 360 비디오 수신 장치 및 그 내/외부 컴포넌트들은, 전술한 본 발명에 따른 360 비디오 전송 장치의 실시예들에 대응되는 실시예들을 수행할 수 있다.
전술한 본 발명에 따른 360 비디오 수신 장치의 실시예들은 서로 조합될 수 있다. 또한 전술한 본 발명에 따른 360 비디오 수신 장치의 내/외부 컴포넌트들은 실시예에 따라 추가, 변경, 대체 또는 삭제될 수 있다. 또한 전술한 360 비디오 수신 장치의 내/외부 컴포넌트들은 하드웨어 컴포넌트로 구현될 수 있다.
도 37 은 본 발명에 따른 커버리지 정보의 일 실시예를 도시한 도면이다.
본 발명에 따른 커버리지 정보는, 전술한 바와 같이 전술한 픽쳐의 서브 픽쳐가 3D 공간 상에서 차지하는 영역을 지시할 수 있다. 실시예에 따라 커버리지 정보는 서브 픽쳐가 아니더라도 픽쳐의 일 영역이 3D 공간 상에서 차지하는 영역을 지시할 수 있다.
전술한 바와 같이, 커버리지 정보는 해당 영역을 특정하기 위한 정보, 해당 영역의 형태(shape) 을 특정하는 정보 및/또는 해당 영역이 가지는 360 비디오가 3D 비디오인지 여부 및/또는 좌우영상인지 여부를 나타내는 정보 등을 포함할 수 있다.
도시된 커버리지 정보 의 일 실시예(37010)에서, 커버리지 정보는 SpatialRelationshipDescriptionOnSphereBox 로 정의될 수 있다. SpatialRelationshipDescriptionOnSphereBox 는 srds 로 표현될 수 있는 박스로서 정의될 수 있으며, 이는 ISOBMFF 파일 내에 포함될 수 있다. 실시예에 따라, 이 박스는 각각의 영역이 저장/전송되는 트랙의 비주얼 샘플 엔트리(visual sample entry) 의 하위에 존재할 수 있다. 실시예에 따라, 이 박스는 스킴 인포메이션 박스(Scheme Information box) 등 다른 박스의 하위에 존재할 수도 있다.
구체적으로, SpatialRelationshipDescriptionOnSphereBox 는 total_center_yaw, total_center_pitch, total_hor_range, total_ver_range, region_shape_type 및/또는 num_of_region 필드를 포함할 수 있다.
total_center_yaw 필드는 해당 영역(실시예에 따라, 타일) 이 속한 전체 3D 공간 영역(3D geometry surface) 의 가운데 점의 yaw (longitude) 값을 나타낼 수 있다.
total_center_pitch 필드는 해당 영역이 속한 전체 3D 공간 영역의 가운데 점의 pitch (latitude) 값을 나타낼 수 있다.
total_hor_range 필드는 해당 영역이 속한 전체 3D 공간 영역의 yaw 값 범위를 나타낼 수 있다.
total_ver_range 필드는 해당 영역이 속한 전체 3D 공간 영역의 pitch 값 범위를 나타낼 수 있다.
region_shape_type 필드는 해당 영역들이 어떠한 형태(shpae) 을 가지는지를 나타낼 수 있다. 영역의 형태는 4 개의 구면 상 대원(4 great circles) 에 의해 특정되는 형태 또는 2 개의 야 원(yaw circle) 및 2 개의 피치 원(pitch circle) 에 의해 특정되는 형태 중 하나일 수 있다. 본 필드 값이 0 인 경우, 해당 영역들은 4 개의 대원으로 둘러쌓인 영역과 같은 형태를 띌 수 있다(37020). 이 경우, 하나의 영역은 앞면, 뒷면, 뒷면 등과 같은 하나의 큐브 면(cube face) 를 나타낼 수도 있다. 본 필드 값이 1 인 경우, 해당 영역들은 2개의 yaw 원들과 2 개의 pitch 원들로 둘러쌓인 영역과 같은 형태를 띌 수 있다(37030).
num_of_region 필드는 SpatialRelationshipDescriptionOnSphereBox 가 나타내고자 하는 해당 영역들의 개수를 나타낼 수 있다. 본 필드 값에 따라 SpatialRelationshipDescriptionOnSphereBox 는 각각의 영역들에 대해 RegionOnSphereStruct() 들을 포함할 수 있다.
RegionOnSphereStruct() 는 해당 영역에 대한 정보들을 나타낼 수 있다. RegionOnSphereStruct() 는 center_yaw, center_pitch, hor_range 및/또는 ver_range 필드를 포함할 수 이다.
center_yaw, center_pitch 필드는 해당 영역의 중심이 되는 점의 yaw 값 및 pitch 값을 나타낼 수 있다. range_included_flag 필드는 RegionOnSphereStruct() 가 hor_range, ver_range 필드를 포함하는지 여부를 나타낼 수 있다. range_included_flag 필드에 따라 RegionOnSphereStruct() 는 hor_range, ver_range 필드를 포함할 수 있다.
hor_range, ver_range 필드는 해당 영역의 너비 값 및 높이 값을 나타낼 수 있다. 이 너비 및 높이는 특정된 해당 영역의 중심점을 기준으로 할 수 있다. 중심점의 위치와 너비, 높이 값을 통해 해당 영역이 3D 공간 상에서 차지하는 커버리지가 특정될 수 있다.
실시예에 따라 RegionOnSphereStruct() 는 center_roll 필드를 더 포함할 수 있다. center_yaw, center_pitch, center_roll 필드는，　 ProjectionOrientationBox 에서　특정된　좌표계를　기준으로　하여， 해당 영역의 중심이 되는 점의 yaw, pitch, roll 값을 2-16 도 단위로　나타낼　수　있다． 실시예에 따라 RegionOnSphereStruct() 는 interpolate 필드를 더 가질 수 있다. interpolate 필드는 0 값을 가질 수 있다.
실시예에 따라 center_yaw 는 180*216 에서, 180　*2161 의 범위를 가질 수 있다. center_pitch 는 90*216 에서, 90　*2161 의 범위를 가질 수 있다. center_roll 은 180*216 에서, 180　*2161 의 범위를 가질 수 있다.
실시예에 따라 hor_range, ver_range 필드는 해당 영역의 너비 값 및 높이 값을 2-16 도 단위로　나타낼　수　있다． 실시예에 따라 hor_range 는 1 에서 720　*　216, 의 범위를 가질 수 있다. ver_range 는 1 에서 180　*　216 의 범위를 가질 수 있다.
도 38 은 본 발명에 따른 커버리지 정보 의 다른 실시예를 도시한 도면이다.
도시된 커버리지 정보 의 다른 실시예에서, 커버리지 정보는 DASH 디스크립터의 형태를 가질 수 있다. 전술한 바와 같이 360 비디오 데이터가 영역별로 나뉘어져 전송될 때, DASH 를 통해 360 비디오 데이터가 전송될 수 있다. 이 때, 커버리지 정보는 DASH MPD 의 Essential Property 또는 Supplemental Property 디스크립터의 형태로서 전달될 수 있다.
커버리지 정보를 포함하는 디스크립터는 “urn:mpeg:dash:mpd:vr-srd:201x” 와 같은 새로운 schemIdURI 로 식별될 수 있다. 또한 이 디스크립터는, 각각의 영역이 저장/전송되는 어댑테이션 셋, 레프리젠테이션 또는 서브 레프리젠테이션의 하위에 존재할 수 있다.
구체적으로, 도시된 디스크립터는 source_id, region_shape_type, region_center_yaw, region_center_pitch, region_hor_range, region_ver_range, total_center_yaw, total_center_pitch, total_hor_range 및/또는 total_ver_range 파라미터를 포함할 수 있다.
source_id 파라미터는 해당 영역들의 소스 360 비디오 컨텐트를 식별하기 위한 식별자를 나타낼 수 있다. 동일한 360 비디오 컨텐트로부터 온 영역들은 동일한 source_id 파라미터 값들을 가질 수 있다.
region_shape_type 파라미터는 전술한 region_shape_type 필드와 같을 수 있다.
region_center_yaw, region_center_pitch 파라미터들은, 복수개의 세트가 포함되어, 각각 N 번째 영역의 가운데 점의 yaw(longitude) 및 pitch (latitude) 값을 나타낼 수 있다.
region_hor_range, region_ver_range 파라미터들은, 복수개의 세트가 포함되어, 각각 N 번째 영역의 yaw 값 범위 및 pitch 값 범위를 나타낼 수 있다.
total_center_yaw, total_center_pitch, total_hor_range 및 total_ver_range 파라미터는 전술한 total_center_yaw, total_center_pitch, total_hor_range, total_ver_range 필드들과 같을 수 있다.
도 39 는 본 발명에 따른 커버리지 정보 의 또 다른 실시예를 도시한 도면이다.
도시된 커버리지 정보의 또 다른 실시예(39010)에서, 커버리지 정보는 역시 DASH 디스크립터의 형태를 가질 수 있다. 이 DASH 디스크립터는 전술한 커버리지 정보들과 마찬가지로, 영역들간의 공간상 관계를 나타내는 정보를 제공할 수 있다. 이 디스크립터는 "urn:mpeg:dash:spherical-region:201X" 와 같은 schemIdURI 로 식별될 수 있다.
전술한 바와 같이 커버리지 정보는 DASH MPD 의 Essential Property 또는 Supplemental Property 디스크립터의 형태로서 전달될 수 있다. 또한 이 디스크립터는, 각각의 영역이 저장/전송되는 어댑테이션 셋, 레프리젠테이션 또는 서브 레프리젠테이션의 하위에 존재할 수 있다. 실시예에 따라 도시된 실시예의 DASH 디스크립터는 어댑테이션 셋 또는 서브 레프리젠테이션의 하위에만 존재할 수도 있다.
구체적으로, 도시된 디스크립터(39010)는 source_id, object_center_yaw, object_center_pitch, object_hor_range, object_ver_range, sub_pic_reg_flag 및/또는 shape_type 파라미터를 포함할 수 있다.
source_id 파라미터는 해당 VR 컨텐트의 소스를 식별하는 식별자일 수 있다. 본 파라미터는 전술한 동명의 파라미터와 같을 수 있다. 실시예에 따라 본 파라미터는 음수가 아닌 정수 값을 가질 수 있다.
object_center_yaw, object_center_pitch 파라미터는 해당 영역의 중점의 yaw, pitch 값을 각각 나타낼 수 있다. 여기서 실시예에 따라 해당 영역이란, 구면상 해당 오브젝트(비디오 영역)가 프로젝션되는 영역을 의미할 수 있다.
object_hor_range, object_ver_range 파라미터는 해당 영역의 너비, 높이의 범위를 각각 나타낼 수 있다. 본 파라미터들은 각각 yaw 값의 범위, pitch 값의 범위를 각도(degree) 값으로 나타낼 수 있다.
sub_pic_reg_flag 파라미터는 해당 영역이 구면 상에 배열되는 전체 서브 픽쳐인지 아닌지 여부를 나타낼 수 있다. 본 파라미터 값이 0 인 경우, 해당 영역은 하나의 전체 서브 픽쳐에 해당할 수 있다. 본 파라미터 값이 1 인 경우, 해당 영역은 하나의 서브 픽쳐 내의 서브 픽쳐 리전에 해당할 수 있다. 서브 픽쳐 즉, 타일은 복수개의 서브 픽쳐 리전으로 나뉘어질 수 있다(39020). 하나의 서브 픽쳐는 'top' 서브 픽쳐 리전과 'bottom' 서브 픽쳐 리전을 포함할 수 있다. 이 때 디스크립터(39010)는 서브 픽쳐 리전, 즉 해당 영역에 대해서 기술할 수 있다. 이 경우 아답테이션 셋 또는 서브 레프리젠테이션은 복수개의 디스크립터(39010)들을 포함하여, 각각의 서브 픽쳐 리전들을 기술할 수 있다. 서브 픽쳐 리전은 전술한 리전 와이즈 패킹에서의 리전과 다른 개념일 수 있다.
shape_type 파라미터는 전술한 region_shape_type 필드와 같을 수 있다.
도 40 은 본 발명에 따른 커버리지 정보 의 또 다른 실시예를 도시한 도면이다.
전술한 바와 같이 360 비디오는 3D 로 제공될 수 잇다. 이러한 360 비디오를 3D 360 비디오 또는 스테레오 스코픽 옴니디렉셔널 비디오(stereoscopic omnidirectional video) 라고 불릴 수 있다.
3D 360 비디오가 복수개의 서브 픽쳐 트랙을 통해 전달되는 경우, 각각의 트랙은 비디오 영역들의 좌영상 또는 우영상을 운반할 수 있다. 또는 각 트랙은 한 영역의 좌영상과 우영상을 동시에 운반할 수도 있다. 좌영상과 우영상이 서로 다른 서브 픽쳐로 분리되어 전송되는 경우, 2D 만을 지원하는 수신기는 어느 하나의 영상만을 이용하여 해당 360 비디오 데이터를 2D 로 재생할 수 있다.
실시예에 따라 하나의 서브 픽쳐 트랙이 같은 커버리지를 가지는 영역의 좌영상과 우영상을 모두 운반하는 경우, 3D 360 비디오의 현재 뷰포트에 해당하는 서브 픽쳐 비트스트림들을 디코딩하는데 필요한 비디오 디코더의 개수가 제한될 수 있다.
도시된 커버리지 정보 의 또 다른 실시예에서, 뷰포트에 해당하는 3D 360 비디오의 서브 픽쳐 비트스트림을 선택하기 위하여, 커버리지 정보는 각 트랙과 관련된 구면상의 영역에 대한 커버리지 정보는 제공할 수 있다.
구체적으로, 3D 360 비디오의 서브 픽쳐의 컴포지션과 커버리지 시그널링을 위하여, 도시된 실시예의 커버리지 정보는 view_idc 정보를 더 포함할 수 있다. view_idc 정보는, 전술한 커버리지 정보의 다른 모든 실시예들에도 추가로 포함될 수 있다. 실시예에 따라 view_idc 정보는 CoverageInformationBox 및/또는 content converage(CC) 디스크립터에 포함될 수 있다.
도시된 실시예의 커버리지 정보는 CoverageInformationBox 형태로 나타날 수 있다. CoverageInformationBox 는 view_idc 필드를 기존의 RegionOnSphereStruct() 에 추가로 포함할 수 있다.
view_idc 필드는 해당 영역이 가지는 360 비디오가 3D 비디오인지 여부 및/또는 좌우영상인지 여부를 나타낼 수 있다. 본 필드가 0 인 경우, 해당 영역이 가지는 360 비디오는 2D 비디오일 수 있다. 본 필드가 1 인 경우, 해당 영역이 가지는 360 비디오는 3D 비디오의 좌영상일 수 있다. 본 필드가 2 인 경우, 해당 영역이 가지는 360 비디오는 3D 비디오의 우영상일 수 있다. 본 필드가 3 인 경우, 해당 영역이 가지는 360 비디오는 3D 비디오의 좌영상 및 우영상일 수 있다.
RegionOnSphereStruct() 는 전술한 바와 같을 수 있다.
도 41 은 본 발명에 따른 커버리지 정보 의 또 다른 실시예를 도시한 도면이다.
도시된 커버리지 정보 의 또 다른 실시예에서, view_idc 정보는 DASH 디스크립터로 구성된 커버리지 정보에, 파라미터 형태로 추가될 수 있다.
구체적으로, 도시된 실시예의 DASH 디스크립터는 center_yaw, center_pitch, hor_range, ver_range 및/또는 view_idc 파라미터를 포함할 수 있다. center_yaw, center_pitch, hor_range, ver_range 파라미터는 전술한 center_yaw, center_pitch, hor_range, ver_range 필드들과 동일할 수 있다.
view_idc 파라미터는 전술한 view_idc 필드와 같이, 해당 영역이 가지는 360 비디오가 3D 비디오인지 여부 및/또는 좌우영상인지 여부를 나타낼 수 있다. 이 파라미터의 값에 할당된 의미들은 전술한 view_idc 필드와 동일할 수 있다.
전술한 본 발명에 따른 커버리지 정보의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치 및 360 비디오 수신 장치의 실시예들에서, 커버리지 정보는 전술한 실시예들에 따른 커버리지 정보 일 수 있다.
도 42 는 본 발명에 따른 360 비디오 전송 장치에 의해 수행될 수 있는, 360 비디오를 전송하는 방법의 일 실시예를 나타낸 도면이다.
360 비디오를 전송하는 방법의 일 실시예는, 적어도 하나 이상의 카메라에 의해 캡쳐된 360 비디오 데이터를 처리하는 단계, 상기 픽쳐를 인코딩하는 단계, 상기 360 비디오 데이터에 대한 시그널링 정보를 생성하는 단계, 상기 인코딩된 픽쳐와 상기 시그널링 정보를 파일로 인캡슐레이팅하는 단계 및/또는 상기 파일을 전송하는 단계를 포함할 수 있다.
360 비디오 전송 장치의 비디오 프로세서는 적어도 하나 이상의 카메라에 의해 캡쳐된 360 비디오 데이터를 처리할 수 있다. 이 처리하는 과정에서, 비디오 프로세서는 360 비디오 데이터를 스티칭하고, 스티칭된 360 비디오 데이터를 픽쳐 상에 프로젝션할 수 있다. 실시예에 따라, 비디오 프로세서는 프로젝션된 픽쳐를 패킹된 픽쳐로 매핑하는 리전 와이즈 패킹을 수행할 수 있다.
360 비디오 전송 장치의 데이터 인코더는 픽쳐를 인코딩할 수 있다. 360 비디오 전송 장치의 메타데이터 처리부는 360 비디오 데이터에 대한 시그널링 정보를 생성할 수 있다. 여기서 시그널링 정보는 픽쳐의 서브 픽쳐가 3D 공간 상에서 차지하는 영역을 지시하는 커버리지 정보를 포함할 수 있다. 360 비디오 전송 장치의 인캡슐레이션 처리부는 인코딩된 픽쳐와 시그널링 정보를 파일로 인캡슐레이팅할 수 있다. 360 비디오 전송 장치의 전송부는 파일을 전송할 수 있다.
360 비디오를 전송하는 방법 의 다른 실시예에서, 커버리지 정보는 3D 공간 상에서 해당 영역의 중심이 되는 점의 야(yaw) 값 및 피치(pitch) 값을 나타내는 정보를 포함할 수 있다. 또한, 커버리지 정보는 3D 공간에서 해당 영역이 가지는 너비 값 및 높이 값을 나타내는 정보를 포함할 수 있다.
360 비디오를 전송하는 방법 의 또 다른 실시예에서, 커버리지 정보는 3D 공간에서 해당 영역이 4 개의 구면 상 대원(4 great circles) 에 의해 특정되는 형태인지, 또는 2 개의 야 원(yaw circle) 및 2 개의 피치 원(pitch circle) 에 의해 특정되는 형태인지 여부를 나타내는 정보를 더 포함할 수 있다.
360 비디오를 전송하는 방법 의 또 다른 실시예에서, 커버리지 정보는 해당 영역에 대응되는 360 비디오가 2D 비디오인지, 3D 비디오의 좌영상인지, 3D 비디오의 우영상인지 또는 3D 비디오의 좌영상 및 우영상을 모두 포함하는지 여부를 나타내는 정보를 더 포함할 수 있다.
360 비디오를 전송하는 방법 의 또 다른 실시예에서, 커버리지 정보는 DASH (Dynamic Adaptive Streaming over HTTP) 디스크립터의 형태로 생성되어, MPD (Media Presentation Description) 에 포함되어 360 비디오 데이터를 가지는 파일과는 다른 별도의 경로로 전송될 수 있다.
360 비디오를 전송하는 방법 의 또 다른 실시예에서, 360 비디오 전송 장치는 (송신측) 피드백 처리부를 더 포함하고, (송신측) 피드백 처리부는 수신측으로부터 현재 사용자의 뷰포트를 지시하는 피드백 정보를 수신할 수 있다.
360 비디오를 전송하는 방법 의 또 다른 실시예에서, 서브 픽쳐는 수신한 피드백 정보가 지시하는 현재 사용자의 뷰포트에 해당하는 서브 픽쳐이고, 커버리지 정보는 피드백 정보가 지시하는 뷰포트에 해당하는 서브 픽쳐에 대한 커버리지 정보일 수 있다.
전술한 본 발명에 따른 360 비디오 수신 장치는 360 비디오를 수신하는 방법을 수행할 수 있다. 360 비디오를 수신하는 방법은, 전술한 본 발명에 따른 360 비디오를 전송하는 방법에 대응되는 실시예들을 가질 수 있다. 360 비디오를 수신하는 방법 및 그 실시예들은, 전술한 본 발명에 따른 360 비디오 수신 장치 및 그 내/외부 컴포넌트들에 의해 수행될 수 있다.
도 43 은 본 발명의 한 관점(aspect) 에 따른 360 비디오 전송 장치를 도시한 도면이다.
한 관점에 따르면 본 발명은 360 비디오 전송 장치와 관련될 수 있다. 360 비디오 전송 장치는 360 비디오 데이터를 처리하고, 360 비디오 데이터에 대한 시그널링 정보를 생성하여 이를 수신측으로 전송할 수 있다.
구체적으로, 360 비디오 전송 장치는 360 비디오를 스티칭하고, 픽쳐에 프로젝션하고, 리전 와이즈 패킹을 수행하고, 이를 DASH 에 따른 포맷으로 처리하고, 360 비디오 데이터에 대한 시그널링 정보를 생성하고, 360 비디오 데이터 및/또는 시그널링 정보를 방송망 또는 브로드밴드를 통해 전송할 수 있다.
본 발명에 따른 360 비디오 전송 장치는 비디오 프로세서, 메타데이터 처리부, 인캡슐레이션 처리부 및/또는 전송부를 내/외부 컴포넌트로서 포함할 수 있다.
비디오 프로세서는 적어도 하나 이상의 카메라에 의해 캡쳐된 360 비디오 데이터를 처리할 수 있다. 비디오 프로세서는 360 비디오 데이터를 스티칭하고, 스티칭된 360 비디오 데이터를 2D 이미지 즉, 픽쳐 상에 프로젝션할 수 있다. 여기서 프로젝션된 픽쳐는 제 1 픽쳐라고 부를 수 있다. 실시예에 따라 비디오 프로세서는 프로젝션된 픽쳐의 각 리전(Region) 들을 패킹된 픽쳐로 매핑하여 리전 와이즈 패킹을 더 수행할 수도 있다. 여기서 패킹된 픽쳐는 제 2 픽쳐라고 부를 수 있다. 여기서 스티칭, 프로젝션, 리전 와이즈 패킹은 전술한 동명의 프로세스에 대응될 수 있다. 리전 와이즈 패킹은 실시예에 따라 리전별 패킹, 영역별 패킹 등으로 불릴 수 있다. 비디오 프로세서는 전술한 스티처, 프로젝션 처리부, 리전별 패킹 처리부 및/또는 데이터 인코더에 대응되는 역할을 수행하는 하드웨어 프로세서일 수 있다.
인캡슐레이션 처리부는 처리된 360 비디오 데이터를 DASH (Dynamic Adaptive Streaming over HTTP) 포맷의 데이터로 처리할 수 있다. 인캡슐레이션 처리부는 프로젝션된 픽쳐(제 1 픽쳐), 또는 리전 와이즈 패킹이 수행된 경우 패킹된 픽쳐(제 2 픽쳐) 를 DASH 포맷의 데이터로 처리할 수 있다. 인캡슐레이션 처리부는 해당 360 비디오 데이터들을 DASH 세그먼트들, 즉 DASH 레프리젠테이션들로 처리할 수 있다. 인캡슐레이션 처리부는 전술한 인캡슐레이션 처리부에 대응될 수 있다.
메타데이터 처리부는 360 비디오 데이터에 대한 시그널링 정보를 생성할 수 있다. 메타데이터 처리부는 360 비디오 데이터에 대한 시그널링 정보를 MPD (Media Presentation Description) 의 형태로 생성할 수 있다. 이 MPD 는 DASH 포맷을 전달되는 360 비디오 데이터에 대한 시그널링 정보를 포함할 수 있다. 메타데이터 처리부는 전술한 메타데이터 처리부에 대응될 수 있다.
전송부는 360 비디오 데이터 및 시그널링 정보를 전송할 수 있다. 여기서, 전송부는 DASH 레프리젠테이션들과 MPD 를 전송할 수 있다. 전송부는 전술한 전송처리부 및/또는 전송부에 대응되는 컴포넌트일 수 있다. 전송부는 방송망 또는 브로드밴드를 통해 해당 정보들을 전송할 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 일 실시예에서, 전술한 MPD 는 제 1 디스크립터를 포함할 수 있다. 제 1 디스크립터는 전술한 프로젝션 과정에 대한 시그널링 정보를 제공할 수 있다. 제 1 디스크립터는 360 비디오 데이터가 제 1 픽쳐 상에 프로젝션될 때 사용된 프로젝션 타입을 지시하는 정보를 포함할 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 다른 실시예에서, 전술한 프로젝션 타입을 지시하는 정보는 해당 프로젝션이 등장방형(equirectangular) 프로젝션 또는 큐브맵(cubemap) 프로젝션 타입인지를 지시할 수 있다. 프로젝션 타입을 지시하는 정보는 그 외에 다른 프로젝션 타입을 지시할 수도 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 전술한 MPD 는 제 2 디스크립터를 포함할 수 있다. 제 2 디스크립터는 전술한 리전 와이즈 패킹 과정에 대한 시그널링 정보를 제공할 수 있다. 제 2 디스크립터는 제 1 픽쳐에서 제 2 픽쳐로 리전 와이즈 패킹이 수행될 때 사용된 패킹 타입을 지시하는 정보를 포함할 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 전술한 패킹 타입을 지시하는 정보는 리전 와이즈 패킹이 사각형(rectangular) 리전 와이즈 패킹 타입을 가짐을 지시할 수 있다. 패킹 타입을 지시하는 정보는 리전 와이즈 패킹이 그 외에 다른 패킹 타입을 가짐을 지시할 수도 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 전술한 MPD 는 제 3 디스크립터를 포함할 수 있다. 제 3 디스크립터는 360 비디오 데이터의 커버리지(coverage) 에 관한 정보를 포함할 수 있다. 커버리지 정보는 360 비디오 데이터에 해당하는 전체 영역이 3D 공간 상에서 차지하는 영역을 지시할 수 있다. 이 커버리지 정보는 해당 360 비디오 컨텐츠 전체가 3D 공간 상에서 렌더링되었을 때, 그 영역이 3D 공간 상에서 차지하는 영역을 나타낼 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 전술한 커버리지 정보는 해당 전체 영역이 3D 공간 상에서 차지하게 되는 영역을, 그 영역의 중점 좌표 및/또는 수평 범위, 수직 범위를 지시하여 특정할 수 있다. 여기서 영역의 중점은 방위각(azimuth) 및 고도(elevation) 값을 통해 특정될 수 있다. 실시예에 따라 이 중점은 yaw 및 pitch 값을 통해 특정될 수도 있다. 여기서 수평 범위, 수직 범위는 각도의 범위로서 나타내어질 수 있다. 실시예에 따라 수평 범위, 수직 범위는 너비와 높이로 나타내어질 수도 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 전술한 DASH 레프리젠테이션들 중 적어도 하나는 타임드 메타데이터(timed metadata)를 포함하는 타임드 메타데이터 레프리젠테이션일 수 있다. 타임드 메타데이터를 다른 DASH 레프리젠테이션들을 통해 전달되는 360 비디오 데이터에 대한 메타데이터를 제공할 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 전술한 타임드 메타데이터는 초기 뷰포인트(initial viewpoint) 또는 초기 시점 (initial viewing orientation) 정보를 포함할 수 있다. 초기 뷰포인트 또는 초기 시점 정보는 해당 360 컨텐츠가 시작되었을 때, 사용자가 처음으로 보게 되는 뷰포인트를 지시할 수 있다. 전술한 바와 같이 뷰포인트는 초기 뷰포트(initial viewport) 의 중점일 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 초기 뷰포인트 정보를 포함하는 타임드 메타데이터는, 해당 초기 뷰포인트 정보가 적용되게 되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 지시할 수 있다. 초기 뷰포인트 정보를 포함하는 타임드 메타데이터는 이를 위한 식별자 정보를 포함할 수 있다. 이 식별자 정보를 통해 해당 초기 뷰포인트 정보와 연관되게 되는 DASH 레프리젠테이션이 식별/지시될 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 전술한 타임드 메타데이터는 추천 뷰포트(recommended viewport) 정보를 포함할 수 있다. 추천 뷰포트 정보는 해당 360 컨텐츠에서 서비스 프로바이더에 의해 추천되는 뷰포트를 지시할 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 추천 뷰포트 정보를 포함하는 타임드 메타데이터는, 해당 추천 뷰포트 정보가 적용되게 되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 지시할 수 있다. 추천 뷰포트 정보를 포함하는 타임드 메타데이터는 이를 위한 식별자 정보를 포함할 수 있다. 이 식별자 정보를 통해 해당 추천 뷰포트 정보와 연관되게 되는 DASH 레프리젠테이션이 식별/지시될 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 해당 360 비디오 데이터가 모노스코픽(monoscopic) 360 비디오인지 스테레오스코픽(stereoscopic) 360 비디오인지 여부와, 스트레오스코픽 360 비디오 데이터인 경우 해당 360 비디오 데이터가 좌영상인지, 우영상인지, 좌영상과 우영상을 모두 포함하는지 여부를 한번에 나타내는 시그널링 필드가 정의될 수 있다. 즉, 이 시그널링 필드는 해당 360 비디오 데이터에 대하여, 프레임 패킹 어레인지먼트(frame packing arrangement) 정보 및 스테레오스코픽(steremoscopic) 360 비디오 여부를 동시에 지시할 수 있다. 전술한 제 1 디스크립터, 제 2 디스크립터 및/또는 제 3 디스크립터는 관련된 360 비디오 데이터에 대하여 전술한 사항들을 지시하는 시그널링 필드를 각각 포함할 수 있다. 이 시그널링 필드는 view_idc 필드에 해당할 수 있다.
본 발명에 따른 360 비디오 전송 장치 의 또 다른 실시예에서, 모노스코픽 360 비디오 데이터는 2D (2-Dimension) 로 제공되는 360 비디오 데이터를 의미할 수 있다. 스테레오스코픽 360 비디오 데이터는 3D 로 제공될 수 있는 360 비디오 데이터를 의미할 수 있다. 수신기의 캐패빌리티에 따라 스테레오스코픽 360 비디오 데이터도 2D 로 제공될 수도 있다.
전술한 본 발명에 따른 360 비디오 전송 장치 의 실시예들은 서로 조합될 수 있다. 또한 전술한 본 발명에 따른 360 비디오 전송 장치 의 내/외부 컴포넌트들은 실시예에 따라 추가, 변경, 대체 또는 삭제될 수 있다. 또한 전술한 360 비디오 전송 장치의 내/외부 컴포넌트들은 하드웨어 컴포넌트로 구현될 수 있다.
도 44 는 본 발명의 다른 관점에 따른 360 비디오 수신 장치 를 도시한 도면이다.
다른 관점에 따르면 본 발명은 360 비디오 수신 장치와 관련될 수 있다. 360 비디오 수신 장치는 360 비디오 데이터 및/또는 360 비디오 데이터에 대한 시그널링 정보를 수신하고, 이를 처리하여 360 비디오를 사용자에게 렌더링할 수 있다. 360 비디오 수신 장치는 전술한 360 비디오 전송 장치 에 대응되는 수신측에서의 장치일 수 있다.
구체적으로, 360 비디오 수신 장치는 360 비디오 데이터 및/또는 360 비디오 데이터에 대한 시그널링 정보를 수신하고, 시그널링 정보를 획득하고, 이를 기반으로 360 비디오 데이터를 처리하여 360 비디오를 렌더링할 수 있다.
본 발명에 따른 360 비디오 수신 장치는 수신부, 데이터 프로세서 및/또는 메타데이터 파서를 내/외부 컴포넌트로서 포함할 수 있다.
수신부는 360 비디오 데이터 및/또는 360 비디오 데이터에 대한 시그널링 정보를 수신할 수 있다. 실시예에 따라 수신부는 이 정보들을 DASH 레프리젠테이션과 MPD 의 형태로 수신할 수 있다. 실시예에 따라 수신부는 방송망 또는 브로드밴드를 통해 해당 정보들을 수신할 수 있다. 수신부는 전술한 수신부에 대응되는 컴포넌트일 수 있다.
데이터 프로세서는 수신된 정보로부터 360 비디오 데이터 및/또는 360 비디오 데이터에 대한 시그널링 정보를 획득할 수 있다. 데이터 프로세서는 수신된 정보에 대하여 전송 프로토콜에 따른 처리를 하거나, DASH 레프리젠테이션의 DASH 세그먼트들을 디캡슐레이션하거나, 360 비디오 데이터에 대해 디코딩을 수행할 수 있다. 또한 데이터 프로세서는 360 비디오 데이터에 대해 리-프로젝션을 수행하고, 이에 따라 렌더링을 수행할 수 있다. 데이터 프로세서는 전술한 수신 처리부, 디캡슐레이션 처리부, 데이터 디코더, 리-프로젝션 처리부 및/또는 렌더러에 대응되는 역할을 수행하는 하드웨어 프로세서일 수 있다.
메타데이터 파서는 획득된 MPD 로부터 시그널링 정보를 파싱할 수 있다. 메타데이터 파서는 전술한 메타데이터 파서에 대응될 수 있다.
본 발명에 따른 360 비디오 수신 장치는, 전술한 본 발명에 따른 360 비디오 전송 장치에 대응되는 실시예들을 가질 수 있다. 본 발명에 따른 360 비디오 수신 장치 및 그 내/외부 컴포넌트들은, 전술한 본 발명에 따른 360 비디오 전송 장치의 실시예들에 대응되는 실시예들을 수행할 수 있다.
전술한 본 발명에 따른 360 비디오 수신 장치의 실시예들은 서로 조합될 수 있다. 또한 전술한 본 발명에 따른 360 비디오 수신 장치의 내/외부 컴포넌트들은 실시예에 따라 추가, 변경, 대체 또는 삭제될 수 있다. 또한 전술한 360 비디오 수신 장치의 내/외부 컴포넌트들은 하드웨어 컴포넌트로 구현될 수 있다.
도 45 는 본 발명에 따른 커버리지 디스크립터의 일 실시예를 도시한 도면이다.
본 발명에서, 360 비디오 데이터가 DASH 에 따라 전송이 될 때, 이 360 비디오 데이터에 대한 시그널링 정보가 정의될 수 있다.
이러한 360 비디오 데이터에 대한 시그널링 정보는, 해당 360 비디오가 어안(fisheye) 컨텐트인지 여부에 대한 지시(indication), 어안 컨텐트가 아니라면 해당 360 비디오에 대한 프로젝션 및/또는 매핑 타입에 대한 지시, 해당 360 비디오 데이터의 컨텐트에 의해 커버되는 구면 상의 영역, 해당 360 비디오 데이터가 렌더링이 시작될 때의 초기 뷰포인트 및/또는 추천 뷰포인트에 대한 정보 등을 포함할 수 있다.
이러한 시그널링이 DASH 에서 구현되기 위하여, 다양한 시그널링 정보가 DASH 디스크립터의 형태로 정의될 수 있다. 본 발명에 따라 어안 360 비디오 지시 디스크립터, 프로젝션 디스크립터, 패킹 디스크립터 및/또는 커버리지 디스크립터가 정의될 수 있다.
본 발명에 따른 어안 360 비디오 지시 디스크립터는(도시되지 않음), 어안 360 비디오 지시 관련 정보를 포함할 수 있다. 어안 360 비디오 지시 디스크립터는 DASH 디스크립터로서, 해당 360 비디오 컨텐트가 어안 컨텐트인지 여부를 지시하는데 사용될 수 있다.
어안 360 비디오 지시 디스크립터의 일 실시예에서, 어안 360 비디오 지시 디스크립터는 "urn:mpeg:dash:omv-fisheye:201x" 와 같은 새로운 schemIdURI 로 식별될 수 있다. 이 디스크립터의 @value 값이 1 인 경우, 이는 해당 360 컨텐트가 어안 컨텐트임을 지시할 수 있다. 어안 360 비디오 지시 디스크립터는 DASH MPD 의 Essential Property 또는 Supplemental Property 디스크립터의 형태로서 전달될 수 있다. 또한 이 디스크립터는, 해당 비디오 데이터가 저장/전송되는 어댑테이션 셋, 레프리젠테이션 또는 서브 레프리젠테이션의 하위에 존재할 수 있다.
본 발명에 따른 프로젝션 디스크립터는(도시되지 않음), 프로젝션 관련 정보를 포함할 수 있다. 프로젝션 디스크립터는 DASH 디스크립터로서, 해당 360 비디오 데이터의 프로젝션 포맷을 지시하는데 사용될 수 있다. 프로젝션 디스크립터는 제 1 디스크립터로 불릴 수도 있다.
프로젝션 디스크립터의 일 실시예에서, 프로젝션 디스크립터는 "urn:mpeg:dash:omv-proj:201x" 와 같은 새로운 schemIdURI 로 식별될 수 있다. 이 디스크립터의 @value 값은 360 비디오 데이터가 픽쳐에 프로젝션될 때 사용된 프로젝션 포맷을 지시할 수 있다. 이 디스크립터의 @value 값은 ProjectionFormatBox 의 projection_type 과 같은 의미를 가질 수 있다. 프로젝션 디스크립터는 DASH MPD 의 Essential Property 또는 Supplemental Property 디스크립터의 형태로서 전달될 수 있다. 또한 이 디스크립터는, 해당 비디오 데이터가 저장/전송되는 어댑테이션 셋, 레프리젠테이션 또는 서브 레프리젠테이션의 하위에 존재할 수 있다.
실시예에 따라 프로젝션 디스크립터는 프로젝션 과정에서 사용된 프로젝션 타입이 등장방형(equirectangular) 프로젝션 또는 큐브맵(cubemap) 프로젝션 타입인지를 지시할 수 있다. 프로젝션 디스크립터는 그 외에 다른 프로젝션 타입을 지시할 수도 있다.
본 발명에 따른 패킹 디스크립터는(도시되지 않음), 패킹 관련 정보를 포함할 수 있다. 패킹 디스크립터는 DASH 디스크립터로서, 해당 360 비디오 데이터의 패킹 포맷을 지시하는데 사용될 수 있다. 패킹 디스크립터는 제 2 디스크립터로 불릴 수도 있다.
패킹 디스크립터의 일 실시예에서, 패킹 디스크립터는 "urn:mpeg:dash:omv-pack:201x" 와 같은 새로운 schemIdURI 로 식별될 수 있다. 이 디스크립터의 @value 값은 360 비디오 데이터가 제 1 픽쳐에서 제 2 픽쳐로 리전 와이즈 패킹이 수행될 때 사용된 패킹 포맷을 지시할 수 있다. 이 디스크립터의 @value 값은 콤마(comma) 로 구분되는 RegionWisePackingBox 의 packing_type 값들의 리스트일 수 있다. 패킹 디스크립터는 DASH MPD 의 Essential Property 또는 Supplemental Property 디스크립터의 형태로서 전달될 수 있다. 또한 이 디스크립터는, 해당 비디오 데이터가 저장/전송되는 어댑테이션 셋, 레프리젠테이션 또는 서브 레프리젠테이션의 하위에 존재할 수 있다.
실시예에 따라 패킹 디스크립터는 리전 와이즈 패킹 과정에서 사용된 패킹 타입이 사각형(rectangular) 리전 와이즈 패킹 타입을 가짐을 지시할 수 있다. 패킹 디스크립터는 리전 와이즈 패킹이 그 외에 다른 패킹 타입을 가짐을 지시할 수도 있다.
본 발명에 따른 커버리지 디스크립터는 커버리지 관련 정보를 포함할 수 있다. 커버리지 디스크립터는 DASH 디스크립터로서, 해당 360 비디오 데이터 에 해당하는 전체 영역이 3D 공간 상에서 차지하는 영역을 지시할 수 있다. 즉, 커버리지 디스크립터는 해당 360 비디오 컨텐츠 전체가 3D 공간 상에서 렌더링되었을 때, 그 영역이 3D 공간 상에서 차지하는 영역을 나타낼 수 있다. 커버리지 디스크립터는 제 3 디스크립터라고 불릴 수도 있다.
도시된 커버리지 디스크립터의 일 실시예에서, 커버리지 디스크립터는 “urn:mpeg:dash:omv-coverage:201x” 와 같은 새로운 schemIdURI 로 식별될 수 있다. 이 디스크립터의 @value 값은 360 비디오 데이터에 해당하는 영역이 3D 공간 상에서 차지하는 영역을 지시할 수 있다. 이 디스크립터의 @value 값은 콤마(comma) 로 구분되는 CoverageInformationBox 값들의 리스트일 수 있다. 커버리지 디스크립터는 DASH MPD 의 Essential Property 또는 Supplemental Property 디스크립터의 형태로서 전달될 수 있다. 또한 이 디스크립터는, 해당 비디오 데이터가 저장/전송되는 어댑테이션 셋 또는 서브 레프리젠테이션의 하위에 존재할 수 있다.
도시된 커버리지 디스크립터의 일 실시예에서, 커버리지 디스크립터는 source_id, total_center_yaw, total_center_pitch, total_hor_range 및/또는 total_ver_range 파라미터를 를 포함할 수 있다.
source_id 파라미터는 해당 소스 360 비디오 컨텐트를 식별하기 위한 식별자를 나타낼 수 있다. 본 파라미터는 음수가 아닌 정수일 수 있다.
total_center_yaw, total_center_pitch 파라미터는, 전체 360 비디오 컨텐트가 프로젝션된 구면 상 영역(spherical surface) 의 중심점(가운데 점) 의 좌표를 나타낼 수 있다. 실시예에 따라 각 파라미터들은 각각 중심점의 yaw 및 pitch 값을 나타낼 수 있다. 실시예에 따라 각 파라미터들은 각각 중심점의 longitude 및 latitude 값을 나타낼 수 있다. 실시예에 따라 각 파라미터들은 각각 중심점의 방위각(azimuth) 및 고도(elevation) 값을 나타낼 수 있다.
total_hor_range, total_ver_range 파라미터는, 전체 360 비디오 컨텐트가 프로젝션된 구면 상 영역의 수평 범위, 수직 범위를 나타낼 수 있다. 수평 범위, 수직 범위는 각도의 범위로서 나타내어질 수 있다. 실시예에 따라 수평 범위, 수직 범위는 너비와 높이로 나타내어질 수도 있다. 실시예에 따라 각 파라미터들은, 전술한 CoverageInformationBox 의 hor_range, ver_range 와 같은 의미를 가질 수 있다.
전술한 본 발명에 따른 어안 360 비디오 지시 디스크립터의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치의 실시예들에서, 어안 360 비디오 지시 디스크립터 은 전술한 실시예들에 따른 어안 360 비디오 지시 디스크립터 일 수 있다.
전술한 본 발명에 따른 프로젝션 디스크립터의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치의 실시예들에서, 프로젝션 디스크립터 은 전술한 실시예들에 따른 프로젝션 디스크립터 일 수 있다.
전술한 본 발명에 따른 패킹 디스크립터의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치의 실시예들에서, 패킹 디스크립터 은 전술한 실시예들에 따른 패킹 디스크립터 일 수 있다.
전술한 본 발명에 따른 커버리지 디스크립터의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치의 실시예들에서, 커버리지 디스크립터 은 전술한 실시예들에 따른 커버리지 디스크립터 일 수 있다.
도 46 은 본 발명에 따른 다이나믹(dynamic) 영역 디스크립터의 일 실시예를 도시한 도면이다.
전술한 바와 같이 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보가 시그널링 정보로서 제공될 수 있다. 실시예에 따라, 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보는 타임드 메타데이터 형태로 전달될 수 있다. 전술한 DASH 레프리젠테이션들 중 적어도 하나는 타임드 메타데이터 레프리젠테이션일 수 있고, 이 타임드 메타데이터 레프리젠테이션은 타임드 메타데이터를 포함할 수 있다.
이 때, 타임드 메타데이터로서 전달되는 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보를 활용하기 위하여, 다이나믹(dynamic) 영역 디스크립터가 사용될 수 있다.
다이나믹 영역 디스크립터는 구면 상에서 변화하는 영역에 대한 정보를 제공할 수 있다. 다이나믹 영역 디스크립터는 DASH 디스크립터로서, 구면 상 다이나믹 영역에 대한 정보를 제공하는데 사용될 수 있다. 다이나믹 영역 디스크립터는 "urn:mpeg:dash:dynamic-ros:201x" 와 같은 새로운 schemIdURI 로 식별될 수 있다. 이 디스크립터의 @value 값은, 콤마로 구분되는, 도시된 바와 같은 파라미터 값들의 리스트일 수 있다. 프로젝션 디스크립터는 DASH MPD 의 Essential Property 또는 Supplemental Property 디스크립터의 형태로서 전달될 수 있다. 또한 이 디스크립터는, 해당 비디오 데이터가 저장/전송되는 어댑테이션 셋 또는 서브 레프리젠테이션의 하위에 존재할 수 있다.
도시된 다이나믹 영역 디스크립터는 source_id 및/또는 coordinate_id 를 포함할 수 있다.
source_id 파라미터는 해당 소스 360 비디오 컨텐트를 식별하기 위한 식별자를 나타낼 수 있다. 본 파라미터는 음수가 아닌 정수일 수 있다.
coordinate_id 파라미터는 구면 상 영역에 대한 타임드 메타데이터를 운반하는 타임드 메타데이터 트랙의 레프리젠테이션을 지시할 수 있다. 즉, 본 파라미터는 해당 타임드 메타데이터를 제공하는 레프리젠테이션의 @id 를 특정할 수 있다.
이러한 다이나믹 영역 디스크립터를 활용하여 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보를 구분할 수 있다. 즉, 특정 360 비디오 데이터가 전달되는 레프리젠테이션은 다이나믹 영역 디스크립터를 포함할 수 잇다. 이 다이나믹 영역 디스크립터는 해당 360 비디오 데이터에 대한 타임드 메타데이터를 제공하는 레프리젠테이션을 지시할 수 있다. 이 때, 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보를 제공하는 타임드 메타데이터 레프리젠테이션은, 다이나믹 영역 디스크립터에 의해 식별될 수 있다. 이를 통해 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보가 해당 360 비디오 데이터와 연관될 수 있다.
여기서, 초기 뷰포인트 정보는 해당 360 컨텐츠가 시작되었을 때, 사용자가 처음으로 보게 되는 뷰포인트를 지시할 수 있다. 전술한 바와 같이 뷰포인트는 초기 뷰포트(initial viewport) 의 중점일 수 있다. 여기서, 추천 뷰포트 정보는 해당 360 컨텐츠에서 서비스 프로바이더에 의해 추천되는 뷰포트를 지시할 수 있다.
초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보를 나타내는 타임드 메타데이터는, 타임드 메타데이터 레프리젠테이션에 의해 제공될 수 있다. 이 타임드 메타데이터 레프리젠테이션은 invp 트랙을 제공할 수 있다. 이 타임드 메타데이터 레프리젠테이션은, 해당 시그널링 정보들이 연관된 실제 360 비디오 데이터를 전달하는 레프리젠테이션과 연관될 수 있다.
초기 뷰포인트 정보를 포함하는 타임드 메타데이터 레프리젠테이션은, @associationId 를 포함할 수 있다. @associationId 는 해당 초기 뷰포인트 정보가 적용되는 실제 360 비디오 데이터를 운반하는 레프리젠테이션을을 지시할 수 있다. 즉, @associationId 는 연관된 실제 데이터가 운반되는 DASH 레프리젠테이션을 식별할 수 있다. 이 예는 추천 뷰포인트/뷰포트에 대해서도 마찬가지로 적용될 수 있다.
실시예에 따라 타임드 메타데이터 레프리젠테이션은 @associationType 을 더 포함할 수 있다. @associationType 는 타임드 메타데이터 레프리젠테이션과 실제 데이터를 운반하는 레프리젠테이션 간의 관계(association)의 타입을 지시할 수 있다. @associationType 가 cdsc 값을 가지는 경우, 해당 타임드 메타데이터는 하나의 미디어 트랙에 대해 각각 기술할 수 있다. 여기서 미디어 트랙은 실제 데이터를 운반하는 트랙을 의미할 수 있다. @associationType 가 cdtg 값을 가지는 경우, 해당 타임드 메타데이터는 트랙 그룹에 대해서 기술할 수 있다.
전술한 본 발명에 따른 초기 뷰포인트 정보, 추천 뷰포인트/뷰포트 정보의 실시예들은 서로 조합될 수 있다. 본 발명에 따른 360 비디오 전송 장치의 실시예들에서, 초기 뷰포인트 정보, 추천 뷰포인트/뷰포트 정보는 전술한 실시예들에 따른 초기 뷰포인트 정보, 추천 뷰포인트/뷰포트 정보일 수 있다.
전술한 본 발명에 따른 초기 뷰포인트 정보, 추천 뷰포인트/뷰포트를 전달하는 방법의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치의 실시예들에서, 초기 뷰포인트 정보, 추천 뷰포인트/뷰포트를 전달하는 방법 은 전술한 실시예들에 따른 초기 뷰포인트 정보, 추천 뷰포인트/뷰포트를 전달하는 방법 일 수 있다.
도 47 은 본 발명에 따른 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보의 활용례를 도시한 도면이다.
도시된 활용례에서, MPD 는 하나의 피리오드(Period)에 대하여 2 개의 어댑테이션 셋을 기술하고 있다. 첫번째 어댑테이션 셋 (47010) 은 실제 360 비디오 데이터를 전달하는 어댑테이션 셋이고, 두번째 어댑테이션 셋 (47030) 은 초기 뷰포인트 정보를 제공하는 타임드 메타데이터를 포함하는 어댑테이션 셋일 수 있다.
첫번째 어댑테이션 셋(47010)은 하나의 레프리젠테이션을 포함하고 있는데, 이 레프리젠테이션은 '360-video' 라는 ID 를 가지는 레프리젠테이션일 수 있다. 이 레프리젠테이션은 해당 레프리젠테이션을 통해 전달되고 있는 360 비디오 데이터에 대한 정보를 기술하는 DASH 디스크립터들을 포함할 수 있다(47020).
이 DASH 디스크립터들(47020)은 레프리젠테이션 레벨에 포함되어 있으므로, 해당 레프리젠테이션에 포함되는 360 비디오 데이터에 대해 기술할 수 있다. 이 디스크립터들은 각각 프로젝션 디스크립터, 패킹 디스크립터, 다이나믹 영역 디스크립터일 수 있다.
활용례의 프로젝션 디스크립터는 0 의 value 를 가지므로, 이 레프리젠테이션의 360 비디오 데이터에는 등장방형(equirectangular) 프로젝션이 사용되었음을 알 수 있다. 패킹 디스크립터는 0 의 value 를 가지므로, 이 레프리젠테이션의 360 비디오 데이터에는 사각형(rectangular) 리전 와이즈 패킹이 수행되었음을 알 수 있다.
활용례의 다이나믹 영역 디스크립터에서, source_id 는 1 이고, coordinate_id 는 'initial-viewpoint' 일 수 있다. 이를 통해 해당 레프리젠테이션의 360 비디오 데이터와 연관된 타임드 메타데이터는 'initial-viewpoint' 로 식별되는 레프리젠테이션에 의해 제공됨을 알 수 있다.
두번째 어댑테이션 셋(47030)은 역시 하나의 레프리젠테이션(47040)을 포함하고 있는데, 이 레프리젠테이션(47040)은 'initial-viewpoint' 라는 ID 를 가지는 레프리젠테이션일 수 있다. 이 레프리젠테이션은 전술한 초기 뷰포인트에 대한 정보를 제공하는 타임드 메타데이터를 포함할 수 있다.
이 레프리젠테이션(47040)은, associationId 값(47050)으로 360-video 를 가질 수 있다. 이에 따라 해당 타임드 메타데이터는 360-video 라는 ID 로 식별되는 레프리젠테이션과 연관됨을 알 수 있다. 이 레프리젠테이션의 360 비디오 데이터에는, 타임드 메타데이터 레프리젠테이션(47040) 에 의해 제공되는 타임드 메타데이터가 적용될 수 있다.
도 48 은 본 발명에 따른 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보의 다른 활용례를 도시한 도면이다.
전술한 바와 같이, 360 비디오 데이터가 DASH 형태로 전달될 때, 360 비디오 데이터에 대한 시그널링 정보는 타임드 메타데이터로서 전달될 수 있다. 타임드 메타데이터는 레프리젠테이션을 통해 전달되며, 이 레프리젠테이션은 초기 뷰포인트 정보를 제공하는 invp 트랙 및/또는 추천 뷰포인트/뷰포트 정보를 제공하는 rcvp 트랙을 포함할 수 있다.
도시된 활용례에서, MPD 는 하나의 360 비디오 스트림과 초기 뷰포인트 정보를 제공하는 타임드 메타데이터 레프리젠테이션에 대해 기술하고 있다.
도시된 활용례에서, MPD 는 2 개의 어댑테이션 셋을 기술할 수 있다.
첫번째 어댑테이션 셋(48010) 은 실제 360 비디오 데이터를 가지는 어댑테이션 셋일 수 있다. 이 어댑테이션 셋은 '360-video' 로 식별되는 레프리젠테이션을 가질 수 있다. 이 레프리젠테이션은 360 비디오 데이터를 운반할 수 있다. 이 레프리젠테이션은 rwpk 디스크립터 즉, 리전 와이즈 패킹에 대한 정보를 제공하는 디스크립터(48020)를 포함할 수 있다. 이 디스크립터는 해당 레프리젠테이션의 360 비디오 데이터에는 리전 와이즈 패킹이 수행되지 않았음을 지시할 수 있다.
두번째 어댑테이션 셋(48030) 은 초기 뷰포인트 관련 정보를 제공하는 타임드 메타데이터를 포함할 수 있다. 이 어댑테이션 셋은 타임드 메타데이터 레프리젠테이션을 포함할 수 있다. 이 레프리젠테이션은 'initial-viewpoint' 라는 ID 로 식별될 수 있고, associationId 값은 '360-video' 를 가질 수 있다. associationId 값을 통해, 이 타임드 메타데이터 레프리젠테이션의 타임드 메타데이터는, 첫번째 어댑테이션 셋(48010) 의 '360-video' ID 를 가지는 레프리젠테이션의 360 비디오 데이터에 적용될 수 있음을 알 수 있다.
도 49 는 본 발명에 따른 초기 뷰포인트 정보 및/또는 추천 뷰포인트/뷰포트 정보의 또 다른 활용례를 도시한 도면이다.
도시된 활용례에서, MPD 는 두 개의 360 비디오 스트림과 추천 뷰포트 정보를 제공하는 타임드 메타데이터 레프리젠테이션에 대해 기술하고 있다. 두 개의 360 비디오 스트림들은 각각 360 비디오의 서브 픽쳐 스트림을 운반할 수 있다. 즉, 하나의 비디오 스트림은 360 비디오 데이터의 서브 픽쳐 하나를 운반할 수 있다.
도시된 활용례에서, MPD 는 3 개의 어댑테이션 셋을 기술할 수 있다.
첫번째 어댑테이션 셋(49010) 은 실제 360 비디오 데이터를 가지는 어댑테이션 셋일 수 있다. 이 어댑테이션 셋은 '180-video-1' 로 식별되는 레프리젠테이션을 가질 수 있다. 이 레프리젠테이션은 -180 도에서 0 도에 해당하는 360 비디오 데이터의 서브 픽쳐를 운반할 수 있다.
두번째 어댑테이션 셋(49020) 은 실제 360 비디오 데이터를 가지는 어댑테이션 셋일 수 있다. 이 어댑테이션 셋은 '180-video-2' 로 식별되는 레프리젠테이션을 가질 수 있다. 이 레프리젠테이션은 0 도에서 180 도에 해당하는 360 비디오 데이터의 서브 픽쳐를 운반할 수 있다.
세번째 어댑테이션 셋(49030) 은 추천 뷰포트 관련 정보를 제공하는 타임드 메타데이터를 포함할 수 있다. 이 어댑테이션 셋은 타임드 메타데이터 레프리젠테이션을 포함할 수 있다. 이 레프리젠테이션은 'recommended-viewport' 라는 ID 로 식별될 수 있고, associationId 값은 '180-video-1, 180-video-2' 를 가질 수 있다. associationId 값을 통해, 이 타임드 메타데이터 레프리젠테이션의 타임드 메타데이터는, 첫번째 및 두번째 어댑테이션 셋(49010, 49020) 의 각각의 레프리젠테이션의 360 비디오 데이터에 적용될 수 있음을 알 수 있다. 이 때 assocationType 값은 cdtg 를 가질 수 있다.
도 50 은 본 발명에 따른 스테레오스코픽 360 비디오 데이터 시그널링에 있어서, 갭 분석(gap analysis) 설명을 위한 도면이다.
전술한 바와 같이, 360 비디오 데이터에 대한 시그널링 정보는 ISOBMFF 의 박스 형태로 저장/전달되거나, DASH MPD 의 디스크립터 등의 형태로 저장/전송될 수 있다.
특히, 스테레오스코픽 360 비디오 데이터에 대한 시그널링 정보 중, 프레임 패킹 어레인지먼트(frame packing arrangement) 에 대한 시그널링 및 뷰 지시(view indication) 에 대한 시그널링에 대하여 갭 분석을 수행해 볼 수 있다. 여기서 특히, 각각의 시그널링 정보가 ISOBMFF 와 DASH MPD 를 통해 시그널링될 때, 차이를 분석해볼 수 있다.
여기서 프레임 패킹이란, 하나의 서브 픽쳐, 트랙 등에 복수개의 영상이 매핑되는 것을 의미할 수 있다. 예를 들어 하나의 트랙에 좌영상과 우영상이 모두 포함되어 있는 경우, 프레임 패킹이 되었다고 말할 수 있다. 이 때 좌영상과 우영상이 포함되어 있는 배치 형태를, 프레임 패킹 어레인지먼트라고 부를 수 있다. 도시된 50030 과 같은 경우, 사이드 바이 사이드의 프레임 패킹 어레인지먼트를 가진다고 할 수 있다.
여기서 뷰 지시란, 해당 스테레오스코픽 360 비디오 데이터가 좌영상인지 우영상인지, 또는 좌영상과 우영상을 함께 가지는 영상인지를 지시하는 것을 말할 수 있다.
먼저, 스테레오스코픽 360 비디오에 있어서, 프레임 패킹 어레인지먼트의 시그널링에 대해서 설명한다.
ISOBMFF 를 통한 시그널링의 경우, 프레임 패킹 어레인지먼트는 ISOBMFF 의 StereoVideoBox 를 통해 지시될 수 있다. stereo_scheme 에 따라 다양한 방식으로 프레임 패킹 어레인지먼트가 지시될 수 있다.
즉, stereo_scheme 이 1 인 경우 ISO/IEC 14496-10 에 따른 프레임 패킹 스킴, 2 인 경우 ISO/IEC 13818-2 에 따른 프레임 패킹 스킴, 3 인 경우 ISO/IEC 23000-11 에 따른 프레임 패킹 스킴이 사용될 수 있다.
예를 들어, 1 의 값을 가지는 stereo_scheme, 3 의 값을 가지는 stereo_indication_type 에 의해, 해당 트랙에 사이드 바이 사이드 프레임 패킹 어레인지먼트가 사용됨이 지시될 수 있다. 이 프레임 패킹 어레인지먼트는 다시, 2 의 값을 가지는 stereo_scheme, 0000011 의 값을 가지는 stereo_indication_type 에 의해 지시될 수도 있다. 또한 이 프레임 패킹 어레인지먼트는 3 의 값을 가지는 stereo_scheme, 0x00 의 값을 가지는 stereo_indication_type 에 의해 지시될 수도 있다.
DASH MPD 를 통한 시그널링의 경우, 프레임 패킹 어레인지먼트는 FramePacking 엘레멘트에 의해 지시될 수 있다. 이 엘레멘트는 프레임 패킹 컨피규레이션 스킴 및/또는 프레임 패킹 어레인지먼트를 식별할 수 있다. DASH 클라이언트는 이 엘레멘트를 기반으로 어댑테이션 셋을 선택하거나 리젝(reject)할 수 있다. 예를 들어, 어댑테이션 셋 및/또는 레프리젠테이션의 360 비디오 데이터가 사이드 바이 사이드 프레임 패킹 어레인지먼트를 가지는 경우, FramePacking 엘레멘트의 @value 는 3 의 값을 가질 수 있다.
다음으로, 스테레오스코픽 360 비디오에 있어서, 뷰 지시의 시그널링에 대해서 설명한다.
ISOBMFF 를 통한 시그널링의 경우, StereoVideoBox 에 의해 뷰 지시가 수행될 수 있다. StereoVideoBox 는 ISOBMFF 의 다른 트랙들에 의해 전달되는 스테레오스코픽 360 비디오 데이터에 대해, 좌영상 또는 우영상인지 여부를 지시할 수 있다. 이 때, scheme_type 은 3 의 값을 가질 수 있고, stereo_indication_type 은 0x03 의 값을 가질 수 있다. 이는 각각 ISO/IEC 23000-11 에 정의된 스테레오 스킴을 사용함을 지시하고, “left/right view sequence type” 을 따름을 지시할 수 있다.
DASH MPD 를 통한 시그널링의 경우, Role 디스크립터에 의해 뷰 지시가 수행될 수 있다. @schemeUri 가 "urn:mpeg:dash:stereoid:2011" 의 값을 가지는 Role 디스크립터의 @value 는 스테레오스코픽 비디오의 좌우 영상의 페어를 지시하는데 사용될 수 있다. 예를 들어, 어느 두 스트림을 기술하는 AdaptationSet 엘레멘트가 @schemeUri 가 "urn:mpeg:dash:stereoid:2011" 의 값을 가지는 Role 디스크립터를 가지고, @value 값이 l0, r0 인 경우, 이는 각각의 스트림이 좌, 우영상에 해당함을 나타낼 수 있다. 또는 실시예에 따라, FramePacking 엘레멘트가 사용될 수 있다. 컨피규레이션을 지시하기 위해서 FramePacking 엘레멘트의 @value 는 6 으로 셋될 수 있다. 이는 “one frame of a frame pair” 를 지시할 수 있다.
스테레오스코픽 비디오에 대한 시그널링 방안들의 갭 분석을 하면 다음과 같다.
스테레오스코픽 360 비디오에 있어서, 프로젝션된 좌영상과 우영상은 프로젝션된 픽쳐(제 1 픽쳐) 상에 배열될 수 있다. 이 때 배열은 탑-바텀 또는 사이드 바이 사이드 프레임 패킹 어레인지먼트가 사용될 수 있다. 프로젝션된 픽쳐의 스테레오스코픽 어레인지먼트는 전술한 바와 같이 StereoVideoBox 의 stereo_scheme 이 4 를 가리키고, stereo_indication_type 가 프레임 패킹 어레인지먼트를 가리키는 것에 의해 지시될 수 있다. 또한 프로젝션된 픽쳐의 스테레오스코픽 어레인지먼트는, 전술한 바와 같이 MPD 의 FramePacking 의 @value 값에 의해 지시될 수도 있다.
또한, 리전 와이즈 패킹이 수행되는 경우, 프로젝션된 리전의 위치, 레졸루션, 사이즈 등은 패킹된 리전의 그것들과 달라질 수 있다. 도시된 (50010) 은, 리전 와이즈 패킹 전후로 프로젝션된 리전의 포지션 및/또는 사이즈가 변경될 수 있는지를 나타낸다. 같은 뷰의 프로젝션된 리전들(예를들어, L1, L2) 이 프로젝션된 픽쳐 상에서 근접하게 위치된 반면, 패킹된 리전들은 리전 와이즈 패킹 뒤에 그 위치가 멀리 떨어지도록 변경될 수 있다. 또한 리전 와이즈 패킹 후에 레졸루션이 변경될 수 있다. 도시된 (50010) 에서, L1 과 R1 은 같은 레졸루션을 가졌었지만, 리전 와이즈 패킹 후에 L1' 는 R1' 보다 더 높은 레졸루션을 가지게 되었다.
하나의 뷰가 하나의 서브 픽쳐 트랙으로 저장/전송되는 경우의 시그널링에 대해서 설명한다.
도시된 (50020) 에서와 같이, (50010) 의 패킹된 픽쳐는 4 개의 서브 픽쳐들로 나뉘어질 수 있다. 4 개의 서브 픽쳐들은 4 개의 서브 픽쳐 트랙들에 포함되어 전송될 수 있다. 여기서 각각의 트랙은 좌영상이거나 우영상일 수 있다.
이 경우 ISOBMFF 에 따라 StereoVideoBox 가 각 서브 픽쳐의 스테레오 비디오 어레인지먼트를 지시하게 한다면, scheme_type 이 3 이고 stereo_indication_type 은 0x03 일 수 있다.
이 경우 DASH MPD 에 따라 FramePacking 엘레멘트가 각 서브 픽쳐의 스테레오 비디오 어레인지먼트를 지시하게 한다면, FramePacking 엘레멘트의 @value 는 3 이 되거나 전술한 "urn:mpeg:dash:stereoid:2011" 스킴 URI 에 따르는 Role 디스크립터가 사용될 수 있다.
그러나 스테레오스코픽 360 비디오의 경우에 있어, StereoVideoBox 및 FramePacking 엘레멘트는 프로젝션된 좌영상 및 우영상의 프레임 패킹 어레인지먼트를 지시하는 것으로 제한되어 있어, 연관된 서브 픽쳐의 뷰 지시는 수행하지 못할 수 있다. 따라서, 각 트랙의 서브 픽쳐에 해당하는 뷰 정보를 위해 확장된 방법이 필요할 수 있다.
좌영상의 뷰 및 우영상의 뷰가 모두 하나의 서브 픽쳐 트랙으로 저장/전송되는 경우의 시그널링에 대해서 설명한다.
도시된 (50030) 에서와 같이, (50010) 의 패킹된 픽쳐들은 두 개의 서브 픽쳐들로 나뉘어질 수 있다. 2 개의 서브 픽쳐들은 각각 두 개의 서브 픽쳐 트랙들에 포함되어 전송될 수 있다. 여기서 각각의 서브 픽쳐 트랙은, 좌우 뷰에 해당하는 두 개의 패킹된 리전들을 포함할 수 있다.
이 경우 ISOBMFF 에 따라 StereoVideoBox 가 각 서브 픽쳐의 스테레오 비디오 어레인지먼트를 지시하게 한다면, 서브 픽쳐 트랙이 서로 다른 레졸루션을 가진 좌우 영상을 함께 포함한다는 것을 지시하지 못할 수 있다.
이 경우 DASH MPD 에 따라 FramePacking 엘레멘트가 각 서브 픽쳐 어댑테이션 셋 또는 레프리젠테이션의 스테레오 비디오 어레인지먼트를 지시하게 한다면, 서로 다른 레졸루션을 가진 좌우 영상을 함께 운반하는 어댑테이션 셋 또는 레프리젠테이션을 지시하지 못할 수 있다.
도 51 은 본 발명에 따른 트랙 커버리지 정보 박스의 또 다른 실시예를 도시한 도면이다.
전술한 갭 분석에 따라, 시그널링이 개선될 수 있다. 특히, 서브 픽쳐 트랙이 서로 다른 레졸루션의 좌우 뷰 리전들을 포함하는 경우에, 각각의 서브 픽쳐 트랙에 해당하는 뷰 정보를 지시하기 위하여, 시그널링이 개선될 필요가 있다.
이를 위해 전술한 view_idc 정보를 전술한 트랙 커버리지 정보 박스(TrackCoverageInformationBox), 컨텐트 커버리지 디스크립터(content coverage (CC) descriptor) 및/또한 서브 픽쳐 컴포지션 박스(SubPictureCompositionBox) 에 추가할 수 있다.
전술한 바와 같이 view_idc 필드는 해당 360 비디오 데이터가 스테레오스코픽 360 비디오인지 여부 및/또는 좌우영상인지 여부를 나타낼 수 있다. 본 필드가 0 인 경우, 해당 360 비디오는 모노스코픽 360 비디오일 수 있다. 본 필드가 1 인 경우, 해당 360 비디오는 스테레오스코픽 360 비디오의 좌영상일 수 있다. 본 필드가 2 인 경우, 해당 360 비디오는 스테레오스코픽 360 비디오의 우영상일 수 있다. 본 필드가 3 인 경우, 해당 360 비디오는 스테레오스코픽 360 비디오의 좌영상 및 우영상일 수 있다.
도시된 바와 같이, 트랙 커버리지 정보 박스에 view_idc 필드가 추가될 수 있다. 여기서 view_idc 필드는, 해당 트랙의 패킹된 픽쳐들의 컨텐트로 나타내어지는 구면상 영역(sphere region) 에 대하여, 전술한 것과 같은 정보들을 기술할 수 있다.
트랙 커버리지 정보 박스는 track_coverage_shape_type 및/또는 SphereRegionStruct 을 더 포함할 수 있다.
track_coverage_shape_type 는 해당 구면상 영역의 형태(shape) 을 나타낼 수 있다. 이 필드는 전술한 shape_type 과 같을 수 있다.
SphereRegionStruct 는 트랙 커버리지 정보 박스에 포함되는 경우, 해당 구면상 영역에 대하여, 전술한 RegionOnSphereStruct() 와 같은 내용을 기술할 수 있다. 즉, SphereRegionStruct 의 center_yaw, center_pitch, center_roll, hor_range, ver_range 및/또는 interpolate 는, 해당 구면상 영역에 대하여, 전술한 RegionOnSphereStruct() 의 동명의 필드들이 나타내는 것과 같은 내용을 기술할 수 있다.
전술한 본 발명에 따른 트랙 커버리지 정보 박스의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치 및/또는 360 비디오 수신 장치의 실시예들에서, 트랙 커버리지 정보 박스 은 전술한 실시예들에 따른 트랙 커버리지 정보 박스 일 수 있다.
도 52 은 본 발명에 따른 컨텐트 커버리지 디스크립터의 또 다른 실시예를 도시한 도면이다.
컨텐트 커버리지 디스크립터는 해당 360 비디오 컨텐트에 의해 커버되는 구면상 영역을 나타낼 수 있다. 이는 DASH 디스크립터의 형태로 구현될 수 있다. 컨텐트 커버리지 디스크립터는 전술한 커버리지 정보를 제공하는 디스크립터일 수 있다.
도시된 바와 같이, 컨텐트 커버리지 디스크립터에 view_idc 필드가 추가될 수 있다. 여기서 view_idc 필드는, 각 레프리젠테이션의 360 비디오 데이터로 나타내어지는 구면상 영역(sphere region) 에 대하여, 전술한 것과 같은 정보들을 기술할 수 있다.
컨텐트 커버리지 디스크립터는 shape_type, center_yaw, center_pitch, center_roll, hor_range 및/또는 ver_range 를 더 포함할 수 있다.
shape_type 은 해당 구면상 영역의 형태를 나타낼 수 있다. 이 필드는 전술한 shape_type 과 같을 수 있다. 이 필드는 전술한 shape_type 과 같을 수 있다.
center_yaw, center_pitch, center_roll, hor_range 및/또는 ver_range 는 각각 해당 구면상 영역의 중점의 yaw, 중점의 pitch, 중점의 roll, 수평 범위, 수직 범위를 나타낼 수 있다. 이 값들은 글로벌 좌표축들(global coordinate axes) 를 기준으로 하여 나타내어질 수 있다. 수평 범위 및 수직 범위는 구면상 영역의 중점을 기준으로 너비와 높이를 나타내는데 사용될 수 있다
전술한 본 발명에 따른 컨텐트 커버리지 디스크립터의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치 및/또는 360 비디오 수신 장치의 실시예들에서, 컨텐트 커버리지 디스크립터 은 전술한 실시예들에 따른 컨텐트 커버리지 디스크립터 일 수 있다.
도 53 은 본 발명에 따른 서브 픽쳐 컴포지션 박스의 일 실시예를 도시한 도면이다.
본 발명에 따른 서브 픽쳐 컴포지션 박스 는 서브 픽쳐 컴포지션 트랙 그룹핑에 관한 정보를 포함할 수 있다.
track_group_type 가 'spco' 값을 가지는 TrackGroupTypeBox 는 해당 트랙이 트랙들의 컴포지션에 포함되는지를 지시할 수 있다. 여기서 컴포지션에 포함되는 트랙들은 컴포지션 픽쳐를 획득하기 위해 공간상에 배열(spatially arranged) 될 수 있다.
이러한 트랙들의 그룹핑에 매핑되는 비주얼 트랙들은 전체적으로(collectively) 프리젠테이션될 수 있는 비주얼 컨텐트를 나타낸다. 여기서, 그룹핑에 매핑되는 비주얼 트랙들이란, track_group_type 가 'spco' 값을 가지는 TrackGroupTypeBox 내에서 같은 track_group_id 값을 가지는 비주얼 트랙들을 의미할 수 있다. 이 그룹핑에 매핑되는 각각의 비주얼 트랙은 다른 비주얼 트랙들 없이 단독으로 프리젠테이션되도록 의도되었거나 의도되지 않았을 수 있다.
여기서, 컨텐트 제작자는 CompositionRestrictionBox 를 이용하여 한 비주얼 트랙이 다른 비주얼 트랙 없이 단독으로 재생되도록 의도되지 않았음을 지시할 수 있다.
여기서, HEVC 비디오 스트림이 타일 트랙들의 셋을 통해 운반되고 관련된 타일 베이스 트랙과 비트스트림이 서브 픽쳐 컴포지션 트랙 그룹에 의해 지시되는 서브 픽쳐를 나타내는 경우, 타일 베이스 트랙만이 서브 픽쳐 컴포지션 박스를 포함할 수 있다.
컴포지션 픽쳐는 트랙 그룹에서 지시하는데로, 같은 서브 픽쳐 컴포지션 트랙 그룹의 모든 트랙들의 시간 평행(time-parallel)한 샘플들을 공간상에 배열함으로써 유도될 수 있다.
도시된 서브 픽쳐 컴포지션 박스 의 일 실시예에서, 서브 픽쳐 컴포지션 박스에 view_idc 필드가 추가될 수 있다. 여기서 view_idc 필드는, 컴포지션 픽쳐의 해당 트랙의 샘플들에 대하여, 전술한 것과 같은 정보들을 기술할 수 있다.
도시된 서브 픽쳐 컴포지션 박스는 track_x, track_y, track_width, track_height, composition_width 및/또는 composition_height 를 더 포함할 수 있다.
track_x, track_y 는 컴포지션 픽쳐의 해당 트랙의 샘플들의 좌 상단 점의 수평 포지션 및 수직 포지션을 각각 루마 샘플 유닛으로 나타낼 수 있다. 이 두 값들의 범위는 각각 0 에서 composition_width - 1 사이, 0 에서 composition_height - 1 사이 일 수 있다.
track_width, track_height 는 컴포지션 픽쳐의 해당 트랙의 샘플들의 너비 및 높이를 각각 루마 샘플 유닛으로 나타낼 수 있다. 이 두 값들의 범위는 각각 1 에서 composition_width - 1 사이, 1 에서 composition_height - 1 사이 일 수 있다.
composition_width, composition_height 는 컴포지션 픽쳐의 너비 및 높이를 각각 루마 샘플 유닛으로 나타낼 수 있다.
여기서, 0 에서 track_width - 1 사이의 값을 가지는 각각의 i 에 대하여, 해당 트랙 샘플들 중 i 번째 열(column)은 컴포지션 픽쳐의 루마 샘플들의 colComposedPic 번째 열일 수 있다. 여기서 colComposedPic 는 ( i + track_x ) % composition_width 일 수 있다.
여기서, 0 에서 track_height - 1 사이의 값을 가지는 각각의 j 에 대하여, 해당 트랙 샘플들 중 j 번째 행(row)은 컴포지션 픽쳐의 루마 샘플들의 rowComposedPic 번째 행일 수 있다. 여기서 rowComposedPic 는 ( j + track_y ) % composition_height 일 수 있다.
전술한 본 발명에 따른 서브 픽쳐 컴포지션 박스의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치 및/또는 360 비디오 수신 장치의 실시예들에서, 서브 픽쳐 컴포지션 박스 은 전술한 실시예들에 따른 서브 픽쳐 컴포지션 박스 일 수 있다.
도 54 는 본 발명에 따른 어안 360 비디오 데이터가 구면 상에 렌더링될 때의 시그널링 과정의 일 실시예를 도시한 도면이다.
실시예에 따라 360 비디오 전송 장치는 어안 렌즈에 의해 획득된 원형 이미지(circular image)들을 픽쳐로 매핑하고, 원형 이미지에 해당하는 어안 360 비디오 데이터에 대한 시그널링 정보를 생성하고, 이 들을 다양한 형태로, 다양한 방법으로 전송할 수 있다. 실시예에 따라 원형 이미지는 어안 렌즈에 의해 캡쳐된 360 비디오를 위한 이미지로서, 어안 이미지 등으로 불릴 수도 있다.
즉, 비디오 프로세서는 적어도 하나 이상의 어안(fish eye) 렌즈를 가지는 카메라에 의해 캡쳐된 적어도 하나 이상의 원형 이미지들을 처리할 수 있다. 비디오 프로세서는 원형 이미지들을 제 1 픽쳐로 매핑할 수 있다. 실시예에 따라 비디오 프로세서는 원형 이미지들을 제 1 픽쳐의 사각형 영역(rectangular region)들로 매핑할 수 있다. 실시예에 따라 이 매핑 과정은 원형 이미지의 '패킹' 이라고 불릴 수도 있다.
실시예에 따라 비디오 프로세서는 어안 360 비디오 데이터를 가지는 원형 이미지들에 대해서는, 스티칭(stitching) 하거나, 리전 와이즈 패킹(region-wise packing) 하지 않을 수 있다. 즉, 비디오 프로세서는 어안 렌즈 기반의 어안 360 비디오 데이터를 처리함에 있어서, 스티칭, 리전 와이즈 패킹 과정을 생략할 수 있다.
어안 360 비디오에 대해서는 전술한 서브 픽쳐 컴포지션 그룹핑이 사용될 수 있다. TrackCoverageInformationBox 를 어안 360 비디오를 위해 사용하는 경우, 유저 뷰포트에 해당하는 원형 이미지들을 운반하는 서브 픽쳐 트랙을 효율적으로 선택될 수 있다. 또한, GlobalCoverageInformationBox 를 사용하는 경우, 어안 이미지들이 매핑된 전체 프로젝션된 픽쳐의 전체 커버리지가 지시될 수 있다.
어안 360 비디오의 각각의 원형 이미지들은 구면 상의 영역(sphere region) 에 매핑될 수 있다. 여기서, 각각의 원형 이미지의 커버리지 각도는 θ 로 둘 수 있다. 예를 들어 θ 가 180 도인 경우, 이는 반구(hemisphere) 에 해당하는 커버리지를 가짐을 의미할 수 있다. 구면 상의 영역은 작은 원 하나에 의해 특정될 수 있다. 이 작은 원은 sin(θ/2) 에 해당하는 반지름을 가지는 원으로서, θ/2 가 나타내는 위도면을 따라 구를 둘러싸는 원일 수 있다(54010).
여기서, 원형 이미지의 중점(center point) 가 구면의 북극점(north pole) 과 얼라인되는 경우, 해당 원형 이미지에 해당하는 구면 상 영역은 GlobalCoverageInformationBox 에 의해 지시되거나, global_coverage_shape_type 또는 track_coverage_shape_type 값이 1 인 TrackCoverageInformationBox 에 의해 지시될 수 있다. 여기서 북극점은 pitch 값이 90 도인 점을 의미할 수 있다.
예를 들어, 170 도의 커버리지 각도를 가지는 원형 이미지의 구면상 영역은, 두 개의 yaw 원(yaw circle) 및 두 개의 pitch 원(pitch circle) 에 의해 정의될 수 있다(54020). 도시된 그림(54020)에서 두 개의 yaw 원들은 각각 -180 도와, 180 도를 가질 수 있다. 이 두 yaw 원들은 북극점을 지나가는 원들로서, 구면 상에서 서로 겹쳐질 수 있다. 또한 도시된 그림(54020)에서 두 개의 pitch 원들은 각각 5 도와, 90 도를 가질 수 있다. 즉, 이 두 pitch 원들은 pitch 가 5 인 점을 따라 구를 둘러싸는 형태의 원 하나와, pitch 가 90 도인 북극점 상에서 실질적으로 점으로 나타내어지는 원 하나일 수 있다.
shape_type 이 1 인 원형 이미지의 커버리지 정보를 지시하기 위하여, 새로운 제한(constraint)들이 고려될 수 있다. 예를 들어, 북극 점에서의 원형 이미지의 중심점 위치를 지시하기 위해, 각각의 원형 이미지에 대해 ProjectionOrientationBox 가 존재할 수 있다. 또한 SphereRegionStruct() 의 hor_range 값은 항상 360 * 216 로 설정되고, center_pitch 값은 90 * 216 에서 ver_range 값의 반을 뺀 값으로 설정되어야 할 수 있다. 여기서 center_pitch 값의 설정은, 하나의 pitch 원 (북극점) 과 다른 pitch 원 사이의 중간점을 지시하기 위함일 수 있다.
또한, SphereRegionStruct() 에 의해 특정되는 구면 상 영역의 중점은 북극점과 다른 pitch 원 사이의 중간에 위치될 수 있다. 예를 들어, 도시된 그림(54020) 에서의 구면 상 영역의 중점은 47.5 도의 pitch 원 상의 한 점일 수 있다(54030).
SphereRegionStruct() 에 의해 특정되는 구면 상 영역의 중점은 실제 해당 구면 상 영역의 중점과 다를 수 있다. 도시된 그림(54030)에서, 실제 구면 상 영역의 중점은 picth = 90 인 점으로 나타내어지는 반면에, SphereRegionStruct() 에 의해 특정되는 구면 상 영역의 중점은 pitch = 47.5 인 pitch 원 상의 한점으로 나타내어지고 있다. 이 경우, 잘못된 중점의 위치는 center_roll 을 적용할 때 부정확한 결과를 가져올 수도 있다.
도 55 는 본 발명에 따른 새로운 shape_type 이 정의되는 시그널링 정보들의 일 실시예를 도시한 도면이다.
전술한 문제를 해결하기 위하여, 본 발명에서는 GlobalCoverageInformationBox 및/또는 GlobalCoverageInformationBox 에 새로운 shape_type 값을 정의할 수 있다. 이 새로운 shape_type 값들은 어안 360 비디오의 커버리지 정보를 지시하는데 사용될 수 있다.
제안되는 새로운 shape_type 값들은 전술한 어안 360 비디오 박스, 글로벌 커버리지 정보 박스 및/또는 트랙 커버리지 정보 박스에 추가로 정의될 수 있다.
도시된 어안 360 비디오 박스(55010) 는 어안 비디오 정보를 제공할 수 있다. 어안 비디오 정보는 시그널링 정보의 하나로서, 원형 이미지, 원형 이미지가 매핑된 사각형 영역, 원형 이미지의 형태로 전달되는 모노스코픽(monoscopic) 360 비디오 데이터 또는 스테레오스코픽(stereoscopic) 360 비디오 데이터, 사각형 영역의 타입 등에 대한 정보 등등을 제공할 수 있다. 또한 어안 비디오 정보는 전술한 원형 이미지를 수신측에서 추출하고, 프로젝션하고, 블렌딩(blending) 하는데 필요한 정보를 제공할 수 있다.
도시된, fovd 로 정의되는 어안 360 비디오 박스(55010, 55020) 는, 해당 프로젝션된 픽쳐(원형 이미지들이 매핑된 픽쳐)에 대한 특징들을 기술할 수 있다. 어안 360 비디오 박스(55010) 는 해당 어안 360 비디오에 대한 어안 비디오 정보 및/또는 해당 어안 360 비디오의 구면 상의 커버리지에 대한 정보를 제공할 수 있다.
글로벌 커버리지 정보 박스는 전체 컨텐트의 픽쳐에 의해 나타내어지는 구면상 영역의 커버리지에 대한 정보를 제공할 수 있다.
도시된 글로벌 커버리지 정보 박스(55030)는 전술한 어안 360 비디오 박스(55010) 에 포함될 수 있다. 실시예에 따라 글로벌 커버리지 정보 박스(55030)는 프로젝션된 360 비디오에 대한 정보를 제공하는 프로젝션 360 비디오 박스(povd) 에 포함될 수도 있다.
글로벌 커버리지 정보 박스는 global_coverage_shape_type 및/또는 SphereRegionStruct() 를 포함할 수 있다.
global_coverage_shape_type 는 해당 구면상 영역의 형태를 지시하는 정보로서, 전체 컨텐트에 의해 나타내어지는 구면상 영역에 대하여, 전술한 shape_type 필드와 같은 의미를 가질 수 있다.
전술한 바와 같이 shape_type 정보는 해당되는 영역이 어떠한 형태(shpae) 을 가지는지를 나타낼 수 있다. shape_type 이 0 의 값을 가질 때, 해당 영역은 전술한 4 개의 구면 상 대원(4 great circles) 에 의해 특정되는 형태일 수 있다. shape_type 이 1 의 값을 가질 때, 2 개의 야 원(yaw circle) 및 2 개의 피치 원(pitch circle) 에 의해 특정되는 형태일 수 있다.
여기서, shape_type 이 새롭게 정의되는 2 의 값을 가지는 경우, 해당 영역 또는 해당 구면상 영역은 도시된 그림(55050)에서와 같이 작은 원 하나(one small circle) 로 정의될 수 있다. 도시된 그림(55050)에서, cSmall 로 표시된 원은 cPitch 변수에 의해 정의될 수 있다. cSmall 원이 cPitch 변수에 의해 정의될 때, center_yaw and center_pitch 에 의해 특정되는 중점의 방향과 얼라인된 Y 축에 상대적으로 정의될 수 있다. cPitch 변수는 cPitch = (90 * 216 - ver_range ÷ 2) ÷ 65536 와 같이 정의될 수 있다.
SphereRegionStruct() 는 글로벌 커버리지 정보 박스에 포함되는 경우, 해당 구면상 영역에 대하여, 전술한 RegionOnSphereStruct() 와 같은 내용을 기술할 수 있다.
구체적으로, global_coverage_shape_type 값이 0 또는 1 인 경우, center_yaw, center_pitch, center_roll 은 전술한 SphereRegionStruct 의 center_yaw, center_pitch, center_roll 와 마찬가지로 해당 구면상 영역의 중점에 대한 yaw, pitch, roll 값을 나타낼 수 있다.
global_coverage_shape_type 값이 2 인 경우, center_yaw, center_pitch, center_roll 은 해당 구면상 영역의 중점에 대한 yaw, pitch, roll 값을 글로벌 좌표계 축(global coordinate axes) 에 상대적으로 나타낼 수 있다.
center_yaw, center_pitch, center_roll 의 단위 및 범위는 전술한 SphereRegionStruct 의 그 것들과 같을 수 있다.
또한, global_coverage_shape_type 값이 0 또는 1 인 경우, hor_range, ver_range 은 전술한 SphereRegionStruct 의 hor_range, ver_range 와 마찬가지로 해당 구면상 영역의 수평 범위 및 수직 범위를 나타낼 수 있다. 이 때 hor_range, ver_range 의 단위 및 범위는 전술한 SphereRegionStruct 의 그 것들과 같을 수 있다.
global_coverage_shape_type 값이 2 인 경우, hor_range 값은 무시될 수 있다. ver_range 는 해당 구면상 영역의 중점을 기준으로 그 범위를 나타낼 수 있다(55050). ver_range 는 0 에서 360 * 216 사이의 값을 가질 수 있다. interpolate 값은 0 일 수 있다.
트랙 커버리지 정보 박스는 해당 트랙에 의해 나타내어지는 구면상 영역의 커버리지에 대한 정보를 제공할 수 있다.
도시된 트랙 커버리지 정보 박스(55040)는 전술한 어안 360 비디오 박스(55010) 에 포함될 수 있다. 실시예에 따라 트랙 커버리지 정보 박스(55040)는 프로젝션 360 비디오 박스(povd) 에 포함될 수도 있다.
트랙 커버리지 정보 박스는 track_coverage_shape_type 및/또는 SphereRegionStruct() 를 포함할 수 있다.
track_coverage_shape_type 는 해당 구면상 영역의 형태를 지시하는 정보로서, 해당 트랙에 의해 나타내어지는 구면상 영역에 대하여, 전술한 shape_type 필드와 같은 의미를 가질 수 있다.
SphereRegionStruct() 는 트랙 커버리지 정보 박스에 포함되는 경우, 해당 구면상 영역에 대하여, 전술한 RegionOnSphereStruct() 와 같은 내용을 기술할 수 있다.
구체적으로, track_coverage_shape_type 값이 0 또는 1 인 경우, center_yaw, center_pitch, center_roll 은 전술한 SphereRegionStruct 의 center_yaw, center_pitch, center_roll 와 마찬가지로 해당 구면상 영역의 중점에 대한 yaw, pitch, roll 값을 나타낼 수 있다.
track_coverage_shape_type 값이 2 인 경우, center_yaw, center_pitch, center_roll 은 해당 구면상 영역의 중점에 대한 yaw, pitch, roll 값을 글로벌 좌표계 축(global coordinate axes) 에 상대적으로 나타낼 수 있다.
center_yaw, center_pitch, center_roll 의 단위 및 범위는 전술한 SphereRegionStruct 의 그 것들과 같을 수 있다.
또한, track_coverage_shape_type 값이 0 또는 1 인 경우, hor_range, ver_range 은 전술한 SphereRegionStruct 의 hor_range, ver_range 와 마찬가지로 해당 구면상 영역의 수평 범위 및 수직 범위를 나타낼 수 있다. 이 때 hor_range, ver_range 의 단위 및 범위는 전술한 SphereRegionStruct 의 그 것들과 같을 수 있다.
track_coverage_shape_type 값이 2 인 경우, hor_range 값은 무시될 수 있다. ver_range 는 해당 구면상 영역의 중점을 기준으로 그 범위를 나타낼 수 있다(55050). ver_range 는 0 에서 360 * 216 사이의 값을 가질 수 있다. interpolate 값은 0 일 수 있다.
전술한 본 발명에 따른 어안 360 비디오 박스의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치 및/또는 360 비디오 수신 장치의 실시예들에서, 어안 360 비디오 박스 은 전술한 실시예들에 따른 어안 360 비디오 박스 일 수 있다.
전술한 본 발명에 따른 글로벌 커버리지 정보 박스의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치 및/또는 360 비디오 수신 장치의 실시예들에서, 글로벌 커버리지 정보 박스 은 전술한 실시예들에 따른 글로벌 커버리지 정보 박스 일 수 있다.
전술한 본 발명에 따른 트랙 커버리지 정보 박스의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치 및/또는 360 비디오 수신 장치의 실시예들에서, 트랙 커버리지 정보 박스 은 전술한 실시예들에 따른 트랙 커버리지 정보 박스 일 수 있다.
도 56 및 도 57 은 본 발명에 따른 어안 360 비디오를 위한 SphereRegionStruct 의 또 다른 실시예를 도시한 도면이다.
전술한 바와 같이 SphereRegionStruct 는 구면상에 나타나지는 영역에 대해 기술할 수 있다. SphereRegionStruct 는 해당 영역의 중점을 center_yaw, center_pitch, center_roll 을 통해 특정할 수 있다.
도시된 실시예에 따른 SphereRegionStruct 는 전술한 새로운 값을 가지는 shape_type 에 따라 변형된 형태의 SphereRegionStruct 일 수 있다. 도시된 실시예에 따른 SphereRegionStruct 는 어안 360 비디오 데이터가 사용되는 경우에 있어, 구면상에 나타나지는 영역에 대해 기술하는데 사용될 수 있다. 여기서 전술한 '2' 외에 다른 shape_type 값이 추가로 정의될 수 있다.
구체적으로, shape_type이 2 일 경우, 해당 영역이 전술한 하나의 작은 원(one small circle) 로 특정되는 형태임이 지시될 수 있다. 이 때, 해당 영역의 범위(range) 를 특정하기 위하여 range 필드가 SphereRegionStruct 에 포함될 수 있다. range 필드는 전술한 ver_range 와 같이 중점에서 작은 원('small circle') 에 이르는 각의 절반의 값을 나타낼 수 있다.
shape_type이 3 일 경우, 해당 영역이 복수개의 범위를 가지는 곡면으로 둘러쌓인 형태임이 지시될 수 있다(57010). 이 때, 해당 영역의 범위를 특정하기 위하여, 범위의 개수를 지시하기 위한 num_range 필드가 SphereRegionStruct 에 포함될 수 있다. num_range 필드에 따른 각각의 범위에 대해 range 필드가 더 추가될 수 있다.
range 필드는 중점에서 각 곡면에 이르는 각의 절반의 값을 나타낼 수 있다. 실시예에 따라 복수개의 range 필드 값이 적용되는 순서 및/또는 곡면 간의 간격이 정해질 수 있다. 실시예에 따라 Z 축을 기준으로 시계방향 또는 반시계방향으로 순서가 정해질 수 있다. 실시예에 따라 곡면 간의 간격은 360/num_range 로 정해질 수 있다. 이 경우 num_range 가 4 의 값을 가지면 90 도 간격으로 곡면들이 위치될 수 있다.
shape_type 이 4 일 경우, 해당 영역이 두 개의 작은 원(small circle) 로 둘러쌓인 형태임이 지시될 수 있다(57020). 이 때, 해당 영역의 범위를 특정하기 위하여, inner_range 및/또는 outer_range 필드가 SphereRegionStruct 에 포함될 수 있다. outer_range 필드는 중점에서 먼 쪽의 작은 원으로부터 중점에 이르는 각의 절반의 값을 나타낼 수 있다. inner_range 필드는 중점에서 가까운 쪽의 작은 원으로부터 중점에 이르는 각의 절반의 값을 나타낼 수 있다. 실시예에 따라 이러한 형태의 영역은 도넛 형태의 원형 이미지에 맵핑될 수 있다.
shape_type 이 5 일 경우, shape_type 이 3 인 경우의 형태와 같은 곡면이 두 개 존재하며, 해당 영역은 이 두 개의 곡면들로 둘러쌓인 형태임이 지시될 수 있다(57030). 이 때, 해당 영역의 범위를 특정하기 위하여, num_inner_ranges 필드 및/또는 num_outer_ranges 필드가 SphereRegionStruct 에 포함될 수 있다.
num_inner_ranges 필드에 따른 각각의 안쪽 범위에 대해 inner_range 필드들이 더 추가될 수 있다. inner_range 필드는 중점에서 가까운 쪽의 곡면으로부터 중점에 이르는 각의 절반의 값을 나타낼 수 있다.
num_outer_ranges 필드에 따른 각각의 바깥쪽 범위에 대해 outer_range 필드들이 더 추가될 수 있다. outer_range 필드는 중점에서 먼 쪽의 곡면으로부터 중점에 이르는 각의 절반의 값을 나타낼 수 있다.
도 58 은 본 발명에 따른 어안 360 비디오를 위한 SphereRegionStruct 의 또 다른 실시예를 도시한 도면이다.
전술한 어안 360 비디오를 위한 SphereRegionStruct 는 DASH 디스크립터의 형태를 가질 수 있다. 전술한 바와 같이 어안 360 비디오 데이터가 전송될 때, DASH 를 통해 전송될 수 있다. 이 때, 어안 360 비디오를 위한 SphereRegionStruct 는 DASH MPD 의 Essential Property 또는 Supplemental Property 디스크립터의 형태로서 전달될 수 있다. 실시예에 따라 이 디스크립터는 어댑테이션 셋, 레프리젠테이션 및/또는 서브 레프리젠테이션 등의 MPD 상 각 레벨에 포함될 수 있다.
도시된 실시예에 따른 어안 360 비디오를 위한 SphereRegionStruct 는 shape_type, center_yaw, center_pitch, center_roll, hor_range, ver_range, range, num_ranges, ranges, inner_range, outer_range, num_inner_ranges, num_outer_ranges, num_inner_ranges 및/또는 num_outer_ranges 를 포함할 수 있다.
shape_type 는 전술한 새로운 값이 정의된 shape_type 에 해당할 수 있다. 해당 레프리젠테이션에 대한 어안 360 비디오 데이터의 구면 상 영역에 대한 형태를 지시할 수 있다.
center_yaw, center_pitch, center_roll 는 해당 구면상 영역의 중점의 yaw, pitch, roll 값을 글로벌 좌표계 축(global coordinate axes) 에 기반하여 지시할 수 있다.
hor_range, ver_range 는 해당 구면 상 영역의 수평 범위, 수직 범위를 center_yaw, center_pitch, center_roll 에 의해 특정된 중점을 기반으로 지시할 수 있다.
range, num_ranges, ranges, inner_range, outer_range, num_inner_ranges, num_outer_ranges, num_inner_ranges, num_outer_ranges 는 전술한 동명의 필드들과 같은 의미를 가질 수 있다. 여기서 DASH 디스크립터의 형태로 기술되어 있으므로, ranges 는 개별 range 값들이 콤마로 구분되어 기술되어 있을 수 있다. num_inner_ranges, num_outer_ranges 는 개별 inner_range, outer_range 값들이 각각 콤마로 구분되어 기술되어 있을 수 있다.
전술한 본 발명에 따른 어안 360 비디오를 위한 SphereRegionStruct 의 실시예들은 서로 조합될 수 있다 본 발명에 따른 360 비디오 전송 장치 및/또는 360 비디오 수신 장치의 실시예들에서, 어안 360 비디오를 위한 SphereRegionStruct 은 전술한 실시예들에 따른 어안 360 비디오를 위한 SphereRegionStruct 일 수 있다.
도 59 는 본 발명에 따른 360 비디오 전송 장치에 의해 수행될 수 있는, 360 비디오를 전송하는 방법의 일 실시예를 나타낸 도면이다.
360 비디오를 전송하는 방법의 일 실시예는, 적어도 하나 이상의 카메라에 의해 캡쳐된 360 비디오 데이터를 스티칭(stitching)하는 단계, 스티칭된 360 비디오 데이터를 제 1 픽쳐 상에 프로젝션하는 단계, 제 1 픽쳐의 각 리전(Region) 들을 제 2 픽쳐로 매핑하여 리전 와이즈 패킹을 수행하는 단계, 제 2 픽쳐의 데이터를 DASH (Dynamic Adaptive Streaming over HTTP) 레프리젠테이션들로 처리하는 단계, 360 비디오 데이터에 대한 시그널링 정보를 포함하는 MPD (Media Presentation Description) 를 생성하는 단계 및/또는 DASH 레프리젠테이션들과 MPD 를 전송하는 단계; 를 포함할 수 있다.
360 비디오 전송 장치의 비디오 프로세서는 적어도 하나 이상의 카메라에 의해 캡쳐된 360 비디오 데이터를 스티칭하고, 스티칭된 360 비디오 데이터를 제 1 픽쳐 상에 프로젝션할 수 있다. 또한 비디오 프로세서는 제 1 픽쳐의 각 리전(Region) 들을 제 2 픽쳐로 매핑하여 리전 와이즈 패킹을 수행할 수 있다.
인캡슐레이션 처리부는 제 2 픽쳐의 데이터를 DASH (Dynamic Adaptive Streaming over HTTP) 레프리젠테이션들로 처리할 수 있다. 메타데이터 처리부는 360 비디오 데이터에 대한 시그널링 정보를 포함하는 MPD (Media Presentation Description) 를 생성할 수 있다. 전송처리부 내지 전송부는 DASH 레프리젠테이션들과 MPD 를 전송할 수 있다.
360 비디오를 전송하는 방법 의 다른 실시예에서, MPD 는 제 1 디스크립터 및/또는 제 2 디스크립터를 포함할 수 있다. 여기서, 제 1 디스크립터는 스티칭된 360 비디오 데이터가 제 1 픽쳐 상에 프로젝션될 때 사용된 프로젝션 타입을 지시하는 정보를 포함할 수 있다. 또한 제 2 디스크립터는 제 1 픽쳐에서 제 2 픽쳐로 리전 와이즈 패킹이 수행될 때 사용된 패킹 타입을 지시하는 정보를 포함할 수 있다.
360 비디오를 전송하는 방법 의 또 다른 실시예에서, 프로젝션 타입을 지시하는 정보는 프로젝션이 등장방형(equirectangular) 프로젝션 또는 큐브맵(cubemap) 프로젝션 타입을 가짐을 지시할 수 있다. 패킹 타입을 지시하는 정보는 리전 와이즈 패킹이 사각형(rectangular) 리전 와이즈 패킹 타입을 가짐을 지시할 수 있다.
360 비디오를 전송하는 방법 의 또 다른 실시예에서, MPD 는 제 3 디스크립터를 포함할 수 있다. 제 3 디스크립터는 360 비디오 데이터에 해당하는 전체 영역이 3D 공간 상에서 차지하는 영역을 지시하는 커버리지(coverage) 정보를 포함할 수 있다. 또한 커버리지 정보는 3D 공간 상의 영역의 중점을 방위각(azimuth) 및 고도(elevation) 값을 이용해 특정하고, 영역의 수평 범위 및 수직 범위를 특정할 수 있다.
360 비디오를 전송하는 방법 의 또 다른 실시예에서, DASH 레프리젠테이션들 중 적어도 하나는 타임드 메타데이터를 포함하는 타임드 메타데이터 레프리젠테이션일 수 있다. 타임드 메타데이터는 초기 뷰포인트(initial viewpoint) 를 지시하는 초기 뷰포인트 정보를 포함할 수 있다. 또한, 타임드 메타데이터는 초기 뷰포인트 정보가 적용되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 식별하는 정보를 포함할 수 있다.
360 비디오를 전송하는 방법 의 또 다른 실시예에서, 타임드 메타데이터는 서비스 프로바이더에 의해 추천되는 뷰포트를 지시하는 추천 뷰포트(recommended viewport) 정보를 포함할 수 있다. 또한 타임드 메타데이터는 추천 뷰포트 정보가 적용되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 식별하는 정보를 포함할 수 있다.
360 비디오를 전송하는 방법 의 또 다른 실시예에서, 제 3 디스크립터는 영역에 대응되는 360 비디오의 프레임 패킹 어레인지먼트(frame packing arrangement) 정보 및/또는 360 비디오가 스테레오스코픽(steremoscopic) 360 비디오인지 여부를 동시에 지시하는 단수개의 시그널링 필드를 더 포함할 수 있다. 이 시그널링 필드는 전술한 view_idc 일 수 있다.
전술한 본 발명에 따른 360 비디오 수신 장치는 360 비디오를 수신하는 방법 를 수행할 수 있다. 360 비디오를 수신하는 방법은, 전술한 본 발명에 따른 360 비디오를 전송하는 방법에 대응되는 실시예들을 가질 수 있다. 360 비디오를 수신하는 방법 및 그 실시예들은, 전술한 본 발명에 따른 360 비디오 수신 장치 및 그 내/외부 컴포넌트들에 의해 수행될 수 있다.
여기서 리전(리전별 패킹에서의 의미, Region) 은, 2D 이미지에 프로젝션된 360 비디오 데이터가 리전별 패킹(region-wise packing) 을 통해 팩드 프레임 내에서 위치하게 되는 영역을 의미할 수 있다. 여기서의 리전은 문맥에 따라 리전별 패킹에서 사용되는 리전을 의미할 수 있다. 전술한 바와 같이 리전들을 2D 이미지를 균등하게 나누어 구분되거나, 프로젝션 스킴 등에 따라 임의로 나누어져 구분될 수도 있다.
여기서 리전(일반적 의미, region) 은, 전술한 리전별 패킹에서의 리전과 달리, 사전적 의미로서 사용될 수도 있다. 이 경우 리전이란 사전적 의미인 '영역', '구역', '일부분' 등의 의미를 가질 수 있다. 예를 들어 후술할 페이스(face) 의 일 영역을 의미할 때, '해당 페이스의 한 리전' 등과 같은 표현이 사용될 수 있다. 이 경우 리전은 전술한 리전별 패킹에서의 리전과는 구분되는 의미로서, 양자는 서로 무관한, 다른 영역을 지시할 수 있다.
여기서 픽쳐는 360 비디오 데이터가 프로젝션된 2D 이미지 전체를 의미할 수 있다. 실시예에 따라 프로젝티드 프레임 내지는 팩드 프레임이 픽쳐가 될 수 있다.
여기서 서브 픽쳐는 전술한 픽쳐의 일부분을 의미할 수 있다. 예를 들어 타일링 등을 수행하기 위해 픽쳐가 여러 서브 픽쳐로 나누어질 수 있다. 이 때 각 서브 픽쳐가 타일이 될 수 있다.
여기서 타일은, 서브 픽처의 하위 개념으로서, 서브 픽처가 타일링을 위한 타일로 쓰일 수 있다. 즉, 타일링에 있어서는 서브 픽처와 타일은 동일한 개념일 수 있다.
여기서 슈페리컬 리전(Spherical region) 내지 슈피어 리전(Sphere region) 은, 360 비디오 데이터가 수신측에서 3D 공간(예를 들어 구면) 상에 렌더링될 때, 그 구면 상의 일 영역을 의미할 수 있다. 여기서 슈페리컬 리전은, 리전별 패킹에서의 리전과는 무관하다. 즉, 슈페리컬 리전이 리전별 패킹에서 정의되었던 리전과 같은 영역을 의미할 필요는 없다. 슈페리컬 리전은 렌더링되는 구면 상의 일 부분을 의미하는 데 사용되는 용어로서, 여기서의 '리전' 은 사전적 의미로서의 '영역'을 뜻할 수 있다. 문맥에 따라 슈페리컬 리전이 단순히 리전이라고 불릴 수도 있다. 슈페리컬 리전 내지 슈피어 리전은 구면 상 영역이라 불릴 수도 있다.
여기서 페이스(face) 는 프로젝션 스킴에 따라 각 면을 부르는 용어일 수 있다. 예를 들어 큐브맵 프로젝션이 사용되는 경우, 앞면, 뒷면, 양 옆면, 윗면, 아랫면 등은 페이스라고 불릴 수 있다.
전술한 각각의 파트, 모듈 또는 유닛은 메모리(또는 저장 유닛)에 저장된 연속된 수행과정들을 실행하는 프로세서이거나 하드웨어 파트일 수 있다. 전술한 실시예에 기술된 각 단계들은 프로세서 또는 하드웨어 파트들에 의해 수행될 수 있다. 전술한 실시예에 기술된 각 모듈/블락/유닛들은 하드웨어/프로세서로서 동작할 수 있다. 또한, 본 발명이 제시하는 방법들은 코드로서 실행될 수 있다. 이 코드는 프로세서가 읽을 수 있는 저장매체에 쓰여질 수 있고, 따라서 장치(apparatus)가 제공하는 프로세서에 의해 읽혀질 수 있다.
설명의 편의를 위하여 각 도면을 나누어 설명하였으나, 각 도면에 서술되어 있는 실시 예들을 병합하여 새로운 실시 예를 구현하도록 설계하는 것도 가능하다. 그리고, 통상의 기술자의 필요에 따라, 이전에 설명된 실시 예들을 실행하기 위한 프로그램이 기록되어 있는 컴퓨터에서 판독 가능한 기록 매체를 설계하는 것도 본 발명의 권리범위에 속한다.
본 발명에 따른 장치 및 방법은 상술한 바와 같이 설명된 실시 예들의 구성과 방법이 한정되게 적용될 수 있는 것이 아니라, 상술한 실시 예들은 다양한 변형이 이루어질 수 있도록 각 실시 예들의 전부 또는 일부가 선택적으로 조합되어 구성될 수도 있다.
한편, 본 발명이 제안하는 방법을 네트워크 디바이스에 구비된, 프로세서가 읽을 수 있는 기록매체에, 프로세서가 읽을 수 있는 코드로서 구현하는 것이 가능하다. 프로세서가 읽을 수 있는 기록매체는 프로세서에 의해 읽혀질 수 있는 데이터가 저장되는 모든 종류의 기록장치를 포함한다. 프로세서가 읽을 수 있는 기록 매체의 예로는 ROM, RAM, CD-ROM, 자기 테이프, 플로피디스크, 광 데이터 저장장치 등이 있으며, 또한, 인터넷을 통한 전송 등과 같은 캐리어 웨이브의 형태로 구현되는 것도 포함한다. 또한, 프로세서가 읽을 수 있는 기록매체는 네트워크로 연결된 컴퓨터 시스템에 분산되어, 분산방식으로 프로세서가 읽을 수 있는 코드가 저장되고 실행될 수 있다.
또한, 이상에서는 본 발명의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 발명은 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 발명의 요지를 벗어남이 없이 당해 발명이 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 발명의 기술적 사상이나 전망으로부터 개별적으로 이해돼서는 안 될 것이다.
본 발명의 사상이나 범위를 벗어나지 않고 본 발명에서 다양한 변경 및 변형이 가능함은 당업자에게 이해된다. 따라서, 본 발명은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 본 발명의 변경 및 변형을 포함하는 것으로 의도된다.
본 명세서에서 장치 및 방법 발명이 모두 언급되고, 장치 및 방법 발명 모두의 설명은 서로 보완하여 적용될 수 있다.
다양한 실시예가 본 발명을 실시하기 위한 최선의 형태에서 설명되었다.
본 발명은 일련의 VR 관련 분야에서 이용된다.
본 발명의 사상이나 범위를 벗어나지 않고 본 발명에서 다양한 변경 및 변형이 가능함은 당업자에게 자명하다. 따라서, 본 발명은 첨부된 청구항 및 그 동등 범위 내에서 제공되는 본 발명의 변경 및 변형을 포함하는 것으로 의도된다.

Claims (14)

  1. 적어도 하나 이상의 카메라에 의해 캡쳐된 360 비디오 데이터를 스티칭(stitching)하는 단계;
    상기 스티칭된 360 비디오 데이터를 제 1 픽쳐 상에 프로젝션하는 단계;
    상기 제 1 픽쳐의 각 리전(Region) 들을 제 2 픽쳐로 매핑하여 리전 와이즈 패킹을 수행하는 단계;
    상기 제 2 픽쳐의 데이터를 DASH (Dynamic Adaptive Streaming over HTTP) 레프리젠테이션들로 처리하는 단계;
    상기 360 비디오 데이터에 대한 시그널링 정보를 포함하는 MPD (Media Presentation Description) 를 생성하는 단계; 및
    상기 DASH 레프리젠테이션들과 상기 MPD 를 전송하는 단계; 를 포함하는 360 비디오를 전송하는 방법.
  2. 제 1 항에 있어서,
    상기 MPD 는 제 1 디스크립터 및 제 2 디스크립터를 포함하고,
    상기 제 1 디스크립터는 상기 스티칭된 360 비디오 데이터가 상기 제 1 픽쳐 상에 프로젝션될 때 사용된 프로젝션 타입을 지시하는 정보를 포함하고,
    상기 제 2 디스크립터는 상기 제 1 픽쳐에서 상기 제 2 픽쳐로 리전 와이즈 패킹이 수행될 때 사용된 패킹 타입을 지시하는 정보를 포함하는 것을 특징으로 하는 360 비디오를 전송하는 방법.
  3. 제 2 항에 있어서,
    상기 프로젝션 타입을 지시하는 정보는 상기 프로젝션이 등장방형(equirectangular) 프로젝션 또는 큐브맵(cubemap) 프로젝션 타입을 가짐을 지시하고,
    상기 패킹 타입을 지시하는 정보는 상기 리전 와이즈 패킹이 사각형(rectangular) 리전 와이즈 패킹 타입을 가짐을 지시하는 것을 특징으로 하는 360 비디오를 전송하는 방법.
  4. 제 1 항에 있어서,
    상기 MPD 는 제 3 디스크립터를 포함하고,
    상기 제 3 디스크립터는 상기 360 비디오 데이터에 해당하는 전체 영역이 3D 공간 상에서 차지하는 영역을 지시하는 커버리지(coverage) 정보를 포함하고,
    상기 커버리지 정보는 상기 3D 공간 상의 상기 영역의 중점을 방위각(azimuth) 및 고도(elevation) 값을 이용해 특정하고, 상기 영역의 수평 범위 및 수직 범위를 특정하는 것을 특징으로 하는 360 비디오를 전송하는 방법.
  5. 제 1 항에 있어서,
    상기 DASH 레프리젠테이션들 중 적어도 하나는 타임드 메타데이터를 포함하는 타임드 메타데이터 레프리젠테이션이고,
    상기 타임드 메타데이터는 초기 뷰포인트(initial viewpoint) 를 지시하는 초기 뷰포인트 정보를 포함하고,
    상기 타임드 메타데이터는 상기 초기 뷰포인트 정보가 적용되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 식별하는 정보를 포함하는 것을 특징으로 하는 360 비디오를 전송하는 방법.
  6. 제 5 항에 있어서,
    상기 타임드 메타데이터는 서비스 프로바이더에 의해 추천되는 뷰포트를 지시하는 추천 뷰포트(recommended viewport) 정보를 포함하고,
    상기 타임드 메타데이터는 상기 추천 뷰포트 정보가 적용되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 식별하는 정보를 포함하는 것을 특징으로 하는 360 비디오를 전송하는 방법.
  7. 제 4 항에 있어서,
    상기 제 3 디스크립터는 상기 영역에 대응되는 360 비디오의 프레임 패킹 어레인지먼트(frame packing arrangement) 정보 및 상기 360 비디오가 스테레오스코픽(steremoscopic) 360 비디오인지 여부를 동시에 지시하는 단수개의 시그널링 필드를 더 포함하는 것을 특징으로 하는 360 비디오를 전송하는 방법.
  8. 적어도 하나 이상의 카메라에 의해 캡쳐된 360 비디오 데이터를 스티칭(stitching)하는 비디오 프로세서, 상기 프로세서는 상기 스티칭된 360 비디오 데이터를 제 1 픽쳐 상에 프로젝션하고, 상기 제 1 픽쳐의 각 리전(Region) 들을 제 2 픽쳐로 매핑하여 리전 와이즈 패킹을 수행하고;
    상기 제 2 픽쳐의 데이터를 DASH (Dynamic Adaptive Streaming over HTTP) 레프리젠테이션들로 처리하는 인캡슐레이션 처리부;
    상기 360 비디오 데이터에 대한 시그널링 정보를 포함하는 MPD (Media Presentation Description) 를 생성하는 메타데이터 처리부; 및
    상기 DASH 레프리젠테이션들과 상기 MPD 를 전송하는 전송부; 를 포함하는 360 비디오 전송 장치.
  9. 제 8 항에 있어서,
    상기 MPD 는 제 1 디스크립터 및 제 2 디스크립터를 포함하고,
    상기 제 1 디스크립터는 상기 스티칭된 360 비디오 데이터가 상기 제 1 픽쳐 상에 프로젝션될 때 사용된 프로젝션 타입을 지시하는 정보를 포함하고,
    상기 제 2 디스크립터는 상기 제 1 픽쳐에서 상기 제 2 픽쳐로 리전 와이즈 패킹이 수행될 때 사용된 패킹 타입을 지시하는 정보를 포함하는 것을 특징으로 하는 360 비디오 전송 장치.
  10. 제 9 항에 있어서,
    상기 프로젝션 타입을 지시하는 정보는 상기 프로젝션이 등장방형(equirectangular) 프로젝션 또는 큐브맵(cubemap) 프로젝션 타입을 가짐을 지시하고,
    상기 패킹 타입을 지시하는 정보는 상기 리전 와이즈 패킹이 사각형(rectangular) 리전 와이즈 패킹 타입을 가짐을 지시하는 것을 특징으로 하는 360 비디오 전송 장치.
  11. 제 8 항에 있어서,
    상기 MPD 는 제 3 디스크립터를 포함하고,
    상기 제 3 디스크립터는 상기 360 비디오 데이터에 해당하는 전체 영역이 3D 공간 상에서 차지하는 영역을 지시하는 커버리지(coverage) 정보를 포함하고,
    상기 커버리지 정보는 상기 3D 공간 상의 상기 영역의 중점을 방위각(azimuth) 및 고도(elevation) 값을 이용해 특정하고, 상기 영역의 수평 범위 및 수직 범위를 특정하는 것을 특징으로 하는 360 비디오 전송 장치.
  12. 제 8 항에 있어서,
    상기 DASH 레프리젠테이션들 중 적어도 하나는 타임드 메타데이터를 포함하는 타임드 메타데이터 레프리젠테이션이고,
    상기 타임드 메타데이터는 초기 뷰포인트(initial viewpoint) 를 지시하는 초기 뷰포인트 정보를 포함하고,
    상기 타임드 메타데이터는 상기 초기 뷰포인트 정보가 적용되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 식별하는 정보를 포함하는 것을 특징으로 하는 360 비디오 전송 장치.
  13. 제 12 항에 있어서,
    상기 타임드 메타데이터는 서비스 프로바이더에 의해 추천되는 뷰포트를 지시하는 추천 뷰포트(recommended viewport) 정보를 포함하고,
    상기 타임드 메타데이터는 상기 추천 뷰포트 정보가 적용되는 360 비디오 데이터를 가지는 DASH 레프리젠테이션을 식별하는 정보를 포함하는 것을 특징으로 하는 360 비디오 전송 장치.
  14. 제 8 항에 있어서,
    상기 제 3 디스크립터는 상기 영역에 대응되는 360 비디오의 프레임 패킹 어레인지먼트(frame packing arrangement) 정보 및 상기 360 비디오가 스테레오스코픽(steremoscopic) 360 비디오인지 여부를 동시에 지시하는 단수개의 시그널링 필드를 더 포함하는 것을 특징으로 하는 360 비디오 전송 장치.
PCT/KR2018/000106 2017-03-29 2018-01-03 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치 WO2018182144A1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020197019426A KR102277267B1 (ko) 2017-03-29 2018-01-03 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
US16/485,142 US20190373245A1 (en) 2017-03-29 2018-01-03 360 video transmission method, 360 video reception method, 360 video transmission device, and 360 video reception device

Applications Claiming Priority (8)

Application Number Priority Date Filing Date Title
US201762478076P 2017-03-29 2017-03-29
US62/478,076 2017-03-29
US201762511399P 2017-05-26 2017-05-26
US62/511,399 2017-05-26
US201762530275P 2017-07-09 2017-07-09
US62/530,275 2017-07-09
US201762531326P 2017-07-11 2017-07-11
US62/531,326 2017-07-11

Publications (1)

Publication Number Publication Date
WO2018182144A1 true WO2018182144A1 (ko) 2018-10-04

Family

ID=63676269

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2018/000106 WO2018182144A1 (ko) 2017-03-29 2018-01-03 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치

Country Status (3)

Country Link
US (1) US20190373245A1 (ko)
KR (1) KR102277267B1 (ko)
WO (1) WO2018182144A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020189816A1 (ko) * 2019-03-19 2020-09-24 전자부품연구원 360 vr 인터랙티브 중계를 위한 사용자 인터페이스 및 방법
US20220245190A1 (en) * 2019-06-26 2022-08-04 Canon Kabushiki Kaisha Method and apparatus for encapsulating panorama images in a file

Families Citing this family (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR102598082B1 (ko) * 2016-10-28 2023-11-03 삼성전자주식회사 영상 표시 장치, 모바일 장치 및 그 동작방법
WO2018131813A1 (en) * 2017-01-10 2018-07-19 Samsung Electronics Co., Ltd. Method and apparatus for generating metadata for 3d images
US10979663B2 (en) * 2017-03-30 2021-04-13 Yerba Buena Vr, Inc. Methods and apparatuses for image processing to optimize image resolution and for optimizing video streaming bandwidth for VR videos
WO2018198487A1 (en) * 2017-04-25 2018-11-01 Sharp Kabushiki Kaisha Systems and methods for signaling quality information for regions in virtual reality applications
EP3649776A4 (en) * 2017-07-03 2020-11-04 Nokia Technologies Oy APPARATUS, METHOD, AND COMPUTER PROGRAM FOR OMNIDIRECTIONAL VIDEO
CN109218755B (zh) * 2017-07-07 2020-08-25 华为技术有限公司 一种媒体数据的处理方法和装置
CN110999308B (zh) * 2017-08-10 2022-02-01 索尼公司 发送装置、发送方法、接收装置和接收方法
US11270413B2 (en) * 2017-10-20 2022-03-08 Sony Corporation Playback apparatus and method, and generation apparatus and method
EP3721636A1 (en) * 2017-12-07 2020-10-14 Koninklijke KPN N.V. Method for adaptive streaming of media
WO2019195101A1 (en) * 2018-04-05 2019-10-10 Futurewei Technologies, Inc. Efficient association between dash objects
US11146802B2 (en) * 2018-04-12 2021-10-12 Mediatek Singapore Pte. Ltd. Methods and apparatus for providing two-dimensional spatial relationships
GB2574445A (en) * 2018-06-06 2019-12-11 Canon Kk Method, device, and computer program for transmitting media content
US11729243B2 (en) * 2019-09-20 2023-08-15 Intel Corporation Dash-based streaming of point cloud content based on recommended viewports
CN114503587A (zh) * 2019-10-07 2022-05-13 Lg电子株式会社 点云数据发送装置、点云数据发送方法、点云数据接收装置和点云数据接收方法
WO2021107663A1 (ko) * 2019-11-27 2021-06-03 엘지전자 주식회사 영상 디코딩 방법 및 그 장치
US11356698B2 (en) * 2019-12-30 2022-06-07 Tencent America LLC Method for parameter set reference constraints in coded video stream
US20210306650A1 (en) * 2020-03-31 2021-09-30 Tencent America LLC Method for signaling subpicture partitioning in coded video stream
CN113766271B (zh) * 2020-06-04 2022-07-12 腾讯科技（深圳）有限公司 一种沉浸媒体的数据处理方法、装置及设备
US20230209091A1 (en) * 2020-06-17 2023-06-29 Intel Corporation Method, apparatus, and articles of manufacture to generate packed video frames for a volumetric video bitstream and an immersive video bitstream

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040050888A (ko) * 2001-10-29 2004-06-17 소니 가부시끼 가이샤 비평면 화상의 화상 처리 장치 및 화상 처리 방법, 기억매체 및 컴퓨터 프로그램
KR20060050348A (ko) * 2004-08-13 2006-05-19 경희대학교 산학협력단 20면체 파노라마 영상의 부호화 및 복호화를 위한 방법 및장치
KR20160079357A (ko) * 2014-12-26 2016-07-06 주식회사 케이티 파노라믹 비디오 영상의 관심 영역의 영상 전송 방법, 장치 및 디바이스
KR20160125708A (ko) * 2015-04-22 2016-11-01 삼성전자주식회사 가상현실 스트리밍 서비스를 위한 영상 데이터를 송수신하는 방법 및 장치
KR20170018352A (ko) * 2014-06-27 2017-02-17 코닌클리즈케 케이피엔 엔.브이. Hevc-타일드 비디오 스트림을 기초로 한 관심영역 결정

Family Cites Families (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150068299A (ko) * 2013-12-09 2015-06-19 씨제이씨지브이 주식회사 다면 영상 생성 방법 및 시스템
US20160150212A1 (en) * 2014-11-26 2016-05-26 Sony Corporation Live selective adaptive bandwidth
JP2017040687A (ja) * 2015-08-17 2017-02-23 株式会社リコー 画像表示システム、情報処理装置、画像表示方法及びプログラム
KR102301352B1 (ko) * 2016-02-09 2021-09-14 프라운호퍼 게젤샤프트 쭈르 푀르데룽 데어 안겐반텐 포르슝 에. 베. 효율적인 감소성 또는 효율적인 랜덤 액세스를 허용하는 픽처/비디오 데이터 스트림들에 대한 개념
KR102523997B1 (ko) * 2016-02-12 2023-04-21 삼성전자주식회사 360도 영상 처리 방법 및 장치
US10319071B2 (en) * 2016-03-23 2019-06-11 Qualcomm Incorporated Truncated square pyramid geometry and frame packing structure for representing virtual reality video content
US11019257B2 (en) * 2016-05-19 2021-05-25 Avago Technologies International Sales Pte. Limited 360 degree video capture and playback
US10841566B2 (en) * 2016-05-26 2020-11-17 Vid Scale, Inc. Methods and apparatus of viewport adaptive 360 degree video delivery
US10360721B2 (en) * 2016-05-26 2019-07-23 Mediatek Inc. Method and apparatus for signaling region of interests
EP3501014A1 (en) * 2016-08-17 2019-06-26 VID SCALE, Inc. Secondary content insertion in 360-degree video
JP2019530311A (ja) * 2016-09-02 2019-10-17 ヴィド スケール インコーポレイテッド ３６０度ビデオ情報をシグナリングするための方法およびシステム
KR102352933B1 (ko) * 2016-09-09 2022-01-20 삼성전자주식회사 3차원 이미지를 프로세싱하기 위한 방법 및 장치
US11172005B2 (en) * 2016-09-09 2021-11-09 Nokia Technologies Oy Method and apparatus for controlled observation point and orientation selection audiovisual content
US10313686B2 (en) * 2016-09-20 2019-06-04 Gopro, Inc. Apparatus and methods for compressing video content using adaptive projection selection
WO2018067952A1 (en) * 2016-10-07 2018-04-12 Vid Scale, Inc. Geometry conversion and frame packing associated with 360-degree videos
WO2018068213A1 (zh) * 2016-10-10 2018-04-19 华为技术有限公司 一种视频数据的处理方法及装置
US10917564B2 (en) * 2016-10-12 2021-02-09 Qualcomm Incorporated Systems and methods of generating and processing files for partial decoding and most interested regions
US10652553B2 (en) * 2016-12-07 2020-05-12 Qualcomm Incorporated Systems and methods of signaling of regions of interest
US20180176468A1 (en) * 2016-12-19 2018-06-21 Qualcomm Incorporated Preferred rendering of signalled regions-of-interest or viewports in virtual reality video
US10560660B2 (en) * 2017-01-04 2020-02-11 Intel Corporation Rectilinear viewport extraction from a region of a wide field of view using messaging in video transmission
US10742999B2 (en) * 2017-01-06 2020-08-11 Mediatek Inc. Methods and apparatus for signaling viewports and regions of interest
US11290755B2 (en) * 2017-01-10 2022-03-29 Qualcomm Incorporated Signaling data for prefetching support for streaming media data
US10194097B2 (en) * 2017-01-13 2019-01-29 Gopro, Inc. Apparatus and methods for the storage of overlapping regions of imaging data for the generation of optimized stitched images
US11172208B2 (en) * 2017-02-28 2021-11-09 Nokia Technologies Oy Method and apparatus for improving the visual quality of viewport-based omnidirectional video streaming
US11532128B2 (en) * 2017-03-23 2022-12-20 Qualcomm Incorporated Advanced signaling of regions of interest in omnidirectional visual media
US11062738B2 (en) * 2017-03-23 2021-07-13 Qualcomm Incorporated Signalling of video content including sub-picture bitstreams for video coding
US10805650B2 (en) * 2017-03-27 2020-10-13 Qualcomm Incorporated Signaling important video information in network video streaming using mime type parameters

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20040050888A (ko) * 2001-10-29 2004-06-17 소니 가부시끼 가이샤 비평면 화상의 화상 처리 장치 및 화상 처리 방법, 기억매체 및 컴퓨터 프로그램
KR20060050348A (ko) * 2004-08-13 2006-05-19 경희대학교 산학협력단 20면체 파노라마 영상의 부호화 및 복호화를 위한 방법 및장치
KR20170018352A (ko) * 2014-06-27 2017-02-17 코닌클리즈케 케이피엔 엔.브이. Hevc-타일드 비디오 스트림을 기초로 한 관심영역 결정
KR20160079357A (ko) * 2014-12-26 2016-07-06 주식회사 케이티 파노라믹 비디오 영상의 관심 영역의 영상 전송 방법, 장치 및 디바이스
KR20160125708A (ko) * 2015-04-22 2016-11-01 삼성전자주식회사 가상현실 스트리밍 서비스를 위한 영상 데이터를 송수신하는 방법 및 장치

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020189816A1 (ko) * 2019-03-19 2020-09-24 전자부품연구원 360 vr 인터랙티브 중계를 위한 사용자 인터페이스 및 방법
US20220245190A1 (en) * 2019-06-26 2022-08-04 Canon Kabushiki Kaisha Method and apparatus for encapsulating panorama images in a file
US11853351B2 (en) * 2019-06-26 2023-12-26 Canon Kabushiki Kaisha Method and apparatus for encapsulating panorama images in a file

Also Published As

Publication number Publication date
KR20190107666A (ko) 2019-09-20
US20190373245A1 (en) 2019-12-05
KR102277267B1 (ko) 2021-07-14

Similar Documents

Publication Publication Date Title
WO2018182144A1 (ko) 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
WO2018174387A1 (ko) 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
WO2018038520A1 (ko) 전방향 비디오를 전송하는 방법, 전방향 비디오를 수신하는 방법, 전방향 비디오 전송 장치, 전방향 비디오 수신 장치
WO2018038523A1 (ko) 전방향 비디오를 전송하는 방법, 전방향 비디오를 수신하는 방법, 전방향 비디오 전송 장치, 전방향 비디오 수신 장치
WO2017188714A1 (ko) 360도 비디오를 전송하는 방법, 360도 비디오를 수신하는 방법, 360도 비디오 전송 장치, 360도 비디오 수신 장치
WO2017142353A1 (ko) 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
WO2020190114A1 (ko) 포인트 클라우드 데이터 송신 장치, 포인트 클라우드 데이터 송신 방법, 포인트 클라우드 데이터 수신 장치 및 포인트 클라우드 데이터 수신 방법
WO2020071703A1 (ko) 포인트 클라우드 데이터 전송 장치, 포인트 클라우드 데이터 전송 방법, 포인트 클라우드 데이터 수신 장치 및/또는 포인트 클라우드 데이터 수신 방법
WO2018131832A1 (ko) 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
WO2019151798A1 (ko) 무선 통신 시스템에서 이미지에 대한 메타데이터를 송수신하는 방법 및 장치
WO2017204491A1 (ko) 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
WO2019066436A1 (ko) 360 비디오 시스템에서 오버레이 처리 방법 및 그 장치
WO2019194573A1 (en) Method for transmitting 360-degree video, method for receiving 360-degree video, apparatus for transmitting 360-degree video, and apparatus for receiving 360-degree video
WO2019198883A1 (ko) 핫스팟 및 roi 관련 메타데이터를 이용한 360도 비디오를 송수신하는 방법 및 그 장치
WO2020197083A1 (ko) Dmvr 및 bdof 기반의 인터 예측 방법 및 장치
WO2018217057A1 (ko) 360 비디오 처리 방법 및 그 장치
WO2018169176A1 (ko) 퀄리티 기반 360도 비디오를 송수신하는 방법 및 그 장치
WO2019168304A1 (ko) 카메라 렌즈 정보를 포함한 360도 비디오를 송수신하는 방법 및 그 장치
WO2018169139A1 (ko) 360도 비디오의 영역 정보 전달 방법 및 장치
WO2019066191A1 (ko) 스티칭 및 리프로젝션 관련 메타데이터를 이용한 6dof 비디오를 송수신하는 방법 및 그 장치
WO2019083266A1 (ko) 피쉬아이 비디오 정보를 포함한 360도 비디오를 송수신하는 방법 및 그 장치
WO2019059462A1 (ko) 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
WO2020242023A1 (ko) 360 비디오를 전송하는 방법, 360 비디오를 수신하는 방법, 360 비디오 전송 장치, 360 비디오 수신 장치
WO2020036384A1 (en) An apparatus for transmitting a video, a method for transmitting a video, an apparatus for receiving a video, and a method for receiving a video
WO2019245302A1 (en) Method for transmitting 360-degree video, method for providing a user interface for 360-degree video, apparatus for transmitting 360-degree video, and apparatus for providing a user interface for 360-degree video

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: 18776042

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 20197019426

Country of ref document: KR

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 18776042

Country of ref document: EP

Kind code of ref document: A1