Google Data » YouTube Staff https://googledata.org Everything Google: News, Products, Services, Content, Culture Thu, 19 Mar 2015 18:59:20 +0000 en-US hourly 1 http://wordpress.org/?v=3.7.5 PLaylists: now with more PL https://googledata.org/youtube-api/playlists-now-with-more-pl/?utm_source=rss&utm_medium=rss&utm_campaign=playlists-now-with-more-pl https://googledata.org/youtube-api/playlists-now-with-more-pl/#comments Wed, 22 Aug 2012 14:51:00 +0000 https://googledata.org/?guid=cf0992585df9b236ebfa92cf3ad21c07 If you ever pay attention to your browser’s location bar, you may have noticed that, for a while now, the YouTube.com website has used playlist IDs that are prefixed with the characters “PL” when constructing the URLs for playlist pages. http://www.youtube.com/playlist?list=PL72CF07D200AA2AFA is one example of that. This practice of prepended playlist IDs previously didn’t extend over to the Data API—PL72CF07D200AA2AFA would not have been recognized as a valid playlist ID, but 72CF07D200AA2AFA would have.

Starting later today, Wednesday, August 22, the YouTube Data API will accept playlist IDs with the “PL” prefix whenever they’re used as metadata or in API request URLs. In most responses, the API will return playlist IDs with “PL” prefixes. The one exception is that for the next few days, searching for playlists will return playlist ids without the “PL” prefix. This will change on Tuesday, August 28, at which point the “PL” prefix will be included in playlist search results as well.

While we will continue to support using unprefixed playlist IDs as metadata or in API request URLs for the time being, at some point in the future we may require the “PL” prefix to be used whenever a playlist ID is provided. We’ll provide additional guidance if we do decide to stop supporting requests with unprefixed playlist IDs.

This change should be backwards compatible, but if you’re currently manipulating or comparing the playlist IDs that are returned via the API in any way, or making any assumptions about the length of the ID (which you shouldn't be), please make sure that your code will handle IDs that contain the “PL” prefix.

If you have any questions about this changes, please let us know in our developer forum.

Cheers,
—Jeffrey Posnick, YouTube API Team]]> If you ever pay attention to your browser’s location bar, you may have noticed that, for a while now, the YouTube.com website has used playlist IDs that are prefixed with the characters “PL” when constructing the URLs for playlist pages. http://www.youtube.com/playlist?list=PL72CF07D200AA2AFA is one example of that. This practice of prepended playlist IDs previously didn’t extend over to the Data API—PL72CF07D200AA2AFA would not have been recognized as a valid playlist ID, but 72CF07D200AA2AFA would have.

Starting later today, Wednesday, August 22, the YouTube Data API will accept playlist IDs with the “PL” prefix whenever they’re used as metadata or in API request URLs. In most responses, the API will return playlist IDs with “PL” prefixes. The one exception is that for the next few days, searching for playlists will return playlist ids without the “PL” prefix. This will change on Tuesday, August 28, at which point the “PL” prefix will be included in playlist search results as well.

While we will continue to support using unprefixed playlist IDs as metadata or in API request URLs for the time being, at some point in the future we may require the “PL” prefix to be used whenever a playlist ID is provided. We’ll provide additional guidance if we do decide to stop supporting requests with unprefixed playlist IDs.

This change should be backwards compatible, but if you’re currently manipulating or comparing the playlist IDs that are returned via the API in any way, or making any assumptions about the length of the ID (which you shouldn't be), please make sure that your code will handle IDs that contain the “PL” prefix.

If you have any questions about this changes, please let us know in our developer forum.

Cheers,
—Jeffrey Posnick, YouTube API Team]]> https://googledata.org/youtube-api/playlists-now-with-more-pl/feed/ 0 Build Compelling Experiences Using YouTube Embeds With The IFrame Player API https://googledata.org/youtube-api/build-compelling-experiences-using-youtube-embeds-with-the-iframe-player-api/?utm_source=rss&utm_medium=rss&utm_campaign=build-compelling-experiences-using-youtube-embeds-with-the-iframe-player-api https://googledata.org/youtube-api/build-compelling-experiences-using-youtube-embeds-with-the-iframe-player-api/#comments Fri, 27 Jul 2012 22:44:00 +0000 https://googledata.org/?guid=782b7c1ad86c4f6af07da593bf05912b If you've hesitated to use the <iframe> player in your app due to the IFrame Player API's experimental status, then wait no more. We've removed that API's 'experimental' tag, which means the API is production-ready and is covered by YouTube's deprecation policy. Since the <iframe> embed is the default way of sharing YouTube videos on the Web, the IFrame Player API is now the recommended mechanism to control video playback behavior in your Web applications.

To provide a consistent developer experience with the YouTube Upload Widget, we’ve changed the the URL for loading the IFrame Player API code to https://www.youtube.com/iframe_api. The old URL (http://www.youtube.com/player_api) is now deprecated, though it will continue to work. Similarly, the iframe API initialization callback name has been changed to onYouTubeIframeAPIReady from onYouTubePlayerAPIReady, also for consistency with the YouTube Upload Widget. The old callback name, onYouTubePlayerAPIReady, is now deprecated as well. If your app uses both the YouTube Upload Widget as well as the IFrame Player API, you only need to include the script once and handle a single initialization callback.

Going forward, we'll continue making improvements to the IFrame API and make it work better with mobile platforms. As before, you can find the details about the API in our documentation and ask questions about it on our developer forum.

Cheers,
--Jarek Wilkiewicz, YouTube API Team]]> If you've hesitated to use the <iframe> player in your app due to the IFrame Player API's experimental status, then wait no more. We've removed that API's 'experimental' tag, which means the API is production-ready and is covered by YouTube's deprecation policy. Since the <iframe> embed is the default way of sharing YouTube videos on the Web, the IFrame Player API is now the recommended mechanism to control video playback behavior in your Web applications.

