What I Accomplished Over The Trimester

It’s been a long journey in CSA, from the WebRTC trenches of trimester 1 to now, things really have changed. But how much? That’s the question.

My Big Five (/5)

Burndown List

Analytics

Issues

Documentation And Iteration (The FUTURE!)

Collaboration

Key Feature (/1)

How Mortevision Works

The fundamental backbone behind Mortevision is WebRTC, or Web Real Time Connections. This is the same technology used to do video calls over HTTP on services such as Discord, Omegle, or any web based video calling service you may think of.
Mortevision uses a Client/Server model, with the server being used to communicate sdp and ice candidates, and there are two types of clients. There are broadcaster clients, and viewer clients. The broadcaster captures their display media and the viewers connect to the broadcaster to watch the stream.

Broadcaster Logic

The broadcaster sends a request to the server to let them stream, and when they do they send out a message using a WebSocket which sets their websocket ID to be the “broadcasterID”, now saved on the server.

Then they have their streams obtained by

let stream = await navigator.getDisplayMedia({video:true,audio:false});
console.log(stream)

Viewer Logic, and WebRTC

The viewer client then can connect when they please after connecting to the WebSocket server. They send a WebSocket request to the server after creating a RTCPeerConnection(servers). The servers are Google’s STUN servers that allow the clients to be able to connect with each other. The viewer will create an offer and will set the local description of the connection to be their side before sending the server their sdp data. Sdp data, or session description protocol defines the parameters for exchanging media. The server then refers to the broadcasterID variable to find what websocket connection to send the sdp data to. Once the sdp data is sent, the broadcaster sets the remote description to be the viewer’s sdp that is equal to the viewer’s offer. They then return their own sdp data which was generated with createOffer().

The users will also exchange ICECandidates everytime the browser finds one, to put it simply, these ICECandidates essentially inform the other party of a faster way to reach them, like adding lanes to a highway.

N@TM (/2)

At Night at the Museum, I presented alongside Ian Wu on our work which he presented the queue system. For my presentation, I presented my presentation system using WebRTC, and I remember notably presenting to my friend Weston Gardener’s parents, and in their comments they really enjoyed our presentation, but they also suggested some improvements, as perhaps sharing audio would be a good idea given the nature of being able to present from a desk.

Here were some photos I took at the event! A cool photo from photography

The bathroom pass group

Our group + Trevor!

A project I saw about presenting national dishes!

MCQ/FRQ (/1)

Q1) k % inputVal == 0, just a stupid mistake, fundamentally understand the answer Q14) Biggest may not work correctly when a and b have equal values as they are the first Q13) A, the loop increments by one first Q3) B, show exists in the B class, so it has no reason not to work Q39) Alex Bob Carl, Alex Alex Alex, as the first loop in the set gets the original values before alex is set 3 times.

Self Evaluation (/1)

Thinking what you will do next in CompSci, interests, classes, college, internships, career. Reflection on individual strengths, weaknesses Reflection on project by creating next steps plans, strengths, weaknesses

For the future I hope to see beyond CompSci and move into integrating it into daily life, even though in certain ways it already is. However, the more things I could innovate with computer science is what brings me the allure. I have gotten two internships so far at UCSD from my experiences with computer science, and I hope to grow even more. For college, I hope to be able to go into a great robotics program, as seeing code work alongside a physical manifestation of it is incredible.

In terms of my strengths this trimester, it was my stronger understanding of WebRTC, and different frameworks for it. I grew alot from my localhost working in “theory”, to an actual deployment. I got the chance to experiment with an SFU, WebSockets, Flask, Socket.io, and the engineering cycle of working towards a greater goal. One major weakness of that though was that I never persisted to make a specific implmentation work, as I settled for an OTM model, when I could have ran a MediaServer. I also struggled with communication as I did not have many people who were working on the project alongside me, Bella being essentially my only teammate. For the future I hope to itegrate better with others, and that will start with Ian and his queue system.

For my individual grades:
Big Five (4.8/5): I think I now have a clearer vision on where Mortevision will go from here. I hope to make Mortevision the best it could ever be.
Key Feature (.9/1) I was really happy with my flowchart and giving a technical explanation of how WebRTC works! I’m really excited to show you how it works internally and my future plans.
NATM / Full stack Demo (1.8/2) I could likely explain it a bit better, as I did need to take more photos during the event. I did get some valuable feedback however!
MC/FRQ (.9/1) Completed both!
Self Evaluation (.9/1) I tried to be as honest as I could
Total:
(9.3/10)