Echo: Day 5

Today, I started working on the Go backend, which receives the stream from the frontend and saves it to the disk. Most of the time was spent fixing the logic for how binary data was saved to disk as a WebM file.

The issue was with how the data was being stored in the temporary file. It was randomly saving to one of the temp files. Because of this, if only one type of stream (e.g., camera) was sent to the backend, it saved properly — as long as no other stream was started during the session. However, if another type of stream (like screen sharing) was also sent to the backend, it created two StreamState objects and alternated the binary data between the two temp file.

Get Alwin Sunil’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

This caused corruption in the output:

• If the stream started with both the camera and screen sharing, it would be corrupted from the start.
• If the camera stream started first, it would produce a proper file until screen sharing began. After that point, one file would be valid, while the other would contain junk data — combined binary from both streams.

This issue was resolved by adding a signal bit at the end of every chunk of data sent to the backend. This additional bit represents the stream type:

• 0 for the camera
• 1 for screen sharing

Based on this bit, the stream is now saved into the appropriate StreamState object. The StreamState is a map containing type-state pairs, ensuring that starting the camera or screen sharing at any moment is properly handled by the Go backend.

Additionally, the backend now creates a JSON file at the end of the stream. This file tracks stream details, such as the number of clips and the timestamp for each clip. Later, this information can be used to combine and encode the video for on-demand playback.

That’s all for today — thank you for reading!