Google Data » Jeffrey Posnick

Committing to the YouTube Data API v3

Jeffrey Posnick — Tue, 04 Mar 2014 21:52:00 +0000

Since the YouTube Data API v3 launch in 2012, many of you have used the v3 API to create integrations like Next Big Sound and Interesante.

The YouTube Data API v3 is now on the list of APIs identified in our deprecation policy, which means we will notify developers a year in advance before deprecating v3. Note, however, that some specific v3 features are excluded from this notice requirement. You can find the list here. As a reminder, v3 gives you the ability to get information about Freebase topics associated with the videos, more search features, improved client libraries support and much more.

To focus on improving v3, it’s time to say goodbye to our old friend, v2. In keeping with deprecation policy, most API functionality will remain available for use until April 20, 2015, so you have more than a year to move to the new API. See the deprecation policy in the Terms of Service for more details.

While v3 offers the majority of v2 functionality, there are currently a couple of tasks that can only be done with the older API. Specifically, applications that manage captions or that work with video comments still need to use the v2 API until modern equivalents are available. Our goal is to provide similar functionality well before the April 2015 shut-off date—please subscribe to this blog, the YouTube Data API v3 revision history page, or follow +YouTubeDev on Google+ to keep up-to-date.

If you’re a v2 developer who’s looking for help migrating to v3, the best place to start is with our documentation and FAQs. We've also made several videos that explain v3 concepts, such as registering for API access and handling authorization with OAuth 2.0.

Cheers,

—Jeff Posnick, YouTube API Team

Making stories with social media and YouTube videos

Jeffrey Posnick — Thu, 27 Feb 2014 15:18:00 +0000

By Xavier Damman, co-founder of Storify

(Cross-posted from the Google Code blog, where the post is part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.)

Storify is part of the Google I/O Sandbox. Please come say hi to find out more about how you can leverage our APIs so your users can remix your content to create stories to share on social networks.

Storify provides a super simple drag and drop user experience to create stories using elements from the web: tweets, YouTube videos, Facebook updates, SlideShare presentations, audioboo files, and so on (see Storify in action here). This post explains how we incorporate videos in Storify using YouTube Data API and Player API. All the code snippets are in JavaScript. In fact, our full stack is in JavaScript: we use NodeJS and MongoDB which we think is an über cool mix.

The source of the source

To create a Storify source, we need to be able to get a feed of results using JSONp (basically JSON with a callback function so that you can do cross domain calls; from the YouTube API perspective this is the JSON-C format). For YouTube, the main search API endpoint looks like this:

request: function(formdata) {
   return {
      'url' : 'http://gdata.youtube.com/feeds/api/videos',
      'params': {
         'v'  : 2,
         'max-results' : 20,
         'alt'  : 'jsonc',
         'q'  : formdata.keywords
       }
    };
  }

This function is called when the user clicks Submit in the search tab of the YouTube source in the Storify Editor. The main controller executes the request and sends the JSON result to the results method, which returns an array of normalized results:

results: function(json) {
 
  if (json.data && json.data.totalItems && json.data.totalItems == 0) {
    throw "No results found";
    }
  
  var videos = json.data.items;
  var results_array = [];

  for (var i = 0; i < videos.length; i++) {
        var normalizedResult = {
           permalink   : 'http://www.youtube.com/watch?v='+videos[i].id,
           source  : 'youtube',
           elementClass : 'video',
           metadata  : videos[i],
           thumbnail   : videos[i].thumbnail.sqDefault,
           title: videos[i].title,
           description  : videos[i].description.substr(0,140),
           author: {username: videos[i].uploader },
           created_at  : videos[i].uploaded,
           oembed: {html: ''
           }};
     
           results_array.push(normalizedResult);
  }
  return results_array;
}

Thanks to this normalized representation of a story element – in this case, it’s a video object – we can build an object-oriented story as the user drags and drops any of these elements. This technique has multiple benefits: we maintain attribution to the original content creator, and we can track the content as it spreads across the web (how many times it has been seen and from where).

The story element also provides the oEmbed HTML code. This is used to render the video embed when the video is added to the story. For that purpose we use the YouTube Player API with their new iframe embed.

Story.json

We have a very simple way to get any data out of our platform: just append .json to any storify.com URL and you get the JSON representation of the content of that page.

For example:

http://storify.com/latest.json?topic=googleio returns the latest stories with the tag #googleio
http://storify.com/xdamman.json returns the user object and the user’s latest stories.
http://storify.com/xdamman/googleio.json returns the story object of the story “GoogleIO” of xdamman. You can use this to easily filter the elements of the story to retrieve only the YouTube videos of a given story and create a fancy HTML5 visualization (see the slideshow or this version). You can see some open source examples at http://github.com/storify/templates.

Add the Storify Editor to your site

The Storify Editor can be called in an iframe. You just need to provide a callback parameter, like this: http://storify.com/story/new?callback=yoursiteurlcallback. The user will be asked to authenticate with Twitter and then will be able to create a new story. Once the user is done and hits “Publish”, we call you back, passing you the permalink of the new story created:
yoursiteurlcallback?permalink=storyPermalink.

You can then either fetch the JSON of the story by appending “.json” to the storyPermalink or you can embed the story by loading . This is a great way to provide your community with a way to create stories right from your site.
This is only the start. We plan to open a Sources API so that any developer can build a source for any service. Please come see us at our booth at the Google I/O Sandbox if you’re interested in joining our developer community. And check out this article in the New York Times to learn more.

Come see Storify in the Developer Sandbox at Google I/O on May 10-11.

Xavier Damman is the co-founder of Storify. He is also the founder of HackDemocracy, a community of hackers who want to improve our democracies using technology.

What to watch? Our APIs can help!

Jeffrey Posnick — Thu, 12 Sep 2013 19:00:00 +0000

It’s an age-old question: what to watch? Applications that integrate with YouTube have access to countless hours of videos, and, as a developer, you have an interest in helping your users find the videos and channel most relevant to them. This blog post will walk you through a few ways that you can use the latest YouTube Data API to discover great content.

If you have an OAuth 2 token for the current user, your application can make a call to youtube.activities.list(part=”snippet”, home=true) to get back a list of videos and channels similar to the recommendations that the user would see on the YouTube.com home page. These results are customized for each individual user, and the list is kept fresh automatically, so it’s a great way to present your users with content they’re likely to enjoy.

Even if your users are not logged in, there are still are a few charts and guides at your disposal to aid in discovery.

To find popular videos your users might want to watch, youtube.videos.list(part=”snippet”, chart=”mostPopular”) is the basic API call to use. By default, it will return a list of videos in any category that are considered popular globally. If this is too broad a list, though, you can narrow things down using the regionCode or videoCategoryId (or both) parameters. regionCode can be set to a two-letter country code to retrieve a list of videos popular in that specific country (though not every country is currently supported). videoCategoryId needs to be set to an ID corresponding to one of our existing video categories—you can retrieve a list of valid categories and their corresponding IDs via youtube.videoCategories.list(part=”snippet”, regionCode=”XX”), where “XX” is also a two-letter country code.

There’s an analogous set of API calls that you could make to find channels your users might be interested in. youtube.guideCategories.list(part=”snippet”, regionCode=”XX”) will return a list of all the channel categories that are available in a given country. Once a user has chosen a category, you can get back a list of the most relevant channels in that category via a call to youtube.channels.list(part=”snippet”, categoryId=”CATEGORY_ID”), where “CATEGORY_ID” is the ID of the guide category you’re interested in. At that point, you could display a list of the most recent videos associated with each channel, and give your users the option of subscribing (assuming they grant OAuth 2 authorization first).

All of these examples assume that you’re using the latest version of the YouTube Data API, v3. Developers still using the Data API v1 or v2 should be aware of some recent changes to our older content discovery mechanism, standard feeds. As explained in the documentation, all of the previous different types of standard feeds are now returning the equivalent of the most_popular feed, with the time parameter set to “today”. If you are still using v1 or v2, there’s no time like the present (time=”today”, if you will) to make the switch to v3.

Update: For a walkthrough and demos of all the API calls, please watch this episode of YouTube Developers Live:

Cheers,

—Jeff Posnick, YouTube API Team

Google+ page identities and the YouTube API

Jeffrey Posnick — Tue, 25 Jun 2013 00:40:00 +0000

As more YouTube channels start using Google+ page identities, here are some best practices to ensure that your code can make authorized API calls to access the channel.

With Google+ page identities, there can be many channels associated with a single Google Account. For example, when a user Alice Smith signs into her Google Account, she may have her “Alice Smith” (personal) channel on that account, and potentially additional channels, linked to Google+ pages, on associated accounts. These associated accounts do not have a password by default; she gets access to them by signing into her personal account, and then using a switcher to go back and forth between them.

How does this channel selection work with APIs? With API access through web-based OAuth 2, the switcher comes automatically. The web flow will ask Alice which account she wants to use, after she signs into her “Alice Smith” account. The OAuth 2 tokens your application gets back work just as they do today.

The OAuth 2 web-based “Select an account” interface, allowing a user to grant access to their personal channel or any channels linked to Google+ pages that they manage.

If you’re not using web-based OAuth 2 (you are still relying on one of our deprecated authorization methods), or if you are an Android developer who is using OAuth 2 (there is currently no native Android account switcher), then the API will choose the “wrong” channel in some cases, or even no channel (e.g., if the personal account doesn’t have a channel). When this happens, the user has two options to specify the correct channel:

Use the Advanced Account Settings tool to select which channel should be used. This is recommended when a user has one channel they want to use for all applications.
Set up login credentials for each of their Google+ pages, and specify those credentials, not their normal Google Account credentials, for each application that needs access.

As a best practice, we recommend that you ensure users know of these options, so your application will access the correct channel. Even more importantly, we recommend that all applications provide visual feedback letting users know which channel is currently authorized. If you’re still using version 2 of the YouTube Data API, you can retrieve the profile of the special identifier default; this corresponds to the currently authorized channel’s profile. In the version 2 response, the channel’s display name is returned as an attribute of yt:username, and the profile image can be found by looking at media:thumbnail. If you’ve started using version 3, then the method to use is channels.list() with the part=snippet and mine=true parameters set. The version 3 response contains a channel’s display name in channel.snippet.title and profile image in channel.snippet.thumbnails.default.url.

To summarize, here are the high-level points to keep in mind:

OAuth 2 will automatically display a “Select an account” web interface, allowing users with multiple channels associated with their account to choose which one they’re authorizing access to.

...this doesn’t apply to Android OAuth 2, yet.

Use of other authorization methods will mean some users need to specify which channel to use, either in their Advanced Account Settings (if they consistently use one channel), or by setting up login credentials for each channel, and using them as needed.
All developers are strongly encouraged to display visual feedback letting their users know which channel is currently authorized.

Update: This YouTube Developers Live show with Sherry Listgarten, the Product Manager responsible for Google+ and YouTube integration, goes into more details about plans for Google identities and YouTube channels. It also contains a video walkthrough of many of the points covered in this blog post.

Cheers,

—Jeff Posnick, YouTube API Team

YouTube for Developers on… YouTube!

Jeffrey Posnick — Wed, 13 Mar 2013 21:26:00 +0000

For almost a year, we’ve been recording weekly shows for YouTube API developers as part of the Google Developers Live series, hosted on the Google Developers YouTube channel. Now, if you want to get just YouTube API-related videos, check out the new YouTube for Developers channel.

On our new channel, you’ll find an up to date playlist of all our YouTube Developers Live shows (which we’ve also embedded below), as well as other playlists with videos related to the API. We still recommend subscribing to Google Developers as well, especially if you plan to work with multiple Google APIs in your applications.

Not surprisingly, we’re using the YouTube Data API v3 to maintain the YouTube Developers Live playlist, and also to post channel bulletins whenever any video related to YouTube is added to the Google Developers channel. If you’re interested in doing this type of automatic curation in your own channels, you can take a look at the open source Ruby script that does the work for us.

Cheers,
—Jeff Posnick, YouTube API Team

ClientLogin using Google Accounts

Jeffrey Posnick — Tue, 11 Dec 2012 22:14:00 +0000

Long-time readers might remember a blog post from a while back entitled “ClientLogin #FAIL”, in which we covered the myriad ways in which your ClientLogin authorization attempts might result in an error. Even though ClientLogin has been officially deprecated since April 2012, and even though we’ve been recommending that developers switch to OAuth 2 for longer than that, we know there are still a good number of legacy applications out there that still rely on ClientLogin.

If you are a developer of such an application, there’s another thing that you (and your users) will need to start watching out for: at some point in the future, we will start requiring that the username parameter passed to ClientLogin (i.e. what’s referred to as the Email= value in the ClientLogin request) correspond to the full email address of the Google Account that’s associated with an underlying YouTube channel. We’ve supported using Google Account email addresses with ClientLogin for many years now, ever since we started linking Google Accounts to YouTube channels, but old habits die hard, and many users still use YouTube usernames.

We haven’t yet determined a date for when we still stop supporting ClientLogin with YouTube usernames and will provide additional details when we know more about when it will take place. However, if you use ClientLogin, it’s not too early to start encouraging your application’s users to start providing their Google Account email addresses instead of their YouTube usernames when logging in. If you have the ability to update your existing application’s user interface, we recommend doing so to indicate that the username field should take a Google Account email address. If you have any online help materials or technical support for your software, update them to ensure that users know to provide their Google Account email address.

Users who log in via the YouTube.com web interface, or who go through the AuthSub, OAuth 1, or OAuth 2 web authorization flows will soon be required to use their Google Account email address instead of their YouTube username as well. This web-based transition will take place well before we deprecate YouTube usernames for ClientLogin, and it should be transparent to developers since Google controls the user interface for these flows. For more information, see this help center article.

As mentioned, we’ll have a follow-up post in coming months with more details about exactly when we’ll stop supporting YouTube usernames with ClientLogin. That post will also communicate the exact error message that ClientLogin will return when a YouTube username is used. We’d like to close with one more plea: ClientLogin is deprecated, and is technically inferior to OAuth 2 in a number of important ways. Our new Google APIs client libraries provide first-class OAuth 2 integration that developers can take advantage of in their new code, or back port to their existing code. You will be doing your users a service and making their accounts more secure by transitioning from ClientLogin to OAuth 2.

Update (June 2013): The change mentioned in this blog post is now in effect. Attempts to use ClientLogin with a YouTube username will result in HTTP 403 Forbidden responses, with Error=BadAuthentication in the response body.

Cheers,
—Jeff Posnick, YouTube API Team

Upcoming HTTPS Certificate Change

Jeffrey Posnick — Tue, 13 Nov 2012 15:38:00 +0000

If you’re a developer who uses the YouTube API, and if you make your requests to the API using HTTPS, there’s an upcoming change that you should be aware of. Sometime in early August 2013, Google will be changing the certificates used for establishing secure HTTPS connections to all of our servers, in what we anticipate will be a backwards-compatible manner. Still, since there are so many slight differences in HTTPS client implementations, we encourage you to test your existing code in advance of this change and to report any issues that you do encounter.

The new certificates are currently active on https://cert-test.sandbox.google.com/, and we recommend testing your HTTPS client implementation against that URL.

If you’re using HTTP instead of HTTPS to access the YouTube Data API then you also won’t be affected by the new security certificates—but you really should start using HTTPS!

This post on the Google Online Security Blog has more information about the upcoming change, which roll out in early August, 2013.

Cheers,

—Jeff Posnick, YouTube API Team

The YouTube API on Stack Overflow

Jeffrey Posnick — Fri, 14 Sep 2012 18:53:00 +0000

Many of you are already familiar with the terrific Stack Overflow website, which has become the de facto resource on the web for all types of programming questions. And many of you have been asking YouTube API questions on Stack Overflow for some time now, but haven’t received any official responses from the YouTube API Developer Relations team. That’s because, for the past five years or so, our focus has been on providing developer support via our dedicated Google Group. We’ve decided that instead of continuing to maintain a dedicated Google Group for YouTube API questions, it would help more users if we focused on responding to Stack Overflow posts.

We encourage all developers who have questions about the YouTube API to start posting on Stack Overflow today using the tag youtube-api. You can use this new question template to pre-populate the tag for you so that you don’t forget. While we’ll do our best to find and answer relevant questions that aren’t tagged with youtube-api, you’d be making our job easier (and you’d get a quicker answer) if you tag things correctly from the get-go.

Here are a few tips for folks new to Stack Overflow:

Before posting, search to make sure your question hasn't been asked before. To do this, put [youtube-api] as the first part of your search, then type in some keywords that describe your problem or question.
If you need to ask a question, make sure you apply the youtube-api tag, as well as the tag that indicates the language that you're using. If you're using PHP to access the API, your question should be tagged youtube-api as well as php.
Make sure you watch your question after posting it, as experts that can provide you with an answer might leave comments to ask you for clarification.

Stack Overflow prides itself in being a destination for questions and answers, and not a place to file bug reports or feature requests. We ask that developers do not post on Stack Overflow for those sorts of things, and instead make use of the templates we have for filing a bug or filing a feature request in our existing public issue tracker. (Be sure to check the list of existing open issues before filing a duplicate.)

On October 15, we’ll be switching the existing discussion Google Group into archive-only mode, meaning that it will no longer accept any new posts. You don’t have to wait until October 15 to start asking questions on Stack Overflow or to file reports in the issue tracker, though.

For those developers who mainly “lurked” in the discussion Google Group and used it as a way of getting official announcements about the YouTube API, we have a number of other communication channels to recommend. Subscribing to this blog’s RSS feed is a great idea, for instance. You can also follow us on Google+ at http://google.com/+YouTubeDev. If you’d like to submit a question to one of our weekly YouTube Developers Live broadcasts, you can do that for the next upcoming scheduled show. Finally, for those who prefer to get updates via email, we will be keeping the announce-only Google Group active, and we’ll continue to post important messages there.

Cheers,
—Jeff Posnick, YouTube API Team

Video Tags: Just for Uploaders

Jeffrey Posnick — Tue, 28 Aug 2012 15:54:00 +0000

Update: This change also applies to tags, which were not mentioned in the original announcement.

If you follow the YouTube Creator Blog, you might have recently seen a post announcing that video tags (also known as keywords) would no longer be displayed to viewers of a video on YouTube’s website. They aren’t going away from the video itself, though—the owner of the video can still create tags for new videos and edit tags for existing videos, and video tags will still provide an important signal used to surface relevant results when searching for videos.

We’re going to be making some corresponding changes to all versions of the YouTube Data API to mimic this behavior in API responses. Starting later today, August 28, on the staging server and September 4 on the production server, any time you get a video entry back from any API method, it will have an empty element. This is a valid response from the API that your application should already handle gracefully, since videos are not required to have any keywords to begin with.

The exception to this rule is when you make authenticated requests to the API, and you request a video entry that’s owned by the currently authorized user. In that scenario, you will get back a element that contains the full list of tags for the video, and you can read, update, or remove those video tags using the standard API operations.

Important: If your application allows video owners to update the metadata of their videos, please ensure that you include the proper Authorization header for both read and write operations. Otherwise, you could accidentally return an empty list of video tags when retrieving an existing video, and end up overwriting the video’s tags if you update the metadata. Video tags continue to play an important role in helping viewers discover your videos when searching on YouTube.com or via the API, so if your application does support metadata editing, please make sure you allow owners to tag their videos properly.

Cheers,
—Jeffrey Posnick, YouTube API Team

“Super Tuesday” Reporting, Powered by YouTube Direct

Jeffrey Posnick — Mon, 05 Mar 2012 23:25:00 +0000

It’s Presidential election season in the United States, and YouTube’s News and Politics team is partnering with Storyful to highlight timely political videos from across the country. With that in mind, we’re excited to announce that citizen journalists can now submit videos documenting the election process by using the new Android and iOS mobile applications powered by YouTube Direct and released by Storyful. Both applications are based on the open source code examples we’ve released for Android and iOS, and submit videos to the instance of YouTube Direct that Storyful curates.

Tomorrow is “Super Tuesday,” when 10 states will hold their primary elections. If you live in one of the Super Tuesday states, we encourage you to install the Storyful Direct mobile application and shoot some footage documenting your political experience—a selection of videos will appear on YouTube and google.com/elections throughout the day. Even if you don’t live in a state that’s holding a primary tomorrow, the Storyful Direct apps can be used to document your experience during the runup to the Presidential election in November.

And if you’re a developer who isn’t yet familiar with the YouTube Direct platform, you can find all the information you need to get started with the web and mobile platforms at the Google Code project page.

Cheers,
—Jeffrey Posnick, YouTube API Team

Insight Report Enhancements

Jeffrey Posnick — Mon, 31 Oct 2011 20:40:00 +0000

YouTube Insight reports provide video owners with statistics about their viewership above and beyond public view count information. They’re a crucial tool when you want to find out more about the demographic or regional breakdown of your videos’ viewership, or what sites are embedding your videos. The YouTube API has provided a way for developers to retrieve YouTube Insight reports in a comma-separated value format for some time now, but there are some recent additions to the Insight retrieval process that we wanted to highlight.

First, we wanted to mention that the API allows developers to access Insight reports for an entire channel’s worth of videos, not just a single video. The appropriate base URL to use for downloading a channel report can be found when requesting the profile corresponding to the user who’s authenticated with the YouTube API, as described in our developer’s guide. The element looks something like:

It can be identified by the rel='http://gdata.youtube.com/schemas/2007#insight.views' attribute. As with single-video Insight retrieval, these reports are only available to the corresponding owner, so authenticating as the correct user is a must.

Current users of the Insight API know that we previously supported a rather restrictive set of custom date ranges for reports. We’re happy to announce that these restrictions have been relaxed—we now support date ranges that span 31 days (up from 28) and, more significantly, you can specify any arbitrary start date for your report going back to March 1, 2009. Please see our documentation for more information on formatting your custom date range parameters to take advantage of this historical data.

As always, we’re waiting to hear from you in our developer forum with any questions or comments.

Cheers,
—Jeffrey Posnick, YouTube API Team

More Ways to Find What You’re Looking For

Jeffrey Posnick — Fri, 14 Oct 2011 02:27:00 +0000

We’ve got some exciting additions to the list of supported search parameters for YouTube feeds that should make it easier to narrow down your search results to exactly the videos you’re looking for. Each of these search parameters has an accompanying element in a video entry’s metadata, which we’ll cover as well. Here's a quick rundown:

license - This parameter lets you filter search results based on whether they're Creative Commons licensed (license=cc) or use the standard YouTube license (license=youtube). The default behavior is to return videos regardless of their license in search results. The license for a given video entry is reflected in its element.

hd - This one lets you request videos that have high-resolution versions available. If you specify hd (no value is needed), all the videos in your search results will be available for playback in at least 720p, and higher resolutions, like 1080p, might be available, too. If you leave the parameter out, then search results won't be filtered at all based on resolution. The element corresponds to this search parameter.
duration - If you cater to an audience with a short attention span, then this parameter is for you. This parameter lets you filter search results based on video length. To find videos less than 4 minutes long, use duration=short. To find videos that are between 4 and 20 minutes long (inclusive), use duration=medium. Only videos that are longer than 20 minutes will be returning when requesting duration=long. The element in a video entry provides a video’s exact runtime.
3d - Finally, for those of you living in the future who want to find 3D content on YouTube, this aptly-named parameter is for you. Adding 3d (no value is needed) to your searches will ensure that all videos you get back are available for viewing in 3D. Videos that are available in 3D will have a element in them, and that element will contain more detail about the nature of the 3D content in the given video.

Putting it all together, let’s say you want to use the API to find Creative Commons-licensed 3D YouTube videos that are available in resolutions of 720p and above and are longer than 20 minutes.The following request URL will return a feed of such videos:

https://gdata.youtube.com/feeds/api/videos?prettyprint=true&v=2&license=cc&hd&duration=long&3d

As always, if you have any questions or comments, please let us know in our developer forum.

Cheers,
—Jeff Posnick, YouTube API Team

Say Hello to the New Playlist Player

Jeffrey Posnick — Fri, 15 Jul 2011 01:19:00 +0000

While the YouTube embedded single-video player has seen a number of improvements in the past few months, the embedded playlist player has lagged behind—until now. We’re happy to introduce a completely rewritten embedded playlist players, ready for inclusion on any of your web pages that needs to display a series of videos in the same player. The new embedded playlist player has a user interface that should be familiar to anyone using our current single-video player. Take a look at the example below:

Any developer can try out the new playlist player right now by appending the version=3 URL query parameter to the URL they’re currently using for an embedded playlist player. For example, if you’re currently specifying http://www.youtube.com/p/E46798C874B35B7F?fs=1 in your <object>/ tags, using http://www.youtube.com/p/E46798C874B35B7F?fs=1&version=3 will play back the same playlist in the new player.

Alternatively, you can just wait until next week. We plan on making the new version of the embedded playlist player the default on July 20, and at that point existing URLs will automatically trigger the new player.

We do encourage all developers to take the opportunity to test the new player with an explicit version=3 in advance of that change—while we don’t anticipate any issues with using the new version, if you do notice anything that is amiss, you can let us know in the YouTube API Google Group.

Cheers,
—Jeff Posnick, YouTube API Team

Sunsetting the Custom Player

Jeffrey Posnick — Wed, 22 Jun 2011 19:07:00 +0000

YouTube previously offered a specialized way of embedding playlists (as well as uploads and favorites feeds) for playback on third party sites in a customizable interface—we called this the Custom Player. While the Custom Player had its fans, it never saw a great deal of usage, and we recently removed support for the creation of new Custom Players. If you’ve already created a Custom Player and have it embedded on your site it should continue to work as-is; the only thing that has changed is that new Custom Players cannot be created.

One common concern is that owners cannot update the videos featured in existing Custom Players. We recommend that you update the associated playlist to reflect the videos that you would like to feature in the Custom Player, or embed a new playlist.

While we will not allow for the creation of new custom players at this time, similar functionality is available through creating embedded playlists, which can be accessed by visiting http://youtube.com/my_playlists, clicking Share, and then using the embed code given there.

We apologize that taking away the ability to create new Custom Players caught anyone off guard. Stay tuned to this blog for upcoming announcements about modern alternatives to the Custom Player—we’ve got some exciting things in store!

Cheers,
—David Boyle, YouTube Team

The next step in embedded videos: HD preview images and a logoless option

Jeffrey Posnick — Mon, 13 Jun 2011 19:54:00 +0000

(Cross-posted from The Official YouTube Blog.)

It may be hard to imagine but YouTube’s video preview images represent to many the ultimate deciding factor as to whether or not they watch a video. If a preview image looks interesting, it can mean the difference between someone pressing the play button. In addition, your site and the videos on it represent to you polished masterpieces. Yet, your videos’ preview images can appear lower in quality, and sometimes you don't want a logo in your player. So today we're rolling out new features for both situations: HD preview images and the option to remove the logo from your player.

HD preview images
Video resolutions have been increasing across YouTube, and the sizes of your embedded players are bigger than ever. But until now, video preview images in today’s larger players (e.g. the image that appears before you click “Play”) haven’t kept up with your high-quality and larger videos.

