Pipe changelog addpipe.com

We've just launched a new Logs section that gives you access to all the successful and failed attempts to access the camera and microphone with getUserMedia().

This section is a very useful tool to help you give better customer support, get accurate analytics and look up user attempts to grant access to their camera and microphone.

You can find out more details in the blog post.

2 updates to the Recordings section:

• you can search recordings by the device IP
• you can filter and show only Recovered recordings (recordings for which the connection was interrupted mid-recording and auto save was ON).

No longer will you need to sift through pages to find the elusive recordings :)

We've implemented a catch all mechanism for all of the situations that were producing 0 byte recordings coming from the HTML5 desktop recorder.

Previously, when a 0 byte file was made, the user that made the recording had no idea.

Now the user experience is much better. After clicking the record button if no incoming data is detected:

1. For the first 2 seconds the message Waiting for data... is shown and the recording counter does not start, because nothing is actual recording.
2. After 2 seconds if there is still no incoming data, the message Device error: no audio or video data is shown and the UI is reset, so that you can retry to record.
3. The failed recording is not saved.

The messages that we were showing when our HTML5 desktop recorder was requesting camera and microphone access needed an improvement.

• We've updated the messages to be in line with the text used by the browsers. Words like access and webcam were replaced by the keywords use and camera respectively.
• When requesting access, we've added the domain name of the website in which Pipe is embeded in, for a better understanding of the context.
• In case the user blocks the camera and/or microphone, an additional message is shown which informs the user how to unblock the devices.
• Now when you record audio only, the messages refer just to the microphone device, in order to avoid any kind of confusion.

With the start of the new year we've fixed the following:

• Fixed issue with some of the recordings being 1 second longer than the actual moment when the stop recording button was pressed
• Fixed issue with minimal number of accepted parameters and their default value for the Pipe embed code
• Added additional check to prevent the deletion of recordings in some rare cases when they were stuck in the storage queue
• Fixed issue with the YouTube integration no longer uploading videos.

We've just rolled out the new HTML5 desktop-like inline recorder to all Pipe accounts. It can be activated from the environment settings.

It will work on Chrome 63+ on Android on secure origins (https).

More details in the blog post.

We've set up these demos to help test various features and configurations. You can use them to test the new recorder on your Android device:

• https://s3.eu-central-1.amazonaws.com/playwithpipe/standard.html
• https://s3.eu-central-1.amazonaws.com/playwithpipe/flipped_responsive.html
• https://s3.eu-central-1.amazonaws.com/playwithpipe/hd_upload.html
• https://s3.eu-central-1.amazonaws.com/playwithpipe/15sec.html
• https://s3.eu-central-1.amazonaws.com/playwithpipe/audio_upload.html
• https://s3.eu-central-1.amazonaws.com/playwithpipe/portrait.html

Some of the stuff we've fixed in this autumn:

• A new configuration option in the S3 bucket configuration page allows you to specify custom S3 endpoints.
• Removed the "Connecting..." message that shows up in the HTML5 recorder after pressing the RECORD button because the recorder is already connected at that point
• Reduced the incidence of duplicate entries in the db for the same recording
• Fixed issue with videos from mobile not being rotated according to their rotation metadata. This affected videos with H.264 video and AAC audio as on such videos we did minimal processing.
• Fixed an issue with the upload percentage going to 100% ahead of time and thus spending a lot of time at 100%
• On mobile we now show only a "Record" label instead of "Record or select a video file" when selecting an existing recording is disabled
• We've added the environment id to the body of the email sent on a new recording or when a push to storage fails for easier filtering in Gmail
• We've stopped using HTML forms in the 2.0 and 1.0 embed code as they conflicted with existing forms when embedding Pipe in an online form like those produced by GravityForms
• Solved issue with TypeError: jQuery(...).ajaxSubmit being thrown if inserting jQuery in the page after the 2.0 Pipe code
• Added Access-Control-Allow-Headers: Origin, X-Requested-With to OPTION requests against precheck.php and the .xml language files
• Better email validation on /signup and /invite
• Turned off echoCancellation in our HTML5 recorder to make sure as little processing as possible is done on the audio

For some time now we've been working closely with a pen tester to tighten the security of the Pipe platform.

The work has been extensive and its ongoing work but briefly, I can say we went through:

• CSRF tokens used in the Pipe account area
• XSS filters on input and possible XSS exploits
• Escaping input data when shown or used
• SQL injection testing
• Spoofing most of the params sent to our account and recording client endpoints
• Brute forcing the sign in/sign up/reset password pages
• Brute forcing other endpoints
• CORS headers for the recording client files
• Website headers (we now get an A @ https://securityheaders.com/)
• Firewall rules protecting our servers
• Whitelist of extensions allowed when uploading existing recordings
• Server-side technology information disclosures

Over the last few weeks, we've kept an eye on the recordings being uploaded to our system that failed to pass through to the other side. Those rare corner cases where for some reason or another the transcoding process failed.

As a result, we've now tweaked our transcoding process to properly accept, transcode and report on:

• .mod, .ogv and .qt files
• streamed .flv and .webm files with audio or video tracks that start in the middle of the recording
• pre-existing audio-only recordings uploaded through desktop and mobile
• recordings with no rotation metadata uploaded from mobile devices.

To make sure our db is ready for 10x growth earlier this autumn we've done a deep dive into the entire functioning of our database.

We've updated the software with the latest patches, reviewed and improved our most demanding queries using the slow query log, reviewed our table indexes, backup strategy and procedures for restoring a backup and more.

As a result:

• you should immediately see a noticeable decrease in the time required to load the recordings and logs pages with large data sets (thousands and tens of thousands of recordings)
• we're now getting the most out of the resources on the db server and it is ready to handle much higher peaks but also more sustained load
• daily backups are faster and have close to no impact on performance
• we have an improved db monitoring and alert system
• our db size is smaller < removed any orphan rows and eliminated unnecessary columns
• we've rehearsed our backup restoring procedures and improved them. We now feel a lot more confident in our ability to restore a complete backup if we will ever need to do that (hopefully not!).