Pipe changelog addpipe.com

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.

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

We've rolled out an update to the search/filter function in the Pipe account area:

• you can now search by recording id
• made it clear you need to search by the exact file name without extension
• you can change the number of results per page by changing the limit value in the URL query string and it works reliably (max 200)
• searching for "all" is not buggy anymore
• fixed/updated search copy to better reflect the returned search results

Sometimes larger files failed to be pushed to DropBox because of the way we handled the upload.

This is no longer the case!

From now on, files that are larger than 150 MB will be successfully uploaded to DropBox all the time, thanks to a new mechanism that uploads large files in manageable smaller chunks.

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