I don't understand the use case. I upload a h264/AAC video file to my server, and this service transcodes it into an h264/AAC video of the same resolution.
I also worry that since it is based on streams and heroku, that it doesn't re-write the meta data to the beginning of the video after encoding. This is a really important step as it cuts the time to first frame by 1/2.
I don't understand the service either or how your blog posting covers this.
Does your service automatically detect what type of video the users device can play and transcode the source from whatever format you uploaded it as into something that can be played?
Or does it simply upload the file from the server it is on to S3?
I can't see anywhere that you can specify transcoding to a different resolution or format?
If it's to mp4, shouldn't the source path in the example URL be something other than mp4? Unless I'm misinterpreting what the path parameter is...
I realize that the mp4 container can support a wide variety of codecs and you're probably transcoding to h264/mp4, but IMO it would help to use something else here (.wmv, .avi, etc) to drive home the use case.
Transcoding is a pain, even when using an awesome service like Zencoder. I love the idea of being able to put the path to my video in a query parameter and be done with it. Really great work!
One suggestion would be to make the description of how it works a little clearer. For example, "No status handling. Prosessing & error messages will be shown through video" could say, "While the video is being processed, a temporary video file will be streamed - with the text "Processing" written on it." like you said in the comments. Also, will transcoded videos be saved in my S3, or in transcode.io's?
Wouldn't there be a huge time gap required in between the first and second view of the video? How are you going to charge people and pay amazon (for bandwidth)? Do you use Amazon Elastic Transcoder or ffmpeg?
That is of-course dependent on the size and resolution of the source file. But, when it is being processed, a temporary video file will be streamed - with the text "Processing" written on it.
Could you provide some more information on this? How is the temporary file generated and what are the tradeoffs against the final, properly transcoded file?
Hello David,
The temporary file is not generated and its preloaded. A default tiny video file which will be streamed till your original video is ready.
I imagine so - but if you spidered your site as part of the dist process (or just your video URLs) this could be neatly eliminated (and you could eliminate the transcode stage from the process, which is usually a pretty crazy stage.)
I believe nmcfarl's saying that if someone was to use your service and automatically make have every page of their website loaded (by an instance of a headless browser, javascript running manually in a web browser, anything really) after each time they uploaded new code then the videos would have already been transcoded and be cached on your end, fixing the issue with delays for first views.
PRICING:
I haven't decided anything on the pricing yet (will be roughly around $0.030 per minute of transcoding - which includes hosting as well). Interested ones can get free access for now Before moving forward with it, just wanted to know if anyone is interested. The MVP is ready for testing. Please fill the form so that I can create and send you the account IDs manually!
Hi! Haven't decided anything on the pricing yet! Roughly it will be around $0.030 per minute of transcoding (including hosting of the transcoded files)
Doesn't strike me as very secure, since everything here happens through the url and anyone can just go in and grab the required values to spoof a transcode request. It's mostly mitigated by the necessity of file upload access, but even with that this can still be taken advantage of, especially if there are rewrite rules on the file server that might expose the same file through different urls (also if this service follows 3xx redirects that's even more vectors of attack).
In case resolution choice is added as an option, what's to keep any random Joe from requesting videos with various resolutions (or very huge resolutions) and racking up the bill for me?
Thanks for your inputs! And yes you are right and even I am worried with those cases. Anyways its a 3 days side project and I had no idea that it will gain this much hype!
I am alone here and 5th position on Hackernews is kinda a new thing for me! Currently I am worried about if my server goes down!
One thing you could do is involve HMACs. Basically, give the user a key that they use to sign the request (basically sign a hash containing the url, user id, requested options). You can then use the HMAC to verify that the user did request a video be transcoded, and website visitors cannot fiddle with the request parameters without invalidating the HMAC.
The problem is that this has to be done server side because the key needs to be secret (thus, this can't happen in javascript in the client), which breaks the whole idea you're selling (API-less transcoding).
You could also provide your clients with urls by having them submit the request on your site (obviously, behind a login). The user would then use that url in the src of their video tag. Again, this method goes against your selling point.
Hey shuzchen, I am still wondering how can people upload file to someone else 's server? When you call the transcode.io URL, you don't provide the host address.
The host address is pulled from the user's account. And the account is linked with payment and other stuff.
And requesting same video with different resolutions doesn't work like that. Transcoding only happens for the first time (and you have to pre-select the output resolution while creating your account)
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.
These issues have been bugging me since long. Thanks for writing the solutions!
I am not sure whether the server treats /d/file and /d/file?v=1 as different files or same. Need to check that.
Regarding the mime type, how can I test it without downloading it..? It downloads and then match. If irrelevant then discards. Need to figure out a way to check mime before downloading.
Your /satic/videos/ idea is excellent. This solves a lot of issues. I will take that path along with name, email & host.
And the account will go to "readOnly" state after every update of these critical account details. We need to test manually the path and host before removing the "readOnly" mode. (any other solution?)
Thanks again for delving this much into this. Shoot me an email if you wish to discuss more on this :)
I'm not sure how that helps any. The issue isn't access to the raw movie file source, but access to the url, userid and eventual customization variables necessary to start a transcode job. All of this is readily available to any website visitor on a page that has a video utilizing this transcoding service.
Fantastic idea, and very well executed for a three day side-project.
As others have pointed out you have a lot of challenges ahead to turn this into a business, but you should be applauded for doing something and not just talking about it like many do.
I also worry that since it is based on streams and heroku, that it doesn't re-write the meta data to the beginning of the video after encoding. This is a really important step as it cuts the time to first frame by 1/2.