Changelog

We added seek functionality in playback mode for the (desktop) recording client delivered by embed code 2.0. This improves the playback experience by allowing the movement to a specific point in a recording by dragging across the progress bar or clicking the progress bar.

The seek functionality works on both desktop and mobile devices (when using the desktop recorder inline on iOS or Android). On mobile, it works by dragging or clicking across the entire lower half of the recorder.

On older Android devices, if our inline desktop recorder was configured to record at a high resolution (720p or higher), you’d get an “Unexpected error occurred” error in recent versions of Chrome when clicking the red record button.

This issue is now fixed.

On such devices, we’re now falling back to VP8 video encoding instead of the more resource-intensive H.264.

The build code (git commit slug for the master branch) is now part of the 2.0 pipe.js.

It will be logged to the web developer console together with the build date and will be sent to our precheck script.

This will allow you to understand what build you’re using, what build is currently live and when was the last build.

It will allow us to understand what builds are out there in the wild.

Previously, with the 2.0 HTML code, the recording client was inserted using a newly created <div> element with an id attribute matching the id of the <piperecorder> tag.

This was problematic because:

1. you ended up with 2 HTML elements with the same id on the page
2. any width/height properties on the initial <piperecorder> tag would take up space separate from the space occupied by the actual recording client. This made any effort to avoid layout shift impossible.

We are now inserting the recording client HTML code directly inside the <piperecorder> tag.

This is how the HTML structure looked previously after insertion:

<div id="custom-id">
    <div id="pipeRecordRTC-custom-id"></div>
</div>
<piperecorder id="custom-id">

This is how it looks now:

<piperecorder id="custom-id">
    <div id="pipeRecordRTC-custom-id"></div>
</piperecorder>

The 2.0 JS insertion mechanism remains unchanged as it is similar to the new 2.0 HTML mechanism.

A documentation article on how to avoid layout shift will also be available soon.

The push to S3 integration has been updated to support a None ACL option. The new option is visible in the dashboard S3 storage section under Canned ACL.

New Amazon S3 buckets and Google Cloud Storage buckets now have ACLs disabled by default. For such buckets GCS needed the None option. Without it would throw the following error:

Cannot insert legacy ACL for an object when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access

le: None is now the value selected by default in the drop down.

The search filters for recordings under https://dashboard.addpipe.com/recordings got a small update:

• new filter: Failed to process (all)
• new names/labels
• better descriptions
• bug fixes

A minified version of pipe.js is now available for the 2.0 embed code.

The minified version (pipe.min.js) is roughly 11,5% smaller in size than pipe.js when comparing the compressed versions (gzip) that get transferred.

You can point your embed code to it using the following URLs in the <script> tag:

1. worldwide AWS CDN: <script type="text/javascript" src="https://cdn.addpipe.com/2.0/pipe.min.js"></script>
2. directly from our EU delivery servers: <script type="text/javascript" src="https://s1.addpipe.com/2.0/pipe.min.js"></script>

le: the docs are online too: https://addpipe.com/docs#using-minified-pipe-js

Our desktop video recording client finally got a playback progress bar. The visual indication of the playback position should be useful especially for longer recordings. Until now, the only indication was the current/total time display. The playback bar is not interactive for now.

We added a new attribute called “capture” to the embed code 2.0.

The “capture” attribute provides control over which camera should be used by the user agent on startup of the recording client. This “capture” attribute is specific to the native mobile recording client.

For more information on how to work directly with the embed code and utilize the new “capture” attribute, please refer to the documentation. There are detailed instructions provided on implementing the new attribute in your native mobile recording client.

Chrome 114 introduced a change that explicitly limits how mime types need to be specified, which affected audio only recordings made by the Pipe recorder.

We’ve deployed a new build of pipe.js which addresses this change.

The 2.0 embed code and desktop recording client now support all CSS units for width, including relative units.

• Embed code improvement: You can now specify the width of the desktop recorder using any CSS unit such as px, %, vm, etc. .
• Desktop recording client improvement: support for absolute and relative units for width in the desktop recorder delivered by the 2.0 embed code. As a result, the 2.0 recording client is now responsive.
• Improved positioning of elements: In the recorder window, all elements now have their independent style. This improvement ensures that these elements remain perfectly where they should be even when dealing with relative width values and across different screen sizes. Regardless of the width settings or the device used, the positioning of elements within the recorder window is consistent and visually pleasing.

The recently rolled-out unified subscription page will now show better information for cancelled subscriptions that have not yet expired including when you will be able to subscribe again.

In the account dashboard, a new unified /subscription page now contains all the information about:

1. subscription options if you’re a trial
2. your current subscription ad upgrade/downgrade options if you have an active paid subscription
3. your expired subscription and re-subscription options if you have an expired subscription

This new unified page replaces 5 other pages and will make it easier for us to present accurate subscription & pricing information.

The page is available at https://dashboard.addpipe.com/subscription

