Memory allocation for seamless media content presentation

The growing popularity of Virtual Reality (VR) technologies has resulted in an increase in real-time rendering performance requirements, while concurrently demanding high fidelity and immersive content for viewers. The storage requirements for datasets utilized in VR applications can easily reach tens of Gigabytes, which exceeds the memory capacity of many graphics processing units (GPUs).

There are provided systems and methods for performing memory allocation for seamless media content presentation, substantially as shown in and/or described in connection with at least one of the figures, and as set forth more completely in the claims.

FIG. 1 shows a diagram of an exemplary virtual reality (VR) venue including a system for performing memory allocation for seamless media content presentation, according to one implementation;

FIG. 2 shows a more detailed block diagram of an exemplary system for performing memory allocation for seamless media content presentation, according to one implementation;

FIG. 3 shows an exemplary system and a computer-readable non-transitory medium including instructions for performing memory allocation for seamless media content presentation, according to one implementation; and

FIG. 4 shows a flowchart presenting an exemplary method for performing memory allocation for seamless media content presentation, according to one implementation.

The following description contains specific information pertaining to implementations in the present disclosure. One skilled in the art will recognize that the present disclosure may be implemented in a manner different from that specifically discussed herein. The drawings in the present application and their accompanying detailed description are directed to merely exemplary implementations. Unless noted otherwise, like or corresponding elements among the figures may be indicated by like or corresponding reference numerals. Moreover, the drawings and illustrations in the present application are generally not to scale, and are not intended to correspond to actual relative dimensions.

As stated above, the growing popularity of Virtual Reality (VR) technologies has resulted in an increase in real-time rendering performance requirements, while concurrently demanding high fidelity and immersive content for viewers. The storage requirements for datasets utilized in VR applications can easily reach tens of Gigabytes, which exceeds the memory capacity of many graphics processing units (GPUs). As a result, an important enabling feature of such technologies is the efficient memory allocation for the typically high-bandwidth data that is contained in compressed animated lightfields. Unless that goal is successfully achieved, a user of a VR system may experience an immersive walkthrough that includes lags or latencies incurred due to visual data not being presented when it is visible or imminently visible.

Nevertheless, moving the dynamic datasets encountered in VR applications, datasets that may change frequently due to temporal and/or spatial configurations, for example, remains a challenging problem. For instance, the data transmission bandwidth between the central processing unit (CPU) and GPU may experience bottleneck because the speed of the data bus connecting the CPU and GPU is typically slower than the rate of computation. In addition, the complexities associated with synchronization require special attention.

The present application discloses systems and methods for performing memory allocation for seamless media content presentation that overcome the drawbacks and deficiencies in the conventional art. By transferring a first dataset of media content from media content storage to GPU memory, and utilizing the first dataset to begin presentation of the media content to a system user, the present solution ensures that GPU memory resources are not overwhelmed. Moreover, by identifying a second dataset of the media content based on a location of the system user, as well as the time code status of the media content when the system user is at the location, the present solution ensures that the GPU memory is provisioned with the data needed to provide the system user with a seamless media content presentation. When implemented to provide a VR experience to the system user, for example, the present solution can advantageously support an arbitrary number of viewpoints for reconstructing three-dimensional (3D) scenes accurately and from substantially any point of view.

FIG. 1 shows a diagram of exemplary VR venue 126 including system 110 for performing memory allocation for seamless media content presentation, according to one exemplary implementation. According to the implementation shown in FIG. 1 , media content presentation system 110 may take the form of a wearable device, such as a head mounted VR viewer, for example. In addition, FIG. 1 shows system user 124 and media content storage 102 storing media content 104 . Also shown in FIG. 1 are first dataset 106 and second dataset 108 of media content 104 .

As further shown in FIG. 1 , in one implementation, media content presentation system 110 may be interactively linked to media content storage 102 by communication network 120 and network communication links 122 . In one such implementation, media content storage 102 may be a cloud based media content storage resource corresponding to one or more web servers accessible over a packet-switched network such as the Internet, for example. Alternatively, media content storage 102 may correspond to one or more servers supporting a local area network (LAN), or included in another type of limited distribution network.