To provide a consistent developer experience with the YouTube Upload Widget, we’ve changed the the URL for loading the IFrame Player API code to https://www.youtube.com/iframe_api. The old URL (http://www.youtube.com/player_api) is now deprecated, though it will continue to work. Similarly, the iframe API initialization callback name has been changed to onYouTubeIframeAPIReady from onYouTubePlayerAPIReady, also for consistency with the YouTube Upload Widget. The old callback name, onYouTubePlayerAPIReady, is now deprecated as well. If your app uses both the YouTube Upload Widget as well as the IFrame Player API, you only need to include the script once and handle a single initialization callback.

Going forward, we'll continue making improvements to the IFrame API and make it work better with mobile platforms. As before, you can find the details about the API in our documentation and ask questions about it on our developer forum.

Cheers,
--Jarek Wilkiewicz, YouTube API Team]]> https://googledata.org/youtube-api/build-compelling-experiences-using-youtube-embeds-with-the-iframe-player-api/feed/ 0 Know What’s Loaded? https://googledata.org/youtube-api/know-whats-loaded/?utm_source=rss&utm_medium=rss&utm_campaign=know-whats-loaded https://googledata.org/youtube-api/know-whats-loaded/#comments Tue, 24 Jul 2012 20:00:00 +0000 https://googledata.org/?guid=2ebe8f920c93843bcfaf4da4e03d9df7 If you’ve ever developed a custom playback experience based on our Player API, you’ve probably used the getVideoBytesLoaded() and getVideoBytesTotal() methods to determine how much the current video is locally buffered and the size of the entire video. After obtaining this information, the next logical step is to divide the number of bytes loaded by the total number of bytes to obtain the fraction of the video that’s been buffered, which you can then display in your custom user interface.

Instead of taking this two-step approach to calculate how much of a video has buffered, we encourage you to use the new getVideoLoadedFraction() method. It will return a numerical value between 0.0 and 1.0 that represents the same fraction obtained by dividing getVideoBytesLoaded() by getVideoBytesTotal(). While those two legacy methods still work today, they are now officially deprecated, as per the terms of our deprecation policy.

getVideoLoadedFraction() allows us to expose more accurate information to your code about the state of the video that’s currently playing across a wider range of playback scenarios. When HTML5 <video> playback was used in the <iframe> Player, for instance, we previously had to return “fake” values for getVideoBytesLoaded() and getVideoBytesTotal(), as the true byte counts weren’t directly exposed via the <video> element. The value returned by getVideoLoadedFraction() should be correct for that and other playback scenarios that we roll out in the future.

If you have any questions about the new method or anything else related to the YouTube APIs, please let us know in the developer forum.

Cheers,
—Jeffrey Posnick, YouTube API Team]]> If you’ve ever developed a custom playback experience based on our Player API, you’ve probably used the getVideoBytesLoaded() and getVideoBytesTotal() methods to determine how much the current video is locally buffered and the size of the entire video. After obtaining this information, the next logical step is to divide the number of bytes loaded by the total number of bytes to obtain the fraction of the video that’s been buffered, which you can then display in your custom user interface.

Instead of taking this two-step approach to calculate how much of a video has buffered, we encourage you to use the new getVideoLoadedFraction() method. It will return a numerical value between 0.0 and 1.0 that represents the same fraction obtained by dividing getVideoBytesLoaded() by getVideoBytesTotal(). While those two legacy methods still work today, they are now officially deprecated, as per the terms of our deprecation policy.

getVideoLoadedFraction() allows us to expose more accurate information to your code about the state of the video that’s currently playing across a wider range of playback scenarios. When HTML5 <video> playback was used in the <iframe> Player, for instance, we previously had to return “fake” values for getVideoBytesLoaded() and getVideoBytesTotal(), as the true byte counts weren’t directly exposed via the <video> element. The value returned by getVideoLoadedFraction() should be correct for that and other playback scenarios that we roll out in the future.

If you have any questions about the new method or anything else related to the YouTube APIs, please let us know in the developer forum.

Cheers,
—Jeffrey Posnick, YouTube API Team]]> https://googledata.org/youtube-api/know-whats-loaded/feed/ 0 Let’s Hear It From Your Users! https://googledata.org/youtube-api/lets-hear-it-from-your-users/?utm_source=rss&utm_medium=rss&utm_campaign=lets-hear-it-from-your-users https://googledata.org/youtube-api/lets-hear-it-from-your-users/#comments Thu, 19 Jul 2012 16:09:00 +0000 https://googledata.org/?guid=b0c147b0c11c3e05295a44bae726b9e1 Over the past few years we’ve heard two specific pieces of feedback from the YouTube API community:
  1. Developers have clamored for years for a way of embedding a webcam YouTube upload widget on their web pages, similar to the webcam upload tool available at youtube.com/my_webcam.
  2. Developers who have used YouTube Direct in the past have asked for a simpler solution that doesn’t require the same level of technical expertise to set up and manage.

Knowing about this demand made us particularly excited for our Google I/O announcements of the YouTube Upload Widget that supports webcam uploads, and YouTube Direct Lite, both of which are now available for public use.

YouTube Upload Widget
Using the YouTube Upload Widget on your site is as simple as adding an <iframe> to your HTML, like so:

<iframe id="widget" type="text/html" width="640" height="390" src="https://www.youtube.com/upload_embed" frameborder="0">

Developers who want more control over the uploads experience can use a full JavaScript API to initiate the widget, and listen for events related to the upload.

