I can't have the customer download the whole video because the file is ridiculously large. I can create a video that easily plays on a webpage (basic htm file), but then the customer only downloads the htm file and can't see the embedded video - since it has not been downloaded.  

Plus, I appreciate the hidden URL feature and expiring download link.

Any ideas out there on how to work this great Product Cart element into a video provider?

I'm not sure I'm following what you are ultimately requesting here. 

Are you wanting customers to be able to download video files, or are you wanting them to download a web page file that has the video embedded?

We've a client using PC to provide video content via Amazon's CDN service, but I'm not sure what you're wanting is the same as what they are doing.

If you could flesh out your request a bit more, that would be helpful.

Ultimately I want a customer to be able to purchase an instructional video through Product Cart. I would like them to receive a link to the video just as they do when they purchase a pdf file from me. 

If I have them download the video file, it's too cumbersome.  They need to be able to watch it through their computer.

I would like the location (URL) of that file to be hidden.  And I would like the link to expire in a designated amount of time.

I am capable of creating a page that features a video (one for free, for example) that is easy to watch, that loads up quickly etc on a regular webpage (using a flv file format).

So, my problem is how can I configure my video into a file that Product Cart can handle, OR how can I modify PC for making this purchase possible.

I'm thinking what I would probably do here is the make the actual download a simple .htm file. That file would include an iframe which would pull a custom .asp file from the site. That file would authenticate login, if customer is not currently logged in and still has access to the deliverable, else load the movie. This would protect the location of the .swf (see a proto-mockup here: http://www.wmsmerchantservices.com/zTest-hideFLASH.asp" rel="nofollow - http://www.wmsmerchantservices.com/zTest-hideFLASH.asp  -- no way to discover where the movie is actually sourced).

Aside from some custom scripted for the above, the bit that would need to be added to PC is a second file location for these downloadables. If the movies are all the same width/height, then this could just be the path to the .swf; else it could be a file or script in which you do the embed.

Does this sound like something that would work for you?

PM me with your phone number if you'd like to discuss.

I'm not seeing how vzaar would solve Pam's concern here vis a vis the downloadable product features of ProductCart.

Could you enlighten us how this would be a solution for her request?

Thanks for the illumination. I totally see where you're coming from, and it's definitely a viable option for someone working with this feature offering in PC -- the main difference being the option to:

I'll be discussing this with  Pam @ManaBeads tomorrow. I'll make sure she's seen this as an option.

As I understand it, ManaBeads:

PS: RE "However, the customer could just as easily download the video and host it themselves if they really wanted to, regardless of any security measures."

I think this could be an interesting and easy enhancement to PC.

ProductCart is loaded with options -- some times the array of possible options is overwhelming (after years of intense use and modifying things, I still stumble around with some features!).

You input here is definitely valuable for some folks in the way they'll want to use it. As I mentioned early on in this thread, we've a client using Amazon's CDN service which is in the most basic ways similar to the vzaar solution you've suggested.

I checked out vzaar and it is very much what I'm interested in except it's a bit more than I need right now. If my video library grows and need better management it would be something I'd do.  It's nice to see that it can be worked into PC if needed. 

My security issues are medium. People purchase my pdfs and they can give them to friends - I realize that. It would just be nice to have the videos a little better protected.

I see the need for providing a downloadable UI that protects the source location while allowing the media to be provided from any source ... all while using PC's built-in protections.

I've built an interface that is multi-layered such that there is no way to find the ultimate media source file no matter where it is coming from. All PC protections apply. No need to touch a single line of PC source code. Rather, just a snippet of WMS code (two lines) at the top of the HTTP path you define, and you're golden.

You can test drive it here (and please let me know if you can find any way to hack your way to the content source file -- I'll owe a pound of coffee beans or a sixer of craft beer if you can -- your choice, as I live in the land of coffee and craft beer!):
http://pc46a-wms-net.3060.wmsmerchantservices.com/store/pc/Digital-Download-Product-3-6p61.htm" rel="nofollow - http://pc46a-wms-net.3060.wmsmerchantservices.com/store/pc/Digital-Download-Product-3-6p61.htm

For your payment method, use the "Just Testing" option.

You'll know be logged in and your options are standard PC.

Try to copy any URL you can find in this mix, and you won't get access (offer above applies X 2). There is no way to get to the "downloadable"/online access video or whatever media file without running through PC's authentication first ... and then there is just NO way to share it short of customer A providing all of their access to friend B (pretty hard to protect against that level of cheating unless you can protect your content with keys)

Best off all, not a line of PC code to change, and no database update needed.

However, I did find that I could drill through it with FireFox's view source (as the links to src's in FF behave just as if you were in the visual side of the browser), so I had to add a human interaction with a form post (a "play" button with a copyright notice).

Now I'm pretty darned sure there's no way to ferret out where the media is coming from.

I think I'm now ready to package it up as a plug-in.

This project was an interesting study in the way various browsers execute "view source".

I tend to work in Chrome and then go check things out in other browsers. Chrome's view source executes a page exactly as if you had just called for that page in the visual side -- it loads a page as if you hadn't already loaded it on the visual side. That much I've always known, and that's very useful for debugging. 

IE, Opera and Safari are very literal. That is, their view source is exactly what you just loaded in your visual side as if that page load were static markup.

FireFox, however, is another animal: it's view source loads exactly as if you were on the visual/user interface side ... and provides links to src's and loads them when clicked exactly as if one were on the visual/UI side. 

So, FireFox's view source provided an easy drill down through all of the server-side protections I buttressed this with. Given that, I found that the only way to stop that was to introduce a human interaction -- a form post using the "post" method.

I think that nailed it and makes it impossible to discover the actual source location of the media. 

I've love any feedback from anyone who can get past it as it is now.

Other layers of protection could be added, but I don't think are necessary and would make it less user-simple for merchants. For example, Mana Beads uses a JavaScript-based player to play their .flv videos. Using a JavaScript obfuscation would make it that much more challenging to crack ... but I expect that anyone who could find a way through this current milieu could probably de-obfuscate the JS pretty easily -- so why bother?