views:

58

answers:

4

I'm developing a PHP application which will charge users for the videos they watch. The business model is "everyone pays for how much she watches". For this purpose, I need to;

  1. Implement secure video (FLV) access. (Authorized sessions will gain access)
  2. Calculate how much video (FLV) data is sent from the server.

    A trivial solution for this is to read FLV with PHP ("fread") and send it to client chunk by chunk (just "echo"). However I have real performance concerns about this method, because the application server has 1.7GB Rams and just a single core.

    In short run we're expecting to get large number of impressions, however we would like to upgrade hardware as late as possible. That's why, I want to implement the requirement with the minimum overhead, in the most effective way.

    I'm not tied to a webserver. I prefer Apache 2.2, however lighttpd can also be deployed if it offers a feature for the implementation.

Any idea is appreciated.

Thanks!

A: 

The PHP fread solution looks like the way to go, but with the server restriction, I think you will need to tweak the flash player. The flash player could send the server messages based on how much of the video has been played. This might be something to think about. Take a look at the JW FLV Media player, the customisation and Javascript integration will allow you to send xmlhttprequests to the server.

Pasta
We already considered that way around, however it's not secure enough. It's like client-side form validation. XMLHttpRequest's are clientside trigers and can be avoided easily. For the player side, we're developing our player but only a serverside solution will guarantee transmitted data.
Lashae
A: 

Streaming websites always have the problem of performance leeks. Instead of using "fread()" all the time, you should consider, splitting the videos into pre-sized chunks and put them into MySQL databases as BLOBs.

Another and additional thought is using cache engines:

daemonfire300
Using database as the security backend is reasonable and common for sensitive and binary data, and BLOB type has some flexibilities to offer, I know. However, leaning more on the database means the more memory you consume. And it will require more resource because every query means at least one I/O.On the other hand, storing videos as chunks is not a preferable way to go; since it'll require lots of work after production and in the maintenance. A change in the strategy (chunk-size change etc.) will require lots of efford.Continued on the next comment...
Lashae
Project has already an accelerator requirement, didn't decide which to use but there will be one. However I'm not sure to cache video on the memory, I think will be more expensive than the real-time-processing.By the way, what is the technical fact (I felt there is at least one :) ) that you prefered to use BLOBS versus fread?
Lashae
The one person which down-voted me: Thank you very much, and please leave a comment next time, or I ll have to assume that you are some kind of moron ;)
daemonfire300
A: 

Why not using some videostreaming servers like Red5, I'm sure they have triggers that could perform writing some statistics to a db or something similar.
Another advantage would be that user could skip forward in the video.

Hippo
Absolutely agree, the final destination to go is Red5. However streaming is something we plan to implement in the late 2010.On the other hand, this question is a very common one which a number of people trying to solve in their very own problems. So, I think, speaking around the pseudo-streaming solutions would make sense for others too.
Lashae
A: 

So to sum up and for future reference I decided to go with the php fread method, since no satisfactory alternative is suggested.

Thanks to all contributers.

Lashae