Can't use Blip.tv Embed Code instead of URL

Hmmm- yeah, I think we need to change the logic here a bit. The issue is that the embedded url contains a different "code" than the page urls (i.e. 1159121 vs. gaUIx5A7AA), and it doesn't look like you can get a valid xml back from blip when you send it the code from the embed source. I'm not sure if there's anyway to reverse lookup the page url code from the embed code, and thus no way to get a valid xml returned, so we have to think through how this could work...

We may have to reach out to the Blip.tv folks on this one...

AH! This is also happening with the 6-dev version as well... I was just about to write a ticket about it. I have been in touch with Blip.tv about it... this explains why I was seeing pr0n on my site instead of my innocuous videos.

I made a screenshot for the fun of it. I was trying to show that I used the embed code given me, but it didn't show my video. This is the code I was initially given:

<embed src="http://blip.tv/play/AcefZgA"
type="application/x-shockwave-flash" width="320" height="260"
allowscriptaccess="always" allowfullscreen="true"></embed>

One little mystery which I find perplexing is that when I've gone back to my video pages, I see my embed code has changed... I don't know how or why. This is the URL: http://kidsown.blip.tv/#1167234

I was told by Blip.tv support that they used the code above and saw my video... However, looking at the page he explained "I don't find that code at all. I see what appears to be an incorrect version of the embed code which may naturally behave in an unexpected manner."

Hello guys,

I am from blip.tv. I'm having a hard time following exactly what's needed because I don't use Drupal or know what value is being added by Embedded Video Field. If you have a custom player that you want to use, can you just embed that code into the page, without running it through the Embedded Video Field component, where it apparently gets mutilated?

Let's start with this: what results are you seeking, given which piece of information?

Since we allow users to create multiple players, I'm not sure how a specific player could be selected from the page URL alone. There would have to be a second parameter somehow, which specifies the desired player.

It seems that this Embedded Video Field system should simply pass through a blip.tv embed code without attempting to alter it. Is that a possibility? It seems that this would satisfy both you and Heather. I don't understand why the embed code would ever be disassembled if it must simply be reassembled again in order to play properly, whereas it makes perfect sense to attempt to construct an embed code around a bare URL.

The reason that the code was "butchered" was in order to make it validate as strict XHTML. But, we'll change back to the other one and just include the object embedding as a possible theme function override. As to why we don't just pass along the embed code, there are a few reasons, first and foremost the xml/json services that blip attaches to a file gives you much more info than just the video, for example the thumbnail, which when combined with thickbox makes for great video galleries, and Views integration (which is what gives Drupal its mojo).

I actually thought we had resolved this problem in the past, but obviously not. I just committed changes that should make the custom player work from the url. It still won't work with the embed code, but I can't think of a way around that problem atm.

Drupal 6 only. Drupal 5.x still uses video_cck rather than emvideo

I'll update it later today.

Hello Alex,

We recently replaced our (XHTML compliant) object elements with (XHTML deprecated) embed elements because of an issue in IE that forbids us from using redirection to provide the flashvars. With the embed element, the source URL can redirect to a URL containing flashvars, which means blip.tv users can change the properties of players that are already embedded.

Unfortunately, it is no longer possible to discover the extra information (thumbnails, etc.) from the embed code. Therefore I suggest you implement the following behavior:

0. Advise your users that page URLs are better than embed codes.

1. If a page URL is input, use the XML or JSON format to look up the extra information (thumbnails, etc.).

2. If an embed code is input, pass it through unchanged.

What do you think?

Also, I'm curious what you did when "I just committed changes that should make the custom player work from the url. " How are you selecting which custom player to use?

@charles.hope

I think that your solutions sounds good, but would not work for many/most users in practice. The biggest issue is that those videos would not have thumbnails, which I suppose we could solve by adding a default thumbnail ('This video does not have a thumbnail') and pushing people to use emfield's emthumb module. But, atm, I don't have time to start to attempt this code- if someone else does and submits it here I'll be more than happy to review it, and if it seems to work without breaking too many things, committing it.

As far as the custom player to use: I have no idea. It's simply posting the embed code you'd find on a blip.tv video- so how do you choose the player that way?

Indeed, you could refuse to accept embed code, and only accept page URLs, because as you observe, the thumbnail cannot be retrieved from embed code.

Embed codes for custom players are available on the page, but not in the JSON, so I don't see how your solution "should make the custom player work from the url."

Backtracking a bit here to try to understand what's happening.

The issue all along with Blip.tv has been that the URL they provide uses a different video code than the embedded player. The work-around we've traditionally used has been to use the code from the URL to look up their REST API to discover the code needed for the embedded player.

The embed code already has the value we need, but unfortunately, the way we set up the field (working with most other providers that simply use a single video code) has been that we require a reverse lookup when using the embedded video code. In retrospect, we should have followed Blip.TV's lead and distanced ourselves entirely from the URL. However, we're stuck with it now, with hundreds of sites using the module to embed thousands of Blip.TV videos -- I have no interest in answering the tons of support questions that would pop up if we broke existing nodes.

That means that we need to:
A) If we have the URL, look up the embed code.
B) If we have the embed code, look up the URL video code.

We store both of them, and use them both in different cases.

As I recall, it has always been difficult to do B. I'll have to see why what we've been using is no longer working.

Meanwhile, perhaps Charles Hope could provide us with a standard method to do both of these; we've been using a combination of their REST API and an RSS feed, as I recall.

Basically, we will have precisely one of either the URL or the embed video code, and need to discover both of them. If their custom players require yet another code, then we need that as well. All from only one or the other.

Thanks,
Aaron Winborn

@Charles- after I switched the code, the player changed to a "branded" player (i.e. it said the shows name on the player instead of blip.tv). I assumed that was the extent of the difference, but apparently not.

