Embedding digital assets

[Mandar Kulkarni]

At the moment we have public urls exposed for assets uploaded in our
Digital Asset Management (DAM) system. We are considering adding a
couple of new features on top of it -

1. Exposing embed html for assets, which users can directly copy to
their webpages, blogs etc. Picasa, Flickr among others have this
provision.

2. Second feature will be similar to this example - a Facebook user
copies a link to Hulu video on his wall and when he posts that, what
is shown is inline video embed and not just a link as posted
originally. According to what I read, here Hulu is an oEmbed provider
and Facebook an oEmbed consumer. So using that link Facebook fetches
the oEmbed response from Hulu's oEmbed endpoint and dumps the HTML
part on the wall. (Please correct me if I am wrong - Facebook and Hulu
might be just imaginary players here)

For #2, we also want to return custom metadata alongwith actual asset.
I assume that is possible in oEmbed as there is provision to return
custom parameters in the response.

So what I expect from the experienced people out here is -

A. Is my understanding in #2 correct?
B. Can oEmbed help in #1? If not do we need to have our custom
implementation for it? Or is there any other standard/library
available for this scenario?

Thanks!

Mandar

[Leah Culver]

Hi Mandar,

On Wednesday, September 7, 2011 at 7:00 AM, Mandar Kulkarni wrote:

At the moment we have public urls exposed for assets uploaded in our
Digital Asset Management (DAM) system. We are considering adding a
couple of new features on top of it -

1. Exposing embed html for assets, which users can directly copy to
their webpages, blogs etc. Picasa, Flickr among others have this
provision.

2. Second feature will be similar to this example - a Facebook user
copies a link to Hulu video on his wall and when he posts that, what
is shown is inline video embed and not just a link as posted
originally. According to what I read, here Hulu is an oEmbed provider
and Facebook an oEmbed consumer. So using that link Facebook fetches
the oEmbed response from Hulu's oEmbed endpoint and dumps the HTML
part on the wall. (Please correct me if I am wrong - Facebook and Hulu
might be just imaginary players here)

For #2, we also want to return custom metadata alongwith actual asset.
I assume that is possible in oEmbed as there is provision to return
custom parameters in the response.

So what I expect from the experienced people out here is -

A. Is my understanding in #2 correct?

Yes. This scenario is pretty much what oEmbed was created for. Hulu definitely supports oEmbed but I'm not sure about Facebook.

oEmbed providers, like Hulu, may include any additional data they like. From 2.3.4 of the spec: "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. Consumers must ignore parameters they do not understand." 

B. Can oEmbed help in #1? If not do we need to have our custom
implementation for it? Or is there any other standard/library
available for this scenario?

Nope. You'll need to create your own embed code and display it to your users. However, you can reuse this embed code in your oEmbed API. I haven't worked much with video... anyone else have suggestions for how to make embed code?

Leah 

[Adam Nemeth]

On Wed, Sep 7, 2011 at 11:50 PM, Leah Culver <leah....@gmail.com> wrote:

Nope. You'll need to create your own embed code and display it to your users. However, you can reuse this embed code in your oEmbed API. I haven't worked much with video... anyone else have suggestions for how to make embed code?

Leah 

Bit off, yet: you create embed code with an <iframe>. Previously you created embed code with embed, yet it was 99 for flash, which mobile browsers don't support, and once the codec war is over, you'll be able to create one with <video>, yet the current approach is that:

   - you create a page without menu or anything, which loads the appropriate videoplayer with whatever technology is your (or your user's) choice (for desktop, it'll be mostly flash, for smartphones, it'll be m4v)

   - you create an iframe which points to this page, with the size of the player.

Essentially, oembed could provide a general solution for that as it's a "universal" solution, yet perhaps not the best one.

--
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.

--
Aadaam <aad...@gmail.com>

[Mandar Kulkarni]

Thanks for all the replies!

Talking about embeds for videos, is it a standard practice to make
videos available in flash format? We allow users of our system to
upload any kind of asset; so videos can be anything - flash, wmv, avi
etc. We can create flash proxies for these. But I wanted to know what
is the accepted way of doing this? And same questions goes with other
types of assets like pdf, doc, ppts, mp3 etc.

Mandar


On Sep 8, 4:19 am, Adam Nemeth <aad...@gmail.com> wrote:

[Brion Vibber]

On Thu, Sep 8, 2011 at 3:53 AM, Mandar Kulkarni <mandarp...@gmail.com> wrote:

Talking about embeds for videos, is it a standard practice to make
videos available in flash format? We allow users of our system to
upload any kind of asset; so videos can be anything - flash, wmv, avi
etc. We can create flash proxies for these. But I wanted to know what
is the accepted way of doing this? And same questions goes with other
types of assets like pdf, doc, ppts, mp3 etc.

oEmbed doesn't directly expose the original files for video and interactive media types, so you can emit whatever HTML code is necessary to show an inline player or download gadget for the formats you choose to expose.

My own preference is for the embedding HTML you give to just be an iframe with a URL, and have that load up a mini-frame that uses whatever player tech is appropriate for the web browser loading it.

Don't forget that Flash isn't always available, especially on tablets and smartphones! If you're already converting to MP4/H.264 for Flash, I strongly recommend having at least an HTML 5 <video> fallback using the same file. (If you're brave, include WebM and Theora transcodes as well for the patent-free open source set! :)

-- brion vibber (brion @ pobox.com / brion @ wikimedia.org)

[Mandar Kulkarni]

Thanks for all the replies. Those were really useful.

At the moment I have settled on an iframe pointing to a page on our
server which emits the embed HTML.

Mandar

On Sep 8, 11:05 pm, Brion Vibber <br...@pobox.com> wrote:
> On Thu, Sep 8, 2011 at 3:53 AM, Mandar Kulkarni

> <mandarpkulka...@gmail.com>wrote: