Changelog

We fixed an issue where recordings that stopped exactly at the configured time limit would display an inaccurate duration during playback.

Build slug: bc3ec0ca2

We removed the “Waiting for data…” message that could briefly appear at the start of a recording and fixed the timer staying at 0 during that period. The recorder now silently waits for data to arrive, and the timer counts up correctly from the moment the recording starts.

Build slug: bc5a4a92f

1. We fixed issues with logging during EU region fallback.
2. We made minor adjustments to client-side variables to ensure server-side logs are recorded with more accuracy.
3. We added an extra safeguard when sending recording chunks through the WebSocket connection to the server.

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:

1. recording at resolutions higher than 480p with capable webcams
2. recording on mobile devices (which already ship with capable cameras)

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:

1. MP4 processed recording
2. Raw recording
3. Snapshot
4. Filmstrip
5. Audio track

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:

1. If you deny camera & microphone permissions, you can now retry without refreshing the page (after permissions are given). Tested Chrome, Firefox and Safari.
2. The error message shown when an existing connection is lost and a new connection can not be re-established is now non-blocking, it allows you to retry the connection.
3. Migrated unexpected getUserMedia errors from blocking to non-blocking.
4. If you cancel the screen recording surface selection dialogue (Chrome) or block the screen permission (Safari, Firefox), you can now retry without refreshing the page.

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.

1. Migrated most warning messages regarding muted devices from blocking to non blocking. Some examples:
   1. Mute triggered through (Logitech) keyboard key
   2. MuteKey app on macOS
   3. Chrome: macOS level input volume set to 0 in System Settings > Sound
   4. Safari’s Pause Camera & Microphone option used while recording

^ These are all related to known onmute events received from the browser. Only one blocking warning message remains (Safari’s Pause used before recording).

2. Migrated some audio warning messages from maybe muted to muted.
3. The muted warnings are now yellow.
4. 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

We’ve added a new “Troubleshooting Recording Issues” page to our documentation, currently covering microphone input issues and common audio-related warnings.

Copy change: in the recording client, the low audio input warning text has changed from “Your microphone might be muted by your system settings.” to “Your microphone is muted or the volume is too low.” to better reflect the actual situations in which we can replicate it.

Build slug: 23269305b

We introduced two new JS API events: onAudioDeviceChange and onVideoDeviceChange. These events are triggered whenever the active audio or video input device is successfully changed. Each event provides the MediaTrackSettings of the newly created audio or video track.

Build slug: d4a29d0af

You can now specify the fps for screen recordings through pipe-gdmconstraints. The value is taken into consideration for both simple screen recordings and screen recordings with facecam.

Build slug: eac4c46a3

1. Resolved an issue where the video feed could freeze when recording the screen and camera, then switching away from the recording tab (to another browser tab, to a different virtual desktop, etc.).

2. fps value passed through pipe-gumconstraints was ignored

3. Improved performance when using background effects (background blur or background color), with noticeable gains on mobile devices.

Build slug: ad04e6930

We’ve just launched a new recording, processing & storage region in Europe, the EU3 region, expanding Pipe’s European infrastructure to deliver better performance and increased reliability for your recording needs.

You can read more about it in our blog post.

We’ve optimized the recording client to improve performance when using background effects (background blur or background color) and when recording the screen with a webcam overlay.

Build slug: e76c28259

A new JavaScript API event, onHostVerificationFailed, has been added to the recording client. This event is triggered whenever the client is embedded on a host that is not included in the whitelisted hosts list.

Build slug: d06e2f5a6

We fixed a Safari-specific issue where enabling the real-time background blurring effect would result in a “double-image” effect instead of a properly blurred background.

Build slug: 31b7f3c81

We fixed a bug where starting a new recording while a video was playing back would leave the preview video in the bottom-right minified position. The video preview now correctly returns to its original, full-size position when a new recording is started during playback.

Build slug: 3a472ceac

We fixed several Safari-specific UI issues in the recording client. Icons in the bottom menu are no longer cut off, and hover interactions have been fixed to prevent icons from twitching or shifting unexpectedly.

Build slug: b8ae38714

We fixed an issue in Safari on iOS and macOS where video recordings used a hardcoded bitrate of 5Mbps regardless of resolution. This limited video quality when recording at high resolutions. The recording client now applies resolution-appropriate bitrates, ranging from 0.3 Mbps for 240p up to 14 Mbps for 4K recordings. We’ve also updated the documentation to include these bitrates.

Build slug: 4df062d59

1. The playback seek bar now accurately reflects the recording’s current playback position on Safari as well.
2. The save button in the recording client has been updated from an HTML <button> element to a <div> element. This change aligns it with the rest of the recording client buttons, which are all implemented as <div> elements .

Build slug: 7c845b616

1. The playback seek bar now accurately reflects the recording’s current playback position on Chrome and Firefox. Previously, the progress indicator could reach the end while the playback continued briefly.
2. When the recording client falls back from video to audio-only mode and then returns to video mode after a camera is reconnected, the audio visualizer waves are now correctly removed from the center of the recording client, preventing them from overlapping the video.

Build slug: 70097637a