YouTube API Blog

An Update to our Deprecation Policy

2012-04-20T12:43:00.000-07:00

As you might have seen announced on our Google Developers blog, the deprecation policies associated with many of Google’s APIs are changing. We want to highlight the specific way this affects YouTube API developers.

As of today, our YouTube API deprecation policy states:

Google will announce if we intend to discontinue or make backwards incompatible changes to this API or Service. We will use commercially reasonable efforts to continue to operate the YouTube API without these changes until the later of: (i) one year after the announcement or (ii) April 20, 2015, unless (as Google determines in its reasonable good faith judgment):

required by law or third party relationship (including if there is a change in applicable law or relationship), or
doing so could create a security risk or substantial economic or material technical burden.

This Deprecation Policy doesn't apply to versions, features, and functionality labeled as "experimental."

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

Cheers,
—Jeff Posnick, YouTube API Team

Upgrading Old Embed Codes

2012-04-17T09:21:00.002-07:00

We’d like to let the community know about an upcoming change that will affect some developers using Flash-only players in their webpages or applications. Previously, a URL like http://www.youtube.com/v/VIDEO_ID would default to the ActionScript 2 version of the Flash player, and it was necessary to explicitly add in the version=3 URL parameter to request the newer, ActionScript 3-based player. Starting on Wednesday, May 2, we will be changing the default behavior so that the ActionScript 3 player will be loaded in those scenarios.

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

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

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

Cheers,
—Jeff Posnick, YouTube API Team

New Player Options for Lists of Videos

2012-03-30T13:42:00.000-07:00

Update (May 2010): The showinfo=1 parameter can now be included in the player's URL to indicate that the list of video thumbnails should be initially visible. The example below has been updated to illustrate this usage.

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

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

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

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

The corresponding embedded player is shown below:

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

Cheers,
—Jeff Posnick, YouTube API Team

Minimum embeds: 200px x 200px

2012-03-29T09:15:00.000-07:00

If you're a careful reader of the YouTube API Terms of Service as well as the YouTube Player documentation, you may have noticed that while embedded players smaller than the minimum size might not support all player features, we haven’t defined what that size is.

As a part of our spring cleaning, we've tidied up our documentation to specify a minimum player size, which is 200px by 200px.

This change will take effect beginning late April 2012, so please check your application to avoid surprises. If you have any questions or comments about this, or any other YouTube API feature, please let us know on the API forum.

Cheers,

-Jarek Wilkiewicz, YouTube API Team

Keeping Things Fresh

2012-03-23T07:36:00.000-07:00

Pop quiz: what’s the difference between the following feed URLs?

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

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

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

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

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

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

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

Cheers,
-Jeff Posnick, YouTube API Team

YouTube, Google+, the API, and You

2012-03-15T09:25:00.000-07:00

Update (April 2012): The last paragraph was changed to reflect the distinct yt:display and display attribute names, depending on whether the parent element is media:credit or yt:username.

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

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

If your application uses authentication and refers to feeds belonging to the currently authenticated user, always use the string default as the username in the feed URL. For example, the URL https://gdata.youtube.com/feeds/api/users/default?v=2 retrieves the currently authenticated user's profile no matter what type of account she has, and https://uploads.gdata.youtube.com/resumable/feeds/api/users/default/uploads?v=2 is always the correct URL to POST to when performing a resumable upload into the current user’s account.

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

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

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

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

Cheers,
–Jeff Posnick, YouTube API Team

“Super Tuesday” Reporting, Powered by YouTube Direct

2012-03-05T15:25:00.000-08:00

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

See you at GDC, PyCon and SXSW

2012-03-01T10:55:00.002-08:00

YouTube Developer Advocates and Engineers will be presenting next week at GDC, PyCon and SXSW. If you’re coming to any of those conferences, we’d love to meet you. Here is what’s in store at each conference:

Games Developers Conference, San Francisco, March 5-9

PYCON 2012, Santa Clara, March 7-15

Session: Scalability at YouTube

SXSW Interactive, Austin, March 9-13

Cheers,

Amanda Surya, YouTube Developer Relations Team

Video Uploads from Your Site’s Community

2012-02-15T07:22:00.002-08:00

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

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

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

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

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

Cheers,
—Jeff Posnick, YouTube API Team

