Changelog

Version 1.0.2 of our WordPress plugin is now available. This update ensures that both pipe.js and pipe.css are only loaded on pages or blog posts where they are needed.

We have updated our pricing page in order to clarify audio only pricing. Additionally, we have built an interactive pricing calculator, which is available in this Google Sheets document.

We’ve made some updates and fixes to our recording processing pipeline, which address the following issues:

1. iOS 18 mp4 recordings were out of sync after processing
2. Some of the already corrupted recordings were having their duration miscalculated.

We’ve rolled out a new desktop recording client build, which includes a new near real-time warning for when the microphone input is detected as very low.

You can read more about this in this article.

When using the upload existing recording option in the desktop recording client you can now re-upload a (new) recording - without refreshing the page - if you upload the wrong file (like with the wrong extension) and an error occurs.

The getPlaybackTime() JS API (v2.0) method has been updated to provide correct values when buffering or pausing occurs (during playback).

• The 2.0 desktop recording client will now rely on the browser specific API (window. isSecureContext) to determine if it is run in a secure context or not. This means it will consider more origins/contexts as secure including file:// and subdomains of localhost. We’ve also added a new docs section on the topic.

• Firefox will now show a red microphone icon when the user revokes any of the mic or cam permissions.

We realized the internal logs retention period (basically 30 days 31 days inclusive of today) for our storage, webhooks, and getUserMedia() logs was not immediately obvious. So, we added it to many relevant locations in the account dashboard and documentation.

A new WordPress plugin with minor updates is now available as version 1.0.1 . You can read more about it in the documentation.

We’ve updated the desktop recording client with a new multi-bar microphone input animation that reflects audio frequencies in real-time, replacing the single-bar design. In audio-only mode, additional bars are displayed in the video area. The animation is sensitive enough to detect subtle sounds, helping users identify and troubleshoot low or missing microphone input before recording. You can read more about it in the official blog post.

The 2.0 desktop recording client now includes several outlines for better positioning your head & body during video recordings. The feature can be turned on by setting the new embed code option outline to one of the following values:

• face (face outline)
• dotted face (dotted version)
• avatar (full torso outline)

The zoom of the outline can be adjusted by using the outlinezoom embed code option that takes values from 1 to 100 (1% - 100%). The default value is 60 (meaning 60%).

The opacity of the outline is currently fixed at 50% and the color is white.

Read more about it in this blog post.

Starting today, expired trial accounts will have access to most dashboard pages:

• recordings page
• S3, (S)FTP, FTPS & Dropbox pages
• environments, webhooks, logs, etc.

Until now, access was allowed only to account management pages.

All the buttons in the account dashboard that make a request and wait for a response now have a working state with a relevant label and animation.

The webhook page in the account dashboard received several updates:

1. creation time and last modified time are shown, when available, in your account’s timezone
2. pagination has been added, 50 webhooks per page
3. refactored the View Schedule, View Logs, Simulator, and Settings buttons into links (they were links all along)

A new npm package called @addpipe/react-pipe-media-recorder is now available. This package simplifies the integration of the Pipe recorder into React applications by streamlining the setup process, making it faster and more straightforward to embed Pipe’s recording client within React projects.

For more details, check out our blog post and the official NPM page.

Our latest build includes styling updates to ensure consistent appearance across various style libraries, such as Tailwind and Bootstrap.

You can now control what PII data Pipe will collect and store together with each recording:

1. Camera name
2. Microphone name
3. Referer (via window.location)
4. User agent header
5. IPv4

By default, Pipe collects all of it.

You can access this new setting by editing any of your existing environments or when creating a new environment.

For this setting to work correctly for the referer, camera name and microphone name, you need to use the latest version of the 2.0 recording client (pipe.js hosted by us). If, for some reason, you’re self-hosting pipe.js, you need the 21st of October 2024 release or newer.

For a more in-depth look at the feature, read the blog post.

Today, we are launching a new recording region: Canada or CA1 for short.

You can select this new region when creating a new environment or by editing an already existing environment from your account dashboard.

CA1 region details:

• region is opt-in for now
• recordings will be made and processed against servers located in Toronto hosted with DigitalOcean
• If you choose to store the recordings on Pipe’s complimentary storage, the recordings will be stored in an Amazon S3 bucket located in Montreal.
• webhooks will be fired, and recordings will be pushed to your storage from the IP 165.227.38.98
• Amazon S3 bucket storage link example: https://ca1-addpipe.s3.ca-central-1.amazonaws.com/ACCOUNT_HASH/RECORDING_NAME.EXTENSION
• recordings made against this region will be labeled with ca1

le: blog post is available with more details

We have improved how the desktop recording client responds to situations where audio or video data becomes unavailable.

This can occur, for example:

1. on Firefox when the user clears previously granted permissions
2. on Chrome when the user resets previously granted permissions
3. on Chrome when a computer goes into sleep mode while the desktop recording client has access to the camera and/or microphone.

With this update:

1. The recording process will automatically stop if both audio and video data captured are no longer available during a recording.
2. If only audio is being recorded, the recording process will stop if the audio data becomes unavailable.
3. If data becomes unavailable while the recording client is idle, the desktop recording client will automatically request permissions again when the user attempts to start a new recording.

A new WordPress plugin called “Pipe Recorder” is now available.

The plugin makes the integration process much easier and straight forward.

You’ll find more information in the blog post.

There’s also a new documentation section that covers it.

We resolved an issue where, while recording, oversized chunks (recording slices) were created by the browser, but, because of their size, they were refused by our ingestion servers. This caused the desktop recording client to fall into a re-connection loop and the oversized chunk and further chunks were never received by the server.

We implemented a new client side mechanism to split these huge chunks - that exceed the maximum size we accept on the ingestion server - into smaller pieces before sending them to our ingestion servers.

Generating such a large recording chunk was a very rare issue. Even though it happened on vanilla browsers (Chrome on Windows, Chrome on Andorid, etc.) we were only able to replicate it and find the root cause (a browser bug) on Safari on macOS/iOS.

le: we were also able to generate large chunks on:

1. Chrome on Android by locking the screen while recording: large chunk is generated when you unlock the phone
2. Chrome on macOS/Windows by entering sleep mode: large chunk is generated when you stop the recording

We also wrote a blog post on the subject.

Every webhook payload now additionally contains the environment code of the environment in which the recording was made. It can be retrieved using the new envCode attribute.

The environment code is the unique alphanumeric string identifier of the environment. You can find this value in your Pipe account dashboard in the environment settings.

We resolved an issue where the “timeout” message appeared in the Recording Client on very slow internet connections, causing it to become unresponsive with no further reconnection attempts. Now, if a disconnection occurs, the Recording Client will automatically attempt to reconnect up to 30 times.

A new embed code option called hidesave has been added to the 2.0 Recording Client. When set to 1, it hides the save button that appears when autosave (asv) is disabled (asv = 0). The default value of hidesave is 0.

Previously, when autosave was disabled, a save button was visible by default without the possibility of hiding it. Now, the save button will still be visible when disabling autosave, but it can also be hidden by setting hidesave to 1.

If both autosave (asv = 1) and hide save (hidesave = 1) are enabled, the recording still saves automatically as usual.

In the dashboard, under /recordings, we’ve fixed the date filter so that:

1. it allows you to show the recordings from just 1 day
2. when selecting an interval, the recordings from the last day of the interval will also be shown