YouTube Direct Lite
YouTube Direct Lite is a complete rewrite of the existing YouTube Direct platform. The goal of the project remains the same: make it possible to solicit videos from your users and then moderate those submissions into standard YouTube playlists for display. The difference is that YouTube Direct Lite is implemented purely in client-side HTML, JavaScript, and CSS, and unlike with YouTube Direct, no Java App Engine deployment is needed. You can download the YouTube Direct Lite code, customize it, and deploy it on your own web server along with the rest of your site’s content. To make things even easier, we’re hosting a canonical deployment of YouTube Direct Lite that you could include on your pages without having to deploy anything at all—just add the appropriate <iframe> tag to your page.

You can find a live example of YouTube Direct Lite integration, including the use of the YouTube Upload Widget, on this sample page. Feel free to use that page to submit a video letting us know how you plan on using the new tools.

Bringing the YouTube Upload Widget and YouTube Direct Lite to web developers and community maintainers will give you new tools to hear from (and see!) your community, and who knows what great things will come from that!



Cheers,
—Eric Lundberg, Jeff Posnick and Vladimir Vuskovic, YouTube API Team]]> Over the past few years we’ve heard two specific pieces of feedback from the YouTube API community:
  1. Developers have clamored for years for a way of embedding a webcam YouTube upload widget on their web pages, similar to the webcam upload tool available at youtube.com/my_webcam.
  2. Developers who have used YouTube Direct in the past have asked for a simpler solution that doesn’t require the same level of technical expertise to set up and manage.

Knowing about this demand made us particularly excited for our Google I/O announcements of the YouTube Upload Widget that supports webcam uploads, and YouTube Direct Lite, both of which are now available for public use.

YouTube Upload Widget
Using the YouTube Upload Widget on your site is as simple as adding an <iframe> to your HTML, like so:

<iframe id="widget" type="text/html" width="640" height="390" src="https://www.youtube.com/upload_embed" frameborder="0">

Developers who want more control over the uploads experience can use a full JavaScript API to initiate the widget, and listen for events related to the upload.

YouTube Direct Lite
YouTube Direct Lite is a complete rewrite of the existing YouTube Direct platform. The goal of the project remains the same: make it possible to solicit videos from your users and then moderate those submissions into standard YouTube playlists for display. The difference is that YouTube Direct Lite is implemented purely in client-side HTML, JavaScript, and CSS, and unlike with YouTube Direct, no Java App Engine deployment is needed. You can download the YouTube Direct Lite code, customize it, and deploy it on your own web server along with the rest of your site’s content. To make things even easier, we’re hosting a canonical deployment of YouTube Direct Lite that you could include on your pages without having to deploy anything at all—just add the appropriate <iframe> tag to your page.

You can find a live example of YouTube Direct Lite integration, including the use of the YouTube Upload Widget, on this sample page. Feel free to use that page to submit a video letting us know how you plan on using the new tools.

Bringing the YouTube Upload Widget and YouTube Direct Lite to web developers and community maintainers will give you new tools to hear from (and see!) your community, and who knows what great things will come from that!



Cheers,
—Eric Lundberg, Jeff Posnick and Vladimir Vuskovic, YouTube API Team]]> https://googledata.org/youtube-api/lets-hear-it-from-your-users/feed/ 0 YouTube @ the Google Developers Academy https://googledata.org/youtube-api/youtube-the-google-developers-academy/?utm_source=rss&utm_medium=rss&utm_campaign=youtube-the-google-developers-academy https://googledata.org/youtube-api/youtube-the-google-developers-academy/#comments Thu, 12 Jul 2012 19:29:00 +0000 https://googledata.org/?guid=f9eec2cb0830025bbdc7a2383ce9b20f Whether you’re a fledgling developer looking to get started with an API or a skilled developer who wants to learn some new tricks, you’ll find engaging material at the Google Developers Academy. Of particular interest to readers of this blog is the YouTube section, which hosts courses specific to the YouTube APIs.

The first course walks JavaScript developers through the steps needed to embed an <iframe> Player on their page along with a list of chapter titles. It’s perfect when you want to embed a lengthy video that consists of multiple sub-sections, since jumping from section to section is as easy as clicking on predefined links. Check out the live demo of a page with videos from last year’s Google I/O conference to see the player in action.

We will be gradually adding to the YouTube section of the Google Developers Academy, and we’ll announce the new courses on this blog and our YouTube for Developers Google+ page. Stay tuned for more great resources!

Cheers,
—Jeff Posnick, YouTube API Team]]> Whether you’re a fledgling developer looking to get started with an API or a skilled developer who wants to learn some new tricks, you’ll find engaging material at the Google Developers Academy. Of particular interest to readers of this blog is the YouTube section, which hosts courses specific to the YouTube APIs.

The first course walks JavaScript developers through the steps needed to embed an <iframe> Player on their page along with a list of chapter titles. It’s perfect when you want to embed a lengthy video that consists of multiple sub-sections, since jumping from section to section is as easy as clicking on predefined links. Check out the live demo of a page with videos from last year’s Google I/O conference to see the player in action.

We will be gradually adding to the YouTube section of the Google Developers Academy, and we’ll announce the new courses on this blog and our YouTube for Developers Google+ page. Stay tuned for more great resources!

Cheers,
—Jeff Posnick, YouTube API Team]]> https://googledata.org/youtube-api/youtube-the-google-developers-academy/feed/ 0 Unlocking JavaScript’s Potential with CORS https://googledata.org/youtube-api/unlocking-javascripts-potential-with-cors/?utm_source=rss&utm_medium=rss&utm_campaign=unlocking-javascripts-potential-with-cors https://googledata.org/youtube-api/unlocking-javascripts-potential-with-cors/#comments Fri, 18 May 2012 18:03:00 +0000 https://googledata.org/?guid=f71a5a2770b04ec8cd9d25463de049b9 Web developers are accustomed to making magical user experiences with a few lines of elegant JavaScript, but when faced with talking to RESTful services like the YouTube API, the options have been anything but simple. The most common approach relies on a technique known as JSONP, which relied on dynamically inserting a <script> tag on a page and triggering a local callback function with response from an external service. The YouTube API has supported JSONP for a while now, but developers using this approach are probably familiar with its drawbacks: request failures can lead to the JavaScript callback never being triggered, and JSONP can only be used for read-only API calls that don’t require HTTP request headers being set.

