Closed GoogleCodeExporter closed 9 years ago
Another example for useless embed code using the viral plugin:
http://anssipiirainen.posterous.com/embedding-with-an-external-config-file
referenced from
http://flowplayer.org/demos/plugins/flash/viralvideos-extconfig.html
Using this external config file:
http://dev.flowplayer.org/demos/plugins/flash/config-embed.js
Nevermind that the 1st clip in the playlist does not exist, clicking on the
share buttons does nothing - even if it would make sense. Sharing from an
object-embedded player does not work.
Original comment by blacktrashproduct
on 16 May 2011 at 12:53
Hi there , i made this a while ago but was never committed. I realised that
some sites need the metadata tags to generate the embed correctly like FB. The
only way to do this is via javascript I think.
http://code.google.com/p/flowplayer-plugins/source/browse/flash/viralvideos/trun
k/src/javascript/flowplayer.viralvideos.js
example setup is this where viral is the name of the plugin, can't think of an
easier way to gain access to it.
.viralvideos({ pluginName: "viral"});
let me know if its working.
Original comment by electrot...@gmail.com
on 16 May 2011 at 3:42
I more than strongly doubt that Facebook (or any other network) will deal with
a client-side script, in other words I doubt it would pass here:
http://developers.facebook.com/tools/lint/
(apart from the fact that everyone moves to opengraph protocols)
imho, the meta attributes must be static, think permalink, so they can be
crawled by Facebook.
Unless we offer a complete service like addthis
http://www.addthis.com/help/widget-sharing
the user must create pages for each video with the necessary meta properties.
And even addthis discourages using their API for this, if you read the page
carefully. And for a reason, because when you share via their API, the shared
link displays the video, but points back to their API instead of the
originating page.
This also does not solve the issue here, the self-propagation of the sharing
plugin(s). But of course it points again to the fundamental problem that we
advertise something as being able to be handled by the client side (Flash,
JavaScript) which imho can only be done on the server side (static html).
In short: have you tested it? ;-)
Original comment by blacktrashproduct
on 16 May 2011 at 6:56
Yes it generates the header files to be used when posting, the system you
suggested also uses javascript and can only be carried over once so I dont see
the difference. If there is any tags missing from the code let me know.
Original comment by electrot...@gmail.com
on 17 May 2011 at 4:26
Maybe stuff has changed yet again it used to be those tags, maybe its this ?
<meta property="og:title" content="AddThis Tour" />
<meta property="og:description" content="Watch the AddThis Tour video." />
<meta property="og:image" content="http://i2.ytimg.com/vi/1F7DKyFt5pY/default.jpg" />
<meta property="og:video" content="http://www.youtube.com/v/1F7DKyFt5pY&fs=1" />
<meta property="og:video:width" content="560" />
<meta property="og:video:height" content="340" />
<meta property="og:video:type" content="application/x-shockwave-flash" />
Original comment by electrot...@gmail.com
on 17 May 2011 at 4:33
http://dl.dropbox.com/u/3394987/flowplayer.viralvideos-3.2.6.zip
http://code.google.com/p/flowplayer-plugins/source/browse/flash/viralvideos/trun
k/src/javascript/flowplayer.viralvideos.js
Please try a combination of these. The external methods were removed so ive
fixed all that up. It adds the required headers via jquery before the video
begins.
Original comment by electrot...@gmail.com
on 17 May 2011 at 6:56
I know about the opengraph attributes, that's not the problem (at the moment
both version still work).
"before the video begins": that imho proves the misunderstanding. Facebook will
parse the headers INDEPENDENTLY of whether a video runs or even whether there
is a video on the page, a client side script will not help.
Perhaps this scenario makes it clearer: once you share a link on a social
network, the network offers a link to propagate it further; when you click on
that the meta properties must be parsed even though you are not visiting the
shared link.
Oh, well, will try it at some point. But please read my tutorial at
http://www.facebook.com/flowplayer?sk=app_7146470109
Apart from some outdated details, the CONCEPT still holds true, I bet on it:
the problem cannot be solved client-side only because the network does not
parse the meta properties with a browser.
Original comment by blacktrashproduct
on 17 May 2011 at 8:44
ok so it needs a live page to parse the header tags. onLoad is not working
because the remote methods cannot get access to certain things because the
events are out of order. It needs to load the player first so the config can be
cleaned up for sharing. The plugin should worked but getting the config and
flowplayer url without loading the player seems to obviously be a problem. So
if the player uses a splash screen and needs to be clicked none of this is
going to work either :)
Original comment by electrot...@gmail.com
on 17 May 2011 at 8:53
It needs a static permalink - even queries and redirections won't work. Just
dumb robots parse it, and asynchronously from viewing it with a browser.
JavaScript won't help.
But I have an idea: offer a script which you run on the page locally before
uploading - or, in case you have access, on the server - which adds/updates the
meta properties according to the configured shareUrl/pageUrl parameters to all
the referenced pages (node.js seems a good tool). Once the pages have been
processed, the user can upload them. That's the only way I see to spare the
user at least some of the manual processing.
Original comment by blacktrashproduct
on 17 May 2011 at 10:30
I'll run more tests so only pretty url permalinks work ? so a query to the swf
won't work ?
Original comment by electrot...@gmail.com
on 17 May 2011 at 11:26
Indeed. Not the Flash object is shared, i.e. not the content of og:video or
video_src, not the flashvars, but just the link to a page - errmh, therefore
the name pageUrl ;-) just http://example.com/video.html. The social network
then decides how it processes the link. In case of Facebook and MySpace for
example, they will also look at the meta attributes of the page. But THEY
decide, not us. They decide whether they will embed a Flash object according to
the meta properties on the page. WE only share the URL.
Original comment by blacktrashproduct
on 17 May 2011 at 11:39
Hi there on research the open graph code cannot be run via javascript, it
requires to be done via the backend on startup. Here is more information
http://stackoverflow.com/questions/5248327/how-to-append-html-to-head-with-jquer
y
Sites to parse the open graph data
http://www.opengraph.in/
http://ogit.heroku.com/
http://ogp.me/
I could take the time to build some kind of php library to add information to
the html header but it looks like it up to the end user to do it, no javascript
plugin will work as it wont run javascript when parsing the page. The best we
could do is provide information on how to do it perhaps ?
Original comment by electrot...@gmail.com
on 20 May 2011 at 1:26
This might also be required
http://www.addthis.com/help/facebook-images#whitelist
How exactly do add this work, is it an api to interface with social networking
sites and creates the page tags via the query params perhaps , would that work
? If so a php web service example could be created perhaps.
Original comment by electrot...@gmail.com
on 20 May 2011 at 1:39
No, Facebook obsoleted whitelisting recently. The requirements listed in the
Facebook demo were continuously updated with the ever-shifting Facebook api.
I am refactoring the Facebook demo (although most of it still holds true,
except for the fbml stuff which is deprecated or unsupported by now) in an
iframe app with the sharing/viralvideos plugins in action, but have a long and
hard time wording around the imho buggy behaviour of sharing/viralvideos
without sounding negative ;-) Warnings about sharing plugins themselves etc.
Once we have the Facebook demo there, we can consider taking over some of the
stuff in the Flowplayer site. I will also talk with Lakshmi if we can find a
way to add the headers on the Flowplayer site at the respective plugin and demo
pages. Until then we can refer users to the Facbook demo.
Even with a php lib there's still a lot of responsability for the user:
consider the case when there is more than 1 video on the page. Each video needs
a "permalink" page with the necessary headers to be shared etc.
Original comment by blacktrashproduct
on 20 May 2011 at 3:09
How would it be possible with multiple videos ? Is it possible with an
interfacing script that is used to build a page with the required headers given
by information in a query string ? Is that how add this works ? You are right
modifying headers of the current page would only work for one video. Painful.
Original comment by electrot...@gmail.com
on 20 May 2011 at 4:00
addthis themselves discourage using the method without meta properties. I can
only speculate how this works by deducting from the symptoms: when you do share
via their service the "written" link points to their sharing service (not nice
btw. if I share something on FB, I want the visible link also to point visibly
to my site). I guess this service is some kind of centralized "database" which
gives facebook the right answers to their queries ... or they have a special
deal with facebook, like YouTube must have: YouTube videos also play when you
use Facebook in "Secure Browsing" mode, i.e. https, whereas "normally" shared
videos become just links in that mode. I filed a bug at FB, but they did not
react.
But may I propose to take this 1 step at a time:
1) make clear decisions what belongs in a shared configuration - until Anssi or
whoever convinces me otherwise, I maintain that SHARED videos may not include
viral or sharing plugin configuration. A shared video on FB with viral or
sharing config enabled throws an error and does not play.
2) Similarly for email, especially when a cgi-script is configured.
3) Sort out the embed code which is generated when no configUrl is given
(these are bugs imho, and should have priority, see 1st post of this issue)
Meanwhile I will polish the demo on FB, and once the bugs are ironed out, we
can think of a possible automation of the meta property creation. It might not
be worth the trouble, because up to now apparently a lot of users do not
actually care what the sharing functionality does. Still it would be good to
have WORKING sample to point to. Which I am providing already, bonus points
when we can migrate some of this stuff to flowplayer.org.
Original comment by blacktrashproduct
on 20 May 2011 at 5:39
Hi im busy with redoing the hd button plugin. trying to consume all this still.
I will try and test out your urls, im guessing these are the examples you are
talking about. im assuming cgi-script you mean an email backend.
Taking out the viral video plugin config when sharing is easy enough, as its
already formatting the config to place into the embed code.
I will keep look at how add this works, and see if an interfacing api may help,
if there is a way for facebook to load the dynamic generated headers from an
interfacing script but share the original url this may work.
If players have to be configured anyway by a backend I can't see how its hard
to also place the configuration in generated tags in a page template. Multiple
videos on the same page I will test how they deal with this also. I can't see
how the system would work for multiple videos anyway ie youtube only has one
video on the page, and its headers are pre-generated by their backend.
Original comment by electrot...@gmail.com
on 21 May 2011 at 12:29
I did some tweaks to the viral videos plugin to make this work. Works slightly
better now.
Original comment by anssip@gmail.com
on 30 May 2011 at 10:57
With http://flowplayer-releases.s3.amazonaws.com/latest.zip the player
initialization error is back again. anssi, you can check the shared video in
our facebook correspondence.
Original comment by blacktrashproduct
on 14 Jun 2011 at 10:02
Demos for this issue and issue290 are here:
current:
http://flowplayer.blacktrash.org/test/fbviral.html
for resulting embed code:
http://flowplayer.blacktrash.org/test/viralembed.html
devel:
http://flowplayer.blacktrash.org/dev/fbviral.html
for resulting embed code:
http://flowplayer.blacktrash.org/dev/viralembed.html
Original comment by blacktrashproduct
on 18 Jun 2011 at 9:52
For the devel version there is now an additional issue: Once you clicked and
closed one of the buttons, clicking on another one has no effect.
Original comment by blacktrashproduct
on 18 Jun 2011 at 10:01
And! after closing a viral dialogue, the bitrateselect fields do not work
anymore either.
Original comment by blacktrashproduct
on 18 Jun 2011 at 11:23
> Facebook obsoleted whitelisting recently.
Do you mean that sharing videos so that they would play on Facebook pages
doesn't require whitelisting domains on which the videos are located? My
project partner is under impression that whitelisting is necessary.
Original comment by roman...@gmail.com
on 18 Jun 2011 at 6:27
Whitelisting is not necessary anymore - since sometime in March.
Original comment by blacktrashproduct
on 18 Jun 2011 at 8:04
As of r686 ALL issues seem to be fixed! Great job.
Original comment by blacktrashproduct
on 19 Jun 2011 at 12:12
is this considered fixed ?
Original comment by electrot...@gmail.com
on 29 Jun 2011 at 3:58
With http://flowplayer-releases.s3.amazonaws.com/info/dist.html as of June
19th, and from my perspective, yes.
Original comment by blacktrashproduct
on 29 Jun 2011 at 4:34
what is the solution now obviously the headers cannot be manipulated with
javascript.
Original comment by electrot...@gmail.com
on 8 Jul 2011 at 4:27
User is responsible for headers.
pageUrl defaults to current page and is always propagated for embed.
User can still shoot himself in the foot if the config for og:video or
video_src does not make sense, but as far as I can see at least there are no
_errors_ anymore when a player is shared. Depending on the social network not
all functionality might be available, but the player does not error out.
Original comment by blacktrashproduct
on 8 Jul 2011 at 5:23
Closing this, i might provide a zend framework demo of the header stuff perhaps
used in conjunction with this library i built
http://framework.electroteque.org/.
Original comment by electrot...@gmail.com
on 8 Jul 2011 at 5:44
Unfortunately this issue raises its head again at the new site:
http://flowplayer.github.com/demos/plugins/flash/viralvideos-colored.html
The problem configuration ist here:
http://flowplayer.github.com/demos/standalone/plugins/flash/viral_videos_colored
.js
And the shared object:
http://flowplayer.github.com/swf/flowplayer.swf?config=http%3A%2F%2Fflowplayer.g
ithub.com%2Fdemos%2Fstandalone%2Fplugins%2Fflash%2Fviral_videos_colored.js
yields Error #1010.
Original comment by blacktrashproduct
on 13 Nov 2011 at 1:47
Note that this is not strictly related to sharing (i.e. on the social network),
it is triggered just by loading
http://flowplayer.github.com/demos/standalone/plugins/flash/viral_videos_colored
.js
as external config file.
However that config file looks valid to me.
Original comment by blacktrashproduct
on 14 Nov 2011 at 10:37
I will create a new ticket for this, please don't open old tickets if possible.
Original comment by dani...@electroteque.org
on 29 Nov 2011 at 9:33
Original comment by dani...@electroteque.org
on 29 Nov 2011 at 9:37
Original issue reported on code.google.com by
blacktrashproduct
on 11 May 2011 at 1:41