Patent Description:
Early efforts in <NUM>-D movie technology used anaglyphs, in which two images of the same scene, with a relative offset between them, are superimposed on a single piece of movie film, with the images being subject to complimentary color filters (e.g., red and green). Viewers donned special glasses so that one image would be seen only by the left eye while the other would be seen only by the right eye. When the brains of the viewers fused the two images, the result was the illusion of depth. In the <NUM>, "dual-strip" projection techniques were widely used to show <NUM>-D movies. Using dual-strip projection techniques, two films were projected side-by-side in synchronism, with the light from each projector being oppositely polarized. Viewers wore polarizing glasses, and each eye would see only one of the two images. More recently, active polarization has been used to distinguish left-eye and right-eye images. Left-eye and right-eye images are projected sequentially using an active direction-flipping circular polarizer that applies opposite circular polarization to the left-eye and right-eye frames. The viewer dons glasses with opposite fixed circular polarizers for each eye, so that each eye sees only the intended frames. Various other systems for projecting <NUM>-D movies have also been used over the years.

The trend towards <NUM>-D movies in theatres and in home entertainment systems has been growing. The <NUM>-D movies may be produced using stereoscopic techniques. Stereoscopic techniques create an illusion of depth from a pair of <NUM>-D images, each of which is presented to a separate eye of a viewer. The pair of <NUM>-D images may represent two slightly different perspectives of a scene. The slightly different perspectives may resemble the natural, binocular vision of the eyes of the viewer. By presenting <NUM>-D images of slightly different perspectives to the right eye and to the left eye of the viewer, respectively, the viewer may perceive a three dimensional composite of the <NUM>-D images, in which certain objects of the scene appear nearer to the viewer than other objects of the scene. That is, the brain of the viewer may merge or fuse the left and right eye images to create a perception of depth.

The degree of offset of objects in the image pair determines the depth at which the objects are perceived by the viewer. An object may appear to protrude toward the viewer and away from the neutral plane or screen when the position or coordinates of the left eye image are crossed with the position or coordinates of the right eye image (e.g., negative parallax). In contrast, an object may appear to recede or be behind the screen when the position or coordinates of the left eye image and of the right image are not crossed (e.g., positive parallax).

It is increasingly common for movies to be filmed (in the case of live action movies) or imaged (in the case of rendered animations) in stereo for <NUM>-D viewing. Image frames used to produce stereoscopic video (or stereo video) may be referred to as stereoscopic images. An image frame (or simply, frame) refers to an image at a specific point in time. An illusion of motion may be achieved by presenting multiple frames per second (fps) to the viewer, such as twenty-four to thirty fps. A frame may include content from a live action movie filmed with two or more cameras. A frame may also include content from a rendered animation that is imaged using two camera locations. In stereo video, stereoscopic perception results from the presenting a left eye image stream and a right eye image stream to the viewer. The following prior art document:
<NPL>,
discloses signalling alternative 3D formats for 3D-HEVC among which global view/ depth formats and some generic warping. The signalling takes place via a depth_type syntax element that is included in a SEI message and leads to interpreting differently the decoded 3D data.

So that the manner in which the above recited features presented in this disclosure can be understood in detail, a more particular description, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments presented in this disclosure and are therefore not to be considered limiting of its scope, for the disclosure may admit to other equally effective embodiments, as long as they fall under the scope of the appended claims, which define the invention.

The expressions "embodiment" and "invention" are not always consistently used along the description. Any subject-matter not falling under the scope of the claims is to be understood as representing a further example outside the scope of the invention, even if it happens to be presented as an "embodiment" or as belonging to the "invention".

<FIG> and <FIG> and the corresponding parts of the description provide the enabling disclosure and illustrate the key aspects of the invention.