A modern alternative to JSONP is Cross-Origin Resource Sharing (CORS), which allows JavaScript developers to make arbitrary HTTP requests (GETs, PUTs, POSTs, etc.) via the standard XMLHttpRequest interface. Not every browser supports the extensions to XMLHttpRequest that support CORS, but if you’re using one that does we have some good news for you: the gdata.youtube.com web servers that host the YouTube Data API now are enabled for CORS support!

This opens up a whole new class of web application integration with YouTube done purely in client-side JavaScript, without any need for running server-side code. To illustrate what’s now possible, take a look at this sample code. When run in a browser that supports CORS, you can authenticate using OAuth 2 and then perform the entire browser-based upload flow entirely from JavaScript. Previously, the portion of the code that POSTed metadata to the YouTube API needed to be run on a web server.

We can’t wait to see what JavaScript developers will build now that the doors to CORS are open. Enjoy!

Cheers,
—Jeff Posnick, YouTube API Team]]> https://googledata.org/youtube-api/unlocking-javascripts-potential-with-cors/feed/ 0 An Update to our Deprecation Policy https://googledata.org/youtube-api/an-update-to-our-deprecation-policy/?utm_source=rss&utm_medium=rss&utm_campaign=an-update-to-our-deprecation-policy https://googledata.org/youtube-api/an-update-to-our-deprecation-policy/#comments Fri, 20 Apr 2012 19:43:00 +0000 https://googledata.org/?guid=a2905f3ad8c779cf1e18e821bd186779 As you might have seen announced on our Google Developers blog, the deprecation policies associated with many of Google’s APIs are changing. We want to highlight the specific way this affects YouTube API developers.

As of today, our YouTube API deprecation policy states:

Google will announce if we intend to discontinue or make backwards incompatible changes to this API or Service. We will use commercially reasonable efforts to continue to operate the YouTube API without these changes until the later of: (i) one year after the announcement or (ii) April 20, 2015, unless (as Google determines in its reasonable good faith judgment):
    • required by law or third party relationship (including if there is a change in applicable law or relationship), or
    • doing so could create a security risk or substantial economic or material technical burden.
This Deprecation Policy doesn't apply to versions, features, and functionality labeled as "experimental."

Please note that while the deprecation policy listed above is current as of the date of this blog post, the definitive version of the policy can always be found in our Terms of Service.

Cheers,
—Jeff Posnick, YouTube API Team
]]> https://googledata.org/youtube-api/an-update-to-our-deprecation-policy/feed/ 0 Upgrading Old Embed Codes https://googledata.org/youtube-api/upgrading-old-embed-codes/?utm_source=rss&utm_medium=rss&utm_campaign=upgrading-old-embed-codes https://googledata.org/youtube-api/upgrading-old-embed-codes/#comments Tue, 17 Apr 2012 16:21:00 +0000 https://googledata.org/?guid=bce1279347f0a313d40a98a6973668b5 We’d like to let the community know about an upcoming change that will affect some developers using Flash-only players in their webpages or applications. Previously, a URL like http://www.youtube.com/v/VIDEO_ID would default to the ActionScript 2 version of the Flash player, and it was necessary to explicitly add in the version=3 URL parameter to request the newer, ActionScript 3-based player. Starting on Wednesday, May 2, we will be changing the default behavior so that the ActionScript 3 player will be loaded in those scenarios.

This change to the default version affects both the Embedded and Chromeless Flash players. Developers who are using the newer <iframe> embedded player will not see any change, as that already defaults to the ActionScript 3 player when Flash playback is needed.

If for some reason you explicitly need the ActionScript 2 version of the player, perhaps because you’re hosting it from within a parent Flash container that was written in ActionScript 2, then you should change your code to explicitly add in the version=2 URL parameter to the player URL. Most developers will not need to do this, though, and they’ll automatically get the benefits of the modern ActionScript 3 playback experience without having to change their code.

As we’ve previously announced, the ActionScript 2 players are all officially deprecated, and have been for several years now. Our plan is to shut them down completely starting in October of this year, so while it is still possible to explicitly request them with version=2 if they’re needed, our recommendation is that you do not continue to rely on the ActionScript 2 player in your code.

Cheers,
—Jeff Posnick, YouTube API Team
]]> https://googledata.org/youtube-api/upgrading-old-embed-codes/feed/ 0 New Player Options for Lists of Videos https://googledata.org/youtube-api/new-player-options-for-lists-of-videos/?utm_source=rss&utm_medium=rss&utm_campaign=new-player-options-for-lists-of-videos https://googledata.org/youtube-api/new-player-options-for-lists-of-videos/#comments Fri, 30 Mar 2012 20:42:00 +0000 https://googledata.org/?guid=a737df04c856bad8e6f2e8a617d98a48 Update (May 2012): The showinfo=1 parameter can now be included in the player's URL to indicate that the list of video thumbnails should be initially visible. The example below has been updated to illustrate this usage.

Most developers know that the YouTube embedded player can display a single video, but did you know that it can be used to display a list of videos as well? There have been a number of recent enhancements around list playback functionality, and if you’re not already taking advantage of those new features, we wanted to let you know what you’re missing out on.

The first change of note is the syntax for embedding the player in an HTML document. As for single-video playback, you can use the <iframe> embed code to load a list of videos, and the IFrame embed supports HTML5 <video> playback in environments where Flash is not available.