Any new video uploaded to the site in a resolution of 480p or higher will have an HD preview image wherever the player is embedded. The difference is even more striking with larger embeds (which don’t fit on this blog), so try it out yourself and see what we’re talking about. Here’s an example:

Before:

Now:

We’ll also automatically give HD preview images to older videos in the next few weeks, as long as they’re 480p or larger.

A note for partners, if you’ve uploaded a custom preview image for your video, you’ll need to re-upload a new one for your videos in order to upgrade it to HD (1920 x 1080px, 2MB max).

Logoless player
Many of you have asked us for a version of the YouTube player without a YouTube logo, so the video plays without any branding nearby. We’ve now added a simple option to do it. At the end of the video URL in your embed code, just add the code ?modestbranding=1 and the player will show without the YouTube logo in the control bar. Note that a small “YouTube” text label will still show up in the upper-right corner of a paused video when you hover over the player. We’ve published the full list of the player’s possible parameters, and here’s an example:

We hope these features help you show your videos the way you want them to be seen.

Kevin Wilson, Software Engineer, recently watched “I'm Yours (ukulele)” and Ravi Kanodia, Software Engineer, recently watched “Candy BBQ - Epic Meal Time.”

YouTube @ Google I/O: API Bootcamp

Jeffrey Posnick — Mon, 13 Jun 2011 19:34:00 +0000

There was more to Google I/O 2011 than formal presentations—Google I/O BootCamp was a day-long developer event geared towards providing beginning-level content to newer developers. Two engineers who work on the YouTube Data API, Raul Furnică and Günther Noack, participated in a BootCamp session that introduced the YouTube Data API and covered examples of how it could be used to discover and curate YouTube content.

If you’re just getting started with the YouTube Data API and want an overview of what it offers, or if you have a particular interest developing apps for content curation, please do check out the session video embedded below!

Cheers,
—Jeff Posnick, YouTube API Team

YouTube @ Google I/O: All About Captioning

Jeffrey Posnick — Fri, 03 Jun 2011 15:17:00 +0000

Google I/O 2011 may be over, but we’re continuing our series of blog posts recapping the great developer material covered at the event. We previously covered our talk on the iframe Player API, and the next presentation we’re highlighting is “The YouTube Caption API, Speech Recognition, and WebVTT captions for HTML5”.

The session features Jeff Posnick from the YouTube Developer Relations team, Naomi Black from the Accessibility Engineering team, and Cynthia Boedihardjo, a Live Stream Program Manager. As the session’s title suggests, a number of different topics were covered, with video accessibility and captions the common theme throughout.

The material covering the YouTube Captions API, including a sample application that demonstrates using the API from Python, will be of particular interest to the YouTube API developer community. The talk also includes some early WebKit demos of WebVTT implementations for the element in HTML5 as well as more information and stats about the Live Caption gadget launched at Google I/O. The gadget provides captions alongside streaming video.

The full video of the session is embedded below, and the slides from the talk are available as well.

Cheers,
—Jeff Posnick, YouTube API Team

YouTube @ Google I/O: The iframe Player API

Jeffrey Posnick — Tue, 31 May 2011 19:22:00 +0000

Google I/O 2011 may be over, but all the great developer information lives on! We want to start our recap of YouTube-related I/O activities by highlighting our developer presentation entitled “YouTube’s iframe Player: The Future of Embedding”.
The session features Jeff Posnick and Jarek Wilkiewicz from the YouTube Developer Relations team, and Greg Schechter, one of the engineers who works on the iframe Player and its API. Topics covered include the development of the iframe Player, challenges related to exposing an API on an iframe element, differences between the ActionScript 3 Player API and the iframe Player API, and real-world example applications that use the new API.

The full video of the session is embedded below (using the iframe Player, of course), and the slides from the talk are available if you’d prefer to read along with the presentation. Be sure to check out the sample web application (along with its source) that illustrates iframe Player API usage as well!

Cheers,
—Jeff Posnick, YouTube API Team

Reinventing News Video with Knight, Mozilla, and the YouTube API

Jeffrey Posnick — Thu, 05 May 2011 20:00:00 +0000

(This is a guest blog post by Ben Moskowitz of the Mozilla Foundation.)

Over the next few weeks, the Knight Foundation and Mozilla are running a series of news innovation challenges. The goal: get the world's smartest hackers thinking about how news organizations can harness the open web.

The first challenge, which runs through Sunday, May 8th, is all about video. This is a great opportunity to be creative with the YouTube APIs—if you have a big, ambitious idea, you could get support from Knight and Mozilla to make it real.

Check out the brief:

Video is a central part of many people's daily news experience. But despite all the opportunity offered by the open web (social, linkable, real-time, dynamic), most online video is still stuck in a boring embedded box, like "TV on a web page." This offers little in the way of context or opportunities for viewers to engage more deeply.

If you're reading this blog, you're probably interested in hacking web video. The challenge is: how can web video bring innovation to the news biz?

How would you take advantage of modern JavaScript, advanced HTML5 features, and the richness of web service APIs like YouTube's? How would you make use of the millions of connected YouTubers who upload 35 hours of video per minute? What are the news video opportunities that are unique to the web?

The YouTube API blog is rife with possibility: check out some posts on curation, remix, and the YouTube chromeless player. Read up on YouTube Direct, a cool open source app, or visit the YouTube API project gallery. While you're at it, check out popcorn.js, the HTML5 video framework (now including a wrapper for the YouTube Flash player!)

What kinds of innovations would you bring to the newsroom? How would you transform news video?

Head over to the challenge site and enter your idea. Submit a short abstract, a napkin sketch, or however you choose to best express yourself. By entering your idea, you'll be eligible to take part in an online learning lab with famous hackers like Christian Heilmann, Burt Herman, Aza Raskin, John Resig. And if your idea rocks, Knight and Mozilla will fly you to Berlin for an in-person development sprint, to take your idea from napkin sketch to prototype to deployment.

Finally: five participants will be invited to become Knight-Mozilla news technology fellows. Fellowships are paid positions inside newsrooms at the BBC, Boston.com, The Guardian, Al Jazeera English, and Zeit Online, to build world class web apps for a large audience.

The challenge ends May 8th, so hurry and study up on the YouTube APIs. For Sunday’s deadline, all you need is a great idea, a rough sketch. If you proceed to the next phases, there will be plenty of time and support to further prototype and build out your idea. Mostly, we want to get to know you through this challenge. Happy hacking!

ShortForm: Mix and Share the World’s Videos

Jeffrey Posnick — Thu, 28 Apr 2011 19:56:00 +0000

By Jereme Monteau, Lead Developer at ShortForm

