Changelog

A client side fix and UX improvement from 3 days ago for the 0 byte recordings created from WebKit browsers (Safari, Chrome on iOS, Firefox on iOS, etc.) was not immediately effective because some of our clients self host the pipe.js library so they don’t get pipe.js updates right away.

Also, just short of 10% of all 0 byte recordings did not originate from Safari/WebKit.

As a result, we’ve now implemented a server side fix that stops recovering any 0 byte recording.

On Safari on macOS, Safari on iOS, and Chrome on iOS it is easy to revoke camera and microphone permissions after you’ve given them.

For example, on Safari on macOS you can:

1. click the grey camera icon in the browser tab OR
2. click the red camera icon in the address bar and choose Pause

to temporarily revoke permissions.

Safari on iOS on the other hand has an easily accessible “Stop Using Camera” option.

Chrome on iOS also makes it relatively easy to revoke permissions

If a user started recording after permissions were revoked, the recording client temporarily showed the “Waiting for data…” message and then “Device error: no audio or video data”. It also created a 0 byte file.

These scenarios have now been improved. The 0 byte recording is not created anymore and the desktop recording client immediately acknowledges the loss of permissions and gives basic instructions to the user.

A small number of .webm recordings contain only 1 video frame and many audio frames. As a result, these .webm files are very small in size and, after processing, have no video frames during playback and no snapshot. After today’s update, such .webm files will be remuxed and will now generate a snapshot, as well as have 1 video frame present on the video playback.

A smaller number of .mp4 recordings come in with their audio and video data not muxed correctly. These recordings do not play correctly in both their raw and converted forms. After processing, these recordings have no snapshot and report a very long duration. We’re now detecting such recordings and remuxing them before processing them further. The final converted .mp4 file will now play correctly and there will be a snapshot for such recordings. The initial raw .mp4 file remains untouched.

We’re working on the client side to see if these issues can be fixed higher up where they originate (browser bugs?).

In June, 25 recordings exhibited the symptoms above.

We’ve fixed an issue on Safari on macOS where if the desktop recording client disconnected while recording, playback inside the recording client would stop at the disconnection point.

This issue has been known since the release of the desktop recording client in beta on Safari on macOS.

Safari on macOS will now stream the recording data in slices of at least 150ms (but not more than 200ms).

Previously, there was only the max slice size limit of 200ms. The last slice can be of any size.

Starting with the 5th of June, a change in the Scaleway S3 API resulted in incomplete URLs saved to our database for recordings uploaded to our complimentary EU2 S3 bucket through multipart upload (>100MiB). We’ve reported the issue to Scaleway, made a change to our code so that it does not affect us, and changed all incomplete URLs to the correct ones.

This affected 219 recordings from several accounts. Affected recordings did not play from the account dashboard and the URL sent through the video_copied_pipe_s3 webhook was also wrong. Accessing such an incomplete URL in the browser resulted in a 404 http status and a NoSuchBucket error code from Scaleway.

You can now record the webcam and screen simultaneously. The feature also allows you to resize and move the webcam feed anywhere within the recording client over the screen feed, even while recording. This feature is only available with the 2.0 embed code.

Also, we did some thorough testing, and we’re pulling the screen recording feature out of beta. 🎉

You can read more about all the exciting features in the blogpost

The dashboard has a new Pages section which lists all the pages created on the environment including the creation time where available, actual 1.0 or 2.0 embed code and a DELETE option.

You’ll now be able to view and manage all the pages generated on your account.

The new section can be accessed by clicking View all generated pages from the /embed section or by going to https://dashboard.addpipe.com/pages .

Password confirmation is now required when:

1. you change the e-mail on an account which has a password attached
2. remove the password from an account

We’ve fixed an issue with older recorder test pages - those which contained 1.0 embed code - showing the message “Go away hacker” instead of the actual recorder.

We have upgraded the version of socket.io used in the 2.0 client embed code from 2.1.1 to 4.7.4.

The 1.0 version of the embed code has officially become deprecated meaning it is not actively maintained. We are working towards migrating any accounts still using it to the 2.0 version. Eventually, we’ll completely retire the 1.0 embed code.

We’ve added a message to the recording client to highlight when a recording cannot be saved due to errors coming from the server (e.g., missing files). Despite the the error message being displayed, a new recording can be started to get rid of it, and all other functions of the recording client remain unaffected.

We’ve updated our codebase for pipe.js and pipe.min.js, transitioning to a more modern ES6 syntax and incorporating async functions. This change not only slightly enhances performance but also reduces the file size of pipe.js by 5kB and pipe.min.js by 2kB.