Watch History Comes to the API

2012-01-24T13:50:00.000-08:00

There’s a new entry in the growing list of video feeds supported by the YouTube Data API: the watch history feed. This feed allows authenticated API users to retrieve their own YouTube viewing histories—retrieving the watch history of any other user is not allowed. The information in this new feed corresponds to the viewing history exposed on the YouTube website.

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

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

Cheers,
—Jeff Posnick, YouTube API Team

Building Professional Video Sites with YouTube APIs

2011-12-29T14:57:00.000-08:00

Using video on your website can add greater depth and richness for your audience. However, to do encoding, hosting and streaming right it takes some time and skill. If you’re lacking in either, here are some suggestions for sites that make it easy to help you setup video-based websites.

VidCaster is a video content management system, whose goal is to make building a website with video as easy as possible.

VidCaster makes use of custom URLs, video sitemaps, metadata, and thumbnails to integrate well with search engines. They provide lots of features to customize your video site, like uploading a logo, picking a theme and choosing custom colors, and you can even upload custom CSS. Using their video management interface, you can publish, unpublish and delete videos. VidCaster can even distribute the videos from your video site to third-party sites such as YouTube and Twitter, and they can also integrate analytics from third-party sources.

VidCaster uses OAuth2 with the YouTube API to manage the user’s YouTube account, using both SUP (Simple Update Protocol) and polling to make sure a user’s video site is always in sync with their YouTube channel. Companies that use VidCaster include AirBnB, Hackers and Founders, and Dirtcast.

By integrating closely with YouTube’s data API, VidCaster makes it easy for users to take advantage of YouTube’s video service from within their own custom video site.

Moviecom.tv tries to make it easy for businesses to build video sites about their company.

Like VidCaster, Moviecom.tv provides users with a variety of features to customize their video site. They too show videos hosted on YouTube, but their integration with YouTube doesn’t yet include all the features that VidCaster does — for instance, Moviecom.tv can show YouTube videos using the iframe player, but they haven’t yet integrated with YouTube’s data API. This is something they plan on doing early in 2012. Moviecom.tv also touts their mobile application which takes the friction out of recording and uploading video to the right place.

And they’re doing well at it — they were recently named a Red Herring Global 100 Winner. Internet World, City Index, and Staples are all example sites created using their platform:

Companies like VidCaster and Moviecom.tv are a welcome part of the online video ecosystem. As Moviecom.tv CEO Gillian O'Neil once noted, Moviecom.tv isn’t competing with YouTube. By enabling third-party video sites to embed YouTube videos, YouTube isn’t trying to get a bigger piece of the pie. They’re making the pie bigger.

Cheers,
—Shannon -jj Behrens, YouTube API Team

Understanding Playback Restrictions

2011-12-28T13:30:00.000-08:00

Have you ever tried to show a user a YouTube video embedded on your site only to find out that they don’t have access to view it? For instance, if you try to play the video below, it’ll say “This video contains content from test_yt_owner, who has blocked it on copyright grounds.” There are many reasons why video playback can be restricted. The user might be in a country where the video is blocked, or the video’s content owner might have decided to block access to the video from all mobile applications.

While we strive to make YouTube content available everywhere, we believe it's important to give YouTube content owners the ability to control where their videos are viewed, which sometimes means you can't view videos in a certain country or on a certain device.

With enhanced content controls comes increased complexity. The only foolproof way to determine if a user has access to watch a video is to ask them to try watching it. So, if you’re writing an application and you’d like to prevent users from seeing videos that they don’t have the ability to watch, here are a list of things to check:

1. yt:accessControl

Videos that are available for embedding on third-party applications will have the following:

<yt:accesscontrol action='embed' permission='allowed' />

If you’d like to only search for videos that are embeddable, add format=5 to your query.

Just as a video can be embeddable or not, it can also be syndicatable or not:

<yt:accesscontrol action='syndicate' permission='allowed' />

A video that is embeddable but not syndicatable will play on YouTube.com or on other sites that embed the YouTube player, but may not play on devices such as mobile phones or TVs. If you’d like to learn more about retrieving videos suitable for playback on mobile devices, see the developer’s guide.

2. Geo Restrictions

Some videos may be restricted in certain countries. This restriction applies to where the viewer is located, not where your third-party server is located. For instance, if a video is blocked in the US, it will have the following:

<media:restriction type='country'
  relationship='deny'>US</media:restriction>

When you make a query, you can add a restriction parameter to filter videos that will not be playable by a client with a specific IP or from a specific country.

3. yt:state

It’s also important to check the yt:state of the video in the API response. Even if yt:accessControl indicates that syndication is allowed, yt:state might override it. For example, a video that has limited syndication would have the following:

<app:control>
  <yt:state name='restricted' reasoncode='limitedSyndication'>
    Syndication of this video was restricted by its owner.
  </yt:state>
</app:control>

You might also see the message, “Syndication of this video was restricted by the content owner.” Hence, even if the uploader allows syndication, the content owner could override that and disallow syndication. For example, this could happen if someone uploads a video that contains a soundtrack that is owned by another content owner.

4. Rentals

Some YouTube videos are rentals. You can tell that they are rentals because they have a media:price tag:

<media:price type='rent' price='1.99' currency='USD' yt:duration='PT2592000S' />

Note that the media:price tag is only included in the response if you use a developer key in the query. If you are building a non-browser based YouTube application where it would be impossible for the user to rent a video, you might want to filter out the rentals. You can do that by passing the parameter paid-content=false.

5. Other Restrictions not Currently Exposed via the API

There are even more subtle restrictions that occasionally come into play. Not all of these are currently queryable via the API. For instance, some videos are only playable on a certain set of domains. As I mentioned above, the only foolproof way to know if a user has access to watch a video is to have them try watching it.

Going back to the video above, you might be wondering why it won’t play. If you look at its video entry:

http://gdata.youtube.com/feeds/api/videos/1kIsylLeHHU?v=2&prettyprint=true

you’ll see that it’s blocked in all countries:

<media:restriction type='country' relationship='deny'>
  BD BE BF...
</media:restriction>

Furthermore, both syndication and embedding are disallowed:

<yt:accesscontrol action='embed' permission='denied' />
<yt:accesscontrol action='syndicate' permission='denied' />

Hopefully this short blog post on video playback restrictions will help you write applications that have a better understanding of what videos users can and can’t watch. If you have any questions, you can ask them on our forum.

Cheers,
—Shannon -jj Behrens, YouTube API Team

YouTube Direct Keeps Growing

2011-12-16T14:45:00.000-08:00

YouTube Direct, our open source platform for obtaining and moderating user-generated videos (and photos!), was first announced over two years ago. Since that time, the project has continued to grow, and we’re happy to announce the latest round of additional features.

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

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

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

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

Cheers,
—Jeff Posnick, YouTube API Team

A Friendly Update

2011-12-07T14:19:00.001-08:00

As you might have recently read, there’s an upcoming change that affects any “friends” you might have associated with your YouTube account. Your existing “friend” connections will be automatically converted into Address Book contacts, and when you visit YouTube.com you will be given the option of creating subscriptions to any or all of those accounts.

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

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

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

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

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

Cheers,
—Jeff Posnick, YouTube API Team

Insight Report Enhancements

2011-10-31T13:40:00.000-07:00

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

Upcoming YouTube API Events

2011-10-27T21:14:00.000-07:00

It was a pleasure meeting YouTube developers at the recent GDD, DevFest and GTUG sessions in São Paulo, Buenos Aires, Moscow, Prague, Paris and Warsaw. We would like to let you know that our around-the-world API tour continues and we hope to meet you at one of our upcoming YouTube API presentations. Here is the list of currently planned YouTube sessions:

GDD Tokyo, Nov 1^st: “HTML5, Flash and the Battle for Faster YouTube Cat Videos”
GDD Sydney, Nov 8^th: “Take a sneak peek at YouTube Live Streaming APIs”
DevFest Singapore, Nov 12^th: "Create Magical Apps and Engage Your Audience Using YouTube APIs"
GDD Tel Aviv, Nov 13^th: “HTML5, Flash and the Battle for Faster YouTube Cat Videos”
GDD Berlin, Nov 19^th: “HTML5, Flash and the Battle for Faster YouTube Cat Videos”

We will also be speaking at local GTUGs; for the most up to date information please check the event schedule of a GTUG near you. As always, upcoming event information can be found on our Google Developer Events Calendar available at http://code.google.com/events/.

