On 12/14/06, Alex Thurlow <[EMAIL PROTECTED]> wrote: > Bob Ippolito wrote: > > On 12/14/06, Alex Thurlow <[EMAIL PROTECTED]> wrote: > > > >> I'm not sure if this is the right place to ask, but I thought some > >> people here might have some knowledge on the subject and could at least > >> tell me if it was possible. > >> > >> I am a web publisher who does VOD music videos. Because of label > >> agreements, I can't let people download the videos, just stream them. I > >> know that by streaming to them, I can't stop them from getting the > >> video, but I need to make it inconvenient. We've traditionally used > >> Windows Media and Real, which are true streaming and make it hard to save. > >> The wave of the future is flash though. We're rolling it out, but > >> unfortunately, Red5 is not quite ready for what we need. We push about > >> 500 simultaneous 700k video streams at any given time, and red5 can't > >> quite keep up yet. > >> So we're just using progressive download with lighttpd right now. > >> The problem is, no matter how we even try to hid the playlist and > >> filename, the file just ends up in the user's browser cache if they know > >> where to look. > >> > > > > You probably should look into using a CDN for the file serving for > > this kind of app. It's a pain in the ass to do it properly yourself... > > > > > We already serve our own content, and we'd like to continue doing so. > It's way cheaper and easier to take care of our own bandwidth deals than > to pay 3-4 times what we should be.
It gets bad if you need high bandwidth and low latency globally, which means multiple data centers scattered around the planet. It's cheaper to pay a CDN than to hire extra operations people to deal with all those different servers. For us, anyway. > >> Basically, the idea I had was to use some sort of stream cipher on > >> the video. I could pre-encode them, and then serve them to the player. > >> Would it be possible, in flash, to have the player run that cipher back > >> over the video before playing? That way, without a lot of work, the > >> videos wouldn't play outside my player. It wouldn't necessarily need to > >> be real encryption either. If some sort of bit-shift or bit-mask would > >> be possible, that would work too. > >> > >> I know it's sort of a dumb problem, but with the legal landscape the way > >> it is these days, I need to try to solve this. > >> > > > > Don't bother; you can't serve anything but plain unencumbered FLV over > > HTTP. I can only make three suggestions: > > > > 1) Expire the HTTP links, so that they can't fetch them more than > > once. They'd need a proxy to save the stream. > > > Right now we're using time-limited urls with mod_sec_download. I just > figure that one time urls are going to break stuff if people refresh the > page and the flash player caches. No they won't, not if the page download generates a new URL. > > 2) Watermark the stream so that it can be tracked back to a particular > > user. The easiest way is with metadata tags, but if you become popular > > enough someone will put together a tool that makes them trivial to > > strip out. You'd then have to find a more clever way to stow that data > > (e.g. use steganography; maybe flipping a few bits on the timestamps > > in a particular way, or hiding data in clever places in the audio or > > video frames). > > 3) Split the files up into a bunch of chunks that are progressively > > fetched at the right time, so then it'd have to be reassembled later. > > This is a real pain and probably isn't worth it; if your service gets > > popular then someone will write a proxy that saves the files and > > splices them back together. > > > Not bad ideas. > > > The browser cache shouldn't be a problem if you're sending the right > > headers, btw. > > > True enough. Currently, you can grab the link with fiddler or ethereal > or the like and just download it anyway though. Not if it's a one time URL. You need to use a proxy to capture it in that case. > > The easiest thing you can do is find a CDN that offers link > > expiration, then you don't have to worry about hosting and you get > > reasonable security. Take a look at CacheFly. I haven't used that part > > of their service (I think they call it ProtectServe), but I've used > > the rest of it. It's reasonably priced and performs as expected. The > > other CDNs are more expensive, don't publish their prices, and don't > > let you Just Sign Up. There are higher caliber CDNs that you should > > look into down the road, but CacheFly is a good start (especially > > considering that the first 30 days are free). > > > > ... and no, I don't work for CacheFly, nor am I getting special > > pricing or bonuses of any kind. I've just used the service and it does > > what it's supposed to do. I just appreciate that they're open about > > their prices and you can sign up without having to talk to a sales > > team. > > > > -bob > > > > ______ > Thanks for the input. After all this, it might even be worth the money > just to get the FMS license, but there really ought to be a good way to > do this. > FMS wouldn't really help you all that much. If the service was popular, someone would write a tool to do it. The stream still comes through the same, the protocol is known, and it still works with proxies so it's easy enough to capture. I'd also be wary about scaling with FMS. You don't have the source so you can't fix it, and I've never seen a large installation. All of Macromedia's server products in the past have really sucked, so I wouldn't expect much from it. -bob _______________________________________________ osflash mailing list [email protected] http://osflash.org/mailman/listinfo/osflash_osflash.org
