youtube-eng.blogspot

Minimum embeds: 200px x 200px

Thursday, March 29, 2012

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

Friday, March 23, 2012

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

https://gdata.youtube.com/feeds/api/users/googledevelopers/uploads?v=2

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

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

All three will return a list of videos uploaded in the GoogleDevelopers YouTube channel, with the most recent uploads listed first. However, only the first URL will return the freshest results available — the second or third feeds could both be missing videos that were uploaded within the past few hours. In addition, even if the videos are listed in the second and third feeds, the metadata returned for those videos might not reflect any recent updates.The reason for this, as explained in our documentation, is that some requests go against our search index, which has cached data, while other requests retrieve data directly from our backend databases, which always contain the most up-to-date data. To determine whether a request will query the search index or the backend database, you can use the following rules of thumb:

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

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

Going against the search index isn’t inherently a bad thing. Using the search index is an incredibly efficient way of returning all the videos that match an arbitrary keyword, or ordering a feed of videos so that they’re sorted by view count. The important thing to realize is that the search index doesn’t need to be used for tasks that the backend database can handle, and you’ll get fresher results from the backend database.Until now we’ve been focusing on retrieving a feed of videos uploaded in a specific account, but these same principles apply to looking up a single video with a given ID as well. Using the information above, can you determine which of these URLs will request a video entry from the backend database, and which will go against the search index?

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

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

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

YouTube, Google+, the API, and You

Thursday, March 15, 2012

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

Monday, March 5, 2012

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

Thursday, March 1, 2012

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

Wednesday, February 15, 2012

Update (August 2012): We now suggest YouTube Direct Lite rather than YouTube Direct for most new integrations.
The following scenario comes up all the time when we talk to developers: a website with an active readership is interested in soliciting videos from its community. While YouTube is a great place to host these videos, it takes some forethought to design a system that makes uploading as straightforward as possible while still adhering to YouTube API Terms of Service and best practices.

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

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

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

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

Cheers,
—Jeff Posnick, YouTube API Team

Watch History Comes to the API

Tuesday, January 24, 2012

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

Engineering and Developers Blog