-
Notifications
You must be signed in to change notification settings - Fork 2
Milestone #2
Again, the submission can be informal documents describing the team’s current understanding of the items listed below. The mentors will be meeting with the teams to ask follow up questions.
How has the plan changed?
Has the team been actively assessing risk and updating the plan accordingly?
Does the team have a plan for any remaining significant issues/risks
Does the team have a reasonable construction plan?
- Experiment takes time due to environmental factors and more complicated experiment process than initially planned
- Additional experiments and technical analysis were conducted to satisfy the requirements.
- The roles of modules and team members have been rebalanced in the design process.
- Team 1 changed the process to register individual tasks as issues, share statuses, and update progress using GITHUB Kanban
- Project : https://github.com/users/changjurhee/projects/3/views/1
- Issues : https://github.com/changjurhee/AONE/issues
- (Availablity ASR) Apply jitter buffer for network jitter (for audio/video)
- (Availablity ASR) Apply packet duplication for netwrok packet drop (for audio)
- (Performance ASR) Apply dynamic video quality change rule for network condition changes
- (Technical RISK) Use STAR TOPOLOGY that minimizes connection links to ensure performance and availability QA in low bandwidth
- (Technical RISK) Use the proven GStreamer open source for development efficiency, stability, secured data transfer w/ plugin module.
What experiments have been conducted?
Have the results of the experiments addressed the open questions/issues?
What experiments remain?
Are the experiments focused on issues relevant to the overall goals of the system?
N | Status | Experiments | Risks / QA tracability / Issues |
---|---|---|---|
1 | Concluded | Network bandwidth measurement in operating environment | (Technical Risk) Find Video transfer throughput to meet Performance ASR within STAR topology. |
2 | Concluded | Find the correlation between network bandwidth and video quality. | (Technical Risk) Find optmal video qualitity to gurantee communiation availability (Performance QA) To make proper video bandwidth resize logics within network & participant condition |
3 | InProgress | Verify that receiver can improve network jitter problems using the jitter buffer. | (Technical Risk ) How to check and recover network jitter (Availability QA) System maintain call quality under amount of increated network jitter |
4 | InProgress | Verify that receiver can improve paket loss problems using duplication / reordering. | (Technical Risk ) How to check and recover Data drop (Availability QA) System maintain call quality under amount of increated data drop |
N | Status | Experiments | Risks / QA tracability / Issues |
---|---|---|---|
5 | Concluded | Secure session communications using TLS | Milestone #1 feedback (from Paulo) (Functional requirement)System shall transfer data for sessions between server & client in secure way. |
6 | Concluded | Measure Video/Audio latency on Network topology we decide | (Performance QA) Check additional risk for STAR Topology |
What is the architecture in terms of the organization of code units and their dependencies? (The team shall create a module view of the architecture.)
- First decomposition of overall architecture
- Second decompositions for ClientUI, Server UI, SessionClient, SessionServer, Database
Element | Description |
---|---|
MediaManager (Client/Server) | Responsible for the client/server media functions. Provides a media function interface to the session manager. |
MediaStatsMonitor | Monitors and collects statistics related to video/audio playback and provides an interface for notifications. |
MediaPipelineManager (Video/Audio) | Provides media sending and receiving functions using gstreamer (external library). It is the only module that depends on gstreamer and provides interfaces for sending/receiving media, checking RTP packet transmission status, and setting video/audio quality. |
MediaClient::VideoQualityAdjuster(VQA) | MediaStatsMonitor provides an interface to subscribe to Video Quality information and provide notifications when problems occur. Provides an interface for setting the video quality so that the bandwidth used for video transmission can be adjusted. |
MediaServer::VideoQualityAdjuster(VQA) | Based on the video quality information received from the client, the size of the merged image is determined and the video quality change request is made to each client. |
TBD
TBD
What is the architecture in terms of components and connectors (runtime perspective)? (The team shall create a C&C/runtime view of the architecture.)
Element | Description |
---|---|
Client/ServerMediaManager | Responsible for the client's media functions. Provides a media function interface to the session manager. |
VideoStatsMonitor | Monitors and collects statistics related to video playback and provides an interface for notifications. |
ClientVideoQualityAdjuster(VQA) | VideoStatsMonitor provides an interface to subscribe to Video Quality information and provide notifications when problems occur. Provides an interface for setting the video quality so that the bandwidth used for video transmission can be adjusted. |
Compositor | Video frames received from each client are merged into one frame. Depending on the setting, the client focusing function is performed. |
ServerVideoQualityAdjuster(VQA) | Based on the video quality information received from the client, the size of the merged image is determined and the video quality change request is made to each client. |
PipelineManager | Provides media sending and receiving functions using gstreamer (external library). It is the only module that depends on gstreamer and provides interfaces for sending/receiving media, checking RTP packet transmission status, and setting video quality. |
rtpjitterbuffer | This is a filter that performs a response mechanism for jitter and lost errors for RTP packets received through buffer operation. When an audio packet is lost, an event is sent to the concealment filter and RTP packet reception information is collected. |
videoscaler | This is a filter that adjusts the video resolution. |
H.264Encoder | Performs video encoding and adjusts the content bitrate according to settings. |
TBD
TBD
What is the architecture in terms of the supporting infrastructure (deployment perspective)? (The team shall create a deployment view highlighting component allocation to hardware elements and communication channels.)
TBD
TBD
TBD
- Communication Diagram
Loss Concealment only applies to Audio
- Use STAR topology instead of MESH topology.
- We derived Performance QA as an important ASR, and based on this, we want to reduce the network occupancy rate of the entire system by reducing the number of connections based on multiple participants in order to transmit the maximum quality video in a limited bandwidth.
- We verified this from our planned experiments. (Experiment #1, Experiment #2)
- We worried about roundtrip latency but it was ok in evaluation environment (Experiment #6)
- Accepted
- System can provide much higher video quality
Have the experiments led to a refinement of the architecture?
Does the team understand the architectural approaches they have/will realize?
Do the architectural approaches align with the goals of the system?
Are there significant concerns that have not been addressed?
Has the architecture been evaluated?