Patent Description:
Nowadays, three-dimensional (3D) content streaming devices becomes ever more important. A few of the digital transformations across our globe predict and promise solutions in which 3D visualizations are central components of the toolset of many of tomorrow's work forces. Digital Twins, Augmented, Mixed and Virtual Reality and even Virtual Assistants by design contain the need to have 3D content in high quality available on the devices.

However, many of the involved devices are mobile devices, e.g. 3D holographic viewing devices, for which reason they are constrained in their resources. they don't have as much memory, storage, bandwidth, computation performance and visual performance compared to desktops and laptops. Mobile devices are not able to interpret the same amount of 3D content as desktop/server based systems can. As 3D models are complex and may become huge, loading, processing and visualizing these models sometimes needs too much time and processing resources. In addition, different mobile devices also vary a lot in how constrained they are in their resources. Furthermore, mobile devices may not have a high-speed/low-latency connection. The connectivity of mobile devices is also not consistent due to a limited availability and a limited quality of networks. A limited quality can e.g. cause interruptions and/or disturbances due to fluctuations of a transmission speed of the connection. Hence, the user experience during processing and visualization of a 3D model can become inconvenient.

One known approach is Remote Edge/Cloud based rendering which is based on full application rendering on the server side. In this case, the client side comprises a simple pass-through application. Thus, this approach requires a high bandwidth and isn't usable in low bandwidth situations. It is also highly sensitive for latency. A high latency or a fluctuating latency could become devastating for the whole visualization. Another known solution is Quad/Octree/Tile based Level of Detail (LOD) sending. In this case the full application rendering is performed on the client side while segments of content to be streamed and information about a LOD of the segments are stored on the server side before they are sent to the client side. As a segmented LOD still can involve switching out complete models, this approach is not granular/adaptive enough to optimize for the available bandwidth, computation performance and memory/storage of resource constrained devices.

The prior art <CIT> presents a Dynamic Adaptive Streaming over HTTP (DASH) scenario wherein the content streaming server receives an indication associated with an intended behaviour of a playback device, such as statistics on users' viewing behaviour, a viewing direction or the most probable viewing direction (MPVD), so that the server can adjust the content to be served via a manifest file more accurately.

Preparative 3D model transcoding involves the creation of different 3D datasets optimized for each device or family of devices. However, it is still impossible to have superior quality for all object levels (i.e. the whole car and a specific screw in the engine). Also, the data still needs to be sent to the consuming device completely before visualization can start. Animations and interactions change the requirements for 3D content, which transcoding is unable to consider.

Hybrid transcoding for adaptive transmission of 3D content is characterized by client-side preselection of modalities that should be prioritized. As most of the decision making is done on the client side, scalable server-side components are not exhausted.

Progressively Ordered Primitive Buffer streaming is a method to stream 3D content to web browsers based on an improvement of the content whenever new information arrives. This method is mostly object oriented and therefore less suited for streaming big models like environments or maps. Also, it does not take into account client-side, server-side and connection metrics whilst streaming.

There is a need for new concepts that enables applications to visualize 3D models even on small devices quick enough in an efficient manner.

It is an objective of the present invention to provide an improved system and an improved method for streaming 3D content. This objective is solved by a system for streaming content and a method for streaming content according to the independent claims, respectively. Advantageous embodiments are characterized by dependent claims.

A system for streaming content comprises a streaming server and a viewing device. The streaming server comprises a generation module, a decision module, a client state manager and a telemetry aggregation cache. The viewing device comprises an engine and an acquisition module. The generation module is designed to generate models of imported content. The decision module is designed to generate model updates. The streaming server is designed to transmit the model updates to the viewing device. The client state manager is designed to store a client state containing information about previously transmitted model updates. The acquisition module is designed to acquire client metrics containing viewing device specific information and to continuously transmit the client metrics to the telemetry aggregation cache. The decision module is designed to generate the model updates based on the models client metrics and the client state. The engine is designed to visualize the content based on the model updates.

By taking the relevant decisions on the decision making module of the streaming server the relevant algorithms do no longer need to run on the viewing device, advantageously. Instead a high computing performance is available on the streaming server. Thus, a resource pressure is removed from the constrained viewing devices like mobile devices. The system enables the usage of all content types, e.g. huge objects comprising a high quality or e.g. detailed maps. Especially, the system enables streaming of 3D content. Also, all types of viewing devices can be used to stream the content.

