Merge MMSYS 16

This commit is contained in:
2019-08-28 11:39:20 +02:00
parent b59a5b394b
commit 2370d41471
22 changed files with 22586 additions and 86 deletions

View File

@@ -30,7 +30,7 @@ Indeed, geometry segments have close to a similar number of faces; their size is
For texture segments, the size is usually much smaller than the geometry segments but also varies a lot, as between two successive resolutions the number of pixels is divided by 4.
Finally, for each texture segment $s^{T}$, the MPD stores the \textit{MSE} (mean square error) of the image and resolution, relative to the highest resolution (by default, triangles are filled with its average color).
Offline parameters are stored in the MPD as shown in Listing 1\todo{fix reference}.
Offline parameters are stored in the MPD as shown in Listing~\ref{listing:MPD}.
\subsubsection{Online parameters}
In addition to the offline parameters stored in the MPD file for each segment, view-dependent parameters are computed at navigation time.
@@ -84,7 +84,7 @@ Algorithm~\ref{algorithm:nextsegment} details how our DASH client makes decision
\begin{algorithm}
\begin{algorithm}[th]
\SetKwInOut{Input}{input}
\SetKwInOut{Output}{output}
\Input{Current index $i$, time $t_i$, viewpoint $v(t_i)$, buffer of already downloaded \texttt{segments} $\mathcal{B}_i$, MPD}

View File

@@ -30,7 +30,7 @@ We consider a face to be large if its area in 3D is more than $a+3\sigma$, where
In our example, it selects the 5 largest faces that represent $15\%$ of the total face area.
We thus obtain a decomposition of the NVE into adaptation sets that partitions the geometry of the scene into a small adaptation set containing the larger faces of the model, and smaller adaptation sets containing the remaining faces.
We store the spatial location of each adaptation set, characterized by the coordinates of its bounding box, in the MPD file as the supplementary property of the adaptation set in the form of ``\textit{$x_{\min}$, width, $y_{\min}$, height, $z_{\min}$, depth}'' (as shown in Listing 1).
We store the spatial location of each adaptation set, characterized by the coordinates of its bounding box, in the MPD file as the supplementary property of the adaptation set in the form of ``\textit{$x_{\min}$, width, $y_{\min}$, height, $z_{\min}$, depth}'' (as shown in Listing~\ref{listing:MPD}).
This information is used by the client to implement a view-dependent streaming (Section~\ref{sec:dashclientspec}).
\subsubsection{Texture Management}
@@ -57,15 +57,13 @@ For an adaptation set containing texture, each representation contains a single
In our example, from the full-size image, we generate successive resolutions by dividing both height and width by 2, stopping when the image size is less or equal to $64\times 64$.
Figure~\ref{fig:textures} illustrates the use of the textures against the rendering using a single, average color per face.
\begin{figure}
\begin{figure}[th]
\centering
\begin{subfigure}[b]{\textwidth}
\begin{subfigure}[b]{0.45\textwidth}
\includegraphics[width=1\textwidth]{assets/dash-3d/average-color/full-res.png}
\caption{With full resolution textures}
\vspace{0.3cm}
\end{subfigure}
\begin{subfigure}[b]{\textwidth}
\begin{subfigure}[b]{0.45\textwidth}
\includegraphics[width=1\textwidth]{assets/dash-3d/average-color/no-res.png}
\caption{With average colors}
\end{subfigure}
@@ -80,11 +78,11 @@ Thus, the first segment contains the biggest faces and the last one the smallest
In addition to the selected faces, a segment stores all face vertices and attributes so that each segment is independent.
For textures, each representation contains a single segment.
\begin{figure}
\begin{figure}[th]
\lstinputlisting[%
language=XML,
caption={MPD description of a geometry adaptation set, and a texture adaptation set.},
label=geometry-as-example,
label=listing:MPD,
emph={%
MPD,
Period,
@@ -99,6 +97,6 @@ For textures, each representation contains a single segment.
SegmentURL,
Viewpoint
}
]{assets/dash-3d/geometry-as.xml}\label{listing:MPD}
]{assets/dash-3d/geometry-as.xml}
\end{figure}

View File

