OEmbed on YouTube

[Chris Zacharias]

As some of you may have already figured out, we are exploring support
for OEmbed on YouTube. Most video pages now have OEmbed link tags in
place. We are currently testing for bugs and could use your help to
make sure our implementation is solid. Once we are certain everything
is running smoothly, we will follow up with further documentation and
a broader announcement. Thanks!

Chris Zacharias
Web Developer @ YouTube

[Leah Culver]

Yeah, Mike and I saw the link tags in the source. Very exciting!

What can we do to help?

Leah

[Takatsugu Shigeta]

Oh, awesome!

BTW, Chris, do you have a plan adding JSON callbacks?
It's like below:
http://www.youtube.com/oembed?url=<URL>&format=json&callback=foo

-- shigeta

[Chris Z]

RE: Leah

Just let us know if anything is missing or not working. I've already
found one bug that needs to be fixed since launching that we hadn't
considered. I'll have a fix in soon. Thanks!

RE: Shigeta

It wouldn't be a problem to implement but I'm wondering if anyone else
has implemented JSON callbacks. It does not seem to appear in the
spec. Is there a reason for this? I would think that it might be a
little dodgy having a provider sending executable code down to the
consumer. I know its done elsewhere in other APIs, but I just want to
make sure this approach is validated by the group before I make the
change.

- Chris

On Sep 15, 6:20 pm, Takatsugu Shigeta <takatsugu.shig...@gmail.com>
wrote:

[Ross Boucher]

>
> RE: Shigeta
>
> It wouldn't be a problem to implement but I'm wondering if anyone else
> has implemented JSON callbacks. It does not seem to appear in the
> spec. Is there a reason for this? I would think that it might be a
> little dodgy having a provider sending executable code down to the
> consumer. I know its done elsewhere in other APIs, but I just want to
> make sure this approach is validated by the group before I make the
> change.
>

As of right now, this is sort of implicitly allowed in the way oembed
works. Because the response is HTML, the implicit assumption is that
people will just append that HTML straight into their page. Of course,
they should make sure to strip anything harmful, especially scripts,
out, but if they aren't, then any oembed provider can execute
arbitrary javascript on your site.

JSONP certainly has this same problem in terms of running arbitrary
javascript, but one of the reasons it probably isn't considered not as
big of a threat is that generally you already know who you are talking
to (or at least expect to be talking to) when you make the request. If
you add autodiscovery into the mix, that's no longer necessarily true.

Unfortunately, I'm not sure there really is a better way than JSONP to
do what you want. I'm sure others will chime in.

-Ross

[Toby Inkster]

On Wed, 2009-09-16 at 07:47 -0700, Chris Z wrote:
> It wouldn't be a problem to implement but I'm wondering if anyone else
> has implemented JSON callbacks.

I have just now as I thought it was such a good idea. The callback
parameter I use is "callback".

Implementers should take note that the correct media type for JSONP is
text/javascript, text/ecmascript, application/javascript or
application/ecmascript, but not application/json.

--
Toby A Inkster
<mailto:ma...@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

[Mike Malone]

Yea, I think the only issue with JSONP is that it encourages inserting
unknown HTML without any sort of sanitization or anything. That said,
I don't think many people will be concerned about trusting YouTube
(after all, most of them are probably already using Google Analytics,
so if Google wanted to pwn them they're already in trouble). And you
can certainly pass through HTML as it is without checking it.

As the security section on oembed.com points out, I still think the
safest way to do oEmbed in general is to stick your embeds in an
iframe on a different domain.

Mike

[James Aylett]

On Wed, Sep 16, 2009 at 05:28:52PM +0100, Toby Inkster wrote:

> Implementers should take note that the correct media type for JSONP is
> text/javascript, text/ecmascript, application/javascript or
> application/ecmascript, but not application/json.

RFC 4329 marks the text/* types as deprecated, I'm guessing for the
usual reason. So really people should use the application/* types only.

James

--
James Aylett

talktorex.co.uk - xapian.org - uncertaintydivision.org

[Mike Malone]

>> Implementers should take note that the correct media type for JSONP is
>> text/javascript, text/ecmascript, application/javascript or
>> application/ecmascript, but not application/json.
>
> RFC 4329 marks the text/* types as deprecated, I'm guessing for the
> usual reason. So really people should use the application/* types only.

Unfortunately when we're talking about JSONP we need to be pragmatic.
JSONP is pointless if it doesn't work properly in browsers. Since IE
(maybe just older versions?) doesn't recognize the
application/javascript mimetype you really _must_ use text/javascript
for JSONP responses, regardless of what the spec says.

Mike

[Toby Inkster]

On Thu, 2009-09-17 at 10:17 -0700, Mike Malone wrote:
> Unfortunately when we're talking about JSONP we need to be pragmatic.
> JSONP is pointless if it doesn't work properly in browsers. Since IE
> (maybe just older versions?) doesn't recognize the
> application/javascript mimetype you really _must_ use text/javascript
> for JSONP responses, regardless of what the spec says.

I could be wrong, as I've not done extensive testing, but I'm pretty
sure that in the presence of a <script type> attribute, browsers tend to
ignore the real media type that a script was served under.

So if you serve a file as application/javascript but link to it using:

<script type="text/javascript" src="..."></script>

it should work more or less everywhere.

Indeed, you could probably serve it as video/mpeg and browsers would
still run it. :-(

[James Aylett]

On Mon, Sep 21, 2009 at 01:01:23PM +0100, Toby Inkster wrote:

[text/ versus application/]

> I could be wrong, as I've not done extensive testing, but I'm pretty
> sure that in the presence of a <script type> attribute, browsers tend to
> ignore the real media type that a script was served under.
>
> So if you serve a file as application/javascript but link to it using:
>
> <script type="text/javascript" src="..."></script>
>
> it should work more or less everywhere.
>
> Indeed, you could probably serve it as video/mpeg and browsers would
> still run it. :-(

Tests: <http://tartarus.org/james/scripttest/>. Using latest browsers,
Firefox, Opera, Safari and Camino (all on Mac) all ignore the server
response type and allow both text/ and application/ in the type
attribute. IE 8 ignores the server response type and allows text/ only
in the type attribute.

So the recommendation should be for clients to a JSONP-enabled oEmbed
endpoint to use text/javascript. Apologies for supporting the opposite
without thinking through the implications.

Whether the oEmbed endpoints themselves should be recommended to use
application/ may depend on someone breaking out earlier versions of
browsers (particularly IE 5, 6, 7 I guess) and figuring out what they
do. I'd favour application/ from the server if it works in older IEs.

oEmbed already mandates UTF-8, so we don't have to worry about that
(except sometimes for setting charset explicitly on the script
element).

J

[pe...@kodfabrik.se]

I'm currently using this support on a new site I'm building and has
updated my oEmbed module for Drupal to use this native support for
embedding YouTube videos.

Some feedback on it:

Try to maximize the specified dimensions whenever possible - I wanted
to have a player with a width of 610 pixels and specified it as
maxwidth - but it seems like the player is capped at 567 pixels. Would
look a lot better on the site I'm building now if it's filling the
entire width of the column and I can see no technical reason for this
limitation?

Would it be possible to add thumbnails? You're already using
thumbnails on youtube.com - would be great if you would expose them
through oembed as well so that we could use a thumbnail in eg. lists
of content where a small image would be much more convenient (and
faster) than a million small youtube players :)

/ Pelle Wessman

On 15 Sep, 05:05, Chris Zacharias <christopher.zachar...@gmail.com>
wrote:

[Chris Z]

On Oct 1, 7:20 am, "g...@vox.nu" <pe...@kodfabrik.se> wrote:
> I'm currently using this support on a new site I'm building and has
> updated my oEmbed module for Drupal to use this native support for
> embedding YouTube videos.
>
> Some feedback on it:
>
> Try to maximize the specified dimensions whenever possible - I wanted
> to have a player with a width of 610 pixels and specified it as
> maxwidth - but it seems like the player is capped at 567 pixels. Would
> look a lot better on the site I'm building now if it's filling the
> entire width of the column and I can see no technical reason for this
> limitation?

I will look into this, but won't have a fix in this week. The logic
behind these constraints is no longer valid (afaik) due to recent
upgrades to the players.

> Would it be possible to add thumbnails? You're already using
> thumbnails on youtube.com - would be great if you would expose them
> through oembed as well so that we could use a thumbnail in eg. lists
> of content where a small image would be much more convenient (and
> faster) than a million small youtube players :)

I don't think this is unreasonable. When I have a moment, I will work
on implementing it.

[globe]

Hi Chris,

On Oct 2, 6:19 pm, Chris Z <christopher.zachar...@gmail.com> wrote:
> > Would it be possible to add thumbnails? [...]

> I don't think this is unreasonable. When I have a moment, I will work
> on implementing it.

As I stumbled across the missing thumbnails today, i thought a little
reminder could help. :)

Using http://www.youtube.com/watch?v=5G0Sq3lwtTs&feature=fvw to get
http://i.ytimg.com/vi/5G0Sq3lwtTs/1.jpg is not much of an issue to
implement manually. But since an open API is already in place, it
kinda seems wrong.

Best Regards,
Rod

[globe]

Hi Chris, Hi Everyone,

I don't quite understand why the oembed specification does not
consider descriptions. Descriptions - in combination with a thumbnail
- are sufficient to serve as a preview. I don't want to load 10 flash
containers on my page, if the user is only interested in one. In
regard to YouTube, Facebook is pretty much doing what I'm trying to
explain here.

On Oct 2, 6:19 pm, Chris Z <christopher.zachar...@gmail.com> wrote:

> I don't think this is unreasonable. When I have a moment, I will work
> on implementing it.

While you're at integrating thumbnail(s), it would be awesome if you
could also introduce a <description>.

The oembed-spec clearly allows the introduction of provider-specific
parameters:
»Providers may optionally include any parameters not specified in this
document (so long as they use the same key-value format) and consumers
may choose to ignore these.«

[Geoff Stearns]

This setup sounds much more advanced than I think the average setup will be.

We already provide data about videos via our GData API[1] - you can get thumbnails and descriptions and titles and whatnot (including any viewing restrictions, etc.). I'm not sure that this data belongs in the oEmbed response since I think it's doubtful that most people would use it.

Obviously we want you to embed the player directly on your pages and not offer thumbnails + titles/descriptions instead - people know what YouTube embeds look like and I'd venture to say that they are probably more likely to click on it if they recognize it and know how to use it. We also run regular experiments on the UI of the player to see how we can improve that experience and increase usage.

I understand your disdain for flash elements littered across the page, but we do work hard to keep the CPU usage of our player as low as possible until the user hits play or interacts with the player.

[1] http://code.google.com/apis/youtube/getting_started.html#data_api

[Leah Culver]

Hi all!

About extra parameters...

Section 2.3.4 (http://oembed.com/) lists a thumbnail_url, as well as thumbnail_width and thumbnail_height, as optional response parameters. It's up to providers, such as YouTube, to decide if they want to provide this. It seems like in this case, Chris is on track to add a thumbnail_url to YouTube OEmbed.

For descriptions, Rod is correct - provider could chose to return a description. In this case, it's completely up to YouTube. If descriptions start to be commonly used, we could add "description" as an optional parameter in the documentation.

The purposes of OEmbed is to be the easiest way to get a visual representation of media via simple link to the permalink page. Therefore, the response can differ based on the type of media item as well as the provider.

Cheers,
Leah

[globe]

Hi Geoff,

On Oct 21, 6:40 pm, Geoff Stearns <ge...@deconcept.com> wrote:
> This setup sounds much more advanced than I think the average setup will be.

If oembed ultimate (and only goal) is to embed videos and images
directly and most people just need that simple functionality, yes, you
may be right.

> We already provide data about videos via our GData API[1] - you can get
> thumbnails and descriptions and titles and whatnot (including any viewing
> restrictions, etc.). I'm not sure that this data belongs in the oEmbed
> response since I think it's doubtful that most people would use it.

I was too focused on oembed that I did not search for any other APIs.
Thank you for the link. I will have a closer look at the GData API and
consider using it for YouTube rather then relying on oembed.

> Obviously we want you to embed the player directly on your pages [...]

Don't get me wrong. I'm happy for you allowing me to integrate your
content on my site. But even if it's your content, it's still my site,
my design, my interaction principles, my world. On my site I'm in
charge of how things look and interact. I'd rather integrate a simple
link (you know, like back in 1998) than being forced to do something
that doesn't fit my concept. (I hope you didn't get my choice of words
wrong - I wasn't trying to piss you off!)

> I understand your disdain for flash elements littered across the page, but
> we do work hard to keep the CPU usage of our player as low as possible until
> the user hits play or interacts with the player.

And I may say you're doing a pretty fine job. :)


Best Regards,
Rod

[globe]

Hi Leah,

On Oct 21, 7:00 pm, Leah Culver <leah.cul...@gmail.com> wrote:
> For descriptions, Rod is correct - provider could chose to return a
> description. In this case, it's completely up to YouTube. If descriptions
> start to be commonly used, we could add "description" as an optional
> parameter in the documentation.

If you want to make description optional, I would try it the other way
'round. Introduce the new parameter into the spec and see what
happens. This way new implementors will at least be hinted to include
the description.

> The purposes of OEmbed is to be the easiest way to get a visual
> representation of media via simple link to the permalink page. Therefore,
> the response can differ based on the type of media item as well as the
> provider.

I don't see why oembed can't be a bit more. Simple, flexible and used
for a bit more than merely injecting some foreign HTML. If that were
your only goal, why supply data like author, title, etc.?

Best Regards,
Rod

[James Aylett]

On Wed, Oct 21, 2009 at 09:40:45AM -0700, Geoff Stearns wrote:

> I understand your disdain for flash elements littered across the page, but
> we do work hard to keep the CPU usage of our player as low as possible until
> the user hits play or interacts with the player.

Which is great providing you aren't in an environment when embedding
Flash is tricky, but providing a link out to YouTube would work fine;
such as Android, where a static thumbnail frame + description could
link through and all would be well. (Or static thumbnail which could
enable the full embed.)

Whether this is a niche or even strawman issue right now is another
matter. I doubt it'll go away, though.

James

[Pelle Wessman]

I think that thumbnails belongs in the oembed for some reasons:

Size - the player is only usable when it's big enough. Consider that I embed a YouTube-player in an article and I have a teaser in that article in which I would like to hint about the embedded video. It wouldn't be a good solution to embed a very small video in the teaserlist - but a thumbnail would be great.

Thumbnails can be more controlled - they don't include html sometimes you need to know the exact properties of something that you embed and that is possible with a thumbnail but not with a video since you don't know what html is returned. This is true for iPhone apps and in special cases on a regular web page.

My usecase is that I have a newspaper that have an article type that relies heavily on oembedded youtube clips. It works fine until they want a teaser for that article type because now the only possible solution is to embed a minimal youtube player and what would be a better solution would be something like Google does when a video shows up in the search result.


Also - a bug report in regards to the oembed solution. All of these four url:s should have a maxwidth of 340 - but only one of them actually gets an embed that fits within that width.

http://www.youtube.com/oembed?format=xml&maxwidth=340&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DgjwgYvzQWS4
http://www.youtube.com/oembed?format=xml&maxwidth=340&maxheight=280&url=http%3A%2F%2Fwww.youtube.com%2Fwatch%3Fv%3DgjwgYvzQWS4
http://www.youtube.com/oembed?format=xml&maxwidth=340&url=http:%2f%2fwww.youtube.com%2fwatch?v=78cr-SOHaCY
http://www.youtube.com/oembed?format=xml&maxwidth=340&maxheight=280&url=http:%2f%2fwww.youtube.com%2fwatch?v=78cr-SOHaCY

/ Pelle Wessman

[Jonathan]

Is there any news on Youtube's support for the maxwidth parameter? It
seems to work only in some cases.. We've been forced to write a
workaround due to the intermittent nature of the implementation.

[jsmullyan]

Just a moment ago, before I was approved for this list and read this
thread, I created the following ticket about this thumbnail issue:

http://code.google.com/p/gdata-issues/issues/detail?id=1640

My argument there was that oembed was particularly suited for cases
when you are dealing with multiple providers, which means multiple
videos, which in turn means either thumbnails or multiple flash
players (not necessarily youtube's expertly optimized one). In that
mixed provider environment, I'd argue that thumbnails are particularly
desirable.

Jacob Smullyan

[Lloyd Budd]

Hi Jonathan,

Can you share your workaround?

We might need to incorporate something like that in WordPress
http://core.trac.wordpress.org/ticket/10337#comment:62

Thank you,
Lloyd

[Geoff Stearns]

Can you give examples of it failing to give the correct width?

The oembed code will maintain the video's aspect ratio (either 4:3 or 16:9), so if you give it a large width but small height, it may make the width a little smaller in order to maintain the aspect ratio.

On Mon, Nov 16, 2009 at 10:05 AM, Jonathan <m...@jonathanpuckey.com> wrote:

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "OEmbed" group.
To post to this group, send email to oem...@googlegroups.com
To unsubscribe from this group, send email to oembed+un...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oembed?hl=en
-~----------~----~----~----~------~----~------~--~---

[danielsemper]

My maxwidth is: 620 and maxheight: 700

Every Youtube video should be resized to width: 620, but some of them
adopts width=”384″ (maybe a default value from youtube).

For Example:

Bug: (width changes to 384)
http://www.youtube.com/oembed?format=xml&maxwidth=620&maxheight=700&url=http:%2f%2fwww.youtube.com%2fwatch?v=CeTa7YYkMcE

Correct width:
http://www.youtube.com/oembed?format=xml&maxwidth=620&maxheight=700&url=http:%2f%2fwww.youtube.com%2fwatch?v=H5UmoD9ReXU

Is there a fix to this?

PD.- None of the Dailymotion videos obey the width parameter.

On 3 dic 2009, 19:36, Geoff Stearns <ge...@deconcept.com> wrote:
> Can you give examples of it failing to give the correct width?
>
> The oembed code will maintain the video's aspect ratio (either 4:3 or 16:9),
> so if you give it a large width but small height, it may make the width a
> little smaller in order to maintain the aspect ratio.
>
> On Mon, Nov 16, 2009 at 10:05 AM, Jonathan <m...@jonathanpuckey.com> wrote:
>
> > Is there any news on Youtube's support for the maxwidth parameter? It
> > seems to work only in some cases.. We've been forced to write a
> > workaround due to the intermittent nature of the implementation.
> > --~--~---------~--~----~------------~-------~--~----~
> > You received this message because you are subscribed to the Google Groups
> > "OEmbed" group.
> > To post to this group, send email to oem...@googlegroups.com
> > To unsubscribe from this group, send email to

> > oembed+un...@googlegroups.com<oembed%2Bunsu...@googlegroups.com>

[bbiggs]

YouTube will return an embed limited to a width of 384 (aspect
correct) for videos where the source file is low resolution. The idea
is that if someone uploads a cellphone camera video, embeds would be
smaller (and look better with less scaling).

The max width and height parameters specify a bounding box, not a
preferred size. Our interpretation of oEmbed was that we should pick
whatever size we think is good for the video so long as it fits in
that bounding box.

It may be reasonable to extend the oEmbed spec to support this use
case.

-Billy

On Jan 5, 12:09 pm, danielsemper <semperte...@gmail.com> wrote:
> My maxwidth is: 620 and maxheight: 700
>
> Every Youtube video should be resized to width: 620, but some of them
> adopts width=”384″ (maybe a default value from youtube).
>
> For Example:
>

> Bug: (width changes to 384)http://www.youtube.com/oembed?format=xml&maxwidth=620&maxheight=700&u...
>
> Correct width:http://www.youtube.com/oembed?format=xml&maxwidth=620&maxheight=700&u...

[Viper0007Bond]

Can't find one off the top of my head, but if I remember correctly,
you could pass it 1000x1000 for example and neither returned dimension
would be 1000. It was maintaining aspect ratio, it was just too
small. If I come across it again, I'll make sure to post it here.

Chris: any chance of youtu.be support on your oEmbed provider? It'd
be great if this worked: http://www.youtube.com/oembed?format=xml&url=http%3A%2F%2Fyoutu.be%2FnTDNLUzjkpg
( http://youtu.be/nTDNLUzjkpg )

[Viper0007Bond]

Whoops, stupid Google Groups interface. I missed the second page of
this thread where Billy mentioned small videos aren't resized to over
100% of their original size.

On Jan 14, 3:41 pm, Viper0007Bond <viper007b...@gmail.com> wrote:
> Can't find one off the top of my head, but if I remember correctly,
> you could pass it 1000x1000 for example and neither returned dimension
> would be 1000. It was maintaining aspect ratio, it was just too
> small.  If I come across it again, I'll make sure to post it here.
>
> Chris: any chance of youtu.be support on your oEmbed provider?  It'd

> be great if this worked:http://www.youtube.com/oembed?format=xml&url=http%3A%2F%2Fyoutu.be%2F...
> (http://youtu.be/nTDNLUzjkpg)

[Viper007Bond]

On Thu, Jan 14, 2010 at 3:43 PM, Viper0007Bond <viper0...@gmail.com> wrote:

Whoops, stupid Google Groups interface. I missed the second page of
this thread where Billy mentioned small videos aren't resized to over
100% of their original size.

Apologies for the triple post, but I wanted to correct my previous posting:

Whoops, stupid me. Not used to the Google Groups interface. I missed [...]