Pipe changelog
Pipe changelog
addpipe.com

Screen recording permissions and UI updates

 

Improvement

 

 

We've made a few changes recently to our screen recording solution.

Now the recorder will first ask permission to use the microphone and then ask permission to record the screen. It used to be the other way around, which caused issues when choosing to record a tab.

Given the fact that recording the screen is a lot more privacy intrusive than recording with a webcam and can pose a security risk, best practices dictate to make sure that the user is the one asking the screen to be recorded and not a malicious actor.

To this extent, we've added an extra step needed to be taken after choosing the [Record Screen] option.

image.png

The [Select screen for capture] is no longer a simple text, but a button that needs to be clicked in order to select the window/screen you wish to capture and ask for permission for doing so.

Full HD resolution option can now be easily enabled from the embed dashboard

 

New

 

 

You can now choose the 1080p resolution option directly when generating your embed code if you wish to record Full HD videos (PRO accounts only).

image.png

Keep in mind that even though you may ask for the 1080p resolution from the camera, not all webcams are Full HD capable, so the browser will default to the nearest resolution supported by the webcam.

Fixed issue with max size value

 

Fix

 

 

Today we've fixed an issue where the max value for our size metadata for both the source file and the processed mp4 was limited to 2GB (or 2147483647 bytes more exactly).

The source file size metadata was shown in the Pipe account area's recordings page. The processed mp4 size metadata, apart from being displayed on the above page, was also used in calculating the bitrate and was available through the REST v1 API and five webhooks.

Screenshot 2021-08-03 at 14.06.32.png

There were only 68 recordings in our database where the source file's size was maxed out and 49 where the processed file's size was maxed out.

Webhooks can now be sent with Content-type: application/json

 

New

 

Improvement

 

 

Until recently, the webhook data was sent only as application/x-www-form-urlencoded.

Now you can choose between sending the data the old way as application/x-www-form-urlencoded OR the new way as application/json.

All new webhooks will default to application/json.

image.png

All existing webhooks will continue to be sent as application/x-www-form-urlencoded, unless you choose to change them.

The content type of the webhook will be reflected in the schedule and logs pages of the webhooks section. Also, the webhook simulator will allow you to test the webhook with both content types.

Fixed issue with the recording not stopping at the maximum recording time (mrt setting) if the recorder was removed from DOM

 

Fix

 

 

Until now, if the Pipe desktop recording client was removed from the DOM before hitting the maximum recording limit, the recording simply continued forever until the user left or closed the webpage on which the Pipe recording client was embedded on.

The issue has been fixed today when we rolled out new, updated client side (pipe.js) files.

This only occurred when the Pipe recording client was removed using custom JS code. Removing the Pipe recorder with the built in remove function worked as expected and is the recommended way to remove Pipe from a webpage.

Aligned and slightly higher file size limit for uploads

 

Improvement

 

 

Whether you're trying to:

  • upload existing recordings through our desktop recorder
  • upload recordings through the mobile native recording client
  • POST them directly to our private POST API

we have a new slightly raised size limit for the files.

The limit is now 1GiB which is 1024 * 1024 * 1024 = 1.073.741.824 bytes.

Previously, the limit was 1000 MiB which is 1000 * 1024 * 1024 bytes.

The new higher limit means any file shown as 1GB on Linux and macOS (1.000.000.000 bytes) and any file shown as 1GB on Windows (1.073.741.824 bytes) will be accepted by our servers.

Fixed issue with incorrect public URLs sent with the video_copied_s3 webhook for S3 buckets with dots in their name

 

Fix

 

 

If your S3 bucket had a dot in the name, the URLs (url, rawRecordingUrl, snaptshotUrl, filmstripUrl) sent through the video_copied_s3 webhook would be incorrect as they missed the bucket name. This happened across storage services, regardless if you used S3 buckets from AWS or S3 API compatible storage.

Longer but correct time to recover recordings

 

Fix

 

 

Our mechanism that recovers recordings if the user is completely disconnected has been updated to recover the recordings after 15 minutes.

This has been done because our 30 reconnections attempts from the client side can, in theory, take just a bit longer than 12 minutes.

The documentation has been updated with more details.

The rollout of this new mechanism has been completed today across all our regions.

Webhooks timeout reduced to 30 seconds

 

Fix

 

 

Today we've reduced the webhook timeout from 127 seconds to 30 seconds to prevent our virtual workers from being tied up in waiting for responses.

This change should not affect any integration dependent on webhooks as 30 seconds is more than enough to open a TCP connection and POST the tiny amount of data. Also, the platform is not dependent on the response, we just save the status, headers and body to the db, show them in the webhook logs section and delete them a month later.

The extension .3g2 is now fully supported for mobile and desktop uploads

 

Improvement

 

 

We've added the .3g2 extension to our list of extensions that are allowed when uploading from a mobile device using the mobile native recorder or when uploading directly from the desktop.

Here is a list of all the supported extensions (bolded is new):

Desktop Uploads Mobile Uploads
mp4 mp4
mov mov
webm webm
3gp 3gp
3gpp 3gpp
3g2 3g2
flv flv
avi avi
m4v m4v
ogv ogv
mod mod
qt qt
wmv wmv
mpeg mpeg
mpg mpg
aac aac
m4a m4a
mp3 mp3
wav wav
ogg ogg
wma wma
flac flac
amr amr