As the streaming server is able to scale almost indefinitely in resources (ram/compute/storage) and isn't restricted by a mobile operating system, it can be much easier to prepare the content for the viewing device, to implement new features and to optimize existing features. The system may also comprise a plurality of viewing devices. Having the models on the streaming server advantageously allows shared viewing of dynamic content and shared editing of content.

As the system can take client metrics into account when generating the model updates, the system allows to adaptively stream content, e.g. according to viewing device specific limitations. The system is designed to conditionally transfer and visualize only the part of the content which is required at a given moment according to client metrics instead of being designed to load the content and to store the whole model before starting processing. Different parts of the content may also be prepared such that they comprise different quality levels.

In an embodiment the acquisition module is designed to acquire client metrics containing information about available resources of the viewing device. In order to make optimal usage of available device resources like CPU, (video) memory and storage, the system is able to adapt the visualization according to these resources. The client metrics are acquired and taken into account in the generation of the model updates. Advantageously, the system is able to scale according to available resources of the viewing device <NUM> and change the quality/quantity of visualization by generating appropriate model updates when only limited resources are available.

Thus, the system can adapt for a specific situation. Advantageously, this enables the best quality of 3D content on mobile devices with limited resources. If the system <NUM> comprises a plurality of viewing devices <NUM>, the system <NUM> can adopt the quality/quantity, depending on resources of the different viewing devices <NUM>.

The system is designed to use client side resources as optimal as possible and introduces optimizations enabled by scaling the streaming of server-side content and/or models. These two factors combined can facilitate an unthrottled client-side content performance.

In an embodiment the acquisition module is designed to acquire metrics containing information about a connectivity of the viewing device. Advantageously, a size and a complexity of the model updates may be adapted to the connectivity, as the system is aware of device connectivity like bandwidth and latency. Thus, the system can be operated in low-bandwidth and in high-latency situations. If e.g. interruptions occur or the bandwidth gets throttled the visualization of the content can be still active. If the connection to the streaming server would be severed the visualization can still continue. However, it won't be changed/improved anymore but the (3D) rendering can continue. The system is also able to scale according to a connectivity and e.g. pause/reduce the quality when not enough bandwidth is available. Thus, the best (3D) content is available for a specific connection situation of mobile devices with limited connectivity.

Furthermore, the content can be visualized immediately and constantly without first transferring a lot of data. This can be realized by starting a stream with low-quality and/or only parts of the available content. Viewing can start immediately without requiring to load the full model first. The system enables a balance between (3D) visualization quality and quantity on constrained mobile devices. By optimizing the (3D) content for each device/connectivity setup individually and constantly the system makes it possible to visualize content without the usual problems/lags in visualization.

In an embodiment the acquisition module is designed to acquire client metrics containing information about a pose, a movement and a view frustum of the viewing device. The pose consists of a position and rotation of the viewing device. Advantageously, the content may be visualized according to motion profile of a user of the viewing device. Thus, a user may e.g. move around a 3D object and look at it from different perspectives and/or distances.

According to the invention, the viewing device comprises a protocol interpreter designed to provide instructions according to the model updates for a mesh updater of the viewing device. The mesh updater is designed to update a mesh of content to be visualized according to the instructions.

In an embodiment the mesh updater is designed to translate a transport protocol specific format of the updated mesh into an engine specific mesh. The viewing device comprises a storage designed to store and load the engine specific mesh. The engine is designed to visualize the content based on the engine specific mesh. Advantageously, the updated mesh can be adapted and optimized with respect to characteristics of the viewing device.

In an embodiment the streaming server comprises a queue module designed to queue model updates before they are transmitted to the viewing device. As client and network conditions change the streaming server locally queues model updates before they are sent to the viewing device. Sending the model updates to the viewing device can be performed asynchronously. If the decision module decides - based on the metrics and client state - that model updates should not be send anymore, they get removed from the queue and/or replaced by further model updates.

The queueing module does not introduce much latency but ensures that in case of changes the data that should be transmitted to the viewing device can be altered as dynamic as possible.

In an embodiment the generator module is designed to modify the models according to external model conditions provided by an interaction module of the streaming server. The decision module is designed to consider the modified models when generating the model updates. The External model conditions may e.g. comprise information about a transformation of at least one object to be visualized.