Embodiments presented in this disclosure provide techniques for view generation based on a video coding scheme. In some embodiments, views may be generated based on warp maps. It may often be desirable to generate multiple views, such as to support use of multiscopic displays, which facilitate stereoscopic viewing without the need for any spectacles to be worn by the user. In scenarios where warp maps are generated during content production, it may be desirable to transmit the warp maps - along with video data - to the users, in order to facilitate generating multiple views by the receiving application. The warp maps may be transmitted based on the video coding scheme and according to embodiments disclosed herein.

In one embodiment, the video coding scheme may be tailored to facilitate transmission of a bitstream containing multi-view video and depth map data. In one embodiment, quantized warp map offsets are transmitted in the bitstream, where the quantized warp map offsets may have the same format as depth maps. Quantized warp map offsets may also be referred to herein as quantized map offsets. So that the receiving application can appropriately interpret the received bitstream, a predefined message is submitted in the bitstream. In one embodiment, the video coding scheme is a High Efficiency Video Coding (HEVC) extension for 3D video coding (3D-HEVC), and the predefined message is a supplementary enhancement information (SEI) message.

In one embodiment, the message indicates, to the receiving application, that image-domain warping - rather than depth-image-based rendering - is to be used as a view synthesis technique. Additionally or alternatively, the message indicates, to the receiving application, that depth samples decoded from the bitstream are to be interpreted as quantized warp map offsets as opposed to depth samples such as a depth map. The message may also indicate, to the receiving application, that syntax elements included in the message are to be used to generate warp maps based on the quantized warp map offsets. The message may also indicate, to the receiving application, that the generated warp maps are to be used for view generation based on image-domain warping. Further, the message need not necessarily be transmitted in some cases, such as where it is desired to transmit multi-view video and depth map data based on the video coding scheme. In such cases, the receiving application uses depth-image-based rendering in lieu of image-domain warping, to generate views. The syntax and semantics associated with the message are specified in the present disclosure, including Appendices A-B attached hereto.

At least in some embodiments, warp maps may often be generated more efficiently or conveniently than depth maps. For instance, warp map generation may often not require as much human intervention as depth map generation. In some embodiments, warp map generation may be substantially or even fully automatic. By using the techniques disclosed herein to generate views based on warp maps, the views may also be generated more efficiently or conveniently at least in some cases.

<FIG> is a data flow diagram illustrating a system <NUM> for view generation based on a video coding scheme, according to one embodiment presented in this disclosure. As shown, the system <NUM> includes a transmitting application <NUM> and a receiving application <NUM>. In one embodiment, the transmitting application <NUM> generates a bitstream <NUM> encoded based on the video coding scheme. The bitstream <NUM> includes video <NUM>, quantized warp map offsets <NUM>, and a message <NUM> of a message type specified by the video coding scheme. The message <NUM> contains syntax elements <NUM>. The transmitting application <NUM> transmits the bitstream <NUM> to the receiving application <NUM>. The receiving application <NUM> receives the bitstream <NUM> and interprets, based on a first syntax element <NUM> included in the message <NUM>, depth samples decoded from the bitstream <NUM>, as a first depth format of quantized warp map offsets. The receiving application <NUM> then generates warp maps <NUM> based on quantized warp map offsets interpreted from the bitstream <NUM> and based further on a second syntax element <NUM> included in the message <NUM>. The receiving application <NUM> then generates views <NUM> using image-domain warping and based on the video <NUM> and the warp maps <NUM>.

In one embodiment, the video coding scheme is 3D-HEVC, and the message type is the SEI message type. The video <NUM> may be multi-view video. Further, image-domain warping may be used in lieu of depth-image-based rendering, and the depth samples may be interpreted as quantized warp map offsets in lieu of depth maps. In some embodiments, multi-view video and depth map data are transmitted using 3D-HEVC and in lieu of an SEI message. The first syntax element may specify any of a plurality of predefined depth types, such as quantized warp map offsets, depth maps, and so forth.

