37 lines
2.8 KiB
Plaintext
37 lines
2.8 KiB
Plaintext
|
= Open problems
|
||
|
|
|
||
|
|
The objective of our work is to design a system which allows a user to access remote 3D content.
|
||
|
|
A 3D streaming client has lots of tasks to accomplish:
|
||
|
|
|
||
|
|
- Decide what part of the content to download next,
|
||
|
|
- Download the next part,
|
||
|
|
- Parse the downloaded content,
|
||
|
|
- Add the parsed result to the scene,
|
||
|
|
- Render the scene,
|
||
|
|
- Manage the interaction with the user.
|
||
|
|
|
||
|
|
This opens multiple problems which need to be considered and will be studied in this thesis.
|
||
|
|
|
||
|
|
#heading(level: 4, numbering: none)[Content preparation]
|
||
|
|
Before streaming content, it needs to be prepared.
|
||
|
|
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.
|
||
|
|
The downloaded chunks can be rendered while more chunks are being downloaded.
|
||
|
|
Content preparation also includes compression.
|
||
|
|
One of the questions this thesis has to answer is: _what is the best way to prepare 3D content so that a streaming client can progressively download and render the 3D model?_
|
||
|
|
|
||
|
|
#heading(level: 4, numbering: none)[Streaming policies]
|
||
|
|
Once our content is prepared and split in chunks, a client needs to determine which chunks should be downloaded first.
|
||
|
|
A chunk that contains data in the field of view of the user is more relevant than a chunk that is not inside; a chunk that is close to the camera is more relevant than a chunk far away from the camera.
|
||
|
|
This should also include other contextual parameters, such as the size of a chunk, the bandwidth and the user's behaviour.
|
||
|
|
In order to propose efficient streaming policies, we need to know _how to estimate a chunk utility, and how to determine which chunks need to be downloaded depending the user's interactions?_
|
||
|
|
|
||
|
|
#heading(level: 4, numbering: none)[Evaluation]
|
||
|
|
In such systems, two commonly used 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 and measures how well the content is served to the client.
|
||
|
|
The quality of experience is a user-centric metric: it relies on user perception and can only be measured by asking how users feel about a system.
|
||
|
|
To be able to know which streaming policies are best, one needs to know _how to compare streaming policies and evaluate the impact of their parameters on the quality of service of the streaming system and on the quality of experience of the final user?_
|
||
|
|
|
||
|
|
#heading(level: 4, numbering: none)[Implementation]
|
||
|
|
The objective of our work is to setup a client-server architecture that answers the above problems: content preparation, chunk utility, streaming policies.
|
||
|
|
In this regard, we have to find out _how do we build this architecture that keeps a low computational load on the server so it scales up and on the client so that it has enough resources to perform the tasks described above?_
|