Set the maximum duration of a video (& audio)
In my application, every user is allowed to upload videos. These don't go through my server but the upload to my library happens on the client-side. What I'm wondering is if it is possible to set a maximum duration of a video, so that users cannot upload videos that are too long. Of course, the validation takes place primarily on the client-side, but I believe that a "server-side" lock is also needed. How could I implement such a check?
-
Hey Niccolo, thanks for reaching out!
Since you're uploading from the client-side, I assume that you're using an unsigned upload preset (is that right?), in that case, a possible solution would be adding an incoming transformation that sets the duration to the maximum desired duration (i.e - du_<desired maximum duration>).
Just to give you an example of the duration parameter semantics - if you want the maximal duration to be 15 seconds, then:
- If the uploaded video is less than 15 seconds, such as the dog video (13s), then the video duration would be kept as is - https://res.cloudinary.com/demo/video/upload/du_15/dog.mp4
- If the uploaded video is more than 15 seconds, such as the elephants video (52s), then the video duration would be cut to 15 - https://res.cloudinary.com/demo/video/upload/du_15/elephants.mp4
Keep in mind that when it comes to manipulating videos, it is advised to turn on the "async" option (you can find this parameter in the Upload API optional parameters list).
Note, that if you're using the upload widget, you can limit the maximum video file size with the "maxVideoFileSize" or the "maxFileSize" parameter (would only work for files uploaded via the "local" source).
Hope this helps!
0 -
Thanks a lot, it works work like a charm!
Although I use a signed upload preset, experimenting a bit, I managed to get the result I was hoping for. The only thing now, is that I am currently trying to implement a resource type check accordingly. So that a user does not ask my server for a signature for an image, and therefore without the transformations for videos, and use it to upload a video. What I tried to do is set in my backend the value "resource_type" in the function to generate the signature. However, even setting the same value in the body or in the URL of the API request on the client-side, I get the error "invalid Signature".
Thanks sincerely for your patience.
0 -
Hi Niccolo,
The reason for the "Invalid Signature" error is that the resource_type parameter is among the few parameters which should not be passed for signature generation. When you included resource_type for signing it produced one signature but then on Cloudinary the string being signed won't include the resource_type so the signatures will not match. More details on the process of manually generating authentication signatures can be found below:
https://cloudinary.com/documentation/upload_images#generating_authentication_signaturesAs I understand, you want to limit the signature your backend server generates for the specific file type (i.e. image/video) such that the signature you generate cannot be used to upload a different file type, is that correct? If so, you may be able to use one of the existing fields in the Upload Preset configuration to achieve that.
When editing an Upload Preset in the "Upload Control" tab you will see a field called "Allowed formats". That will allow you to configure the format of files you wish to allow when that upload_preset is used. With this approach, you can define one upload preset for images and a different one for videos with relevant "allowed formats".
Then on your backend, you would generate the signature and pass in your upload call the upload_preset based on the file that is selected for upload. This way, if the signature is taken and another file type attempted to be uploaded, you will receive an error for that upload call because the check against "allowed formats" will not succeed.
Would this approach be something you can use?
0 -
Sorry for the late reply, but thank you very much for the tip. It is just what I was looking for!
0
Post is closed for comments.
Comments
4 comments