Cheers,

--Jarek Wilkiewicz, YouTube API Team

More Ways to Find What You’re Looking For

2011-10-13T19:27:00.000-07:00

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 <media:license> 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 <yt:hd> 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 <yt:duration> 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 <yt:threed> 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

Introducing Google Account support and YouTube API v2.1

2011-10-07T15:46:00.000-07:00

Update (December 2011): The YouTube API now supports associating an unlinked Google Account with a YouTube channel as well as providing username suggestions.

Authenticated access to YouTube APIs lets your app offer many features that are unavailable to logged-out users. By authenticating user actions, your app can allow users to manage subscriptions, create playlists, and upload videos. Until recently, users could only perform any of these operations if they had YouTube accounts. (A YouTube account provides a user with a YouTube channel.)

We are pleased to announce that we have also started to give Google Account holders who don’t already have YouTube channels access to certain YouTube features on YouTube.com and in the YouTube API. We call these unlinked Google Accounts since they haven’t already been linked to a YouTube channel. For example, a user with a Gmail account or an Android device is certain to have a Google Account but may not have already linked that account to a YouTube channel.

What this means for your application is that with a few relatively simple changes, you should be able to allow authenticated access for users who have unlinked Google Accounts. Thus, those users will be able to log in to YouTube without having to create a YouTube username.

In a moment, we’ll dive into the details of how to use the API with unlinked Google Accounts and also offer a few user experience recommendations for your YouTube API application. First, though, a quick note about the new minor YouTube API revision that we’re introducing.

Say "Hello!" to YouTube API v2.1

When designing this feature, we decided to take a conservative approach toward backward compatibility. The set of write operations supported for Google Accounts is currently a subset of API operations available to YouTube account holders. Rather than expose existing applications to accounts with potentially restricted functionality, we’re explicitly requiring that an application prepared to handle unlinked Google Accounts tells us so by using the API version 2.1, a new, minor version of the API. Our documentation explains that you can specify an API version by appending v=2.1 to the API request URI or by using the GData-Version: 2.1 request header.

HTTP response codes for authenticated operations

API v2.0 supports all authenticated operations for users with YouTube accounts, which could also be called linked Google Accounts, but doesn’t support any authenticated operations for unlinked Google Accounts. If the authentication token for a v2.0 API request identifies an unlinked Google Account, the API will return a 401 NoLinkedYouTubeAccount error.

In API v2.1, however, a number of operations that require authentication are supported for users with unlinked Google Accounts, and the API will return a 200 response code for those operations. For operations that aren’t supported for unlinked Google Accounts in v2.1, the API will return an HTTP 403 Forbidden error with a youtube_signup_required error code.

The table below shows how API v2.1 changes response codes when different types of users try to execute operations that require authentication:

	API v2	API v2.1
YouTube Account	200 OK	200 OK
Unlinked Google Account	401 NoLinkedYouTubeAccount	200 OK or 403 Forbidden youtube_signup_required

Handling the youtube_signup_required error

We do not recommend that you try to modify your application to provide a different experience for users with YouTube accounts than for unlinked Google Accounts. That approach would require you to constantly update your application as YouTube expands the list of features that we support for unlinked Google Accounts.

Instead, we recommend that you prepare your application to gracefully handle the youtube_signup_required error, preferably by associating the unlinked Google Account with a YouTube channel using the API, or presenting an option for the user to navigate to https://www.youtube.com/create_channel. If you are building a mobile application, you can bypass a redirect by using https://m.youtube.com/create_channel instead. The API documentation lists the operations that are and are not currently supported for unlinked Google Account holders.

The XML below shows a sample youtube_signup_required error:

<errors> 
  <error>
    <domain>yt:service</domain>
    <code>youtube_signup_required</code> 
  </error>
</errors>

User profiles for unlinked Google Account holders

A user profile entry for a user with an unlinked Google Account differs from a user profile entry for a user with a YouTube account in two ways:

An entry for an unlinked Google Account holder contains a <yt:incomplete> tag. (This tag is not present if the user already has a YouTube channel.) It is useful if you choose to disregard our advice about the youtube_signup_required error and modify your application to provide a different user experience for users with unlinked Google Accounts.
An entry for an unlinked Google Account holder contains only a few tags as those users can not customize their profile data without first creating a YouTube channel. The <entry> tag definition lists the different tags that may appear in a profile entry depending on whether the user has a YouTube account or an unlinked Google Account.

