The /e/ URL is valid, as is /v/. Both currently work in general for
YouTube playback on the web. We document /e/ at
http://code.google.com/apis/youtube/js_api_reference.html
as the recommended URL for loading the AS3 embedded player at this
time, and the oEmbed service switched over to returning /e/ URLs
several weeks ago.
Safari on iOS has hardcoded logic in place to detect /v/ embed URLs,
and to turn them in to clickable links that will open in the native
YouTube application on the iOS device. This logic does not work with /
e/ embed URLs, as folks have pointed out in this thread and as we went
over in a thread from a week or so ago. Apple was notified about the
new /e/ URLs in advance of the switch, and are planning on doing the
same thing for /e/ URLs that they currently do for /v/ URLs in an
upcoming release of the Safari iOS browser. There should not be any
need for individual developers to reach out to Apple and petition for
this. Unfortunately, the /e/ switch for the oEmbed service took place
before Apple was able to update iOS Safari, leading to the issues
raised in this thread.
If you'd like to use YouTube embeds that iOS Safari will be able to
play back right now, you have two options: either use /v/ URLs (which
would require manually replacing the /e/ with /v/ in the string
returned by oEmbed) or use <iframe>-style embeds, which you can obtain
from the oEmbed service by passing in the iframe=1 parameter to the
request URL, e.g.
I'll also ask the Players team their thoughts on switching back the
oEmbed responses from /e/ to /v/ URLs, if only temporarily. I don't
know how receptive they will be to that, so I can't make any promises.
Cheers,
-Jeff Posnick, YouTube API Team
~ YouTube is hiring! ~ http://google.com/jobs/workyoutube ~
On Mar 1, 8:52 am, bert bonkowski <bert.bonkow...@gmail.com> wrote:
> Yes, that was what I was assuming or perhaps hoping that that was all there
> was to it. Now it looks even more serious.
>
> Bert
>
>
>
>
>
>
>
> On Tue, Mar 1, 2011 at 3:31 AM, Tim Wintle <timwin...@gmail.com> wrote:
> > On Mon, 2011-02-28 at 23:29 -0500, bert bonkowski wrote:
> > > Is it possible for Wordpress websites to recognize an iOS agent making
> > > the request and consequently replacing occurrences of "/e/" with "/v/"
> > > in the YouTube oembed responses?
>
> > I think you are assuming it's the client making the oembed request.
> > oembed requests are normally cached on the server side, so unless you're
> > passing full headers from the client's initial request to the server's
> > proxied request YouTube doesn't normally know what kind of device will
> > be viewing the content.
>
> > Tim Wintle.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "YouTube APIs Developer Forum" group.
> > To post to this group, send email to youtube-api-gdata@googlegroups.com.
> > To unsubscribe from this group, send email to
> > youtube-api-gdata+unsubscribe@googlegroups.com.
> > For more options, visit this group at
> >http://groups.google.com/group/youtube-api-gdata?hl=en.
--
You received this message because you are subscribed to the Google Groups "YouTube APIs Developer Forum" group.
To post to this group, send email to youtube-api-gdata@googlegroups.com.
To unsubscribe from this group, send email to youtube-api-gdata+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/youtube-api-gdata?hl=en.
No comments:
Post a Comment