Every update to the Pipe platform: new features, improvements and fixes.
In the dashboard, under /recordings:
We have updated our audio processing pipeline for our inline recording client by switching from ScriptProcessorNode to AudioWorkletNode. This change was necessary as ScriptProcessorNode is deprecated and might no longer be supported in future browser versions.
This change also bumps up the browser requirements for our inline recording client:
We’ve implemented a new password policy.
It is now mandatory that all new Pipe account passwords respect the following:
This new policy is enforced in the following cases:
We have a new publicly available, manually updated status page available at https://addpipe.instatus.com/ .
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:
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:
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).