Show HN: transcode.io
transcode.io
transcode.io
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.
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?
And its any resolution to 480p.
But all these will be configurable via the URL in a future release.
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.
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?
I will make these updates. The transcoded file will be saved in transcode.io 's S3.
( A quick question: If I update code to heroku, will it pull the site down, even for a few minutes? )
Thanks
Read more about it here: http://amritbera.com/journal/why-i-built-transcode-io
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?
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!
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.
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)
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.
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 :)
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 am the only guy working on it currently. And I am open to team-up in every possible way. Interested ones please get in touch with me!