Page History
After generating the upload urlURL, you can now upload your video. This is done using the chunked upload method with retry handling.
| Note |
|---|
| The token in the upload URL is valid for four hours. This means that if the video upload takes longer than four hours to complete, an error will occur. If this happens, perform the "Get upload URL" request again to generate a new upload URL. |
Chunked Upload
Sample
| Code Block | ||||
|---|---|---|---|---|
| ||||
curl -X POST -H "Mi24-Upload-Total-Chunks: 10" -H "Mi24-Upload-Current-Chunk: 1" -H "Content-Type:application/octet-stream" --data-binary "@/<FILENAME>" "https://file-1-a.video-cdn.net/jshdfkjhdfgjh/987876565423?__token__=abc123 |
| URL | Description |
|---|---|
| UPLOAD_URL | An example upload URL is shown above (see "Getting the Upload URL"). |
| Parameters | |
| token | The token is returned along with the upload URL and is valid for 4 hours (see warning above). |
| Headers | |
| Mi24-Upload-Total-Chunks | Total number of chunks. The example above uses 10 chunks. |
| Mi24-Upload-Current-Chunk | Current chunk number, starting with 1. The above example is the first chunk out of 10. |
| Content-Type | Specify "application/octet-stream" for the content type as in the example above. |
| Command-line Options | |
| --data-binary <@/FILENAME> | Upload as bytes of binary data and be sure to prefix the filename with "@". Then indicate the filename (and path if necessary) of the local video file to upload. |
| Info |
|---|
You would need to send the above example request 10 times, incrementing the current chunk each time. You can upload your file in as many or as few chunks as you wish, although typically the chunk size should be between 2 and 10MB. By using a larger number of smaller chunks, and implementing retry handling (see next section), you can expect a smoother and more reliable upload of your videos. |
Response codes
202 - Accepted. Response code for the chunk request
201 - Created. Response code for the last chunk request, when upload has been completed
4xx - Error (client-side). Response code for when the server rejects a client request due to authorization errors, authentication errors or badly-formed requests.
5xx - Error (server-side). Response codes for when the server was unable to process a request.
1101 - If you receive this response, it means your upload was denied because you've reached the limits of your booked storage capacity
Retry Handling
If the response to a chunk upload request is not in the 2xx range, the chunk must be uploaded again.
This can happen for a few reasons, such as:
- Failure in the connection across the Internet
- Expired upload token
- Rate-limiting
- Timeout in receiving a response from the API
To avoid these situations interrupting your upload, we strongly suggest implementing retry handling in your code.
A good strategy for retry handling is to wait for an incrementally longer or random time between each failure. There are several options, for example:
- wait for 1 second, then 2, then 3 ... incrementing by one second each time
- wait for 1 second, then 2, then 3, 5, 8, 13 ... incrementing using a Fibonacci sequence
- wait for between 1 and 5 seconds, chosen randomly
Regardless of method, you should put a limit on the number of times you retry. Sometimes failure causes are more than transient and no amount of retries will succeed.
(DEPRECATED) Full File Upload
| Warning |
|---|
As of July 2019, the full file upload method is deprecated in the movingimage REST API. While your code will still work, we strongly recommend that you update to use the chunked upload method with retry handling as soon as possible. |
| Expand | |||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Request
Response 200 - OK 1101 - Upload denied because the booked storage capacity limit is reached. |