This commit is contained in:
Thomas Forgione 2020-02-06 10:46:57 +01:00
parent 9d003d4544
commit 4b461b7a8d
3 changed files with 32 additions and 22 deletions

View File

@ -495,6 +495,14 @@
howpublished = {\url{https://insights.stackoverflow.com/survey/2019#technology-most-loved-dreaded-and-wanted}}
}
@misc{3d-tiles-10x,
name = "3D Tiles Blog",
title = {Up to 10x Faster 3D Tiles Streaming},
year = {2019},
author = {},
howpublished = {\url{https://cesium.com/blog/2019/05/07/faster-3d-tiles/}}
}
@inproceedings{urban-data-visualisation,
author = {Gaillard, J{\'e}r{\'e}my and Vienne, Alexandre and Baume, R{\'e}mi and Pedrinis, Fr{\'e}d{\'e}ric and Peytavie, Adrien and Gesqui\`{e}re, Gilles},
title = {Urban Data Visualisation in a Web Browser},
@ -928,10 +936,3 @@
year={2003}
}
@inproceedings{3d-tiles-2,
title={Using glTF for streaming CityGML 3D city models},
author={Schilling, Arne and Bolling, Jannes and Nagel, Claus},
booktitle={Proceedings of the 21st International Conference on Web3D Technology},
pages={109--116},
year={2016}
}

View File

@ -184,18 +184,7 @@ For example, \citep{game-on-demand} proposes an online game engine based on geom
\subsection{NVE streaming frameworks}
\citep{zampoglou} is the first paper that proposes to use DASH to stream 3D content.
In their work, the authors describe a system that allows users to access 3D content at multiple resolutions.
They organize the content, following DASH terminology, into periods, adaptation sets, representations.
Their first adaptation set codes the tree structure of the scene graph.
Each further adaptation set contains both geometry and texture information and is available at different resolutions defined in a corresponding representation.
To avoid requests that would take too long and thus introduce latency, the representations are split into segments.
The authors discuss the optimal number of polygons that should be stored in a single segment.
On the one hand, using segments containing very few faces will induce many HTTP requests from the client, and will lead to poor streaming efficiency.
On the other hand, if segments contain too many faces, the time to load the segment will be long and the system loses adaptability.
Their approach works well for several objects, but does not handle view-dependent streaming, which is desirable in the use case of large NVEs\@.
Another example of NVE streaming framework is 3D Tiles \citep{3d-tiles,3d-tiles-2}, which is a specification for visualizing massive 3D geospatial data developed by Cesium and built on top of glTF\@.
An example of NVE streaming framework is 3D Tiles \citep{3d-tiles}, which is a specification for visualizing massive 3D geospatial data developed by Cesium and built on top of glTF\@.
Their main goal is to display 3D objects on top of regular maps, and their visualisation consists in a top-down view, whereas we seek to let users freely navigate in our scenes, whether it be flying over the scene or moving along the roads.
\begin{figure}[ht]
@ -220,6 +209,19 @@ It started with a regular octree, but has then been improved to a $k$-d tree (se
\caption{Spatial partitionning used in 3D Tiles\label{sote:3d-tiles-partition}}
\end{figure}
In~\citeyear{3d-tiles-10x}, 3D Tiles streaming system was improved by preloading the data at the camera's next position when known in advance (with ideas that are similar to those we discuss and implement in Chapter~\ref{bi}, published in~\citeyear{bookmarks-impact}) and by ordering tile requests depending on the user's position (with ideas that are similar to those we discuss and implement in Chapter~\ref{d3}, published in~\citeyear{dash-3d}).
\citep{zampoglou} is another example of a streaming framework: it is the first paper that proposes to use DASH to stream 3D content.
In their work, the authors describe a system that allows users to access 3D content at multiple resolutions.
They organize the content, following DASH terminology, into periods, adaptation sets, representations.
Their first adaptation set codes the tree structure of the scene graph.
Each further adaptation set contains both geometry and texture information and is available at different resolutions defined in a corresponding representation.
To avoid requests that would take too long and thus introduce latency, the representations are split into segments.
The authors discuss the optimal number of polygons that should be stored in a single segment.
On the one hand, using segments containing very few faces will induce many HTTP requests from the client, and will lead to poor streaming efficiency.
On the other hand, if segments contain too many faces, the time to load the segment will be long and the system loses adaptability.
Their approach works well for several objects, but does not handle view-dependent streaming, which is desirable in the use case of large NVEs\@.
% \subsection{Prefetching in NVE}
% The general prefetching problem can be described as follows: what are the data most likely to be accessed by the user in the near future, and in what order do we download the data?
%

View File

@ -1,9 +1,16 @@
\section{Video\label{sote:vide}}
Accessing a remote video through the Web has been a widely studied problem since the 1990s. The Real-time Transport Protocol (RTP,~\cite{rtp-std}) has been an early attempt
to formalize audio and video streaming. The protocol allowed data to be transferred unilaterally from a server to a client, and required the server to handle a separate session for each client. While this protocol can be useful in particular scenarii, such as video-conferencing, it can not realistically scale to modern video streaming platforms such as Youtube or Netflix, which must serve millions of simultaneous clients.
Accessing a remote video through the Web has been a widely studied problem since the 1990s.
The Real-time Transport Protocol (RTP,~\cite{rtp-std}) has been an early attempt to formalize audio and video streaming.
The protocol allowed data to be transferred unilaterally from a server to a client, and required the server to handle a separate session for each client.
% While this protocol can be useful in particular scenarii, such as video-conferencing, it suffers from several is a stateful protocol: the server keeps track of every user along the streaming session.
Because of this limitation, and while the increasing network capabilities made video streaming a more and more common practice, a new trend emerged during the 2000s. Building on the democratization of HTTP servers, many industrial actors (Apple, Microsoft, Adobe, etc.) developed HTTP streaming systems to deliver multimedia content over the network. In an effort to bring interoperability between all different actors, the MPEG group launched an initiative, which eventually became a standard known as DASH, Dynamic Adaptive Streaming over HTTP\@.
In the following years, HTTP servers have become ubiquitous, and many industrial actors (Apple, Microsoft, Adobe, etc.) developed HTTP streaming systems to deliver multimedia content over the network.
In an effort to bring interoperability between all different actors, the MPEG group launched an initiative, which eventually became a standard known as DASH, Dynamic Adaptive Streaming over HTTP\@.
Using HTTP for multimedia streaming has many advantages over RTP\@.
While RTP is stateful (that is to say, it requires keeping track of every user along the streaming session), HTTP is stateless, and thus more efficient.
Furthermore, an HTTP server can easily be replicated at different geographical locations, allowing users to fetch data from the closest server.
This type of network architecture is called CDN (Content Delivery Network) and increases the speed of HTTP requests, making HTTP based multimedia streaming more efficient.
\subsection{DASH\@: the standard for video streaming\label{sote:dash}}