Changelog

The Pipe account area shows many dates & times.

Some (recordings, logs, etc.) reflect the date & time in the city defined in your account settings while others (billing, usage, sign-ins, contracts, etc.) reflect the date & time on our servers which are set to Bucharest/Romania time.

If some of these dates & times had inaccurate or no accompanying context regarding the city of reference and timezone, they now do.

We’ve fixed an issue where if the following 4 clauses were met:

1. screen recording
2. made with Chrome
3. that captured a window (not the screen)
4. the window was resized during the recording process

the Chrome browser would produce a .mp4 file that had several sections in several resolutions. Such .mp4 files would not play in Safari, QuickTime, and VLC on Mac.

We’re now analyzing Chrome screen recordings where the source is a window (window:*:* for camera name) and, if they have sections in different resolutions, we’re converting the entire file to a single resolution .mp4 video file which plays correctly on all browsers and desktop players.

The resolution used for both the video and the snapshot will be the resolution of the 1st section/frame. All other sections will be stretched to fit this resolution (this is similar to how Firefox addresses the problem).

Here’s how a recording with 7 sections in different resolutions (height differs between the segments) looks when analyzed:

In light of some users recording a video in the morning and saving it in the afternoon (with a Pipe integration that had Do Not Save activated.) we’ve made it more clear in our documentation and in the account area that we’re deleting unsaved recordings made with the desktop recorder from our media servers 1 hour after the recording has finished writing to disk.

We keep the file on the media server for both playback and to wait for users to review it and (manually) save it.

In some cases, we might keep the file for longer (like when we need more time to copy it to the transcoding server).

We’ve fixed an issue where recordings with 422 chroma key or 10 bit colour would be processed by our platform but the resulting .mp4 file would not play in Safari. We’re now converting such videos to yuv420p or yuvj420p.

Here’s the full list of formats we’re converting:

• yuv422p
• yuvj422p
• yuv444p
• yuvj444p
• yuv420p10le
• yuv422p10le
• yuv444p10le
• nv12
• nv16
• nv21
• nv20le

We’ve only seen a few of these formats in our production environment.

Here’s a good 10 bit colour and chroma key explanation on YouTube.

Next week we’ll start rolling out a 2nd US region on the east coast to complement the existing one on the west coast.

US2 Details:

• recording will be made against media servers in NY
• our storage will be on an S3 bucket in N Virginia
• webhooks will be fired and files will be pushed to your storage from 68.183.96.15
• URL example for recording stored by us https://us2-addpipe.s3.amazonaws.com/1edfef4c4967d69b7129ec3ffa534002/GBRsMl19YtbqwaFfRYCeX1rU4Rm05kRx.mp4
• JS API location parameter value us2-addpipe.s3.us-east-1.amazonaws.com
• recordings made against this region will be labeled with us2

Lots more details in the blog post.

We’ve made improvements to the list of recordings:

• The major browser and OS version for every recording is now shown on page (without having to hover with your mouse)
• FIX: the recovered sign (R) was not shown for recordings made with the inline recorder on Chrome on Android
• Made it more clear when a recording is a desktop upload or mobile upload
• Better wording around not yet copied recordings

We’ve reviewed how we keep track of and how we present information about the Terms of Service, Privacy Policy, and Data Processing Agreement you’ve agreed to (on signup up or through the account area).

You’ll now see more granular information in https://addpipe.com/contracts and several pop-ups throughout the Pipe account area asking you to agree to some of these documents if you have not done so already.

At the bottom of the account page, we’ve clarified that when deleting an account we’ll also delete:

• the Google id for Google accounts
• the information from our messaging software (Intercom)

Through the native mobile recorder.

Not anymore.

You can now export your monthly and historic usage to a comma-separated .csv file (the dot is used as a decimal separator) from https://addpipe.com/usage. It also works for yearly and 6mo plans.

To import the resulting .csv file in Google Sheets:

1. Go to https://sheets.google.com/ and create a new spreadsheet
2. Click File > Import and upload the exported .csv file from your desktop
3. In the Import file modal select the Comma for Separator type (just to be sure)
4. You can replace the cells in the Cost columns and Total rows with formulas to verify our calculations

Now you can further integrate Pipe by tracking the upload percentage.

We’ve added a new event API that tracks the upload progress of the desktop HTML recorder, mobile native recorder, and the direct desktop upload.

The event functions are named as follows:

• onUploadProgress for the desktop HTML5 recorder
• onVideoUploadProgress for the mobile native recorder
• onDesktopVideoUploadProgress for the direct desktop upload

For further details read the updated documentation for JavaScript Events API (Desktop recorder) and JavaScript Events API (Mobile native recorder).

The new event functions are available for both the embed code 2.0 and embed code 1.0.

• NEW: You can now search your recordings by 2 new additional filters: custom payload and recording name
• NEW: Added a confirmation dialog when deleting recordings from the Recordings section
• NEW: Embed code 2.0 is now the default embedding option
• NEW: Password reset requests are now shown in the Sessions section
• NEW: Chrome: we’re now logging to the browser JS console whether or not Feature Policy allows camera and microphone access (details here)
• FIX: Fixed an issue with some User Agents not being correctly shown
• FIX: Fixed issue with video player being bigger than the play window in the recordings section
• FIX: Correct error message is now shown in the Pipe desktop recorder when a NotReadableError is thrown in case of an audio source

