jslack

@johnymyko: ya, no, I just wanted to clarify. That sucks. Would be curious if it's caused by GPU acceleration, could try turning it off in chrome (http://www.pcadvisor.co.uk/how-to/internet/how-turn-off-gpu-hardware-acceleration-in-google-chrome-3605455/)

@johnymyko: It's not as if we run any kind of special non-standard video. It's just normal video content served in html5 player. The difference you might find, is that we run super high FPS, and super high bitrate - we are more generous than many sites when it comes to bitrate and resolutions. Our user base is quite discerning with their video content ;) You can try choosing lower resolutions so you can compare it to other sites that are likely running lower quality settings.

@davidfox1983: Yes, more or less. We do not have special access API keys yet, so everyone is on an even playing field - except they started using the API before we started adding some of the limits, so they were able to get around some of the restrictions initially - not a great answer for you, but it's the truth. To my knowledge, they did the population from their own cron servers, instead of doing on every client request, sharing an API key.

As long as you stay within reasonable usage limits with the API key, you will be ok, just rather you don't hardcode it into your distributed app, as you can understand, we can detect how many IPs are being used per API key, and those get marked for abuse. I'd rather you set up some kind of worker box with your own api key, and fill up your data cache that way. That way, you only have 1 IP per API key, and its much more reasonable for us, from a denial of service and security perspective. We officially support 200 requests per 15 minutes, and unofficially support up to 400 requests per 15 mins - which is a hell of a limit, if you rate limit your requests it will not take long for you to fill up the cache. Run it over a period of 48 hours, and it should be totally fine.

@scab120: That's strange, thanks for reporting. No one else has reported issues, and we get a lot of video downloads. Curious what might be going on. Any video in particular you can't point me to? The one's I've tried work so far. Also, what OS/browser you on?

@irulzu: That's pretty decent, and should be enough to get the highest resolutions we offer.

There are a lot of different variables that can be causing this. GPU acceleration on/off depending on your chipset, flash vs html5 (depending on your hardware). Some hardware works better with acceleration off than others with it on. AMD vs Intel, Nvida vs ATI, dedicated graphics vs software, etc.

Find out what works best (youtube html5 or youtube flash), then try to run the same thing on GB.

At home, on my windows machine I had to turn off all GPU acceleration for my AMD based system - as it caused a crazy amount of problems, and it's pretty widespread. This is just an anecdote for typical kind of problems.

@hunkulese: So very true. I think I distrust the Liberals even more than the Conservatives. At least with Harper, I know he's going to fuck shit up. With the Libs, it's constant let downs.

@euantor: Definitely. It's under active development, and should be ready relatively soon (tm). The reason it's taking so long, is that it's a change that will affect our whole platform. Essentially the blocker is the extra security and tokenization per user per video in order to protect streams from being shared to non-premium. It involves working with our CDN.

@Coreus: Yes, it is ridiculous. I'm working on this myself, so I can make sure it goes out. The reason it's an issue now is that the original youtube option was built on the old youtube API that didn't have html5 fallback support.

@giganteus: Before that :)

@clidus: @tjockapa:Absolutely. Something I'm working on now is updating some of the documentation reflecting policies, so our API users have a better understanding of guidelines and changes. And yes, a roadmap is something I've been working on creating. I think Jeff and Tony are open to new ideas for the API, but they wanted to prioritize stability and fixes first. But yes, a roadmap is being discussed. The API / wiki are things I have a lot of personal interest in, and I'll do what I can to get a roadmap out there.

@davidfox1983: Yes, we are doing many things from the security front, and more is coming on that.

Just like GiantBomb video buddy works, you can allow the user to input his own existing API KEY into the settings page of your app (then of course you store it permanently in your local device storage), or you can do a request to the generation page, and just generate, and grab the token after the user auths, and then you'll be able to take that key and use it.

Otherwise, Video Buddy uses it's own cache for results, so it's not having to do unique hits on every request. You can cache responses if you wish (as long as it's non premium), which will allow for extremely fast searches that don't have to hit our API. You can pre-populate this cache by using your own user account API if you'd like. For example, take the first 10 pages of video results, and build a cache DB. That's 1000 videos - cool!

Additionally, we are working on coming up with new solutions for our API users, involving oath tools and solutions to make API interactive easier. First priority is us fixing some current performance issues and fixing API abuses, so we can make sure to scale.