Chrome 111 was released Tuesday, March 7, 2023, and it introduced a breaking MediaRecorder API change which resulted in corrupt recordings made by the Pipe recorder.

We’ve caught the bug quickly and implemented a workaround in our code in pipe.js (embed code v1.0 and v2.0) to circumvent the issue until Chrome fixes it.

If you are using a self-hosted version of pipe.js we strongly recommend that you update it, or better still, use the one delivered by Pipe to ensure you have access to the latest features and fixes soon as they are released.

We’ve just rolled out a new feature in the Beta phase that allows you to whitelist the hosts where the Pipe embed code can be added. This is useful to prevent abuse from malicious users that could embed your generated Pipe embed code on other websites.

The whitelist can be set up at the environment level so that you can have specific whitelists for each of your environments that could be related to different websites.

Access the new Whitelisted hosts section by editing any of your environments and add the hosts you want to whitelist.

The list will be empty by default, meaning any host will be allowed.

For more information about this new feature, you can read the documentation.

We have reviewed and updated our webhook documentation and the webhook simulator data from the account dashboard.

1. Aligned the docs and simulator examples with the actual webhook data fired in production (added missing elements, removed excess elements, aligned data types, corrected lowercase/uppercase values)
2. Used real data instead of some placeholders for the webhook simulator & docs (md5 & sha-1 values, region, bucket name, etc.)
3. Clarified the moment when the video_recorded webhook is sent
4. Clarified that the video_converted webhook is not sent if the mp4 output is disabled in the Transcoding Engine
5. Clarified all the possible values for the type parameter that’s present in many webhooks
6. Removed cutToLength parameter from the video_converted webhook examples and parameters explanations (it does not exist in the actual webhook body)
7. The storedStatus parameter, part of video_copied_pipe_s3 webhook, is now covered in the docs
8. application/json is now the principal webhook type in the docs

We fixed a bug in the Pipe Account Dashboard’s Transcoding page that resulted in an error (500 HTTP status code) when an account with a Standard subscription made any changes to the settings available on the Transcoding page.

There are currently 2 settings available on the Transcoding page available to accounts with Standard subscriptions:

1. enable “Cut to length” (it is disabled by default)
2. disable “.jpg snapshot output” (it is enabled by default).

This issue affected all Standard users.

We fixed a bug that caused the webhook signature to be generated incorrectly by Pipe in cases where the custom payload parameter value contained a + character.

Our FTP implementation has been updated with support for Explicit FTP over SSL/TLS. The recording files can now be securely pushed to your storage through FTPS.

Details in the blog post @ https://blog.addpipe.com/ftps/ .

We have expanded our Amazon S3 Storage with three more regions:

1. Zurich (eu-central-2)
2. Jakarta (ap-southeast-3)
3. UAE (me-central-1)

The object URLs for files pushed to your S3 storage will be available regardless of the canned ACL used in the upload process. These URLs are visible in the account dashboard’s s3_logs page and are sent with the videocopieds3 webhook.

The blog post goes into detail.

https://blog.addpipe.com/s3-object-urls/

We have aligned the FTP behavior between the FTP test and the actual FTP push attempts with various FTP folder values (empty string, /, or any other folder value).

Changes to Dashboard FTP test #

• More descriptive log messages.
• We stopped trying to make active FTP connections.
• We now print the connection timeout and connection established times.
• The file which is uploaded during the test is now removed from your FTP server at the end of the test.
• The FTP test’s timeout value is now aligned with the actual FTP push attempt’s timeout (10 seconds instead of 20 seconds).

Changes to actual FTP push attempt #

• We stopped trying to make active FTP connections.
• As a result, we have stopped pushing the addpipe-ftp-test.test file with every group of recording files. The file was pushed in an attempt to test if the passive connection mode succeeded.
• We added e new error code, FTP_PASV_FAILED.

You can now test your SFTP connection and credentials from the Pipe Account Dashboard.

Now you will be able to test if the connection goes through, if the credentials are correct, if the folder provided exists and if the user has write permission.

The test will also print the timeout value and the working folder and warns you if the user has shell access.

The test will upload a file named addpipe-sftp-test.test.

For the SFTP test to succeed, the port 22 needs to be opened for our account dashboard IP (116.203.232.162).

We finally separated FTP and SFTP storage options. You will see the separation in the Pipe Account Dashboard (credentials and logs) and the documentation.

FTP (File Transfer Protocol) and SFTP (SSH File Transfer Protocol) are 2 diferent protocols.

Moving forward, we expect to deprecate FTP because it is inherently insecure. We plan to add support for FTPS (FTP over TLS). This separation will clear the way for that effort.

The embed code generated in the account dashboard now enforces HTTPS for the two main assets: pipe.js and pipe.css. Previously it inherited the protocol used to deliver the page in which the code was embedded.

Separately, the Pipe recording client also enforces HTTPS for POST communication and asset loading. Previously it inherited the protocol used to deliver the page in which the code was embedded. This is important for kiosk-like applications where the pages are usually delivered over HTTP/localhost.