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.

  • No, you're mixing up making a HTTP request and loading the Elgg engine.

  • you wrote:

    Engine gets loaded for the page but the video comes through a separate request, which requires the engine to be loaded a second time

    so i wrote:

    even if i just embed a media player (e.g. jwplayer / projekktor etc.) on an elgg page that was created using elgg engine, that there is a 2nd request for the video object?


    when i referred to the 2nd request (for the video) i was referencing that you wrote that the 2nd request requires the elgg engine to be loaded for a 2nd time. hence my surprise when you drew in the loading of css/js files too. i think you are the one who is mixing up the context here.. ;)

    fyi, there is an nginx webinar starting shortly on the exact topic of serving/streaming videos.. it's still listed on the nginx website i think. i will listen and possibly record it.

  • the nginx webinar was nearly entirely to cover the commercial licensed nginx-plus media features.

  • @Ura Browser caching mostly eliminates the CSS/JS requests. The video responses are probably much less likely to use cache. The size of the video isn't the big issue (readfile efficiently streams from disk to output), it's that the PHP request can be expensive (if you have to boot Elgg for every range request) and readfile must hold open the Apache process until the video completes/client disconnects. Google "X-Sendfile".

    One way to make that video request lighter: if the video is public, embed in the stream request a timestamp and MAC of the URL. Then your stream request endpoint can verify the resource is public without ever checking the DB (though you need to get the MAC key and path to the video somehow). But the basic idea is to use the HTML page to fetch info you'd normally need to look up in the stream responses.

  • so are you saying that an instance of the the engine is loaded for every css/js request, except that due to caching schemas this rarely occurs?

    i am not certain, though i think that nginx handles the process of serving streaming video differently to apache - i don't know all the details presently, however there are flv and mp4 modules pre-packaged with standard nginx and these do effect the way streaming of these formats is performed.

    i appreciate that booting elgg for every range request would be highly inefficient.

    i am not comrehending your idea regarding the MAC address here. i thought MAC addresses were for physical hardware only.. so not clear on what 'MAC of the URL' translates to.

    i might be mistaken, but i suspect that projekktor handles the http pseudostreaming functions in a way that is not being appreciated fully here - since i have not heard of anyone in the forums there needing to address the types of issues being raised here.

  • so are you saying that an instance of the the engine is loaded for every css/js request, except that due to caching schemas this rarely occurs?


  • oh ok, so clearly i have no idea of the process schema of the elgg engine.. i have never seen this documented much anywhere. i searched the old and new docs pages.. didn't find anything helpful yet.

  • Can reloading the engine (with all plugins) for css and js ony be avoided if you use simple_cache ?

  • Yes, how else would you get js/css files from cobbled together views?  You need the elgg engine to stitch those views together into a js/css file.  That's why simplecache is recommended for production environments.

  • Hmm, this is a serious issue. Why is elgg_register_js and elgg_register_css than not fixing this ? Instead of recommending it, it should be doing it for us.

    At least I know what I will be doing the coming days. Check a 100+ plugins for following the recommendation.