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 work and give the same results. This is perhaps a more explicit way of writing the previous code's logic.
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.