We’ve created a new environments page in the dashboard that will make it a lot easier to navigate, manage & switch between environments when you have many of them.

The new page lists all your environments, their settings and also async counts the number of recordings (undeleted) in each environment.

We’ve upgraded the 2.0 pipe.js and pipe.min.js builds to utilise modern ES6 syntax. Browser support remains consistent with the documentation, with the only change being an increase in Firefox support from version 50+ to 52+.

Minor improvements the the dashboard: TOS alert, payload display, finer .svg logo and more compact usage and billing tables.

Introducing a new 2.0 embed code option for HTML (pipe-timertype) and JavaScript (timertype) embed codes. This option enables customisation of the timer behaviour at the top of the recording client. Setting this option to 0 configures the timer as a count-up timer, while setting it to 1 configures it as a count-down timer. By default, the timer functions as a count-up timer.

We’ve implemented a fallback mechanism for when the quality profile data XML file request fails. This ensures that even if the quality profile data is not successfully fetched, the recording client can still be generated using pre-defined hardcoded quality profile values. These values are determined based on the requested quality profile XML URL. For instance, if a request for 720p fails, the system falls back to hardcoded quality profile values for 720p. Additionally, if the quality is not specified, it defaults to 360p.

Previously, very rarely, an EncodingError error with the message “Video encoding failed” would occur in the client way after a recording was started. This triggered our fallback to VP8 mechanism, causing a different recording to be started right away. However, this prevented the content of the initial recording (before the error occurred) from being fully processed before starting the new recording leading to the 1st recording needing to be recovered.

We’ve resolved this issue by updating the fallback mechanism in the 2.0 client. Now, if the error occurs during a recording, the fallback is not triggered. Instead, the recording simply stops, allowing the content to be processed correctly. Users can then manually initiate a new recording if needed.

We’ve made a significant improvement to pipe.js version 2.0 by completely removing jQuery in favor of our lightweight JavaScript library for simplified DOM manipulation. This way, we eliminated the overhead associated with jQuery, reducing the size of pipe.js by 31% (~37kB) and of pipe.min.js by 40% (~40kB).

• Removed the two duplicate checkboxes;
• Added the missing ‘Desktop recorder: allow uploads’ checkbox.

1. Resolved an issue impacting the styling of the desktop recorder’s device selector buttons when embedded within websites utilising Bootstrap 4 or 5. The fix now ensures a consistent styling.
2. Fixed a sizing issue with the canvas displaying the video with the background blurring effect active. Previously, the canvas did not always resize appropriately. This fix ensures dynamic resizing of the canvas.

1. We’ve finally upgraded the account dashboard to Bootstrap 4 (4.6.2).
   1. As a result, all the texts in our dashboard will respect the font-size specified in your browser settings (16px by default). We’ve also removed any hardcoded font-size in px of our own meaning all texts should scale together with your browser level font-size setting.
   2. As a result, most content text will be slightly bigger since Bootstrap 3 defaults to 14px while Bootstrap 4 defaults to 1 rem, which is normally 16px.
   3. We’ve also upgraded jQuery from 1.12.4 to 3.7.1.
2. The logo will finally appear sharp and clear on all devices.
3. Dashboard users can swiftly dismiss the notifications displayed at the top of the page.
4. “Occurred” is finally spelled correctly

1. We introduced a new download button in the bottom menu of the desktop recorder delivered using the 2.0 embed code. By default, the button is visible, allowing users to download the current recording locally, even if it is not fully uploaded to the server. The button can be hidden by setting the HTML embed code option pipe-downloadbtn or the JS embed code option downloadbtn to 0. There’s also a new download() function in the 2.0 JS Control API.

2. Previously, a minor issue existed where the timer at the top did not reset to 0 immediately after initiating a second recording. It momentarily displayed the duration of the previous recording before updating to 1 second. This bug has been successfully fixed, and now the timer’s value immediately resets to “00:00” the moment a new recording is started.

1. We resolved an issue where the countdown timer was displayed behind the audio-only icon. The countdown timer is now displayed prominently over all icons located in the center of the recording client.
2. We addressed a bug in screen recording where changing the microphone using the device selector while the “Also share audio tab” option in Chrome was enabled resulted in the loss of audio from the shared window. This issue has been fixed, and now the audio from the window is always combined with the microphone audio stream, indicated by the title in the device selector as “(with system audio)”.
3. We fixed a previous limitation where enabling the background blurring effect during recording playback caused the video to stretch and excluded the miniature video from the effect. Now, the background blurring effect can be applied seamlessly during playback.