Introi
This commit is contained in:
@@ -15,28 +15,27 @@ A 3D streaming client has lots of tasks to accomplish:
|
||||
|
||||
This opens multiple problems that we need to take care of.
|
||||
|
||||
\subsection{Content preparation}
|
||||
\paragraph{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.
|
||||
Before streaming content, it needs to be prepared.
|
||||
This includes but is not limited to compression and segmentation.
|
||||
The segmentation of the content into chunks is particularly important for streaming since it allows transmitting only a portion of the data to the client, that it can render before downloading more chunks.
|
||||
Content preparation also includes compression.
|
||||
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?}
|
||||
|
||||
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}
|
||||
Once our content is prepared and split in chunks, one needs 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.
|
||||
This rating should also include other contextual parameters, such as the size of a chunk, the bandwidth, the user's behaviour, etc\ldots.
|
||||
\paragraph{Streaming policies.}
|
||||
Once our content is prepared and split in chunks, a client needs to determine which chunks it needs to download.
|
||||
A chunk that contains data in the field of view of the user is more relevant than a chunk outside of it; a chunk that is close to the camera is more relevant than a chunk far away from the camera, etc\ldots.
|
||||
This should also include other contextual parameters, such as the size of a chunk, the bandwidth, the user's behaviour, etc\ldots.
|
||||
The most important question we have to answer is \emph{how do we determine which chunks need to be downloaded depending on the chunks themselves and the user's interactions?}
|
||||
|
||||
\subsection{Evaluation}
|
||||
\paragraph{Evaluation.}
|
||||
In such systems, the two most important criteria for evaluation are quality of service, and quality of experience.
|
||||
The quality of service is a network-centric metric, which considers values such as throughput.
|
||||
The quality of experience is a user-centric metric, and can only be measured by asking how users feel about a system.
|
||||
To be able to know which streaming policies, one needs to know \emph{how can we compare streaming policies and evalute the impact of their parameters in terms of quality of service and quality of experience?}
|
||||
To be able to know which streaming policies are best, one needs to know \emph{how can we compare streaming policies and evalute the impact of their parameters in terms of quality of service and quality of experience?}
|
||||
|
||||
\subsection{Implementation}
|
||||
\paragraph{Implementation.}
|
||||
The objective of our work is to setup a client-server architecture that answers the problems mentioned 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 and the client efficient so that it has resources to perform its many tasks?}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user