In an embodiment the viewing device comprises a cache provided for storing model updates. Advantageously, an upcoming visualization may be prepared by storing model updates. Also, this allows for disconnected viewing by intelligently parsing the content and corresponding metadata without any interaction with the streaming server. Furthermore, reapplication of content for a multitude of use cases is possible without a complex preprocessing workflow and/or manual labor.

A method for streaming content comprises the following steps. A content is loaded on a streaming server. Models of the content are generated. Model updates are generated based on the models. The model updates are transmitted to a viewing device. The content is visualized according to the model updates. Generating the model updates is based on acquired client metrics containing viewing device specific information and a client state containing information about previously transmitted model updates.

In an embodiment model updates contain information about a change of quantity and quality of the content according to the client metrics. Advantageously, the quantity and quality is adapted to available client-side resources and the connectivity of the viewing device.

In an embodiment the model updates are queued before being transmitted to the viewing device. Advantageously, the system may complement, remove or change an order of queued model updates. Thus, the system can react to changing situations and adapt an upcoming visualization of the content.

In an embodiment parts of the model updates referring to a view frustum are transmitted in a prioritized manner. This kind of sequence of model updates ensures that fragments of a model that are within the view frustum are prioritized and are therefore send to the viewing device before non-frustum fragments.

In an embodiment model updates referring to parts of the content that are to be visualized in a foreground are transmitted in a prioritized manner. This may also be called occlusion-based sequencing. In this embodiment, parts that are behind a visible content get a lower priority and are therefore send later to the viewing device. As the streaming server takes into account the camera translation, rotation and view frustum it can correct the priority of fragments as long as they are queued on the streaming server and not yet send.

The net effect of this approach is that objects and/or parts of objects a viewer is looking at get prioritized and additional updates that happen at boundaries of the view frustum and/or behind an object are delayed.

The above-described properties, features and advantages of this invention and the way in which they are achieved are explained in greater detail in association with the drawings below. In a schematic illustration:.

<FIG> schematically shows elements of a system <NUM> for streaming content.

The system <NUM> comprises a streaming server <NUM> and a viewing device <NUM>. The system <NUM> may also comprise a plurality of viewing devices <NUM>. The streaming server <NUM> provides a streaming service which may be hosted on a computer, in a cloud, an edge device or any other device. The viewing device <NUM> is designed to visualize streamed content. The viewing device <NUM> may be any device, e.g. a computer <NUM> or a mobile device, e.g. a smart phone <NUM>, a tablet <NUM> or a head-mountable display <NUM> (HMD), e.g. wearable glasses e.g. with augmented reality/ virtual reality capabilities.

The streaming server <NUM> and the viewing device <NUM> are designed to exchange data with each other. A first connection <NUM> is designed to transmit data from the streaming server <NUM> to the viewing device <NUM>. A second connection <NUM> is provided for transmitting data from the viewing device <NUM> to the streaming server <NUM>.

<FIG> schematically shows components of the streaming server <NUM> and the viewing device <NUM> of the system <NUM>.

The streaming server <NUM> comprises an import module <NUM> designed to import content to be streamed and visualized. The import module <NUM> may be triggered by means of an external signal to load the content. The content may be any content, e.g. three-dimensional (3D) content. The content can be provided as point clouds or in any other formats, e.g. in a standard 3D format. The exact format of the content depends on the import module <NUM> used.

The streaming server <NUM> comprises a generating module <NUM>. The generating module <NUM> is designed to generate models of the imported content. The imported content is converted into a model that is algorithm-specific for the whole streaming process. The models can be kept in-memory. The models contain all data needed to upscale and/or downscale fragments of the content and all the algorithmic logic needed to quickly provide specific fragments to serve to the client side. Generating a model can comprise generating a Level of Detail (LOD) tree using conventional spatial layouting algorithms (i.e. quad-tree/R-tree etc.). The model is structured in a way to support the decision-making algorithms as good as possible.

The streaming server <NUM> comprises a decision module <NUM>. The decision module <NUM> is designed to generate model updates. The streaming server <NUM> is designed to transmit the model updates to the viewing device <NUM>. The streaming server <NUM> and the viewing device <NUM> are connected with each other by the first connection <NUM>, which can be e.g. based on a guaranteed protocol, e.g. the first connection <NUM> can be a Transmission Control Protocol (TCP) based connection.