@@ -11,9 +11,10 @@ The converted model has 387,551 vertices and 552,118 faces.
Table~\ref{table:size} gives some general information about the model.
We partition the geometry into a k-$d$ tree until the leafs have less than 10000 faces, which gives us 64 adaptation sets, plus one containing the large faces.
\begin{table}
\begin{table}[th]
\centering
\begin{tabular}{ll}
\toprule
\textbf{Files} & \textbf{Size} \\ \midrule
3DS Max & 55 MB \\
OBJ file & 62 MB\\
@@ -67,7 +68,7 @@ The second streaming policy that we run is the one we proposed in equation (\ref
We have also analyzed the effect of grouping the faces in geometry segments of an adaptation set based on their 3D area.
Finally, we try several bandwidth parameters to study how our system can adapt to varying network conditions.
\begin{table}
\begin{table}[th]
\centering
\begin{tabular}{@{}ll@{}}
\toprule
@@ -82,7 +83,7 @@ Finally, we try several bandwidth parameters to study how our system can adapt t
\end{table}
\subsection{Experimental Results}
\begin{figure}
\begin{figure}[th]
\centering
\begin{tikzpicture}
\begin{axis}[
@@ -113,7 +114,7 @@ The octree partitions content into non-homogeneous adaptation sets; as a result,
Figure~\ref{fig:preparation} shows that the system seems to be slightly less efficient with an Octree than with a $k$-d tree based partition, but this result is not significant.
For the remaining experiments, partitioning is based on a $k$-d tree.
\begin{figure}
\begin{figure}[th]
\centering
\begin{tikzpicture}
\begin{axis}[
@@ -137,7 +138,7 @@ For the remaining experiments, partitioning is based on a $k$-d tree.
\addlegendentry{\scriptsize Offline only}
\end{axis}
\end{tikzpicture}
\caption{Impact of the segment utility metric on the rendering qualit with a 5Mbps bandwidth.\label{fig:utility}}
\caption{Impact of the segment utility metric on the rendering quality with a 5Mbps bandwidth.\label{fig:utility}}
\end{figure}
Figure~\ref{fig:utility} displays how a utility metric should take advantage of both offline and online features.
@@ -145,7 +146,7 @@ The experiments consider $k$-d tree cell for adaptation sets and the proposed st
We observe that a purely offline utility metric leads to poor PSNR results.
An online-only utility improves the results, as it takes the user viewing frustum into consideration, but still, the proposed utility (in Section~\ref{subsec:utility}) performs better.
\begin{figure}
\begin{figure}[th]
\centering
\begin{tikzpicture}
\begin{axis}[
@@ -185,7 +186,7 @@ In contrast, our proposed streaming policy adapts to an increasing bandwidth by
In fact, an interesting feature of our proposed streaming policy is that it adapts the geometry-texture compromise to the bandwidth. The textures represent 57.3\% of the total amount of downloaded bytes at 2.5 Mbps, and 70.2\% at 10 Mbps.
In other words, our system tends to favor geometry segments when the bandwidth is low, and favor texture segments when the bandwidth increases.
\begin{figure}
\begin{figure}[th]
\centering
\begin{tikzpicture}
\begin{axis}[
@@ -210,7 +211,7 @@ In other words, our system tends to favor geometry segments when the bandwidth i
\caption{Impact of the streaming policy (greedy vs.\ proposed) with a 5 Mbps bandwidth.}\label{fig:greedyweakness}
\end{figure}
\begin{table}
\begin{table}[th]
\centering
\begin{tabular}{@{}p{2.5cm}p{0.7cm}p{0.7cm}p{0.7cm}p{0.3cm}p{0.7cm}p{0.7cm}p{0.7cm}@{}}
\toprule
@@ -225,12 +226,13 @@ In other words, our system tends to favor geometry segments when the bandwidth i
\caption{Average PSNR, Greedy vs. Proposed\label{table:greedyVsproposed}}
\end{table}
\begin{table}
\begin{table}[th]
\centering
\renewcommand{\arraystretch}{1.2}
\begin{tabular}{@{}cccc@{}}
\textbf{Resolutions} & \textbf{2.5 Mbps} & \textbf{5 Mbps} & \textbf{10 Mbps} \\
\toprule
\textbf{Resolutions} & \textbf{2.5 Mbps} & \textbf{5 Mbps} & \textbf{10 Mbps} \\
\midrule
1 & 5.7\% vs 1.4\% & 6.3\% vs 1.4\% & 6.17\% vs 1.4\% \\
2 & 10.9\% vs 8.6\% & 13.3\% vs 7.8\% & 14.0\% vs 8.3\%\\
3 & 15.3\% vs 28.6\% & 20.1\% vs 24.3\% & 20.9\% vs 22.5\% \\