According to the exemplary implementation shown in FIG. 1 , system user 124 may utilize media content presentation system 110 to enjoy a VR experience in VR venue 126 . For example, system user 124 may utilize media content presentation system 110 by wearing or carrying media content presentation system 110 to walk through or otherwise traverse VR venue 126 . According to implementations of the present inventive concepts, media content presentation system 110 is configured to provide system user 124 with a high fidelity, immersive VR experience, without significant latency, using media content 104 .

Media content 104 may take a variety of forms, depending upon the implementational details or use case for media content presentation system 110 . For example, in some implementations, media content 104 may include audio-visual content and/or haptic content. Moreover, in some implementations, media content 104 may include high-definition (HD) video, or ultra HD video, such as 2K or 4K video. In addition, in implementations in which media content presentation system 110 takes the form of a VR viewer, media content 104 may include 3D video.

As a specific example, in implementations in which media content presentation system 110 takes the form of a VR viewer, media content 104 may include full motion lightfield video (FMLV). In such an implementation, for each video frame of media content 104 , a set of 360-degree images per frame (color and depth) may be generated using a subset of predetermined camera viewpoints corresponding to VR venue 126 . That is to say, media content 104 may include video content contributed by multiple video cameras.

It is noted that media content 104 may be partitioned into first dataset 106 and second dataset 108 . However, it is emphasized that the depiction of first and second datasets 106 and 108 is merely exemplary. In other implementations, media content 104 may be partitioned into more than the two datasets shown in FIG. 1 .

FIG. 2 shows a more detailed block diagram of exemplary system 210 for performing memory allocation for seamless media content presentation, according to one implementation. As shown in FIG. 2 , media content presentation system 210 includes computing platform 212 having CPU 214 implemented as a hardware processor, and main memory 216 implemented as a non-transitory storage device. According to the present exemplary implementation, main memory 216 stores memory allocation software code 240 , and may further store media content 204 including first dataset 206 and second dataset 208 , as well as first differential dataset 207 and second differential dataset 209 . Also shown in FIG. 2 are display 218 , location sensor 234 , GPU 244 including GPU memory 246 , and data bus 248 linking main memory 216 and GPU memory 246 .

Media content presentation system 210 and media content 204 including first dataset 206 and second dataset 208 correspond respectively in general to media content presentation system 110 and media content 104 including first dataset 106 and second dataset 108 , in FIG. 1 , and those corresponding features may share any of the characteristics attributed to either corresponding feature by the present disclosure. In other words, media content presentation system 110 may include features corresponding respectively to computing platform 212 , main memory 216 , CPU 214 , GPU 244 including GPU memory 246 , location sensor 234 , display 218 , and memory allocation software code 240 .

It is noted that, in contrast to the exemplary implementation shown in FIG. 1 , media content 204 is stored in main memory 216 of media content presentation system 210 . Thus, according to the implementation shown in FIG. 2 , main memory 212 serves as a local substitute for media content storage 102 . It is also noted that in other implementations, media content storage 102 may take the form of another storage resource, such as an internal hard drive of computing platform 212 , or an external hard drive accessible by computing platform 212 . It is further noted that display 218 may take the form of a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic light-emitting diode (OLED) display, or another suitable display screen that performs a physical transformation of signals to light.

FIG. 3 shows exemplary system 310 and a computer-readable non-transitory medium including instructions for performing memory allocation for seamless media content presentation, according to one implementation. System 310 includes computing platform 312 having CPU 314 , GPU 344 , and main memory 316 , interactively linked to display 318 . Display 318 may take the form of an LCD, LED display, an OLED display, or another suitable display screen that performs a physical transformation of signals to light.

System 310 including computing platform 312 , CPU 314 , GPU 344 , main memory 316 , and display 318 corresponds in general to media content presentation system 110 , in FIG. 1 , and those corresponding features may share any of the characteristics attributed to either corresponding feature by the present disclosure. Furthermore, system 310 corresponds in general to media content presentation system 210 , in FIG. 2 . Consequently, system 310 may share any of the characteristics and may perform any of the actions attributed to corresponding media content presentation system 110 / 210 by the present disclosure.