Another exciting change relates to the lists of videos that you can load. The player is no longer limited to just displaying videos from an actual YouTube playlist. You can also load a user's uploaded videos, a user's favorite videos, or videos matching a specific search term. In the embed URL, the listType and list parameters control the list of videos that is loaded. The listType value can be either playlist (the default), user_uploads, or search. Depending on the listType value, the list parameter value should be set to the desired playlist id, YouTube user ID, or search term. For example, the following embed code displays the most recent videos uploaded in the “GoogleDevelopers” YouTube channel:

<iframe width="560" height="315" src="http://www.youtube.com/embed/?listType=user_uploads&list=GoogleDevelopers&showinfo=1" frameborder="0" allowfullscreen></iframe>

The corresponding embedded player is shown below:



Finally, for developers who want more control over their player than what a simple embed code offers, a full YouTube JavaScript API is available for use. There are methods for loading lists, moving to the next/previous video in a list, and controlling whether playback is shuffled or looped. To give you an idea of how you can use this new JavaScript Player API functionality, we’ve put together a sample page that you can experiment with and use as inspiration when developing your own code.

Cheers,
—Jeff Posnick, YouTube API Team
]]> https://googledata.org/youtube-api/new-player-options-for-lists-of-videos/feed/ 0 Keeping Things Fresh https://googledata.org/uncategorized/keeping-things-fresh/?utm_source=rss&utm_medium=rss&utm_campaign=keeping-things-fresh https://googledata.org/uncategorized/keeping-things-fresh/#comments Fri, 23 Mar 2012 14:36:00 +0000 https://googledata.org/?guid=6a22f7bfca68f97c3a3483cd61f0657c Pop quiz: what’s the difference between the following feed URLs?

  1. https://gdata.youtube.com/feeds/api/users/googledevelopers/uploads?v=2
  2. https://gdata.youtube.com/feeds/api/users/googledevelopers/uploads?v=2&orderby=published
  3. https://gdata.youtube.com/feeds/api/videos?v=2&author=googledevelopers&orderby=published

All three will return a list of videos uploaded in the GoogleDevelopers YouTube channel, with the most recent uploads listed first. However, only the first URL will return the freshest results available — the second or third feeds could both be missing videos that were uploaded within the past few hours. In addition, even if the videos are listed in the second and third feeds, the metadata returned for those videos might not reflect any recent updates.

The reason for this, as explained in our documentation, is that some requests go against our search index, which has cached data, while other requests retrieve data directly from our backend databases, which always contain the most up-to-date data. To determine whether a request will query the search index or the backend database, you can use the following rules of thumb:

  • If your request only includes the max-results and/or start-index query parameters, then it should go against the backend database and the results will be fresh. A few other parameters that change the way the feed is formatted, like prettyprint, callback, or alt, can also be used without triggering the search index. Although it does filter results out of the feed, the fields parameter can also be used while still going against the backend database, because the filtering is performed server-side after the data has been retrieved.

  • If your request contains other parameters, there’s a good chance it will end up against the search index. Some common parameters that will always trigger a search are q and orderby.

Going against the search index isn’t inherently a bad thing. Using the search index is an incredibly efficient way of returning all the videos that match an arbitrary keyword, or ordering a feed of videos so that they’re sorted by view count. The important thing to realize is that the search index doesn’t need to be used for tasks that the backend database can handle, and you’ll get fresher results from the backend database.

Until now we’ve been focusing on retrieving a feed of videos uploaded in a specific account, but these same principles apply to looking up a single video with a given ID as well. Using the information above, can you determine which of these URLs will request a video entry from the backend database, and which will go against the search index?

  1. https://gdata.youtube.com/feeds/api/videos/sOEAD-gfJ_M?v=2
  2. http://gdata.youtube.com/feeds/api/videos?q=sOEAD-gfJ_M?v=2

As you’ve probably figured out, the first URL retrieves the entry for video ID sOEAD-gfJ_M directly from the backend database, while the second URL searches for all entries with metadata containing sOEAD-gfJ_M and then returns the one matching result. The results look similar, but only the first URL will give you the complete, up-to-date video metadata. As such, we recommend always using that syntax when retrieving the entry for a video whose ID you know.

Cheers,
-Jeff Posnick, YouTube API Team
]]> https://googledata.org/uncategorized/keeping-things-fresh/feed/ 0 YouTube, Google+, the API, and You https://googledata.org/youtube-api/youtube-google-the-api-and-you/?utm_source=rss&utm_medium=rss&utm_campaign=youtube-google-the-api-and-you https://googledata.org/youtube-api/youtube-google-the-api-and-you/#comments Thu, 15 Mar 2012 16:25:00 +0000 https://googledata.org/?guid=8a862306508f134b2604f40274365f2d Update (April 2012): The last paragraph was changed to reflect the distinct yt:display and display attribute names, depending on whether the parent element is media:credit or yt:username.


By now, you may have read about the recent launch of connecting a Google+ profile with a new YouTube channel and questioned whether the change will affect YouTube Data API responses and, consequently, your application. The API does have a couple of changes that affect the way account names are returned, and these changes are designed to be backward compatible with applications that follow the best practices defined in our compatibility guidelines.

With that in mind, this post explains how to ensure that user names function properly in your application.


  • Avoid manually generating links to related feeds — instead, extract URLs for related feeds from <link> or <gd:feedLink> elements. For instance, the profile entry for a given account contains a <gd:feedLink> element with a rel attribute of http://gdata.youtube.com/schemas/2007#user.playlists, and that element's href attribute contains the URL for that account’s playlists.

  • If you do need to manually generate a feed URL that is not for the default user, use the value in the <yt:username> element as the username in the feed URL. Other fields, like <author>, might contain a display name or a different identifier that is not appropriate for use in a feed URL.

    Note that for accounts that have connected a Google+ profile to a new YouTube channel and for     Google Accounts without a linked YouTube account, the <yt:username> field will not be a traditional YouTube username. Instead, it will be a globally unique identifier that isn't intended for display in a user interface. A new field, <yt:userId>, will always contain this globally unique identifier regardless of the account type, and if you are writing new code to specifically deal with that identifier, we recommend reading it from <yt:userId>.

  • Any existing code that relies on displaying the <yt:username> or <media:credit> value to users should instead switch to using a value taken from one of that element's attributes. On the <yt:username> element, the relevant attribute is called display. On the <media:credit> element, the corresponding attribute is called yt:display. The display or yt:display attribute value will always be a meaningful value suitable for display. For accounts connected to Google+, it will be set to the full public display name. For full YouTube accounts that aren’t connected to Google+, it will be set to the YouTube account name.


Cheers,
–Jeff Posnick, YouTube API Team
]]> https://googledata.org/youtube-api/youtube-google-the-api-and-you/feed/ 0 Video Uploads from Your Site’s Community https://googledata.org/youtube-api/video-uploads-from-your-sites-community/?utm_source=rss&utm_medium=rss&utm_campaign=video-uploads-from-your-sites-community https://googledata.org/youtube-api/video-uploads-from-your-sites-community/#comments Wed, 15 Feb 2012 15:22:00 +0000 https://googledata.org/?guid=d46fa65d72669d164427c8bf06d9d4c0 Update (August 2012): We now suggest YouTube Direct Lite rather than YouTube Direct for most new integrations.

The following scenario comes up all the time when we talk to developers: a website with an active readership is interested in soliciting videos from its community. While YouTube is a great place to host these videos, it takes some forethought to design a system that makes uploading as straightforward as possible while still adhering to YouTube API Terms of Service and best practices.

One crucial consideration is which account the videos will be uploaded to on YouTube. It’s tempting to design a system in which all videos are uploaded to a single “master” YouTube account, but this is always the wrong approach. While using a master account means that each uploader doesn’t need to register for their own YouTube account, a high rate of uploads into a single YouTube account is a good way to run afoul of the YouTube API’s quota system. Additionally, each uploader to YouTube agrees to YouTube’s Terms of Service, which says that they have the right to upload that content, and that the content does not violate our Community Guidelines. By taking responsibility for other users’ content, you are essentially putting your own account and YouTube standing at risk.

The approach we recommend instead is using AuthSub or OAuth 2 (please don’t use ClientLogin!) to authenticate users and allow users to access their YouTube accounts. Then, you can use the browser-based upload flow to transmit the video from users’ local drives to YouTube’s servers. Uploads spread across end users’ accounts are less likely to trigger quota errors. And since videos end up in individual accounts, each account owner takes responsibility for ensuring that their uploads comply with YouTube’s community guidelines. Videos uploaded via your site will show up in a user’s channel just like any of their other videos.

After a video’s been uploaded, you will almost certainly want to display it on your own site or on a YouTube channel page, which raises the question of how to keep track of videos that have been uploaded through your site but which end up in users’ own accounts. One option for doing this programmatically is via the use of developer tags; another approach is to make use of a local database and keep track of the YouTube video id returned by the API following each upload. Once you’ve identified uploaded videos that you’d like to feature, you could, for instance, add them to a playlist and embed that playlist on your site, or feature the playlist on the channel page of your own YouTube account.

Designing a system that adheres to these best practices takes a little work, but avoiding the common pitfalls will pay off in the long run. For existing code that you could use as-is or adapt on your own site, take a look at the YouTube Direct project. It consists of code that uses AuthSub, browser-based uploads, developer tags, and playlists to allow the users of any website to contribute video uploads.

Cheers,
—Jeff Posnick, YouTube API Team
]]> https://googledata.org/youtube-api/video-uploads-from-your-sites-community/feed/ 0 Watch History Comes to the API https://googledata.org/youtube-api/watch-history-comes-to-the-api/?utm_source=rss&utm_medium=rss&utm_campaign=watch-history-comes-to-the-api https://googledata.org/youtube-api/watch-history-comes-to-the-api/#comments Tue, 24 Jan 2012 21:50:00 +0000 https://googledata.org/?guid=57276dba70e4f4dda9f522320a074feb There’s a new entry in the growing list of video feeds supported by the YouTube Data API: the watch history feed. This feed allows authenticated API users to retrieve their own YouTube viewing histories—retrieving the watch history of any other user is not allowed. The information in this new feed corresponds to the viewing history exposed on the YouTube website.

The feed could enable interesting new functionality in your applications. If your site displays a list of recommended videos for an authenticated user to watch, you might consider excluding those videos that have been already viewed, for instance. Or you might want to include a video that you discover the user has been watching over and over again. Knowing the sorts of videos that a user watches makes it easier for your application to algorithmically suggest other videos that might interest your users.

As with any functionality related to the YouTube API, the best place to ask questions about the new watch history feed is the YouTube API developer forum.

Cheers,
—Jeff Posnick, YouTube API Team
]]> https://googledata.org/youtube-api/watch-history-comes-to-the-api/feed/ 0 YouTube Direct Keeps Growing https://googledata.org/uncategorized/youtube-direct-keeps-growing/?utm_source=rss&utm_medium=rss&utm_campaign=youtube-direct-keeps-growing https://googledata.org/uncategorized/youtube-direct-keeps-growing/#comments Fri, 16 Dec 2011 22:45:00 +0000 https://googledata.org/?guid=a2b7b62c485ef330c30b1e9863f9379c YouTube Direct, our open source platform for obtaining and moderating user-generated videos (and photos!), was first announced over two years ago. Since that time, the project has continued to grow, and we’re happy to announce the latest round of additional features.

Most notably, we’ve released a completely rewritten YouTube Direct upload client for iOS devices (seen below). You can find it in its own open source project, and it complements the existing upload client for Android devices. As with the Android client, we see the iOS code as a reference implementation and a starting point for developers who want to build their own branded applications that submit video or photos that could be moderated using YouTube Direct.