<FIG> depicts a syntax <NUM> for an SEI message, according to one embodiment presented in this disclosure. The syntax <NUM> specifies syntax elements <NUM> in the SEI message and descriptors <NUM>, each indicating a predefined parsing process for respective syntax element. In one embodiment, the SEI message signals to interpret decoded depth samples as an alternative depth format. A first syntax element <NUM> in the SEI message specifies a desired, alternative depth type. In one embodiment, a depth type value of zero indicates to use decoded depth samples to derive a warp map and further indicates to perform view synthesis via image-domain warping, while other depth type values, e.g., one through three, are reserved values. In one embodiment, a predefined depth type value, other than zero, indicates to perform view synthesis based on depth-image-based rendering rather than based on image-domain warping.

In one embodiment, additional syntax elements contained in the SEI message are used to derive corresponding warp maps from decoded depth samples of each view. For instance, a second syntax element <NUM> in the SEI message specifies an integer part of a minimum offset for a horizontal direction of a warp map. A third syntax element <NUM> specifies a fractional part of the minimum offset for the horizontal direction of the warp map. These syntax elements <NUM>, <NUM> may be used to derive a minimum horizontal offset, as follows: <MAT> Similarly, a fourth syntax element <NUM> specifies an integer part of a maximum offset for the horizontal direction of the warp map. A fifth syntax element <NUM> specifies a fractional part of the maximum offset for the horizontal direction of the warp map. The syntax elements <NUM>, <NUM> may be used to derive a maximum horizontal offset, as follows: <MAT>.

In one embodiment, a sixth syntax element <NUM> in the SEI message is a flag that, when set, indicates the presence of minimum and maximum offset values for the vertical direction. A seventh syntax element <NUM> specifies an integer part of a minimum offset for a vertical direction of the warp map. An eighth syntax element <NUM> species a fractional part of the minimum offset for the vertical direction of the warp map. The syntax elements <NUM>, <NUM> may be used to derive a minimum vertical offset, as follows: <MAT> Similarly, a ninth syntax element <NUM> specifies an integer part of a maximum offset for the vertical direction of the warp map. A tenth syntax element <NUM> specifies a fractional part of the maximum offset for the vertical direction of the warp map. The syntax elements <NUM>, <NUM> may be used to derive a maximum vertical offset, as follows: <MAT>.

In one embodiment, an eleventh syntax element <NUM> in the SEI message is a flag that, when set, specifies the presence of a new warp map size that is valid for the current and all ensuing warp maps in output order, until another new warp map size is explicitly specified. When cleared, the flag specifies that the warp map size remains unchanged. Twelfth and thirteenth syntax elements <NUM> and <NUM> specify a width and a height of the warp map, respectively. In one embodiment, valid values for the syntax elements <NUM>, <NUM> are given as follows: <MAT> Although embodiments herein are described with reference to the syntax <NUM> and the syntax elements <NUM>, this is not intended to be limiting of disclosed embodiments, and other syntaxes, syntax elements, descriptors, and values are broadly contemplated in the present disclosure.

<FIG> depicts pseudocode <NUM> to derive a warp map from decoded depth samples and syntax elements provided by the SEI message, according to one embodiment presented in this disclosure. As shown, the pseudocode <NUM> iterates though the width and height of the warp map, respectively, deriving each value of the warp map based on the decoded depth samples and syntax elements. In such a manner, decoded depth samples of each view are used to derive a corresponding warp map for the respective view. The decoded depth samples and the warp map are represented in the pseudocode <NUM> as d and w, respectively. In one embodiment, each warp map so derived is assigned to its corresponding input view. Further, each warp map has a property to map the corresponding input view to a central camera position.

<FIG> illustrates exemplary camera positions and associated warp maps <NUM>, according to one embodiment presented in this disclosure. As indicated by a legend <NUM>, the camera positions include input camera positions <NUM> and central camera positions <NUM>. In this particular example, only the warp map WA,M_AS of the leftmost input view maps its corresponding input view to a central camera position <NUM><NUM> to its right. In contrast, the other warps maps WB,M_AB, WC,M_BC, WD,M_CD map their corresponding input views to central camera positions <NUM><NUM>, <NUM><NUM>, <NUM><NUM> to their left, respectively.

