google-code-export / flowplayer-core

Automatically exported from code.google.com/p/flowplayer-core
2 stars 0 forks source link

Viralvideos and Sharing videos propating themselves very problematic #265

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
1. propagation onto social networks will not work - demos sent to Anssi and 
Tero.
2. Email with cgi-script will not work on other servers - should at least be 
set back to default without cgi script.
3. Embed:
   a. Generated code is broken
   b. When using config file with same config as a. (assuming a. has been fixed) the sharing functionality is useless, as almost certainly the page where the video is embedded will not have the necessary meta attributes, furthermore 1., 2., and 3.a. apply.

Demo of intial setup:
http://flowplayer.blacktrash.org/fbviral-default.html

Demo for 3.a. embedded from inital setup and 3.b.:
http://flowplayer.blacktrash.org/viralembed.html

Original issue reported on code.google.com by blacktrashproduct on 11 May 2011 at 1:41

GoogleCodeExporter commented 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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
> 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

GoogleCodeExporter commented 9 years ago
Whitelisting is not necessary anymore - since sometime in March.

Original comment by blacktrashproduct on 18 Jun 2011 at 8:04

GoogleCodeExporter commented 9 years ago
As of r686 ALL issues seem to be fixed! Great job.

Original comment by blacktrashproduct on 19 Jun 2011 at 12:12

GoogleCodeExporter commented 9 years ago
is this considered fixed ? 

Original comment by electrot...@gmail.com on 29 Jun 2011 at 3:58

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago
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

GoogleCodeExporter commented 9 years ago

Original comment by dani...@electroteque.org on 29 Nov 2011 at 9:37