Amazon Elastic Transcoder - Watermarking, Bit / Frame Rate Control
aws.typepad.com
aws.typepad.com
For me photo transcoding comes in batches that take 5-15 minutes to process, a few times per week. This work bogs down the tiny instance, so I have to keep around a medium instance just for the occasional conversion work, but 99% of the time it's a waste of hardware. It's also a waste of my time having to write code to deal with things like iPhone picture image rotation and so on.
Or if you want to get fancier, try their queues [0], they've got an example of doing image processing to explain how it works. Essentially, you set up your processing pipeline attached to a queue. You then drop messages on the queue whenever you want to do work, and they spin up one or many machines (controllable by you) to process the data. Then after 20 seconds of nothing new appearing on the queue, they turn them all off.
They'll even give you 20 hours of compute time free, every month.
Edit - if you don't want to build it, drop me a message, I can do it.
[0] http://blog.picloud.com/2013/04/03/introducing-queues-creati...
What I want is a service that takes this URL and returns a resized JPG:
http://SimpleImageService.com/resize
?account=DenisM
&source=http://s3.amazonaws.com/DenisMsPictures/Image1.TIFF
&size=400x400
That's it. I'll drop this into my app and forget about it. Set the prices at your AWS cost + 25%, and send me the bill at the end of each month.Sadly, I obviously can't just share the code because I don't own the copyright.
(Disclaimer : I am the CTO )
Eg. store only the original to start, when 1024p wide version is requested, check filesystem or database blob cache for 1024p version, if it exists, serve it, if not, transcode then serve it, cache it so next time it is requested you'll have it. This way you don't spend cycles transcoding photos at resolutions that are subsequently never requested as various sizes.
And existing APIs like ImageMagick make all the normal image processing features a breeze to implement.
Granted, photo transcoding is still a good idea for a service for people who really don't care about it and just want something that works out of the box, but video transcoding is a much tougher nut to crack (despite ffmpeg/libav and other solutions, there's still a lot of black magic people who haven't gotten their hands dirty with this sort of thing don't realize is an issue until they start transcoding videos and noticing audio sync and other such issues) and thus I'd be way more likely to pay for a service to do it rather than roll my own with video as opposed to photos.
They've been iterating quickly and we're so close to being able to use this, but the billing thing is a big hurdle for us.
Big thanks goes to them for moving fast, getting involved, and acting [quickly] on user feedback.
A bunch of gamers have issues live streaming to youtube and twitch. Each requires special (different) encoding parameters for streaming, and youtube needs each resolution streamed separately. This, along with separate streams for twitch and youtube murders most people's bandwidth not to mention a home computer's encoding capacity.
Most of the time they end up choosing only one site and a specific resolution and miss out on a large portion of their fan base. (People have a wide range of quality preferences/bandwidth requirements, in addition to being on different sites.)
Someone should use this to build a super easy multi-output streaming transcoder for youtube / twitch.tv / etc.
No.
This isn't a sales pitch so much as an offer to chat about it and see if we could help turn a service we provide into a product that meets this need.
For years we've provided this as a "private label" service to major media companies that need to provide one single broadcast quality live stream and have it delivered to thousands or hundreds of thousands of end users on Windows and OSX (RTMP), Android (RTSP), and iOS (HLS), in bitrates ranging from 300 kbps to 6 megabits, while also pushing the full array of bitrates to YouTube, Hulu, etc.
The problem is that this is not cheap. Pulling it off with low latency and across a full array of formats and protocols tends to require dedicated hardware (depends on the source material, talking heads easier than sports, for example). But our approach does cost significantly less than trying to use AWS instances, and if the community of broadcasters or viewers was large enough, it might make sense for us to open up this private label service to individuals.
Feel free to ping me if someone wants to talk about it.