I try stuff

src/introduction/challenges.tex

@@ -16,34 +16,38 @@ A 3D streaming client has lots of tasks to accomplish:
 This opens multiple problems that we need to take care of.
 
 \subsection{Content preparation}
-Any preprocessing that can be done on our 3D data gives us a strategical advantage since it consists in computations that will not be needed live, neither for the server nor for the client.
-Furthermore, for streaming, data needs to be split into chunks that are requested separately, so perparing those chunks in advance can also help the streaming.
+% Any preprocessing that can be done on our 3D data gives us a strategical advantage since it consists in computations that will not be needed live, neither for the server nor for the client.
+% Furthermore, for streaming, data needs to be split into chunks that are requested separately, so perparing those chunks in advance can also help the streaming.
 Before streaming content, it needs to be prepared.
 This includes but is not limited to compression and segmentation.
+One of the question this thesis has to answer is \emph{what is the best way to prepare 3D content so that a client can benefit from it?}
 
 \subsection{Chunk utility}
 Once our content is prepared and split in chunks, we need to be able to rate those chunks depending on the user's position.
-A chunk that contains data in the field of view of the user should have a higher score than a chunk outside of it; a chunk that is close to the camera should have a higher score than a chunk far away from the camera, etc\ldots
+A chunk that contains data in the field of view of the user should have a higher score than a chunk outside of it; a chunk that is close to the camera should have a higher score than a chunk far away from the camera, etc\ldots.
+An open question of this thesis is \emph{how do we determine how useful is a chunk of data depending on the user's position?}
 
 \subsection{Streaming policies}
-Rating the chunks is not enough, there are other parameters that need to be taken into account.
-For example, the time needed to download a chunk is important: when two segments have the same score, a smart client would rather download the once that arrives earlier.
-The user interaction can also be taken into account: if we are able to perdict the user movement in the scene, we can get a more precise information about what chunks should be downloaded.
-This is why we need to define streaming policies that rely on chunk utilities to determine the optimal segments to download.
+Rating the chunks is not enough, there are other contextual parameters that need to be taken into account, such as the size of a chunk, the bandwidth, the user's behaviour, etc\ldots.
+Another question that raises from this is \emph{how do we take into the context into account to decide what chunks to download?}
 
 \subsection{Evaluation}
 All the problems mentionned earlier yield many ideas and solutions with different parameters.
-We need to compare the different options we have for each of the previous problem, and evaluate their impact in terms of quality of service and quality of exeperience.
+We need to answer \emph{how can we compare streaming policies and evalute the impact of their parameters in terms of quality of service and quality of exeperience?}
 
 \subsection{Implementation}
-We have to setup a client-server architecture that answers the problems mentionned earlier (content preparation, chunk utility, streaming policies).
-This implementation must respect constraints required for performant software:
-
-\begin{itemize}
-    \item \textbf{for the server}, since a server must serve many clients, and a solution that requires even low computational load on the server will scale difficultly;
-    \item \textbf{for the client}, since the end user will use his own device, whether it be an old computer or a mobile device, and the implementation must be efficient enough to leave resources (such as CPU or memory) for the other tasks it has to accomplish.
-\end{itemize}
-
-Furthermore, since we want to be able to evaluate our systems, user studies are required and using web technologies is a way to simplify this task.
-Therefore, part of our software needs to be runnable from a web browser.
+The objective of our work is to setup a client-server architecture that answers the problems mentionned earlier (content preparation, chunk utility, streaming policies).
+In this regard, we have to find out \emph{how do we build this architecture while keeping the computational load on the server low so it can scale, the client efficient so that it has resources to perform its many tasks, and in a way that allow easy deployment of user studies and simulations?}
 
+% This implementation must respect constraints required for performant software:
+%
+% \begin{itemize}
+%     \item \textbf{for the server}, since a server must serve many clients, and a solution that requires even low computational load on the server will scale difficultly;
+%     \item \textbf{for the client}, since the end user will use his own device, whether it be an old computer or a mobile device, and the implementation must be efficient enough to leave resources (such as CPU or memory) for the other tasks it has to accomplish.
+% \end{itemize}
+%
+% Furthermore, since we want to be able to evaluate our systems, user studies are required and using web technologies is a way to simplify this task.
+% Therefore, part of our software needs to be runnable from a web browser.
+%
+% We will have to find out \emph{how do we build a client-server architecture that
+%