simplify server for record-audio-video-stream #39
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
As only one stream can be maintained at a time, this change moves to just holding on to one stream and closing it before opening a new one. If we receive audio data after the stream is changed, then the stream ID won't match the global `STREAM_ID` counter. Furthermore, by using only a single stream instance we can simplify the merging process, as we've just a list of files as a result. Additionally, the previous code used clearTimeout on a setInterval, which seemed like a bug. I wasn't sure if a video could change it's frame-size whilst you're receiving frames, which seems a little odd. Furthermore, a change in size would likely corrupt the entire recording as the two video files to merge would be mismatched in resolution (size). n.b., I've not had a chance to actually test this code, as I've authored this via GitHub, but it should give the same results.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
As only one stream can be maintained at a time, this change moves to just holding on to one stream and closing it before opening a new one. If we receive audio data after the stream is changed, then the stream ID won't match the global
STREAM_IDcounter. Furthermore, by using only a single stream instance we can simplify the merging process, as we've just a list of files as a result. Additionally, the previous code used clearTimeout on a setInterval, which seemed like a bug.I wasn't sure if a video could change it's frame-size whilst you're receiving frames, which seems a little odd. Furthermore, a change in size would likely corrupt the entire recording as the two video files to merge would be mismatched in resolution (size).
n.b., I've not had a chance to actually test this code, as I've authored this via GitHub, but it should work and give the same results. This is perhaps a more explicit way of writing the previous code's logic.