We've rolled out an update to the search/filter function in the Pipe account area:
limit value in the URL query string and it works reliably (max 200)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:
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:
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:
https://us2-addpipe.s3.amazonaws.com/1edfef4c4967d69b7129ec3ffa534002/GBRsMl19YtbqwaFfRYCeX1rU4Rm05kRx.mp4
us2-addpipe.s3.us-east-1.amazonaws.com
us2
Lots more details in the blog post.
We've made improvements to the list of recordings:
We've reviewed how we keep track of and how we present information about the Terms of Service, Privacy Policy, and Data Processing Agreement you've agreed to (on signup up or through the account area).
You'll now see more granular information in https://addpipe.com/contracts and several pop-ups throughout the Pipe account area asking you to agree to some of these documents if you have not done so already.
At the bottom of the account page, we've clarified that when deleting an account we'll also delete: