0

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!

Lashae
  • 1,372
  • 1
  • 20
  • 36
  • +1, for asking such a good question. This will hopefully help everyone to design more efficient streams – Julius F Dec 09 '09 at 14:12
  • You would normally want to store flat files on the webserver to let it serve them at full speed and let them be properly cached, but then have them encrypted, requiring the client to contact the PHP script for a token to decrypt them. Is it possible to connect a Flash Video object to something that alters the incoming stream (to perform the decryption) instead of passing HTTP through directly? – bobince Dec 09 '09 at 14:53
  • @bobince, passing through http is not very useful due to the fact that FLV players are designed to serve optiomal quality with having low traffic, http has no possibility to send encrypted flv data, or let me say, the client has no possibility to decrypt flv data. – Julius F Dec 09 '09 at 15:02
  • @Lashae, Maintenance: You could code a ACP which handles the chunks etc. it is just about tools. I think that having chunks saved into a database is more performant, tough I actually can not proof this by any benchmark. Having a database is in anyway a good solution in comparison to native files. – Julius F Dec 09 '09 at 15:05
  • @bobince I couldn't grab the reason behind your idea. Yes,I want to allow autheticated users to view the videos,but encryption can't be a way of handling this. Since video-x is enrcypted with hash y; once 'y' is sent to the client, it's no more secret. As I answered @Pasta below, client-side solutions cannot be considered as secure enough. On the other hand realtime decryption on the client machine will require a base hardware on the client which I definitely would'nt to prefer to implement. Moreover, this encryption method doesn't introduce a solution for to measure how much data is sent. – Lashae Dec 09 '09 at 19:23
  • @Lashae: The idea is to chunk the video by billable granule and make the hash obtainable by challenge/response process which can be time- and user-sensitive. Shifting the challenge from the large-file-download process to the small authorisation process allows the large file step to be efficiently served and cached over the existing HTTP infrastructure. Serving the files through PHP and deliberately making them uncacheable (to force authorisation in the download step) means more server load for you and poorer performance for the customer (compared to cacheable sites). – bobince Dec 09 '09 at 23:02
  • Unfortunately (apparently?) Flash doesn't seem to allow a decoding step to be placed between the HTTP stream and the Video player object. So unless someone can think of a workaround you're left to choose between slow-but-authorised downloads and weak fast-but-open-to-anyone-who finds-the-URL auth. As for “once ‘y’ has been sent to the client it's no more secret”: well spotted... and exactly the same applies to ‘video-x’. Once someone has a copy of the end content, you can't stop them doing what they like with them. That's the Copy Protection Problem, and it's historically unsolvable. – bobince Dec 09 '09 at 23:03
  • In fact, I'm not planning to implement a security-level which will also prevent users to grab/copy the content. If the user has an intention to do it, he will achieve it in some way around. He uses a capture program and captures the video, for example. My problem is to authorize requests "ended on my server" and charge for the bandwidth used. Authorization is easier to implement, so if you agree let's move on to the quantification/measuring part. – Lashae Dec 10 '09 at 06:44

3 Answers3

0

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
  • 2,491
  • 5
  • 24
  • 33
  • 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 Dec 09 '09 at 14:03
0

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.

TheHippo
  • 61,720
  • 15
  • 75
  • 100
  • 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 Dec 09 '09 at 15:04
0

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
  • 1,372
  • 1
  • 20
  • 36