Before transmitting model updates to the viewing device <NUM>, the model updates may be queued locally. For this, the streaming server <NUM> comprises a queue module <NUM> designed to queue model updates before they are transmitted to the viewing device <NUM>. The queue module <NUM> allows removal of model updates from the queue and/or replaced them by further model updates. The queue module <NUM> may be omitted.

To make it possible for the system <NUM> to decide which model updates need to be send, the system <NUM> needs to know what data was already sent. For this, the streaming server <NUM> comprises a client state manager <NUM> designed to store a client state containing information about previously transmitted model updates. Thus, the decision module <NUM> can generate model updates according to the client state. The system <NUM> maintains unique identifiers of different parts of a model and its quality that the streaming server <NUM> has already sent. This reflects the client state which is read and updated by the client state manager <NUM>.

The viewing device <NUM> comprises an engine <NUM> designed to visualize the content based on the model updates. Furthermore, the viewing device <NUM> comprises an acquisition module <NUM> designed to acquire client metrics containing viewing device specific information. Each client metric consists of a timestamp and a value. The acquisition module <NUM> is also designed to continuously transmit the client metrics to a telemetry aggregation cache <NUM> of the streaming server <NUM> via the second connection <NUM> if the decision module <NUM> is requesting client metrics. Thus, the client metrics can be provided to the decision module <NUM>. The second connection <NUM> can transmit client metrics without a guaranteed delivery, e.g. the second connection <NUM> may be a User Datagram Protocol (UDP) based connection. The second connection <NUM> can transmit client metrics at a dynamic interval and in a very compact form. This can reduce a bandwidth pressure. The acquisition module <NUM> is also designed to decide which client metric is important and therefore has to be send to the telemetry aggregation cache <NUM>. The telemetry aggregation cache <NUM> is designed to keep at least a latest version of the client metrics.

The acquisition module <NUM> may be designed to acquire client metrics containing information about available resources of the viewing device <NUM>, like e.g. CPU, (video) memory and storage. The decision module <NUM> continuously runs an algorithm that considers the client metrics and decides for which part of a model a specific quality representation should be transmitted. As the decision module <NUM> is designed to generate the model updates based on the client metrics, the system <NUM> is able to adapt the visualization to a viewing device <NUM> which comprises limited available resources. This enables the best quality (3D) content possible on mobile devices with limited resources.

The acquisition module <NUM> may also be designed to acquire client metrics containing information about a connectivity of the viewing device <NUM>. As the decision module <NUM> is designed to generate the model updates based on the client metrics, the system <NUM> can be operated in low-bandwidth and in high-latency situations. This enables the best quality (3D) content possible on mobile devices with limited connectivity.

The acquisition module <NUM> may also be designed to acquire client metrics containing information about a pose, a movement and a view frustum of the viewing device <NUM>. A pose consists of a position and a rotation of the viewing device. This e.g. allows to consider a motion of a user of the viewing device <NUM> when visualizing objects. Thus, the user can look at objects from different locations.

The acquisition of the client metrics can be performed on a low-priority background thread continuously. The transmission of client metrics can be performed in temporal distances which can be changed when resources or connectivity become more critical. , an interval between the transmissions of client metrics to the telemetry aggregation cache <NUM> can be increased if enough resources are available and the connectivity is good, whilst when resources become scarce or the connectivity bad, the interval can be decreases.

The streaming server <NUM> may also comprise an interaction module <NUM>. The generation module <NUM> is designed to modify the models according to external model conditions provided by the interaction module <NUM>. In this case, the decision module <NUM> is designed to consider the modified models when generating the model updates, too. The External model conditions may e.g. comprise information about a transformation of at least one object to be visualized by the system. The transformation of at least one object can e.g. contain information about a movement and/or a rotation and/or a scaling of the object. The external model conditions may also contain predictions of the behavior of the transformation of the at least one object. Further external model conditions may be e.g., comprise information about a visibility of at least one object and/or colors of the object. The interaction module <NUM> can be omitted.

The viewing device <NUM> furthermore comprises a protocol interpreter <NUM> and a mesh updater <NUM>. The protocol interpreter <NUM> is designed to provide instructions according to the model updates for the mesh updater <NUM>. The mesh updater <NUM> is designed to update a mesh of content to be visualized according to the instructions.

