19 lines
2.5 KiB
XML
19 lines
2.5 KiB
XML
== Conclusion<d3:conclusion>
|
|
|
|
Our work in this chapter started with the question: can DASH be used for NVE\@?
|
|
The answer is _yes_.
|
|
In answering this question, we contributed by showing how to organize a polygon soup and its textures into a DASH-compliant format that (i) includes a minimal amount of metadata that is useful for the client, (ii) organizes the data to allow the client to get the most useful content first.
|
|
We further show that the data organization and its description with metadata (precomputed offline) is sufficient to design and build a DASH client that is adaptive --- it selectively downloads segments within its view, makes intelligent decisions about what to download, balances between geometry and texture while adapting to network bandwidth.
|
|
This way, our system addresses the open problems we mentioned in @i:challenges.
|
|
|
|
- *It prepares and structures the content in a way that enables streaming*: all this preparation is precomputed, and all the content is structured according to DASH framework, geometry but also materials and textures. Furthermore, textures are prepared in a multi-resolution manner, and even though multi-resolution geometry is not discussed here, the difficulty of integrating it in this system seem moderated: we could encode levels of detail in different representations and define a utility metric for each representation and the system should adapt naturally.
|
|
- *We are able to estimate the utility of each segment* by exploiting all the metadata given in the MPD and by analysing the camera parameters of the user.
|
|
- *We proposed a few streaming policies*, from the easiest to implement to the more complex, so that the client exploits the utility metrics to define a best guess for the next chunk to download.
|
|
- *The implementation is efficient*: the content preparation allows a client to get all the information it needs from metadata and the server has nothing else to do than to serve files. Special attention has been granted to the client's performance.
|
|
|
|
However, the work described in this chapter does not take any quality of experience metrics into account.
|
|
We designed a 3D streaming system, but we kept the interaction system the simplest possible.
|
|
Dealing with interaction while dealing with all of the other problems we try to solve seems hard, and we believe keeping the interaction simple was a necessary step to build a solid 3D streaming system.
|
|
Now that we have this system, we are able to work again on the interaction problem and our work and conclusions are given in Chapter~\ref{sb}.
|
|
|