anyone excited to team up to create an enhanced video plugin for elgg?

i am beginning the process of creating a new version of 'videolist' for elgg and would appreciate assistance from anyone who can assist me.

features i intend to include:

  • on-server videos - integrated in with external videos (using the file plugin).
  • integration of a media player - currently i am using projekktor - though may possibly switch for stability reasons.
  • support for different sizes of video thumbnails from external sites.
  • support for more external sites than the default videolist support scope.
  • support for playlists (projekktor supports its own approach to youtube style playlists and also supports youtube videos directly, so youtube videos can be played inside your own themed media player).
  • many configuration options for the admin.
  • option: video river entries load as images and are replaced by a media player when clicked.

other features can be added too, however, these are my current list.

  • right so the issue of mp4 files not streaming correctly with nginx appears to be related to the same issue that was previously highlighted in this thread about the elgg engine being triggered for every video.

    essentially if i access an mp4 file from, for example, the root of my site - i can stream it correctly. if i upload the file to the elgg file plugin and attempt to stream that, the nginx config/server is treating it as a php file instead of an mp4 file and thus does not serve it in an appropriate way for streaming (i think).

    so essentially it would appear that we need to change the way that elgg handles files in some way, for this and other features to function as needed.
    i have a thread here in the nginx forum on this: http://forum.nginx.org/read.php?2,251236

  • @steve_clay - i read about X-Sendfile on an nginx page and also an apache page (http://www.brighterlamp.com/2010/10/send-files-faster-better-with-php-mod_xsendfile/).

    though i am not grasping 100% what exactly this achieves, from what i have read..

    if a php process is adding the X-Sendfile header and then the server responds to that by stopping php processing and sending the video file, why is that a significant improvement over just using php to trigger a file sending action and then exiting?

    does anyone have experience of resolving this with elgg yet?

     

  • if a php process is adding the X-Sendfile header and then the server responds to that by stopping php processing and sending the video file, why is that a significant improvement over just using php to trigger a file sending action and then exiting?

    I'm not too familiar with X-sendfile, but I understand that there are at least two use cases:

    1. Seeking would normally trigger the the PHP code again, but not with X-sendfile
    2. It adds all the cache-headers, so you can access the same video the next day without triggering the PHP code again
  • but how to add the X-sendfile header without using PHP!?

  • there is an nginx config option called 'internal' which i am testing, which may assist in exposing the files held in the datastore, without loading the php engine. however, i do not currently know how to point nginx to the correct video within the datastore, without invoking PHP.. i can only point to the main data root folder and assign it an alias.
     

  • but how to add the X-sendfile header without using PHP!?

    I'm guessing the very first request has to go through PHP.

    i do not currently know how to point nginx to the correct video within the datastore, without invoking PHP

    Not using PHP at all requires the file URL to include parameters that can be used to locate the file inside the dataroot.

  • I'm guessing the very first request has to go through PHP.

    and then each subsequent request would re-access the same url that was used for the first request, so the same php would be triggered again.

    Not using PHP at all requires the file URL to include parameters that can be used to locate the file inside the dataroot.

    yes, so i would either need to change the url so that it reflects the structure of the datastore, or i would need to custom code some fairly complex processes into the server config to mirror what would have been done via php.. which is an uncharted area for me and i have no evidence that to do so would be magically more efficient than using php. hmm.
    i am also wondering whether this issue of not using PHP is significant with nginx, or whether it is only apache's less efficient memory usage that causes the efficiency/resource issues that need to be overcome.

  • and then each subsequent request would re-access the same url that was used for the first request, so the same php would be triggered again.

    Not if the PHP script adds the X-sendfile header on the first request.

  • aha, ok, i see.. i missed the meaning of that part about caching.
    so the cache headers must be set to cache for at least several hours.

    so maybe all i need to do is create a new page handler case for the file plugin called 'stream' and then serve the relevant file using php and the X-sendfile header via that new page/view. i already coded most of this, so i will explore this now. :)

  • hmm.. actually, no.. this will not work, since i am essentially allowing access to the entire elgg datastore just by prefixing the request with the magic word 'stream'.

    X-sendfile may resolve the challenge of how to handle multiple requests for the same file without triggering php.. but it does not resolve the issue of allowing the webserver to identify and process video files in specific ways if they are outside of the root location of the site.

    if i implement the type of structure seen here: http://kovyrin.net/2006/11/01/nginx-x-accel-redirect-php-rails/
    then i may be able to provide access in almost the right way, yet if i include security checks in the initial php load of the video, then the video would remain cached and streamable to visitors for a while, even after the content owner changes the privacy of the item to private.. (as far as i am aware).