If that's the case with the resolution setting then my concern there isn't as major, although users might still be at risk if their webservers are configured a certain way.
I'm not concerned about users uploading files to someone else's server, but sometimes servers are configured to rewrite certain urls, or to do redirects, and attackers might be able to take advantage of that to rack up some user's bill. For instance, some cache-busting schemes rewrite /d/_somehash_/file or /d/file._somehash_ to the same /d/file and your service has no idea they're actually the same file. In this case, some attacker can just make up random hashes to make false transcode jobs, even though they all return the same video file.
Does your service treat /d/file and /d/file?v=1 as separate files? If so that can also be used as an attack vector as someone can add whatever parameters they want to the url, and most webservers silently ignore those. You can close this by ignoring those parameters, but then you exclude sites that serve files through some script (like /cgi/get-file?f=somefile)
Does your service whitelist file extensions? Or stream in file headers first to decide whether any file is a valid movie, otherwise stopping the download? Otherwise, any site that hosts other large files (say, linux ISOs) can force you to download really large files and waste bandwidth and resources.
With that in mind, I think if you also make it so your clients must also provide a subdirectory (for example, I could set it so only files within /static/videos/ are valid, as that's where I've decided to put my videos) then most of these issues will be taken care of. Your clients would then just need to make sure they don't have rewrite enabled for that subsection of their site, and make sure other large assets live outside that subdirectory.