<FIG> depicts pseudocode <NUM> to derive a warp map used to synthesize a view at an arbitrary position Q using an input view at position P, according to one embodiment presented in this disclosure. Position P corresponds to either positions A, B, C, or D in <FIG>. The warp map, represented in the pseudocode <NUM> as w_pq, is derived from a warp map w_pm, which maps the same input view to a central camera position M in <FIG>. The warp map w_pq is then used to synthesize the texture for a view at position Q from texture of a view at position P.

In one embodiment, warp map samples are interpreted as a two-dimensional sub-pixel position in the synthesized view, to which the color samples of the input view at the sub-pixel position (x*deltax, y*deltax) are mapped. The warp map samples are represented in the pseudocode as w_pq[x][y][<NUM>] and w_pq[x][y][<NUM>]. A warp map also represents a mapping of color samples of quads of the input view to corresponding quads in the synthesized view. In one embodiment, the quads of the input view are defined by four positions given by: <MAT> The corresponding quads in the synthesized view are defined by corresponding positions given by: <MAT>.

Thus, the quad-based color mapping process described above provides synthesis of an arbitrary view at position Q from an input view at position P and a warp map w_pq, where the warp map w_pq is derived from a warp map w_pm, which is in turn derived from decoded depth samples and syntax elements provided by the SEI message. Depending on the embodiment, the position of a view to synthesize may not necessarily be disposed between two input views. In cases where the view is indeed disposed between two input views, then two different versions of the view may be synthesized, including a first version based on the closest input view to its left, and a second version based on the closest input view to its right. A final synthesized view may then be computed by combining both results via a predefined view composition technique, e.g., pixel-wise blending. On the other hand, in cases where the view to synthesize is not disposed between input views, then the closest input view may be used to synthesize the view.

<FIG> is a flowchart depicting a method <NUM> for view generation based on the video coding scheme, according to one embodiment presented in this disclosure. As shown, the method <NUM> begins at step <NUM>, where the transmitting application <NUM> generates a first bitstream encoded based on the video coding scheme. The first bitstream includes video, one or more quantized warp map offsets, and a first message of a predefined message type specified by the video coding scheme. The first message contains syntax elements including a first syntax element and a second syntax element. Each syntax element is disposed at an arbitrarily defined offset within the first message. In other words, reference to the first syntax element does not necessarily imply that the first syntax element is first in order relative to other syntax elements in the first message. Depending on the embodiment, the first syntax element may be first in order, second in order, last in order, etc. At step <NUM>, the transmitting application <NUM> transmits the first bitstream to the receiving application <NUM>.

At step <NUM>, the receiving application <NUM> receives the first bitstream from the transmitting application. At step <NUM>, the receiving application <NUM> interprets, based on the first syntax element included in the first message, depth samples decoded from the first bitstream, as a first predefined depth format of quantized warp map offsets. At step <NUM>, the receiving application <NUM> generates one or more warp maps based on one or more quantized warp map offsets interpreted from the first bitstream, and based further on at least the second syntax element. At step <NUM>, the receiving application <NUM> generates one or more views using image-domain warping and based on the video and the one or more warp maps.

<FIG> is a flowchart depicting a method <NUM> for view generation based on the video coding scheme, according to one embodiment presented in this disclosure. As shown, the method <NUM> begins at step <NUM>, where the transmitting application generates a second bitstream encoded based on the video coding scheme. The second bitstream includes video, one or more depth maps, and a second message of the predefined message type specified by the video coding scheme. Depending on the embodiment, the video included in the second bitstream may be the same as or different from the video included in the first bitstream. The second message contains the first syntax element. The first syntax element in the second message specifies a depth type different than the first syntax element in the first message. At step <NUM>, the transmitting application <NUM> transmits the second bitstream to the receiving application <NUM>.