The biggest change in the 3.0 release of the YouTube Direct server code has to do with multitenancy. As explained in this guide, YouTube Direct administrators can now deploy their code to App Engine once, and have App Engine serve many different logical instances of YouTube Direct, each with their own submission queues and moderators. While not every YouTube Direct deployment will benefit from this new functionality, we see it being particularly useful for agencies and other organizations that might have multiple individual clients, each interested in keeping track of their own YouTube Direct submissions.

YouTube Direct powers a wide variety of video submission initiatives: sites as diverse as the New York Times’ Reflections on 9/11 project, DrugFree.org’s “You are not alone” and Google Developers’ own “Share your story” page are running by YouTube Direct behind the scenes.

As always, please let us know about any specific issues you encounter with YouTube Direct or either of the mobile clients in the issue trackers associated with each open source project. If you have any general questions about YouTube Direct, we’d be happy to answer them in our YouTube API developer’s forum.

Cheers,
—Jeff Posnick, YouTube API Team
]]> https://googledata.org/uncategorized/youtube-direct-keeps-growing/feed/ 0 A Friendly Update https://googledata.org/youtube-api/a-friendly-update/?utm_source=rss&utm_medium=rss&utm_campaign=a-friendly-update https://googledata.org/youtube-api/a-friendly-update/#comments Wed, 07 Dec 2011 22:19:00 +0000 https://googledata.org/?guid=d0146cd8b1345e0f2da27f49aa5d9562 As you might have recently read, there’s an upcoming change that affects any “friends” you might have associated with your YouTube account. Your existing “friend” connections will be automatically converted into Address Book contacts, and when you visit YouTube.com you will be given the option of creating subscriptions to any or all of those accounts.

If you’re a developer, you might ask yourself how this impacts your existing code that uses the YouTube Data API. One specific feed that’s exposed via the API is no longer relevant: the friends activity feed. The users of your application may have converted their old friends to corresponding subscriptions, and in that case you can make use of a new feed in our staging environment that contains activity updates from the accounts you’re subscribed to:

 https://gdata.youtube.com/feeds/api/users/default/subtivity

As of right now on our staging server, and around December 14 in production, we will automatically translate requests to the existing friends activity feed’s URL into requests to the new subscriptions activity feed, rather than just returning an empty friends activity feed. While this translation will take place transparently behind the scenes, we encourage all developers who are using the friends activity feed to explicitly update their code to point to the new subscription activity feed as a best practice.

There are also API calls related to YouTube contact management that would accept either an email address (in a <gd:email> element) or a YouTube username (in a <yt:username> element). As a side effect of this migration, you can only use <yt:username> for these calls, which is what the API’s documentation has recommended doing all along. An attempt to use <gd:email> will lead to a HTTP 400 error response.

Thanks for bearing with us through these changes. If you have any questions or concerns, please let us know in our developer forum.

Cheers,
—Jeff Posnick, YouTube API Team
]]> https://googledata.org/youtube-api/a-friendly-update/feed/ 0 Support for the Watch Later List https://googledata.org/youtube-api/support-for-the-watch-later-list/?utm_source=rss&utm_medium=rss&utm_campaign=support-for-the-watch-later-list https://googledata.org/youtube-api/support-for-the-watch-later-list/#comments Wed, 05 Oct 2011 18:44:00 +0000 https://googledata.org/?guid=bed36849f258175b473ff249458aa08d
YouTube’s Watch Later list is the perfect way to keep track of interesting videos you come across but don’t have time to watch at the moment. Since rolling out that feature on the YouTube website and the embedded players, developers have been asking for ways to interact with the Watch Later list via the YouTube Data API. We’re happy to announce that this is now possible.

As explained in our documentation, the YouTube Data API treats the Watch Later list like a playlist, and the normal playlist operations (additions, retrievals, modifications) can all be performed on the Watch Later list. While every YouTube user has their own Watch Later list, it’s important to keep in mind that by default it’s a private playlist, so it will not normally be accessible unless you’re making an authenticated request as the list’s owner.

If you have any questions about using the Data API to work with the Watch Later list, please let us know in our developer forum.

Cheers,
—Jeff Posnick, YouTube API Team
]]> https://googledata.org/youtube-api/support-for-the-watch-later-list/feed/ 0 Auth Tokens & Unlinked YouTube Accounts https://googledata.org/youtube-api/auth-tokens-unlinked-youtube-accounts/?utm_source=rss&utm_medium=rss&utm_campaign=auth-tokens-unlinked-youtube-accounts https://googledata.org/youtube-api/auth-tokens-unlinked-youtube-accounts/#comments Thu, 25 Aug 2011 19:46:00 +0000 https://googledata.org/?guid=619485960cbd693fba6c15e540f91c43
Dedicated readers of this blog will remember our post from a few months back entitled “ClientLogin #FAIL”. In it, we laid out a number of scenarios in which attempts to use ClientLogin authentication would result in an error (and urged developers to move off of ClientLogin in general). The first failure scenario involved users whose YouTube account is not linked to a Google Account. Fortunately, the number of YouTube accounts in that unlinked state has decreased greatly over the past few months, so failures of that sort with ClientLogin are not as common now.

There’s another related failure scenario that we want to bring to everyone’s attention, this time involving both AuthSub and OAuth (collectively referred to here as “auth”) tokens. Starting on Wednesday, August 31, if your code attempts to use an auth token that was generated for an unlinked YouTube account, your request will fail with an HTTP 401 response code indicating that the token is invalid.

It’s important to note that what determines when the token is invalid is whether the YouTube account was linked at the time the initial auth token was generated. For example, if your code generated the auth token for an unlinked YouTube account on March 1, and then the user linked their YouTube and Google accounts on March 2, the auth token will still be considered invalid.

