Comments on: Using Drupal to deliver video http://blog.raisedeyebrow.com/2009/12/using-drupal-to-deliver-video/#utm_source=rss&utm_medium=rss&utm_campaign=using-drupal-to-deliver-video What's turning heads at Raised Eyebrow Mon, 05 Jul 2010 17:48:54 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Colin Calnan http://blog.raisedeyebrow.com/2009/12/using-drupal-to-deliver-video/comment-page-1/#comment-2252 Colin Calnan Tue, 22 Dec 2009 22:31:54 +0000 http://blog.raisedeyebrow.com/?p=103#comment-2252 Thanks for the comment Steve, glad you enjoyed the post. Steal away, and if you need more let me know, I'm well versed in the video stuff at this stage. Do you have any idea of preliminary specs at this stage? Thanks for the comment Steve, glad you enjoyed the post. Steal away, and if you need more let me know, I’m well versed in the video stuff at this stage. Do you have any idea of preliminary specs at this stage?

]]> By: Steve http://blog.raisedeyebrow.com/2009/12/using-drupal-to-deliver-video/comment-page-1/#comment-2251 Steve Tue, 22 Dec 2009 22:28:09 +0000 http://blog.raisedeyebrow.com/?p=103#comment-2251 That's a great & useful piece on video you just wrote! tx! I'll likely steal some for the project we're about to start - it looks like I'm about to do my first large-scale drupal-based site in the next 2-3 months. :) One note: There's a minor typo in the Aspect Ratio paragraph: "for the profieration of the widescreen" That’s a great & useful piece on video you just wrote! tx! I’ll likely steal some for the project we’re about to start – it looks like I’m about to do my first large-scale drupal-based site in the next 2-3 months. :)

One note: There’s a minor typo in the Aspect Ratio paragraph: “for the profieration of the widescreen”

]]> By: Colin Calnan http://blog.raisedeyebrow.com/2009/12/using-drupal-to-deliver-video/comment-page-1/#comment-2249 Colin Calnan Tue, 22 Dec 2009 18:48:18 +0000 http://blog.raisedeyebrow.com/?p=103#comment-2249 Wow Jamie, that's an impressive amount of custom work. Could you give an estimate of how long building such a custom system took? As I mentioned in my post, I've tried to find the simplest way to quickly implement video without having to encode on the fly or use any special upload tools. To recap it seems that you: <ul> <li>Created a custom uploader</li> <li>Uploader was hosted on a seperate server and communicated with Drupal via FormAPI</li> <li>Video files are encoded on the fly using FFMPEG?</li> </ul> And future updates: <ul> <li>Opening the system up to public uploads</li> <li>Instant feedback to users on upload status</li> <li>Ability to modify uploads after the fact.</li> </ul> Well done, maybe you could write up the process with some code samples. - Col Wow Jamie, that’s an impressive amount of custom work. Could you give an estimate of how long building such a custom system took? As I mentioned in my post, I’ve tried to find the simplest way to quickly implement video without having to encode on the fly or use any special upload tools.

To recap it seems that you:

  • Created a custom uploader
  • Uploader was hosted on a seperate server and communicated with Drupal via FormAPI
  • Video files are encoded on the fly using FFMPEG?

And future updates:

  • Opening the system up to public uploads
  • Instant feedback to users on upload status
  • Ability to modify uploads after the fact.

Well done, maybe you could write up the process with some code samples.

- Col

]]> By: Jamie http://blog.raisedeyebrow.com/2009/12/using-drupal-to-deliver-video/comment-page-1/#comment-2248 Jamie Tue, 22 Dec 2009 17:49:31 +0000 http://blog.raisedeyebrow.com/?p=103#comment-2248 For crooksandliars.com, I ended up going with a 100% custom system. We needed the ability to handle multiple media files per post, so to do that I ended up using a quicktags system (similar to Wordpress). The video metadata is stored in it's own table, and has a very relational style system with numerous other tables to track video/post relationship, statistics and a few other minor items. This system has worked out very well the 14 months we have been running it and I am getting ready to roll out another major update to it in the next month or so. Currently I am using SWFUpload to handle the file uploads, but am moving to a totally separate uploader. This uploader will actually be a separate server on a subdomain. The upload form is still a Drupal form, but the action is set to the special uploader. All validation and handling is done there, then the results are passed back to Drupal, so the actual use of this separate server isn't that obvious to the end user. The big advantages of this is being able to use a different method for upload progress (php_upload_progress), while still being able to maintain APC on the main site. Also our video encoding is handled by a separate server, and the uploads will now go directly to that server instead of to the main web server and then have to be transferred over to the encoding server. There was a big headache getting this working, mostly with cross-domain XHR requests. To overcome that I had I decided to use the database and special keys transferred between the requests, stored with the appropriate action data in the database (ie: validation errors, success, etc.) We are getting ready to open up video uploads to our general membership next year, so security was a big concern. Going this route I was able to add in a lot of extra security, plus have the added benefit of parsing the video meta out of the uploaded file directly from FFMPEG as soon as the upload is complete. That's a big bonus as our end users will instantly know if there is a problem with the uploaded video or not. It will also instantly create a screen grab from the video once uploaded. After the video is fully encoded and live, users will have the option to go back and change the screen cap (either by uploading a new one, or using a special Flash based editor I developed) and/or trim the video length. For crooksandliars.com, I ended up going with a 100% custom system. We needed the ability to handle multiple media files per post, so to do that I ended up using a quicktags system (similar to Wordpress). The video metadata is stored in it’s own table, and has a very relational style system with numerous other tables to track video/post relationship, statistics and a few other minor items.

This system has worked out very well the 14 months we have been running it and I am getting ready to roll out another major update to it in the next month or so. Currently I am using SWFUpload to handle the file uploads, but am moving to a totally separate uploader. This uploader will actually be a separate server on a subdomain. The upload form is still a Drupal form, but the action is set to the special uploader. All validation and handling is done there, then the results are passed back to Drupal, so the actual use of this separate server isn’t that obvious to the end user.

The big advantages of this is being able to use a different method for upload progress (php_upload_progress), while still being able to maintain APC on the main site. Also our video encoding is handled by a separate server, and the uploads will now go directly to that server instead of to the main web server and then have to be transferred over to the encoding server.

There was a big headache getting this working, mostly with cross-domain XHR requests. To overcome that I had I decided to use the database and special keys transferred between the requests, stored with the appropriate action data in the database (ie: validation errors, success, etc.)

We are getting ready to open up video uploads to our general membership next year, so security was a big concern. Going this route I was able to add in a lot of extra security, plus have the added benefit of parsing the video meta out of the uploaded file directly from FFMPEG as soon as the upload is complete. That’s a big bonus as our end users will instantly know if there is a problem with the uploaded video or not. It will also instantly create a screen grab from the video once uploaded. After the video is fully encoded and live, users will have the option to go back and change the screen cap (either by uploading a new one, or using a special Flash based editor I developed) and/or trim the video length.

]]>