I hate this shit

This commit is contained in:
2019-11-04 15:29:27 +01:00
parent 8a78c1a982
commit c4c4f9b2fc
24 changed files with 66 additions and 88077 deletions

View File

@@ -90,34 +90,34 @@ anchorcolor = blue]{hyperref}
\DeclareOldFontCommand{\sc}{\normalfont\scshape}{\@nomath\sc}
\makeatother
\usepackage[ED=MITT-ImgInf, Ets=INP]{tlsflyleaf}
% \usepackage[ED=MITT-ImgInf, Ets=INP]{tlsflyleaf}
\title{Dynamic Adaptive 3D Streaming over HTTP}
\author{Thomas \textsc{Forgione}}
\defencedate{01/10/2019}
\lab{Institut de Recherche en Informatique de Toulouse (UMR 5505)}
%% Directeur de these
\nboss{3}
\makesomeone{boss}{1}{Vincent CHARVILLAT}{}{} % Sera afiche en premier
\makesomeone{boss}{2}{Axel CARLIER}{}{} % Sera affiche en second
\makesomeone{boss}{3}{Géraldine MORIN}{}{} % Sera affiche en troisieme
%% Referee
\nreferee{2}
\makesomeone{referee}{1}{Premier RAPPORTEUR}{}{}
\makesomeone{referee}{2}{Second RAPPORTEUR}{}{}
%% Jury
\njudge{5}
\makesomeone{judge}{1}{Premier MEMBRE}{Professeur d'Universit\'e}{Pr\'esident du Jury}
\makesomeone{judge}{2}{Second MEMBRE}{LULZ}{Membre du Jury}
\makesomeone{judge}{3}{Troisi\`eme MEMBRE}{Charg\'e de Recherche}{Membre du Jury}
\makesomeone{judge}{4}{Quatri\`eme MEMBRE}{Charg\'e de Recherche}{Membre du Jury}
\makesomeone{judge}{5}{Cinqui\`eme MEMBRE}{Charg\'e de Recherche}{Membre du Jury}
% \defencedate{01/10/2019}
%
% \lab{Institut de Recherche en Informatique de Toulouse (UMR 5505)}
%
% %% Directeur de these
% \nboss{3}
% \makesomeone{boss}{1}{Vincent CHARVILLAT}{}{} % Sera afiche en premier
% \makesomeone{boss}{2}{Axel CARLIER}{}{} % Sera affiche en second
% \makesomeone{boss}{3}{Géraldine MORIN}{}{} % Sera affiche en troisieme
%
% %% Referee
% \nreferee{2}
% \makesomeone{referee}{1}{Premier RAPPORTEUR}{}{}
% \makesomeone{referee}{2}{Second RAPPORTEUR}{}{}
%
% %% Jury
% \njudge{5}
% \makesomeone{judge}{1}{Premier MEMBRE}{Professeur d'Universit\'e}{Pr\'esident du Jury}
% \makesomeone{judge}{2}{Second MEMBRE}{LULZ}{Membre du Jury}
% \makesomeone{judge}{3}{Troisi\`eme MEMBRE}{Charg\'e de Recherche}{Membre du Jury}
% \makesomeone{judge}{4}{Quatri\`eme MEMBRE}{Charg\'e de Recherche}{Membre du Jury}
% \makesomeone{judge}{5}{Cinqui\`eme MEMBRE}{Charg\'e de Recherche}{Membre du Jury}
\lstdefinelanguage{JavaScript}{
keywords={break, case, catch, continue, debugger, default, delete, do, else, finally, for, function, if, in, instanceof, new, return, switch, this, throw, try, typeof, var, void, while, with, let},

View File

@@ -3,7 +3,7 @@ Dans cette section, nous détaillons un client DASH NVE qui exploite la prépara
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.
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 demandé, 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}

View File

@@ -0,0 +1,3 @@
\section{Conclusion}\label{fr:conclusion}
Notre travail sur ce chapitre a commencé avec la question : peut-on utiliser DASH pour la transmission de modèles 3D massifs ? La réponse est \emph{oui}. Pour répondre à cette question, nous avons montré comment organiser une soupe de polygones et ses textures dans un format compatible avec DASH qui inclut un minimum de métadonnées utiles au client, et organise le contenu pour permettre au client de télécharger le contenu le plus utile en premier.

View File

@@ -1,6 +1,6 @@
\section{Formatter un NVE en DASH}\label{fr:dash3d}
\section{Formater 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 cette section, nous décrivons comment nous préparons et stockons les données 3D de notre NVE (Networked Virtual Environment) 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}

View File

@@ -17,7 +17,7 @@ Toutes les 100 ms, la position et l'angle de la caméra sont enregistrées dans
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.
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 téléchargés. 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.
@@ -49,7 +49,7 @@ Enfin, nous testons différents paramètres de débit pour étudier comment notr
\subsection{Résultats expérimentaux}
\begin{figure}[h]
\centering
\centering
\begin{tikzpicture}
\begin{axis}[
xlabel=Temps (en s),
@@ -61,8 +61,6 @@ Enfin, nous testons différents paramètres de débit pour étudier comment notr
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}
@@ -72,13 +70,13 @@ Enfin, nous testons différents paramètres de débit pour étudier comment notr
\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}}
\caption{Impact de l'utilité des segments de géométrie sur le rendu à une débit de 5 Mbps.\label{fr:utility-curve}}
\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.
La Figure~\ref{fr:utility-curve} 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
\centering
\begin{tikzpicture}
\begin{axis}[
xlabel=Time (in s),
@@ -90,8 +88,6 @@ La Figure~\ref{fr:utility} montre comment la métrique d'utilité peut exploiter
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}
@@ -109,7 +105,7 @@ Nous avons aussi comparé l'approche gloutonne et celle proposée (voir Figure~\
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
\centering
\begin{tikzpicture}
\begin{axis}[
xlabel=Time (in s),
@@ -121,8 +117,6 @@ La Table~\ref{fr:perc} montre la distribution des textures téléchargées par l
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é}
@@ -163,6 +157,6 @@ La Table~\ref{fr:perc} montre la distribution des textures téléchargées par l
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}}
\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}

View File

@@ -1 +1,11 @@
Blabla
Ce chapitre présente la majeure contribution de cette thèse en français, pour les lecteurs non anglophones.
Il s'agit de l'adaptation du standard DASH (Dynamic Adaptive Streaming over HTTP) pour la transmission vidéo à la transmission de contenu 3D.
DASH propose une préparation et une organisation du contenu qui permet l'élaboration de politiques de chargement.
Un client DASH est un client qui télécharge la description de l'organisation du contenu (un fichier XML appelé Media Persentation Description, MPD), et qui décide, en fonction de ses besoins, ce qui doit être téléchargé.
Ces décisions étant prises indépendamment du serveur, celui-ci n'effectue aucun calcul ce qui rend la solution scalable.
Dans ce chapitre, nous montrons comment nous imitons DASH vidéo pour la transmission 3D, et nous développons un système qui hérite des avantages de DASH.
La Section~\ref{fr:dash3d} décrit la préparation et l'organisation du contenu, ainsi que les métadonnées et les prétraitements effectués sur notre modèle 3D pour optimiser la transmission.
La Section~\ref{fr:dashclientspec} propose plusieurs implémentations de clients qui exploitent cette organisation du contenu.
La Section~\ref{fr:eval} évalue l'impact des différents paramètres de notre préparation et de nos clients.
Nous concluons enfin dans la Section~\ref{fr:conclusion}.

View File

@@ -1,5 +1,18 @@
\chapter{Résumé en français}
\begin{figure}[th]
\centering
\includegraphics[width=\textwidth]{assets/dash-3d/bigpicture.png}
\caption{%
Une scène 3D subdivisée en un arbre $k$-d avec ses régions délimitées avec des bordures rouges.
En blanc, les régions à l'extérieur du champ de vision de la caméra; en vert, les régions à l'intérieur.\label{fr:bigpic}
}
\end{figure}
\input{src/french/intro}
\newpage
\input{src/french/dash-3d}
\input{src/french/client}
\input{src/french/evaluation}
\input{src/french/conclusion}

View File

@@ -8,16 +8,16 @@
thin,
above=0.5cm,
minimum width=19cm,
minimum height=9.5cm,
minimum height=9.75cm,
]{};
\node at (current page.south)[
above=8.5cm,
above=8.75cm,
font=\sffamily\bfseries\Huge,
] {\color{white}\thetitle};
\node at (current page.south)[
above=7.25cm,
above=7.5cm,
font=\sffamily\bfseries\large,
align=center,
] {%
@@ -26,13 +26,14 @@
};
\node at (current page.south)[
above=3.325cm,
above=3.25cm,
font=\sffamily\small,
align=center,
] {%
\color{white}\textbf{Sidonie CHRISTOPHE}, reviewer\\
\color{white}\textbf{Gwendal SIMON}, reviewer\\
\color{white}\textbf{Gilles GESQUIÈRE}, reviewer\\
\color{white}\textbf{Maarten Wijnants}, examiner\\
\color{white}\textbf{Wei Tsang OOI}, examiner\\
\color{white}\textbf{Vincent CHARVILLAT}, thesis supervisor\\
\color{white}\textbf{Axel CARLIER}, thesis co-supervisor\\
@@ -48,7 +49,7 @@
\color{white}\textbf{Field}: Computer science and telecommunication\\
\color{white}\textbf{Research unit}: IRIT (5505)\\
\color{white}\textbf{Thesis supervisors}: Vincent CHARVILLAT, Axel CARLIER and Géraldine MORIN\\
\color{white}\textbf{Rapporteurs}: Sidonie CHRISTOPHE and Gwendal SIMON
\color{white}\textbf{Reviewers}: Sidonie CHRISTOPHE and Gwendal SIMON
};
\end{tikzpicture}
\end{titlepage}