Is it not possible to include other embed codes in the json/xml, similar to how you provide multiple video formats, when available?

Hello Aaron,

I have already explained that it is possible to do A and almost impossible to do B. We have intentionally abstracted the embed code away from representing a single specific video, so that now our embed codes may represent entire playlists, or the video most recently created by the user.

Although our embed codes do not make the thumbnails files available, they are displayed for the user, and this is better than nothing, therefore I once again suggest my three implementation points as the best possible solution.

@charles.hope - as I mentioned before: we aren't just retrieving the thumbnails in every case. Often, when I use the module to build sites for clients, I grab entire feeds of videos from blip and map the data in the XML file to various fields I define (for example I tend to pull the tags, thumbnail, author name, etc) using the FeedAPI and FeedAPI Element Mapper.

One potential workaround would be to provide a default thumbnail (i.e. a small jpeg that says "thumbnail not available") and allow the user to override via the embedded thumbnail module, but I still don't think that this is a good idea, and I think it will lead to a lot of support requests along the lines of "Why don't I get my thumbnails?". But then again, some providers change their thumbnail info or remove support from that feature all together, so maybe it's not such a big deal...

I think that the best we can do at this point is to let people know that we don't support blip embed codes, nor do we support the custom players. I don't think it's worth our time to try and hack something together before the Blip api provides for all of the services that the site offers (imo, it's odd that it allows you to upload via the api but not retrieve any custom features), and fundamentally changing emfield to suite one provider just isn't going to happen (despite blip's awesomeness).

Hello Alex,

I agree that you should advise your users that page URLs are the preferred means of referencing a video.

We can make custom embed codes available in the JSON format. Can you tell me exactly what call you're making?

subscribing

downgrading from critical. moving to the d6 version. if this ever gets fixed, it can be backported.

I just committed a validation hook for blip.tv that checks that we haven't pasted an embed code rather than a URL. Should make things a little more user-friendly until Blip.TV gives us a way to generate the URL from an embed code.

does this mean that if we use the embed code instead of the url that the module won't be able to pull additional formats for rss?

subscribe

Hey guys,

You can turn our embed code URLs into an API call by changing /play to /players/episode. So for example with the embed in the example above:

<embed src="http://blip.tv/play/gaUIx5A7AA" type="application/x-shockwave-flash" width="320" height="270" allowscriptaccess="always" allowfullscreen="true"></embed>

Try

http://blip.tv/players/episode/gaUIx5A7AA?skin=api

or

http://blip.tv/players/episode/gaUIx5A7AA?skin=json&version=2&callback=foo

Where does this issue stand? It looks like potatono has provided a way that will work (potatono, are you from Blip.tv?), but of course if you try to enter the embed into an emfield field you still get the 'Please do not use the Embed Code from Blip.TV. You must instead paste the URL from the video page.' message, preventing you from being able to embed.

9 months have gone by since Aaron made this change (according to the dates on this thread). Can we re-awaken this from hibernation?

I'm confirming that this is still an issue in Media: BlipTV, and moving into the correct queue. I'm also marking it as a feature request (patches welcome!), since Blip works fine with the URLs this isn't really a bug.

For reference, if this is patched then this feature will be available via Media: BlipTV, and will require Emfield 6.x-2.x.

I'm hoping someone here can help me too. For some reason my video wont load on my site. Here is the external link: http://blip.tv/file/4092158. And here is the page it's on http://www.divejp.com/dive-mask-preparation-using-omer-alien-1st-dive. The weird thing is, the drupal install seems to be working, because if I paste cbloodworth's link in my node (http://blip.tv/file/1159121), it loads his video on my page and works just fine. What is going on here? Is there some setting on blip.tv that blocks my video from being embedded.

I researched everywhere on google and through drupal.org, and can't see anyone else having this problem.

Please help!!!

@drupalfan81: It appears you got the video working.

@drupalfan81: I seem to be having the same problem that you were having a few weeks ago. Since you were able to fix it, can you tell me what you did? When I paste other blip.tv video urls into my video field, they work (I tried both cbloodworth's and yours). When I paste my url (http://blip.tv/file/4322750), I get this message under the video heading (and no video):

FAIL (the browser should render some flash content, not this).

My video is rather long (~1 hour), so maybe that is part of my problem? Any tips are welcome - thanks in advance!

Yep - same issue as #35. A blip url like http://blip.tv/file/4322750 not working...

Using v 1.24 - does 1.25 or DEV fix this? I don't see any notes indicating that.

Thanks.

@Mercury500: I got a response from blip.tv - apparently their new player doesn't work with the Drupal Media:Blip.Tv module. Bummer. They are looking into it (even though they don't technically support the module). I tried vimeo and it worked for embedding my video to my website. Good luck!

For what it's worth, I can confirm that the information potatono provided is accurate. Using the embed code in that manner produces a nearly identical XML document to using the file page API. The only difference is the omission of one seemingly unimportant tag (<link type="application/rdf+xml" href="http://blip.tv/users/view/UserName" />).

I'd very much like to have this feature, since custom player styles is a big reason why I use blip.tv in the first place. Embed code is the only guaranteed way to get the intended player style.

subscribing

Just wanted to point out that I was having this problem, but just noticed that as of this morning, I am now seeing the custom blip.tv player on my site. Perhaps the good folks at blip took care of this?

Sorry, what format should we use to get Blip.TV content working?

I don't think that was quite the issue being discussed here, but here's a great link in which the Blip.tv folks explain what their technical requirements/suggestions are for formatting,etc.

http://blip.tv/learning/export/

Otherwise, perhaps you can use Blip.tv's forums/help features to get the info you need.