Also shown in FIG. 3 is computer-readable non-transitory medium 350 having memory allocation software code 340 stored thereon. The expression “computer-readable non-transitory medium,” as used in the present application, refers to any medium, excluding a carrier wave or other transitory signal, that provides instructions to CPU 314 of computing platform 312 . Thus, a computer-readable non-transitory medium may correspond to various types of media, such as volatile media and non-volatile media, for example. Volatile media may include dynamic memory, such as dynamic random access memory (dynamic RAM), while non-volatile memory may include optical, magnetic, or electrostatic storage devices. Common forms of computer-readable non-transitory media include, for example, optical discs, RAM, programmable read-only memory (PROM), erasable PROM (EPROM), and FLASH memory.

According to the implementation shown in FIG. 3 , computer-readable non-transitory medium 350 provides memory allocation software code 340 for execution by CPU 314 of computing platform 312 . Memory allocation software code 340 corresponds in general to memory allocation software code 240 , in FIG. 2 , and is capable of performing all of the operations attributed to that corresponding feature by the present disclosure.

The functionality of memory allocation software code 240 / 340 will be further described by reference to FIG. 4 in combination with FIGS. 1, 2, and 3 . FIG. 4 shows flowchart 460 presenting an exemplary method for use by a system, such as media presentation system 110 and 210 , in respective FIGS. 1 and 2 , or system 310 , in FIG. 3 , to perform memory allocation for seamless media content presentation.

Flowchart 460 begins with transferring first dataset 106 / 206 of media content 104 / 204 from a media content storage to GPU memory 246 of media content presentation system 110 / 210 / 310 (action 461 ). By way of example, in one implementation, as shown in FIG. 1 , media content presentation system 110 may interact with remote media content storage 102 in order to transfer first dataset 106 to GPU memory 246 via communication network 120 and network communication links 122 .

However, in another implementation, as shown in FIG. 2 , main memory 216 of media content presentation system 210 may serve as a local media content storage for media content 204 . First dataset 206 may be transferred to GPU memory 246 from main memory 216 via data bus 248 . First dataset 106 / 206 may be transferred to GPU memory 246 from media content storage by memory allocation software code 240 / 340 , executed by CPU 214 / 314 of media content presentation system 110 / 210 / 310 .

Flowchart 460 continues with seamlessly presenting media content 104 / 204 to system user 124 by GPU 244 / 344 utilizing first dataset 106 / 206 (action 462 ). As noted above, media content 104 / 204 may include audio-visual content and/or haptic content. For example, in some implementations, media content 104 / 204 may include HD video, or ultra HD video, such as 2K or 4K video.

As also noted above, in implementations in which media content presentation system 110 / 210 / 310 takes the form of a VR viewer, as shown in FIG. 1 , media content 104 / 204 may include 3D video. In such an implementation, first dataset 106 / 206 may include FMLV in which each video frame includes a set of 360-degree color and depth images generated using a subset of predetermined camera viewpoints corresponding to VR venue 126 . Thus, in some implementations, seamlessly presenting media content 104 / 204 to system user 124 using first dataset 106 / 206 may correspond to initiating presentation of an immersive VR experience to system user 124 via display 218 . The seamless presentation of media content 104 / 204 to system user 124 by GPU 244 / 344 utilizing first dataset 106 / 206 may occur under the control of memory allocation software code 240 / 340 , executed by CPU 214 / 314 of media content presentation system 110 / 210 / 310 .

Flowchart 460 continues with registering a location of system user 124 during the seamless presentation of media content 104 / 204 to system user 124 by GPU 244 / 344 utilizing first dataset 106 / 206 (action 463 ). Registering the location of system user 124 may correspond to receiving and storing a location of system user 124 sensed by location sensor 234 of media content presentation system 110 / 210 / 310 . Location sensor 234 may be any suitable location sensing feature, and may include one or more of a gyroscope, an accelerometer, and a Global Positioning System (GPS) sensor, for example.

As a specific example, in implementations in which media content presentation system 110 / 210 / 310 takes the form of a head mounted VR viewer, as shown in FIG. 1 , the location of system user 124 may correspond to the location of system user 124 within VR venue 126 . Furthermore, in those implementations, location may include more than merely the spatial location of system user 124 . For example, in those implementations, the location of system user 124 may include viewpoint or perspective information, such as the altitude, tilt, and/or rotation of media content presentation system 110 . Registering the location of system user 124 during the seamless presentation of media content 104 / 204 to system user 124 by GPU 244 / 344 utilizing first dataset 106 / 206 may be performed by memory allocation software code 240 / 340 , executed by CPU 214 / 314 of media content presentation system 110 / 210 / 310 .

