Open eddie-at-curve10 opened 2 years ago
@eddie-at-curve10, can you post a snippet of the code producing this issue?
` recorderRef.current = new RecordRTCPromisesHandler(currentStream, {
audioBitsPerSecond: 192000, // this gets clamped to 128k
bufferSize: 1024,
desiredSampRate: 44100, // 44100
mimeType: fileType === "audio/wav" ? "audio/wav" : mime,
numberOfAudioChannels: 1, // 2
timeSlice: Number.parseInt(state.timeSlice, 10), // needs to be a number
type: fileType === "video/webm;codecs=vp9" ? "video" : "audio",
recorderType:
fileType === "audio/wav"
? StereoAudioRecorder
: MediaStreamRecorder, async ondataavailable(blob) {
const localCount = count.current + 1;
count.current += 1;
setPartNumber(localCount);
const endTime = Date.now();
//calc start stop time and set it
const chunkStartSeconds = (chunkTimes.current.chunkStartTime - chunkTimes.current.streamStartTime) / 1000;
const chunkEndSeconds = (endTime - chunkTimes.current.streamStartTime) / 1000;
// send blob to cloud
handleBlobSave(
blob,
localCount,
fileType === "audio/wav" ? "audio/wav" : mime,
streamData.s3FilePath,
chunkTimes.current.sessionStartTime,
chunkStartSeconds,
chunkEndSeconds,
endTime,
streamData,
header
);`
I'm assuming this has to do with the use of setTimeout either in your app or somewhere in recordRtc (https://developer.mozilla.org/en-US/docs/Web/API/setTimeout).
Unfortunately setTimeout can't be used to reliably capture any duration. Ex: https://stackoverflow.com/questions/21097421/what-is-the-reason-javascript-settimeout-is-so-inaccurate
Best workaround I've found is using a worker (which operates outside the main thread) for the setTimeout functionality.
We have web app that is set to record and upload 10 second chunks using recordRTC on chromebooks (as well as chrome on macs where we test the app).
We're finding that sometimes, the chunks are less than 10 seconds in duration. We've timestamped the end times of each chunk and sure enough, ondataavailable(blob) is called every 10 seconds.
However, the blob data with the chunk is sometimes as short as 8 seconds of audio+video data. And, typically, when we see an 8 second chunk, it's usually followed by a 12 second's of data chunk (though it arrives on the 10 second timeslice).
Finally, when we concatenate all of the chunks we get a full stream that is correct.
What would cause this? Have you seen this? We really need the blobs to be 10 seconds long when they are uploaded.
Thanks.
(attached is an uploaded chunk that is approx 8 seconds long but should have been 10.. this is chunk #10. and the subsequent chunk #11 which is about 12 seconds long) uploadedChunk10.webm uploadedChunk11.webm