Build slug: d380e56e9
Our recording client now dynamically scales the video bitrate based on resolution on all browsers (previously, this was only done on Safari). This improves video quality, particularly when:
We’ve also aligned bitrate values more closely follow YouTube's recommendations for SDR video at 30fps.
Our documentation has been updated with the latest bitrate details used by the recording client.
Build slug: 1e2c84b63
P.S. For more details, see our in-depth blog post on MediaRecorder video bitrates.
We've aligned the file upload order for the push to our storage mechanism with all the other push to storage mechanisms.
Previously, the raw recording, when enabled, was pushed first, rather than the processed MP4 recording.
Now the following order is respected across the line:
The storage logs for S3, (S)FTP, Dropbox, and Pipe-complementary storage have received significant improvements.
All storage logs are now independent per file, meaning that each recording and all its associated files (processed recording, raw recording, snapshot, filmstrip, and extracted audio file) will have their own storage logs with specific details.
This will allow you to better track the storage of your recordings and see any issues that may arise in more detail.
Several errors (regarding permissions, connection and getUserMedia that previously blocked the recording client have been migrated to be non-blocking:
getUserMedia errors from blocking to non-blocking.All of these errors now include a "Click here to retry" button. Clicking it reloads the recording client, without refreshing the entire tab.
Build slug: 0dc9ed67a
We significantly improved how we handle very high-resolution videos (e.g., 8K) on our processing servers.
These changes are especially impactful when the processing servers are under high load, and also allow us to process more such recordings simultaneously without hitting hardware limits.
^ These are all related to known onmute events received from the browser. Only one blocking warning message remains (Safari's Pause used before recording).
Migrated some audio warning messages from maybe muted to muted.
The muted warnings are now yellow.
The maybe muted warnings are now green.
The related documentation has also been heavily updated.
If the microphone device is muted before initializing the recorder, and we know about it, a warning message is now shown immediately.
Build slug: 71ee6c16b
We simplified the detection logic for silent microphones. The silence evaluation now runs repeatedly every 5 seconds (instead of just once, after 15 seconds), and evaluates the last 5 seconds. If the value is below the threshold, the warning message is shown to the user. As soon as the instant RMS value exceeds the threshold, the message is removed.
In our tests, the mechanism works better under heavy stress (CPU Burn Loop & DOM Thrash).
The RMS threshold is now configurable through the new pipe-rmsthreshold embed code option.
Build slug: 1c8374a84
The concurrency mechanism keeps track of how many recordings can be processed simultaneously for each account. It only kicks in when the processing server is under high load.
We've made a slew of changes in how it works behind the scenes to make it more robust in the face of external errors.
We fixed an issue where the low-audio warning message could briefly persist after switching to a different microphone, even when valid audio input was present. The warning now clears correctly when changing devices.
We adopted a universally accepted RMS (root mean square) calculation for measuring the microphone input level. We also set the threshold for showing a warning message to below the room-silence level based on 30+ tests with different microphone devices. The threshold is 0.00002.
Build slug: a21aea38f