My question is very simple and I think there are a lot of way to do it but I'm not a specialist. I don't need to prevent people from downloading my flvs, I don't have bandwidth problems.
I have a flv video gallery displaying an embed code like this :
I want other sites to display my videos in my flvplayer.swf but I am afraid some people will add the file http://www.mysite.com/video.flv directly in their flv player (with their watermarks, ads, recommandations etc.)
What should I do to prevent this ? Don't need a lot of details but some suggestions would be welcome !
if you dont have bandwidth problems, it doesnt really seem worthwhile - even if you encrypt the address, its just a matter of checking in the browser cache to see the true address, else you will have to go for the full serverside implementation with rtmp streaming and access limiting etc. etc...
I'd like an answer to this too. It would be cool if the flv url wasn't super obvious. I thought of hardcoding the path into the swfobject.js but javascript confuses me. Any info would be appreciated!
Why is it when someone wants to hide a url or a piece of code, the almost-immediate response from most people is "it's not worth it".
I for one believe it is.
Most people aren't going to lift your videos, nor will they take the time.
Making something just a little difficult for people to figure out will keep those who just want to lift your videos for kicks from doing it, and will have others who are really interested in your code a little smarter in the end.
But it's not a yes or no situation. There is a great benefit to making your code hard to find.
Naija Boy... EXCELLENT idea.
Are you from Nigeria, or an international Superman dancer? =D
There's nothing to be gained from preventing downloading of a file when it's already sitting in the client browser's cache. Almost everybody knows how to find it there.
The real value is in preventing hotlinking which generates a lot of traffic with no revenue to pay for that traffic.
Look at the ongoing battle in the MEGAVIDEO threads...
I'm running in circles about the same prob. The Idea is to call a php script, that' generating the streampath (and stream itself), instead of the video-stream directly by the player. But I didn't get it working yet, the "streamscript" (or streamer?) variable seems to be a hint, but I wonder if it's working without the "file" variable, where the streampath, thats to hide, usually is readable?
I searching for days now, but I didn'f find any example for a HTTP streaming (or better a RTMP streaming), some kind of stream relay station.
the streaming data lay on an external server elsewhere, so the flashvar file should contain the hole path? the player (jw 4.0.46) returns an error, when flv fils couldn't be found, even before the XMoov-PHP script could be done.
an external streaming script (XMoov-PHP script) can only handle http streams? not rtmp streams? or does this simply depend on the apaches/webserver configuration?
Your HTML page with the player is on Server-A. You also have a stream script on Server-A. The media file is on Server-B.
The client (user) computer makes a request for a media file to the stream script on Server-A. The stream script on Server-A makes a request for the media file to Server-B.
Server-B sends the media file to Server-A which sends the media file to the client.
You can seek in the remote media file with HTTP byte ranges.
Doubles the traffic to your site (once in, once out).
Doesn't work very well for scrubbing on Windows because of a limit on the number of socket connections that an application can have open and because of a delay before socket connections are dropped and new ones can be opened. I have a working script for external file access, but you have to wait about 24 seconds between scrubs for the old socket connection to be dropped before you can make another request - I can't find a way around that.
Better to just put the stream script on Server-B, if you can.
Second question:
The XMoov-PHP script is for HTTP "fake" streaming only.
RTMP is a completely different protocol than HTTP. To "true" stream using the RTMP protocol, you need an RTMP server like Red5 (free, open-source) or FMS or Wowza (both have developer versions that allow 10 users).
@kLink first answer: you assumed absolutly right! In addition: Server-B just accepts RTMP prot. I tried to make the streaming script to a kind of relais station, that simply should pass through the stream (after creating the path to the stream source on Server-B), but didn't get it working: (<?php) a simpe header command seems not to be enought (what header content informations are set by jw player for RTMP?), and any f** commands can't handle the RTMP protocol. Is your script for external file access able, to handle RTMP prot.? While the delay's a real prob I didn't think of, even if it running on a linux server..
Your solution, to put the streaming script to Server-B, doesn't work, it depends on the database on Server-A.
In theory, the relay on Server-A could be a RTMP server like Red5. It is capable of receiving and sending an RTMP stream. I've never done this, so I don't know how hard (or how) it is to setup.
I think artAGE wants to stream a media file that resides on Server-B, but he can't put a stream script on Server-B, so he has to do an external file access and use HTTP Range requests from Server-A to Server-B to be able to stream the file from Server-A to the client.
artAGE cold also make a request to the database on Server-A to get the media file name, then request that file from Server-B, but Server-B would have to have a stream script or an RTMP server to actually stream the media file directly to the client.
@kLink: but Server-B would have to have a stream script or an RTMP server to actually stream the media file directly to the client.
Wouldn't this lead to security problems at the client? It would recieve the requests answer from an other domain, than the request has been sent to? The sandbox problem?
There is no security problem if you load an HTML page with the player from Server-A and a data file (playlist or captions) from Server-A and the media files from Server-B. Or, you can load the playlist from Server-B if server-B has a cross-domain policy file allowing access. The media files from Server-B can be served directly by HTTP progressive download, by a stream script, or by an RTMP server. I have done it many times, so I'm sure that it works.
I'm surprised, but well, I believe you, even if the easyer way, passing through the stream from Server-B over the the streaming script on Server-A to the client, I want to try first. Any ideas where I can find the headers, send by the player on doing a RTMP request?
You can use a packet sniffer like WireShark to see the RTMP conversation.
RTMP (Real Time Messaging Protocol) is different from HTTP in that it establishes a two-way control conversation between the client and the server and they continue talking to each other throughout the streaming of the media file. The media file packets being sent from the server to the client are "seperate" from the control conversation.
Do you need the external file access stream script?
This should work, but I made some changes based on another streaming script that I'm working on, and I haven't had the time to test it. However, I'm actively using and developing this script, so if there are problems, I'll help you get it working. bc.. <?php
@kLink Thanks a lot for the script, but unfortunately we talked at cross purposes.
As I mentiond above, Server-B only accepts RTMP prot. that's why I "simply" want to pass throught the stream. Sadly, fsockopen cannot handle RTMP.
My idea is to use header("location: ".$streampath); but therefore I need the headers and get vars, created by the player, when it request a RTMP stream. Another unlucky solution (in calling the streamer), is that the streampath has to be given in flashvar::file too, as plaintext.. Hopefully, it'll be enought for the player, to call the passthrought script on the flashvar::file..
It would be difficult to write a script that did a relay of the RTMP stream. You could do that with the Red5 RTMP server running on Server-A.
You can't do a simple redirect header("location: ".$streampath); because RTMP is a continuous, two-way conversation between the server and the client. (Well, maybe you can, I'd have to test it to be sure.)
@kLink well the first attempts were in vain :-( The basic question is: Is the bi-directional conversation between client and server, done in one existing connection, or will every request / reply be done in its own, new built connection? Also it would be highly interesting, how the request is looking (headers and GETvars)
Thanks for your tipps, but meanwhile I'm about giving up: The first request, that creates the connection, is simply a TCP request, while Wireshark even don't tell me the port (or I didn't find it), and simulating this request, seems to be very hard.
Copying the headrs might not be enought: bc.. <?php $hdrs = getallheaders(); foreach($hdrs as $K => $V) header($K.": ".$V);
I'll keep on trying, but it seems, as if another solution is inevitable.
What you really need is a 302 Redirect built into the RTMP protocol.
Or a proxy server (setup to redirect) that can handle the RTMP protocol. See this article: *http://kb.adobe.com/selfservice/viewContent.do?externalId=1ccfec30&sliceId=2*
I think I have a configuration along the lines of what you are striving to create. My web sites are hosted on the east coast but I have a wowza media server here on my LAN to stream content. The approach I am using simply involved embedding the RTPM streamer address directly into JW's player.as file. In fact I've embedded most everything I use by default in the same manner. That way the standar code I use to instantiate the player doesn't require much information. Here's a snippet.
autostart:true, bufferlength:0.1, displayclick:'play', item:0, mute:false, quality:true, repeat:'none', shuffle:false, state:'IDLE', stretching:'exactfit', volume:80, abouttext:'modified 4.1 Rev 60 player', aboutlink:'http://www.jeroenwijering.com/?item=JW_FLV_Media_Player', client:undefined, id:undefined, linktarget:'_self', margins:'0,0,0,0', plugins:undefined, streamer:'rtmp://MYDOMAIN.COM/fastplay/', <--- actually I use my IP to avoid DNS lookup token:undefined, tracecall:undefined, version:'4.1.60'
This is all I need to put into my html code. It's generic so that I can use the same web page to play any file. I just add the file name to the URL as a parameter
<script language="JavaScript" type="text/javascript"> getQueryParamValue('id') var so = new SWFObject('player.swf','mpl','822','548','9.0.115'); so.addParam('allowscriptaccess','always'); so.addParam('allowfullscreen','true'); so.addParam('wmode','opaque'); so.addVariable('file', getQueryParamValue('id')); so.write('x'); </script>
Maybe not elegant but functional. Thinking about adding another layer of security via wowza securetoken. They have all of the code on their forum to make it very simple to add it.
@kLink, you're right about a slight delay when scrubbing but it's acceptable to me for now. My stuff is almost just for friends and family these days. Just videomail for the most part.
Actually that 1st code snippet is just from my modified version of JW's original PLAYER.AS file. I only modify those items of functional interest to me as I don't want any unintended consequences should I remove elements many of the other scripts require. The items you mention fall into that catagory. If memory serves I hard coded 11 items to avoid having to place them in my javascript.
Perhaps I can get some feedback from you on a small issue. I use identical encoding values on my FLV and MOV yet when I scrub in an FLV there is virtually no delay. Do you have an idea what it is about MOV's that cause it? More metadate etc?
I don't know much about the MOV container. Maybe it has the HUGE metadata like MP4 does.
People complain about the FLV container, but it was designed to deliver crappy video at high speed and it does that quite well. MP4 encoded with H.264 is better now, but still has the MOOV atom problem.
I'm guessing you're right about the H264 content. I use a cheap solution to create it. Quicktime Pro really works well though. I did follow Charlies updated instructions on wowza's forum for getting secure token working with version 1.5.3 and it worked out great
I Had the same issue. Hotlinking is what I was trying to avoid.
Here is what I did:
In the Controller.as file about the 73rd line down (assuming you haven't edited the file already) You'll find the following block of code.
if(config['file']) { playlister.load(config); }
*slightly edit it to follow the below example. * if(config['file']) { *config['file'] = 'http://www.website.com/path/' + config['file'];* playlister.load(config); }
*Now when you supply your flashvars, you only need to supply the actual name of the file. see example below.*
var s1 = new SWFObject("SingeFilePlayer.swf","mediaplayer","360","240","8"); s1.addVariable("width","360"); s1.addVariable("height","240"); s1.addVariable("file","*flashvideo.flv*"); s1.addVariable("autostart","true"); s1.addVariable("volume","30");
Hypothetically this would stop hotlinking? Some one please correct me if I'm wrong.
Also of use if you are using a streaming server rather than progressive download is to set the server up to reject connections from any domains you haven't explicitly coded into the servers configuration.
hi, There is no way of hiding the url.. well u can mask it.. but it can be revealed to lechers. I'm in this biz from some time, running a 300 Megs per sec. So what you want is to be able to protect your flvs against unauthorized download. I did this about 2 years ago using this players and about 9 years ago for a streamming company. At that time there were no integrated solutions so I will explain u what u need to know. Now there are 2 different implementations, one against leechers leaving a download option intact (simple) and one against download. Against leechers you need to generate a token once and use that one on the request. that token has to be unique on your site and has to expire after some time. The idea is simple, when request is done you check the token.
an easy way to make a token is md5
$token=md5 ("mypassword".date("mdY"));
this will expire after one day ;)
New player can use this however older cannot so I had overcome it by using a clever done htaccess..
to translate flvdir/file.flv?token=ggggggg to flvdir/gggg/file.flv
so on the streamming server u have to check this.
Against download you need a pay as u go implementation, that means once user got some of the movie then more is requested and so on and token has to be changed all the time.
i'm trying to make working the getQueryParamValue('id') but with no luck
if i put in adress http://somedomain.com/flash/test.html?id=movietest nothing is happening, i have to put mp4 in url and the flashvars don't work
<script language="JavaScript" type="text/javascript"> getQueryParamValue('id') var so = new SWFObject('test3/player.swf','mpl','822','548','9'); so.addParam('allowscriptaccess','always'); so.addParam('allowfullscreen','true'); so.addVariable('file', getQueryParamValue('id')); so.addParam('flashvars','&plugins=accessibility&captions=test3/caption.xml'); when i add this line the player freeze so.write('player'); </script> </html> I make same modifications like Jimb. but with no luck. I use player version 4.2 Somebody can help me please? Thnx
What, if any, error message is showing? Without details, it's impossible to help you.
If the file on your server doesn't have an extension, then you can use:bc.. http://somedomain.com/flash/test.html?id=movietest
and then use the *type* flashvar to tell the player what type of media file it will be receiving:bc.. <html> <head> <script type="text/javascript" src="test3/swfobject.js"></script>
</head>
<div id="player" class="player"> <a href="http://www.adobe.com/shockwave/download/download.cgi?P1_Prod_Version=ShockwaveFlash">Get the Adobe Flash Player to see this video.</a> </div>
<script language="JavaScript" type="text/javascript"> var so = new SWFObject('test3/player.swf', 'mpl', '822', '548', '9.0.124'); so.addParam('allowscriptaccess', 'always'); so.addParam('allowfullscreen', 'true'); so.addVariable('file', swfobject.getQueryParamValue('id')); so.addVariable('type', 'video'); so.addVariable('plugins', 'accessibility'); so.addVariable('captions', 'test3/caption.xml'); so.write('player'); </script>
</html>
Use a more informative alternate content message.
You may also need to add some path information for the media file. If it's an FLV, the path is relative to the movie, if it's any other media type, the path is relative to the HTML page that has the Flash Player embedded in it:bc.. so.addVariable('file', 'test3/' + swfobject.getQueryParamValue('id'));
Check the Internet accessibility of each file:bc.. http://my.domain.com/test3/swfobject.js http://my.domain.com/test3/player.swf http://my.domain.com/test3/movietest
when i put so.addVariable('file', swfobject.getQueryParamValue('id')); the player is not loading, in internet explorer i have the error: 'swfobject" is undefined if i put : so.addVariable('file', getQueryParamValue('id')); is ok
http://my.domain.com/test3/swfobject.js http://my.domain.com/test3/player.swf both are loading succesfully i copy/paste your code for the html
the web server and the stream server are on diferent computers. i edited player.as to point to rtmpe://somedomain/stream
and about the file without extension, i have all my files *.mp4. but i want the link to not explicit the extension of the file. with http://somedomain.com/flash/test.html?id=movietest the player is trying to load but never finish with the .mp4 extension added is working. i hope u understand me. thnx again
i believe i have to return to 4.1.6 version, because of the accessibility bug staying on top of the control bar. The code u suggested is the same? thnx
I have been reading about the security problems on several forums and it seems to me that the best solution is to put credits and a logo watermark directly in the video during post production. That way, everybody can steal to their hearts content, because there is no way you can remove the info in your video without re-sampling the video and I think most hackers are too lazy to bother with real work.
All other options seem to be like putting a plastic padlock on your door with a lot of effort.
So, I do understand when some folks say that it isn't worth it, because most hackers have more free time then you have. And you can bet that everytime someone finds a solution, some bum will want to crack it.
Yet, I do like the solution to hide the path from the source code, because that will indeed keep some people away from leeching and it is not a great effort. Thanks Naija Boy!
I guess you can always send your video files through a script which checks that the http referer is your own site. If they know how to fake the referer they most likely also have the knowledge to get hold of your videos anyway.
Still, is it worth it? The solution is to be the best provider of your own content. That way the users comes to you.
