Pipe changelog
Pipe changelog
addpipe.com

Webhooks timeout reduced to 30 seconds

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

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
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

Round 2 of improvements to our recording servers

This round of changes focuses on one thing in particular: the way we add tasks for our transcoding servers.

Until now, the recording servers relied on the database to pass on the task needed to be done towards the transcoding servers.

With this update, we've implemented direct communication between the recording servers and the transcoding servers.

What does this mean for you?

  • Faster processing (up to 150 ms faster )
  • No more rare random delays (up to 2 minutes) in processing the recordings.

Stay tuned for the next round of updates for our recording servers!

Fixed issue with connecting from behind an ipv6 proxy

Until today, some visitors using IPv6 might have had issues loading the Pipe Recorder. Those days are gone!

In situations where the user was connecting through IPv6 to a proxy and then to our client delivery server or CDN the X-Forwarded-For header contained IPv6 value which led to a 500 HTTP error instead of a proper JSON response. Parsing the header value (which lead to the error) only happened when the environment's region was set to Auto or Auto-US. From our investigation, this was a rare event. During the past month, it has affected under 100 requests against our precheck mechanism.

This also happened when the X-Forwarded-For header contained malformed information in which case we now just default to the eu region (when the region option is set to Auto on the environment) or us1 (Auto-US).

This is yet another improvement in a series of infrastructure improvements that we're making to the Pipe Platform.

The recording ID from the webhooks payload is now a consistent data type

The recording ID within a webhook payload was correctly sent as an Integer data type when the recording was processed in real-time (first attempt), but incorrectly sent as a String data type when the webhook was sent as a result of a successfully retried recording (one that failed on its first attempt).

This has been fixed so that the recording ID within any of the possible webhook payloads will always be an Integer data type across the board as it should.

Round 1 of improvements to our recording servers

We just deployed part 1 of an ongoing huge update that our recording servers will receive. Here are some of the most important changes we made in the first round:

  • The recording servers can now make multiple connections to our database at the same time.
  • Reduced the number of queries made to our database by implementing a caching mechanism.
  • Code optimization and restructuring.
  • Made changes to lower the number of duplicate recordings even further. This was already a rare occurrence.
  • Better logs with new data to allow us to better keep track of potential issues in the future.

All of these changes mean that our servers will be able to take on much higher recording loads than before for less hardware usage.

Stay tuned for the next round!

Safari 14 Support

Safari 14 has been released, which drops the support for Flash Player, but at the same time it does not introduce the support for MediaStream Recording API (this feature is still under a flag).

This forced us to drop support for desktop Safari 14 until the MediaStream Recording API is fully supported and turned on by default.

As of now, our desktop recorder will redirect Safari 14 users towards other browsers:

Safari-14-not-supported-1.png

The Record Video/Audio button will also be greyed out and disabled.

More details can be found in the blogpost.

More MIME types allowed with mobile uploads

Allowed MIME types are now in sync between the desktop upload path and the native mobile recording/upload path.

This especially impacts the uploads/recordings coming from the mobile native recorder, many more formats are now supported.

Here's the complete list (what's bolded is new):

Desktop Uploads Mobile Uploads
video/mp4 video/mp4
video/quicktime video/quicktime
video/webm video/webm
video/3gpp video/3gpp
video/3gpp2 video/3gpp2
video/x-flv video/x-flv
video/x-msvideo video/x-msvideo
video/avi video/avi
video/x-ms-wmv video/x-ms-wmv
video/x-matroska video/x-matroska
video/mpeg video/mpeg
audio/aac audio/aac
audio/webm audio/webm
audio/3gpp audio/3gpp
audio/3gpp2 audio/3gpp2
audio/mp4 audio/mp4
audio/mpeg audio/mpeg
audio/m4a audio/m4a
audio/x-m4a audio/x-m4a
audio/mp3 audio/mp3
audio/x-wav audio/x-wav
audio/wav audio/wav
audio/ogg audio/ogg
audio/x-ms-wma audio/x-ms-wma
audio/flac audio/flac
audio/amr audio/amr

Fixed video downscaling issue

Some of the videos that were in portrait mode did not correctly report their width and height in the right order which resulted in videos that were scaled down for no reason when using the transcoding engine with a max height option set.

TL;DR The width was considered the height and vice-versa because video rotation was not taken into account.

Updates to the Usage Page in the Account Area

We've made several updates to the underlying code of the usage page during the last few weeks. To the account owner they amount to:

  • 🚀 being faster when calculating the pricing for large numbers of recordings (when you run into 2nd tier and 3rd tier pricing). Not quite rocket fast, but faster .
  • the monospaced font we've switched to in the tables will make said tables easier to scan and read 👓
  • seeing the exact start and end times for their current billing period (for example the 1st billing period starts with a date & time but ends on a full date)
  • being able to see the usage during their expired trial period
  • fix: total length values on previous billing periods are now correct, previously they did not include the audio length (cost was shown correctly)
  • fix: they'll not encounter a minor issue with showing lengths affected by how floating-point arithmetic works on computers
  • fix: on trial accounts we're not showing the cancel subscription button anymore