5 ms·
> Unless you are just measuring the time between the upload finishing and the transcode being done. That is what we are measuring indeed. > But why would a us
by felixge 16y ago
> Unless you are just measuring the time between the upload finishing and the transcode being done.
That is what we are measuring indeed.
> But why would a user care about that metric rather than the total elapsed time?
Because that is the time where the user feels he has already done his part, but the site he is on is taking forever to do what he needs it to do.
Another reason why we measure the time from upload done to encoding done is because that's what our customers pay us to do.
- sophacles 16y agoI demand you address the OP question of why you haven't fixed the physical constraints of crappy upload bandwidth? Seriously, wtf would we pay your for otherwise? </snark>
- jodrellblank 16y agoYeah, why don't they make a 150x faster javascript encoder, then I only have to upload much less data! </derp>
- randallsquared 16y agoYou're derping, but a browser plugin seems like it might actually be a good idea for this. Even if JS is too slow, someone who uploads lots of video through a site might well be willing to install a little plugin to make it faster, especially if it comes with other simple things like queuing a directory of videos, etc.
- robryan 16y agoWonder if something like the Google Native Client would be good for this in the future? (Don't know a whole heap about it so may be off the mark)
- barrkel 16y agoNaCl might be good for doing the transcoding on the client side before uploading - and would be especially helpful if the transcoding is a downsampling (i.e. reducing stream length), and if the client machine is beefy enough to do it without adversely affecting performance when pumping out bits at the rate of the upload connection. However, it wouldn't be particularly useful for things like queuing uploads from a directory. The point of NaCl is running native machine code in a provably secure sandbox. It's about making possible web app features faster on the client side, rather than adding new capability, per se.
- felixge 16y agoAs funny as this sounds, fixing the upload bandwidth problem is also something we will work on. Getting a good route between your users and servers can make a real difference. So at some point in the future we'll offer upload servers in all major geographic areas.
- nitrogen 16y agoIt's interesting how difficult this can be. I was recently evaluating Linode locations for a new virtual server, and though I'm geographically much closer to California, the Texas location gave me almost 20x the download speed. To be precise, I was able to download from a California node at 300K/s, while I got close to 6MB/s from Texas. Comcast used to route my traffic to California through Seattle, Washington, then down to San Jose and then Fremont, but now, it's going to Texas first, then across to San Diego, then up to Fremont, across a saturated link.
- biot 16y agoWith the exception of video formats (you mention quicktime) that puts the metadata at the end, how about real-time preview as the file is still uploading? Even a series of static thumbnails every 10 seconds would be an interesting new feature.
- felixge 16y agoThat's a very cool idea - we'll add support for that as well : ).