The mesh updater <NUM> can be designed to translate a transmission protocol specific format of the updated mesh into an engine specific mesh. The viewing device <NUM> also comprises a storage <NUM> designed to store and load the engine specific mesh. In this case, the engine <NUM> is designed to visualize the content based on the engine specific mesh. Depending on hardware, operating system and/or software runtime, the engine <NUM> will comprise different internal mechanisms and structures to store and visualize meshes. The aim is that the mesh is an as good fit as possible for the viewing device <NUM> it is visualized on. Therefore, the storage <NUM> stores the engine specific mesh by adapting the mesh such that it is compatible with the internal mechanisms and structures of the engine <NUM>. the updated mesh may be stored such that it is adapted to a viewing device <NUM> using e.g. OpenGL or Direct3D. These two platforms have different internal mechanisms and structures to store and display meshes. The storage <NUM> can be designed to store the engine specific mesh in-memory. The mesh adapter <NUM> may be omitted.

The viewing device <NUM> may comprise another optional component which is a cache <NUM> provided for storing transmitted model updates or instructions based on the model updates. This allows for disconnected viewing without any interaction with the streaming server <NUM>. The system <NUM> of <FIG> is designed such that the cache <NUM> can obtain instructions according to the model updates from the protocol interpreter <NUM> and provide them to the mesh updater <NUM>. However, the cache <NUM> can obtain transmitted model updates directly from the streaming server <NUM> and provide them to the protocol interpreter <NUM>. The cache <NUM> may also be omitted.

<FIG> schematically shows method steps <NUM>, <NUM>, <NUM>, <NUM>, <NUM> of a method <NUM> for streaming content. The method <NUM> can be performed by using the system <NUM> of <FIG> and <FIG>. Therefore, the reference numerals of <FIG> and <FIG> are used in the description below.

In a first method step <NUM> the content is loaded on the streaming server <NUM>. In a second method step <NUM> models of the content are generated. In a third method step <NUM> model updates are generated. In a fourth method step <NUM> the model updates are transmitted to a viewing device <NUM>. In a fifth method step <NUM> the content is visualized according to the model updates. Generating the model updates is based on the models, acquired client metrics containing viewing device specific information and the client state containing information about previously transmitted model updates. When generating the model updates external interactions can also be considered by modifying the models according to external model conditions, too.

The model updates can e.g. contain information about a change of quantity and quality of the content according to the client metrics. , if the viewing device <NUM> generates a resource pressure, i.e. that the viewing device <NUM> does not have sufficient resources like e.g. computing performance and/or memory, the model updates can contain information about how to remove parts of the content which are not visible. Alternatively or additionally, parts of the content can also be downscaled in their quality to relief resource pressure. In this case, the client state will be updated accordingly. If there is a connection pressure a quality of the model can be adapted, e.g. a model update containing information about downgrading a level of detail of visible content can be generated. Alternatively or additionally, parts of the content which are not visible can be removed due to connectivity pressure. The client state will be updated accordingly. If the model updates are queued before being transmitted to the viewing device <NUM> a model update containing information about upgrading a level of detail may be removed from the queue.

As the streaming server <NUM> of the system <NUM> of <FIG> and <FIG> is designed to transmit model updates to the viewing device <NUM> within the fourth method step <NUM> of the method <NUM> of <FIG>, visualized parts of at least one object and/or the whole object can be updated sequentially. <FIG> schematically shows an exemplary object <NUM> being visualized by the system <NUM> according to an exemplary sequence <NUM> of model updates. The object <NUM> is visualized according to nine exemplary model updates, wherein different parts of the object <NUM> are visualized such that they comprise different quality levels successively.

The system <NUM> is designed to conditionally transfer and visualize only the part of the object <NUM> which is required at a given moment. Thus, the whole object <NUM> in all its details does not have to be transferred to the viewing device <NUM> before starting the visualization. Therefore, a first update <NUM> of the object <NUM> can be a rough mesh of the complete object <NUM> like shown in <FIG>.