Displaying an email address for unlinked Google Account holders

In addition to handling the youtube_signup_required error, your application should also be prepared to display an email address for users with unlinked Google Accounts.

In Closing

If you have reached this point in the blog post, thanks for being a dedicated reader. We recognize that unlinked Google Accounts do introduce a certain level of complexity, but, at the same time, they can also open your application to a much larger audience of users who use Google services but haven’t created YouTube channels yet.

We also want to note that v2.1 does not deprecate v2.0 since it is a minor revision. Going forward, new features unrelated to unlinked Google Accounts will be added to both v2.0 and v2.1 but not to the (deprecated) v1.0 of the API.

Version 2.1 of the API is now available for testing on stage.gdata.youtube.com, and will be released to production in mid-October.

Cheers,

—Jarek Wilkiewicz, YouTube API Team

Support for the Watch Later List

2011-10-05T11:44:00.000-07:00

YouTube’s Watch Later list is the perfect way to keep track of interesting videos you come across but don’t have time to watch at the moment. Since rolling out that feature on the YouTube website and the embedded players, developers have been asking for ways to interact with the Watch Later list via the YouTube Data API. We’re happy to announce that this is now possible.

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

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

Cheers,
—Jeff Posnick, YouTube API Team

YouTube API and the News

2011-09-28T12:23:00.000-07:00

If you love to follow the news as much as you love to code, then Hacks/Hackers, an international organization that sits at the nexus of journalism and technology, is for you. Its mission is to create a network of journalists (“hacks”) and technologists (“hackers”) to rethink the future of news and information. Recently, YouTube and LinkTV hosted a Hacks/Hackers meetup at Google’s San Francisco office. Together with four developer partners, we demoed web applications used by reporters and built using the YouTube API. The presentation started with a YouTube API overview, followed by demos of the following:

YouTube Direct is an open source, user-generated content video submission and moderation platform.
Storyful was founded by journalists to discover the smartest conversations about world events and raise up the authentic voices on the big stories.
Storify lets users make stories using social media. With Storify you can drag-and-drop tweets, YouTube videos, Flickr images, Facebook updates, etc. and add your own narrative to tell a story.
Shortform is a new social entertainment medium, delivering continuous channels containing the best videos from anywhere on the web, curated by our community of video DJs (VJs).
GoAnimate was founded to provide an outlet for everyone's creative ideas. In just 10 minutes, you can make fun animated videos without having to draw.
Link TV recently launched Link News, an international news website that sifts through YouTube's library of news content to deliver breaking news and hidden stories to a wider audience.

We would like to share the video recording of the event with you so that you can learn more. If you want to discover more about Hacks/Hackers, you can find the list of local chapters here.

Cheers,
—Jarek Wilkiewicz, YouTube API Team

Getting 3D Content on YouTube

2011-09-08T22:47:00.000-07:00

Over the last few months, we've been steadily rolling out features for YouTube 3D. Early this year, we announced support for the LG Optimus 3D and NVIDIA 3D Vision, and this month we announced support for Samsung 3D TVs. And we'll keep rolling out to more platforms to make it easier for everyone to get access to user-generated 3D content.

Many readers have been asking how to upload content. 3D uploads to YouTube will work across all supported devices, from red/blue glasses to the latest 3D televisions.

There are two ways to upload content to YouTube in 3D. If you're just uploading one or two videos, upload content in any supported format and then edit the video settings to tell us that it's 3D. From a video's watch page, select "edit info", then "3D Video". This will only work on videos you've uploaded yourself.

If you're using the API to upload 3D videos, you'll want to format your video in a certain way. YouTube supports automatic detection of 3D content with certain file formats. If you upload with a format that supports automatic detection, we'll automatically set the correct settings so that your video shows up automatically in 3D and shows up properly on phones, TVs, and PCs.

In both cases, YouTube requires that content be uploaded in Side by Side L/R with each frame squashed 50% and preferably with a 16:9 aspect ratio. The following formats are automatically detected when uploaded:

