Filepicker.io + Zencoder

It is a BAD IDEA to put your Zencoder API key in plain text inside of JavaScript. Just to repeat that one more time, do not use this in code that other people could possibly access. Nothing would stop people from taking your API key and encoding all the video they wanted.

The implication is that I couldn't therefore put this code in any internet-facing webpages.

Which leads me to wonder what the use-cases are for this implementation ?

Re: Filepicker.io + Zencoder

#6

Post by brettcvz » Thu, Mar 21, 2013, 5:11 PM UTC

whyleyc wrote: post #5

The Zencoder blogpost cautions: It is a BAD IDEA to put your Zencoder API key in plain text inside of JavaScript. Just to repeat that one more time, do not use this in code that other people could possibly access. Nothing would stop people from taking your API key and encoding all the video they wanted. The implication is that I couldn't therefore put this code in any internet-facing webpages. Which leads me to wonde…

This is a demonstration of how the two can work together, but in a production setup you'll want to do the following transformation:

Instead of getting the fpurl and passing that to zencoder via a $.ajax call, first pass it to your server and then hit zencoder server-side using one of their libraries.

Re: Filepicker.io + Zencoder

#7

Post by gailees » Thu, Mar 21, 2013, 5:24 PM UTC

Can't wait to mess around with this!

To be honest, I'm surprised there isn't more competition in this market, as filepicker has been saving me and the rest of our dev team hours and hours of valuable time.

Re: Filepicker.io + Zencoder

#8

Post by whyleyc » Thu, Mar 21, 2013, 5:25 PM UTC

brettcvz wrote: post #6

whyleyc wrote: post #5

The Zencoder blogpost cautions: It is a BAD IDEA to put your Zencoder API key in plain text inside of JavaScript. Just to repeat that one more time, do not use this in code that other people could possibly access. Nothing would stop people from taking your API key and encoding all the video they wanted. The implication is that I couldn't therefore put this code in any internet-facing webpages. Which leads me to wonde…

This is a demonstration of how the two can work together, but in a production setup you'll want to do the following transformation: Instead of getting the fpurl and passing that to zencoder via a $.ajax call, first pass it to your server and then hit zencoder server-side using one of their libraries.

Which you could do before this integration ?

(I'm not trying to be down on what has been developed here - just trying to understand how it is different from what was already possible)

Re: Filepicker.io + Zencoder

#9

Post by mtrimpe » Thu, Mar 21, 2013, 5:26 PM UTC

I just recorded my video but my since Flash auto-selects line-in for me, no audio was actually recorded.

We ran into that problem a lot while trying to optimize the user experience of the VideoView recording application. It turns out end users will ignore lack of audio feedback and some will even continue recording when the interface shows nothing but a black screen in case the wrong camera is selected.

We're building a semi-automated selection interface for it now using entropy estimations to select the best camera and microphone, but since you're probably optimizing more for a quick start I'd suggest doing a quality analysis (like PExQ for example) after the fact so you can at least give an early warning that there may have been an issue recording the video.

Re: Filepicker.io + Zencoder

#10

Post by brettcvz » Thu, Mar 21, 2013, 5:30 PM UTC

whyleyc wrote: post #8

brettcvz wrote: post #6

Earlier quoted context omitted.

This is a demonstration of how the two can work together, but in a production setup you'll want to do the following transformation: Instead of getting the fpurl and passing that to zencoder via a $.ajax call, first pass it to your server and then hit zencoder server-side using one of their libraries.

Which you could do before this integration ? (I'm not trying to be down on what has been developed here - just trying to understand how it is different from what was already possible)

Yup, this partnership is more about providing demos and showing people in each of our respective communities how they can use the two services together. Fortunately both of our APIs were powerful enough already that we didn't have to write any additional library code to integrate the two