The sequence <NUM> of <FIG> comprises further model updates representing a simple example of adding incrementally more details to the object <NUM>. Within a second update <NUM> the level of detail of a first part of the object <NUM> is increased, while the rest of the objects <NUM> is visualized using the rough mesh of the first update <NUM>. Within a third update <NUM> the level of detail of only a second part of the object <NUM> is increased, wherein it comprises the same level of detail as the first part. The rest of the object <NUM> is visualized using the rough mesh of the first update <NUM>. In a fourth update <NUM> and in a fifth update <NUM> the level of detail of a third part and a fourth part of the object <NUM> are increased, respectively. After the fifth update <NUM>, all parts of the object <NUM> comprise the same level of detail, which is higher compared to the first update <NUM>.

In a sixth update <NUM>, a seventh update <NUM>, an eighth update <NUM> and a ninth update <NUM>, the level of detail of the first part, the second part, the third part and the fourth part of the object <NUM> is increased further, respectively. After the ninth update <NUM>, all parts of the object <NUM> comprise the same level of detail, which is higher compared to the level of detail after the fifth update <NUM>. Note, that the system <NUM> may also decide to downgrade parts of the object <NUM>, e.g. due to restricted resources of the viewing device <NUM> and/or due to a connectivity pressure.

The server can also decide to only send a fragment of the object <NUM> or only a part that the user can see, e.g. parts of the object that are in the visual frustum. <FIG> schematically shows the principle of frustum prioritized fragment sequencing. In this embodiment of the method <NUM>, only parts of the model updates referring to a view frustum <NUM> are transmitted in a prioritized manner.

This kind of sequence of model updates ensures that fragments of a model that are within the view frustum <NUM> are send to the viewing device <NUM> before non-frustum fragments. However, sending non-frustum fragments allows for a preparative transfer of model updates. They may be transmitted e.g. in moments where the visible content does not need to be improved.

However, the decision module <NUM> of the streaming server <NUM> can also decide to degrade the quality of the object <NUM> or remove parts of the object <NUM> which are no longer visible. One example is shown in <FIG>, which schematically shows the principle of occlusion prioritized fragment sequencing.

In this embodiment of the method <NUM>, model updates referring to parts of the content that are to be visualized in a foreground <NUM> are transmitted in a prioritized manner. The decision module <NUM> can decide which parts of the content need to be added based on the camera position/rotation and view frustum <NUM> and fill the queue accordingly. Fragments <NUM> that are behind visible parts of the content which are in the foreground <NUM> from a perspective of a user of the viewing device <NUM> get a lower priority and are therefore send later to the viewing device <NUM>. As the streaming server <NUM> can take into account the translation and the rotation of the viewing device <NUM> and the view frustum <NUM> it can correct the priority of fragments as long as they are queued on the streaming server <NUM> and not sent, yet.

As explained above, quality degradation may also be triggered by restricted resources of the viewing device and/or a connectivity pressure. On the other hand, by occlusion prioritized fragment sequencing invisible parts may be ignored until the visible parts have achieved sufficient quality on the viewing device <NUM> and there is still memory available to start transferring the occluded parts.

Claim 1:
A system (<NUM>) for streaming content
comprising a streaming server (<NUM>) and a viewing device (<NUM>), wherein the streaming server (<NUM>) comprises a generation module (<NUM>), a decision module (<NUM>), a client state manager (<NUM>) and a telemetry aggregation cache (<NUM>),
wherein the viewing device (<NUM>) comprises an engine (<NUM>) and an acquisition module (<NUM>),
wherein the generation module (<NUM>) is designed to generate models of imported content,
wherein the decision module (<NUM>) is designed to generate model updates,
wherein the streaming server (<NUM>) is designed to transmit the model updates to the viewing device (<NUM>),
wherein the client state manager (<NUM>) is designed to store a client state containing information about previously transmitted model updates,
wherein the acquisition module (<NUM>) is designed to acquire client metrics containing viewing device specific information and to continuously transmit the client metrics to the telemetry aggregation cache (<NUM>),
wherein the decision module (<NUM>) is further designed to generate the model updates based on the models, the client metrics and the client state,
wherein the engine (<NUM>) is designed to visualize the content based on the model updates
wherein the viewing device (<NUM>) further comprises a protocol interpreter(<NUM>)designed to provide instructions according to the model updates for a mesh updater (<NUM>) of the viewing device (<NUM>),
wherein the mesh updater (<NUM>) is designed to update a mesh of content to be visualized according to the instructions.