January 2020 Update: The new Chromium based Edge 79+ behaves exactly the same as Chrome. This means that screen recording with system sounds is supported and works exactly as described below for Chrome.

Capturing the system or tab sounds is now possible when using Chrome 74+ and the Pipe desktop recorder to record your screen or a tab.

A new option will now show up in the Chrome screen sharing dialog which allows the user to share the sound when recording the screen or a tab. It is up to the user to share it.

When one chooses to share the audio, it will be captured together with the microphone input (if present) in one merged audio track.

The feature works in the following 3 situations:

• On Windows, when recording Your Entire screen (all of the system sounds will be captured) OR when recording a Chrome tab (only the tab sound will be captured).
• On macOS, when recording a Chrome tab (only the tab sound will be captured).
• On Linux, when recording a Chrome tab (only the tab sound will be captured).

You can not capture the (window) sound when capturing/sharing just a window.

You can not capture the system sounds on macOS when capturing/sharing your entire screen.

The feature is only available with Pipe recording clients embedded with the 2.0 embed code.

📱 Great news! From now on, if the mobile native recorder is disconnected from the Internet during an upload, a reconnect attempt will be made each second.

Once the connection is re-established, the interrupted upload will start from the beginning.

When embedded inside a multipart/form-data form, the mobile recording client and desktop uploading client would cause an issue where the selected file would be uploaded twice: when it was uploaded through our recording client and when the form in which the client was embedded was submitted. This issue was very visible with large files.

This no longer happens.

The EU bucket was correctly configured. Only the US bucket needed a fix. Both buckets we use to store recordings have CORS enabled meaning that if you send in your GET request the Origin header, the S3 bucket will reply with the actual recording together with the following headers:

Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000

We’ve added storage logs for our own storage in our continuous pursuit of making Pipe the best platform it can be.

We saw the need for these logs as a result of the recent Amazon S3 issue.

You can access these logs as you would with any others from the logs section.

The recent release of iPadOS 13 introduced a change that caused Safari on iPadOS to present itself to websites as Safari on Mac!

This resulted in Pipe delivering the wrong recorder: the desktop version instead of the mobile native recorder.

This issue has now been fixed and Pipe will deliver the mobile native recorder on iPads running iPadOS 13 👍.

A new APIs & Integrations page will make it easy to find all our:

• APIs (JavaScript, REST, POST, etc.)
• direct integrations (S3, Dropbox, etc.)
• plugins
• integration tutorials (Squarespace, SurveyGizmo, etc.)

The new page is in your Pipe account area under Account > APIs & Integrations

We’ve updated the sessions page inside the Pipe account area:

• FIX: date column now correctly shows the sign in date & time (it was mistakenly showing the last activity date & time)
• FIX: removed duplicate session info on failed sign in attempts
• NEW: we’re now showing the last activity date & time in a new column

The environment IDs are now 6 character long alphanumeric strings.

All the newly generated embed codes will contain the alphanumeric ID as the value for the eid parameter.

The environment edit section now shows the alphanumeric ID.

This change is fully backward compatible and does not impact older embed codes that use the numeric environment ID.

For better security, we advise you to update the value of eid with the new alphanumeric ID for the embed codes you already have in your websites or apps.

Here’s the new ID in a 2.0 HTML embed code:

When pushing files to Amazon S3 you can now choose between 4 of their storage classes:

• Standard (default)
• Standard-Infrequent Access
• Intelligent Tiering
• One Zone-Infrequent Access

The options are available in the s3 section inside the Pipe account area.

You can find out more about each storage class here and here.

All the storage options(S3, (S)FTP, Dropbox) have been grouped inside a new section called, you guessed it, Storage.

In this new section, we’ve also added all the information about Pipe’s own storage.

The Do Not Store setting has been moved from the environment options to the new storage section.

At this time the Pipe platform supports only IPv4, however, the CDN part of the platform had IPv6 enabled until now, which led to cases where a US user connected to the Internet through IPv6 would be directed to the EU region. Such connections defaulted to the EU region if the region setting on the Pipe account was set to Auto-detect.

To fix this issue, we’ve disabled IPv6 on the CDN.

• NEW: center position for watermarks
• FIX: added support for audio/amr to the mobile native client
• NEW: moved all billing details and the cancel subscription button under the new Subscription section
• NEW: we’re now also showing the sum for failed payment attempts
• FIX: updates to the reconnection mechanism (fix when the user presses the STOP button while the recording client is disconnected
• The HTML5 recorder is now used instead of the Flash one on localhost, 127.0.0.1 and ::1 on both Chrome 63+ and Firefox 50+ (localhost is a secure origin). JANUARY 2020 Update: this also applies to the Chromium based Edge 79+
• We’re now defaulting to the 640x360 @ 30 fps resolution for the recorder in the Pipe account area