At step <NUM>, the receiving application <NUM> receives the second bitstream from the transmitting application <NUM>. At step <NUM>, the receiving application <NUM> interprets, based on the first syntax element included in the second message, depth samples decoded from the second bitstream, as a second predefined format of depth maps. At step <NUM>, the receiving application <NUM> generates one or more views using depth-image-based rendering and based on the video and one or more depth maps interpreted from the second bitstream.

<FIG> is a block diagram illustrating components of the system <NUM> for view generation, according to one embodiment presented in this disclosure. The system <NUM> corresponds to the system <NUM> of <FIG>. As shown, the system <NUM> includes a plurality of client systems <NUM> and a plurality of server systems <NUM>. The client systems <NUM> are communicatively coupled via a network <NUM>. In some embodiments, the server systems <NUM> may also be communicatively coupled via the network <NUM> or via a network other than the network <NUM>. In one embodiment, the network <NUM> is an ad hoc network connecting multiple cellular phones.

In one embodiment, the client systems <NUM> may include existing computer systems, e.g., smartphones and other cellular phones, desktop computers, server computers, laptop computers, tablet computers, gaming consoles, hand-held or portable devices and the like. The client systems <NUM> illustrated in <FIG>, however, are merely examples of computer systems in which embodiments disclosed herein may be used. Embodiments disclosed herein may be implemented differently, regardless of whether the computer systems are complex multi-user computing systems, such as a cluster of individual computers connected by a highspeed network, single-user workstations, or network appliances lacking non-volatile storage. Moreover, it is explicitly contemplated that embodiments disclosed herein may be implemented using any device or computer system capable of performing the functions described herein.

As shown, each client system <NUM> and server system <NUM> includes, without limitation, a processor <NUM>, which obtains instructions and data via a bus <NUM> from a memory <NUM> and storage <NUM>. The processor <NUM> is a programmable logic device that performs instruction, logic, and mathematical processing, and may be representative of one or more CPUs. The memory <NUM> is any memory sufficiently large to hold the necessary programs and data structures. The memory <NUM> could be one or a combination of memory devices, including Random Access Memory, nonvolatile or backup memory (e.g., programmable or Flash memories, read-only memories, etc.).

As shown, the memory <NUM> includes an operating system ("OS") <NUM>. Operating system <NUM> is software used for managing the operation of the client system <NUM> or the server system <NUM>. Examples of the OS <NUM> include UNIX, versions of the Microsoft Windows® operating system and distributions of the Linux® operating system. Additional examples of the OS <NUM> include custom operating systems for smartphones and gaming consoles, including the custom operating systems for systems such as the Microsoft Xbox <NUM>®, Nintendo Wii® and Sony PlayStation® <NUM>. As shown, the memory <NUM><NUM> of the client system <NUM> further includes the receiving application <NUM>, which is configured according to embodiments described above. The memory <NUM><NUM> of the server system <NUM> further includes the transmitting application <NUM>, which is also configured according to embodiments described above.

In one embodiment, the storage <NUM> is representative of hard-disk drives, flash memory devices, optical media and the like. Generally, the storage <NUM> stores application programs and data for use by the client systems <NUM>. In addition, the memory <NUM> and the storage <NUM> may be considered to include memory physically located elsewhere; for example, on another computer coupled to the client system <NUM> or to the server system <NUM> via the bus <NUM>. The client systems <NUM> and the server systems <NUM> include network interfaces for operably connecting to one another via a network, such as the network <NUM>. As shown, the storage <NUM><NUM> of the server system <NUM> includes the bitstream <NUM> to be transmitted to the client system <NUM>. The storage <NUM><NUM> of the client system <NUM> includes the bitstream <NUM> that is received from the server system <NUM>, according to embodiments described above.

In one embodiment, the client systems <NUM> are each coupled to a display device <NUM>. The display device <NUM> may include output devices such as cellular phone displays, movie theater displays, monitors, touch screen displays, and so forth. In some embodiments, each client system <NUM> is also coupled to an input device <NUM>. The input device <NUM> may include keypads, keyboards, mice, controllers, and so forth.