(Cross-posted from the Google Code blog, where it is a part of Who's at Google I/O, a series of guest blog posts written by developers who are appearing in the Developer Sandbox at Google I/O.)

ShortForm is a new entertainment medium where you find continuous channels of the best videos, curated by a growing community of VJs. At ShortForm you can be a viewer, a VJ, or both. Viewers subscribe to channels of interest, lean back, and enjoy a continuous stream of videos. VJs mix and share the world’s best videos into continuous channels.

The developers at ShortForm worked with various YouTube Data APIs in order to deliver both the Viewer and VJ experience.

Standard Feeds and User Playlists: ShortForm makes it easy and fun for anyone to VJ a channel. We also auto-curate a select set of channels to surface mainstream content that would appeal to most audiences. For example, our YouTube Hits channel includes content from the standard YouTube video feeds such as Top Rated, Most Viewed and Most Popular. ShortForm developed a system for retrieving video entries and their associated metadata, and then ordering them in playlists based on a ranking algorithm.

Favorites and Uploads: ShortForm allows VJs to import their YouTube favorites and uploads into their channels quickly and easily by authenticating via YouTube’s OAuth provider. Once a user has connected their ShortForm account to their YouTube account, we are able to allow them to import their favorites and uploads through an authenticated call to the YouTube Data API. In the future we will streamline the process of uploading videos to YouTube by allowing VJs to upload videos to YouTube directly from ShortForm while adding those videos to their ShortForm channel in the same flow.

Player API: Providing a seamless channel viewing experience on ShortForm requires that we integrate tightly with YouTube’s JavaScript API to the ActionScript 3 player. This allows us to properly handle video events to ensure continuous playback. Users have full control over their viewing experience using the next and previous video buttons, which load videos into the YouTube player. We have also begun integrating with the new iframe API interface that is currently in beta and have seen promising results in our initial tests across desktop and mobile platforms.

Android Tablet: Tablet computing represents an exciting opportunity for ShortForm to provide a first class viewing experience in a new package. We have begun testing and looking for places to optimize the viewing experience on tablet devices.

ShortForm Widget: Our embeddable widget syntax was inspired by YouTube’s new iframe embed syntax. We believe this is the simplest, most flexible and most powerful way to allow our users to embed their channels anywhere on the web.

We are thrilled to be a part of Google I/O and in order to demonstrate the power of ShortForm, we are putting together a Google I/O Sandbox channel, a continuous channel of product pitches and demos from companies represented in the I/O Developer Sandbox. We invite all Sandbox companies to submit a video of their product pitch or demo. Details can be found at the ShortForm at Google I/O page. Well use the channel to preview cool companies in the Sandbox before the conference. The channel will also provide media members with a summary of all the technology from all sandbox companies.

Lastly, we are going to have a little fun and invite all attendees to vote on their favorite pitches and demos. Submit your video on the ShortForm at Google I/O page. We’ll surface a leaderboard showing videos with the top votes, and the winning entry will be highlighted in a press release and will get prime placement on ShortForm’s homepage for one week, reaching hundreds of thousands of people.

Come see ShortForm in the Developer Sandbox at Google I/O on May 10-11.

As a founding member of ShortForm Jereme has been hacking around with the YouTube APIs for over a year now and has been building software for 15 years. When he’s not coding he’s probably trail running or roasting his own coffee while eagerly anticipating the arrival of his first child in June!

Deprecating Equine-Frame Embedding

Jeffrey Posnick — Fri, 01 Apr 2011 04:15:00 +0000

Although equine-frame embedding of YouTube moving pictures was launched with great huzzabulloo a few short months ago, we regret that we can no longer recommend this horsey practice. While playback quality was smashing, bareback riding quality invariably suffered as a result of the large projector apparatus embedded in the horse’s frame.

As an alternative, we suggest a return to the traditional practice of affixing a portrait of your local constable to the mane of your steed for entertainment on-the-go. When your horse gallops, it will look like the officer is dancing the hully-gully.

Thankfully, progress doesn’t halt with a single setback. We are working closely with various motor-car manufactures, and hope to offer a preview of Model T-frame embedding in time for the next World’s Fair!

—Web-logged by Jeffrey Posnick, who does not suggest embedding anything in a horse that you might want back at a later date.

ClientLogin #FAIL

Jeffrey Posnick — Wed, 30 Mar 2011 17:26:00 +0000

The YouTube API supports a number of authentication schemes—AuthSub, OAuth 1 and 2, and ClientLogin—but it’s that last method, ClientLogin, that is in many ways the most problematic. This blog post will cover some of the ways ClientLogin attempts can fail, and when possible, provide ways of working around those failures.

Before we get into that, though, a bit of a public service announcement: given all the ways that things can go wrong when using ClientLogin, please consider using one of the alternative methods of authentication that the YouTube API supports! AuthSub and in particular OAuth 2 are straightforward to implement and aren’t susceptible to the issues that we’ll cover with ClientLogin. Even if you’re writing a small script for personal use, obtaining one long-lived AuthSub or OAuth 2 token and reusing that for authentication is preferable to hardcoding a login name and password for ClientLogin. And just because your code doesn’t have access to a web browser doesn’t mean that ClientLogin is your only option—this guide covers techniques for using OAuth 2 in such scenarios.

With that out of the way, let’s investigate some failures!

Scenario 1: A user with an unlinked YouTube account attempts ClientLogin.
This scenario won’t actually lead to a failure as of right now, but it will in the near future. As was recently announced on the main YouTube blog, all YouTube accounts must be linked to a Google Account or else logins will start fail—the current plan is to disable logins for unlinked accounts towards the end of April. The only workaround is to have your users link their YouTube account to a Google Account. If they login from a web browser, either at www.youtube.com or using AuthSub/OAuth, they’ll be taken through the steps to link accounts. It’s important to note that while we are requiring linked accounts, we will continue to accept either a YouTube username or a Google Account email address as the Email parameter in the ClientLogin request.

Scenario 2: A user who has enabled to OpenID federated sign-in attempts ClientLogin.
Federerated sign-in using OpenID is a new method of authenticating Google Accounts that correspond to email addresses on specific email providers (currently Yahoo! and AOL). It is currently being offered on an opt-in basis, so for the time being, just because someone’s Google Account is associated with an @yahoo.com or @aol.com address does not mean that they are using Federated sign-in. For the users who have opted-in, ClientLogin will no longer work at all. With Federated sign-in, all login requests need to be processed by the identity provider, and Google’s ClientLogin servers cannot relay the credentials to a third-party server on the user’s behalf. Because AuthSub and both versions of OAuth are web-based, users can log in directly on the identity provider’s site and have that redirect back to Google’s servers to issue the appropriate AuthSub or OAuth token. Migrating off of ClientLogin to AuthSub or OAuth is the only way to provide authentication that works with OpenID accounts.

Scernario 3: A user who has enabled 2-step verification attempts ClientLogin.
This scenario, and the reasons why it will result in a failure, is covered in detail in an earlier blog post. The important takeaway is that a user with 2-step verification enabled needs to generate application-specific passwords for each application that requires ClientLogin, and provide that password instead of their normal Google Account password. Alternatively, using AuthSub or OAuth allows you users to log in using their two factor credentials directly, leading to a better user experience.

Scenario 4: A user encounters a CAPTCHA when attempting ClientLogin.
This is not a new failure scenario, but it’s often overlooked by developers who don’t properly handle it. The ClientLogin documentation includes recommendations for how your application should handle CAPTCHA responses from ClientLogin attempts. If you’re using AuthSub or OAuth, your application does not need to worry about logic for handling CAPTCHAs—it’s taken care of for you by the standard AuthSub and OAuth login process.

This may seem like an exhaustive list of failure scenarios, but as we continue to iterate on the login experience for YouTube and Google Accounts, chances are more “gotchas” will crop up in the future. We’ll do our best to keep our developer community informed, but the best way to future-proof your application is to stop using ClientLogin!

Update: A Google I/O 2011 session borrowed this blog post's title and covered similar material (though not YouTube-specific). Check out the ClientLogin #FAIL session's video embedded below:

—Jeffrey Posnick, YouTube API Team

Best Practices for User Authentication

Jeffrey Posnick — Thu, 17 Mar 2011 16:31:00 +0000

(Cross-posted from the Google Code blog.)

By now, many of you have seen our recent announcement regarding 2-step verification for Google Accounts. It’s an optional way of protecting your Google Account from unauthorized access, providing a level of security beyond that of a password alone. The initial announcement did not detail the impact enabling 2-step verification has on programmatic account access from code written against one of Google’s official APIs. We want to go into some more detail regarding the implications of 2-step verification on various authentication (and authorization) techniques, and offer best practices that you as a developer should follow.

There are three forms of authentication supported by almost all of Google’s APIs. AuthSub andOAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.

If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.

ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an HTTP 403 error response from our servers with the following in error included in the response body:

Error=BadAuthentication Info=InvalidSecondFactor

There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.

The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.

While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.

By Jeffrey Posnick, Google Developer Relations

HTTPS Support for YouTube Embeds

Jeffrey Posnick — Thu, 10 Feb 2011 03:38:00 +0000

HTTPS, the secure counterpart to HTTP, wraps a layer of encryption around the information traveling between your computer and a web server. YouTube already uses HTTPS to encrypt sensitive data during the account login process. Now we’re planning a gradual expansion of HTTPS across other aspects of the site. The first place you may see HTTPS YouTube URLs is in our various embed codes, all of which currently support HTTPS in addition to the standard HTTP. Anyone can try HTTPS with YouTube embeds today—simply change the protocol portion of the URL from http to https. For example, http://www.youtube.com/embed/Zhawgd0REhA becomes https://www.youtube.com/embed/Zhawgd0REhA. This applies to URLs found in our newer embeds as well as our older-style <object> + <embed> codes.

If any of your existing code attempts to parse YouTube embed URLs that are entered by end-users, it’s important that you support both HTTP and HTTPS as the URL’s protocol across all the varieties of YouTube embed codes.

Most web browsers will warn users when they access web pages via HTTPS that contain embedded content loaded via HTTP. If your main site is currently accessed via HTTPS, using the new HTTPS URLs for your YouTube embeds will prevent your users from running into that warning. If your site can be accessed either via HTTP or HTTPS, you could employ protocol-relative URLs instead of hardcoding a value; //www.youtube.com/ will automatically resolve to HTTP or HTTPS depending on the protocol used by the host page.

It’s very important to note that this is just a first step in enabling HTTPS for the entire YouTube viewing experience. In particular, only the YouTube player code is accessible via HTTPS at this time. The actual video bitstream, and some additional content loaded by the YouTube player may still be accessed via standard HTTP connections when you use an HTTPS URL in your embed code. Also note that HTTPS remains optional for YouTube embeds; we have no plans to turn off support for the HTTP URLs.

If you have any comments or questions about this change, please let us know in the YouTube API developer’s forum.

Cheers,
–Jeff Posnick, YouTube API Team

YouTube Captions Uploader Web App

Jeffrey Posnick — Thu, 27 Jan 2011 21:26:00 +0000

Captions can greatly enhance the experience of viewing a YouTube video, and the YouTube API has offered developers ways to upload and retrieve caption data in authorized requests for a while now. However, the various YouTube API client libraries don’t natively support interacting with captions at this time, and writing your own code for uploading or retrieving captions can be challenging.

With that in mind, we're happy to announce the YouTube Captions Uploader open source project on Google Code, which provides real-world code for uploading captions to YouTube. The code is written for the Java App Engine environment, and it uses some nifty new App Engine features like the Channel API, the Blobstore Service, and Task Queues. And even if you're not an App Engine developer, we hope that the code that interacts with the YouTube API's captions service will provide a good starting point for writing your own code.

In addition to open sourcing the code for this project, we’re also running the code itself on a public App Engine instance, http://yt-captions-uploader.appspot.com/. So, even if you're not a developer, you can still use the application to upload captions for videos in your YouTube account.

Please share your comments or feedback via the project’s issue tracker. We hope that you find it useful both as a standalone web application and as a starting point for writing your own code!

Cheers,
—Jeff Posnick, YouTube API Team

YouTube Captions Uploader Web App

Jeffrey Posnick — Thu, 27 Jan 2011 21:26:00 +0000

A Chrome Extension for YouTube Activity Feeds

Jeffrey Posnick — Wed, 22 Dec 2010 19:17:00 +0000

Slave Jovanovski, an engineer at YouTube, has put together a Google Chrome extension that should be of interest to the YouTube API community. It’s called YouTube Feed, and after installing and authenticating with your YouTube account, it automatically will fetch your YouTube social activity stream (both subscriptions and friends’ actions) while you use Google Chrome. When a new event, like a YouTube friend uploading or commenting on a video, takes place, the extension will notify you and provide details on the activity, as well as links to view the actual video. You have control over which types of activities you’d like to be notified about, as well as how frequently you’d like the extension to check for updates.

While you’ll hopefully find the extension useful on its own merits, the fact that the source code has been released as part of an open source project means that the extension’s code can serve as inspiration (or a jumping off point) for writing your own JavaScript code that interacts with the YouTube API. Curious as to how to use OAuth to authenticate YouTube accounts from a Chrome Extension? Or request JSON data with a JavaScript callback? The answers await you in the source code!

Cheers,
–Jeff Posnick, YouTube API Team

A Chrome Extension for YouTube Activity Feeds

Jeffrey Posnick — Wed, 22 Dec 2010 19:17:00 +0000

Accelerating YouTube Playback

Jeffrey Posnick — Wed, 01 Dec 2010 15:30:00 +0000

The YouTube Players team’s goal is to make sure that watching videos online is as enjoyable an experience as possible. As a viewer, maximizing enjoyment usually involves some tradeoffs: sure, you can watch a 1080p high definition version of the newest movie trailer, but that might mean choppy playback as your computer strains to keep up with the more demanding processing required. We wanted to let you know about some changes we’re making to help minimize those tradeoffs, so that you can watch smoother, higher-quality video from your existing devices.

Adobe’s recently announced Flash Player 10.2 release supports a new, more efficient video display mechanism known as the Stage Video API. The full details of how and why Stage Video speeds up video display can be found in Adobe’s technical documentation. The Players Team will be gradually experimenting with Stage Video playbacks on YouTube.com in the coming weeks, but as a developer using the ActionScript 3 Player APIs, you can enable Stage Video playback for your embedded video right away; simply add the wmode=direct parameter to the player URL that you’re using to reference the YouTube video. You’ll need the Flash Player 10.2 installed to take advantage of the accelerated playback, but playbacks will work for users with older Flash Player versions as well.

The Players Team knows that Stage Video for Flash playbacks is just one path to take toward improving video playback performance across the web. For example, YouTube playbacks using the new embeds will automatically benefit as more and more (and more) modern browsers add hardware acceleration for the native HTML5 element.

Cheers,
-Jeff Posnick, on behalf of the YouTube Players team
(Updated 2011-02-09 to reflect the production release of Flash Player 10.2.)

Accelerating YouTube Playback

Jeffrey Posnick — Wed, 01 Dec 2010 15:30:00 +0000

More Channels to Feed On

Jeffrey Posnick — Wed, 10 Nov 2010 20:51:00 +0000

The YouTube API’s standard feeds are a great way to expose your users to the best of what YouTube has to offer. To compliment the existing standard video feeds, which contain lists of individual videos that meet certain criteria (the top rated videos in the United States for the current day, for instance), we’re happy to introduce a new set of standard channel feeds.

While standard video feeds contain lists of videos, standard channel feeds contain lists of channels, or user accounts. The two types of standard channel feeds are most_viewed and most_subscribed, and just like with video feeds you can narrow down your results even further with time, region, and category or user type parameters. For example, the URL for requesting the most viewed channels with videos related to music in Great Britain for the past week is http://gdata.youtube.com/feeds/api/channelstandardfeeds/GB/most_viewed/-/Music?v=2&time=this_week. Each entry in a standard channel feed provides detailed information about a specific YouTube channel, including a element with info on how many comments, videos, and views that channel has received.

Once you have these lists of channels, a natural next step would be to allow your logged-in users to subscribe to a given channel or view a list of videos uploaded in that channel.

Standard channel feeds are only available in version 2 of the YouTube API, which will soon be the default version in the production environment. In the meantime, be sure to explicitly specify that you want to use version 2 when making your YouTube API requests.

Cheers,
Jeff Posnick, YouTube API Team

Update to the ClientLogin URL

Jeffrey Posnick — Thu, 04 Nov 2010 20:30:00 +0000

We want to let the developer community know about a change to the officially supported URL for YouTube API ClientLogin requests. Previously, developers who wanted to obtain authentication credentials via a username and password had to send their ClientLogin request to https://www.google.com/youtube/accounts/ClientLogin. The new URL that we encourage all developers to use is https://www.google.com/accounts/ClientLogin. This new URL has been functional for a while, and is the same URL that other Google APIs use for ClientLogin requests. Switching YouTube API ClientLogin traffic to the standard URL ensures that developers across all of Google’s APIs will see standard behavior when logging users in.

All of the details regarding this switch as well as best practices for performing ClientLogin requests can be found in our YouTube API documentation. There is one specific change in behavior that is worth calling out: responses from the new ClientLogin URL will not include the YouTube username of the authenticated user, which the old URL’s responses did provide. We encourage developers to take advantage of the username default when constructing YouTube API request URLs, which always refers to the currently logged in user.

We have no immediate plans to disable the old ClientLogin URL, but we do encourage developers to update their code at their earliest convenience to point to the new URL. We will post again with further details if and when the legacy URL is turned off.

Cheers,
-Jeff Posnick, YouTube API Team

The ActionScript 2 Chromeless Player and Monetized Videos

Jeffrey Posnick — Mon, 25 Oct 2010 21:01:00 +0000

The ActionScript 3 Player APIs, both in the chromeless and embedded variety, have been available for use since last October. When we released the ActionScript 3 APIs, we announced the deprecation of the ActionScript 2 equivalents. As per our deprecation policy, we will keep the ActionScript 2 Player APIs running through October of 2012; however, we wanted to announce a change in the videos available for playback that will affect those still using the ActionScript 2 chromeless player.

As of early January, 2011, some videos that YouTube and our content partners would like to monetize will not be playable using the ActionScript 2 chromeless player because it does not have the ability to show ads. If you attempt to play back such a video, an onError event will be fired, as documented in the ActionScript 2 Player APIs reference guide. As a developer, you can handle this event and play an alternate video, or display an explanatory message to your users.

Please note that this change only affects playback in the ActionScript 2 chromeless player. If you are using the ActionScript 2 embedded player (i.e. the official YouTube player with built-in controls) or if you’ve already upgraded to one of the ActionScript 3 players, you can continue to play the same video content you can play today. Also note that you might be using the the ActionScript 2 chromeless player indirectly if you’re using a third-party custom video player to play back YouTube content. Please reach out to the provider of your custom video player if you’re not sure whether this change will affect you.

Cheers,
-Jeff Posnick, YouTube API Team

PubSubHubbub for YouTube Activities

Jeffrey Posnick — Thu, 07 Oct 2010 19:19:00 +0000

PubSubHubbub, for those not in the know, is a server-to-server protocol for notifying interested parties of events they’re interested in. Notifications are pushed out to subscribers via HTTP web hooks, which offers efficiencies over polling-based solutions. With PubSubHubbub, your server finds out about events in near real-time, without having to determine the optimal polling interval or repeatedly fetch individual activity feeds that haven’t changed.

We’re happy to announce that it’s now possible to subscribe to three types of YouTube user events via PubSubHubbub: video uploads, new subscriptions, and video favorites. The subscription requests need to be made on a per-user basis, so you will only receive updates for specific users that you’re interested in.

Your code can look for our PubSubHubbub hub address in the href attribute of the top-level element in uploads, subscriptions, and favorites feeds. For example, the feed http://gdata.youtube.com/feeds/api/users/GoogleDevelopers/uploads?v=2 exposes the hub address in the element.

More details on the PubSubHubbub can be found in the specification document. If you’d like your server to receive YouTube user event updates via PubSubHubbub, this list of libraries is a good place to start.

Cheers,
-Jeff Posnick, YouTube API Team, in conjunction with the PubSubHubbub Team

Staging Server Now Defaults to YouTube API Version 2

Jeffrey Posnick — Mon, 13 Sep 2010 21:33:00 +0000

The YouTube Google Data API currently exists in two flavors: version 1 and version 2. If you’re not explicitly requesting version 2 of the API, then you’re using the default, version 1.

As we add new functionality to the API, it’s invariably added to version 2: features like partial responses/updates, extended access controls, captioning support, and YouTube Insight statistics are only available to developers accessing the newer release. We’ve kept version 1 running as-is for a while now, and will continue to do so for months to come, but we’re taking the first step to transition developers off of version 1 of the API by changing the default in our staging server environment to version 2.

We expect to default the production environment to version 2 before the end of the year, and we will post again when we have more definite dates. In the meantime, if you are still using version 1 of the API, please prepare for the change by taking one of the following steps:

Modify a test version of your code to access stage.gdata.youtube.com URLs as described in this blog post. You’ll automatically default to version 2, and you can test and make changes to your code against the staging server.
Start explicitly requesting version 2 using the v=2 URL parameter or GData-Version HTTP request header. Most of the YouTube API client libraries provide methods for switching between API versions, and they will take care of setting the appropriate GData-Version header for you. You may need to modify your code to make it compatible with version 2.
If you know that your code is incompatible with version 2 of the YouTube API and you can’t fix things yet, start explicitly requesting version 1 of the API. Note that this is not a long-term solution, as all code will eventually need to be migrated off of version 1.

Stay tuned over the coming months for more announcements about the change to the default in production, and the eventual decommission of version 1, currently scheduled for October 2011.

Cheers,
-Jeff Posnick, YouTube API Team

YouTube API @ Google I/O 2010

Jeffrey Posnick — Tue, 08 Jun 2010 21:04:00 +0000

Kuan Yong, Gareth McSorley and I -- representing Product Management, Engineering, and Developer Relations, respectively -- were happy to present a YouTube API session at this year’s Google I/O developer conference. We got the chance to meet many members of the developer community there, but unfortunately not everyone is able to make it out to San Francisco in person. For the benefit of those who could not attend, a recording of our session is now available on YouTube, and embedded below.

The session was titled “YouTube API Uploads: Tips, Tricks, and Best Practices” and we covered all topics related to uploads from A (Android app uploads) to Z (zero-metadata uploads). We hit a few letters in between, too: B (browser-based uploads) I (iPhone app uploads), Q (upload quota questions), R (resumable uploads) and Y (YouTube Direct). There’s something for everyone in this session, so if your application uploads video to YouTube, be sure to check it out!

Cheers,
-Jeff Posnick, YouTube API Team
YouTube is hiring! ~ http://google.com/jobs/workyoutube

Java YouTube Developers: Update Your Libraries

Jeffrey Posnick — Mon, 17 May 2010 19:03:00 +0000

If you access the YouTube API via Java using the official Google Data Client Library, we want to let you know about upcoming changes to the YouTube API that may affect your existing code. Developers who are using a client library in a language other than Java, or who use Java but access the YouTube API without using the Google Data Client Library will not be affected by this change.

Versions of the Java Google Data Client Library earlier than 1.41.2 (the most recent release as of this writing) are particularly picky about the data they receive back from the YouTube API and deserialize into Java objects. If our YouTube API servers are updated to start including an additional attribute for an existing element in their Atom XML responses, older versions of the Java client library will throw a deserialization exception complaining about this extra data. While this might be considered beneficial in some contexts, it unfortunately precludes our ability to extend the YouTube API’s functionality by returning back new data in its responses. We recently ran into this issue while trying to launch a new totalUploadViews attribute, for instance.

We removed the totalUploadViews attribute soon after adding it, but progress can’t be delayed forever. If you’re using the Java Google Data Client Library, we strongly recommend that you update your installation to the 1.41.2 (or newer) release. We plan on re-adding the totalUploadViews attribute in mid-July, and other new attributes may follow. If you haven’t updated to a compatible version of the Java client library by mid-July, your existing Java code will start throwing exceptions when you retrieve an Atom XML response containing the new attribute, such as a request for a user’s YouTube profile.

A special note to developers using YouTube Direct: because YouTube Direct is built on top of the Java client library, it also needs to be updated to use a compatible release. The latest archived downloads of the source code for both the 1.0 and 2.0 releases, as well as the SVN source, have been updated for compatibility. Please take the time to update your YouTube Direct deployment in App Engine before mid-July.

Cheers,
—Jeff Posnick, YouTube API Team
YouTube is hiring! ~ http://google.com/jobs/workyoutube

Partial Responses and Updates with the YouTube API

Jeffrey Posnick — Mon, 22 Mar 2010 21:58:00 +0000

We wanted to share some big news that was just announced on the Google Code blog: the YouTube API now supports partial responses and partial update requests. Both these features allow you to drastically cut down on the amount of data you send and receive via the API, which means simpler, faster API operations and happier users.

The announcement post on the Google Code blog goes into much more detail, so take a look at that first. When you’re ready to start writing code, check out the partial response and partial update sections of the YouTube API Developer’s Guide.

Cheers,
-Jeff Posnick, YouTube API Team
YouTube is hiring! ~ http://google.com/jobs/workyoutube

YouTube Direct for Mobile, and Other Updates

Jeffrey Posnick — Tue, 09 Mar 2010 23:20:00 +0000

Since launching YouTube Direct last November, our team has been hard at work adding new functionalities, fixing bugs, and answering developer's questions. We wanted to take a momentary break from all that to share some updates.

Separate from but related to the main YouTube Direct project are two other Google Code projects: video capture and YouTube Direct upload applications for the Android and iPhone operating systems. These two projects are basic implementations that we hope will inspire organizations to add video capture and YouTube Direct upload functionality to their Android or iPhone applications.

We've been gradually, and quietly, checking in various bug fixes and enhancements to the current release's Subversion repository on Google Code. One recent change is especially important, as it adds support for the new video page URLs that will start becoming more common. Periodically, we package the current release into a new "tagged" release, and generate release notes summarizing what's new. If you haven't updated your YouTube Direct codebase recently, we strongly suggest that you read the release notes and perform a sync with our code repository. Starting with the next YouTube Direct release, we will send email announcements to the low-traffic, announce-only Google Group. We recommend that all developers using YouTube Direct sign up to the group — actually, all YouTube API users should sign up to receive periodic important notifications.

Many organizations, in addition to our launch partners, have deployed YouTube Direct on their websites since our launch, and we wanted to highlight a few here.

Gannett rolled out a company-wide initiative in honor of Black History month, in which they ask people to interview civil rights heroes via video. Al-Jazeera invited the community to share their thoughts and experiences around Hajj, the annual Muslim pilgrammage to Mecca. And if you have news videos around any of the big stories of the day, ITN News wants them. Even Tufts University is using YouTube Direct to solicit personal videos from the community called "You, in One Minute".

As always, the best resource for developers looking to embed YouTube Direct functionality on their website is our Getting Started Guide. If you have any technical questions about YouTube Direct, our YouTube API Developer's Google Group is the place to turn.

Cheers,

-Jeff Posnick on behalf of the YouTube Direct Team

Upcoming Change to YouTube Video Page URLs

Jeffrey Posnick — Mon, 08 Mar 2010 19:11:00 +0000

There's an upcoming change to YouTube video page URLs that we wanted developers to know about. While it's not something that will directly affect users of the YouTube APIs, chances are there are some developers in the audience who have code that parses existing YouTube video page URLs, possibly to extract a video's id.

Here's what some users will start seeing: URLs for YouTube video pages will change from the format http://www.youtube.com/watch?v=ylLzyHk54Z0 to http://www.youtube.com/watch#!v=ylLzyHk54Z0. That is to say, the ? character in the URL will be replaced with #! characters. Not all users will be directed to the new URLs, and the change will be implemented gradually over time. This change is part of a larger AJAX rewrite of the YouTube web site. The old-format URLs will continue working indefinitely when used for browser navigation, so if your web site has existing links to YouTube video pages, you don't need to worry about them breaking.

What we're concerned about is developers who have written code that takes a user-supplied YouTube video page URL as input and attempts to parse out the video id using a method that assumes there will be a ? character in the URL. If you have such code, you will need to make it flexible enough to support both styles of URLs. In both formats, the value of the v parameter will be the video id, but other URL parameters in an arbitrary order may also be present in valid URLs.

You might be tempted to parse YouTube URLs when generating HTML snippets that embed videos on your web pages. We recommend that you don't take that approach. Our oEmbed service can take care of that for you. oEmbed will happily take watch page URLs of either format as input and return a proper HTML embed code that you can use.

Cheers,

-Jeff Posnick, YouTube API Team

Extended Access Controls Available via API

Jeffrey Posnick — Tue, 23 Feb 2010 16:28:00 +0000

One of the feature requests that we've received most frequently from developers it to have a YouTube API call that enables or disables commenting for videos. It's a logical request — videos can be automatically uploaded via the API, and having to visit youtube.com from a web browser to modify the commenting settings manually doesn't make much sense.

We've taken action on this feature request, and gone one step further: the new element lets video owners enable or disable video rating, comment voting, video responses, and off-web syndication in addition to commenting. We've also taken an existing element for controlling embedding, , and migrated its functionality to . Existing code that uses the element will continue to work as per our API deprecation policy, but is preferred for new development.

You can set access controls for a video when uploading or updating a video. See the Setting access controls for a video section of the Developer's Guide for more information.

With the addition of the this feature, the YouTube API now offers parity with all the settings available via the YouTube web interface. We hope that applications that support YouTube uploads take advantage of this new functionality, and we know your users will appreciate it!

Cheers,

-Jeff Posnick, YouTube API Team

Announcing the YouTube SDK for .NET

Jeffrey Posnick — Mon, 22 Feb 2010 21:02:00 +0000

I am happy to announce a new resource for the .NET fans in the YouTube developer community. The YouTube Software Developer Kit for .NET contains all you need to get you started with the YouTube API using Visual Studio 2008.

The SDK includes a help file, a project template and the following sample programs:

An application that use the Simple Update Protocol to watch for YouTube activity from a group of users.
An example ASP.NET website that illustrates the use of AuthSub authentication.
A bulk uploader tool that uses the new ResumableUploader component to asynchronously and reliably upload video files. Multiple threads are used to process video metadata, which is read from a CSV file.

After installing the SDK, you can open Visual Studio 2008 and select the YouTube template to get started writing your own code.

This packaged SDK no longer contains any source code, but it's all available from the project's Subversion repository. The YouTubeUploader source code is of specific interest to developer who want to see the ResumableUploader component in action.

To file bug reports or make feature requests, please use the project's Issue Tracker.

Regards,

—Frank Mantek, Google Data APIs Team

Best Practices for Avoiding Quota Issues

Jeffrey Posnick — Tue, 09 Feb 2010 21:02:00 +0000

Like most publicly-available web services, the YouTube API implements a quota system to protect our servers from excessive traffic. This traffic might result from a harmless typo – who hasn't written an infinite loop or two after a long night of coding? – or it may result from an inefficiently designed system that makes needless API calls. Regardless of the cause, blocking traffic from a specific source once it reaches a certain level is necessary for the overall health of the YouTube API. It ensures that one developer's actions cannot negatively impact the larger community.

That being said, we've recently made some changes to the way we implement YouTube API quotas. Our previous quota implementation was a bit too coarse-grained for some common usage scenarios. For instance, if an application running on a common web hosting platform generated excessive requests, it could end up blocking other applications running on the same servers that were generating only a modest amount of traffic.

We believe that our new quota implementation is much more straightforward and less likely to negatively impact applications that are "doing the right thing." The new quota system ties usage to a specific developer key; as long as your application includes a developer key along with your YouTube API requests, your requests will be less likely to be flagged for quota violations.

It's also worth noting that different types of API operations count differently towards quota calculations. In general, you can safely make more frequent HTTP GET requests to retrieve data than HTTP POST/PUT/DELETE requests to modify data.

In the unlikely event that you do get flagged for excessive API requests, you'll receive an HTTP response with a code of 403 and a response body that includes

yt:quotatoo_many_recent_calls

It's up to your code to detect this error and take appropriate action. As a best practice, we recommend stopping all API calls from your application for 10 minutes after receiving such an error in order to "reset" your quota. When you resume making API calls, you should scale back on the frequency of your requests. As a rule, API requests that do not originate from user interaction – requests made one right after another as part of a background synchronization or bulk import process, for instance – are more likely to trigger quota violations, so they should be avoided.

Cheers,

-Jeff Posnick, YouTube API Team

A New Format for JSON Results

Jeffrey Posnick — Mon, 01 Feb 2010 19:38:00 +0000

It's been two and a half years since we announced JSON as an alternative output format to Atom XML for YouTube API responses. As illustrated in the developer's guide and codelab, JSON-formatted data is a natural choice when writing web applications – after all, who wants to parse XML from JavaScript?

Our existing JSON format isn't perfect, however. It's very much a literal translation from Atom. As is often the case with literal translations, the current JSON format is wordier than it needs to be, and it lacks some of the elegance that a native dialect would offer.

We've rethought out current JSON implementation, and moved away from a literal representation of the Atom data to a format that we hope will be more pleasing to those who are fluent in JSON. The vestigial XML namespace prefixes are no more, and we've removed many pieces of metadata specific to Atom documents that come across as noise in JSON. Repeating data elements are always structured as true JSON lists, and useful video metadata that exist as XML attributes in Atom have been rearranged to make more sense in the JSON document. You'll also find that the new JSON results are more compact than Atom XML, which is of special importance to code running from limited-bandwith mobile applications.

We call this new format JSON-C, and you can read about all the technical details in our documentation and see it in action in our live demo.

With the release of JSON-C, we consider the legacy JSON format officially deprecated. All new development should prefer JSON-C to JSON, and if you have existing YouTube API code that relies on JSON-formatted results, you'll need to upgrade your code to use the new format. We will be supporting legacy JSON-formatted output in accordance with the deprecation policy outlined in our Terms of Service.

Cheers,

-Jeff Posnick, YouTube API Team

Enrich your site with YouTube Direct

Jeffrey Posnick — Tue, 17 Nov 2009 15:16:00 +0000

Today we announced the launch of YouTube Direct, a new tool built on top of YouTube's public APIs that enables any developer to solicit video submissions on their website, powered by YouTube.

Users upload their videos directly on the developer's website, after which the developer can review the submissions and select the best ones to showcase. Since these videos live on YouTube, users are able to reach YouTube's large user base directly while also getting broader exposure and editorial validation for the videos they create.

Although YouTube Direct was originally created with our news partners in mind, we believe that other developers and website owners can benefit from it as well. To put YouTube Direct in the hands of as many developers as possible, we open sourced the bulk of the code and designed it to run on Google App Engine - Google's scalable hosting platform. This enables developers to easily deploy their own instance of the tool and take advantage of App Engine's scalability and low cost. The videos themselves are served from the same infrastructure that powers YouTube.com.

Visit YouTube Direct for Developers page to read more about it or go directly to the project page to download the code. As always, we'd love to hear your feedback on this new tool. Drop us a line in YouTube's Developer Forum.

New YouTube API Version Available for Testing

Jeffrey Posnick — Tue, 10 Nov 2009 21:31:00 +0000

While we don't normally call out new releases of the Google Data YouTube API on this blog, we wanted to draw specific attention to the version that has just been pushed out to our staging servers. There are two specific changes that we'd like to give our developers and partners a chance to test before they go live. Both changes affect important areas of the API: ClientLogin authentication, and playback URLs in media:content entries.

We fully intend for the changes to be backwards compatible, and from the developer's perspective you should not have to change any code. But testing your code is always a best practice, so if you rely on ClientLogin or retrieving media playback URLs from the Google Data YouTube API, please repoint your code to http://stage.gdata.youtube.com and confirm functionality.

Any incompatibilities should be reported as soon as possible in our YouTube API Developer Forum. We expect to move the changes from the staging environment into production on November 17.

Final Decommission Notice for the Legacy YouTube API

Jeffrey Posnick — Wed, 04 Nov 2009 21:03:00 +0000

It's been several years since we've released the Google Data-based YouTube API, and in that time we've been encouraging developers who used the legacy YouTube API to upgrade before we pull the metaphoric plug on that older version. At this point, all but a handful of holdouts have upgraded, and as of November 11, 2009, the legacy YouTube API will cease operation.

If you're using one of our YouTube API client libraries, then you're definitely making use of the modern Google Data YouTube API. If you're manually making HTTP requests to a URL whose hostname contains gdata.youtube.com, then you're also good to go. If you think you might still be using the legacy YouTube API but aren't sure, take a look at some of the example legacy API calls in this migration guide. If it turns out that you are still using the older API, then the migration guide will give you the information you need to upgrade – and be sure to do so before November 11!

The ActionScript 3 YouTube Chromeless Player is Now Live

Jeffrey Posnick — Wed, 14 Oct 2009 22:31:00 +0000

We have some good news for developers who integrate YouTube videos into their ActionScript 3 Flash applications: the official YouTube Chromeless Player API has been updated to natively support ActionScript 3!

Previous to this release, ActionScript 3 developers had to rely on wrapper libraries that bridged the gap between the native ActionScript 2 API and their own ActionScript 3 code. We're thrilled that intrepid developers were able to patch things together on their own and share their code with the rest of the community. Now that there's official support for using the chromeless player from ActionScript 3, everyone should have more time to focus on writing compelling Flash applications, rather than dealing with the unique issues that cross-language coding entails.

Please check out our ActionScript 3 documentation, and let us know what you think of the new API in our developer forum.

With the launch of ActionScript 3 support, we're officially deprecating the ActionScript 2 YouTube Chromeless Player API. As per our YouTube API deprecation policy, detailed in our Terms of Service, we will continue to operate the ActionScript 2 API for a period of three years (until October 14, 2012).

Cheers,

-The YouTube API Team

Direct Uploads Server Migration

Jeffrey Posnick — Mon, 12 Oct 2009 18:20:00 +0000

We first announced our new API upload infrastructure back in June and asked developers to test their YouTube API code against our staging environment.

Since then, we've started deploying the new upload infrastructure to production machines in a phased manner. Last month, we transitioned browser-based API uploads to the new servers, and have been closely monitoring performance and error rates to ensure that there were no unintended side effects.

We're now ready to begin the transition for direct uploads. Starting today, a small percentage of direct uploads traffic will automatically be routed to our new servers. We will be monitoring traffic over the next few weeks and gradually increasing the traffic that the new servers receive until we have fully completed the migration.

As a developer, you won't have to make any changes in your code to take advantage of the increased reliability and bug fixes found in the new infrastructure. While we do expect that this new infrastructure will be fully backwards compatible, if you do notice any change in your application's behavior with regard to direct uploads, please let us know in our developer group.

Cheers,

-The YouTube API Team