Flowchart 460 continues with registering a timecode status of media content 104 / 204 when system user 124 is at the location registered in action 463 (action 464 ). Media content 104 / 204 may be timecode indexed media content, where the timecode has a granularity of tenths, hundredths, or thousandths of a second, for example. In such an implementation, registering the timecode status of media content 104 / 204 when system user 124 is at the location registered in action 463 may correspond to reading and storing the timecode of media content 104 / 204 when system user 124 is at the registered location. Registering the timecode status of media content 104 / 204 when system user 124 is at the location registered in action 463 may be performed by memory allocation software code 240 / 340 , executed by CPU 214 / 314 of media content presentation system 110 / 210 / 310 .

Flowchart 460 continues with identifying second dataset 108 / 208 of media content 104 / 204 based on the location and the timecode status registered in respective actions 463 and 464 (action 465 ). Identification of second dataset 108 / 208 based on the location and the timecode status registered in respective actions 463 and 464 may be performed by memory allocation software code 240 / 340 , executed by CPU 214 / 314 of media content presentation system 110 / 210 / 310 .

As a specific exemplary implementation, in VR use cases, media content 104 / 204 may be per-viewpoint temporal media content including 3D video frames. Seamless presentation of such per-viewpoint temporal media content 104 / 204 requires that the next dataset, i.e., second dataset 108 / 208 , be transferred into GPU memory 246 in time for dependent rendering operations. This advantageously avoids potential stalls in a rendering pipeline due to unfinished memory transfers, which can lead to immersion breaking.

According to one implementation, identification of second dataset 108 / 208 needed for future rendering operations includes determining a clairvoyance window (C) representing a span of frames (F), for the viewpoints that are used for view reconstruction (P). The clairvoyance window, C, defines a unit subset of encoded viewpoint frames that are to be on GPU 244 / 344 for a given time range and media content 104 / 204 .

The clairvoyance window of each viewpoint, C p , is estimated to ensure that the correct next dataset, i.e., second dataset 108 / 208 is in GPU memory 246 in time for rendering operations. Given a particular viewpoint p i ∈P, C pi is determined using a common time-frame of reference φ, 1≤φ≤Φ, where Φ denotes the entire timecode of media content 104 / 204 . The variable φ is analogous to the frame reference for the next reconstructed view-frame. The beginning of C pi is estimated over the course of Φ given φ as c φ =φ−(φ mod F). The last frame in the span of C pi can be determined as c Δ =min (F, Φ−c φ ), which can be determined if the frames spanning C pi have elapsed. From this, the collective subset of frames in C for the set of viewpoints that are used for view reconstruction is defined by:

C=C p1 +C p2 + . . . +C pN

where N is the number of viewpoints that are used for reconstruction, and C pi is defined as ∫ cφ cΔ Φ. This representation for C is essential for providing support for certain key features in animated light fields such as dynamic video branching.

It follows that the frequency of transfer for a given media content 104 / 204 is dependent on

