scenario:
i am using a site built with the php based social framework called elgg (www.elgg.org) and am extending elgg to stream video.
i discovered that nginx is not serving the mp4 files (for example) with the 'Accept-Ranges' header and thus without streaming support.
i am searching for a way to remedy this.
a 2nd issue is that the php overhead for repeatedly accessing the same file, through the elgg framework, is high and thus needs to be mitigated somehow.

what i know:
after some debugging, i found that elgg stores the video files in a directory that is outside of the root of the virtual site that is defined by my nginx configuration and this is resulting in some aspects of nginx (streaming) processing not being applied to the video files when they are served. i am not 100% clear whether the missing processing is that which occurs due to the presence of the mp4 directive, or due to a different core process of nginx. either way, files that are placed within the root of the site (as defined in the virtual site config file) stream correctly and those that are in the elgg data folder do not stream, they load as static files and cannot be played from arbitrary start points.

the only solution i have found so far, that maintains any of elgg's ability to provide security levels to access to the files, is to create a new PHP file in my site that provides the media streams and which outputs an 'X-Accel-Redirect' header, which is then cached - such that each subsequent access to the streamed file is redirected via the redirect header and no PHP is processed (in theory).

however, i have not been able to test this because when i coded what i thought might produce the desired results, i found that nginx was always processing the location block that is designated for .php files within the site's config file and skipping the new location block that i created for the streaming files.

the new location block is:

location /stream/
{
root /var/www/data_dev;
internal;
add_header "stream" "mp4";
mp4;
mp4_buffer_size 4M;
mp4_max_buffer_size 20M;
gzip off;
gzip_static off;
}

which uses the 'internal' directive (http://nginx.org/en/docs/http/ngx_http_core_module.html#internal) to make the data store available internally via redirects. i have not been able to test this though, since the .php block always over-rides this /stream/ block.

in any case, i don't think this is a usable approach, since from what i can tell, even if this works, the security will be lost from the data folder and thus the entire element of privacy will be lost from the site.

anyone got any thoughts to add here?
thanks

(this is a continuation of my thread here: http://forum.nginx.org/read.php?2,251236 - which i have relocated to provide a more accurate thread title)