WebM with the StereoMode setting set to STEREOMODE_TYPE_LEFT_RIGHT. Note that other modes, including alternate track, are not supported.
H264 AVC with Supplementary Enhancement Information, Frame Packing Arrangement set. If you are using x264, the argument --frame-packing=3 will set this correctly. In Handbrake you can set this in "x264 Advanced Option String".

Be sure to get the squashing and positioning exactly correct. 3D content won't look right if video formatting is off by even a pixel or two.

We're excited to see what you'll show us! Here's an idea from a favorite webcomic of ours.

Cheers,

—Jonathan Huang, YouTube 3D Product Manager

P.S.—We recently worked with some folks to help them get 3D Mars footage from 1979 restored from the Viking landers. Check it out!

Auth Tokens & Unlinked YouTube Accounts

2011-08-25T12:46:00.000-07:00

Dedicated readers of this blog will remember our post from a few months back entitled “ClientLogin #FAIL”. In it, we laid out a number of scenarios in which attempts to use ClientLogin authentication would result in an error (and urged developers to move off of ClientLogin in general). The first failure scenario involved users whose YouTube account is not linked to a Google Account. Fortunately, the number of YouTube accounts in that unlinked state has decreased greatly over the past few months, so failures of that sort with ClientLogin are not as common now.

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

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

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

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

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

Cheers,
—Jeff Posnick, YouTube API Team

The New CodeIgniter PHP Client Library

2011-08-23T07:04:00.000-07:00

While the YouTube Data API’s RESTful nature means that talking to YouTube is as easy as making an HTTP request, using a client library is a great way to improve your YouTube Data API productivity and write code using your preferred language’s native features. PHP developers using the Zend framework have had access to a client library for a while now, and that library continues to be a supported way of using the YouTube API. But if you’re a PHP developer using the CodeIgniter framework, you’ll be happy to hear that there’s now an alternative client library available just for you.

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

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

Cheers,
—Jeff Posnick, YouTube API Team

Coming Soon: The Dark Player for Embeds

2011-08-05T22:04:00.000-07:00

You may have noticed that we’ve changed the look of the player on YouTube. You may even have noticed that we’ve been experimenting with changing the look of embedded players too. Coming up on August 10, all embeds will automatically be updated to the new "dark player":

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

To pick an alternate theme, pass in values for the "theme" and "color" player parameters. For instance, if you’d like to keep the traditional colors, you can pass parameters such as:

<iframe width="560" height="349"
  src="http://www.youtube.com/embed/9h1swNWgP8Q?theme=light&color=red"
  frameborder="0" allowfullscreen></iframe>

Here are all the new themes, including the new default:

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

Cheers,
—Shannon -jj Behrens, YouTube API Team

YouTube @ Google I/O: Your Game + YouTube = Instant Community

2011-07-28T13:01:00.001-07:00

If you have ever wondered how to generate excitement around your video game using YouTube, we would like to share a few hints from the makers of Call of Duty: Black Ops. They included the ability to upload gameplay video clips directly from the game to YouTube using the YouTube upload APIs. This fourth, and final installment of Google I/O 2011 session videos covers a game-focused presentation entitled “Your Game + YouTube = Instant Community” by Jarek Wilkiewicz from the YouTube Developer Relations team, Doug Muir, Technical Director from Activision, Cliff Samaniego and Kenji Arai from the YouTube Strategic Partner Management team.

The presentation gives an overview of YouTube platform features relevant to the gaming audience and highlights the benefits that integrating gameplay video uploads can bring into your title. The session also covers the good, the bad and the ugly of the integration project that Black Ops team had undertaken on a compressed timeframe. Finally, we show a couple of examples of user-generated gameplay video clips from Blacks Ops.

Since hindsight is 20/20, especially as it relates to software projects, the presentation also features a small demo of OAuth 2.0 for Devices authorization flow. OAuth 2.0 for Devices streamlines authorization process for embedded devices such as gaming consoles. While the technology was not yet released at the time of Activision’s integration, it is now in Beta. Another example of technology not initially introduced in the integration is WebM/VP8 encoding. If you watch the video you will learn about why the video clips were restricted in size and how WebM helps with solving this issue.

The full video of the session is embedded below, and you can find the slides here.

Cheers,

—Jarek Wilkiewicz, YouTube API Team