Pownce is the best way to share media with your friends online and one of the best parts of Pownce is the embedded images and video. When you post a link-type note with a URL to an image site such as Flickr, the Pownce website displays a thumbnail of that image. Video links display an embedded video player for sites such as Ustream, Qik, or Viddler.
At Pownce, we were adding these new video and photo service embeds on a case-by-case basis with custom code for each site. As we got more requests for supporting different services, we realized that we didn’t want to pick and choose which services we would implement. We want to support as many services as possible!
While at dinner with Cal Henderson (Flickr), Mike Malone (Pownce), and Richard Crowley (OpenDNS), we chatted about this problem and chatted about creating an open standard for accessing embed code from a URL via an API endpoint. Cal drafted up the initial spec for this standard overnight and we named it OEmbed (or oEmbed).
OEmbed is an open web API standard for fetching embed code based on a URL. The spec is fairly simple and can be found at oembed.com.
Since creating OEmbed, we’ve been working with various photo and video sites to implement this standard. OEmbed is currently supported by Flickr, Viddler, Qik, Pownce, Revision3 and Hulu. Vimeo and Blip.tv are currently working on implementations. Pownce is the first consumer of OEmbed; we use these APIs to display inline images and video on the Pownce site. We’ve been working with Digg and Facebook to use OEmbed for story and share embeds.
We’re excited about gaining more support and feedback for OEmbed. If you work on a photo or video sharing site and are interested in adding OEmbed to your API or if you’d like to use OEmbed as a consumer, please join our Google Group - we’d love to hear from you.
More press:
11 Comments
Eric Florenzano
Also, if you’re using Django, I recently wrote a reusable application for quickly getting up and running with oembed. You can find it here: http://code.google.com/p/django-oembed/
Youpinadi
oEmbed is coming soon on Dailymotion! It’s already “soft launched”. Example: http://www.dailymotion.com/oembed/video/x5kyog_weezer-pork-and-beans_music?format=xml
Wil Tan (MojiPage)
This is really cool! A concise spec with a well-defined, much needed use case, implemented in an efficient and elegant RESTful manner! Kudos to you guys!
While we are waiting for some services to support it, does it make sense to create an oEmbed proxy?
Adam Nemeth
Whoah, thinking / working on such solutions for ages!
Another thing: maybe a http header extension or catalog would be needed, so it could be auto-detected if some site supports oembed or such. Like RSS auto-discovery:
link type=”alternative” type=”oembed/json”…
something like such.. maybe provided by regexps.. relative to the element url (s/flickr.com\//photo\//.*/flickr.com\/oembed?\1 ?), maybe provided in the root page, like favicon (even better, maybe forcing the provider to always use the same scheme, eg. it should be http://www.domainname.com/oembed always…)
All this stuff is for consumers to auto-discover new oembed providers.
Matt Froese
Excellent idea. I am happy to see many sites on board already.
Is it really necessary to pass a full url to the oembed request. Seems somewhat redudant to request something from Flickr by sending it a Flickr URL!
Wil Tan (MojiPage)
@adam, there are too many link tags. XRDS-Simple http://xrds-simple.net/ was created for this so we should use it.
Leah, I’d be curious to know if you have discussed using a template in addition to the currently-defined per-instance mechanism. For the most part, the chunk of HTML used for embedding a particular URL scheme (such as Youtube) won’t change much, so it could be a waste of resources to do that for every call.
Of course, there are still plenty of use-cases for having per-instance call so as to allow providers to control it at a finer-granularity.
There are definitely interesting applications of this in the “mobile web” arena.
Dean Landolt
Beautiful. I can envision this being useful for all kinds of rich objects, not just media. Most objects have at least a few natural metaphors for how they would be represented when embedding — this would allow the object’s owner to provide a skeleton for that metaphor. Especially if some kind of autodiscovery a la rss be were in the offing?
I’m not much of a security weenie, but perhaps autodiscovering foreign code to embed may be a bit too risky. Perhaps a whitelist providers could register domains with as part of the autodiscovery spec would alleviate some of the problems.
Still, elegant spec. Brilliant.
Michael R. Bernstein
Standardizing the format and the endpoint schema for information about embeddable content is a great idea and will obviously save a lot of duplicated effort. But there is no provision here for autodiscovery, so this does not actually accomplish the stated goal of eliminating manually picking and choosing which services to support.
thejbf
Finally data is getting out of pages! I’m so sure that in a short time, major media providers like youtube will go for this marvelous concept!
robert
Does oembed output standards compliant code, or code that will work across all the old browsers instead? I figure I know the answer, but figured I would ask anyways.
Also a port of this to say a wordpress plug in, could be infinitely useful as well.
Other than that, great job, I am surprised you guys had to come up with this and it wasn’t available in the first place.
Andrew Mager
Don’t forget about Plurk!
Hey, I was gonna write about OEmbed at the same time