Last modified: 2014-05-01 12:26:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 25854 - Expose image thumbs, embedded video players via oEmbed (API + discovery <link rel>)
Expose image thumbs, embedded video players via oEmbed (API + discovery <link...
Status: NEW
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
unspecified
All All
: Normal enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 25862
Blocks: 17503 25269
  Show dependency treegraph
 
Reported: 2010-11-09 20:40 UTC by Brion Vibber
Modified: 2014-05-01 12:26 UTC (History)
18 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brion Vibber 2010-11-09 20:40:29 UTC
The oEmbed protocol is used by a number of sites to make it easier to get thumbnail images or inline video player code for a foreign-hosted media entry that we've just got a URL for. We use this in StatusNet to fetch previews and video embedding for remote media.

Spec: http://oembed.com/

oEmbed data can be read via JSON or XML formats; this may be a good candidate for a custom API module like the opensearch suggestions.


Note that there's an oEmbed proxy service which provides basic metadata on articles for Wikipedia:
http://oohembed.com/oohembed/?url=http%3A//en.wikipedia.org/wiki/Bridge

but it does a poor job on images, where it's really more important:
http://oohembed.com/oohembed/?url=http://en.wikipedia.org/wiki/File:Akashi-kaikyo_bridge3.jpg

We should be able to expose most files as 'photo' or 'video' types, which lets us include a thumbnail URL, and inline HTML for Ogg video players etc.

Compare with Flickr and YouTube entries:
* http://www.flickr.com/services/oembed?url=http://www.flickr.com/photos/brionv/4936308232/&format=json
* http://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=1tjC0mYfcrg&format=json

There are also optional 'maxwidth' and 'maxheight' parameters, which can be used to specify what size thumbnail or inline image/video player you want; the resulting photo/thumb URL or HTML should match.

<link rel>s can specify the JSON and/or XML discovery URLs for the item on the current page, and should be provided to third-party services will pick it up.

I _think_ we should be able to make the video handling pretty general by grabbing HTML fragments from the media handler, though I'm not 100% sure.
Comment 1 Derk-Jan Hartman 2010-11-09 20:44:45 UTC
Doing this properly in api, requires solving bug 25624 first. Until then JS screenscraping for Stockphoto and video embed script is the only option to properly provide embed services with appropriate licensing and attribution conditions.
Comment 2 Brion Vibber 2010-11-09 22:53:35 UTC
(In reply to comment #1)
> Doing this properly in api, requires solving bug 25624 first. Until then JS
> screenscraping for Stockphoto and video embed script is the only option to
> properly provide embed services with appropriate licensing and attribution
> conditions.

oEmbed doesn't expose license info directly, so the buck can be passed for now; whatever our embedded player HTML includes will go in there, whatever doesn't won't. :) (I'm not 100% sure the current state of embedded player helpers for Ogg player; if we have to rig one up, it should probably include text data or link to it, leaving the 'where's the license info' for 'go look at the link'.)

I've started a stub implementation for the API point in a separate git project since it's not too convenient to do a work branch in SVN yet:

http://www.gitorious.org/mediawiki-oembed
http://www.gitorious.org/mediawiki-oembed/mediawiki-oembed/commit/8ddaf0cc918c32a35247472acfb3b8d5289c464c
Comment 3 Brion Vibber 2010-11-10 00:02:08 UTC
Removing dep reference for bug 25624 (machine-readable license info exposed through API). oEmbed doesn't provide license information directly; the embedded player might wish to be able to get at it, but that's out of scope for oEmbed providers and consumers.

Added dep ref for bug 25862 (stable URL interface for media embedding).
Comment 4 Derk-Jan Hartman 2010-11-10 02:01:24 UTC
OK, lets just put it this way then. The Commons community has been highly resistant to any embedding service that does not provide full attribution and license information. They will not settle for "Click here to read the license info" and would request that such a feature is disabled until such a time that such information IS provided inline with the embedding. Stockphoto has shown as much.
Comment 5 Gurch 2010-11-14 00:37:29 UTC
(In reply to comment #4)
> OK, lets just put it this way then. The Commons community has been highly
> resistant to any embedding service that does not provide full attribution and
> license information.

Last time I checked Wikimedia allowed remote linking of images, and I don't think that is going anywhere. oEmbed is scarcely less primitive, are they really opposed to it?
Comment 6 Michael Dale 2011-05-02 18:50:03 UTC
Some notes on the video embedding. We would probably want use an iframe html like youtube and the current mwEmbed gadget based video sharing works. 

The main reason for this is you need javascript support code for the embed players to work. ( ie you have to switch among available video sources and playback methods ) and embedding an iframe is a lot safer then remote javascript. i.e Compromised 3rd party hosted medaWiki installs won't be able to run arbitrary javascript on any page the player is embed on.
Comment 7 Bugmeister Bot 2011-08-19 19:12:26 UTC
Unassigning default assignments. http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/54734
Comment 8 Brion Vibber 2011-09-23 00:17:11 UTC
See also bug 19043 which notes issues with OggHandler + ForeignAPIRepo/InstantCommons: the Cortado java video player sitting on the local domain is unable to download and play offsite Ogg videos.

Using the same embedding iframe stuff for things exported over ForeignAPIRepo might do the job nicely.
Comment 9 Michael Dale 2011-09-23 08:23:24 UTC
Adding a note that facebook now supports open graph html5 sources:
http://developers.facebook.com/docs/opengraph/

So we could now in theory embed html5 wikimedia video inline in facebook with our player and full commons author attribution. 

oEmbed and open graph support would be nice easy win features for Timed Media Handler. But we have new feature lock down until we first get ~a version / release~ of TMH out there.
Comment 10 Nischay Nahata 2012-03-18 13:12:55 UTC
(In reply to comment #2)
> I've started a stub implementation for the API point in a separate git project
> since it's not too convenient to do a work branch in SVN yet:
> 
> http://www.gitorious.org/mediawiki-oembed

I was thinking of an API to embed wiki articles/infobox to external sites.
Maybe it can be done using oembed but I am not sure if I can do it as I am new to Mediawiki.Let me know if I can help.
Comment 11 Brion Vibber 2013-09-28 17:32:57 UTC
Note that there's a proposed successor protocol to oembed: http://iframely.com/oembed2
Comment 12 vladjohn2013 2013-12-01 15:41:41 UTC
Hi, this project is still listed at  https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Extension:OEmbedProvider 

Should this project be still listed in that page? If not, please remove it. If it still makes sense, then it could be moved to the "Featured projects" section if it has community support and mentors.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links