In the preceding, reference is made to embodiments presented in this disclosure. However, the scope of the present disclosure is not limited to specific described embodiments. Instead, any combination of the following features and elements, whether related to different embodiments or not, is contemplated to implement and practice contemplated embodiments. Furthermore, although embodiments disclosed herein may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the preceding aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s). Likewise, reference to "the invention" shall not be construed as a generalization of any inventive subject matter disclosed herein and shall not be considered to be an element or limitation of the appended claims except where explicitly recited in a claim(s).

Aspects presented in this disclosure may be embodied as a system, method or computer program product. Accordingly, aspects disclosed herein may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system. " Furthermore, aspects disclosed herein may take the form of a computer program product embodied in one or more computer readable medium(s) having computer readable program code embodied thereon.

In the context of this disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

Computer program code for carrying out operations for aspects disclosed herein may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the computer of a user, partly on the computer of the user, as a stand-alone software package, partly on the computer of the user and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the computer of the user via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).

Aspects presented in this disclosure are described above with reference to flowchart illustrations or block diagrams of methods, apparatus (systems) and computer program products according to embodiments disclosed herein. It will be understood that each block of the flowchart illustrations or block diagrams, and combinations of blocks in the flowchart illustrations or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart or block diagram block or blocks.

These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer readable medium produce an article of manufacture including instructions which implement the function/act specified in the flowchart or block diagram block or blocks.

The computer program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus or other devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions/acts specified in the flowchart or block diagram block or blocks.

Embodiments disclosed herein may be provided to end users through a cloud computing infrastructure. Cloud computing generally refers to the provision of scalable computing resources as a service over a network. More formally, cloud computing may be defined as a computing capability that provides an abstraction between the computing resource and its underlying technical architecture (e.g., servers, storage, networks), enabling convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. Thus, cloud computing allows a user to access virtual computing resources (e.g., storage, data, applications, and even complete virtualized computing systems) in "the cloud," without regard for the underlying physical systems (or locations of those systems) used to provide the computing resources.

Typically, cloud computing resources are provided to a user on a pay-peruse basis, where users are charged only for the computing resources actually used (e.g. an amount of storage space consumed by a user or a number of virtualized systems instantiated by the user). A user can access any of the resources that reside in the cloud at any time, and from anywhere across the Internet. In context of the present disclosure, the bitstream <NUM> may be stored in the cloud, and the transmitting application <NUM> or the receiving application <NUM> may additionally execute in the cloud, thereby improving accessibility of the bitstream <NUM> at least in some cases.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments disclosed herein. Each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special-purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

Claim 1:
A computer-implemented method of view generation based on a video coding scheme, the computer implemented method comprising:
receiving a first bitstream (<NUM>) encoded based on the video coding scheme, wherein the video coding scheme is a High Efficiency Video Coding extension for 3D video coding (3D-HEVC), wherein the first bitstream includes video, one or more depth samples, and a first message of a predefined message type specified by the video coding scheme, wherein the predefined message type is a supplementary enhancement information (SEI) message type, wherein the first message contains a plurality of syntax elements including a first syntax element and a second syntax element;
determining, based on a first depth type, specified by the first syntax element, to interpret (<NUM>) the one or more depth samples, which are decoded from the first bitstream, as being a first predefined depth format comprising a warp-map-offset format;
generating one or more warp maps (<NUM>) based on at least the second syntax element and interpreting the one or more depth samples as one or more quantized warp map offsets; and
generating, by an application and based on the first depth type specified by the first syntax element, one or more views (<NUM>) using image-domain warping and based on the video and the one or more warp maps,
wherein the application is configured such that in lieu of the first depth type being specified, a second depth type is specifiable, or an SEI message is omittable, to cause view generation by the application based on interpreting the one or more depth samples as being in a second predefined depth format other than the warp-map-offset format, wherein the second depth type indicates depth-image-based rendering and wherein the second predefined depth format is a depth-map format.