On March 31 we started to enforce the need to have a linked Google Account as part of the AuthSub and OAuth login flow, meaning that it was impossible to generate an auth token for an unlinked YouTube account after that date. So this change can only affect auth tokens generated before March 31 of this year.

While auth tokens normally don’t expire, users have the option of manually revoking them. If your code uses a revoked token, you’ll also get back an HTTP 401 response. If you’re using a client library, it will generate an exception to indicate the failure. It’s a best practice to make sure that your code handles invalid token errors by asking your user to go through the AuthSub or OAuth login flow again, storing the new token value and discarding the old one in the process.

If you have any questions about YouTube API authentication, please let us know in our developer forum.

Cheers,
—Jeff Posnick, YouTube API Team
]]> https://googledata.org/youtube-api/auth-tokens-unlinked-youtube-accounts/feed/ 0 The New CodeIgniter PHP Client Library https://googledata.org/youtube-api/the-new-codeigniter-php-client-library/?utm_source=rss&utm_medium=rss&utm_campaign=the-new-codeigniter-php-client-library https://googledata.org/youtube-api/the-new-codeigniter-php-client-library/#comments Tue, 23 Aug 2011 14:04:00 +0000 https://googledata.org/?guid=2ae0461e3fb59896bb8bf5142f2385bf
While the YouTube Data API’s RESTful nature means that talking to YouTube is as easy as making an HTTP request, using a client library is a great way to improve your YouTube Data API productivity and write code using your preferred language’s native features. PHP developers using the Zend framework have had access to a client library for a while now, and that library continues to be a supported way of using the YouTube API. But if you’re a PHP developer using the CodeIgniter framework, you’ll be happy to hear that there’s now an alternative client library available just for you.

A third-party developer, Jim Saunders, has developed a YouTube Data API library specifically for the CodeIgniter framework. You download the library on GitHub, and read the article he’s written to find out how to get started with some sample code.

While Jim wrote and still maintains the library, please feel free to ask any questions about the YouTube API in general in our developer forum!

Cheers,
—Jeff Posnick, YouTube API Team
]]> https://googledata.org/youtube-api/the-new-codeigniter-php-client-library/feed/ 0 Coming Soon: The Dark Player for Embeds https://googledata.org/youtube-api/coming-soon-the-dark-player-for-embeds/?utm_source=rss&utm_medium=rss&utm_campaign=coming-soon-the-dark-player-for-embeds https://googledata.org/youtube-api/coming-soon-the-dark-player-for-embeds/#comments Sat, 06 Aug 2011 05:04:00 +0000 https://googledata.org/?guid=e0dfab5f198c1edd3e28e15a10ddd497


Although we’re very excited about this change, which comes after months of design, research, and experimentation, we realize that some embedders would prefer a lighter color to match a lighter webpage, so we’re also announcing a few other themes that we’ll be making available. We also realize that some embedders would prefer something more mild than our use of red, so we’re happy to introduce a "desaturated" color option without any bright colors at all. (Note: Using the desaturated color disables the modestbranding option.)

To pick an alternate theme, pass in values for the "theme" and "color" player parameters. For instance, if you’d like to keep the traditional colors, you can pass parameters such as:
<iframe width="560" height="349"
  src="http://www.youtube.com/embed/9h1swNWgP8Q?theme=light&color=red"
  frameborder="0" allowfullscreen></iframe>
Here are all the new themes, including the new default:



If you have any questions about this change, you can ask them on our forum.

Cheers,
—Shannon -jj Behrens, YouTube API Team
]]> https://googledata.org/youtube-api/coming-soon-the-dark-player-for-embeds/feed/ 0 Introducing YouTube.com/create https://googledata.org/youtube-api/introducing-youtube-comcreate/?utm_source=rss&utm_medium=rss&utm_campaign=introducing-youtube-comcreate https://googledata.org/youtube-api/introducing-youtube-comcreate/#comments Fri, 01 Jul 2011 17:42:00 +0000 https://googledata.org/?guid=bdcf7a66bef76ad6a80faab69495cdb2 YouTube.com/create is a platform for third-party applications that enable users to create videos. The idea is simple. The third-party application runs in an HTML iframe on YouTube. The user creates a video with the application, and then the application uploads the video to YouTube for the user to watch and share.

Many different types of applications are already listed at YouTube.com/create. One True Media is a simple video editor. GoAnimate lets you create custom animations. Stupeflix lets you mix pictures, videos, maps, text, and music into a story. Xtranormal lets you turn anything you type into a fully-animated CG movie. Who knows what other developers have in store for YouTube.com/create?

Here’s one example of a company that decided to integrate with YouTube.com/create and experienced a signficant growth in traffic:



To list your application on YouTube.com/create, you’ll need the following:
  • The name of your application (max 60 characters).
  • A description of your application (max 50 words).
  • A 120x120 icon. The icon will display with rounded corners.
  • A tutorial video (hosted on YouTube).
The application itself must meet the following requirements:
  • It must support Google federated login using OpenID.
  • It must post the resulting video to YouTube. The application should upload the video on behalf of the user using OAuth2 or AuthSub.
  • It must provide branding within the user interface if the user is required to upload assets (to make it clear that the upload is going to the third-party application, not to YouTube).
  • It must not show ads within the iframe. However, the freemium model is acceptable, providing the base level of functionality is useful.
The application must run within the context of a 960px-wide iframe that will display on YouTube. The iframe does not limit the vertical space that your application occupies. For best appearance, your application should have a white background.

When you are ready to submit your application for inclusion on YouTube.com/create, submit it to the YouTube Project Gallery using the hashtag #create, and YouTube will contact you via email.

For more information about integrating with YouTube’s API, check out our developer documentation and join us on our mailing list!

Cheers,
—Shannon -jj Behrens, YouTube API Team
]]> https://googledata.org/youtube-api/introducing-youtube-comcreate/feed/ 0