At this time you can only cancel the upload.
Pausing the upload is also something that I would personally suggest avoiding in general (even if it was possible in our code). The reason is that it is easy for any or all of the following to happen:
- That the end-user does not understand that they also need to confirm the upload so upload is never started
- Recorded video is left too long in the browser memory that it gets corrupted or destroyed
- End-users perception of the time it takes to record and upload the video increases drastically.
The reason why I say that is because all of the non Flash based and native app based recordings are done within the browser. This makes many things much easier, however also adds up on what is actually needed for the video to exist there.
The video will take space for as long as there is available memory. Once there is no more memory the browser will either:
- Throw an error (which would discard or finalize the recording),
- Not complain and just reuse the same memory for new recording time or
- Discard the entire video as is
Now lets take into account that you might have the recorder that is used internally so that you can account for PC that is being used always having 16 GB of RAM. This means that you have approximately 16 GB of RAM as the starting base. On top of that is OS and all applications, including the browser. Once the browser loads the page into the screen it is using more RAM for that page, and this goes on, so by the time you are recording video, and depending how you are recording some of your devices could just have 1 GB of free RAM.
OS is the first part of the system that would work on releasing the memory where it can, followed by browser. In general if the code does not seem to be using something heavy on resources, browser looks to clear it.
Overall this is a dangerous concept if you reliably want to have a way for the videos to come to your system.
I also mentioned the end-user perception of how long the entire process takes. We found that using parameters such as localplayback work great for end-user perception of upload times. Most people prefer to see the video as it is uploaded and then possibly wait a bit more for it to finalize the upload compared to watching the upload progress. If they were to record 15 minutes of video and then click on the start upload an hour later their overall experience would be that the process of using your service is of over an hour, or one and a half hours. Even though it was just 15 minutes to record the entire time is what they would share with anyone asking about the time.
One similar concept that is much better in terms of reliability is to download the video file once it is recorded. This is something that we look to add down the road, and what I would personally suggest as a possible solution depending on the actual reasons behind the request.
Now having said that, there are few things to mention depending on the reasons why you want to pause before upload.
Since we do not charge for re-recordings the most likely scenario is the privacy. If that is the case I would like to point out the following:
- All recordings are made over HTTPS (encrypted between end-user and our servers)
- HTTPS tunneling is applied to both your website and our system as browsers decided to follow suit and require HTTPS for all video recordings.
- Once the videos get to our servers they are transcoded and pushed to a secure storage behind a unique token that your code knows at that time.
Now we have the parameter to help you delete all videos in a day's time if you are re-recording by recreating the embedding so each recording is a new token, this would automatically clear them.
You could also issue a simple delete request and instantly the video is removed.
If you are re-recording it using same embedding (so that it is rerecording on same token) you can use another parameter that clears out the old recordings for you automatically.
The parameters I am talking about are: expiration-days and delete-old-streams.
In case you wanted to get the end-user permission for the video, then you could instead approach it a bit differently. You could add manualsubmit parameter to your embedding.
What this will do is that there will be a button that is to be clicked to confirm that the video is OK.
Once they do click on the button the manually_submitted event fires to let your code know this happened.
* Nothing really changes in how embedding works, it just provides you with a way to see if they confirm the video as OK or not and allow you to update your code (or issue upload to the video data).
Hope this helps :)