λ = { F Φ > F Φ Φ ≤ F

since the frames spanning C pi elapse specifically when c φ =φ. This ability to control the frequency via λ has an additional benefit with regard to performance tuning. It advantageously enables controlling the sizes of the datasets being transferred by tuning for the optimal value of F subject to hardware constraints. This is useful in scenarios where, for example, configurations on high-end desktop computing platforms may not be suitable for lower-powered mobile computing platforms. Moreover, λ can be chosen based on the compression rates of a given media content 104 / 204 to control the sizes of first and second datasets 106 / 206 and 108 / 208 being transferred to GPU 2441344 . This follows from the fact that datasets with little animation will typically have higher compression ratios than those with more animation.

Flowchart 460 continues with transferring first differential dataset 207 to GPU memory 246 (action 466 ). It is noted that first differential dataset 207 contains data included in second dataset 108 / 208 but omitted from first dataset 106 / 206 . Thus, transfer of first differential dataset 207 to GPU memory 246 assures that the contents of second dataset 108 / 208 are present on GPU memory 246 after the data transfer, while the bandwidth required to perform the data transfer is advantageously minimized.

In one implementation, as shown in FIG. 2 , main memory 216 of media content presentation system 210 may serve as a local media content storage for media content 104 / 204 , and may further store first differential dataset 207 . First differential dataset 207 may be transferred to GPU memory 246 from main memory 216 via data bus 248 . In some implementations, first differential dataset 207 may be determined by memory allocation software code 240 / 340 , executed by CPU 214 / 314 of media content presentation system 110 / 210 / 310 . However, in other implementations, first differential dataset 207 may be predetermined through offline analysis of the range of locations and timecodes relevant to the presentation of media content 104 / 204 . First differential dataset 207 may be transferred to GPU memory 246 by memory allocation software code 240 / 340 , executed by CPU 214 / 314 .

Flowchart 460 continues with continuing the seamless presentation of media content 104 / 204 to system user 124 by GPU 244 / 344 utilizing at least first differential dataset 207 (action 467 ). It is noted that, in implementations in which second dataset 108 / 208 is entirely different from first dataset 106 / 206 , i.e., first differential dataset 207 is substantially equal to second dataset 1081208 , the continued seamless presentation of media content 104 / 204 to system user 124 may be performed using first differential dataset 207 alone. However, in implementations in which there is data overlap between first dataset 106 / 206 and second dataset 108 / 208 , the continued seamless presentation of media content 104 / 204 to system user 124 may be performed using first differential dataset 207 and data common to first dataset 106 / 206 and second dataset 108 / 208 .

It is further noted that the continued seamless presentation of media content 104 / 204 is enabled by the determination and transfer of first differential dataset 207 into GPU memory 246 before second dataset 108 / 208 is required for rendering media content 104 / 204 . The continued seamless presentation of media content 104 / 204 to system user 124 by GPU 244 / 344 utilizing at least first differential dataset 207 may occur under the control of memory allocation software code 240 / 340 , executed by CPU 214 / 314 of media content presentation system 110 / 210 / 310 .

Flowchart 460 can conclude with transferring second differential dataset 209 out of GPU memory 246 during the continued seamless presentation of media content 104 / 204 to system user 124 by GPU 244 / 344 utilizing at least first differential dataset 207 (action 468 ). Second differential dataset 209 contains data included in first dataset 106 / 206 but omitted from second dataset 1081208 . Thus, transfer of second differential dataset 209 out of GPU memory 246 assures that only the contents of second dataset 108 / 208 needed for continued seamless presentation of media content 104 / 204 are present on GPU memory 246 after the data transfer, while once again advantageously minimizing the bandwidth required to perform the data transfer.

In one implementation, transferring second differential dataset 209 out of GPU memory 246 may include transferring second differential dataset 209 to main memory 216 / 316 of media content presentation system 110 / 210 / 310 . However, in other implementations, transferring second differential dataset 209 out of GPU memory 246 may include transferring second differential dataset 209 to an internal hard drive of computing platform 212 / 312 , or to an external hard drive accessible by computing platform 212 / 312 . Second differential dataset 209 may be transferred out of GPU memory 246 during the continued seamless presentation of media content 104 / 204 to system user 124 , by memory allocation software code 240 / 340 , executed by CPU 214 / 314 of media content presentation system 110 / 210 / 310 .

Thus, the present application discloses systems and methods for performing memory allocation for seamless media content presentation. By transferring a first dataset of media content from media content storage to GPU memory, and utilizing the first dataset to begin presentation of the media content to a system user, the present solution ensures that GPU memory resources are not overwhelmed. Moreover, by identifying a second dataset of the media content based on a location of the system user, as well as the time code status of the media content when the system user is at the location, the present solution ensures that the GPU memory is provisioned with the data needed to provide the system user with a seamless media content presentation. When implemented to provide a VR experience to the system user, for example, the present solution can advantageously support an arbitrary number of viewpoints for reconstructing 3D scenes accurately and from substantially any point of view.

From the above description it is manifest that various techniques can be used for implementing the concepts described in the present application without departing from the scope of those concepts. Moreover, while the concepts have been described with specific reference to certain implementations, a person of ordinary skill in the art would recognize that changes can be made in form and detail without departing from the scope of those concepts. As such, the described implementations are to be considered in all respects as illustrative and not restrictive. It should also be understood that the present application is not limited to the particular implementations described herein, but many rearrangements, modifications, and substitutions are possible without departing from the scope of the present disclosure.