Adds french part and ugly cover
This commit is contained in:
parent
6794ee1db9
commit
8a78c1a982
Binary file not shown.
|
|
@ -28,7 +28,7 @@ anchorcolor = blue]{hyperref}
|
|||
\usepackage{setspace}
|
||||
\onehalfspacing{}
|
||||
\usepackage{numprint}
|
||||
|
||||
\usepackage{pdfpages}
|
||||
\usepackage{enumitem}
|
||||
\setitemize{noitemsep,topsep=4pt,parsep=4pt,partopsep=0pt}
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,94 @@
|
|||
\section{Client DASH 3D}\label{fr:dashclientspec}
|
||||
Dans cette section, nous détaillons un client DASH NVE qui exploite la préparation du contenu 3D.
|
||||
|
||||
Le client DASH commence par télécharger le MPD, avant de commencer à télécharger les segments. Quand un segment arrive, le client prend la décision du prochain segment à télécharger pour l'afficher quand il arrivera.
|
||||
|
||||
Nous considérons une caméra virtuelle qui suit continuellement un chemin $C=\{v(t_i), t_i \in [t_1, t_{final}]\}$, où $t_i$ est l'instant où le segment $i$ est requêté, et au cours duquel les opportunités de téléchargement sont stratégiquement exploitées pour télécharger séquentiellement les segments les plus utiles.
|
||||
|
||||
\subsection{Utilité des Segments}\label{fr:utility}
|
||||
|
||||
Contrairement au streaming vidéo, où la taille (en octets) de chaque segment est corrélée à la qualité de la vidéo reçue, pour le contenu 3D, la taille du contenu n'est pas nécessairement corrélée à sa contribution en terme de qualité du rendu. Un grand polygone qui aura un grand impact visuel occupera à peu près autant d'octets qu'un petit polygone. De plus, l'impact visuel dépend du point de vue --- un grand polygone lointain ne contribuera pas autant qu'un petit polygone plus près de l'utilisateur. Ainsi, il est important pour un client DASH-NVE d'estimer ce que nous appelons \emph{l'utilité d'un segment}, de sorte à prendre les bonnes décisions de téléchargement.
|
||||
|
||||
L'utilité est une fonction d'un segment, qu'il soit de géométrie ou de texture, et du point de vue courant (position de la caméra et direction du regard), et est donc calculé dynamiquement par le client à partir des métadonnées du MPD\@.
|
||||
|
||||
\paragraph{Paramètres statiques}
|
||||
Dans un premier temps, nous allons détailler les paramètres calculés lors de la préparation du contenu, stockés dans le MPD\@.
|
||||
|
||||
Tout d'abord, pour chaque segment de géométrie $s_G$, nous calculons une aire $\mathcal{A}(s^G)$, égale à la somme des aires des polygones du segment.
|
||||
Ensuite, pour chaque segment de texture $s^T$, le MPD enregistre l'\emph{EQM} (erreur quadratique moyenne) entre l'image courante et l'image à la plus haute résolution disponible.
|
||||
Enfin, pour tous les segments, nous stockons la taille du fichier (en octets). En effet, les segments de géométrie ont un nombre similaire de faces, et leurs tailles sont donc à peu près les mêmes. En ce qui concerne les textures, les tailles sont généralement bien plus faibles que celles des segments de géométrie, mais sont aussi très variables, puisqu'entre deux résolutions, le nombre de pixels est multiplié par 4.
|
||||
|
||||
\paragraph{Paramètres dynamiques}
|
||||
En plus des paramètres statiques stockés dans le MPD pour chaque segment, des paramètres dépendants du point de vue sont calculés pendant la navigation. Premièrement, une mesure d'aire est calculée pour les segments de texture. Puisqu'une texture est peinte sur un ensemble de polygones, on compte pour l'aire de la texture la somme des aires de ces polygones. Nous pourrions calculer cette information de manière statique et la stocker dans le MPD, mais faire ce calcul dynamiquement nous permet de ne prendre en compte que les polygones déjà reçus par le client. Pour une texture $T$, nous notons l'ensemble des polygones peints par cette texture $\Delta(s^T) = \Delta(T)$ (qui ne dépend que de la texture $T$ et qui est donc constante pour chaque représentation de la texture). À chaque instant $t_i$, un sous ensemble de $\Delta(T)$ a été téléchargé, nous le notons $\Delta(T, t_i)$.
|
||||
|
||||
De plus, chaque segment de géométrie appartient à un \emph{adaptation set} $AS^G$ dont les coordonnées de la boîte englobante sont stockées dans le MPD\@. Étant donné la boîte englobante $\mathcal{BB}(AS^G)$ et le point de vue $v(t_i)$ à l'instant $t_i$, le client calcule la distance $\mathcal{D}(v(t_i), AS^G)$ à $\mathcal{BB}(AS^G)$ comme la distance du centre de $\mathcal{BB}(AS^G)$ au point principal de la caméra.
|
||||
|
||||
\paragraph{Utilité des segments de géométrie}
|
||||
Maintenant, nous avons tous les paramètres pour déduire une mesure d'utilité d'un segment de géométrie. L'utilité des segments de textures est déduite des utilités des segments de géométrie.
|
||||
|
||||
L'utilité d'un segment de géométrie $s^G$ pour un point de vue $v(t_i)$ est
|
||||
\begin{equation*}
|
||||
\mathcal{U} \Big(s^G,v(t_i) \Big) = \frac{\mathcal{A}(s^G)}{\mathcal{D}(v(t_i),AS^G)^2}
|
||||
\end{equation*}
|
||||
où $AS^G$ est l'\emph{adaptation set} qui contient $s^G$.
|
||||
|
||||
Concrètement, l'utilité d'un segment est proportionnelle à l'aire couverte par ce segment, et inversement proportionnelle au carré de la distance entre la caméra et la boîte englobante de son \emph{adaptation set}. De cette manière, nous favorisons les segments contenant des grandes faces, et qui sont proches de la caméra.
|
||||
|
||||
\paragraph{Utilité des segments de texture}
|
||||
Pour une texture $T$, les polygones de $\Delta(T)$ peuvent être dans plusieurs segments de géométrie. Ainsi, pour chaque segment de géométrie déjà téléchargé $s_k^G \in K$, on compte les polygones de $\Delta(T, t_i)$ dans $s^G_k$, et on calcule ainsi le ratio qu'occupe $T$ dans $\mathcal{A}(s_k^G)$. Nous définissons donc l'utilité, notée $\mathcal{U}\Big( s^T,v(t_i) \Big)$, par
|
||||
|
||||
$$psnr(s^T) \sum_{k\in K}\frac{\mathcal{A}_{3D}( s_k^G\cap \Delta(T,t_i))}{\mathcal{A}_{3D}(s_k^G)} \mathcal{U}\big( s_k^G,v(t_i) \big)$$
|
||||
|
||||
Concrètement, cette formule définit l'utilité d'un segment de texture grâce à la combinaison linéaire des utilités des segments de géométrie qui utilisent cette texture, pondérées par la proportion occupée par la texture dans le segment.
|
||||
On calcule ensuite un PSNR en utilisant l'erreur quadratique moyenne du MPD et on le note $psnr(s^T)$, de sorte à donner une utilité plus grande à des textures plus haute résolution.
|
||||
|
||||
Le client peut ainsi utiliser les utilités définies sur les segments de géométrie et de textures pour sa stratégie de chargement.
|
||||
|
||||
\subsection{Logique d'adaptation de DASH}\label{fr:dashadaptation}
|
||||
|
||||
Le long du chemin de caméra $C=\{v(t_i)\}$, les points de vue sont indexés par un intervalle de temps continu $t_i \in [t_1, t_{final}]$. Par contraste, la logique d'adaptation de DASH procède séquentiellement le long d'une suite discrète d'instants. La première requête HTTP faite par le client DASH à l'instant $t_1$ choisit le segment le plus utile $s_1^*$, qui sera suivi des décisions suivantes aux instants $t_2, t_3, \dots$. Pour choisir le segment $s_i^*$, le client doit faire un compromis entre la géométrie et les différentes résolutions de texture en tenant compte du débit, des mouvements de la caméra, et des utilités des segments. La différence entre $t_{i+1}$ et $t_i$ correspond au temps que va mettre $s_i^*$ à arriver. Cette durée peut varier en fonction de la taille du segment et des conditions du réseau. L'algorithme~\ref{fr:nextsegment} explique comment notre client DASH prend ses décisions.
|
||||
|
||||
\begin{algorithm}[th]
|
||||
\SetKwInOut{Input}{entrée}
|
||||
\SetKwInOut{Output}{sorties}
|
||||
|
||||
\SetKw{Continue}{continue}
|
||||
\SetKwData{Bw}{estimation\_bande\_passante}
|
||||
\SetKwData{Rtt}{estimation\_temps\_aller\_reotur}
|
||||
\SetKwData{Segment}{meilleur\_segment}
|
||||
\SetKwData{Candidates}{candidats}
|
||||
\SetKwData{AllSegments}{segments\_mpd}
|
||||
\SetKwData{DownloadedSegments}{segments\_telecharges}
|
||||
\SetKwData{Frustum}{frustum}
|
||||
\SetKwFunction{Argmax}{argmax}
|
||||
\SetKwFunction{Filter}{filter}
|
||||
\SetKwFunction{EstimateNetwork}{estimer\_parametres\_reseau}
|
||||
\SetKwFunction{Append}{append}
|
||||
|
||||
\Input{Indice courant $i$, instant $t_i$, point de vue $v(t_i)$, liste des segments déjà téléchargés $\mathcal{B}_i$, MPD}
|
||||
\Output{Prochain segment $s^{*}_i$ à télécharger, liste mise à jour $\mathcal{B}_{i+1}$}
|
||||
\BlankLine{}
|
||||
(\Bw, \Rtt) \leftarrow{} \EstimateNetwork{}\;
|
||||
|
||||
\BlankLine{}
|
||||
\Candidates\leftarrow{} \AllSegments\newline\makebox[1cm]{}.\Filter{$\Segment\rightarrow\Segment\notin\DownloadedSegments$}\newline\makebox[1cm]{}.\Filter{$\Segment\rightarrow\Segment\in\Frustum$}\;
|
||||
\BlankLine{}
|
||||
\Segment\leftarrow{} \Argmax{\Candidates, \Segment\rightarrow{} $\Omega\left(\mathcal{U}(\Segment)\right)$}\;
|
||||
\DownloadedSegments.\Append{\Segment}\;
|
||||
|
||||
{\caption{Sélection du prochain segment\label{fr:nextsegment}}}
|
||||
\end{algorithm}
|
||||
|
||||
La façon la plus naïve de séquentiellement optimiser $\mathcal{U}$ est de limiter la décision au point de vue courant $v(t_i)$. Dans ce cas, le meilleur segment $s$ à télécharger sera celui qui maximisera $\mathcal{U}(s, v(t_i))$ pour simplement avoir un meilleur rendu au point de vue courant $v(t_i)$. À cause des délais de transmission, ce segment n'arrivera qu'à l'instant $t_{i+1}=t_{i+1}(s)$ qui dépendra des conditions du réseau et de la taille du segment \begin{equation*} t_{i+1}(s)=t_i+\frac{\mathtt{size}(s)}{\widehat{BW_i}} + \widehat{\tau_i}\label{eq2}\end{equation*}
|
||||
|
||||
En conséquence, le segment le plus utile depuis $v(t_i)$ à l'instant $t_i$ sera peut-être moins utile au moment où il arrivera, à l'instant $t_{i+1}$.
|
||||
|
||||
Une meilleure solution est de télécharger un segment qui devrait être plus utile dans le futur. Avec un horizon temporel $\chi$, nous pouvons optimiser le cumul de $\mathcal{U}$ pendant $[t_{i+1}(s), t_i+\chi]$ :
|
||||
\begin{equation} s^*_i= \argmax{s \in \mathcal{S} \backslash \mathcal{B}_i \cap \mathcal{FC} } \int_{t_{i+1}(s)}^{t_i+\chi} \mathcal{U}(s,\hat{v}(t_i)) dt \label{fr:smart}\end{equation}
|
||||
|
||||
Nous avons aussi testé une approche gloutonne qui optimise l'utilité à l'arrivée du segment :
|
||||
\begin{equation}
|
||||
s^{\texttt{GLOUTON}}_i= \argmax{s \in \mathcal{S} \backslash \mathcal{B}_i \cap \mathcal{FC} } \frac{\mathcal{U}\left(s,\hat{v}\left(t_{i+1}(s)\right)\right)}{ t_{i+1}(s) -t_i }
|
||||
\label{fr:greedy}
|
||||
\end{equation}
|
||||
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
\section{Formatter un NVE en DASH}\label{fr:dash3d}
|
||||
|
||||
Dans cette section, nous décrivons comment nous préparons et stockons les données 3D de notre NVE dans un format qui soit compatible avec DASH\@.
|
||||
Dans nos travaux, nous utilisons le format WaveFront OBJ pour les polygones et PNG pour les textures. Cependant, le processus s'applique aussi à d'autres formats.
|
||||
|
||||
\subsection{Le MPD}
|
||||
|
||||
Dans DASH, les informations telles que les URL des fichiers, leur résolution ou leur taille sont extraites par le client grâce à un fichier appelé \emph{Media Presentation Description, MPD}. Le client ne se base que sur ces informations pour décider quel fichier télécharger et à quel niveau de résolution.
|
||||
|
||||
Le MPD est un fichier XML organisé hiérarchiquement en différentes sections.
|
||||
Les \emph{periods} sont le premier niveau, qui dans le cas de la vidéo, indiquent le début et la durée d'un chapitre. Cet élément ne s'applique pas dans le cas d'un NVE, et nous utilisons donc une seule \emph{period} qui contiendra toute la scène, puisque celle-ci est statique.
|
||||
|
||||
Chaque \emph{period} contient un ou plusieurs \emph{adaptation sets} qui décrivent des versions alternatives, formats et types de contenu. Nous utilisons les \emph{adaptation sets} pour organiser la géométrie et les textures de la scène.
|
||||
|
||||
\subsection{Adaptation Sets}
|
||||
|
||||
Quand un utilisateur navigue librement dans un NVE, le champ de vision à un moment donné ne contient qu'une partie limitée de la scène. De la même façon que DASH-vidéo partitionne une vidéo en blocs temporels, nous partitionnons les polygones en blocs spatiaux, de sorte que notre client puisse ne télécharger que les blocs nécessaires.
|
||||
|
||||
\textbf{Gestion de la géométrie.}\label{fr:geometry}
|
||||
Nous utilisons un arbre de partitionnement de l'espace pour organiser les faces en cellules.
|
||||
Une face appartient à une cellule si son barycentre est à l'intérieur de la boîte englobante correspondante.
|
||||
Chaque cellule appartient à un \emph{adaptation set}.
|
||||
Ainsi, l'information géométrique est étalée dans les \emph{adaptation sets} en fonction de leur cohérence spatiale, permettant au client de choisir les faces pertinentes à télécharger. Une cellule est pertinente si son intersection avec le champ de vision de l'utilisateur est non vide. Dans la figure~\ref{fr:bigpic}, les cellules pertinentes sont représentées en bleu.
|
||||
|
||||
Puisque notre scène 3D est principalement étalée le long d'un plan horizontal, nous séparons alternativement le modèle dans les deux directions de ce plan.
|
||||
|
||||
Nous créons un \emph{adaptation set} séparé pour les grandes faces (par exemple, le ciel ou le sol) puisqu'elles sont essentielles au modèle 3D et qu'elles ne rentrent pas dans les cellules. Nous considérons une face comme grande si son aire est supérieure à $a+3\sigma$ où $a$ et $\sigma$ sont respectivement la moyenne et l'écart-type des aires des faces. Dans notre exemple, ceci correspond aux 5 plus grandes faces, qui représentent $15\%$ de l'aire totale. Nous obtenons ainsi une décomposition du NVE en \emph{adaptation sets} qui partitionne la géométrie de la scène en un \emph{adaptation set} qui contient les faces les plus grandes, et d'autres qui contiennent les faces restantes.
|
||||
|
||||
Nous enregistrons la position de chaque \emph{adaptation set}, caractérisée par les coordonnées de sa boîte englobante, dans le MPD comme une propriété supplémentaire de l'\emph{adaptation set}, sous la forme ``\textit{$x_{min}$, largeur, $y_{min}$, hauteur, $z_{min}$, profondeur}'' (comme indiqué dans le listing 1). Ces informations sont utilisées par le client pour implémenter un streaming dépendant de la vue (Section~\ref{fr:dashclientspec}).
|
||||
|
||||
|
||||
\textbf{Gestion des textures.}
|
||||
Avec les données de géométrie, nous gérons les textures en utilisant différents \emph{adaptation sets}, indépendants de ceux de la géométrie. Chaque fichier de texture correspond à un \emph{adaptation set} différent, avec différentes \emph{representations} (voir Section~\ref{fr:representation}) qui fournissent des résolutions différentes des images. Nous ajoutons à chaque \emph{adaptation set} de texture un attribut qui décrit la couleur moyenne de la texture. Le client peut se servir de cet attribut pour dessiner une face dont la texture n'a pas encore été téléchargée avec une couleur uniforme naturelle (voir Figure~\ref{fr:textures}).
|
||||
|
||||
|
||||
\subsection{Représentations\label{fr:representation}}
|
||||
Chaque \emph{adaptation set} peut contenir une ou plusieurs \emph{representations} de la géométrie ou des textures, à différent niveaux de détail (par exemple, avec un nombre différent de faces).
|
||||
Pour la géométrie, la résolution est hétérogène, et appliquer une représentation multi-résolution est pénible : l'aire des faces varie de $0.01$ à plus de $10K$, sans tenir compte des faces extrêmes.
|
||||
Pour les scènes texturées, il est commun d'avoir des données hétérogènes puisque l'information peut être stockée soit sous forme de géométrie, soit sous forme de texture. Anisi, gérer un compromis entre géométrie et textures est plus adaptable que gérer une combinaison multi-résolution.
|
||||
Pour chaque texture, nous générons des résolutions successives en divisant par 2 la hauteur et la largeur, en s'arrêtant lorsque l'image a une taille inférieure à $64 \times 64$.
|
||||
La Figure~\ref{fr:textures} montre l'utilisation des textures comparée à l'affichage avec une seule couleur par face.
|
||||
|
||||
\begin{figure}[th]
|
||||
\centering
|
||||
\begin{subfigure}[b]{0.45\textwidth}
|
||||
\includegraphics[width=1\textwidth]{assets/dash-3d/average-color/full-res.png}
|
||||
\caption{Avec textures haute résolution}
|
||||
\end{subfigure}
|
||||
\begin{subfigure}[b]{0.45\textwidth}
|
||||
\includegraphics[width=1\textwidth]{assets/dash-3d/average-color/no-res.png}
|
||||
\caption{Avec les couleurs moyennes}
|
||||
\end{subfigure}
|
||||
\caption{Rendu du modèle avec différents styles de textures\label{fr:textures}}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Segments}
|
||||
Pour permettre l'accès aléatoire au contenu au sein d'un \emph{adaptation set} de géométrie, nous groupons les faces en \emph{segments}. Chaque \emph{segment} est ensuite encodé en un fichier OBJ, qui peut être requêté individuellement par le client. Nous partitionnons les faces d'un \emph{adaptation set} en ensembles de $N_s$ faces, en triant les faces par aires décroissantes, et en plaçant ensuite les $N_s$ faces successives dans un \emph{segment}. Ainsi, le premier \emph{segment} contient les faces les plus grandes et le dernier les faces les plus petites. Pour les textures, chaque \emph{representation} contient un \emph{segment} unique.
|
||||
|
||||
\begin{figure}
|
||||
\lstset{
|
||||
language=xml,
|
||||
tabsize=3,
|
||||
%frame=lines,
|
||||
%caption={MPD description of a geometry adaptation set, and a texture adaptation set. %\CMTGM{do we really want to show 2 representations for geometry as we argue that a single resolution/representation is a good choice ? -> Should we rather show a texture adaptation set ?}\CMTTF{Here is an interesting part of MPD, do what you think is best.} The supplemental property values are the bounding box coordinates of the adaptation set.
|
||||
caption={Description d'un \emph{adaptation set} de géométrie, et un de texture, dans le MPD\@. %\CMTGM{do we really want to show 2 representations for geometry as we argue that a single resolution/representation is a good choice ? -> Should we rather show a texture adaptation set ?}\CMTTF{Here is an interesting part of MPD, do what you think is best.} The supplemental property values are the bounding box coordinates of the adaptation set.
|
||||
},
|
||||
label=fr:geometry-as-example,
|
||||
frame=single,
|
||||
rulesepcolor=\color{gray},
|
||||
xleftmargin=0pt,
|
||||
framexleftmargin=0pt,
|
||||
keywordstyle=\color{blue}\bf,
|
||||
commentstyle=\color{OliveGreen},
|
||||
stringstyle=\color{red},
|
||||
numbers=none,
|
||||
breaklines=true,
|
||||
showstringspaces=false,
|
||||
basicstyle=\scriptsize\ttfamily,
|
||||
emph={%
|
||||
MPD,
|
||||
Period,
|
||||
AdaptationSet,
|
||||
Representation,
|
||||
BaseURL,
|
||||
SegmentBase,
|
||||
Initialization,
|
||||
Role,
|
||||
SupplementalProperty,
|
||||
SegmentList,
|
||||
SegmentURL,
|
||||
Viewpoint
|
||||
},emphstyle={\color{DarkGreen}}}
|
||||
\lstinputlisting[language=XML]{assets/dash-3d/geometry-as.xml}\label{fr:MPD}
|
||||
\end{figure}
|
||||
|
||||
|
|
@ -0,0 +1,168 @@
|
|||
\section{Évaluation}\label{fr:eval}
|
||||
|
||||
Nous décrivons maintenant notre installation et les données que nous utilisons dans nos expériences. Nous présentons une évaluation de notre système et une comparaison de l'impact des choix de conception que nous avons introduit dans les sections précédentes.
|
||||
|
||||
\subsection{Installation expérimentale}
|
||||
|
||||
\paragraph{Modèle}
|
||||
Dans nos expériences, nous utilisons un modèle du quartier de Marina Bay à Singapour. Le modèle contient 387.551 sommets et 552.118 faces. La géométrie occupe 62 MO et les textures en occupent 167. Nous partitionnons la géométrie dans un \emph{$k$-d tree} jusqu'à ce que les feuilles contiennent moins de 10.000 faces, ce qui nous donne 64 \emph{adaptation sets}, plus un pour les grandes faces.
|
||||
|
||||
\paragraph{Navigation des utilisateurs}
|
||||
Pour évaluer notre système, nous avons collecté des traces d'utilisateurs réalistes que nous pouvons rejouer.
|
||||
|
||||
Nous avons présenté notre interface web à six utilisateurs, sur laquelle le modèle se chargeait progressivement pendant que l'utilisateur pouvait naviguer. Les interactions disponibles sont inspirées des jeux vidéos à la première personne (le clavier pour se déplacer et la souris pour tourner). Nous avons demandé aux utilisateurs de naviguer et d'explorer la scène jusqu'à ce qu'ils estiment avoir visité les régions les plus importantes. Nous leur avons ensuite demandé d'enregistrer un chemin qui donnerait une bonne présentation de la scène à un utilisateur qui voudrait la découvrir.
|
||||
Toutes les 100 ms, la position et l'angle de la caméra sont enregistrées dans un tableau qui sera ensuite exporté au format JSON\@. Les traces enregistrées nous permettent de rejouer chaque enregistrement et d'effectuer les simulations et évaluations de notre système. Nous avons ainsi collecté 13 enregistrements.
|
||||
|
||||
\paragraph{Configuration du réseau}
|
||||
Nous avons testé notre implémentation sous trois débits de 2.5 Mbps, 5 Mbps et 10 Mbps avec un temps aller-retour de 76 ms, en suivant les paramètres de~\citep{dash-network-profiles}. Les valeurs restent constantes pendant toute la durée de la session pour analyser les variations de performance en fonction du débit.
|
||||
|
||||
|
||||
Dans nos expériences, nous créons une caméra virtuelle qui suit un enregistrement, et notre système télécharge les segments en temps réel selon l'algorithme~\ref{fr:nextsegment}. Nous enregistrons dans un fichier JSON les moments où les segments sont requêtés et reçus. En faisant ainsi, nous évitons de gaspiller le temps et les ressources nécessaires à l'évaluation du système pendant que les segments sont en train d'être téléchargés et aux stockage des informations nécessaires pour tracer les courbes présentées dans les prochaines sections.
|
||||
|
||||
\paragraph{Machines et logiciels}
|
||||
Les expériences ont été lancées sur un Acer Aspire V3, avec un processeur Intel Core i7 3632QM et une carte graphique NVIDIA GeForce GT 740M. Le client DASH est écrit en Rust, et utilise Glium pour le rendu et reqwest pour le téléchargement des segments.
|
||||
|
||||
\paragraph{Métriques}
|
||||
Pour mesurer objectivement la qualité du rendu, nous utilisons le PSNR\@. La scène rendue a posteriori en utilisant les mêmes chemins mais en ayant téléchargé toute la géométrie et les textures est utilisée comme vérité terrain. Dans notre cas, une erreur de pixel ne peut arriver que lorsqu'une face est manquante ou quand une texture est manquante ou à une résolution trop faible.
|
||||
|
||||
\paragraph{Expériences}
|
||||
Nous présentons des expériences qui valident nos choix d'implémentation à chaque étape de notre système. Nous rejouons les chemins créés par les utilisateurs avec différentes conditions de débit tout en variant les composants clés de notre système.
|
||||
|
||||
Nous considérons deux stratégies de chargement appliquées à notre client, proposées dans la Section~\ref{fr:dashclientspec}. La stratégie gloutonne détermine, à chaque décision, le segment qui maximise l'utilité prédite du segment au moment de son arrivée, ce qui correspond à l'équation~(\ref{fr:greedy}). La deuxième stratégie de chargement que nous testons est celle proposée dans l'équation~(\ref{fr:smart}). Nous avons aussi analysé l'impact du groupement des faces dans les segments de géométrie en fonction de leur aire.
|
||||
Enfin, nous testons différents paramètres de débit pour étudier comment notre système s'adapte à des conditions de réseau différentes.
|
||||
|
||||
\begin{table}
|
||||
\centering
|
||||
\renewcommand{\arraystretch}{1.2}
|
||||
\begin{tabular}{@{}ll@{}}
|
||||
\toprule
|
||||
Paramètres & Valeurs \\\midrule
|
||||
Utilité & Statique, Dynamique, Combinée \\
|
||||
Stratégie & Gloutonne, Proposée \\
|
||||
Segments & Triés par aire, non triés\\
|
||||
Bande passante & 2.5 Mbps, 5 Mbps, 10 Mbps \\\bottomrule
|
||||
\end{tabular}
|
||||
\caption{Paramètres de nos expériences\label{table:experiments}}
|
||||
\end{table}
|
||||
|
||||
|
||||
\subsection{Résultats expérimentaux}
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\begin{tikzpicture}
|
||||
\begin{axis}[
|
||||
xlabel=Temps (en s),
|
||||
ylabel=PSNR,
|
||||
no markers,
|
||||
cycle list name=mystyle,
|
||||
width=\tikzwidth,
|
||||
height=\tikzheight,
|
||||
legend pos=south east,
|
||||
xmin=0,
|
||||
xmax=90,
|
||||
x label style={at={(axis description cs:0.5,0.05)},anchor=north},
|
||||
y label style={at={(axis description cs:0.125,.5)},anchor=south},
|
||||
]
|
||||
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/1/curve.dat};
|
||||
\addlegendentry{\scriptsize Combinée}
|
||||
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/3/curve.dat};
|
||||
\addlegendentry{\scriptsize Statique}
|
||||
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/4/curve.dat};
|
||||
\addlegendentry{\scriptsize Dynamique}
|
||||
\end{axis}
|
||||
\end{tikzpicture}
|
||||
\caption{Impact de l'utilité des segments de géométrie sur le rendu à une débit de 5 Mbps.\label{fr:utility}}
|
||||
\end{figure}
|
||||
|
||||
La Figure~\ref{fr:utility} montre comment la métrique d'utilité peut exploiter les paramètres statiques et dynamiques. Les expériences utilisent un \emph{$k$-d tree} et la politique de chargement proposée, sur tous les chemins. On observe qu'une métrique d'utilité purement statique donne des mauvais PSNR\@. Une utilité purement dynamique donne des résultats légèrement meilleurs, notamment grâce a l'élimination des parties à l'extérieur du champ de vision, mais la version combinée décrite dans la Section~\ref{fr:utility} donne les meilleurs résultats.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\begin{tikzpicture}
|
||||
\begin{axis}[
|
||||
xlabel=Time (in s),
|
||||
ylabel=PSNR,
|
||||
no markers,
|
||||
cycle list name=mystyle,
|
||||
width=\tikzwidth,
|
||||
height=\tikzheight,
|
||||
legend pos=south east,
|
||||
xmin=0,
|
||||
xmax=90,
|
||||
x label style={at={(axis description cs:0.5,0.05)},anchor=north},
|
||||
y label style={at={(axis description cs:0.125,.5)},anchor=south},
|
||||
]
|
||||
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/1/curve.dat};
|
||||
\addlegendentry{\scriptsize Tri des faces par aires}
|
||||
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/5/curve.dat};
|
||||
\addlegendentry{\scriptsize Pas de tri des faces}
|
||||
\end{axis}
|
||||
\end{tikzpicture}
|
||||
\caption{Impact du tri des faces dans les segments à un débit de 5 Mbps}\label{fr:sorting}
|
||||
\end{figure}
|
||||
|
||||
La Figure~\ref{fr:sorting} montre l'impact de l'arrangement des polygones dans les segments en fonction de leur aire. Il est clair que le PSNR augmente considérablement lorsque l'aire des faces est prise en compte lors de la création des segments. Puisque les segments ont tous la même taille (en octets), trier les faces par aire avant de les ranger dans les segments introduit une asymétrie dans la distribution des aires. Cette asymétrie permet au client de prendre des décisions (télécharger les segments avec la plus grande utilité) et peut créer une grande différence en terme de qualité de rendu.
|
||||
|
||||
Nous avons aussi comparé l'approche gloutonne et celle proposée (voir Figure~\ref{fr:greedyweakness}) pour un débit limitée (5 Mbps). La méthode proposée est meilleure sur les 30 premières secondes et fait mieux en moyenne. La Table~\ref{fr:greedyVsproposed} montre le PSNR moyen pour les deux méthodes pour différents débits. C'est sur les 30 premières secondes que les décisions sont cruciales puisqu'elles correspondent aux moments où peu de contenu a été téléchargé. Nous observons que notre méthode augmente la qualité du rendu entre 1 et 1.9 dB par rapport à l'approche gloutonne.
|
||||
|
||||
La Table~\ref{fr:perc} montre la distribution des textures téléchargées par les deux approches, à différents débits. La résolution 5 est la plus détaillée, et la résolution 1 la plus grossière. Cette table met en évidence une faiblesse de la politique gloutonne : quand le débit augmente, la distribution des résolutions téléchargées reste plus ou moins la même. En revanche, notre politique s'adapte en téléchargeant des plus hautes résolutions quand le débit est meilleur (13.9\% à 10 Mbps contre 0.3\% à 2.5 Mbps). En fait, une propriété intéressante de la politique proposée est qu'elle adapte le compromis géométrie-texture au débit. Les textures représentent 57.3\% des octets téléchargés à 2.5 Mbps, et 70.2\% à 10 Mbps. En d'autres termes, notre système tend à favoriser la géométrie quand le débit est faible, et favoriser les textures quand le débit augmente.
|
||||
|
||||
\begin{figure}
|
||||
\centering
|
||||
\begin{tikzpicture}
|
||||
\begin{axis}[
|
||||
xlabel=Time (in s),
|
||||
ylabel=PSNR,
|
||||
no markers,
|
||||
cycle list name=mystyle,
|
||||
width=\tikzwidth,
|
||||
height=\tikzheight,
|
||||
legend pos=south east,
|
||||
xmin=0,
|
||||
xmax=90,
|
||||
x label style={at={(axis description cs:0.5,0.05)},anchor=north},
|
||||
y label style={at={(axis description cs:0.125,.5)},anchor=south},
|
||||
]
|
||||
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/1/curve.dat};
|
||||
\addlegendentry{\scriptsize Proposé}
|
||||
\addplot table [y=psnr, x=time]{assets/dash-3d/gnuplot/6/curve.dat};
|
||||
\addlegendentry{\scriptsize Glouton}
|
||||
\end{axis}
|
||||
\end{tikzpicture}
|
||||
\caption{Impact de la politique de chargement (glouton vs proposé) à un débit de 5 Mbps}\label{fr:greedyweakness}
|
||||
\end{figure}
|
||||
|
||||
\begin{table}
|
||||
\centering
|
||||
\renewcommand{\arraystretch}{1.2}
|
||||
\begin{tabular}{@{}p{1.9cm}p{0.7cm}p{0.7cm}p{0.7cm}p{0.7cm}p{0.7cm}p{0.7cm}@{}}
|
||||
\toprule
|
||||
\multirow{2}{1.7cm}{} & \multicolumn{3}{c}{\textbf{Premières 30s}} & \multicolumn{3}{c}{\textbf{Globalement}}\\
|
||||
% \hline
|
||||
% \textbf{Inactive Modes} & \textbf{Description}\\
|
||||
\cline{2-7}
|
||||
BP (Mbps) & 2.5 & 5 & 10 & 2.5 & 5 & 10 \\
|
||||
\midrule
|
||||
Glouton & 14.4 & 19.4 & 22.1 & 19.8 & 26.9 & 29.7 \\
|
||||
Proposé & 16.3 & 20.4 & 23.2 & 23.8 & 28.2 & 31.1 \\
|
||||
\bottomrule
|
||||
\end{tabular}
|
||||
\caption{PSNR moyens, Glouton vs Proposé\label{fr:greedyVsproposed}}
|
||||
\end{table}
|
||||
|
||||
\begin{table}
|
||||
\centering
|
||||
\renewcommand{\arraystretch}{1.2}
|
||||
\begin{tabular}{@{}cccc@{}}
|
||||
Résolution & 2.5 Mbps & 5 Mbps & 10 Mbps \\
|
||||
\toprule
|
||||
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\% \\
|
||||
4 & 14.6\% vs 18.4\% & 14.4\% vs 25.2\% & 14.2\% vs 24.1\% \\
|
||||
5 & 11.4\% vs 0.3\% & 11.1\% vs 5.9\% & 11.5\% vs 13.9\% \\\bottomrule
|
||||
\end{tabular}
|
||||
\caption{Pourcentage d'octets téléchargés pour chaque résolution de texture, pour la politique gloutonne (gauche) et pour celle proposée (droite) \label{fr:perc}}
|
||||
\end{table}
|
||||
|
||||
|
|
@ -0,0 +1 @@
|
|||
Blabla
|
||||
|
|
@ -0,0 +1,5 @@
|
|||
\chapter{Résumé en français}
|
||||
\input{src/french/intro}
|
||||
\input{src/french/dash-3d}
|
||||
\input{src/french/client}
|
||||
\input{src/french/evaluation}
|
||||
|
|
@ -22,6 +22,8 @@
|
|||
\let\rawref\ref%
|
||||
%\renewcommand{\ref}[1]{\rawref{#1} (page~\pageref{#1})}
|
||||
|
||||
\includepdf[pages=-]{assets/ugly-cover.pdf}
|
||||
|
||||
\frontmatter
|
||||
|
||||
\input{titlepage.tex}
|
||||
|
|
@ -41,6 +43,10 @@
|
|||
|
||||
\bibliography{src/bib.bib}
|
||||
|
||||
\appendix
|
||||
|
||||
\input{src/french/main}
|
||||
|
||||
\chaptermark{Abstracts}
|
||||
\input{abstracts/main}
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue