Maybe, if we keep bringing it up on here, startups will finally start putting a couple of lines of boilerplate at the top of their blog pages so we will know what on earth it is that they do when we end up there from HN.

A guy can dream, can't he?

At least this time the logo at the top links back to the main product page. Oh, and I see that the title text of the logo has just such a description! You're almost there guys!

I don't really get the 150x bit:

"Since our servers can encode video much faster than most of your users can upload it, this means there is literally no more delay between the end of the upload and the video finishing encoding. In the screencast above this makes a 150x speed difference."

Surely the upper bound is 2x if you could transcode faster than the upload before.

Unless you are just measuring the time between the upload finishing and the transcode being done. But why would a user care about that metric rather than the total elapsed time?

It's nice to see people thinking about processing input as a stream rather than waiting for the entire message to be received before doing anything.

If you start to think about input and output in web app as streams rather than buffered data, alot of neat possibilities arise for reducing latency.

A video starts playing the moment you navigate to that page. Note to OP: please add a play button to your video. The video should start only if the user has specifically requested it. It took me a minute to hunt down the tab that was the source of noise in my otherwise quiet work environment and, once I found it, I killed the tab without even glancing at the page title.

As you can probably tell, we are super excited about this, feel free to ask me anything : ).

One small question: if a user has their upload stream redirected to your service, and for some reason this upload is unable to finish, are we now forced to have the user try the upload again? It seems one advantage of the two step process would be the ability to try the process again on behalf of the user rather than making them wait and that should be weighed into the convenience formula.

I've never used your service so I'm not sure exactly how the upload stream is redirected to your platform, so this concern might not be totally valid if the upload is running through the client platform anyways.

The biggest challenge to me seems to be spinning up instances once you get a spike of realtime jobs in parallel. Keeping the 'realtime' promise is often hard once your systems go into production.

Isn't the whole purpose of pre-encoding before uploading is so that you shrink the file size and upload faster?

Why would I want to upload 4GB of video when I can encode it down to 700MB then upload?

Kudos on launching the new feature!

The pricing is a tad expensive, but doesn't look bad at all when you consider the need for an on demand encoder for the entire time that the user is uploading.

I was thinking this should be done in realtime on the client machine and streamed up the server. Then you cut down on both transfer and encoding time, and use far less server resources.

"While this sounds easy in theory, it is rather difficult to pull off on most stacks."

Why is it difficult on most stacks? Because it's tying up a request handling thread?

Is that "contact us" link correct? It adds an e-mail address to the end of the URL, which conveniently opens a comment page, but it still seems wrong.

It is not faster, just parallel processing with the upload buffer. This would be a nice feature to add to most web servers/web scripting environments.

You may want to avoid using the word "sucks" in a professional context because there is a population of people for whom the word evokes the idea of oral sex. Try substituting "is not so good." This will have the added virtue of being super charming in your German accent.

edit: I usually don't bitch about being downmodded. But don't you guys know any old people? And know that old people tend to be in charge of things? In any event, you shouldn't rely upon business leaders of any age being ignorant of the language.

-http://www.thefreedictionary.com/sucks 5. Vulgar Slang To perform fellatio on.

-suck, Old English sucan, corresponding to Latine sugere "to suck." It's of imitative origin. Meaning "do fellatio" is first recorded 1928.

-Slang sense of "be contemptible" first attested 1971